Hi,
Thanks for sharing your codes Andy!. Really helpfull!. Also thanks to risto
for his answer(always helpful)!. I´m going to test it and i´ll tell you.
Regards!.
2018-01-27 16:35 GMT+01:00 Risto Vaarandi <risto.vaara...@gmail.com>:
> hi all,
> sec rule repository has been updated with new rules for Xymon:
> https://github.com/simple-evcorr/rulesets/tree/master/xymon
> I would like to thank Andy for sharing them with other sec users :-)
>
> kind regards,
> risto
>
>
> 2018-01-26 15:59 GMT+02:00 Risto Vaarandi <risto.vaara...@gmail.com>:
>
>> hi Andy,
>>
>> calling the signal handler which sets the relevant flag is another way
>> for addressing the problem.
>> Thanks for posting such a nice example to the mailing list :-)
>>
>> Since you mentioned sharing the relevant module, it would be a nice
>> candidate for sec rule repository: https://github.com/simple-evco
>> rr/rulesets
>> If you want to share it, please let me know.
>>
>> kind regards,
>> risto
>>
>>
>> 2018-01-26 15:15 GMT+02:00 Andy Smith <hastym...@googlemail.com>:
>>
>>> Hi,
>>>
>>> I have some sympathy, we look after servers where the owners will not
>>> permit the use of Cygwin.
>>>
>>> As a workaround, we load a module (Sec2Xym.pm) that includes this :-
>>>
>>> # Subroutine to provide access to native signal processing on platforms
>>> # where signals not supported, eg Windows with native perl (ActiveState,
>>> # Strawberry etc)
>>> sub fake_signal_handler {
>>> my ($fakesignal) = @_;
>>> given ($fakesignal) {
>>> when (/^HUP$/i) { main::hup_handler; }
>>> when (/^ABRT$/i) { main::abrt_handler; }
>>> when (/^USR1$/i) { main::usr1_handler; }
>>> when (/^USR2$/i) { main::usr2_handler; }
>>> when (/^INT$/i) { main::int_handler; }
>>> when (/^TERM$/i) { main::term_handler; }
>>> default: {
>>> main::log_msg(main::LOG_WITHOUT_LEVEL,
>>> "$SELF Unknown fake signal $fakesignal");
>>> return "Unknown fake signal $fakesignal";
>>> }
>>> }
>>> return 0;
>>> }
>>>
>>> Then we include --conf=etc/01control.sr --input=etc/control=CONTROL in
>>> the startup and have a ruleset like this that allows us to manipulate SEC
>>> via additions to a text file we control.
>>>
>>> ############################################################
>>> ###################
>>> # Rules to allow Windows implementations to be controlled when
>>> # no signals are otherwise supported
>>> ############################################################
>>> ###################
>>> type=single
>>> continue=dontcont
>>> ptype=tvalue
>>> pattern=TRUE
>>> desc=don't apply these rules unless from control file.
>>> context=! CONTROL
>>> action=none
>>>
>>> ############################################################
>>> ###################
>>> type=single
>>> continue=takenext
>>> ptype=tvalue
>>> pattern=TRUE
>>> desc=report event processed.
>>> action=create EVENT_PROCESSED
>>>
>>> ############################################################
>>> ###################
>>> type = single
>>> continue=dontcont
>>> desc = do a full restart of SEC
>>> ptype = regexp
>>> pattern = ^reset
>>> action = lcall %r HUP -> ( sub { Sec2Xym::fake_signal_handler(@_) } );\
>>> if %r ( logonly %r )
>>>
>>> ############################################################
>>> ###################
>>> type = single
>>> continue=dontcont
>>> desc = do a soft restart of SEC
>>> ptype = regexp
>>> pattern = ^reload
>>> action = lcall %r ABRT -> ( sub { Sec2Xym::fake_signal_handler(@_) } );\
>>> if %r ( logonly %r )
>>>
>>> ############################################################
>>> ###################
>>>
>>> I am happy to share these snippets in full if anyone is interested.
>>> --
>>> Andy
>>>
>>> On 26 January 2018 at 12:46, Risto Vaarandi <risto.vaara...@gmail.com>
>>> wrote:
>>>
>>>> hi Jaren,
>>>>
>>>> I can see that your rules are trying to emulate process control via
>>>> UNIX signals which are missing on Windows/Strawberry platform. However, I
>>>> would *not* recommend to call functions like read_config() directly, since
>>>> in sec source code they are executed with a number of additional
>>>> surrounding statements. For example, for clean execution of read_config() a
>>>> number of hash tables are cleared in sec-2.6.2 source code, but your rules
>>>> lack these statements. As a result, your sec instance will run with
>>>> inconsistent internal state which could also result in unexpected duplicate
>>>> output.
>>>>
>>>> If you want to emulate UNIX signals with Strawberry perl, probably the
>>>> only reasonable way for that is to set corresponding signal flags (as
>>>> signal handlers would do). For example, the following action list would set
>>>> the "softrefresh" flag that is raised by ABRT signal (this signal forces
>>>> SEC to reopen its inputs and reload its configuration):
>>>>
>>>> lcall %o -> ( sub { $main::softrefresh = 1; } )
>>>>
>>>> When sec sees this flag, it will execute the full code for handling the
>>>> ABRT signal and then clear the flag. Therefore, you would not have issues
>>>> from partial execution that would most likely lead to inconsistent/corrupt
>>>> internal state.
>>>>
>>>> Although the mailing list archive contains an example when USR1 signal
>>>> is emulated by calling dump_data() function directly, this example only
>>>> works since the handling of USR1 involves executing just dump_data(). But
>>>> for the sake of clarity I would personally use the signal flag approach
>>>> even for USR1.
>>>>
>>>> However, if you seriously need support for signals and other UNIX-like
>>>> functionality, I'd recommend to go with Cygwin perl.
>>>>
>>>> Hope this helps,
>>>> risto
>>>>
>>>> 2018-01-26 12:59 GMT+02:00 Jaren Peich <burkol...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a problem with the reading a processing the file logs wit SEC
>>>>> 2.6.2 on Windows. I use Strawberry Perl.
>>>>> I have a main file with regexp and Jump rules for post processing log
>>>>> lines.
>>>>>
>>>>> Example(invented):
>>>>>
>>>>> rem = Alert 001
>>>>> type = Jump
>>>>> ptype = RegExp
>>>>> desc = $0
>>>>> continue = DontCont
>>>>> pattern = (.*)
>>>>> varmap = alert;log=0;
>>>>> cfset = alertSet
>>>>>
>>>>> After this rules, previously we had problems with the reading and i
>>>>> added this calls from SEC library.
>>>>>
>>>>> #Force reopen file logs at 06:15
>>>>> type=Calendar
>>>>> time= 15 6 * * *
>>>>> desc= $0
>>>>> action= lcall %o -> ( sub { main::read_options(); main::open_input(-1,
>>>>> $keepopen); } )
>>>>>
>>>>>
>>>>> #Open Files not open yet
>>>>> #type=Calendar
>>>>> #time= */5 * * * *
>>>>> #desc= $0
>>>>> #action= lcall %o -> ( sub { main::open_input(0,1); } )
>>>>>
>>>>>
>>>>> #Reload configuration after 2 hours.
>>>>> type=Calendar
>>>>> time= */15 * * * *
>>>>> desc= $0
>>>>> action= eval %o (sleep 61;);\
>>>>> lcall %o -> ( sub { main::read_config(); } )
>>>>>
>>>>> The problem it´s when i rexecute(finish process and execute again)
>>>>> alerts get duplicated in the output file. any idea to solve this?
>>>>>
>>>>> I have another doubt where or how do you create file paths from log
>>>>> files in library?
>>>>>
>>>>> Sorry for my english.
>>>>>
>>>>> Thank you!. Regards. :)
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Simple-evcorr-users mailing list
>>>> Simple-evcorr-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
