how to check current kernel version
list Robert P McGraw
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? Robert P. McGraw, Jr. Manager, Computer System EMAIL: user-33cf07af04dd@xymon.invalid Purdue University ROOM: MATH-807 Department of Mathematics PHONE: (XXX) XXX-XXXX XXX N. University Street West Lafayette, IN XXXXX-XXXX
list Xymon User in Richmond
▸
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.
list Ralph Mitchell
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 -r`
# the 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":" -f2`
if [ "$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 <
▸
user-24d6f8323faa@xymon.invalid> 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.
list Xymon User in Richmond
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 -r` # the 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":" -f2` if [ "$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 < user-24d6f8323faa@xymon.invalid> 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.
list Ralph Mitchell
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 <
▸
user-24d6f8323faa@xymon.invalid> 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 -r` # the 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":" -f2` if [ "$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 < user-24d6f8323faa@xymon.invalid> 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.