|Summary:||net-analyzer/monitoring-plugins-2.1.1 - a bundle of more than fifty standard plugins for Icinga, Naemon, Nagios, Shinken, Sensu, and other monitoring applications|
|Product:||Gentoo Linux||Reporter:||Tomáš Mózes <hydrapolic>|
|Component:||New packages||Assignee:||Default Assignee for New Packages <maintainer-wanted>|
|Package list:||Runtime testing required:||---|
Description Tomáš Mózes 2014-08-18 16:41:02 UTC
There is a new version of monitoring-plugins, created by the former maintainers of nagios-plugins that is in portage. Nagios-plugins is still under development, but only oficially supports nagios. Monitoring-plugins aims to support Icinga, Naemon, Nagios, Shinken, Sensu...
Comment 1 Robin Bankhead 2015-01-04 12:23:18 UTC
Being somewhat invested in this (I think Nagios Enterprises' conduct last year was execrable, nor am I too impressed at the Gentoo maintainers for letting it slide), I'm willing to help if I can to get this into the tree. An initial thought: as these plugins serve multiple cores, thought needs to be given to where they should reside and how each different core can locate and use them. Nagios-core seems to have /usr/lib*/nagios/plugins as a hard-coded plugin dir, so for it to use monitoring-plugins (hey, someone might!) they either have to install there (as nagios-plugins do now), or recoding/symlinking would be needed for it to find them in an alternate location. I'll try to produce a basic copy-and-paste ebuild shortly, to hopefully get this moving.
Comment 2 Robin Bankhead 2015-01-05 12:07:38 UTC
BTW I see that version 2.1.1 is now out. What I first realise I'm unclear on, is which ebuild is the last one under the old team. Should I simply be working off nagios-plugins-1.4.16-r3.ebuild? Or have the projects not yet diverged enough for it to matter? (Or maybe is it better to start from scratch?) Secondly I see that Icinga is the only other compatible monitor in Portage at the moment, so the keeping-everyone-happy part is probably not so hard, though it does I guess mean that both nagios and icinga ebuilds (and any others that enter tree later) will need to do something to support the chosen install location. I will need to bone up on Icinga (and more on nagios itself, I expect). Looking at the tarball docs, the default install location is $PREFIX/libexec, which is a sensible choice. I believe nagios-core just needs this dir to be symlinked under /usr/lib64/nagios/plugins/ to find them; don't know yet what icinga's requirements may be. It also showed me, however, that the install wants to know the http path for the host monitor's CGIs. If that's set at install-time, I'm concerned that supporting multiple monitors (someone will find a reason for needing this, I'm sure) may be problematic.  https://www.monitoring-plugins.org/news/release-2-1-1.html
Comment 3 Anthony Parsons 2015-02-14 19:14:22 UTC
(In reply to Robin Bankhead from comment #2) > BTW I see that version 2.1.1 is now out. > > What I first realise I'm unclear on, is which ebuild is the last one under > the old team. Should I simply be working off > nagios-plugins-1.4.16-r3.ebuild? Or have the projects not yet diverged > enough for it to matter? (Or maybe is it better to start from scratch?) 1.4.16-r3 was added in 2012, so it's safe to assume it's the real deal. It'd make sense to keep the ebuild if it works, after all only the name has changed.
Comment 4 Tomáš Mózes 2015-02-14 22:35:54 UTC
Created attachment 396476 [details] monitoring-plugins-2.1.1.ebuild Based on nagios-plugins-2.0.3-r1.ebuild. Added gnutls support.
Comment 5 Tomáš Mózes 2015-02-14 23:05:31 UTC
Nagios-plugins could be either added as a virtual (let's say virtual/nagios-plugins) or just separate and the ebuilds then need to be updated with mentioning both, nagios-plugins and monitoring-plugins (packages that use them - icinga, nagios, nrpe, etc.). Since the versions in the future can diverge, it may be problematic to express the dependencies via the virtual - some of the packages mention the version of nagios-plugins to be installed (for example nagios-check_logfiles/nagios-check_logfiles-18.104.22.168-r1.ebuild). Maybe it's not a problem today and it's just a historical artefact, however it may be a problem in the future, who knows... It seems like nagios-plugins is dead (last commit 06/2014), however monitoring-plugins is constantly being updated. I believe it would be easier to just append a possible dependency on monitoring-plugins and to not have a virtual - what do you think?
Comment 6 Tomáš Mózes 2015-02-16 10:40:38 UTC
Created attachment 396588 [details] monitoring-plugins-2.1.1.ebuild Add blocker on nagios-plugins, change USE, thanks mjo for the tips.
Comment 7 Michael Orlitzky 2015-02-21 23:15:14 UTC
Ok, should show up soon: *monitoring-plugins-2.1.1 (21 Feb 2015) 21 Feb 2015; Michael Orlitzky <firstname.lastname@example.org> +metadata.xml, +monitoring-plugins-2.1.1.ebuild: New package with standard plugins for Icinga, Naemon, Nagios, etc. by Tomas Mozes (bug #520196). I'm going to revbump nagios to make this optional, and open a bug for net-analyzer/nrpe as well.
Comment 8 Tomáš Mózes 2015-02-22 08:01:53 UTC
Great, thanks Michael!
Comment 9 Robin Bankhead 2015-02-22 12:34:43 UTC
Must have missed some interim bugmails, as I didn't know this was on the move until today - great news! Thanks all. I do have one reservation about the methodology, in that it perpetuates the status quo where users still aren't being told by portage about what happened. IOW, nagios-plugins continues on as though nothing had changed, and users don't find out about it until/unless compatibility breaks. I want to emphasise that I'm not just blowing smoke when I say that: the first "poisoned" nagios-plugins update did just that to me, by removing (again, without a word) contrib plugins, one of which I was using. That's how I found out about all of this myself. As little more than an armchair critic I know I have no vote in any of this, but I'll state that the above was/is letting users down, IMHO.