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-evcorr/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
