April 2012 - Xymon - Xymon mailman web

useradm.c - possible bug
by henrik＠hswn.dk 11 Apr '12

11 Apr '12

On 12-03-2012 15:22, John Horne wrote: > Hello, > > In Xymon 4.3.7 the useradm.c file around line 126 shows: > > ================================ > cmd = (char *)malloc(1024 + strlen(passfile) + strlen(adduser_name) + > strlen(adduser_password)); > sprintf(cmd, "htpasswd -b '%s' '%s' '%s'", > passfile, adduser_name, adduser_password); > n = system(cmd); > n = system(cmd); ret = WEXITSTATUS(n); > ================================ > > Just wondering why 'n = system(cmd)' is run twice? Why indeed ... cannot see how that makes sense. Deleted the extra call. Thanks, Henrik

1 0

Bug report for RRD graphs generated from devmon.
by KK1051＠att.com 11 Apr '12

11 Apr '12

I have found that RRD graphs that are generated from Devmon test that have a Note or other text after the "TABLE:rrd(DS:ds0:ifInEps:GAUGE)" section get counded as a line to link to a graph. Here is a sample:  Note: Error rates are per second, averaged over a 60 second interval. EEM errors match up with triggers set in EEM scripts using the inInErrors delta counter. The EEM script on the routers watch the counter and triggers the script when it crosses 10 errors. Then it holds the path out of OSPF till the error count drops back to Zero. This test will go yellow when one error is counted then turn red at 10. This is so we can see events leading up to the script triggering then monitor till it clears. When the script runs to build the page it finds the " line. I was getting 7 extra links to graphs for every host. If you see my Note: is 7 lines. I removed this and no longer get the extra links. I confirmed further checking the web page source and could see that the <-- linecount= was exactly 7 more than the lines before the --> of the RRD section. Kevin H. King Engineer V Implementations AT&T 404-444-0410 "You can not please everyone everyday, But everyday please everyone you can" -me

1 0

autofixing
by lebarber＠gmail.com 11 Apr '12

11 Apr '12

Resending to the list, Gmail seems to be hiding the "reply to all". Thanks, Larry Barber On Fri, Apr 6, 2012 at 4:28 PM, Larry Barber <lebarber at gmail.com> wrote: > The kind of things that you can automate should be handled routinely, not > be triggered by an alert from your monitoring tool. If you have logs > growing to fast that they are filling up you file system you should find > out what is filling them up and why and then fix that. Automatic log > rotation and compression should be done by a tool like logrotate, not Xymon > or any other monitoring tool. You shouldn't be using a monitoring tool to > trigger routine maintenance, it simply causes unnecessary alerts that cause > problems in other areas. > > Thanks, > Larry Barber > > > On Fri, Apr 6, 2012 at 4:06 PM, KING, KEVIN <KK1051 at att.com> wrote: > >> Larry,**** >> >> ** ** >> >> Some auto correcting is not bad. Back in the Big brother days I had a >> datacenter and team of folks. We managed to the “yellow” alerts. I had >> folks correct and build scripts to address the things that brought on the >> yellow so we never saw the red. This made it so very little red was ever >> seen.**** >> >> ** ** >> >> Now the things you can automate are the disk full kind of things. If that >> happens you can run a script to clean logs compress and that stuff. This >> was usually handled by managing the yellow. There would be a script in >> place to keep the space to below the yellow trigger. So if you got a red it >> was usually a bug temp file or something that would get cleaned shortly. So >> say on the red alert you could have it run the cleanup script rather than >> waiting for your cron to do the normal cleanup.**** >> >> ** ** >> >> Now on other issues it really depends on what the alert is about. You >> cannot automate everything economically. At some point it is cheaper and >> faster to put a human in the loop. I did have a script that would take the >> e-mail response from the alert and we could have it parse the message and >> do the work. This was back in the day with the RIM pagers. So you got an >> alert you replied to the alert with “run clean script on host” The reply >> e-mail was parsed in by the same script we were using to acknowledge the >> alert. It would parse and run a clean script. This let my admins be able to >> work issues while away from a PC or network connection.**** >> >> ** ** >> >> I do hear and agree with your concerns. A blanket statement from managers >> that do not have a full understanding of all the elements is a ruff thing >> to swallow. But there heart is in the right spot J **** >> >> ** ** >> >> I guess in a rather long rambling way I am saying that you learn and tune >> your systems. Address re-occurring issues so they do not. Then watch for >> the next thing to be addressed.**** >> >> ** ** >> >> ** ** >> >> -Kevin**** >> >> ** ** >> >> ** ** >> >> *From:* xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] *On >> Behalf Of *Larry Barber >> *Sent:* Friday, April 06, 2012 1:43 PM >> *To:* xymon at xymon.com >> *Subject:* [Xymon] autofixing**** >> >> ** ** >> >> My management has gotten the idea that we should be automating the repair >> processes on our servers. They want things set up so that when a fault is >> detected a script is run that attempts to repair it. I've tried to convince >> them that this is a profoundly wrong-headed idea, but I'm not having much >> luck. Do any of you know of any articles or resources that might help >> convince them? >> >> Thanks, >> Larry Barber**** >> > >

6 6

Feature - NTP stratum too high - test shows yellow
by john.horne＠plymouth.ac.uk 11 Apr '12

11 Apr '12

Hello, Using Xymon 4.3.7 the NTP test currently shows a green result if the NTP daemon is running, and red if not. However, what we want to know is if the NTP daemon is running, but not synchronised to any high stratum clock. When this happens the NTP daemon will return time based on the servers own local clock (if so configured), and this will usually be a low stratum value (on RHEL/CentOS this is stratum 10). We don't want this, and want to be warned if it happens. Attached is a patch which will allow admins to specify at what stratum level the 'ntp' test should turn yellow. If the returned stratum value (from 'ntpdate') is greater than or equal to the given value, then the 'ntp' test will show yellow. If the stratum is not specified, then the ntp test uses the default behaviour (that is, no test of the stratum value). This does not work if sntp is used. I had a look at this, but it seems that older versions of sntp did not return the stratum value. New versions do, but as far as I can gather sntp is not usually supplied because of licensing problems. John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001

5 9

Question on rrd parsing of disk report
by Mark.Deiss＠acs-inc.com 11 Apr '12

11 Apr '12

It looks like I need to spend time with the xymond/rrd/do_disk.c source code. I can see where the code would have an issue handling the BB test variant. Have not figured out why the xymonclient df report section would also be acting up. -----Original Message----- From: Deiss, Mark Sent: Wednesday, April 11, 2012 10:51 AM To: xymon at xymon.com Subject: Question on rrd parsing of disk report I am running into an issue with my 4.33 and 4.37 Xymon servers with the received disk test results. I am running cases of either the BB df test or the Xymonclient module that reports df results. In both cases, the header line from the df output is being processed into an rrd database file and into graph entries (on 4.33 and 4.37 servers). I am not seeing this bahaviour with the Xymon demo site; the df header line is appearing in the disk detail web page; the graphs look fine there. Which file(s) should I be looking at where the df header line should be suppressed for rrd purposes? I thought maybe this would be defined in one of the configuration files but now am thinking it may be explicitly handled in of the C binaries. Googling around I see where there is mention of special filters required for usage with custom scripts but no mention on how the standard tests are being massaged to eliminate chaff lines.

1 0

History data
by Sridhar.Adapalli＠hhsc.state.tx.us 10 Apr '12

10 Apr '12

Hi I am using Hobbit v 4.2. I am monitoring some Linux servers as well as Windows servers. When I click on the 'HISTORY' button for any of the columns such as cpu, memory, etc. I get a message saying "Cannot open history file". I am able to see the history data for the Windows servers. Can someone please help me how to resolve this issue for the Linux servers? Thanks -- Sridhar

1 0

yum or rpm for Redhat 6
by tyler＠beloit.edu 09 Apr '12

09 Apr '12

Xymon experts, I am running the Redhat 6.2 64 bit OS. Is there a (yum) distribution channel for Xymon or perhaps a rpm src package for Redhat 6 to install from? Or will I need to build and compile it all from scratch from the given download package? Tim Tyler Network Engineer Beloit College

4 5

Xymon Internal Server Error
by indymichaelb＠gmail.com 06 Apr '12

06 Apr '12

or inodes On Fri, Feb 17, 2012 at 7:20 AM, Jeremy Ruffer <jeremy.ruffer at gmail.com>wrote: > Could you be out of disk space? > > Jeremy > > On 17 Feb 2012, at 11:11, Kapildev Khemraj <kapildev.khemraj.1 at bc.edu> > wrote: > > Greetings all,**** > > ** ** > > I have Xymon 4.3.5 running on redhat 5. It has been working fine for > quite some time. Around 3am this morning, the webpages display “internal > Server error”. I looked at the apache logs and Xymon logs and do not see > anything that is wrong or that could be causing this. Any help would be > greatly appreciated.**** > > ** ** > > Kapildev Khemraj**** > > ** ** > > ** ** > > _______________________________________________ > 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 > >

1 0

Configuration report
by Tom.Moore＠sas.com 06 Apr '12

06 Apr '12

I need to do a health check on all the servers we monitor and what thresholds/alerts are associated with it. However, the config report is quite huge due to the fact that the "procs" column apparently spits out the current process list of the machine. Also, according to the manpage confreport.cgi doesn't include analysis.cfg data. And this email from back in 2006 shows it hasn't been fixed. Anyone have any ideas on how I may accomplish this task efficiently for 1000+ servers? Henrik Stoerner wrote: > You're not crazy. The config report tool hasn't really been updated to > handle the new Hobbit client data, so the reports do look odd in 4.2.0. > > > Regards, > Henrik > > On Mon, Oct 16, 2006 at 01:49:03PM -0700, Charles Jones wrote: > >> Can anyone else check their conf report and confirm this? Just want to >> make sure that I'm not crazy :) >> >> -Charles >> >> Charles Jones wrote: >> >>> When I generate a confreport, under the "Local tests" section it lists >>> various tests and their thresholds. For example: >>> memoryNo-/-/-Yellow: swap/pagefile use > 80%, Red: swap/pagefile use > >>> 90% >>> >>> The problem I am experiencing, is that for "procs", instead of showing >>> what proc patterns are being checked along with their thresholds, it is >>> showing the actual PS output! Example: >>> procsNo-/-/-sshd (found 2, req. 1 or more)\n\n PID PPID USER STARTED S >>> PRI %CPU TIME %MEM RSZ VSZ CMD\n 1 0 root Aug 16 S 24 0.0 00:09:36 0.0 >>> 468 1540 init\n 2 0 root Aug 16 S 139 0.0 00:00:00 0.0 0 0 >>> [migration/0]\n 3 0 root Aug 16 S 139 0.0 00:00:00 0.0 0 0 >>> [migration/1]\n 4 1 root Aug 16 S 24 0.0 00:00:00 0.0 0 0 [keventd]\n 5 >>> 1 root Aug 16 S 5 0.0 00:00:21 0.0 0 0 [ksoftirqd/0]\n >>> >>> This creates a HUGE confreport that is basically unreadable since it >>> contains pages and pages of ps output. Surely this is a bug? >>> >> To unsubscribe from the hobbit list, send an e-mail to >> hobbit-unsubscribe at hswn.dk<http://lists.xymon.com/mailman/listinfo/xymon> >> >> >> > >

1 0

autofixing
by lebarber＠gmail.com 06 Apr '12

06 Apr '12

My management has gotten the idea that we should be automating the repair processes on our servers. They want things set up so that when a fault is detected a script is run that attempts to repair it. I've tried to convince them that this is a profoundly wrong-headed idea, but I'm not having much luck. Do any of you know of any articles or resources that might help convince them? Thanks, Larry Barber

1 0