hi Richard,
it is good to hear the rule example is useful for you. Just one small note
-- the execution of 'lcall' action takes place in SEC process which is
single threaded, and custom perl code should not contain blocking function
calls (or anything that would run for significant amount of time).
Otherwise, the custom code would block the SEC process from doing anything
else.
This note is also relevant for my previous example, since perl 'open()'
function will block if it is invoked for a named pipe and the pipe does not
have a writer. For avoiding such situations, make sure that the file
pattern in the code will match regular files only, or check if the file is
a regular file before attempting to open it. Here is an example
modification to 'lcall' code from my previous post:
@files = grep { -f $_ } glob("*.log");
This code applies perl grep() function to original list of files, in order
to filter out files which are not regular files.
kind regards,
risto
Thank you, Risto, we could try to integrate lcall with calendar into our
> setup. SELinux was just theoretical example, we have no problem with that
> now, I was just seeking for bullet-proof solution.
>
> Richard
>
> st 8. 4. 2020 o 12:05 Risto Vaarandi <risto.vaara...@gmail.com>
> napísal(a):
>
>> hi Richard,
>>
>> if you want to find input files which can not be opened because of
>> permission issues, and want to conduct all checks specifically from SEC
>> process without forking anything, I would recommend to set up an 'lcall'
>> action that runs all checks from a Perl function. Since this function is
>> executed within SEC process, it will have the same permissions for
>> accessing the file as SEC itself. If you return one or more values from the
>> function, 'lcall' will set the output variable by joining return values
>> into single string, so that newline is acting as a separator between return
>> values. Also, if no values are returned from the function, output variable
>> will be set to perl 'undef'. After collecting the output from the function
>> in this way, you can provide the output variable to 'event' action that
>> creates synthetic event from its content. Note that if multi-line string is
>> submitted to 'event' action, several synthetic events are generated (one
>> for each line). And now that you have synthetic events about files that are
>> not accessible, you can process them further in any way you like (e.g., an
>> e-mail could be sent to admin about input file with wrong permissions).
>>
>> Here is an example rule that executes the input file check once a minute
>> from Calendar rule:
>>
>> type=Calendar
>> time=* * * * *
>> desc=check files
>> action=lcall %events -> ( sub { my(@files, @list, $file); \
>> @files = glob("*.log"); foreach $file (@files) { \
>> if (!open(FILE, $file)) { push @list, "$file is not accessible";
>> } else { close(FILE); } \
>> } return @list; } ); \
>> if %events ( event %events )
>>
>> The action list of the Calendar rule consists of two actions -- the
>> 'lcall' action and 'if' action, with 'if' action executing 'event' action
>> conditionally. The 'lcall' action tries to open given input files and
>> verify that each open succeeds. For all files that it could not open,
>> 'lcall' returns a list of messages "<file> is not accessible", and the list
>> is assigned to %events variable as a multi-line string (each line in the
>> multi-line string represents one message for some file). If the list is
>> empty, %events variable is set to perl 'undef' value. After 'lcall' action,
>> the 'if' action is executed which verifies that %events is true in perl
>> boolean context (if %events has been previously set to 'undef', that check
>> will fail). If the check succeeds (in other words, we have some messages to
>> report), the 'event' action will generate synthetic events from messages.
>>
>> That is one way how to check input files without forking anything from
>> SEC. However, if the root cause of the problem is related to SELinux, it is
>> probably much better to adjust SELinux configuration (perhaps by changing
>> file contexts), so that the problem would not appear.
>>
>> kind regards,
>> risto
>>
>>
>> Kontakt Richard Ostrochovský (<richard.ostrochov...@gmail.com>) kirjutas
>> kuupäeval E, 6. aprill 2020 kell 17:21:
>>
>>> Hello friends,
>>>
>>> I am thinking about how to monitor not only events from log files, but
>>> also those files existence and accessibility (for user running SEC) - in
>>> cases, where this is considered to be a problem.
>>>
>>> As I saw in the past, these were logged into SEC log file, but higher
>>> debug level was required, so it is not suitable for production.
>>>
>>> There are handful of other options how to monitor it "externally", e.g.
>>> via some script, or other monitoring agent, but this is not ultimate
>>> solution, as e.g. SELinux may be configured, allowing external script or
>>> agent (running under the same user as SEC) to see nad open file for
>>> reading, but not SEC (theoretical caveat of such solution).
>>>
>>> So, has somebody some "best practise" for reliable and production-ready
>>> way, how to "self-monitor" log files being accessed by SEC, if:
>>>
>>> - they exist
>>> - they are accessible by SEC
>>>
>>> ?
>>>
>>> Thanks in advance.
>>>
>>> Richard
>>> _______________________________________________
>>> Simple-evcorr-users mailing list
>>> Simple-evcorr-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>>
>>
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
