batch configuration of critical systems?
list Richard Hamilton
Is there a recommended/supported mechanism to configure (and as needed, update or replace the configuration) of critical systems from the command line? Assume an external database of service levels or priorities, from which the importance of monitored systems can be determined; and probably some heuristics to expand that into which tests for which hosts to treat as critical. I want to write a script to fetch that and create/update/replace the critical systems configuration on a xymon server; not live from the database, but periodically (probably run by cron as needed, e.g. 4x daily weekdays or something like that).
list Jeremy Laidman
▸
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
list Richard L. Hamilton
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
list Thomas Eckert
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
list 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 <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