From notifications at github.com Mon Jan 6 11:33:02 2014 From: notifications at github.com (Dominik Schulz) Date: Mon, 06 Jan 2014 02:33:02 -0800 Subject: [nagios-plugins] check_procs: Support cgroups / LXC (#1222) Message-ID: The current implementation of check_procs is nice and handy to make sure that a certain number of processes is running, e.g. ntp. It does so, however, in a way that is not suitable for systems running a cgroup based virtualization (lxc, docker, ...). On those systems all processes running in the child containers will show up in the process list of the host and thus the numbers reported by check_procs are inaccurate. Please add a switch which will make check_procs obey the cgroups visible in e.g. /proc//cgroup. --- Reply to this email directly or view it on GitHub: https://github.com/nagios-plugins/nagios-plugins/issues/1222 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eponymousalias at yahoo.com Tue Jan 7 10:52:34 2014 From: eponymousalias at yahoo.com (eponymous alias) Date: Tue, 7 Jan 2014 01:52:34 -0800 (PST) Subject: [nagios-plugins] check_procs: Support cgroups / LXC (#1222) In-Reply-To: Message-ID: <1389088354.10400.YahooMailBasic@web160703.mail.bf1.yahoo.com> I'm not familiar with cgroups, but this sounds like a similar problem we have with Solaris zones, wherein processes in non-global zones show up in the global-zone listing of processes. To address this, I have implemented a "-Z ZONELIST" or "--zonelist=ZONELIST" filtering option ("-z", the natural option letter for this, was already taken) to constrain the counted processes to those in the list of named zones. ZONELIST is a comma-separated or space-separated list of zone names. ".self" may be used as a virtual zone name for the current zone. For simple operation across platforms, "global" or ".self" may be used even on platforms that do not support zones. I implemented this new option in a manner that preserves backward compatibility with the old existing behavior (count all visible processes, if no -Z option is specified to filter the counted processes), even though it's not clear that this behavior is really desired, simply so as never to break any existing use of the plugin. I wish to contribute this extension back to the community, but have gotten stuck on how to make autoconf/automake stuff work correctly in sensing the presence or absence of the file. (I want the autoconf stuff to reliably define [or not] the HAVE_ZONE_H symbol, depending on whether or not exists, and ensure that this symbol is effectively propagated to all the Makefile.in and Makefile files.) If I can get that to work, I'll post the corrections back to this group, and I think that might serve as a good basis for your similar request, if suitably generalized. But my auto-fu is near nonexistent. Any help in this regard would be appreciated. I asked here once before, but the simple advice supplied didn't crack the case, and I failed to follow up. As part of this work, I also fixed a few minor issues with check_procs plugin output (treatment of newlines, and such). That's a benefit of thoroughly testing my own changes. -------------------------------------------- On Mon, 1/6/14, Dominik Schulz wrote: Subject: [nagios-plugins] check_procs: Support cgroups / LXC (#1222) To: "nagios-plugins/nagios-plugins" Date: Monday, January 6, 2014, 2:33 AM The current implementation of check_procs is nice and handy to make sure that a certain number of processes is running, e.g. ntp. It does so, however, in a way that is not suitable for systems running a cgroup based virtualization (lxc, docker, ...). On those systems all processes running in the child containers will show up in the process list of the host and thus the numbers reported by check_procs are inaccurate. Please add a switch which will make check_procs obey the cgroups visible in e.g. /proc//cgroup. ? Reply to this email directly or view it on GitHub. From notifications at github.com Wed Jan 15 22:20:53 2014 From: notifications at github.com (Helmut Januschka) Date: Wed, 15 Jan 2014 13:20:53 -0800 Subject: SF.net feature request #3574197 (#27) In-Reply-To: References: Message-ID: ok merged in upstream/master and dermoth/pu - switchet to monitoring-plugins - any chances this is going to get merged? --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/27#issuecomment-32416247 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at zedat.fu-berlin.de Thu Jan 16 01:12:27 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 16 Jan 2014 01:12:27 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins Message-ID: <20140116001227.GL700617@zedat.fu-berlin.de> As some of you might've noticed, we, the Nagios Plugins Development Team, renamed the "Nagios Plugins" to "Monitoring Plugins". Why? In the past, the domain "nagios-plugins.org" pointed to a server maintained by us, the Nagios Plugins Development Team. The domain itself had been transferred to Nagios Enterprises a few years ago, but we had an agreement that the project would continue to be independently run by the actual plugin maintainers.? Yesterday, the DNS records were modified to point to web space controlled by Nagios Enterprises instead. This change was done without prior notice. To make things worse, large parts of our web site were copied and are now served (with slight modifications?) by . Again, this was done without contacting us, and without our permission. This means we cannot use the name "Nagios Plugins" any longer. We're not too happy having to rename the project. This will lead to some confusion, and to quite a bit of work for others and for ourselves. We would've preferred to save everyone this trouble. One of the unfortunate consequences is that we had to change the mailing list addresses *again*: They now all use the "monitoring-plugins.org" domain instead of "nagios-plugins.org". We're really sorry for this inconvenience, but the issue is beyond our control. While we don't like the idea of sending password reminders on a regular basis, we'll trigger them once for all our mailing lists within the next 48 hours, so that you can easily unsubscribe should you prefer doing so. That said, we *do* like how the "Monitoring Plugins" name indicates that our plugins are also used by various other projects these days. While the Nagios folks created the original implementation of the core plugins bundle, an independent team has taken over development more than a decade ago, and the product is intended to be useful for *all* users, including, but not limited to, the customers of Nagios Enterprises. It'll probably take us a few days to sort out various issues caused by the new project name, but we're confident that we can resume our development work towards the next stable releases very soon. The new web site is already up and running: We'd like to take the chance to thank you, our community, for your countless contributions, which made the plugins what they are today. You guys are awesome. We're looking forward to the next chapter of Monitoring Plugins development, and we hope you are, too! ? See . ? E.g., no longer mentions Icinga, Shinken, and Naemon. From Stephan.Hradek at gmx.net Thu Jan 16 08:11:24 2014 From: Stephan.Hradek at gmx.net (Stephan Hradek) Date: Thu, 16 Jan 2014 08:11:24 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <20140116001227.GL700617@zedat.fu-berlin.de> References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: <52D7861C.6010409@gmx.net> Am 16.01.14 01:12, schrieb Holger Wei?: > To make things worse, large parts of our web site were copied and are > now served (with slight modifications?) by . > Again, this was done without contacting us, and without our permission. Did you tell them that you don't want them to use your name on their site? Same question goes to: Jan Wagner (Patch Review, Development) Matthias Eble (Patch Review, Development) Sven Nierlein (Patch Review, Development) Thomas Guyot-Sionnest (Patch Review, Development) Ton Voon (Patch Review, Development) From waja at cyconet.org Thu Jan 16 17:30:52 2014 From: waja at cyconet.org (Jan Wagner) Date: Thu, 16 Jan 2014 17:30:52 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <52D7861C.6010409@gmx.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <52D7861C.6010409@gmx.net> Message-ID: <52D8093C.1070501@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.01.14 08:11, schrieb Stephan Hradek: > Am 16.01.14 01:12, schrieb Holger Wei?: >> To make things worse, large parts of our web site were copied and >> are now served (with slight modifications?) by >> . Again, this was done without >> contacting us, and without our permission. > > Did you tell them that you don't want them to use your name on > their site? > > Same question goes to: > > Jan Wagner (Patch Review, Development) Matthias Eble (Patch Review, > Development) Sven Nierlein (Patch Review, Development) Thomas > Guyot-Sionnest (Patch Review, Development) Ton Voon (Patch Review, > Development) The question is, who (and how) should be contacted, there is no contact (beside our copied ones) available there. The only way is to send a mail to the domain registrant mail contact. Cheers, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLYCTwACgkQ9u6Dud+QFyRMvgCeLWZSZm8RHUJ05EZJjr3Q2kIL mxoAoMi/WAmqkcDu/0VtJ8Bnut04dBXV =gVHt -----END PGP SIGNATURE----- From lvl at omnitec.net Thu Jan 16 22:48:02 2014 From: lvl at omnitec.net (L. V. Lammert) Date: Thu, 16 Jan 2014 15:48:02 -0600 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <20140116001227.GL700617@zedat.fu-berlin.de> References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: <201401162147.s0GLlqvL018286@Mail.omnitec.net> At 06:12 PM 1/15/2014, Holger Wei? wrote: >As some of you might've noticed, we, the Nagios Plugins Development >Team, renamed the "Nagios Plugins" to "Monitoring Plugins". > >Why? Yes, Why? Seems like Nagios has a slightly different opinion, ... why can't you guys play nice? Lee ===============: This is true though we have another team in place now. This had to do with the current team getting out of control and not responding to us at all. We simply can't allow others with connections to competing companies harm the Nagios name. There will still be a plugins team and it will be the exact same GitHub account even. I read their post and it was misleading at best. We emailed them in the past about certain thing's and told them that it needed to be corrected. We never received a response back from them so we had to take back control of the site. We have another team in place and are always looking for more contributors if you interested in submitting patches. Regards, Mike O'keefe ___ Nagios Enterprises, LLC Email: sales at nagios.com Phone: (888)624-4671 Fax: (651)204-9103 Web: www.nagios.com >In the past, the domain "nagios-plugins.org" pointed to a server >maintained by us, the Nagios Plugins Development Team. The domain >itself had been transferred to Nagios Enterprises a few years ago, but >we had an agreement that the project would continue to be independently >run by the actual plugin maintainers.? Yesterday, the DNS records were >modified to point to web space controlled by Nagios Enterprises instead. >This change was done without prior notice. > >To make things worse, large parts of our web site were copied and are >now served (with slight modifications?) by . >Again, this was done without contacting us, and without our permission. > >This means we cannot use the name "Nagios Plugins" any longer. > >We're not too happy having to rename the project. This will lead to >some confusion, and to quite a bit of work for others and for ourselves. >We would've preferred to save everyone this trouble. > >One of the unfortunate consequences is that we had to change the mailing >list addresses *again*: They now all use the "monitoring-plugins.org" >domain instead of "nagios-plugins.org". We're really sorry for this >inconvenience, but the issue is beyond our control. While we don't like >the idea of sending password reminders on a regular basis, we'll trigger >them once for all our mailing lists within the next 48 hours, so that >you can easily unsubscribe should you prefer doing so. > >That said, we *do* like how the "Monitoring Plugins" name indicates that >our plugins are also used by various other projects these days. While >the Nagios folks created the original implementation of the core plugins >bundle, an independent team has taken over development more than a >decade ago, and the product is intended to be useful for *all* users, >including, but not limited to, the customers of Nagios Enterprises. > >It'll probably take us a few days to sort out various issues caused by >the new project name, but we're confident that we can resume our >development work towards the next stable releases very soon. The new >web site is already up and running: > > > >We'd like to take the chance to thank you, our community, for your >countless contributions, which made the plugins what they are today. >You guys are awesome. We're looking forward to the next chapter of >Monitoring Plugins development, and we hope you are, too! > >? See . >? E.g., no longer mentions Icinga, Shinken, > and Naemon. From michael.friedrich at gmail.com Thu Jan 16 23:50:47 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Thu, 16 Jan 2014 23:50:47 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162147.s0GLlqvL018286@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> Message-ID: <52D86247.5030208@gmail.com> On 16.01.2014 22:48, L. V. Lammert wrote: > At 06:12 PM 1/15/2014, Holger Wei? wrote: >> As some of you might've noticed, we, the Nagios Plugins Development >> Team, renamed the "Nagios Plugins" to "Monitoring Plugins". >> >> Why? > > Yes, Why? Seems like Nagios has a slightly different opinion, ... why > can't you guys play nice? Because Nagios Enterprises tries to censor every mention of any fork. Mention Icinga on your website containing nagios in your domain, say nagios-portal.org - ban hammer & domain lost. Claim Icinga copyright on your patches at tracker.nagios.org - banned. Wikipedia article mentions Icinga and other forks - Nagios Enterprise users edit the page and get banned by Wikipedia for being a sock puppet. More on that fights at http://www.freesoftwaremagazine.com/comment/79247#comment-79247 Kicking Andreas Ericsson out of the Nagios Core development team, who wrote 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to see the full presentation from last years OSMC: http://www.youtube.com/watch?v=YgbbyyNIiHc ) ** Rather ask Nagios Enterprises if the value of defending their trademark is worth loosing a community full of qualified developers & users. ** I welcome and appreciate the project's decision to overcome the censorship enforced by Nagios Enterprises and freely commit to Nagios and its forks - Icinga, Shinken, Naemon, Centreon Engine, Opsview, etc That makes me believe that this project is _free_ and follows the true open source community spirit - it keeps me motivated to start sending them patches from which i've stepped back in the past due to the unclear situation. That's my personal opinion, not my Icinga one. best regards, Michael PS: I've taken the liberty to notify package maintainers about the changed upstream url. https://bugzilla.redhat.com/show_bug.cgi?id=1054340 https://bugzilla.novell.com/show_bug.cgi?id=859105 http://www.freebsd.org/cgi/query-pr.cgi?pr=185829 OpenBSD response: "I've updated URLs, thanks for pointing this out." https://bugs.gentoo.org/show_bug.cgi?id=498292 https://aur.archlinux.org/packages/nagios-plugins/ -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org From psychotrahe at gmail.com Thu Jan 16 23:51:29 2014 From: psychotrahe at gmail.com (Matthias Eble) Date: Thu, 16 Jan 2014 23:51:29 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162147.s0GLlqvL018286@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> Message-ID: Am 16.01.2014 22:48 schrieb "L. V. Lammert" : > > At 06:12 PM 1/15/2014, Holger Wei? wrote: >> >> As some of you might've noticed, we, the Nagios Plugins Development >> Team, renamed the "Nagios Plugins" to "Monitoring Plugins". >> >> Why? > > > Yes, Why? Seems like Nagios has a slightly different opinion, ... why can't you guys play nice? I think, everybody who followed the na*ios community in the last years knows how to judge the situation. And we, as plugin team have been neutral and good willing for so long time. Even after it was clear that strange things happen everywhere around us in the community. It remains to be seen how long the word na*ios will have a meaning in floss monitoring. And it's a shame! Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at leibzon.org Fri Jan 17 00:03:22 2014 From: william at leibzon.org (William Leibzon) Date: Thu, 16 Jan 2014 15:03:22 -0800 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <20140116001227.GL700617@zedat.fu-berlin.de> References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: I think this is a right decision given their actions that were done without consultation with the project. However I also think there should have been some private discussions with Nagios before doing it but it should have been done unless they agreed to keep things as they were. On Wed, Jan 15, 2014 at 4:12 PM, Holger Wei? wrote: > As some of you might've noticed, we, the Nagios Plugins Development > Team, renamed the "Nagios Plugins" to "Monitoring Plugins". > > Why? > > In the past, the domain "nagios-plugins.org" pointed to a server > maintained by us, the Nagios Plugins Development Team. The domain > itself had been transferred to Nagios Enterprises a few years ago, but > we had an agreement that the project would continue to be independently > run by the actual plugin maintainers.? Yesterday, the DNS records were > modified to point to web space controlled by Nagios Enterprises instead. > This change was done without prior notice. > > To make things worse, large parts of our web site were copied and are > now served (with slight modifications?) by . > Again, this was done without contacting us, and without our permission. > > This means we cannot use the name "Nagios Plugins" any longer. > > We're not too happy having to rename the project. This will lead to > some confusion, and to quite a bit of work for others and for ourselves. > We would've preferred to save everyone this trouble. > > One of the unfortunate consequences is that we had to change the mailing > list addresses *again*: They now all use the "monitoring-plugins.org" > domain instead of "nagios-plugins.org". We're really sorry for this > inconvenience, but the issue is beyond our control. While we don't like > the idea of sending password reminders on a regular basis, we'll trigger > them once for all our mailing lists within the next 48 hours, so that > you can easily unsubscribe should you prefer doing so. > > That said, we *do* like how the "Monitoring Plugins" name indicates that > our plugins are also used by various other projects these days. While > the Nagios folks created the original implementation of the core plugins > bundle, an independent team has taken over development more than a > decade ago, and the product is intended to be useful for *all* users, > including, but not limited to, the customers of Nagios Enterprises. > > It'll probably take us a few days to sort out various issues caused by > the new project name, but we're confident that we can resume our > development work towards the next stable releases very soon. The new > web site is already up and running: > > > > We'd like to take the chance to thank you, our community, for your > countless contributions, which made the plugins what they are today. > You guys are awesome. We're looking forward to the next chapter of > Monitoring Plugins development, and we hope you are, too! > > ? See . > ? E.g., no longer mentions Icinga, Shinken, > and Naemon. From waja at cyconet.org Fri Jan 17 00:21:21 2014 From: waja at cyconet.org (Jan Wagner) Date: Fri, 17 Jan 2014 00:21:21 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162147.s0GLlqvL018286@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> Message-ID: <52D86971.3010602@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, Am 16.01.2014 22:48, schrieb L. V. Lammert: > At 06:12 PM 1/15/2014, Holger Wei? wrote: >> As some of you might've noticed, we, the Nagios Plugins >> Development Team, renamed the "Nagios Plugins" to "Monitoring >> Plugins". >> >> Why? > > Yes, Why? Seems like Nagios has a slightly different opinion, ... > why sorry, but in all that light it's not surprising that "Nagios Enterprises, LLC" has another opinion. They base (parts of) their business on the work of the Plugins Developers without contributing anything back. > can't you guys play nice? Play nice? From my point of view all actions was public, even when representatives of "Nagios Enterprises, LLC" tried to force the developers things to do or even not. > Lee > > ===============: > > > This is true though we have another team in place now. This had to > do with the current team getting out of control and not responding > to us at all. We simply can't allow others with connections to > competing companies harm the Nagios name. There will still be a > plugins team and it will be the exact same GitHub account even. "Out of control" for just developing and maintaining a peace of software that "Nagios Enterprises, LLC" is using and has "na*ios" in it's name? For just naming some of the projects which are compatible with the plugins on the website?!? > I read their post and it was misleading at best. We emailed them in > the past about certain thing's and told them that it needed to be > corrected. We never received a response back from them so we had to > take back control of the site. Why is this statement not send to the developers team? There are written things, just without a proof of it or even pointing to the sources. That's just all FUD about, as long as "Nagios Enterprises, LLC" can't proof otherwise. > We have another team in place and are always looking for more > contributors if you interested in submitting patches. I hope it will be more patches, then the plugins projects has recieved from "Nagios Enterprises, LLC" representatives! With kind regards, Jan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFS2Glt9u6Dud+QFyQRArFdAKDE+o+Kapn3n3qt+kjZixBkZNX/YwCbBOpJ 8vdijbZLkHxvuaSlwbFqFNw= =fudB -----END PGP SIGNATURE----- From william at leibzon.org Fri Jan 17 00:49:48 2014 From: william at leibzon.org (William Leibzon) Date: Thu, 16 Jan 2014 15:49:48 -0800 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <52D86247.5030208@gmail.com> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86247.5030208@gmail.com> Message-ID: On Thu, Jan 16, 2014 at 2:50 PM, Michael Friedrich wrote: > On 16.01.2014 22:48, L. V. Lammert wrote: >> >> At 06:12 PM 1/15/2014, Holger Wei? wrote: >>> >>> As some of you might've noticed, we, the Nagios Plugins Development >>> Team, renamed the "Nagios Plugins" to "Monitoring Plugins". >>> >>> Why? >> >> >> Yes, Why? Seems like Nagios has a slightly different opinion, ... why >> can't you guys play nice? > > Because Nagios Enterprises tries to censor every mention of any fork. > Mention Icinga on your website containing nagios in your domain, say > nagios-portal.org - ban hammer & domain lost. Claim Icinga copyright on your > patches at tracker.nagios.org - banned. Wikipedia article mentions Icinga > and other forks - Nagios Enterprise users edit the page and get banned by > Wikipedia for being a sock puppet. More on that fights at > http://www.freesoftwaremagazine.com/comment/79247#comment-79247 I'll give you my personal opinion since we're discussing it. I think this all started with people at Netways. I was under the opinion that they way they were doing things (with nagiosexchange but also a few other projects) was as if they were trying to take project away Ethan while promoting their own software and company. I was very reluctant to add my plugins to their site because it was not official nagios and they were promoting themselves too much. I also had private discussions with them in regards to some of my own work and they refused to allow me to contribute unless I give up copyright to them, which I refused because this is not how its done in open-source unless copyright holder is a neutral organization. At the time ICINGA appeared there were also quite a few other software packages based on nagios that did not actually fork it. There was no need to fork and force the issue. And that it happened got Ethan really really irritated and strongly in favor of keeping nagios private for his own company. > Kicking Andreas Ericsson out of the Nagios Core development team, who wrote > 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to > see the full presentation from last years OSMC: > http://www.youtube.com/watch?v=YgbbyyNIiHc ) Andreas did major rework on nagios3->nagios4. Its really good work. But he is really hard on policing what goes into core and not allowing fully joined development. This happens in open-source regularly when lead developer is a bit of a nazi but this does not promote cooperation and growth of the project and without new developers project stagnates. I told him all that privately. All that said kicking him off core team was absolutely wrong thing to do, and shows Nagios & Ethan's interest in keeping project private rather than truly open-source. There were other solutions available that would not cause yet another split in the community. Some time ago in private I tried proposing having a technical review/advisory board of about 5 people so that there would not be one person making decisions on the core and the decisions and work on the core would be more transparent to the open-source community. There was not enough interest and without multiple people a board like this a split was not surprising. I'm quite disappointed how because of their personal egos and/or business interests the developers couldn't work together to continue the project in open-source collaborative way. Multiple forks is bad for everyone and actually means less contributions and development. Notice how Shinken does not have this issue where as original nagios core code development does. > ** Rather ask Nagios Enterprises if the value of defending their trademark > is worth loosing a community full of qualified developers & users. ** > > I welcome and appreciate the project's decision to overcome the censorship > enforced by Nagios Enterprises and freely commit to Nagios and its forks - > Icinga, Shinken, Naemon, Centreon Engine, Opsview, etc > > That makes me believe that this project is _free_ and follows the true open > source community spirit - it keeps me motivated to start sending them > patches from which i've stepped back in the past due to the unclear > situation. I've stepped back from working on Nagios core code work because of how people who control its development have been acting. But I basically have my own fork, I just keep it private for my own customers use only. For now until things are more clear I'm not sending any patches to anyone. Do note that unlike many people involved, I'm someone who does not have commercial interest with any of these companies or projects. I do private consulting and can work with any of the projects. And all this is < 20% of my time as I'm not full-time devops with any company or full-time open-source developer. This is just something extra I kept being involved in when I went to academia because I liked nagios. But all this drama will make me rethink if I should continue and in what way despite that I've been involved in nagios in some way for over 10 years. Again, this is just my own personal opinion. And I do hope things get together in this community. P.S. One other thing I've been unhappy about with Nagios was their decision to drop mail lists. I don't have the time to read forums and as an "old school" open-source person I like mail lists. Not that I comment that often anyway but major things I do read on. > That's my personal opinion, not my Icinga one. > > best regards, > Michael > > PS: I've taken the liberty to notify package maintainers about the changed > upstream url. > > https://bugzilla.redhat.com/show_bug.cgi?id=1054340 > https://bugzilla.novell.com/show_bug.cgi?id=859105 > http://www.freebsd.org/cgi/query-pr.cgi?pr=185829 > OpenBSD response: "I've updated URLs, thanks for pointing this out." > https://bugs.gentoo.org/show_bug.cgi?id=498292 > https://aur.archlinux.org/packages/nagios-plugins/ > -- > DI (FH) Michael Friedrich > > mail: michael.friedrich at gmail.com > twitter: https://twitter.com/dnsmichi > jabber: dnsmichi at jabber.ccc.de > irc: irc.freenode.net/icinga dnsmichi > > icinga open source monitoring > position: lead core developer > url: https://www.icinga.org > From lvl at omnitec.net Fri Jan 17 00:57:53 2014 From: lvl at omnitec.net (L. V. Lammert) Date: Thu, 16 Jan 2014 17:57:53 -0600 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <52D86971.3010602@cyconet.org> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86971.3010602@cyconet.org> Message-ID: <201401162357.s0GNvgvL020187@Mail.omnitec.net> At 05:21 PM 1/16/2014, Jan Wagner wrote: > > can't you guys play nice? > >Play nice? From my point of view all actions was public, even when >representatives of "Nagios Enterprises, LLC" tried to force the >developers things to do or even not. "Play Nice" from the standpoint that this is the first the lists heard of any discord. "Play Nice" from the standpoint of acknowledging that different team members have different views, objectives, and resources. "Play Nice" from the standpoint of appearing like a nice, cohesive project for the muggles. >"Out of control" for just developing and maintaining a peace of >software that "Nagios Enterprises, LLC" is using and has "na*ios" in >it's name? For just naming some of the projects which are compatible >with the plugins on the website?!? If it were that simple, it would seem possible to work out the issues, would it not? > > I read their post and it was misleading at best. We emailed them in > > the past about certain thing's and told them that it needed to be > > corrected. We never received a response back from them so we had to > > take back control of the site. > >Why is this statement not sent to the developers team? If you did not receive it, that would seem to point to bad communications? Of course there are two sides to the story, and the do not need to be aired on a public list. The point is that Nagios is not really the "dark side", rather from a user perspective it seems like the do try to support the OS community in many ways; the fact that it IS possible to fork a project just means that another option exists for the community. It does not mean that it is the best solution to the problem. In this case, forks do the Nagios community a disservice, as having five or six Monitoring projects and code bases is just is an indication of a fractured community where folks can "take the only baseball to another field". Not many users are going to switch projects just because there is somebody or something they don't like - they have to stick with the original project as long as it has not been abandoned or trashed in some way. In addition, the fact that there IS a commercial project is a big benefit in that is makes the entire project visible, which makes it possible for commercial users to contribute - *especially* when they want something done and they pay a developer to solve a problem that is then added back to the project. > > We have another team in place and are always looking for more > > contributors if you interested in submitting patches. > >I hope it will be more patches, then the plugins projects has recieved >from "Nagios Enterprises, LLC" representatives! >With kind regards, Jan. That would be a nice goal, but it probably won't happen - it doesn't make sense for Nagios to push patches to a forked project, does it? *Especially* since that forked project probably is no longer compatible? All that produces is a bunch of unsupported forks, which dilutes the pool of talented folks that DO wish to contribute. Just an outside view, .. please accept as intended. I like the Nagios project, and have enjoyed the benefits of Core while watching XI and seeing what the commercial side is going. Thanks!! Lee From michael.friedrich at gmail.com Fri Jan 17 01:54:50 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Fri, 17 Jan 2014 01:54:50 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86247.5030208@gmail.com> Message-ID: <52D87F5A.6070707@gmail.com> On 17.01.2014 00:49, William Leibzon wrote: > On Thu, Jan 16, 2014 at 2:50 PM, Michael Friedrich > wrote: >> On 16.01.2014 22:48, L. V. Lammert wrote: >>> At 06:12 PM 1/15/2014, Holger Wei? wrote: >>>> As some of you might've noticed, we, the Nagios Plugins Development >>>> Team, renamed the "Nagios Plugins" to "Monitoring Plugins". >>>> >>>> Why? >>> >>> Yes, Why? Seems like Nagios has a slightly different opinion, ... why >>> can't you guys play nice? >> Because Nagios Enterprises tries to censor every mention of any fork. >> Mention Icinga on your website containing nagios in your domain, say >> nagios-portal.org - ban hammer & domain lost. Claim Icinga copyright on your >> patches at tracker.nagios.org - banned. Wikipedia article mentions Icinga >> and other forks - Nagios Enterprise users edit the page and get banned by >> Wikipedia for being a sock puppet. More on that fights at >> http://www.freesoftwaremagazine.com/comment/79247#comment-79247 > I'll give you my personal opinion since we're discussing it. > > I think this all started with people at Netways. I was under the > opinion that they way they were doing things (with nagiosexchange but > also a few other projects) was as if they were trying to take project > away Ethan while promoting their own software and company. I was very > reluctant to add my plugins to their site because it was not official > nagios and they were promoting themselves too much. I also had private > discussions with them in regards to some of my own work and they > refused to allow me to contribute unless I give up copyright to them, > which I refused because this is not how its done in open-source unless > copyright holder is a neutral organization. At the time ICINGA > appeared there were also quite a few other software packages based on > nagios that did not actually fork it. There was no need to fork and > force the issue. I joined the Icinga project a month after their fork looking for a way to bring Oracle support into NDOUtils. Looking back at all those years with Icinga now, leading the Core development and having fun in my spare time, it was the best decision ever made, and I've learnt a lot during these times. I do know that people start to think that a company promoting their addons and additions around Nagios (or Icinga even) is bad. I've experienced that most of the time when talking to people about Icinga. They approached me with things like being abused by Netways. Which is a total negative association - you'll put your energy and motivation into a project for your personal pleasure and leisure activities. But not to work for someone for free. At least I was *never* under the impression to do so. I probably do know more than anyone else in the community about what Netways invested into the community, providing stable platforms such as monitoringexchange, or plenty of useful addons and plugins. Just like other companies in this sector, like consol does. Maybe just because I've asked Julian and Bernd about all those rumors instead of trusting someone claiming that their intentions are evil and bad. Though it's sad to see that there's still the opinion that someone started something. The real problem is much more different - when you want to build your stuff based on a software developed by someone not responding (or slowly even), you'll either live with it, or you'll copy the code and patch it yourself. Looking at the nagios-devel mailinglist archives and all the patches I've collected into Icinga, the impression was that every patch sender has a local fork of Nagios anyways. Being responsive isn't always easy, especially when you lost focus and motivation. And that won't get better when you'll see your "friends" earning money with the product you're developing in your spare time. People start to even insult you for not responding. Like it happened some months ago on the repoforge mailinglists, where Dag luckily responded after all those blamings (sad to see). In the end I'd say it was a mix of the nagios community demanding too much and too fast for nagios3 which started the things getting worse, and also the single developer "failure". > And that it happened got Ethan really really > irritated and strongly in favor of keeping nagios private for his own > company. Keeping something private has nothing to do with enforcing trademarks in way of censoring every occurence of bad words. Ok, the fork was bad. But hey, we could've lived side-by-side, sharing patches amongst each other. But when your patch gets corrected just because you've sent it under the Icinga hat? Well, that's *very* strange and imho not into the right direction. Comparison charts could've been answered with straight forward comparison charts themselves, instead of spreading FUD about non existing ip violations. The list is rather endless what could be gone wrong. And i'm not saying that Icinga is the good guy in the story. In the very beginning, telling that Nagios is bad, and Icinga is better, worked quite well. But after a while you'll go figure that people don't like the "blame nagios" habit, and you'll change in sharing what Icinga can do with your social media channels. See, it works even better. But that's just Icinga. Why has it happened to other projects as well? Why was adagios removed from nagios exchange? Is it ok to fork existing community projects like NagTrap (NSTI), TeenyNagios (Nagios Mobile), NagioSQL (CCM) just because you've created the Nagios core project, and take something back, while on the other hand creating licenses that forbid you to fork the project? That doesn't fit into being honest with the community imho. And it's no wonder how Nagios Enterprises (whoever may be responsible for that dick move) treats the Monitoring Plugins developers, copies their website and leaves the _user_ without any information, replacing unwanted opinions and developers. That's something you could do if you pay for them and their dayjob. But actually it's their fucking spare time and they want to be treated like people, and not some unwanted "thing". > >> Kicking Andreas Ericsson out of the Nagios Core development team, who wrote >> 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to >> see the full presentation from last years OSMC: >> http://www.youtube.com/watch?v=YgbbyyNIiHc ) > Andreas did major rework on nagios3->nagios4. Its really good work. > But he is really hard on policing what goes into core and not allowing > fully joined development. This happens in open-source regularly when > lead developer is a bit of a nazi but this does not promote > cooperation and growth of the project and without new developers > project stagnates. I told him all that privately. It doesn't hurt to control the architecture and quality process. But it hurts the project if it's just one leader, that's true. > > All that said kicking him off core team was absolutely wrong thing to > do, and shows Nagios & Ethan's interest in keeping project private > rather than truly open-source. The fact that I've extracted from all those happenings was that the XI product still uses Nagios 3 and the OSS version with Nagios 4 would just been better than the commercial version performance wise. So more of a product strategy decision which wasn't really the best idea given the recent happenings. Well, the reaction closing down the mailinglists and kicking him out leaves nothing more to add. > There were other solutions available > that would not cause yet another split in the community. Some time ago > in private I tried proposing having a technical review/advisory board > of about 5 people so that there would not be one person making > decisions on the core and the decisions and work on the core would be > more transparent to the open-source community. There was not enough > interest and without multiple people a board like this a split was not > surprising. People are lazy (and slow even). That doesn't work well with the monitoring community, maybe other communities do better. Though, the idea is great. > > I'm quite disappointed how because of their personal egos and/or > business interests the developers couldn't work together to continue > the project in open-source collaborative way. Multiple forks is bad > for everyone and actually means less contributions and development. > Notice how Shinken does not have this issue where as original nagios > core code development does. Shinken got other problems which are in the nature of how they organize development. But that's the fun with these projects - learn & get better. In terms of Icinga and Naemon sharing the code base with Nagios, you're probably right about that. But to be honest - that's history. Either you choose to fix the code, and rewrite it (Andreas had a slide on OSMC with ~35% of the code being rewritten). In Icinga 2 we made a radical decision in throwing away the old Nagios code and implementing everything from scratch. Well, not really me, but Gunnar did a magnificent job on that. And I know what people say - why C++? Why not Java/C/whateverlanguage? Why not asking Naemon devs to join forces? Apparently that question was after each presentation on that wednesday. Different interests and goals. And the most important part - everyone wants to act *independant* from a dictatorship like seen with Nagios. > >> ** Rather ask Nagios Enterprises if the value of defending their trademark >> is worth loosing a community full of qualified developers & users. ** >> >> I welcome and appreciate the project's decision to overcome the censorship >> enforced by Nagios Enterprises and freely commit to Nagios and its forks - >> Icinga, Shinken, Naemon, Centreon Engine, Opsview, etc >> >> That makes me believe that this project is _free_ and follows the true open >> source community spirit - it keeps me motivated to start sending them >> patches from which i've stepped back in the past due to the unclear >> situation. > I've stepped back from working on Nagios core code work because of how > people who control its development have been acting. But I basically > have my own fork, I just keep it private for my own customers use > only. For now until things are more clear I'm not sending any patches > to anyone. That's too bad. Not that I add every patch to Icinga 1.x but I am interested in any valuable input that in regards. But I also understand your position, not liking the chaotic ecosystem now existing, especially with that code base available in different projects. That's btw also a reason for Icinga 2 - to abandon old bug history, and start off/over. Porting patches and reworking them is much more work, than designing and implementing own stuff. But I guess you already know that. > > Do note that unlike many people involved, I'm someone who does not > have commercial interest with any of these companies or projects. I do > private consulting and can work with any of the projects. And all this > is < 20% of my time as I'm not full-time devops with any company or > full-time open-source developer. This is just something extra I kept > being involved in when I went to academia because I liked nagios. But > all this drama will make me rethink if I should continue and in what > way despite that I've been involved in nagios in some way for over 10 > years. Hm yeah well. At some point such projects eat 200% of your spare time, while work says different stuff. My decision on getting closer with Icinga and sharing my expertise with customer projects was led by the most common problem these days - meet in either Vienna or Nuremberg for 3 days, hack away, talk, discuss and you'll get more stuff fixed than in 3 months. These days, we're doing this in the office, every day. And I really appreciate the fact that Netways pays me for developing Icinga 2 - it could've been my 200% spare time instead (so it's just some percentage for Icinga 1.x haha) And I do know the reactions, just as "Uh ah eh, your employee dictates the direction the project is heading". That's just bullshit, even if we've learnt otherwise from other companies dictating and controlling open source projects (that's one of the reasons why there will *never* exist any "Icinga Enterprise" or "Icinga Commercial Version" just because that's not our vision of an open source project). And if anyone thinks that my opinion is now influenced by my employer - good companies actually trust the expertise and opinion of their employees. I feel comfortable here in Nuremberg. > > Again, this is just my own personal opinion. And I do hope things get > together in this community. I'm hoping that the monitoring plugins project will receive their feedback just as usual, and all new users will recognize the new project name. It's always confusing acting under a new name, and being asked "why?" all the time. Probably the team should add a FAQ entry, sort of the "why a fork" entry we keep for historical reasons for icinga.org Other than that, even if Nagios gets lost in their enterprise cloud with their moderated forum, there's still the monitoring-portal.org where the community meets, unmoderated. > > P.S. One other thing I've been unhappy about with Nagios was their > decision to drop mail lists. I don't have the time to read forums and > as an "old school" open-source person I like mail lists. Not that I > comment that often anyway but major things I do read on. That's true. Only moving away from sourceforge is a necessary step given the recent ad-ware crap, but a local mailman isn't that hard to setup. We did that with lists.icinga.org last week. best regards, Michael > >> That's my personal opinion, not my Icinga one. >> >> best regards, >> Michael >> >> PS: I've taken the liberty to notify package maintainers about the changed >> upstream url. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1054340 >> https://bugzilla.novell.com/show_bug.cgi?id=859105 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=185829 >> OpenBSD response: "I've updated URLs, thanks for pointing this out." >> https://bugs.gentoo.org/show_bug.cgi?id=498292 >> https://aur.archlinux.org/packages/nagios-plugins/ >> -- >> DI (FH) Michael Friedrich >> >> mail: michael.friedrich at gmail.com >> twitter: https://twitter.com/dnsmichi >> jabber: dnsmichi at jabber.ccc.de >> irc: irc.freenode.net/icinga dnsmichi >> >> icinga open source monitoring >> position: lead core developer >> url: https://www.icinga.org >> -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org From holger at zedat.fu-berlin.de Fri Jan 17 02:06:46 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Fri, 17 Jan 2014 02:06:46 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162147.s0GLlqvL018286@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> Message-ID: <20140117010646.GC654350@zedat.fu-berlin.de> * L. V. Lammert [2014-01-16 15:48]: > At 06:12 PM 1/15/2014, Holger Wei? wrote: > >As some of you might've noticed, we, the Nagios Plugins Development > >Team, renamed the "Nagios Plugins" to "Monitoring Plugins". > > > >Why? > > Yes, Why? Seems like Nagios has a slightly different opinion, ... > why can't you guys play nice? I'll spare you from the stories that would illustrate how we tried our very best to do just that. I'll also spare you from my appreciation of notions such as "the current team getting out of control" when talking about the volunteers who took care of the actual plugin maintenance over the past several years. Instead, I'm going to respond with the simple facts that presumably led to the current happenings. I can only assure you that I'm not omitting anything relevant that I'm aware of, and that I'm not consciously misrepresenting anything. If anyone from Nagios Enterprises is reading this and believes that I got my facts wrong, please let us know. So here you go. A few months ago, Ethan Galstadt sent me a private email (instead of posting to our internal team@ list that he was also subscribed to). He asked me (personally) to remove the references to Icinga and Shinken from the following sentence on our home page (plus a link to an #Icinga IRC channel on the /support.html page): | We, the Nagios Plugins Development Team, maintain a bundle of more than | fifty standard plugins for Nagios, Icinga, Shinken, and other monitoring | applications. I talked to the other team members and sent a response the same day. If Nagios Enterprises continues to assert they got no response, I'm happy to compare mail server logs. Of course they received it. This was my response (with Ethan's text snipped): | Hi Ethan, | | > [...] | | for what it's worth, let me clarify that I'm not involved in either of | these projects. Personally, I use Nagios, and I have no plans on | switching to something else. I'm mentioning this just in case you're | worried the description on our web site might be a sign of a creeping | "hostile takeover" or something. It is not. | | That said, the Plugins team understands itself as independent of all | projects that use the Plugins, including Nagios itself. As far as I | know, you explicitly agreed with this stance. In my view, this would | include the definition of the purpose of the Nagios Plugins site; within | reasonable constraints, of course. | | It's obvious that mentioning competing products is not in the direct | interest of Nagios Enterprises, so I understand where you're coming | from. The issue is that our interest doesn't fully line up with yours. | While I'm not interested in causing Nagios Enterprises any financial | harm whatsoever, I work on the project in my free time (as opposed to | being paid for maximizing your profit), so I'm happy with anyone who | uses (and contributes to) the Plugins. The more users, the better. | | I would ask you to shrug this issue off as the price to pay for having a | team take care of the project in their free time. I'm not looking for | any sort of conflict, I'm trying to act fairly (e.g. by mentioning the | roots of the Plugins project in the first sentence on the home page), | and I hope you can live with this level of independence. | | Take care, Holger That's it. The next thing that happend was that they copied our web site and pointed to their web server. None of the team members is affiliated with any of the companies in question. We just think the text on our home page is an adequate description of the Plugins project, and that it's totally harmless. In retrospect, you might argue that keeping the text wasn't worth the mess, and I could understand such a viewpoint very well. However, while I can't speak for the other team members here, personally I just wouldn't have felt comfortable with letting Nagios Enterprises dictate such things upon the team. Anyway, I hope everyone will be able to form his or her own opinion now. Let me add one unrelated note to Mike: >> There will still be a plugins team and it will be the exact same >> GitHub account even. Indeed. We made that possible by renaming our GitHub account immediately. You're welcome. However, you recreated a Git repository from scratch, thereby abandoning the complete commit history (which dates back to Ethan's initial CVS commit). May I suggest you base your repository on ours instead? That would make it easier for you and your contributors to work with the repository, and it wouldn't give those that look into the details such a bad impression. Holger From holger at zedat.fu-berlin.de Fri Jan 17 02:22:41 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Fri, 17 Jan 2014 02:22:41 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: <20140117012241.GD654350@zedat.fu-berlin.de> * William Leibzon [2014-01-16 15:03]: > However I also think there should have been some private discussions > with Nagios before doing it but it should have been done unless they > agreed to keep things as they were. You mean we should've talked to Nagios Enterprises after we noticed that they silently changed the DNS records to point to web space which served a sligtly modified version of our home page? Sorry, but at that point, there was *no* doubt whatsoever that Nagios Enterprises had decided to take over the project. I'm sure they would confirm this if you asked them. Holger From holger at zedat.fu-berlin.de Fri Jan 17 02:46:12 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Fri, 17 Jan 2014 02:46:12 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162357.s0GNvgvL020187@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86971.3010602@cyconet.org> <201401162357.s0GNvgvL020187@Mail.omnitec.net> Message-ID: <20140117014612.GE654350@zedat.fu-berlin.de> * L. V. Lammert [2014-01-16 17:57]: > Of course there are two sides to the story [...]. Actually, I disagree here. Sometimes, there's just one side acting beyond the pale. It's just often hard to judge on this when you're not involved. Holger From robin.sonefors at op5.com Fri Jan 17 10:36:29 2014 From: robin.sonefors at op5.com (Robin Sonefors) Date: Fri, 17 Jan 2014 10:36:29 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86247.5030208@gmail.com> Message-ID: <52D8F99D.4080607@op5.com> On 2014-01-17 00:49, William Leibzon wrote: > On Thu, Jan 16, 2014 at 2:50 PM, Michael Friedrich >> Kicking Andreas Ericsson out of the Nagios Core development team, who wrote >> 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to >> see the full presentation from last years OSMC: >> http://www.youtube.com/watch?v=YgbbyyNIiHc ) > > Andreas did major rework on nagios3->nagios4. Its really good work. > But he is really hard on policing what goes into core and not allowing > fully joined development. This happens in open-source regularly when > lead developer is a bit of a nazi but this does not promote > cooperation and growth of the project and without new developers > project stagnates. I told him all that privately. (I'm getting off-topic, but you used the N-word about my friend, so...) The amusing thing is, while working on Nagios, Andreas was unable to give others commit access, which meant he had to read and review a lot of patches by himself. Some got lost, some weren't received as warmly as they perhaps should/could have, reviewing patches is *boring*. Now that he works on Naemon, others - like myself - have permissions to review and apply patches as well. So, somewhat counter-intuitively, the project initiated by said "nazi" should be better at promoting cooperation. Sometimes, a bad outcome is the result of being given bad tools to work with. From ae at op5.se Fri Jan 17 17:30:39 2014 From: ae at op5.se (Andreas Ericsson) Date: Fri, 17 Jan 2014 17:30:39 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86247.5030208@gmail.com> Message-ID: <52D95AAF.5000901@op5.se> On 2014-01-17 00:49, William Leibzon wrote: > On Thu, Jan 16, 2014 at 2:50 PM, Michael Friedrich > wrote: >> On 16.01.2014 22:48, L. V. Lammert wrote: >>> >>> At 06:12 PM 1/15/2014, Holger Wei? wrote: >>>> >>>> As some of you might've noticed, we, the Nagios Plugins Development >>>> Team, renamed the "Nagios Plugins" to "Monitoring Plugins". >>>> >>>> Why? >>> >>> >>> Yes, Why? Seems like Nagios has a slightly different opinion, ... why >>> can't you guys play nice? >> >> Because Nagios Enterprises tries to censor every mention of any fork. >> Mention Icinga on your website containing nagios in your domain, say >> nagios-portal.org - ban hammer & domain lost. Claim Icinga copyright on your >> patches at tracker.nagios.org - banned. Wikipedia article mentions Icinga >> and other forks - Nagios Enterprise users edit the page and get banned by >> Wikipedia for being a sock puppet. More on that fights at >> http://www.freesoftwaremagazine.com/comment/79247#comment-79247 > > I'll give you my personal opinion since we're discussing it. > > I think this all started with people at Netways. I was under the > opinion that they way they were doing things (with nagiosexchange but > also a few other projects) was as if they were trying to take project > away Ethan while promoting their own software and company. I was very > reluctant to add my plugins to their site because it was not official > nagios and they were promoting themselves too much. I also had private > discussions with them in regards to some of my own work and they > refused to allow me to contribute unless I give up copyright to them, > which I refused because this is not how its done in open-source unless > copyright holder is a neutral organization. At the time ICINGA > appeared there were also quite a few other software packages based on > nagios that did not actually fork it. There was no need to fork and > force the issue. And that it happened got Ethan really really > irritated and strongly in favor of keeping nagios private for his own > company. > I first thought Netways were a bit too aggressive in their marketing, and I wasn't too fond of many of their technical decisions (such as using NDOUtils to get data and not addressing the pressing performance issues for large networks), but after what happened to me I realize that they were just an earlier version of me, and came from a corporate standpoint rather than a community developer one. >> Kicking Andreas Ericsson out of the Nagios Core development team, who wrote >> 99% of Nagios 4 and then let him fork Naemon? Priceless. (you might need to >> see the full presentation from last years OSMC: >> http://www.youtube.com/watch?v=YgbbyyNIiHc ) > > Andreas did major rework on nagios3->nagios4. Its really good work. > But he is really hard on policing what goes into core and not allowing > fully joined development. This happens in open-source regularly when > lead developer is a bit of a nazi but this does not promote > cooperation and growth of the project and without new developers > project stagnates. I told him all that privately. > True that. I've blocked more patches than I've let in, but I've never blocked a single patch without reading it properly, applying it and then thinking about how it affects other parts of everything. Most patches I've blocked have been blocked because they would force a version number bump, and only Ethan can do that (and he tends to do it with a one-day advance warning saying "Now's the codefreeze, so stop committing anything at all and we'll cut a major version tomorrow"). That means API-altering patches can't go in nilly-willy, or every single module would break randomly. Unfortunately, Nagios core is quite convoluted and messy to begin with, with several functions having a LoC-count in the thousands. Figuring out the sideeffects of changes is never easy in a project like that, and bugfixes (usually) aren't as obviously good as one would want. > All that said kicking him off core team was absolutely wrong thing to > do, and shows Nagios & Ethan's interest in keeping project private > rather than truly open-source. There were other solutions available > that would not cause yet another split in the community. Some time ago > in private I tried proposing having a technical review/advisory board > of about 5 people so that there would not be one person making > decisions on the core and the decisions and work on the core would be > more transparent to the open-source community. There was not enough > interest and without multiple people a board like this a split was not > surprising. > I was actually for that idea. The problem is that there already was a steering committee, which formed in 2008 and was never asked about anything at all. I was on it, as was Ton Voon (who was kicked from both core and plugins projects in 2011, I think) and neither of us got any steering power at all. Since Ethan would've had to approve of things like that, and Ethan is a professional procrastinator when it comes to making decisions that let others do anything at all with Nagios, it all fell through the cracks and noone could do anything about it. > I'm quite disappointed how because of their personal egos and/or > business interests the developers couldn't work together to continue > the project in open-source collaborative way. Multiple forks is bad > for everyone and actually means less contributions and development. > Notice how Shinken does not have this issue where as original nagios > core code development does. > Naemon doesn't either. We're averaging six new developers per month, which is quite good for such a young project :-) -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 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 michael.friedrich at gmail.com Fri Jan 17 17:38:22 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Fri, 17 Jan 2014 17:38:22 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <20140116001227.GL700617@zedat.fu-berlin.de> References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: <52D95C7E.5060802@gmail.com> fyi RHEL decided not to update anything trusting a comment by the new Nagios Plugin Development Team member (commits: 1). https://bugzilla.redhat.com/show_bug.cgi?id=1054340 -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org From ae at op5.se Fri Jan 17 17:54:40 2014 From: ae at op5.se (Andreas Ericsson) Date: Fri, 17 Jan 2014 17:54:40 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <201401162357.s0GNvgvL020187@Mail.omnitec.net> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86971.3010602@cyconet.org> <201401162357.s0GNvgvL020187@Mail.omnitec.net> Message-ID: <52D96050.60502@op5.se> On 2014-01-17 00:57, L. V. Lammert wrote: > At 05:21 PM 1/16/2014, Jan Wagner wrote: > >> > can't you guys play nice? >> >> Play nice? From my point of view all actions was public, even when >> representatives of "Nagios Enterprises, LLC" tried to force the >> developers things to do or even not. > > "Play Nice" from the standpoint that this is the first the lists heard > of any discord. "Play Nice" from the standpoint of acknowledging that > different team members have different views, objectives, and resources. > "Play Nice" from the standpoint of appearing like a nice, cohesive > project for the muggles. > >> "Out of control" for just developing and maintaining a peace of >> software that "Nagios Enterprises, LLC" is using and has "na*ios" in >> it's name? For just naming some of the projects which are compatible >> with the plugins on the website?!? > > If it were that simple, it would seem possible to work out the issues, > would it not? > >> > I read their post and it was misleading at best. We emailed them in >> > the past about certain thing's and told them that it needed to be >> > corrected. We never received a response back from them so we had to >> > take back control of the site. >> >> Why is this statement not sent to the developers team? > > If you did not receive it, that would seem to point to bad > communications? Of course there are two sides to the story, and the do > not need to be aired on a public list. > > The point is that Nagios is not really the "dark side", rather from a > user perspective it seems like the do try to support the OS community in > many ways; the fact that it IS possible to fork a project just means > that another option exists for the community. Except it comes at a cost. We've sent quite a lot of patches (bugfixes only) back to Nagios from Naemon. They're being ignored, which is sad, because if they fix bugs that Naemon also has, we'll have to sort out the mess of ignoring old bugs that we've already fixed, so we can't get the synergy that multiple similar projects should have (and that benefits the users). I should also mention that the same day I forked Nagios into Naemon, I got a message from Nagios Enterprises (well, one of its employees, but she's about as high up as you can get without being Ethan), saying "The real Andreas Ericsson has shown itself, and it is ugly." Ad hominem arguments for utilizing my freedom to fork code that I alone maintained for the past four years. How's that for "playing nice"? The fact of the matter is that I was treated as shit. Not because I'm a particularly horrible guy (I can be at times, but who can't?) or because of any technical reasons, or because op5 acted unethically or marketed Nagios aggressively. The fact of the matter is that people started associating Nagios development with me, to the point where people from all over the world actually came to visit op5.com to find supported Nagios-based solutions. That was obviously bad for Ethan and his company, so they had to get rid of me as fast as possible. And the weird part is that all that happened because I maintained the core for several years without Ethan having to pay a single cent for it. If he'd been clever, he would have utilized that fact in his marketing. "Hey, even our competitors are sponsoring our development. That's how fucking awesome we are!". Instead, paranoia was allowed to reign free and fear was allowed to make technical decisions. Never a good thing. > It does not mean that it > is the best solution to the problem. In this case, forks do the Nagios > community a disservice, as having five or six Monitoring projects and > code bases is just is an indication of a fractured community where folks > can "take the only baseball to another field". Not many users are going > to switch projects just because there is somebody or something they > don't like - they have to stick with the original project as long as it > has not been abandoned or trashed in some way. > Nagios was abandoned in 2007. That's why the forks popped up in 2009, when the mountain of patches had simply gotten too big. During those two years, I maintained a patch queue and a sort of "this is stuff I think is good, and I'll make sure Ethan looks at it when he can". That wasn't good enough, and when nothing still had happened in 2009, Icinga and Shinken came to life. Fun anecdote about shinken btw; It started as a discarded patch to Nagios, which me and Jean Gab?s mentally refactored into the scheduler + workers concept that gives such an amazing performance boost to Nagios 4 and Naemon. Ethan wouldn't let anyone near the code, so Jean hacked it up as a proof of concept that our brainstorming was sound. In short; Neglect and general assholeness from the part of Nagios Enterprises has been behind pretty much every fork. > In addition, the fact that there IS a commercial project is a big > benefit in that is makes the entire project visible, which makes it > possible for commercial users to contribute - *especially* when they > want something done and they pay a developer to solve a problem that is > then added back to the project. > You can't pay Nagios Enterprises to do anything at all. Lots of people have tried. You can pay them to use Nagios XI, which is inferior to every other Nagios-based solution I've seen in every respect imaginable. >> > We have another team in place and are always looking for more >> > contributors if you interested in submitting patches. >> >> I hope it will be more patches, then the plugins projects has recieved >> from "Nagios Enterprises, LLC" representatives! >> With kind regards, Jan. > > That would be a nice goal, but it probably won't happen - it doesn't > make sense for Nagios to push patches to a forked project, does it? No, but unless they close their sources it's easy for other projects to keep an eye on what they do and figure out if the patch should be applied to the fork as well. > *Especially* since that forked project probably is no longer compatible? Where did you get that idea? Most of the code in Naemon is identical to the one in Nagios, although we have a bit different layout on the source files since we want to be able to build modules directly from a checkout of Naemon. > All that produces is a bunch of unsupported forks, which dilutes the > pool of talented folks that DO wish to contribute. > Not really, no. I wrote 98.5% of all changes that went into Nagios 3 in order to make it Nagios 4. Another guy (Robin) at op5 wrote 0.5%, and a guy from Nagios Enterprises wrote 0.5%. The rest of the community shared the remaining 0.5%. The only thing that got diluted was Nagios itself, which lost at least 99% of its contributions when they kicked me out. -- Andreas Ericsson andreas.ericsson at op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 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 william at leibzon.org Sat Jan 18 02:45:49 2014 From: william at leibzon.org (William Leibzon) Date: Fri, 17 Jan 2014 17:45:49 -0800 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <20140116001227.GL700617@zedat.fu-berlin.de> References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: On Wed, Jan 15, 2014 at 4:12 PM, Holger Wei? wrote: > As some of you might've noticed, we, the Nagios Plugins Development > Team, renamed the "Nagios Plugins" to "Monitoring Plugins". .... > Is anyone working on updating README.md and other documentation to reflect new name and url? ----- Unrelated (sort-of): I will try to put together presentation on open-source monitoring for LA Devops and LA Linux meetups. I'm probably too busy in winter to do this, so it maybe pushed to May. And I'll also do this presentation for San Francisco devops people probably in September. I planned to do this presentation for some time on new features of Nagios 4, but given current status of things its going to be neutral (and I'm remaining neutral myself) and not about any one project. If people want to send me some slides about your project and features, feel free to do so. I will mention change of nagios-plugins to monitoring-plugins and will try to explain to people what is going on and why - people in two largest metro areas in California ought to know about "political" situation with nagios and related projects. And FYI, as of today I changed my own plugins repository to be https://github.com/willixix/naglio-plugins with old repo name https://github.com/willixix/WL-NagiosPlugins now being a clone. This is not as much renaming as it is actually choosing to have a name for project as before it was jut a collection of plugins in one repository which I could not decide what to call all together. Naglio here is name I came up with a year ago for library which came out my code, its meant to be something like 'ugly nagios library'. I'll just use same name for entire repository and project now. William From notifications at github.com Sun Jan 19 09:39:15 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Sun, 19 Jan 2014 00:39:15 -0800 Subject: check_nagios should support other platform (#1223) Message-ID: spy6 proposed a patch to check_nagios (which I'll attach if I can...). I don't think it really applies to the project rename, but I think at this point it's important this plugins supports other similar monitoring systems. We should rename this plugin and use symlinks to provide check_nagios, check_icinga, check_skrinken, etc. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1223 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at netconsonance.com Sat Jan 18 23:52:03 2014 From: jrhett at netconsonance.com (Jo Rhett) Date: Sat, 18 Jan 2014 14:52:03 -0800 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: References: <20140116001227.GL700617@zedat.fu-berlin.de> Message-ID: <5D37A7BB-A6FC-4822-81E4-66CCAEF21184@netconsonance.com> On Jan 17, 2014, at 5:45 PM, William Leibzon wrote: > I will try to put together presentation on open-source monitoring for > LA Devops and LA Linux meetups. I'm probably too busy in winter to do > this, so it maybe pushed to May. And I'll also do this presentation > for San Francisco devops people probably in September. I planned to do Perhaps we should approach Chris Westin for giving talks at the March Meeting for Large Scale Production Engineering? I'd be happy to throw something together to fill out that meetup. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. Author of Instant Puppet 3 Starter: http://www.netconsonance.com/instant-puppet-3-starter-book/ From notifications at github.com Sun Jan 19 14:58:17 2014 From: notifications at github.com (Michael Friedrich) Date: Sun, 19 Jan 2014 05:58:17 -0800 Subject: check_nagios should support other platform (#1223) In-Reply-To: References: Message-ID: I would have proposed such a patch after your renaming todos. It's not really reasonable to tell Icinga/Shinken/Naemon user to use check_nagios at all. So +++++++ from me :) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1223#issuecomment-32708820 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.friedrich at gmail.com Sun Jan 19 19:19:07 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Sun, 19 Jan 2014 19:19:07 +0100 Subject: [HEADS UP] New project name: Monitoring Plugins In-Reply-To: <52D86247.5030208@gmail.com> References: <20140116001227.GL700617@zedat.fu-berlin.de> <201401162147.s0GLlqvL018286@Mail.omnitec.net> <52D86247.5030208@gmail.com> Message-ID: <52DC171B.2020201@gmail.com> Hello, just a short heads-up. On 16.01.2014 23:50, Michael Friedrich wrote: > > > PS: I've taken the liberty to notify package maintainers about the > changed upstream url. > > https://bugzilla.redhat.com/show_bug.cgi?id=1054340 After a strong discussion, creating a new monitoring-plugins package is reasonable. The upgrade path from nagios-plugins -> monitoring-plugins package should be established. Otherwise users install something they are not able to trust anymore. It also states another valid point - Nagios Enterprises copied the website content owned by the now renamed project at https://www.monitoring-plugins.org . That's a clear copyright violation. https://bugzilla.redhat.com/show_bug.cgi?id=1054340#c33 > https://bugzilla.novell.com/show_bug.cgi?id=859105 Upstream has updated their url, and is waiting for future releases with renamed tarballs and/or decision from the rhel bug. > http://www.freebsd.org/cgi/query-pr.cgi?pr=185829 They were faster than me, already updated. > > https://bugs.gentoo.org/show_bug.cgi?id=498292 Still pending, and the Nagios Enterprises guy posted the same FUD as on the RHEL bug. > https://aur.archlinux.org/packages/nagios-plugins/ Updated with comments same as on the other tickets, the Nagios Enterprises guy comments there as well. Kind regards, Michael -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org From notifications at github.com Wed Jan 22 11:03:02 2014 From: notifications at github.com (Lars Vogdt) Date: Wed, 22 Jan 2014 02:03:02 -0800 Subject: fix outdated Free Software Foundation address (#1226) Message-ID: Fix the obsolete Free Software Foundation address. See http://www.fsf.org/about/contact/ for the current address. You can merge this Pull Request by running: git pull https://github.com/lrupp/monitoring-plugins maint Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1226 -- Commit Summary -- * fix outdated Free Software Foundation address -- File Changes -- M plugins-scripts/check_file_age.pl (2) M plugins-scripts/check_ifoperstatus.pl (3) M plugins-scripts/check_ifstatus.pl (2) M plugins-scripts/check_mailq.pl (4) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1226.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1226.diff --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1226 -------------- next part -------------- An HTML attachment was scrubbed... URL: From waja at cyconet.org Wed Jan 22 11:36:15 2014 From: waja at cyconet.org (Jan Wagner) Date: Wed, 22 Jan 2014 11:36:15 +0100 Subject: Github mail Message-ID: <52DF9F1F.4050206@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Subscriber, sorry for the noise with the github mails. We (I) didn't set the list to moderated before fixing the github notifications. With best regards, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFS358c9u6Dud+QFyQRAi86AJ9xTIrFMYTV8y5t93e4Ex6zywxHIQCguUN8 EdPcdBAXavV3JTpQ4nEzSYA= =58ef -----END PGP SIGNATURE----- From notifications at github.com Wed Jan 22 11:48:43 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 22 Jan 2014 02:48:43 -0800 Subject: fix outdated Free Software Foundation address (#1226) In-Reply-To: References: Message-ID: Applied, thanks. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1226#issuecomment-33010964 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 22 11:48:43 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 22 Jan 2014 02:48:43 -0800 Subject: fix outdated Free Software Foundation address (#1226) In-Reply-To: References: Message-ID: Closed #1226. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1226 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 22 12:39:25 2014 From: notifications at github.com (Ricardo Maraschini) Date: Wed, 22 Jan 2014 03:39:25 -0800 Subject: Warning fixes (#1227) Message-ID: Some warning fixes. You can merge this Pull Request by running: git pull https://github.com/ricardomaraschini/monitoring-plugins fixes Or you can view, comment on it, or merge it online at: https://github.com/monitoring-plugins/monitoring-plugins/pull/1227 -- Commit Summary -- * lib/utils_base.c: if asprintf fails, string is undefined * plugins/utils.h: avoiding warnings on empty printf statements -- File Changes -- M lib/utils_base.c (15) M plugins/utils.h (2) -- Patch Links -- https://github.com/monitoring-plugins/monitoring-plugins/pull/1227.patch https://github.com/monitoring-plugins/monitoring-plugins/pull/1227.diff --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1227 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 22 13:18:20 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Wed, 22 Jan 2014 04:18:20 -0800 Subject: Warning fixes (#1227) In-Reply-To: References: Message-ID: We have an `xasprintf()` function in `plugins/utils.c`, we should just use that consistently across the code. But I like the `" \b"` hack! :-) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1227#issuecomment-33016507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at leibzon.org Thu Jan 23 03:45:32 2014 From: william at leibzon.org (William Leibzon) Date: Wed, 22 Jan 2014 18:45:32 -0800 Subject: np_ function prefix Message-ID: Do we want to keep np_ prefix that many functions in the source code use? One of the options could be to change this to mp_ which is not difficult for nagios plugins source code itself but there are, I think, external plugins that link to and use these nagios plugin functions too. William From notifications at github.com Thu Jan 23 06:43:35 2014 From: notifications at github.com (waja) Date: Wed, 22 Jan 2014 21:43:35 -0800 Subject: check_http timeout problem on http redirection case [sf#2200323] (#826) In-Reply-To: References: Message-ID: this is also nagios-plugins/nagios-plugins#12 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/826#issuecomment-33098795 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 09:27:11 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 23 Jan 2014 00:27:11 -0800 Subject: check_ide_smard should default to nagios-compatible output (#1224) In-Reply-To: References: Message-ID: Fixed in b5cc292 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1224#issuecomment-33105106 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 09:27:11 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 23 Jan 2014 00:27:11 -0800 Subject: check_ide_smard should default to nagios-compatible output (#1224) In-Reply-To: References: Message-ID: Closed #1224. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1224 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 09:43:56 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 23 Jan 2014 00:43:56 -0800 Subject: Configure: make --enable-extra-opts the default (#1225) In-Reply-To: References: Message-ID: Closed #1225. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1225 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 09:43:56 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 23 Jan 2014 00:43:56 -0800 Subject: Configure: make --enable-extra-opts the default (#1225) In-Reply-To: References: Message-ID: Fixed in 49ae05f --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1225#issuecomment-33106043 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 10:06:23 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 01:06:23 -0800 Subject: check_ide_smart: Fix smart attribute comparation (#1162) In-Reply-To: References: Message-ID: This patch is also used over there in fedora: http://pkgs.fedoraproject.org/cgit/nagios-plugins.git/tree/nagios-plugins-0010-fix-smart-attribute-comparison.patch --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1162#issuecomment-33107166 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 10:10:10 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 01:10:10 -0800 Subject: check_swap: returns OK, if no swap activated (#1193) In-Reply-To: References: Message-ID: This patch is also used over there in fedora: http://pkgs.fedoraproject.org/cgit/nagios-plugins.git/tree/nagios-plugins-0005-Prevent-check_swap-from-returning-OK-if-no-swap-acti.patch --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193#issuecomment-33107370 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 10:26:43 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 01:26:43 -0800 Subject: check_ssh add --fingerprint option [sf#3574197] (#1119) In-Reply-To: References: Message-ID: is indeed now monitoring-plugins/monitoring-plugins/pull/26 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1119#issuecomment-33108387 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 10:35:04 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 01:35:04 -0800 Subject: Add support for drill tool to check_dig (#1218) In-Reply-To: References: Message-ID: The patch over there in freebsd seems https://github.com/freebsd/freebsd-ports/blob/master/net-mgmt/nagios-plugins/files/extra-patch-dig-to-drill.diff --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1218#issuecomment-33108874 -------------- next part -------------- An HTML attachment was scrubbed... URL: From f at zz.de Thu Jan 23 11:59:51 2014 From: f at zz.de (Florian Lohoff) Date: Thu, 23 Jan 2014 11:59:51 +0100 Subject: persistent storage for checks Monitoring::Plugin Message-ID: <20140123105951.GA25775@pax.zz.de> Hi, is there a way for persistent storage in the checks? I wrote myself an interface check plugin which gets an interface name as input and looks through the ifName/ifDescr table to find its oid. Now i am caching the result that do not need to do the walk again on every invocation. I do verify that the name still matches. So if i dont have a cache file i do snmpwalk ifName ifDescr snmpget ifInOctets ifOutOctets ifName ifDescr write cachefile The next invocation i do read cachefile snmpget ifInOctets ifOutOctets ifName IfDescr check if ifName ifDescr still matches if not do walk again Currently i simply create a directory and i drop my cache files somewhere in /var/lib/nagios3/run something but i think it'll be a good idea to formalize the way to do persistent storage via Monitoring::Plugin Flo -- Florian Lohoff f at zz.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From holger at zedat.fu-berlin.de Thu Jan 23 12:51:30 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 23 Jan 2014 12:51:30 +0100 Subject: persistent storage for checks Monitoring::Plugin In-Reply-To: <20140123105951.GA25775@pax.zz.de> References: <20140123105951.GA25775@pax.zz.de> Message-ID: <20140123115130.GI654350@zedat.fu-berlin.de> * Florian Lohoff [2014-01-23 11:59]: > Currently i simply create a directory and i drop my cache files > somewhere in /var/lib/nagios3/run something but i think it'll be > a good idea to formalize the way to do persistent storage > via Monitoring::Plugin Someone posted a Nagios::Plugin::Differences module a few years ago, you might want to look into that: https://www.monitoring-plugins.org/archive/devel/2009-September/007749.html https://www.monitoring-plugins.org/archive/devel/attachments/20090904/65c2d73a/attachment.ksh I haven't tested it myself, but I guess it would be nice to get that onto CPAN if it works well. Holger From holger at zedat.fu-berlin.de Thu Jan 23 13:18:30 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 23 Jan 2014 13:18:30 +0100 Subject: np_ function prefix In-Reply-To: References: Message-ID: <20140123121830.GJ654350@zedat.fu-berlin.de> * William Leibzon [2014-01-22 18:45]: > Do we want to keep np_ prefix that many functions in the source code use? We haven't really decided on this one yet. Do you think we should? > One of the options could be to change this to mp_ which is not > difficult for nagios plugins source code itself but there are, I > think, external plugins that link to and use these nagios plugin > functions too. Yes. That's never been supported, but of course there might be plugins doing just that regardless. The other downside is that such a change makes it a bit harder to exchange patches with the Nagios Enterprises team. Holger From notifications at github.com Thu Jan 23 16:14:37 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 07:14:37 -0800 Subject: check_ide_smart: fix smart attribute comparison [sf#3428117] (#1040) In-Reply-To: References: Message-ID: fixed with c4a99b023d03326ad49e03c8731eec19d19a75bf --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1040#issuecomment-33132002 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 16:14:37 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 07:14:37 -0800 Subject: check_ide_smart: fix smart attribute comparison [sf#3428117] (#1040) In-Reply-To: References: Message-ID: Closed #1040. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1040 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 16:14:52 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 07:14:52 -0800 Subject: check_ide_smart: Fix smart attribute comparation (#1162) In-Reply-To: References: Message-ID: Closed #1162. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1162 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 16:22:39 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 07:22:39 -0800 Subject: check_ntp_time picks IPv6 address when no IPv6 is available [sf#3031365] (#1131) In-Reply-To: References: Message-ID: Closing this, cause the plugin was removed with 43fbde678c608c2d44d9ebd98a710e63d9300f06 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1131#issuecomment-33132738 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 16:22:40 2014 From: notifications at github.com (waja) Date: Thu, 23 Jan 2014 07:22:40 -0800 Subject: check_ntp_time picks IPv6 address when no IPv6 is available [sf#3031365] (#1131) In-Reply-To: References: Message-ID: Closed #1131. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1131 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 23 23:28:14 2014 From: notifications at github.com (Alexander Wittig) Date: Thu, 23 Jan 2014 14:28:14 -0800 Subject: Add support for drill tool to check_dig (#1218) In-Reply-To: References: Message-ID: That's correct, it was a first version I submitted to the port maintainer. However, just removing the "-t" does not work with "advanced" settings, e.g. when the transport type (-4 and -6) or user supplied extra options are specified. Then drill is called as e.g. "drill @127.0.0.1 -p 53 google.com A -4", with the -4 attached at the end. While apparently OK with dig, for drill that does not work (see below). Reordering the arguments to have all possibly specified options given first followed by the server, domain, and query type (e.g. "drill -4 -p 53 @127.0.0.1 google.com A") works for both as stated above. If you prefer I will submit this new patch to the FreeBSD maintainer again, but I think it should be fixed upstream as this is not a FreeBSD specific issue. ``` %drill @127.0.0.1 -p 53 google.com A -4 ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 3495 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; -4. IN A ;; ANSWER SECTION: ;; AUTHORITY SECTION: . 1237 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014012301 1800 900 604800 86400 ;; ADDITIONAL SECTION: ;; Query time: 0 msec ;; SERVER: 127.0.0.1 ;; WHEN: Thu Jan 23 23:17:28 2014 ;; MSG SIZE rcvd: 95 ``` --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1218#issuecomment-33176435 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:24:18 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:24:18 -0800 Subject: check_ntp_time: Bug in average calculation [sf#2993229] (#956) In-Reply-To: References: Message-ID: Closed #956 via c5dc81cd2889421115b4d33b959b0ff8e2df9f6c. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/956 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:24:19 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:24:19 -0800 Subject: check_ntp_time: Bug in average calculation (#1166) In-Reply-To: References: Message-ID: Closed #1166 via c5dc81cd2889421115b4d33b959b0ff8e2df9f6c. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1166 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:26:36 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:26:36 -0800 Subject: check_ntp_time and check_ntp return just first offset [sf#3552882] (#1089) In-Reply-To: References: Message-ID: fixed with ccecba33a2b32e607b2d008a69a90f6532926374 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1089#issuecomment-33242975 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:26:39 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:26:39 -0800 Subject: check_ntp_time and check_ntp return just first offset [sf#3552882] (#1089) In-Reply-To: References: Message-ID: Closed #1089. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1089 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:45:23 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:45:23 -0800 Subject: check_ping: Fixing "time of day goes back" (#1165) In-Reply-To: References: Message-ID: Closed #1165. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1165 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 18:45:24 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 09:45:24 -0800 Subject: check_ping: Fixing "time of day goes back" (#1165) In-Reply-To: References: Message-ID: Fixed with 455fe96e7dcadd433973b1709ee79cdb58ffe428 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1165#issuecomment-33244469 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 19:04:15 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 10:04:15 -0800 Subject: Add performance data to check_mysql_query.c (#1202) In-Reply-To: References: Message-ID: merged with fc01a54e933aadec5059bf56e79fa7aca08af6d2 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1202#issuecomment-33246107 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 19:04:16 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 10:04:16 -0800 Subject: Add performance data to check_mysql_query.c (#1202) In-Reply-To: References: Message-ID: Closed #1202. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1202 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 20:53:47 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 11:53:47 -0800 Subject: check_file_age should optional ignore missing files [sf#2550243] (#845) In-Reply-To: References: Message-ID: Closed #845 via 0b9b300f856d021b56950030f4e6053d84bc77c8. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/845 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 20:53:47 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 11:53:47 -0800 Subject: check_file_age: support for --ignore-missing (#1181) In-Reply-To: References: Message-ID: Closed #1181 via 0b9b300f856d021b56950030f4e6053d84bc77c8. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1181 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 20:53:48 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 11:53:48 -0800 Subject: check_file_age: Add option (-m) to allow for missing file (#1187) In-Reply-To: References: Message-ID: Closed #1187 via 0b9b300f856d021b56950030f4e6053d84bc77c8. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1187 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 20:53:48 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 11:53:48 -0800 Subject: Add support for --ignore-missing for check_file_age [sf#3240541] (#989) In-Reply-To: References: Message-ID: Closed #989 via 0b9b300f856d021b56950030f4e6053d84bc77c8. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/989 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 20:53:48 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 11:53:48 -0800 Subject: check_file_age - Add option (-m) to allow for missing file [sf#2708481] (#862) In-Reply-To: References: Message-ID: Closed #862 via 0b9b300f856d021b56950030f4e6053d84bc77c8. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/862 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 21:39:50 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 12:39:50 -0800 Subject: check_hpjd: port option (#1160) In-Reply-To: References: Message-ID: Over there in n-p there is an other fix suggested: https://github.com/nagios-plugins/nagios-plugins/compare/1657daf52a0611361a5061348e6369f2500f7c76...3282a335392ebbb1d0e4f848f59bac04229721ad --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1160#issuecomment-33258605 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 21:43:41 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 12:43:41 -0800 Subject: plugins/utils.h: avoiding warnings on empty printf statements (82033b3) In-Reply-To: References: Message-ID: see https://github.com/nagios-plugins/nagios-plugins/commit/6349834e9ad0973c2942a0d3b7e731253f9bacf3 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/82033b35b162c1b8a64a4b8be36c1c9c87ef9555#commitcomment-5172836 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 21:54:41 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 12:54:41 -0800 Subject: check_file_age: support for --ignore-missing (0b9b300) In-Reply-To: References: Message-ID: just for reference: https://github.com/nagios-plugins/nagios-plugins/commit/d6e72e9071552e9777f2f57d49c0b78d2fecf6d3 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/0b9b300f856d021b56950030f4e6053d84bc77c8#commitcomment-5172985 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 22:15:05 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 13:15:05 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: Reopened #361. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 22:16:09 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 13:16:09 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: https://github.com/nagios-plugins/nagios-plugins/issues/13 and https://github.com/nagios-plugins/nagios-plugins/pull/14 seems to indicate there are still problems with multiline output --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33261989 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 22:45:08 2014 From: notifications at github.com (abrist) Date: Fri, 24 Jan 2014 13:45:08 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: I don't see any options for multiple line output in check_disk.c. Am I just blind today? --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33264321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:02:33 2014 From: notifications at github.com (abrist) Date: Fri, 24 Jan 2014 14:02:33 -0800 Subject: check_snmp: fix for multiple non numeric OIDs [sf#3386172] (#1013) In-Reply-To: References: Message-ID: I have been unable to reproduce this issue. We do not have a netapp device in house, but I have been attempting to reproduce the behavior with other OIDs. .1.3.6.1.4.1.789.1.2.2.4.0 --> returns an integer .1.3.6.1.4.1.789.1.2.2.25.0 --> returns a DisplayString I have attempted to use OIDs with similar returns (same type, nearly same output) and have yet to encounter this error. Have you guys had any luck reproducing this on your side? If so, what OIDs? --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1013#issuecomment-33265892 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:11:12 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 14:11:12 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: I would say 'no' .. just linking your issue over there into our old multiline issue --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33266889 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:13:27 2014 From: notifications at github.com (abrist) Date: Fri, 24 Jan 2014 14:13:27 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: No problem. I will clean up Trevor's pull req by Monday if he or you do not hit it first. Have a good weekend and thanks for the reply. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33267088 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:20:06 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 14:20:06 -0800 Subject: check_snmp: fix for multiple non numeric OIDs [sf#3386172] (#1013) In-Reply-To: References: Message-ID: Nope ... but maybe as you have the ability todo so ... try asking the origin submitter: https://sourceforge.net/p/nagiosplug/patches/360/ I'm not able to reply on that cause this seems disabled anyhow. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1013#issuecomment-33267560 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:22:43 2014 From: notifications at github.com (abrist) Date: Fri, 24 Jan 2014 14:22:43 -0800 Subject: check_snmp: fix for multiple non numeric OIDs [sf#3386172] (#1013) In-Reply-To: References: Message-ID: Done. I will let you know if he responds. It was posted a few years ago, so he may be mia. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1013#issuecomment-33267738 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 24 23:35:03 2014 From: notifications at github.com (Matthias Eble) Date: Fri, 24 Jan 2014 14:35:03 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: this issue should've remained closed, as this is just an error that was reported when check_disk was a df wrapper. It's not relevant any more ss gnulib's fsusage is now being used. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33268566 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Jan 25 00:25:07 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 15:25:07 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: okay .. so we close this for now, but maybe should just open new one. Maybe we could also wait until anybody other is opening a new issue or the guys from M-P got forward with their https://github.com/nagios-plugins/nagios-plugins/issues/13 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361#issuecomment-33271555 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Jan 25 00:25:08 2014 From: notifications at github.com (waja) Date: Fri, 24 Jan 2014 15:25:08 -0800 Subject: Rel. 1.3.0: check_disk multiline df output on HP-UX [sf#696439] (#361) In-Reply-To: References: Message-ID: Closed #361. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/361 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Jan 25 11:56:01 2014 From: notifications at github.com (waja) Date: Sat, 25 Jan 2014 02:56:01 -0800 Subject: check_ping warning.. "time of day goes back" [sf#1991275] (#809) In-Reply-To: References: Message-ID: closed via https://github.com/waja/monitoring-plugins/commit/90f2c6d850ce3960e5cb3508ce0670b3238db38a --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/809#issuecomment-33286326 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sat Jan 25 11:56:01 2014 From: notifications at github.com (waja) Date: Sat, 25 Jan 2014 02:56:01 -0800 Subject: check_ping warning.. "time of day goes back" [sf#1991275] (#809) In-Reply-To: References: Message-ID: Closed #809. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/809 -------------- next part -------------- An HTML attachment was scrubbed... URL: From william at leibzon.org Sun Jan 26 08:17:04 2014 From: william at leibzon.org (William Leibzon) Date: Sat, 25 Jan 2014 23:17:04 -0800 Subject: np_ function prefix In-Reply-To: <20140123121830.GJ654350@zedat.fu-berlin.de> References: <20140123121830.GJ654350@zedat.fu-berlin.de> Message-ID: On Thu, Jan 23, 2014 at 4:18 AM, Holger Wei? wrote: > * William Leibzon [2014-01-22 18:45]: >> Do we want to keep np_ prefix that many functions in the source code use? > > We haven't really decided on this one yet. Do you think we should? I'm not sure that's why I opened the topic up. Seems like eventually it'd be best to rename but its not a big issue at the moment. Maybe seen how much patch exchange there would be between monitoring-plugins and nagios-plugins and who does patches and how and then decide. >> One of the options could be to change this to mp_ which is not >> difficult for nagios plugins source code itself but there are, I >> think, external plugins that link to and use these nagios plugin >> functions too. > > Yes. That's never been supported, but of course there might be plugins > doing just that regardless. > > The other downside is that such a change makes it a bit harder to > exchange patches with the Nagios Enterprises team. From holger at zedat.fu-berlin.de Sun Jan 26 09:28:46 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Sun, 26 Jan 2014 09:28:46 +0100 Subject: np_ function prefix In-Reply-To: References: <20140123121830.GJ654350@zedat.fu-berlin.de> Message-ID: <20140126082846.GR654350@zedat.fu-berlin.de> * William Leibzon [2014-01-25 23:17]: > On Thu, Jan 23, 2014 at 4:18 AM, Holger Wei? wrote: > > * William Leibzon [2014-01-22 18:45]: > >> Do we want to keep np_ prefix that many functions in the source code use? > > > > We haven't really decided on this one yet. Do you think we should? > > I'm not sure that's why I opened the topic up. Seems like eventually > it'd be best to rename but its not a big issue at the moment. Maybe > seen how much patch exchange there would be between monitoring-plugins > and nagios-plugins and who does patches and how and then decide. Yup, agreed. Either way, the higher priority is to get everything user-visible fixed, which is quite a bunch of work (though I think we're through with most of that by now). Holger From notifications at github.com Sun Jan 26 13:36:51 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 04:36:51 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: SuSE over there: https://build.opensuse.org/package/view_file/server:monitoring/nagios-plugins/nagios-plugins-wrong_return_in_check_swap.patch?expand=1 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193#issuecomment-33315793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 14:55:00 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 05:55:00 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Closed #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 14:57:59 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 05:57:59 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Reopened #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:00:43 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:00:43 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Closed #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:01:23 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:01:23 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Reopened #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:05:57 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:05:57 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Closed #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:06:19 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:06:19 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Reopened #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:13:30 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:13:30 -0800 Subject: check_snmp: small improvement (#1173) In-Reply-To: References: Message-ID: Closed #1173. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1173 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Sun Jan 26 15:13:51 2014 From: notifications at github.com (waja) Date: Sun, 26 Jan 2014 06:13:51 -0800 Subject: check_snmp: small improvement (#1173) In-Reply-To: References: Message-ID: Reopened #1173. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1173 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Mon Jan 27 15:12:10 2014 From: notifications at github.com (=?UTF-8?B?U3TDqXBoYW5lIEJvcnR6bWV5ZXI=?=) Date: Mon, 27 Jan 2014 06:12:10 -0800 Subject: The -6 option of check_dig does not work as documented (#1228) Message-ID: When you monitor an IPv6 DNS server with check_dig -6, and uses the server name (not its IP address), check_dig falls back to IPv4 if the name server does not reply immediately in IPv6. It is not the behavior I expect (if I say -6, it is because I want to be sure IPv6 works). Reading the source, it seems check_dig puts the -6 as the end of the command line (call to xasprintf ). Testing with dig on the command line, it seems indeed that -6 does not have the same semantics when used at the begin or at the end of the command line (before or after the server name). I therefore suggest this patch: ``` --- ./plugins/check_dig.c.orig 2014-01-27 14:55:56.000000000 +0100 +++ ./plugins/check_dig.c 2014-01-27 15:10:07.000000000 +0100 @@ -88,8 +88,8 @@ usage_va(_("Could not parse arguments")); /* get the command to run */ - xasprintf (&command_line, "%s @%s -p %d %s -t %s %s %s", - PATH_TO_DIG, dns_server, server_port, query_address, record_type, dig_args, query_transport); + xasprintf (&command_line, "%s %s @%s -p %d %s -t %s %s", + PATH_TO_DIG, query_transport, dns_server, server_port, query_address, record_type, dig_args); alarm (timeout_interval); gettimeofday (&tv, NULL); ?`?` Yes, dig's parsing is... special. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1228 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Tue Jan 28 04:18:43 2014 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Mon, 27 Jan 2014 22:18:43 -0500 Subject: The -6 option of check_dig does not work as documented (#1228) In-Reply-To: References: Message-ID: <52E72193.6030909@aei.ca> Fixed in #58e57b3 Thanks -- Thomas From notifications at github.com Tue Jan 28 07:49:27 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Mon, 27 Jan 2014 22:49:27 -0800 Subject: The -6 option of check_dig does not work as documented (#1228) In-Reply-To: References: Message-ID: Closed #1228. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1228 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 07:50:30 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Mon, 27 Jan 2014 22:50:30 -0800 Subject: Add ability to read from options file to check_mysql_query.c (#1200) In-Reply-To: References: Message-ID: Merged #1200. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1200 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 09:37:47 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 00:37:47 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: Closed #1193. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 09:39:03 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 00:39:03 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: Reopened #1193. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 09:39:54 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 00:39:54 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: Closed #1167. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 09:40:36 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 00:40:36 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: Reopened #1167. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 09:40:36 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 00:40:36 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: recommited a propper commit --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167#issuecomment-33459846 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 10:04:11 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 01:04:11 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: Closed #1167. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 10:22:44 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 01:22:44 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: Reopened #1167. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 10:31:49 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 01:31:49 -0800 Subject: check_http timeout problem on http redirection case [sf#2200323] (#826) In-Reply-To: References: Message-ID: Closed #826. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/826 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 10:31:50 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 01:31:50 -0800 Subject: check_http timeout problem on http redirection case [sf#2200323] (#826) In-Reply-To: References: Message-ID: This bug should be fixed with 3dd27fb06. If anybody experiencing problems here, please reopen the bug. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/826#issuecomment-33462869 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 10:32:26 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 01:32:26 -0800 Subject: check_http: timeout problem on http redirection case [sf#2200323] (#1167) In-Reply-To: References: Message-ID: Closed #1167. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1167 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 11:23:48 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 02:23:48 -0800 Subject: check_ide_smart: Invalid argument [sf#3343431] (#1104) In-Reply-To: References: Message-ID: n-p has this too https://github.com/nagios-plugins/nagios-plugins/issues/16 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1104#issuecomment-33466361 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 12:02:12 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 03:02:12 -0800 Subject: check_disk: precise the help output (#1170) In-Reply-To: References: Message-ID: Closed #1170. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1170 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 21:01:29 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 12:01:29 -0800 Subject: The -6 option of check_dig does not work as documented (#1228) In-Reply-To: References: Message-ID: In N-P this is https://github.com/nagios-plugins/nagios-plugins/issues/18 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1228#issuecomment-33518462 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 21:13:42 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 12:13:42 -0800 Subject: check_disk: inconsistency when given device file as -p [sf#3590374] (#1118) In-Reply-To: References: Message-ID: Closed #1118. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1118 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 21:13:42 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 12:13:42 -0800 Subject: check_disk: inconsistency when given device file as -p [sf#3590374] (#1118) In-Reply-To: References: Message-ID: Closed by cb99931e43a1da8c6cb3ff80e2561d4d5d34764f --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/1118#issuecomment-33519720 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Tue Jan 28 22:09:30 2014 From: notifications at github.com (waja) Date: Tue, 28 Jan 2014 13:09:30 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: redhat: https://bugzilla.redhat.com/show_bug.cgi?id=512559 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193#issuecomment-33525632 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 04:58:58 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Tue, 28 Jan 2014 19:58:58 -0800 Subject: check_ldap: add certificate support (#1195) In-Reply-To: References: Message-ID: Hi waja, You know, i'm not really against this patch, but one weird thing I noticed is that for straight up SSL services, check_http certificate check works! Makes me think the check should actually be implemented in check_tcp for all SSL protocols. Then once we get there, what prevent us form adding just the required logic in check_tcp to implement the STARTTLS certificate checks for every other STARTTLS-cabaple protocol? So I don't really mind this merge gets in, but I think the check_tcp suggestion is still worth it and would make this patch obsolete. It's just a mater of which one can get in first I guess... --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1195#issuecomment-33554590 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 09:18:41 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 00:18:41 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: dermoth started with 6f2d545244193432a6ad3d54185628b8f6a6091e to get that fixed ;) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193#issuecomment-33564358 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 09:19:34 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 00:19:34 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: Closed #1193. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 09:31:57 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 00:31:57 -0800 Subject: check_swap returns OK, if no swap activated [sf#2823005] (#896) In-Reply-To: References: Message-ID: Initial commit toward a fix by dermoth: 6f2d545244193432a6ad3d54185628b8f6a6091e --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/896#issuecomment-33565055 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 09:51:34 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 00:51:34 -0800 Subject: check_swap: returns OK, if no swap activated [sf#2823005] (#1193) In-Reply-To: References: Message-ID: 6f2d545 fixes the check_swap plugin not returning CRITICAL when only percentage thresholds are passed. 7afbca0 add a command-line option to specify which state should be returned when the swap is absent. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1193#issuecomment-33566135 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 10:00:58 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 01:00:58 -0800 Subject: check_swap returns OK, if no swap activated [sf#2823005] (#896) In-Reply-To: References: Message-ID: 6f2d545 fixes the check_swap plugin not returning CRITICAL when only percentage thresholds are passed. 7afbca0 add a command-line option to specify which state should be returned when the swap is absent. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/896#issuecomment-33566679 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 10:00:58 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 01:00:58 -0800 Subject: check_swap returns OK, if no swap activated [sf#2823005] (#896) In-Reply-To: References: Message-ID: Closed #896. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/896 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 10:09:55 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 01:09:55 -0800 Subject: no perf-data check_swap [sf#1614554] (#622) In-Reply-To: References: Message-ID: This patch is broken. I may have a look at it, but it appears we're only missing the stats when specifying thresholds as integers only. With your patch applied, the data was always incorrect, but the breakage was different with integer vs. percent thresholds. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/622#issuecomment-33567190 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 10:12:45 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 01:12:45 -0800 Subject: no perf-data check_swap [sf#1614554] (#622) In-Reply-To: References: Message-ID: related to #466 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/622#issuecomment-33567369 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 10:13:19 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Wed, 29 Jan 2014 01:13:19 -0800 Subject: no perf-data check_swap [sf#1614554] (#622) In-Reply-To: References: Message-ID: Closed #622. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/622 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 13:51:07 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 04:51:07 -0800 Subject: check_mailq: nullmailer support [sf#1510712] (#740) In-Reply-To: References: Message-ID: Fixed with 2dc150da81169ec6d81858478b6203eb3aa164a9 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/740#issuecomment-33581589 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 13:51:08 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 04:51:08 -0800 Subject: check_mailq: nullmailer support [sf#1510712] (#740) In-Reply-To: References: Message-ID: Closed #740. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/740 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 13:51:17 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 04:51:17 -0800 Subject: check_mailq: adding nullmailer support (#1189) In-Reply-To: References: Message-ID: Closed #1189. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1189 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Wed Jan 29 13:51:18 2014 From: notifications at github.com (waja) Date: Wed, 29 Jan 2014 04:51:18 -0800 Subject: check_mailq: adding nullmailer support (#1189) In-Reply-To: References: Message-ID: Fixed with 2dc150da81169ec6d81858478b6203eb3aa164a9 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1189#issuecomment-33581599 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen.Bern at LINworks.de Wed Jan 29 18:53:09 2014 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Wed, 29 Jan 2014 18:53:09 +0100 Subject: check_ldap: add certificate support (#1195) In-Reply-To: References: Message-ID: <52E94005.6090704@LINworks.de> On 29.01.2014 04:58, Thomas Guyot-Sionnest wrote: > one weird thing I noticed is that for straight up SSL services, > check_http certificate check works! That's because - as far as I can tell without examining the code - having check_http do a cert check terminates/ignores/whatever all communication following the server cert presentation, and thus the HTTP part of HTTPS. In other words, it *does* behave like a check_tcp plus cert check; if I remember correctly, it will even happily *ignore* all additional limits etc. specified for time, size, string match, etc. from the command line. Note that that might very well *not* be what we want check_*http* to do in the long run. > Then once we get there, what prevent us form adding just the required > logic in check_tcp to implement the STARTTLS certificate checks for > every other STARTTLS-cabaple protocol? The fact that STARTTLS, more precisely the proper point at which to issue that command, is *embedded into* said STARTTLS-enabled protocol. Hence OpenSSL's requirement of specifying said protocol (out of two currently supported) when you do an "openssl s_client -connect foo.bar.org:baz -starttls $HERES_DA_MAGIC_KEYWORD". Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From notifications at github.com Thu Jan 30 09:10:16 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 00:10:16 -0800 Subject: check_dig: patch to make dig honor -t option (#1168) In-Reply-To: References: Message-ID: Eventually we should add here a test. On the other hand ... taking here a >15 sec in maybe controversial. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1168#issuecomment-33667410 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 12:08:04 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 03:08:04 -0800 Subject: check_dig: patch to make dig honor -t option (#1168) In-Reply-To: References: Message-ID: Closed #1168 via df53473d03783ef853465c80162758bb6ee403c7. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1168 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 12:10:16 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 03:10:16 -0800 Subject: check_dig: patch to make dig honor -t option [sf#1889955] (#774) In-Reply-To: References: Message-ID: Fixed with df53473d03783ef853465c80162758bb6ee403c7 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/774#issuecomment-33678561 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 12:10:16 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 03:10:16 -0800 Subject: check_dig: patch to make dig honor -t option [sf#1889955] (#774) In-Reply-To: References: Message-ID: Closed #774. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/774 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 13:31:01 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 04:31:01 -0800 Subject: check_dig: patch to make dig honor -t option [sf#1889955] (#774) In-Reply-To: References: Message-ID: Eventually we should add here a test. On the other hand ... taking here a >15 sec in maybe controversial. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/774#issuecomment-33683451 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 13:31:01 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 04:31:01 -0800 Subject: check_dig: patch to make dig honor -t option [sf#1889955] (#774) In-Reply-To: References: Message-ID: Reopened #774. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/issues/774 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 18:15:51 2014 From: notifications at github.com (abrist) Date: Thu, 30 Jan 2014 09:15:51 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: Holger made a good point about this change: https://github.com/nagios-plugins/nagios-plugins/commit/05a63d8c3e83cc006b6168efe61b9922f2d14ecf ceil may be more correct as the plugin will still alarm once it reaches the global timeout value. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5227666 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 18:28:23 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Thu, 30 Jan 2014 09:28:23 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: Note that we're using `timeout_interval / number_tries + number_tries` (while your [interim solution][1] didn't add `number_tries` to the result). Yes, the results will often be, err, "less correct" compared to the floating point division, but I think this might be good enough for us. Especially as we didn't add a fancy `--retries` flag like you did :-) But thanks for the hint! [1]: https://github.com/nagios-plugins/nagios-plugins/commit/05a63d8c3e83cc006b6168efe61b9922f2d14ecf --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5227804 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 19:39:34 2014 From: notifications at github.com (William Leibzon) Date: Thu, 30 Jan 2014 10:39:34 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: long long timeout_interval_ll = (timeout_interval<<8); timeout_interval_ll = timeout_interval_ll / ( number_tries<<8); int timeout_interval_dig = (timeout_interval_lg >>8) + number_tries; --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5228709 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 21:35:56 2014 From: notifications at github.com (abrist) Date: Thu, 30 Jan 2014 12:35:56 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: It may be good enough, but most timeout values other than those that produce 0 from the division (less than 3) will cause dig to only timeout twice with the patch. I think the disagreement is philosophical at this point: I would rather allow the user to control the behavior - if they have a slow server or an intermittent one, they may wish for more retries etc. So we will stick with floating point division, though this does work just fine as well and escapes having to pull in the math libraries. Cheers all. @willix. no bitwise thank you, though it is clever :) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5230439 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 21:52:25 2014 From: notifications at github.com (=?UTF-8?B?SG9sZ2VyIFdlacOf?=) Date: Thu, 30 Jan 2014 12:52:25 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: Actually, I was inclined to hardcode `+tries=1` on the `dig(1)` command line. While the `dig(1)` command happens to implement retries by default, most of our plugins don't, because users might want to *notice* if some fraction of queries fail, and because Nagios & friends support "soft states" if users *don't* want to be notified in such cases. I'd be surprised if the original `check_dig` author consciously relied on these `dig(1)` semantics. And yes, maybe the disagreement is "philosophical": I do not at all believe that more configuration switches are necessarily better. Only those that might actually be useful are good :-) But I'll agree that there are many cases where you could argue one way or the other. Either way, if there's just one more comment on this single line of code, I'll revert to the floating point division, which I agree is totally fine as well ;-) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5230669 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Thu Jan 30 22:08:26 2014 From: notifications at github.com (waja) Date: Thu, 30 Jan 2014 13:08:26 -0800 Subject: check_dig: stick with integer devision (e33ecc8) In-Reply-To: References: Message-ID: We still love each all! ;) --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/commit/e33ecc84c7ebdf4af3e8649a326e8a5acc9fe5b6#commitcomment-5230902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at zedat.fu-berlin.de Thu Jan 30 22:58:18 2014 From: holger at zedat.fu-berlin.de (Holger =?iso-8859-1?Q?Wei=DF?=) Date: Thu, 30 Jan 2014 22:58:18 +0100 Subject: GitHub notifications Message-ID: <20140130215818.GA344156@zedat.fu-berlin.de> As you surely have noticed, our GitHub account is configured to forward notifications to this mailing list. We've set things up this way because we like the idea of having a single place where all development-related stuff goes. Most discussions on contributed code happen on GitHub these days. I consider those to be an essential part of our development history, so I'm not really comfortable with having the archives locked into a proprietary site. Then again, we've had at least two subscribers complain about these notifications on our IRC channel (#monitoring-plugins on freenode). I do see their point, especially when it comes to all the "closed"/"reopened" status change messages that were generated recently. One suggestion was to try to filter out those, so that only actual comments would get through to this list. But we figured we'd ask you, first! Which of the following options would you prefer? | IMPORTANT: Please send an email to me PERSONALLY to just vote for one | of the options. If you have additional comments, feel free to post | them to the list, of course. [ ] Please continue to forward all notifications to this list. [ ] Please filter out status changes, but forward actual comments. [ ] Please don't forward any GitHub notifications! [ ] I don't care. Holger From mithun.gaikwad at gmail.com Fri Jan 31 05:31:13 2014 From: mithun.gaikwad at gmail.com (Mithun Gaikwad) Date: Fri, 31 Jan 2014 10:01:13 +0530 Subject: GitHub notifications In-Reply-To: <20140130215818.GA344156@zedat.fu-berlin.de> References: <20140130215818.GA344156@zedat.fu-berlin.de> Message-ID: [ ] Please don't forward any GitHub notifications! On Fri, Jan 31, 2014 at 3:28 AM, Holger Wei? wrote: > As you surely have noticed, our GitHub account is configured to forward > notifications to this mailing list. We've set things up this way > because we like the idea of having a single place where all > development-related stuff goes. Most discussions on contributed code > happen on GitHub these days. I consider those to be an essential part > of our development history, so I'm not really comfortable with having > the archives locked into a proprietary site. > > Then again, we've had at least two subscribers complain about these > notifications on our IRC channel (#monitoring-plugins on freenode). I > do see their point, especially when it comes to all the > "closed"/"reopened" status change messages that were generated recently. > One suggestion was to try to filter out those, so that only actual > comments would get through to this list. But we figured we'd ask you, > first! Which of the following options would you prefer? > > | IMPORTANT: Please send an email to me PERSONALLY to just vote for one > | of the options. If you have additional comments, feel free to post > | them to the list, of course. > > [ ] Please continue to forward all notifications to this list. > [ ] Please filter out status changes, but forward actual comments. > [ ] Please don't forward any GitHub notifications! > [ ] I don't care. > > Holger > -- Mithun Gaikwad -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 31 06:56:58 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 30 Jan 2014 21:56:58 -0800 Subject: Handle negative values properly with check_snmp (#1215) In-Reply-To: References: Message-ID: Closed #1215. --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1215 -------------- next part -------------- An HTML attachment was scrubbed... URL: From notifications at github.com Fri Jan 31 06:56:58 2014 From: notifications at github.com (Thomas Guyot-Sionnest) Date: Thu, 30 Jan 2014 21:56:58 -0800 Subject: Handle negative values properly with check_snmp (#1215) In-Reply-To: References: Message-ID: Fixed in 3581184 --- Reply to this email directly or view it on GitHub: https://github.com/monitoring-plugins/monitoring-plugins/pull/1215#issuecomment-33763609 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.friedrich at gmail.com Fri Jan 31 10:19:23 2014 From: michael.friedrich at gmail.com (Michael Friedrich) Date: Fri, 31 Jan 2014 10:19:23 +0100 Subject: GitHub notifications In-Reply-To: <20140130215818.GA344156@zedat.fu-berlin.de> References: <20140130215818.GA344156@zedat.fu-berlin.de> Message-ID: <52EB6A9B.6020302@gmail.com> On 30.01.2014 22:58, Holger Wei? wrote: > [x] Please continue to forward all notifications to this list. I appreciate the idea of having all activity in one stream. devel lists are rather dead these days anyways. -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org From waja at cyconet.org Fri Jan 31 10:32:23 2014 From: waja at cyconet.org (Jan Wagner) Date: Fri, 31 Jan 2014 10:32:23 +0100 Subject: GitHub notifications In-Reply-To: <52EB6A9B.6020302@gmail.com> References: <20140130215818.GA344156@zedat.fu-berlin.de> <52EB6A9B.6020302@gmail.com> Message-ID: <52EB6DA7.5030503@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.14 10:19, schrieb Michael Friedrich: > On 30.01.2014 22:58, Holger Wei? wrote: > >> [x] Please continue to forward all notifications to this list. > > I appreciate the idea of having all activity in one stream. devel > lists are rather dead these days anyways. Same for me, thanks! - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLrbacACgkQ9u6Dud+QFyR15QCfS0wFt+r/64dMlAcv8msd4WPd 6wEAniDKyucPGtdRcZQcR5M6a2vd9L/W =wjTS -----END PGP SIGNATURE----- From waja at cyconet.org Fri Jan 31 10:34:34 2014 From: waja at cyconet.org (Jan Wagner) Date: Fri, 31 Jan 2014 10:34:34 +0100 Subject: GitHub notifications In-Reply-To: References: <20140130215818.GA344156@zedat.fu-berlin.de> Message-ID: <52EB6E2A.5070602@cyconet.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mithun, Am 31.01.14 05:31, schrieb Mithun Gaikwad: > [ ] Please don't forward any GitHub notifications! juzst one question from my side: What is your expectation (in terms of content) of this _development_ mailinglist? Cheers, Jan. - -- Never write mail to , you have been warned! - -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++ - ------END GEEK CODE BLOCK------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLrbioACgkQ9u6Dud+QFySnbgCfXrKggmOClVy0yIR9QNZjenON zREAoM4w+cHGxsFbMg7lm9eYw8xK3F2r =Z8NX -----END PGP SIGNATURE----- From Jochen.Bern at LINworks.de Fri Jan 31 15:49:20 2014 From: Jochen.Bern at LINworks.de (Jochen Bern) Date: Fri, 31 Jan 2014 15:49:20 +0100 Subject: GitHub notifications In-Reply-To: <20140130215818.GA344156@zedat.fu-berlin.de> References: <20140130215818.GA344156@zedat.fu-berlin.de> Message-ID: <52EBB7F0.10009@LINworks.de> On 30.01.2014 22:58, Holger Wei? wrote: > [?] Please continue to forward all notifications to this list. > [?] Please filter out status changes, but forward actual comments. > [ ] Please don't forward any GitHub notifications! > [ ] I don't care. I'm a bit torn on the issue. In the best possible world, there should be a "devel" list for everyone having an interest in where development of the plugin goes (which would ask for publication of at least *some* of the comments), while the actual guardians of the official versions/commits would have a "maintainers" list for themselves. But that latter isn't (yet?) in existence for the monitoring-plugins project, is it? Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im : Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Gesch?ftsf?hrer Metin Dogan, Oliver Michel From mshirley at gmail.com Fri Jan 31 18:50:27 2014 From: mshirley at gmail.com (m shirley) Date: Fri, 31 Jan 2014 10:50:27 -0700 Subject: GitHub notifications In-Reply-To: <52EB6A9B.6020302@gmail.com> References: <20140130215818.GA344156@zedat.fu-berlin.de> <52EB6A9B.6020302@gmail.com> Message-ID: Please continue forwarding all notifications to this list. On 30.01.2014 22:58, Holger Wei? wrote: [x] Please continue to forward all notifications to this list. > I appreciate the idea of having all activity in one stream. devel lists are rather dead these days anyways. -- DI (FH) Michael Friedrich mail: michael.friedrich at gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmichi at jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org -------------- next part -------------- An HTML attachment was scrubbed... URL: