[osiris-devel] monitoring host state

[Brian Wotring]

On Jan 23, 2004, at 4:53 PM, Alexei_Roudnev wrote:

> 1) Can anyone remind me, what is filter syntax for Windows (which have 
> not
> reg-exp) so that if I want to disable some atrribute checks (bytes, 
> blocks,
> mtime, ctime, inode) I can do it (manager is windows, but target 
> systems are
> different)?

There is no regex support for Windows, therefore, you must specify the 
complete host and path.  This is a real pain until we find a way to put 
in regex support for Windows.

This is one of the less important reasons to not run the management 
console on Windows.  It is not recommended unless you have no other 
options.  This may be the case for you, so I'll leave it at that.

> Brian, may be, we just write out simplified reg-exp functions (able to
> recognize 'xxx', '*xxx' and 'xxx*') or even just (* and xxx where xxx 
> is
> exact string), to have windows and unix syntax the same? For now, I 
> was not
> able to get success with filters?

I think the real solution is to not add this to the code but, instead, 
add regex support so all it behaves just as it does on all the other 
platforms.

> 2) As you remember, I applied a patch, which calls 'config' (print 
> current
> config name) in the end of all configuration lists (so we have current 
> name
> in allcommands, which require to enter configuration name - it is 
> impossible
> to work without it).
> First of all, where (if any) was this feature incorporated (which
> versions) - 3.*? /if 3.*, can we include it into 2.4 release as well?/
> Second, sometimes this patch cause 'osiris' to loop during 2 - 5 
> minutes
> (90% CPU - osiris and 10% cpu - osirismd) before printing result (it 
> happens
> 1 time during all session). I (still) have not windows exe files, 
> compiled
> in debug mode (do you have it in the new version?), so there is not 
> simple
> way to figure out, what is it going.

I don't know what is going on in your patch.  The 3.x branch does have 
support for defaulting to the used config for all related commands.  I 
think we can merge these changes down into the 2.x branch as they are 
only CLI modifications, it wouldn't be too much trouble.

As far as the debug configuration goes, this is also only in the 3.x 
branch.  However, it's not difficult to create a debug configuration.  
Just clone the release and add the DEBUG flag in the project settings.

> 3) How do we expect to distinguish configuration files for different 
> scanner
> versions? It is very important to be able to have different central 
> server
> (both, osiris and osirismd) and scanners, because it is unrealistic to
> update all 60 - 100 scanners at once, when new version arrives. So, it
> became very important to keep protocol compatibility, and to have some 
> way
> to distinguish configuration files.
>
> There are 4 possible approaches:
> 1 - ignore the whole problem. It works only if versions are fully 
> compatible
> for 1 - 2 years, which is not our current case.
> 2 - have backward compatibility, so that new options will be ignored 
> (even
> with warning, it is OK) by the old scanners.
> 3 - have different sets of configurations (use different directories).
> 4 - use # if # else (something like this) operators.

Well, the problem is that the current scan agent code doesn't have the 
ability to nicely ignore so any new code will require scanner updates.  
Of course, we will make our best effort to keep this from happening.

The 3.0 merge into mainline will require scanner updates.  However, it 
is not necessary that you update with each release.  If the current 
release doesn't have anything to offer you, it's recommended you not 
update.  There are many reasons for this.

--
     Brian Wotring ( brian at shmoo.com )
     PGP KeyID: 0x9674763D