June 2006 - Xymon - Xymon mailman web

Small modification to hobbitclient-linux.sh
by frederic.mangeant＠steria.com 05 Jun '06

05 Jun '06

Hi Henrik hobbitclient-linux.sh uses "uname -a" to report information about the OS, which gives something like this : Linux hades 2.6.14.2 #2 Wed Nov 16 10:14:26 CET 2005 i686 Pentium III (Katmai) GNU/Linux IMHO it would be great to display less information about the running kernel and add information about the Linux distribution, something like that : Linux 2.6.14.2 i686 - Gentoo Base System version 1.6.14 Linux 2.6.9-34.EL i686 - CentOS release 4.3 (Final) Linux 2.4.20-28.7 i686 - Red Hat Linux release 7.3 (Valhalla) Linux 2.4.26-vs1.28 i686 - Debian 3.1 Linux 2.4.18-64GB-SMP i686 - SuSE Linux 8.0 (i386) If you like this idea, I've tested the attached "patch" (on top of latest snapshot) with RedHat / CentOS, Gentoo, Debian and SuSE. Regards, -- Frédéric Mangeant Steria EDC Sophia-Antipolis

4 5

[hobbit] MRTG graphs
by jeffnewman75＠gmail.com 05 Jun '06

05 Jun '06

Thomas, I had the same problem. I changed the following line in my hobbitgraph.cfg file and my graphs started working: [mrtg] FNPATTERN mrtg.(.*).rrd # FNPATTERN mrtg.*\.([a-z0-9]+).rrd (original one) -Jeff On 5/5/06, Christophe Truffier <ctruffier at pack-solutions.com> wrote: > Henrik Stoerner wrote: > > On Wed, Apr 19, 2006 at 02:08:40PM +0200, Christophe Truffier wrote: > >>> do you have the other rrd files under the /var/lib/hobbit/rrd directory ? > >> Yes, all others file for this host (master) are in rrd/master dir: > >> # ls -latr /var/lib/hobbit/rrd/master/ > >> total 1131 > >> -rw-r--r-- 1 hobbit hobbit 105160 2006-04-19 13:55 mrtg.master.eth0.rrd > >> > >> I don't understand why all other tests except mrtg works... naming > >> problem ? whatever ? > > > > A bit late, but: What's in your TEST2RRD and GRAPHS settings in > > hobbitserver.cfg ? > > Here's what's in my hobbitserver.cfg: > TEST2RRD="cpu=la,disk,inode,qtree,memory,$PINGCOLUMN=tcp,http=tcp,dns=tcp, > dig=tcp,time=ntpstat,vmstat,iostat,netstat,temperature,apache,bind,send > mail,mailq,nmailq=mailq,socks,bea,iishealth,citrix,bbgen,bbtest,bbproxy,hobbitd" > > and > > GRAPHS="la,disk,inode,qtree,memory,users,vmstat,iostat,tcp.http,tcp,netstat, > mrtg::1,temperature,ntpstat,apache,bind,sendmail,mailq,socks,bea,iish > ealth,citrix,bbgen,bbtest,bbproxy,hobbitd" > > Regards > > -- > Christophe Truffier > Pack-Solutions > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

3 12

Hobbit SUID's
by jonescr＠cisco.com 04 Jun '06

04 Jun '06

I'm installing Hobbit for a client where root access is not available, and having SUID files is on an as-needed basis (as-needed as in "this app simply won't function without it), and even then only after having a darn good reason and approval from Infosec after they audit the code. As such, I am installing Hobbit as a normal user and get the following errors when I do "make install" chown 0 /users/monitor/local/hobbit/client/bin/logfetch /users/monitor/local/hobbit/client/bin/clientupdate || echo "" chown: changing ownership of `/users/monitor/local/hobbit/client/bin/logfetch': Operation not permitted chown: changing ownership of `/users/monitor/local/hobbit/client/bin/clientupdate': Operation not permitted chgrp 0 /users/monitor/local/hobbit/client/bin/logfetch /users/monitor/local/hobbit/client/bin/clientupdate || echo "" chgrp: changing group of `/users/monitor/local/hobbit/client/bin/logfetch': Operation not permitted chgrp: changing group of `/users/monitor/local/hobbit/client/bin/clientupdate': Operation not permitted (There were also errors for "hobbitping", which I understand why that needs to be SUID.) Can you tell me if these (logfetch and clientupdate) absolutely require being SUID root? I believe logfetch does not, provided that the user that hobbit is running as has permissions to read the specified files. It's a lot easier to get the security ninjas to do "chmod o+r /var/log/messages" than it is to convince them to SUID "some code you downloaded off the internet". What about "clientupdate". What does it do, and what does it use root access for? *pause for RTFM* Oka I just read the logfetch and clientupdate man pages, which seems to have answered those questions. I will post it here for anyone else who was wondering the same thing: ---snip--- SUID ROOT INSTALLATION logfetch may be installed with suid-root privileges. This allows Hobbit to monitor logfiles regardless of any access restrictions there may be in place for these files. If logfetch is not installed suid-root, it will of course only be able to monitor logs that it has read-access to. But logfetch will function without suid-root privileges. For security reasons, logfetch drops all root privileges except when opening logfiles. In particular, logfetch will not perform directory- utilitation scannings via the "du" command with root privileges, since an external command is used. It is therefore believed to be safe to install logfetch as suid-root. Note that if you choose to install logfetch with suid-root privileges, then the clientupdate utility will also need suid-root privileges, or these will be lost after an automated update of the client. When installing the new client software, any suid-root permis- sions set for the logfetch(1) utility were lost. The final step is to re-establish the suid-root privileges for the logfetch utility, by running the new clientupdate utility with the "--suid-setup" option. This sets the logfetch utility to suid- root, if possible. SUID-ROOT OPERATION clientupdate will attempt to perform some operations with root privi- leges, as described above. However, if it was not installed as suid- root initially, these operations will fail. This does not prevent clientupdate or the Hobbit client from working - it just means that permissions needed by the Hobbit client will have to be managed manu- ally, eg. you may need to modify permissions for logfiles such that the logfetch(1) utility can read them to check the logs. The Hobbit client is fully capable of running without any special privileges. ---snip--- So, correct me if I am wrong about any of these statements: 1. The ONLY hobbit binary that MUST be SUID root is "hobbitping" (because only root can send ICMP ECHO packets). 2. "logfetch" is SUID root for ease of monitoring root-owned logfiles. It does not need to be SUID if the monitored files are readable by the hobbit user. 3. "clientupdate" is SUID in order to restore the SUID bit of "logfetch", when a client update is rolled out via the automated mechanism. I should be able to convince the security folks to SUID hobbitping. Is there anything special about hobbitping itself, or can "fping" be used as a replacement? The only other comment I have is, since the man page specifically says that logfetch and clientupdate do not need to be SUID, either "make install" should not fail because of the chown errors, or there should be a --no-suid option to tell the installer not to attempt to make those SUID.

2 1

Extra script not firing
by rsmrcina＠wi.rr.com 04 Jun '06

04 Jun '06

It appears that after the 20060423 alfa (I'm currently running 20060601 beta), that the extra script isn't firing. I noticed that a custom graph isn't being populated and in the course of debugging I just added an echo of some text into a file from the beginning of the script. The file never appears. This leads me to believe that the script is not being executed. If more info is needed, let me know. Thanks. -- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007

3 3

[hobbit] system log and application log monitoring
by jeffnewman75＠gmail.com 04 Jun '06

04 Jun '06

Henrik, Is there a facility already in place, or a way to graph the number of "hits" returned by a pattern match for a log file? For instance: I am checking xyz log file for the word "wrap" It would be *very* useful to have a graph that shows the number of times that word showed up between the previous check and the current check. This could be very useful to illustrate, say, a disk dying (one blip of a bad read or something would be one thing, but looking at a graph over time that shows 1 blip one week, 10 the next, and 20 the week after that would indicate the disk was almost dead) etc... Right now, the only way I have to do this is with a client side script that runs in a constant loop: while true; do NUM=`grep "Buffer wrapped" /quotes/env/errlog | wc -l | sed 's/ *//g'` if [ $NUM -gt $INITIALNUM ] ; then WRAP_NUM=`expr $NUM - $INITIALNUM` $BB $BBDISP "status $MACHINE.wraps green `date` `echo "wraps:$WRAP_NUM"` " INITIALNUM=$NUM else OKNUM=0 $BB $BBDISP "status $MACHINE.wraps green `date` `echo "wraps:$OKNUM"` " fi -Jeff On 5/28/06, Henrik Stoerner <henrik at hswn.dk> wrote: > On Sun, May 21, 2006 at 07:29:49PM +0200, Olivier Beau wrote: > > > > well.. i was glad to find OS log files definitions in client-local.cfg > > Could there be basic OS pattern definitions in hobbit-client.cfg's DEFAULT ? > > You'll have to contribute some, then. I don't really know what people > are looking for in their logfiles. > > > next step: application log monitoring > > let's say i have 100 servers (differents OS of course) running mysql, and i want > > to follow "ended" in /var/log/mysqld.log > > ->setting up 100 entries in client-local.cfg doesn't seem great, could there be > > some kind of grouping in client-local.cfg (PAGE actually..) ? (i guess this > > would required to processing client-local.cfg before transferring to the clients..) > > Welcome to the world of configuration "classes". > > Step 1: Put a "CLASS:mysqlservers" on those hosts in bb-hosts. > Step 2: Put a section in your client-local.cfg file with > [mysqlservers] > logfile:/var/log/mysql/status.log > Step 3: Configure hobbit-clients.cfg for these logfiles. > > Only problem is that you'll need todays snapshot for this to work. > > > Regards, > Henrik > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

2 2

test/tests consolidaiotn
by hobbit＠razorsedge.org 04 Jun '06

04 Jun '06

Henrik, Are there any plans to consolidate the (for example) imap and imaps tests into one column like the http tests are? This would lessen the clutter I seem to have with all my tests. -- -mike

3 4

[hobbit] Alternate pageset and noconn ?
by henrik＠hswn.dk 03 Jun '06

03 Jun '06

On Tue, May 30, 2006 at 12:07:13PM +0200, Dominique Frise wrote: > Dominique Frise wrote: > >>This patch should fix it. It isn't pretty, but it should work. > > I think the fix does not cover the case where the same host should appear > on different pages of an alternate pageset. We have such cases where a > given host handles different services that should be grouped logically on > different pages (Databases, Directories, File Sharing, Mail). I'm sorry, but I don't see how that can be handled correctly with the way the alternate pagesets are currently built. I've said on a number of occasions that the alternate pageset handling needs some serious work; the current setup is just too inflexible and error-prone. So right now I'll consider this a bug, but one that will not be fixed for the moment. Regards, Henrik

2 1

hobbitd_alert crashes
by Dominique.Frise＠unil.ch 03 Jun '06

03 Jun '06

Hi, This is snapshot of 01 june running on Solaris 9. [bb at iris tmp]$ gdb ../bin/hobbitd_alert core GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... Core was generated by `hobbitd_alert --checkpoint-file=/soft/pub/BB/hobbit/server/tmp/alert.chk --chec'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1 #0 0xff1a05c8 in _libc_kill () from /usr/lib/libc.so.1 (gdb) Dominique UNIL - University of Lausanne

2 7

[hobbit] Generated Reports coredump
by henrik＠hswn.dk 02 Jun '06

02 Jun '06

On Wed, May 31, 2006 at 04:44:24PM +0100, Morris, Chris (Shared Services) wrote: > > This problem has been outstanding for quite a while now on AIX. > > When running the pre-generated reports, bbgen coredumps. I think this is related to how bbgen looks into historical logs to try and extract the cause of why a status has gone red. The only problem is that I simply cannot understand how the code is supposed to work ... The patch below solves the crash. Extracting the interesting bit of data from the historical logfile is tricky, but it does work in most cases. Regards, Henrik

1 0

[hobbit] Hobbit Ping
by tomg＠mcclatchyinteractive.com 02 Jun '06

02 Jun '06

Henrik Stoerner wrote: > Could you grab the latest snapshot, and in your hobbitserver.cfg set > > FPING="$BBHOME/bin/hobbitping --responses=3" > > This will make hobbitping report the average round-trip time for 3 > pings, like fping does. I would be interested to know if that helps, > and if it has any other consequences (like hosts being reported as > "down" when they are really up). I've been fighting a problem with false conn failures in 4.1.2p1 and I thought I'd try hobbitping to see if it helps. I'm not completely sure that I actually switched from fping to hobbitping, though, because I'm still seeing fping-std* files in server/tmp (as a result of "CMD bbtest-net --report --ping --checkresponse --debug" in hobbitlaunch.cfg.). Is fping in the filenames coming from the fping program itself, or are the files named that way b/c hobbit still calls hobbitping 'fping' because of the variable setting in hobbitserver.cfg? I built hobbitping from today's snapshot, into my server/bin/ directory, and make it suid root (4755, with root:bb ownership). Is there anything else I need to modify? Thanks, Tom

2 2