From noreply at sourceforge.net Fri May 1 11:25:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 May 2009 09:25:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2731755 ] check_nt crashes Message-ID: Bugs item #2731755, was opened at 2009-04-04 20:14 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2731755&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_nt crashes Initial Comment: The following Bugreport we got against our debian package: Package: nagios-plugins-basic Version: 1.4.11-2ubuntu2.1 Severity: normal Can crash in 2 ways: - if -H $host is not specified; - if -l $drive is given for a drive which doesn't exist This patch fixes 2 bugs: . Crash when -H specified multiple times; . Crash when -H specified zero times; It doesn't fix the parsing problem when -l is specified for a drive that doesn't exist. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521097 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-05-01 11:25 Message: Hi Jan, this is fixed now in our git repo. The -l problem has already been fixed: commit 31efea1b490a12a64ce0359c2d847a381d2efb7b Author: Ton Voon Date: Thu Feb 19 23:43:15 2009 +0000 Fixed coredump from check_nt when drive not found (Olli Hauer - SF 2179754) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2731755&group_id=29880 From noreply at sourceforge.net Fri May 1 12:06:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 May 2009 10:06:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2784928 ] check_disk no longer hangs on hanging filesystems Message-ID: Patches item #2784928, was opened at 2009-05-01 12:06 Message generated for change (Tracker Item Submitted) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk no longer hangs on hanging filesystems Initial Comment: Hi, i created a patch for check_disk (v2025/1.4.13) which can handle hanging nfs filesystems. Imagine you mounted a share from a NAS at the mountpoint /mnt. Now if the Storage device or whatever acts as NFS server dies or encounters a network problem, you will see messages like "NFS server nas.naprax.de not responding still trying" and every process accessing files inside the /mnt directory will be blocked, maybe forever. Depending on the mount options the hanging processes may even be invulnerable to a kill -9. This also applies to check_disk. If you have a service monitoring usage of /mnt with "check_disk ... -p /mnt", it will also be blocked. Nagios will report a timeout then. But the bad thing is, every minutes another check_disk will be started which also will hang then. Sooner or later your process list fills up with unkillable check_disks. The critical piece of code inside check_disk is the stat system call, which is in the moment needed to find out, if a path exists at all. If that stat call hits a directory which is mounted from a dead nfs server, it will not return with an error code, but will not return at all. I found out that although processes cannot be killed in such a situations, threads can. So i rewrote the stat_path subroutine in a way, where the critical stat is executed in it's own thread. If this thread does not terminate within the --timeout interval, it is considered to be blocked by a dead nfs filesystem and the thread will be detached. I tested it on Linux 2.6.18 (gcc 4.1.2) and Solaris 10/x86 (gcc 3.4.3) # mount -ohard,nointr nas.naprax.de:/mnt/md1/db2 /mnt $ check_disk -w 2G -c 1G -p /mnt DISK OK - free space: /mnt 67815 MB (7% inode=99%);| /mnt=823060MB;938549;938550;0;938551 Then i switched off the nas device: $ check_disk -w 3G -c 2G -p /mnt DISK CRITICAL - /mnt hangs: Timeout $ check_disk -t 5 -w 3G -c 1G -p /mnt/rollout-p DISK CRITICAL - /mnt/rollout-p hangs: Timeout real 0m5.013s user 0m0.001s sys 0m0.003s The patch includes modifications to plugins/check_disk.c : include pthread.h, prototype for do_stat_path, the old stat_path was renamed to do_stat_path and the new stat_path uses the thread trick (and calls the old stat_path code inside a thread) plugins/Makefile.am : added -lpthread to check_disk_LDADD configure.in : check for presence of libpthread,pthread.h I hope this is useful to you. Gerhard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 From noreply at sourceforge.net Fri May 1 17:17:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 May 2009 15:17:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2784928 ] check_disk no longer hangs on hanging filesystems Message-ID: Patches item #2784928, was opened at 2009-05-01 12:06 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk no longer hangs on hanging filesystems Initial Comment: Hi, i created a patch for check_disk (v2025/1.4.13) which can handle hanging nfs filesystems. Imagine you mounted a share from a NAS at the mountpoint /mnt. Now if the Storage device or whatever acts as NFS server dies or encounters a network problem, you will see messages like "NFS server nas.naprax.de not responding still trying" and every process accessing files inside the /mnt directory will be blocked, maybe forever. Depending on the mount options the hanging processes may even be invulnerable to a kill -9. This also applies to check_disk. If you have a service monitoring usage of /mnt with "check_disk ... -p /mnt", it will also be blocked. Nagios will report a timeout then. But the bad thing is, every minutes another check_disk will be started which also will hang then. Sooner or later your process list fills up with unkillable check_disks. The critical piece of code inside check_disk is the stat system call, which is in the moment needed to find out, if a path exists at all. If that stat call hits a directory which is mounted from a dead nfs server, it will not return with an error code, but will not return at all. I found out that although processes cannot be killed in such a situations, threads can. So i rewrote the stat_path subroutine in a way, where the critical stat is executed in it's own thread. If this thread does not terminate within the --timeout interval, it is considered to be blocked by a dead nfs filesystem and the thread will be detached. I tested it on Linux 2.6.18 (gcc 4.1.2) and Solaris 10/x86 (gcc 3.4.3) # mount -ohard,nointr nas.naprax.de:/mnt/md1/db2 /mnt $ check_disk -w 2G -c 1G -p /mnt DISK OK - free space: /mnt 67815 MB (7% inode=99%);| /mnt=823060MB;938549;938550;0;938551 Then i switched off the nas device: $ check_disk -w 3G -c 2G -p /mnt DISK CRITICAL - /mnt hangs: Timeout $ check_disk -t 5 -w 3G -c 1G -p /mnt/rollout-p DISK CRITICAL - /mnt/rollout-p hangs: Timeout real 0m5.013s user 0m0.001s sys 0m0.003s The patch includes modifications to plugins/check_disk.c : include pthread.h, prototype for do_stat_path, the old stat_path was renamed to do_stat_path and the new stat_path uses the thread trick (and calls the old stat_path code inside a thread) plugins/Makefile.am : added -lpthread to check_disk_LDADD configure.in : check for presence of libpthread,pthread.h I hope this is useful to you. Gerhard ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-05-01 17:17 Message: Hi Gerhard, great enhancement. Have you tested this on other platforms also? I think this would also be great to have in the upcoming release. Will review it and do some further testing. Thanks a lot Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 From noreply at sourceforge.net Fri May 1 22:30:56 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 01 May 2009 20:30:56 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2784928 ] check_disk no longer hangs on hanging filesystems Message-ID: Patches item #2784928, was opened at 2009-05-01 12:06 Message generated for change (Comment added) made by lausser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: gerhard lausser (lausser) Assigned to: Nobody/Anonymous (nobody) Summary: check_disk no longer hangs on hanging filesystems Initial Comment: Hi, i created a patch for check_disk (v2025/1.4.13) which can handle hanging nfs filesystems. Imagine you mounted a share from a NAS at the mountpoint /mnt. Now if the Storage device or whatever acts as NFS server dies or encounters a network problem, you will see messages like "NFS server nas.naprax.de not responding still trying" and every process accessing files inside the /mnt directory will be blocked, maybe forever. Depending on the mount options the hanging processes may even be invulnerable to a kill -9. This also applies to check_disk. If you have a service monitoring usage of /mnt with "check_disk ... -p /mnt", it will also be blocked. Nagios will report a timeout then. But the bad thing is, every minutes another check_disk will be started which also will hang then. Sooner or later your process list fills up with unkillable check_disks. The critical piece of code inside check_disk is the stat system call, which is in the moment needed to find out, if a path exists at all. If that stat call hits a directory which is mounted from a dead nfs server, it will not return with an error code, but will not return at all. I found out that although processes cannot be killed in such a situations, threads can. So i rewrote the stat_path subroutine in a way, where the critical stat is executed in it's own thread. If this thread does not terminate within the --timeout interval, it is considered to be blocked by a dead nfs filesystem and the thread will be detached. I tested it on Linux 2.6.18 (gcc 4.1.2) and Solaris 10/x86 (gcc 3.4.3) # mount -ohard,nointr nas.naprax.de:/mnt/md1/db2 /mnt $ check_disk -w 2G -c 1G -p /mnt DISK OK - free space: /mnt 67815 MB (7% inode=99%);| /mnt=823060MB;938549;938550;0;938551 Then i switched off the nas device: $ check_disk -w 3G -c 2G -p /mnt DISK CRITICAL - /mnt hangs: Timeout $ check_disk -t 5 -w 3G -c 1G -p /mnt/rollout-p DISK CRITICAL - /mnt/rollout-p hangs: Timeout real 0m5.013s user 0m0.001s sys 0m0.003s The patch includes modifications to plugins/check_disk.c : include pthread.h, prototype for do_stat_path, the old stat_path was renamed to do_stat_path and the new stat_path uses the thread trick (and calls the old stat_path code inside a thread) plugins/Makefile.am : added -lpthread to check_disk_LDADD configure.in : check for presence of libpthread,pthread.h I hope this is useful to you. Gerhard ---------------------------------------------------------------------- Comment By: gerhard lausser (lausser) Date: 2009-05-01 22:30 Message: No, just Linux and Solaris10. I hope, the thread code behaves identically on other platforms. Maybe i get access to HPUX11.11, but i can only test it with an intact filesystem. They won't allow me to switch off a nas storage. Gerhard ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2009-05-01 17:17 Message: Hi Gerhard, great enhancement. Have you tested this on other platforms also? I think this would also be great to have in the upcoming release. Will review it and do some further testing. Thanks a lot Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2784928&group_id=29880 From noreply at sourceforge.net Mon May 4 21:19:43 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 04 May 2009 19:19:43 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2786808 ] check_http asks for HTTP/1.1, but doesn't understand chunked Message-ID: Bugs item #2786808, was opened at 2009-05-04 21:19 Message generated for change (Tracker Item Submitted) made by wferi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ferenc W?gner (wferi) Assigned to: Nobody/Anonymous (nobody) Summary: check_http asks for HTTP/1.1, but doesn't understand chunked Initial Comment: Fixing 2638765 uncovered this bug (actually, most HTTP servers respect Host: headers in HTTP/1.0 requests, even though it isn't part of the spec). Anyway: if a client sends a HTTP/1.1 request, it must be able to handle the incoming HTTP/1.1 reply. Which includes coping with a chunked one. This exact same command worked with check_http version 1.4.5 (and still does so with -H replaced by -I, but that isn't the point). $ /usr/lib/nagios/plugins/check_http -v -H idp.niif.hu -u /idp/profile/Status --ssl -r "^ok$" GET /idp/profile/Status HTTP/1.1 Host: idp.niif.hu:443 User-Agent: check_http/v1991 (nagios-plugins 1.4.12) Connection: close https://idp.niif.hu:443/idp/profile/Status is 141 characters STATUS: HTTP/1.1 200 OK **** HEADER **** Date: Mon, 04 May 2009 19:12:13 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/plain **** CONTENT **** 2 ok 0 HTTP CRITICAL - pattern not found|time=0.067933s;;;0.000000 size=141B;;;0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&group_id=29880 From sbennett at groundworkopensource.com Tue May 5 23:40:55 2009 From: sbennett at groundworkopensource.com (Simon Bennett) Date: Tue, 05 May 2009 14:40:55 -0700 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright Message-ID: I've got a couple of patches to the core Nagios plug-ins set that I'd like to contribute back to the project. They were created for our customers but some might be generally useful. The FAQ mentioned to post to this list if you'd like to contribute but want to retain copyright. The copyright in this case is my company's. I searched the archives but didn't see any discussion of how to achieve this? -- Simon Bennett GROUNDWORK Open Source, Inc. sbennett at gwos.com NOTICE: This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this email or its contents is strictly prohibited.If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. From ton.voon at opsera.com Wed May 6 10:02:35 2009 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 6 May 2009 09:02:35 +0100 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: References: Message-ID: Hi Simon, On 5 May 2009, at 22:40, Simon Bennett wrote: > I've got a couple of patches to the core Nagios plug-ins set that > I'd like > to contribute back to the project. They were created for our > customers but > some might be generally useful. The FAQ mentioned to post to this > list if > you'd like to contribute but want to retain copyright. The copyright > in this > case is my company's. Any contributed code that gets back into the main code from now on is accepted on the basis that the copyright can be given to the Nagios Plugin team. I've updated the FAQ entry to be clearer on that policy: http://nagiosplugins.org/copyright We'd be happy to hear about any changes, but only if you are willing to relinquish copyright. Ton From Sascha.Runschke at gfkl.com Wed May 6 11:02:12 2009 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Wed, 6 May 2009 11:02:12 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Contributing patches and retaining copyright In-Reply-To: References: Message-ID: > Any contributed code that gets back into the main code from now on is > accepted on the basis that the copyright can be given to the Nagios > Plugin team. I've updated the FAQ entry to be clearer on that policy: > http://nagiosplugins.org/copyright > > We'd be happy to hear about any changes, but only if you are willing > to relinquish copyright. Hi Ton, for most people - including me, it is unacceptable to fully relinquish the copyright on something that's my (or my companies) work. The reasoning that the plugins team needs "the right" to make changes to the code even after the original author has withdrawn from public does not really make sense to me. After all the code is GPL and everyone can do whatever he wants with it - as long as the copyright and GPL notice are retained. May I ask what the reasons behind this are? I just don't get it. Regards Sascha GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 From ton.voon at opsera.com Wed May 6 11:34:21 2009 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 6 May 2009 10:34:21 +0100 Subject: [Nagiosplug-devel] Antwort: Re: Contributing patches and retaining copyright In-Reply-To: References: Message-ID: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> On 6 May 2009, at 10:02, Sascha.Runschke at gfkl.com wrote: >> Any contributed code that gets back into the main code from now on is >> accepted on the basis that the copyright can be given to the Nagios >> Plugin team. I've updated the FAQ entry to be clearer on that policy: >> http://nagiosplugins.org/copyright >> >> We'd be happy to hear about any changes, but only if you are willing >> to relinquish copyright. > > Hi Ton, > > for most people - including me, it is unacceptable to fully > relinquish the copyright on something that's my (or my > companies) work. The reasoning that the plugins team needs > "the right" to make changes to the code even after the > original author has withdrawn from public does not really make > sense to me. After all the code is GPL and everyone can do > whatever he wants with it - as long as the copyright and > GPL notice are retained. We're following advice given by FSF: http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright If you have contributed some code to the project, we thank you and we make sure you (and/or your company) get credit. But in reality, the team take on the responsibility to make sure that the code continues to work correctly. Not just at commit time, but forever. I think this continued responsibility should be reflected in the ownership of the code. The upshot for you (and/or your company) is that you no longer maintain that code anymore - that has to be worth something! Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From Guillaume.Rousse at inria.fr Wed May 6 13:26:38 2009 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Wed, 06 May 2009 13:26:38 +0200 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <49F832A8.2070507@aei.ca> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> <49F71E7E.8000900@inria.fr> <49F76226.5020907@aei.ca> <49F80657.5070300@inria.fr> <49F832A8.2070507@aei.ca> Message-ID: <4A0173EE.1010405@inria.fr> Thomas Guyot-Sionnest a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 29/04/09 03:48 AM, Guillaume Rousse wrote: >> Thomas Guyot-Sionnest a ?crit : >>>> Also, I'm still interested in having my LDAP certificat patch reviewed: >>>> [2430999] add check certificate support for LDAP plugin >>>> >>>> Last comment I received asked for a test case, without information about >>>> what kind of test case exactly. >>> I can't easily implement automated tests for this... What I was looking >>> for is a publicly-reachable server on which I can test the feature manually. >> I never heard of available public ldap servers. Especially with sensible >> content that would require encryption support... > > Oh! Sorry, I was talking about another patch (SNI support)! The one you > mentioned wasn't in my list... Just try www.msr-inria.inria.fr, sympa.msr-inria.inria.fr and stats.msr-inria.inria.fr > Have you tried check_http's certificate check against LDAP?? I believe > the -C options makes it a simple certificate check? If so the > certificate check would better fit on check_tcp with a symlink > (check_certificate) for checking any SSL certificate. check_tcp generic support is fine for SSL connections (ldaps), indeed, but not for TLS, which require protocol-specific knowledge. The same is true for pop, imap and smtp, BTW. -- BOFH excuse #190: Proprietary Information. From Sascha.Runschke at gfkl.com Wed May 6 14:35:34 2009 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Wed, 6 May 2009 14:35:34 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Antwort: Re: Contributing patches and retaining copyright In-Reply-To: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> Message-ID: > We're following advice given by FSF: http://www.gnu.org/licenses/ > gpl-faq.html#AssignCopyright > > If you have contributed some code to the project, we thank you and > we make sure you (and/or your company) get credit. But in reality, > the team take on the responsibility to make sure that the code > continues to work correctly. Not just at commit time, but forever. Well, the above FAQ entry does not mention a single word about "ease of maintainance of code", but instead it's all about those GPL fanatics and their lawyers. While I like the GPL, I do not like the fanatism some of the "open source evangalists" come around like. No offense here against anyone involved in this discussion - I do have some special people of the GPL public in mind, but I don't like calling names. > I think this continued responsibility should be reflected in the > ownership of the code. > > The upshot for you (and/or your company) is that you no longer > maintain that code anymore - that has to be worth something! I don't think that continued responsibility has _anything_ to do with ownership - at least not with GPLed code. Regards Sascha GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 From addw at phcomp.co.uk Wed May 6 15:17:23 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Wed, 6 May 2009 14:17:23 +0100 Subject: [Nagiosplug-devel] Antwort: Re: Antwort: Re: Contributing patches and retaining copyright In-Reply-To: References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> Message-ID: <20090506131722.GD16192@mint.phcomp.co.uk> On Wed, May 06, 2009 at 02:35:34PM +0200, Sascha.Runschke at gfkl.com wrote: > > We're following advice given by FSF: http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright Basically they are saying: If we are the copyright owners then we can legally bash anyone who infringes the copyright. I can see their point, it makes life simpler. However: if that situation were to arise with nagios plugins, then there is no reason why the different plugin owners could not give Ton Voon/whoever the legal right to protect (ie sue for infringing use of the code). The point about it being easier if the owner/maintainer were to abandon it is wrong - it is GPL, there is nothing to stop you forking it - if the owner abandons it or not. It would, however, be considered impolite to fork if the owner/maintainer continues to do the job and in a way that is not too different from what the 'general population of users' want - which may mean accepting decisions that the owner makes that you may not agree with. > > If you have contributed some code to the project, we thank you and > > we make sure you (and/or your company) get credit. But in reality, > > the team take on the responsibility to make sure that the code > > continues to work correctly. Not just at commit time, but forever. With a responsive owner then you can submit patches back to him. If/when he abandons it - you fork your copy/version. > Well, the above FAQ entry does not mention a single word about > "ease of maintainance of code", but instead it's all about those > GPL fanatics and their lawyers. While I like the GPL, I do not > like the fanatism some of the "open source evangalists" come > around like. No offense here against anyone involved in this > discussion - I do have some special people of the GPL public > in mind, but I don't like calling names. > > I think this continued responsibility should be reflected in the > > ownership of the code. > > > > The upshot for you (and/or your company) is that you no longer > > maintain that code anymore - that has to be worth something! > > I don't think that continued responsibility has _anything_ to do > with ownership - at least not with GPLed code. Well, almost. If someone owns they code they can change the license into something else if they wish. The code that was GPLed cannot be taken away, ie you can't stop anyone using/distributing/... it up to the point that the license changed. However: once the license changed (perhaps to something not open) and development continued then users have a choice: 1) continue using the code up to when the license changed, live with any bugs 2) use the post license change code for the extra goodies and perhaps pay a fee to the owner, if required 3) fork the code (as of license change) and develop in parallel, perhaps emulate the festures in (2). This is why code with multiple owners is best ... it prevents someone doing (2). If (and this is a thought experiment, not an accusation/...) Von Toon/Nagios Enterprises/... were to be bought by then the Nagios community would be better protected by multiple copyright. What might be considered is dual ownership: this would set out what the various parties could do with the code. I would not feel happy if code that I had contributed for free were now proprietary & being used to make someone else a profit. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From holger at CIS.FU-Berlin.DE Wed May 6 15:50:30 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 6 May 2009 15:50:30 +0200 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: <20090506131722.GD16192@mint.phcomp.co.uk> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> Message-ID: <20090506135030.GB41927050@CIS.FU-Berlin.DE> * Alain Williams [2009-05-06 14:17]: > > > We're following advice given by FSF: http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright > > Basically they are saying: > > If we are the copyright owners then we can legally bash anyone who > infringes the copyright. > > I can see their point, it makes life simpler. > > However: if that situation were to arise with nagios plugins, then > there is no reason why the different plugin owners could not give > Ton Voon/whoever the legal right to protect (ie sue for infringing use > of the code). What if one or more of the contributors are not aware of the problem and their e-mail address bounces by then (which I guess would be a very likely scenario)? Holger From holger at CIS.FU-Berlin.DE Wed May 6 15:34:33 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 6 May 2009 15:34:33 +0200 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> Message-ID: <20090506133433.GA41927050@CIS.FU-Berlin.DE> * Sascha.Runschke at gfkl.com [2009-05-06 14:35]: > > We're following advice given by FSF: > > http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright > > > > If you have contributed some code to the project, we thank you and > > we make sure you (and/or your company) get credit. But in reality, > > the team take on the responsibility to make sure that the code > > continues to work correctly. Not just at commit time, but forever. > > Well, the above FAQ entry does not mention a single word about > "ease of maintainance of code", but instead it's all about those > GPL fanatics and their lawyers. While I like the GPL, I do not > like the fanatism some of the "open source evangalists" come > around like. Our policy has nothing to do with "GPL fanatism" or the like. Having a single copyright holder can simplify things, that's all. Holger From addw at phcomp.co.uk Wed May 6 16:21:35 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Wed, 6 May 2009 15:21:35 +0100 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: <20090506135030.GB41927050@CIS.FU-Berlin.DE> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> <20090506135030.GB41927050@CIS.FU-Berlin.DE> Message-ID: <20090506142135.GF16192@mint.phcomp.co.uk> On Wed, May 06, 2009 at 03:50:30PM +0200, Holger Weiss wrote: > * Alain Williams [2009-05-06 14:17]: > > > > > We're following advice given by FSF: http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright > > > > Basically they are saying: > > > > If we are the copyright owners then we can legally bash anyone who > > infringes the copyright. > > > > I can see their point, it makes life simpler. > > > > However: if that situation were to arise with nagios plugins, then > > there is no reason why the different plugin owners could not give > > Ton Voon/whoever the legal right to protect (ie sue for infringing use > > of the code). > > What if one or more of the contributors are not aware of the problem and > their e-mail address bounces by then (which I guess would be a very > likely scenario)? You could always ask for the authority/agreement at the time that the plugin was accepted ... if a copyright assignment is not agreed. Not much difference in the work that you would need to to in either case. Basically: it is good for the Nagios plugins project to make it easy for people to contribute, accepting something like this instead of copyright assignment can help - especially those who work for large corporations. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From ae at op5.se Wed May 6 16:23:30 2009 From: ae at op5.se (Andreas Ericsson) Date: Wed, 06 May 2009 16:23:30 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Antwort: Re: Contributing patches and retaining copyright In-Reply-To: <20090506131722.GD16192@mint.phcomp.co.uk> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> Message-ID: <4A019D62.5070303@op5.se> Alain Williams wrote: > On Wed, May 06, 2009 at 02:35:34PM +0200, Sascha.Runschke at gfkl.com wrote: > >>> If you have contributed some code to the project, we thank you and >>> we make sure you (and/or your company) get credit. But in reality, >>> the team take on the responsibility to make sure that the code >>> continues to work correctly. Not just at commit time, but forever. > > With a responsive owner then you can submit patches back to him. > If/when he abandons it - you fork your copy/version. > >> Well, the above FAQ entry does not mention a single word about >> "ease of maintainance of code", but instead it's all about those >> GPL fanatics and their lawyers. While I like the GPL, I do not >> like the fanatism some of the "open source evangalists" come >> around like. No offense here against anyone involved in this >> discussion - I do have some special people of the GPL public >> in mind, but I don't like calling names. > >>> I think this continued responsibility should be reflected in the >>> ownership of the code. >>> >>> The upshot for you (and/or your company) is that you no longer >>> maintain that code anymore - that has to be worth something! >> I don't think that continued responsibility has _anything_ to do >> with ownership - at least not with GPLed code. > > Well, almost. > If someone owns they code they can change the license into something else > if they wish. The code that was GPLed cannot be taken away, ie you can't > stop anyone using/distributing/... it up to the point that the license > changed. However: once the license changed (perhaps to something not open) > and development continued then users have a choice: > > 1) continue using the code up to when the license changed, live with any bugs > 2) use the post license change code for the extra goodies and perhaps pay a fee > to the owner, if required > 3) fork the code (as of license change) and develop in parallel, perhaps emulate > the festures in (2). > > This is why code with multiple owners is best ... it prevents someone doing (2). Not necessarily. In a court of law, copyright holders must show that their contribution is not insignificant. A one-line fix from me to net-snmp gives me absolutely zero right to decide over the license of the project. Also, if a large enough majority of the contributors (and contributors here is counted by number of contributed lines of code), the license can be changed without even asking the remaining programmers, so long as they didn't write a significant part of the project as a whole. With the plugins project, I doubt this is a real problem, because: a) The plugins are free-standing programs, so a license-change could just drop the plugins where copyright isn't owned by the plugin team. b) Contributions to already existing plugins can very, very rarely be considered "significant contributions", unless they drastically alter how the plugin works. > If (and this is a thought experiment, not an accusation/...) Von Toon/Nagios > Enterprises/... were to be bought by then > the Nagios community would be better protected by multiple copyright. > Certainly, but you may rest assured that forks would rise like mushrooms if that happened ;-) > What might be considered is dual ownership: this would set out what the various > parties could do with the code. I would not feel happy if code that I had > contributed for free were now proprietary & being used to make someone else a profit. > Right. So you could make the nagios plugin team leasees of your code for zero money, which gives them the right to defend the plugin project as a whole in a court of law, but does not give them right to re-license it. There's trouble with paperwork for doing that though, and it works differently in different countries which, I believe, is why EFF offers the advice of having a single copyright owner. Actually though, the EFF advices that copyright is signed over to them, which is something I've never felt very comfortable with. Ah well. The horrors of law mustn't penetrate the fun of hacking imo. I stay well away from even Ally McBeal unless I'm thoroughly protected by a thick coating of alcohol ;-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From Sascha.Runschke at gfkl.com Wed May 6 16:34:54 2009 From: Sascha.Runschke at gfkl.com (Sascha.Runschke at gfkl.com) Date: Wed, 6 May 2009 16:34:54 +0200 Subject: [Nagiosplug-devel] Antwort: Re: Contributing patches and retaining copyright In-Reply-To: <20090506133433.GA41927050@CIS.FU-Berlin.DE> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506133433.GA41927050@CIS.FU-Berlin.DE> Message-ID: > Our policy has nothing to do with "GPL fanatism" or the like. Having a > single copyright holder can simplify things, that's all. I agree to a certain extend. Though the _need_ to give away the copyright to the team can make things harder, too. Especially for all of us who work for companies using nagios and writing code/extensions/plugins for it. I cannot give away something which doesn't belong to me. Code I produce during my work is owned by my company. And it's not like I'm alone in that boat - lots of people are in the same position. By ruling out any submission without relinquishing the copyright you also miss on a lot of submissions at all. I considered submitting some plugins for a long time and have even been doing some work on refurbishing them so they are usable by the public without the need to hack things inside the plugins - but I can stop that work now. Big question is: Does the "benefit" of that restriction beat the "disadvantage" of missing a lot of possibilities for new code submission? I sincerely doubt that... Regards Sascha GFKL Financial Services AG Vorstand: Dr. Peter J?nsch (Vors.), J?rgen Baltes, Dr. Tom Haverkamp Vorsitzender des Aufsichtsrats: Dr. Georg F. Thoma Sitz: Limbecker Platz 1, 45127 Essen, Amtsgericht Essen, HRB 13522 From dermoth at aei.ca Wed May 6 16:44:21 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 06 May 2009 10:44:21 -0400 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: References: Message-ID: <4A01A245.2050309@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/09 04:02 AM, Ton Voon wrote: > Hi Simon, > > On 5 May 2009, at 22:40, Simon Bennett wrote: > >> I've got a couple of patches to the core Nagios plug-ins set that >> I'd like >> to contribute back to the project. They were created for our >> customers but >> some might be generally useful. The FAQ mentioned to post to this >> list if >> you'd like to contribute but want to retain copyright. The copyright >> in this >> case is my company's. > > Any contributed code that gets back into the main code from now on is > accepted on the basis that the copyright can be given to the Nagios > Plugin team. I've updated the FAQ entry to be clearer on that policy: http://nagiosplugins.org/copyright > > We'd be happy to hear about any changes, but only if you are willing > to relinquish copyright. I totally agree about getting copyrights for the team for legal issue; at the same time can't we leave the original code copyright to its original author? That means the we'd still have full copyright, and the author would retain full copyright of the original code, but not for modified version by the team. IANAL, so does that makes any sense (legally)? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKAaJF6dZ+Kt5BchYRAhlkAKCGs6H2hX4ChlVwT3QSOW2QL1JGGACgioT5 yinO/pHFAIrSiCyi32g5+Ro= =QhVl -----END PGP SIGNATURE----- From ae at op5.se Wed May 6 16:51:37 2009 From: ae at op5.se (Andreas Ericsson) Date: Wed, 06 May 2009 16:51:37 +0200 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: <4A01A245.2050309@aei.ca> References: <4A01A245.2050309@aei.ca> Message-ID: <4A01A3F9.9050802@op5.se> Thomas Guyot-Sionnest wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/05/09 04:02 AM, Ton Voon wrote: >> Hi Simon, >> >> On 5 May 2009, at 22:40, Simon Bennett wrote: >> >>> I've got a couple of patches to the core Nagios plug-ins set that >>> I'd like >>> to contribute back to the project. They were created for our >>> customers but >>> some might be generally useful. The FAQ mentioned to post to this >>> list if >>> you'd like to contribute but want to retain copyright. The copyright >>> in this >>> case is my company's. >> Any contributed code that gets back into the main code from now on is >> accepted on the basis that the copyright can be given to the Nagios >> Plugin team. I've updated the FAQ entry to be clearer on that policy: http://nagiosplugins.org/copyright >> >> We'd be happy to hear about any changes, but only if you are willing >> to relinquish copyright. > > I totally agree about getting copyrights for the team for legal issue; > at the same time can't we leave the original code copyright to its > original author? > > That means the we'd still have full copyright, and the author would > retain full copyright of the original code, but not for modified version > by the team. > > IANAL, so does that makes any sense (legally)? > No, it doesn't. It would only make sense if the plugin team rewrote the plugin from scratch, without looking at the plugin sent by the "other" copyright holder. However, anyone can sign over the right to legally defend their work in a court of law. If they couldn't, a *LOT* of lawyers would be out of a job really, really quickly ;-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From marc at ena.com Wed May 6 16:59:14 2009 From: marc at ena.com (Marc Powell) Date: Wed, 6 May 2009 09:59:14 -0500 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright In-Reply-To: <4A01A245.2050309@aei.ca> References: <4A01A245.2050309@aei.ca> Message-ID: <7272A78C-5C5E-457D-8DD3-B53D56E4ED4C@ena.com> On May 6, 2009, at 9:44 AM, Thomas Guyot-Sionnest wrote: > I totally agree about getting copyrights for the team for legal issue; > at the same time can't we leave the original code copyright to its > original author? > > That means the we'd still have full copyright, and the author would > retain full copyright of the original code, but not for modified > version > by the team. The copyright page specifically mentions dual-copyright -- "There is a task to ensure all code is owned (solely or dual copyright) to the Nagios Plugins Development Team, to avoid confusion about ownership in future." I have no real horse in this race but this seems most interesting to me... -- Marc From nagios at babar.us Wed May 6 18:00:56 2009 From: nagios at babar.us (Olivier 'Babar' Raginel) Date: Wed, 6 May 2009 18:00:56 +0200 Subject: [Nagiosplug-devel] Antwort: Antwort: Contributing patches and retaining copyright In-Reply-To: <4A019D62.5070303@op5.se> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> <4A019D62.5070303@op5.se> Message-ID: <20090506160056.GA26934@mail.babar.us> On Wed, May 06, 2009 at 04:23:30PM +0200, Andreas Ericsson wrote: > Not necessarily. In a court of law, copyright holders must show that > their contribution is not insignificant. A one-line fix from me to > net-snmp gives me absolutely zero right to decide over the license of > the project. Also, if a large enough majority of the contributors (and > contributors here is counted by number of contributed lines of code), > the license can be changed without even asking the remaining > programmers, so long as they didn't write a significant part of the > project as a whole. IANAL, so I'll refrain from commenting on this. I'm just like Sasha, meaning I couldn't contribute back some code because the company I wrote it for owned the copyright. Anyway, Andreas, are you sure about that? This seems pretty hard to enforce to me. Let's take a concrete example: Nagios::Plugins. Afaik, Gavin Carr wrote the first shot at this. It's been extended a lot since then. What if, over time, someone refactors that up to a point that not a single line of what Gavin wrote is left in the source. If I did that re-factoring, would I then be able to claim copyright? Would the copyright be shared between Gavin, myself, and the others who made substantial contributions to that piece of code? May I also rip Gavin's name out of N::P then? And no, I'm not planning to re-write N::P, it's perfectly fine. This is just intended as an example, as I've been wondering this for quite some time, and could never find a clear statement about this. GPL mentions something about every contributor should be credited, but I couldn't find anything about copyrights and what it actually means. But once again, IANAL, I'm only very interested and eager to learn how this licensing model can work. -- Babar. From ppb at usc.edu Wed May 6 18:28:04 2009 From: ppb at usc.edu (Philip Brown) Date: Wed, 06 May 2009 09:28:04 -0700 Subject: [Nagiosplug-devel] Antwort: Antwort: Contributing patches and retaining copyright In-Reply-To: <20090506160056.GA26934@mail.babar.us> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> <4A019D62.5070303@op5.se> <20090506160056.GA26934@mail.babar.us> Message-ID: <4A01BA94.2080409@usc.edu> Olivier 'Babar' Raginel wrote: > Let's take a concrete example: Nagios::Plugins. Afaik, Gavin Carr wrote > the first shot at this. It's been extended a lot since then. What if, > over time, someone refactors that up to a point that not a single line > of what Gavin wrote is left in the source. If I did that re-factoring, > would I then be able to claim copyright? Would the copyright be shared > between Gavin, myself, and the others who made substantial contributions > to that piece of code? > May I also rip Gavin's name out of N::P then? > it then becomes an issue of both copyright, AND trademark. (the name). if you have essentially a new work, then he no longer would have any claim to copyright. but may still retain some rights to the name. except that it's got "nagios" in the name, so the nagios trademark holders would probably hold trump card on that one. however, for me too, IANAL. From ton.voon at opsera.com Wed May 6 19:24:44 2009 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 6 May 2009 18:24:44 +0100 Subject: [Nagiosplug-devel] Antwort: Re: Contributing patches and retaining copyright In-Reply-To: References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506133433.GA41927050@CIS.FU-Berlin.DE> Message-ID: On 6 May 2009, at 15:34, Sascha.Runschke at gfkl.com wrote: >> Our policy has nothing to do with "GPL fanatism" or the like. >> Having a >> single copyright holder can simplify things, that's all. > > I agree to a certain extend. > Though the _need_ to give away the copyright to the team can make > things harder, too. Especially for all of us who work for companies > using nagios and writing code/extensions/plugins for it. I cannot > give away something which doesn't belong to me. Code I produce > during my work is owned by my company. And it's not like I'm > alone in that boat - lots of people are in the same position. > By ruling out any submission without relinquishing the copyright > you also miss on a lot of submissions at all. I considered submitting > some plugins for a long time and have even been doing some work on > refurbishing them so they are usable by the public without the need > to hack things inside the plugins - but I can stop that work now. > > Big question is: > > Does the "benefit" of that restriction beat the "disadvantage" of > missing a lot of possibilities for new code submission? > > I sincerely doubt that... There's lot of good discussion on this thread, but I just want to home in on the issue re "code is owned by my company so I cannot contribute". Let's assume the Nagios Plugin team does accept dual copyrights, and your company, Company A, has a non-trivial (less than 10%, but greater than 5 lines) change made and want to retain copyright. Let's say the change gets into the core code with those copyrights intact. Then let's say Company X takes Nagios Plugin code, rips out all copyright statements, and then proceeds to call the code their own (by the way, this actually happened a few years back). Legally, its much more difficult for the Nagios Plugin team to pursue infringement - we have to contact all copyright owners and get agreement before any action is taken. This is why we want the simplicity. But let's concentrate on Company A - what's happened to their "intellectual property"? Can they now have a say in how the Nagios Plugin team responds to this? I guess they could, but they have more important things to do, like running their company. What's happened to the code they've released? Well, now everyone can see it, it can get incorporated anywhere that there is a fork of the plugins code. The only difference with the Nagios Plugin team is our integrity of allowing the dual copyright in the first place - anyone ripping code is not working to the same standards. The fact of the matter is that Company A is not going to get any additional benefit from contributing their code upstream to a project. Their "ownership" of their changes will not get them a seat at the table. (If you do want a seat at the table, you can - join the team and contribute. I am more than happy to take on new members that will devote their time to the project. I listen to a lot of opinions, but I value the opinions of the people doing the work a lot more.) So what does Company A get out of contributing? They get their changes evaluated by our team. They get their changes tested by a wider audience. They get their code running against our test servers. They get reduced support overhead as they no longer need to continue patching their version (which may break in future). None of these have anything to do with copyright. As an example, my company, Opsera, make changes to Nagios. As required by GPL, we publish the changes we do to Nagios (http://trac.opsview.org/browser/trunk/opsview-base/Makefile#L256 ). We list all the patches we make against a virgin Nagios tarball. Some of our patches do say "Copyright Opsera", but with the caveat that if it gets into the core distribution, then we give the copyright to Ethan (http://trac.opsview.org/browser/trunk/opsview-base/patches/nsca_alternate.t#L6 ). The benefit to Opsera is that we are perceived as (1) experts, (2) good citizens. And if it gets into core code - great! That's one less thing to patch and worry about. There's no way Opsera would claim to be "authors of Nagios". If your company doesn't want to contribute, that's their prerogative and the licence permits that. But I'm willing to bet that a change in policy to dual copyrights will not make a difference. If you want permission from your company to contribute, you need to make the argument with them. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbennett at groundworkopensource.com Wed May 6 21:01:27 2009 From: sbennett at groundworkopensource.com (Simon Bennett) Date: Wed, 06 May 2009 12:01:27 -0700 Subject: [Nagiosplug-devel] Contributing patches and retaining copyright Message-ID: Ton and team, Thanks for the prompt reply, it wasn't my intention to touch off such a lively discussion. Thanks for the gnu.org link, I think I understand the issue. I'm still trying to get my hands on the patches (they were completed by a third-party for us) but they're mostly in the 'minor fix-up and improvement' category. For this type of contribution I don't think assignment is a big deal and I certainly don't want to create administrative pain for the project. Simon -- Simon Bennett GROUNDWORK Open Source, Inc. NOTICE: This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this email or its contents is strictly prohibited.If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. From ae at op5.se Thu May 7 10:13:24 2009 From: ae at op5.se (Andreas Ericsson) Date: Thu, 07 May 2009 10:13:24 +0200 Subject: [Nagiosplug-devel] Antwort: Antwort: Contributing patches and retaining copyright In-Reply-To: <20090506160056.GA26934@mail.babar.us> References: <82D2423D-E6BA-40A0-851F-30679A80E9CF@opsera.com> <20090506131722.GD16192@mint.phcomp.co.uk> <4A019D62.5070303@op5.se> <20090506160056.GA26934@mail.babar.us> Message-ID: <4A029824.5050907@op5.se> Olivier 'Babar' Raginel wrote: > On Wed, May 06, 2009 at 04:23:30PM +0200, Andreas Ericsson wrote: >> Not necessarily. In a court of law, copyright holders must show that >> their contribution is not insignificant. A one-line fix from me to >> net-snmp gives me absolutely zero right to decide over the license of >> the project. Also, if a large enough majority of the contributors (and >> contributors here is counted by number of contributed lines of code), >> the license can be changed without even asking the remaining >> programmers, so long as they didn't write a significant part of the >> project as a whole. > > IANAL, so I'll refrain from commenting on this. I'm just like Sasha, > meaning I couldn't contribute back some code because the company I wrote > it for owned the copyright. > > Anyway, Andreas, are you sure about that? Yes. It's been done for example for the netwide assembler, and we're doing it as we speak for the scm tool git, relicensing key parts of it to gpl + gcc exception for use in libgit2. In git, we have the consent of the authors of 94% of the lines of code in question. The authors of the remaining 6% can't be found, do not respond or have contributed typo fixes or other microscopic and obvious bug-fixes and are therefore not interesting. > This seems pretty hard to enforce to me. Well, yes. "Significant part" etc are the things that the court will decide, so it's far from trivial. If it *was* trivial, no court of law would ever be bothered with things like this. > Let's take a concrete example: Nagios::Plugins. Afaik, Gavin Carr wrote > the first shot at this. It's been extended a lot since then. What if, > over time, someone refactors that up to a point that not a single line > of what Gavin wrote is left in the source. If I did that re-factoring, > would I then be able to claim copyright? You would certainly be able to claim copyright for the parts you wrote, but the code you wrote is a derivative work, so Gavin would hold copyright to the original version and you would hold copyright to the new version. Depending on the license in question, it may hold views on derivative works ;-) > Would the copyright be shared > between Gavin, myself, and the others who made substantial contributions > to that piece of code? Insofar as I understand it; Yes. > May I also rip Gavin's name out of N::P then? > No, you may not, because of the derivative work thing above. It's not enough to just change phrases in a book and claim you wrote it afterwards. A work is more than just *how* something is put together. If, however, you were to write a completely new framework that happens to be compatible API-wise to N::P, but without looking at Gavin's code, you would then be the sole owner and copyright holder. These things are tricky though, but use of common sense sees you through 99.999% of the time. The questions to ask yourself, in the following order, when in doubt are these: 1. Is anyone likely to be pissed off if I claim credit for this? 2. Will they be pissed off enough to sue? 3. Will it hold in court? 4. Is it worth the hassle? If you answer 'yes' to 1-3, I'd probably not find you very likable, and you'd be the sort of person I'd expect to have ulterior motives. If you answer 'no' to any of 1-3, you're most likely safe, but if you're in the slightest doubt, just *ask* the person who wrote it, or add a small comment where the copyright owners are listed why you removed someone from the list. Preferrably with a "kudos to" attribution. I have a feeling these things are discussed a billion times for every time it's actually a problem, and for those few times when it actually *is* a problem, it could have been avoided by simply talking about it and asking nicely what the possibly-offended person would think of this and that. > And no, I'm not planning to re-write N::P, it's perfectly fine. This is > just intended as an example, as I've been wondering this for quite some > time, and could never find a clear statement about this. > GPL mentions something about every contributor should be credited, but I > couldn't find anything about copyrights and what it actually means. > The "every contributor should be credited" is best stored in the version control system, really. Here are the owners of "transport.c" in git.git, for example (it's trivial to get ownership for all of git.git in one go, but it takes quite a long time with the clumsy script I wrote for it, so I'll refrain if it's all the same to you). The first column represent the lines of code last modified by the author in the second column. exon:~/git/git (master)$ git showners transport.c transport.c 400 Daniel Barkalow 359 Johannes Schindelin 141 Jeff King 106 Shawn O. Pearce 48 Andreas Ericsson 29 Junio C Hamano 12 Mike Hommey 9 Paolo Bonzini 7 Andy Whitcroft 5 Petr Baudis 4 Ren? Scharfe 3 Steffen Prohaska 2 Miklos Vajna 2 Johannes Sixt 1 Tuncer Ayaz 1 Sam Vilain 1 Jim Meyering 1 Clemens Buchacher 1 Blake Ramsdell 1 Alexander Potashev Similar things can be done with all version control systems that have a "blame" command aware of code moves between file boundaries, but I only know how to do it with git as I've never fiddled with other DSCM's, and centralized ones are agonizingly slow for digging into archaeology. > But once again, IANAL, I'm only very interested and eager to learn how > this licensing model can work. > It works just fine unless someone actively *wants* to be an arsehole and just steal the code to profit from it without giving things back. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From pepper at reppep.com Thu May 7 21:50:22 2009 From: pepper at reppep.com (Chris Pepper) Date: Thu, 07 May 2009 15:50:22 -0400 Subject: [Nagiosplug-devel] Typos in check_disk Message-ID: <4A033B7E.3050102@reppep.com> You cannot post to the Nagios Plugin Development mailing list as you are not subscribed. Due to the amount of spam and the administrative burden, all emails from non-members will be automatically discarded. Please subscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel and repost your message. Subject: Typos in check_disk From: Chris Pepper Date: Thu, 07 May 2009 15:39:08 -0400 To: nagiosplug-devel at lists.sourceforge.net s/pathes/paths/ > Index: check_disk.c > =================================================================== > --- check_disk.c (revision 2189) > +++ check_disk.c (working copy) > @@ -661,19 +661,19 @@ > break; > case 'E': > if (path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set -E before selecting pathes\n")); > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set -E before selecting paths\n")); > exact_match = TRUE; > break; > case 'g': > if (path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set group value before selecting pathes \n")); > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set group value before selecting paths \n")); > group = optarg; > break; > case 'I': > cflags |= REG_ICASE; > case 'i': > if (!path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), _("Pathes need to be selected before using -i/-I. Use -A to select all pathes explicitly")); > + die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), _("Paths need to be selected before using -i/-I. Use -A to select all paths explicitly")); > err = regcomp(&re, optarg, cflags); > if (err != 0) { > regerror (err, &re, errbuf, MAX_INPUT_BUFFER); > @@ -930,7 +930,7 @@ > printf (" %s\n", "-e, --errors-only"); > printf (" %s\n", _("Display only devices/mountpoints with errors")); > printf (" %s\n", "-g, --group=NAME"); > - printf (" %s\n", _("Group pathes. Thresholds apply to (free-)space of all partitions together")); > + printf (" %s\n", _("Group paths. Thresholds apply to (free-)space of all partitions together")); > printf (" %s\n", "-k, --kilobytes"); > printf (" %s\n", _("Same as '--units kB'")); > printf (" %s\n", "-l, --local"); > @@ -943,7 +943,7 @@ > printf (" %s\n", "-m, --megabytes"); > printf (" %s\n", _("Same as '--units MB'")); > printf (" %s\n", "-A, --all"); > - printf (" %s\n", _("Explicitly select all pathes. This is equivalent to -R '.*'")); > + printf (" %s\n", _("Explicitly select all paths. This is equivalent to -R '.*'")); > printf (" %s\n", "-R, --eregi-path=PATH, --eregi-partition=PARTITION"); > printf (" %s\n", _("Case insensitive regular expression for path/partition (may be repeated)")); > printf (" %s\n", "-r, --ereg-path=PATH, --ereg-partition=PARTITION"); Index: check_disk.c =================================================================== --- check_disk.c (revision 2189) +++ check_disk.c (working copy) @@ -661,19 +661,19 @@ break; case 'E': if (path_selected) - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set -E before selecting pathes\n")); + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set -E before selecting paths\n")); exact_match = TRUE; break; case 'g': if (path_selected) - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set group value before selecting pathes \n")); + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must set group value before selecting paths \n")); group = optarg; break; case 'I': cflags |= REG_ICASE; case 'i': if (!path_selected) - die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), _("Pathes need to be selected before using -i/-I. Use -A to select all pathes explicitly")); + die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), _("Paths need to be selected before using -i/-I. Use -A to select all paths explicitly")); err = regcomp(&re, optarg, cflags); if (err != 0) { regerror (err, &re, errbuf, MAX_INPUT_BUFFER); @@ -930,7 +930,7 @@ printf (" %s\n", "-e, --errors-only"); printf (" %s\n", _("Display only devices/mountpoints with errors")); printf (" %s\n", "-g, --group=NAME"); - printf (" %s\n", _("Group pathes. Thresholds apply to (free-)space of all partitions together")); + printf (" %s\n", _("Group paths. Thresholds apply to (free-)space of all partitions together")); printf (" %s\n", "-k, --kilobytes"); printf (" %s\n", _("Same as '--units kB'")); printf (" %s\n", "-l, --local"); @@ -943,7 +943,7 @@ printf (" %s\n", "-m, --megabytes"); printf (" %s\n", _("Same as '--units MB'")); printf (" %s\n", "-A, --all"); - printf (" %s\n", _("Explicitly select all pathes. This is equivalent to -R '.*'")); + printf (" %s\n", _("Explicitly select all paths. This is equivalent to -R '.*'")); printf (" %s\n", "-R, --eregi-path=PATH, --eregi-partition=PARTITION"); printf (" %s\n", _("Case insensitive regular expression for path/partition (may be repeated)")); printf (" %s\n", "-r, --ereg-path=PATH, --ereg-partition=PARTITION"); -- Chris Pepper: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: check_disk.diff URL: From ton.voon at opsera.com Thu May 7 23:39:45 2009 From: ton.voon at opsera.com (Ton Voon) Date: Thu, 7 May 2009 22:39:45 +0100 Subject: [Nagiosplug-devel] Typos in check_disk In-Reply-To: <4A033B7E.3050102@reppep.com> References: <4A033B7E.3050102@reppep.com> Message-ID: <825BBD31-291D-4976-A16D-8FD00E8F8CBF@opsera.com> Chris, Thanks for the patch. Applied in git. Ton On 7 May 2009, at 20:50, Chris Pepper wrote: > You cannot post to the Nagios Plugin Development mailing list as you > are not subscribed. Due to the amount of spam and the administrative > burden, all emails from non-members will be automatically discarded. > > Please subscribe at > https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel and > repost your message. > > > > > > Subject: > Typos in check_disk > From: > Chris Pepper > Date: > Thu, 07 May 2009 15:39:08 -0400 > To: > nagiosplug-devel at lists.sourceforge.net > > s/pathes/paths/ > > > Index: check_disk.c > > =================================================================== > > --- check_disk.c (revision 2189) > > +++ check_disk.c (working copy) > > @@ -661,19 +661,19 @@ > > break; > > case 'E': > > if (path_selected) > > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set -E before selecting pathes\n")); > > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set -E before selecting paths\n")); > > exact_match = TRUE; > > break; > > case 'g': > > if (path_selected) > > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set group value before selecting pathes \n")); > > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set group value before selecting paths \n")); > > group = optarg; > > break; > > case 'I': > > cflags |= REG_ICASE; > > case 'i': > > if (!path_selected) > > - die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), > _("Pathes need to be selected before using -i/-I. Use -A to select > all pathes explicitly")); > > + die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), > _("Paths need to be selected before using -i/-I. Use -A to select > all paths explicitly")); > > err = regcomp(&re, optarg, cflags); > > if (err != 0) { > > regerror (err, &re, errbuf, MAX_INPUT_BUFFER); > > @@ -930,7 +930,7 @@ > > printf (" %s\n", "-e, --errors-only"); > > printf (" %s\n", _("Display only devices/mountpoints with > errors")); > > printf (" %s\n", "-g, --group=NAME"); > > - printf (" %s\n", _("Group pathes. Thresholds apply to > (free-)space of all partitions together")); > > + printf (" %s\n", _("Group paths. Thresholds apply to > (free-)space of all partitions together")); > > printf (" %s\n", "-k, --kilobytes"); > > printf (" %s\n", _("Same as '--units kB'")); > > printf (" %s\n", "-l, --local"); > > @@ -943,7 +943,7 @@ > > printf (" %s\n", "-m, --megabytes"); > > printf (" %s\n", _("Same as '--units MB'")); > > printf (" %s\n", "-A, --all"); > > - printf (" %s\n", _("Explicitly select all pathes. This is > equivalent to -R '.*'")); > > + printf (" %s\n", _("Explicitly select all paths. This is > equivalent to -R '.*'")); > > printf (" %s\n", "-R, --eregi-path=PATH, --eregi- > partition=PARTITION"); > > printf (" %s\n", _("Case insensitive regular expression for > path/partition (may be repeated)")); > > printf (" %s\n", "-r, --ereg-path=PATH, --ereg- > partition=PARTITION"); > > > > Index: check_disk.c > =================================================================== > --- check_disk.c (revision 2189) > +++ check_disk.c (working copy) > @@ -661,19 +661,19 @@ > break; > case 'E': > if (path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set -E before selecting pathes\n")); > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set -E before selecting paths\n")); > exact_match = TRUE; > break; > case 'g': > if (path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set group value before selecting pathes \n")); > + die (STATE_UNKNOWN, "DISK %s: %s", _("UNKNOWN"), _("Must > set group value before selecting paths \n")); > group = optarg; > break; > case 'I': > cflags |= REG_ICASE; > case 'i': > if (!path_selected) > - die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), > _("Pathes need to be selected before using -i/-I. Use -A to select > all pathes explicitly")); > + die (STATE_UNKNOWN, "DISK %s: %s\n", _("UNKNOWN"), _("Paths > need to be selected before using -i/-I. Use -A to select all paths > explicitly")); > err = regcomp(&re, optarg, cflags); > if (err != 0) { > regerror (err, &re, errbuf, MAX_INPUT_BUFFER); > @@ -930,7 +930,7 @@ > printf (" %s\n", "-e, --errors-only"); > printf (" %s\n", _("Display only devices/mountpoints with > errors")); > printf (" %s\n", "-g, --group=NAME"); > - printf (" %s\n", _("Group pathes. Thresholds apply to > (free-)space of all partitions together")); > + printf (" %s\n", _("Group paths. Thresholds apply to > (free-)space of all partitions together")); > printf (" %s\n", "-k, --kilobytes"); > printf (" %s\n", _("Same as '--units kB'")); > printf (" %s\n", "-l, --local"); > @@ -943,7 +943,7 @@ > printf (" %s\n", "-m, --megabytes"); > printf (" %s\n", _("Same as '--units MB'")); > printf (" %s\n", "-A, --all"); > - printf (" %s\n", _("Explicitly select all pathes. This is > equivalent to -R '.*'")); > + printf (" %s\n", _("Explicitly select all paths. This is > equivalent to -R '.*'")); > printf (" %s\n", "-R, --eregi-path=PATH, --eregi- > partition=PARTITION"); > printf (" %s\n", _("Case insensitive regular expression for > path/partition (may be repeated)")); > printf (" %s\n", "-r, --ereg-path=PATH, --ereg- > partition=PARTITION"); > > -- > Chris Pepper: > > < > check_disk > .diff > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > production scanning environment may not be a perfect world - but > thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com_______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null Ton Voon Product Architect Opsera Limited | Unit 69 Suttons Business Park Reading | Berkshire | RG6 1AZ | UK Phone: +44 (0) 845 057 7887 Mobile: +44 (0) 7931 365796 Skype: tonvoon Email: ton.voon at opsera.com www.opsera.com This e-mail is confidential, intended only for the named recipient(s) above and may contain information that is privileged and confidential. If you receive this message in error, or are not the named recipient(s), please notify the sender at the phone number above, do not copy this message, do not disclose its contents to anyone, and delete this e-mail message from your computer. Although Opsera routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Opsera makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Opsera Limited is registered in the UK under Company Number 5396532. Our registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From hpsekhon at googlemail.com Fri May 8 12:34:21 2009 From: hpsekhon at googlemail.com (Hari Sekhon) Date: Fri, 08 May 2009 11:34:21 +0100 Subject: [Nagiosplug-devel] check_apt switch for warn on non-security updates Message-ID: <4A040AAD.7060803@googlemail.com> Hi, I'm not sure if this has been brought up before, but would it be possible to add a switch to control the behaviour of check_apt with regards to warning on non-security updates. I recently deployed an ubuntu server (puke, at the insistence of a developer where I work) that although is the server version, it pops up with non-security updates (which I don't agree with) and is quite annoying to end up having a warning state on this check. I'd like to be able to tell the plugin, look, don't bother me unless it's a security update. This dumbuntu system has check_apt v1590 (nagios-plugins 1.4.11). Is this switch available in a newer version, or a planned feature. If not, could we please make it so? Thanks -h -- Hari Sekhon Always open to interesting opportunities http://www.linkedin.com/in/harisekhon From pepper at reppep.com Fri May 8 15:07:58 2009 From: pepper at reppep.com (Chris Pepper) Date: Fri, 08 May 2009 09:07:58 -0400 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' Message-ID: <4A042EAE.3090902@reppep.com> All, On Solaris 10 (with gmake -- this is different than ), "make" fails for nagios-plugins-1.4.13. It does on mysql, and the workaround is "./configure --without-mysql" . configure's logic should be enhanced so it can succesfully build check_mysql with Sun's gcc on Solaris 10, or it skips the plugin so those of us who don't need mysql don't have to work around it. Additionally, this appears to be a FAQ, so it should probably be added to the FAQ DB. Regards, Chris Pepper -- Chris Pepper: From ton.voon at opsera.com Fri May 8 17:40:47 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 8 May 2009 16:40:47 +0100 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' In-Reply-To: <4A042EAE.3090902@reppep.com> References: <4A042EAE.3090902@reppep.com> Message-ID: <461EEB5C-34F5-4995-89BE-85E35B13B789@opsera.com> On 8 May 2009, at 14:07, Chris Pepper wrote: > On Solaris 10 (with gmake -- this is different than > ), "make" fails for > nagios-plugins-1.4.13. It does on mysql, and the workaround is > "./configure --without-mysql" > >. > > configure's logic should be enhanced so it can succesfully build > check_mysql with Sun's gcc on Solaris 10, or it skips the plugin so > those of us who don't need mysql don't have to work around it. This sounds like a bug with mysql_config. You should contact where your mysql came from to correct the cflags to be non-gcc specific. It sounds like a decent idea to attempt to compile a minimal mysql program and then stop mysql compiling. Can you provide a patch? > Additionally, this appears to be a FAQ, so it should probably be > added > to the FAQ DB. I've updated the FAQ: http://nagiosplugins.org/node/99. I'm happy to give you access to update if it is not quite worded right. Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ton.voon at opsera.com Fri May 8 21:25:21 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 8 May 2009 20:25:21 +0100 Subject: [Nagiosplug-devel] Icinga and the plugins Message-ID: Hi, No doubt most of the people on this list have already heard about Icinga on the nagios-devel list: http://article.gmane.org/gmane.network.nagios.devel/6246 I don't want to get into the rights or wrongs about it. I only care about how to move this project forward. So my question is this: What needs to be done for the Nagios Plugins project? Ton From exon at op5.com Sat May 9 02:06:52 2009 From: exon at op5.com (Andreas Ericsson) Date: Sat, 09 May 2009 02:06:52 +0200 Subject: [Nagiosplug-devel] Icinga and the plugins In-Reply-To: References: Message-ID: <4A04C91C.30803@op5.com> Ton Voon wrote: > Hi, > > No doubt most of the people on this list have already heard about > Icinga on the nagios-devel list: http://article.gmane.org/gmane.network.nagios.devel/6246 > > I don't want to get into the rights or wrongs about it. I only care > about how to move this project forward. > > So my question is this: What needs to be done for the Nagios Plugins > project? > I think: Absolutely nothing. Icinga claims to be 100% compatible with Nagios (even down to ABI levels for event-broker modules). I can't imagine for one second that any nagios-fork will ever break the basic plugin API. There's still no code from Icinga, so I can't give a final answer, but common sense, cold hard logic and the Icinga developers I've spoken to say it will be so. /Andreas From matthias.flacke at gmx.de Sat May 9 08:41:58 2009 From: matthias.flacke at gmx.de (Matthias Flacke) Date: Sat, 09 May 2009 08:41:58 +0200 Subject: [Nagiosplug-devel] Icinga and the plugins In-Reply-To: <4A04C91C.30803@op5.com> References: <4A04C91C.30803@op5.com> Message-ID: <4A0525B6.2050708@gmx.de> Andreas Ericsson wrote: > Ton Voon wrote: >> Hi, >> >> No doubt most of the people on this list have already heard about >> Icinga on the nagios-devel list: http://article.gmane.org/gmane.network.nagios.devel/6246 >> >> I don't want to get into the rights or wrongs about it. I only care >> about how to move this project forward. >> >> So my question is this: What needs to be done for the Nagios Plugins >> project? >> > > I think: Absolutely nothing. Icinga claims to be 100% compatible with > Nagios (even down to ABI levels for event-broker modules). I can't > imagine for one second that any nagios-fork will ever break the basic > plugin API. For sure. The simplicity of the plugin interface (RC 0-3, some explaining output) is one of the reasons for the success of Nagios. This format needs to be supported forever even if there may be enhancements in the future. Icinga will strictly keep the plugin interface format, so there is no impact on the Plugins project. -Matthias From jitendra.g at navin.com Wed May 13 13:58:21 2009 From: jitendra.g at navin.com (Jitendra | navin.com) Date: Wed, 13 May 2009 17:28:21 +0530 Subject: [Nagiosplug-devel] Ping script for multiple IP Message-ID: <013501c9d3c2$1d921980$96f1fea9@JITENDRATSG> Hi Team, We have our server at seven different location and all this location are connected via MPLS. We have installed nagios at one location. Now I am able to check the link status beetwen location where the nagios is installed and other location. But I am not able to monitor link status beetwen the any location where nagios does not come in the picture. Lets say I have servers at location A, B, C, D, and E and I have nagios at location A. Now I want to monitor the MPLS connectivity from all to all location. Now I want a script where nagios will run it on remote location C and that script will check the connectivity from location C to A, B, D and E. I tried to make such a script in a two way but I am not able to get the proper result. Please find the attached scripts. Thanks & Regards, Jitendra -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ping 2.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ping 1.txt URL: From kajones_irc at hotmail.com Thu May 14 12:24:00 2009 From: kajones_irc at hotmail.com (Aigor Kajones) Date: Thu, 14 May 2009 12:24:00 +0200 Subject: [Nagiosplug-devel] check_mrtg command is returning STATE_UNKNOWN when the state is ok Message-ID: Hi! I?m checking cpu status using check_mrtg command and i always get STATE_UNKNOWN when the state is Ok. I have modified the check_mrtg.c file like this: int main (int argc, char **argv) { /* int result = STATE_UNKNOWN; */ int result = STATE_OK; FILE *fp; int line; char input_buffer[MAX_INPUT_BUFFER]; etc? But the problem is not solved, I always get the service status like this: CPU LOAD VIA MRTG UNKNOWN 05-14-2009 11:35:31 0d 0h 11m 27s 5/5 Max. value = 1 This is what I have added at /usr/local/nagios/etc/objects/commands.cfg: # 'check_local_mrtgcpu' command definition define command{ command_name check_local_mrtgcpu command_line $USER1$/check_mrtg -F $ARG1$ -a $ARG2$ -v $ARG3$ -w $ARG4$ -c $ARG5$ -e $ARG6$ } And the service added to /usr/local/nagios/etc/objects/switch.cfg: ################################################ # Monitor CPU LOAD on FIREWALL using MRTG GRAPHS ################################################ define service{ use generic-service ; Inherit values from a template host_name TICS_FIREWALL service_description CPU LOAD VIA MRTG check_command check_local_mrtgcpu!/var/www/html/mrtg/172.17.17.3_cpu.log!MAX!1!90!75!5 max_check_attempts 5 check_interval 5 retry_interval 5 check_period 24x7 notification_interval 5 notification_period 24x7 notification_options w,c,r notifications_enabled 1 contact_groups admins } What am I doing wrong?? The nagios plugins I?m using are 1.4.12 thanks very muchAiGoR! _________________________________________________________________ Comparte, crea, disfruta? Descubre todo, en estos v?deos http://www.windowslive.es -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at scherbaum.info Fri May 15 19:40:41 2009 From: tobias at scherbaum.info (Tobias Scherbaum) Date: Fri, 15 May 2009 19:40:41 +0200 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <49F71606.9030608@aei.ca> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> Message-ID: <1242409241.6671.16.camel@homer.ob.libexec.de> Thomas Guyot-Sionnest wrote: > We've been able to get a bunch of fixes in after the release > announcement, though there's still 4-5 bugs I'd like to get fixed or at > least have a deeper look into them: > > * [1985246] ssh_disk dont interpret -C with single quotes correct > * [2632995] check_procs fails on Solaris > * [2722832] awk subst.in/subst script path error > * [2268675] fix for quoting in check_by_ssh > * [1939022] SSL/TLS hostname extension support (SNI) What about [2531905] check_mysql does not properly handle passwords in from file wkr, Tobias From pepper at reppep.com Mon May 18 16:16:52 2009 From: pepper at reppep.com (Chris Pepper) Date: Mon, 18 May 2009 10:16:52 -0400 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' Message-ID: <4A116DD4.3080605@reppep.com> > If you are using GCC and your MySQL version was compiled using Sun's C compiler (or the other way round), then it is likely that the configure options will fail as configure will run mysql_config to get the appropriate CFLAGS. This assumes MySQL is installed. Our S10 boxen don't have MySQL, so I'd amend as follows: If you are using GCC to build the plugins, but your MySQL version was compiled using Sun's C compiler (or the other way round) -- or if you don't have MySQL installed on Solaris at all -- then it is likely that the default build procedure will fail, as configure assumes it get appropriate CFLAGS by executing mysql_config. But really, configure shouldn't assume MySQL is present at all. Chris -- Chris Pepper: From pepper at reppep.com Mon May 18 16:33:59 2009 From: pepper at reppep.com (Chris Pepper) Date: Mon, 18 May 2009 10:33:59 -0400 Subject: [Nagiosplug-devel] git URLs on main site? Message-ID: <4A1171D7.2090605@reppep.com> I found the git download information in , but says development is via CVS, and the Download page doesn't provide git/svn/cvs info at all. For the Development pages, here's a possible patch (inline & attached): --- developer-guidelines.html 2009-05-18 10:29:37.000000000 -0400 +++ developer-guidelines.pepper.html 2009-05-18 10:32:14.000000000 -0400 @@ -549,7 +549,7 @@ >

Nagios plugins are developed to the GNU standard, so any OS which is supported by GNU should run the plugins. While the requirements for compiling the Nagios plugins release - is very small, to develop from CVS needs additional software to be installed. These are the + are very basic, developing from the git repository requires additional software to be installed. These are the minimum levels of software required:

- To compile from CVS, after you have checked out the code, run: + To compile from git, after you have checked out the code run:

tools/setup
@@ -578,7 +578,7 @@ distribute.

Note: gnu libtool, which must be at version 1.5.22 or above, has files installed into CVS, so is not +>Note: GNU libtool, which must be at version 1.5.22 or above, has its files included in the git repository, so is not a development platform requirement.

If you have a change that is useful for noting in the next release, please update the NEWS file.

All CVS commit comments will be written to a ChangeLog at release time. +>All commit comments are written to a ChangeLog at release time.

If you have a bug patch, please supply a unified or context diff against the version you are using. For new features, please supply a diff against - the CVS HEAD version.

Patches should be submitted via From pepper at reppep.com Mon May 18 16:17:31 2009 From: pepper at reppep.com (Chris Pepper) Date: Mon, 18 May 2009 10:17:31 -0400 Subject: [Nagiosplug-devel] check_disk --megabytes doesn't work Message-ID: <4A116DFB.6010800@reppep.com> The help says I can use --megabytes, but when I do it eats the -w argument and causes an error. http://nagiosplugins.org/man/check_disk Chris > maguro:~ # /usr/local/nagios/libexec/check_disk -m -w 3% -c 1% -p / > DISK OK - free space: / 3912 MB (81% inode=96%);| /=873MB;4889;4990;0;5041 > maguro:~ # /usr/local/nagios/libexec/check_disk --megabytes -w 3% -c 1% -p / > DISK CRITICAL - 3% is not accessible: No such file or directory > maguro:~ # /usr/local/nagios/libexec/check_disk --version > check_disk v2025 (nagios-plugins 1.4.13) -- Chris Pepper: From holger at CIS.FU-Berlin.DE Mon May 18 17:43:57 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Mon, 18 May 2009 17:43:57 +0200 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' In-Reply-To: <4A116DD4.3080605@reppep.com> References: <461EEB5C-34F5-4995-89BE-85E35B13B789@opsera.com> <4A116DD4.3080605@reppep.com> Message-ID: <20090518154357.GV41927050@CIS.FU-Berlin.DE> * Chris Pepper [2009-05-18 10:16]: > This assumes MySQL is installed. Our S10 boxen don't have MySQL, so I'd > amend as follows: > > If you are using GCC to build the plugins, but your MySQL version was > compiled using Sun's C compiler (or the other way round) -- or if you > don't have MySQL installed on Solaris at all -- then it is likely that > the default build procedure will fail, as configure assumes it get > appropriate CFLAGS by executing mysql_config. > > But really, configure shouldn't assume MySQL is present at all. By default (that is, if "--with-mysql" isn't specified), the configure script doesn't assume that MySQL is available unless mysql_config is found in the current $PATH. At least, that's the idea. Could you post the exact error messages you get? Holger From pepper at reppep.com Mon May 18 17:51:04 2009 From: pepper at reppep.com (Chris Pepper) Date: Mon, 18 May 2009 11:51:04 -0400 Subject: [Nagiosplug-devel] check_ups.c typos Message-ID: <4A1183E8.8060405@reppep.com> --- check_ups.c 2009-05-18 10:25:58.000000000 -0400 +++ check_ups.pepper.c 2009-05-18 11:41:27.000000000 -0400 @@ -12,8 +12,8 @@ * * This file contains Network UPS Tools plugin for Nagios * -* This plugin tests the UPS service on the specified host.Network UPS Tools -* from www.networkupstools.org must be running for thisplugin to work. +* This plugin tests the UPS service on the specified host. Network UPS Tools +* from www.networkupstools.org must be running for this plugin to work. * * * This program is free software: you can redistribute it and/or modify @@ -605,7 +605,7 @@ printf (COPYRIGHT, copyright, email); printf ("%s\n", _("This plugin tests the UPS service on the specified host. Network UPS Tools")); - printf ("%s\n", _("from www.networkupstools.org must be running for thisplugin to work.")); + printf ("%s\n", _("from www.networkupstools.org must be running for this plugin to work.")); printf ("\n\n"); @@ -641,12 +641,12 @@ printf ("\n"); printf ("%s\n", _("Notes:")); printf (" %s\n", _("You may also specify a variable to check (such as temperature, utility voltage,")); - printf (" %s\n", _("battery load, etc.) as well as warning and critical thresholds for the value")); + printf (" %s\n", _("battery load, etc.) as well as warning and critical thresholds for the value")); printf (" %s\n", _("of that variable. If the remote host has multiple UPS that are being monitored")); printf (" %s\n", _("you will have to use the --ups option to specify which UPS to check.")); printf ("\n"); printf (" %s\n", _("This plugin requires that the UPSD daemon distributed with Russell Kroll's")); - printf (" %s\n", _("Smart UPS Tools be installed on the remote host. If you do not have the")); + printf (" %s\n", _("Network UPS Tools be installed on the remote host. If you do not have the")); printf (" %s\n", _("package installed on your system, you can download it from")); printf (" %s\n", _("http://www.networkupstools.org")); #ifdef NP_EXTRA_OPTS From pepper at reppep.com Mon May 18 17:51:27 2009 From: pepper at reppep.com (Chris Pepper) Date: Mon, 18 May 2009 11:51:27 -0400 Subject: [Nagiosplug-devel] Typos in urlize.c Message-ID: <4A1183FF.2020400@reppep.com> --- urlize.c 2009-05-18 10:25:58.000000000 -0400 +++ urlize.pepper.c 2009-05-18 11:46:37.000000000 -0400 @@ -10,8 +10,8 @@ * This file contains the urlize plugin * * This plugin wraps the text output of another command (plugin) in HTML -* tags, thus displaying the plugin output in as a clickable link in the -* Nagios status screen. The return status is the same as the invoked plugin. +* tags, thus displaying the child plugin's output in as a clickable link in the +* Nagios status screen. This plugin returns the status of the invoked plugin. * * * This program is free software: you can redistribute it and/or modify @@ -167,8 +167,8 @@ printf (COPYRIGHT, copyright, email); printf ("%s\n", _("This plugin wraps the text output of another command (plugin)")); - printf ("%s\n", _("in HTML tags, thus displaying the plugin output in as a clickable link in")); - printf ("%s\n", _("the Nagios status screen. The return status is the same as the invoked plugin.")); + printf ("%s\n", _("in HTML tags, thus displaying the child plugin's output in as a clickable link in")); + printf ("%s\n", _("the Nagios status screen. This plugin returns the status of the invoked plugin.")); printf ("\n\n"); From shadhin71 at gmail.com Tue May 19 00:00:43 2009 From: shadhin71 at gmail.com (shadih rahman) Date: Mon, 18 May 2009 18:00:43 -0400 Subject: [Nagiosplug-devel] check_flexlm Message-ID: <6db4a4200905181500y23647ad8rdbe7fa071afbd0b2@mail.gmail.com> All, check_flexlm perl script is hard coding lmstat location. This is not proper programming practice. script location: contrib/check_flexlm -- Cordially, Shadhin Rahman -------------- next part -------------- An HTML attachment was scrubbed... URL: From PsychoTrahe at gmx.de Tue May 19 00:10:37 2009 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Tue, 19 May 2009 00:10:37 +0200 Subject: [Nagiosplug-devel] check_disk --megabytes doesn't work In-Reply-To: <4A116DFB.6010800@reppep.com> References: <4A116DFB.6010800@reppep.com> Message-ID: <1242684637.7811.4.camel@pc.site> Hi Chris, > The help says I can use --megabytes, but when I do it eats the -w > argument and causes an error. > > http://nagiosplugins.org/man/check_disk > > Chris > > > maguro:~ # /usr/local/nagios/libexec/check_disk -m -w 3% -c 1% -p / > > DISK OK - free space: / 3912 MB (81% inode=96%);| > /=873MB;4889;4990;0;5041 > > maguro:~ # /usr/local/nagios/libexec/check_disk --megabytes -w 3% -c > 1% -p / > > DISK CRITICAL - 3% is not accessible: No such file or directory > > maguro:~ # /usr/local/nagios/libexec/check_disk --version > > check_disk v2025 (nagios-plugins 1.4.13) I cannot reproduce this, here (at least not with the current git version. Can you try the latest one? You can find it here: http://repo.or.cz/w/nagiosplugins.git Otherwise: maybe there's a bug in your getopt parser? I can't remember any commits that could've affected this. Matthias From ton.voon at opsera.com Tue May 19 10:18:26 2009 From: ton.voon at opsera.com (Ton Voon) Date: Tue, 19 May 2009 09:18:26 +0100 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' In-Reply-To: <4A116D73.9060909@cbio.mskcc.org> References: <4A116D73.9060909@cbio.mskcc.org> Message-ID: <6EBCB750-0BDD-47EA-ADCE-444ED99F5307@opsera.com> On 18 May 2009, at 15:15, Chris Pepper wrote: >> If you are using GCC and your MySQL version was compiled using >> Sun's C compiler (or the other way round), then it is likely that >> the configure options will fail as configure will run mysql_config >> to get the appropriate CFLAGS. > > This assumes MySQL is installed. Our S10 boxen don't have MySQL, so > I'd amend as follows: > > If you are using GCC to build the plugins, but your MySQL version > was compiled using Sun's C compiler (or the other way round) -- or > if you don't have MySQL installed on Solaris at all -- then it is > likely that the default build procedure will fail, as configure > assumes it get appropriate CFLAGS by executing mysql_config. > > But really, configure shouldn't assume MySQL is present at all. Hi Chris, If mysql_config doesn't exist, then it assumes mysql does not exist and then doesn't try to compile check_mysql. I think this is a reasonable course of action. The current logic is: * if you've been told to include mysql, then try to compile check_mysql * if you've been told not to include mysql, don't try to compile check_mysql * if you have not specified anything, then see if mysql_config is available and if it is the compile check_mysql I think the last step could be enhanced to include trying to compile a very small mysql program and if that fails, then do not try check_mysql. Patches welcome. (Copying to nagiosplug-devel list) Ton From addw at phcomp.co.uk Tue May 19 12:47:10 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Tue, 19 May 2009 11:47:10 +0100 Subject: [Nagiosplug-devel] Patch to check_procs Message-ID: <20090519104710.GB4463@mint.phcomp.co.uk> Please find attached a patch to check_procs. Motivation ********** Detect a process that enters an infinite loop. With today's multi process CPUs this might not be noticed for some time. Discussion ********** Taking a snapshot and detecting that a process is using 100% of a CPU can generate false positives, eg catching the overnight batch job that is CPU intensive for a few minutes. Using the nagios config option 'max_check_attempts' may also generate false positives if different processes eat CPU in succession. The patch saves notes about 'interesting processes' in a status file that is checked/updated by successive runs of check_procs. This allows detection of processes that exceed the limits over a long time. It records the start time of when individual process exceed limits. Only processes that exceed a limit are deemed interesting and so have details in the status file. The start of Warning and Critical times are separate. Start of Critical implies Warning. Processes are identified by PID. If the PPID or program change it is assumed to be a different process (ie any history is forgotten). Configuration ************* resource.cfg may contain: # Somewhere that plugins can write to: $USER8$=/var/log/nagios commands.cfg may contain: # 'check_cpu_hog_procs' command definition # Args: # 1 A unique name, used for the state file name in $USER8$ (with .status appended) # 2 How many minutes that an individual process needs to exceed a threshold for it to be reported # 3 Warning threshold # 4 Critical threshold define command{ command_name check_cpu_hog_procs command_line $USER1$/check_procs --state-file=$USER8$/$ARG1$.status --state-time=$ARG2$ -w $ARG3$ -c $ARG4$ -m CPU } The config file for the machine may contain (note the setting of max_check_attempts): # Detect CPU hogs # A process needs to exceed the limit for 15 minutes to be reported. # 80% CPU for warning. 90% CPU for critical. define service{ use local-service ; Name of service template to use max_check_attempts 1 ; Report any change of state immediately, check_cpu_hog_procs already does exceeded time host_name mint.phcomp.co.uk. service_description CPU Hog check_command check_cpu_hog_procs!cpu_hog!15!80!90 } Testing/Porting *************** This has been written on a 64 bit x86 CentOS 5 machine and tested on similar machines. No attempt to port it elsewhere has been made. The patch is against: nagios-plugins-trunk-200905081200 Copyright ********* I am content to assign copyright of this code to the Nagios Plugins Development Team on the understanding that this will not prevent me from using the code that I have written in any way that I wish (in this or another project). -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include -------------- next part -------------- --- check_procs.c 2009-02-21 09:59:24.000000000 +0000 +++ check_procs.c.new 2009-05-19 10:41:14.000000000 +0000 @@ -27,7 +27,8 @@ * * You should have received a copy of the GNU General Public License * along with this program. If not, see . -* +* +* State file stuff originally by: Alain Williams * *****************************************************************************/ @@ -42,13 +43,7 @@ #include "regex.h" #include - -int process_arguments (int, char **); -int validate_arguments (void); -int check_thresholds (int); -int convert_to_seconds (char *); -void print_help (void); -void print_usage (void); +#include int wmax = -1; int cmax = -1; @@ -77,6 +72,7 @@ METRIC_ELAPSED }; enum metric metric = METRIC_PROCS; +char metric_state_name = 'P'; /* Metric name in the state file */ int verbose = 0; int uid; @@ -92,9 +88,98 @@ char *fmt; char *fails; char tmp[MAX_INPUT_BUFFER]; +time_t now; +time_t state_limit_start; FILE *ps_input = NULL; +/* Optionally trigger an alert if a process has been in a state for + * some time. This time will be measured in minutes, ie much longer than + * this program runs for - thus a state file is needed to store this + * between runs of this program. + * This happens if --state-file is specified. + * + * The state file records information about processes that exceed some criteria + * for a warning or critical notice. + * The file will contain one 'V' line. + * If the metric is PROCS there will be one N line, else zero or more P lines. + * Format of the state file: + * Max line length of 500 + * Empty lines and lines starting '#' are ignored + * Lines consist of a type character, a space and optional extra information + * V version_number + * P pid ppid name MS secs + * name is limited to a max 20 characters + * M is the metric: + * V virtual memory size + * R resident set memory size + * C percentage CPU + * E time elapsed in seconds + * S is the state: + * W Warning + * C Critical + * N MS secs + * M will be 'P' + * S is the state as above + * secs is the epoch time the metric was first exceeded - hex number + * The 'MS secs' or 'S secs' may appear twice as it is possible for a process (or the + * max # processes) to exceed both the warning and critical thresholds but for different times. + * If something is C then it is implicitly W. + * + * There might be a trailing space on a N line. + * + * Eg: + * P 1234 1200 cpu_hog CW 4a05a817 CC 4a05a91f + * N PW 4a05a91f + */ +#define STATE_VERSION 1 /* Change me if the file format changes */ +#define STATE_MAX_LINE 500 /* Longest line */ +#define MAX_PROG_NAME 20 /* Longest name of program - search for this if you change it */ +#define METRIC_CODES "PVRCE" /* For input validation */ +#define STATE_CODES "WC" /* For input validation */ +#define STATE2state(x) ((x) == STATE_WARNING ? 'W' : 'C') /* Convert STATE_WARNING or STATE_CRITICAL to 'W' or 'C' */ + +/* A process can exceed various limits. This describes on of them + */ +typedef struct plimit { + struct plimit* pl_next; /* NULL terminated list */ + time_t pl_when; /* When it first exceeded this limit */ + int pl_state; /* STATE_WARNING or STATE_CRITICAL */ + int pl_seen; /* Exceeded this run */ + char pl_metric; /* What is exceeded - as in file */ +} PLimit; + +/* Something to describe a process that is exceeding something + */ +typedef struct exproc { + struct exproc* ep_next; /* NULL terminated list */ + pid_t ep_pid; /* Process ID */ + pid_t ep_ppid; /* Parent PID */ + char* ep_prog; /* Program name */ + PLimit* ep_limits; /* Limits exceeded list */ + int ep_seen; /* Updated/noticed this run */ +} ExProc; + +char* state_filename; /* File that we store this in */ +int state_time = 5; /* Trigger time - minutes */ +ExProc* state_list; /* Used for process specific metrics - ie metric is *not* PROCS */ +PLimit* state_nprocs; /* Info on # procs exceeded - used if metric is PROCS */ +int state_changed; /* Ie need to write back to file */ +int must_rewrite; /* Set this if there is a syntax error in the file, or + * some other reason which means we must rewrite it */ + +int process_arguments (int, char **); +int validate_arguments (void); +int check_thresholds (int); +int convert_to_seconds (char *); +void print_help (void); +void print_usage (void); +void read_state_file(void); +void write_state_file(char** argv); +void record_state(pid_t procpid, pid_t procppid, char* procprog, char prog_metric, int state, time_t start_time); +void record_limit(PLimit** l_ref, int state, char proc_metric, time_t start_time); +void read_limit_line(const char* in_line, PLimit** ppl, char* state_filename, int line_no); +int check_limit(PLimit* pl); int main (int argc, char **argv) @@ -129,13 +214,16 @@ int result = STATE_UNKNOWN; output chld_out, chld_err; + now = time(NULL); + setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); setlocale(LC_NUMERIC, "POSIX"); - input_buffer = malloc (MAX_INPUT_BUFFER); - procprog = malloc (MAX_INPUT_BUFFER); + if( ! (input_buffer = malloc (MAX_INPUT_BUFFER)) || + ! (procprog = malloc (MAX_INPUT_BUFFER))) + die(STATE_UNKNOWN, _("Out of memory in startup\n")); asprintf (&metric_name, "PROCS"); metric = METRIC_PROCS; @@ -168,6 +256,9 @@ result = cmd_file_read( input_filename, &chld_out, 0); } + /* What do we remember from last time ? */ + read_state_file(); + /* flush first line: j starts at 1 */ for (j = 1; j < chld_out.lines; j++) { input_line = chld_out.line[j]; @@ -237,6 +328,10 @@ procetime, procprog, procargs); } + /* This is all made simpler because metric can only talk about + * one metric, ie can't check more than one thing at a time. + * This means that metric_state_name is the char equivalent of metric. + */ if (metric == METRIC_VSZ) i = check_thresholds (procvsz); else if (metric == METRIC_RSS) @@ -248,15 +343,29 @@ i = check_thresholds (procseconds); if (metric != METRIC_PROCS) { - if (i == STATE_WARNING) { - warn++; - asprintf (&fails, "%s%s%s", fails, (strcmp(fails,"") ? ", " : ""), procprog); - result = max_state (result, i); - } - if (i == STATE_CRITICAL) { - crit++; - asprintf (&fails, "%s%s%s", fails, (strcmp(fails,"") ? ", " : ""), procprog); - result = max_state (result, i); + if(state_filename) { + /* State is being stored - ie don't report immediately. + * Note what we have found: + */ + if(i == STATE_WARNING || i == STATE_CRITICAL) + record_state(procpid, procppid, procprog, metric_state_name, i, now); + } else { + if (i == STATE_WARNING) { + char* str = fails; + warn++; + asprintf (&fails, "%s%s%s", fails, (strcmp(fails,"") ? ", " : ""), procprog); + result = max_state (result, i); + if(str) + free(str); + } + if (i == STATE_CRITICAL) { + char* str = fails; + crit++; + asprintf (&fails, "%s%s%s", fails, (strcmp(fails,"") ? ", " : ""), procprog); + result = max_state (result, i); + if(str) + free(str); + } } } } @@ -276,7 +385,59 @@ /* Needed if procs found, but none match filter */ if ( metric == METRIC_PROCS ) { - result = max_state (result, check_thresholds (procs) ); + int threshold = check_thresholds(procs); + int putative_result = max_state(result, threshold); + + if(state_filename) { /* Do not report immediately - note what we found */ + /* Only record something if we may need to report it */ + if(putative_result == STATE_WARNING || putative_result == STATE_CRITICAL) + record_limit(&state_nprocs, putative_result, 'P', now); + } else + result = putative_result; + } + + /* If we have a state file, the above has just stored the results away, so have + * a look and see if there is anything that we should note. + * The slight subtlety is that we could have something recorded as both a warning + * & a critical - in this case only report the critical. + */ + if(state_filename) { + /* Compute the start time of any state that we must report. + * Ie any state younger than this we keep quiet about. + */ + state_limit_start = (time_t)((unsigned long)now - state_time * 60); + + if(verbose >= 3) + printf("Checking metric %c, limit_start %s", metric_state_name, ctime(&state_limit_start)); + + if(metric == METRIC_PROCS) { + result = check_limit(state_nprocs); + } else { + ExProc* pp; + + for(pp = state_list; pp; pp = pp->ep_next) { + char* str = fails; + + /* What is the state of this recorded process ? */ + int res = check_limit(pp->ep_limits); + + switch(res) { + case STATE_OK: + continue; /* Don't do the stuff below */ + case STATE_WARNING: + warn++; + break; + case STATE_CRITICAL: + crit++; + break; + } + + asprintf (&fails, "%s%s%s", fails, (strcmp(fails,"") ? ", " : ""), pp->ep_prog); + result = max_state(result, res); + if(str) + free(str); + } + } } if ( result == STATE_OK ) { @@ -302,6 +463,9 @@ printf (" [%s]", fails); printf ("\n"); + + write_state_file(argv); + return result; } @@ -336,6 +500,8 @@ {"verbose", no_argument, 0, 'v'}, {"ereg-argument-array", required_argument, 0, CHAR_MAX+1}, {"input-file", required_argument, 0, CHAR_MAX+2}, + {"state-file", required_argument, 0, 'S'}, + {"state-time", required_argument, 0, 'T'}, {0, 0, 0, 0} }; @@ -344,7 +510,7 @@ strcpy (argv[c], "-t"); while (1) { - c = getopt_long (argc, argv, "Vvht:c:w:p:s:u:C:a:z:r:m:P:", + c = getopt_long (argc, argv, "Vvht:c:w:p:s:u:C:a:z:r:m:P:S:T:", longopts, &option); if (c == -1 || c == EOF) @@ -479,22 +645,27 @@ asprintf (&metric_name, "%s", optarg); if ( strcmp(optarg, "PROCS") == 0) { metric = METRIC_PROCS; + metric_state_name = 'P'; break; } else if ( strcmp(optarg, "VSZ") == 0) { metric = METRIC_VSZ; + metric_state_name = 'V'; break; } else if ( strcmp(optarg, "RSS") == 0 ) { metric = METRIC_RSS; + metric_state_name = 'R'; break; } else if ( strcmp(optarg, "CPU") == 0 ) { metric = METRIC_CPU; + metric_state_name = 'C'; break; } else if ( strcmp(optarg, "ELAPSED") == 0) { metric = METRIC_ELAPSED; + metric_state_name = 'E'; break; } @@ -505,6 +676,16 @@ case CHAR_MAX+2: input_filename = optarg; break; + case 'S': /* state-file */ + state_filename = optarg; + break; + case 'T': /* state-time */ + if (!is_integer (optarg)) + usage2 (_("state-time must be a positive integer"), optarg); + else + if((state_time = atoi (optarg)) < 0) /* Treat -ve time as zero */ + state_time = 0; + break; } } @@ -727,6 +908,12 @@ printf (" %s\n", "-C, --command=COMMAND"); printf (" %s\n", _("Only scan for exact matches of COMMAND (without path).")); + printf ("\n"); + printf ( "%s\n", "State memory (complain if a process exceeds a limit for a long time):"); + printf ( " %s\n", "-S, --state-file=StateFile"); + printf ( " %s\n", _("Store process information in this file")); + printf ( " %s\n", "-T, --state-time=minutes"); + printf(_("\n\ RANGEs are specified 'min:max' or 'min:' or ':max' (or 'max'). If\n\ specified 'max:min', a warning status will be generated if the\n\ @@ -755,7 +942,9 @@ printf (" %s\n", "check_procs -w 50000 -c 100000 --metric=VSZ"); printf (" %s\n\n", _("Alert if VSZ of any processes over 50K or 100K")); printf (" %s\n", "check_procs -w 10 -c 20 --metric=CPU"); - printf (" %s\n", _("Alert if CPU of any processes over 10%% or 20%%")); + printf (" %s\n\n", _("Alert if CPU of any processes over 10% or 20%")); + printf (" %s\n", "check_procs -w 80 -c 90 --metric=CPU --state-time=10 --state-file=/tmp/CPU-state"); + printf (" %s\n", _("Alert if CPU of any processes over 80% or 90% for at least 10 minutes, record state in /tmp/CPU-state")); printf (_(UT_SUPPORT)); } @@ -766,5 +955,423 @@ printf (_("Usage: ")); printf ("%s -w -c [-m metric] [-s state] [-p ppid]\n", progname); printf (" [-u user] [-r rss] [-z vsz] [-P %%cpu] [-a argument-array]\n"); - printf (" [-C command] [-t timeout] [-v]\n"); + printf (" [-C command] [-t timeout] [-v] [-S state_file] [-T state_time_minutes]\n"); +} + +/* Read the state file - if there is one. + * + * This file is not locked. On a horribly over loaded system it might happen that reads & writes + * could overlap in the wrong way. Locking could make things worse, you may end up with many + * instances of this program waiting on the lock. + */ +void +read_state_file(void) +{ + FILE* sf; + char* errstr; + char* str; + char in_buf[STATE_MAX_LINE]; /* Input buffer */ + int line_no = 0; + char prog_name[MAX_PROG_NAME + 1]; + int eaten; + ExProc* pp; + + if( ! state_filename) /* No file specified */ + return; + + if( ! (sf = fopen(state_filename, "r"))) { + /* It is OK if it doesn't exist, we just haven't created it yet */ + if(errno == ENOENT) { + must_rewrite = 1; /* Force it to be created */ + return; + } + + /* Anything else - should not happen */ + errstr = strerror(errno); + die(STATE_UNKNOWN, _("Can't open %s for reading as: %s"), state_filename, errstr); + } + + /* Read a line at a time */ + while(fgets(in_buf, STATE_MAX_LINE, sf)) { + line_no++; + if( ! (str = strchr(in_buf, '\n'))) { + printf(_("State file %s corrupt, line too long, at line %d\n"), state_filename, line_no); + must_rewrite = 1; /* Force write */ + goto read_off; /* Will be fixed when we rewrite it in a moment */ + } + *str = '\0'; + + /* Empty line or comment ? */ + if(in_buf[0] == '\0' || in_buf[0] == '#') + continue; + + if(in_buf[1] != ' ') { + printf(_("State file %s corrupt, no space at position 1, at line %d\n"), state_filename, line_no); + must_rewrite = 1; /* Force write */ + goto read_off; + } + + /* What line type ? */ + switch(in_buf[0]) { + case 'V': /* In case we are running 1st time after upgrade */ + if(atoi(in_buf + 2) != STATE_VERSION) { + printf(_("State file %s is wrong version, expecting %d. File ignored\n"), state_filename, STATE_VERSION); + must_rewrite = 1; /* Force write */ + goto read_off; + } + break; + case 'P': /* Info about a process */ + /* P 1234 1200 cpu_hog CW 4a05a817 CC 4a05a92f */ + if( ! (pp = calloc(sizeof(ExProc), 1))) + die(STATE_UNKNOWN, _("Out of memory reading %s line %d"), state_filename, line_no); + + pp->ep_next = state_list; + state_list = pp; + + /* MAX_PROG_NAME on next line */ + if(sscanf(in_buf, "P %d %d %20s%n", &pp->ep_pid, &pp->ep_ppid, prog_name, &eaten) != 3) { + printf(_("State file corrupt, bad process line, file %s line %d\n"), state_filename, line_no); + must_rewrite = 1; /* Force write */ + goto read_off; + } + + if( ! (pp->ep_prog = strdup(prog_name))) + die(STATE_UNKNOWN, _("Out of memory reading %s line %d\n"), state_filename, line_no); + + if(verbose >= 3) + printf("Read pid %d ppid %d proc %s\n", pp->ep_pid, pp->ep_ppid, pp->ep_prog); + + read_limit_line(in_buf + eaten, &pp->ep_limits, state_filename, line_no); + break; + case 'N': /* Number of procs exceeded */ + if(verbose >= 3) + printf("Read N:\n"); + read_limit_line(in_buf + 1, &state_nprocs, state_filename, line_no); + break; + default: + printf(_("State file %s corrupt, unknown line type, at line %d\n"), state_filename, line_no); + must_rewrite = 1; /* Force write */ + goto read_off; + } + } + + /* Ignore changes so far */ +read_off: + state_changed = 0; + + fclose(sf); +} + +/* Read a line (or rest of) a process or global limit line. + * Expect the first character of in_line to be NUL or a space. + * Args: + * in_line the line to read + * ppl pointer to pointer to linked list where to store what is read + * filename the name of the file being read + * line_no that was read + * + * Read lines like: + * PW 4a05a91f PC 4a05a817 + */ +void +read_limit_line(const char* in_line, PLimit** ppl, char* state_filename, int line_no) +{ + PLimit* pl; + unsigned long when; + int eaten; + + while(*in_line) { + if(*in_line == ' ') { /* Ignore spaces */ + in_line++; + continue; + } + + /* We have found something, allocate somewhere to put it */ + if( ! (pl = calloc(sizeof(PLimit), 1))) + die(STATE_UNKNOWN, _("Out of memory reading %s line %d\n"), state_filename, line_no); + + /* Read a metric code */ + if( ! strchr(METRIC_CODES, *in_line)) { + printf(_("State file %s corrupt, unknown metric code, at line %d\n"), state_filename, line_no); + must_rewrite = 1; + free(pl); + return; + } + pl->pl_metric = *in_line++; + + /* Read the state code */ + if(*in_line == '\0' || ! strchr(STATE_CODES, *in_line)) { + printf(_("State file %s corrupt, unknown state code, at line %d\n"), state_filename, line_no); + must_rewrite = 1; + free(pl); + return; + } + pl->pl_state = *in_line++ == 'W' ? STATE_WARNING : STATE_CRITICAL; + + /* Read the time */ + if(sscanf(in_line, " %lx%n", &when, &eaten) != 1) { + printf(_("State file %s corrupt, bad time, at line %d\n"), state_filename, line_no); + must_rewrite = 1; + free(pl); + return; + } + pl->pl_when = (time_t)when; + in_line += eaten; + + if(verbose >= 3) + printf(" metric=%c state=%c since %s", pl->pl_metric, STATE2state(pl->pl_state), ctime(&pl->pl_when)); + + /* Link it in */ + pl->pl_next = *ppl; + *ppl = pl; + } + + if(verbose >= 3) + printf("\n"); +} + +/* Write back to the state file + */ +void +write_state_file(char** argv) +{ + FILE* sf; + char* errstr; + ExProc* pp; + PLimit* pl; + + if( ! state_filename) /* No file specified */ + return; + + /* Work out if we are going to write back what we read in. + * If there is something that has not been seen then it was read in + * from the file - need to write back to loose the entry, scan for that. + * Otherwise: state_changed will tell us what we want to know and was set + * when a change was made. + */ + if(metric == METRIC_PROCS) { + for(pl = state_nprocs; pl; pl = pl->pl_next) + if( ! pl->pl_seen) + state_changed = 1; + } else { + for(pp = state_list; pp; pp = pp->ep_next) { + if( ! pp->ep_seen) + state_changed = 1; + + for(pl = pp->ep_limits; pl; pl = pl->pl_next) + if( ! pl->pl_seen) + state_changed = 1; + } + } + + if(verbose >= 3) + printf("Write state, changed=%d\n", state_changed); + + /* No change to the state file ? */ + if( ! state_changed && ! must_rewrite) + return; + + if( ! (sf = fopen(state_filename, "w"))) { + errstr = strerror(errno); + die(STATE_UNKNOWN, _("Can't open %s for writing as: %s"), state_filename, errstr); + } + + fprintf(sf, "# Process state file written by %s - DO NOT HAND EDIT\n", progname); + fprintf(sf, "# Args:"); + for(; *argv; argv++) + fprintf(sf, " %s", *argv); + fprintf(sf, "\n"); + fprintf(sf, "V %d\n", STATE_VERSION); + + if(metric != METRIC_PROCS) { + /* Traverse the processes that we know about */ + for(pp = state_list; pp; pp = pp->ep_next) { + if( ! pp->ep_seen) + continue; + + fprintf(sf, "P %d %d %.*s", pp->ep_pid, pp->ep_ppid, MAX_PROG_NAME, pp->ep_prog); + for(pl = pp->ep_limits; pl; pl = pl->pl_next) + if(pl->pl_seen) + fprintf(sf, " %c%c %lx", pl->pl_metric, STATE2state(pl->pl_state), (unsigned long)pl->pl_when); + + fprintf(sf, "\n"); + } + } else { + /* Print when the # processes is what is being checked */ + fprintf(sf, "N"); + for(pl = state_nprocs; pl; pl = pl->pl_next) + if(pl->pl_seen) + fprintf(sf, " %c%c %lx", pl->pl_metric, STATE2state(pl->pl_state), (unsigned long)pl->pl_when); + + /* Space before \n is important - else get error on read if no limits follow -- which + * will happen if all is well. + */ + fprintf(sf, " \n"); + } + + fclose(sf); +} + +/* Record a state for a program. + * Create a new entry if we need to, or update an existing one. + * Program must match on the first 3 args to update. + * Args: + * procpid Process ID + * procppid Parent process ID + * progprog Program name + * prog_metric What we are measuring (METRIC_something but represented as the character in the file) + * state Error or warning (STATE_something) + */ +void +record_state(pid_t procpid, pid_t procppid, char* procprog, char prog_metric, int state, time_t start_time) +{ + ExProc* pp; + + /* Look for the process */ + for(pp = state_list; pp; pp = pp->ep_next) { + if(pp->ep_pid != procpid) + continue; + + /* Right process, but if it has mutated - throw it away and start again. + * This doesn't detect processes that exec() a lot w/out fork(), but that is rare. + */ + if(pp->ep_ppid != procppid || strcmp(pp->ep_prog, procprog)) { + PLimit* pl; + while(pl = pp->ep_limits) { + pp->ep_limits = pl->pl_next; + free(pl); + } + pp->ep_ppid = procppid; + if(strcmp(pp->ep_prog, procprog)) { + free(pp->ep_prog); + if( ! (pp->ep_prog = strdup(procprog))) + die(STATE_UNKNOWN, _("Out of memory")); + } + + state_changed = 1; + } + + if(verbose >= 3) + printf("Record found: pid %d %s\n", pp->ep_pid, pp->ep_prog); + + break; + } + + /* Didn't find the process, allocate a new entry */ + if( ! pp) { + if( ! (pp = calloc(sizeof(ExProc), 1))) + die(STATE_UNKNOWN, _("Out of memory")); + pp->ep_pid = procpid; + pp->ep_ppid = procppid; + if( ! (pp->ep_prog = strdup(procprog))) + die(STATE_UNKNOWN, _("Out of memory")); + + pp->ep_next = state_list; + state_list = pp; + state_changed = 1; + + if(verbose >= 3) + printf("Record alloc: pid %d %s\n", pp->ep_pid, pp->ep_prog); + } + + pp->ep_seen = 1; /* Ensure that this gets written out */ + + record_limit(&pp->ep_limits, state, prog_metric, start_time); +} + +/* Store a limit + * l_ref address of head of limits chain + * prog_metric What we are measuring (METRIC_something but represented as the character in the file) + * state Error or warning (STATE_something) + * start_time The time to record when it started, if we already record this - don't change the time + * unless this is older. + * + * If something is C then it is implicitly W. This is important: if something goes from + * W to C, it might remain at C for less than the state time (which it might do W -> C + * & back again several times) - but the time above the W level might be notifiable. + */ +void +record_limit(PLimit** l_ref, int state, char proc_metric, time_t start_time) +{ + PLimit* pl; + PLimit* pl_found = NULL; + int seen_warning = 0; + + /* Find the individual process limit. + * Scan the whole lot since we want to 'seen' a Warning if we have Critical. + */ + for(pl = *l_ref; pl; pl = pl->pl_next) + if(pl->pl_metric == proc_metric) { + if(state == STATE_CRITICAL && pl->pl_state == STATE_WARNING) { + pl->pl_seen = 1; /* Ensure that it is output */ + seen_warning = 1; + } + + if(pl->pl_state == state) + pl_found = pl; /* We found what we were looking for */ + } + + pl = pl_found; + + /* Didn't find it, allocate a new one */ + if( ! pl) { + if( ! (pl = calloc(sizeof(PLimit), 1))) + die(STATE_UNKNOWN, _("Out of memory")); + pl->pl_next = *l_ref; + *l_ref = pl; + pl->pl_when = start_time; + pl->pl_state = state; + pl->pl_metric = proc_metric; + + state_changed = 1; + } else /* It is possible that the time was set earlier when a 'C' generated + * an implicit 'W'. Since the 'W' prob started earlier that the 'C' + * we may have recorded the later 'C' time rather than the 'W' time. + */ + if(pl->pl_when > start_time) + pl->pl_when = start_time; + + pl->pl_seen = 1; /* Ensure that it is output */ + + if(verbose >= 3) + printf("Record limit: metric=%c state=%c since %s", pl->pl_metric, STATE2state(pl->pl_state), ctime(&pl->pl_when)); + + /* If this is a critical, but we didn't see the warning - generate the warning */ + if(state == 'C' && ! seen_warning) + record_limit(l_ref, 'W', proc_metric, start_time); +} + +/* Check if limits have been exceeded for at least the state-time + * Check only metric_state_name regardless of what is stored. + * + * Args: + * pl List of limit values + * + * Return: STATE_OK, STATE_WARNING or STATE_CRITICAL + */ +int +check_limit(PLimit* pl) +{ + int result = STATE_OK; + + for(; pl; pl = pl->pl_next) { + if( ! pl->pl_seen) + continue; /* Of no interest, not updated this run */ + + if(pl->pl_metric != metric_state_name) + continue; /* Not what we are looking for */ + + /* Is this something that has been going on for long enough that we + * are to report it ? + */ + if(pl->pl_when <= state_limit_start) { + if(result == STATE_OK) + result = pl->pl_state; + + if(result == STATE_WARNING && pl->pl_state == STATE_CRITICAL) + result = STATE_CRITICAL; + } + } + + return(result); } From pepper at reppep.com Tue May 19 13:56:46 2009 From: pepper at reppep.com (Chris Pepper) Date: Tue, 19 May 2009 07:56:46 -0400 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' Message-ID: <4A129E7E.1030109@reppep.com> Ton Voon wrote: > > On 18 May 2009, at 15:15, Chris Pepper wrote: > >>> If you are using GCC and your MySQL version was compiled using Sun's C compiler (or the other way round), then it is likely that the configure options will fail as configure will run mysql_config to get the appropriate CFLAGS. >> >> This assumes MySQL is installed. Our S10 boxen don't have MySQL, so I'd amend as follows: >> >> If you are using GCC to build the plugins, but your MySQL version was compiled using Sun's C compiler (or the other way round) -- or if you don't have MySQL installed on Solaris at all -- then it is likely that the default build procedure will fail, as configure assumes it get appropriate CFLAGS by executing mysql_config. >> >> But really, configure shouldn't assume MySQL is present at all. > > Hi Chris, > > If mysql_config doesn't exist, then it assumes mysql does not exist and then doesn't try to compile check_mysql. This doesn't work -- on our S10 systems with no MySQL at all, the build fails. Perhaps the MySQL configuration needs to be wrapped in a check for availability. > I think this is a reasonable course of action. The current logic is: > * if you've been told to include mysql, then try to compile check_mysql > * if you've been told not to include mysql, don't try to compile check_mysql > * if you have not specified anything, then see if mysql_config is available and if it is the compile check_mysql This is a good model, but not current behavior. > I think the last step could be enhanced to include trying to compile a very small mysql program and if that fails, then do not try check_mysql. Patches welcome. Sorry, I don't have a fix. Chris -- Chris Pepper: From holger at CIS.FU-Berlin.DE Tue May 19 14:12:39 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 19 May 2009 14:12:39 +0200 Subject: [Nagiosplug-devel] Solaris 10: mysql plugin breaks 'make' In-Reply-To: <4A129E7E.1030109@reppep.com> References: <6EBCB750-0BDD-47EA-ADCE-444ED99F5307@opsera.com> <4A129E7E.1030109@reppep.com> Message-ID: <20090519121239.GW41927050@CIS.FU-Berlin.DE> * Chris Pepper [2009-05-19 07:56]: > Ton Voon wrote: > > If mysql_config doesn't exist, then it assumes mysql does not exist > > and then doesn't try to compile check_mysql. > > This doesn't work -- on our S10 systems with no MySQL at all, the > build fails. As I cannot reproduce the problem (building the plugins without MySQL installed works just fine for me): Could you please post the exact error message(s) you get? Holger From pepper at reppep.com Tue May 19 16:30:24 2009 From: pepper at reppep.com (Chris Pepper) Date: Tue, 19 May 2009 10:30:24 -0400 Subject: [Nagiosplug-devel] check_disk --megabytes doesn't work In-Reply-To: References: Message-ID: <4A12C280.5000308@reppep.com> nagiosplug-devel-request at lists.sourceforge.net wrote: > Date: Tue, 19 May 2009 00:10:37 +0200 > From: Matthias Eble > Subject: Re: [Nagiosplug-devel] check_disk --megabytes doesn't work > To: Nagios Plugin Development Mailing List > Message-ID: <1242684637.7811.4.camel at pc.site> > Content-Type: text/plain > Hi Chris, >> > The help says I can use --megabytes, but when I do it eats the -w >> > argument and causes an error. >> > >> > http://nagiosplugins.org/man/check_disk >> > >> > Chris >> > >> > > maguro:~ # /usr/local/nagios/libexec/check_disk -m -w 3% -c 1% -p / >> > > DISK OK - free space: / 3912 MB (81% inode=96%);| >> > /=873MB;4889;4990;0;5041 >> > > maguro:~ # /usr/local/nagios/libexec/check_disk --megabytes -w 3% -c >> > 1% -p / >> > > DISK CRITICAL - 3% is not accessible: No such file or directory >> > > maguro:~ # /usr/local/nagios/libexec/check_disk --version >> > > check_disk v2025 (nagios-plugins 1.4.13) > > I cannot reproduce this, here (at least not with the current git > version. Can you try the latest one? You can find it here: > http://repo.or.cz/w/nagiosplugins.git > > Otherwise: maybe there's a bug in your getopt parser? I can't remember > any commits that could've affected this. Matthias, It looks like this has indeed changed since the last plugin release. On a CentOS 5.2 system, the release complains if --megabytes is the last argument, while a build from git works. Chris > -bash-3.2$ ./plugins/check_disk -l --megabytes > DISK OK - free space: / 4650 MB (62% inode=95%); /home 109429 MB (99% inode=99%); /var 3567 MB (94% inode=99%); /boot 224 MB (94% inode=99%); /dev/shm 1975 MB (100% inode=99%); /noribeast0a 5227326 MB (66% inode=99%); /noribeast0b 2174653 MB (27% inode=97%); /noribeast0c 371462 MB (99% inode=99%); /noribeast1a 2822197 MB (36% inode=98%); /noribeast1b 2188479 MB (27% inode=96%); /noribeast1c 369582 MB (99% inode=99%);| /=2786MB;;;0;7841 /home=287MB;;;0;115688 /var=194MB;;;0;3966 /boot=13MB;;;0;250 /dev/shm=0MB;;;0;1975 /noribeast0a=2606394MB;;;0;8252946 /noribeast0b=5659067MB;;;0;8252946 /noribeast0c=1771MB;;;0;393207 /noribeast1a=5011523MB;;;0;8252946 /noribeast1b=5645241MB;;;0;8252946 /noribeast1c=3651MB;;;0;393207 > -bash-3.2$ pwd > /home/pepper/nagios/nagiosplugins.git > -bash-3.2$ ./plugins/check_disk --version > check_disk v1.4.13.git (nagios-plugins 1.4.13) > -bash-3.2$ /usr/local/nagios/libexec/check_disk -l --megabytes > /usr/local/nagios/libexec/check_disk: option `--megabytes' requires an argument > Unknown argument > Usage: check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x device} > [-C] [-E] [-e] [-g group ] [-k] [-l] [-M] [-m] [-R path ] [-r path ] > [-t timeout] [-u unit] [-v] [-X type] > -bash-3.2$ /usr/local/nagios/libexec/check_disk --version > check_disk v2025 (nagios-plugins 1.4.13) > -bash-3.2$ uname -a > Linux norimaki.cbio.mskcc.org 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64 x86_64 GNU/Linux > -bash-3.2$ cat /etc/redhat-release > CentOS release 5.2 (Final) -- Chris Pepper: From noreply at sourceforge.net Tue May 19 21:04:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 May 2009 19:04:33 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2786808 ] check_http asks for HTTP/1.1, but doesn't understand chunked Message-ID: Bugs item #2786808, was opened at 2009-05-04 21:19 Message generated for change (Comment added) made by hweiss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parsing problem Group: CVS Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ferenc W?gner (wferi) >Assigned to: Holger Wei? (hweiss) Summary: check_http asks for HTTP/1.1, but doesn't understand chunked Initial Comment: Fixing 2638765 uncovered this bug (actually, most HTTP servers respect Host: headers in HTTP/1.0 requests, even though it isn't part of the spec). Anyway: if a client sends a HTTP/1.1 request, it must be able to handle the incoming HTTP/1.1 reply. Which includes coping with a chunked one. This exact same command worked with check_http version 1.4.5 (and still does so with -H replaced by -I, but that isn't the point). $ /usr/lib/nagios/plugins/check_http -v -H idp.niif.hu -u /idp/profile/Status --ssl -r "^ok$" GET /idp/profile/Status HTTP/1.1 Host: idp.niif.hu:443 User-Agent: check_http/v1991 (nagios-plugins 1.4.12) Connection: close https://idp.niif.hu:443/idp/profile/Status is 141 characters STATUS: HTTP/1.1 200 OK **** HEADER **** Date: Mon, 04 May 2009 19:12:13 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/plain **** CONTENT **** 2 ok 0 HTTP CRITICAL - pattern not found|time=0.067933s;;;0.000000 size=141B;;;0 ---------------------------------------------------------------------- >Comment By: Holger Wei? (hweiss) Date: 2009-05-19 21:04 Message: I'll look into teaching check_http how to cope with chunked replies. Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2786808&group_id=29880 From holger at CIS.FU-Berlin.DE Tue May 19 23:35:07 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Tue, 19 May 2009 23:35:07 +0200 Subject: [Nagiosplug-devel] git URLs on main site? In-Reply-To: <4A1171D7.2090605@reppep.com> References: <4A1171D7.2090605@reppep.com> Message-ID: <20090519213506.GY41927050@CIS.FU-Berlin.DE> * Chris Pepper [2009-05-18 10:33]: > I found the git download information in , but > > says development is via CVS Fixed. > and the Download page doesn't provide > git/svn/cvs info at all. I added a link to /git on that page (in order to not duplicate the information). Thanks, Holger From holger at CIS.FU-Berlin.DE Wed May 20 00:04:58 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 20 May 2009 00:04:58 +0200 Subject: [Nagiosplug-devel] check_ups.c typos In-Reply-To: <4A1183E8.8060405@reppep.com> References: <4A1183E8.8060405@reppep.com> Message-ID: <20090519220458.GZ41927050@CIS.FU-Berlin.DE> * Chris Pepper [2009-05-18 11:51]: > --- check_ups.c 2009-05-18 10:25:58.000000000 -0400 > +++ check_ups.pepper.c 2009-05-18 11:41:27.000000000 -0400 Applied (manually, as the patch was mangled). Thanks, Holger From holger at CIS.FU-Berlin.DE Wed May 20 00:07:01 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Wed, 20 May 2009 00:07:01 +0200 Subject: [Nagiosplug-devel] Typos in urlize.c In-Reply-To: <4A1183FF.2020400@reppep.com> References: <4A1183FF.2020400@reppep.com> Message-ID: <20090519220701.GA41927050@CIS.FU-Berlin.DE> * Chris Pepper [2009-05-18 11:51]: > --- urlize.c 2009-05-18 10:25:58.000000000 -0400 > +++ urlize.pepper.c 2009-05-18 11:46:37.000000000 -0400 Again: applied (manually, as the patch was mangled). Thanks, Holger From noreply at sourceforge.net Wed May 20 00:25:05 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 19 May 2009 22:25:05 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2794120 ] Detect a process that enters an infinite loop. Message-ID: Patches item #2794120, was opened at 2009-05-19 23:25 Message generated for change (Tracker Item Submitted) made by addw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2794120&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: alain williams (addw) Assigned to: Nobody/Anonymous (nobody) Summary: Detect a process that enters an infinite loop. Initial Comment: Motivation ********** Detect a process that enters an infinite loop. With today's multi process CPUs this might not be noticed for some time. Discussion ********** Taking a snapshot and detecting that a process is using 100% of a CPU can generate false positives, eg catching the overnight batch job that is CPU intensive for a few minutes. Using the nagios config option 'max_check_attempts' may also generate false positives if different processes eat CPU in succession. The patch saves notes about 'interesting processes' in a status file that is checked/updated by successive runs of check_procs. This allows detection of processes that exceed the limits over a long time. It records the start time of when individual process exceed limits. Only processes that exceed a limit are deemed interesting and so have details in the status file. The start of Warning and Critical times are separate. Start of Critical implies Warning. Processes are identified by PID. If the PPID or program change it is assumed to be a different process (ie any history is forgotten). Configuration ************* resource.cfg may contain: # Somewhere that plugins can write to: $USER8$=/var/log/nagios commands.cfg may contain: # 'check_cpu_hog_procs' command definition # Args: # 1 A unique name, used for the state file name in $USER8$ (with .status appended) # 2 How many minutes that an individual process needs to exceed a threshold for it to be reported # 3 Warning threshold # 4 Critical threshold define command{ command_name check_cpu_hog_procs command_line $USER1$/check_procs --state-file=$USER8$/$ARG1$.status --state-time=$ARG2$ -w $ARG3$ -c $ARG4$ -m CPU } The config file for the machine may contain (note the setting of max_check_attempts): # Detect CPU hogs # A process needs to exceed the limit for 15 minutes to be reported. # 80% CPU for warning. 90% CPU for critical. define service{ use local-service ; Name of service template to use max_check_attempts 1 ; Report any change of state immediately, check_cpu_hog_procs already does exceeded time host_name mint.phcomp.co.uk. service_description CPU Hog check_command check_cpu_hog_procs!cpu_hog!15!80!90 } Testing/Porting *************** This has been written on a 64 bit x86 CentOS 5 machine and tested on similar machines. No attempt to port it elsewhere has been made. The patch is against: nagios-plugins-trunk-200905081200 Copyright ********* I am content to assign copyright of this code to the Nagios Plugins Development Team on the understanding that this will not prevent me from using the code that I have written in any way that I wish (in this or another project). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2794120&group_id=29880 From noreply at sourceforge.net Wed May 20 05:06:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 03:06:33 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2531905 ] check_mysql does not properly handle passwords in from file. Message-ID: Bugs item #2531905, was opened at 2009-01-23 18:13 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2531905&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing >Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Timby (btimby) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_mysql does not properly handle passwords in from file. Initial Comment: ----------------- PROBLEM ----------------- The mysql client can use a password from a configuration file. This feature is nice as it keeps the password off of the command line. The check_mysql function does not allow for this. Even though the program informs you via a warning that passing the password on the command line is insecure. It does not allow for the best alternative. According to mysql, the mysql_connect() and mysql_real_connect() both allow a value of NULL to be given for the password. http://dev.mysql.com/doc/refman/5.1/en/mysql-real-connect.html In this case, if a password was read from the option file, it will be used for authentication. The constant "" is used in the case of NO password. Right now, check_mysql, in the validate_arguments() function sets the value of db_pass to "" if it was not provided on the command line. This prevents the password configured in the option file from being used. ----------------- TEST CASE ----------------- # vi $HOME/.my.cnf [client] password=foo # ./check_mysql Access denied for user 'root'@'localhost' (using password: NO) ----------------- PATCH ----------------- The attached patch remedies this. It uses the same method as the mysql client to determine if NULL or "" should be used. If -p is provided, without a value, then "" is used. If -p is omitted, then NULL is used. If -p is provided WITH a password, that password is used. ---------------------------------------------------------------------- Comment By: Ben Timby (btimby) Date: 2009-02-11 08:28 Message: Hopefully that last post clears up your questions, if not here is a short explaination. While the check_mysql plugin always called mysql_options(), it also always set db_pass to "". This caused the password from the file to be ignored as the password was explicitly set to "". To counteract this, I modified the source so that if the -p parameter is omitted, then db_pass is left as NULL. If the -p parameter is provided, but no password is provided, then db_pass is set to "" (like before). If a password is provided as an argument to -p, then that value is copied to db_pass. ---------------------------------------------------------------------- Comment By: Ben Timby (btimby) Date: 2009-02-11 08:22 Message: dermoth, I think you read the patch wrong. The last hunk REMOVES the setting of db_pass to null when it is ''. That was basically the whole problem :-). -- @@ -361,9 +365,6 @@ if (db_host == NULL) db_host = strdup(""); - if (db_pass == NULL) - db_pass = strdup(""); - if (db == NULL) db = strdup(""); -- The difference between '', NULL and is explained at the link I sent in my original bug report: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-connect.html I reproduce the relevant part below... -- For some parameters, it is possible to have the value taken from an option file rather than from an explicit value in the mysql_real_connect() call. To do this, call mysql_options() with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option before calling mysql_real_connect(). Then, in the mysql_real_connect() call, specify the ?no-value? value for each parameter to be read from an option file: * For passwd, specify a value of NULL. (For the password, a value of the empty string in the mysql_real_connect() call cannot be overridden in an option file, because the empty string indicates explicitly that the MySQL account must have an empty password.) -- ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-01-23 19:03 Message: Thanks for your patch. There's one thing though that I don't understand, since it already sets db_pass to "" when null (last hunk of your patch does it), why do you need to do this using -p? Can you explain the difference between db_pass=NULL, ="" and =, or point me to the right place in the libmysql documentation? You should also be aware that you can also use the extra-opts feature to use a file for the password argument (you need to enable it with configure; I know some packages enable it by default), although I highly suggest to use the latest snapshot until the 1.4.14 release as there have been some important fixes since 1.4.13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2531905&group_id=29880 From dermoth at aei.ca Wed May 20 05:13:17 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 19 May 2009 23:13:17 -0400 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <1242409241.6671.16.camel@homer.ob.libexec.de> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> <1242409241.6671.16.camel@homer.ob.libexec.de> Message-ID: <4A13754D.7010102@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/05/09 01:40 PM, Tobias Scherbaum wrote: > Thomas Guyot-Sionnest wrote: >> We've been able to get a bunch of fixes in after the release >> announcement, though there's still 4-5 bugs I'd like to get fixed or at >> least have a deeper look into them: >> >> * [1985246] ssh_disk dont interpret -C with single quotes correct >> * [2632995] check_procs fails on Solaris >> * [2722832] awk subst.in/subst script path error >> * [2268675] fix for quoting in check_by_ssh >> * [1939022] SSL/TLS hostname extension support (SNI) > > What about > > [2531905] check_mysql does not properly handle passwords in from file > > wkr, > Tobias Hey thanks for pointing it out - I will have a look As a general reminder please DO insist about bugs/patches that seems to have been left behind. The development team is mostly made of volunteers; while we do our best to get bugs and important patches in it can happen that we forget about a discussion or miss an email. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKE3VN6dZ+Kt5BchYRAhn1AJwOkGe1Ra3d4tXD2ZMCz2GG3+ZCDQCdEt2d STQRSDQwqD+RizLj9SZG3Y0= =Npk5 -----END PGP SIGNATURE----- From noreply at sourceforge.net Wed May 20 06:24:20 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 04:24:20 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2531905 ] check_mysql does not properly handle passwords in from file. Message-ID: Bugs item #2531905, was opened at 2009-01-23 18:13 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2531905&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: v1.4.14 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ben Timby (btimby) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_mysql does not properly handle passwords in from file. Initial Comment: ----------------- PROBLEM ----------------- The mysql client can use a password from a configuration file. This feature is nice as it keeps the password off of the command line. The check_mysql function does not allow for this. Even though the program informs you via a warning that passing the password on the command line is insecure. It does not allow for the best alternative. According to mysql, the mysql_connect() and mysql_real_connect() both allow a value of NULL to be given for the password. http://dev.mysql.com/doc/refman/5.1/en/mysql-real-connect.html In this case, if a password was read from the option file, it will be used for authentication. The constant "" is used in the case of NO password. Right now, check_mysql, in the validate_arguments() function sets the value of db_pass to "" if it was not provided on the command line. This prevents the password configured in the option file from being used. ----------------- TEST CASE ----------------- # vi $HOME/.my.cnf [client] password=foo # ./check_mysql Access denied for user 'root'@'localhost' (using password: NO) ----------------- PATCH ----------------- The attached patch remedies this. It uses the same method as the mysql client to determine if NULL or "" should be used. If -p is provided, without a value, then "" is used. If -p is omitted, then NULL is used. If -p is provided WITH a password, that password is used. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 00:24 Message: Ok, I looked at it... FYI you didn't update the longopt struct (--password). OTOH I don't see why make -p argument optional; users can specify '-p ""' if they need an empty password - without -p will work just like the mysql client. Therefore I'm only committing the last hunk. Feel free to comment if you think there's a real need for an optional argument for -p. This is fixed in Git. ---------------------------------------------------------------------- Comment By: Ben Timby (btimby) Date: 2009-02-11 08:28 Message: Hopefully that last post clears up your questions, if not here is a short explaination. While the check_mysql plugin always called mysql_options(), it also always set db_pass to "". This caused the password from the file to be ignored as the password was explicitly set to "". To counteract this, I modified the source so that if the -p parameter is omitted, then db_pass is left as NULL. If the -p parameter is provided, but no password is provided, then db_pass is set to "" (like before). If a password is provided as an argument to -p, then that value is copied to db_pass. ---------------------------------------------------------------------- Comment By: Ben Timby (btimby) Date: 2009-02-11 08:22 Message: dermoth, I think you read the patch wrong. The last hunk REMOVES the setting of db_pass to null when it is ''. That was basically the whole problem :-). -- @@ -361,9 +365,6 @@ if (db_host == NULL) db_host = strdup(""); - if (db_pass == NULL) - db_pass = strdup(""); - if (db == NULL) db = strdup(""); -- The difference between '', NULL and is explained at the link I sent in my original bug report: http://dev.mysql.com/doc/refman/5.1/en/mysql-real-connect.html I reproduce the relevant part below... -- For some parameters, it is possible to have the value taken from an option file rather than from an explicit value in the mysql_real_connect() call. To do this, call mysql_options() with the MYSQL_READ_DEFAULT_FILE or MYSQL_READ_DEFAULT_GROUP option before calling mysql_real_connect(). Then, in the mysql_real_connect() call, specify the ?no-value? value for each parameter to be read from an option file: * For passwd, specify a value of NULL. (For the password, a value of the empty string in the mysql_real_connect() call cannot be overridden in an option file, because the empty string indicates explicitly that the MySQL account must have an empty password.) -- ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-01-23 19:03 Message: Thanks for your patch. There's one thing though that I don't understand, since it already sets db_pass to "" when null (last hunk of your patch does it), why do you need to do this using -p? Can you explain the difference between db_pass=NULL, ="" and =, or point me to the right place in the libmysql documentation? You should also be aware that you can also use the extra-opts feature to use a file for the password argument (you need to enable it with configure; I know some packages enable it by default), although I highly suggest to use the latest snapshot until the 1.4.14 release as there have been some important fixes since 1.4.13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2531905&group_id=29880 From noreply at sourceforge.net Wed May 20 06:44:27 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 04:44:27 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2722832 ] awk subst.in/subst script path error Message-ID: Patches item #2722832, was opened at 2009-03-31 00:01 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2722832&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Foster (martinfoster) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: awk subst.in/subst script path error Initial Comment: the plugins-scripts/subst.in awk script's last stage is to replace references to fully qualified commands with whatever is returned from the path subroutine. This can trap the path derived by led() to update the "use lib " statement at the top of scripts. eg: use lib "/usr/lib/nagios/plugins"; gets updated to: use lib "nagios/plugins"; the second isn't valid. I perceive the command line substitution as a cosmetic optimization, there's nothing wrong with calling commands explicitly. They should be properly discovered by the configure stage for a given platform/distribution anyways. patch knocks out the substitution. May be more elegant ways to accomplish the same goal. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 00:44 Message: Thanks! Fixed in Git ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-01 21:02 Message: yup - that appears to work. Change paths for execs first, then change lib path. Original 'use lib ".";' won't catch. See updated nagios-plugins-subst.patch, should also obsolete the debian patch. ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-01 20:48 Message: running the exec path substitution prior to updating INC with the libexec dir appears to accomplish fixing up the script for non-standard paths, while not harming libexec dirs that are under /usr/lib or any other detected executable hosting directory. Will test a bit more & submit updated patch ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-01 20:40 Message: Hi, I'm taking a closer look at this now that I get why it's there. first things first: ./configure --prefix=/usr --exec-prefix=/usr --libexecdir=/usr/lib/nagios/plugins --sysconfdir=/etc/nagios --datadir=/usr/share --with-cgiurl=/nagios/cgi-bin so the plugins are installed to /usr/lib/nagios/plugins I note that this is the same path used by Debian, so I went to check what their package does. They apply a patch that explicitly sets the paths in subst - then removes the substitution wholesale, the led() function, and removes the which() function. see attached as a reference. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-31 07:03 Message: Uhg sorry I might have been too wuick on the trigger. Looks like this is a "automatic configuration" thingy - i.e. instead of detecting commands in configure it does it at the make phase using this script. What it you move that up in the script, so that this substition happens before the lib expansion? A better way of doing it is making an explicit keyword in the paths, and matching the keyword in that block. I.e. substituting "NP_AUTO_PATH/echo" to the result of `which echo` That would require finding all paths modified by running the said part of the script and comparing source plugins with generated files. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-31 06:52 Message: Thanks for reporting this, though your patch is wrong. These substitutions are required for non-standard paths. What configure options did you use, so I can try to reproduce it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2722832&group_id=29880 From noreply at sourceforge.net Wed May 20 07:58:28 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 05:58:28 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1939022 ] SSL/TLS hostname extension support (SNI) Message-ID: Patches item #1939022, was opened at 2008-04-09 19:56 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Enhancement Group: release-1.4.14 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Joe Presbrey (presbrey) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: SSL/TLS hostname extension support (SNI) Initial Comment: Patch against Plugin Version (-V output): SVN trunk Plugin Name: sslutils/check_http Example Plugin Commandline: check_http -H wildcard.scripts.mit.edu -S -C 14 Tested on operating system: debian/4.0 Tested on architecture: i686 Tested with compiler: gcc-4.1.2-20061115 A TLS extension called "Server Name Indication" allows name-based HTTPS virtual hosting. (From Gentoo: http://gentoo-wiki.com/HOWTO_Apache_with_Name_Based_Hosting_and_SSL). This is especially common when serving HTTPS requests with a wildcard certificate (*.domain.tld). This patch adds a call to SSL_set_tlsext_host_name (OpenSSL 0.9.8f and higher) in the certificate check section of sslutils to allow certificate verification of HTTPS virtual-host domains. This patch also corrects the expiration check to escalate to 'critical' when the certificate is expired but for less than 1 day (currently emits 'warning') and displays the time-zone with the expiration time. Joe Presbrey ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 01:58 Message: I finally got around testing this... Works well, though looks like the only use case is for certificate validity checks. Fixed in Git. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-25 20:16 Message: Thanks. I haven't replied earlier but that's exactly why I preferred the first patch. I'll apply it soon. ---------------------------------------------------------------------- Comment By: Guillaume Rousse (guillomovitch) Date: 2009-03-25 17:13 Message: Here is a new version of my own patch, keeping original API intact to reduce impact (sorry, it seems only original reporter can attach files). I just tested it, it works OK. diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/check_http.c nagios-plugins-1.4.13-sni-support/plugins/check_http.c --- nagios-plugins-1.4.13/plugins/check_http.c 2008-09-02 13:26:31.000000000 +0200 +++ nagios-plugins-1.4.13-sni-support/plugins/check_http.c 2009-03-25 21:43:57.000000000 +0100 @@ -773,7 +773,7 @@ die (STATE_CRITICAL, _("HTTP CRITICAL - Unable to open TCP socket\n")); #ifdef HAVE_SSL if (use_ssl == TRUE) { - np_net_ssl_init(sd); + np_net_ssl_init_with_hostname(sd, host_name); if (check_cert == TRUE) { result = np_net_ssl_check_cert(days_till_exp); np_net_ssl_cleanup(); diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/netutils.h nagios-plugins-1.4.13-sni-support/plugins/netutils.h --- nagios-plugins-1.4.13/plugins/netutils.h 2008-01-31 12:45:28.000000000 +0100 +++ nagios-plugins-1.4.13-sni-support/plugins/netutils.h 2009-03-25 21:31:29.000000000 +0100 @@ -95,6 +95,7 @@ #ifdef HAVE_SSL /* maybe this could be merged with the above np_net_connect, via some flags */ int np_net_ssl_init(int sd); +int np_net_ssl_init_with_hostname(int sd, char *host_name); void np_net_ssl_cleanup(); int np_net_ssl_write(const void *buf, int num); int np_net_ssl_read(void *buf, int num); diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/sslutils.c nagios-plugins-1.4.13-sni-support/plugins/sslutils.c --- nagios-plugins-1.4.13/plugins/sslutils.c 2008-01-31 12:27:22.000000000 +0100 +++ nagios-plugins-1.4.13-sni-support/plugins/sslutils.c 2009-03-25 21:31:14.000000000 +0100 @@ -38,7 +38,11 @@ static SSL *s=NULL; static int initialized=0; -int np_net_ssl_init (int sd){ +int np_net_ssl_init (int sd) { + return np_net_ssl_init_with_hostname(sd, NULL); +} + +int np_net_ssl_init_with_hostname (int sd, char *host_name) { if (!initialized) { /* Initialize SSL context */ SSLeay_add_ssl_algorithms (); @@ -51,6 +55,10 @@ return STATE_CRITICAL; } if ((s = SSL_new (c)) != NULL){ +#ifdef SSL_set_tlsext_host_name + if (host_name != NULL) + SSL_set_tlsext_host_name(s, host_name); +#endif SSL_set_fd (s, sd); if (SSL_connect(s) == 1){ return OK; @@ -68,6 +76,9 @@ void np_net_ssl_cleanup (){ if(s){ +#ifdef SSL_set_tlsext_host_name + SSL_set_tlsext_host_name(s, NULL); +#endif SSL_shutdown (s); SSL_free (s); if(c) { ---------------------------------------------------------------------- Comment By: Guillaume Rousse (guillomovitch) Date: 2009-03-24 17:46 Message: You can test with https://sympa.msr-inria.inria.fr and https://www.msr-inria.inria.fr, both of them are different virtual hosts running on the same physical hosts, using different certificates. I didn't found the time to test the patch myself yet. To include the test in an automated test suite, however, you'll need a SNI-enabled web server, and I don't think does it. BTW, your message about "clearing the host on cleanup" sound like you used the original patch supplied. The one I submitted myself avoid this by using a local variable instead of a global one :P ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-21 02:49 Message: Actually I prefer the other method. I stripped the timezone stuff, cleared the host on cleanup and added the call to check_http to set the hostname only if needed. Does it works for you? It would be really kind if you could send me an url to test with. Thanks. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-19 22:06 Message: Sorry, it's not about old openssl (I assumed that without really reading the error message). I realized it yesterday after sending the comment, though it was a coincidence: I was reading about timezone stuff and read somewhere that tm.tm_zone is a gnu extension. I can commit it without the timezone stuff though (isn't the timezone always GMT?? I couldn't find any good documentation on the OpenSSL functions used in sslutil...). Please attach it as a file though. What you paste in comments it totally unusable for patch. Also, do you have anything to test with? Would there be any way to integrate this in the unit tests too (they use HTTP::Daemon::SSL for emulating a web server) ? Thanks ---------------------------------------------------------------------- Comment By: Guillaume Rousse (guillomovitch) Date: 2009-03-19 19:06 Message: diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/check_http.c nagios-plugins-1.4.13-sni-support/plugins/check_http.c --- nagios-plugins-1.4.13/plugins/check_http.c 2008-09-02 13:26:31.000000000 +0200 +++ nagios-plugins-1.4.13-sni-support/plugins/check_http.c 2009-03-19 23:54:12.000000000 +0100 @@ -773,7 +773,7 @@ die (STATE_CRITICAL, _("HTTP CRITICAL - Unable to open TCP socket\n")); #ifdef HAVE_SSL if (use_ssl == TRUE) { - np_net_ssl_init(sd); + np_net_ssl_init(sd, host_name); if (check_cert == TRUE) { result = np_net_ssl_check_cert(days_till_exp); np_net_ssl_cleanup(); diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/check_smtp.c nagios-plugins-1.4.13-sni-support/plugins/check_smtp.c --- nagios-plugins-1.4.13/plugins/check_smtp.c 2008-05-07 12:02:42.000000000 +0200 +++ nagios-plugins-1.4.13-sni-support/plugins/check_smtp.c 2009-03-19 23:55:38.000000000 +0100 @@ -236,7 +236,7 @@ smtp_quit(); return STATE_UNKNOWN; } - result = np_net_ssl_init(sd); + result = np_net_ssl_init(sd, NULL); if(result != STATE_OK) { printf (_("CRITICAL - Cannot create SSL context.\n")); np_net_ssl_cleanup(); diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/check_tcp.c nagios-plugins-1.4.13-sni-support/plugins/check_tcp.c --- nagios-plugins-1.4.13/plugins/check_tcp.c 2008-05-07 12:02:42.000000000 +0200 +++ nagios-plugins-1.4.13-sni-support/plugins/check_tcp.c 2009-03-19 23:55:21.000000000 +0100 @@ -236,7 +236,7 @@ #ifdef HAVE_SSL if (flags & FLAG_SSL){ - result = np_net_ssl_init(sd); + result = np_net_ssl_init(sd, NULL); if (result == STATE_OK && check_cert == TRUE) { result = np_net_ssl_check_cert(days_till_exp); if(result != STATE_OK) { diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/netutils.h nagios-plugins-1.4.13-sni-support/plugins/netutils.h --- nagios-plugins-1.4.13/plugins/netutils.h 2008-01-31 12:45:28.000000000 +0100 +++ nagios-plugins-1.4.13-sni-support/plugins/netutils.h 2009-03-19 23:57:45.000000000 +0100 @@ -94,7 +94,7 @@ /* SSL-Related functionality */ #ifdef HAVE_SSL /* maybe this could be merged with the above np_net_connect, via some flags */ -int np_net_ssl_init(int sd); +int np_net_ssl_init(int sd, char *host_name); void np_net_ssl_cleanup(); int np_net_ssl_write(const void *buf, int num); int np_net_ssl_read(void *buf, int num); diff -Naur --exclude '*~' nagios-plugins-1.4.13/plugins/sslutils.c nagios-plugins-1.4.13-sni-support/plugins/sslutils.c --- nagios-plugins-1.4.13/plugins/sslutils.c 2008-01-31 12:27:22.000000000 +0100 +++ nagios-plugins-1.4.13-sni-support/plugins/sslutils.c 2009-03-20 00:01:58.000000000 +0100 @@ -38,7 +38,7 @@ static SSL *s=NULL; static int initialized=0; -int np_net_ssl_init (int sd){ +int np_net_ssl_init (int sd, char *host_name){ if (!initialized) { /* Initialize SSL context */ SSLeay_add_ssl_algorithms (); @@ -51,6 +51,10 @@ return STATE_CRITICAL; } if ((s = SSL_new (c)) != NULL){ +#ifdef SSL_set_tlsext_host_name + if (host_name != NULL) + SSL_set_tlsext_host_name(s, host_name); +#endif SSL_set_fd (s, sd); if (SSL_connect(s) == 1){ return OK; @@ -68,6 +72,9 @@ void np_net_ssl_cleanup (){ if(s){ +#ifdef SSL_set_tlsext_host_name + SSL_set_tlsext_host_name(s, NULL); +#endif SSL_shutdown (s); SSL_free (s); if(c) { ---------------------------------------------------------------------- Comment By: Guillaume Rousse (guillomovitch) Date: 2009-03-19 19:03 Message: Here is a slightly different version, changing np_net_ssl_init() prototype to pass host name, rather than using a global variable. This adress your question 1). However, I don't understand the issue with old openssl versions, the patch already does use #idfef block to only use this function if available ? ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-19 01:16 Message: Moreover this seems to break old OpsnSSL's (at least on my Solaris tinderbox) I rolled it back (except the timestamp fix). I will apply an updated version if you add the proper ifdef's to keep backwards compatibility. Thanks ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-17 04:02 Message: Thanks for your report I have two questions: 1. This patch does not alter check_http to use the new function to set host name. Did you expect us to make this change, or do you have a complete patch around? 2. Regarding printing the timezone, AFAIK is can be longer than three characters, unless if certificates have a strict standars. This command will list all timezones in /usr/share/zoneinfo: $ find /usr/share/zoneinfo/ -type f -exec zdump {} \;|sed 's/^.* 2009 \(.*\)$/\1/'|sort|uniq If you add "wc -L" this gives you a max length of 6 characters. The current code will apparently cut it to three characters. ---------------------------------------------------------------------- Comment By: Guillaume Rousse (guillomovitch) Date: 2009-03-05 06:01 Message: This is really useful, I'd like to have it merged too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1939022&group_id=29880 From noreply at sourceforge.net Wed May 20 08:19:48 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 06:19:48 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2550224 ] check_ntp: wrong output for host with both A and AAAA record Message-ID: Bugs item #2550224, was opened at 2009-01-30 15:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp: wrong output for host with both A and AAAA record Initial Comment: The following Bugreport we got against our debian package: Please consider this: $ host -t any lipton.aai.niif.hu lipton.aai.niif.hu A 193.225.14.195 lipton.aai.niif.hu AAAA 2001:738:0:701:80:C1E1:EC3:0 $ /usr/lib/nagios/plugins/check_ntp -H lipton.aai.niif.hu -v sending request to peer 0 sending request to peer 1 response from peer 1: offset -2.680183388e-05 sending request to peer 1 response from peer 1: offset -1.871510176e-05 sending request to peer 1 response from peer 1: offset 3.834080417e-06 sending request to peer 1 response from peer 1: offset -3.614556044e-05 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 overall average offset: nan NTP OK: Offset nan secs|offset=nan This isn't serious, since one uses IP addresses anyway, but still a bug. Sure the client doesn't respond to IPv6 packets, but its offset isn't NaN. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509589 ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:19 Message: IPv6 "DO" work if your OS supports IPv6 and is configured/connected properly (I just testes it on a dual v4/v6 server). In the other case you can use the -4 switch to force IPv4 (tested on a system which isn't IPv6-capable) IPv6: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v sending request to peer 0 sending request to peer 1 response from peer 0: offset 0.0126850605 sending request to peer 0 response from peer 1: offset 0.01730811596 sending request to peer 1 response from peer 0: offset 0.0123462677 sending request to peer 0 re-sending request to peer 0 response from peer 1: offset 0.01795887947 sending request to peer 1 response from peer 0: offset 0.01281118393 sending request to peer 0 response from peer 0: offset 0.01216220856 response from peer 1: offset 0.01737487316 sending request to peer 1 response from peer 1: offset 0.01733827591 overall average offset: 0.0126850605 NTP OK: Offset 0.0126850605 secs|offset=0.012685s;60.000000;120.000000; $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.02037644386 sending request to peer 0 response from peer 0: offset 0.02015924454 sending request to peer 0 response from peer 0: offset 0.02035975456 sending request to peer 0 re-sending request to peer 0 response from peer 0: offset 0.02017998695 overall average offset: 0.02037644386 NTP OK: Offset 0.02037644386 secs|offset=0.020376s;60.000000;120.000000; $ IPv4: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v Address family not supported by protocol can not create new socket$ $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.06370124064 sending request to peer 0 response from peer 0: offset 0.06318281766 sending request to peer 0 response from peer 0: offset 0.06347788981 sending request to peer 0 response from peer 0: offset 0.06340960733 overall average offset: 0.06370124064 NTP OK: Offset 0.06370124064 secs|offset=0.063701s;60.000000;120.000000; $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 From noreply at sourceforge.net Wed May 20 08:27:24 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 06:27:24 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2550224 ] check_ntp: wrong output for host with both A and AAAA record Message-ID: Bugs item #2550224, was opened at 2009-01-30 15:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp: wrong output for host with both A and AAAA record Initial Comment: The following Bugreport we got against our debian package: Please consider this: $ host -t any lipton.aai.niif.hu lipton.aai.niif.hu A 193.225.14.195 lipton.aai.niif.hu AAAA 2001:738:0:701:80:C1E1:EC3:0 $ /usr/lib/nagios/plugins/check_ntp -H lipton.aai.niif.hu -v sending request to peer 0 sending request to peer 1 response from peer 1: offset -2.680183388e-05 sending request to peer 1 response from peer 1: offset -1.871510176e-05 sending request to peer 1 response from peer 1: offset 3.834080417e-06 sending request to peer 1 response from peer 1: offset -3.614556044e-05 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 overall average offset: nan NTP OK: Offset nan secs|offset=nan This isn't serious, since one uses IP addresses anyway, but still a bug. Sure the client doesn't respond to IPv6 packets, but its offset isn't NaN. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509589 ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:27 Message: Sorry - I just realized it's about the offset calculation... ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:19 Message: IPv6 "DO" work if your OS supports IPv6 and is configured/connected properly (I just testes it on a dual v4/v6 server). In the other case you can use the -4 switch to force IPv4 (tested on a system which isn't IPv6-capable) IPv6: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v sending request to peer 0 sending request to peer 1 response from peer 0: offset 0.0126850605 sending request to peer 0 response from peer 1: offset 0.01730811596 sending request to peer 1 response from peer 0: offset 0.0123462677 sending request to peer 0 re-sending request to peer 0 response from peer 1: offset 0.01795887947 sending request to peer 1 response from peer 0: offset 0.01281118393 sending request to peer 0 response from peer 0: offset 0.01216220856 response from peer 1: offset 0.01737487316 sending request to peer 1 response from peer 1: offset 0.01733827591 overall average offset: 0.0126850605 NTP OK: Offset 0.0126850605 secs|offset=0.012685s;60.000000;120.000000; $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.02037644386 sending request to peer 0 response from peer 0: offset 0.02015924454 sending request to peer 0 response from peer 0: offset 0.02035975456 sending request to peer 0 re-sending request to peer 0 response from peer 0: offset 0.02017998695 overall average offset: 0.02037644386 NTP OK: Offset 0.02037644386 secs|offset=0.020376s;60.000000;120.000000; $ IPv4: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v Address family not supported by protocol can not create new socket$ $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.06370124064 sending request to peer 0 response from peer 0: offset 0.06318281766 sending request to peer 0 response from peer 0: offset 0.06347788981 sending request to peer 0 response from peer 0: offset 0.06340960733 overall average offset: 0.06370124064 NTP OK: Offset 0.06370124064 secs|offset=0.063701s;60.000000;120.000000; $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 From noreply at sourceforge.net Wed May 20 08:35:57 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 20 May 2009 06:35:57 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2550224 ] check_ntp: wrong output for host with both A and AAAA record Message-ID: Bugs item #2550224, was opened at 2009-01-30 15:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_ntp: wrong output for host with both A and AAAA record Initial Comment: The following Bugreport we got against our debian package: Please consider this: $ host -t any lipton.aai.niif.hu lipton.aai.niif.hu A 193.225.14.195 lipton.aai.niif.hu AAAA 2001:738:0:701:80:C1E1:EC3:0 $ /usr/lib/nagios/plugins/check_ntp -H lipton.aai.niif.hu -v sending request to peer 0 sending request to peer 1 response from peer 1: offset -2.680183388e-05 sending request to peer 1 response from peer 1: offset -1.871510176e-05 sending request to peer 1 response from peer 1: offset 3.834080417e-06 sending request to peer 1 response from peer 1: offset -3.614556044e-05 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 overall average offset: nan NTP OK: Offset nan secs|offset=nan This isn't serious, since one uses IP addresses anyway, but still a bug. Sure the client doesn't respond to IPv6 packets, but its offset isn't NaN. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509589 ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:35 Message: Works for me - I tried blocking both address alternatively so that I could see results with either peer0 or peer1 unresponsive. what check_ntp version are you using? ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:27 Message: Sorry - I just realized it's about the offset calculation... ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:19 Message: IPv6 "DO" work if your OS supports IPv6 and is configured/connected properly (I just testes it on a dual v4/v6 server). In the other case you can use the -4 switch to force IPv4 (tested on a system which isn't IPv6-capable) IPv6: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v sending request to peer 0 sending request to peer 1 response from peer 0: offset 0.0126850605 sending request to peer 0 response from peer 1: offset 0.01730811596 sending request to peer 1 response from peer 0: offset 0.0123462677 sending request to peer 0 re-sending request to peer 0 response from peer 1: offset 0.01795887947 sending request to peer 1 response from peer 0: offset 0.01281118393 sending request to peer 0 response from peer 0: offset 0.01216220856 response from peer 1: offset 0.01737487316 sending request to peer 1 response from peer 1: offset 0.01733827591 overall average offset: 0.0126850605 NTP OK: Offset 0.0126850605 secs|offset=0.012685s;60.000000;120.000000; $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.02037644386 sending request to peer 0 response from peer 0: offset 0.02015924454 sending request to peer 0 response from peer 0: offset 0.02035975456 sending request to peer 0 re-sending request to peer 0 response from peer 0: offset 0.02017998695 overall average offset: 0.02037644386 NTP OK: Offset 0.02037644386 secs|offset=0.020376s;60.000000;120.000000; $ IPv4: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v Address family not supported by protocol can not create new socket$ $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.06370124064 sending request to peer 0 response from peer 0: offset 0.06318281766 sending request to peer 0 response from peer 0: offset 0.06347788981 sending request to peer 0 response from peer 0: offset 0.06340960733 overall average offset: 0.06370124064 NTP OK: Offset 0.06370124064 secs|offset=0.063701s;60.000000;120.000000; $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 From ton.voon at opsera.com Wed May 20 09:54:02 2009 From: ton.voon at opsera.com (Ton Voon) Date: Wed, 20 May 2009 08:54:02 +0100 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <2274b9c30904290613y609b5c4dg732d597e0ff3803c@mail.gmail.com> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> <2274b9c30904280823y5f0d1253mcf75abd646daca94@mail.gmail.com> <87CDCA11-7ABF-414A-95C9-C27E2AEFECA7@opsera.com> <2274b9c30904290613y609b5c4dg732d597e0ff3803c@mail.gmail.com> Message-ID: Updated, thanks. http://nagiosplugins.org/faq/compile/pst3 On 29 Apr 2009, at 14:13, Kyle O'Donnell wrote: > I've used this for SunOS 5.8 5.9 and 5.10 > > --with-ps-command="/usr/bin/ps -eo 's uid pid ppid vsz rss pcpu etime > comm args'" \ > --with-ps-format="%s %d %d %d %d %d %f %s %s %n" \ > --with-ps-cols=10 \ > --with-ps- > varlist > = > "procstat > ,&procuid > ,&procpid > ,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos" > > > On 4/28/09, Ton Voon wrote: >> >> On 28 Apr 2009, at 16:23, Kyle O'Donnell wrote: >> >>> What is broken with check_procs on solaris? I have found >>> formulating >>> the ps command works better than using the native nagios-plugins >>> methods. I can provide you with working compile options. >> >> This question comes up a lot so I've put a FAQ entry up: >> http://nagiosplugins.org/faq/compile/pst3 >> >> I'm happy to update the entry with your compile options if you let me >> know what they are. >> >> I think the 64 bit issue is due to a Solaris system using Sun's cc >> rather than gcc. This is a good example of a tinderbox build server >> being helpful here: http://nagiosplugins.org/tinderbox. Anyone that >> can offer a Solaris server with Sun's cc will mean we can catch these >> issues earlier. >> >> My thoughts about check_procs is that I want to be able to run some >> tests with actual ps outputs from running systems. I need to spend >> some time on this. >> >> Ton >> >> >> ------------------------------------------------------------------------------ >> Register Now & Save for Velocity, the Web Performance & Operations >> Conference from O'Reilly Media. Velocity features a full day of >> expert-led, hands-on workshops and two days of sessions from industry >> leaders in dedicated Performance & Operations tracks. Use code >> vel09scf >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >> _______________________________________________________ >> Nagios Plugin Development Mailing List >> Nagiosplug-devel at lists.sourceforge.net >> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel >> ::: Please include plugins version (-v) and OS when reporting any >> issue. >> ::: Messages without supporting info will risk being sent to /dev/ >> null >> > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code > vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________________ > Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net > Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel > ::: Please include plugins version (-v) and OS when reporting any > issue. > ::: Messages without supporting info will risk being sent to /dev/null Ton Voon Product Architect Opsera Limited | Unit 69 Suttons Business Park Reading | Berkshire | RG6 1AZ | UK Phone: +44 (0) 845 057 7887 Mobile: +44 (0) 7931 365796 Skype: tonvoon Email: ton.voon at opsera.com www.opsera.com This e-mail is confidential, intended only for the named recipient(s) above and may contain information that is privileged and confidential. If you receive this message in error, or are not the named recipient(s), please notify the sender at the phone number above, do not copy this message, do not disclose its contents to anyone, and delete this e-mail message from your computer. Although Opsera routinely screens for viruses, addressees should scan this e-mail and any attachments for viruses. Opsera makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Opsera Limited is registered in the UK under Company Number 5396532. Our registered office is Gorse View, Horsell Rise, Woking, Surrey, GU21 4RB. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 749 bytes Desc: not available URL: From holger at CIS.FU-Berlin.DE Fri May 22 02:22:58 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 22 May 2009 02:22:58 +0200 Subject: [Nagiosplug-devel] Git commit e-mails Message-ID: <20090522002258.GE41927050@CIS.FU-Berlin.DE> The commit e-mails posted on are currently still generated via the Subversion mirror of our Git repository. Since we don't want to rely on the Subversion mirror forever, I prepared a setup which would send out such e-mails directly from Git, instead. These e-mails would look different than before, though. Only one e-mail per push would be generated, not one e-mail per commit. More precisely: every (e.g., 5) minutes, a script would generate one e-mail for each branch or tag which points to a different object than it did minutes ago, or which was created or deleted during that interval. This e-mail would report all changes for the given branch or tag. Usually, it would list the log message and the author/committer of any new commits, as well as a single diff which shows the effect of all listed commits (up to a size of currently 300 KiB). Here's an example e-mail which reports two commits on the master branch: ftp://ftp.in-berlin.de/pub/users/weiss/nagios/plugins/commit-mails/example.txt Please let me know if you have any suggestions for improvements. In particular, I'm unsure about the case where multiple commits are reported in a single e-mail (as in this example). While I personally like seeing all log messages at the top of the e-mail followed by a single diff, I guess others might prefer separate diffs for each commit, so that the code changes are matched with the log messages. That is: * Log message of commit A * Diff A^..A * Log message of commit B * Diff B^..B * Log message of commit C * Diff C^..C instead of: * Log message of commit A * Log message of commit B * Log message of commit C * Diff A^..C Both options have pros and cons, so let me know what you'd prefer. Or, as another alternative, should we simply continue to send a separate e-mail for each commit? In case you're interested, here's is the script which would do the job (via Cron) by updating a mirror of the Git repository, remembering which refs have changed, and then executing a modified version? of the post-receive-email script? provided with Git: ftp://ftp.in-berlin.de/pub/users/weiss/nagios/plugins/commit-mails/mirror.sh Holger ? ftp://ftp.in-berlin.de/pub/users/weiss/nagios/plugins/commit-mails/post-receive-email.diff ? http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/hooks/post-receive-email From ton.voon at opsera.com Fri May 22 11:27:55 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 22 May 2009 10:27:55 +0100 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <20090522002258.GE41927050@CIS.FU-Berlin.DE> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> Message-ID: On 22 May 2009, at 01:22, Holger Weiss wrote: > Both options have pros and cons, so let me know what you'd prefer. > Or, > as another alternative, should we simply continue to send a separate > e-mail for each commit? I would personally prefer one email per commit as it is easier to glance at what is happening and just read the subject to get an idea of the changes and the importance. The 5 minute delay is not a big deal. A quick look at the nagiosplug-checkins list (which has 181 members) shows out of 38 members, 4 wanted a digest. So 90% of the members to this list prefer individual emails. If git sends out individual emails, then the list digest would act as the summary view. However, I'd cede to the majority if a summarised view is preferred. Ton From ae at op5.se Fri May 22 11:45:29 2009 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 May 2009 11:45:29 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> Message-ID: <4A167439.6000901@op5.se> Ton Voon wrote: > On 22 May 2009, at 01:22, Holger Weiss wrote: > >> Both options have pros and cons, so let me know what you'd prefer. >> Or, >> as another alternative, should we simply continue to send a separate >> e-mail for each commit? > > I would personally prefer one email per commit as it is easier to > glance at what is happening and just read the subject to get an idea > of the changes and the importance. The 5 minute delay is not a big deal. > > A quick look at the nagiosplug-checkins list (which has 181 members) > shows out of 38 members, 4 wanted a digest. So 90% of the members to > this list prefer individual emails. If git sends out individual > emails, then the list digest would act as the summary view. > > However, I'd cede to the majority if a summarised view is preferred. > Personally I like to get things as one email, and getting the diff in the email is *usually* not interesting (assuming proper commit messages are always written). A nice mail-format would be something like this: git shortlog -ns old..new; git shortlog old..new; git log old..new Which would look something like this: ###### 14 Ton Voon 4 Holger Weiss Ton Voon patchsubject1 patchsubject2 ... patchsubject14 Holger Weiss patchsubject1 ... patchsubject4 (git log output) ####### I personally prefer that since it's quite common to do multiple commits to implement a single feature, and this way one gets all the commits in one go. Ofcourse, it would be easier if you could just use the post-receive hook, since that would prevent mingling of several patch-series, but with a 5 min interval I suppose that'll only happen very rarely anyway. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From dermoth at aei.ca Fri May 22 14:10:28 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 22 May 2009 08:10:28 -0400 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A167439.6000901@op5.se> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> Message-ID: <4A169634.60706@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/05/09 05:45 AM, Andreas Ericsson wrote: > Ton Voon wrote: >> On 22 May 2009, at 01:22, Holger Weiss wrote: >> >>> Both options have pros and cons, so let me know what you'd prefer. >>> Or, >>> as another alternative, should we simply continue to send a separate >>> e-mail for each commit? >> I would personally prefer one email per commit as it is easier to >> glance at what is happening and just read the subject to get an idea >> of the changes and the importance. The 5 minute delay is not a big deal. >> >> A quick look at the nagiosplug-checkins list (which has 181 members) >> shows out of 38 members, 4 wanted a digest. So 90% of the members to >> this list prefer individual emails. If git sends out individual >> emails, then the list digest would act as the summary view. >> >> However, I'd cede to the majority if a summarised view is preferred. >> > > Personally I like to get things as one email, and getting the diff in > the email is *usually* not interesting (assuming proper commit messages > are always written). > > A nice mail-format would be something like this: > git shortlog -ns old..new; git shortlog old..new; git log old..new > > Which would look something like this: > > ###### > 14 Ton Voon > 4 Holger Weiss > > Ton Voon > patchsubject1 > patchsubject2 > ... > patchsubject14 > > Holger Weiss > patchsubject1 > ... > patchsubject4 > > (git log output) > ####### > > I personally prefer that since it's quite common to do multiple commits to > implement a single feature, and this way one gets all the commits in one go. > Ofcourse, it would be easier if you could just use the post-receive hook, > since that would prevent mingling of several patch-series, but with a 5 min > interval I suppose that'll only happen very rarely anyway. I agree... Since the commit subjects currently do not show anything useful we have to look inside emails already. A top summary would be nice, or anything that can reduce the email size (i.e. removing the diffs) so we'd be able to quickly see what have been committed. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKFpY06dZ+Kt5BchYRArdvAJ9NVklhaWid/iOlkuTRLY+fyzVqkgCfXF63 wzvUGPFPrFj8arR2D4LUzZQ= =x0bZ -----END PGP SIGNATURE----- From ton.voon at opsera.com Fri May 22 14:24:21 2009 From: ton.voon at opsera.com (Ton Voon) Date: Fri, 22 May 2009 13:24:21 +0100 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A169634.60706@aei.ca> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> <4A169634.60706@aei.ca> Message-ID: <493887BE-9637-4F42-ABE0-D0A9912E9F75@opsera.com> On 22 May 2009, at 13:10, Thomas Guyot-Sionnest wrote: > I agree... Since the commit subjects currently do not show anything > useful we have to look inside emails already. A top summary would be > nice, or anything that can reduce the email size (i.e. removing the > diffs) so we'd be able to quickly see what have been committed. I'm up for a decent subject line. I would insist on keeping the diffs in the email. I can then search my entire mail folder for phrases to see if anything has changed recently. But if this functionality is in git, then I guess the diffs can be removed. Pointers and an update to http://nagiosplugins.org/git would be great. Ton From ae at op5.se Fri May 22 15:18:27 2009 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 May 2009 15:18:27 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <493887BE-9637-4F42-ABE0-D0A9912E9F75@opsera.com> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> <4A169634.60706@aei.ca> <493887BE-9637-4F42-ABE0-D0A9912E9F75@opsera.com> Message-ID: <4A16A623.7030509@op5.se> Ton Voon wrote: > On 22 May 2009, at 13:10, Thomas Guyot-Sionnest wrote: > >> I agree... Since the commit subjects currently do not show anything >> useful we have to look inside emails already. A top summary would be >> nice, or anything that can reduce the email size (i.e. removing the >> diffs) so we'd be able to quickly see what have been committed. > > I'm up for a decent subject line. > > I would insist on keeping the diffs in the email. I can then search my > entire mail folder for phrases to see if anything has changed > recently. But if this functionality is in git, then I guess the diffs > can be removed. git log -p --grep="some phrase in the commit message" git show :/"Start of commit subject" git log -p -S"a sequence of code you're interested in" The missing space between -S and the string is, unfortunately, not a typo; It's a truly ancient feature of git that nearly all UI apps now rely on, so it can't be changed easily without breaking those apps. Note that the pickaxe option (S) will show you patches where the diff between a commit and its parent(s) introduces or removes at least one instance of the piece of code you gave as parameter to 'S'. Code movements are not shown with this option. For that I'd suggest using git log -p and just searching within less for the string you're interested in. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From jd at op5.com Fri May 22 14:21:06 2009 From: jd at op5.com (Johannes Dagemark) Date: Fri, 22 May 2009 14:21:06 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A167439.6000901@op5.se> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> Message-ID: <4A1698B2.9060604@op5.com> Andreas Ericsson wrote: > Personally I like to get things as one email, and getting the diff in > the email is *usually* not interesting (assuming proper commit messages > are always written). > > how about a proper link to the commit or commitdiff on http://repo.or.cz/w/nagiosplugins.git instead of including the diff in the email, that way if you are interested on reading up on the patch its just a click away Best regards Johannes Dagemark From ae at op5.se Fri May 22 15:42:53 2009 From: ae at op5.se (Andreas Ericsson) Date: Fri, 22 May 2009 15:42:53 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A1698B2.9060604@op5.com> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> <4A1698B2.9060604@op5.com> Message-ID: <4A16ABDD.7060907@op5.se> Johannes Dagemark wrote: > Andreas Ericsson wrote: >> Personally I like to get things as one email, and getting the diff in >> the email is *usually* not interesting (assuming proper commit messages >> are always written). >> >> > how about a proper link to the commit or commitdiff on > http://repo.or.cz/w/nagiosplugins.git instead of including the diff in > the email, that way if you are interested on reading up on the patch its > just a click away > I like the simplicity of it, but I intensely dislike the fact that this makes one repository far more "central" than any other. Also, the URL's to view certain patches are quite clunky to work with, and anyone who's actually interested in the patches could just as well run git log -p $old..$new from within their git repository (why be interested in patches if you don't want the code?). Printing that little command above in the email might be a good idea though, as it lets you just run git fetch && $copy_pasted_command to see absolutely everything. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Register now for Nordic Meet on Nagios, June 3-4 in Stockholm http://nordicmeetonnagios.op5.org/ Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. From holger at CIS.FU-Berlin.DE Fri May 22 19:03:12 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 22 May 2009 19:03:12 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A167439.6000901@op5.se> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> Message-ID: <20090522170312.GF41927050@CIS.FU-Berlin.DE> * Andreas Ericsson [2009-05-22 11:45]: > Ton Voon wrote: > > I would personally prefer one email per commit as it is easier to > > glance at what is happening and just read the subject to get an idea > > of the changes and the importance. The 5 minute delay is not a big deal. > > > > A quick look at the nagiosplug-checkins list (which has 181 members) > > shows out of 38 members, 4 wanted a digest. So 90% of the members to > > this list prefer individual emails. If git sends out individual > > emails, then the list digest would act as the summary view. > > > > However, I'd cede to the majority if a summarised view is preferred. > > Personally I like to get things as one email, and getting the diff in > the email is *usually* not interesting (assuming proper commit messages > are always written). I guess my preference is somewhere in between. Sometimes I'm interested in how a change is implemented, sometimes I'm not. Sometimes I'm just enough interested take a quick peek at the patch in the e-mail, but not interested enough to fire up Git :-) Therefore, I like having the diff appended to the end of the e-mail, where it doesn't hurt. > A nice mail-format would be something like this: > git shortlog -ns old..new; git shortlog old..new; git log old..new > > [...] > > I personally prefer that since it's quite common to do multiple commits to > implement a single feature, and this way one gets all the commits in one go. Agreed. That's why "one e-mail per push" is different from a digest, which simply stuffs any commits which happened during a given time frame into a single e-mail, no matter whether or not they're related. That said, we don't really commit large patch serieses that often and I guess it's unlikely that this will change dramatically in the foreseeable future, so we'd probably gain less by summarizing multiple commits within a single e-mail than larger projects do. Therefore, I'd be fine with one e-mail per commit, too. > Ofcourse, it would be easier if you could just use the post-receive hook, Yap. Holger From PsychoTrahe at gmx.de Fri May 22 19:14:15 2009 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Fri, 22 May 2009 19:14:15 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <493887BE-9637-4F42-ABE0-D0A9912E9F75@opsera.com> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> <4A169634.60706@aei.ca> <493887BE-9637-4F42-ABE0-D0A9912E9F75@opsera.com> Message-ID: <1243012455.22338.37.camel@pc.site> Am Freitag, den 22.05.2009, 13:24 +0100 schrieb Ton Voon: > I would insist on keeping the diffs in the email. Maybe the use cases differ. Some might want to get notified about checkins and check them using git. Some others might like to skim over checkins and, if needed, do further analysis using git. I personally like the old way (having the diffsin the email) as I usually have a short look at the checkins when I'm in the office doing some other things. If the commit message sounds interesting, then I can have a short look at the diffs without having to switch to a console, navigate to a local git repo,... It's just a scroll away. I'd personally prefer having one mail with a meaningful subject for each commit. That's because you never know which commits are actually combined in the mail body. Maybe they cover the same issue, maybe not. Users would have to inspect the message rather than checking the subject line to see what's going on in the tree. But I'd cede to the majority also Matthias From holger at CIS.FU-Berlin.DE Fri May 22 19:22:36 2009 From: holger at CIS.FU-Berlin.DE (Holger Weiss) Date: Fri, 22 May 2009 19:22:36 +0200 Subject: [Nagiosplug-devel] Git commit e-mails In-Reply-To: <4A169634.60706@aei.ca> References: <20090522002258.GE41927050@CIS.FU-Berlin.DE> <4A167439.6000901@op5.se> <4A169634.60706@aei.ca> Message-ID: <20090522172236.GG41927050@CIS.FU-Berlin.DE> * Thomas Guyot-Sionnest [2009-05-22 08:10]: > Since the commit subjects currently do not show anything useful we > have to look inside emails already. True. However, if we'd generate a separate e-mail for each commit, we could use the first line of the commit message as the subject, for example. There's a "git-notify" script which does just that: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-6ce199bb0961e1a9bd530ec055042e0aa7a25fb4 It splits a push into commits and then generates e-mails which look similar to the e-mails we currently get. Holger [who could live with any of the suggested options] From noreply at sourceforge.net Fri May 22 19:40:15 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 17:40:15 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985246 ] ssh_disk dont interpret -C with single quotes correct Message-ID: Bugs item #1985246, was opened at 2008-06-05 11:16 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing >Group: v1.4.14 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: ssh_disk dont interpret -C with single quotes correct Initial Comment: The following Bugreport we got against our debian package: By default, the ssh_disk configuration has the following command line... /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$' This creates the following error when trying to check a remote system... [1179694002] SERVICE ALERT: tagboard;/dev/hda1 Free Space;UNKNOWN;SOFT;1;Could not open pipe: /usr/bin/ssh 172.24.32.1 '/usr/lib/nagios/plugins/check_disk -w 5% -c 3% -p "/dev/hda1"' Changing the single quotes to be double quotes in the config resolves this problem. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425312 Thanks and kind regards, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-17 05:55 Message: Thanks, wpreston, for the patch. It looks very nice, though I have some questions/comments about it... By going over ssh the remote end normally spawns a shell when it feels it's required. Are there any possible interaction with your patch and fancy/quirky check commands to work around them? Backwards-compatibility is an important issue there, though I guess it wouldn't be too hard to allow it with a conditional switch if required. It would be very nice if you could include code comments about the new functions. It seems like there are bug fixes along with new features (i.e. you seem to alter functions/unrelated parts of the code). It would be nice if you could make separate patches for them and apply the new features on top of the fixed code. Any reason for strcpy'ing the arguments when you can simply pass pointers around? This avoids the need to free them afterwards. I wouldn't modify the process_arguments function, as we may one day write a C library that will take care of thet (among other). Any reason **newargv and **opts are not global like the rest? Somewhere in np_runcmd_open_argv you have this, and I can't see these variables anywhere else in the patch...: + int master,slave; Why not using MAXARGS for detecting a full array? C++ comments (//) break on some architectures (just FYI) Does it apply on latest development code? Thanks ---------------------------------------------------------------------- Comment By: Will Preston (wpreston) Date: 2009-03-13 16:26 Message: There's a patch 2268675 (fix for quoting in check_by_ssh) in the queue which would fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 From noreply at sourceforge.net Fri May 22 19:40:47 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 17:40:47 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2632995 ] check_procs fails on Solaris Message-ID: Bugs item #2632995, was opened at 2009-02-24 10:08 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2632995&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: v1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner (forsbring) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_procs fails on Solaris Initial Comment: Hi, check_procs v2019 (nagios-plugins 1.4.13) exits with "Unable to read output" on most of our Solaris8 and Solaris 10 servers (I do not have access to any Solaris9 servers). 1.4.11 works just fine. I've attached the truss output. - Werner ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-17 08:42 Message: Sorry for the late reply... According pst3 header comment (I have no idea how it compares to "ps" though): * This executable works by reading process address structures, so needs * to be executed as root Regarding 64bits, I might be wrong but IIRC that's needed to get data about 64bit processes. Maybe that's somehow related to the root requisite as well, since it's probably a different way than "ps". I will have to look for a way to support cleanly both compilers, probably using autoconf. I'll look further into this when I can. Thanks ---------------------------------------------------------------------- Comment By: Werner (forsbring) Date: 2009-03-12 14:23 Message: Nope, not trying to run from source repository. But after looking into the buildlogs I guess I found the problem. You assume we use gcc, and the compiler option -m64 is used for pst3, which is not working with cc from older SunStudio. Why do pst3 have to be setuid root when /usr/bin/ps and /usr/ucp/ps don't? And regarding the 64-bit requirement, why? Almost no other binaries on Solaris is 64-bit. The pst3-thing seems like a ugly hack to me, sorry. :) - Werner ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-24 10:29 Message: Thanks for the debug output. Nagios-plugins now use pst3 to get the process list and this program needs to be installed and setuid root (I think old versions of nagios-plugins used it too, so you may have it already on some servers). It looks like you're trying to run from the source repository. Be sure to install the plugins, or at least hand-install pst3 (in plugins-root/ directory, don't forget to setuit root). If you still have issues I'll be able to help you is you can send the truss output again with the option to follow forks (-f). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2632995&group_id=29880 From noreply at sourceforge.net Fri May 22 19:41:27 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 17:41:27 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2722832 ] awk subst.in/subst script path error Message-ID: Patches item #2722832, was opened at 2009-03-31 06:01 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2722832&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix >Group: release-1.4.14 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Foster (martinfoster) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: awk subst.in/subst script path error Initial Comment: the plugins-scripts/subst.in awk script's last stage is to replace references to fully qualified commands with whatever is returned from the path subroutine. This can trap the path derived by led() to update the "use lib " statement at the top of scripts. eg: use lib "/usr/lib/nagios/plugins"; gets updated to: use lib "nagios/plugins"; the second isn't valid. I perceive the command line substitution as a cosmetic optimization, there's nothing wrong with calling commands explicitly. They should be properly discovered by the configure stage for a given platform/distribution anyways. patch knocks out the substitution. May be more elegant ways to accomplish the same goal. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 06:44 Message: Thanks! Fixed in Git ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-02 03:02 Message: yup - that appears to work. Change paths for execs first, then change lib path. Original 'use lib ".";' won't catch. See updated nagios-plugins-subst.patch, should also obsolete the debian patch. ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-02 02:48 Message: running the exec path substitution prior to updating INC with the libexec dir appears to accomplish fixing up the script for non-standard paths, while not harming libexec dirs that are under /usr/lib or any other detected executable hosting directory. Will test a bit more & submit updated patch ---------------------------------------------------------------------- Comment By: Martin Foster (martinfoster) Date: 2009-04-02 02:40 Message: Hi, I'm taking a closer look at this now that I get why it's there. first things first: ./configure --prefix=/usr --exec-prefix=/usr --libexecdir=/usr/lib/nagios/plugins --sysconfdir=/etc/nagios --datadir=/usr/share --with-cgiurl=/nagios/cgi-bin so the plugins are installed to /usr/lib/nagios/plugins I note that this is the same path used by Debian, so I went to check what their package does. They apply a patch that explicitly sets the paths in subst - then removes the substitution wholesale, the led() function, and removes the which() function. see attached as a reference. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-31 13:03 Message: Uhg sorry I might have been too wuick on the trigger. Looks like this is a "automatic configuration" thingy - i.e. instead of detecting commands in configure it does it at the make phase using this script. What it you move that up in the script, so that this substition happens before the lib expansion? A better way of doing it is making an explicit keyword in the paths, and matching the keyword in that block. I.e. substituting "NP_AUTO_PATH/echo" to the result of `which echo` That would require finding all paths modified by running the said part of the script and comparing source plugins with generated files. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-31 12:52 Message: Thanks for reporting this, though your patch is wrong. These substitutions are required for non-standard paths. What configure options did you use, so I can try to reproduce it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2722832&group_id=29880 From noreply at sourceforge.net Fri May 22 19:42:15 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 17:42:15 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2268675 ] fix for quoting in check_by_ssh Message-ID: Patches item #2268675, was opened at 2008-11-12 11:32 Message generated for change (Settings changed) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2268675&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix >Group: release-1.4.14 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Will Preston (wpreston) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: fix for quoting in check_by_ssh Initial Comment: check_by_ssh builds its check into a single string and passes it to the np_runcmd() function to execute ssh. This function parses the command line back into ssh options and calls execve. Unfortunately the conversion causes various problems with quoted strings. The patch bypasses this conversion and passes the option string directly to execve. This should ensure that ssh checks and local checks are identical. Example: > /bin/sh -c "echo '"'$PATH'"'" $PATH > /bin/sh -c 'echo "a b"' a b > Unpatched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" /usr/local/bin:/usr/bin/:/bin > check_by_ssh -H localhost -C 'echo "a b"' Could not open pipe: /usr/bin/ssh localhost 'echo "a b"' > Patched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" $PATH > check_by_ssh -H localhost -C 'echo "a b"' a b > ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2268675&group_id=29880 From noreply at sourceforge.net Fri May 22 20:39:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 18:39:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2782784 ] check_smtp: invalid option -- n Message-ID: Bugs item #2782784, was opened at 2009-04-28 13:38 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2782784&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: CVS >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Matthias Eble (psychotrahe) Summary: check_smtp: invalid option -- n Initial Comment: We got a bugreport against our debian package, the problem is the following: nagios:~# LANG=C /usr/lib/nagios/plugins/check_smtp -n /usr/lib/nagios/plugins/check_smtp: invalid option -- n Usage:check_smtp -H host [-p port] [-e expect] [-C command] [-f from addr][-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6] nagios:~# LANG=C /usr/lib/nagios/plugins/check_smtp --help | grep -1 nocommand String to expect in first line of server response (default: '220') -n, nocommand Suppress SMTP command You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525307 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-05-22 20:39 Message: Hi Jan, -n was removed from check_smtp as this is covered by check_tcp already. ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2009-05-22 20:39 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2782784&group_id=29880 From noreply at sourceforge.net Fri May 22 20:59:16 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 18:59:16 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2782785 ] check_smtp: --expect= result in "recv() failed" Message-ID: Bugs item #2782785, was opened at 2009-04-28 13:41 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2782785&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution >Group: v1.4.14 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Matthias Eble (psychotrahe) Summary: check_smtp: --expect= result in "recv() failed" Initial Comment: The following Bugreport we got against our debian package (1.4.12): I monitor a SMTP server that refuses the connection immediately, without waiting for HELO. Before upgrade to lenny I used this command: /usr/lib/nagios/plugins/check_smtp -H novell.vkol.cz -e 520 and it was OK. Now I get error: recv() failed and status is WARNING. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525976 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Matthias Eble (psychotrahe) Date: 2009-05-22 20:59 Message: Hi Jan, this can easily be accomplished by using check_tcp. There's nothing smtp specific in there. Matthias ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2782785&group_id=29880 From noreply at sourceforge.net Sat May 23 00:00:21 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 22 May 2009 22:00:21 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2654308 ] check_mrtgtraf Perf data incorrect Message-ID: Bugs item #2654308, was opened at 2009-03-02 12:44 Message generated for change (Comment added) made by psychotrahe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2654308&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: v1.4.14 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Gavin Williams (fatmcgav88) >Assigned to: Matthias Eble (psychotrahe) Summary: check_mrtgtraf Perf data incorrect Initial Comment: When using check_mrtgtraf, the performance data returned is incorrectly tagging both sets of data as the in data. Line 202 should read: fperfdata("out", adjusted_outgoing_rate, outgoing_speed_rating, Changed on local source and recompiled and confirmed working. Plugin Version (-V output): check_mrtgtraf v1991 (nagios-plugins 1.4.12) Plugin Name: check_mrtgtraf Plugin Commandline showing issues: Operating System: CentOs 5.2 Architecture: x86_64 Compiler: gcc ---------------------------------------------------------------------- Comment By: Matthias Eble (psychotrahe) Date: 2009-05-23 00:00 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2654308&group_id=29880 From noreply at sourceforge.net Tue May 26 01:13:18 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 25 May 2009 23:13:18 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2796624 ] check_icmp wrong output in help Message-ID: Bugs item #2796624, was opened at 2009-05-26 01:13 Message generated for change (Tracker Item Submitted) made by cyco_dd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2796624&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Nobody/Anonymous (nobody) Summary: check_icmp wrong output in help Initial Comment: The following Bugreport we got against our debian package (1.4.12): At no point are warn.rta and crit.rta handled differently. The default behavior has a .5s timeout, not a 500s timeout. The range for pl seems to be 0..100, and not some orders of magnitude otherwise. All evidence indicates that the factor of 1000 was misplaced during some code change. --- ./check_icmp.c +++ /tmp/tmp.BWCqbw/check_icmp.c 2009-05-25 10:32:23.000000000 -0700 @@ -1271,10 +1271,10 @@ printf (" %s\n", _("specify a target")); printf (" %s\n", "-w"); printf (" %s", _("warning threshold (currently ")); - printf ("%0.3fms,%u%%)\n", (float)warn.rta / 1000 , warn.pl / 1000); + printf ("%0.3fms,%u%%)\n", (float)warn.rta / 1000 , warn.pl); printf (" %s\n", "-c"); printf (" %s", _("critical threshold (currently ")); - printf ("%0.3fms,%u%%)\n", (float)crit.rta, crit.pl); + printf ("%0.3fms,%u%%)\n", (float)crit.rta / 1000, crit.pl); printf (" %s\n", "-s"); printf (" %s\n", _("specify a source IP address or device name")); printf (" %s\n", "-n"); I know, its not an unified diff, but thats what we got so far, sorry. :) You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530553 Thanks and kind regards, Jan. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2796624&group_id=29880 From noreply at sourceforge.net Tue May 26 09:06:39 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 May 2009 07:06:39 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2550224 ] check_ntp: wrong output for host with both A and AAAA record Message-ID: Bugs item #2550224, was opened at 2009-01-30 15:40 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: CVS >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_ntp: wrong output for host with both A and AAAA record Initial Comment: The following Bugreport we got against our debian package: Please consider this: $ host -t any lipton.aai.niif.hu lipton.aai.niif.hu A 193.225.14.195 lipton.aai.niif.hu AAAA 2001:738:0:701:80:C1E1:EC3:0 $ /usr/lib/nagios/plugins/check_ntp -H lipton.aai.niif.hu -v sending request to peer 0 sending request to peer 1 response from peer 1: offset -2.680183388e-05 sending request to peer 1 response from peer 1: offset -1.871510176e-05 sending request to peer 1 response from peer 1: offset 3.834080417e-06 sending request to peer 1 response from peer 1: offset -3.614556044e-05 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 re-sending request to peer 0 overall average offset: nan NTP OK: Offset nan secs|offset=nan This isn't serious, since one uses IP addresses anyway, but still a bug. Sure the client doesn't respond to IPv6 packets, but its offset isn't NaN. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509589 ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-26 03:06 Message: Was fixed in 1.4.12 (git commit 34cfb0c1034a6b3289e9aca567fd2393126aa80a) ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:35 Message: Works for me - I tried blocking both address alternatively so that I could see results with either peer0 or peer1 unresponsive. what check_ntp version are you using? ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:27 Message: Sorry - I just realized it's about the offset calculation... ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-20 02:19 Message: IPv6 "DO" work if your OS supports IPv6 and is configured/connected properly (I just testes it on a dual v4/v6 server). In the other case you can use the -4 switch to force IPv4 (tested on a system which isn't IPv6-capable) IPv6: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v sending request to peer 0 sending request to peer 1 response from peer 0: offset 0.0126850605 sending request to peer 0 response from peer 1: offset 0.01730811596 sending request to peer 1 response from peer 0: offset 0.0123462677 sending request to peer 0 re-sending request to peer 0 response from peer 1: offset 0.01795887947 sending request to peer 1 response from peer 0: offset 0.01281118393 sending request to peer 0 response from peer 0: offset 0.01216220856 response from peer 1: offset 0.01737487316 sending request to peer 1 response from peer 1: offset 0.01733827591 overall average offset: 0.0126850605 NTP OK: Offset 0.0126850605 secs|offset=0.012685s;60.000000;120.000000; $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.02037644386 sending request to peer 0 response from peer 0: offset 0.02015924454 sending request to peer 0 response from peer 0: offset 0.02035975456 sending request to peer 0 re-sending request to peer 0 response from peer 0: offset 0.02017998695 overall average offset: 0.02037644386 NTP OK: Offset 0.02037644386 secs|offset=0.020376s;60.000000;120.000000; $ IPv4: $ host -t any tmpntpsrv.join.uni-muenster.de. tmpntpsrv.join.uni-muenster.de has address 128.176.191.9 tmpntpsrv.join.uni-muenster.de has IPv6 address 2001:638:500:101:2e0:4bff:fe04:bc5f $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -v Address family not supported by protocol can not create new socket$ $ ./check_ntp -H tmpntpsrv.join.uni-muenster.de. -4 -v sending request to peer 0 response from peer 0: offset 0.06370124064 sending request to peer 0 response from peer 0: offset 0.06318281766 sending request to peer 0 response from peer 0: offset 0.06347788981 sending request to peer 0 response from peer 0: offset 0.06340960733 overall average offset: 0.06370124064 NTP OK: Offset 0.06370124064 secs|offset=0.063701s;60.000000;120.000000; $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2550224&group_id=29880 From noreply at sourceforge.net Tue May 26 09:09:15 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 May 2009 07:09:15 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2555775 ] nagios check_smtp expects integer instead of double Message-ID: Bugs item #2555775, was opened at 2009-02-01 11:36 Message generated for change (Settings changed) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Wagner (cyco_dd) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: nagios check_smtp expects integer instead of double Initial Comment: The following Bugreport we got against the ubuntu package: Command execution returns error with double value: # /usr/lib/nagios/plugins/check_smtp -H localhost -w 0.2 check_smtp: Warning time must be a positive integer Usage:check_smtp -H host [-p port] [-e expect] [-C command] [-f from addr][-A authtype -U authuser -P authpass] [-w warn] [-c crit] [-t timeout] [-S] [-D days] [-n] [-v] [-4|-6] But docu ( /usr/lib/nagios/plugins/check_smtp -h) says: -w, --warning=DOUBLE Response time to result in warning status (seconds) -c, --critical=DOUBLE Response time to result in critical status (seconds) I think, that the integer check is done on error, since all other commands with -w / -c option take double arguments and sub second response time checks are really useful. ----------------------------------------- Current package: Status: install ok installed Priority: extra Section: net Installed-Size: 1252 Maintainer: Ubuntu Core Developers Architecture: i386 Source: nagios-plugins Version: 1.4.11-1ubuntu5 ---------------------------------------- Patch vs nagios-plugins-1.4.12 source (untested): --- check_smtp.orig 2009-01-19 10:57:05.000000000 +0100 +++ check_smtp.c 2009-01-19 11:34:04.000000000 +0100 @@ -103,9 +103,9 @@ char *authtype = NULL; char *authuser = NULL; char *authpass = NULL; -int warning_time = 0; +double warning_time = 0; int check_warning_time = FALSE; -int critical_time = 0; +double critical_time = 0; int check_critical_time = FALSE; int verbose = 0; int use_ssl = FALSE; @@ -432,9 +432,9 @@ elapsed_time = (double)microsec / 1.0e6; if (result == STATE_OK) { - if (check_critical_time && elapsed_time > (double) critical_time) + if (check_critical_time && elapsed_time > critical_time) result = STATE_CRITICAL; - else if (check_warning_time && elapsed_time > (double) warning_time) + else if (check_warning_time && elapsed_time > warning_time) result = STATE_WARNING; } @@ -565,21 +565,19 @@ nresponses++; break; case 'c': /* critical time threshold */ - if (is_intnonneg (optarg)) { - critical_time = atoi (optarg); - check_critical_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Critical time must be a positive")); else { - usage4 (_("Critical time must be a positive integer")); + critical_time = strtod (optarg, NULL); + check_critical_time = TRUE; } break; case 'w': /* warning time threshold */ - if (is_intnonneg (optarg)) { - warning_time = atoi (optarg); - check_warning_time = TRUE; - } + if (!is_nonnegative (optarg)) + usage4 (_("Warning time must be a positive")); else { - usage4 (_("Warning time must be a positive integer")); + warning_time = strtod (optarg, NULL); + check_warning_time = TRUE; } break; case 'v': /* verbose */ Cross comparison with other files (e.g. check_http.c) showed that there might be more of these issues, e.g. wrong message outputs/conversions case 'w': /* warning time threshold */ if (!is_nonnegative (optarg)) usage2 (_("Warning threshold must be integer"), optarg); else { warning_time = strtod (optarg, NULL); check_warning_time = TRUE; } break; You can track the whole bugreport at https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/318703 Thank, Jan. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-02-04 23:37 Message: Thanks for your report. The proper fix would rather be using the nagios thresholds functions. OTOH it's more likely that we put time toward implementing the new thresholds format than fixing plugins that were never converted to the old one. Feel free to attach a working patch if you wish - we'll consider it anyway. Otherwise a quick fix would rather be fixing the documentation. ---------------------------------------------------------------------- Comment By: Jan Wagner (cyco_dd) Date: 2009-02-01 11:51 Message: File Added: patch-nagios-plugins-1.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2555775&group_id=29880 From noreply at sourceforge.net Tue May 26 10:31:53 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 May 2009 08:31:53 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2268675 ] fix for quoting in check_by_ssh Message-ID: Patches item #2268675, was opened at 2008-11-12 05:32 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2268675&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: release-1.4.14 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Will Preston (wpreston) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: fix for quoting in check_by_ssh Initial Comment: check_by_ssh builds its check into a single string and passes it to the np_runcmd() function to execute ssh. This function parses the command line back into ssh options and calls execve. Unfortunately the conversion causes various problems with quoted strings. The patch bypasses this conversion and passes the option string directly to execve. This should ensure that ssh checks and local checks are identical. Example: > /bin/sh -c "echo '"'$PATH'"'" $PATH > /bin/sh -c 'echo "a b"' a b > Unpatched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" /usr/local/bin:/usr/bin/:/bin > check_by_ssh -H localhost -C 'echo "a b"' Could not open pipe: /usr/bin/ssh localhost 'echo "a b"' > Patched: > check_by_ssh -H localhost -C "echo '"'$PATH'"'" $PATH > check_by_ssh -H localhost -C 'echo "a b"' a b > ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-26 04:31 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2268675&group_id=29880 From noreply at sourceforge.net Tue May 26 10:33:30 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 May 2009 08:33:30 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-1985246 ] ssh_disk dont interpret -C with single quotes correct Message-ID: Bugs item #1985246, was opened at 2008-06-05 05:16 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Argument proccessing Group: v1.4.14 >Status: Closed >Resolution: Fixed Priority: 7 Private: No Submitted By: Jan Wagner (cyco_dd) Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: ssh_disk dont interpret -C with single quotes correct Initial Comment: The following Bugreport we got against our debian package: By default, the ssh_disk configuration has the following command line... /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$ -C '/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$' This creates the following error when trying to check a remote system... [1179694002] SERVICE ALERT: tagboard;/dev/hda1 Free Space;UNKNOWN;SOFT;1;Could not open pipe: /usr/bin/ssh 172.24.32.1 '/usr/lib/nagios/plugins/check_disk -w 5% -c 3% -p "/dev/hda1"' Changing the single quotes to be double quotes in the config resolves this problem. You can track the bugreport via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425312 Thanks and kind regards, Jan. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-26 04:33 Message: check_by_ssh now accepts any kind of quotes ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-26 04:33 Message: This problem is now fixed in Git. Thank you for your report. ---------------------------------------------------------------------- Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-03-17 00:55 Message: Thanks, wpreston, for the patch. It looks very nice, though I have some questions/comments about it... By going over ssh the remote end normally spawns a shell when it feels it's required. Are there any possible interaction with your patch and fancy/quirky check commands to work around them? Backwards-compatibility is an important issue there, though I guess it wouldn't be too hard to allow it with a conditional switch if required. It would be very nice if you could include code comments about the new functions. It seems like there are bug fixes along with new features (i.e. you seem to alter functions/unrelated parts of the code). It would be nice if you could make separate patches for them and apply the new features on top of the fixed code. Any reason for strcpy'ing the arguments when you can simply pass pointers around? This avoids the need to free them afterwards. I wouldn't modify the process_arguments function, as we may one day write a C library that will take care of thet (among other). Any reason **newargv and **opts are not global like the rest? Somewhere in np_runcmd_open_argv you have this, and I can't see these variables anywhere else in the patch...: + int master,slave; Why not using MAXARGS for detecting a full array? C++ comments (//) break on some architectures (just FYI) Does it apply on latest development code? Thanks ---------------------------------------------------------------------- Comment By: Will Preston (wpreston) Date: 2009-03-13 11:26 Message: There's a patch 2268675 (fix for quoting in check_by_ssh) in the queue which would fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=1985246&group_id=29880 From noreply at sourceforge.net Tue May 26 10:39:23 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 26 May 2009 08:39:23 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-1721843 ] check_by_ssh -C quoting documentation Message-ID: Patches item #1721843, was opened at 2007-05-19 11:18 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1721843&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Bugfix Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Loic Dachary (loic) >Assigned to: Thomas Guyot-Sionnest (dermoth) Summary: check_by_ssh -C quoting documentation Initial Comment: The quoting rules of the -C argument of check_by_ssh are unusual and will mislead every system administrator unless properly documented. The attached patch adds a few lines in the usage help. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-26 04:39 Message: -C was fixed - no need for that patch anymore ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=1721843&group_id=29880 From addw at phcomp.co.uk Tue May 26 17:43:20 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Tue, 26 May 2009 16:43:20 +0100 Subject: [Nagiosplug-devel] how do I get a patch integrated Message-ID: <20090526154320.GI7032@mint.phcomp.co.uk> About a week ago I put up a patch for the check_procs plugin, I have not seen any comment about it. How can I help it to be made part of the released version ? You can view a description of it here: http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From PsychoTrahe at gmx.de Tue May 26 19:11:18 2009 From: PsychoTrahe at gmx.de (Matthias Eble) Date: Tue, 26 May 2009 19:11:18 +0200 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: <20090526154320.GI7032@mint.phcomp.co.uk> References: <20090526154320.GI7032@mint.phcomp.co.uk> Message-ID: <1243357878.10342.10.camel@pc.site> Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: > About a week ago I put up a patch for the check_procs plugin, I have not > seen any comment about it. How can I help it to be made part of the released version ? > > You can view a description of it here: > > http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 > Hi Alain, I had a short look at it and I somewhat disliked the fact that it makes use of a temp file. Even though this looks absolutely arguable for your enhancement, we usually avoid temporary files: http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 Submitting patches to the tracker and ringing the bells on np-devel if nothing happens is the right approach. Detecting a CPU hog would be a nice thing, though. Other opinions? Matthias From rouilj at cs.umb.edu Tue May 26 19:20:05 2009 From: rouilj at cs.umb.edu (John P. Rouillard) Date: Tue, 26 May 2009 13:20:05 -0400 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: Your message of "Tue, 26 May 2009 19:11:18 +0200." <1243357878.10342.10.camel@pc.site> Message-ID: <200905261720.n4QHK5pT004854@mx1.cs.umb.edu> In message <1243357878.10342.10.camel at pc.site>, Matthias Eble writes: >Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: >> About a week ago I put up a patch for the check_procs plugin, I have not >> seen any comment about it. How can I help it to be made part of the releas > >I had a short look at it and I somewhat disliked the fact that it makes >use of a temp file. Even though this looks absolutely arguable for your >enhancement, we usually avoid temporary files: >http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 > >Submitting patches to the tracker and ringing the bells on np-devel if >nothing happens is the right approach. > >Detecting a CPU hog would be a nice thing, though. Other opinions? Well until nagios provides some mechanism for plugin data storage, the use of a temp file seems reasonable if less than desirable. IIRC the temp file isn't used/required unless the cpu hog detention is enabled, so it won't impact the other use cases for check_proc. It also allows setting the temp file on the command line, so the user can place it in a secure location. I would say it's a valuable addition. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. From addw at phcomp.co.uk Tue May 26 19:24:37 2009 From: addw at phcomp.co.uk (Alain Williams) Date: Tue, 26 May 2009 18:24:37 +0100 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: <1243357878.10342.10.camel@pc.site> References: <20090526154320.GI7032@mint.phcomp.co.uk> <1243357878.10342.10.camel@pc.site> Message-ID: <20090526172437.GQ7032@mint.phcomp.co.uk> On Tue, May 26, 2009 at 07:11:18PM +0200, Matthias Eble wrote: > Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: > > About a week ago I put up a patch for the check_procs plugin, I have not > > seen any comment about it. How can I help it to be made part of the released version ? > > > > You can view a description of it here: > > > > http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 > > > > Hi Alain, > > I had a short look at it and I somewhat disliked the fact that it makes > use of a temp file. Even though this looks absolutely arguable for your > enhancement, we usually avoid temporary files: > http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 I looked at that, I could not see a way round it. For this to work I need to keep information on 'bad' processes between invocations of the plugin. I cannot see any other sensible way of holding it; shared memory would do - but I think is a worse approach. An improvement would be if Nagios were to export an environment variable (eg NAGIOS_STATE_DIR) where such state files could be kept -- but that is not today's nagios. > Submitting patches to the tracker and ringing the bells on np-devel if > nothing happens is the right approach. Thanks > Detecting a CPU hog would be a nice thing, though. Other opinions? Done at the request of a customer, it seems to work well on his machine. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include From dermoth at aei.ca Wed May 27 01:32:49 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Tue, 26 May 2009 19:32:49 -0400 Subject: [Nagiosplug-devel] how do I get a patch integrated In-Reply-To: <1243357878.10342.10.camel@pc.site> References: <20090526154320.GI7032@mint.phcomp.co.uk> <1243357878.10342.10.camel@pc.site> Message-ID: <4A1C7C21.50208@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/05/09 01:11 PM, Matthias Eble wrote: > Am Dienstag, den 26.05.2009, 16:43 +0100 schrieb Alain Williams: >> About a week ago I put up a patch for the check_procs plugin, I have not >> seen any comment about it. How can I help it to be made part of the released version ? >> >> You can view a description of it here: >> >> http://sourceforge.net/tracker/?func=detail&aid=2794120&group_id=29880&atid=397599 >> > > Hi Alain, > > I had a short look at it and I somewhat disliked the fact that it makes > use of a temp file. Even though this looks absolutely arguable for your > enhancement, we usually avoid temporary files: > http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN254 > > Submitting patches to the tracker and ringing the bells on np-devel if > nothing happens is the right approach. > > Detecting a CPU hog would be a nice thing, though. Other opinions? I agree - I do not like temp files either. For small stuff I like to use performance data string (I have a perl plugin implementing that, and a outdated branch tries to implement that with check_snmp). For bigger stuff, would shared memory segments be a good substitute for temp files? Regarding this patch, it is quite invasive... so much I'm wondering if it wouldn't be better as a separate plugin. One thing I would have liked too is a plugin parsing SAR logfiles (which would allow getting many more metrics), unfortunately sar does not seem to log anything that would help finding cpu hogs (there's pidstat but even with the latest release of sysstat I couldn't find a way to get that info logged to file). If we could get sar to log pidstat info we could get a *very* useful general-purpose plug-in by parsing the sar log file. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKHHwh6dZ+Kt5BchYRAtf0AKCwkhyUSC7R2N6YjoKbNQgN9d59qACbBdrf wLKk7VWAGW6w/3VZ+iVFnTE= =BP0D -----END PGP SIGNATURE----- From jonslusher at gmail.com Thu May 28 05:10:59 2009 From: jonslusher at gmail.com (Jonathan Slusher) Date: Wed, 27 May 2009 22:10:59 -0500 Subject: [Nagiosplug-devel] Fwd: -w switch in check_smtp nagios plug in command In-Reply-To: <6fb2f0c60905272004y612c5765vaa01eeb8f59b33c5@mail.gmail.com> References: <6fb2f0c60905272004y612c5765vaa01eeb8f59b33c5@mail.gmail.com> Message-ID: <6fb2f0c60905272010k6e7ef492xb43d8343f9995191@mail.gmail.com> I can't seem to be able to set it to anything less than a second. Is this possible? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu May 28 05:28:27 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Wed, 27 May 2009 23:28:27 -0400 Subject: [Nagiosplug-devel] [PATCH] check_snmp: Make use of standard threshold functions Message-ID: <1243481307-21917-1-git-send-email-dermoth@aei.ca> I just finished this patch, however I also realized it breaks one untested "feature": inclusive ranges used to be spesifies as "max:min" whereas the official range format uses "@min:max". I was wondering if it's a fair change or if I should hack around to detect and correct the original format... In its current state this patch would cause such ranges to return UNKNOWN and output "Range format incorrect". Patch below... This patch makes use of standard threshold functions. This allows using doubles as thresholds. Since SNMP supports only integers, double precision numbers are only printed when parsed from a STRING type. In addition, support for printing properly Timeticks type has been added, and the code has been thoroughly cleaned. --- NEWS | 1 + lib/utils_base.h | 3 + plugins/check_snmp.c | 248 +++++++++++--------------------------------------- 3 files changed, 56 insertions(+), 196 deletions(-) diff --git a/NEWS b/NEWS index 494dd6f..ab8844f 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,7 @@ This file documents the major additions and syntax changes between releases. check_http: Add SSL/TLS hostname extension support (SNI) - (#1939022 - Joe Presbrey) Fixed wrong perfdata label for output traffic in check_mrtgtraf (#2654308 - Gavin Williams) Fixed check_by_ssh interpretation of quotes in -C parameter (#1985246, #2268675) + check_snmp now supports standard threshold ranges and doubles (floating numbers) in thresholds 1.4.13 25th Sept 2008 Fix Debian bug #460097: check_http --max-age broken (Hilko Bengen) diff --git a/lib/utils_base.h b/lib/utils_base.h index f40fdb0..49e40a6 100644 --- a/lib/utils_base.h +++ b/lib/utils_base.h @@ -35,6 +35,9 @@ void print_thresholds(const char *, thresholds *); int check_range(double, range *); int get_status(double, thresholds *); +/* All possible characters in a threshold range */ +#define NP_THRESHOLDS_CHARS "0123456789.:@~" + char *np_escaped_string (const char *); void die (int, const char *, ...) __attribute__((noreturn,format(printf, 2, 3))); diff --git a/plugins/check_snmp.c b/plugins/check_snmp.c index 94b75b9..ef930da 100644 --- a/plugins/check_snmp.c +++ b/plugins/check_snmp.c @@ -53,33 +53,14 @@ const char *email = "nagiosplug-devel at lists.sourceforge.net"; #define CRIT_PRESENT 1 #define CRIT_STRING 2 #define CRIT_REGEX 4 -#define CRIT_GT 8 -#define CRIT_LT 16 -#define CRIT_GE 32 -#define CRIT_LE 64 -#define CRIT_EQ 128 -#define CRIT_NE 256 -#define CRIT_RANGE 512 -#define WARN_PRESENT 1024 -#define WARN_STRING 2048 -#define WARN_REGEX 4096 -#define WARN_GT 8192 -#define WARN_LT 16384 -#define WARN_GE 32768 -#define WARN_LE 65536 -#define WARN_EQ 131072 -#define WARN_NE 262144 -#define WARN_RANGE 524288 +#define WARN_PRESENT 8 +#define WARN_STRING 16 +#define WARN_REGEX 32 #define MAX_OIDS 8 -#define MAX_DELIM_LENGTH 8 int process_arguments (int, char **); int validate_arguments (void); -char *clarify_message (char *); -int check_num (int); -int llu_getll (unsigned long long *, char *); -int llu_getul (unsigned long long *, char *); char *thisarg (char *str); char *nextarg (char *str); void print_usage (void); @@ -89,7 +70,6 @@ void print_help (void); char regex_expect[MAX_INPUT_BUFFER] = ""; regex_t preg; regmatch_t pmatch[10]; -char timestamp[10] = ""; char errbuf[MAX_INPUT_BUFFER] = ""; char perfstr[MAX_INPUT_BUFFER] = "| "; int cflags = REG_EXTENDED | REG_NOSUB | REG_NEWLINE; @@ -122,15 +102,12 @@ int numoids = 0; int numauthpriv = 0; int verbose = FALSE; int usesnmpgetnext = FALSE; -unsigned long long lower_warn_lim[MAX_OIDS]; -unsigned long long upper_warn_lim[MAX_OIDS]; -unsigned long long lower_crit_lim[MAX_OIDS]; -unsigned long long upper_crit_lim[MAX_OIDS]; -unsigned long long response_value[MAX_OIDS]; -int check_warning_value = FALSE; -int check_critical_value = FALSE; +char *warning_thresholds = NULL; +char *critical_thresholds = NULL; +thresholds *thlds[MAX_OIDS]; +double response_value[MAX_OIDS]; int retries = 0; -unsigned long long eval_method[MAX_OIDS]; +int eval_method[MAX_OIDS]; char *delimiter; char *output_delim; char *miblist = NULL; @@ -140,7 +117,7 @@ int needmibs = FALSE; int main (int argc, char **argv) { - int i = 0; + int i; int iresult = STATE_UNKNOWN; int result = STATE_UNKNOWN; int return_code = 0; @@ -152,6 +129,8 @@ main (int argc, char **argv) char *outbuff; char *ptr = NULL; char *show = NULL; + char *th_warn=NULL; + char *th_crit=NULL; char type[8] = ""; output chld_out, chld_err; @@ -163,7 +142,6 @@ main (int argc, char **argv) unitv = malloc (unitv_size); for (i = 0; i < MAX_OIDS; i++) eval_method[i] = CHECK_UNDEF; - i = 0; label = strdup ("SNMP"); units = strdup (""); @@ -171,7 +149,6 @@ main (int argc, char **argv) outbuff = strdup (""); delimiter = strdup (" = "); output_delim = strdup (DEFAULT_OUTPUT_DELIMITER); - /* miblist = strdup (DEFAULT_MIBLIST); */ timeout_interval = DEFAULT_TIMEOUT; retries = DEFAULT_RETRIES; @@ -181,6 +158,28 @@ main (int argc, char **argv) if (process_arguments (argc, argv) == ERROR) usage4 (_("Could not parse arguments")); + /* Populate the thresholds */ + th_warn=warning_thresholds; + th_crit=critical_thresholds; + for (i=0; iwarning || thlds[i]->critical) { ptr = strpbrk (show, "0123456789"); if (ptr == NULL) die (STATE_UNKNOWN,_("No valid data returned")); - response_value[i] = strtoul (ptr, NULL, 10); - iresult = check_num (i); - asprintf (&show, "%llu", response_value[i]); + response_value[i] = strtod (ptr, NULL); + iresult = get_status(response_value[i], thlds[i]); + asprintf (&show, conv, response_value[i]); } /* Process this block for string matching */ @@ -363,9 +357,6 @@ main (int argc, char **argv) } } -/* if (nunits == 1 || i == 1) */ -/* printf ("%s %s -%s %s\n", label, state_text (result), outbuff, units); */ -/* else */ printf ("%s %s -%s %s \n", label, state_text (result), outbuff, perfstr); return result; @@ -488,27 +479,11 @@ process_arguments (int argc, char **argv) break; /* Test parameters */ - case 'c': /* critical time threshold */ - if (strspn (optarg, "0123456789:,") < strlen (optarg)) - usage2 (_("Invalid critical threshold"), optarg); - for (ptr = optarg; ptr && jj < MAX_OIDS; jj++) { - if (llu_getll (&lower_crit_lim[jj], ptr) == 1) - eval_method[jj] |= CRIT_LT; - if (llu_getul (&upper_crit_lim[jj], ptr) == 1) - eval_method[jj] |= CRIT_GT; - (ptr = index (ptr, ',')) ? ptr++ : ptr; - } + case 'c': /* critical threshold */ + critical_thresholds = optarg; break; - case 'w': /* warning time threshold */ - if (strspn (optarg, "0123456789:,") < strlen (optarg)) - usage2 (_("Invalid warning threshold"), optarg); - for (ptr = optarg; ptr && ii < MAX_OIDS; ii++) { - if (llu_getll (&lower_warn_lim[ii], ptr) == 1) - eval_method[ii] |= WARN_LT; - if (llu_getul (&upper_warn_lim[ii], ptr) == 1) - eval_method[ii] |= WARN_GT; - (ptr = index (ptr, ',')) ? ptr++ : ptr; - } + case 'w': /* warning threshold */ + warning_thresholds = optarg; break; case 'e': /* PRELIMINARY - may change */ case 'E': /* PRELIMINARY - may change */ @@ -758,117 +733,6 @@ validate_arguments () -char * -clarify_message (char *msg) -{ - int i = 0; - int foo; - char tmpmsg_c[MAX_INPUT_BUFFER]; - char *tmpmsg = (char *) &tmpmsg_c; - tmpmsg = strcpy (tmpmsg, msg); - if (!strncmp (tmpmsg, " Hex:", 5)) { - tmpmsg = strtok (tmpmsg, ":"); - while ((tmpmsg = strtok (NULL, " "))) { - foo = strtol (tmpmsg, NULL, 16); - /* Translate chars that are not the same value in the printers - * character set. - */ - switch (foo) { - case 208: - { - foo = 197; - break; - } - case 216: - { - foo = 196; - break; - } - } - msg[i] = foo; - i++; - } - msg[i] = 0; - } - return (msg); -} - - - -int -check_num (int i) -{ - int result; - result = STATE_OK; - if (eval_method[i] & WARN_GT && eval_method[i] & WARN_LT && - lower_warn_lim[i] > upper_warn_lim[i]) { - if (response_value[i] <= lower_warn_lim[i] && - response_value[i] >= upper_warn_lim[i]) { - result = STATE_WARNING; - } - } - else if - ((eval_method[i] & WARN_GT && response_value[i] > upper_warn_lim[i]) || - (eval_method[i] & WARN_GE && response_value[i] >= upper_warn_lim[i]) || - (eval_method[i] & WARN_LT && response_value[i] < lower_warn_lim[i]) || - (eval_method[i] & WARN_LE && response_value[i] <= lower_warn_lim[i]) || - (eval_method[i] & WARN_EQ && response_value[i] == upper_warn_lim[i]) || - (eval_method[i] & WARN_NE && response_value[i] != upper_warn_lim[i])) { - result = STATE_WARNING; - } - - if (eval_method[i] & CRIT_GT && eval_method[i] & CRIT_LT && - lower_crit_lim[i] > upper_crit_lim[i]) { - if (response_value[i] <= lower_crit_lim[i] && - response_value[i] >= upper_crit_lim[i]) { - result = STATE_CRITICAL; - } - } - else if - ((eval_method[i] & CRIT_GT && response_value[i] > upper_crit_lim[i]) || - (eval_method[i] & CRIT_GE && response_value[i] >= upper_crit_lim[i]) || - (eval_method[i] & CRIT_LT && response_value[i] < lower_crit_lim[i]) || - (eval_method[i] & CRIT_LE && response_value[i] <= lower_crit_lim[i]) || - (eval_method[i] & CRIT_EQ && response_value[i] == upper_crit_lim[i]) || - (eval_method[i] & CRIT_NE && response_value[i] != upper_crit_lim[i])) { - result = STATE_CRITICAL; - } - - return result; -} - - - -int -llu_getll (unsigned long long *ll, char *str) -{ - char tmp[100]; - if (strchr (str, ':') == NULL) - return 0; - if (strchr (str, ',') != NULL && (strchr (str, ',') < strchr (str, ':'))) - return 0; - if (sscanf (str, "%llu%[:]", ll, tmp) == 2) - return 1; - return 0; -} - - - -int -llu_getul (unsigned long long *ul, char *str) -{ - char tmp[100]; - if (sscanf (str, "%llu%[^,]", ul, tmp) == 1) - return 1; - if (sscanf (str, ":%llu%[^,]", ul, tmp) == 1) - return 1; - if (sscanf (str, "%*u:%llu%[^,]", ul, tmp) == 1) - return 1; - return 0; -} - - - /* trim leading whitespace if there is a leading quote, make sure it balances */ @@ -973,10 +837,10 @@ print_help (void) printf (" %s\n", _("to be the data that should be used in the evaluation.")); /* Tests Against Integers */ - printf (" %s\n", "-w, --warning=INTEGER_RANGE(s)"); - printf (" %s\n", _("Range(s) which will not result in a WARNING status")); + printf (" %s\n", "-w, --warning=THRESHOLD(s)"); + printf (" %s\n", _("Warning threshold range(s)")); printf (" %s\n", "-c, --critical=INTEGER_RANGE(s)"); - printf (" %s\n", _("Range(s) which will not result in a CRITICAL status")); + printf (" %s\n", _("Criticat threshold range(s)")); /* Tests Against Strings */ printf (" %s\n", "-s, --string=STRING"); @@ -1010,16 +874,8 @@ print_help (void) printf (" %s\n", _("- Multiple OIDs may be indicated by a comma- or space-delimited list (lists with")); printf (" %s\n", _("internal spaces must be quoted) [max 8 OIDs]")); - printf (" %s\n", _("- Ranges are inclusive and are indicated with colons. When specified as")); - printf (" %s\n", _("'min:max' a STATE_OK will be returned if the result is within the indicated")); - printf (" %s\n", _("range or is equal to the upper or lower bound. A non-OK state will be")); - printf (" %s\n", _("returned if the result is outside the specified range.")); - - printf (" %s\n", _("- If specified in the order 'max:min' a non-OK state will be returned if the")); - printf (" %s\n", _("result is within the (inclusive) range.")); + printf(" -%s", _(UT_THRESHOLDS_NOTES)); - printf (" %s\n", _("- Upper or lower bounds may be omitted to skip checking the respective limit.")); - printf (" %s\n", _("- Bare integers are interpreted as upper limits.")); printf (" %s\n", _("- When checking multiple OIDs, separate ranges by commas like '-w 1:10,1:,:20'")); printf (" %s\n", _("- Note that only one string and one regex may be checked at present")); printf (" %s\n", _("- All evaluation methods other than PR, STR, and SUBSTR expect that the value")); -- 1.6.3 From noreply at sourceforge.net Thu May 28 10:03:45 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 28 May 2009 08:03:45 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Bugs-2797757 ] segfault in check_mysql when checking slave (-S) Message-ID: Bugs item #2797757, was opened at 2009-05-28 12:03 Message generated for change (Tracker Item Submitted) made by nikitajob You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2797757&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General plugin execution Group: Release (specify) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nikita Girman (nikitajob) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in check_mysql when checking slave (-S) Initial Comment: Plugin Version (-V output): check_mysql v2034 (nagios-plugins 1.4.13) Plugin Name: check_mysql Plugin Commandline showing issues: check_mysql -u checker -p "123" -H 172.16.7.17 -P 13306 -S Operating System: FreeBSD 7.1-RELEASE-p4 amd64 Architecture: amd64 Compiler: gcc version 4.2.1 20070719 [FreeBSD] check_mysql crashes with segfault when checking mysql slave (-S option), regardless of warning/critical ranges specified or not (MYSQL server has to be alive to reproduce the bug). Only 64-bit arch is affected, i386 version works fine. I discovered the memory allocation problem in function _set_thresholds() (line 107 of lib/utils_base.c file): ... thresholds *temp_thresholds = NULL; temp_thresholds = malloc(sizeof(temp_thresholds)); ... Instead of thresholds struct size, it's requested the size of _pointer_ to thresholds, so it leads to insufficient memoty allocation for the struct and further memory corruption while mysql_init (&mysql) call (line 92 in check_mysql.c): --- gdb.txt --- Breakpoint 1 at 0x4020d0: file check_mysql.c, line 92. Starting program: ~/src/nagios-plugins-1.4.13/plugins/check_mysql -u checker -p "123" -H 172.16.7.17 -P 13306 -S Breakpoint 1, main (argc=10, argv=0x7fffffffeb70) at check_mysql.c:92 92 mysql_init (&mysql); Watchpoint 2: my_threshold->critical $1 = (range *) 0x0 Continuing. Watchpoint 2: my_threshold->critical Old value = (range *) 0x0 New value = (range *) 0x67 0x0000000801374420 in memcpy () from /lib/libc.so.7 #0 0x0000000801374420 in memcpy () from /lib/libc.so.7 #1 0x00000008012fb86f in strdup () from /lib/libc.so.7 #2 0x0000000801349b42 in _nsyylex () from /lib/libc.so.7 #3 0x0000000801348e63 in _nsyyparse () from /lib/libc.so.7 #4 0x000000080134e9a7 in nsdispatch () from /lib/libc.so.7 #5 0x000000080133fdbc in getservbyname_r () from /lib/libc.so.7 #6 0x000000080133f79b in if_nametoindex () from /lib/libc.so.7 #7 0x000000080065b2f6 in mysql_server_init () from /usr/pkg/lib/mysql/libmysqlclient.so.14 #8 0x000000080067a9b8 in mysql_init () from /usr/pkg/lib/mysql/libmysqlclient.so.14 #9 0x00000000004020dd in main (argc=10, argv=0x7fffffffeb70) at check_mysql.c:92 Continuing. Watchpoint 2: my_threshold->critical Old value = (range *) 0x67 New value = (range *) 0x7267 0x0000000801374420 in memcpy () from /lib/libc.so.7 Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0000000000403ad2 in check_range (value=0, my_range=0x70756f7267) at utils_base.c:168 168 if (my_range->alert_on == INSIDE) { --- end of gdb.txt --- The bug still exists in latest nagios-plugins snapshot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397597&aid=2797757&group_id=29880 From ton.voon at opsera.com Thu May 28 10:13:51 2009 From: ton.voon at opsera.com (Ton Voon) Date: Thu, 28 May 2009 09:13:51 +0100 Subject: [Nagiosplug-devel] [PATCH] check_snmp: Make use of standard threshold functions In-Reply-To: <1243481307-21917-1-git-send-email-dermoth@aei.ca> References: <1243481307-21917-1-git-send-email-dermoth@aei.ca> Message-ID: On 28 May 2009, at 04:28, Thomas Guyot-Sionnest wrote: > I just finished this patch, however I also realized it breaks one > untested > "feature": inclusive ranges used to be spesifies as "max:min" > whereas the > official range format uses "@min:max". I was wondering if it's a fair > change or if I should hack around to detect and correct the original > format... Tough decision.... I would say it is fair change to break the "max:min" format range, as long as there was a big warning section in the release notes. Is it possible to add a test in to check this command line option. Ton From Ovidiu.Marcu at tdn.de Thu May 28 12:17:52 2009 From: Ovidiu.Marcu at tdn.de (Ovidiu Marcu) Date: Thu, 28 May 2009 12:17:52 +0200 Subject: [Nagiosplug-devel] Is there a way to monitor interface traffic on solaris zones? In-Reply-To: References: <1243481307-21917-1-git-send-email-dermoth@aei.ca> Message-ID: Is there a way to monitor interface traffic on solaris zones? I've got a complicated script but it returns the values used by all my solaris zone. From djpersia at tiscali.it Thu May 28 22:02:02 2009 From: djpersia at tiscali.it (djpersia) Date: Thu, 28 May 2009 22:02:02 +0200 Subject: [Nagiosplug-devel] R: nagios plugin without clear-text password for ms sql References: <000001c9def9$a7e893b0$f7b9bb10$@it> Message-ID: <000c01c9dfcf$2b20bd40$816237c0$@it> Hi, thank you very much for your collaboration. I am writing this mail because I need a plugin that interfaces with nagios to monitor some parameters for ms sql 2000 ms sql 2005; this plugin does not have the passwd in clear, I have already looked into the network but I found when only plugin that passwd user and pwd in clear text; I used a server nagios for monitoring Microsoft sql 2000 e Microsoft sql 2005; specified here is the controls that I do; connection-time cpu-busy io-busy connected-users transactions batch-requests locks-deadlocks sql-recompilations sql-initcompilations mem-pool-data-buffer-hit-ratio page-life-expectancy I should run queries with no clear passwd to read the results of Tables; Thank you very much for your cooperation, I apologize for my English. Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply at sourceforge.net Fri May 29 10:52:44 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 29 May 2009 08:52:44 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2798295 ] Report expect_string in plugin output if test fails Message-ID: Patches item #2798295, was opened at 2009-05-29 10:52 Message generated for change (Tracker Item Submitted) made by patricia_jung You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2798295&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patricia Jung (patricia_jung) Assigned to: Nobody/Anonymous (nobody) Summary: Report expect_string in plugin output if test fails Initial Comment: Patch against Plugin Version (-V output): check_http v2053 (nagios-plugins 1.4.13) Plugin Name: check_http Example Plugin Commandline: check_http -H www.trish.de -p 80 -L --onredirect=CRITICAL --string "bla" Tested on operating system: (SuSE) Linux Tested on architecture: x86 Tested with compiler: gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] With more than one website to monitor one does not want to check the nagios configuration in order to find out the expect string configured. This patch reports it and this way relieves stress in case of failure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2798295&group_id=29880 From tobias at scherbaum.info Fri May 29 21:38:20 2009 From: tobias at scherbaum.info (Tobias Scherbaum) Date: Fri, 29 May 2009 21:38:20 +0200 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <4A13754D.7010102@aei.ca> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> <1242409241.6671.16.camel@homer.ob.libexec.de> <4A13754D.7010102@aei.ca> Message-ID: <1243625900.6226.3.camel@homer.ob.libexec.de> Heya, Thomas Guyot-Sionnest wrote: > > What about > > > > [2531905] check_mysql does not properly handle passwords in from file > > > > wkr, > > Tobias > > Hey thanks for pointing it out - I will have a look Great, thanks! > As a general reminder please DO insist about bugs/patches that seems to > have been left behind. The development team is mostly made of > volunteers; while we do our best to get bugs and important patches in it > can happen that we forget about a discussion or miss an email. Oh well, I have Gentoo bug #253893 which reminds me to sometimes check if it's fixed (or will be fixed in 1.4.14) (or if the proposed patch is accepted) ;) (https://bugs.gentoo.org/show_bug.cgi?id=253893) wkr, Tobias -- Gentoo Linux - Die Metadistribution http://www.mitp.de/5941 http://www.metadistribution.eu https://www.xing.com/profile/Tobias_Scherbaum From dermoth at aei.ca Sat May 30 04:02:29 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 29 May 2009 22:02:29 -0400 Subject: [Nagiosplug-devel] Notification of plugins 1.4.14 release In-Reply-To: <1243625900.6226.3.camel@homer.ob.libexec.de> References: <688CCBBE-4346-49A8-8644-96FA98D212FE@opsera.com> <200904281410.21215.waja@cyconet.org> <49F71606.9030608@aei.ca> <1242409241.6671.16.camel@homer.ob.libexec.de> <4A13754D.7010102@aei.ca> <1243625900.6226.3.camel@homer.ob.libexec.de> Message-ID: <4A2093B5.7030509@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/05/09 03:38 PM, Tobias Scherbaum wrote: > Heya, > > Thomas Guyot-Sionnest wrote: >>> What about >>> >>> [2531905] check_mysql does not properly handle passwords in from file >>> >>> wkr, >>> Tobias >> Hey thanks for pointing it out - I will have a look > > Great, thanks! > >> As a general reminder please DO insist about bugs/patches that seems to >> have been left behind. The development team is mostly made of >> volunteers; while we do our best to get bugs and important patches in it >> can happen that we forget about a discussion or miss an email. > > Oh well, I have Gentoo bug #253893 which reminds me to sometimes check > if it's fixed (or will be fixed in 1.4.14) (or if the proposed patch is > accepted) ;) > > (https://bugs.gentoo.org/show_bug.cgi?id=253893) This was fixed in 917fcc7 (Wed May 20 00:20:11 2009 -0400). Will be for the next release. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKIJO16dZ+Kt5BchYRAudSAKCbi/p2AYPQtA0hdzzACypeqfSA1QCg1Zsg kI5W14AjP/MWbXY8/fft89I= =OnBM -----END PGP SIGNATURE----- From noreply at sourceforge.net Sat May 30 15:09:33 2009 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 30 May 2009 13:09:33 +0000 Subject: [Nagiosplug-devel] [ nagiosplug-Patches-2798295 ] Report expect_string in plugin output if test fails Message-ID: Patches item #2798295, was opened at 2009-05-29 04:52 Message generated for change (Comment added) made by dermoth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2798295&group_id=29880 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patricia Jung (patricia_jung) Assigned to: Nobody/Anonymous (nobody) Summary: Report expect_string in plugin output if test fails Initial Comment: Patch against Plugin Version (-V output): check_http v2053 (nagios-plugins 1.4.13) Plugin Name: check_http Example Plugin Commandline: check_http -H www.trish.de -p 80 -L --onredirect=CRITICAL --string "bla" Tested on operating system: (SuSE) Linux Tested on architecture: x86 Tested with compiler: gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] With more than one website to monitor one does not want to check the nagios configuration in order to find out the expect string configured. This patch reports it and this way relieves stress in case of failure. ---------------------------------------------------------------------- >Comment By: Thomas Guyot-Sionnest (dermoth) Date: 2009-05-30 09:09 Message: Thanks for your patch, unfortunately it won't apply to the development head as there was many changes to check_http since the last release. Besides, I don't think I could apply this patch as it is right now. Under some circumstances it could be desired not to show the passed parameters (sensitive information, very long strings...); an additional parameter could enable this behaviour. Moreover, this change should also apply to regex pattern matching (-r) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=397599&aid=2798295&group_id=29880