[osiris-devel] monitoring host state

[Alexei_Roudnev]

> > 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.
Why don't treat -empty- fiend as ANY - no one field can be empty (in output)
so empty field have not other meaning, anyway.
And add reg-exp support onto 3.0.

Another improvement can be - classify changes by levels, and show only 1
level changes per file. For example, if checksum changed, it is no big use
to show 'bytes' change, 'blocks' change, 'ctime' and 'mtime' change (but
file atribute change is still a change). For now, when 1 file changes in the
system, we receive report '6 changes' instead of '1 change' (6 or 4, it
depends).

> > 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.
It's OK, let's try. I was bothered about CPU loop - I really saw it even on
1 host configuration, which is pretty strange. I applied the same change to
2.4.3 now, and have the same CPU loop (very first or second time, when
system request config, then it works fast). See atatchment - may be, this
change is not correct?

>
> 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.

Do you mean, that 3.0 protocol (manager / scanner) is other than 2.4
protocol? New configuration options does not require instant update; problem
is, that if new manager is not compatible with old agents, there is not
_ANY_ reasonable way to update a manager, except may be once / year - we
already have > 60 systems (scanners), so it takes few days to update all
scanners. In reality, such systems, as osiris (central manager and many
agents around) are updated once a few years (examples - BMC patrol; CA
unicenter; ProactiveNet; Tripwire; Intact) or NEVER (im my experience, it
was NEVER in all cases) - you can update central manager as often as you
wish, if it can work with old agents, but you have not any chance to udate
all agents at once, so you can not change a protocol so that new manager can
not work with old agents. I can say, that 100 agents is not a big
installation - you can have more agents in the network, and (what is worst)
can live without access to the agents machines.

This is exactly why I am trying to keep major (and cheap) improvements (such
as 'config' and '*' in filters) at 2.4 version - because, if you follow
standard numbering schema, 2.xx and 3.xx means _different protocols_ (2.4.1
vs 2.4.2 - improvement; 2.4.2 vs 2.5.1 - new features but compatible
protocol; 2.4 vs 3.0 - new protocol, system is not compatible). Fortunately,
you have not big osiris installations yet (you can not count me, I can
reinstall everything), but it will be a problem in next 1/2 year.


>
> --
>      Brian Wotring ( brian at shmoo.com )
>      PGP KeyID: 0x9674763D
>
> _______________________________________________
> osiris-devel mailing list
> osiris-devel at lists.shmoo.com
> https://lists.shmoo.com/mailman/listinfo/osiris-devel
>