[Xymon] how to check current kernel version
Ralph Mitchell
ralphmitchell at gmail.com
Sat Dec 3 22:57:44 CET 2011
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 -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 <
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20111203/7485ea48/attachment.html>
More information about the Xymon
mailing list