[Xymon] batch configuration of critical systems?

[Martin Lenko]

Hi Richard,
we are using a cgi script to extract hosts from xymondboard and generate
our custom criticalhost views. Te make things simple we always use a "flag"
in page name so all hosts that are on "flagged" pages get extracted.

Here is one of our scripts that generate criticalview page for all live
systems:
#!/bin/sh

# Pick only hosts on the "live" pages
PAGE="live"

# Get red ones as priority 1
xymon 127.0.0.1 "xymondboard color=red fields=hostname,testname page=$PAGE"
| awk '{ print $1 "||||1|||" }' > /tmp/crit_$$.cfg
# Yellow ones get priority 2
xymon 127.0.0.1 "xymondboard color=yellow,purple fields=hostname,testname
page=$PAGE" |  awk '{ print $1 "||||2|||" }' >> /tmp/crit_$$.cfg

# Build the webpage
. /usr/lib/xymon/server/etc/cgioptions.cfg
/usr/lib/xymon/server/bin/criticalview.cgi $CGI_CRITVIEW_OPTS
 --config=/tmp/crit_$$.cfg

rm -f /tmp/crit_$$.cfg
exit 0


We made these scripts available through the web interface by adding them
into xymonmnu.cfg, .g.:
<a class="inner"
href="$XYMONSERVERCGIURL/criticalview-live.sh?MINCOLOR=purple">Live</a><span
class="invis"> | </span>

The advantage of this approach is that you can have multiple critical views
for various groups of hosts or services. You just need to know how to
generate the config file in the right format.

Regards,
Martin


On 16 October 2014 18:15, Thomas Eckert <thomas.eckert at it-eckert.de> wrote:

> Hi Richard,
>
> I created some entries through the web-interface including a “clone” a
> while back. After that I never touched the `criticaleditor` again.
>
> The “clones” provide a templating-mechanism that allows to define “host
> classes” that define the critical parameters (priority, instructions, …).
> These templates can used to copy a complete “critical-config” to a host
> (“ftp.local” uses the “template1”-config).
>
> The original hostname was replaced to match the class (“template1” in the
> example below) to keep things clean.
>
> Sample `critical.cfg`:
>
> template1|conn||||1|resolvergroup|instruction|admin 2014-10-16 19:00:00
> template1|cpu||||1|resolvergroup|instruction|admin 2014-10-16 19:00:00
> template1|disk|||W:0100:0400|2|resolvergroup2|instruction2|admin
> 2014-10-16 19:00:00
> template1|files|1388534400|1388966400|W:0100:0400|3|resolvergroup2|instruction2|admin
> 2014-10-16 19:10:00
> ftp.local|=xymon.local
>
> The fields are:
>
> hostname|testname|starttime|endtime|priority|resolvergroup|instructions|user
> timestamp
>
> To create a new class just copy the lines and adjust as needed.
>
> All the best
> Thomas
>
> On 16 Oct 2014, at 17:33, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:
>
> Thanks.  Since the man page for the file purposely does not document the
> format, how might one best determine that?  Creating a bunch of entries
> with the web interface _might_ do, if one carefully exercised each feature;
> or I suppose there’s the option of digging through the source.  Any other
> ideas?
>
>
> On Oct 15, 2014, at 10:51 PM, Jeremy Laidman <jlaidman at rebel-it.com.au>
> wrote:
>
> On 16 October 2014 11:58, Richard Hamilton <rlhamil2 at gmail.com> wrote:
>
>> Is there a recommended/supported mechanism to configure (and as needed,
>> update or replace the configuration) of critical systems from the command
>> line?
>>
>
> I doubt it.  There's only one binary that updates the critical
> configuration file, and that's criticaleditor.cgi.
>
> You might be able to cobble together a script that calls
> criticaleditor.cgi with the required parameters/environment to simulate a
> web browser. But it seems a lot of trouble, when you can just update the
> file.
>
> As far as I can tell, there's no locking in the web interface, so if two
> updates happen at around the same time, the second one wins, and the
> changes in the first save will be lost.  So I don't think you can make it
> much worse by implementing an extra interface to the file, but if you
> wanted to avoid concurrency problems like this, you could disable the CGI,
> and also include some kind of locking code in your own script.
>
> J
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20141019/3595661f/attachment.html>