<p dir="ltr"><br>
On Jul 4, 2013 10:58 PM, "Jeremy Laidman" <<a href="mailto:jlaidman@rebel-it.com.au">jlaidman@rebel-it.com.au</a>> wrote:<br>
><br>
> On 5 July 2013 07:44, Ralph Mitchell <<a href="mailto:ralphmitchell@gmail.com">ralphmitchell@gmail.com</a>> wrote:<br>
>><br>
>> You should be very careful about how you validate this kind of automation.  The client should probably do some kind of verification, and use canned scripts rather than just running any command handed to it.<br>
><br>
><br>
> Yes.  With ssh, authorized_keys can force a particular command to run, rather than let an attacker dictate what gets executed.</p>
<p dir="ltr">I was thinking more of having restart scripts that vary from one machine to another. E.g. on one server just restart apache, on another perhaps clear cache and tmp files first. Xymon doesn't need to care about that.<br>

>  <br>
>><br>
>>   For example:<br>
>><br>
>> xymon adds to client-local.cfg for server1:   restartapache:`date+%s`<br>
><br>
><br>
> This is ingenious.  However it should be noted that it can take quite some time for changes in client-local.cfg to be actioned on the client.  Expect a 10-15 minute delay between the change to client-local.cfg and when the cron task picks it up - and that's if it runs every minute.</p>

<p dir="ltr">I already noted the delay. The action check script doesn't need to run from cron every minute. It can be hung on the end of the xymonclient.sh, to execute right after the local.cfg has been received when the client data message has been sent.</p>

<p dir="ltr">> It would be more responsive for the client cron task to just query the status from the server every minute, and act accordingly.  Something like:<br>
><br>
> #!/usr/lib/xymon/client/bin/xymoncmd /bin/sh<br>
> $XYMON $XYMSRV "query $MACHINE.http" | grep ^green >/dev/null || sudo service httpd restart<br>
> $XYMON $XYMSRV "query $MACHINE.smtp" | grep ^green >/dev/null || sudo service postfix restart</p>
<p dir="ltr">I've swapped out the client's xymon binary with a script that delivers the status report via secure https using curl posting to xymoncgimsg. I get back the local.cfg, but I haven't tried a query like that, though.</p>

<p dir="ltr">><br>
> This kind of automated restart can get you into a bit of trouble, so should be used with caution.  The last thing you want is a stack of run-away tasks that end up consuming all memory and CPU resources.  A change to make this a manually-triggered process might be for the client cron task to look for a disabled/acknowledged status using xymondboard, and detect when a special keyword (eg "!!RESTART!!") is entered into the disable/ack message.  Something like this:<br>

></p>
<p dir="ltr">The original poster asked about getting the Xymon gui to initiate restarts. I threw the in the timestamp as a way to limit multiple retries. When the client sees the restart message it can query a CGI on the Xymon server to see if the action still needs to be taken The CGI can look in Xymon and see the current color. If its green, then the answer if no. If red, do the restart, if blue, answer no because maybe the service is supposed to be down.</p>

<p dir="ltr">I think there would be less traffic that way.</p>
<p dir="ltr">> #!/usr/lib/xymon/client/bin/xymoncmd /bin/sh<br>
> RESPONSE=`$XYMON $XYMSRV "xymondboard host=$MACHINE test=http color=blue fields=lastchange,dismsg" | grep '!!RESTART!!' | cut -d"|" -f1`<br>
> [ `expr 0$RESPONSE + 60` -gt `date +%s` ] && sudo service httpd restart<br>
><br>
> This gets the status time for the host and test, but only if it's blue (disabled) and only if it contains the '!!RESTART!!' keyword.  The status time is compared to the current time and if within 60 seconds, runs the restart command.<br>

><br>
> J<br>
></p>
<p dir="ltr">Ralph Mitchell </p>