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
criticaleditoragain.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