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
