From holger at CIS.FU-Berlin.DE Tue Nov 1 10:35:15 2005 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue Nov 1 10:35:15 2005 Subject: [Nagiosplug-devel] PATCH: SMTP auth support in nagios plugin check_smtp.c In-Reply-To: <20051031212222.GD32185@platon.sk> References: <20051031212222.GD32185@platon.sk> Message-ID: <20051101183425.GC16376785@CIS.FU-Berlin.DE> * Lubomir Host [2005-10-31 22:22]: > Here is a patch that adds the ability to confirm that your SMTP AUTH > mechanism is working on your smtp server. I was going to do the same thing this week, thanks for saving me the work! ;-) FWIW, I've attached my backport of your patch to the 1.4.2 release of check_smtp in case it's useful for anyone. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE -------------- next part -------------- --- check_smtp.c.orig 2005-04-07 06:33:33.000000000 +0200 +++ check_smtp.c 2005-11-01 19:09:29.182255669 +0100 @@ -60,9 +60,10 @@ SMTP_PORT = 25 }; const char *SMTP_EXPECT = "220"; -const char *SMTP_HELO = "HELO "; +const char *SMTP_HELO = "EHLO "; const char *SMTP_QUIT = "QUIT\r\n"; const char *SMTP_STARTTLS = "STARTTLS\r\n"; +const char *SMTP_AUTH_LOGIN = "AUTH LOGIN\r\n"; int process_arguments (int, char **); int validate_arguments (void); @@ -95,6 +96,9 @@ int response_size=0; char **commands = NULL; char **responses = NULL; +char *authtype = NULL; +char *authuser = NULL; +char *authpass = NULL; int warning_time = 0; int check_warning_time = FALSE; int critical_time = 0; @@ -109,6 +113,47 @@ MAXBUF = 1024 }; +/* written by lauri alanko */ +static char * +base64 (const char *bin, size_t len) +{ + + char *buf = (char *) malloc ((len + 2) / 3 * 4 + 1); + size_t i = 0, j = 0; + + char BASE64_END = '='; + char base64_table[64]; + strncpy (base64_table, "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/", 64); + + while (j < len - 2) { + buf[i++] = base64_table[bin[j] >> 2]; + buf[i++] = base64_table[((bin[j] & 3) << 4) | (bin[j + 1] >> 4)]; + buf[i++] = base64_table[((bin[j + 1] & 15) << 2) | (bin[j + 2] >> 6)]; + buf[i++] = base64_table[bin[j + 2] & 63]; + j += 3; + } + + switch (len - j) { + case 1: + buf[i++] = base64_table[bin[j] >> 2]; + buf[i++] = base64_table[(bin[j] & 3) << 4]; + buf[i++] = BASE64_END; + buf[i++] = BASE64_END; + break; + case 2: + buf[i++] = base64_table[bin[j] >> 2]; + buf[i++] = base64_table[((bin[j] & 3) << 4) | (bin[j + 1] >> 4)]; + buf[i++] = base64_table[(bin[j + 1] & 15) << 2]; + buf[i++] = BASE64_END; + break; + case 0: + break; + } + + buf[i] = '\0'; + return buf; +} + int main (int argc, char **argv) { @@ -119,6 +164,7 @@ int result = STATE_UNKNOWN; char *cmd_str = NULL; char *helocmd = NULL; + char *error_msg = NULL; struct timeval tv; setlocale (LC_ALL, ""); @@ -198,6 +244,21 @@ printf (_("CRITICAL - Cannot create SSL context.\n")); return STATE_CRITICAL; } + + /* resend the EHLO command + * + * RFC 3207, 4.2 says: ``The client MUST discard any knowledge + * obtained from the server, such as the list of SMTP service + * extensions, which was not obtained from the TLS negotiation + * itself. The client SHOULD send an EHLO command as the + * first command after a successful TLS negotiation.'' + * + * For this reason, at least Exim will not allow an AUTH LOGIN + * command if we haven't resent EHLO. + */ + SSL_write(ssl, helocmd, strlen(helocmd)); + myrecv(); + if ( check_cert ) { if ((server_cert = SSL_get_peer_certificate (ssl)) != NULL) { result = check_certificate (&server_cert); @@ -256,7 +317,7 @@ regerror (errcode, &preg, errbuf, MAX_INPUT_BUFFER); printf (_("Could Not Compile Regular Expression")); return ERROR; - } + } excode = regexec (&preg, buffer, 10, pmatch, eflags); if (excode == 0) { result = STATE_OK; @@ -280,6 +341,107 @@ n++; } + if (authtype != NULL) { + if (strcmp (authtype, "LOGIN") == 0) { + char *abuf; + int ret; + do { + if (authuser == NULL) { + result = STATE_CRITICAL; + error_msg = _("no authuser specified, "); + break; + } + if (authpass == NULL) { + result = STATE_CRITICAL; + error_msg = _("no authpass specified, "); + break; + } + + /* send AUTH LOGIN */ +#ifdef HAVE_SSL + if (use_ssl) + SSL_write(ssl, SMTP_AUTH_LOGIN, strlen(SMTP_AUTH_LOGIN)); + else +#endif + send(sd, SMTP_AUTH_LOGIN, strlen(SMTP_AUTH_LOGIN), 0); + if (verbose) + printf (_("sent %s\n"), "AUTH LOGIN"); + + if((ret = myrecv()) < 0){ + error_msg = _("recv() failed after AUTH LOGIN, \n"); + result = STATE_WARNING; + break; + } + buffer[ret] = 0; + if (verbose) + printf (_("received %s\n"), buffer); + + if (strncmp (buffer, "334", 3) != 0) { + result = STATE_CRITICAL; + error_msg = _("invalid response received after AUTH LOGIN, "); + break; + } + + /* encode authuser with base64 */ + abuf = base64 (authuser, strlen(authuser)); + strcat (abuf, "\r\n"); +#ifdef HAVE_SSL + if (use_ssl) + SSL_write(ssl, abuf, strlen(abuf)); + else +#endif + send(sd, abuf, strlen(abuf), 0); + if (verbose) + printf (_("sent %s\n"), abuf); + + if ((ret = myrecv()) == -1) { + result = STATE_CRITICAL; + error_msg = _("recv() failed after sending authuser, "); + break; + } + buffer[ret] = 0; + if (verbose) { + printf (_("received %s\n"), buffer); + } + if (strncmp (buffer, "334", 3) != 0) { + result = STATE_CRITICAL; + error_msg = _("invalid response received after authuser, "); + break; + } + /* encode authpass with base64 */ + abuf = base64 (authpass, strlen(authpass)); + strcat (abuf, "\r\n"); +#ifdef HAVE_SSL + if (use_ssl) + SSL_write(ssl, abuf, strlen(abuf)); + else +#endif + send(sd, abuf, strlen(abuf), 0); + if (verbose) { + printf (_("sent %s\n"), abuf); + } + if ((ret = myrecv()) == -1) { + result = STATE_CRITICAL; + error_msg = _("recv() failed after sending authpass, "); + break; + } + buffer[ret] = 0; + if (verbose) { + printf (_("received %s\n"), buffer); + } + if (strncmp (buffer, "235", 3) != 0) { + result = STATE_CRITICAL; + error_msg = _("invalid response received after authpass, "); + break; + } + break; + } while (0); + } else { + result = STATE_CRITICAL; + error_msg = _("only authtype LOGIN is supported, "); + } + } + /* tell the server we're done */ #ifdef HAVE_SSL if (use_ssl) @@ -305,13 +467,15 @@ result = STATE_WARNING; } - printf (_("SMTP %s - %.3f sec. response time%s%s|%s\n"), - state_text (result), elapsed_time, - verbose?", ":"", verbose?buffer:"", - fperfdata ("time", elapsed_time, "s", - (int)check_warning_time, warning_time, - (int)check_critical_time, critical_time, - TRUE, 0, FALSE, 0)); + printf (_("SMTP %s - %s%.3f sec. response time%s%s|%s\n"), + state_text (result), + (error_msg == NULL ? "" : error_msg), + elapsed_time, + verbose?", ":"", verbose?buffer:"", + fperfdata ("time", elapsed_time, "s", + (int)check_warning_time, warning_time, + (int)check_critical_time, critical_time, + TRUE, 0, FALSE, 0)); return result; } @@ -336,6 +500,9 @@ {"command", required_argument, 0, 'C'}, {"response", required_argument, 0, 'R'}, {"nocommand", required_argument, 0, 'n'}, + {"authtype", required_argument, 0, 'A'}, + {"authuser", required_argument, 0, 'U'}, + {"authpass", required_argument, 0, 'P'}, {"verbose", no_argument, 0, 'v'}, {"version", no_argument, 0, 'V'}, {"use-ipv4", no_argument, 0, '4'}, @@ -359,7 +526,7 @@ } while (1) { - c = getopt_long (argc, argv, "+hVv46t:p:f:e:c:w:H:C:R:SD:", + c = getopt_long (argc, argv, "+hVv46t:p:f:e:c:w:H:C:R:SD:A:U:P:", longopts, &option); if (c == -1 || c == EOF) @@ -384,6 +551,15 @@ from_arg = optarg; smtp_use_dummycmd = 1; break; + case 'A': + authtype = optarg; + break; + case 'U': + authuser = optarg; + break; + case 'P': + authpass = optarg; + break; case 'e': /* server expect string on 220 */ server_expect = optarg; break; @@ -548,6 +724,15 @@ Use STARTTLS for the connection.\n")); #endif + printf("\ + -A, --authtype=STRING\n\ + SMTP AUTH type to check (default none, only LOGIN supported)\n\ + -U, --authuser=STRING\n\ + SMTP AUTH username\n\ + -P, --authpass=STRING\n\ + SMTP AUTH password\n\ + "); + printf (_(UT_WARN_CRIT)); printf (_(UT_TIMEOUT), DEFAULT_SOCKET_TIMEOUT); @@ -570,6 +755,7 @@ { printf ("\ Usage: %s -H host [-p port] [-e expect] [-C command] [-f from addr]\n\ + [-A authtype -U authuser -P authpass]\n\ [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6]\n", progname); } @@ -693,11 +879,11 @@ #ifdef HAVE_SSL if (use_ssl) { - i = SSL_read (ssl, buffer, MAXBUF - 1); + i = SSL_read (ssl, buffer, MAX_INPUT_BUFFER - 1); } else { #endif - i = read (sd, buffer, MAXBUF - 1); + i = read (sd, buffer, MAX_INPUT_BUFFER - 1); #ifdef HAVE_SSL } #endif From seanius at seanius.net Wed Nov 2 00:47:28 2005 From: seanius at seanius.net (sean finney) Date: Wed Nov 2 00:47:28 2005 Subject: [Nagiosplug-devel] PATCH: SMTP auth support in nagios plugin check_smtp.c In-Reply-To: <20051101133251.GF32185@platon.sk> References: <20051031212222.GD32185@platon.sk> <20051101071827.GA6168@seanius.net> <20051101133251.GF32185@platon.sk> Message-ID: <20051102084657.GA21433@seanius.net> hi lubomir, just sitting down with your patch now. is there any reason the block of login-related code goes before the list queued smtp commands? anyway, the code is clean and straightforward enough that i'll go ahead and commit it now. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From seanius at seanius.net Wed Nov 2 01:02:33 2005 From: seanius at seanius.net (sean finney) Date: Wed Nov 2 01:02:33 2005 Subject: [Nagiosplug-devel] Fwd: check_disk with inode usage? In-Reply-To: <2b36e660510311024m390838c1n4bda10788d8a4b71@mail.gmail.com> References: <2b36e660510310622p6f7fb360s127ed7c2773b159d@mail.gmail.com> <2b36e660510310628k70d777cdg4c6ba6885301cdfe@mail.gmail.com> <2b36e660510310705m58592259o3498028a80bc3233@mail.gmail.com> <20051031172422.GA31050@seanius.net> <2b36e660510311024m390838c1n4bda10788d8a4b71@mail.gmail.com> Message-ID: <20051102090153.GB21433@seanius.net> hi ben, On Mon, Oct 31, 2005 at 06:24:13PM +0000, Ben O'Hara wrote: > Ive attached a copy of the patch, its against the latest snapshot of HEAD. > > Ive got it running on Sol7,8,9 and FreeBSD4,5 machines and it appears > to be reporting back the correct info as far as inode usage is > concerned, and it doesnt appear to have broken the disk reporting. i've committed this to cvs. i see you did some stuff with the perfparse in the patch too--since i don't use perfparse myself i'll have to take your word that it doesn't break anything. otherwise, seems to work just fine. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Wed Nov 2 01:03:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 2 01:03:42 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-995761 ] check_disk to include inode percentage. Message-ID: Patches item #995761, was opened at 2004-07-22 04:21 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=995761&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Jorgen Lundman (lundman) >Assigned to: M. Sean Finney (seanius) Summary: check_disk to include inode percentage. Initial Comment: Since the 1.4.0alpha1 plugins code in check_disk, which calls fsusage.c, already retrieves the inode values I thought to patch it to also print inode percentage free. Additionally, I changed the static "0" in perfdata to be inode percent free. I added -W and -K (sorry, -C was taken) for inode percent warning and critical levels. Alas, only percentage implemented as of now. (No integer value support). Current output looks like: # ./check_disk -l -w 10% -c 2% -X tmpfs -W 10% -K 2% DISK OK - free space: / 31266 MB (93% inode=98%);| /=31266MB;30168;32850;97;33521 And indeed, brining up the -W warning value triggers a warning: # ./check_disk -l -w 10% -c 2% -X tmpfs -W 98% -K 2% DISK WARNING - free space: / 31266 MB (93% inode=98%);| /=31266MB;30168;32850;97;33521 Hope it helps more than it annoys. I could also have patched contrib/check_inodes for Solaris's "df -o i" call, but since nearly all the work was already done in check_disk I opted for that approach. Sincerely, Lundy ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-02 04:02 Message: Logged In: YES user_id=226838 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Jorgen Lundman (lundman) Date: 2004-07-22 23:45 Message: Logged In: YES user_id=286650 Additionally, there is a bug when you use -p, or -x, to list paths to include or exclude. The nodes allocated do not get w_df etc variables cleared, so when you walk the list, they get assigned to global w_df variables, and all tests are out the window. This is a side effect of an OS where malloc() returned memory is not zero'd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=995761&group_id=29880 From noreply at sourceforge.net Wed Nov 2 01:06:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 2 01:06:34 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: Bugs item #1291126, was opened at 2005-09-14 12:04 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Pending Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-11-02 04:05 Message: Logged In: YES user_id=226838 haven't heard back from ya, and haven't heard any complaints, so i'm going to set this one to "pending" and close it at the next release ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-10-07 13:50 Message: Logged In: YES user_id=226838 hi bob, any chance you've taken a look to see if check_procs now works for you from cvs? about the other issues, i guess i don't have the interest to look more into it if you don't :) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-25 11:23 Message: Logged In: YES user_id=226838 hi bob, i've now included your code in cvs head, and mangled the configure script appropriately, so pst3 should now be the default for all SunOS systems. could you try the latest copy of what's in cvs and verify that it works for you? as i previously stated, i don't have r00t on a solaris machine, unfortunately :( likewise, to any others who have r00t access on a solaris bug, i'd appreciate hearing back. ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 2005-09-22 15:20 Message: Logged In: YES user_id=1086870 Sean, To answer your previous posts (sorry for the delay - I've been slammed at work,): 1. why isn't pPsInfo->pr_pid included in the output? I designed pst3 to exactly duplicate the output columns produced by the output produced by the original Solaris ps command: /usr/bin/ps -Ao 's uid ppid vsz rss pcpu comm args' You'll notice that Parent-PID is requested (ppid) but not the current process PID (pid). According to the source for check_procs, you can search for children of a parent PID (hence the ppid,) or you can search for a username/uid (hence the uid). But apparetnly, the option is not provided to search for just a PID. 2. You need root access on a Solaris server. I have a Solaris box I can test you config changes on. 3. Can I drop privileges after opening the kernel image? I don't know if it will work. That would depend upon whether the subsequent kvm_* calls also check the effective UID of the caller or not. Do you still want me to try this? Bob ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 07:40 Message: Logged In: YES user_id=226838 slight complication, i'll email the list with details... ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-22 05:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-21 06:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 2005-09-20 03:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-09-19 11:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From bohara at gmail.com Wed Nov 2 01:08:37 2005 From: bohara at gmail.com (Ben O'Hara) Date: Wed Nov 2 01:08:37 2005 Subject: [Nagiosplug-devel] Fwd: check_disk with inode usage? In-Reply-To: <20051102090153.GB21433@seanius.net> References: <2b36e660510310622p6f7fb360s127ed7c2773b159d@mail.gmail.com> <2b36e660510310628k70d777cdg4c6ba6885301cdfe@mail.gmail.com> <2b36e660510310705m58592259o3498028a80bc3233@mail.gmail.com> <20051031172422.GA31050@seanius.net> <2b36e660510311024m390838c1n4bda10788d8a4b71@mail.gmail.com> <20051102090153.GB21433@seanius.net> Message-ID: <2b36e660511020107v308762cqe0e5404afb3923c@mail.gmail.com> On 11/2/05, sean finney wrote: > hi ben, > > On Mon, Oct 31, 2005 at 06:24:13PM +0000, Ben O'Hara wrote: > > Ive attached a copy of the patch, its against the latest snapshot of HEAD. > > > > Ive got it running on Sol7,8,9 and FreeBSD4,5 machines and it appears > > to be reporting back the correct info as far as inode usage is > > concerned, and it doesnt appear to have broken the disk reporting. > > i've committed this to cvs. i see you did some stuff with the perfparse > in the patch too--since i don't use perfparse myself i'll have to take > your word that it doesn't break anything. otherwise, seems to work just fine. > > sean > Cheers Sean, I took the patch that had been previously sent to the list and reapplied it against the latest code. I believe the change to the perdata was to insert the freeinodepct value into the 3rd field which was being set as 0 previously. Regards Ben > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFDaICBynjLPm522B0RAhA3AJ9yjEVGTj+YW+lkv1nLMrmQcP9/+gCfUTa9 > VGfl9IYAvPZ0AZ8jCNpNkSo= > =wGTR > -----END PGP SIGNATURE----- > > > -- "There are 10 types of IT people. Those who understand binary and those who don't." From ae at op5.se Wed Nov 2 01:14:34 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Nov 2 01:14:34 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-995761 ] check_disk to include inode percentage. In-Reply-To: References: Message-ID: <43688359.3000307@op5.se> SourceForge.net wrote: > > I added -W and -K (sorry, -C was taken) -W is protected by posix for "implementation specific purposes". Some implementations make -W fud equal -f -u -d, and some just makes it ignore warnings for unrecognized options. If we're going to use it we should force our own getopt library code to be used, like gcc does. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From rajo at platon.sk Wed Nov 2 01:28:34 2005 From: rajo at platon.sk (Lubomir Host) Date: Wed Nov 2 01:28:34 2005 Subject: [Nagiosplug-devel] PATCH: SMTP auth support in nagios plugin check_smtp.c In-Reply-To: <20051102084657.GA21433@seanius.net> References: <20051031212222.GD32185@platon.sk> <20051101071827.GA6168@seanius.net> <20051101133251.GF32185@platon.sk> <20051102084657.GA21433@seanius.net> Message-ID: <20051102092808.GL32185@platon.sk> On Wed, Nov 02, 2005 at 03:46:57AM -0500, sean finney wrote: > hi lubomir, > > just sitting down with your patch now. is there any reason the block > of login-related code goes before the list queued smtp commands? No, I don't have any special reason. But check also patch from Holger Weiss https://sourceforge.net/mailarchive/forum.php?forum_id=8499&max_rows=25&style=flat&viewmonth=200511&viewday=1 Here is a part "resend the EHLO command - RFC 3207". I don't have this fragment of code in my version, because my version is tested only with postfix, not exim. > anyway, the code is clean and straightforward enough that i'll > go ahead and commit it now. Thanks. I will take a look on commited code. rajo -- Lubomir Host 'rajo' ICQ #: 257322664 ,''`. Platon Software Development Group http://platon.sk/ : :' : Homepage: http://rajo.platon.sk/en/references `. `' http://www.gnu.org/philosophy/no-word-attachments.html `- From noreply at sourceforge.net Wed Nov 2 02:49:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 2 02:49:24 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1314503 ] nagios cant check local sockets Message-ID: Bugs item #1314503, was opened at 2005-10-06 08:33 Message generated for change (Settings changed) made by samm2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1314503&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alex Samorukov (samm2) Assigned to: M. Sean Finney (seanius) Summary: nagios cant check local sockets Initial Comment: Hi. It is not a bug, its a feture request but i sent patch MANY month ago and i still have no any reaction on it :( It is still open. Some users use it (they wrote me mail) but i dont know why it is not included in the sources :( Bug itself is that check_tcp (and it childs) cant check services on local sockets. I am sure that many services which dont need to communicate with external world have only local socket connectors, e.g. clamav antivirus, or local SQL server, etc. The patch (newdiff file) is located on http://sourceforge.net/tracker/index.php?func=detail&aid=1145413&group_id=29880&atid=397599 I used on my servers and it seems to work fine. I hope to see it in later releases or explanation why this cannot be done. With best regards, Alex Samorukov ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-10-29 18:43 Message: Logged In: YES user_id=226838 this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1314503&group_id=29880 From noreply at sourceforge.net Wed Nov 2 02:50:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 2 02:50:47 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1145413 ] This patche allow to use unix sockets in nagios plugins. Message-ID: Patches item #1145413, was opened at 2005-02-21 15:20 Message generated for change (Settings changed) made by samm2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1145413&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Alex Samorukov (samm2) Assigned to: M. Sean Finney (seanius) Summary: This patche allow to use unix sockets in nagios plugins. Initial Comment: With this patch user can specify unix socket as -H argument. This allow to check tcp services which are bind to unix sockets only. I use this for checking clamav-clamd. Alsi, i added check_clamd prototype to check status of the CLAMAV daemon (clamav.net). ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-10-30 12:29 Message: Logged In: YES user_id=226838 fixed in cvs, thanks ---------------------------------------------------------------------- Comment By: Alex Samorukov (samm2) Date: 2005-10-29 21:23 Message: Logged In: YES user_id=891004 I tried latest CVS and found some errors on it. This small error make check_tcp completely unusable (core on startup). Here is a correction: samm>~/src/nagios-plugins/nagiosplug/plugins: cvs diff -u cvs diff: Diffing . Index: check_tcp.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_tcp.c,v retrieving revision 1.70 diff -u -r1.70 check_tcp.c --- check_tcp.c 25 Oct 2005 10:38:02 -0000 1.70 +++ check_tcp.c 29 Oct 2005 18:15:10 -0000 @@ -177,7 +177,7 @@ QUIT = "QUIT\r\n"; PORT = 119; } - else if (strncmp(SERVICE, "CLAMD", 5)) { + else if (!strncmp(SERVICE, "CLAMD", 5)) { SEND = "PING"; EXPECT = "PONG"; QUIT = NULL; @@ -550,7 +550,7 @@ if (server_address == NULL) usage4 (_("You must provide a server address")); - else if (is_host (optarg) == FALSE && optarg[0] != '/') + else if (is_host (server_address) == FALSE && server_address[0] != '/') usage2 (_("Invalid hostname, address, or socket"), optarg); return TRUE; ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2005-06-01 17:29 Message: Logged In: YES user_id=46572 Can you take a shot at reworking the patch based on the current CVS - a bunch of changes went in a couple of weeks ago that breaks this patch. ---------------------------------------------------------------------- Comment By: Alex Samorukov (samm2) Date: 2005-03-11 12:04 Message: Logged In: YES user_id=891004 Hi. Will nagios-plugins use this code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1145413&group_id=29880 From seanius at seanius.net Wed Nov 2 07:35:51 2005 From: seanius at seanius.net (M. Sean Finney) Date: Wed Nov 2 07:35:51 2005 Subject: [Nagiosplug-devel] Re: [Nagiosplug-checkins] nagiosplug/plugins check_disk.c,1.58,1.59 In-Reply-To: References: Message-ID: <20051102153504.GA25858@seanius.net> hi subhendu, (cc'ing to nagiosplug-devel, hope you don't mind) On Wed, Nov 02, 2005 at 08:53:57AM -0500, Subhendu Ghosh wrote: > Hi Sean > > Looking at the patch and the base64 function - There is another one in > check_http.c > > Perhaps it should be moved to lib as a common function. yes, i saw that check_smtp introduced such a function, and had the same thoughts myself. my thought was that when we came across another plugin that needed it it could be moved into utils.{c,h}. apparently i didn't know there was already another plugin doing base64 :) sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From noreply at sourceforge.net Wed Nov 2 08:08:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 2 08:08:24 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1346104 ] check_tcp -s/-q line ends not handled consistently Message-ID: Patches item #1346104, was opened at 2005-11-02 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1346104&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Rouillard (rouilj) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp -s/-q line ends not handled consistently Initial Comment: check_tcp adds a \r\n to the quit string specified by -q but not to the send string specified with -s. This is confusing and also makes it a major pain to test services using check_tcp where the service expects an alternate line ending. This is even more difficult if using something like check_by_ssh to perform the remote check_tcp invocation. The attached patch against the 1.4.2 released check_tcp adds a "-l " flag that allows the line ending to be set to 'b'oth , 'e'mpty, 'n'ewline or 'r'eturn. The default is "-l e" for the -s string and "-l b" for the quit string replicating current behavior. -- rouilj-np at renesys.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1346104&group_id=29880 From ifetch at du.edu Wed Nov 2 12:57:01 2005 From: ifetch at du.edu (Ivan Fetch) Date: Wed Nov 2 12:57:01 2005 Subject: [Nagiosplug-devel] Mailman plugin - some dev questions Message-ID: <20051102135446.W24360@tnetnzry.hgf.qh.rqh> Hello, I've begun work on a Nagios (V1) plugin for mailman and have a couple of things I'd like to get some feedback about. I'm looking at the developer guidelines (http://nagiosplug.sourceforge.net/developer-guidelines.html) and also using some of the existing plugins (1.4.2) to see how others have implemented things thus far. The plugin checks the amount of items in any of nine Mailman queues against warning and critical thresholds. I can (1) try to squeeze output into an eighty character limit (in the worst case of all queues exceeding a threshold the output would have to be a bit cryptic?), or (2) I can expect the plugin to be called nine separate times, potentially providing nine separate notifications given the same scenario. I'm leaning towards allowing the plugin to be called with thresholds for one to nine queues, allowing users to pick their method, but I'm curious- what are others' experiences with this type of situation? I've seen mention of plugins outputting statistics to be stored in RRD, is this something plugins are to do completely on their own, or is there a standard for outputting data in a particular format to a particular place, which Nagios then processes? Thanks to everyone for their feedback, and for the great work on Nagios! - Ivan Fetch. From jhmartin at toger.us Wed Nov 2 19:07:08 2005 From: jhmartin at toger.us (Jason Martin) Date: Wed Nov 2 19:07:08 2005 Subject: [Nagiosplug-devel] Mailman plugin - some dev questions In-Reply-To: <20051102135446.W24360@tnetnzry.hgf.qh.rqh> References: <20051102135446.W24360@tnetnzry.hgf.qh.rqh> Message-ID: <20051103030635.GH5791@mal.members.linode.com> On Wed, Nov 02, 2005 at 01:55:29PM -0700, Ivan Fetch wrote: > allowing the plugin to be called with thresholds for one to nine queues, > allowing users to pick their method, but I'm curious- what are others' > experiences with this type of situation? User choice is ideal. > I've seen mention of plugins outputting statistics to be stored in RRD, The statistics output format is standardized, see the plugin dev docs on that. Some plugins (APAN plugins in particular) take care of the storage in a RRD on their own, but I personally consider this a bad idea. It is better to have that data handled coming out the backend then in between nagios and the plugin. Less moving parts in plugins is idea, especially since the mailman plugin may not be running on the Nagios server. -Jason Martin -- 186,000 miles/sec: Not just a good idea, it's the LAW. This message is PGP/MIME signed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 211 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Wed Nov 2 19:16:16 2005 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed Nov 2 19:16:16 2005 Subject: [Nagiosplug-devel] PATCH: SMTP auth support in nagios plugin check_smtp.c In-Reply-To: <20051102092808.GL32185@platon.sk> References: <20051031212222.GD32185@platon.sk> <20051101071827.GA6168@seanius.net> <20051101133251.GF32185@platon.sk> <20051102084657.GA21433@seanius.net> <20051102092808.GL32185@platon.sk> Message-ID: <20051103031447.GB13445839@CIS.FU-Berlin.DE> * Lubomir Host [2005-11-02 10:28]: > But check also patch from Holger Weiss > https://sourceforge.net/mailarchive/forum.php?forum_id=8499&max_rows=25&style=flat&viewmonth=200511&viewday=1 > Here is a part "resend the EHLO command - RFC 3207". I don't have this > fragment of code in my version, because my version is tested only with > postfix, not exim. Yes, with Exim you'll get an "503 AUTH command used when not advertised" error if trying to use AUTH without (re)sending EHLO _after_ the TLS negotiation (if Exim was configured to allow SMTP AUTH only via TLS). Apart from that, your patch works fine for me. I've attached a patch for the current code, it would be nice if it could be applied. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE -------------- next part -------------- Index: check_smtp.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_smtp.c,v retrieving revision 1.50 diff -u -r1.50 check_smtp.c --- check_smtp.c 2 Nov 2005 08:47:26 -0000 1.50 +++ check_smtp.c 3 Nov 2005 03:13:01 -0000 @@ -270,6 +270,35 @@ } else { ssl_established = 1; } + + /* + * Resend the EHLO command. + * + * RFC 3207 (4.2) says: ``The client MUST discard any knowledge + * obtained from the server, such as the list of SMTP service + * extensions, which was not obtained from the TLS negotiation + * itself. The client SHOULD send an EHLO command as the first + * command after a successful TLS negotiation.'' For this + * reason, some MTAs will not allow an AUTH LOGIN command before + * we resent EHLO via TLS. + */ + if (my_send(helocmd, strlen(helocmd)) <= 0) { + printf(_("UNKNOWN - Cannot send '%s' command via TLS.\n"), helocmd); + np_net_ssl_cleanup(), close(sd); + return STATE_UNKNOWN; + } + if (verbose) + printf(_("sent %s"), helocmd); + if ((n = my_recv(buffer, MAX_INPUT_BUFFER - 1)) <= 0) { + printf(_("UNKNOWN - Cannot read '%s' response via TLS.\n"), helocmd); + np_net_ssl_cleanup(), close(sd); + return STATE_UNKNOWN; + } + if (verbose) { + buffer[n] = '\0'; + printf("%s", buffer); + } + # ifdef USE_OPENSSL if ( check_cert ) { result = np_net_ssl_check_cert(days_till_exp); From holger at CIS.FU-Berlin.DE Wed Nov 2 20:02:39 2005 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed Nov 2 20:02:39 2005 Subject: [Nagiosplug-devel] PATCH: SMTP auth support in nagios plugin check_smtp.c In-Reply-To: <20051103031447.GB13445839@CIS.FU-Berlin.DE> References: <20051031212222.GD32185@platon.sk> <20051101071827.GA6168@seanius.net> <20051101133251.GF32185@platon.sk> <20051102084657.GA21433@seanius.net> <20051102092808.GL32185@platon.sk> <20051103031447.GB13445839@CIS.FU-Berlin.DE> Message-ID: <20051103040146.GC13445839@CIS.FU-Berlin.DE> * Holger Weiss [2005-11-03 04:14]: > I've attached a patch for the current code, it would be nice if it could > be applied. Sorry, minor update -- just realized that using 'helocmd' in the plugin output is ugly because it contains a newline. Holger -- PGP fingerprint: F1F0 9071 8084 A426 DD59 9839 59D3 F3A1 B8B5 D3DE -------------- next part -------------- Index: check_smtp.c =================================================================== RCS file: /cvsroot/nagiosplug/nagiosplug/plugins/check_smtp.c,v retrieving revision 1.50 diff -u -r1.50 check_smtp.c --- check_smtp.c 2 Nov 2005 08:47:26 -0000 1.50 +++ check_smtp.c 3 Nov 2005 03:59:39 -0000 @@ -270,6 +270,35 @@ } else { ssl_established = 1; } + + /* + * Resend the EHLO command. + * + * RFC 3207 (4.2) says: ``The client MUST discard any knowledge + * obtained from the server, such as the list of SMTP service + * extensions, which was not obtained from the TLS negotiation + * itself. The client SHOULD send an EHLO command as the first + * command after a successful TLS negotiation.'' For this + * reason, some MTAs will not allow an AUTH LOGIN command before + * we resent EHLO via TLS. + */ + if (my_send(helocmd, strlen(helocmd)) <= 0) { + printf(_("SMTP UNKNOWN - Cannot send EHLO command via TLS.\n")); + np_net_ssl_cleanup(), close(sd); + return STATE_UNKNOWN; + } + if (verbose) + printf(_("sent %s"), helocmd); + if ((n = my_recv(buffer, MAX_INPUT_BUFFER - 1)) <= 0) { + printf(_("SMTP UNKNOWN - Cannot read EHLO response via TLS.\n")); + np_net_ssl_cleanup(), close(sd); + return STATE_UNKNOWN; + } + if (verbose) { + buffer[n] = '\0'; + printf("%s", buffer); + } + # ifdef USE_OPENSSL if ( check_cert ) { result = np_net_ssl_check_cert(days_till_exp); From f.j.vanheusden at amc.nl Thu Nov 3 03:22:55 2005 From: f.j.vanheusden at amc.nl (Folkert van Heusden) Date: Thu Nov 3 03:22:55 2005 Subject: [Nagiosplug-devel] check_radius not 64bit safe Message-ID: <20051103110444.GN5174@vanheusden.com> Hi, When I compile the nagios plugins set with 64 bit enabled, the check_radius plugin failes: authentications always return "auth failed". Using tcpdump I found the following: 11:27:37.371469 ncs-new.45922 > fido.datametrics: rad-access-req 74 [id 53] Attr[ Service_type{length 8 != 4} User{test-local at amc} Pass NAS_ipaddr{length 8 != 4} ] (DF) 0x0000 4500 0066 0000 4000 4011 d69e 9175 20fb E..f.. at .@....u.. 0x0010 9175 2003 b362 066d 0052 7ad6 0135 004a .u...b.m.Rz..5.J 0x0020 47ef fbf3 5fd5 e621 2c0d 2809 3702 9667 G..._..!,.(.7..g 0x0030 060a 0000 0008 0000 0000 0110 7465 7374 ............test 0x0040 2d6c 6f63 616c 4061 6d63 0212 6728 91a6 -local at amc..g(.. 0x0050 8bfe 32da e9f9 0378 18dd a861 040a 9175 ..2....x...a...u 0x0060 20fb 0000 0000 ...... 11:27:37.376928 fido.datametrics > ncs-new.45922: rad-access-reject 36 [id 53] Attr[ Reply{Request Denied} ] (DF) 0x0000 4500 0040 0032 4000 4011 d692 9175 2003 E.. at .2@. at ....u.. 0x0010 9175 20fb 066d b362 002c ec8a 0335 0024 .u...m.b.,...5.$ 0x0020 ecbd 46cd 14b8 093a 6712 e0b0 ecdf a427 ..F....:g......' 0x0030 1210 5265 7175 6573 7420 4465 6e69 6564 ..Request.Denied as you can see, some fields have invalid lengths (8 -indicating a 64bit int- instead of 4 bytes). Compling the plugin in 32-bit mode (-m32) makes it work correctly. Folkert van Heusden -- Try MultiTail! Multiple windows with logfiles, filtered with regular expressions, colored output, etc. etc. www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Get your PGP/GPG key signed at www.biglumber.com! ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 282 bytes Desc: Digital signature URL: From dmitriy.budashny at gmail.com Thu Nov 3 04:32:45 2005 From: dmitriy.budashny at gmail.com (Dmitriy Budashny) Date: Thu Nov 3 04:32:45 2005 Subject: [Nagiosplug-devel] [check_tcp] -M option problem Message-ID: <891161a10511030431x4770a5fdna0fd5460d0b42154@mail.gmail.com> Please take a look at my patch, i'm not sure if i got all right, but it have fixed probs w/ -M option and now check_tcp understands this option. [(dym at sweeper):~/src]$ diff -Naur ../check_tcp.c nagiosplug/plugins/check_tcp.c --- ../check_tcp.c 2005-11-03 14:25:25.000000000 +0200 +++ nagiosplug/plugins/check_tcp.c 2005-10-31 22:03:19.000000000 +0200 @@ -311,7 +311,7 @@ /* did we get the response we hoped? */ if(match == -2 && result != STATE_CRITICAL) - result = expect_mismatch_state; + result = STATE_WARNING; /* reset the alarm */ alarm (0); -- wbr, dym From rouilj at cs.umb.edu Thu Nov 3 05:15:36 2005 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Thu Nov 3 05:15:36 2005 Subject: [Nagiosplug-devel] looking for script to create client certificates Message-ID: <200511031314.jA3DEIuj015713@mx1.cs.umb.edu> In message <4361E65C.1 at op5.se>, Andreas Ericsson writes: >sean finney wrote: >> does anyone around here have a server that they wouldn't mind me >> testing plugins against while i hack out the code? also, the >> cmdline options required to generate the proper cert via openssl >> would be helpful too (or sending me a copy of a cert that would "just >> work" would be fine too, i guess). >> > >Attached is a script to generate certificates for webservers. You'll >most likely have to tweak some of it a bit to make it sane for smtp >usage, but it should give you a fairly good idea of how to do it. Does anybody know how I can get a copy of this script without having it resent to me as zip or compressed file? Mimedefang removed it at the location where I get my email, and the nagios list archive at sourceforge: https://sourceforge.net/mailarchive/message.php?msg_id=13678206 doesn't seem to keep/allow download of attachments. Any other mirrors of the mailing list that behave differently maybe? -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From ae at op5.se Thu Nov 3 05:24:08 2005 From: ae at op5.se (Andreas Ericsson) Date: Thu Nov 3 05:24:08 2005 Subject: [Nagiosplug-devel] looking for script to create client certificates In-Reply-To: <200511031314.jA3DEIuj015713@mx1.cs.umb.edu> References: <200511031314.jA3DEIuj015713@mx1.cs.umb.edu> Message-ID: <436A0F1B.6030206@op5.se> John P. Rouillard wrote: > In message <4361E65C.1 at op5.se>, > Andreas Ericsson writes: > >>Attached is a script to generate certificates for webservers. You'll >>most likely have to tweak some of it a bit to make it sane for smtp >>usage, but it should give you a fairly good idea of how to do it. > > > Does anybody know how I can get a copy of this script without having > it resent to me as zip or compressed file? http://oss.op5.se/mksslcert.sh.gz -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ton.voon at altinity.com Thu Nov 3 07:15:44 2005 From: ton.voon at altinity.com (Ton Voon) Date: Thu Nov 3 07:15:44 2005 Subject: [Nagiosplug-devel] Working on testcases Message-ID: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> Hi! I've been setting up a tinderbox server and I should be in a position to make it publicly available by end of next week. This means that the testcases are going to get more important, so I'm just fixing some of them at the moment. Question on invalid hostnames: - if a server does not exist, it looks like check_tcp uses usage2 to alert the error. This returns a status of UNKNOWN. The tests currently check for CRITICAL. Which should it be? The plugin documentation says UNKNOWN is: "Invalid command line arguments were supplied to the plugin or the plugin was unable to check the status of the given hosts/service", which does suggest hostname invalid, but then I'm worried that Nagios needs to be specifically configured to alert on unknown states. Any thoughts? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From rick at gribnut.com Thu Nov 3 23:21:31 2005 From: rick at gribnut.com (Rick Frey) Date: Thu Nov 3 23:21:31 2005 Subject: [Nagiosplug-devel] [check_tcp] -M option problem In-Reply-To: <891161a10511030431x4770a5fdna0fd5460d0b42154@mail.gmail.com> References: <891161a10511030431x4770a5fdna0fd5460d0b42154@mail.gmail.com> Message-ID: <436B0BBC.6050900@gribnut.com> I had also used same fix and submitted on project patch tracking system just last week. I'm new to Nagios but didn't see a previous bug/patch listed for the problem. http://sourceforge.net/tracker/index.php?func=detail&aid=1339134&group_id=29880&atid=397599 - Rick Dmitriy Budashny wrote: >Please take a look at my patch, i'm not sure if i got all right, but >it have fixed probs w/ -M option and now check_tcp understands this >option. > >[(dym at sweeper):~/src]$ diff -Naur ../check_tcp.c nagiosplug/plugins/check_tcp.c >--- ../check_tcp.c 2005-11-03 14:25:25.000000000 +0200 >+++ nagiosplug/plugins/check_tcp.c 2005-10-31 22:03:19.000000000 +0200 >@@ -311,7 +311,7 @@ > > /* did we get the response we hoped? */ > if(match == -2 && result != STATE_CRITICAL) >- result = expect_mismatch_state; >+ result = STATE_WARNING; > > /* reset the alarm */ > alarm (0); > >-- >wbr, dym > > >------------------------------------------------------- >SF.Net email is sponsored by: >Tame your development challenges with Apache's Geronimo App Server. Download >it for free - -and be entered to win a 42" plasma tv or your very own >Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >_______________________________________________________ >Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net >Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >::: Please include plugins version (-v) and OS when reporting any issue. >::: Messages without supporting info will risk being sent to /dev/null > > -- Reclaim your Inbox by trying Thunderbird! and while you're at it Get Firefox! From seanius at seanius.net Thu Nov 3 23:40:26 2005 From: seanius at seanius.net (sean finney) Date: Thu Nov 3 23:40:26 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> References: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> Message-ID: <20051104073941.GA15777@seanius.net> hi ton, On Thu, Nov 03, 2005 at 03:14:18PM +0000, Ton Voon wrote: > - if a server does not exist, it looks like check_tcp uses usage2 to > alert the error. This returns a status of UNKNOWN. The tests > currently check for CRITICAL. Which should it be? The plugin > documentation says UNKNOWN is: "Invalid command line arguments were > supplied to the plugin or the plugin was unable to check the status > of the given hosts/service", which does suggest hostname invalid, but > then I'm worried that Nagios needs to be specifically configured to > alert on unknown states. > > Any thoughts? my thought is that for most plugins (except the dns-related ones), UNKNOWN seems a proper state. chances are there's something monitoring DNS that will issue a CRITICAL anyway. however, i don't feel to comitted to this opinion and would be interested to hear the counter-argument. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Fri Nov 4 01:07:27 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 4 01:07:27 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051104073941.GA15777@seanius.net> References: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> <20051104073941.GA15777@seanius.net> Message-ID: <08AB1E2F-6783-47ED-B15C-BDD745DB345B@altinity.com> On 4 Nov 2005, at 07:39, sean finney wrote: > hi ton, > > On Thu, Nov 03, 2005 at 03:14:18PM +0000, Ton Voon wrote: >> - if a server does not exist, it looks like check_tcp uses usage2 to >> alert the error. This returns a status of UNKNOWN. The tests >> currently check for CRITICAL. Which should it be? The plugin >> documentation says UNKNOWN is: "Invalid command line arguments were >> supplied to the plugin or the plugin was unable to check the status >> of the given hosts/service", which does suggest hostname invalid, but >> then I'm worried that Nagios needs to be specifically configured to >> alert on unknown states. >> >> Any thoughts? > > my thought is that for most plugins (except the dns-related ones), > UNKNOWN seems a proper state. chances are there's something > monitoring DNS that will issue a CRITICAL anyway. however, i don't > feel to comitted to this opinion and would be interested to hear > the counter-argument. My "bad" scenario: - Nagios configured to alert on critical/warning - but not unknown - for a check_http on wiki.internal.company.com - Nagios also configured for critical on check_dns to check nameserver, but not specific wiki.internal.company.com record - Someone deletes the DNS entry for wiki.internal.company.com by mistake - Nagios says check_dns is okay (nameserver still running) - check_http on wiki.internal.company.com returns UNKNOWN because cannot resolve hostname - however, no alert. Sys admin gets b0ll0cked for not spotting problem :( Three ways to fix at the configuration level: - check_http against IP address, but then removes point of DNS - alert on unknown, but then what's the point of unknown? - for each hostname used, configure a check_dns for it. But that sounds like a huge (and unobvious) overhead Cons to using CRITICAL: - if DNS goes, all services that rely on hostname lookup via DNS will go CRITICAL and flood alerts (but that, I think, is an obvious reaction) Am I worrying too much? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Nov 4 01:40:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 4 01:40:33 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1339134 ] Fixes --mismatch option for check_tcp Message-ID: Patches item #1339134, was opened at 2005-10-27 04:30 Message generated for change (Settings changed) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1339134&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rick Frey (grater) >Assigned to: Ton Voon (tonvoon) Summary: Fixes --mismatch option for check_tcp Initial Comment: check_tcp correctly parsed options for --mismatch option and set var expect_mismatch_state, but never used var when mismatch was detected (string mismatch always returned STATE_WARNING regardless of mismatch argument). Patch to check_tcp 1.66 (supplied with 1.4.2 plugins): *** check_tcp.c Sun Jun 5 12:43:58 2005 --- check_tcp.c.patch Wed Oct 26 22:20:30 2005 *************** *** 350,356 **** /* did we get the response we hoped? */ if(match == -2 && result != STATE_CRITICAL) ! result = STATE_WARNING; /* reset the alarm */ alarm (0); --- 350,356 ---- /* did we get the response we hoped? */ if(match == -2 && result != STATE_CRITICAL) ! result = expect_mismatch_state; /* reset the alarm */ alarm (0); ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-11-04 09:39 Message: Logged In: YES user_id=664364 Rick, Thanks for the report. Fixed in CVS now. Have added a test into t/ check_imap.t so that this argument will always be checked in the automated tests. Ton ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1339134&group_id=29880 From seanius at seanius.net Fri Nov 4 03:19:38 2005 From: seanius at seanius.net (sean finney) Date: Fri Nov 4 03:19:38 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <08AB1E2F-6783-47ED-B15C-BDD745DB345B@altinity.com> References: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> <20051104073941.GA15777@seanius.net> <08AB1E2F-6783-47ED-B15C-BDD745DB345B@altinity.com> Message-ID: <20051104111856.GA17980@seanius.net> hi ton, you made a good point about dns checks not always being targeted for every hostname (which would be a major pita to maintain). i guess i'm warming up to your suggestion, but i still don't feel a strong conviction either way. one way or the other, though, consistency would be nice. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Fri Nov 4 05:44:38 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 4 05:44:38 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051104111856.GA17980@seanius.net> References: <0D7E95B2-A920-4FB8-B165-9A9AF59EA1A8@altinity.com> <20051104073941.GA15777@seanius.net> <08AB1E2F-6783-47ED-B15C-BDD745DB345B@altinity.com> <20051104111856.GA17980@seanius.net> Message-ID: On 4 Nov 2005, at 11:18, sean finney wrote: > hi ton, > > you made a good point about dns checks not always being targeted for > every hostname (which would be a major pita to maintain). i guess i'm > warming up to your suggestion, but i still don't feel a strong > conviction either way. one way or the other, though, consistency > would be nice. > > sean Thanks for your opinions, Sean. I'm proposing this: - hostname lookups will fail with CRITICAL. I'll make sure the tests reflect and we use a consistent exit function - amend dev guidelines so that UNKNOWN says: "Invalid command line arguments. If the plugin is unable to check status for whatever reason (system call failure, hostname lookup failure, etc), it should return CRITICAL". This narrows down the definition of UNKNOWN to basically "bad command line options". This kinda makes sense if we deprecate a command line option in a new release - we raise an UNKNOWN error, so sys admins will know that they need to investigate a particular plugin. If there are no objections by Monday, I'll crack on with this. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From rouilj at cs.umb.edu Fri Nov 4 10:01:25 2005 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri Nov 4 10:01:25 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: Your message of "Fri, 04 Nov 2005 09:06:34 GMT." <08AB1E2F-6783-47ED-B15C-BDD745DB345B@altinity.com> Message-ID: <200511041759.jA4HxEEb016538@mx1.cs.umb.edu> In message <08AB1E2F-6783-47ED-B15C-BDD745DB345B at altinity.com>, Ton Voon writes: >My "bad" scenario: > > - Nagios configured to alert on critical/warning - but not unknown >- for a check_http on wiki.internal.company.com > - Nagios also configured for critical on check_dns to check >nameserver, but not specific wiki.internal.company.com record > - Someone deletes the DNS entry for wiki.internal.company.com by >mistake > - Nagios says check_dns is okay (nameserver still running) > - check_http on wiki.internal.company.com returns UNKNOWN because >cannot resolve hostname > - however, no alert. Sys admin gets b0ll0cked for not spotting >problem :( > >Three ways to fix at the configuration level: > - check_http against IP address, but then removes point of DNS > - alert on unknown, but then what's the point of unknown? > - for each hostname used, configure a check_dns for it. But that >sounds like a huge (and unobvious) overhead How about a flag to set the exit status in case of a failed lookup? >Am I worrying too much? No, I don't think so. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From ton.voon at altinity.com Fri Nov 4 10:21:37 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 4 10:21:37 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <200511041759.jA4HxEEb016538@mx1.cs.umb.edu> References: <200511041759.jA4HxEEb016538@mx1.cs.umb.edu> Message-ID: <2AF98002-8B3F-41C2-8CA5-23661990F12D@altinity.com> On 4 Nov 2005, at 17:58, John P. Rouillard wrote: > How about a flag to set the exit status in case of a failed lookup? What do you mean? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rouilj at cs.umb.edu Fri Nov 4 10:51:39 2005 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Fri Nov 4 10:51:39 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: Your message of "Fri, 04 Nov 2005 18:20:01 GMT." <2AF98002-8B3F-41C2-8CA5-23661990F12D@altinity.com> Message-ID: <200511041850.jA4IoW47025804@mx1.cs.umb.edu> In message <2AF98002-8B3F-41C2-8CA5-23661990F12D at altinity.com>, Ton Voon writes: > >On 4 Nov 2005, at 17:58, John P. Rouillard wrote: > >> How about a flag to set the exit status in case of a failed lookup? > >What do you mean? --dns-failure-status = CRITICAL --dns-faulre-status = UNKNOWN Then if a dns failure occurs, the user can set what they want the exit status of the command to be. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From noreply at sourceforge.net Fri Nov 4 11:32:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 4 11:32:25 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1292404 ] Can't send newline with check_tcp Message-ID: Bugs item #1292404, was opened at 2005-09-15 18:24 Message generated for change (Comment added) made by rouilj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1292404&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Wiesinger (swiesinger) Assigned to: Nobody/Anonymous (nobody) Summary: Can't send newline with check_tcp Initial Comment: In v1.4.1 check_tcp doesn't send \r\n at the end of the -s string. that breaks many checks. I didn't see a way to send a newline, so I made the following patch which parses \(n,r,t) in the -s string. I don't know if that should be added to the expect string, too, I'm a C novice and didn't find an easy way to add that functionality. Regards, Sebastian ---------------------------------------------------------------------- Comment By: John Rouillard (rouilj) Date: 2005-11-04 14:31 Message: Logged In: YES user_id=707416 See: https://sourceforge.net/tracker/index.php?func=detail&aid=1346104&group_id=29880&atid=397599 for a different patch that addresses the same problem and includes support for the quit string as well. The expect string could probably benefit from your pasing of \(n,r,t) in it provided \ works to embed a \. Hopefully one of our patches will make it into the mainline. -- rouilj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1292404&group_id=29880 From noreply at sourceforge.net Fri Nov 4 11:43:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 4 11:43:25 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1348595 ] check_tcp w/ expect string doesn't work w/ nulls in data Message-ID: Feature Requests item #1348595, was opened at 2005-11-04 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1348595&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: John Rouillard (rouilj) Assigned to: Nobody/Anonymous (nobody) Summary: check_tcp w/ expect string doesn't work w/ nulls in data Initial Comment: I have a tcp service that generates a pattern that I can test for using the -e flag. However the data stream is binary and nulls are embedded in the data stream and prevent strstr() from recognizing the pattern in the stream. E.G. set up a server that spits out \000 h e l l o then use check_tcp -e "hello". One way to do this is to use memchr and the length of the data returned in the my_read call from the tcp socket to implement a null agnostic strstrb() replacement for strstr(). -- rouilj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1348595&group_id=29880 From ton.voon at altinity.com Fri Nov 4 14:22:28 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 4 14:22:28 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <200511041850.jA4IoW47025804@mx1.cs.umb.edu> References: <200511041850.jA4IoW47025804@mx1.cs.umb.edu> Message-ID: <450659ED-076A-4BD7-9E49-7E6E936F4DD7@altinity.com> On 4 Nov 2005, at 18:50, John P. Rouillard wrote: > Ton Voon writes: > >> On 4 Nov 2005, at 17:58, John P. Rouillard wrote: >> >>> How about a flag to set the exit status in case of a failed lookup? >> >> What do you mean? > > --dns-failure-status = CRITICAL > --dns-faulre-status = UNKNOWN > > Then if a dns failure occurs, the user can set what they want the > exit status of the command to be. I see what you mean now. However, using this technique would mean that every plugin using hostname lookups would have to support this flag and I'm not sure that is a good idea. And then what if you get a different kind of failure? A malloc call failure? A system call with unexpected results? A different flag for each? I'm of the Keep It Simple philosophy so I think we need to decide whether "unexpected failures" should be UNKNOWN or CRITICAL. Unfortunately, I think your suggestion will take us to some complicated exceptions handling. Anyway, what's the default setting? :) Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From gh at 3gupload.com Fri Nov 4 14:42:48 2005 From: gh at 3gupload.com (Garrett Honeycutt) Date: Fri Nov 4 14:42:48 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <450659ED-076A-4BD7-9E49-7E6E936F4DD7@altinity.com> References: <200511041850.jA4IoW47025804@mx1.cs.umb.edu> <450659ED-076A-4BD7-9E49-7E6E936F4DD7@altinity.com> Message-ID: <1131144098.18189.186.camel@gspot.internal.3gupload.com> On Fri, 2005-11-04 at 22:20 +0000, Ton Voon wrote: > On 4 Nov 2005, at 18:50, John P. Rouillard wrote: > > > Ton Voon writes: > > > >> On 4 Nov 2005, at 17:58, John P. Rouillard wrote: > >> > >>> How about a flag to set the exit status in case of a failed lookup? > >> > >> What do you mean? > > > > --dns-failure-status = CRITICAL > > --dns-faulre-status = UNKNOWN > > > > Then if a dns failure occurs, the user can set what they want the > > exit status of the command to be. > > I see what you mean now. However, using this technique would mean > that every plugin using hostname lookups would have to support this > flag and I'm not sure that is a good idea. > > And then what if you get a different kind of failure? A malloc call > failure? A system call with unexpected results? A different flag for > each? It could be a compile time option handled by the configure script. This gives those who want to change it the ability. > I'm of the Keep It Simple philosophy so I think we need to decide > whether "unexpected failures" should be UNKNOWN or CRITICAL. > Unfortunately, I think your suggestion will take us to some > complicated exceptions handling. "my thought is that for most plugins (except the dns-related ones), UNKNOWN seems a proper state. chances are there's something monitoring DNS that will issue a CRITICAL anyway. however, i don't feel to comitted to this opinion and would be interested to hear the counter-argument." -sean I would rather get false positives than miss something because the status was UNKNOWN as opposed to CRTICAL. > > Anyway, what's the default setting? :) > > Ton > > > http://www.altinity.com > T: +44 (0)870 787 9243 > F: +44 (0)845 280 1725 > Skype: tonvoon > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null -- // Garrett Honeycutt // 3GUpload.com, Inc. // Sr. Systems Administrator // 317.472.4969 Office From noreply at sourceforge.net Fri Nov 4 17:00:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 4 17:00:27 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-04 16:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Ted Cabeen (secabeen) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From noreply at sourceforge.net Fri Nov 4 18:35:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 4 18:35:14 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1341528 ] configure options to skip program autodetection Message-ID: Feature Requests item #1341528, was opened at 2005-10-29 15:17 Message generated for change (Comment added) made by ahmake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Elan Ruusam?e (ahmake) Assigned to: M. Sean Finney (seanius) Summary: configure options to skip program autodetection Initial Comment: hi this patch adds commandline arguments to specify location of programs to be used, so the programs are not needed to exist at compile time in system, but plugins are usable. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch please be so kind and apply in your cvs. note: the ps program related patch chunk creates .rej with current snapshot (200510290447), but if you apply the rest, i'm happy to make that portion compatible with current cvs code. ---------------------------------------------------------------------- >Comment By: Elan Ruusam?e (ahmake) Date: 2005-11-05 04:34 Message: Logged In: YES user_id=289546 (thank you sourceforge for discarding my first post as i wasn't logged in) sorry for the delay, i've got carried away with work last week i've updated the patch to apply against 200510310547 snapshot. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch?rev=1.6.2.1 regarding the ac_cv_ping_has_timeout=yes, it was already broken by design. ie if --with-ping-command was supplied it was set to no. perhaps add configure options for those two options (see below)? here's the configure.ac snippet: AC_MSG_CHECKING(for ICMP ping syntax) ac_cv_ping_packets_first=no ac_cv_ping_has_timeout=no if test -n "$with_ping_command" then AC_MSG_RESULT([(command-line) $with_ping_command]) if test -n "$ac_cv_ping_packets_first" then ac_cv_ping_packets_first=yes ac_cv_ping_has_timeout=yes fi ---------------------------------------------------------------------- Comment By: Elan Ruusam?e (ahmake) Date: 2005-10-29 17:12 Message: Logged In: YES user_id=289546 ok. i've updated the /proc/loadavg to be also with commandline arg. ac_cv_ping_has_timeout needs more look, i guess it was added because there was no way to do it with commandline. i'll look on this later, perhaps on monday. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-10-29 15:42 Message: Logged In: YES user_id=226838 hi elan, this would be a wonderful feature to have. as i'm also maintaining the debian distribution's package, i'm very much in the same situation as you. the previous maintainer issued build-dependencies on these packages, which was not only an ugly hack but also problematic, as some of the dependencies tried to install daemons on the debian build-hosts :) my current approach was to patch common.h to include a "debian.h" that had everything hardcoded, which isn't the most "graceful" way anyway, if you could supply a version that works against the current configure.in in cvs HEAD, i'd be more than willing to include it. also, could you comment on the first two hunks in the patch? not sure what the first one does and the second looks like it would have problems on non-linux hosts. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 From ae at op5.se Sat Nov 5 06:37:09 2005 From: ae at op5.se (Andreas Ericsson) Date: Sat Nov 5 06:37:09 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <1131144098.18189.186.camel@gspot.internal.3gupload.com> References: <200511041850.jA4IoW47025804@mx1.cs.umb.edu> <450659ED-076A-4BD7-9E49-7E6E936F4DD7@altinity.com> <1131144098.18189.186.camel@gspot.internal.3gupload.com> Message-ID: <436CC378.4030504@op5.se> Garrett Honeycutt wrote: > On Fri, 2005-11-04 at 22:20 +0000, Ton Voon wrote: > >>On 4 Nov 2005, at 18:50, John P. Rouillard wrote: >> >> >>>Ton Voon writes: >>> >>> >>>>On 4 Nov 2005, at 17:58, John P. Rouillard wrote: >>>> >>>> >>>>>How about a flag to set the exit status in case of a failed lookup? >>>> >>>>What do you mean? >>> >>>--dns-failure-status = CRITICAL >>>--dns-faulre-status = UNKNOWN >>> >>>Then if a dns failure occurs, the user can set what they want the >>>exit status of the command to be. >> >>I see what you mean now. However, using this technique would mean >>that every plugin using hostname lookups would have to support this >>flag and I'm not sure that is a good idea. >> >>And then what if you get a different kind of failure? A malloc call >>failure? A system call with unexpected results? A different flag for >>each? > > > It could be a compile time option handled by the configure script. This > gives those who want to change it the ability. > No, no, no, no, no. Compiled binaries are supposed to behave identically on all systems they come across. So what happens if Debian chooses the non-default strategy? List-noise goes up, up, up. > >>I'm of the Keep It Simple philosophy so I think we need to decide >>whether "unexpected failures" should be UNKNOWN or CRITICAL. >>Unfortunately, I think your suggestion will take us to some >>complicated exceptions handling. > > > "my thought is that for most plugins (except the dns-related ones), > UNKNOWN seems a proper state. chances are there's something > monitoring DNS that will issue a CRITICAL anyway. however, i don't > feel to comitted to this opinion and would be interested to hear > the counter-argument." -sean > > I would rather get false positives than miss something because the > status was UNKNOWN as opposed to CRTICAL. > > I've lobbied before to get a "transport/network" error status in Nagios so that UNKNOWN can be used for user-error only. It could certainly be used for this case. OTOH, if a dns lookup fails, the service *is* actually UNKNOWN, since the plugin can't check it. > >>Anyway, what's the default setting? :) >> >>Ton >> >> >>http://www.altinity.com >>T: +44 (0)870 787 9243 >>F: +44 (0)845 280 1725 >>Skype: tonvoon >> >> >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: >>Tame your development challenges with Apache's Geronimo App Server. Download >>it for free - -and be entered to win a 42" plasma tv or your very own >>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >>_______________________________________________________ >>Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net >>Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >>::: Please include plugins version (-v) and OS when reporting any issue. >>::: Messages without supporting info will risk being sent to /dev/null -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From rouilj at cs.umb.edu Sat Nov 5 19:43:34 2005 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Sat Nov 5 19:43:34 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: Your message of "Fri, 04 Nov 2005 22:20:59 GMT." <450659ED-076A-4BD7-9E49-7E6E936F4DD7@altinity.com> Message-ID: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> In message <450659ED-076A-4BD7-9E49-7E6E936F4DD7 at altinity.com>, Ton Voon writes: >On 4 Nov 2005, at 18:50, John P. Rouillard wrote: >> Ton Voon writes: >>> On 4 Nov 2005, at 17:58, John P. Rouillard wrote: >>>> How about a flag to set the exit status in case of a failed lookup? >>> What do you mean? >> --dns-failure-status = CRITICAL >> --dns-faulre-status = UNKNOWN >> Then if a dns failure occurs, the user can set what they want the >> exit status of the command to be. >I see what you mean now. However, using this technique would mean >that every plugin using hostname lookups would have to support this >flag and I'm not sure that is a good idea. Yeah, it does open a Pandora's box. >And then what if you get a different kind of failure? A malloc call >failure? A system call with unexpected results? A different flag for >each? Sadly this problem is caused by the mixing of two different functions in a plugin: communication with a device/service analysis of device/service communication and assignment of severity info into nagios. There is no simple answer. With the SEC plugin I had put into v1 of nagios, I could separate the two functions easily. SEC handled the analysis of the plugin output, and the plugin talked to the device. >I'm of the Keep It Simple philosophy so I think we need to decide >whether "unexpected failures" should be UNKNOWN or CRITICAL. >Unfortunately, I think your suggestion will take us to some >complicated exceptions handling. I agree. >Anyway, what's the default setting? :) I would say critical for DNS failure if DNS responds with a host unknown. If you get a DNS timeout (no valid response), return UNKNOWN. They should be testing DNS for functionality anyway if they are using it. So the DNS failure to respond will be picked up by the DNS check. The failure of DNS to resolve a host then is critical for the reasons outlined (by you IIRC) in this thread. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From ton.voon at altinity.com Mon Nov 7 01:53:38 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Nov 7 01:53:38 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> References: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> Message-ID: <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> Hi! This is an interesting and important thread and I seem to have got some strong opinions, so we should continue with this until we get a result. Just going to summarise where we are: PROBLEM While working on testcases, have noticed that "name resolution failure" now returns UNKNOWN instead of CRITICAL. What exactly should UNKNOWN mean? VIEWS John Rouillard suggested command line option for user to choose return code, but Ton Voon thinks this would overcomplicate. John retracted suggestion. Garrett Honeycutt suggested configure time option for return code, but Andreas Ericsson thinks this is bad because compiled binaries should behave identically across platforms. I think the "configurable return code" suggestion can be dropped. John suggests separating "host not found" and "cannot resolve" exceptions, so the former is a CRITICAL and the latter is an UNKNOWN, which is an interesting idea but I'm not sure what the philosophy of this is. Andreas suggests a new status code in Nagios: "Transport/network error", and then UNKNOWN will mean "user error". With no network error state supported, Andreas suggests using UNKNOWN. John's analysis is that there are two functions of a plugin: 1) communication with device/service 2) analysis of device/service and assigning appropriate status [and perf data] MY TAKE Trying to tie these views together, I think "transport/network" errors goes into (1). John's suggestion about "host not found" and "cannot resolve" go into (1) as well, but then this suggests there is no difference in state. My feeling is that (2) depends on (1), so if (1) is not possible - for ANY reason - then I think that should be a CRITICAL (with appropriate message text). I think Nagios helps with the "transport/ network" error with things like "flapping" and "soft states" (I think Nagios works well because it doesn't try and come up with lots of different plugin states and just keeps it simple). I think Garrett summed it up best for me: "I would rather get false positives than miss something because the status was UNKNOWN as opposed to CRITICAL" NEXT STEPS I think we need to bat this around a bit more to get consensus. If it gets to the stage where we need a vote, I'm happy to cast one out to the community. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ton.voon at altinity.com Mon Nov 7 03:59:10 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Nov 7 03:59:10 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> References: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> Message-ID: On 7 Nov 2005, at 09:52, Ton Voon wrote: > Hi! > > This is an interesting and important thread and I seem to have got > some strong opinions, so we should continue with this until we get > a result. > > Just going to summarise where we are: > > PROBLEM > > While working on testcases, have noticed that "name resolution > failure" now returns UNKNOWN instead of CRITICAL. What exactly > should UNKNOWN mean? > > VIEWS > > John Rouillard suggested command line option for user to choose > return code, but Ton Voon thinks this would overcomplicate. John > retracted suggestion. > > Garrett Honeycutt suggested configure time option for return code, > but Andreas Ericsson thinks this is bad because compiled binaries > should behave identically across platforms. I think the > "configurable return code" suggestion can be dropped. > > John suggests separating "host not found" and "cannot resolve" > exceptions, so the former is a CRITICAL and the latter is an > UNKNOWN, which is an interesting idea but I'm not sure what the > philosophy of this is. > > Andreas suggests a new status code in Nagios: "Transport/network > error", and then UNKNOWN will mean "user error". With no network > error state supported, Andreas suggests using UNKNOWN. > > John's analysis is that there are two functions of a plugin: > > 1) communication with device/service > 2) analysis of device/service and assigning appropriate status > [and perf data] > > MY TAKE > > Trying to tie these views together, I think "transport/network" > errors goes into (1). John's suggestion about "host not found" and > "cannot resolve" go into (1) as well, but then this suggests there > is no difference in state. > > My feeling is that (2) depends on (1), so if (1) is not possible - > for ANY reason - then I think that should be a CRITICAL (with > appropriate message text). I think Nagios helps with the "transport/ > network" error with things like "flapping" and "soft states" (I > think Nagios works well because it doesn't try and come up with > lots of different plugin states and just keeps it simple). > > I think Garrett summed it up best for me: "I would rather get false > positives than miss something because the status was UNKNOWN as > opposed to CRITICAL" > > NEXT STEPS > > I think we need to bat this around a bit more to get consensus. If > it gets to the stage where we need a vote, I'm happy to cast one > out to the community. Sorry to reply to my own post, but after discussing this with a colleague, I've changed my mind. I'm interested to hear what other people think about this suggestion: - Failures to communicate with the device/service is considered to be "UNKNOWN" The idea is that a Nagios administrator would send UNKNOWN alerts to themselves, while service owners (eg, DBAs, web masters, network administrators) would only receive WARNING/CRITICAL alerts. This is driven by the desire to alert to the "right people". Consider this scenario: 0) Nagios administrator receives all UNKNOWN alerts 1) A Nagios administrator sets up a "check oracle for number of users" servicecheck. This alerts to DBAs on WARN/CRIT if above a certain number 2) This plugin fails with some transport error and thus returns UNKNOWN. Notification sent to Nagios admin 3) On investigation, Nagios admin discovers that host has run out of memory. Curses System Administrator. Sets up a new service specifically to check that host has enough memory. Makes this a dependency that check_oracle_users requires check_memory 4) Next time this happens, check_oracle_users returns unknown, check_memory kicks in and returns CRITICAL, so System Administrators are notified and the Nagios admin can continue web surfing I am very interested in "placing the pain" at the right owners. At stage (2), the pain arrives to the Nagios admin because the model for their infrastructure is incomplete. However, the Nagios admin is the right owner because then they can make the changes in step (3). So next time this specific case happens, the pain arrives on the System Administrator instead. If transport errors were set to CRITICAL, then the pain at stage (2) would go to the DBA, who would say "bloody monitoring system". If you like to think graphically, think of the Nagios server at one end with the servicecheck (in a red & yellow spot) at the other end. Everything in between is UNKNOWN. This is the responsibility of the Nagios Administrator. To reduce their responsibility, they need to cover as many points in between as possible, which is basically their job. If everything in between was CRITICAL, then this implies the responsibility belongs to the service owner, but their primary job is to keep the service running, not to cover these other scenarios. So I'm being swayed over to UNKNOWNs for all transport errors. This would mean that something like check_procs would return UNKNOWN if the ps command was not available or returned incorrect data, which fits with this philosophy. Similarly so, hostname lookups would therefore come under UNKNOWN. Extending this philosophy to check_nrpe means that connection problems to the nrpe agent would be considered UNKNOWN (which makes sense because the pain is to the Nagios Administrator) and - since it does not actually check anything itself - should only ever raise an UNKNOWN exception. Make sense? Any other comments? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ae at op5.se Mon Nov 7 04:21:55 2005 From: ae at op5.se (Andreas Ericsson) Date: Mon Nov 7 04:21:55 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: References: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> Message-ID: <436F46A7.30407@op5.se> Ton Voon wrote: > > On 7 Nov 2005, at 09:52, Ton Voon wrote: > >> Hi! >> >> This is an interesting and important thread and I seem to have got >> some strong opinions, so we should continue with this until we get a >> result. >> >> Just going to summarise where we are: >> >> PROBLEM >> >> While working on testcases, have noticed that "name resolution >> failure" now returns UNKNOWN instead of CRITICAL. What exactly should >> UNKNOWN mean? >> >> VIEWS >> >> John Rouillard suggested command line option for user to choose >> return code, but Ton Voon thinks this would overcomplicate. John >> retracted suggestion. >> >> Garrett Honeycutt suggested configure time option for return code, >> but Andreas Ericsson thinks this is bad because compiled binaries >> should behave identically across platforms. I think the "configurable >> return code" suggestion can be dropped. >> >> John suggests separating "host not found" and "cannot resolve" >> exceptions, so the former is a CRITICAL and the latter is an UNKNOWN, >> which is an interesting idea but I'm not sure what the philosophy of >> this is. >> >> Andreas suggests a new status code in Nagios: "Transport/network >> error", and then UNKNOWN will mean "user error". With no network >> error state supported, Andreas suggests using UNKNOWN. >> >> John's analysis is that there are two functions of a plugin: >> >> 1) communication with device/service >> 2) analysis of device/service and assigning appropriate status [and >> perf data] >> >> MY TAKE >> >> Trying to tie these views together, I think "transport/network" >> errors goes into (1). John's suggestion about "host not found" and >> "cannot resolve" go into (1) as well, but then this suggests there is >> no difference in state. >> >> My feeling is that (2) depends on (1), so if (1) is not possible - >> for ANY reason - then I think that should be a CRITICAL (with >> appropriate message text). I think Nagios helps with the "transport/ >> network" error with things like "flapping" and "soft states" (I think >> Nagios works well because it doesn't try and come up with lots of >> different plugin states and just keeps it simple). >> >> I think Garrett summed it up best for me: "I would rather get false >> positives than miss something because the status was UNKNOWN as >> opposed to CRITICAL" >> >> NEXT STEPS >> >> I think we need to bat this around a bit more to get consensus. If it >> gets to the stage where we need a vote, I'm happy to cast one out to >> the community. > > > Sorry to reply to my own post, but after discussing this with a > colleague, I've changed my mind. I'm interested to hear what other > people think about this suggestion: > > - Failures to communicate with the device/service is considered to be > "UNKNOWN" > > The idea is that a Nagios administrator would send UNKNOWN alerts to > themselves, while service owners (eg, DBAs, web masters, network > administrators) would only receive WARNING/CRITICAL alerts. This is > driven by the desire to alert to the "right people". > > Consider this scenario: > > 0) Nagios administrator receives all UNKNOWN alerts > 1) A Nagios administrator sets up a "check oracle for number of > users" servicecheck. This alerts to DBAs on WARN/CRIT if above a > certain number > 2) This plugin fails with some transport error and thus returns > UNKNOWN. Notification sent to Nagios admin > 3) On investigation, Nagios admin discovers that host has run out of > memory. Curses System Administrator. Sets up a new service specifically > to check that host has enough memory. Makes this a dependency that > check_oracle_users requires check_memory > 4) Next time this happens, check_oracle_users returns unknown, > check_memory kicks in and returns CRITICAL, so System Administrators > are notified and the Nagios admin can continue web surfing > > I am very interested in "placing the pain" at the right owners. At > stage (2), the pain arrives to the Nagios admin because the model for > their infrastructure is incomplete. However, the Nagios admin is the > right owner because then they can make the changes in step (3). So > next time this specific case happens, the pain arrives on the System > Administrator instead. > > If transport errors were set to CRITICAL, then the pain at stage (2) > would go to the DBA, who would say "bloody monitoring system". > > If you like to think graphically, think of the Nagios server at one end > with the servicecheck (in a red & yellow spot) at the other end. > Everything in between is UNKNOWN. This is the responsibility of the > Nagios Administrator. To reduce their responsibility, they need to > cover as many points in between as possible, which is basically their > job. If everything in between was CRITICAL, then this implies the > responsibility belongs to the service owner, but their primary job is > to keep the service running, not to cover these other scenarios. > > So I'm being swayed over to UNKNOWNs for all transport errors. This > would mean that something like check_procs would return UNKNOWN if the > ps command was not available or returned incorrect data, which fits > with this philosophy. Similarly so, hostname lookups would therefore > come under UNKNOWN. > > Extending this philosophy to check_nrpe means that connection problems > to the nrpe agent would be considered UNKNOWN (which makes sense > because the pain is to the Nagios Administrator) and - since it does > not actually check anything itself - should only ever raise an UNKNOWN > exception. > > Make sense? Any other comments? > I'd just like to point out that this is in no way incompatible with the "transport error" service-status, since nagios by default sets all out-of-bounds return codes to UNKNOWN. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Mon Nov 7 04:50:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 7 04:50:13 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1341528 ] configure options to skip program autodetection Message-ID: Feature Requests item #1341528, was opened at 2005-10-29 08:17 Message generated for change (Settings changed) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Priority: 5 Submitted By: Elan Ruusam?e (ahmake) Assigned to: M. Sean Finney (seanius) Summary: configure options to skip program autodetection Initial Comment: hi this patch adds commandline arguments to specify location of programs to be used, so the programs are not needed to exist at compile time in system, but plugins are usable. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch please be so kind and apply in your cvs. note: the ps program related patch chunk creates .rej with current snapshot (200510290447), but if you apply the rest, i'm happy to make that portion compatible with current cvs code. ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-11-07 07:50 Message: Logged In: YES user_id=226838 hi elan, i've merged your patch into the latest cvs, thanks! i've made the following modifications: - all the AC_ARG_WITH statements were modified to use ACX_HELP_STRING in their descriptions - a couple other random cosmetic changes (PATH instead of , etc) - changed "with-cols" to "with-ps-cols" at some later time, i may take another pass over the entire configure.in script to try and clean up and consolidate the detection code, but what you've provided seems to work from my initial testing, so... it's in. thanks again, sean ---------------------------------------------------------------------- Comment By: Elan Ruusam?e (ahmake) Date: 2005-11-04 21:34 Message: Logged In: YES user_id=289546 (thank you sourceforge for discarding my first post as i wasn't logged in) sorry for the delay, i've got carried away with work last week i've updated the patch to apply against 200510310547 snapshot. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch?rev=1.6.2.1 regarding the ac_cv_ping_has_timeout=yes, it was already broken by design. ie if --with-ping-command was supplied it was set to no. perhaps add configure options for those two options (see below)? here's the configure.ac snippet: AC_MSG_CHECKING(for ICMP ping syntax) ac_cv_ping_packets_first=no ac_cv_ping_has_timeout=no if test -n "$with_ping_command" then AC_MSG_RESULT([(command-line) $with_ping_command]) if test -n "$ac_cv_ping_packets_first" then ac_cv_ping_packets_first=yes ac_cv_ping_has_timeout=yes fi ---------------------------------------------------------------------- Comment By: Elan Ruusam?e (ahmake) Date: 2005-10-29 10:12 Message: Logged In: YES user_id=289546 ok. i've updated the /proc/loadavg to be also with commandline arg. ac_cv_ping_has_timeout needs more look, i guess it was added because there was no way to do it with commandline. i'll look on this later, perhaps on monday. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-10-29 08:42 Message: Logged In: YES user_id=226838 hi elan, this would be a wonderful feature to have. as i'm also maintaining the debian distribution's package, i'm very much in the same situation as you. the previous maintainer issued build-dependencies on these packages, which was not only an ugly hack but also problematic, as some of the dependencies tried to install daemons on the debian build-hosts :) my current approach was to patch common.h to include a "debian.h" that had everything hardcoded, which isn't the most "graceful" way anyway, if you could supply a version that works against the current configure.in in cvs HEAD, i'd be more than willing to include it. also, could you comment on the first two hunks in the patch? not sure what the first one does and the second looks like it would have problems on non-linux hosts. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 From noreply at sourceforge.net Mon Nov 7 04:52:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 7 04:52:21 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1350249 ] check_disk -p ignores third and following argument of -p Message-ID: Bugs item #1350249, was opened at 2005-11-07 13:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1350249&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Maik (aussendorf) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk -p ignores third and following argument of -p Initial Comment: Using version 1.4.2 (tar download from 11/07/05 If I call check_disk with the -p option, it will check the first two named pathes only. It will ignore any following path. e.g. check_disk -w 100 -c 30 -p /p1 / p2 /p3 will only check /p1 and /p2, while /p3 is ignored. With kind regards Maik Aussendorf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1350249&group_id=29880 From noreply at sourceforge.net Mon Nov 7 04:56:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 7 04:56:26 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-04 19:59 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Ted Cabeen (secabeen) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-11-07 07:56 Message: Logged In: YES user_id=226838 hi, um, i just have to ask. how do you have negative free space? some other information that would be helpful: - is check_disk using the df command or internal disk space routines? - if df, what df command syntax is check_disk using? - what version of the plugins are you using? i believe that the plugin is making an assumption that the amount of disk space available is unsigned, because, er... well i'd never heard of negative disk space, anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From noreply at sourceforge.net Mon Nov 7 13:26:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 7 13:26:35 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-04 16:59 Message generated for change (Comment added) made by secabeen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Ted Cabeen (secabeen) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- >Comment By: Ted Cabeen (secabeen) Date: 2005-11-07 13:25 Message: Logged In: YES user_id=40466 All modern unix file-systems reserve a portion (5-10%) of the disk space for use by root only and to speed disk accesses. If the root user exceeds the normal disk space and uses some of the reserve space, the system will represent the amount of free space as negative. I don't know how check_disk is checking the disk space (df or internal routines). Is there an easy way to check? check_disk (nagios-plugins 1.4.2) 1.57 is the version I'm running. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-07 04:56 Message: Logged In: YES user_id=226838 hi, um, i just have to ask. how do you have negative free space? some other information that would be helpful: - is check_disk using the df command or internal disk space routines? - if df, what df command syntax is check_disk using? - what version of the plugins are you using? i believe that the plugin is making an assumption that the amount of disk space available is unsigned, because, er... well i'd never heard of negative disk space, anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From ifetch at du.edu Mon Nov 7 13:33:29 2005 From: ifetch at du.edu (Ivan Fetch) Date: Mon Nov 7 13:33:29 2005 Subject: [Nagiosplug-devel] Plugins and embedded Perl Message-ID: <20051107140936.U7442@tnetnzry.hgf.qh.rqh> Hello, Thank you again to folks who've responded about my earlier queries RE: developing a Mailman plugin in PERL. I've got a few questions about the embedded PERL section of the development guidelines: 1. Do not use BEGIN and END blocks since they will be called only once (when Nagios starts and shuts down) with Embedded Perl (ePN). In particular, do not use BEGIN blocks to initialize variables. -- I've been using an END sub to return exit value 3 when we exit unexpectedly, such as when someone uses an incorrect option. This could be avoided if there were a GetOpt function for this - I have read the docs for Getopt::Long multiple times but don't see anything. Am I missing it or does it not exist? Something like a what-to-call-when-Getopt-is-mad sub. 2. To use utils.pm, you need to provide a full path to the module in order for it to work. -- If I have: use lib utils.pm; in the script, then add lines to configure.in so that it substitutes utils.pm with the proper lib path, is that sufficient to properly integrate my plugin? 4. ..... Explicitly initialize each variable in use. Otherwise with caching enabled, the plugin will not be recompiled each time, and therefore Perl will not reinitialize all the variables. All old variable values will still be in effect. -- Don't variables declared with my, within a sub, go away when that sub exits? SO the above really only applies to "global variables?" Thanks all for your help -- Ivan Fetch. From David.Andrew at development.tas.gov.au Mon Nov 7 15:08:35 2005 From: David.Andrew at development.tas.gov.au (David.Andrew at development.tas.gov.au) Date: Mon Nov 7 15:08:35 2005 Subject: [Nagiosplug-devel] David Andrew is out of the office. Message-ID: I will be out of the office starting 07/11/2005 and will not return until 22/11/2005. Please direct all inquiries to helpdesk at development.tas.gov.au or call (03) 6233 5825 From noreply at sourceforge.net Tue Nov 8 03:29:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 8 03:29:44 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-04 19:59 Message generated for change (Comment added) made by seanius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Ted Cabeen (secabeen) >Assigned to: M. Sean Finney (seanius) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- >Comment By: M. Sean Finney (seanius) Date: 2005-11-08 06:28 Message: Logged In: YES user_id=226838 hi, well chalk this up to my having been away from traditional unix/bsd implementations. afaict in linux such reserved space is still taken into calculation of total available space (ie, you could get ENOSPC before the disk reached 0%). but anyway, i think the fix is still obvious, that we should do all scans and assignments as signed integers instead of unsigned. if i don't hear any complaints from anyone else on the plugins team, i'll probably do this at some point (and hope that it doesn't break something else) also, having taken a look at the check_disk code, i can't seem to find any references to the df program... so i guess if you're using 1.4.2 or later that it's purely within the internal disk space routines. ---------------------------------------------------------------------- Comment By: Ted Cabeen (secabeen) Date: 2005-11-07 16:25 Message: Logged In: YES user_id=40466 All modern unix file-systems reserve a portion (5-10%) of the disk space for use by root only and to speed disk accesses. If the root user exceeds the normal disk space and uses some of the reserve space, the system will represent the amount of free space as negative. I don't know how check_disk is checking the disk space (df or internal routines). Is there an easy way to check? check_disk (nagios-plugins 1.4.2) 1.57 is the version I'm running. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-07 07:56 Message: Logged In: YES user_id=226838 hi, um, i just have to ask. how do you have negative free space? some other information that would be helpful: - is check_disk using the df command or internal disk space routines? - if df, what df command syntax is check_disk using? - what version of the plugins are you using? i believe that the plugin is making an assumption that the amount of disk space available is unsigned, because, er... well i'd never heard of negative disk space, anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From noreply at sourceforge.net Tue Nov 8 04:06:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 8 04:06:30 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1348746 ] check_disk reports incorrect disk free with neg space on BSD Message-ID: Bugs item #1348746, was opened at 2005-11-05 00:59 Message generated for change (Comment added) made by tonvoon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Ted Cabeen (secabeen) Assigned to: M. Sean Finney (seanius) Summary: check_disk reports incorrect disk free with neg space on BSD Initial Comment: With check_disk running on FreeBSD 5-STABLE, when a disk has negative free space remaining, the amount of free space goes hugely positive: DISK CRITICAL - free space: /usr 36028797018963968 MB (1191472380510208%): Here's a df from the time: /dev/ad4s1g 3096462 2989082 -140336 105% /usr ---------------------------------------------------------------------- >Comment By: Ton Voon (tonvoon) Date: 2005-11-08 12:05 Message: Logged In: YES user_id=664364 >From 1.4 onwards, we use the GNU coreutils library to get df data. I don't know if FreeBSD use their own routines or not, but GNU coreutils should support it. Yes, I guess signed integers should fix. Was an assumption on our part that values would be always positive. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-08 11:28 Message: Logged In: YES user_id=226838 hi, well chalk this up to my having been away from traditional unix/bsd implementations. afaict in linux such reserved space is still taken into calculation of total available space (ie, you could get ENOSPC before the disk reached 0%). but anyway, i think the fix is still obvious, that we should do all scans and assignments as signed integers instead of unsigned. if i don't hear any complaints from anyone else on the plugins team, i'll probably do this at some point (and hope that it doesn't break something else) also, having taken a look at the check_disk code, i can't seem to find any references to the df program... so i guess if you're using 1.4.2 or later that it's purely within the internal disk space routines. ---------------------------------------------------------------------- Comment By: Ted Cabeen (secabeen) Date: 2005-11-07 21:25 Message: Logged In: YES user_id=40466 All modern unix file-systems reserve a portion (5-10%) of the disk space for use by root only and to speed disk accesses. If the root user exceeds the normal disk space and uses some of the reserve space, the system will represent the amount of free space as negative. I don't know how check_disk is checking the disk space (df or internal routines). Is there an easy way to check? check_disk (nagios-plugins 1.4.2) 1.57 is the version I'm running. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 2005-11-07 12:56 Message: Logged In: YES user_id=226838 hi, um, i just have to ask. how do you have negative free space? some other information that would be helpful: - is check_disk using the df command or internal disk space routines? - if df, what df command syntax is check_disk using? - what version of the plugins are you using? i believe that the plugin is making an assumption that the amount of disk space available is unsigned, because, er... well i'd never heard of negative disk space, anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1348746&group_id=29880 From srunschke at abit.de Wed Nov 9 00:33:32 2005 From: srunschke at abit.de (srunschke at abit.de) Date: Wed Nov 9 00:33:32 2005 Subject: [Nagiosplug-devel] dig/nslookup wait() problems - RedHat support responses # Part 3 - FIXED and SOLVED In-Reply-To: Message-ID: Greetings again, My workout with RedHat finally succeeded and they were able to pinpoint the bug and fixed it! I haven't read the changelogs yet - so I can't say for sure what the reason was. The hotfixed kernel is currently still under internal testing of redhat, but if you have an active subscription to RHN you can request that version via support. The kernel to request is: hotfix-kernel-2.6.9-22.12.EL I am not sure if there is a hotfixed version for FC available. I expect the kernel to become publicly available within the next 2-4 weeks most likely as redhat does not really consider it a harmful issue. regards Sascha PS: Please do not request to give you a download link for the kernel or to have me upload it somewhere - I won't do so. I received this internal testing kernel solely because we are paying for their support. -------------------------------------------------- Sascha Runschke Netzwerk Administration IT-Services ABIT AG Robert-Bosch-Str. 1 40668 Meerbusch Tel.:+49 (0) 2150.9153.226 Mobil:+49 (0) 173.5419665 mailto:SRunschke at abit.de http://www.abit.net http://www.abit-epos.net --------------------------------- Sicherheitshinweis zur E-Mail Kommunikation / Security note regarding email communication: http://www.abit.net/sicherheitshinweis.html From ton.voon at altinity.com Wed Nov 9 00:39:30 2005 From: ton.voon at altinity.com (Ton Voon) Date: Wed Nov 9 00:39:30 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <436F46A7.30407@op5.se> References: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> <436F46A7.30407@op5.se> Message-ID: On 7 Nov 2005, at 12:20, Andreas Ericsson wrote: > I'd just like to point out that this is in no way incompatible with > the "transport error" service-status, since nagios by default sets > all out-of-bounds return codes to UNKNOWN. > Andreas, Just trying to make your suggestion clear: are you proposing "transport error" as another status from the plugins, but one that Nagios will (currently) support because it will map it onto UNKNOWN? I'm against adding another state unless absolutely necessary. I don't think there is sufficient difference between UNKNOWN and TRANSPORT_ERROR. And while I agree with the idea of "transport errors", I'm not sure if we agree on the concept. In your previous email, you said "UNKNOWN can be used for user-error only", but then you contradicted yourself by saying when "a dns fails, the service *is* UNKNOWN". I wonder if the word "UNKNOWN" is causing problems. Maybe "OTHER" makes more sense meaning "any other failure to stop analysis of the service". Any other opinions? This feels like it could be a big change that could impact how Nagios works so I want to make sure this is the right route to go. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From ae at op5.se Wed Nov 9 04:20:14 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Nov 9 04:20:14 2005 Subject: [Nagiosplug-devel] dig/nslookup wait() problems - RedHat support responses # Part 3 - FIXED and SOLVED In-Reply-To: References: Message-ID: <4371E90C.50401@op5.se> srunschke at abit.de wrote: > The hotfixed kernel is currently still under internal testing of redhat, > but > if you have an active subscription to RHN you can request that version > via support. The kernel to request is: hotfix-kernel-2.6.9-22.12.EL > I am not sure if there is a hotfixed version for FC available. > FC (3, at least) doesn't need one. It uses 2.6.12 for base and this problem isn't in there. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Wed Nov 9 04:28:45 2005 From: ae at op5.se (Andreas Ericsson) Date: Wed Nov 9 04:28:45 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: References: <200511060342.jA63gvw5015879@mx1.cs.umb.edu> <19585243-C6AD-42E9-A683-A7F532945D31@altinity.com> <436F46A7.30407@op5.se> Message-ID: <4371EB14.3060806@op5.se> Ton Voon wrote: > > On 7 Nov 2005, at 12:20, Andreas Ericsson wrote: > >> I'd just like to point out that this is in no way incompatible with >> the "transport error" service-status, since nagios by default sets >> all out-of-bounds return codes to UNKNOWN. >> > > Andreas, > > Just trying to make your suggestion clear: are you proposing "transport > error" as another status from the plugins, but one that Nagios will > (currently) support because it will map it onto UNKNOWN? > Yes. > I'm against adding another state unless absolutely necessary. I don't > think there is sufficient difference between UNKNOWN and TRANSPORT_ERROR. > > And while I agree with the idea of "transport errors", I'm not sure if > we agree on the concept. In your previous email, you said "UNKNOWN can > be used for user-error only", but then you contradicted yourself by > saying when "a dns fails, the service *is* UNKNOWN". > What I meant was that the service isn't in a determined state (i.e. "unknown" as humans read the word which isn't necessarily how Nagios understands it). > I wonder if the word "UNKNOWN" is causing problems. Maybe "OTHER" makes > more sense meaning "any other failure to stop analysis of the service". > Apparently it does. I don't think a change would be very welcome though. > Any other opinions? This feels like it could be a big change that could > impact how Nagios works so I want to make sure this is the right route > to go. > It needs lots and lots of testing. It would probably be better if Nagios did something along the lines of service_status = return_code & 0x3; plugin_flags = return_code & ~0x3; This would mean that plugins would still only have 4 valid exit-codes, but could choose to pass on additional information to Nagios which would help users determine what went wrong (if the GUI supports it, ofcourse). I'm not sure if this would break anything for now though, but if it does it'll have to wait until there's a new major release (i.e. 3.0). I don't think it's worth fiddling with right now. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nagios at nagios.org Wed Nov 9 11:12:11 2005 From: nagios at nagios.org (Ethan Galstad) Date: Wed Nov 9 11:12:11 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <4371EB14.3060806@op5.se> References: Message-ID: <4371F588.20966.D7F0C3@nagios.nagios.org> I'm a bit late into this thread, but here are some of my thoughts... At least one person should be getting notifications for UNKNOWN states, as they can be important. The UNKNOWN state doesn't really have a clear definition, but here's what I think it should be used to signify... 1. Invalid command line args passed to the plugin (e.g. the plugin doesn't know what to do). 2. Internal failures in the plugin itself which prevent it from performing a check (i.e. malloc() failures, unexpected system call failures, or anything else that needs to be done - but fails - before a check can be performed). As an example, the check_dhcp plugin returns an UNKNOWN state if it can't determine the local hardware address or bind to port 68. 3. Nagios will also assign an UNKNOWN state to any plugin/script/whatever that either doesn't exist on the filesystem or returns a code that is out-of-bounds in accordance with the plugin specs. I think that DNS errors and the like should either result in a WARNING or (preferably) a CRITICAL state. By specifying a host/DNS name in the config, the admin has implicity indicated to Nagios/the plugins that the name should resolve. If for whatever reason it doesn't, it should be treated as a serious error and the admin should be notified appropriately. I don't think there's a real need to add another state type to Nagios for indicating transport or resolution errors. The existing states should provide enough to indicate various problems, althought I'm sure there are different opinions on this. :-) On 9 Nov 2005 at 13:27, Andreas Ericsson wrote: > Ton Voon wrote: > > > > On 7 Nov 2005, at 12:20, Andreas Ericsson wrote: > > > >> I'd just like to point out that this is in no way incompatible with > >> the "transport error" service-status, since nagios by default sets > >> all out-of-bounds return codes to UNKNOWN. > >> > > > > Andreas, > > > > Just trying to make your suggestion clear: are you proposing "transport > > error" as another status from the plugins, but one that Nagios will > > (currently) support because it will map it onto UNKNOWN? > > > > Yes. > > > I'm against adding another state unless absolutely necessary. I don't > > think there is sufficient difference between UNKNOWN and TRANSPORT_ERROR. > > > > And while I agree with the idea of "transport errors", I'm not sure if > > we agree on the concept. In your previous email, you said "UNKNOWN can > > be used for user-error only", but then you contradicted yourself by > > saying when "a dns fails, the service *is* UNKNOWN". > > > > What I meant was that the service isn't in a determined state (i.e. > "unknown" as humans read the word which isn't necessarily how Nagios > understands it). > > > I wonder if the word "UNKNOWN" is causing problems. Maybe "OTHER" makes > > more sense meaning "any other failure to stop analysis of the service". > > > > Apparently it does. I don't think a change would be very welcome though. > > > Any other opinions? This feels like it could be a big change that could > > impact how Nagios works so I want to make sure this is the right route > > to go. > > > > It needs lots and lots of testing. It would probably be better if Nagios > did something along the lines of > > service_status = return_code & 0x3; > plugin_flags = return_code & ~0x3; > > This would mean that plugins would still only have 4 valid exit-codes, > but could choose to pass on additional information to Nagios which would > help users determine what went wrong (if the GUI supports it, ofcourse). > > I'm not sure if this would break anything for now though, but if it does > it'll have to wait until there's a new major release (i.e. 3.0). I don't > think it's worth fiddling with right now. > > -- > Andreas Ericsson andreas.ericsson at op5.se > OP5 AB www.op5.se > Tel: +46 8-230225 Fax: +46 8-230231 > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any issue. > ::: Messages without supporting info will risk being sent to /dev/null > > Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From ton.voon at altinity.com Thu Nov 10 16:51:55 2005 From: ton.voon at altinity.com (Ton Voon) Date: Thu Nov 10 16:51:55 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <4371F588.20966.D7F0C3@nagios.nagios.org> References: <4371F588.20966.D7F0C3@nagios.nagios.org> Message-ID: <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> On 9 Nov 2005, at 19:11, Ethan Galstad wrote: > I'm a bit late into this thread, but here are some of my thoughts... > > At least one person should be getting notifications for UNKNOWN > states, as they can be important. The UNKNOWN state doesn't really > have a clear definition, but here's what I think it should be used to > signify... > > 1. Invalid command line args passed to the plugin (e.g. the plugin > doesn't know what to do). > > 2. Internal failures in the plugin itself which prevent it from > performing a check (i.e. malloc() failures, unexpected system call > failures, or anything else that needs to be done - but fails - before > a check can be performed). As an example, the check_dhcp plugin > returns an UNKNOWN state if it can't determine the local hardware > address or bind to port 68. > > 3. Nagios will also assign an UNKNOWN state to any > plugin/script/whatever that either doesn't exist on the filesystem or > returns a code that is out-of-bounds in accordance with the plugin > specs. So the guidelines should be updated with: "UNKNOWN is for invalid command args or any other failure before the requested check can be performed - with the only exception being hostname lookups which should return CRITICAL." Some example changes based on the advice above: (1) check_http -H webserver This returns OK if it can connect to the webserver and returns data. (2) check_http -H webserver -w 2 This returns OK if can connect to webserver and returns data within 2 seconds. If it cannot connect, then this returns UNKNOWN because it is not the metric that is being requested to check against (currently returns CRITICAL). (3) check_http -H webserver -r 'string_to_find' This returns OK if it can find the server and return data with the string. If it cannot connect to the server (currently CRITICAL), or gets a 302 redirection (currently OK (?) ), this should be an UNKNOWN. (4) check_http -H webserver --pagesize=1000 Returns OK if it can find server and the web page size is >= 1000 bytes. If it cannot connect to server (currently CRITICAL) or get a 302 redirection (currently OK), this should return UNKNOWN. (5) check_http -H webserver --pagesize=1000 -w 2 Returns OK if it can find server, the web page size is >= 1000 bytes and time taken is <= 2. If it cannot connect to server (currently CRITICAL) or get a 302 redirection (currently OK), this should return UNKNOWN. Is this right? I'm starting to think so. It is clear to me now what state should be returned given what is actually being asked to check. In fact, a side effect is it clearly defines what perf data should be returned: (2) should return time taken, (4) should return page size, (5) should return both, whereas (1) and (3) shouldn't return anything. (There's an issue re: inconsistent arguments. I think probably it should be something like: check_http -H webserver --metric pagesize -w 1000 --metric time -w 2 But that's another story.) Back to UNKNOWN - should we do it? (However, it still doesn't make sense to treat hostname lookups differently, but if that's the consensus, I'll go with it.) Ton (So much work, so little time ....) http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From skiymaz at netpia.com Fri Nov 11 00:23:12 2005 From: skiymaz at netpia.com (Serhan D. KIYMAZ) Date: Fri Nov 11 00:23:12 2005 Subject: [Nagiosplug-devel] Notify via SMS script Message-ID: <43733879.8060001@netpia.com> Hi, I have developed a plugin which sends nofication mails via SMS to a GSM phone. We're using it in our company Netpia. We're using it with Clickatell SMS Gateway. I hope this plugin will help someone. You can find it in the attachment. BTW, I would be happy if there's any tasks that I can help you. Thanks very much for your great work. Regards -- *Art?k Tan?nmak Daha Kolay, Hem de T?rk?e'mizle..* *Serhan D. KIYMAZ* Netpia ?nternet Hizmetleri Pazarlama A.?. Teknoloji www.netpia.com.tr www.serotizm.com +90 212 346 0814 +90 212 346 0816 +90 543 726 6682 ------------------------------------------------------------------------ Bu elektronik posta mesaj? ve ekleri sadece g?nderildi?i ki?i veya kuruma ?zeldir ve gizli bilgiler i?erebilir. Eger bu mesaj? hataen ald?ysan?z lutfen bu durumu gonderen ki?iye derhal bildiriniz ve mesaj? sisteminizden siliniz. E?er do?ru ki?iye ula?mad???n? d???n?yorsan?z, bu mesaj?n gizlenmesi, y?nlendirilmesi, kopyalanmas? veya herhangi bir ?ekilde kullan?lmas? yasakt?r. Mesaj i?eri?inde bulunan fikir ve yorumlar, Netpia ?nternet Hizmetleri Pazarlama A.?.'ne de?il sadece g?ndericiye aittir. Internet ileti?iminde g?venlik ve hatas?z g?nderim garanti edilemeyece?inden, mesaj?n yerine ula?mamas?, ge? ula?mas?, i?eri?inin bozulmas? ya da mesaj?n virus ta??mas? gibi problemler olu?abilir. G?nderen taraf bu tip sorunlardan sorumlu tutulmaz. This e-mail message and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately and delete it from your system. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited.The opinions expressed in this message belong to sender alone. There is no implied endorsement by Netpia ?nternet Hizmetleri Pazarlama A.?.. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission. -------------- next part -------------- A non-text attachment was scrubbed... Name: notify_sms.tar.gz Type: application/x-gzip Size: 1488 bytes Desc: not available URL: From ton.voon at altinity.com Fri Nov 11 02:04:57 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 11 02:04:57 2005 Subject: [Nagiosplug-devel] Notify via SMS script In-Reply-To: <43733879.8060001@netpia.com> References: <43733879.8060001@netpia.com> Message-ID: On 10 Nov 2005, at 12:09, Serhan D. KIYMAZ wrote: > Hi, > > I have developed a plugin which sends nofication mails via SMS to a > GSM phone. > We're using it in our company Netpia. We're using it with > Clickatell SMS Gateway. > I hope this plugin will help someone. You can find it in the > attachment. Serhan, Thanks very much for this. Unfortunately, we are not accepting new plugins into the core distribution at the moment. Please consider registering your plugin at http://www.nagiosexchange.org as this is the official 3rd party plugin repository. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Sat Nov 12 08:51:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 12 08:51:26 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1355304 ] contrib/check_email_loop.pl - Perl warnings & ePN failures Message-ID: Bugs item #1355304, was opened at 2005-11-12 11:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1355304&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Embedded Perl failure Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Robert Gash (gashalot) Assigned to: Nobody/Anonymous (nobody) Summary: contrib/check_email_loop.pl - Perl warnings & ePN failures Initial Comment: There are a few small issues with the check_email_loop.pl script that cause ePN to fail in Nagios 2.0. The attached patch file addresses them and also defaults to the "-w" perl flag so warnings show up during future development work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1355304&group_id=29880 From noreply at sourceforge.net Sat Nov 12 19:20:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 12 19:20:55 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1333956 ] check_log errors on non-Linux platforms Message-ID: <200511130320.jAD3KpkI018648@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1333956, was opened at 10/21/05 02:46 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1333956&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Submitted By: Ade Rixon (aderixon) Assigned to: M. Sean Finney (seanius) Summary: check_log errors on non-Linux platforms Initial Comment: I am running check_log from the 1.4 release (unchanged in 1.4.2) on Solaris 8. It gives shell errors and falis to work correctly because: a) chmod command is unrecognised (no path) in the case where mktemp is not available; b) tail command uses GNU-specific long option instead of generic alternative. The attached patch fixes these issues and also adds: - variable definitions for CHMOD and TOUCH to match command usage in rest of script; - use of extended grep (egrep) in place of grep to support full regex matching; assume this works on all supported platforms. Ade ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 11/12/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 10/29/05 08:39 Message: Logged In: YES user_id=226838 this problem is now fixed in cvs. thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1333956&group_id=29880 From seanius at seanius.net Sun Nov 13 11:57:56 2005 From: seanius at seanius.net (sean finney) Date: Sun Nov 13 11:57:56 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> References: <4371F588.20966.D7F0C3@nagios.nagios.org> <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> Message-ID: <20051113195737.GA12236@seanius.net> hi, just to throw another $0.02 into the bucket... On Fri, Nov 11, 2005 at 12:51:48AM +0000, Ton Voon wrote: > "UNKNOWN is for invalid command args or any other failure before the > requested check can be performed - with the only exception being > hostname lookups which should return CRITICAL." given the example you listed below, i don't think this is a good idea. rather, i think something like: "UNKNOWN is for invalid command args or other failures preventing the plugin from performing the specified operation." about dns: i think there are two specific and very different kinds of failure. there is "general resolution failure", and there is a "host does not exist failure". i would say that the former ought to remain as an UNKNOWN, as it parallels similar failures in other system calls such as malloc. however, if the plugin gets a "no such host" response, then it definitely should be CRITICAL--as you could implicitly divine that the hostname is supposed to resolve. similarly, i feel that remote service check connection failures should remain CRITICAL. > (2) check_http -H webserver -w 2 > > This returns OK if can connect to webserver and returns data within 2 > seconds. If it cannot connect, then this returns UNKNOWN because it > is not the metric that is being requested to check against (currently > returns CRITICAL). i'd say it should still return CRITICAL. > (3) check_http -H webserver -r 'string_to_find' > > This returns OK if it can find the server and return data with the > string. If it cannot connect to the server (currently CRITICAL), or > gets a 302 redirection (currently OK (?) ), this should be an UNKNOWN. again, i think things such as "connection refused" should still result in states indicative of a problem. the big difference in my view is that some problems prevent the plugin from doing its job, while other problems signify that there really is a problem. wrt the 302 redirections, i haven't even looked at what we're currently doing but feel we ought to follow the redirection (or provide a cmdline toggle) if we want to be good user-agents :) for example, malloc or name resolution failing means that the plugin could not tell you the service status regardless of what it was, whereas a "host does not exist" or "connection refused" mean that something is in fact wrong (and that other people would probably be having the same problem). sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ae at op5.se Sun Nov 13 12:34:29 2005 From: ae at op5.se (Andreas Ericsson) Date: Sun Nov 13 12:34:29 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051113195737.GA12236@seanius.net> References: <4371F588.20966.D7F0C3@nagios.nagios.org> <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> <20051113195737.GA12236@seanius.net> Message-ID: <4377A34E.7030603@op5.se> sean finney wrote: > hi, > > just to throw another $0.02 into the bucket... > > On Fri, Nov 11, 2005 at 12:51:48AM +0000, Ton Voon wrote: > >>"UNKNOWN is for invalid command args or any other failure before the >>requested check can be performed - with the only exception being >>hostname lookups which should return CRITICAL." > > > given the example you listed below, i don't think this is a good idea. > rather, i think something like: > > "UNKNOWN is for invalid command args or other failures preventing > the plugin from performing the specified operation." > > about dns: i think there are two specific and very different kinds > of failure. there is "general resolution failure", and there is a > "host does not exist failure". i would say that the former ought > to remain as an UNKNOWN, as it parallels similar failures in other > system calls such as malloc. however, if the plugin gets a "no such > host" response, then it definitely should be CRITICAL I'd say UNKNOWN for both. The most common cases of HOST_NOT_FOUND are probably configuration file typos (shouldn't escalate to critical) and DNS misconfiguration (should return critical for the check_{dig,dns} plugins but no others). >--as you could > implicitly divine that the hostname is supposed to resolve. similarly, > i feel that remote service check connection failures should remain > CRITICAL. > Addendum to that last sentence; ... unless the remote service check connection is only established to query an agent returning a specific metric. That is, check_nt, check_nwstat, check_nrpe and check_snmp should return UNKNOWN if it can't get the data it's requesting (as it's not the status of the agent that's being requested). All others should return CRITICAL which is the logical thing to do when a plugin is being asked to connect to an ftp server and see how long it takes, as such; if (connection_failed) response_time = FOREVER; if (response_time > threshold) return CRITICAL; > > > >>(2) check_http -H webserver -w 2 >> >>This returns OK if can connect to webserver and returns data within 2 >>seconds. If it cannot connect, then this returns UNKNOWN because it >>is not the metric that is being requested to check against (currently >>returns CRITICAL). > > > i'd say it should still return CRITICAL. > It has to. It's being asked to check the functionality of a webserver that doesn't respond. It's a bit like asking someone dead if they're feeling alright and only chalk it up as CRITICAL if they say "no". > >>(3) check_http -H webserver -r 'string_to_find' >> >>This returns OK if it can find the server and return data with the >>string. If it cannot connect to the server (currently CRITICAL), or >>gets a 302 redirection (currently OK (?) ), this should be an UNKNOWN. > > > again, i think things such as "connection refused" should still result > in states indicative of a problem. the big difference in my > view is that some problems prevent the plugin from doing its job, > while other problems signify that there really is a problem. > > wrt the 302 redirections, i haven't even looked at what we're currently > doing but feel we ought to follow the redirection (or provide > a cmdline toggle) if we want to be good user-agents :) > 302 redirections must be followed or dropped, according to the RFC. Note that 302 is not an error code though, so if we don't follow we should return OK. > for example, malloc or name resolution failing means that the plugin > could not tell you the service status regardless of what it was, > whereas a "host does not exist" or "connection refused" mean that > something is in fact wrong (and that other people would probably > be having the same problem). > This logic holds with the addendum above (users don't query agents, only network admins and network monitoring tools do that). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From nagios at nagios.org Sun Nov 13 23:12:06 2005 From: nagios at nagios.org (Ethan Galstad) Date: Sun Nov 13 23:12:06 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051113195737.GA12236@seanius.net> References: <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> Message-ID: <4377E460.8505.34732A7@nagios.nagios.org> I agree with what Sean is suggestion for the return codes. I would recommend staying away from using the UNKNOWN state for much of anything - save internal plugin errors and command line boo-boos. Connection failures and timeouts should probably be CRITICAL errors, as they represent a real (serious) problem with the service being checked. On 13 Nov 2005 at 14:57, sean finney wrote: > hi, > > just to throw another $0.02 into the bucket... > > On Fri, Nov 11, 2005 at 12:51:48AM +0000, Ton Voon wrote: > > "UNKNOWN is for invalid command args or any other failure before the > > requested check can be performed - with the only exception being > > hostname lookups which should return CRITICAL." > > given the example you listed below, i don't think this is a good idea. > rather, i think something like: > > "UNKNOWN is for invalid command args or other failures preventing > the plugin from performing the specified operation." > > about dns: i think there are two specific and very different kinds > of failure. there is "general resolution failure", and there is a > "host does not exist failure". i would say that the former ought > to remain as an UNKNOWN, as it parallels similar failures in other > system calls such as malloc. however, if the plugin gets a "no such > host" response, then it definitely should be CRITICAL--as you could > implicitly divine that the hostname is supposed to resolve. similarly, > i feel that remote service check connection failures should remain > CRITICAL. > > > > > (2) check_http -H webserver -w 2 > > > > This returns OK if can connect to webserver and returns data within 2 > > seconds. If it cannot connect, then this returns UNKNOWN because it > > is not the metric that is being requested to check against (currently > > returns CRITICAL). > > i'd say it should still return CRITICAL. > > > (3) check_http -H webserver -r 'string_to_find' > > > > This returns OK if it can find the server and return data with the > > string. If it cannot connect to the server (currently CRITICAL), or > > gets a 302 redirection (currently OK (?) ), this should be an UNKNOWN. > > again, i think things such as "connection refused" should still result > in states indicative of a problem. the big difference in my > view is that some problems prevent the plugin from doing its job, > while other problems signify that there really is a problem. > > wrt the 302 redirections, i haven't even looked at what we're currently > doing but feel we ought to follow the redirection (or provide > a cmdline toggle) if we want to be good user-agents :) > > for example, malloc or name resolution failing means that the plugin > could not tell you the service status regardless of what it was, > whereas a "host does not exist" or "connection refused" mean that > something is in fact wrong (and that other people would probably > be having the same problem). > > > sean > Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From ton.voon at altinity.com Mon Nov 14 02:33:19 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Nov 14 02:33:19 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051113195737.GA12236@seanius.net> References: <4371F588.20966.D7F0C3@nagios.nagios.org> <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> <20051113195737.GA12236@seanius.net> Message-ID: <5B8997C1-8E37-4FE7-93B9-5DAB72A2DF51@altinity.com> On 13 Nov 2005, at 19:57, sean finney wrote: > just to throw another $0.02 into the bucket... Please! I value all your opinions! > On Fri, Nov 11, 2005 at 12:51:48AM +0000, Ton Voon wrote: >> "UNKNOWN is for invalid command args or any other failure before the >> requested check can be performed - with the only exception being >> hostname lookups which should return CRITICAL." > > given the example you listed below, i don't think this is a good idea. > rather, i think something like: > > "UNKNOWN is for invalid command args or other failures preventing > the plugin from performing the specified operation." Yes, I think this is better. I'm keep thinking about "things in the middle" that affect results. I think my facetious examples with check_http muddied the waters a bit. Just to make it clearer, how about amending to: "UNKNOWN is for invalid command args, or failures in other systems preventing the plugin from performing the specified operation" So, other systems that could prevent the check include: internal errors (unix level: malloc, fork, etc), networks, DNS and agents. > about dns: i think there are two specific and very different kinds > of failure. there is "general resolution failure", and there is a > "host does not exist failure". i would say that the former ought > to remain as an UNKNOWN, as it parallels similar failures in other > system calls such as malloc. however, if the plugin gets a "no such > host" response, then it definitely should be CRITICAL--as you could > implicitly divine that the hostname is supposed to resolve. > similarly, > i feel that remote service check connection failures should remain > CRITICAL. Given the above definition, both failures should be UNKNOWN. I'm with Andreas on this. But there's Sean and Ethan on CRITICAL. So the voting currently stands at 2-2. If we go with CRITICAL, then this needs to be marked as an exception in the guidelines. Andreas also says: > check_nt, check_nwstat, check_nrpe and check_snmp should return > UNKNOWN if it can't get the data it's requesting (as it's not the > status of the agent that's being requested) which also fits with this definition. >> (2) check_http -H webserver -w 2 >> >> This returns OK if can connect to webserver and returns data within 2 >> seconds. If it cannot connect, then this returns UNKNOWN because it >> is not the metric that is being requested to check against (currently >> returns CRITICAL). > > i'd say it should still return CRITICAL. > Yes, I'm clearly wrong. By the definition, it is not a failure "in [an]other system", so UNKNOWN is the wrong state, so it must be CRITICAL. >> (3) check_http -H webserver -r 'string_to_find' >> >> This returns OK if it can find the server and return data with the >> string. If it cannot connect to the server (currently CRITICAL), or >> gets a 302 redirection (currently OK (?) ), this should be an >> UNKNOWN. > > again, i think things such as "connection refused" should still result > in states indicative of a problem. Connection failure is critical. By the requested arguments, the string_to_find is not found, so OK is wrong. But it is not a failure in another system, so UNKNOWN is wrong too. So it must be CRITICAL (or, I guess, configurable to WARNING). > the big difference in my > view is that some problems prevent the plugin from doing its job, > while other problems signify that there really is a problem. I think that difference is a lot clearer in your mind than it is in mine :) I think the "other systems" helps me, which Sean's intuitively picked up on. > wrt the 302 redirections, i haven't even looked at what we're > currently > doing but feel we ought to follow the redirection (or provide > a cmdline toggle) if we want to be good user-agents :) The default is not to follow. "-f follow" in the case above will work. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanius at seanius.net Mon Nov 14 03:44:14 2005 From: seanius at seanius.net (sean finney) Date: Mon Nov 14 03:44:14 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <5B8997C1-8E37-4FE7-93B9-5DAB72A2DF51@altinity.com> References: <4371F588.20966.D7F0C3@nagios.nagios.org> <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> <20051113195737.GA12236@seanius.net> <5B8997C1-8E37-4FE7-93B9-5DAB72A2DF51@altinity.com> Message-ID: <20051114114216.GA26736@seanius.net> hey, On Mon, Nov 14, 2005 at 10:32:42AM +0000, Ton Voon wrote: > >about dns: i think there are two specific and very different kinds > >of failure. there is "general resolution failure", and there is a > >"host does not exist failure". i would say that the former ought > >to remain as an UNKNOWN, as it parallels similar failures in other > >system calls such as malloc. however, if the plugin gets a "no such > >host" response, then it definitely should be CRITICAL--as you could > >implicitly divine that the hostname is supposed to resolve. > >similarly, > >i feel that remote service check connection failures should remain > >CRITICAL. > > Given the above definition, both failures should be UNKNOWN. I'm with > Andreas on this. But there's Sean and Ethan on CRITICAL. So the > voting currently stands at 2-2. > > If we go with CRITICAL, then this needs to be marked as an exception > in the guidelines. i disagree that this would be an "exception", and has more to do with individual interpretation of the two classes of errors. in the case that name resolution fails entirely, this would be indicative of a problem outside the control of both the plugin and the remove service being checked(maybe someone tripped over the nagios servers' cable). in such a case, nothing can be divined about the ability to reach a specified host, and the contact for the service is not the proper person to notify. but... if the lookup operation succeeds (that is, it talks with a name server, but was unable to find a specified host), then dns is working "just fine" (or working, anyway). in such a case, there is nothing wrong with the plugin's attempt to prepare and/or execute the check, but the host does not seem to exist. such a problem would be more properly directed to the contact for the service. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ton.voon at altinity.com Mon Nov 14 07:34:42 2005 From: ton.voon at altinity.com (Ton Voon) Date: Mon Nov 14 07:34:42 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <20051114114216.GA26736@seanius.net> References: <4371F588.20966.D7F0C3@nagios.nagios.org> <522E5375-EEB2-48CE-912E-0B0458309D3A@altinity.com> <20051113195737.GA12236@seanius.net> <5B8997C1-8E37-4FE7-93B9-5DAB72A2DF51@altinity.com> <20051114114216.GA26736@seanius.net> Message-ID: <0717B2B6-4F6A-420C-9DE3-AE9D969C3389@altinity.com> On 14 Nov 2005, at 11:42, sean finney wrote: > On Mon, Nov 14, 2005 at 10:32:42AM +0000, Ton Voon wrote: >> >> Given the above definition, both failures should be UNKNOWN. I'm with >> Andreas on this. But there's Sean and Ethan on CRITICAL. So the >> voting currently stands at 2-2. >> >> If we go with CRITICAL, then this needs to be marked as an exception >> in the guidelines. > > i disagree that this would be an "exception", and has more to do with > individual interpretation of the two classes of errors. Think of it as trying to "nail down the interpretation" :) > in the case that name resolution fails entirely, this would be > indicative > of a problem outside the control of both the plugin and the remove > service > being checked(maybe someone tripped over the nagios servers' cable). > in such a case, nothing can be divined about the ability to reach a > specified host, and the contact for the service is not the proper > person > to notify. > > but... if the lookup operation succeeds (that is, it talks with a name > server, but was unable to find a specified host), then dns is working > "just fine" (or working, anyway). in such a case, there is nothing > wrong with the plugin's attempt to prepare and/or execute the check, > but the host does not seem to exist. Surely this is a problem with preparation? address = gethostbyname( hostname ); address is empty, can't get socket to connect So there is no way check_http can execute the check. Going back to the proposed definition: "UNKNOWN is for invalid command args, or failures in other systems preventing the plugin from performing the specified operation" This would be a failure in another system (name resolution, which could be files, DNS, LDAP, NIS+). So this must be UNKNOWN. However, I'm willing to concede and define this particular scenario as CRITICAL as long as it is documented in the guidelines (with recommended library routine to use). Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From nagios at nagios.org Mon Nov 14 08:52:37 2005 From: nagios at nagios.org (Ethan Galstad) Date: Mon Nov 14 08:52:37 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <0717B2B6-4F6A-420C-9DE3-AE9D969C3389@altinity.com> References: <20051114114216.GA26736@seanius.net> Message-ID: <43786C65.3461.42F81A@nagios.nagios.org> On 14 Nov 2005 at 15:34, Ton Voon wrote: > > On 14 Nov 2005, at 11:42, sean finney wrote: > > On Mon, Nov 14, 2005 at 10:32:42AM +0000, Ton Voon wrote: > >> > >> Given the above definition, both failures should be UNKNOWN. I'm with > >> Andreas on this. But there's Sean and Ethan on CRITICAL. So the > >> voting currently stands at 2-2. > >> > >> If we go with CRITICAL, then this needs to be marked as an exception > >> in the guidelines. > > > > i disagree that this would be an "exception", and has more to do with > > individual interpretation of the two classes of errors. > > Think of it as trying to "nail down the interpretation" :) > > > > in the case that name resolution fails entirely, this would be > > indicative > > of a problem outside the control of both the plugin and the remove > > service > > being checked(maybe someone tripped over the nagios servers' cable). > > in such a case, nothing can be divined about the ability to reach a > > specified host, and the contact for the service is not the proper > > person > > to notify. > > > > but... if the lookup operation succeeds (that is, it talks with a name > > server, but was unable to find a specified host), then dns is working > > "just fine" (or working, anyway). in such a case, there is nothing > > wrong with the plugin's attempt to prepare and/or execute the check, > > but the host does not seem to exist. > > Surely this is a problem with preparation? > > address = gethostbyname( hostname ); > address is empty, can't get socket to connect > > So there is no way check_http can execute the check. Going back to > the proposed definition: > > "UNKNOWN is for invalid command args, or failures in other systems > preventing the plugin from performing the specified operation" > > This would be a failure in another system (name resolution, which > could be files, DNS, LDAP, NIS+). So this must be UNKNOWN. > > However, I'm willing to concede and define this particular scenario > as CRITICAL as long as it is documented in the guidelines (with > recommended library routine to use). > > Ton Name and address resolution problems aren't internal to the plugin. The plugin was still able to attempt the resolution/connection/check, but the system came back with an error. Those types of problems and would probably be better suited for a CRITICAL state. Its just my opinion, but I would shy away from using the UNKNOWN state too much. I would consider rewording the guidelines as follows: "UNKNOWN is for invalid command args, or low-level failures internal to the plugin that prevent it from performing the specified operation. Higher-level errors such as name resolution errors, socket timeouts, etc. are outside the control of plugins and should generally NOT be reported as UNKNOWN states." Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From benoit.mortier at opensides.be Mon Nov 14 08:55:40 2005 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Mon Nov 14 08:55:40 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <43786C65.3461.42F81A@nagios.nagios.org> References: <20051114114216.GA26736@seanius.net> <43786C65.3461.42F81A@nagios.nagios.org> Message-ID: <200511141755.17718.benoit.mortier@opensides.be> Le Lundi 14 Novembre 2005 17:52, Ethan Galstad a ?crit?: [..] > Name and address resolution problems aren't internal to the plugin. > The plugin was still able to attempt the resolution/connection/check, > but the system came back with an error. Those types of problems and > would probably be better suited for a CRITICAL state. Its just my > opinion, but I would shy away from using the UNKNOWN state too much. > > I would consider rewording the guidelines as follows: > > "UNKNOWN is for invalid command args, or low-level failures internal > to the plugin that prevent it from performing the specified > operation. Higher-level errors such as name resolution errors, > socket timeouts, etc. are outside the control of plugins and should > generally NOT be reported as UNKNOWN states." I second this, it seems the better rules till now... -- Benoit Mortier CEO www.opensides.be From sghosh at sghosh.org Mon Nov 14 09:42:30 2005 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Nov 14 09:42:30 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: <200511141755.17718.benoit.mortier@opensides.be> References: <20051114114216.GA26736@seanius.net> <43786C65.3461.42F81A@nagios.nagios.org> <200511141755.17718.benoit.mortier@opensides.be> Message-ID: On Mon, 14 Nov 2005, Benoit Mortier wrote: > Le Lundi 14 Novembre 2005 17:52, Ethan Galstad a ?crit?: > > [..] > >> Name and address resolution problems aren't internal to the plugin. >> The plugin was still able to attempt the resolution/connection/check, >> but the system came back with an error. Those types of problems and >> would probably be better suited for a CRITICAL state. Its just my >> opinion, but I would shy away from using the UNKNOWN state too much. >> >> I would consider rewording the guidelines as follows: >> >> "UNKNOWN is for invalid command args, or low-level failures internal >> to the plugin that prevent it from performing the specified >> operation. Higher-level errors such as name resolution errors, >> socket timeouts, etc. are outside the control of plugins and should >> generally NOT be reported as UNKNOWN states." > > I second this, it seems the better rules till now... > > Second this as well. -- -sg From ton.voon at altinity.com Tue Nov 15 01:45:01 2005 From: ton.voon at altinity.com (Ton Voon) Date: Tue Nov 15 01:45:01 2005 Subject: [Nagiosplug-devel] Working on testcases In-Reply-To: References: <20051114114216.GA26736@seanius.net> <43786C65.3461.42F81A@nagios.nagios.org> <200511141755.17718.benoit.mortier@opensides.be> Message-ID: On 14 Nov 2005, at 17:41, Subhendu Ghosh wrote: >>> "UNKNOWN is for invalid command args, or low-level failures internal >>> to the plugin that prevent it from performing the specified >>> operation. Higher-level errors such as name resolution errors, >>> socket timeouts, etc. are outside the control of plugins and should >>> generally NOT be reported as UNKNOWN states." >> >> I second this, it seems the better rules till now... > > Second this as well. OK. Unless we have any major objections, I'll update the dev guidelines on Wednesday to add this in. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From piouso at gmail.com Wed Nov 16 18:27:01 2005 From: piouso at gmail.com (Pio Niyi) Date: Wed Nov 16 18:27:01 2005 Subject: [Nagiosplug-devel] Re: Welcome to the "Nagiosplug-devel" mailing list In-Reply-To: <20051117020605.C287F12E37@sc8-sf-spam2.sourceforge.net> References: <20051117020605.C287F12E37@sc8-sf-spam2.sourceforge.net> Message-ID: <3909846c0511161826id083d77td2723d4dd4c687e9@mail.gmail.com> Hi all, I'm a newbie to Nagios and I'm trying to monitor https on my servers but I can't seem to understand some of the options and their outputs my questios are: 1) for example what does this output mean in English: ./check_tcp -H somehost.com -p 443 -v Using service TCP Port: 0 flags: 0x6 server_expect_count: 0 TCP OK - 0.000 second response time on port 443|time=0.000484s;0.000000;0.000000;0.000000;10.000000 2) What parameters do I use to measure the -w (warnings) and -c (critical) threshold.. 3) I also noticed that when I ran nmap on the servers port 443 was open then after a while it wasn't open then I get connection refused error how do I monitor this service or do I enable flapping for this service?? or maybe I'm missing some basics if I am pls. can u send links of some tutorials on how to successfully monitor this service as it is crucial to the services my company offers. thanks in advance -- "I might be a slow walker but I never walk backwards" -Johnny Walker -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Wed Nov 16 19:21:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 16 19:21:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-995761 ] check_disk to include inode percentage. Message-ID: <200511170320.jAH3KBYw031888@sc8-sf-db2-new-b.sourceforge.net> Patches item #995761, was opened at 07/22/04 01:21 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=995761&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jorgen Lundman (lundman) Assigned to: M. Sean Finney (seanius) Summary: check_disk to include inode percentage. Initial Comment: Since the 1.4.0alpha1 plugins code in check_disk, which calls fsusage.c, already retrieves the inode values I thought to patch it to also print inode percentage free. Additionally, I changed the static "0" in perfdata to be inode percent free. I added -W and -K (sorry, -C was taken) for inode percent warning and critical levels. Alas, only percentage implemented as of now. (No integer value support). Current output looks like: # ./check_disk -l -w 10% -c 2% -X tmpfs -W 10% -K 2% DISK OK - free space: / 31266 MB (93% inode=98%);| /=31266MB;30168;32850;97;33521 And indeed, brining up the -W warning value triggers a warning: # ./check_disk -l -w 10% -c 2% -X tmpfs -W 98% -K 2% DISK WARNING - free space: / 31266 MB (93% inode=98%);| /=31266MB;30168;32850;97;33521 Hope it helps more than it annoys. I could also have patched contrib/check_inodes for Solaris's "df -o i" call, but since nearly all the work was already done in check_disk I opted for that approach. Sincerely, Lundy ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 11/16/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 11/02/05 01:02 Message: Logged In: YES user_id=226838 this patch has been committed to the nagiosplug CVS repository. thank you for your contribution. ---------------------------------------------------------------------- Comment By: Jorgen Lundman (lundman) Date: 07/22/04 20:45 Message: Logged In: YES user_id=286650 Additionally, there is a bug when you use -p, or -x, to list paths to include or exclude. The nodes allocated do not get w_df etc variables cleared, so when you walk the list, they get assigned to global w_df variables, and all tests are out the window. This is a side effect of an OS where malloc() returned memory is not zero'd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=995761&group_id=29880 From noreply at sourceforge.net Wed Nov 16 19:21:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 16 19:21:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1291126 ] Alternate ps for Solaris Message-ID: <200511170320.jAH3KB2U031905@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1291126, was opened at 09/14/05 09:04 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed Resolution: None Priority: 5 Submitted By: Bob Ingraham (rwingraham) Assigned to: M. Sean Finney (seanius) Summary: Alternate ps for Solaris Initial Comment: Per Sean, I am uploading the source for an alternate ps utility for Solaris that will work with the existing check_procs plugin. This alternate ps gets around the 80-character limitation inherent in the native ps for Solaris. It has been extensively testing on our corporate Solaris farm. Notes: 1. I've installed this alternate ps (called pst3) in the libexec directory, along with the other plugins. 2. It needs setuid-root permissions to run, but accepts no arguments and reads no input streams and therefore isn't subject to exploitations such as buffer overflow and the like. The only reason is needs the setuid-root permission is so that it can open the running kernel image, in READ-ONLY mode, in order to access the process argument vectors. 3. It requires a patch to the configuration file which substitutes this alternate utility instead of ps for Soalris systems. Bob ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 11/16/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 11/02/05 01:05 Message: Logged In: YES user_id=226838 haven't heard back from ya, and haven't heard any complaints, so i'm going to set this one to "pending" and close it at the next release ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 10/07/05 10:50 Message: Logged In: YES user_id=226838 hi bob, any chance you've taken a look to see if check_procs now works for you from cvs? about the other issues, i guess i don't have the interest to look more into it if you don't :) ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/25/05 08:23 Message: Logged In: YES user_id=226838 hi bob, i've now included your code in cvs head, and mangled the configure script appropriately, so pst3 should now be the default for all SunOS systems. could you try the latest copy of what's in cvs and verify that it works for you? as i previously stated, i don't have r00t on a solaris machine, unfortunately :( likewise, to any others who have r00t access on a solaris bug, i'd appreciate hearing back. ---------------------------------------------------------------------- Comment By: Bob Ingraham (rwingraham) Date: 09/22/05 12:20 Message: Logged In: YES user_id=1086870 Sean, To answer your previous posts (sorry for the delay - I've been slammed at work,): 1. why isn't pPsInfo->pr_pid included in the output? I designed pst3 to exactly duplicate the output columns produced by the output produced by the original Solaris ps command: /usr/bin/ps -Ao 's uid ppid vsz rss pcpu comm args' You'll notice that Parent-PID is requested (ppid) but not the current process PID (pid). According to the source for check_procs, you can search for children of a parent PID (hence the ppid,) or you can search for a username/uid (hence the uid). But apparetnly, the option is not provided to search for just a PID. 2. You need root access on a Solaris server. I have a Solaris box I can test you config changes on. 3. Can I drop privileges after opening the kernel image? I don't know if it will work. That would depend upon whether the subsequent kvm_* calls also check the effective UID of the caller or not. Do you still want me to try this? Bob ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/22/05 04:40 Message: Logged In: YES user_id=226838 slight complication, i'll email the list with details... ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/22/05 02:32 Message: Logged In: YES user_id=226838 btw: why isn't pPsInfo->pr_pid included in the output? ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/22/05 02:16 Message: Logged In: YES user_id=226838 hi bob, ton, i just finished looking over the script, and it looks good. unfortunately i no longer have root access to a solaris server, so i can't install the plugin setuid root. i can still throw together everything else (the configure patch, etc), but the final test will need to be conducted by someone else. ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 09/21/05 03:14 Message: Logged In: YES user_id=664364 Sean, plugins-root/ is created now. This would be the best place to put pst3. Ton ---------------------------------------------------------------------- Comment By: Ton Voon (tonvoon) Date: 09/20/05 00:55 Message: Logged In: YES user_id=664364 Sean, I have no problem with setuid scripts since we already have check_icmp and check_dhcp, but they don't install as root at the moment (it is manually done). I am trying to separate setuid scripts out to plugins- root/ so then the installer can be configured to install with the correct permissions, but haven't fully tested my local copy yet. Give me another day to sort this out. Ton ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 09/19/05 08:27 Message: Logged In: YES user_id=226838 hi bob, thanks for this, i've just taken a look over it. if this program has to run setuid root to open the kmem structure, would it be possible to drop priviliges immediately after having done so? ton: what are your thoughts about dropping this utility in the libexec dir? i could throw together a pretty quick configure patch to decide whether or not the ps utility was needed. not sure how we're handling the other setuid programs, but i could follow suit with whatever we're doing for the others ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1291126&group_id=29880 From naoki at valuecommerce.com Wed Nov 16 23:50:01 2005 From: naoki at valuecommerce.com (Naoki) Date: Wed Nov 16 23:50:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-995761 ] check_disk to include inode percentage Message-ID: <1132213722.32379.345.camel@dragon.sys.intra> A while back I was asking a question regarding file systems such as reiser that do not use inodes, for such file systems the nagios plugin will always report an error "0 inodes free" which to me seems wrong. Will this patch alter the functioning of the check such that extent based, and other file systems without traditional inodes will report "100% free" all the time ? From ae at op5.se Thu Nov 17 00:33:10 2005 From: ae at op5.se (Andreas Ericsson) Date: Thu Nov 17 00:33:10 2005 Subject: [Nagiosplug-devel] Re: Welcome to the "Nagiosplug-devel" mailing list In-Reply-To: <3909846c0511161826id083d77td2723d4dd4c687e9@mail.gmail.com> References: <20051117020605.C287F12E37@sc8-sf-spam2.sourceforge.net> <3909846c0511161826id083d77td2723d4dd4c687e9@mail.gmail.com> Message-ID: <437C4017.70708@op5.se> Pio Niyi wrote: > Hi all, > I'm a newbie to Nagios and I'm trying to monitor https on my servers but I > can't seem to understand some of the options and their outputs my questios > are: > > 1) for example what does this output mean in English: > > ./check_tcp -H somehost.com -p 443 -v The -v flag is for debugging plugins. Non-programmers aren't expected to understand it, since you need to read the code to be able to understand what everything means. In this case you may also have to know the binary positions of tcp flags. > Using service TCP > Port: 0 > flags: 0x6 > server_expect_count: 0 > TCP OK - 0.000 second response time on port > 443|time=0.000484s;0.000000;0.000000;0.000000;10.000000 > > > 2) What parameters do I use to measure the -w (warnings) and -c (critical) > threshold.. > Whatever you choose. > 3) I also noticed that when I ran nmap on the servers port 443 was open then > after a while it wasn't open then I get connection refused error how do I > monitor this service or do I enable flapping for this service?? > Flapping is autodetected if you enable it. > or maybe I'm missing some basics if I am pls. can u send links of some > tutorials on how to successfully monitor this service as it is crucial to > the services my company offers. > thanks in advance > check_http --help grok the Nagios docs. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Thu Nov 17 17:46:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 17 17:46:10 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1251096 ] check_ntp perl warnings Message-ID: Bugs item #1251096, was opened at 2005-08-03 16:49 Message generated for change (Comment added) made by fischaz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Peter Pramberger (peterpramb) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp perl warnings Initial Comment: Using check_ntp.pl from plugins 1.4.1 produces some warnings if the checked host is not reachable or responding before timeout. These warnings produce an UNKNOWN state in Nagios. See the attached patch for clarification. ---------------------------------------------------------------------- Comment By: Johan Fischer (fischaz) Date: 2005-11-18 02:45 Message: Logged In: YES user_id=459934 The attached patch is wrong. It will override the value of the jitter. Basically the jitter is defined as undef at the begginning, then should be overriden for each server with selected by the regex. It should not be touched otherwise. On the other side, more tests need to be done to see if jitter is defined (and in that case, it will be a numeric) and print it. So it means more test at the end of the script to parse the results. ---------------------------------------------------------------------- Comment By: Charles Bueche (cbueche) Date: 2005-10-27 10:30 Message: Logged In: YES user_id=299377 duplicate with 1267741 ---------------------------------------------------------------------- Comment By: Ade Rixon (aderixon) Date: 2005-10-21 12:12 Message: Logged In: YES user_id=145082 This is still a problem in 1.4.2, can someone review before next release, please? The warning is: Argument "(not parsed)" isn't numeric in abs at ./check_ntp line 401. ...Caused by assigning a string value ('(not parsed)') to $jitter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 From noreply at sourceforge.net Thu Nov 17 17:47:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 17 17:47:16 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1251096 ] check_ntp perl warnings Message-ID: Bugs item #1251096, was opened at 2005-08-03 16:49 Message generated for change (Comment added) made by fischaz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Peter Pramberger (peterpramb) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp perl warnings Initial Comment: Using check_ntp.pl from plugins 1.4.1 produces some warnings if the checked host is not reachable or responding before timeout. These warnings produce an UNKNOWN state in Nagios. See the attached patch for clarification. ---------------------------------------------------------------------- Comment By: Johan Fischer (fischaz) Date: 2005-11-18 02:46 Message: Logged In: YES user_id=459934 Below patch (that I can't seem to be able to attach) diff -Naur nagios-plugins-1.4.2.orig/plugins-scripts/check_ntp.pl nagios-plugins-1.4.2/plugins-scripts/check_ntp.pl --- nagios-plugins-1.4.2.orig/plugins-scripts/check_ntp.pl 2005-05-26 00:05:41.000000000 +1000 +++ nagios-plugins-1.4.2/plugins-scripts/check_ntp.pl 2005-11-18 12:39:07.000000000 +1100 @@ -309,7 +309,6 @@ } } else { print "No match!\n" if $verbose; - $jitter = '(not parsed)'; } } @@ -365,7 +364,7 @@ } elsif ($have_ntpq && $jitter_error != $ERRORS{'OK'}) { $state = $jitter_error; - $answer = "Jitter $jitter too high"; + $answer = 'Jitter ' . ((defined $jitter) ? $jitter : '-') . ' too high'; if (defined($offset) && abs($offset) > $ocrit) { $state = $ERRORS{'CRITICAL'}; $answer = "Jitter error and offset $offset sec > +/- $ocrit sec"; @@ -401,13 +400,13 @@ if (abs($offset) > $ocrit) { $state = $ERRORS{'CRITICAL'}; $answer = "Offset $offset sec > +/- $ocrit sec, jitter $jitter msec"; - } elsif (abs($jitter) > $jcrit ) { + } elsif (defined($jitter) && abs($jitter) > $jcrit ) { $state = $ERRORS{'CRITICAL'}; $answer = "Jitter $jitter msec> +/- $jcrit msec, offset $offset sec"; } elsif (abs($offset) > $owarn) { $state = $ERRORS{'WARNING'}; $answer = "Offset $offset sec > +/- $owarn sec, jitter $jitter msec"; - } elsif (abs($jitter) > $jwarn ) { + } elsif (defined($jitter) && abs($jitter) > $jwarn ) { $state = $ERRORS{'WARNING'}; $answer = "Jitter $jitter msec> +/- $jwarn msec, offset $offset sec"; @@ -421,7 +420,7 @@ foreach my $key (keys %ERRORS) { if ($state==$ERRORS{$key}) { # print ("NTP $key: $answer"); - print ("NTP $key: $answer|offset=$offset, jitter=" . $jitter/1000 . ",peer_stratum=$stratum\n"); + print ("NTP $key: $answer|offset=$offset, jitter=" . ((defined $jitter) ? $jitter/1000 : '-') . ",peer_stratum=$stratum\n"); last; } } ---------------------------------------------------------------------- Comment By: Johan Fischer (fischaz) Date: 2005-11-18 02:45 Message: Logged In: YES user_id=459934 The attached patch is wrong. It will override the value of the jitter. Basically the jitter is defined as undef at the begginning, then should be overriden for each server with selected by the regex. It should not be touched otherwise. On the other side, more tests need to be done to see if jitter is defined (and in that case, it will be a numeric) and print it. So it means more test at the end of the script to parse the results. ---------------------------------------------------------------------- Comment By: Charles Bueche (cbueche) Date: 2005-10-27 10:30 Message: Logged In: YES user_id=299377 duplicate with 1267741 ---------------------------------------------------------------------- Comment By: Ade Rixon (aderixon) Date: 2005-10-21 12:12 Message: Logged In: YES user_id=145082 This is still a problem in 1.4.2, can someone review before next release, please? The warning is: Argument "(not parsed)" isn't numeric in abs at ./check_ntp line 401. ...Caused by assigning a string value ('(not parsed)') to $jitter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 From noreply at sourceforge.net Thu Nov 17 17:59:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 17 17:59:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1359414 ] 64bits support for mysql Message-ID: Bugs item #1359414, was opened at 2005-11-18 02:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1359414&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compilation Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Johan Fischer (fischaz) Assigned to: Nobody/Anonymous (nobody) Summary: 64bits support for mysql Initial Comment: nagios-plugins 1.4.2 (and current CVS HEAD as well) don't build the check_mysql plugin for a x86_64 bits arch. on my system (centos 4.2 on a x86_64), the mysql library is located (like most of the libs) in /usr/lib64/mysql and not anymore in /usr/lib For this situation I used a quick hack (see attached patch) to call mysql_config and use it to get the mysql lib and include path on any linux system... I'm sure the hack is not portable enough since I removed most of the tests trusting the result of the mysql_config call.... But the intention is to, if mysql_config exists, use it, and if not, fallback on the usual tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1359414&group_id=29880 From ton.voon at altinity.com Fri Nov 18 07:39:02 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 18 07:39:02 2005 Subject: [Nagiosplug-devel] Tinderbox server Message-ID: <5192872F-104D-4EF8-B419-5A3731698683@altinity.com> Hi! I've managed to get a tinderbox server running now. You can see status here: http://tinderbox.altinity.org. Currently, the trees are flaming because the automated tests are failing. I'll be working on these in the next week (with Serhan Kiymaz, who has offered to help). We'd welcome any volunteer build boxes, to increase the visibility of builds on other platforms. See the front page for information. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From noreply at sourceforge.net Fri Nov 18 10:58:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 18 10:58:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1285165 ] changed output to match dev guidelines Message-ID: Patches item #1285165, was opened at 2005-09-08 12:57 Message generated for change (Settings changed) made by monkeymanorg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1285165&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: monkeymanorg (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) Summary: changed output to match dev guidelines Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1285165&group_id=29880 From noreply at sourceforge.net Fri Nov 18 11:02:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 18 11:02:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1288725 ] check_dhcp UNKNOWN set incorrectly, output matches standards Message-ID: Patches item #1288725, was opened at 2005-09-12 08:53 Message generated for change (Comment added) made by monkeymanorg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Bugfix Group: None Status: Open Resolution: None Priority: 5 Submitted By: monkeymanorg (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) >Summary: check_dhcp UNKNOWN set incorrectly, output matches standards Initial Comment: Trivial patch for standardization. Changed the plugin to conform to the developer guideline of "METRIC STATUS: Information text" in the one line output of the plugin. Also removed the #defines for the status codes. UNKNOWN was set to -1 instead of 3 and they are already included from common.h. ---------------------------------------------------------------------- >Comment By: monkeymanorg (monkeymanorg) Date: 2005-11-18 14:01 Message: Logged In: YES user_id=1277734 updated the patch against the 1.4.2 branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1288725&group_id=29880 From noreply at sourceforge.net Fri Nov 18 11:09:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 18 11:09:04 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1201050 ] check_mem with perf data Message-ID: Patches item #1201050, was opened at 2005-05-12 18:00 Message generated for change (Settings changed) made by monkeymanorg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1201050&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Garrett Honeycutt (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) Summary: check_mem with perf data Initial Comment: wrote a quick perl script that calculates the percentage of memory usage based on the outputs on `free`. the script has perf data, as well. depending on OS / kernel, you might need to awk out a different group for your needs.. so give it a sanity check. ---------------------------------------------------------------------- >Comment By: Garrett Honeycutt (monkeymanorg) Date: 2005-11-18 14:08 Message: Logged In: YES user_id=1277734 not an offical plugin .. using nagiosexchange ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1201050&group_id=29880 From noreply at sourceforge.net Fri Nov 18 11:10:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 18 11:10:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1201049 ] added perf data to check_cpu Message-ID: Patches item #1201049, was opened at 2005-05-12 17:54 Message generated for change (Comment added) made by monkeymanorg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1201049&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Perf data Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Garrett Honeycutt (monkeymanorg) Assigned to: Nobody/Anonymous (nobody) Summary: added perf data to check_cpu Initial Comment: Added performance data... cause graphs are cool ---------------------------------------------------------------------- >Comment By: Garrett Honeycutt (monkeymanorg) Date: 2005-11-18 14:09 Message: Logged In: YES user_id=1277734 not an offical plugin .. using nagiosexchange ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1201049&group_id=29880 From noreply at sourceforge.net Fri Nov 18 21:51:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 18 21:51:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1310495 ] check_snmp.c Doesn't Compile on RH7.3 Message-ID: Bugs item #1310495, was opened at 2005-10-01 16:09 Message generated for change (Comment added) made by judg3 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1310495&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Craig Orsinger (cjorsinger) Assigned to: Nobody/Anonymous (nobody) Summary: check_snmp.c Doesn't Compile on RH7.3 Initial Comment: Because there's a local variable declared in the middle of a while loop, this source file won't compile on RedHat 7.3. The error was introduced in nagios-plugins version 1.4.1, and still exists in version 1.4.2. I've attempted to attach a patch file that fixes this. ---------------------------------------------------------------------- Comment By: Jeremy D Pavleck (judg3) Date: 2005-11-18 23:50 Message: Logged In: YES user_id=510182 exact same problem on Solaris 9. The patch fixed it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1310495&group_id=29880 From dalain.zuir at ge.com Mon Nov 21 09:04:04 2005 From: dalain.zuir at ge.com (Zuir, Dalain (GE Energy, Non GE)) Date: Mon Nov 21 09:04:04 2005 Subject: [Nagiosplug-devel] question about check_ping 1.42 Message-ID: Hello, First thanks for your support, Now the issue is that I need to add the normal -W flag for the ping can you help me to see on witch part of the code I need to add it would be great I need to add -W 8000 for all the pings like default so can you just tell me. Thanks a lot Dalain Zuir Rios. From ae at op5.se Mon Nov 21 09:21:05 2005 From: ae at op5.se (Andreas Ericsson) Date: Mon Nov 21 09:21:05 2005 Subject: [Nagiosplug-devel] question about check_ping 1.42 In-Reply-To: References: Message-ID: <438201CF.4040601@op5.se> Zuir, Dalain (GE Energy, Non GE) wrote: > Hello, First thanks for your support, > > Now the issue is that I need to add the normal -W flag for the ping > can you help me to see on witch part of the code I need to add it > would be great I need to add -W 8000 for all the pings like default > so can you just tell me. > On my system, -W sets timeout in seconds. Are you sure you want 2 hours+ timeout on a ping check? If you read the check_ping.c code you'll see where to add it, or you could use the check_icmp plugin. If there some option you need to have that it doesn't, tell me about it. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From ae at op5.se Mon Nov 21 09:39:06 2005 From: ae at op5.se (Andreas Ericsson) Date: Mon Nov 21 09:39:06 2005 Subject: [Nagiosplug-devel] question about check_ping 1.42 In-Reply-To: References: Message-ID: <4382060A.4050101@op5.se> Zuir, Dalain (GE Energy, Non GE) wrote: > Thanks so much for answers me. > > I'll check icmp maybe that is the answer. > check_icmp. It's a plugin. :) > the issue is that I run nagios check_ping service but I can not add the normal > -W 3000 (-w timeout Timeout in milliseconds to wait for each reply) option that I use in a normal ping. > check_icmp -i 3000 -H host.xz should do the trick. Try check_icmp -h otherwise. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From noreply at sourceforge.net Mon Nov 21 19:21:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 21 19:21:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1341528 ] configure options to skip program autodetection Message-ID: <200511220320.jAM3KLrk025105@sc8-sf-db2-new-b.sourceforge.net> Feature Requests item #1341528, was opened at 10/29/05 05:17 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Priority: 5 Submitted By: Elan Ruusam?e (ahmake) Assigned to: M. Sean Finney (seanius) Summary: configure options to skip program autodetection Initial Comment: hi this patch adds commandline arguments to specify location of programs to be used, so the programs are not needed to exist at compile time in system, but plugins are usable. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch please be so kind and apply in your cvs. note: the ps program related patch chunk creates .rej with current snapshot (200510290447), but if you apply the rest, i'm happy to make that portion compatible with current cvs code. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 11/21/05 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 11/07/05 04:50 Message: Logged In: YES user_id=226838 hi elan, i've merged your patch into the latest cvs, thanks! i've made the following modifications: - all the AC_ARG_WITH statements were modified to use ACX_HELP_STRING in their descriptions - a couple other random cosmetic changes (PATH instead of , etc) - changed "with-cols" to "with-ps-cols" at some later time, i may take another pass over the entire configure.in script to try and clean up and consolidate the detection code, but what you've provided seems to work from my initial testing, so... it's in. thanks again, sean ---------------------------------------------------------------------- Comment By: Elan Ruusam?e (ahmake) Date: 11/04/05 18:34 Message: Logged In: YES user_id=289546 (thank you sourceforge for discarding my first post as i wasn't logged in) sorry for the delay, i've got carried away with work last week i've updated the patch to apply against 200510310547 snapshot. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-configure.patch?rev=1.6.2.1 regarding the ac_cv_ping_has_timeout=yes, it was already broken by design. ie if --with-ping-command was supplied it was set to no. perhaps add configure options for those two options (see below)? here's the configure.ac snippet: AC_MSG_CHECKING(for ICMP ping syntax) ac_cv_ping_packets_first=no ac_cv_ping_has_timeout=no if test -n "$with_ping_command" then AC_MSG_RESULT([(command-line) $with_ping_command]) if test -n "$ac_cv_ping_packets_first" then ac_cv_ping_packets_first=yes ac_cv_ping_has_timeout=yes fi ---------------------------------------------------------------------- Comment By: Elan Ruusam?e (ahmake) Date: 10/29/05 07:12 Message: Logged In: YES user_id=289546 ok. i've updated the /proc/loadavg to be also with commandline arg. ac_cv_ping_has_timeout needs more look, i guess it was added because there was no way to do it with commandline. i'll look on this later, perhaps on monday. ---------------------------------------------------------------------- Comment By: M. Sean Finney (seanius) Date: 10/29/05 05:42 Message: Logged In: YES user_id=226838 hi elan, this would be a wonderful feature to have. as i'm also maintaining the debian distribution's package, i'm very much in the same situation as you. the previous maintainer issued build-dependencies on these packages, which was not only an ugly hack but also problematic, as some of the dependencies tried to install daemons on the debian build-hosts :) my current approach was to patch common.h to include a "debian.h" that had everything hardcoded, which isn't the most "graceful" way anyway, if you could supply a version that works against the current configure.in in cvs HEAD, i'd be more than willing to include it. also, could you comment on the first two hunks in the patch? not sure what the first one does and the second looks like it would have problems on non-linux hosts. thanks, sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341528&group_id=29880 From noreply at sourceforge.net Tue Nov 22 13:35:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 22 13:35:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1364157 ] bring contrib programs into shape Message-ID: Feature Requests item #1364157, was opened at 2005-11-22 23:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1364157&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Elan Ruusam?e (ahmake) Assigned to: Nobody/Anonymous (nobody) Summary: bring contrib programs into shape Initial Comment: hello again ;) http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-contrib-API.patch?rev=1.3 this makes few contrib programs to compile with newer mysql (4.0+ i believe) and with current nagios api. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1364157&group_id=29880 From noreply at sourceforge.net Tue Nov 22 13:38:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 22 13:38:10 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-1341531 ] subst problem Message-ID: Feature Requests item #1341531, was opened at 2005-10-29 15:19 Message generated for change (Comment added) made by ahmake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341531&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Elan Ruusam?e (ahmake) Assigned to: Nobody/Anonymous (nobody) Summary: subst problem Initial Comment: do the utils.pm substitution AFTER path based substitution otherwise if 'nagios' is in $PATH somewhy, then wrong perl library path is substituted to perl programs. http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/nagios-plugins-subst.patch?rev=1.2 ---------------------------------------------------------------------- >Comment By: Elan Ruusam?e (ahmake) Date: 2005-11-22 23:37 Message: Logged In: YES user_id=289546 just to encourage somebody to apply this. it's safe fix. it's almost getting year old patch in PLD Linux :) to reproduce: try configuring nagios-plugins with /usr/sbin in your $PATH (ie location where nagios is installed) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=1341531&group_id=29880 From seanius at seanius.net Wed Nov 23 06:29:18 2005 From: seanius at seanius.net (sean finney) Date: Wed Nov 23 06:29:18 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-995761 ] check_disk to include inode percentage. In-Reply-To: <43688359.3000307@op5.se> References: <43688359.3000307@op5.se> Message-ID: <20051123142843.GA16948@seanius.net> getting back around to this, On Wed, Nov 02, 2005 at 10:14:01AM +0100, Andreas Ericsson wrote: > -W is protected by posix for "implementation specific purposes". Some > implementations make -W fud equal -f -u -d, and some just makes it > ignore warnings for unrecognized options. finally found the right google incantation to bring up the posix reference. it is reserved for "vendor extensions", which is somewhat ambiguous but i agree that we shouldn't use it. looking for examples of "vendor"s implementing -W, i find that the latest LSB spec states that -W will pass all (colon seperated) arguments seperately as long options, for example, i have no idea about others. > If we're going to use it we should force our own getopt library code to > be used, like gcc does. we should either remove references to -W in all plugins or do this, yes. however, in this specific case (check_disk, inodes) i think a more optimal solution would be to provide another cmdline option to specify to check pct/amount/inodes/foo used/free. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From cisbani at perlafinanza.it Thu Nov 24 09:44:03 2005 From: cisbani at perlafinanza.it (Emanuele Cisbani) Date: Thu Nov 24 09:44:03 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: Message-ID: <20051124174317.5A9EE4F415D@desire.netways.de> Hi I dont know why, but the following bash script work fine. May be the problem is elsewere? - Emanuele Cisbani (cisba) #!/bin/bash # Standard Nagios Status codes STATE_OK=0 STATE_WARNING=1 STATE_CRITICAL=2 STATE_UNKNOWN=3 filename="/tmp/check_dns_$$.tmp" result='' stato='UNKNOWN' code=3 dig @"$2" "$1" > $filename 2>&1 #head $filename num_of_answer=$(cat $filename \ | grep ANSWER: \ | awk 'BEGIN{FS=","}{print $2}' \ | awk 'BEGIN{FS=":"}{print $2}' ) if grep 'ANSWER:' $filename >'/dev/null' ; then result=$num_of_answer if [ $result -gt 0 ] ; then stato="OK" code=0 elif [ $result -eq 0 ]; then stato="WARNING: $(cat $filename)" code=1 fi elif grep "connection timed out" >'/dev/null' $filename ; then stato="CRITICAL: $(cat $filename)" code=2 elif grep "Couldn't find server" >'/dev/null' $filename ; then stato="CRITICAL: $(cat $filename)" code=2 fi rm $filename echo $stato exit $code ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofa q_pi1[showUid]=10253 From cisbani at perlafinanza.it Thu Nov 24 09:44:05 2005 From: cisbani at perlafinanza.it (Emanuele Cisbani) Date: Thu Nov 24 09:44:05 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: References: Message-ID: <20051124174348.F2B7D4F415D@desire.netways.de> Hi I dont know why, but the following bash script work fine. May be the problem is elsewere? - Emanuele Cisbani (cisba) #!/bin/bash # Standard Nagios Status codes STATE_OK=0 STATE_WARNING=1 STATE_CRITICAL=2 STATE_UNKNOWN=3 filename="/tmp/check_dns_$$.tmp" result='' stato='UNKNOWN' code=3 dig @"$2" "$1" > $filename 2>&1 #head $filename num_of_answer=$(cat $filename \ | grep ANSWER: \ | awk 'BEGIN{FS=","}{print $2}' \ | awk 'BEGIN{FS=":"}{print $2}' ) if grep 'ANSWER:' $filename >'/dev/null' ; then result=$num_of_answer if [ $result -gt 0 ] ; then stato="OK" code=0 elif [ $result -eq 0 ]; then stato="WARNING: $(cat $filename)" code=1 fi elif grep "connection timed out" >'/dev/null' $filename ; then stato="CRITICAL: $(cat $filename)" code=2 elif grep "Couldn't find server" >'/dev/null' $filename ; then stato="CRITICAL: $(cat $filename)" code=2 fi rm $filename echo $stato exit $code ----------------------- This thread is located in the archive at this URL: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html?&tx_maillisttofa q_pi1[showUid]=10253 From ton.voon at altinity.com Fri Nov 25 02:32:10 2005 From: ton.voon at altinity.com (Ton Voon) Date: Fri Nov 25 02:32:10 2005 Subject: [Nagiosplug-devel] check_dns: DNS WARNING - nslookup returned error status In-Reply-To: <20051124174348.F2B7D4F415D@desire.netways.de> References: <20051124174348.F2B7D4F415D@desire.netways.de> Message-ID: <13AC5E51-D04A-4CDF-8C6E-1A65176C38DC@altinity.com> On 24 Nov 2005, at 17:43, Emanuele Cisbani wrote: > > I dont know why, but the following bash script work fine. > Emanuele, Thanks for your report. The problem was in the signal handling of nslookup/dig when called from popen in the C version of check_dns. Bash may handle external calls in a different way. As we've patched this in the 1.4.2 release and Sacha has raised this to Red Hat and has been fixed in the kernel, I think this thread can be closed. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From a.depretis at 25th-floor.com Tue Nov 29 06:13:04 2005 From: a.depretis at 25th-floor.com (Andreas de Pretis) Date: Tue Nov 29 06:13:04 2005 Subject: [Nagiosplug-devel] Patch for check_mailq.pl Message-ID: <438C60BC.4040708@25th-floor.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I attached a patch that adds an option "-Q" (--clientmqueue) to "check_mail.pl". With this option its possible to check sendmail's submission queue (e.g. /var/spool/clientmqueue) instead of the MTA queue (e.g. /var/spool/mqueue) Eventually you'll find it useful :-) Regards, Andreas de Pretis - -- - --------------------------------------------------------------- Andreas de Pretis Mail: a.depretis at 25th-floor.com de Pretis & Helmberger KEG Web : http://www.25th-floor.com Hauslabgasse 35-37/28, Mob.: +43 699 201 58 627 A-1050 Wien, Austria Fax : +43 699 401 58 627 - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDjGC8GFoAHJp0DTURAr2EAJwIKNt/DaVBseWK9RPqmVG9geRG2wCgu/AS nLPKEuaxVzSI7lbtMnJYP7A= =xKpv -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_mailq.pl-clientmqueue.patch URL: From noreply at sourceforge.net Tue Nov 29 13:48:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 29 13:48:01 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1350249 ] check_disk -p ignores third and following argument of -p Message-ID: Bugs item #1350249, was opened at 2005-11-07 04:50 Message generated for change (Comment added) made by harpermann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1350249&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Maik (aussendorf) >Assigned to: Harper Mann (harpermann) Summary: check_disk -p ignores third and following argument of -p Initial Comment: Using version 1.4.2 (tar download from 11/07/05 If I call check_disk with the -p option, it will check the first two named pathes only. It will ignore any following path. e.g. check_disk -w 100 -c 30 -p /p1 / p2 /p3 will only check /p1 and /p2, while /p3 is ignored. With kind regards Maik Aussendorf ---------------------------------------------------------------------- >Comment By: Harper Mann (harpermann) Date: 2005-11-29 13:47 Message: Logged In: YES user_id=939531 Hi Maik, The "-p" argument works if you use multiple ones. Like this: ./check_disk -w 100 -c 30 -p / -p /boot DISK OK - free space: / 22014 MB (62% inode=94%); /boot 84 MB (85% inode=100%);| /=13471MB;35385;35455;94;35485 /boot=14MB;98;68;99;98 I think that's a more traditional use of a *NIX CLI argument. Does that work for you? Cheers, - Harper ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1350249&group_id=29880 From noreply at sourceforge.net Tue Nov 29 15:23:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 29 15:23:05 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1355304 ] contrib/check_email_loop.pl - Perl warnings & ePN failures Message-ID: Bugs item #1355304, was opened at 2005-11-12 08:51 Message generated for change (Comment added) made by harpermann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1355304&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Embedded Perl failure Group: CVS >Status: Closed Resolution: None Priority: 5 Submitted By: Robert Gash (gashalot) >Assigned to: Harper Mann (harpermann) Summary: contrib/check_email_loop.pl - Perl warnings & ePN failures Initial Comment: There are a few small issues with the check_email_loop.pl script that cause ePN to fail in Nagios 2.0. The attached patch file addresses them and also defaults to the "-w" perl flag so warnings show up during future development work. ---------------------------------------------------------------------- >Comment By: Harper Mann (harpermann) Date: 2005-11-29 15:22 Message: Logged In: YES user_id=939531 Added included patch and tested. Fixed a type comparison warning and return code of "-1" for UNKNOWN changed to "3". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1355304&group_id=29880 From noreply at sourceforge.net Tue Nov 29 16:51:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 29 16:51:05 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1251096 ] check_ntp perl warnings Message-ID: Bugs item #1251096, was opened at 2005-08-03 07:49 Message generated for change (Comment added) made by harpermann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: Release (specify) >Status: Closed Resolution: None Priority: 5 Submitted By: Peter Pramberger (peterpramb) >Assigned to: Harper Mann (harpermann) Summary: check_ntp perl warnings Initial Comment: Using check_ntp.pl from plugins 1.4.1 produces some warnings if the checked host is not reachable or responding before timeout. These warnings produce an UNKNOWN state in Nagios. See the attached patch for clarification. ---------------------------------------------------------------------- >Comment By: Harper Mann (harpermann) Date: 2005-11-29 16:50 Message: Logged In: YES user_id=939531 Hi Peter and Johan, Thanks for filing this bug. check_ntp wasn't properly handing a bad exit status from the external programs it calls (ntpdate and ntpq), so jitter wasn't set. Added check of $? on close and proper error output if status from the sub program call completion is non-zero. This includes "host not found". Please verify this is fixed in your environment. I'll reopen the bug if you find any problems. Regards, - Harper ---------------------------------------------------------------------- Comment By: Johan Fischer (fischaz) Date: 2005-11-17 17:46 Message: Logged In: YES user_id=459934 Below patch (that I can't seem to be able to attach) diff -Naur nagios-plugins-1.4.2.orig/plugins-scripts/check_ntp.pl nagios-plugins-1.4.2/plugins-scripts/check_ntp.pl --- nagios-plugins-1.4.2.orig/plugins-scripts/check_ntp.pl 2005-05-26 00:05:41.000000000 +1000 +++ nagios-plugins-1.4.2/plugins-scripts/check_ntp.pl 2005-11-18 12:39:07.000000000 +1100 @@ -309,7 +309,6 @@ } } else { print "No match!\n" if $verbose; - $jitter = '(not parsed)'; } } @@ -365,7 +364,7 @@ } elsif ($have_ntpq && $jitter_error != $ERRORS{'OK'}) { $state = $jitter_error; - $answer = "Jitter $jitter too high"; + $answer = 'Jitter ' . ((defined $jitter) ? $jitter : '-') . ' too high'; if (defined($offset) && abs($offset) > $ocrit) { $state = $ERRORS{'CRITICAL'}; $answer = "Jitter error and offset $offset sec > +/- $ocrit sec"; @@ -401,13 +400,13 @@ if (abs($offset) > $ocrit) { $state = $ERRORS{'CRITICAL'}; $answer = "Offset $offset sec > +/- $ocrit sec, jitter $jitter msec"; - } elsif (abs($jitter) > $jcrit ) { + } elsif (defined($jitter) && abs($jitter) > $jcrit ) { $state = $ERRORS{'CRITICAL'}; $answer = "Jitter $jitter msec> +/- $jcrit msec, offset $offset sec"; } elsif (abs($offset) > $owarn) { $state = $ERRORS{'WARNING'}; $answer = "Offset $offset sec > +/- $owarn sec, jitter $jitter msec"; - } elsif (abs($jitter) > $jwarn ) { + } elsif (defined($jitter) && abs($jitter) > $jwarn ) { $state = $ERRORS{'WARNING'}; $answer = "Jitter $jitter msec> +/- $jwarn msec, offset $offset sec"; @@ -421,7 +420,7 @@ foreach my $key (keys %ERRORS) { if ($state==$ERRORS{$key}) { # print ("NTP $key: $answer"); - print ("NTP $key: $answer|offset=$offset, jitter=" . $jitter/1000 . ",peer_stratum=$stratum\n"); + print ("NTP $key: $answer|offset=$offset, jitter=" . ((defined $jitter) ? $jitter/1000 : '-') . ",peer_stratum=$stratum\n"); last; } } ---------------------------------------------------------------------- Comment By: Johan Fischer (fischaz) Date: 2005-11-17 17:45 Message: Logged In: YES user_id=459934 The attached patch is wrong. It will override the value of the jitter. Basically the jitter is defined as undef at the begginning, then should be overriden for each server with selected by the regex. It should not be touched otherwise. On the other side, more tests need to be done to see if jitter is defined (and in that case, it will be a numeric) and print it. So it means more test at the end of the script to parse the results. ---------------------------------------------------------------------- Comment By: Charles Bueche (cbueche) Date: 2005-10-27 01:30 Message: Logged In: YES user_id=299377 duplicate with 1267741 ---------------------------------------------------------------------- Comment By: Ade Rixon (aderixon) Date: 2005-10-21 03:12 Message: Logged In: YES user_id=145082 This is still a problem in 1.4.2, can someone review before next release, please? The warning is: Argument "(not parsed)" isn't numeric in abs at ./check_ntp line 401. ...Caused by assigning a string value ('(not parsed)') to $jitter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1251096&group_id=29880 From noreply at sourceforge.net Wed Nov 30 05:20:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 30 05:20:03 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1370031 ] check_disk_smb requires DNS agree with NetBIOS names Message-ID: Bugs item #1370031, was opened at 2005-11-30 08:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1370031&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: John (relph) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk_smb requires DNS agree with NetBIOS names Initial Comment: check_disk_smb fails if the NetBIOS name of the server does not match the IP address for that name. This patch allows the specification of both the IP address of the samba server and the NetBIOS name of the server. This is useful in virtual server environments and is required in our system configuration. In addition, some share names include space (" ") and check_disk_smb couldn't handle it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1370031&group_id=29880 From noreply at sourceforge.net Wed Nov 30 05:22:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 30 05:22:12 2005 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-990948 ] check_disk_smb doesn't allow spaces in share names Message-ID: Bugs item #990948, was opened at 2004-07-14 10:35 Message generated for change (Comment added) made by relph You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=990948&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Paul Dugas (pdugas) Assigned to: Benoit Mortier (opensides) Summary: check_disk_smb doesn't allow spaces in share names Initial Comment: Some SOHO NAS devices (i.e. Linksys NSLU2) don't let you change the share names and have spaces in the defaults. I've hacked the script on my server to simply ignore the check on the share name but a better "fix" is needed. ---------------------------------------------------------------------- Comment By: John (relph) Date: 2005-11-30 08:21 Message: Logged In: YES user_id=1169224 See https://sourceforge.net/tracker/index.php?func=detail&aid=1370031&group_id=29880&atid=397597 ---------------------------------------------------------------------- Comment By: Benoit Mortier (opensides) Date: 2005-01-02 20:55 Message: Logged In: YES user_id=388184 Hi, could you attach a patch for the script here so i can review it. thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=990948&group_id=29880