Risto Vaarandi wrote:
> [EMAIL PROTECTED] wrote:
>> I have a simple SEC rule to watch daily log files for network switch
>> events and notify me if it sees any messages that are new in the past
>> week. Whenever the system is rebooted (ie. updates, hardware
>> maintenance, etc.) there's a flurry of notifications as the rule
>> re-builds the supressions. The ideal solution would be to have SEC
>> somwhow save it's context periodically and be able to re-load that when
>> it's started, but I don't see how to do that. Is there a better way?
>
...the approach I suggested works if you are doing event suppression
with the help of contexts (Single rule combined with a suppression
context with a certain lifetime). However, it is not straightforward to
extend this approach for saving and restoring SEC's internal data
structures that contain data for event correlation operations. Firstly,
the keys of these operations depend on the content of rule files - if
these are changed between restarts, there could be operations restored
from disk to memory that don't correspond to any of the rules. In
addition, there are also some caveats when restoring the state of Pair*
rules which are not easy to overcome with current data structures.
Therefore I'd suggest to use this approach for saving/restoring contexts
only.
hth,
risto
> Hugh,
> that's an interesting question - it was discussed in the mailing list
> several years before, but I couldn't find the thread in the list archive
> (unfortunately, posts for the relevant date are not saved).
> However, I found one of the mails in my private folder, and will repost
> it - hopefully it answers your question:
>
> Risto Vaarandi wrote:
> > Tycho Fruru wrote:
> >> Hi,
> >>
> >> I suppose one could try to dump the complete structure of
> >> %context_list with Data::Dumper or Storable upon receipt of SIGINT (or
> >> perhaps using an internal event), and then add an option to read back
> >> the dumped %context_list when restarting... I suppose this should work
> >> and it wouldn't be very difficult to implement - but I'd like some
> >> confirmation from Riso or someone else that this is indeed the right
> >> track ...
> >
> > hi Tycho,
> >
> > I think this is actually the best way to solve the problem, because it
> > doesn't require any code modifications or messing with SEC internals. I
> > feel glad that SEC is written in Perl, because instead of reinventing
> > the wheel we can use existing modules :)
> >
> > I made some tests with Storable module (like Data::Dumper, it is
> > included in the standard installation of Perl), and found that the
> > following simple ruleset works nicely:
> >
> > type=Single
> > ptype=RegExp
> > pattern=context (\S+)
> > desc=create $1
> > action=create $1 300 (create TEST 10 write - end; report $1 /bin/cat)
> >
> > type=Single
> > ptype=RegExp
> > pattern=add (\S+) (\S+)
> > desc=add $2 to $1
> > action=add $1 $2
> >
> > type=Single
> > ptype=SubStr
> > pattern=SEC_STARTUP
> > desc=Restore contexts
> > action=eval %o ( use Storable; %main::context_list =
> > %{retrieve("CONTEXTS")} )
> >
> > type=Single
> > ptype=SubStr
> > pattern=SEC_SHUTDOWN
> > desc=Store contexts
> > action=eval %o ( store(\%main::context_list, "CONTEXTS") )
> >
> > The only thing you have to know about SEC internals is that contexts are
> > stored in the list called %main::context_list.
> >
> > The only slight problem with the ruleset is that SEC creates an internal
> > context called SEC_INTERNAL_EVENT when SEC_STARTUP event is generated.
> > In my ruleset I have called %main::context_list =
> > %{retrieve("CONTEXTS")}, which overwrites entire context list, including
> > SEC_INTERNAL_EVENT. Therefore, it would be a good idea to either make
> > the context loading the very last step of the SEC_STARTUP initalization
> > procedure, or save $context_list{SEC_INTERNAL_EVENT} into a temporary
> > value, reassigning it after retreive(). (note, however, that since
> > store() is called when SEC_SHUTDOWN event appears, the
> > SEC_INTERNAL_EVENT context is actually written to the CONTEXTS file and
> > restored SEC_STARTUP event is observed :)
> >
> > I have also studied the SEC code for possible caveats, but so far
> > haven't found any that would prevent the use of the Storable module.
> >
> > Thanks for the excellent idea :-)
> >
> > br,
> > risto
> >
> >
> >>
> >> Best regards,
> >> Tycho
> >>
> >>
> >> On Wed, 20 Oct 2004 18:01:38 +0200, Peter Eckel <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>
> >>> I am in the process of building a SEC-based event correlation system
> >>> for a customer. One of the development goals is to make contexts
> >>> persistent across SEC restarts (they occur quite infrequently, wihich
> >>> is why there is no very high priority on this topic).
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >> Use IT products in your business? Tell us what you think of them.
> Give us
> >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> >> more
> >> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >> _______________________________________________
> >> Simple-evcorr-users mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
> out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Simple-evcorr-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
> >
>
>
>
>> Hugh Fraser | Senior Technical Specialist
>> ArcelorMittal Dofasco
>>
>> Information Systems | Box 2460, 1330 Burlington St. E.
>> Hamilton, Ontario L8N 3J5
>>
>> T 905-548-7200 x6941 | F 905-548-4554
>> _www.arcelormittal.com_ <file://www.arcelormittal.com> |
>> _www.arcelormittal.com/hamilton/dofasco_
>> <file://www.arcelormittal.com/hamilton/dofasco>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Simple-evcorr-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Simple-evcorr-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
