From pla at softflare.com Thu Apr 1 16:21:03 2004 From: pla at softflare.com (Paul L. Allen) Date: Thu Apr 1 16:21:03 2004 Subject: [Nagiosplug-devel] Re: check_by_ssh patch In-Reply-To: <406AFAE5.7010908@op5.se> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> Message-ID: <20040402002017.4294.qmail@minnow.softflare.net> I really shouldn't feed the trolls, but there's a slight possibility he's serious but misguided. Andreas Ericsson writes: > Paul L. Allen wrote: >> Andreas Ericsson writes: >>> and that it is a fair amount slower (even with the epn) than a properly >>> written C-program. >> >> It depends very much on what you're doing with it. For number-crunching >> it is slower, for uses where it runs, does a few things, then terminates >> then the difference can be a lot smaller. >> > Datacrunching in general. check_ifoperstatus runs in 6 seconds real time > whereas a shellscript checking multiple interfaces at the same time runs > in 1 second. Somebody else already answered you on that one. He doesn't see the results you're seeing. His results are a lot faster than yours. >> Anddefining a programming language as "industrial strength" first >> requires you to state whether you are basing your definition on >> programmer efficiency, CPU efficiency, memory efficiency or other >> criteria. > > Language possibilities. If you can't do it in C, it can't be done at all. The same is true of any Turing-complete language with full access to operating system calls, *or* a way of getting to them. With perl, a *small* number of syscalls on *some* platforms are not accessible from the language itself but *can* be accessed via modules. Hint: perl on Risc OS can access all syscalls. >> Perl has a lot of stuff that C lacks without adding libraries that are >> not a standard part of C. > > But not without perl modules. Really? Regexes are a standard part of the perl language, no modules required. If you want regexes in C you have to hunt out non-standard (as in not supplied with C compilers and not part of the ANSI standard) libraries. The same goes for many perl features. >> Useful stuff like data structures, regexes and >> memory management. > > Ofcourse it has memory management. Every script language in the world does > memory management, and virtually every script language has data > structures. Yes, C has memory management. If you remember to call malloc and friends carefully and don't make any mistakes. Perl takes care of it for you. C has fairly primitive data structures, but if you grab non-standard libraries or write your own code you can have the equivalent of perl's arrays and hashes. Etc. >> Stuff that allows perl programmers to be more >> productive and means they don't have to take care to avoid buffer >> overflows. > > There's always a tradeoff in development time if execution time is more > important. This is true in perl as well. Yes, it is. I wouldn't write an operating system in perl, and I wouldn't write a plugin in C. Horses for courses. If you really need execution- time speed, you can generate C code from perl. Not as fast as hand-written C, but an improvement. >>> This means that some things just can't be done without C-coding anyways. >> >> Most things can be done in perl without C coding, although a small number >> of them would be a little inefficient. > > A gross overstatement followed by an equally gross understatement. Crap. Perl will let you do anything any Turing-complete language will let you do, provided you do not need to access every possible syscall. Most *useful* syscalls already have perl equivalents or are accessible from perl's syscall function. Sure, a perl module written in C that computes MD5 hashes would be more efficient than a native perl implementation because there is some serious ALU-bashing, but you can *do* it in pure perl if you want. >> Most, but not all, syscalls can be >> handled by perl. For the few that cannot you need an XS module to >> provide >> the glue. Since perl is Turing-complete, with a little XS to take care >> of the small number of syscalls that return multiple values and which >> are not already accessible natively, it can do anything you can do in C. >> > So what you're saying is; > Code it in C, then write some more code so that the third layer of code > you write (the perl script) can access the code you wrote first. So what I'm saying is that for most cases you don't need C. Take a look at the perl plugins. NONE of them make use of C-code modules that I know of. In the few cases you need a module to access a syscall, somebody has already written it for you. We can say the same thing about any non-standard C libraries you use that were written by others. > How does this make development time faster and more efficient? Most competent programmers understand that programmers generate the same average number of *fully* debugged lines of code a day no matter which language they write in. It is left as an exercise for the reader to compute the average code-density ratio of perl and C. > Those same functions can be called and linked from any C program > without the intermittent layer and the top-level code. You can do anything from any language, if you try hard enough. >>> If we set all that aside there is still the issue of having every bug >>> ever intoduced in Perl spread to every plugin written in it >> >> As opposed to every bug ever introduced into the C compiler and >> libraries, > > ... which ALSO fan down into Perl. ROFL. I wondered if you'd fall for that one. I didn't think you were that foolish, but you were. Do you know how much of the perl installation process is devoted to detecting known bugs in operating systems and compilers and finding the secure alternatives? Perl tries hard to avoid hitting on known bugs in OSs and compilers. Perl also does not use every feature in C that a C programmer might use. >> along with every bug introduced by plugin authors being careless with >> buffer overflows and who use printf without a format specification. > > A plugin is not a big thing to audit. Fix the bugs and you're back in the > fast lane again. A plugin is a gigantic thing to audit if you check everything it calls. I remember mentioning to you just how much of the TCP stack is in kernel space these days but I haven't seen a response. However, as Karl pointed out, the important issue is that plugins get written. More people are happy writing them in perl than in C. If you were to put your money where your mouth is and convert all the perl plugins to C then I think they would be accepted. Most of us would prefer a perl plugin that does X than no plugin at all because you insist all plugins be written in C and the people who are confident with C have no interest in X. Some of us live in the real world where things have to get done... >>> (currently mostly temporary filehandling stuff). >> >> For which there are three solutions. One of which is not recommended >> because it relies upon C's tmpfile(3) implementation - which is broken >> on some systems. >> > And should be fixed to be secure and honor the $TMPDIR environment > variable. Perl knows there are problems with some implementations of tmpfile(3). Perl documentation points out the problems. Many C programmers have no idea their vendor ships a broken tmpfile(3). Even if your OS does it right, other people's OSs may not. I'd prefer a solution that works everywhere, not a solution that works only on the OSs I happen to run. A *good* coder works around the limitations of many platforms rather than coding purely for his own platform. Perl simplifies that process by already knowing about many of those problems. >> Anyone who was in a position to know what they were talking about when >> commenting on the deficiencies of perl would know that Nagios does not >> have to run as root to run a setuid script. > > I know that, but how does it work under the hood? If perl (the program) is > invoked every time a precompiled image needs to execute I seriously doubt > the effectiveness of the epn. If it doesn't, then how can it the elevated > privileges of the script be retained? > That's why the epn was mentioned in the follow-up question. Now that's a good question, and one I don't have the answer to since I haven't looked at epn (too unstable for my liking). Embedded perls are usually C programs that call the perl functions needed. I don't see any reason, in principle, why setuid scripts could not be handled by epn, but it would probably get messy with separate instances being forked, and piped communications, and might require some rewriting of the plugin. In practise, the only plugin I have seen that needs to run an external command as another user called sudo. I expect that is possible to conceive of problems that cannot be handled that way. But they can all be worked around. Apache's suexec will *not* run setuid scripts, but I once (reluctantly) wrote a couple of perl scripts that ran under suexec and defeated its checking. It's not rocket science to get around these problems, just a matter of judgement as to whether or not that is the best solution. I warn people who ask for this sort of stuff that they're opening serious security holes and that I strongly advise against it - but if they then insist they want to pay me to do it then that is their concern. > On a personal note; > I really don't like your tone. You dismiss without knowing, you are > arrogant when you should be humble and you are stubborn enough to teach > a mule. You're projecting your own faults onto others. -- Paul Allen Softflare Support From Stanley.Hopcroft at IPAustralia.Gov.AU Thu Apr 1 22:32:06 2004 From: Stanley.Hopcroft at IPAustralia.Gov.AU (Stanley Hopcroft) Date: Thu Apr 1 22:32:06 2004 Subject: [Nagiosplug-devel] check_wins patched for perl framework In-Reply-To: <406A96B4.3010508@cohtech.com>; from howard@cohtech.com on Wed, Mar 31, 2004 at 11:00:20AM +0100 References: <406A96B4.3010508@cohtech.com> Message-ID: <20040402163059.G46375@IPAustralia.Gov.AU> Dear Sir, After a few amendments 1 remove taint checking - doesn't seem to work in the 5.005 env 2 remove probably configure tokens (use lib utils.om; /usr/bin/nmblookup [replace by path of nmblookup]) check_wins.pl works here. However, performance is not as good as 'an old version' of check_wins pc09011> ./check_wins -V check_wins (netsaint-plugins 1.2.9-4) 2.8 The netsaint plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. pc09011> ./check_wins.pl -V check_wins.pl (nagios-plugins 1.4.0alpha2) 1.2 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. pc09011> ~anwsmh/perl/dotime 10 "./check_wins -W wins -D ipaustralia -C ipa01 -C ipa04" Running ./check_wins -W wins -D ipaustralia -C ipa01 -C ipa04 10 times 1 2 3 4 5 6 7 8 9 10 done Avg 1 2 3 4 5 6 7 8 9 10 ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ real 0.091 0.10 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 0.09 user 0.053 0.05 0.05 0.06 0.07 0.06 0.05 0.04 0.06 0.05 0.04 sys 0.017 0.02 0.02 0.01 0.00 0.01 0.02 0.03 0.01 0.02 0.03 pc09011> ~anwsmh/perl/dotime 10 "./check_wins.pl -W wins -D ipaustralia -C ipa01 -C ipa04" Running ./check_wins.pl -W wins -D ipaustralia -C ipa01 -C ipa04 10 times 1 2 3 4 5 6 7 8 9 10 done Avg 1 2 3 4 5 6 7 8 9 10 ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ real 0.164 0.17 0.16 0.16 0.16 0.16 0.16 0.16 0.17 0.17 0.17 user 0.129 0.14 0.12 0.11 0.13 0.14 0.13 0.14 0.14 0.13 0.11 sys 0.015 0.01 0.02 0.03 0.01 0.00 0.01 0.01 0.01 0.02 0.03 pc09011> -- ------------------------------------------------------------------------ Stanley Hopcroft ------------------------------------------------------------------------ '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. From Stanley.Hopcroft at IPAustralia.Gov.AU Thu Apr 1 23:04:01 2004 From: Stanley.Hopcroft at IPAustralia.Gov.AU (Stanley Hopcroft) Date: Thu Apr 1 23:04:01 2004 Subject: [Nagiosplug-devel] check_ms_spooler modified for perl framework In-Reply-To: <4069E1B2.3010301@cohtech.com>; from howard@cohtech.com on Tue, Mar 30, 2004 at 10:08:02PM +0100 References: <4069E1B2.3010301@cohtech.com> Message-ID: <20040402170245.H46375@IPAustralia.Gov.AU> Dear Sir, Here is a patch for check_ms_spooler.pl without which the output is many lines of unhelpful info from the spooler. pc09011> ./check_ms_spooler.pl.orig -H ipaprint -u foo -p bar | & head -c 480 Ok. Connected to 17 queues on //ipaprint. Queues BW02: Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] IT02: Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] N001: Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] Domain=[IPAUSTRALIA] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]pc09011> --- check_ms_spooler.pl.orig Fri Apr 2 16:58:53 2004 +++ check_ms_spooler.pl Fri Apr 2 16:53:24 2004 @@ -205,10 +205,12 @@ # Howard Wilkinson # Remove added interface messages our machines have 1000's. - foreach my $result (@tresults) { - next if ($result =~ m/^added interface/i); - push @results, $result; - } + # foreach my $result (@tresults) { + # next if ($result =~ m/^added interface/i); + # push @results, $result; + # } + + @results = grep !/^added interface/i, @tresults ; print STDERR "\"@results\"\n" if $debug ; Performance is not as big an issue with this plugin as check_wins; since the elapsed time is bounded below by the sum of spooler response times, this plugin runs about the as slowly as one without the framework. pc09011> ~anwsmh/perl/dotime 10 "./check_ms_spooler.pl -H ipaprint -u foo -p bar" Running ./check_ms_spooler.pl -H ipaprint -u helpdesk -p helpme 10 times 1 2 3 4 5 6 7 8 9 10 done Avg 1 2 3 4 5 6 7 8 9 10 ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ real 5.100 4.70 5.28 5.31 4.99 4.97 5.25 4.69 5.27 4.99 5.55 user 0.205 0.22 0.21 0.24 0.20 0.21 0.20 0.17 0.23 0.19 0.18 sys 0.140 0.11 0.14 0.12 0.14 0.12 0.16 0.16 0.12 0.15 0.18 pc09011> ~anwsmh/perl/dotime 10 "./check_ms_spooler -H ipaprint -u foo -p bar" Running ./check_ms_spooler -H ipaprint -u helpdesk -p helpme 10 times 1 2 3 4 5 6 7 8 9 10 done Avg 1 2 3 4 5 6 7 8 9 10 ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ real 4.937 5.19 4.62 4.90 5.17 4.87 5.18 4.65 4.89 4.90 5.00 user 0.137 0.13 0.15 0.12 0.15 0.14 0.16 0.08 0.12 0.16 0.16 sys 0.125 0.13 0.10 0.14 0.12 0.13 0.11 0.17 0.14 0.10 0.11 pc09011> pc09011> ./check_ms_spooler.pl -V check_ms_spooler.pl (nagios-plugins 1.4.0alpha2) 1.1 The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. pc09011> ./check_ms_spooler -V check_ms_spooler (netsaint-plugins 1.2.9-4) 2.5 The netsaint plugins come with ABSOLUTELY NO WARRANTY. You may redistribute copies of the plugins under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. pc09011> -- ------------------------------------------------------------------------ Stanley Hopcroft ------------------------------------------------------------------------ '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. From ae at op5.se Fri Apr 2 01:45:03 2004 From: ae at op5.se (Andreas Ericsson) Date: Fri Apr 2 01:45:03 2004 Subject: [Nagiosplug-devel] Embedded Perl (was check_by_ssh something...) In-Reply-To: <20040402002017.4294.qmail@minnow.softflare.net> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> <20040402002017.4294.qmail@minnow.softflare.net> Message-ID: <406D35BE.3010306@op5.se> Paul L. Allen wrote: >>> Perl has a lot of stuff that C lacks without adding libraries that >>> are not a standard part of C. >> >> But not without perl modules. > > Really? Regexes are a standard part of the perl language, no modules > required. If you want regexes in C you have to hunt out non-standard > (as in not supplied with C compilers and not part of the ANSI standard) > libraries. The same goes for many perl features. > Regexes is sugarcoating for text mangling. Useful indeed, but not strictly necessary. If you want sockets and some other basic necessities you need modules. > C has fairly primitive data structures, but if you grab non-standard > libraries or write your own code you can have the equivalent of perl's > arrays and hashes. Etc. > Unions and structs are a part of ANSI. It's perfectly acceptable to have an array of structs containing arrays of structs with arrays of arrays (or whatever) in them, allowing for infinite depth arrays. Hashes are convenient, but not necessary since it's perfectly possible for you to hop the pointer yourself. >>> Stuff that allows perl programmers to be more >>> productive and means they don't have to take care to avoid buffer >>> overflows. >> >> There's always a tradeoff in development time if execution time is >> more important. This is true in perl as well. > > Yes, it is. I wouldn't write an operating system in perl, Correction, noone *could* write an OS in pure perl. In fact, noone can even write an OS in pure C. > and I wouldn't write a plugin in C. Bah. Some plugins should be written in C. Those that parse a lot of text should be written in perl, and those that rely on external commands for their data retrieval (like snmpget and fping) should be written in unix shell (it handles program execution better than perl, since it can fork() instead of execve()). >> So what you're saying is; >> Code it in C, then write some more code so that the third layer of >> code you write (the perl script) can access the code you wrote first. > > So what I'm saying is that for most cases you don't need C. Take a > look at the perl plugins. NONE of them make use of C-code modules that > I know of. The Socket module works with C-code underneath, as does SNMP and File. >> How does this make development time faster and more efficient? > > Most competent programmers understand that programmers generate the > same average number of *fully* debugged lines of code a day no matter > which language they write in. It is left as an exercise for the reader > to compute the average code-density ratio of perl and C. > >> Those same functions can be called and linked from any C program >> without the intermittent layer and the top-level code. > > You can do anything from any language, if you try hard enough. > My point exactly. Why try 'hard enough' to write it in perl if it needs C under the hood any way? >>>> If we set all that aside there is still the issue of having every >>>> bug ever intoduced in Perl spread to every plugin written in it >>> >>> As opposed to every bug ever introduced into the C compiler and >>> libraries, >> >> ... which ALSO fan down into Perl. > > ROFL. I wondered if you'd fall for that one. I didn't think you were > that foolish, but you were. Do you know how much of the perl installation > process is devoted to detecting known bugs in operating systems and > compilers and finding the secure alternatives? Perl tries hard to avoid > hitting on known bugs in OSs and compilers. Perl also does not use every > feature in C that a C programmer might use. > No. I've been writing programs since I was eight but I have never installed perl (doh!). On a serious note though; Do you know how many bugs and potential bugs me and the other Owl developers have fixed in perl 5.8.3? Last time I checked we were at patch-level 23 (each patch fixes 3 or more bugs). Patches have been submitted, but it's a serious load of code so I'm thinking it'll be a while until they're allowed in the tree. Also, we value security above functionality, which isn't always functional enough for the kind of ad-hockery many perl programmers (read script kiddies) indulge in. >>> along with every bug introduced by plugin authors being careless with >>> buffer overflows and who use printf without a format specification. >> >> A plugin is not a big thing to audit. Fix the bugs and you're back in >> the fast lane again. > > A plugin is a gigantic thing to audit if you check everything it calls. Ofcourse. Hence the kernel, glibc and gcc audit, but that's a one-time penalty. Auditing a perl plugin makes the one-time penalty even worse, since it requires auditing of perl itself as well (not to mention the modules it uses). > I remember mentioning to you just how much of the TCP stack is in kernel > space these days but I haven't seen a response. What do you want me to respond to? You weren't asking me anything if I remember things correctly, merely stating that it was (which is true, so I don't have a respond for that). Besides, perl is as vulnerable as anything to kernel bugs. > However, as Karl pointed out, the important issue is that plugins get > written. More people are happy writing them in perl than in C. > If you were to put your money where your mouth is and convert all the > perl plugins to C then I think they would be accepted. I do that for plugins we use which run terribly slow in perl. I'll post them on our website as soon as I get green light from the boss (copyright stuff). Right now I'm working on nrpe, and creating an acceptable nrpe-client for vms systems. This work is derived from code already under the GPL license, so no copyright issues apply. > A *good* coder works around the limitations of many platforms rather > than coding purely for his own platform. Perl simplifies that process > by already knowing about many of those problems. > You put too much faith in Larry Wall et al. Also, a false sense of security is worse than real sense of insecurity. >> I know that, but how does it work under the hood? If perl (the >> program) is invoked every time a precompiled image needs to execute I >> seriously doubt the effectiveness of the epn. If it doesn't, then how >> can it the elevated privileges of the script be retained? > Now that's a good question, and one I don't have the answer to since > I haven't looked at epn (too unstable for my liking). Embedded perls > are usually C programs that call the perl functions needed. If it works as I think would seem logical (for it to be a real speedup); The perl EPN calls perl once to compile the script and then caches the executable image. When it's time to run it, it vfork()'s and execve()'s and points the instruction pointer to the executable image and things run as expected. If the above is wrong, then please correct me. If it's not, the following questions arise. Is this accomplished using trampoline calls or some voodoo I'm not aware of? How does kernel patches preventing an executable stack affect this? Is the EPN capable of sharing perl functions (truly amazing if it is)? If not, how much memory does each script consume at a bare minimum? Will problems arise if we're running lots of different checks, and how can we prevent nagios from bringing the system to kneel from memory exhaustion? > I don't > see any reason, in principle, why setuid scripts could not be handled > by epn, but it would probably get messy with separate instances being > forked, and piped communications, and might require some rewriting of the > plugin. If it works as guessed above, there's no way setuid plugins can be handled. > In practise, the only plugin I have seen that needs to run > an external command as another user called sudo. Which means a legitimate sudo call will exist on the stack (free fire zone). Some input from the EPN author would be much appreciated here. Preferrably in low-level teach-speak, so we get all the details. > I expect that is possible to conceive of problems that cannot be > handled that way. But they can all be worked around. Yes, but at what cost? Do we need to mark certain scripts as unsafe for the EPN, and how do we go about doing that? Config variables in nagior, or with shell-scripts wrapped around them? Will the EPN be able to detect when programs as opposed to perl builtins are being called, and how much code (most likely non-trivial such) would that lead to? -- Mvh / Best regards Sourcerer / Andreas Ericsson OP5 AB +46 (0)733 709032 andreas.ericsson at op5.se From pla at softflare.com Fri Apr 2 04:11:13 2004 From: pla at softflare.com (Paul L. Allen) Date: Fri Apr 2 04:11:13 2004 Subject: [Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...) In-Reply-To: <406D35BE.3010306@op5.se> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> <20040402002017.4294.qmail@minnow.softflare.net> <406D35BE.3010306@op5.se> Message-ID: <20040402121033.19201.qmail@minnow.softflare.net> Andreas Ericsson writes: > Regexes is sugarcoating for text mangling. Useful indeed, but not strictly > necessary. You can write everything in assembler if you want to. Lots more lines of code so it takes a lot longer to write and there are likely to be proportionately more bugs. You can write C to do text matching, but it's a lot easier if you have a regex library. Or if you use perl. > Unions and structs are a part of ANSI. It's perfectly acceptable to have > an array of structs containing arrays of structs with arrays of arrays (or > whatever) in them, allowing for infinite depth arrays. Gosh, you have unions and structs. Ah well, that's everything you'll ever need. > Hashes are convenient, but not necessary since it's perfectly possible > for you to hop the pointer yourself. Hashes are not just convenient, they solve many problems that would scale badly and run very slowly without them. Of course, you can write your own hash code, but good hashing code is difficult to write. Or you could find a C library. Or you could use perl. > Bah. Some plugins should be written in C. Those that parse a lot of text > should be written in perl, and those that rely on external commands for > their data retrieval (like snmpget and fping) should be written in unix > shell (it handles program execution better than perl, since it can fork() > instead of execve()). And if you rely on external commands that generate a lot of text that you have to parse? >> So what I'm saying is that for most cases you don't need C. Take a >> look at the perl plugins. NONE of them make use of C-code modules that >> I know of. > > The Socket module works with C-code underneath, as does SNMP and File. The socket module is part of the standard distribution. Perl is written in C. Neither of those facts mean that it is sensible to rewrite perl plugins in C just because perl is written in C. >> Most competent programmers understand that programmers generate the >> same average number of *fully* debugged lines of code a day no matter >> which language they write in. It is left as an exercise for the reader >> to compute the average code-density ratio of perl and C. >> >>> Those same functions can be called and linked from any C program without >>> the intermittent layer and the top-level code. With many more lines of code needed to do so, especially if you need text mangling. I made the point about productivity and your response ignored it. >> You can do anything from any language, if you try hard enough. >> > My point exactly. Why try 'hard enough' to write it in perl if it needs C > under the hood any way? Why work hard to code something in many lines of C that could be done in a few lines of perl? BTW, code generated in C is just a bunch of opcodes and data. Why write it in C when it's just opcodes under the hood? Why not write raw machine instructions? > On a serious note though; Do you know how many bugs and potential bugs me > and the other Owl developers have fixed in perl 5.8.3? Last time I checked > we were at patch-level 23 (each patch fixes 3 or more bugs). Patches have > been submitted, but it's a serious load of code so I'm thinking it'll be a > while until they're allowed in the tree. You're doing a good job with the patches. But, as you admit, you've submitted patches for other things like Apache. You may have the luxury of not running Apache until you've done a thorough audit and fixed all the holes, most people don't. The same thing goes for perl. > Also, we value security above functionality, which isn't always > functional enough for the kind of ad-hockery many perl programmers > (read script kiddies) indulge in. Yeah, script kiddies like the programmers for the Swedish state pension scheme. After the main project code went way off schedule, some of these "script kiddies" knocked up some code in perl as an interim system. It worked so well that the main project code was dropped and the interim perl code upgraded to have all the functionality in the spec. The perl code took a small fraction of the time to write that had already been spent on the main code. >> A plugin is a gigantic thing to audit if you check everything it calls. > > Ofcourse. Hence the kernel, glibc and gcc audit, but that's a one-time > penalty. The penalty can be amortized over everything you run, but it's a large penalty. And it's a moving target unless you intend to stick to that version forever. > Auditing a perl plugin makes the one-time penalty even worse, since it > requires auditing of perl itself as well (not to mention the modules it > uses). That's a fair point. But given the choice between a plugin that does what I need written in perl or no plugin at all, I take the former. >> I remember mentioning to you just how much of the TCP stack is in kernel >> space these days but I haven't seen a response. > > What do you want me to respond to? You weren't asking me anything if I > remember things correctly, merely stating that it was (which is true, so I > don't have a respond for that). The point is that most of the stack runs in kernel space and is therefore a potential vulnerability. Yet another thing to audit. > Besides, perl is as vulnerable as anything to kernel bugs. And C isn't? Hint: perl is written in C. So if you can write something in perl that's vulnerable to a kernel bug you can write the same thing in C with the same vulnerability. >> A *good* coder works around the limitations of many platforms rather >> than coding purely for his own platform. Perl simplifies that process >> by already knowing about many of those problems. >> > You put too much faith in Larry Wall et al. The same faith I put into linux and apache. I know that they are going to contain bugs but they are better than the alternatives. I know that open source development means they are likely to improve. I know that they may contain bugs, but in the end I need an OS and webserver. > Also, a false sense of security is worse than real sense of insecurity. I don't trust any software to be secure. Short of disconnecting servers from the internet, there isn't much I can do to be confident I am totally secure. Unlike you, I don't believe that your patches will make any of these things totally secure because I don't fool myself that I can think of every possible vulnerability or that totally new exploit mechanisms will never be found. >> In practise, the only plugin I have seen that needs to run >> an external command as another user called sudo. > > Which means a legitimate sudo call will exist on the stack (free fire > zone). Are you advocating setuid as a safer alternative? > Yes, but at what cost? Do we need to mark certain scripts as unsafe for > the EPN, and how do we go about doing that? Config variables in nagior, or > with shell-scripts wrapped around them? How about separate directories? -- Paul Allen Softflare Support From ae at op5.se Fri Apr 2 05:17:04 2004 From: ae at op5.se (Andreas Ericsson) Date: Fri Apr 2 05:17:04 2004 Subject: [Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...) In-Reply-To: <20040402121033.19201.qmail@minnow.softflare.net> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> <20040402002017.4294.qmail@minnow.softflare.net> <406D35BE.3010306@op5.se> <20040402121033.19201.qmail@minnow.softflare.net> Message-ID: <406D65D8.4040506@op5.se> Paul L. Allen wrote: >> Unions and structs are a part of ANSI. It's perfectly acceptable to >> have an array of structs containing arrays of structs with arrays of >> arrays (or whatever) in them, allowing for infinite depth arrays. > > Gosh, you have unions and structs. Ah well, that's everything you'll ever > need. > For functionality, yes. >> Hashes are convenient, but not necessary since it's perfectly possible >> for you to hop the pointer yourself. > > Hashes are not just convenient, they solve many problems that would scale > badly and run very slowly without them. If the code is written properly, scaling is not a problem. If it isn't, no language in the world will do the trick for you. > Of course, you can write your own > hash code, but good hashing code is difficult to write. Or you could find > a C library. Or you could use perl. > Enter simple mathematics. I argue that good hashing code is trivial to write as long as it has been properly implemented from the beginning. >> Bah. Some plugins should be written in C. Those that parse a lot of >> text should be written in perl, and those that rely on external >> commands for their data retrieval (like snmpget and fping) should be >> written in unix shell (it handles program execution better than perl, >> since it can fork() instead of execve()). > > And if you rely on external commands that generate a lot of text that you > have to parse? > man grep man sed man awk man cut >>> So what I'm saying is that for most cases you don't need C. Take a >>> look at the perl plugins. NONE of them make use of C-code modules that >>> I know of. >> >> The Socket module works with C-code underneath, as does SNMP and File. > > The socket module is part of the standard distribution. Perl is written > in C. Neither of those facts mean that it is sensible to rewrite perl > plugins in C just because perl is written in C. > SNMP is not, but I guess you missed that. Also, if I read Karl's comments on the perl framework correctly, it has almost grown out of its own usefulness. >>> Most competent programmers understand that programmers generate the >>> same average number of *fully* debugged lines of code a day no matter >>> which language they write in. It is left as an exercise for the reader >>> to compute the average code-density ratio of perl and C. >>> >>>> Those same functions can be called and linked from any C program >>>> without the intermittent layer and the top-level code. > > With many more lines of code needed to do so, especially if you need > text mangling. I made the point about productivity and your response > ignored it. > By reducing the intermittent code layers production times will drop. In what way did I ignore the productivity issues? >>> You can do anything from any language, if you try hard enough. >> >> My point exactly. Why try 'hard enough' to write it in perl if it >> needs C under the hood any way? > > Why work hard to code something in many lines of C that could be done in > a few lines of perl? BTW, code generated in C is just a bunch of > opcodes and data. Why write it in C when it's just opcodes under the > hood? Why not write raw machine instructions? > Now you're just being silly. >> On a serious note though; Do you know how many bugs and potential bugs >> me and the other Owl developers have fixed in perl 5.8.3? Last time I >> checked we were at patch-level 23 (each patch fixes 3 or more bugs). >> Patches have been submitted, but it's a serious load of code so I'm >> thinking it'll be a while until they're allowed in the tree. > > You're doing a good job with the patches. But, as you admit, you've > submitted patches for other things like Apache. You may have the luxury > of not running Apache until you've done a thorough audit and fixed all > the holes, most people don't. The same thing goes for perl. > Are you expecting a reply to this? >> Also, we value security above functionality, which isn't always >> functional enough for the kind of ad-hockery many perl programmers >> (read script kiddies) indulge in. > > Yeah, script kiddies like the programmers for the Swedish state pension > scheme. After the main project code went way off schedule, some of these > "script kiddies" knocked up some code in perl as an interim system. It > worked so well that the main project code was dropped and the interim > perl code upgraded to have all the functionality in the spec. The perl > code took a small fraction of the time to write that had already been > spent on the main code. > many != all Are you making this up, btw? I live and work in sweden but I've never seen this pension scheme, or any news or anything about it. >> Auditing a perl plugin makes the one-time penalty even worse, since it >> requires auditing of perl itself as well (not to mention the modules >> it uses). > > That's a fair point. But given the choice between a plugin that does > what I need written in perl or no plugin at all, I take the former. > Already discussed and agreed upon. >>> I remember mentioning to you just how much of the TCP stack is in kernel >>> space these days but I haven't seen a response. >> >> What do you want me to respond to? You weren't asking me anything if I >> remember things correctly, merely stating that it was (which is true, >> so I don't have a respond for that). > > The point is that most of the stack runs in kernel space and is therefore > a potential vulnerability. Yet another thing to audit. > Do you think I mainly spent my time working on IDE-drivers while auditing the kernel? >> Besides, perl is as vulnerable as anything to kernel bugs. > > And C isn't? Hint: perl is written in C. So if you can write something > in perl that's vulnerable to a kernel bug you can write the same thing in > C with the same vulnerability. > 'as vulnerable as anything' wasn't there for rhetorical reasons. >>> A *good* coder works around the limitations of many platforms rather >>> than coding purely for his own platform. Perl simplifies that process >>> by already knowing about many of those problems. >> >> You put too much faith in Larry Wall et al. > > The same faith I put into linux and apache. I know that they are going > to contain bugs but they are better than the alternatives. I know that > open source development means they are likely to improve. I know that > they may contain bugs, but in the end I need an OS and webserver. > And I'll be happy to provide both. Actually, it's more than just likely that some of the code you rely on was written by me, or based off of work I put into it. Fun, eh? >> Also, a false sense of security is worse than real sense of insecurity. > > I don't trust any software to be secure. Short of disconnecting servers > from the internet, there isn't much I can do to be confident I am > totally secure. Unlike you, I don't believe that your patches will > make any of these things totally secure because I don't fool myself that > I can think of every possible vulnerability or that totally new exploit > mechanisms will never be found. I don't believe they will make me totally secure. I believe they will make me more secure than I would have been without them. > >>> In practise, the only plugin I have seen that needs to run >>> an external command as another user called sudo. >> >> Which means a legitimate sudo call will exist on the stack (free fire >> zone). > > Are you advocating setuid as a safer alternative? > No, I suggest the script calling sudo shouldn't be cached. If it is then evey instance of nagios will have an easy shot at a vulnerability in its stack. >> Yes, but at what cost? Do we need to mark certain scripts as unsafe >> for the EPN, and how do we go about doing that? Config variables in >> nagior, or with shell-scripts wrapped around them? > > How about separate directories? Should work out ok. Then we'd only have to add one new variable to the main configuration file. 'perl_safe_cache_dir' or something. Code could be kept rather clean (well, not any messier than it is at least) and consistent, and everybody would be happy. -- Mvh Andreas Ericsson OP5 AB +46 (0)733 709032 andreas.ericsson at op5.se From dmozingo at topechelon.com Fri Apr 2 06:38:12 2004 From: dmozingo at topechelon.com (Darrell Mozingo) Date: Fri Apr 2 06:38:12 2004 Subject: [Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...) In-Reply-To: <406D65D8.4040506@op5.se> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> <20040402002017.4294.qmail@minnow.softflare.net> <406D35BE.3010306@op5.se> <20040402121033.19201.qmail@minnow.softflare.net> <406D65D8.4040506@op5.se> Message-ID: <1080915356.4133.14.camel@localhost> You guys mind discussing your language flame war between each other? I'm tired of getting these messages, they're not why I signed up to the mailing list. Darrell Mozingo On Fri, 2004-04-02 at 08:08, Andreas Ericsson wrote: > Paul L. Allen wrote: > >> Unions and structs are a part of ANSI. It's perfectly acceptable to > >> have an array of structs containing arrays of structs with arrays of > >> arrays (or whatever) in them, allowing for infinite depth arrays. > > > > Gosh, you have unions and structs. Ah well, that's everything you'll ever > > need. > > > For functionality, yes. > > >> Hashes are convenient, but not necessary since it's perfectly possible > >> for you to hop the pointer yourself. > > > > Hashes are not just convenient, they solve many problems that would scale > > badly and run very slowly without them. > > If the code is written properly, scaling is not a problem. If it isn't, > no language in the world will do the trick for you. > > > Of course, you can write your own > > hash code, but good hashing code is difficult to write. Or you could find > > a C library. Or you could use perl. > > > Enter simple mathematics. I argue that good hashing code is trivial to > write as long as it has been properly implemented from the beginning. > > >> Bah. Some plugins should be written in C. Those that parse a lot of > >> text should be written in perl, and those that rely on external > >> commands for their data retrieval (like snmpget and fping) should be > >> written in unix shell (it handles program execution better than perl, > >> since it can fork() instead of execve()). > > > > And if you rely on external commands that generate a lot of text that you > > have to parse? > > > man grep > man sed > man awk > man cut > > >>> So what I'm saying is that for most cases you don't need C. Take a > >>> look at the perl plugins. NONE of them make use of C-code modules that > >>> I know of. > >> > >> The Socket module works with C-code underneath, as does SNMP and File. > > > > The socket module is part of the standard distribution. Perl is written > > in C. Neither of those facts mean that it is sensible to rewrite perl > > plugins in C just because perl is written in C. > > > SNMP is not, but I guess you missed that. Also, if I read Karl's > comments on the perl framework correctly, it has almost grown out of its > own usefulness. > > >>> Most competent programmers understand that programmers generate the > >>> same average number of *fully* debugged lines of code a day no matter > >>> which language they write in. It is left as an exercise for the reader > >>> to compute the average code-density ratio of perl and C. > >>> > >>>> Those same functions can be called and linked from any C program > >>>> without the intermittent layer and the top-level code. > > > > With many more lines of code needed to do so, especially if you need > > text mangling. I made the point about productivity and your response > > ignored it. > > > By reducing the intermittent code layers production times will drop. In > what way did I ignore the productivity issues? > > >>> You can do anything from any language, if you try hard enough. > >> > >> My point exactly. Why try 'hard enough' to write it in perl if it > >> needs C under the hood any way? > > > > Why work hard to code something in many lines of C that could be done in > > a few lines of perl? BTW, code generated in C is just a bunch of > > opcodes and data. Why write it in C when it's just opcodes under the > > hood? Why not write raw machine instructions? > > > Now you're just being silly. > > >> On a serious note though; Do you know how many bugs and potential bugs > >> me and the other Owl developers have fixed in perl 5.8.3? Last time I > >> checked we were at patch-level 23 (each patch fixes 3 or more bugs). > >> Patches have been submitted, but it's a serious load of code so I'm > >> thinking it'll be a while until they're allowed in the tree. > > > > You're doing a good job with the patches. But, as you admit, you've > > submitted patches for other things like Apache. You may have the luxury > > of not running Apache until you've done a thorough audit and fixed all > > the holes, most people don't. The same thing goes for perl. > > > Are you expecting a reply to this? > > >> Also, we value security above functionality, which isn't always > >> functional enough for the kind of ad-hockery many perl programmers > >> (read script kiddies) indulge in. > > > > Yeah, script kiddies like the programmers for the Swedish state pension > > scheme. After the main project code went way off schedule, some of these > > "script kiddies" knocked up some code in perl as an interim system. It > > worked so well that the main project code was dropped and the interim > > perl code upgraded to have all the functionality in the spec. The perl > > code took a small fraction of the time to write that had already been > > spent on the main code. > > > many != all > Are you making this up, btw? I live and work in sweden but I've never > seen this pension scheme, or any news or anything about it. > > >> Auditing a perl plugin makes the one-time penalty even worse, since it > >> requires auditing of perl itself as well (not to mention the modules > >> it uses). > > > > That's a fair point. But given the choice between a plugin that does > > what I need written in perl or no plugin at all, I take the former. > > > Already discussed and agreed upon. > > >>> I remember mentioning to you just how much of the TCP stack is in kernel > >>> space these days but I haven't seen a response. > >> > >> What do you want me to respond to? You weren't asking me anything if I > >> remember things correctly, merely stating that it was (which is true, > >> so I don't have a respond for that). > > > > The point is that most of the stack runs in kernel space and is therefore > > a potential vulnerability. Yet another thing to audit. > > > Do you think I mainly spent my time working on IDE-drivers while > auditing the kernel? > > >> Besides, perl is as vulnerable as anything to kernel bugs. > > > > And C isn't? Hint: perl is written in C. So if you can write something > > in perl that's vulnerable to a kernel bug you can write the same thing in > > C with the same vulnerability. > > > 'as vulnerable as anything' wasn't there for rhetorical reasons. > > >>> A *good* coder works around the limitations of many platforms rather > >>> than coding purely for his own platform. Perl simplifies that process > >>> by already knowing about many of those problems. > >> > >> You put too much faith in Larry Wall et al. > > > > The same faith I put into linux and apache. I know that they are going > > to contain bugs but they are better than the alternatives. I know that > > open source development means they are likely to improve. I know that > > they may contain bugs, but in the end I need an OS and webserver. > > > And I'll be happy to provide both. Actually, it's more than just likely > that some of the code you rely on was written by me, or based off of > work I put into it. Fun, eh? > > >> Also, a false sense of security is worse than real sense of insecurity. > > > > I don't trust any software to be secure. Short of disconnecting servers > > from the internet, there isn't much I can do to be confident I am > > totally secure. Unlike you, I don't believe that your patches will > > make any of these things totally secure because I don't fool myself that > > I can think of every possible vulnerability or that totally new exploit > > mechanisms will never be found. > > I don't believe they will make me totally secure. I believe they will > make me more secure than I would have been without them. > > > > >>> In practise, the only plugin I have seen that needs to run > >>> an external command as another user called sudo. > >> > >> Which means a legitimate sudo call will exist on the stack (free fire > >> zone). > > > > Are you advocating setuid as a safer alternative? > > > No, I suggest the script calling sudo shouldn't be cached. If it is then > evey instance of nagios will have an easy shot at a vulnerability in its > stack. > > >> Yes, but at what cost? Do we need to mark certain scripts as unsafe > >> for the EPN, and how do we go about doing that? Config variables in > >> nagior, or with shell-scripts wrapped around them? > > > > How about separate directories? > > Should work out ok. Then we'd only have to add one new variable to the > main configuration file. 'perl_safe_cache_dir' or something. Code could > be kept rather clean (well, not any messier than it is at least) and > consistent, and everybody would be happy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pla at softflare.com Fri Apr 2 13:26:01 2004 From: pla at softflare.com (Paul L. Allen) Date: Fri Apr 2 13:26:01 2004 Subject: [Nagiosplug-devel] Re: Embedded Perl (was check_by_ssh something...) In-Reply-To: <406D65D8.4040506@op5.se> References: <4069C92C.40000@cohtech.com> <20040331015144.0a293d0e.karl@debisschop.net> <406A80A5.8090704@cohtech.com> <20040331074913.019de845.karl@debisschop.net> <406AC697.8080509@op5.se> <20040331154532.27457.qmail@minnow.softflare.net> <406AFAE5.7010908@op5.se> <20040402002017.4294.qmail@minnow.softflare.net> <406D35BE.3010306@op5.se> <20040402121033.19201.qmail@minnow.softflare.net> <406D65D8.4040506@op5.se> Message-ID: <20040402212512.19947.qmail@minnow.softflare.net> Andreas Ericsson writes: > Paul L. Allen wrote: > For functionality, yes. For functionality all you need is shorts. You can build everything up from those. It's just hard work. I made this point earlier when suggestion writing opcodes. It can be done, but why would you want to? Considering how many C programmers overflow fixed buffers and walk off the end of arrays when they try to build a data structure of a type offered natively by perl but not by C, richer data structures with protecion a part of the language can be a distinct advantage. Especially when you need to write something quickly. >> Hashes are not just convenient, they solve many problems that would scale >> badly and run very slowly without them. > > If the code is written properly, scaling is not a problem. If it isn't, no > language in the world will do the trick for you. Having a language that has hashes as a native data structure takes the hard work away from you. Sometimes you can gain a bit of efficiency by using other methods, but you're trading increased programmer time for decreased execution time. >> Of course, you can write your own hash code, but good hashing code is >> difficult to write. Or you could find a C library. Or you could use >> perl. >> > Enter simple mathematics. I argue that good hashing code is trivial to > write as long as it has been properly implemented from the beginning. It's trivial to write. It's somewhat harder to write well. Perl's hashing function has changed over the years both to accommodate a tendency for people to use larger hashes and to adopt a new hashing algorithm that somebody came up with. >>> Bah. Some plugins should be written in C. Those that parse a lot of text >>> should be written in perl, and those that rely on external commands for >>> their data retrieval (like snmpget and fping) should be written in unix >>> shell (it handles program execution better than perl, since it can >>> fork() instead of execve()). >> >> And if you rely on external commands that generate a lot of text that you >> have to parse? >> > man grep > man sed > man awk > man cut Ah. And this comes from the man who says we should write modules in C because perl is C under the hood. But when it comes to a task involving text mangling he advocates a mix of shell (written in C), grep (written in C), sed (written in C), awk (written in C) and cut (written in C). They're all C under the hood, so you should write your plugin in C in the first place. >>> The Socket module works with C-code underneath, as does SNMP and File. >> >> The socket module is part of the standard distribution. Perl is written >> in C. Neither of those facts mean that it is sensible to rewrite perl >> plugins in C just because perl is written in C. >> > SNMP is not, but I guess you missed that. It's not part of the standard perl distribution. That isn't a justification for your stance of "anything but perl." The SNMP module has been written. The check_if plugin has been written. They work. If I want to do any SNMP checks I'll be using them rather than re-inventing the wheel. If somebody writes a C version of the plugin then I'll have a choice of two wheels. I suspect the perl wheel will give a smoother, if slower, ride. > Also, if I read Karl's comments on the perl framework correctly, it has > almost grown out of its own usefulness. If I read his comments correctly, perl is the preferred language for plugins. The question is whether or not a new framework is going to be adopted. The new framework has distinct advantages but the guy who developed it needs more output for his own use. I would think a command-line switch to get more output with the default being current behaviour would fix that. >> With many more lines of code needed to do so, especially if you need >> text mangling. I made the point about productivity and your response >> ignored it. >> > By reducing the intermittent code layers production times will drop. Why would that be true if somebody has already written the intermediate layers? If you had to write the intermediate layer yourself then perhaps it would be faster to write in C - it depends on how much hard work is being done in the plugin, how much code is needed in the intermediate layer, etc.. >>> My point exactly. Why try 'hard enough' to write it in perl if it needs >>> C under the hood any way? >> >> Why work hard to code something in many lines of C that could be done in >> a few lines of perl? BTW, code generated in C is just a bunch of >> opcodes and data. Why write it in C when it's just opcodes under the >> hood? Why not write raw machine instructions? >> > Now you're just being silly. No, I'm making a point. You can do anything you want in raw machine instructions. Most people would find assembly language more productive. Most people would find C more productive than assembly. Most people would find perl more productive than C. My boss loves Java but cannot get his head around regexes, so he knows that when serious text mangling is involved I can knock up a few lines of perl that would take him many dozens of lines of Java. I'd do it in Java using one of the regex classes available but they don't integrate as closely with the rest of the language as regexes in perl. >> You're doing a good job with the patches. But, as you admit, you've >> submitted patches for other things like Apache. You may have the luxury >> of not running Apache until you've done a thorough audit and fixed all >> the holes, most people don't. The same thing goes for perl. >> > Are you expecting a reply to this? I'm pointing out that most people don't have the luxury of refusing to use stuff that they haven't personally audited to the finest detail. You may call them stupid, but they don't have the budget you clearly do, nor the business requirements driving that level of security- consciousness. Their business may go down the tubes if they're hacked, as may yours, but in absolute terms the potential losses and the low profit margins mean they have to accept the risks. They're not stupid because they don't vet code to the degree you do, they're being realistic about what they can afford to do and hoping that the white hats find and fix holes before the black hats exploit them. > Are you making this up, btw? I live and work in sweden but I've never seen > this pension scheme, or any news or anything about it. Take a look at . >> The point is that most of the stack runs in kernel space and is therefore >> a potential vulnerability. Yet another thing to audit. >> > Do you think I mainly spent my time working on IDE-drivers while auditing > the kernel? I hope not. >>> Besides, perl is as vulnerable as anything to kernel bugs. >> >> And C isn't? Hint: perl is written in C. So if you can write something >> in perl that's vulnerable to a kernel bug you can write the same thing in >> C with the same vulnerability. >> > 'as vulnerable as anything' wasn't there for rhetorical reasons. Sorry, I thought you had were using an English idiom. "Does 'x' like anything" is a slightly out-of-fashion way of saying something excels at doing 'x'. "I put a V8 engine in my volkswagen beetle and now it goes like anything." The "like anything" means "like anything else that is considered to be a top performer" not "like anything else you can think of because they are all equal." >> The same faith I put into linux and apache. I know that they are going >> to contain bugs but they are better than the alternatives. I know that >> open source development means they are likely to improve. I know that >> they may contain bugs, but in the end I need an OS and webserver. >> > And I'll be happy to provide both. Actually, it's more than just likely > that some of the code you rely on was written by me, or based off of work > I put into it. Fun, eh? I can't recall seeing your name as the author or team lead of anything I rely on, nor in the cast of characters. But then I rarely look at the credits. >> I don't trust any software to be secure. Short of disconnecting servers >> from the internet, there isn't much I can do to be confident I am >> totally secure. Unlike you, I don't believe that your patches will >> make any of these things totally secure because I don't fool myself that >> I can think of every possible vulnerability or that totally new exploit >> mechanisms will never be found. > > I don't believe they will make me totally secure. I believe they will make > me more secure than I would have been without them. At last we converge upon agreement. Now please accept that unlike you, I don't have the luxury of pulling the plug on stuff I haven't vetted in great detail, nor do I have the budget to vet stuff to that level. Nor do most people. Most big ISPs run Apache. Some big ISPs contribute to Apache development. Even so, you've found holes they missed because they cannot afford to do the sort of exercise your company can. Nor can they simply not deploy Apache until they've vetted it even if they did have the budget. I doubt any of them are happy with the risks they take, but they don't have much option. >> Are you advocating setuid as a safer alternative? >> > No, I suggest the script calling sudo shouldn't be cached. If it is then > evey instance of nagios will have an easy shot at a vulnerability in its > stack. I haven't delved in detail, but I believe an embedded perl can throw off a separate instance of a perl interpreter which can be destroyed after its work is done. All the necessary subroutines are shared but the data structures are separate. So the only overhead in treating such plugins separately would be down to the initialization of the interpreter's data structures. I think, but am not sure, that epn will initialize a different interpreter for each plugin rather than re-using a single interpreter, otherwise the plugin specs would not warn that BEGIN blocks only get run when epn starts. It ought to be able to make the interpreters that handle particular plugins go away after each run instead of being persistent. But I skimmed through the perlembed man page rather quickly, so could well be wrong. -- Paul Allen Softflare Support From Ben at clewett.org.uk Tue Apr 6 07:35:13 2004 From: Ben at clewett.org.uk (Ben Clewett) Date: Tue Apr 6 07:35:13 2004 Subject: [Nagiosplug-devel] Problem with check_mysql Message-ID: <4072C09B.5080400@clewett.org.uk> I believe there might be a possible error in check_mysql, other than the one I just posted to nagios-help. Just downloaded 1.4.0 alpha1 and tried to 'make'. The program makes ok, but core-dump's on execution. On inspection, I found (around) line 122: if (argc < 1) return ERROR; I believe this should be: if (argc <= 1) return ERROR; It certainly allows the program to run correctly if this is done. Regards, Ben Clewett. From digiover at dsinet.org Tue Apr 6 07:36:26 2004 From: digiover at dsinet.org (Jan Reilink) Date: Tue Apr 6 07:36:26 2004 Subject: [Nagiosplug-devel] check_mailq for qmail Message-ID: <4071B84C.7050905@dsinet.org> Hi, One of the advantages of Nagios, plugins incluis, is that you can monitor servers and services remotely. Looking at the source, check_mailq can only be run locally and in the --help I read: "Feedback/patches to support non-sendmail mailqueue welcome" I am absolutely no programmer (I can read Perl/Bash/C and that's it :$), but I do think I have an option for the qmail mailqueue (and, DBJ himself has it too): /var/qmail/bin/qmail-qstat It is an auto-generated Bash shell script, created during the qmail installation: /var/qmail/bin# file qmail-qstat qmail-qstat: Bourne shell script text executable I do have a version which is ported to Perl, it's not completely correct, sometimes it prints out some slightly different number of messages, but the difference between both is not that big. Because, to my knowledge, check_mailq can only be run localy, it *might* be a nice addition to the Nagios plugins, eventhough it is still a disadvantage you can only use it localy. Fortunaly we have a -qmail based- hack for this too which involves the use of 'tcpserver' and a tiny Bash script. If interested, we can email the sources, they are scripts we made at the office, therefor my different Reply-To address. -- Met vriendelijke groet / Best regards, Jan Reilink VEVIDA Nederland BV - Abuse & Security desk Postbus 329, 9700 AH GRONINGEN, +31(0)50 - 5492234 Private: Dutch Security Information Network, http://www.dsinet.org/ From benny at bennyvision.com Tue Apr 6 07:36:28 2004 From: benny at bennyvision.com (C. Bensend) Date: Tue Apr 6 07:36:28 2004 Subject: [Nagiosplug-devel] Plugin check_http segfaulting on OpenBSD 3.4-STABLE Message-ID: <52474.63.227.74.41.1081213759.squirrel@webmail.stinkweasel.net> Hey folks, I sat down tonight to debug a few issues I've been having with Nagios 2.0a1, and I caught check_http segfaulting when I shut down an Apache server to force an alert from nagios. The service returns to normal (and check_http behaves) when I fire Apache up again. This is with the latest plugins snapshot (from March 29th), on an OpenBSD 3.4-STABLE machine. I captured the following ktrace data (snipped for the interesting bits - if the entire trace is needed, let me know): 9460 check_http RET socket 3 9460 check_http CALL sigprocmask(0x1,0xffffffff) 9460 check_http RET sigprocmask 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x3) 9460 check_http RET mprotect 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x1) 9460 check_http RET mprotect 0 9460 check_http CALL sigprocmask(0x3,0) 9460 check_http RET sigprocmask -65793/0xfffefeff 9460 check_http CALL connect(0x3,0x3c00b060,0x10) 9460 check_http RET connect -1 errno 61 Connection refused 9460 check_http CALL sigprocmask(0x1,0xffffffff) 9460 check_http RET sigprocmask 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x3) 9460 check_http RET mprotect 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x1) 9460 check_http RET mprotect 0 9460 check_http CALL sigprocmask(0x3,0) 9460 check_http RET sigprocmask -65793/0xfffefeff 9460 check_http CALL close(0x3) 9460 check_http RET close 0 9460 check_http CALL sigprocmask(0x1,0xffffffff) 9460 check_http RET sigprocmask 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x3) 9460 check_http RET mprotect 0 9460 check_http CALL mprotect(0x3c005000,0x2000,0x1) 9460 check_http RET mprotect 0 9460 check_http CALL sigprocmask(0x3,0) 9460 check_http RET sigprocmask -65793/0xfffefeff 9460 check_http PSIG SIGSEGV SIG_DFL code 1 addr=0x1c trapno=1 9460 check_http PSIG SIGSEGV SIG_DFL code 0 addr=0x0 trapno=0 9460 check_http NAMI "check_http.core" And this is where the plugin dies. Once I fire Apache back up and ktrace again: 24768 check_http RET mprotect 0 24768 check_http CALL sigprocmask(0x3,0) 24768 check_http RET sigprocmask -65793/0xfffefeff 24768 check_http CALL write(0x1,0x3c00f000,0x60) 24768 check_http GIO fd 1 wrote 96 bytes "HTTP OK HTTP/1.1 200 OK - 2215 bytes in 0.064 seconds |time=0.063799s;\ ;;0.000000 size=2215B;;;0 " 24768 check_http RET write 96/0x60 24768 check_http CALL sigprocmask(0x1,0xffffffff) 24768 check_http RET sigprocmask 0 24768 check_http CALL mprotect(0x3c005000,0x2000,0x3) 24768 check_http RET mprotect 0 24768 check_http CALL mprotect(0x3c005000,0x2000,0x1) 24768 check_http RET mprotect 0 24768 check_http CALL sigprocmask(0x3,0) 24768 check_http RET sigprocmask -65793/0xfffefeff 24768 check_http CALL sigprocmask(0x1,0xffffffff) 24768 check_http RET sigprocmask 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x3) 24768 check_http RET mprotect 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x1) 24768 check_http RET mprotect 0 24768 check_http CALL sigprocmask(0x3,0) 24768 check_http RET sigprocmask -65793/0xfffefeff 24768 check_http CALL sigprocmask(0x1,0xffffffff) 24768 check_http RET sigprocmask 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x3) 24768 check_http RET mprotect 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x1) 24768 check_http RET mprotect 0 24768 check_http CALL sigprocmask(0x3,0) 24768 check_http RET sigprocmask -65793/0xfffefeff 24768 check_http CALL munmap(0x7c008000,0x1000) 24768 check_http RET munmap 0 24768 check_http CALL sigprocmask(0x1,0xffffffff) 24768 check_http RET sigprocmask 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x3) 24768 check_http RET mprotect 0 24768 check_http CALL mprotect(0x286fd000,0x2000,0x1) 24768 check_http RET mprotect 0 24768 check_http CALL sigprocmask(0x3,0) 24768 check_http RET sigprocmask -65793/0xfffefeff 24768 check_http CALL exit(0) I was running plugins from the beginning of March (which behaved the same way), upgrading to the latest didn't help. One thought that came to my mind is that this might be some of OpenBSD's security features kicking in on an iffy piece of code and pre-emptively killing it. I don't find anything in my system logs, but I'll keep looking. Thoughts? Ideas? Cluebats? Benny -- "I can't believe it's not carp!" -- MXC From dmozingo at topechelon.com Tue Apr 6 08:54:02 2004 From: dmozingo at topechelon.com (Darrell Mozingo) Date: Tue Apr 6 08:54:02 2004 Subject: [Nagiosplug-devel] check_mailq for qmail In-Reply-To: <4071B84C.7050905@dsinet.org> References: <4071B84C.7050905@dsinet.org> Message-ID: <1081266677.25107.5.camel@localhost> On Mon, 2004-04-05 at 15:49, Jan Reilink wrote: > Hi, > > One of the advantages of Nagios, plugins incluis, is that you can monitor > servers and services remotely. Looking at the source, check_mailq can only > be run locally and in the --help I read: > "Feedback/patches to support non-sendmail mailqueue welcome" True, but if used with check_by_ssh or check_nrpe, it wouldn't matter, would it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ton.Voon at egg.com Tue Apr 6 09:23:14 2004 From: Ton.Voon at egg.com (Voon, Ton) Date: Tue Apr 6 09:23:14 2004 Subject: [Nagiosplug-devel] Problem with check_mysql Message-ID: Ben, Thanks for the bug report. The --help says that: There are no required arguments. By default, the local database with a server listening on MySQL standard port 3306 will be checked On my server, I get: $ ./check_mysql Access denied for user: 'voont at localhost' (Using password: NO) So I don't think the line is meant to say "if (argc <= 1)". What version of mysql are you using? I'm on 3.23.53. Ton -----Original Message----- From: Ben Clewett [mailto:Ben at clewett.org.uk] Sent: Tuesday, April 06, 2004 3:37 PM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] Problem with check_mysql I believe there might be a possible error in check_mysql, other than the one I just posted to nagios-help. Just downloaded 1.4.0 alpha1 and tried to 'make'. The program makes ok, but core-dump's on execution. On inspection, I found (around) line 122: if (argc < 1) return ERROR; I believe this should be: if (argc <= 1) return ERROR; It certainly allows the program to run correctly if this is done. Regards, Ben Clewett. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Nagiosplug-devel mailing list Nagiosplug-devel at lists.sourceforge.net 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 This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which is authorised and regulated by the Financial Services Authority. Egg Investments Ltd. is entered in the FSA register under number 190518. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From ae at op5.se Tue Apr 6 10:10:20 2004 From: ae at op5.se (Andreas Ericsson) Date: Tue Apr 6 10:10:20 2004 Subject: [Nagiosplug-devel] Problem with check_mysql In-Reply-To: References: Message-ID: <4072E427.7020304@op5.se> Voon, Ton wrote: > Ben, > > Thanks for the bug report. The --help says that: > > There are no required arguments. By default, the local database with > a server listening on MySQL standard port 3306 will be checked > > On my server, I get: > > $ ./check_mysql > Access denied for user: 'voont at localhost' (Using password: NO) > > So I don't think the line is meant to say "if (argc <= 1)". What version of > mysql are you using? I'm on 3.23.53. > In light of the fact that argc NEVER (no, not ever) is < 1, I'm thinking that check could be removed and the discussion dropped right here. > Ton > > -----Original Message----- > From: Ben Clewett [mailto:Ben at clewett.org.uk] > Sent: Tuesday, April 06, 2004 3:37 PM > To: nagiosplug-devel at lists.sourceforge.net > Subject: [Nagiosplug-devel] Problem with check_mysql > > > I believe there might be a possible error in check_mysql, other than the > one I just posted to nagios-help. > > Just downloaded 1.4.0 alpha1 and tried to 'make'. The program makes ok, > but core-dump's on execution. > > On inspection, I found (around) line 122: > > if (argc < 1) > return ERROR; > > I believe this should be: > > if (argc <= 1) > return ERROR; > > It certainly allows the program to run correctly if this is done. > > Regards, > > Ben Clewett. > -- Mvh Andreas Ericsson OP5 AB +46 (0)733 709032 andreas.ericsson at op5.se From noreply at sourceforge.net Tue Apr 6 14:03:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 6 14:03:07 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-876708 ] check_smart.pl - Health-check S.M.A.R.T. disks Message-ID: New Plugins item #876708, was opened at 2004-01-14 10:57 Message generated for change (Comment added) made by ediaz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=876708&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Sigurd Karlsbakk (rkarlsba) Assigned to: Nobody/Anonymous (nobody) Summary: check_smart.pl - Health-check S.M.A.R.T. disks Initial Comment: check_smart interfaces with smartmontools and uses smartctl to check drives. It supports basic health (-H) checks and device type settings, including checking drives on a 3ware controller. Licensed under GPL. ---------------------------------------------------------------------- Comment By: Eduardo Diaz (ediaz) Date: 2004-04-06 15:33 Message: Logged In: YES user_id=36388 I need to change this. print "$e_commandline $e_devopen $e_chksum $e_disk_failing $e_prefail $e_mayprefail $e_errlog $e_selftestlog\n" if ($verbose); $exitcode = 0; $errtxt = ""; if ($exitcode) { if ($e_commandline) { $errtxt .= "Commandline didn't parse, "; $exitcode = 3 if ($exitcode == 0) For this: print "$e_commandline $e_devopen $e_chksum $e_disk_failing $e_prefail $e_mayprefail $e_errlog $e_selftestlog\n" if ($verbose); $exitcode = 0; $errtxt = ""; if ($exitcode || $e_commandline || $e_devopen || $e_chksum || $e_disk_failing || $e_prefail || $e_mayprefail || $e_errlog || $e_selftestlog) { if ($e_commandline) { $errtxt .= "Commandline didn't parse, "; $exitcode = 3 if ($exitcode == 0); } # For detect all errors :-D... ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2004-02-10 14:42 Message: Logged In: YES user_id=145309 Bugfix fixing the plugin so that checking special devices like 3ware controllers actually works ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=876708&group_id=29880 From Ben.Clewett at roadrunner.uk.com Wed Apr 7 05:03:12 2004 From: Ben.Clewett at roadrunner.uk.com (Ben Clewett) Date: Wed Apr 7 05:03:12 2004 Subject: [Nagiosplug-devel] First post. Message-ID: <4072ABD1.40603@roadrunner.uk.com> Posting from a newbe: I have forked a plugin to satisfy IBM's HACMP setup on AIX UNIX. I belive GPL required that I tell you and publish the code. I hope this is correct and I have not offended the origional programmers. It's a fork of check_disk which examins the 'path'. If the path is valid and contains no files, it assumes it's an unmounted disk and returns OK. The origional code will either check the parent file system, or reply "Disk \"%s\" not mounted or nonexistant\n". The requirement to reply OK is for the IBM HACMP high-availability, which mounts and unmounts disks to move resources round. An unmounted disk must reply OK, or most of my servers are listed as in error. I do not know if this compiles under non-AIX OS. However, it used the which does appear on Linux, so the chances are good. Code is attached for anybody who can make use of it. Regards, Ben Clewett. -------------- next part -------------- A non-text attachment was scrubbed... Name: check_hacmp_disk.c.gz Type: application/gzip Size: 3930 bytes Desc: not available URL: From Torsten.Werner at assyst-intl.com Wed Apr 7 05:03:15 2004 From: Torsten.Werner at assyst-intl.com (Torsten.Werner at assyst-intl.com) Date: Wed Apr 7 05:03:15 2004 Subject: [Nagiosplug-devel] patch for check_oracle Message-ID: Hi all, there are two small problems with the script: 1. If a login trigger produces any output, the script fails. The lines to call awk are not clean 2. If Oracle print out numbers with a different national language caracter set it could be, it prints commas instead of dots as decimal sepparator. The shell is not able to interprete it as number apply the patch to check_oracle 1.4.2.2 (nagios-plugins 1.3.1) to fix it: # patch check_oracle < check_oracle.patch Bye Torsten (See attached file: check_oracle.patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: check_oracle.patch Type: application/octet-stream Size: 950 bytes Desc: not available URL: From Ben at clewett.org.uk Thu Apr 8 01:01:01 2004 From: Ben at clewett.org.uk (Ben Clewett) Date: Thu Apr 8 01:01:01 2004 Subject: [Nagiosplug-devel] Quality Metrics In-Reply-To: <4072E427.7020304@op5.se> References: <4072E427.7020304@op5.se> Message-ID: <40750689.1010008@clewett.org.uk> Forgive if asked many times before: The nagios plugins produce many great quality metrics. For instance, load, disk space. These are collected by Nagios and displayed as a textual line. There must be a great need for these to be formally collected, by Nagios or otherwise, to create a quantitative picture of a system. Since the plugins are so close to this, I am interested to know if anybody has formally defined a protocol, or otherwise, to complete this. Eq, as a 'toy' example, including a delimiter (??) in the description, followed bu CGI style variables: $? = 0 DISK OK [21404 kB (26%) free on /dev/hd1] ??disk=/dev/hd1&size=21404&free=26 Regards, Ben Clewett From Ben at clewett.org.uk Thu Apr 8 02:47:06 2004 From: Ben at clewett.org.uk (Ben Clewett) Date: Thu Apr 8 02:47:06 2004 Subject: [Nagiosplug-devel] Quality Metrics In-Reply-To: <40750689.1010008@clewett.org.uk> References: <4072E427.7020304@op5.se> <40750689.1010008@clewett.org.uk> Message-ID: <40751F88.6070102@clewett.org.uk> Sorry, I've been using an old set which compile for AIX. Looking at your modern version for Linux, I see you do exactly this: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185 My final challange is to get this into a MySQL database... Ben :) Ben Clewett wrote: > Forgive if asked many times before: > > The nagios plugins produce many great quality metrics. For instance, > load, disk space. These are collected by Nagios and displayed as a > textual line. > From Ton.Voon at egg.com Thu Apr 8 05:48:23 2004 From: Ton.Voon at egg.com (Voon, Ton) Date: Thu Apr 8 05:48:23 2004 Subject: [Nagiosplug-devel] patch for check_oracle Message-ID: Torsten, Thanks for the patch. Have applied to r1_3_0 and CVS HEAD. Ton -----Original Message----- From: Torsten.Werner at assyst-intl.com [mailto:Torsten.Werner at assyst-intl.com] Sent: Tuesday, April 06, 2004 5:26 PM To: nagiosplug-devel at lists.sourceforge.net Subject: [Nagiosplug-devel] patch for check_oracle Hi all, there are two small problems with the script: 1. If a login trigger produces any output, the script fails. The lines to call awk are not clean 2. If Oracle print out numbers with a different national language caracter set it could be, it prints commas instead of dots as decimal sepparator. The shell is not able to interprete it as number apply the patch to check_oracle 1.4.2.2 (nagios-plugins 1.3.1) to fix it: # patch check_oracle < check_oracle.patch Bye Torsten (See attached file: check_oracle.patch) This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which is authorised and regulated by the Financial Services Authority. Egg Investments Ltd. is entered in the FSA register under number 190518. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. From noreply at sourceforge.net Thu Apr 8 15:37:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 8 15:37:24 2004 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-932066 ] Improved check_inodes script Message-ID: Bugs item #932066, was opened at 2004-04-08 15:36 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=932066&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Quanah Gibson-Mount (mishikal) Assigned to: Nobody/Anonymous (nobody) Summary: Improved check_inodes script Initial Comment: I've taken the check_inodes script that is part of the 1.4 alpha plugins release, and done a major rewrite. It now more closely follows nagios plugin standards, and allows you to check all the partitions on a system for inode use, much like check_disk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=932066&group_id=29880 From sghosh at sghosh.org Fri Apr 9 08:16:01 2004 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Fri Apr 9 08:16:01 2004 Subject: [Nagiosplug-devel] Quality Metrics In-Reply-To: <40750689.1010008@clewett.org.uk> Message-ID: On Thu, 8 Apr 2004, Ben Clewett wrote: > Forgive if asked many times before: > > The nagios plugins produce many great quality metrics. For instance, > load, disk space. These are collected by Nagios and displayed as a > textual line. > > There must be a great need for these to be formally collected, by Nagios > or otherwise, to create a quantitative picture of a system. Since the > plugins are so close to this, I am interested to know if anybody has > formally defined a protocol, or otherwise, to complete this. > > Eq, as a 'toy' example, including a delimiter (??) in the description, > followed bu CGI style variables: > > $? = 0 > > DISK OK [21404 kB (26%) free on /dev/hd1] ??disk=/dev/hd1&size=21404&free=26 > > Regards, Ben Clewett > A formal definition does not exist as yet - but the data is being output on the PERFDATA section of the plugin. The PERFDATA is separated from the visibile OUTPUT by a | and is available for the perfdata handlers. -- -sg From Torsten.Werner at assyst-intl.com Sun Apr 11 05:48:32 2004 From: Torsten.Werner at assyst-intl.com (Torsten.Werner at assyst-intl.com) Date: Sun Apr 11 05:48:32 2004 Subject: [Nagiosplug-devel] patch for check_disk.c Message-ID: Hi, check_disk has a small problem on HP-UX. HP-UX produces 2 lines at 'df -Pk': root at xxxxxx> /usr/bin/df -Pk Filesystem 1024-blocks Used Available Capacity Mounted on ..... /dev/vguser/home 1268596 890624 377972 71% /home /dev/vgroot/JavaWebServer 195393 16688 178705 9% /opt/JavaWebServer1.1.3 /dev/vgde/optassyst 347487 228572 118915 66% /opt/assyst /dev/vgroot/opt 1783990 1580886 203104 89% /opt ...... check_disk is not able to handle this. Apply the patch to check_disk.c 1.7.2.4 (nagios-plugins 1.3.1): $: patch check_disk.c < check_disk.c.patch It's working on HP-UX 10, 11.0 and 11i. Bye Torsten (See attached file: check_disk.c.patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: check_disk.c.patch Type: application/octet-stream Size: 687 bytes Desc: not available URL: From tonvoon at mac.com Sun Apr 11 09:49:12 2004 From: tonvoon at mac.com (Ton Voon) Date: Sun Apr 11 09:49:12 2004 Subject: [Nagiosplug-devel] patch for check_disk.c In-Reply-To: References: Message-ID: Torsten, Thanks for this patch, but we will not be applying it. Release 1.4 uses a different way of querying disks (using GNU coreutils libs), thus removing the peculiarities of df across multiple systems. If you can test the CVS snapshot to confirm it works on HP-UX, that would be very helpful. Regards, Ton On 8 Apr, 2004, at 14:19, Torsten.Werner at assyst-intl.com wrote: > Hi, > check_disk has a small problem on HP-UX. HP-UX produces 2 lines at 'df > -Pk': > > root at xxxxxx> /usr/bin/df -Pk > Filesystem 1024-blocks Used Available Capacity Mounted on > ..... > /dev/vguser/home 1268596 890624 377972 71% /home > /dev/vgroot/JavaWebServer > 195393 16688 178705 9% > /opt/JavaWebServer1.1.3 > /dev/vgde/optassyst > 347487 228572 118915 66% /opt/assyst > /dev/vgroot/opt 1783990 1580886 203104 89% /opt > ...... > > check_disk is not able to handle this. > > Apply the patch to check_disk.c 1.7.2.4 (nagios-plugins 1.3.1): > $: patch check_disk.c < check_disk.c.patch > > It's working on HP-UX 10, 11.0 and 11i. > Bye > Torsten > > (See attached file: check_disk.c.patch) From noreply at sourceforge.net Mon Apr 12 10:19:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 12 10:19:10 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-933760 ] check_insight Message-ID: New Plugins item #933760, was opened at 2004-04-12 17:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=933760&group_id=29880 Category: System monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ruddel (ruddel) Assigned to: Nobody/Anonymous (nobody) Summary: check_insight Initial Comment: There was a problem with the check_insight plugin. When this plugin was started with the integrated perl interpreter it fails. The solution was to define the variables in the perl script. Rudi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=933760&group_id=29880 From noreply at sourceforge.net Mon Apr 12 22:47:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 12 22:47:26 2004 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-934025 ] check_smtp bug fix Message-ID: Bugs item #934025, was opened at 2004-04-12 22:46 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=934025&group_id=29880 Category: None Group: CVS Status: Open Resolution: None Priority: 5 Submitted By: Matthew Kent (mattkent) Assigned to: Nobody/Anonymous (nobody) Summary: check_smtp bug fix Initial Comment: Small bug fix: # ./check_smtp -H 192.168.40.9 -w 1 -c 4 No route to host SMTP WARNING - 3.018 sec. response time|time=3018187us;1;4;0 while it should return CRITICAL regardless. I also updated the output to use fperfdata. Having most of the plugins outputting the same time format (seconds) is making it easier to write generic perfdata handling perl. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=934025&group_id=29880 From happy at usg.edu Tue Apr 13 08:21:17 2004 From: happy at usg.edu (Mark Plaksin) Date: Tue Apr 13 08:21:17 2004 Subject: [Nagiosplug-devel] Re: patch for check_disk.c References: Message-ID: Ton Voon writes: > Torsten, > > Thanks for this patch, but we will not be applying it. Release 1.4 uses > a different way of querying disks (using GNU coreutils libs), thus > removing the peculiarities of df across multiple systems. > > If you can test the CVS snapshot to confirm it works on HP-UX, that > would be very helpful. We ran into the same problem and the CVS version of check_disk *does* work on HP-UX. From jwz at jwz.org Tue Apr 13 20:38:10 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Tue Apr 13 20:38:10 2004 Subject: [Nagiosplug-devel] additions to check_http.c (--no-body, --max-age) Message-ID: <407CB026.1CD081B3@jwz.org> Hi there, I recently upgraded to Nagios 1.2.0 from an old Netsaint, and I needed to add a couple of features to the check_http plugin. I sent these patches in a couple of years ago, but they haven't made it into the distribution, so here they are again... (I hope you include them this time, so that I don't have to rewrite this code again the next time I upgrade...) Anyway, I added two new options to check_http: -N, --no-body Don't wait for document body: stop reading after headers. I needed this so that I can check for the existence of Icecast MP3 streams: such streams look like audio/mpeg files, except that they are of infinite length. -M, --max-age=SECONDS Warn if the document is more than SECONDS old. I needed this so that I can check whether my webcam is still working: if the date on the JPEG file has stopped updating, the webcam is down. Here's how I use these: define command{ command_name check_icecast command_line $USER1$/check_http2 -H $HOSTADDRESS$ \ -p 8000 --no-body -u $ARG1$ } define command{ command_name check_http_age command_line $USER1$/check_http -H $HOSTALIAS$ \ -I $HOSTADDRESS$ --no-body -u $ARG1$ --max-age $ARG2$ } This diff is against check_http.c 1.24.2.4 from nagios-plugins-1.3.1. Thanks! -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ --- /tmp/check_http.c 2004-04-13 20:09:38.000000000 -0700 +++ check_http.c 2004-04-13 20:25:40.000000000 -0700 @@ -21,6 +21,8 @@ * * $Id: check_http.c,v 1.24.2.4 2003/06/21 05:31:23 kdebisschop Exp $ * + * 13-Apr-2004 -- jwz -- added "--no-body" and "--max-age" options + * *****************************************************************************/ const char *progname = "check_http"; @@ -45,7 +47,7 @@ [-w ] [-c ] [-t ] [-L]\n\ [-a auth] [-f ] [-e ]\n\ [-s string] [-l] [-r | -R ]\n\ - [-P string]" + [-P string] [-N] [-M ]" #define LONGOPTIONS "\ -H, --hostname=ADDRESS\n\ @@ -63,6 +65,13 @@ Port number (default: %d)\n\ -P, --post=STRING\n\ URL encoded http POST data\n\ + -N, --no-body\n\ + Don't wait for document body: stop reading after headers.\n\ + (Note that this still does an HTTP GET or POST, not a HEAD.)\n\ + -M, --max-age=SECONDS\n\ + Warn if the document is more than SECONDS old. The number can\n\ + also be of the form \"10m\" for minutes, \"10h\" for hours, or\n\ + \"10d\" for days.\n\ -w, --warning=INTEGER\n\ Response time to result in warning status (seconds)\n\ -c, --critical=INTEGER\n\ @@ -159,6 +168,10 @@ int check_certificate (X509 **); #endif +/* jwz */ +int no_body = FALSE; +int maximum_age = -1; + #ifdef HAVE_REGEX_H enum { REGS = 2, @@ -311,6 +324,10 @@ {"linespan", no_argument, 0, 'l'}, {"onredirect", required_argument, 0, 'f'}, {"certificate", required_argument, 0, 'C'}, + + /* jwz */ + {"no-body", no_argument, 0, 'N'}, + {"max-age", required_argument, 0, 'M'}, {0, 0, 0, 0} }; #endif @@ -331,7 +348,8 @@ strcpy (argv[c], "-n"); } -#define OPTCHARS "Vvht:c:w:H:P:I:a:e:p:s:R:r:u:f:C:nlLS" +/*#define OPTCHARS "Vvht:c:w:H:P:I:a:e:p:s:R:r:u:f:C:nlLS"*/ +#define OPTCHARS "Vvht:c:w:H:P:I:a:e:p:s:R:r:u:f:C:M:nlLSN" /* jwz */ while (1) { #ifdef HAVE_GETOPT_H @@ -469,6 +487,27 @@ case 'v': /* verbose */ verbose = TRUE; break; + case 'N': /* no-body (jwz) */ + no_body = TRUE; + break; + case 'M': /* max-age (jwz) */ + { + int L = strlen(optarg); + if (L && optarg[L-1] == 'm') + maximum_age = atoi (optarg) * 60; + else if (L && optarg[L-1] == 'h') + maximum_age = atoi (optarg) * 60 * 60; + else if (L && optarg[L-1] == 'd') + maximum_age = atoi (optarg) * 60 * 60 * 24; + else if (L && (optarg[L-1] == 's' || + isdigit (optarg[L-1]))) + maximum_age = atoi (optarg); + else { + fprintf (stderr, "unparsable max-age: %s\n", optarg); + exit (1); + } + } + break; } } @@ -534,6 +573,223 @@ +/* Returns 1 if we're done processing the document body; 0 to keep going. + (jwz) + */ +static int +document_headers_done (char *full_page) +{ + const char *body, *s; + const char *end; + + for (body = full_page; *body; body++) { + if (!strncmp (body, "\n\n", 2) || + !strncmp (body, "\n\r\n", 3)) + break; + } + + if (!*body) + return 0; /* haven't read end of headers yet */ + + full_page[body - full_page] = 0; + return 1; +} + + +/* jwz */ +static time_t +parse_time_string (const char *string) +{ + struct tm tm; + time_t t; + memset (&tm, 0, sizeof(tm)); + + /* Like this: Tue, 25 Dec 2001 02:59:03 GMT */ + + if (isupper (string[0]) && /* Tue */ + islower (string[1]) && + islower (string[2]) && + ',' == string[3] && + ' ' == string[4] && + (isdigit(string[5]) || string[5] == ' ') && /* 25 */ + isdigit (string[6]) && + ' ' == string[7] && + isupper (string[8]) && /* Dec */ + islower (string[9]) && + islower (string[10]) && + ' ' == string[11] && + isdigit (string[12]) && /* 2001 */ + isdigit (string[13]) && + isdigit (string[14]) && + isdigit (string[15]) && + ' ' == string[16] && + isdigit (string[17]) && /* 02: */ + isdigit (string[18]) && + ':' == string[19] && + isdigit (string[20]) && /* 59: */ + isdigit (string[21]) && + ':' == string[22] && + isdigit (string[23]) && /* 03 */ + isdigit (string[24]) && + ' ' == string[25] && + 'G' == string[26] && /* GMT */ + 'M' == string[27] && /* GMT */ + 'T' == string[28]) { + + tm.tm_sec = 10 * (string[23]-'0') + (string[24]-'0'); + tm.tm_min = 10 * (string[20]-'0') + (string[21]-'0'); + tm.tm_hour = 10 * (string[17]-'0') + (string[18]-'0'); + tm.tm_mday = 10 * (string[5] == ' ' ? 0 : string[5]-'0') + (string[6]-'0'); + tm.tm_mon = (!strncmp (string+8, "Jan", 3) ? 0 : + !strncmp (string+8, "Feb", 3) ? 1 : + !strncmp (string+8, "Mar", 3) ? 2 : + !strncmp (string+8, "Apr", 3) ? 3 : + !strncmp (string+8, "May", 3) ? 4 : + !strncmp (string+8, "Jun", 3) ? 5 : + !strncmp (string+8, "Jul", 3) ? 6 : + !strncmp (string+8, "Aug", 3) ? 7 : + !strncmp (string+8, "Sep", 3) ? 8 : + !strncmp (string+8, "Oct", 3) ? 9 : + !strncmp (string+8, "Nov", 3) ? 10 : + !strncmp (string+8, "Dec", 3) ? 11 : + -1); + tm.tm_year = ((1000 * (string[12]-'0') + + 100 * (string[13]-'0') + + 10 * (string[14]-'0') + + (string[15]-'0')) + - 1900); + + tm.tm_isdst = 0; /* GMT is never in DST, right? */ + + if (tm.tm_mon < 0 || + tm.tm_mday < 1 || + tm.tm_mday > 31) + return 0; + + /* #### This is actually wrong: we need to subtract the local timezone + offset from GMT from this value. But, that's ok in this usage, + because we only comparing these two GMT dates against each other, + so it doesn't matter what time zone we parse them in. + */ + + t = mktime (&tm); + if (t == (time_t) -1) t = 0; + + if (verbose) { + const char *s = string; + while (*s && *s != '\r' && *s != '\n') + fputc (*s++, stdout); + printf (" ==> %lu\n", (unsigned long) t); + } + + return t; + + } else { + return 0; + } +} + + +/* jwz */ +static void +check_document_dates (const char *headers) +{ + const char *s; + char *server_date = 0; + char *document_date = 0; + + s = headers; + while (*s) { + const char *field = s; + const char *value = 0; + + /* Find the end of the header field */ + while (*s && !isspace(*s) && *s != ':') + s++; + + /* Remember the header value, if any. */ + if (*s == ':') + value = ++s; + + /* Skip to the end of the header, including continuation lines. */ + while (*s && + !(*s == '\n' && (s[1] != ' ' && s[1] != '\t'))) + s++; + s++; + + /* Process this header. */ + if (value && value > field+2) { + char *ff = (char *) malloc (value-field); + char *ss = ff; + while (field < value-1) + *ss++ = tolower(*field++); + *ss++ = 0; + + if (!strcmp (ff, "date") || + !strcmp (ff, "last-modified")) { + const char *e; + while (*value && isspace (*value)) + value++; + for (e = value; *e && *e != '\r' && *e != '\n'; e++) + ; + ss = (char *) malloc (e - value + 1); + strncpy (ss, value, e - value); + ss[e - value] = 0; + if (!strcmp (ff, "date")) { + if (server_date) free (server_date); + server_date = ss; + } else { + if (document_date) free (document_date); + document_date = ss; + } + } + free (ff); + } + } + + /* Done parsing the body. Now check the dates we (hopefully) parsed. + */ + if (!server_date || !*server_date) { + terminate (STATE_UNKNOWN, "server date unknown\n"); + } else if (!document_date || !*document_date) { + terminate (STATE_CRITICAL, "document modification date unknown\n"); + } else { + time_t sd = parse_time_string (server_date); + time_t dd = parse_time_string (document_date); + char buf [255]; + + if (sd <= 0) { + sprintf (buf, "server date \"%100s\" unparsable", server_date); + terminate (STATE_CRITICAL, buf); + + } else if (dd <= 0) { + sprintf (buf, "document date \"%100s\" unparsable", document_date); + terminate (STATE_CRITICAL, buf); + + } else if (dd > sd + 30) { + char buf[200]; + sprintf (buf, "document is %d seconds in the future\n", dd - sd); + terminate (STATE_CRITICAL, buf); + + } else if (dd < sd - maximum_age) { + char buf[200]; + int n = (sd - dd); + if (n > (60 * 60 * 24 * 2)) + sprintf (buf, "last modified %.1f days ago\n", + ((float) n) / (60 * 60 * 24)); + else + sprintf (buf, "last modified %d:%02d:%02d ago\n", + n / (60 * 60), (n / 60) % 60, n % 60); + terminate (STATE_CRITICAL, buf); + } + + free (server_date); + free (document_date); + } +} + + + int check_http (void) { @@ -625,6 +881,12 @@ buffer[i] = '\0'; asprintf (&full_page, "%s%s", full_page, buffer); pagesize += i; + + /* jwz */ + if (no_body && document_headers_done (full_page)) { + i = 0; + break; + } } if (i < 0 && errno != ECONNRESET) { @@ -685,7 +947,8 @@ page += (size_t) strspn (page, "\r\n"); header[pos - header] = 0; if (verbose) - printf ("**** HEADER ****\n%s\n**** CONTENT ****\n%s\n", header, page); + printf ("**** HEADER ****\n%s\n**** CONTENT ****\n%s\n", header, + (no_body ? " [[ skipped ]]" : page)); /* jwz */ /* make sure the status line matches the response we are looking for */ if (!strstr (status_line, server_expect)) { @@ -810,6 +1073,11 @@ } /* end else (server_expect_yn) */ + /* jwz */ + if (maximum_age >= 0) { + check_document_dates (header); + } + /* check elapsed time */ elapsed_time = delta_time (tv); asprintf (&msg, "HTTP problem: %s - %7.3f second response time %s%s|time=%7.3f\n", From Ben at clewett.org.uk Wed Apr 14 01:03:46 2004 From: Ben at clewett.org.uk (Ben Clewett) Date: Wed Apr 14 01:03:46 2004 Subject: [Nagiosplug-devel] Possible error in check_disk In-Reply-To: <40751F88.6070102@clewett.org.uk> References: <4072E427.7020304@op5.se> <40750689.1010008@clewett.org.uk> <40751F88.6070102@clewett.org.uk> Message-ID: <407CF052.5050705@clewett.org.uk> Possible error in check_disk. Sample output from latest HEAD: $ check_disk -w 20% -c 10% -p /dev/hda3 DISK OK - free space: / 31959 MB (88%);| /=31958MB;29204;32854;0;36505 /dev/hda3 According to the specification: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN185 The '/dev/hda3' tagged onto the end I think might be illegal. This might effect nagios related programs trying to parse this data. Ben. From m.barrera at choin.net Wed Apr 14 11:57:06 2004 From: m.barrera at choin.net (Marco Barrera) Date: Wed Apr 14 11:57:06 2004 Subject: [Nagiosplug-devel] return code Message-ID: <0848042A293E9B46B2CD3C466956DC056155D9@exchsrv> Hi All, Hope I am starting a discussion in the correct forum, I think this is more of a development issue rather than anything else. I have been seeing a problem with a my plugin firebox I am using some perl code to submit commands containing: ========================================= #!/usr/bin/perl -w use lib "/usr/lib/nagios/plugins"; use utils qw($TIMEOUT %ERRORS); my $state = 'OK'; my $memtotal = 0; my $memused = 0; my $memfree = 0; my $memshared = 0; my $membuffers = 0; my $memcached = 0; my $Mensaje = ''; open(OUTPUT,"/usr/sbin/cbsh 372.168.0.154 DDDDedo9 -c 'status all' | grep 'Mem:'|"); while (){ if (/^Mem:\s+(\d.*)/) { $Mensaje = $1; last; } } ($memtotal, $memused, $memfree, $memshared, $membuffers, $memcached) = split /\s+/, $Mensaje, 6; print "Stest $memfree $membuffers\n"; exit $ERRORS{$state}; ============================================= When I run the plugin manually, it consistently works, [root at csm-server plugins]# ./check_wg-mem.pl Stest 18944000 14516224 but when it is run by nagios, the exit code is frequently wrong. Stest I work with RH ES 3 Is there an alternative solution? From sghosh at sghosh.org Wed Apr 14 13:18:01 2004 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Wed Apr 14 13:18:01 2004 Subject: [Nagiosplug-devel] Re: return code In-Reply-To: <0848042A293E9B46B2CD3C466956DC056155D7@exchsrv> Message-ID: Sorry - you posted to the admin list. On Wed, 14 Apr 2004, Marco Barrera wrote: > Hi All, > > Hope I am starting a discussion in the correct forum, I think this is > more of a development issue rather than anything else. > > I have been seeing a problem with a my plugin firebox > > I am using some perl code to submit commands containing: > > ========================================= > #!/usr/bin/perl -w > > use lib "/usr/lib/nagios/plugins"; > use utils qw($TIMEOUT %ERRORS); > > > my $state = 'OK'; > > my $memtotal = 0; > my $memused = 0; > my $memfree = 0; > my $memshared = 0; > my $membuffers = 0; > my $memcached = 0; > my $Mensaje = ''; > > > open(OUTPUT,"/usr/sbin/cbsh 372.168.0.154 DDDDedo9 -c 'status all' | grep 'Mem:'|"); > while (){ > if (/^Mem:\s+(\d.*)/) { $Mensaje = $1; last; } > } > > ($memtotal, $memused, $memfree, $memshared, $membuffers, $memcached) = split /\s+/, $Mensaje, 6; > > print "Stest $memfree $membuffers\n"; > exit $ERRORS{$state}; > ============================================= > > When I run the plugin > manually, it consistently works, > > [root at csm-server plugins]# ./check_wg-mem.pl > Stest 18944000 14516224 > > but when it is run by > nagios, the exit code is frequently wrong. > > Stest > > I work with RH ES 3 > > Is there an alternative solution? > > -- From Stanley.Hopcroft at IPAustralia.Gov.AU Wed Apr 14 16:36:01 2004 From: Stanley.Hopcroft at IPAustralia.Gov.AU (Stanley Hopcroft) Date: Wed Apr 14 16:36:01 2004 Subject: [Nagiosplug-devel] return code In-Reply-To: <0848042A293E9B46B2CD3C466956DC056155D9@exchsrv>; from m.barrera@choin.net on Wed, Apr 14, 2004 at 08:56:39PM +0200 References: <0848042A293E9B46B2CD3C466956DC056155D9@exchsrv> Message-ID: <20040415093443.A85514@IPAustralia.Gov.AU> Dear Sir, I am writing to thank you for your letter and say, On Wed, Apr 14, 2004 at 08:56:39PM +0200, Marco Barrera wrote: > Hi All, > > Hope I am starting a discussion in the correct forum, I think this is > more of a development issue rather than anything else. ... agreed. > > I have been seeing a problem with a my plugin firebox > > I am using some perl code to submit commands containing: > > ========================================= > #!/usr/bin/perl -w > > use lib "/usr/lib/nagios/plugins"; > use utils qw($TIMEOUT %ERRORS); > > > my $state = 'OK'; > > my $memtotal = 0; > my $memused = 0; > my $memfree = 0; > my $memshared = 0; > my $membuffers = 0; > my $memcached = 0; > my $Mensaje = ''; > > > open(OUTPUT,"/usr/sbin/cbsh 372.168.0.154 DDDDedo9 -c 'status all' | grep 'Mem:'|"); > while (){ > if (/^Mem:\s+(\d.*)/) { $Mensaje = $1; last; } > } > > ($memtotal, $memused, $memfree, $memshared, $membuffers, $memcached) = split /\s+/, $Mensaje, 6; > > print "Stest $memfree $membuffers\n"; > exit $ERRORS{$state}; > ============================================= > > When I run the plugin > manually, it consistently works, > > [root at csm-server plugins]# ./check_wg-mem.pl > Stest 18944000 14516224 > > but when it is run by > nagios, the exit code is frequently wrong. My comments are 1 I can't see where $status is set apart from the initialisation (= 'OK') => the plugin will always return OK or something else if the plugin abends. There doesn't seem any way for it to return other than OK with a normal exit. 2 the /bin/sh pipeline is not checked for (fork) errors, so the result could be CRITICAL (code in base/checks.c IIRC traps no output from the plugin and sets the return code to CRITICAL). I think you need to trap an open failure open(OUTPUT,"/usr/sbin/cbsh 372.168.0.154 DDDDedo9 -c 'status all' | grep 'Mem:'|") or do { print "open failed - fork() or other /bin/sh problem: $!" ; exit $ERRORS{'UNKNOWN'} ; } ; and the close failure (in case the child processes forked by /bin/sh fail) close OUTPUT or do { } ; 3 You may want to use the 'strict' pragma to have Perl detect anything risky (at compile time). 4 If you are using embedded Perl, that may be causing problems. You could try without it. 5 You should always try the command from the CLI logged in as the Nagios user; this will reveal any permissions problems. Yours sincerely. -- ------------------------------------------------------------------------ Stanley Hopcroft ------------------------------------------------------------------------ '...No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were. Any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee...' from Meditation 17, J Donne. From pla at softflare.com Wed Apr 14 16:59:00 2004 From: pla at softflare.com (Paul L. Allen) Date: Wed Apr 14 16:59:00 2004 Subject: [Nagiosplug-devel] Re: return code In-Reply-To: <20040415093443.A85514@IPAustralia.Gov.AU> References: <0848042A293E9B46B2CD3C466956DC056155D9@exchsrv> <20040415093443.A85514@IPAustralia.Gov.AU> Message-ID: <20040414235757.18302.qmail@minnow.softflare.net> Stanley Hopcroft writes: > 1 I can't see where $status is set apart from the initialisation (= > 'OK') => the plugin will always return OK or something else if the > plugin abends. I couldn't see anything setting $status either. But it's late here. :) And you're showing your age with "abend." I'm a boring old fart, but even I only know of "abend" as something that predates my experiences with computing. Damn, but you're OLD. :) > 5 You should always try the command from the CLI logged in as the Nagios > user; this will reveal any permissions problems. Then there is the problem of path cleaning. Many perl plugins clean out the PATH environment variable. The recent changes to the check_mailq plugin which handle qmail have this problem and fail to work because qmail-qstat calls several utilities that are not in the cleaned path. The changes were not fully tested. I have reported the problem but seen no acknowledgement. -- Paul Allen Softflare Support From brylon at jla.rutgers.edu Fri Apr 16 11:29:03 2004 From: brylon at jla.rutgers.edu (Bryan Loniewski) Date: Fri Apr 16 11:29:03 2004 Subject: [Nagiosplug-devel] check_qstat.pl plugin Message-ID: Attached is a perl plugin based off of check_mailq, however it checks the qmail queue using qmail-qstat. Bryan Loniewski -------------- next part -------------- #! /usr/local/bin/perl -w -- -*- Perl -*- # check_qstat - check on the number of messages messages in the qmail queue # based on check-mailq # Initial version support sendmail's mailq command # Modified to support qmail-qstat # License Information: # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # ############################################################################ use POSIX; use strict; use Getopt::Long; use vars qw($opt_V $opt_h $verbose $PROGNAME $status $state $msg $msg_q ); use lib "/usr/local/nagios/libexec" ; use utils qw(%ERRORS &print_revision &support &usage ); # suppress strict warns about one time use :-( $utils::PATH_TO_QSTAT = $utils::PATH_TO_QSTAT; $utils::QSTAT_QUEUE_WARN = $utils::QSTAT_QUEUE_WARN; $utils::QSTAT_QUEUE_CRIT = $utils::QSTAT_QUEUE_CRIT; $utils::QSTAT_PRE_WARN = $utils::QSTAT_PRE_WARN; $utils::QSTAT_PRE_CRIT = $utils::QSTAT_PRE_CRIT; my $QSTAT = $utils::PATH_TO_QSTAT || "/var/qmail/bin/qmail-qstat"; my $queuewarn = $utils::QSTAT_QUEUE_WARN || 100; my $queuecrit = $utils::QSTAT_QUEUE_CRIT || 500; my $prewarn = $utils::QSTAT_PRE_WARN || 20; my $precrit = $utils::QSTAT_PRE_CRIT || 50; my $timeout = $utils::TIMEOUT || 10; sub print_help (); sub print_usage (); sub process_arguments (); $ENV{'PATH'}='/usr/bin:/bin'; $ENV{'BASH_ENV'}=''; $ENV{'ENV'}=''; $PROGNAME = "check_qstat"; Getopt::Long::Configure('bundling'); $status = process_arguments(); if ($status){ print "ERROR: processing arguments\n"; exit $ERRORS{"UNKNOWN"}; } if ($timeout) { $SIG{'ALRM'} = sub { print ("ERROR: timed out waiting for $QSTAT \n"); exit $ERRORS{"WARNING"}; }; alarm($timeout); } ## open mailq if ( defined $QSTAT && -x $QSTAT ) { if (! open(QSTAT, "$QSTAT 2>/dev/null |" ) ) { print "ERROR: could not open $QSTAT \n"; exit $ERRORS{'UNKNOWN'}; } } else { print "ERROR: Could not find qstat executable $QSTAT!\n"; exit $ERRORS{'UNKNOWN'}; } use vars qw ($anzq $anzp); my $answer = ''; while () { next if /^\s*$/; # skip blank lines if (/^messages in queue: (\d+)/) { # Mails in Queues $anzq = $1; if ($anzq < $queuewarn) { $answer .= "OK: $anzq messages in queue, limits $queuewarn/$queuecrit "; } else { if ($anzq >= $queuecrit) { $answer = "CRITICAL: $anzq messages in queue, limit $queuecrit "; } else { $answer = "WARNING: $anzq messages in queue, limit $queuewarn "; } } next; } # unpreprocessed Mails if (/^messages in queue but not yet preprocessed: (\d+)/) { $anzp = $1; if ($anzp < $prewarn) { $answer .= "OK: $anzp messages not preprocessed, limits $prewarn/$precrit "; } else { if ($anzp >= $precrit) { $answer = "CRITICAL: $anzp messages not preprocessed, limit $precrit "; } else { $answer = "WARNING: $anzp messages not preprocesed, limit $prewarn "; } } next; } chomp; $answer .="unrecognised line output from $QSTAT '$_'\n"; } close QSTAT; if ($?) { print "ERROR: $QSTAT failed, return code $?\n"; exit $ERRORS{'UNKNOWN'}; } if (defined($anzq) and defined($anzp)) { if ($anzp >= $precrit or $anzq >= $queuecrit) { $state = 'CRITICAL'; } elsif ($anzp >= $prewarn or $anzq >= $queuewarn) { $state = 'WARNING'; } else { $state = 'OK'; } } else { $state = 'UNKNOWN'; } print ("$answer\n"); exit $ERRORS{$state}; ##################################### #### subs sub process_arguments(){ GetOptions ("V" => \$opt_V, "version" => \$opt_V, "v" => \$verbose, "verbose" => \$verbose, "h" => \$opt_h, "help" => \$opt_h, "w=i" => \$queuewarn, "queuewarning=i" => \$queuewarn, "W=i" => \$prewarn, "prewarning=i" => \$prewarn, "c=i" => \$queuecrit, "queuecritical=i" => \$queuecrit, "C=i" => \$precrit, "precritical=i" => \$precrit, "t=i" => \$timeout, "timeout=i" => \$timeout ); if ($opt_V) { print_revision($PROGNAME,'$Revision: 1.1 $ '); exit $ERRORS{'OK'}; } if ($opt_h) { print_help(); exit $ERRORS{'OK'}; } if ( $queuewarn >= $queuecrit) { print "ERROR: queue Warning($queuewarn) cannot be greater than Critical($queuecrit)!\n"; exit $ERRORS{'UNKNOWN'}; } if ( $prewarn >= $precrit) { print "ERROR: pre Warning($prewarn) cannot be greater than Critical($precrit)!\n"; exit $ERRORS{'UNKNOWN'}; } return $ERRORS{'OK'}; } sub print_usage () { print "Usage: $PROGNAME [-w ] [-c ] [-W ] [-C ] [-t ] [-h] [-v] [-V]\n"; } sub print_help () { print_revision($PROGNAME,'$Revision: 1.1 $'); print "Copyright (c) 2002 Subhendu Ghosh\n"; print "\n"; print_usage(); print "\n"; print " Checks the number of messages in the mail queue\n"; print " Feedback/patches to support non-sendmail mailqueue welcome\n\n"; print "-w (--queuewarning) = Min. # of messages in queue for a warning\n"; print "-c (--queuecritical) = Min. # of messages in queue for a critical alert ( w < c )\n"; print "-W (--prewarning) = Min. # of not preprocessed messages in queue to generate warning\n"; print "-C (--precritical) = Min. # of not preprocessed messages in queue to generate critical alert ( W < C )\n"; print "-t (--timeout) = Plugin timeout in seconds (default = $utils::TIMEOUT)\n"; print "-h (--help)\n"; print "-V (--version)\n"; print "-v (--verbose) = debugging output\n"; print "\n\n"; support(); } From benny at bennyvision.com Sat Apr 17 20:10:12 2004 From: benny at bennyvision.com (C. Bensend) Date: Sat Apr 17 20:10:12 2004 Subject: [Nagiosplug-devel] Re: Plugin check_http segfaulting on OpenBSD 3.4-STABLE In-Reply-To: <52474.63.227.74.41.1081213759.squirrel@webmail.stinkweasel.net> References: <52474.63.227.74.41.1081213759.squirrel@webmail.stinkweasel.net> Message-ID: <52571.63.227.74.41.1082257761.squirrel@webmail.stinkweasel.net> OK, with some hints from Stanley, here are further details of SEGVs from OpenBSD 3.4-STABLE, running today's CVS snapshot of the plugins: [nagios at tau ~/nagios-plugins-HEAD-200404171647/plugins]$ gdb check_http GNU gdb 4.16.1 Copyright 1996 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd3.4"... (gdb) set args -I 127.0.0.1 (gdb) run Starting program: /home/nagios/nagios-plugins-HEAD-200404171647/plugins/check_http -I 127.0.0.1 Program received signal SIGSEGV, Segmentation fault. 0xf1b955a in freeaddrinfo () (gdb) backtrace #0 0xf1b955a in freeaddrinfo () #1 0x1c00406b in my_connect (host_name=0x3c009050 "127.0.0.1", port=80, sd=0x3c007908, proto=6) at netutils.c:263 #2 0x1c003f22 in my_tcp_connect (host_name=0x3c009050 "127.0.0.1", port=80, sd=0x3c007908) at netutils.c:193 #3 0x1c002589 in check_http () at check_http.c:508 #4 0x1c001ba7 in main (argc=3, argv=0xcfbf8db0) at check_http.c:178 #5 0x1c0018f1 in ___start () #6 0x1c001867 in _start () #7 0xcfbf8ee8 in ?? () Error accessing memory address 0x3: Invalid argument. But. This isn't a check_http problem: Program received signal SIGSEGV, Segmentation fault. 0xca3c55a in ?? () from /usr/lib/libc.so.30.1 (gdb) backtrace #0 0xca3c55a in ?? () from /usr/lib/libc.so.30.1 #1 0x1c0024cb in my_connect (host_name=0xcfbfdce0 "63.227.74.43", port=25, sd=0xcfbfd6e8, proto=6) at netutils.c:263 #2 0x1c002382 in my_tcp_connect (host_name=0xcfbfdce0 "63.227.74.43", port=25, sd=0xcfbfd6e8) at netutils.c:193 #3 0x1c0015af in main (argc=3, argv= Error accessing memory address 0x0: Invalid argument. ) at check_smtp.c:119 #4 0x1c001391 in ___start () #5 0x1c001307 in _start () #6 0xcfbfdc9c in ?? () Error accessing memory address 0x3: Invalid argument. That was from check_smtp. As soon as I start either service back up and try again, the plugins behave. But, if the service is down and I test it, it SEGVs. Thoughts? It looks like netutils.c has something weird going on... Benny -- "I can't believe it's not carp!" -- MXC From noreply at sourceforge.net Mon Apr 19 06:20:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 19 06:20:08 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-848367 ] New plugin: check_atria Message-ID: New Plugins item #848367, was opened at 2003-11-24 10:38 Message generated for change (Comment added) made by sghosh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=848367&group_id=29880 Category: Application monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hugo Monteiro (hvm_pt) Assigned to: Nobody/Anonymous (nobody) Summary: New plugin: check_atria Initial Comment: This is a shell script plugin to check if the (IBM) Rational Clearcase daemons are running. It checks for Albd Server daemon and the Lock Manager daemon and it returns: STATE_CRITICAL - If Albd Server is not running; STATE_DEPENDENT - If Albd Server is running but Lock Manager is not; STATE_OK - If both daemons are running; STATE_WARNING - Is not used; NOTES: It does not need any parameters to run; I've already tested it in SunOS, Linux and Tru64(OSF). cya... Hugo Monteiro ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2004-04-19 09:19 Message: Logged In: YES user_id=46572 Can you change the output of the plugin - STATE_DEPENDENT is an internal state and should not be passed back to Nagios. If the Lock Manager fails is WARNING appropriate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=848367&group_id=29880 From noreply at sourceforge.net Mon Apr 19 06:23:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 19 06:23:03 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-738128 ] check_mssql plugin Message-ID: New Plugins item #738128, was opened at 2003-05-15 04:32 Message generated for change (Comment added) made by sghosh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=738128&group_id=29880 Category: Perl plugin Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Roy Sigurd Karlsbakk (rkarlsba) Assigned to: Subhendu Ghosh (sghosh) Summary: check_mssql plugin Initial Comment: hi here's (another?) check_mssql plugin written in perl. the only other I've seen was a hacky bourne shell. Waddayathink? roy ---------------------------------------------------------------------- >Comment By: Subhendu Ghosh (sghosh) Date: 2004-04-19 09:22 Message: Logged In: YES user_id=46572 modifed plugin is in distribution. ---------------------------------------------------------------------- Comment By: Subhendu Ghosh (sghosh) Date: 2004-02-26 14:27 Message: Logged In: YES user_id=46572 Instead of OpenClient, use the FreeTDS libs - from Freetds.org DBD::Sybase recognizes FreeTDS just fine. ---------------------------------------------------------------------- Comment By: Alain Goldberg (agolt) Date: 2004-02-26 05:17 Message: Logged In: YES user_id=982117 I think i would like to use it ;-) It's just that I fail install of CPAN DBD::Sybase it says I need an "open client" library... where/how do i get this stuff... some install help inside the plugin source could be very valuable Thansk anyway ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-06-04 03:43 Message: Logged In: YES user_id=145309 bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, bugs, sorry. forgot to test last upload. here's another one. this should work ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-06-02 03:19 Message: Logged In: YES user_id=145309 Updated comment in top to reflect a GPL licence ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-05-27 09:23 Message: Logged In: YES user_id=145309 Thanks you for submitting your plugin/script for inclusion in the NagiosPlugins project. Please note that only plugins/scripts with an opensource license can be accepted in this project. Please ensure that your code contains explicit copyright and license information. Future status of your plugin: Initially the plugin will be included asis in the contrib directory. If you have any updates or patches that need to be applied, please post them on the NaiosPlugins website under Patches. (http://sourceforge.net/tracker/?group_id=29880&atid=397599) If the plugin code meets with the guidelines and there is a general consensus among users that it is useful and could see wide deployment, the plugin code will be migrated from "contrib" to "supported" status in either the plugins or plugins-scripts directories. Future status of your script: At this time we have only started collecting scripts that are used for report generation. Their future migration to supported status is not clear at the moment. Again thanks for contributing to opensource. The NagiosPlugins Team ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-05-27 09:21 Message: Logged In: YES user_id=145309 Thanks you for submitting your plugin/script for inclusion in the NagiosPlugins project. Please note that only plugins/scripts with an opensource license can be accepted in this project. Please ensure that your code contains explicit copyright and license information. Future status of your plugin: Initially the plugin will be included asis in the contrib directory. If you have any updates or patches that need to be applied, please post them on the NaiosPlugins website under Patches. (http://sourceforge.net/tracker/?group_id=29880&atid=397599) If the plugin code meets with the guidelines and there is a general consensus among users that it is useful and could see wide deployment, the plugin code will be migrated from "contrib" to "supported" status in either the plugins or plugins-scripts directories. Future status of your script: At this time we have only started collecting scripts that are used for report generation. Their future migration to supported status is not clear at the moment. Again thanks for contributing to opensource. The NagiosPlugins Team ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=738128&group_id=29880 From sghosh at sghosh.org Mon Apr 19 07:56:01 2004 From: sghosh at sghosh.org (Subhendu Ghosh) Date: Mon Apr 19 07:56:01 2004 Subject: [Nagiosplug-devel] check_qstat.pl plugin In-Reply-To: Message-ID: Bryan - the current version for check_mailq supports sendmail, postfix and qmail (check the commandline options) Is this qmail patch sufficiently different for the CVS version? On Fri, 16 Apr 2004, Bryan Loniewski wrote: > Attached is a perl plugin based off of check_mailq, however it checks the > qmail queue using qmail-qstat. > > Bryan Loniewski > -- From noreply at sourceforge.net Mon Apr 19 08:02:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 19 08:02:01 2004 Subject: [Nagiosplug-devel] [ nagiosplug-Support Requests-889948 ] check_hpjd Message-ID: Support Requests item #889948, was opened at 2004-02-03 22:57 Message generated for change (Comment added) made by mikaeljokela You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=889948&group_id=29880 Category: None Group: None Status: Open Priority: 5 Submitted By: Joseph Ronzio (jronzio) Assigned to: Nobody/Anonymous (nobody) Summary: check_hpjd Initial Comment: under the check_hpjd everything works fine in most cases but for selective printers I am routinely seeing a Hex string "52 4F 4D 20 54 52 41 59 20 32" under the printer status. Is there any explination for this result and if so can we get it coded into the check_hpjd so that is doesn't give a warning message each time the printer is queried? ---------------------------------------------------------------------- Comment By: mikael.jokela (mikaeljokela) Date: 2004-04-19 18:01 Message: Logged In: YES user_id=1024488 Adding "-Oa" to snmpget parameters might resolve this problem. At times, snmpget seems to determine that the printer status text is a binary string. This parameter is needed to make snmpget always print the status text is ascii. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397598&aid=889948&group_id=29880 From jhmartin at toger.us Mon Apr 19 10:30:06 2004 From: jhmartin at toger.us (Jason Martin) Date: Mon Apr 19 10:30:06 2004 Subject: [Nagiosplug-devel] Partial feature additions Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm looking to add a feature to check_procs that deals with the age of the process. I see that that check_procs has ps format listings for quite a few platforms and I only have access to a few. Would it be acceptable to submit a patch that only enables that functionality on a subset of platforms? Is there a standard way of dealing with this sort of situation? Thanks, - -Jason Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.5 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQFAhAyOl2ODWuqVSBMRAuduAJ9yLRnIlcUEvXmfg6DqdVqjdwyBlgCeJtZ1 Gj1fcqV02bo1IA2T2f4fjd0= =UHpR -----END PGP SIGNATURE----- From noreply at sourceforge.net Mon Apr 19 15:04:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 19 15:04:06 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-938208 ] check_mysqld w/ performance data Message-ID: New Plugins item #938208, was opened at 2004-04-19 15:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938208&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Kent (mattkent) Assigned to: Nobody/Anonymous (nobody) Summary: check_mysqld w/ performance data Initial Comment: This is a plugin for contribs to check a mysql server and return performance data. The idea being that you could run the stock check_mysql.c plugin from the clients to check connectivity to their corresponding mysql server. Then run this plugin from the nagios server to check the database servers themselves and return data for performance data post processing. As I'm working on an addon package for nagios 2.0 which will use this check (and my other lm_sensors submission), I would appreciate it being considered for addition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938208&group_id=29880 From noreply at sourceforge.net Mon Apr 19 15:10:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 19 15:10:02 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-938212 ] check_sensors w/ performance data Message-ID: New Plugins item #938212, was opened at 2004-04-19 15:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938212&group_id=29880 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Kent (mattkent) Assigned to: Nobody/Anonymous (nobody) Summary: check_sensors w/ performance data Initial Comment: This is a plugin for contribs to lm_sensors output and return performance data. The purpose of this plugin is to provide an alternative to the current contrib plugin which relies on the ALARM field in the sensors output for problem notification. After reading the chip documentation for our particular boards, the way ALARM is set by the driver wouldn't have been reliable enough to use in production. I also wanted performance data for post processing and a check that could run through nrpe so I wouldn't have to edit sensors.conf on every server for a threshold change. As I'm working on an addon package for nagios 2.0 which will use this check (and my other mysqld submission), I would appreciate it being considered for addition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=938212&group_id=29880 From noreply at sourceforge.net Tue Apr 20 02:06:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 20 02:06:05 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-746083 ] check_asterisk Message-ID: New Plugins item #746083, was opened at 2003-05-30 15:36 Message generated for change (Comment added) made by rkarlsba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=746083&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Sigurd Karlsbakk (rkarlsba) Assigned to: Nobody/Anonymous (nobody) Summary: check_asterisk Initial Comment: plugin to log into the asterisk PBX (asterisk.org) manager interface. This just logs in and out, but it's better than nothing :) roy ---------------------------------------------------------------------- >Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2004-04-20 11:05 Message: Logged In: YES user_id=145309 I found this doesn't check the asterisk server sufficiently, as althought the manager interface may work, the other parts (isdn subsystem, sip, iax etc) may be down. It's a simple plugin that does nothnig worth more than a ping. If the asterisk server goes down (SIGSEGV or something), this plugin will find it, but that's about it. roy ---------------------------------------------------------------------- Comment By: Roy Sigurd Karlsbakk (rkarlsba) Date: 2003-06-02 09:20 Message: Logged In: YES user_id=145309 updated licence to GPL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=746083&group_id=29880 From noreply at sourceforge.net Wed Apr 21 02:24:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 02:24:02 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-939170 ] check_yum - Check Message-ID: New Plugins item #939170, was opened at 2004-04-21 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 Category: System monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: G. Krist (g_krist) Assigned to: Nobody/Anonymous (nobody) Summary: check_yum - Check Initial Comment: check_yum does a check to see if a system is up-to-date with all updates/patches. It's using the "yum check-update" command on either local host or remote hosts (using nrpe). It has 3 levels of return text: 1) Server is up-to-date (no updates available) 2) Server is NOT up-to-date, xxx packages etc (There are updates, will be a Criticical error) 3) Something wrong with yum etc etc (something is wrong with yum, will be a warning) IMHO there is no need for -w or -c parameters not even possible i think :D note: I would like to see some feedback, i'm already using it for like 10 servers, it worked oke here. We run it once a day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 From noreply at sourceforge.net Wed Apr 21 02:25:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 02:25:01 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-939170 ] check_yum - Check if YUM/RPM based system is up-to-date Message-ID: New Plugins item #939170, was opened at 2004-04-21 11:23 Message generated for change (Settings changed) made by g_krist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 Category: System monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: G. Krist (g_krist) Assigned to: Nobody/Anonymous (nobody) >Summary: check_yum - Check if YUM/RPM based system is up-to-date Initial Comment: check_yum does a check to see if a system is up-to-date with all updates/patches. It's using the "yum check-update" command on either local host or remote hosts (using nrpe). It has 3 levels of return text: 1) Server is up-to-date (no updates available) 2) Server is NOT up-to-date, xxx packages etc (There are updates, will be a Criticical error) 3) Something wrong with yum etc etc (something is wrong with yum, will be a warning) IMHO there is no need for -w or -c parameters not even possible i think :D note: I would like to see some feedback, i'm already using it for like 10 servers, it worked oke here. We run it once a day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 From gerwin at digitalus.nl Wed Apr 21 02:56:03 2004 From: gerwin at digitalus.nl (Gerwin Krist -|- Digitalus.NL) Date: Wed Apr 21 02:56:03 2004 Subject: [Nagiosplug-devel] New plugin: check_yum Message-ID: <1082541331.13681.6.camel@gerwin.digitalus.nl> details at: https://sourceforge.net/tracker/index.php?func=detail&aid=939170&group_id=29880&atid=541465 Regards, G.Krist From agrajag at dragaera.net Wed Apr 21 07:28:09 2004 From: agrajag at dragaera.net (Sean Dilda) Date: Wed Apr 21 07:28:09 2004 Subject: [Nagiosplug-devel] New plugin: check_yum In-Reply-To: <1082541331.13681.6.camel@gerwin.digitalus.nl> References: <1082541331.13681.6.camel@gerwin.digitalus.nl> Message-ID: <1082557658.4475.2.camel@pel> On Wed, 2004-04-21 at 05:55, Gerwin Krist -|- Digitalus.NL wrote: > details at: > > https://sourceforge.net/tracker/index.php?func=detail&aid=939170&group_id=29880&atid=541465 > Interesting. From a quick look, I'd suggest relying more on exit codes and textual output. From the man page, if the exit code is 100, then your system is not up to date. If its 0, your system is up to date. If its anything else, yum had a problem running. (A quick check just showed python exits with a status of 1 if there's an IOError) Checking the exit codes is a little more robust than your current method. From noreply at sourceforge.net Wed Apr 21 08:22:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 08:22:01 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-939170 ] check_yum - Check if YUM/RPM based system is up-to-date Message-ID: New Plugins item #939170, was opened at 2004-04-21 11:23 Message generated for change (Comment added) made by g_krist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 Category: System monitor Group: None Status: Open Resolution: None Priority: 5 Submitted By: G. Krist (g_krist) Assigned to: Nobody/Anonymous (nobody) Summary: check_yum - Check if YUM/RPM based system is up-to-date Initial Comment: check_yum does a check to see if a system is up-to-date with all updates/patches. It's using the "yum check-update" command on either local host or remote hosts (using nrpe). It has 3 levels of return text: 1) Server is up-to-date (no updates available) 2) Server is NOT up-to-date, xxx packages etc (There are updates, will be a Criticical error) 3) Something wrong with yum etc etc (something is wrong with yum, will be a warning) IMHO there is no need for -w or -c parameters not even possible i think :D note: I would like to see some feedback, i'm already using it for like 10 servers, it worked oke here. We run it once a day. ---------------------------------------------------------------------- >Comment By: G. Krist (g_krist) Date: 2004-04-21 17:20 Message: Logged In: YES user_id=1025858 0.3 is using the exit codes from yum now! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=939170&group_id=29880 From gerwin at digitalus.nl Wed Apr 21 08:24:01 2004 From: gerwin at digitalus.nl (Gerwin Krist -|- Digitalus.NL) Date: Wed Apr 21 08:24:01 2004 Subject: [Nagiosplug-devel] New plugin: check_yum In-Reply-To: <1082557658.4475.2.camel@pel> References: <1082541331.13681.6.camel@gerwin.digitalus.nl> <1082557658.4475.2.camel@pel> Message-ID: <1082560888.26863.55.camel@sarah.krist.dmn> Thanks for the tip, I changed it right away. I had some problems for getting the error codes within bash (i normally don't use bash scripts for my scripting needs). But now it's completely based on the exit codes from yum. G. Krist PS. Sorry if this messages is sent 2 times! On Wed, 2004-04-21 at 16:27, Sean Dilda wrote: > On Wed, 2004-04-21 at 05:55, Gerwin Krist -|- Digitalus.NL wrote: > > details at: > > > > https://sourceforge.net/tracker/index.php?func=detail&aid=939170&group_id=29880&atid=541465 > > > > Interesting. From a quick look, I'd suggest relying more on exit codes > and textual output. From the man page, if the exit code is 100, then > your system is not up to date. If its 0, your system is up to date. If > its anything else, yum had a problem running. (A quick check just > showed python exits with a status of 1 if there's an IOError) > > Checking the exit codes is a little more robust than your current > method. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Nagiosplug-devel mailing list > Nagiosplug-devel at lists.sourceforge.net > 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 -- Met vriendelijke groet/With kind regards, Gerwin Krist System Engineer Digitalus First-class Internet Webhosting URL: http://www.digitalus.nl Email: g.krist at digitalus.nl Tel: +31 (0) 598 630000 Fax: +31 (0) 598 631860 *************************************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. *************************************************************************************** From agrajag at dragaera.net Wed Apr 21 10:18:02 2004 From: agrajag at dragaera.net (Sean Dilda) Date: Wed Apr 21 10:18:02 2004 Subject: [Nagiosplug-devel] New plugin: check_yum In-Reply-To: <1082560888.26863.55.camel@sarah.krist.dmn> References: <1082541331.13681.6.camel@gerwin.digitalus.nl> <1082557658.4475.2.camel@pel> <1082560888.26863.55.camel@sarah.krist.dmn> Message-ID: <1082567838.4475.13.camel@pel> On Wed, 2004-04-21 at 11:21, Gerwin Krist -|- Digitalus.NL wrote: > Thanks for the tip, I changed it right away. I had some problems for > getting the error codes within bash (i normally don't use bash scripts > for my scripting needs). But now it's completely based on the exit codes > from yum. Just looked at the new version. It looks good. Although I still have a few small suggestions I'd like to make :) First is you seem to have a carriage return before your '#!/bin/sh' That'll work in most cases, but is technically wrong and will cause problems in a few instances. For the return codes, I'd suggest removing the check for $returncode = 1. Then, after after the check for $returncode = 0, have it give the error for yum related problem, without checking the returncode. Just assume anything other than 0 or 100 is a yum problem. Right now if yum gives any other exit code, your plugin will exit normally with a return code of 0, which is kinda bad. From jim.mozley at exponential-e.com Thu Apr 22 01:43:05 2004 From: jim.mozley at exponential-e.com (Jim Mozley) Date: Thu Apr 22 01:43:05 2004 Subject: [Nagiosplug-devel] check_sonet plugin Message-ID: <4087856A.2080404@exponential-e.com> Below is a plugin for checking sonet/sdh interfaces. I'm unsure of the submission process for contributed plugins but anyone is welcome to use it. I've aimed to abide by the plug-in guidelines. One obvious difference I can see is that I've used warnings rather than perl -w (which I guess could cause problems with anyone using pre 5.6 perl?). Happy to correct anything like this should the plugin be deemed useful enough or suitable to include in any contrib type distribution. This has been tested on RiverStone switches so I'd welcome any feedback from anyone who can test it on other vendors equipment. Jim Mozley #!/usr/local/bin/perl =head1 Description This plug-in uses SNMP to check the Sonet MIB (RFC 2558) for the status of SONET or SDH interfaces. The information is collected by querying the ifType table to determine the Sonet interfaces. Each physical sonet interface also has a logical path interface. If these interfaces are administratively up then the Sonet MIB status tables for the line sections and path are checked. The status is defined in the Sonet MIB as an integer representing a binary whose bit positions indicate problems. See RFC 2558. Line and section problems are flagged against the physical interface, while path errors are flagged against the logical path interface. It is intended to check the sonet interfaces on a host as one service rather than treating them as individual services to reduce the number of SNMP queries to the device. =cut use strict; use warnings; use POSIX; use Net::SNMP; use Getopt::Long; Getopt::Long::Configure('bundling'); use lib "/usr/local/nagios/libexec" ; use utils qw($TIMEOUT %ERRORS &print_revision &support); my $PROGNAME = "check_sonet"; my $status; my $state = "UNKNOWN"; my $answer = ""; my $community = "public"; my $port = 161; my @snmpoids; my $ifType = '1.3.6.1.2.1.2.2.1.3'; my $ifAdminStatus = '1.3.6.1.2.1.2.2.1.7'; my $ifName = '1.3.6.1.2.1.31.1.1.1.1'; my $ifDescr = '1.3.6.1.2.1.2.2.1.2'; my $lineStatus = '1.3.6.1.2.1.10.39.1.3.1.1.1'; my $sectionStatus = '1.3.6.1.2.1.10.39.1.2.1.1.1'; my $pathStatus = '1.3.6.1.2.1.10.39.2.1.1.1.2'; my $hostname; my %ifStatus; my $lineup = 0; my $sectionup = 0; my $pathup = 0; my $iferr = 0; my $ifmessage = ""; my $snmp_version = 1; my $opt_h; my $opt_V; # Just in case of problems, let's not hang Nagios $SIG{'ALRM'} = sub { print ("ERROR: No snmp response from $hostname (alarm timeout)\n"); exit $ERRORS{"UNKNOWN"}; }; alarm($TIMEOUT); #Option checking $status = GetOptions( "V" => \$opt_V, "version" => \$opt_V, "h" => \$opt_h, "help" => \$opt_h, "v=i" => \$snmp_version, "snmp_version=i" => \$snmp_version, "C=s" => \$community, "community=s" => \$community, "p=i" => \$port, "port=i" => \$port, "H=s" => \$hostname, "hostname=s" => \$hostname, ); if ($status == 0) { print_help() ; exit $ERRORS{'OK'}; } if ($opt_V) { print_revision($PROGNAME,'$Revision: 1.0 $ '); exit $ERRORS{'OK'}; } if ($opt_h) { print_help(); exit $ERRORS{'OK'}; } if (! utils::is_hostname($hostname)){ usage(); exit $ERRORS{"UNKNOWN"}; } unless ( $snmp_version =~ /[12]/ ) { $state='UNKNOWN'; print ("$state: No support for SNMP v$snmp_version yet\n"); exit $ERRORS{$state}; } my ($session, $error) = Net::SNMP->session( -hostname => $hostname, -community => $community, -port => $port, -version => $snmp_version ); unless ( $session ) { $state='UNKNOWN'; $answer=$error; print ("$state: $answer"); exit $ERRORS{$state}; } push(@snmpoids, $ifType, $ifAdminStatus, $ifDescr, $lineStatus, $sectionStatus, $pathStatus ); foreach my $tableoid (@snmpoids) { my $varbind_ref; my $oid; unless (defined($varbind_ref = $session->get_table($tableoid))) { $answer = $session->error; $session->close; $state = 'CRITICAL'; print ("$state: $answer for $tableoid with snmp version $snmp_version\n"); exit $ERRORS{$state}; } foreach (keys %{$varbind_ref}) { my ( $index ) = /.*\.(\d+)$/; $ifStatus{$index}{$tableoid} = $varbind_ref->{$_}; } } $session->close; foreach my $index (keys %ifStatus) { # check only if interface is administratively up if ($ifStatus{$index}{$ifAdminStatus} == 1 ) { # if interface is a sonet (39) check sonetLineCurrentStatus # and sonetSectionCurrentStatus tables if ( $ifStatus{$index}{$ifType} == 39 ) { if ( $ifStatus{$index}{$lineStatus} == 1 ) { $lineup++; } else { $iferr++; my @status = line_status( bit_positions( $ifStatus{$index}{$lineStatus} ) ); $ifmessage .= sprintf( "%s: line status %s ", $ifStatus{$index}{$ifDescr}, join ',', @status ); } if ( $ifStatus{$index}{$sectionStatus} == 1 ) { $sectionup++; } else { $iferr++; my @status = section_status( bit_positions( $ifStatus{$index}{$sectionStatus} ) ); $ifmessage .= sprintf( "%s: section status is %s ", $ifStatus{$index}{$ifDescr}, join ',', @status ); } } # if interface is a sonetPath (50) check # sonetPathCurrentStatus table if ( $ifStatus{$index}{$ifType} == 50 ) { if ( $ifStatus{$index}{$pathStatus} == 1 ) { $pathup++; } else { $iferr++; my @status = path_status( bit_positions( $ifStatus{$index}{$pathStatus} ) ); $ifmessage .= sprintf( "%s: path status is %s ", $ifStatus{$index}{$ifDescr}, join ',', @status ); } } } } if ($iferr > 0) { $state = 'CRITICAL'; $answer = sprintf( "host '%s' - %d errors: ", $hostname, $iferr, ); $answer = $answer . $ifmessage . "\n"; } else { $state = 'OK'; $answer = sprintf( "host '%s', %d lines, sections and paths up", $hostname, $lineup + $sectionup + $pathup, ); $answer = $answer . $ifmessage . "\n"; } print ("$state: $answer"); exit $ERRORS{$state}; # Name: bit_positions # Input: integer # Description: Takes an integer and converts this to a binary. Each bit # that is set to one is converted back to its decimal value and the list # of these is returned. # e.g. we are passed integer 20 representing binary 10100 so we need # to return 16 and 4. # Returns: list of bit positions sub bit_positions { my @bits = split //, dec2bin( shift ); my @bit_pos; # go through the bits looking for 1's while ( @bits ) { my $length = scalar @bits; next unless shift @bits; # skip if this bit is zero # Build the binary number and add the decimal conversion of # it to the list of bit positions. my $format = "%-$length" . "s"; my $binnum = sprintf( $format, 1 ); $binnum =~ tr/ /0/; push @bit_pos, bin2dec( $binnum ); } return reverse @bit_pos; } # end bit_positions # Names: line_status, section_status, path_status # Input: list of numbers # Description: These return the status values correponding to the # bit positions as in the SONET-MIB # Returns: list of status values sub line_status { my %status = ( 1 => 'sonetLineNoDefect', 2 => 'sonetLineAIS', 4 => 'sonetLineRDI', ); return @status{ @_ }; } # end line_status sub section_status { my %status = ( 1 => 'sonetSectionNoDefect', 2 => 'sonetSectionLOS', 4 => 'sonetSectionLOF', ); return @status{ @_ }; } # end section_status sub path_status { my %status = ( 1 => 'sonetPathNoDefect', 2 => 'sonetPathSTSLOP', 4 => 'sonetPathSTSAIS', 8 => 'sonetPathSTSRDI', 16 => 'sonetPathUnequipped', 32 => 'sonetPathSignalLabelMismatch', ); return @status{ @_ }; } # end path_status # Names: dec2bin, bin2dec # Input: decimal or binary # Description: These convert decimal to binary # Returns: converted number sub dec2bin { my $str = unpack("B32", pack("N", shift)); $str =~ s/^0+(?=\d)//; # remove leading zeros return $str; } sub bin2dec { return unpack("N", pack("B32", substr("0" x 32 . shift, -32))); } sub usage { (my $usage = <<' USAGEEND') =~ s/^\s+//gm; Usage: check_sonet -H -p -v -C check_sonet -h # for help check_sonet -V # for version of this plug-in USAGEEND print $usage; support(); exit $ERRORS{"UNKNOWN"}; } # end usage sub print_help { (my $help = <<' HELPEND') =~ s/^\s+//gm; Help: check_sonet plugin for Nagios monitors the status of Sonet network interface on the target host Options: -H (--hostname) Hostname to query - (required) -p (--port) SNMP port (default 161) -C (--community) SNMP read community (defaults to public) -v (--snmp_version) 1 for SNMPv1 (default) 2 for SNMPv2c -V Plugin version -h (--help) help HELPEND print $help; print_revision($PROGNAME, '$Revision: 1.0 $'); } # end print_help From noreply at sourceforge.net Thu Apr 22 09:12:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 09:12:14 2004 Subject: [Nagiosplug-devel] [ nagiosplug-New Plugins-940139 ] check Network UPS Tools daemon Message-ID: New Plugins item #940139, was opened at 2004-04-22 18:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=940139&group_id=29880 Category: Perl plugin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fabio (blaxwan) Assigned to: Nobody/Anonymous (nobody) Summary: check Network UPS Tools daemon Initial Comment: I found that check_ups doesn't work with nut 2.0 (www.networkupstools.org) so I wrote this simple perl plugin for monitoring my ups. I hope it may be useful to someone else. The plugin simply contact the upsd on the specified (or default) port, logins to the specified ups and ask for ups.status variable It reports: - OK when the ups is running on AC power - WARNING when the ups is running on battery or has some minor trouble - CRITICAL when the ups is running low on battery or is not running at all I have it in "production" since last week, no problems at all......it's too simple for fail! Thanks P.S. I don't know exactly which files to patch/diff for installation, here is the patch for command.cfg.in --- command.cfg.in.backup 2004-04-20 17:10:28.000000000 +0200 +++ command.cfg.in 2004-04-20 17:11:52.000000000 +0200 @@ -91,6 +91,7 @@ command[check_procs]=@libexecdir@/check_ command[check_procs_zombie]=@libexecdir@/check_procs -w $ARG1$ -c $ARG2$ -s Z command[check_procs_httpd]=@libexecdir@/check_procs -w 5:$ARG1$ -c 1:$ARG2$ -C httpd command[check_vsz]=@libexecdir@/check_vsz -w 8096 -c 16182 -C httpd +command[check_nut]=@libexecdir@/check_nut -H $HOSTADDRESS$ -u $ARG1$ -l $ARG2$ -p $ARG3$ -P $ARG4$ # An example of using check_by_ssh as an active service check command[ssh_disk]=@libexecdir@/check_by_ssh -H $HOSTADDRESS$ -C '@libexecdir@/check_disk -w 85% -c 95% -p $ARG1$' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541465&aid=940139&group_id=29880 From tonvoon at mac.com Thu Apr 22 16:57:05 2004 From: tonvoon at mac.com (Ton Voon) Date: Thu Apr 22 16:57:05 2004 Subject: [Nagiosplug-devel] Partial feature additions In-Reply-To: References: Message-ID: On 19 Apr, 2004, at 18:29, Jason Martin wrote: > I'm looking to add a feature to check_procs that deals with the age of > the > process. I see that that check_procs has ps format listings for quite > a > few platforms and I only have access to a few. Would it be acceptable > to > submit a patch that only enables that functionality on a subset of > platforms? Is there a standard way of dealing with this sort of > situation? > > This is an interesting idea and would be useful - someone has already made this suggestion but I had rejected it because of the work involved. I think it will probably be very hard to do as there would have to be a lot of intelligence in evaluating the ps output (etime available? Is format different?). However, if you would like to have a go, I would be keen to see your patch. It would be unrealistic to insist on all platforms if you do not have access, but I think you would need to prove your change would work on at least 3 platforms to increase confidence in non-OS specific functionality. This change would not go into the 1.4 release - it would be added to the 1.5 release. Just to give you an idea of what I have planned (time permitting), my medium term aim is to separate the ps code out of check_procs and check_nagios into utils.c with a routine called (say) psopen to start a ps fork, with subsequent psgets to return each process information into a process structure (with null values for columns that are not defined). This would allow more flexibility in the functionality per OS. The long term strategy is to move to other libraries that handle the cross-platform issues (such as check_disk using the GNU coreutils code), but I don't think there is a suitable one for process listings. Ton From nagios at proy.org Sun Apr 25 15:29:04 2004 From: nagios at proy.org (Patrick Proy) Date: Sun Apr 25 15:29:04 2004 Subject: [Nagiosplug-devel] SNMP plugin Message-ID: <20040425222746.9EFB1ABBB4@www.manubulon.com> Hi everbody, I wrote some plugins which can check by snmp disks, interface and process on a remote host. I tried to be platform independant (currently tested on Linux, Windows, Cisco, AS400). I wrote these new plugins to be able to use snmp v1 and v3 and to select disks, interfaces and processes by perl regexp (for ex. '[CDE]:' to check C,D and E disk on Windows, 'Fast.*0.1[1234]' to check FastEthernet0/11 to 0/14 on Cisco, etc...). You can download them at http://www.manubulon.com/nagios/ Please send me your feedback, advices, PLATFORMS YOU TESTED at nagios at proy.org . Patrick Proy nagios at proy.org From frank at confra.nl Mon Apr 26 07:23:05 2004 From: frank at confra.nl (Frank Schuurman) Date: Mon Apr 26 07:23:05 2004 Subject: [Nagiosplug-devel] could not interpret ping output Message-ID: <0E3DA3B8048E254491EC61B94802D1240177F5@nlvbntex03.Confra.local> Hi, I have a problem getting the stuff right. I use the 1.4 plugin series. Downloaded, ./configure, make, make install en use it. (just the same as de RH5 box). The reason to go to Mandrake was that the de RH5 box was not up to date with the Libs, and Mandrake came for free. [root at nagios libexec]# ./check_ping -H 213.10.27.129 -w 400,20% -c 600,60% -t 30 /bin/ping -n -c 5 213.10.27.129 Error: Could not interpret output from ping command On the RH5 box it works fine. I don't know were to look now. I don't want to implement a Windows sort of HP Openview app. but I have not much resources available to promote Linux in my org. Ping Mandrake Linux 9.2 [root at nagios libexec]# /bin/ping -n -c 5 213.10.27.129 PING 213.10.27.129 (213.10.27.129) 56(84) bytes of data. 64 bytes from 213.10.27.129: icmp_seq=1 ttl=245 time=27.7 ms 64 bytes from 213.10.27.129: icmp_seq=2 ttl=245 time=27.5 ms 64 bytes from 213.10.27.129: icmp_seq=3 ttl=245 time=27.5 ms 64 bytes from 213.10.27.129: icmp_seq=4 ttl=245 time=26.9 ms 64 bytes from 213.10.27.129: icmp_seq=5 ttl=245 time=26.9 ms --- 213.10.27.129 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4038ms rtt min/avg/max/mdev = 26.994/27.379/27.794/0.358 ms Ping RedHat Linux 5.0 [root at nagios libexec]# /bin/ping -n -c 5 213.10.27.129 PING 213.10.27.129 (213.10.27.129): 56 data bytes 64 bytes from 213.10.27.129: icmp_seq=0 ttl=245 time=27.8 ms 64 bytes from 213.10.27.129: icmp_seq=1 ttl=245 time=29.1 ms 64 bytes from 213.10.27.129: icmp_seq=2 ttl=245 time=28.2 ms 64 bytes from 213.10.27.129: icmp_seq=3 ttl=245 time=28.4 ms 64 bytes from 213.10.27.129: icmp_seq=4 ttl=245 time=28.6 ms --- 213.10.27.129 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 27.8/28.4/29.1 ms Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From syn_uw at hotmail.com Mon Apr 26 23:34:01 2004 From: syn_uw at hotmail.com (syn uw) Date: Mon Apr 26 23:34:01 2004 Subject: [Nagiosplug-devel] check_ups and NUT 2.0 Message-ID: Hello, I just wanted to report that check_ups doesn't seem to work with NUT 2.0, I guess this is due that NUT 2.0 has changed it's protocol a bit on how it talks to the ups daemon. Is there maybe already a patch available for check_ups to work with NUT 2.0 ? Many thanks in advance Regards _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From noreply at sourceforge.net Tue Apr 27 13:08:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 27 13:08:12 2004 Subject: [Nagiosplug-devel] [ nagiosplug-Feature Requests-816804 ] More to add for check_nwstat Message-ID: Feature Requests item #816804, was opened at 2003-10-02 20:45 Message generated for change (Settings changed) made by faucon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=816804&group_id=29880 Category: None Group: None Status: Open >Priority: 1 Submitted By: Alex (faucon) Assigned to: Nobody/Anonymous (nobody) Summary: More to add for check_nwstat Initial Comment: Hello, James Drews (who does mrtgext.nlm) as release a new version of mrtgext (version 1.43). ---from the readme.txt of mrtgext--- [...] The following were added to version 1.43 S28 : Current Service Processes MP S29 : Total Server Memory (bytes) S30 : Allocated Memory (bytes) [...] ---end--- Check it out here... http://forge.novell.com/modules/xfmod/project/?mrtgext ...if you need to. This sample of the readme.txt file only show what I would like to be added , of course ;) I can test the modifications if you need to. Thanks! Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397600&aid=816804&group_id=29880 From noreply at sourceforge.net Wed Apr 28 13:58:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 28 13:58:04 2004 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-944000 ] Patch to improve check_dig Message-ID: Patches item #944000, was opened at 2004-04-28 20:57 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=944000&group_id=29880 Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill Kunkel (gollum13) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to improve check_dig Initial Comment: This patch adds the ability to set the record type (i.e. A, MX, NS, etc) that gets passed to dig and also set an string expected in the answer section of the dig results. This is very usefull to keep an eye on things like MX records to know when the go missing or get changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=944000&group_id=29880