Re: The checksum statement ++

[Martin Pala]

In addition to the solution described in my previous mail, it is 
possible to revert to old behavior, e.g. in the case of error, set 
(optionally) the expected test value to current erroneous value and stop 
monitoring by default. Monitoring stop must be handed by all dependants 
in both cases (previous and this proposal).

In such case however, it could be probably better to drop IF-THEN scheme 
for checksum, permission, uid and gid statements, because the behavior 
will be fixed/predicted and different from other statements/checks => 
instead of current:

if failed checksum then stop

write again:

checksum


I like better first proposal - it provides more power and from my 
personal point of view it is more clean and consistent with the language.

Cheers,
Martin


Jan-Henrik Haukeland wrote:

> I'm not at all happy with how the checksum is implemented now. For
> instance if I use this entry in monitrc:
>
> check file httpd.conf with path /usr/local/apache/httpd.conf
> if failed checksum 
>    then exec "/etc/init.d/apache restart"
> alert address@hidden
>
> 1) If the checksum for httpd.conf was changed then for *every* cycle
>   an alert is sent and apache restarted. This is not what we want!
>   In this case the old checksum should be set to the new checksum, so
>   apache is restarted only *once* and only one alert is sent.
>
> 2) In the example below we will call the apache stop program, but for
>   security reasons we do absolutely not want to do that! Instead we
>   should only send an alert and then *stop* monitoring the apache
>   entry (which was done in the original checksum implementation).
>
>  check apache with pidfile "/usr/local/apache/logs/httpd.pid"
>    start program = "/usr/local/apache/bin/http start" 
>    stop program  = "/usr/local/apache/bin/http stop"
>    alert address@hidden 
>    depends on httpd
>
>  check http.bin with path /usr/local/apache/bin/http
>    if failed checksum then stop
>
> I do not have a solution to this problem now and it's late. Maybe
> tomorrow or maybe others have already thought up a good solution by
> then :) 
>
>
> - On another note, please try to keep the code at 80 chars per
>  line. (Martin :) 
>
> - I'm not so hapy with the eval_action() function in validate.c
>  either. It's very awkward to use together with the new Event_post
>  "paradigm", also the report buffer is used there is not a good
>  solution either (for instance, report may be NULL, but Event_post
>  expect report to have a value in eval_action)
>
>  Good suggestions for refactoring this structure/function would be
>  highly appreciated and the one with the best solution wins a Kinder
>  Egg :-)
>
>