batch configuration of critical systems?

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 <user-2a86d6cd6326@xymon.invalid> 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 <user-af55987f6d56@xymon.invalid> 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 <user-71895fb2e44c@xymon.invalid>
wrote:

On 16 October 2014 11:58, Richard Hamilton <user-af55987f6d56@xymon.invalid> 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