Thank you! I think I originally saw the client-local trick in a Solaris iostat script. This one turned out simple enough to warrant posting as an example.
Ralph Mitchell
On Sat, Dec 3, 2011 at 2:30 PM, Xymon User in Richmond < hobbit at epperson.homelinux.net> wrote:
Neatly done. And the script is easily adaptable to use grubby if you want to check for the condition I mentioned instead of maintaining a cfg file for checking a specified version.
On Sat, December 3, 2011 13:57, Ralph Mitchell wrote:
Just out of curiousity I fooled around with this a bit last night. Seems easy enough to implement as an external test, if you're OK with having an extra column show up. Or maybe make a combo with something else, though I've never tried that at all.
========== client side: /home/xymon/client/ext/osver.sh ==========
#!/bin/bash
column name to report
TEST="osver"
our current os version
CURVER=
uname -rthe logfetch cfg file is filled by xymonclient.sh
LOGFETCH=${XYMONTMP}/logfetch.$(uname -n).cfg
Default to OK
COLOR=green MESSAGE="No OS version specified in client-local.cfg. OS version is: $CURVER"
anything interesting for us?
if [ -f "$LOGFETCH" ]; then OSVER=
grep "^OSVER:" $LOGFETCH | cut -d":" -f2if [ "$OSVER" ]; then # found OSVER in the cfg if [ "$CURVER" = "$OSVER" ]; then COLOR=green MESSAGE="OS version is correct: $OSVER" else # report mismatch COLOR=yellow MESSAGE="OS version is incorrect. $CURVER should be $OSVER" fi fi fi$XYMON $XYMSRV "status $MACHINE.$TEST $COLOR
date$MESSAGE"
exit 0
========= client side: /home/xymon/client/etc/clientlaunch.cfg ==========
[osver] ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg CMD $XYMONCLIENTHOME/ext/osver.sh LOGFILE $XYMONCLIENTLOGS/osver.log INTERVAL 5m
========== server side: /home/xymon/server/etc/client-local.cfg
[linux] OSVER:2.6.32-131.21.1.el6.x86_64
Obviously you would append the above line to any system-specific client-local.cfg entries.
The same approach works for *any* config value that you might want to pass from the server to the clients for client/ext scripts. I imagine there are probably some limitations on what special characters can be passed, but simple name/value pairs ought to be just fine.
Ralph Mitchell
On Fri, Dec 2, 2011 at 5:58 PM, Xymon User in Richmond < hobbit at epperson.homelinux.net> wrote:
On Fri, December 2, 2011 14:48, McGraw, Robert P wrote:
Xymon's "info" column for a host already reports the uname -r value. For example, on hardy, the info page shows
OS: Linux hardy.math.purdue.edu 2.6.18-274.7.1.el5xen x86_64
Question: is Xymon able to let us specify somewhere (client-local.cfg maybe?) what the current kernel version *should* be, so that when the current kernel is supposed to be 2.6.18-274.7.1 then we can have the info column go yellow or red for hosts that haven't been booted to that version yet?
If what you're after is essentially running kernel doesn't match kernel that will run on next boot, should be a fairly trivial ext script to compare contents of uname -r to grubby --default-kernel|sed "s/\/boot\/vmlinuz-//". That would be how to do it on Red Hat, looks like you'd also have to massage uname -r for hardy.
Don't know if it's already been done.
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