From holtet at gmail.com Mon Feb 6 17:37:06 2006 From: holtet at gmail.com (Robin Holtet) Date: Mon Feb 6 17:37:06 2006 Subject: [Nagiosplug-devel] freebsd warning Message-ID: <3043222f0602060631s6dcf2b33i299517b84eb53551@mail.gmail.com> Hi, I received this warning while compiling nagios-plugins on freebsd. I am not sure what to do, or if it's relevant, but it says I should report it so I do. If you want any more information, please do ask. robin at s02$ uname -r 5.4-RELEASE robin at s02$ less distinfo MD5 (nagios-plugins-1.4.tar.gz) = 9b21b92acc4b2b0dbb2d12bca6b27582 SIZE (nagios-plugins-1.4.tar.gz) = 972810 checking sys/mount.h presence... yes configure: WARNING: sys/mount.h: present but cannot be compiled configure: WARNING: sys/mount.h: check for missing prerequisite headers? configure: WARNING: sys/mount.h: see the Autoconf documentation configure: WARNING: sys/mount.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mount.h: proceeding with the preprocessor's result configure: WARNING: sys/mount.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------------- ## configure: WARNING: ## Report this to the nagios-plugins lists. ## configure: WARNING: ## ----------------------------------------- ## checking for sys/mount.h... yes Sincerely, Robin Holtet -- Robin Holtet M: 96999903 W: 21677003 H: 21677222 -------------- next part -------------- An HTML attachment was scrubbed... URL: From benny at bennyvision.com Thu Feb 9 11:25:04 2006 From: benny at bennyvision.com (C. Bensend) Date: Thu Feb 9 11:25:04 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? Message-ID: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> Hey folks, So, we've been burned a few times in the past weeks when an unauthorized (accidental) NIS server was brought up on our network. And since it didn't have the correct maps, clients that latched onto it began having problems. Not so much. I checked around nagiosexchange, and didn't find anything. Do any of you happen to have a Nagios check that will alert if any unknown NIS servers answer an NIS broadcast? Man, would I appreciate not having to try to figure that one out. :) Thanks much! Benny -- "'And you've got 10 gig of files to put through our mail system?' I ask, squeezing my mouse in a non-approved manner." -- BOFH, 2006-01 From seanius at seanius.net Sun Feb 12 12:01:04 2006 From: seanius at seanius.net (sean finney) Date: Sun Feb 12 12:01:04 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> Message-ID: <20060212200002.GA32082@seanius.net> hi benny, On Thu, Feb 09, 2006 at 01:24:46PM -0600, C. Bensend wrote: > So, we've been burned a few times in the past weeks when an > unauthorized (accidental) NIS server was brought up on our network. > And since it didn't have the correct maps, clients that latched > onto it began having problems. Not so much. > > I checked around nagiosexchange, and didn't find anything. Do > any of you happen to have a Nagios check that will alert if any > unknown NIS servers answer an NIS broadcast? Man, would I > appreciate not having to try to figure that one out. :) if you could write me a fairly portable chunk of (preferably C) code that sent out a broadcast and returned a list of domains, i'd be happy to throw it in a plugin for you, but i'm not familiar enough with NIS to know off the top of my head an easy way to do that. 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 Feb 12 12:21:02 2006 From: ae at op5.se (Andreas Ericsson) Date: Sun Feb 12 12:21:02 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <20060212200002.GA32082@seanius.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> Message-ID: <43EF9883.8020907@op5.se> sean finney wrote: > hi benny, > > On Thu, Feb 09, 2006 at 01:24:46PM -0600, C. Bensend wrote: > >> So, we've been burned a few times in the past weeks when an >>unauthorized (accidental) NIS server was brought up on our network. >>And since it didn't have the correct maps, clients that latched >>onto it began having problems. Not so much. >> >> I checked around nagiosexchange, and didn't find anything. Do >>any of you happen to have a Nagios check that will alert if any >>unknown NIS servers answer an NIS broadcast? Man, would I >>appreciate not having to try to figure that one out. :) > > > if you could write me a fairly portable chunk of (preferably C) > code that sent out a broadcast and returned a list of domains, > i'd be happy to throw it in a plugin for you, but i'm not familiar > enough with NIS to know off the top of my head an easy way to > do that. > I think that will be fairly difficult. Broadcasting for responses and checking if there is one that shouldn't be there means waiting for ALL servers on the network to respond. This quickly turns unwieldy even for small networks, since most have some IP-addresses empty. Management nightmare, if I ever saw one. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From benny at bennyvision.com Sun Feb 12 14:19:03 2006 From: benny at bennyvision.com (C. Bensend) Date: Sun Feb 12 14:19:03 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <20060212200002.GA32082@seanius.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> Message-ID: <51728.63.227.74.41.1139782723.squirrel@webmail.stinkweasel.net> > if you could write me a fairly portable chunk of (preferably C) > code that sent out a broadcast and returned a list of domains, > i'd be happy to throw it in a plugin for you, but i'm not familiar > enough with NIS to know off the top of my head an easy way to > do that. Hmmm, yeah. Let me assure you, any C that I write from scratch will be the stuff of nightmares, the kind of thing that makes you wake in the middle of the night, screaming in the dark. ;) I used to know C. Haven't touched it in years. I'm trying to relearn it again, but I am very bad at it. -- "'And you've got 10 gig of files to put through our mail system?' I ask, squeezing my mouse in a non-approved manner." -- BOFH, 2006-01 From noreply at sourceforge.net Mon Feb 13 07:18:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 13 07:18:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1430709 ] check_uptime don´t compile error Message-ID: Bugs item #1430709, was opened at 2006-02-13 15:17 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=1430709&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: None Status: Open Resolution: None Priority: 5 Submitted By: Wilson Galafassi (wgalafassijr) Assigned to: Nobody/Anonymous (nobody) Summary: check_uptime don??t compile error Initial Comment: hello. when i try to complite check_uptime.c this error occours: gcc check_uptime.c check_uptime.c:24:20: config.h: No such file or directory check_uptime.c:25:20: common.h: No such file or directory check_uptime.c:26:19: utils.h: No such file or directory check_uptime.c:27:19: popen.h: No such file or directory check_uptime.c: In function `main': check_uptime.c:33: error: `MAX_INPUT_BUFFER' undeclared (first use in this function) check_uptime.c:33: error: (Each undeclared identifier is reported only once check_uptime.c:33: error: for each function it appears in.) check_uptime.c:36: error: `NULL' undeclared (first use in this function) check_uptime.c:52: error: `STATE_UNKNOWN' undeclared (first use in this function) check_uptime.c:55: error: `child_process' undeclared (first use in this function) check_uptime.c:55: error: `PATH_TO_UPTIME' undeclared (first use in this function) check_uptime.c:60: error: `child_stderr' undeclared (first use in this function) check_uptime.c:60: error: `child_stderr_array' undeclared (first use in this function) check_uptime.c:78: warning: assignment makes pointer from integer without a cast check_uptime.c:80: warning: assignment makes pointer from integer without a cast check_uptime.c:98: error: `STATE_OK' undeclared (first use in this function) i??m using fc4 and nagios-plugins-1.4.2. very thanks wilson ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1430709&group_id=29880 From seanius at seanius.net Mon Feb 13 08:36:02 2006 From: seanius at seanius.net (sean finney) Date: Mon Feb 13 08:36:02 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <43EF9883.8020907@op5.se> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> <43EF9883.8020907@op5.se> Message-ID: <20060213163443.GA1674@seanius.net> On Sun, Feb 12, 2006 at 09:20:19PM +0100, Andreas Ericsson wrote: > I think that will be fairly difficult. Broadcasting for responses and > checking if there is one that shouldn't be there means waiting for ALL > servers on the network to respond. This quickly turns unwieldy even for > small networks, since most have some IP-addresses empty. Management > nightmare, if I ever saw one. um, isn't the point of broadcasting such that you don't have to contact the individual addresses? my assumption was that for NIS broadcasting you simply put some noise on the wire, and any masters on the local network segment responded. more to the point, i was thinking a tool like the following might be nice: check_nis -d domain1,domain2 -H host1 <--- check master for serving domain check_nis -d domain1,domain2 -b [addr] <--- same, but broadcast check_nis -d domain1,domain2 -x <--- same, but invert matching sense the last is what the OP was talking about, i guess. unfortunately my NIS/YP/RPC-foo isn't nearly up to the challenge, at least without a couple RTFM pointers. sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From benny at bennyvision.com Mon Feb 13 08:43:03 2006 From: benny at bennyvision.com (C. Bensend) Date: Mon Feb 13 08:43:03 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <20060213163443.GA1674@seanius.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> <43EF9883.8020907@op5.se> <20060213163443.GA1674@seanius.net> Message-ID: <1793.134.244.169.17.1139848920.squirrel@webmail.stinkweasel.net> > contact the individual addresses? my assumption was that for > NIS broadcasting you simply put some noise on the wire, and any > masters on the local network segment responded. As best I understand it, yes, that's the way it works. > more to the point, i was thinking a tool like the following might be > nice: > > check_nis -d domain1,domain2 -H host1 <--- check master for serving > domain > check_nis -d domain1,domain2 -b [addr] <--- same, but broadcast > check_nis -d domain1,domain2 -x <--- same, but invert matching > sense > > the last is what the OP was talking about, i guess. unfortunately my > NIS/YP/RPC-foo isn't nearly up to the challenge, at least without > a couple RTFM pointers. Personally, I need something like: check_nis -d domain1,domain2 -x -s server1,server2 ... that will return a non-OK value if any _more_ servers respond, other than server1 or server2, such as an unintentional or rogue server3 answering the broadcast. I know I can't code it, but I could certainly help test it if someone were to take a shot. :) Benny -- "A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila." -- Dave Pooser From ae at op5.se Mon Feb 13 09:17:05 2006 From: ae at op5.se (Andreas Ericsson) Date: Mon Feb 13 09:17:05 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <1793.134.244.169.17.1139848920.squirrel@webmail.stinkweasel.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> <43EF9883.8020907@op5.se> <20060213163443.GA1674@seanius.net> <1793.134.244.169.17.1139848920.squirrel@webmail.stinkweasel.net> Message-ID: <43F0BF02.6070005@op5.se> C. Bensend wrote: >>contact the individual addresses? my assumption was that for >>NIS broadcasting you simply put some noise on the wire, and any >>masters on the local network segment responded. > > > As best I understand it, yes, that's the way it works. > > >>more to the point, i was thinking a tool like the following might be >>nice: >> >>check_nis -d domain1,domain2 -H host1 <--- check master for serving >>domain >>check_nis -d domain1,domain2 -b [addr] <--- same, but broadcast >>check_nis -d domain1,domain2 -x <--- same, but invert matching >>sense >> >>the last is what the OP was talking about, i guess. unfortunately my >>NIS/YP/RPC-foo isn't nearly up to the challenge, at least without >>a couple RTFM pointers. > > > Personally, I need something like: > > check_nis -d domain1,domain2 -x -s server1,server2 > > ... that will return a non-OK value if any _more_ servers respond, And this is where the trouble lies. How long should we wait for any other server to respond, and how many broadcasts should we send? > other than server1 or server2, such as an unintentional or rogue > server3 answering the broadcast. > > I know I can't code it, but I could certainly help test it if > someone were to take a shot. :) > A much better way is to set up a daemon which listens to broadcasts and shouts out loud if it hears one from the wrong server. You still have to implement the NIS protocol (partially) but you can get rid of the problem of having plugins run with elevated privileges and determining how long to wait. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From per-arne.wallstrom at enlight.net Mon Feb 13 10:06:00 2006 From: per-arne.wallstrom at enlight.net (Per-Arne Wallstroem) Date: Mon Feb 13 10:06:00 2006 Subject: [Nagiosplug-devel] check_http plugin feature Message-ID: <1139853898.15611.16.camel@localhost> Hi List, We are using the check_http plugin to check our webapps. We use the regex feature of check_http but needed a way to match more than a single regex on a page, and also the ability to match for words that we do not expect to be present (certain error messages). The check_http of 1.4.2 plugins (which we are currently using) did not allow us to do this, and supported only one single regex match. We did not want to create yet another http plugin, so so we made a patch for it. The patch can be found below. It introduces 2 command options: -j, --invert-match Invert the sense of next regex (must precede -r or -R) -r, --regex, --ereg=STRING Can be present more than once on a command line. I'm not a programmer, so maybe the code could be written more elegant... Enjoy, -- Kind regards / Med v?nliga h?lsningar, Per-Arne Wallstr?m ____________________________________________________ Per-Arne Wallstr?m System Administrator Enlight AB Direct +46 (0)90 71 71 26 Fax +090 71 71 99 Mobile +46 (0)70 609 0559 Hagaplan 1, 903 36 Ume?, Sweden enlight.net ____________________________________________________ Assuring Knowledge --- plugins/check_http.orig 2006-02-13 16:13:30.344818411 +0100 +++ plugins/check_http.c 2006-02-13 18:12:52.357068769 +0100 @@ -73,10 +73,15 @@ #ifdef HAVE_REGEX_H enum { REGS = 2, - MAX_RE_SIZE = 256 + MAX_RE_SIZE = 256, + MAX_RE_PREGS = 256 }; #include -regex_t preg; +int num_preg = 0; +int num_match = 0; +int re_invert_reg = 0; +int re_invert[MAX_RE_PREGS]; +regex_t preg[MAX_RE_PREGS]; regmatch_t pmatch[REGS]; char regexp[MAX_RE_SIZE]; char errbuf[MAX_INPUT_BUFFER]; @@ -215,6 +220,7 @@ {"regex", required_argument, 0, 'r'}, {"ereg", required_argument, 0, 'r'}, {"eregi", required_argument, 0, 'R'}, + {"invert-match", no_argument, 0, 'j'}, {"linespan", no_argument, 0, 'l'}, {"onredirect", required_argument, 0, 'f'}, {"certificate", required_argument, 0, 'C'}, @@ -246,7 +252,7 @@ } while (1) { - c = getopt_long (argc, argv, "Vvh46t:c:w:A:k:H:P:T:I:a:e:p:s:R:r:u:f:C:nlLSm:M:N", longopts, &option); + c = getopt_long (argc, argv, "Vvh46t:c:w:A:k:H:P:T:I:a:e:p:s:R:r:u:f:C:nlLSm:M:Nj", longopts, &option); if (c == -1 || c == EOF) break; @@ -382,18 +388,33 @@ case 'l': /* linespan */ cflags &= ~REG_NEWLINE; break; + case 'j': /* invert next regex */ + if (num_preg < MAX_RE_PREGS) { + re_invert_reg = 1; + } + break; case 'R': /* regex */ cflags |= REG_ICASE; case 'r': /* regex */ - strncpy (regexp, optarg, MAX_RE_SIZE - 1); - regexp[MAX_RE_SIZE - 1] = 0; - errcode = regcomp (&preg, regexp, cflags); - if (errcode != 0) { - (void) regerror (errcode, &preg, errbuf, MAX_INPUT_BUFFER); - printf (_("Could Not Compile Regular Expression: %s"), errbuf); - return ERROR; + if (num_preg < MAX_RE_PREGS) { + strncpy (regexp, optarg, MAX_RE_SIZE - 1); + regexp[MAX_RE_SIZE - 1] = 0; + errcode = regcomp (&preg[num_preg], regexp, cflags); + if (errcode != 0) { + (void) regerror (errcode, &preg[num_preg], errbuf, MAX_INPUT_BUFFER); + printf (_("Could Not Compile Regular Expression: %s"), errbuf); + return ERROR; + } + /* Should the result be inverted? */ + re_invert[num_preg] = re_invert_reg; + re_invert_reg = 0; + num_preg++; + break; + } + else { + usage4(_("Too many regular expressions")); + break; } - break; #endif case '4': address_family = AF_INET; @@ -781,6 +802,7 @@ char *auth; int http_status; int i = 0; + int match = 1; size_t pagesize = 0; char *full_page; char *buf; @@ -1048,27 +1070,59 @@ } } #ifdef HAVE_REGEX_H - if (strlen (regexp)) { - errcode = regexec (&preg, page, REGS, pmatch, 0); - if (errcode == 0) { + if (num_preg) { + for (i = 0; i < num_preg; i++) { + errcode = regexec (&preg[i], page, REGS, pmatch, 0); + + switch (errcode) { + case 0: + match = 1; + break; + case REG_NOMATCH: + match = 0; + break; + default: + regerror (errcode, &preg[i], errbuf, MAX_INPUT_BUFFER); + printf (_("CRITICAL - Execute Error: %s\n"), errbuf); + exit (STATE_CRITICAL); + break; + } + + if (re_invert[i] == 0) { + if (match) { + num_match++; + } + else { + printf (_("CRITICAL - pattern not found%s|%s %s\n"), + (display_html ? "" : ""), + perfd_time (elapsed_time), perfd_size (pagesize)); + exit (STATE_CRITICAL); + } + } + else { /* Inverted match. */ + if (match) { + printf (_("CRITICAL - pattern found%s|%s %s\n"), + (display_html ? "" : ""), + perfd_time (elapsed_time), perfd_size (pagesize)); + exit (STATE_CRITICAL); + } + else { + num_match++; + } + } + } + + if (num_preg == num_match) { printf (_("HTTP OK %s - %.3f second response time %s%s|%s %s\n"), status_line, elapsed_time, - timestamp, (display_html ? "" : ""), + timestamp, (display_html ? "" : ""), perfd_time (elapsed_time), perfd_size (pagesize)); exit (STATE_OK); } else { - if (errcode == REG_NOMATCH) { - printf (_("CRITICAL - pattern not found%s|%s %s\n"), - (display_html ? "" : ""), - perfd_time (elapsed_time), perfd_size (pagesize)); - exit (STATE_CRITICAL); - } - else { - regerror (errcode, &preg, errbuf, MAX_INPUT_BUFFER); - printf (_("CRITICAL - Execute Error: %s\n"), errbuf); - exit (STATE_CRITICAL); - } + /* Should not happen */ + printf(("CRITICAL - not all patterns were checked\n")); + exit(STATE_CRITICAL); } } #endif @@ -1497,6 +1551,8 @@ #ifdef HAVE_REGEX_H printf (_("\ + -j, --invert-match\n\ + Invert the sense of next regex (must precede -r or -R)\n\ -l, --linespan\n\ Allow regex to span newlines (must precede -r or -R)\n\ -r, --regex, --ereg=STRING\n\ @@ -1566,7 +1622,7 @@ Usage: %s -H | -I [-u ] [-p ]\n\ [-w ] [-c ] [-t ] [-L]\n\ [-a auth] [-f ] [-e ]\n\ - [-s string] [-l] [-r | -R ]\n\ + [-s string] [-l] [-j] [-r | -R ]\n\ [-P string] [-m :] [-4|-6] [-N] \n\ [-M ] [-A string] [-k string]\n", progname); } From benny at bennyvision.com Mon Feb 13 10:54:07 2006 From: benny at bennyvision.com (C. Bensend) Date: Mon Feb 13 10:54:07 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <43F0BF02.6070005@op5.se> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> <43EF9883.8020907@op5.se> <20060213163443.GA1674@seanius.net> <1793.134.244.169.17.1139848920.squirrel@webmail.stinkweasel.net> <43F0BF02.6070005@op5.se> Message-ID: <2065.134.244.169.17.1139856815.squirrel@webmail.stinkweasel.net> > And this is where the trouble lies. How long should we wait for any > other server to respond, and how many broadcasts should we send? Yes, I think _I_ would make these configurable parameters. On my network, I wouldn't have to wait that long. On other networks, NIS servers might be overwhelmed, or other factors, that would necessitate a different timeout and number-of-broadcasts values. > A much better way is to set up a daemon which listens to broadcasts and > shouts out loud if it hears one from the wrong server. You still have to > implement the NIS protocol (partially) but you can get rid of the > problem of having plugins run with elevated privileges and determining > how long to wait. Well, the _clients_ broadcast, but I don't think the servers do? Hmmmm, elevated privs - do you need root privs to broadcast? I've never touched that sort of thing myself. Benny -- "A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila." -- Dave Pooser From ae at op5.se Mon Feb 13 11:56:07 2006 From: ae at op5.se (Andreas Ericsson) Date: Mon Feb 13 11:56:07 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <2065.134.244.169.17.1139856815.squirrel@webmail.stinkweasel.net> References: <3727.134.244.169.17.1139513086.squirrel@webmail.stinkweasel.net> <20060212200002.GA32082@seanius.net> <43EF9883.8020907@op5.se> <20060213163443.GA1674@seanius.net> <1793.134.244.169.17.1139848920.squirrel@webmail.stinkweasel.net> <43F0BF02.6070005@op5.se> <2065.134.244.169.17.1139856815.squirrel@webmail.stinkweasel.net> Message-ID: <43F0E442.4090402@op5.se> C. Bensend wrote: >>And this is where the trouble lies. How long should we wait for any >>other server to respond, and how many broadcasts should we send? > > > Yes, I think _I_ would make these configurable parameters. Naturally. It could still mean you're getting invalid results if the network is bogged though, and since that would be a false negative (mostly everything else would return false positives in a too-highly loaded network), you wouldn't know if it happened. > On my > network, I wouldn't have to wait that long. On other networks, > NIS servers might be overwhelmed, or other factors, that would > necessitate a different timeout and number-of-broadcasts values. > > >>A much better way is to set up a daemon which listens to broadcasts and >>shouts out loud if it hears one from the wrong server. You still have to >>implement the NIS protocol (partially) but you can get rid of the >>problem of having plugins run with elevated privileges and determining >>how long to wait. > > > Well, the _clients_ broadcast, but I don't think the servers > do? > Ah. My bad. I'd still implement this as a daemon though, possibly with unicast packets forwarded to a single host from the switch. That way you'd see both queries and responses. > Hmmmm, elevated privs - do you need root privs to broadcast? I've > never touched that sort of thing myself. > Not necessarily, but unless you're broadcasting ICMP requests on a patched Linux kernel I think you'll need a raw socket to see the replies. -- 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 Mon Feb 13 12:00:06 2006 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Mon Feb 13 12:00:06 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: Your message of "Mon, 13 Feb 2006 18:16:50 +0100." <43F0BF02.6070005@op5.se> Message-ID: <200602131959.k1DJxeoQ020192@mx1.cs.umb.edu> In message <43F0BF02.6070005 at op5.se>, Andreas Ericsson writes: >C. Bensend wrote: > [some other attributions lost in response] >>>contact the individual addresses? my assumption was that for >>>NIS broadcasting you simply put some noise on the wire, and any >>>masters on the local network segment responded. >> Personally, I need something like: >> >> check_nis -d domain1,domain2 -x -s server1,server2 >> >> ... that will return a non-OK value if any _more_ servers respond, > >And this is where the trouble lies. How long should we wait for any >other server to respond, and how many broadcasts should we send? > >> other than server1 or server2, such as an unintentional or rogue >> server3 answering the broadcast. >> >> I know I can't code it, but I could certainly help test it if >> someone were to take a shot. :) >A much better way is to set up a daemon which listens to broadcasts and >shouts out loud if it hears one from the wrong server. IIRC the client broadcasts for the server. The server replies using the client's IP address. So it's not a broadcast response but a niswatch (doesn't look like google knows of a niswatch that does this) type daemon (sort of like arpwatch) would work if you have a port on your switches than can be used to monitor all traffic looking for the response. You can probably cobble something together from tcpdump and nagios passive service results. >You still have to >implement the NIS protocol (partially) but you can get rid of the >problem of having plugins run with elevated privileges and determining >how long to wait. Well you can use regular network NIS traffic as your probe and just look for incorrect responses. -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From drw at adnc.com Mon Feb 13 22:23:02 2006 From: drw at adnc.com (Dan Wilson) Date: Mon Feb 13 22:23:02 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <200602131959.k1DJxeoQ020192@mx1.cs.umb.edu> References: <200602131959.k1DJxeoQ020192@mx1.cs.umb.edu> Message-ID: <43F1771A.80506@adnc.com> What about using it's mac address to quarantine it? We've done something similar in the past for virus/worm infected machines. Basically we used tcpdump to capture find what we were looking for and that output was processed by a perl script. When a computer was found it's IP address was written to a file. Every minute that file would be read and a tool to spoof the mac address was put into action. Once running, it caught nearly all that offending machines in the first 5-10 minutes... and continued to catch machines as they were turned on. An email alert would then be sent to the admin who could then take his time quarantining and fixing the machines. In the end we found more than 70 of our 300+ machines had been infected with a worm... The network was unusable until we tried the above. In fact when we setup it up and started it the techs though they had fixed the problem when they patched and restarted a computer.... the network just happened to be usable again after they finished. Boy were they dissapointed to find out that they still had to patch all the rest of the computers ;-) John P. Rouillard wrote: > In message <43F0BF02.6070005 at op5.se>, Andreas Ericsson writes: > >> C. Bensend wrote: >> [some other attributions lost in response] >> >>>> contact the individual addresses? my assumption was that for >>>> NIS broadcasting you simply put some noise on the wire, and any >>>> masters on the local network segment responded. >>>> >>> Personally, I need something like: >>> >>> check_nis -d domain1,domain2 -x -s server1,server2 >>> >>> ... that will return a non-OK value if any _more_ servers respond, >>> >> And this is where the trouble lies. How long should we wait for any >> other server to respond, and how many broadcasts should we send? >> >> >>> other than server1 or server2, such as an unintentional or rogue >>> server3 answering the broadcast. >>> >>> I know I can't code it, but I could certainly help test it if >>> someone were to take a shot. :) >>> >> A much better way is to set up a daemon which listens to broadcasts and >> shouts out loud if it hears one from the wrong server. >> > > IIRC the client broadcasts for the server. The server replies using > the client's IP address. So it's not a broadcast response but a > niswatch (doesn't look like google knows of a niswatch that does this) > type daemon (sort of like arpwatch) would work if you have a port on > your switches than can be used to monitor all traffic looking for the > response. > > You can probably cobble something together from tcpdump and nagios > passive service results. > > >> You still have to >> implement the NIS protocol (partially) but you can get rid of the >> problem of having plugins run with elevated privileges and determining >> how long to wait. >> > > Well you can use regular network NIS traffic as your probe and just > look for incorrect responses. > > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benny at bennyvision.com Mon Feb 13 22:34:01 2006 From: benny at bennyvision.com (C. Bensend) Date: Mon Feb 13 22:34:01 2006 Subject: [Nagiosplug-devel] Checking for unknown NIS servers? In-Reply-To: <43F1771A.80506@adnc.com> References: <200602131959.k1DJxeoQ020192@mx1.cs.umb.edu> <43F1771A.80506@adnc.com> Message-ID: <64021.63.227.74.41.1139898778.squirrel@webmail.stinkweasel.net> > What about using it's mac address to quarantine it? > > > We've done something similar in the past for virus/worm infected > machines. Basically we used tcpdump to capture find what we were > looking for and that output was processed by a perl script. When a > computer was found it's IP address was written to a file. Every minute > that file would be read and a tool to spoof the mac address was put into > action. Once running, it caught nearly all that offending machines in > the first 5-10 minutes... and continued to catch machines as they were > turned on. That would probably work well for worms and viruses, but an NIS server doesn't broadcast anything, nor does it scan IPs. It simply responds to a broadcast. Hence, unless you send a broadcast from the Nagios server and use tcpdump to watch for replies, I don't think this is viable for my situation. I really don't think this is a hard problem to solve... The plugin would simply act as an NIS client, send an NIS broadcast, collect the replies, and compare them against the list of "good" NIS servers. That's it, in a nutshell. Yes, there are a few other details like timeouts and number of broadcasts, but the basic functionality doesn't seem too complex. I simply can't code well enough to do it. :) But, I'll poke at it, and see what if I can come up with anything useful. Benny -- "A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila." -- Dave Pooser From wolvverine at tarchomin.pl Wed Feb 15 03:25:02 2006 From: wolvverine at tarchomin.pl (=?iso-8859-2?Q?Micha=B3?= Panasiewicz) Date: Wed Feb 15 03:25:02 2006 Subject: [Nagiosplug-devel] bug?? check_procs (nagios-plugins 1.4.2) 1.46 - 0 processes Message-ID: <1140002635.17017.30.camel@localhost> [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd PROCS OK: 0 processes with command name 'smbd' [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd -vvv | grep smbd SNs 0 1 9972 3488 0.0 smbd smbd -D 0 0 9972 3488 0 1 0,00 SNs .0 smbd smbd -D SN 0 9361 10128 3684 0.0 smbd smbd -D 0 0 10128 3684 0 9361 0,00 SN .0 smbd smbd -D SN 1019 9361 11152 5436 0.4 smbd smbd -D 0 1019 11152 5436 0 9361 0,00 SN .4 smbd smbd -D SN 99 9361 10704 4872 0.0 smbd smbd -D 0 99 10704 4872 0 9361 0,00 SN .0 smbd smbd -D RN 1001 9361 11620 5696 1.1 smbd smbd -D 0 1001 11620 5696 0 9361 1,00 RN .1 smbd smbd -D SN 1002 9361 10864 4784 17.3 smbd smbd -D 0 1002 10864 4784 0 9361 17,00 SN .3 smbd smbd -D SN 0 9361 10560 4200 0.1 smbd smbd -D 0 0 10560 4200 0 9361 0,00 SN .1 smbd smbd -D S+ 0 1984 1756 640 0.0 check_procs /usr/lib/nagios/plugins/check_procs -C smbd -vvv 0 0 1756 640 0 1984 0,00 S+ .0 check_procs /usr/lib/nagios/plugins/check_procs -C smbd -vvv S+ 0 1984 1824 600 0.0 grep grep smbd 0 0 1824 600 0 1984 0,00 S+ .0 grep grep smbd PROCS OK: 0 processes with command name 'smbd' [root at kuf-serwer ~]# ps ax | grep smbd 9361 ? SNs 0:00 smbd -D 9368 ? SN 0:02 smbd -D 7450 ? SN 0:42 smbd -D 13219 ? SN 0:04 smbd -D 3912 ? SN 0:46 smbd -D 734 ? RN 0:37 smbd -D 2543 ? SN 0:00 smbd -D 2969 pts/0 R+ 0:00 grep smbd [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd -vv CMD: /bin/ps axwo 'stat uid ppid vsz rss pcpu comm args' PROCS OK: 0 processes with command name 'smbd' -- Micha? Panasiewicz jabber: wolvverine [ at ] chrome [ dot ] pl e-mail: wolvverine [ at ] tlen [ dot ] pl , wolvverine [ at ] pld-linux [ dot ] org Potrzebujesz Informatyka/Administratora (Warszawa) -skontaktuj sie ze mn? From ae at op5.se Wed Feb 15 03:42:08 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 15 03:42:08 2006 Subject: [Nagiosplug-devel] bug?? check_procs (nagios-plugins 1.4.2) 1.46 - 0 processes In-Reply-To: <1140002635.17017.30.camel@localhost> References: <1140002635.17017.30.camel@localhost> Message-ID: <43F31360.3050301@op5.se> Micha? Panasiewicz wrote: > [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd > PROCS OK: 0 processes with command name 'smbd' > [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd -vvv | > grep smbd > SNs 0 1 9972 3488 0.0 smbd smbd -D > 0 0 9972 3488 0 1 0,00 SNs .0 smbd smbd -D > SN 0 9361 10128 3684 0.0 smbd smbd -D > 0 0 10128 3684 0 9361 0,00 SN .0 smbd smbd -D > SN 1019 9361 11152 5436 0.4 smbd smbd -D > 0 1019 11152 5436 0 9361 0,00 SN .4 smbd smbd -D > SN 99 9361 10704 4872 0.0 smbd smbd -D > 0 99 10704 4872 0 9361 0,00 SN .0 smbd smbd -D > RN 1001 9361 11620 5696 1.1 smbd smbd -D > 0 1001 11620 5696 0 9361 1,00 RN .1 smbd smbd -D > SN 1002 9361 10864 4784 17.3 smbd smbd -D > 0 1002 10864 4784 0 9361 17,00 SN .3 smbd smbd -D > SN 0 9361 10560 4200 0.1 smbd smbd -D > 0 0 10560 4200 0 9361 0,00 SN .1 smbd smbd -D > S+ 0 1984 1756 640 0.0 > check_procs /usr/lib/nagios/plugins/check_procs -C smbd -vvv > 0 0 1756 640 0 1984 0,00 S+ .0 > check_procs /usr/lib/nagios/plugins/check_procs -C smbd -vvv > S+ 0 1984 1824 600 0.0 grep grep smbd > 0 0 1824 600 0 1984 0,00 S+ .0 grep grep smbd > PROCS OK: 0 processes with command name 'smbd' > [root at kuf-serwer ~]# ps ax | grep smbd > 9361 ? SNs 0:00 smbd -D > 9368 ? SN 0:02 smbd -D > 7450 ? SN 0:42 smbd -D > 13219 ? SN 0:04 smbd -D > 3912 ? SN 0:46 smbd -D > 734 ? RN 0:37 smbd -D > 2543 ? SN 0:00 smbd -D > 2969 pts/0 R+ 0:00 grep smbd > [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd -vv > CMD: /bin/ps axwo 'stat uid ppid vsz rss pcpu comm args' > PROCS OK: 0 processes with command name 'smbd' > You've been hacked, and pretty thoroughly, if clumsily, I'd say. First of all, pull the network cable. Installing local firewall rules probably won't do. Then install new 'find' and 'netstat' utilities on your system. Preferrably tools that have been pre-compiled on a different, trusted, system. Do *not* use a package management tool to install it. Then do (as root) # netstat -tpan | grep smbd # find / -type f -name "smbd -D" The good thing is that the "smbd -D" ssh daemon comes with a lot of root-kits, so you're most likely being attacked by script-kids (otherwise you probably wouldn't see the daemon with ps). The bad thing is that most of those root-kits have been written by very competent people, so you'll most likely have to re-install the entire system from the ground up. While you're at it, make sure you upgrade as well, and do a readonly chroot jail setup for networking daemons. That way you shouldn't have to worry about these things later on. To summarize, check_procs is actually quite right. The process name is 'smbd -D' (not smbd), and it is in fact an ssh daemon hacked to always allow a certain key to authenticate and spawn a root-shell. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From wolvverine at tarchomin.pl Wed Feb 15 04:42:02 2006 From: wolvverine at tarchomin.pl (=?iso-8859-2?Q?Micha=B3?= Panasiewicz) Date: Wed Feb 15 04:42:02 2006 Subject: [Nagiosplug-devel] bug?? check_procs (nagios-plugins 1.4.2) 1.46 - 0 processes In-Reply-To: <43F31360.3050301@op5.se> References: <1140002635.17017.30.camel@localhost> <43F31360.3050301@op5.se> Message-ID: <1140007276.17017.51.camel@localhost> Dnia 15-02-2006, ?ro o godzinie 12:41 +0100, Andreas Ericsson napisa?(a): > Micha? Panasiewicz wrote: > > [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd > > PROCS OK: 0 processes with command name 'smbd' > > [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C smbd -vvv | > > grep smbd > > SNs 0 1 9972 3488 0.0 smbd smbd -D > > 0 0 9972 3488 0 1 0,00 SNs .0 smbd smbd -D > > SN 0 9361 10128 3684 0.0 smbd smbd -D > > 0 0 10128 3684 0 9361 0,00 SN .0 smbd smbd -D > > SN 1019 9361 11152 5436 0.4 smbd smbd -D > > 0 1019 11152 5436 0 9361 0,00 SN .4 smbd smbd -D > > SN 99 9361 10704 4872 0.0 smbd smbd -D > > 0 99 10704 4872 0 9361 0,00 SN .0 smbd smbd -D > > You've been hacked, and pretty thoroughly, if clumsily, I'd say. First > of all, pull the network cable. Installing local firewall rules probably > won't do. Then install new 'find' and 'netstat' utilities on your > system. Preferrably tools that have been pre-compiled on a different, > trusted, system. Do *not* use a package management tool to install it. > Then do (as root) > > # netstat -tpan | grep smbd > # find / -type f -name "smbd -D" > > The good thing is that the "smbd -D" ssh daemon comes with a lot of > root-kits, so you're most likely being attacked by script-kids System is OK (PLD linux distribution www.pld-linux.org) -D is argument smbd is command [root at kuf-serwer ~]# smbd --help Usage: smbd [OPTION...] -D, --daemon Become a daemon (default) [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C "smbd -D" PROCS OK: 0 processes with command name 'smbd -D' [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -a "smbd -D" PROCS OK: 8 processes with args 'smbd -D' [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -a "smbd" PROCS OK: 8 processes with args 'smbd' [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C "smbd" PROCS OK: 0 processes with command name 'smbd' [root at kuf-serwer ~]# [root at kuf-serwer ~]# netstat --version net-tools 1.60 netstat 1.42 (2001-04-15) [root at kuf-serwer ~]# find --version GNU find wersja 4.2.25 [root at kuf-serwer ~]# /bin/ps axwo 'stat uid ppid vsz rss pcpu comm args' | grep smbd SNs 0 1 9972 3488 0.0 smbd smbd -D SN 0 9361 10128 3708 0.0 smbd smbd -D SN 1019 9361 11152 5436 0.4 smbd smbd -D SN 99 9361 10704 4884 0.0 smbd smbd -D RN 1001 9361 12620 6628 0.7 smbd smbd -D SN 1002 9361 10928 4824 1.2 smbd smbd -D SN 0 9361 10648 4580 0.1 smbd smbd -D SN 0 9361 10556 4192 0.1 smbd smbd -D R+ 0 6457 1788 556 0.0 grep grep smbd smbd is only example, for all commands is 0: [root at kuf-serwer ~]# /bin/ps axwo 'stat uid ppid vsz rss pcpu comm args' | grep httpd.prefork SNs 0 1 28376 11000 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 28780 11668 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 32212 15228 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 32456 15372 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 32216 15208 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 28644 11544 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 28768 11684 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf SN 51 16289 32852 15676 0.0 httpd.prefork httpd.prefork -f /etc/httpd/apache.conf R+ 0 6457 1824 600 0.0 grep grep httpd.prefork [root at kuf-serwer ~]# /usr/lib/nagios/plugins/check_procs -C httpd.prefork PROCS OK: 0 processes with command name 'httpd.prefork' -- Micha? Panasiewicz jabber: wolvverine [ at ] chrome [ dot ] pl e-mail: wolvverine [ at ] tlen [ dot ] pl , wolvverine [ at ] pld-linux [ dot ] org Potrzebujesz Informatyka/Administratora (Warszawa) -skontaktuj sie ze mn? From noreply at sourceforge.net Thu Feb 16 12:01:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 16 12:01:02 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1433114 ] check_procs does not work with german locale Message-ID: Bugs item #1433114, was opened at 2006-02-16 20:00 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=1433114&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: None Status: Open Resolution: None Priority: 5 Submitted By: Hadmut Danisch (hadmut) Assigned to: Nobody/Anonymous (nobody) Summary: check_procs does not work with german locale Initial Comment: Hi, check_procs does not work properly if used in Germany. Reason: In Germany/Europe floating numbers are written with a decimal comma instead of a decimal point. When you set LC_NUMERIC to something like de_DE, the function sscanf expects a decimal comma, not a decimal point. check_procs calls /bin/ps axwo 'stat uid pid ppid vsz rss pcpu comm args' and then parses the output. That's where trouble begins. The %CPU is written as 0.0, but sscanf now expects a comma. It therefore scans only "0", and leaves ".0" for the next argument, thus shifting all subsequent arguments one to the right. check_procs -C something therefore does not work anymore. regards Hadmut ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433114&group_id=29880 From noreply at sourceforge.net Thu Feb 16 13:28:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 16 13:28:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1433179 ] check_jabber (check_tcp) does not honor --mismatch Message-ID: Bugs item #1433179, was opened at 2006-02-16 14:27 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=1433179&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: Open Resolution: None Priority: 5 Submitted By: BuckNaked (mnk26) Assigned to: Nobody/Anonymous (nobody) Summary: check_jabber (check_tcp) does not honor --mismatch Initial Comment: expect_mismatch_state is set but is never used anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1433179&group_id=29880 From hadmut at danisch.de Fri Feb 17 00:44:01 2006 From: hadmut at danisch.de (Hadmut Danisch) Date: Fri Feb 17 00:44:01 2006 Subject: [Nagiosplug-devel] check_procs and Linux? Message-ID: <20060216122324.GA336@danisch.de> Hi, I'm trying # /usr/lib/nagios/plugins/check_procs -c 2:10 -C tcsh PROCS CRITICAL: 0 processes with command name 'tcsh' although there are plenty of tcsh processes (tcsh used for testing, same problem occurs with all other processes. ps: % /bin/ps axwo "stat uid pid ppid vsz rss pcpu comm args" | egrep '(STAT|tcsh)' STAT UID PID PPID VSZ RSS %CPU COMMAND COMMAND S 1000 4968 4853 7644 2860 0.0 xterm xterm -sb -title tcsh -geometry 90x38+0+120 Ss 1000 4981 4968 5972 2188 0.0 tcsh -csh Ss+ 1000 4982 4967 5972 2128 0.0 tcsh -csh Ss 1000 5808 5807 6492 2672 0.0 tcsh -csh Ss 1000 5810 5809 6024 2196 0.0 tcsh -csh Is it possible that check_procs has a problem with parsing the output of ps? regards Hadmut From noreply at sourceforge.net Fri Feb 17 01:38:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 17 01:38:04 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1433447 ] Typo in check_by_ssh Message-ID: Patches item #1433447, was opened at 2006-02-17 09:37 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=1433447&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: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in check_by_ssh Initial Comment: --- check_by_ssh.c-orig 2006-02-17 10:30:56.551425340 +0100 +++ check_by_ssh.c 2006-02-17 10:31:53.794663253 +0100 @@ -383,7 +383,7 @@ passphrase and the public key should be listed in the authorized_keys\n\ file of the remote host. Usually the key will be restricted to running\n\ only one command on the remote server. If the remote SSH server tracks\n\ -invocation agruments, the one remote program may be an agent that can\n\ +invocation arguments, the one remote program may be an agent that can\n\ execute additional commands as proxy\n")); printf (_("\n\ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1433447&group_id=29880 From wolvverine at tarchomin.pl Sat Feb 18 11:06:04 2006 From: wolvverine at tarchomin.pl (=?iso-8859-2?Q?Micha=B3?= Panasiewicz) Date: Sat Feb 18 11:06:04 2006 Subject: [Nagiosplug-devel] check_procs and Linux? In-Reply-To: <20060216122324.GA336@danisch.de> References: <20060216122324.GA336@danisch.de> Message-ID: <1140289518.13526.0.camel@localhost> Dnia 16-02-2006, czw o godzinie 13:23 +0100, Hadmut Danisch napisa?(a): > Hi, > > I'm trying > > # /usr/lib/nagios/plugins/check_procs -c 2:10 -C tcsh > PROCS CRITICAL: 0 processes with command name 'tcsh' > > > although there are plenty of tcsh processes (tcsh used for testing, > same problem occurs with all other processes. > > > > ps: > > % /bin/ps axwo "stat uid pid ppid vsz rss pcpu comm args" | egrep '(STAT|tcsh)' > STAT UID PID PPID VSZ RSS %CPU COMMAND COMMAND > S 1000 4968 4853 7644 2860 0.0 xterm xterm -sb -title tcsh -geometry 90x38+0+120 > Ss 1000 4981 4968 5972 2188 0.0 tcsh -csh > Ss+ 1000 4982 4967 5972 2128 0.0 tcsh -csh > Ss 1000 5808 5807 6492 2672 0.0 tcsh -csh > Ss 1000 5810 5809 6024 2196 0.0 tcsh -csh > > > > Is it possible that check_procs has a problem with parsing the output > of ps? > maybe better use libproc, not ps in check_procs?? -- Micha? Panasiewicz jabber: wolvverine [ at ] chrome [ dot ] pl e-mail: wolvverine [ at ] tlen [ dot ] pl , wolvverine [ at ] pld-linux [ dot ] org Potrzebujesz Informatyka/Administratora (Warszawa) -skontaktuj sie ze mn? From wolvverine at tarchomin.pl Sat Feb 18 11:44:02 2006 From: wolvverine at tarchomin.pl (=?iso-8859-2?Q?Micha=B3?= Panasiewicz) Date: Sat Feb 18 11:44:02 2006 Subject: [Nagiosplug-devel] check_procs and Linux? In-Reply-To: <1140289518.13526.0.camel@localhost> References: <20060216122324.GA336@danisch.de> <1140289518.13526.0.camel@localhost> Message-ID: <1140291792.13838.2.camel@localhost> Dnia 18-02-2006, sob o godzinie 20:05 +0100, Micha? Panasiewicz napisa?(a): > Dnia 16-02-2006, czw o godzinie 13:23 +0100, Hadmut Danisch napisa?(a): > > Hi, > > > > I'm trying > > > > # /usr/lib/nagios/plugins/check_procs -c 2:10 -C tcsh > > PROCS CRITICAL: 0 processes with command name 'tcsh' > > > > > > although there are plenty of tcsh processes (tcsh used for testing, > > same problem occurs with all other processes. > > > > > > > > ps: > > > > % /bin/ps axwo "stat uid pid ppid vsz rss pcpu comm args" | egrep '(STAT|tcsh)' > > STAT UID PID PPID VSZ RSS %CPU COMMAND COMMAND > > S 1000 4968 4853 7644 2860 0.0 xterm xterm -sb -title tcsh -geometry 90x38+0+120 > > Ss 1000 4981 4968 5972 2188 0.0 tcsh -csh > > Ss+ 1000 4982 4967 5972 2128 0.0 tcsh -csh > > Ss 1000 5808 5807 6492 2672 0.0 tcsh -csh > > Ss 1000 5810 5809 6024 2196 0.0 tcsh -csh > > > > > > > > Is it possible that check_procs has a problem with parsing the output > > of ps? > > > > maybe better use libproc, not ps in check_procs?? > ~$echo $LC_ALL $LANG pl_PL pl_PL ~$/usr/lib/nagios/plugins/check_procs -C smbd PROCS OK: 0 processes with command name 'smbd' ~$LC_ALL=C LANG=C /usr/lib/nagios/plugins/check_procs -C smbd PROCS OK: 2 processes with command name 'smbd -- Micha? Panasiewicz jabber: wolvverine [ at ] chrome [ dot ] pl e-mail: wolvverine [ at ] tlen [ dot ] pl , wolvverine [ at ] pld-linux [ dot ] org Potrzebujesz Informatyka/Administratora (Warszawa) -skontaktuj sie ze mn? From seanius at seanius.net Sun Feb 19 02:02:12 2006 From: seanius at seanius.net (sean finney) Date: Sun Feb 19 02:02:12 2006 Subject: [Nagiosplug-devel] check_procs and Linux? In-Reply-To: <1140291792.13838.2.camel@localhost> References: <20060216122324.GA336@danisch.de> <1140289518.13526.0.camel@localhost> <1140291792.13838.2.camel@localhost> Message-ID: <20060219100143.GA18899@seanius.net> hi micha? and hadmut, On Sat, Feb 18, 2006 at 08:43:11PM +0100, Micha? Panasiewicz wrote: > ~$echo $LC_ALL $LANG > pl_PL pl_PL > ~$/usr/lib/nagios/plugins/check_procs -C smbd > PROCS OK: 0 processes with command name 'smbd' > ~$LC_ALL=C LANG=C /usr/lib/nagios/plugins/check_procs -C smbd > PROCS OK: 2 processes with command name 'smbd i can confirm that in 1.4.2 check_procs was missing a call to setlocale, as is done in some of the other output-parsing programs. please test the latest version in cvs (committed a few days back) as i believe it should fix this 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 laughlin at rv-revelle.ucsd.edu Sun Feb 19 12:30:08 2006 From: laughlin at rv-revelle.ucsd.edu (Jeff Laughlin) Date: Sun Feb 19 12:30:08 2006 Subject: [Nagiosplug-devel] check_ntp bugs Message-ID: <43F7F8FE.7050607@rv-revelle.ucsd.edu> Hello, I had a minor problem with check_ntp I'd like to report. I had to add the -d switch to the ntpdate arguments to make ntpdate use an unpriviledged port, since I didn't want to run the check as root. It seems like that should be the standard way to do it. Also I was getting an annoying perl warning: [scg at zeppo libexec]$ ./check_ntp -H 137.110.149.50 Use of uninitialized value in division (/) at ./check_ntp line 424. NTP OK: Offset -0.004400 secs|offset=-0.004400, jitter=0,peer_stratum=1 that didn't really make sense since like 424 is "1;", so I just turned off warnings. But I wanted to bring it up because it does confuse Nagios when it sees that warning. -Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: laughlin.vcf Type: text/x-vcard Size: 306 bytes Desc: not available URL: From yves.martin at elca.ch Tue Feb 21 04:42:04 2006 From: yves.martin at elca.ch (Yves Martin) Date: Tue Feb 21 04:42:04 2006 Subject: [Nagiosplug-devel] RRD database check script Message-ID: <20060221103840.EC5734F40E3@desire.netways.de> Hello, I have improved the "check_rrd_data.pl" (switch debug message) and create a "check_rrd_percent.pl" for my own usage: compute the % of disk used from cacti rrd file And I do not want to create a new project. Is it possible for somebody having "nagiosexchange" account to install my scripts in "Databases / RDD databases" project ? Thank you in advance. check_rrd_data.pl ----------------------- #!/usr/bin/perl -wT # check_rrd_data plugin for nagios # # usage: # check_rrd_data.pl rrdfile datasource warning critical # # Copyright Notice: GPL use lib "/usr/lib/nagios/plugins/"; use utils qw(%ERRORS $TIMEOUT); use RRDs; use strict; # RRD:File and utils.pm don't like this $ENV{'PATH'} = "/bin:/usr/bin"; $ENV{'ENV'} = ""; use constant DEBUG => 0; if (scalar @ARGV != 1 && scalar @ARGV != 4) { print STDERR "Usage: check_rrd_data.pl rrdfile datasource warning critical\n"; print STDERR " or check_rrd_data.pl rrdfile to list available data sources.\n"; exit $ERRORS{'UNKNOWN'}; } # Default # Guess which RRD file have to be opened my $rrdfile = $ARGV[0] if (-r $ARGV[0]); # First the parameter print "\$rrdfile = $rrdfile\n" if DEBUG; my $ds = defined $ARGV[1]?$ARGV[1]:0; print "\$ds = " . $ds . "\n" if DEBUG; $ds =~ s/\$//g; # Sometimes Nagios gives 1$ as the last parameter my $warn = defined $ARGV[2] ? $ARGV[2] : 0; print "\$warn = " . $warn . "\n" if DEBUG; my $crit = defined $ARGV[3] ? $ARGV[3] : 0; print "\$crit = " . $crit . "\n" if DEBUG; my ($last) = RRDs::last ($rrdfile); print "\$last: ","$last\n" if DEBUG; my ($start,$step,$names,$data) = RRDs::fetch ($rrdfile,"AVERAGE","-s",$ last,"-e",$last); $last = $start; ($start,$step,$names,$data) = RRDs::fetch ($rrdfile,"AVERAGE","-s",$las t,"-e",$last); if (DEBUG) { print "Start: ", scalar localtime($start), " ($start)\n"; print "Step size: $step seconds\n"; print "DS names: ", join (", ", @$names)."\n"; print "Data points: ", $#$data + 1, "\n"; print "Data:\n"; foreach my $line (@$data) { print " ", scalar localtime($start), " ($start) "; $start += $step; foreach my $val (@$line) { printf "%12d ", $val; } print "\n"; } } my $i; my $found_index; for ($i= 0; $i < @$names; $i++) { if (@$names[$i] eq $ds) { $found_index = $i; last; } } if (!defined($found_index)) { print "Available data sources in $rrdfile: " . join (", ", @$names) . "\n"; exit $ERRORS{'UNKNOWN'}; } my $value = @$data[0]->[$found_index]; printf "DS Index: %d value: %s\n", $found_index, "$value" if DEBUG; # First check for critical errors if ($value > $crit) { print "RRD CRITICAL ", "$ds:", " $value\n"; exit $ERRORS{'CRITICAL'}; } # Check for warnings if ($value > $warn) { print "RRD WARNING ", "$ds:", " $value\n"; exit $ERRORS{'WARNING'}; } # Normally returns 0 (OK) print "RRD Check OK ", "$ds:", " $value\n"; exit $ERRORS{'OK'}; ----------------------- check_rrd_percent.pl ----------------------- #!/usr/bin/perl -wT # check_rrd_percent plugin for nagios # # usage: # check_rrd_percent.pl rrdfile datasource1 datasource2 warning critical # # Copyright Notice: GPL # use lib "/usr/lib/nagios/plugins/"; use utils qw(%ERRORS $TIMEOUT); use RRDs; use strict; # RRD:File and utils.pm don't like this $ENV{'PATH'} = "/bin:/usr/bin"; $ENV{'ENV'} = ""; use constant DEBUG => 0; if (scalar @ARGV != 1 && scalar @ARGV != 5) { print STDERR "Usage: check_rrd_data.pl rrdfile datasource1 datasource2 warning critical\n"; print STDERR " or check_rrd_data.pl rrdfile to list available data sources.\n"; exit $ERRORS{'UNKNOWN'}; } # Default # Guess which RRD file have to be opened my $rrdfile = $ARGV[0] if (-r $ARGV[0]); # First the parameter print "\$rrdfile = $rrdfile\n" if DEBUG; my $ds1 = defined $ARGV[1]?$ARGV[1]:0; print "\$ds1 = " . $ds1 . "\n" if DEBUG; $ds1 =~ s/\$//g; # Sometimes Nagios gives 1$ as the last parameter my $ds2 = defined $ARGV[2]?$ARGV[2]:0; print "\$ds2 = " . $ds2 . "\n" if DEBUG; $ds2 =~ s/\$//g; # Sometimes Nagios gives 1$ as the last parameter my $warn = defined $ARGV[3] ? $ARGV[3] : 0; print "\$warn = " . $warn . "\n" if DEBUG; my $crit = defined $ARGV[4] ? $ARGV[4] : 0; print "\$crit = " . $crit . "\n" if DEBUG; my ($last) = RRDs::last ($rrdfile); print "\$last: ","$last\n" if DEBUG; my ($start,$step,$names,$data) = RRDs::fetch ($rrdfile,"AVERAGE","-s",$ last,"-e",$last); $last = $start; ($start,$step,$names,$data) = RRDs::fetch ($rrdfile,"AVERAGE","-s",$las t,"-e",$last); if (DEBUG) { print "Start: ", scalar localtime($start), " ($start)\n"; print "Step size: $step seconds\n"; print "DS names: ", join (", ", @$names)."\n"; print "Data points: ", $#$data + 1, "\n"; print "Data:\n"; foreach my $line (@$data) { print " ", scalar localtime($start), " ($start) "; $start += $step; foreach my $val (@$line) { printf "%12d ", $val; } print "\n"; } } my $i; my $found_index1; my $found_index2; for ($i= 0; $i < @$names; $i++) { if (@$names[$i] eq $ds1) { $found_index1 = $i; } if (@$names[$i] eq $ds2) { $found_index2 = $i; } } if (!defined($found_index1) || !defined($found_index2)) { print "Available data sources in $rrdfile: " . join (", ", @$names) . "\n"; exit $ERRORS{'UNKNOWN'}; } my $value1 = @$data[0]->[$found_index1]; printf "DS Index: %d value: %s\n", $found_index1, "$value1" if DEBUG; my $value2 = @$data[0]->[$found_index2]; printf "DS Index: %d value: %s\n", $found_index2, "$value2" if DEBUG; my $value = $value1 / ($value1 + $value2) * 100; print "Percentage datasource1/(datasource1+datasource2)*100 = $value\n" if DEBUG; # First check for critical errors if ($value > $crit) { print "RRD CRITICAL ", "$ds1/($ds1+$ds2) % :", " $value\n"; exit $ERRORS{'CRITICAL'}; } # Check for warnings if ($value > $warn) { print "RRD WARNING ", "$ds1/($ds1+$ds2) % :", " $value\n"; exit $ERRORS{'WARNING'}; } # Normally returns 0 (OK) print "RRD Check OK ", "$ds1/($ds1+$ds2) % :", " $value\n"; exit $ERRORS{'OK'}; ----------------------- - Yves Martin (ymartin) ----------------------- The mailing list archive is found here: http://www.nagiosexchange.org/nagiosplug-devel.31.0.html From leefitzg at aol.com Wed Feb 22 09:03:07 2006 From: leefitzg at aol.com (Lee Fitz) Date: Wed Feb 22 09:03:07 2006 Subject: [Nagiosplug-devel] Ping: I would expect Nagios to return -1, or 3 for "system14;UP;HARD;1;(No output!)" Message-ID: <43FC974E.4070101@aol.com> I have a most perplexing couple of issues: ---- Nagios (ping plugin) appears to be returning '1' and this is causing an erroneous system UP notification - seems like is should be returning -1, or 3 = UNKNOWN which I would assume would not translate to system UP date mmdd hhmm ss 0203 0332 43 [1138966363] HOST ALERT: system14;DOWN;SOFT;1;CRITICAL - Plugin timed out after 20 seconds 0203 0333 03 [1138966383] HOST ALERT: system14;DOWN;SOFT;2;CRITICAL - Plugin timed out after 20 seconds 0203 0333 23 [1138966403] HOST ALERT: system14;DOWN;HARD;3;CRITICAL - Plugin timed out after 20 seconds 0203 0333 23 [1138966403] HOST NOTIFICATION: mtools;system14;DOWN;host-notify-by-mknotify;CRITICAL - Plugin timed out after 20 seconds 0203 0426 05 [1138969565] HOST ALERT: system14;UP;HARD;1;(No output!) <===this is the problem 0203 0426 05 [1138969565] HOST NOTIFICATION:mtools;system14;UP;host-notify-by-mknotify;(No output!) NOTE: I am using define host { check_interval 1 ... check_command check-host-alive } define command { command_name check-host-alive command_line ....libexec/check_ping -H $HOSTADDRESS$ -w 6000.0,80% -c 15000.0,100% -p 1 -t 20 } Any suggestions would be appreciated -Lee From gh at 3gupload.com Wed Feb 22 09:11:08 2006 From: gh at 3gupload.com (gh) Date: Wed Feb 22 09:11:08 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion Message-ID: <1140628193.13789.3.camel@gspot.internal.3gupload.com> >From what I can tell check_ping has been deprecated in favor of check_icmp. Is this the case or are there certain systems or conditions that make check_ping favorable or even necessary? Thanks for clearing this up. -g -- // Garrett Honeycutt // 3GUpload.com, Inc. // Systems Engineer // // 317.472.4969 From ae at op5.se Wed Feb 22 09:34:04 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 09:34:04 2006 Subject: [Nagiosplug-devel] Ping: I would expect Nagios to return -1, or 3 for "system14;UP;HARD;1;(No output!)" In-Reply-To: <43FC974E.4070101@aol.com> References: <43FC974E.4070101@aol.com> Message-ID: <43FCA065.3010005@op5.se> Lee Fitz wrote: > I have a most perplexing couple of issues: > ---- Nagios (ping plugin) appears to be returning '1' and this is > causing an > erroneous system UP notification > - seems like is should be returning -1, or 3 = UNKNOWN which I > would assume would not translate to system UP > > date > mmdd hhmm ss > 0203 0332 43 [1138966363] HOST ALERT: system14;DOWN;SOFT;1;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 03 [1138966383] HOST ALERT: system14;DOWN;SOFT;2;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 23 [1138966403] HOST ALERT: system14;DOWN;HARD;3;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 23 [1138966403] HOST NOTIFICATION: > mtools;system14;DOWN;host-notify-by-mknotify;CRITICAL - Plugin timed > out after 20 seconds > This is according to spec. The plugin times out so Nagios returns critical for it. > 0203 0426 05 [1138969565] HOST ALERT: system14;UP;HARD;1;(No > output!) <===this is the problem > 0203 0426 05 [1138969565] HOST > NOTIFICATION:mtools;system14;UP;host-notify-by-mknotify;(No output!) > This is weird though. The plugin clearly exits gracefully, but it should print something when it doesn't time out. What version of Nagios and plugins are you using? What OS and OS-version is this (uname -a should tell you). > NOTE: I am using > define host { > check_interval 1 > ... > check_command check-host-alive > } > > define command { > command_name check-host-alive > command_line ....libexec/check_ping -H $HOSTADDRESS$ -w > 6000.0,80% -c 15000.0,100% -p 1 -t 20 > } > > Any suggestions would be appreciated > Try check_icmp instead. You can just replace the check_ping binary with check_icmp instead. Make sure you do "chmod 4755 check_icmp" as root though, or it won't work. -- 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 Feb 22 09:37:02 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 09:37:02 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <1140628193.13789.3.camel@gspot.internal.3gupload.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> Message-ID: <43FCA103.20902@op5.se> gh wrote: >>From what I can tell check_ping has been deprecated in favor of > check_icmp. Is this the case or are there certain systems or conditions > that make check_ping favorable or even necessary? > check_icmp had some problems on systems with 32-bit process id's in the early days (causing it to mark the packets wrong and then not recognizing them when they returned). It also used to calculate timings slightly wrong. Both those problems are solved long since, however. Now there are no real reasons to use check_ping instead of check_icmp. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From gh at 3gupload.com Wed Feb 22 09:50:04 2006 From: gh at 3gupload.com (gh) Date: Wed Feb 22 09:50:04 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCA103.20902@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> Message-ID: <1140630504.13789.10.camel@gspot.internal.3gupload.com> On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: > gh wrote: > >From what I can tell check_ping has been deprecated in favor of > > check_icmp. Is this the case or are there certain systems or conditions > > that make check_ping favorable or even necessary? > > > > check_icmp had some problems on systems with 32-bit process id's in the > early days (causing it to mark the packets wrong and then not > recognizing them when they returned). It also used to calculate timings > slightly wrong. Both those problems are solved long since, however. Now > there are no real reasons to use check_ping instead of check_icmp. > What do people think about just dropping check_ping from the next version of the plugins package to avoid all this unnecessary confusion that is evident on the mailing lists and replace it with a symlink to check_icmp for backwards compatibility? -g -- // Garrett Honeycutt // 3GUpload.com, Inc. // Systems Engineer // // 317.472.4969 From ae at op5.se Wed Feb 22 09:53:05 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 09:53:05 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <1140630504.13789.10.camel@gspot.internal.3gupload.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> Message-ID: <43FCA4E1.2040107@op5.se> gh wrote: > On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: > >>gh wrote: >>>From what I can tell check_ping has been deprecated in favor of >> >>>check_icmp. Is this the case or are there certain systems or conditions >>>that make check_ping favorable or even necessary? >>> >> >>check_icmp had some problems on systems with 32-bit process id's in the >>early days (causing it to mark the packets wrong and then not >>recognizing them when they returned). It also used to calculate timings >>slightly wrong. Both those problems are solved long since, however. Now >>there are no real reasons to use check_ping instead of check_icmp. >> > > > What do people think about just dropping check_ping from the next > version of the plugins package to avoid all this unnecessary confusion > that is evident on the mailing lists and replace it with a symlink to > check_icmp for backwards compatibility? > I'm all for it. Considering I wrote the thing originally I'm a bit biased though. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From jasonrcrawford at gmail.com Wed Feb 22 10:41:00 2006 From: jasonrcrawford at gmail.com (Jason Crawford) Date: Wed Feb 22 10:41:00 2006 Subject: [Nagiosplug-devel] Ping: I would expect Nagios to return -1, or 3 for "system14;UP;HARD;1;(No output!)" In-Reply-To: <43FC974E.4070101@aol.com> References: <43FC974E.4070101@aol.com> Message-ID: <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> On 2/22/06, Lee Fitz wrote: > I have a most perplexing couple of issues: > ---- Nagios (ping plugin) appears to be returning '1' and this is causing an > erroneous system UP notification > - seems like is should be returning -1, or 3 = UNKNOWN which I > would assume would not translate to system UP > > date > mmdd hhmm ss > 0203 0332 43 [1138966363] HOST ALERT: system14;DOWN;SOFT;1;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 03 [1138966383] HOST ALERT: system14;DOWN;SOFT;2;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 23 [1138966403] HOST ALERT: system14;DOWN;HARD;3;CRITICAL - > Plugin timed out after 20 seconds > 0203 0333 23 [1138966403] HOST NOTIFICATION: > mtools;system14;DOWN;host-notify-by-mknotify;CRITICAL - Plugin timed > out after 20 seconds > > 0203 0426 05 [1138969565] HOST ALERT: system14;UP;HARD;1;(No output!) <===this is the problem > 0203 0426 05 [1138969565] HOST NOTIFICATION:mtools;system14;UP;host-notify-by-mknotify;(No output!) > > NOTE: I am using > define host { > check_interval 1 > ... > check_command check-host-alive > } > > define command { > command_name check-host-alive > command_line ....libexec/check_ping -H $HOSTADDRESS$ -w > 6000.0,80% -c 15000.0,100% -p 1 -t 20 > } > > Any suggestions would be appreciated > This is the exact error I got, so I think this is related to the bug I found in the nagios plugins 1.4.2 where the alert signal function was trying to use child_process without checking whether it's NULL or not. A little patch I sent got put into the current version of nagios-plugins, but as far as I know has not been back-ported to 1.4.2 or whatever. For me, it had to do with the ipv6 host check, where it would check whether or not the host is an IPv6 address, by calling a getaddrinfo(), and that would take long enough that SIGALRM would be tripped, and child_process was NULL at that point. I found it went away if I did --without-ipv6, as even with my fix, it still exists, but with a better output message (and nagios doesn't segfault). The thing I don't like about check_icmp is it has to be run as root or setuid root, where as check_ping does not (it uses the system setuid ping binary). Jason From jasonrcrawford at gmail.com Wed Feb 22 10:45:11 2006 From: jasonrcrawford at gmail.com (Jason Crawford) Date: Wed Feb 22 10:45:11 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <1140630504.13789.10.camel@gspot.internal.3gupload.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> Message-ID: <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> On 2/22/06, gh wrote: > On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: > > gh wrote: > > >From what I can tell check_ping has been deprecated in favor of > > > check_icmp. Is this the case or are there certain systems or conditions > > > that make check_ping favorable or even necessary? > > > > > > > check_icmp had some problems on systems with 32-bit process id's in the > > early days (causing it to mark the packets wrong and then not > > recognizing them when they returned). It also used to calculate timings > > slightly wrong. Both those problems are solved long since, however. Now > > there are no real reasons to use check_ping instead of check_icmp. > > > > What do people think about just dropping check_ping from the next > version of the plugins package to avoid all this unnecessary confusion > that is evident on the mailing lists and replace it with a symlink to > check_icmp for backwards compatibility? > I just don't like the fact that check_icmp must be setuid root or run as root. Personally, I like to have as few setuid binaries as possible on my system, as well as little running as root as possible (in order to run check_icmp as root, the parent nagios stuff must be running as root as well). The great thing about check_ping is that it uses the already setuid ping binary. Jason From ae at op5.se Wed Feb 22 11:00:07 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 11:00:07 2006 Subject: [Nagiosplug-devel] Ping: I would expect Nagios to return -1, or 3 for "system14;UP;HARD;1;(No output!)" In-Reply-To: <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> References: <43FC974E.4070101@aol.com> <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> Message-ID: <43FCB498.2010407@op5.se> Jason Crawford wrote: > On 2/22/06, Lee Fitz wrote: > >>I have a most perplexing couple of issues: >>---- Nagios (ping plugin) appears to be returning '1' and this is causing an >>erroneous system UP notification >>- seems like is should be returning -1, or 3 = UNKNOWN which I >>would assume would not translate to system UP >> >>date >>mmdd hhmm ss >>0203 0332 43 [1138966363] HOST ALERT: system14;DOWN;SOFT;1;CRITICAL - >>Plugin timed out after 20 seconds >>0203 0333 03 [1138966383] HOST ALERT: system14;DOWN;SOFT;2;CRITICAL - >>Plugin timed out after 20 seconds >>0203 0333 23 [1138966403] HOST ALERT: system14;DOWN;HARD;3;CRITICAL - >>Plugin timed out after 20 seconds >>0203 0333 23 [1138966403] HOST NOTIFICATION: >>mtools;system14;DOWN;host-notify-by-mknotify;CRITICAL - Plugin timed >>out after 20 seconds >> >>0203 0426 05 [1138969565] HOST ALERT: system14;UP;HARD;1;(No output!) <===this is the problem >>0203 0426 05 [1138969565] HOST NOTIFICATION:mtools;system14;UP;host-notify-by-mknotify;(No output!) >> >>NOTE: I am using >>define host { >>check_interval 1 >>... >>check_command check-host-alive >>} >> >>define command { >>command_name check-host-alive >>command_line ....libexec/check_ping -H $HOSTADDRESS$ -w >>6000.0,80% -c 15000.0,100% -p 1 -t 20 >>} >> >>Any suggestions would be appreciated >> > > > This is the exact error I got, so I think this is related to the bug I > found in the nagios plugins 1.4.2 where the alert signal function was > trying to use child_process without checking whether it's NULL or not. > A little patch I sent got put into the current version of > nagios-plugins, but as far as I know has not been back-ported to 1.4.2 > or whatever. It was put in the CVS trunk. > The > thing I don't like about check_icmp is it has to be run as root or > setuid root, where as check_ping does not (it uses the system setuid > ping binary). > Either way, a setuid program has to be called. check_icmp is very heavily tested to withstand input anomalies (although not so much as ping, I'm sure). What I don't like about it is its lack of IP6 support, but I intend to rectify that "Any day now". ;) -- 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 Feb 22 11:10:04 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 11:10:04 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> Message-ID: <43FCB6D1.9090108@op5.se> Jason Crawford wrote: > On 2/22/06, gh wrote: > >>On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: >> >>>gh wrote: >>>>From what I can tell check_ping has been deprecated in favor of >>> >>>>check_icmp. Is this the case or are there certain systems or conditions >>>>that make check_ping favorable or even necessary? >>>> >>> >>>check_icmp had some problems on systems with 32-bit process id's in the >>>early days (causing it to mark the packets wrong and then not >>>recognizing them when they returned). It also used to calculate timings >>>slightly wrong. Both those problems are solved long since, however. Now >>>there are no real reasons to use check_ping instead of check_icmp. >>> >> >>What do people think about just dropping check_ping from the next >>version of the plugins package to avoid all this unnecessary confusion >>that is evident on the mailing lists and replace it with a symlink to >>check_icmp for backwards compatibility? >> > > > I just don't like the fact that check_icmp must be setuid root or run > as root. Personally, I like to have as few setuid binaries as possible > on my system, as well as little running as root as possible This is both sane and wise. > (in order > to run check_icmp as root, the parent nagios stuff must be running as > root as well). This is a downright lie. setuid binaries are executed with the permissions of the owner of the file. Nagios does *not* have to run as root (otherwise check_ping would fail as well). > The great thing about check_ping is that it uses the > already setuid ping binary. > Arguably, that's a worse setup since /bin/ping is executable by every user on the system (normally), while there's no reason for check_icmp to be. If you do # chown root:nagios check_icmp # chmod 4710 check_icmp and then set the nagios users shell to /bin/false (and ofcourse make sure there are no other users in the nagios group), you have a much safer setup than if you use check_ping to invoke /bin/ping. On a side note, both ping and check_icmp drop their root-privileges (unless run as root, anyways) immediately after obtaining the raw socket necessary to send layer 2 packets. However, if this is a very large concern for lots of people I could make check_icmp do all its work inside a chroot(2) jail. Then you'd be safer running check_icmp than /bin/ping. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From jasonrcrawford at gmail.com Wed Feb 22 11:15:16 2006 From: jasonrcrawford at gmail.com (Jason Crawford) Date: Wed Feb 22 11:15:16 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCB6D1.9090108@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> Message-ID: <5d6838280602221114g739b7fbbj4f16b1efd4557fd1@mail.gmail.com> On 2/22/06, Andreas Ericsson wrote: > Jason Crawford wrote: > > On 2/22/06, gh wrote: > > > >>On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: > >> > >>>gh wrote: > >>>>From what I can tell check_ping has been deprecated in favor of > >>> > >>>>check_icmp. Is this the case or are there certain systems or conditions > >>>>that make check_ping favorable or even necessary? > >>>> > >>> > >>>check_icmp had some problems on systems with 32-bit process id's in the > >>>early days (causing it to mark the packets wrong and then not > >>>recognizing them when they returned). It also used to calculate timings > >>>slightly wrong. Both those problems are solved long since, however. Now > >>>there are no real reasons to use check_ping instead of check_icmp. > >>> > >> > >>What do people think about just dropping check_ping from the next > >>version of the plugins package to avoid all this unnecessary confusion > >>that is evident on the mailing lists and replace it with a symlink to > >>check_icmp for backwards compatibility? > >> > > > > > > I just don't like the fact that check_icmp must be setuid root or run > > as root. Personally, I like to have as few setuid binaries as possible > > on my system, as well as little running as root as possible > > This is both sane and wise. > > > (in order > > to run check_icmp as root, the parent nagios stuff must be running as > > root as well). > > > This is a downright lie. setuid binaries are executed with the > permissions of the owner of the file. Nagios does *not* have to run as > root (otherwise check_ping would fail as well). You misunderstand what I was saying. What I meant to say was EITHER the binary must be setuid root OR the parent calling process must be run as root. > > > > The great thing about check_ping is that it uses the > > already setuid ping binary. > > > > Arguably, that's a worse setup since /bin/ping is executable by every > user on the system (normally), while there's no reason for check_icmp to be. > > If you do > # chown root:nagios check_icmp > # chmod 4710 check_icmp > > and then set the nagios users shell to /bin/false (and ofcourse make > sure there are no other users in the nagios group), you have a much > safer setup than if you use check_ping to invoke /bin/ping. > > On a side note, both ping and check_icmp drop their root-privileges > (unless run as root, anyways) immediately after obtaining the raw socket > necessary to send layer 2 packets. > > However, if this is a very large concern for lots of people I could make > check_icmp do all its work inside a chroot(2) jail. Then you'd be safer > running check_icmp than /bin/ping. Well I was more referring to the fact that the system's ping binary has gone through very extensive and thorough security audits (it's been around for how many years?) so there are less likely to be issues in the privileged code. However, a chroot(2) jail would make it even better. Jason From ae at op5.se Wed Feb 22 11:16:06 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 11:16:06 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCB6D1.9090108@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> Message-ID: <43FCB84B.2000901@op5.se> Andreas Ericsson wrote: > Jason Crawford wrote: > >> On 2/22/06, gh wrote: >> >>> On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: >>> >>>> gh wrote: >>>> >>>>> From what I can tell check_ping has been deprecated in favor of >>>> >>>> >>>>> check_icmp. Is this the case or are there certain systems or >>>>> conditions >>>>> that make check_ping favorable or even necessary? >>>>> >>>> >>>> check_icmp had some problems on systems with 32-bit process id's in the >>>> early days (causing it to mark the packets wrong and then not >>>> recognizing them when they returned). It also used to calculate timings >>>> slightly wrong. Both those problems are solved long since, however. Now >>>> there are no real reasons to use check_ping instead of check_icmp. >>>> >>> >>> What do people think about just dropping check_ping from the next >>> version of the plugins package to avoid all this unnecessary confusion >>> that is evident on the mailing lists and replace it with a symlink to >>> check_icmp for backwards compatibility? >>> >> >> >> I just don't like the fact that check_icmp must be setuid root or run >> as root. Personally, I like to have as few setuid binaries as possible >> on my system, as well as little running as root as possible > > > This is both sane and wise. > >> (in order >> to run check_icmp as root, the parent nagios stuff must be running as >> root as well). > > > > This is a downright lie. setuid binaries are executed with the > permissions of the owner of the file. Nagios does *not* have to run as > root (otherwise check_ping would fail as well). > > >> The great thing about check_ping is that it uses the >> already setuid ping binary. >> > Oh, and the most compelling reasons not to use check_ping: * It runs /bin/ping and parses the output. This works nicely so long as the developers have access to a ping that produces output in a certain format, but that's not as predictable as some like to think. * It is *much* slower than check_icmp. * It consumes more resources. * The code is ugly enough to make a mans eyes pop. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From jasonrcrawford at gmail.com Wed Feb 22 11:21:13 2006 From: jasonrcrawford at gmail.com (Jason Crawford) Date: Wed Feb 22 11:21:13 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCB84B.2000901@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> <43FCB84B.2000901@op5.se> Message-ID: <5d6838280602221120k1886c560vcb8355662334eab9@mail.gmail.com> On 2/22/06, Andreas Ericsson wrote: > Andreas Ericsson wrote: > > Jason Crawford wrote: > > > >> On 2/22/06, gh wrote: > >> > >>> On Wed, 2006-02-22 at 18:36 +0100, Andreas Ericsson wrote: > >>> > >>>> gh wrote: > >>>> > >>>>> From what I can tell check_ping has been deprecated in favor of > >>>> > >>>> > >>>>> check_icmp. Is this the case or are there certain systems or > >>>>> conditions > >>>>> that make check_ping favorable or even necessary? > >>>>> > >>>> > >>>> check_icmp had some problems on systems with 32-bit process id's in the > >>>> early days (causing it to mark the packets wrong and then not > >>>> recognizing them when they returned). It also used to calculate timings > >>>> slightly wrong. Both those problems are solved long since, however. Now > >>>> there are no real reasons to use check_ping instead of check_icmp. > >>>> > >>> > >>> What do people think about just dropping check_ping from the next > >>> version of the plugins package to avoid all this unnecessary confusion > >>> that is evident on the mailing lists and replace it with a symlink to > >>> check_icmp for backwards compatibility? > >>> > >> > >> > >> I just don't like the fact that check_icmp must be setuid root or run > >> as root. Personally, I like to have as few setuid binaries as possible > >> on my system, as well as little running as root as possible > > > > > > This is both sane and wise. > > > >> (in order > >> to run check_icmp as root, the parent nagios stuff must be running as > >> root as well). > > > > > > > > This is a downright lie. setuid binaries are executed with the > > permissions of the owner of the file. Nagios does *not* have to run as > > root (otherwise check_ping would fail as well). > > > > > >> The great thing about check_ping is that it uses the > >> already setuid ping binary. > >> > > > > Oh, and the most compelling reasons not to use check_ping: > * It runs /bin/ping and parses the output. This works nicely so long as > the developers have access to a ping that produces output in a certain > format, but that's not as predictable as some like to think. > * It is *much* slower than check_icmp. > * It consumes more resources. > * The code is ugly enough to make a mans eyes pop. > True, trying to use /bin/ping on a system no developer has seen yet would be a bit difficult, as well as running a separate binary does take up more resources. And when I was trying to track down that check_ping segfault issue, going over that code wasn't the easiest. Having check_icmp chroot(2) itself would definetly improve security quite a bit, but I also wonder how much more resources it would consume (never did chroot(2) benchmarks before). From ae at op5.se Wed Feb 22 11:38:02 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 11:38:02 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <5d6838280602221114g739b7fbbj4f16b1efd4557fd1@mail.gmail.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> <5d6838280602221114g739b7fbbj4f16b1efd4557fd1@mail.gmail.com> Message-ID: <43FCBD74.2060603@op5.se> Jason Crawford wrote: > On 2/22/06, Andreas Ericsson wrote: > >> >>On a side note, both ping and check_icmp drop their root-privileges >>(unless run as root, anyways) immediately after obtaining the raw socket >>necessary to send layer 2 packets. >> >>However, if this is a very large concern for lots of people I could make >>check_icmp do all its work inside a chroot(2) jail. Then you'd be safer >>running check_icmp than /bin/ping. > > > Well I was more referring to the fact that the system's ping binary > has gone through very extensive and thorough security audits (it's > been around for how many years?) Since 1968, I believe. I don't think very many lines of the original code remain anywhere now though. > so there are less likely to be issues > in the privileged code. I'm assuming you mean the lines of code that runs with root privileges here. These are the interesting parts of check_icmp.c: int main(int argc, char **argv) { int sock_recv_buf = IP_MAX_PACKET + 128; icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP); setsockopt(icmp_sock, SOL_SOCKET, SO_RCVBUF, (void *)&sock_recv_buf, sizeof(sock_recv_buf)); setsockopt(icmp_sock, SOL_SOCKET, SO_SNDBUF, (void *)&sock_recv_buf, sizeof(sock_recv_buf)); /* drop privileges (no effect if not setsuid or !geteuid() */ setuid(getuid()); .... } There are more variables, and naturally I check the result of the syscalls. My point remains though. Only three actions take place, in any path of execution, prior to dropping the privileges. Each and every one with hard-coded values. This is done prior to parsing the arguments, so userland or network input never go into the program while running as root, ever. > However, a chroot(2) jail would make it even > better. > Not necessarily. Unless it's hardcoded one has to slurp it from the command line arguments or someplace else, which means parsing userland input, or reading an environment variable, as root (ordinary users aren't allowed to chroot(2)). What I'm saying here is that it might make it more secure (although I doubt it's needed). However that goes though, people will wonder why their plugins start saying check_icmp: Failed to chroot() to '/var/empty': No such file or directory. I'm not particularly interested in answering that stream of questions, but I could provide a non-official patch that you and other as security-minded as you could use though. -- 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 Feb 22 11:47:01 2006 From: ae at op5.se (Andreas Ericsson) Date: Wed Feb 22 11:47:01 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <5d6838280602221120k1886c560vcb8355662334eab9@mail.gmail.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> <43FCB84B.2000901@op5.se> <5d6838280602221120k1886c560vcb8355662334eab9@mail.gmail.com> Message-ID: <43FCBF73.7060402@op5.se> Jason Crawford wrote: > On 2/22/06, Andreas Ericsson wrote: > >>Andreas Ericsson wrote: >> >>> >>Oh, and the most compelling reasons not to use check_ping: >>* It runs /bin/ping and parses the output. This works nicely so long as >>the developers have access to a ping that produces output in a certain >>format, but that's not as predictable as some like to think. >>* It is *much* slower than check_icmp. >>* It consumes more resources. >>* The code is ugly enough to make a mans eyes pop. >> > > True, trying to use /bin/ping on a system no developer has seen yet > would be a bit difficult, as well as running a separate binary does > take up more resources. And when I was trying to track down that > check_ping segfault issue, going over that code wasn't the easiest. > Having check_icmp chroot(2) itself would definetly improve security > quite a bit, but I also wonder how much more resources it would > consume (never did chroot(2) benchmarks before). > Virtually none. chroot(2) is a very simple system call that comes at the expense of setting a couple of variables in the kernel. The relevant parts are in fs/open.c (sys_chroot), fs/namespace.c (set_fs_root()) and fs/namei.c (set_fs_altroot()). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From skreuzer at f2o.org Wed Feb 22 12:50:01 2006 From: skreuzer at f2o.org (Steven Kreuzer) Date: Wed Feb 22 12:50:01 2006 Subject: [Nagiosplug-devel] Patch for check_mysql In-Reply-To: <43FCB498.2010407@op5.se> References: <43FC974E.4070101@aol.com> <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> <43FCB498.2010407@op5.se> Message-ID: <43FCCEE4.6030604@f2o.org> I have modified the check_mysql plugin to have it check how far behind (measured in seconds) a MySQL 4.x.x slave server is from the master server and exit with a status of either CRITICAL or WARNING if the user defined thresholds are met. I have attached a copy of the patch to this email, and it can also be found at http://skreuzer.f2o.org/code/nagios/check_mysql.patch Any and all feedback is greatly appreciated. -Steven -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_mysql.patch URL: From ton.voon at altinity.com Wed Feb 22 23:31:03 2006 From: ton.voon at altinity.com (Ton Voon) Date: Wed Feb 22 23:31:03 2006 Subject: [Nagiosplug-devel] Ping: I would expect Nagios to return -1, or 3 for "system14;UP;HARD;1;(No output!)" In-Reply-To: <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> References: <43FC974E.4070101@aol.com> <5d6838280602221039q535450f2ra24180a30f7ebea0@mail.gmail.com> Message-ID: <9D326685-9D01-44E9-9429-CE796EFE72AF@altinity.com> On 22 Feb 2006, at 18:39, Jason Crawford wrote: > This is the exact error I got, so I think this is related to the bug I > found in the nagios plugins 1.4.2 where the alert signal function was > trying to use child_process without checking whether it's NULL or not. > A little patch I sent got put into the current version of > nagios-plugins, but as far as I know has not been back-ported to 1.4.2 > or whatever. I added this into CVS. It should be in the snapshot on http:// nagiosplug.sf.net/snapshot. Let me know if it works okay. We're looking at a 1.4.3 release around mid March. Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From seanius at seanius.net Thu Feb 23 00:08:02 2006 From: seanius at seanius.net (sean finney) Date: Thu Feb 23 00:08:02 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCA103.20902@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> Message-ID: <20060223080720.GA31668@seanius.net> just to chime in here on the ping vs icmp topic, i think it's high time that we drop check_ping as the official pinging program and choose check_icmp as the default. to allay the security concerns of another installed setuid binary, my suggestion is we do what andreas has suggested and install it as root:nagios/4710. this way it's only able to be run by other members of the nagios group. as andreas pointed out, it drops it's root privileges immediately as well, so it's not really cause for much concern anyway. i'd also support your idea to chroot, but i'd suggest to make it non-default behaviour and configurable as a cmdline option. that would prvent the bogus support-inducing error messages, but would give software packagers like myself (who know somewhere the plugin could chroot itself on a debian system) the ability to introduce this easily as part of a default installation. personally, i'd prefer to completely purge check_ping, and make it a symlink pointing to check_icmp. perhaps this would require some extra code if the cmline options aren't compatible, but it would make our code base a whole lot cleaner. 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 Thu Feb 23 00:18:17 2006 From: ae at op5.se (Andreas Ericsson) Date: Thu Feb 23 00:18:17 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <20060223080720.GA31668@seanius.net> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <20060223080720.GA31668@seanius.net> Message-ID: <43FD6F90.3090706@op5.se> sean finney wrote: > > as andreas pointed out, it drops it's root privileges immediately > as well, so it's not really cause for much concern anyway. i'd > also support your idea to chroot, but i'd suggest to make it > non-default behaviour and configurable as a cmdline option. that > would prvent the bogus support-inducing error messages, but would > give software packagers like myself (who know somewhere the plugin > could chroot itself on a debian system) the ability to introduce > this easily as part of a default installation. > I take it you mean ./configure-time option? Otherwise it means parsing arguments as root. The '-j' flag could ofcourse be parsed separately and in an ultra-paranoid fashion, but still. > personally, i'd prefer to completely purge check_ping, and make > it a symlink pointing to check_icmp. perhaps this would require > some extra code if the cmline options aren't compatible, but > it would make our code base a whole lot cleaner. > I made an effort to make command-line options identical with both check_ping and check_fping, so it should be no extra work at all. If there is, let me know and I'll fix it up. If you're going with the symlink idea, you might want to make the check_host symlink as well. Not many seem to know about it (no doubt I've documented it poorly). -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From mh+nagiosplug-devel at zugschlus.de Thu Feb 23 01:23:01 2006 From: mh+nagiosplug-devel at zugschlus.de (Marc Haber) Date: Thu Feb 23 01:23:01 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FCB84B.2000901@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> <5d6838280602221044g6a4561ejec9dc0f41702e3ef@mail.gmail.com> <43FCB6D1.9090108@op5.se> <43FCB84B.2000901@op5.se> Message-ID: <20060223092202.GA1417@torres.l21.ma.zugschlus.de> On Wed, Feb 22, 2006 at 08:15:23PM +0100, Andreas Ericsson wrote: > Oh, and the most compelling reasons not to use check_ping: > * It runs /bin/ping and parses the output. This works nicely so long as > the developers have access to a ping that produces output in a certain > format, but that's not as predictable as some like to think. Also, from a distribution point of view, it is ugly to have check_ping configured for a certain ping flavor at build time. Since Debian is a binary distribution, we as maintainers have to make that decision for our users, making our package depend on a certain ping flavor, making it impossible for the local admin to choose a different ping to be installed on the nagios system. I am all for changing to check_icmp if that means that we can drop our package dependency on ping. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From seanius at seanius.net Thu Feb 23 01:41:02 2006 From: seanius at seanius.net (sean finney) Date: Thu Feb 23 01:41:02 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <43FD6F90.3090706@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <20060223080720.GA31668@seanius.net> <43FD6F90.3090706@op5.se> Message-ID: <20060223093956.GA31969@seanius.net> On Thu, Feb 23, 2006 at 09:17:20AM +0100, Andreas Ericsson wrote: > I take it you mean ./configure-time option? Otherwise it means parsing > arguments as root. The '-j' flag could ofcourse be parsed separately and > in an ultra-paranoid fashion, but still. hah. tricky. so it's a trade off between chrooting to a user-specified location and not parsing cmdline opts as root then. > I made an effort to make command-line options identical with both > check_ping and check_fping, so it should be no extra work at all. If > there is, let me know and I'll fix it up. cool. if there are no objections, i'll see what i can do this weekend. 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 Thu Feb 23 01:46:01 2006 From: ae at op5.se (Andreas Ericsson) Date: Thu Feb 23 01:46:01 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <20060223093956.GA31969@seanius.net> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <20060223080720.GA31668@seanius.net> <43FD6F90.3090706@op5.se> <20060223093956.GA31969@seanius.net> Message-ID: <43FD844B.5040306@op5.se> sean finney wrote: > On Thu, Feb 23, 2006 at 09:17:20AM +0100, Andreas Ericsson wrote: > >>I take it you mean ./configure-time option? Otherwise it means parsing >>arguments as root. The '-j' flag could ofcourse be parsed separately and >>in an ultra-paranoid fashion, but still. > > > hah. tricky. so it's a trade off between chrooting to a > user-specified location and not parsing cmdline opts as > root then. > Yup. Unless we maintain CAP_CHROOT but drop other capabilities. That's not very portable though. *sigh* > >>I made an effort to make command-line options identical with both >>check_ping and check_fping, so it should be no extra work at all. If >>there is, let me know and I'll fix it up. > > > cool. if there are no objections, i'll see what i can do this > weekend. > Go wild. :) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 From mh+nagiosplug-devel at zugschlus.de Thu Feb 23 02:09:13 2006 From: mh+nagiosplug-devel at zugschlus.de (Marc Haber) Date: Thu Feb 23 02:09:13 2006 Subject: check_icmp wish list (was: [Nagiosplug-devel] check_ping and check_icmp confusion) In-Reply-To: <43FCA103.20902@op5.se> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> Message-ID: <20060223100826.GC1417@torres.l21.ma.zugschlus.de> On Wed, Feb 22, 2006 at 06:36:03PM +0100, Andreas Ericsson wrote: > check_icmp had some problems on systems with 32-bit process id's in the > early days (causing it to mark the packets wrong and then not > recognizing them when they returned). It also used to calculate timings > slightly wrong. Both those problems are solved long since, however. Now > there are no real reasons to use check_ping instead of check_icmp. While we're at it: I have recently come across some systems which have ICMP echo request filtered, but send "host unreachable, administrative prohibition" back. It would be great if check_icmp could would have a command line option listing which ICMP packet types are considered a valid response. Additionally, it would be good to be able to specify a TTL value so that one could force a remote host to issue a "TTL exceeded" packet just in case that "host unreachable" is not configured as well. for example, 195.20.247.162, the last hop before the monitored host nechayev.zugschlus.de, is configured to show up in a traceroute, but doesn't answer to pings at all. That one could be monitored by sending a ping with the appropriate ttl to the actual host being monitored, forcing the otherwise silent gateway to answer with "Time to live exceeded": $ ping -c 1 -w 10 195.20.247.162 PING 195.20.247.162 (195.20.247.162) 56(84) bytes of data. --- 195.20.247.162 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9030ms $ ping -c 1 -t 8 nechayev.zugschlus.de PING nechayev.zugschlus.de (217.160.109.85) 56(84) bytes of data. >From gw-prtr-a.ds.ka.schlund.net (195.20.247.162) icmp_seq=1 Time to live exceeded --- nechayev.zugschlus.de ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms $ This allows host failures to be distinguished from network outages even in uncooperative networks, which is a nice thing to have and could be implemented easily in the existing check_icmp code. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 From ton.voon at altinity.com Thu Feb 23 04:26:11 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu Feb 23 04:26:11 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <1140630504.13789.10.camel@gspot.internal.3gupload.com> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <1140630504.13789.10.camel@gspot.internal.3gupload.com> Message-ID: On 22 Feb 2006, at 17:48, gh wrote: > What do people think about just dropping check_ping from the next > version of the plugins package to avoid all this unnecessary confusion > that is evident on the mailing lists and replace it with a symlink to > check_icmp for backwards compatibility? My decision is to distribute both. If there is not enough information about the choice of using check_ping or check_icmp, I am happy to hear suggestions on where this could be clarified. Andreas, who is not on the team, is very vocal about check_icmp, and I'm sure people will pickup its existence. The CVS version will now install check_icmp with suid root if "make install" is run as root. This will be in the 1.4.3 release around mid March. 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 ton.voon at altinity.com Thu Feb 23 10:43:08 2006 From: ton.voon at altinity.com (Ton Voon) Date: Thu Feb 23 10:43:08 2006 Subject: [Nagiosplug-devel] check_ping and check_icmp confusion In-Reply-To: <20060223093956.GA31969@seanius.net> References: <1140628193.13789.3.camel@gspot.internal.3gupload.com> <43FCA103.20902@op5.se> <20060223080720.GA31668@seanius.net> <43FD6F90.3090706@op5.se> <20060223093956.GA31969@seanius.net> Message-ID: <33ED5CF8-4CB8-4F55-96D8-BE973923696A@altinity.com> On 23 Feb 2006, at 09:39, sean finney wrote: >> I made an effort to make command-line options identical with both >> check_ping and check_fping, so it should be no extra work at all. If >> there is, let me know and I'll fix it up. > > cool. if there are no objections, i'll see what i can do this > weekend. Sorry, I sent my email re: keeping check_ping while on a train, so I didn't realise this issue was exploding until I reconnected and my email already flew out. I still say to keep both check_ping and check_icmp because the fact you still have ideas on how to secure it means that there's still work to be done on check_icmp. I'm happy to promote the use of check_icmp more (ideas?), but the dropping of check_ping should be in a more significant release at a later date. 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 Andrew.Laden at tudor.com Thu Feb 23 10:45:02 2006 From: Andrew.Laden at tudor.com (Andrew Laden) Date: Thu Feb 23 10:45:02 2006 Subject: [Nagiosplug-devel] FW: [Nagios-users] Check_http with size and regex conditions igno ring size check. Message-ID: <56EAA5BC64E6C34F8C9EE6725D4A2DFA024DF3B7@tudor.com> Bouncing request to plugdevel. Can the check_http plugin handle multiple conditions. Ie, check both for a regex and for a minimum size. Thanks -Andrew > > > > I want to check a web page, and check both for a regex and for a > minimum > > size. > > > > However, it appears that the regex requirement overides the > size. Eg. > > (names changes to protect the innocent) check_http (nagios-plugins > > 1.4.1) 1.81 > > > > aladen at host> check_http -H servername -p 8080 -u "uri" -r "REGEX > CHECK" - > > m 60:100 > > HTTP OK HTTP/1.1 200 OK - 0.420 second response time > > |time=0.419695s;;;0.000000 size=2405B;60;0;0 > > > > aladen at host> check_http -H servername -p 8080 -u "uri" -m > 60:100 HTTP > > WARNING: page size 2405 too large|size=2405B;60;0;0 > > > > Is this a bug in check_http? > > Technically no it's not a bug, the command line arguments are > not compatible. Looking around line 1030 and forward of > check_http.c, the regex tests and size tests are not > progressive. The order (from there > forward) is header checks, regex checks then size checks. > Each will exit the program based on *success* or failure of > the check. I would call it a feature request to have checks > be progressive. On success, continue to the next test... You > might want to bounce this over to the nagiosplug-devel list > for their consideration. > > -- > Marc > From nicolai at linpro.no Fri Feb 24 06:11:06 2006 From: nicolai at linpro.no (Nicolai Langfeldt) Date: Fri Feb 24 06:11:06 2006 Subject: [Nagiosplug-devel] Check_ntp stratum checking Message-ID: <43FF016D.3030509@linpro.no> Hi, At least Debian and Red Hat / Fedora Linux systems fall back to the local clock fudged to stratum 13 if the reference dissappears. The attached patch (relative to 1.29 which is the latest version it appears) adds a stratum check and if the stratum value is higher than or equal to 13 a warning is raised. The threshold value can be changed with the -s option. Nicolai -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_ntp-stratumdiff.txt URL: From lars.bruun-hansen at nordea.com Fri Feb 24 08:11:17 2006 From: lars.bruun-hansen at nordea.com (lars.bruun-hansen at nordea.com) Date: Fri Feb 24 08:11:17 2006 Subject: [Nagiosplug-devel] check_procs v 1.46 BASENAME and ignore self Message-ID: <02A80999ABFD6C418E9EDA7CCD41929C0153FED4@fid1ms09.fid1.root4.net> I've previously succesfully used v1.43 but now I seem to be facing major problems with 1.46. I'm on Solaris 10 and these are my findings: Issue #1 The HAVE_BASENAME change is not good for me because this piece of code is not compiled since HAVE_BASENAME is undefined. Where is it supposed to come from ? (Solaris does indeed have a basename() function and it will work as expected) The result of this is that -C filter does not work as expected. Issue #2 The code changes made in order to ignore self does not seem to work. I can see this by running in verbose mode (-vvv) and checking when the procs counter is increased. To me the problem seems to be that there are actually two proceses that you would want to ignore. 1. the check_procs process 2. the ps process (which will be a child of the one above) Not really knowing the code I think that you will have to check on both the actual PID and as well as the PPID, i.e. if (mypid == procpid || mypid == procppid) continue; The result of this issue is that check_procs will report one more process than what actually exist. Issue #3 There is something strange - unless it is intentional - with my PS_VARLIST. I note that variable procpid is repeated. Is this really intentional? This is how it looks in config.h: /* Variable list for sscanf of 'ps' output */ #define PS_VARLIST procstat,&procuid,&procpid,&procpid,&procvsz,&procrss,&procpcpu,procprog ,&pos I would have thought that it should have been: #define PS_VARLIST procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procpro g,&pos rgds, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Tue Feb 28 03:19:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 28 03:19:05 2006 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1440257 ] check_file_age - multiple files Message-ID: Patches item #1440257, was opened at 2006-02-28 12:18 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=1440257&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: Open Resolution: None Priority: 5 Submitted By: Matthias Eble (kis_meble) Assigned to: Nobody/Anonymous (nobody) Summary: check_file_age - multiple files Initial Comment: This patch enhances check_file_age by following functionalities: -d check all files in FILE (if -f is a directory) -r REGEXP only check files in matching REGEXP -n NUM only exit non OK if the sum of non OK files is larger or equal than NUM The output contains a list of the failed filenames if -d option is given hope you like it.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1440257&group_id=29880 From nagios at nagios.org Tue Feb 28 10:11:04 2006 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 28 10:11:04 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes Message-ID: <44043D9A.4419.F099FE@nagios.nagios.org> Hi all - I'm looking for some comments on proposed extensions to the current plugin API for Nagios 3.x. For a long time, people have been requesting multiline output for host and service checks. I currently have this feature working in the Nagios CVS HEAD (3.x) code and would like some feedback as to how this should work. The multiline output changes that I am proposing would remain compatible with the existing (single line) plugin output. Take this sample plugin output as an example: Line1: "Short output | Perf1" Line2: "Long output 1" Line3: "Long output 2" Line4: "Long output3 | Perf2" Line5: "Perf3" Line6: "Perf4" Nagios would interpret the six lines out of above plugin output and make it avaiable in macros it like this: $SERVICEOUTPUT$="Short output" $PERFDATA$="Perf1 Perf2 Perf3 Perf4" $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" The proposed format would allow for: 1. Multiple lines of output to be optional, rather than required 2. Multiple lines of perfdata can follow the long output if seperated by a pipe (|) symbol, as can be done of the first line 3. Multiple lines of perfdata are concatenated together, seperated by a space (newlines are not included) 4. Long output would have newlines escaped as shown above The proposed changes are nice in that they allow for multiline (and longer) output and perf data, while remaining compatible with the current plugin API. What are people's thoughts on this? FYI, there will be no inherent limitations on the length of plugin output in Nagios 3.x. IPC is handled slightly differently in the CVS code, which allows us to have longer output without bumping into the 512-byte PIPE_BUF Posix limitation for pipes. I'll probably cap the output at 2K or so to prevent runaway plugins from spewing megs of data back to Nagios. You wouldn't want that much data sent to your pager or cellphone. :-) Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From jhmartin at toger.us Tue Feb 28 10:53:02 2006 From: jhmartin at toger.us (Jason Martin) Date: Tue Feb 28 10:53:02 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <44043D9A.4419.F099FE@nagios.nagios.org> References: <44043D9A.4419.F099FE@nagios.nagios.org> Message-ID: <20060228185203.GD7611@mal.toger.us> On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: > Line1: "Short output | Perf1" > Line2: "Long output 1" > Line3: "Long output 2" > Line4: "Long output3 | Perf2" > Line5: "Perf3" > Line6: "Perf4" > $SERVICEOUTPUT$="Short output" > $PERFDATA$="Perf1 Perf2 Perf3 Perf4" > $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" How does Nagios differentiate between Line2 being 'long output' and line5 being perfdata? Both follow a line with a | character in it. Thank you, -Jason Martin -- This message is PGP/MIME signed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From nagios at nagios.org Tue Feb 28 11:05:07 2006 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 28 11:05:07 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <20060228185203.GD7611@mal.toger.us> References: <44043D9A.4419.F099FE@nagios.nagios.org> Message-ID: <44044A5E.19609.1227627@nagios.nagios.org> On 28 Feb 2006 at 10:52, Jason Martin wrote: > On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: > > Line1: "Short output | Perf1" > > Line2: "Long output 1" > > Line3: "Long output 2" > > Line4: "Long output3 | Perf2" > > Line5: "Perf3" > > Line6: "Perf4" > > $SERVICEOUTPUT$="Short output" > > $PERFDATA$="Perf1 Perf2 Perf3 Perf4" > > $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" > How does Nagios differentiate between Line2 being 'long output' > and line5 being perfdata? Both follow a line with a | character > in it. Any additional lines (beyond the first one) are considered standard text output and made a part of the $LONGSERVICEOUTPUT$ macro. Once a pipe symbol is found in those additional lines, anything after that symbol (including additional full lines of text) are considered to be performance data. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From ae at op5.se Tue Feb 28 11:54:07 2006 From: ae at op5.se (Andreas Ericsson) Date: Tue Feb 28 11:54:07 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <44044A5E.19609.1227627@nagios.nagios.org> References: <44043D9A.4419.F099FE@nagios.nagios.org> <44044A5E.19609.1227627@nagios.nagios.org> Message-ID: <4404AA46.1050308@op5.se> Ethan Galstad wrote: > On 28 Feb 2006 at 10:52, Jason Martin wrote: > > >>On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: >> >>>Line1: "Short output | Perf1" >>>Line2: "Long output 1" >>>Line3: "Long output 2" >>>Line4: "Long output3 | Perf2" >>>Line5: "Perf3" >>>Line6: "Perf4" >>>$SERVICEOUTPUT$="Short output" >>>$PERFDATA$="Perf1 Perf2 Perf3 Perf4" >>>$LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" > > >>How does Nagios differentiate between Line2 being 'long output' >>and line5 being perfdata? Both follow a line with a | character >>in it. > > > Any additional lines (beyond the first one) are considered standard > text output and made a part of the $LONGSERVICEOUTPUT$ macro. Once a > pipe symbol is found in those additional lines, anything after that > symbol (including additional full lines of text) are considered to be > performance data. > Seems like a tricky rule. Why not just stick with current behaviour (that is, first pipe-char splits output and perf-data)? One can already do multiple perf-data entries with that, using the current parsers. -- 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 Tue Feb 28 12:36:02 2006 From: nagios at nagios.org (Ethan Galstad) Date: Tue Feb 28 12:36:02 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <4404AA46.1050308@op5.se> References: <44044A5E.19609.1227627@nagios.nagios.org> Message-ID: <44045F86.4965.1751D94@nagios.nagios.org> On 28 Feb 2006 at 20:53, Andreas Ericsson wrote: > Ethan Galstad wrote: > > On 28 Feb 2006 at 10:52, Jason Martin wrote: > > > > > >>On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: > >> > >>>Line1: "Short output | Perf1" > >>>Line2: "Long output 1" > >>>Line3: "Long output 2" > >>>Line4: "Long output3 | Perf2" > >>>Line5: "Perf3" > >>>Line6: "Perf4" > >>>$SERVICEOUTPUT$="Short output" > >>>$PERFDATA$="Perf1 Perf2 Perf3 Perf4" > >>>$LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" > > > > > >>How does Nagios differentiate between Line2 being 'long output' and > >>line5 being perfdata? Both follow a line with a | character in it. > > > > > > Any additional lines (beyond the first one) are considered standard > > text output and made a part of the $LONGSERVICEOUTPUT$ macro. Once > > a pipe symbol is found in those additional lines, anything after > > that symbol (including additional full lines of text) are considered > > to be performance data. > > > > Seems like a tricky rule. Why not just stick with current behaviour > (that is, first pipe-char splits output and perf-data)? One can > already do multiple perf-data entries with that, using the current > parsers. > Just to make things clear, each of the "Perfx" components in the above example can contain multiple perf data entries. The additional perf data lines are present to allow for more (optional) perf data that could potentially break backward compatability in terms of line length if it was all on the first line. If all the perf data entries can fit on the first line, that's great. If not, some of them can be appended in later lines as described above. Either way, any perf data entries found will get concatenated into the $xPERFDATA$ macros. So the current plugins run just fine as they are, but the new design allows for longer output and perf data if necessary. Ethan Galstad, Nagios Developer --- Email: nagios at nagios.org Website: http://www.nagios.org From jd at op5.se Tue Feb 28 13:18:04 2006 From: jd at op5.se (Johannes Dagemark) Date: Tue Feb 28 13:18:04 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <44045F86.4965.1751D94@nagios.nagios.org> References: <44044A5E.19609.1227627@nagios.nagios.org> <44045F86.4965.1751D94@nagios.nagios.org> Message-ID: <4404BDBE.20602@op5.se> Ethan Galstad wrote: > On 28 Feb 2006 at 20:53, Andreas Ericsson wrote: > >> Ethan Galstad wrote: >>> On 28 Feb 2006 at 10:52, Jason Martin wrote: >>> >>> >>>> On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: >>>> >>>>> Line1: "Short output | Perf1" >>>>> Line2: "Long output 1" >>>>> Line3: "Long output 2" >>>>> Line4: "Long output3 | Perf2" >>>>> Line5: "Perf3" >>>>> Line6: "Perf4" >>>>> $SERVICEOUTPUT$="Short output" >>>>> $PERFDATA$="Perf1 Perf2 Perf3 Perf4" >>>>> $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" >>> >>>> How does Nagios differentiate between Line2 being 'long output' and >>>> line5 being perfdata? Both follow a line with a | character in it. >>> >>> Any additional lines (beyond the first one) are considered standard >>> text output and made a part of the $LONGSERVICEOUTPUT$ macro. Once >>> a pipe symbol is found in those additional lines, anything after >>> that symbol (including additional full lines of text) are considered >>> to be performance data. >>> >> Seems like a tricky rule. Why not just stick with current behaviour >> (that is, first pipe-char splits output and perf-data)? One can >> already do multiple perf-data entries with that, using the current >> parsers. >> > > Just to make things clear, each of the "Perfx" components in the > above example can contain multiple perf data entries. The additional > perf data lines are present to allow for more (optional) perf data > that could potentially break backward compatability in terms of line > length if it was all on the first line. > > If all the perf data entries can fit on the first line, that's great. > If not, some of them can be appended in later lines as described > above. Either way, any perf data entries found will get concatenated > into the $xPERFDATA$ macros. > > So the current plugins run just fine as they are, but the new design > allows for longer output and perf data if necessary. > I might be way of here but why not simply let \n separate the diffrent lines of perfdata as well as for the plugin output. For example plugin output\n even more output\n output on third line | perfdata for line1\n perfdata for line2\n perfdata for line3 Cheers Johannes Dagemark -- OP5 AB Drottninggatan 26 SE-411 11 G?teborg Cellphone: +46 733-709024 Fax: +46 31-7740432 www.op5.se > > > > > Ethan Galstad, > Nagios Developer > --- > Email: nagios at nagios.org > Website: http://www.nagios.org > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________________ > 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 > From ton.voon at altinity.com Tue Feb 28 13:54:02 2006 From: ton.voon at altinity.com (Ton Voon) Date: Tue Feb 28 13:54:02 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <44043D9A.4419.F099FE@nagios.nagios.org> References: <44043D9A.4419.F099FE@nagios.nagios.org> Message-ID: On 28 Feb 2006, at 18:10, Ethan Galstad wrote: > The multiline output changes that I am proposing would remain > compatible with the existing (single line) plugin output. Take this > sample plugin output as an example: > > Line1: "Short output | Perf1" > Line2: "Long output 1" > Line3: "Long output 2" > Line4: "Long output3 | Perf2" > Line5: "Perf3" > Line6: "Perf4" > > Nagios would interpret the six lines out of above plugin output and > make it avaiable in macros it like this: > > $SERVICEOUTPUT$="Short output" > $PERFDATA$="Perf1 Perf2 Perf3 Perf4" > $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" I think this design works well. Should $LONGSERVICEOUTPUT$ be "Short output\nLong output 1\nLong output2\nLong output3\n"? Ton http://www.altinity.com T: +44 (0)870 787 9243 F: +44 (0)845 280 1725 Skype: tonvoon From jhmartin at toger.us Tue Feb 28 14:13:01 2006 From: jhmartin at toger.us (Jason Martin) Date: Tue Feb 28 14:13:01 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: References: <44043D9A.4419.F099FE@nagios.nagios.org> Message-ID: <20060228221208.GG7611@mal.toger.us> On Tue, Feb 28, 2006 at 09:53:26PM +0000, Ton Voon wrote: > Should $LONGSERVICEOUTPUT$ be "Short output\nLong output 1\nLong > output2\nLong output3\n"? I'd suggest keeping them seperate. If the user wants them both together it is easy to cat them, while breaking them apart is harder. Fighting entropy and all that. -Jason Martin -- I apologize to the deaf for the loss of subtitles. This message is PGP/MIME signed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From sghosh at sghosh.org Tue Feb 28 21:08:01 2006 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Tue Feb 28 21:08:01 2006 Subject: [Nagiosplug-devel] RFC: Plugin API Changes In-Reply-To: <4404AA46.1050308@op5.se> References: <44043D9A.4419.F099FE@nagios.nagios.org> <44044A5E.19609.1227627@nagios.nagios.org> <4404AA46.1050308@op5.se> Message-ID: On Tue, 28 Feb 2006, Andreas Ericsson wrote: > Ethan Galstad wrote: >> On 28 Feb 2006 at 10:52, Jason Martin wrote: >> >> >>> On Tue, Feb 28, 2006 at 12:10:02PM -0600, Ethan Galstad wrote: >>> >>>> Line1: "Short output | Perf1" >>>> Line2: "Long output 1" >>>> Line3: "Long output 2" >>>> Line4: "Long output3 | Perf2" >>>> Line5: "Perf3" >>>> Line6: "Perf4" >>>> $SERVICEOUTPUT$="Short output" >>>> $PERFDATA$="Perf1 Perf2 Perf3 Perf4" >>>> $LONGSERVICEOUTPUT$="Long output 1\nLong output2\nLong output3\n" >> >> >>> How does Nagios differentiate between Line2 being 'long output' >>> and line5 being perfdata? Both follow a line with a | character >>> in it. >> >> >> Any additional lines (beyond the first one) are considered standard text >> output and made a part of the $LONGSERVICEOUTPUT$ macro. Once a pipe >> symbol is found in those additional lines, anything after that symbol >> (including additional full lines of text) are considered to be performance >> data. >> > > Seems like a tricky rule. Why not just stick with current behaviour (that is, > first pipe-char splits output and perf-data)? One can already do multiple > perf-data entries with that, using the current parsers. > > Either that - or each new line is either output or perfdata with separators allowing multiple parts but the line will be prefixed to distinguish betwwen the two. current parsers will have to be modified to handle multiline, so adding line prefix detection in the loop should be trivial. -- -sg