Bug 1054340 - Update upstream URL to https://www.monitoring-plugins.org
Summary: Update upstream URL to https://www.monitoring-plugins.org
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: nagios-plugins
Version: 22
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
Assignee: Nick Bebout
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 16:30 UTC by Michael Friedrich
Modified: 2021-07-11 06:41 UTC (History)
35 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-31 21:21:31 UTC
Type: Bug
Embargoed:
me: fedora_requires_release_note+


Attachments (Terms of Use)
Update Url/Source to monitoring-plugins.org (1015 bytes, patch)
2014-01-16 16:33 UTC, Michael Friedrich
no flags Details | Diff

Description Michael Friedrich 2014-01-16 16:30:37 UTC
Description of problem: 

The nagios-plugins.org website has been compromised, and the project team therefore moved to https://www.monitoring-plugins.org including the tarball releases. They also renamed their project from 'nagios-plugins' to 'monitoring-plugins' and it's most likely that the tarball release names will be changed to the new name in future releases.

https://www.monitoring-plugins.org/archive/help/2014-January/006503.html

Additional info:

While I wouldn't suggest to rename the package unless there's an immediate requirement, the source and URL location should be updated in order to use official releases provided by the Monitoring Plugins Development Team. Further, users should use official online references and stay safe.

Attached is a patch against HEAD.

Comment 1 Michael Friedrich 2014-01-16 16:33:14 UTC
Created attachment 851158 [details]
Update Url/Source to monitoring-plugins.org

Comment 2 Andy Brist 2014-01-17 15:53:39 UTC
This is absolutely not true.  The nagios-plugins.org website has not been compromised. The site is safe and hosted by Nagios Enterprises.  monitoring-plugins.org is a new fork and should be named as such.  The nagios-plugins project will continue with the same url (nagios-plugins.org) and github account (github.com/nagios-plugins). I would suggest those in doubt to contact Nagios Enterprises directly:

http://www.nagios.com/contact/
US: 1-888-NAGIOS-1 (1-888-624-4671)

Comment 3 Sam Kottler 2014-01-17 15:57:09 UTC
Thanks for the clarification, Andy. So what would you recommend going forward? Would it be wrong for us to continue to call this package nagios-plugins and change the upstream URL?

Comment 4 Andy Brist 2014-01-17 16:03:00 UTC
(In reply to Sam Kottler from comment #3)
> Thanks for the clarification, Andy. So what would you recommend going
> forward? Would it be wrong for us to continue to call this package
> nagios-plugins and change the upstream URL?

The current package should retain the name.  Any future updates from the monitoring-plugins team should carry a new name as is expected with forks.  The nagios-plugins project will continue under the same name, albeit with new team members.

Comment 5 Sam Kottler 2014-01-17 16:11:05 UTC
Okay, thanks for that info. I'm closing this issue because it sounds like nothing needs to happen right now. Feel free to reopen this in the future if something changes.

Comment 6 Michael Friedrich 2014-01-17 16:20:15 UTC
Actually the old Nagios Plugins Development Team was required to rename their project due to the fact that Nagios Enterprises hijacked the DNS and website and kicked them out. 

Whilst the original memebers are now known as 'Monitoring Plugins Development Team', the newly formed 'Nagios Core Plugin Development Team' is actually providing a fork of their work under the old name.

For any clarifications required, you should follow the discussion here: https://www.monitoring-plugins.org/archive/devel/2014-January/009417.html

Imho the official former nagios plugins are now provided by the same developers under a new URL and that should be reflected for any future updates.

Though, I'm leaving that to you who to trust here. I'm just a community member appreciating the work done by the original Nagios Plugins Development team, accepting their origin and the fact that there's no censorship of Icinga, Shinken or Naemon (as Nagios forks) needed.

Comment 7 Andy Brist 2014-01-17 16:45:32 UTC
(In reply to Michael Friedrich from comment #6)
> Actually the old Nagios Plugins Development Team was required to rename
> their project due to the fact that Nagios Enterprises hijacked the DNS and
> website and kicked them out. 

The domain was, and continues to be, owned by Nagios Enterprises.

> Whilst the original memebers are now known as 'Monitoring Plugins
> Development Team', the newly formed 'Nagios Core Plugin Development Team' is
> actually providing a fork of their work under the old name.

nagios-plugins is not a fork, but a rebase with new team members.  monitoring-plugins is indeed a fork, as their new name suggests. 

If you need any further clarification, please contact Nagios enterprises directly.

Thank you kindly.

Comment 8 Michael Friedrich 2014-01-17 17:03:39 UTC
(In reply to Andy Brist from comment #7)
> (In reply to Michael Friedrich from comment #6)
> > Actually the old Nagios Plugins Development Team was required to rename
> > their project due to the fact that Nagios Enterprises hijacked the DNS and
> > website and kicked them out. 
> 
> The domain was, and continues to be, owned by Nagios Enterprises.

The "good" thing about that is, that noone did get a complaint by ICANN claiming the trademark on the domain and requiring a transfer, as happened to nagios-portal.org before.

But yeah, as domain owner you can treat your community like shit, and still feel happy about it. It's still a miracle why you didn't fork the former Nagios Plugins project into your own enterprise product stack any sooner. Probably their work was just needed, and now you're just throwing them away like rubbish. 

> 
> > Whilst the original memebers are now known as 'Monitoring Plugins
> > Development Team', the newly formed 'Nagios Core Plugin Development Team' is
> > actually providing a fork of their work under the old name.
> 
> nagios-plugins is not a fork, but a rebase with new team members. 
> monitoring-plugins is indeed a fork, as their new name suggests.

Sounds odd with a single import of 1.5 release into git. I would trust the project with a 10+ years / 2000+ commits history. 
 
> 
> If you need any further clarification, please contact Nagios enterprises
> directly.

Please discuss that publicly in order to let anyone comment on the issue, rather than hiding it somewhere, like usual.

> 
> Thank you kindly.

Not really. Thanks for nothing.

Comment 9 Jan Wagner 2014-01-17 17:22:25 UTC
Hi there,

you can compare just the VCS histroy.

https://github.com/monitoring-plugins/monitoring-plugins/commits/master
https://github.com/nagios-plugins/nagios-plugins/commits/master

Look into it and think about what project forked from what ... smart people will get the obviously.

Cheers, Jan.

Comment 10 Andy Brist 2014-01-17 18:46:48 UTC
For clarification purposes, the monitoring-plugins project team has essentially forked the project.  Nagios Enterprises owns the nagios-plugins project.  The monitoring-plugins team changed the name and location of the repo.  Nagios Enterprises has rebased with a new team using the same urls and repo locations the project has always used.  

Further evidence of the fork can be found on the git repos for the monitoring-plugins site:

https://www.monitoring-plugins.org/repositories/site/diff/web/input/doc/faq/control.md?id=58af77e919ee68d1cba1b5dce3e745003d7d6d67 

My apologies for any disruption this has caused.  It is my opinion that no action needs to be taken at the moment.  When a new release from either project is ready, they should end up in their respective packages:  nagios-plugins should remain nagios-plugins, while monitoring-plugins should be packaged under a different name (monitoring-plugins perhaps?).

Comment 11 Michael Friedrich 2014-01-17 19:39:35 UTC
(In reply to Andy Brist from comment #10)
> For clarification purposes, the monitoring-plugins project team has
> essentially forked the project.  Nagios Enterprises owns the nagios-plugins
> project.  The monitoring-plugins team changed the name and location of the
> repo.  Nagios Enterprises has rebased with a new team using the same urls
> and repo locations the project has always used.  
> 
> Further evidence of the fork can be found on the git repos for the
> monitoring-plugins site:
> 
> https://www.monitoring-plugins.org/repositories/site/diff/web/input/doc/faq/
> control.md?id=58af77e919ee68d1cba1b5dce3e745003d7d6d67 

The only evidence I do see here is the fact that Nagios Enterprises *never* controlled the project in any way, only got the domain transferred for trademark reasons. Owning a project does not necessarily mean to control their releases and development cycles.

So basically, once and for all, the same volunteers have acted as Nagios Plugins Development Team and are now providing their same hard work under a new name, required by the obvious change enforced by Nagios Enterprises in regards of changing the domain and its content to a duplicate (a 1:1 copy, a fork) of the website, now trying to convince upstream packagers that it's their project.

The only fact here what counts imho - upstream packagers are not bound to upstream tarball sources, nor any trademark enforcing them to do so some action.

And just because Nagios Enterprises claims to own the nagios plugins project doesn't mean that Fedora must use their tarball. Fedora may just use the one provided by monitoring-plugins, just like other upstream distributions like Debian will do.

> 
> My apologies for any disruption this has caused.  It is my opinion that no
> action needs to be taken at the moment.  When a new release from either
> project is ready, they should end up in their respective packages: 
> nagios-plugins should remain nagios-plugins, while monitoring-plugins should
> be packaged under a different name (monitoring-plugins perhaps?).

Imho https://www.monitoring-plugins.org ships the only valid history for updating the Fedora package 'nagios-plugins' and making sure that future packages remain built from the same source, as before. Imho a new, even rebased project must provide proof and evidence that they will continue to develop the current used upstream sources, and may ask to take over the probably misleading name. But not with just importing a forked code repository on github, and then coming here, and telling that everything is ok (which obviously it isn't).

Comment 12 Jan Wagner 2014-01-17 19:48:06 UTC
Andy,

(In reply to Andy Brist from comment #10)
> Further evidence of the fork can be found on the git repos for the
> monitoring-plugins site:
> 
> https://www.monitoring-plugins.org/repositories/site/diff/web/input/doc/faq/
> control.md?id=58af77e919ee68d1cba1b5dce3e745003d7d6d67 

All this fuzz is caused about the trademark of 'Nagios'. So the owner of this trademark has control over who is able to use the name 'Nagios Plugins'. As you can see in you diff:

"This means that decisions about the web site and the development of code related to the project are handled independently by the team."

The trademark holder has control over the name, while all other decisions and code changes where independently taken by the team members (none of the actual ones is in any relation to the trademark holder).

> My apologies for any disruption this has caused.  It is my opinion that no
> action needs to be taken at the moment.  When a new release from either
> project is ready, they should end up in their respective packages: 
> nagios-plugins should remain nagios-plugins, while monitoring-plugins should
> be packaged under a different name (monitoring-plugins perhaps?).

This maybe one way. As the origin team swapped the name, due obvious reasons and the trademark holder forked from this project, some may argue that just the origin project changed his name and a new one started under the old project name.
Under the code (and upstream maintainers) point of view monitoring-plugins has the same code and developer base as nagios-plugins was until 2014-15-01.

Comment 13 Andy Brist 2014-01-17 20:46:35 UTC
Jan,
(In reply to Jan Wagner from comment #12)
> This maybe one way. As the origin team swapped the name, due obvious reasons
> and the trademark holder forked from this project, some may argue that just
> the origin project changed his name and a new one started under the old
> project name.
> Under the code (and upstream maintainers) point of view monitoring-plugins
> has the same code and developer base as nagios-plugins was until 2014-15-01.

And this will remain the case, as the commit logs have been retained on the nagios-plugins repo.  The question is what to do about package names moving forward.  Until the next release from either project, the package, as it stands, should remain untouched.  I feel there will be more confusion introduced by packaging the the next "monitoring-plugins" version as "nagios-plugins" as they no longer develop or control the nagios-plugins project and the next nagios-plugins release will most definitely be called "nagios-plugins" whereas theirs will most likely be named "monitoring-plugins" as their github account suggests.  As the monitoring-plugins project changed their name and repository, their future packages reflect that fact.  

Any new releases from the nagios-plugins project could and should retain the name so as not to further confuse the issue.  I feel the break is already rather public, so those who care to be aware, will be soon enough and the decision to change a project name does include certain consequences pertaining to domains, package names, and upstream conventions.

I would like to remind those involved with this dispute, that nagios-plugins source was originally developed and supported by Ethan Galstad for a number of years before community involvement.  Many of the plugins still bear his name and copyright.  Releasing future packages not associated with Nagios but retaining the Nagios name would further confuse users.

I am curious as to what the packagers think about this current situation.
Regards.

Comment 14 Sam Kottler 2014-01-17 21:03:27 UTC
(In reply to Andy Brist from comment #13)
> Jan,
> (In reply to Jan Wagner from comment #12)
> > This maybe one way. As the origin team swapped the name, due obvious reasons
> > and the trademark holder forked from this project, some may argue that just
> > the origin project changed his name and a new one started under the old
> > project name.
> > Under the code (and upstream maintainers) point of view monitoring-plugins
> > has the same code and developer base as nagios-plugins was until 2014-15-01.
> 
> And this will remain the case, as the commit logs have been retained on the
> nagios-plugins repo.  The question is what to do about package names moving
> forward.  Until the next release from either project, the package, as it
> stands, should remain untouched.  I feel there will be more confusion
> introduced by packaging the the next "monitoring-plugins" version as
> "nagios-plugins" as they no longer develop or control the nagios-plugins
> project and the next nagios-plugins release will most definitely be called
> "nagios-plugins" whereas theirs will most likely be named
> "monitoring-plugins" as their github account suggests.  As the
> monitoring-plugins project changed their name and repository, their future
> packages reflect that fact.  

Agreed. I do not want to keep the package name the same and change the Source0 to point to an upstream of a different name. Splitting the packages apart and maintaining them separately; if everyone agrees that is a reasonable path forward then I'll start doing the work to get that done in rawhide and for EPEL 7. We can also work on getting that done for EPEL 6 and Fedora 19/20 if people think it'd be fruitful.

> 
> Any new releases from the nagios-plugins project could and should retain the
> name so as not to further confuse the issue.  I feel the break is already
> rather public, so those who care to be aware, will be soon enough and the
> decision to change a project name does include certain consequences
> pertaining to domains, package names, and upstream conventions.

+1.

> 
> I would like to remind those involved with this dispute, that nagios-plugins
> source was originally developed and supported by Ethan Galstad for a number
> of years before community involvement.  Many of the plugins still bear his
> name and copyright.  Releasing future packages not associated with Nagios
> but retaining the Nagios name would further confuse users.
> 
> I am curious as to what the packagers think about this current situation.
> Regards.

I hope my comments above provide a reasonable route to resolving this issue. What do the two parties involved think?

Comment 15 Andy Brist 2014-01-17 21:08:20 UTC
(In reply to Sam Kottler from comment #14)
> Agreed. I do not want to keep the package name the same and change the
> Source0 to point to an upstream of a different name. Splitting the packages
> apart and maintaining them separately; if everyone agrees that is a
> reasonable path forward then I'll start doing the work to get that done in
> rawhide and for EPEL 7. We can also work on getting that done for EPEL 6 and
> Fedora 19/20 if people think it'd be fruitful.

Can I presume that the splitting of the packages entails:

1) Retaining the current spec for "nagios-plugins" so that we may be able to release new versions under the current package name.

2) Using a new package name and spec file for "monitoring-plugins" moving forward.

?

> I hope my comments above provide a reasonable route to resolving this issue.
> What do the two parties involved think?

As do I.  Regards.

Comment 16 Jan Wagner 2014-01-17 21:12:46 UTC
From the users of the distribution point of view, they installed a piece of software ... when upgrading they expect to have a new version of the software they installed in the past.
Following here the software of the upstream developer whould result ito using 'monitoring-plugins'.

Anyhow ... I have no knowledge about how rpm can handle this. As packager I would maybe do the following for further releases:

* Source package: nagios-enterprises-plugins
* Source package: monitoring-plugins
  - Here providing the old 'nagios-plugins-*' packages.

This would give the users the route they decided when they installed their packages mapped to the upstream developers.

Comment 17 Holger Weiß 2014-01-17 21:35:57 UTC
I'm one of the maintainers of the original Nagios Plugins project that
has now been forced to change its name.  So, I'm obviously biased---just
like Andy Brist, but from the other side of the fence.

I guess the answer to the question of who forked whom isn't immediately
obvious, especially if you're not involved in the mess.  It'll depend on
how exactly you define a "fork", and it may not be all that relevant for
the decision on how to proceed with the RedHat/Fedora packaging anyway.

Let me just add my view on the current situation.  I'd invite Andy (or
anyone else) to let us know if he thinks I got any of my facts wrong.
Hopefully that'll help RedHat/Fedora with making an informed decision on
which of the two upstreams to use for packaging, or whether to package
both.

Over the past several years, the Nagios Plugins project was maintained
by a team of volunteers not affiliated with Nagios Enterprises.
However, back in 2011, we transferred the "nagios-plugins.org" domain to
Nagios Enterprises on their request.  This transfer was coupled with an
agreement that the actual maintainers would continue to run the project
independently.¹  However, a few days ago, Nagios Enterprises copied most
of our web site and changed the DNS records to point to their web space
instead, which now serves a slightly modified version of our site
including the tarballs we created.  This was done without prior notice.
From what I understand², their reasoning for this move was that they
weren't happy with us mentioning competing monitoring products on our
home page (please correct me if I'm wrong, Andy).³

So, we now have two upstreams:

One driven by the team that lost its domain, but that did the actual
maintenance work in the past, and that will continue to maintain the
same project with the same infrastructure (GitHub repos/trackers,
mailing lists, automated test builds, and so on) under the new name.

The other one is driven by a team that seems to be "new" indeed:
Personally I don't recall *any* contributions of *any* of the new team
members (in fact I didn't even know their names before reading them on
the new Nagios Plugins web site).  Or can you point me to just a single
patch or mailing list posting of any of the members of the new team,
Andy?  Don't get me wrong: You guys may well be into Nagios Plugins
development.  But for outsiders like me, the fact that you didn't show
any public activity in this area so far might add a bit of uncertainty
regarding the future of your project.

In short, I see two differences to a "prototypical" fork:

1) The project that has been forked doesn't own the domain name.
2) The project that performed the fork did so without showing any previous
   development activities.

¹ https://www.monitoring-plugins.org/news/domain-transfer.html
² https://www.monitoring-plugins.org/archive/devel/2014-January/009420.html
³ https://www.monitoring-plugins.org/archive/devel/2014-January/009428.html

Comment 18 Jan Wagner 2014-01-17 21:36:56 UTC
(In reply to Andy Brist from comment #15)
> Can I presume that the splitting of the packages entails:
> 
> 1) Retaining the current spec for "nagios-plugins" so that we may be able to
> release new versions under the current package name.
> 
> 2) Using a new package name and spec file for "monitoring-plugins" moving
> forward.

Sorry, but I can't suppress the feeling that Nagios Enterprises, LLC tries to keep relevant in the monitoring scene and is hardly trying to convince everybody that the now called 'nagios-plugins' software will overrule it's competitors. 
Even if that means they need to use the name other individuals used in the past for their work and copy over website and design from others.

This all makes it very hard to keep emotions out of this, but this is not the first time that Nagios Enterprises, LLC is going to be harsh to people they used their contribution in the past (and build business on top) and now going to abuse them.

Comment 19 Sam Kottler 2014-01-17 21:56:31 UTC
(In reply to Andy Brist from comment #15)
> (In reply to Sam Kottler from comment #14)
> > Agreed. I do not want to keep the package name the same and change the
> > Source0 to point to an upstream of a different name. Splitting the packages
> > apart and maintaining them separately; if everyone agrees that is a
> > reasonable path forward then I'll start doing the work to get that done in
> > rawhide and for EPEL 7. We can also work on getting that done for EPEL 6 and
> > Fedora 19/20 if people think it'd be fruitful.
> 
> Can I presume that the splitting of the packages entails:
> 
> 1) Retaining the current spec for "nagios-plugins" so that we may be able to
> release new versions under the current package name.

Yes, that's right.

> 
> 2) Using a new package name and spec file for "monitoring-plugins" moving
> forward.

Yep.

> 
> ?
> 
> > I hope my comments above provide a reasonable route to resolving this issue.
> > What do the two parties involved think?
> 
> As do I.  Regards.

Comment 20 Andy Brist 2014-01-17 22:04:37 UTC
(In reply to Sam Kottler from comment #19)
> (In reply to Andy Brist from comment #15)
> > Can I presume that the splitting of the packages entails:
> > 
> > 1) Retaining the current spec for "nagios-plugins" so that we may be able to
> > release new versions under the current package name.
> 
> Yes, that's right.
> 
> > 
> > 2) Using a new package name and spec file for "monitoring-plugins" moving
> > forward.
> 
> Yep.
Alright. This was my understanding and I find the solution agreeable.

Comment 21 Sam Kottler 2014-01-17 22:07:34 UTC
(In reply to Holger Weiß from comment #17)
> I'm one of the maintainers of the original Nagios Plugins project that
> has now been forced to change its name.  So, I'm obviously biased---just
> like Andy Brist, but from the other side of the fence.
> 
> I guess the answer to the question of who forked whom isn't immediately
> obvious, especially if you're not involved in the mess.  It'll depend on
> how exactly you define a "fork", and it may not be all that relevant for
> the decision on how to proceed with the RedHat/Fedora packaging anyway.
> 
> Let me just add my view on the current situation.  I'd invite Andy (or
> anyone else) to let us know if he thinks I got any of my facts wrong.
> Hopefully that'll help RedHat/Fedora with making an informed decision on
> which of the two upstreams to use for packaging, or whether to package
> both.

I'm starting to feel more and more strongly after reading about the issue and researching the history that both nagios-plugins and monitoring-plugins can and should both be included in Fedora + EPEL. monitoring-plugins can have a Conflicts with nagios-plugins and vice versa. At some point if one of the projects becomes canonical and the community has agreed it has succeeded then we can just add an Obseletes for the other package to the package that has grown to be successful.

> 
> Over the past several years, the Nagios Plugins project was maintained
> by a team of volunteers not affiliated with Nagios Enterprises.
> However, back in 2011, we transferred the "nagios-plugins.org" domain to
> Nagios Enterprises on their request.  This transfer was coupled with an
> agreement that the actual maintainers would continue to run the project
> independently.¹  However, a few days ago, Nagios Enterprises copied most
> of our web site and changed the DNS records to point to their web space
> instead, which now serves a slightly modified version of our site
> including the tarballs we created.  This was done without prior notice.
> From what I understand², their reasoning for this move was that they
> weren't happy with us mentioning competing monitoring products on our
> home page (please correct me if I'm wrong, Andy).³
> 
> So, we now have two upstreams:
> 
> One driven by the team that lost its domain, but that did the actual
> maintenance work in the past, and that will continue to maintain the
> same project with the same infrastructure (GitHub repos/trackers,
> mailing lists, automated test builds, and so on) under the new name.
> 
> The other one is driven by a team that seems to be "new" indeed:
> Personally I don't recall *any* contributions of *any* of the new team
> members (in fact I didn't even know their names before reading them on
> the new Nagios Plugins web site).  Or can you point me to just a single
> patch or mailing list posting of any of the members of the new team,
> Andy?  Don't get me wrong: You guys may well be into Nagios Plugins
> development.  But for outsiders like me, the fact that you didn't show
> any public activity in this area so far might add a bit of uncertainty
> regarding the future of your project.

I'm happy to help you work toward a resolution of this issue in EPEL/Fedora, but please try to keep stuff like this last paragraph on the mail lists where other discussions are happening. They don't really help move things forward.

> 
> In short, I see two differences to a "prototypical" fork:
> 
> 1) The project that has been forked doesn't own the domain name.
> 2) The project that performed the fork did so without showing any previous
>    development activities.

Right, agreed on both counts that those two make this fork a little different. Even still, there's no doubt that both can co-exist in the same distro despite seemingly severe contention between the upstream projects.

> 
> ¹ https://www.monitoring-plugins.org/news/domain-transfer.html
> ² https://www.monitoring-plugins.org/archive/devel/2014-January/009420.html
> ³ https://www.monitoring-plugins.org/archive/devel/2014-January/009428.html

Comment 22 Sam Kottler 2014-01-17 22:11:30 UTC
(In reply to Andy Brist from comment #20)
> (In reply to Sam Kottler from comment #19)
> > (In reply to Andy Brist from comment #15)
> > > Can I presume that the splitting of the packages entails:
> > > 
> > > 1) Retaining the current spec for "nagios-plugins" so that we may be able to
> > > release new versions under the current package name.
> > 
> > Yes, that's right.
> > 
> > > 
> > > 2) Using a new package name and spec file for "monitoring-plugins" moving
> > > forward.
> > 
> > Yep.
> Alright. This was my understanding and I find the solution agreeable.

Also, just to make it clear I'm willing to be the maintainer for both the nagios-plugins and monitoring-plugins packages if that's ultimately the route we decide to take.

Comment 23 Holger Weiß 2014-01-17 22:13:58 UTC
(In reply to Sam Kottler from comment #14)
> I hope my comments above provide a reasonable route to resolving this issue.
> What do the two parties involved think?

I'm sorry, but for the moment, I have no idea why a user would want to switch to tarballs provided by Nagios Enterprises.  This might change in the future, of course.  Therefore, my feeling is that it's too early for deciding on this issue.

That said, my hope was simply that we were able to explain the current situation more or less accurately.  As long as you actually understood what happened and where the two upstreams are coming from, I'm (of course) totally fine with you deciding whatever you think is the best solution for RedHat/Fedora.

Thanks for taking the time to look into this mess.

Comment 24 Sam Kottler 2014-01-18 11:21:46 UTC
(In reply to Holger Weiß from comment #23)
> (In reply to Sam Kottler from comment #14)
> > I hope my comments above provide a reasonable route to resolving this issue.
> > What do the two parties involved think?
> 
> I'm sorry, but for the moment, I have no idea why a user would want to
> switch to tarballs provided by Nagios Enterprises.  This might change in the
> future, of course.  Therefore, my feeling is that it's too early for
> deciding on this issue.

I agree that it's too early to decide on the issue. These are the packages in EPEL that depend on nagios-plugins and what do we want to do about them? Create community-plugins-* alternatives?

nagios-plugins-apt-0:1.4.16-10.el6.x86_64
nagios-plugins-breeze-0:1.4.16-10.el6.x86_64
nagios-plugins-by_ssh-0:1.4.16-10.el6.x86_64
nagios-plugins-check-updates-0:1.6.3-1.el6.x86_64
nagios-plugins-check_sip-0:1.3-4.el6.x86_64
nagios-plugins-cluster-0:1.4.16-10.el6.x86_64
nagios-plugins-dhcp-0:1.4.16-10.el6.x86_64
nagios-plugins-dig-0:1.4.16-10.el6.x86_64
nagios-plugins-disk-0:1.4.16-10.el6.x86_64
nagios-plugins-disk_smb-0:1.4.16-10.el6.x86_64
nagios-plugins-dns-0:1.4.16-10.el6.x86_64
nagios-plugins-dummy-0:1.4.16-10.el6.x86_64
nagios-plugins-file_age-0:1.4.16-10.el6.x86_64
nagios-plugins-flexlm-0:1.4.16-10.el6.x86_64
nagios-plugins-fping-0:1.4.16-10.el6.x86_64
nagios-plugins-game-0:1.4.16-10.el6.x86_64
nagios-plugins-hpjd-0:1.4.16-10.el6.x86_64
nagios-plugins-http-0:1.4.16-10.el6.x86_64
nagios-plugins-icmp-0:1.4.16-10.el6.x86_64
nagios-plugins-ide_smart-0:1.4.16-10.el6.x86_64
nagios-plugins-ifoperstatus-0:1.4.16-10.el6.x86_64
nagios-plugins-ifstatus-0:1.4.16-10.el6.x86_64
nagios-plugins-ircd-0:1.4.16-10.el6.x86_64
nagios-plugins-lcgdm-common-0:0.9.5-1.el6.x86_64
nagios-plugins-ldap-0:1.4.16-10.el6.x86_64
nagios-plugins-linux_raid-0:1.4.16-10.el6.x86_64
nagios-plugins-load-0:1.4.16-10.el6.x86_64
nagios-plugins-log-0:1.4.16-10.el6.x86_64
nagios-plugins-mailq-0:1.4.16-10.el6.x86_64
nagios-plugins-mrtg-0:1.4.16-10.el6.x86_64
nagios-plugins-mrtgtraf-0:1.4.16-10.el6.x86_64
nagios-plugins-mysql-0:1.4.16-10.el6.x86_64
nagios-plugins-nagios-0:1.4.16-10.el6.x86_64
nagios-plugins-nrpe-0:2.14-5.el6.x86_64
nagios-plugins-nt-0:1.4.16-10.el6.x86_64
nagios-plugins-ntp-0:1.4.16-10.el6.x86_64
nagios-plugins-ntp-perl-0:1.4.16-10.el6.x86_64
nagios-plugins-nwstat-0:1.4.16-10.el6.x86_64
nagios-plugins-openmanage-0:3.7.11-1.el6.x86_64
nagios-plugins-oracle-0:1.4.16-10.el6.x86_64
nagios-plugins-overcr-0:1.4.16-10.el6.x86_64
nagios-plugins-perl-0:1.4.16-10.el6.x86_64
nagios-plugins-pgsql-0:1.4.16-10.el6.x86_64
nagios-plugins-ping-0:1.4.16-10.el6.x86_64
nagios-plugins-procs-0:1.4.16-10.el6.x86_64
nagios-plugins-radius-0:1.4.16-10.el6.x86_64
nagios-plugins-real-0:1.4.16-10.el6.x86_64
nagios-plugins-rhev-0:1.0.0-2.el6.noarch
nagios-plugins-rpc-0:1.4.16-10.el6.x86_64
nagios-plugins-sensors-0:1.4.16-10.el6.x86_64
nagios-plugins-smtp-0:1.4.16-10.el6.x86_64
nagios-plugins-snmp-0:1.4.16-10.el6.x86_64
nagios-plugins-ssh-0:1.4.16-10.el6.x86_64
nagios-plugins-swap-0:1.4.16-10.el6.x86_64
nagios-plugins-tcp-0:1.4.16-10.el6.x86_64
nagios-plugins-time-0:1.4.16-10.el6.x86_64
nagios-plugins-ups-0:1.4.16-10.el6.x86_64
nagios-plugins-users-0:1.4.16-10.el6.x86_64
nagios-plugins-wave-0:1.4.16-10.el6.x86_64

> 
> That said, my hope was simply that we were able to explain the current
> situation more or less accurately.  As long as you actually understood what
> happened and where the two upstreams are coming from, I'm (of course)
> totally fine with you deciding whatever you think is the best solution for
> RedHat/Fedora.
> 
> Thanks for taking the time to look into this mess.

Comment 25 Jan Wagner 2014-01-18 13:44:51 UTC
(In reply to Sam Kottler from comment #24)
> I agree that it's too early to decide on the issue. These are the packages
> in EPEL that depend on nagios-plugins and what do we want to do about them?

Dunno if rpm have a 'provide', but if, I would add such a provide to the corresponding binary packages. This would be "nagios-enterprises-plugins" and "monitoring-plugins" as long as both are compatible.

> Create community-plugins-* alternatives?

This isn't a bad idea at all, as those plugins aren't either from Nagios Enterprises, LCC nor from the Monitoring Plugins Project. If there are projects maintaining a larger set of plugins those should maybe get it's own source package.

Cheers, Jan.

Comment 26 Michael Friedrich 2014-01-18 14:00:33 UTC
Just a final thought on the packages and which will be installed/upgraded by default:

I'm maintaining and leading the Icinga Core development (a fellow fork of Nagios in 2009) amongst the other projects such as Web, Reporting, etc.

Ihe Icinga community users are using the Fedora/EPEL packages currently named 'nagios-plugins' which are built from sources maintained and developed by the former Nagios Plugins Dev Team, now Monitoring Plugins Dev Team.

If the now hijacked (yes, for me this phrase is the real truth about the happenings) sources are used for future package builds, I cannot ensure that our community members are not getting any untrusted stuff during their upgrade maintenance. Just because it's a totally new formed project acting as the old established trust platform.

It doesn't matter if Nagios Enterprises says not to do any harm. It's a different scope here, and opens a door into every (!) server having this package installed. Some could also think of hijacking a package already installed everywhere.

What I am saying is

- The user should be made aware of the changed sources on upgrade acknowledging the fact (which obviously noone does, but a Changelog entry explaining some details is necessary imho)
- *if* there is a new package named 'monitoring-plugins' the current 'nagios-plugins' package should be made a transitional package and forward every install to its new origin. 
- The newly formed Nagios Plugins Dev Team shall use a different name space, such as 'nagios-core-plugins' and may act as opt-in replacement, if the user chooses to do so. But not as default upgrade option.

And I am saying that also for the reason, that every single documentation for any Nagios Core or Forks now points to the nagios-plugins rpm. That would be insane from a community support guy's point of view to make all those docs/howto changes happen - while imho the package upstream could take care of it.

I guess the Shinken and Naemon guys would think the same, but I'll forward them the question.

It's a matter of trust & honesty here, not necessarily business.

Comment 27 Drew Blessing 2014-01-18 16:26:54 UTC
I agree with Michael. It would be extremely misleading and, IMO, unsafe to allow the "new" nagios-plugins maintainers to provide new packages under the nagios-plugins name. I have installed nagios-plugins packages on my servers and trust the now monitoring-plugins maintainers. If it is unacceptable to allow the monitoring-plugins team to release new nagios-plugins packages then I suggest both teams should be required to package under a new name. Then, as a user, I am forced to make an informed decision.

Comment 28 Sven Nierlein 2014-01-18 17:32:00 UTC
I totally agree with michael here. From users perspective, the worst thing that could happen is getting an update for the nagios-plugins package from a new upstream source from a new team (which till now had nothing to do with maintaining that piece of software)
The monitoring-plugins team is in fact the source of that package and therefor
should be used for upcoming releases too. Everything else would be dangerous and misleading.
I do however see a problem with the package name itself, so a transitional package would be a good idea to make it easier for packagers to move on to a
renamed package.

Comment 29 David Greaves 2014-01-19 15:29:46 UTC
Agreeing with Michael.

As a user of the package identified by the string "nagios-plugins" I consider that string to represent a connection to a team of people who have demonstrated their ability to maintain an opensource project; not a relationship to the owner of a brand that happens to partially match although sometimes that happens to be the same thing.

If a new team of people found a technical security hole that allowed them to subvert the Provides: of a well known package I think that would be a serious bug. This seems to be a social/legal 'hole' that could result in the same effect although of course it's being managed here.

Reading around the subject and mainly being influenced by comment #17 I personally
would be happy with the original patch and with nagios-plugins being replaced by monitoring-plugins due to brand-driven renaming and would expect nagios-enterprise-plugins to have to follow the route of any new package for inclusion in the distribution.

Comment 30 Sam Kottler 2014-01-19 16:40:28 UTC
I don't necessarily disagree with moving the current nagios-plugins to be under some different name, but let's not get ahead of ourselves. I'm working on getting a review submitted for monitoring-plugins and should have that done in the next 24 hours. Once monitoring-plugins is available then we can figure out what to do about nagios-plugins. I'm not really very comfortable with changing the package name in existing releases (like EPEL 6 or Fedora 20) without providing a 100% compatible upgrade path.

Additionally, I've decided that I will not be maintaining nagios-plugins in EPEL 7, but will be happy to be the monitoring-plugins maintainer.

Comment 31 Drew Blessing 2014-01-19 17:42:02 UTC
Sam,

By having monitoring-plugins in EPEL 6 what options does that leave for nagios-plugins? Continue with the new nagios-plugins team as provider for the packages, remove them, or make them a pointer toward the monitoring-plugins? I'm just looking for clarification. It seems like maybe the entire path forward should be decided before making any changes, including the addition of monitoring-plugins.

Comment 32 Michael Friedrich 2014-01-19 17:53:01 UTC
Yeah, that's good news!

I've looked into the list of dependencies below in order to also sort upgrade path issues.

(In reply to Sam Kottler from comment #24)
> I agree that it's too early to decide on the issue. These are the packages
> in EPEL that depend on nagios-plugins and what do we want to do about them?
> Create community-plugins-* alternatives?
> 
> [...]

* nagios-plugins-*-1.4.16
is built from nagios-plugins.spec so that's gotta be a 1:1 copy (or a local requires in the main spec file)

* nagios-plugins-nrpe
is built from upstream nrpe, and not part of the monitoring plugins project. it contains 'check_nrpe' but that only works with the remote clients actually run the nrpe daemon. Apart from that the current NRPE implementation lacks off good security layers, so it shouldn't be touch anyway.

* nagios-plugins-rhev
seems to be deprecated: http://pkgs.fedoraproject.org/cgit/nagios-plugins-rhev.git/log/

* nagios-plugins-lcgdm
seems to be a cern specific package, not sure if anyone uses it. 

* nagios-plugins-bdii
doesn't depend on nagios-plugins, but nagios-common. 

And then there are some additional plugins which require the nagios-plugins rpm for providing the directories (http://pkgs.fedoraproject.org/cgit/nagios-plugins-openmanage.git/tree/nagios-plugins-openmanage.spec#n29)

* nagios-plugins-openmanage
* nagios-plugins-check_sip
* nagios-plugins-check-updates

That could possibly be overcome by providing a generic monitoring-plugins-common package providing users/paths/etc if those packages are reworked as well. check-updates is the most common plugin, so it should be made available under the new package name space as well imho.

(In reply to Drew Blessing from comment #31)
> Sam,
> 
> By having monitoring-plugins in EPEL 6 what options does that leave for
> nagios-plugins? Continue with the new nagios-plugins team as provider for
> the packages, remove them, or make them a pointer toward the
> monitoring-plugins? I'm just looking for clarification. It seems like maybe
> the entire path forward should be decided before making any changes,
> including the addition of monitoring-plugins.

I would remove the new team by Nagios Enterprises from any further decisions made in this bug. I've opened this ticket in the means of updating the current package. If they require their newly formed sources in Fedora, they should ask for a package review, but in a different task / bug. 

Our scope here is to solve the existing problem with changed sources, and once Sam gets the monitoring-plugins package into review, it's reasonable to make nagios-plugins package a transitional package. But I also understand the need for a clean upgrade path, in either now EPEL6, and future EPEL7/el7.

Beyond that, I'd suggest to "freeze" the nagios-plugins package and don't release any updates, until a proper solution is found.

Comment 33 DJ Delorie 2014-01-19 17:56:28 UTC
I looked at the current and previous (via archive.org) versions of both websites, and saw nothing that permitted copying that content.  If The content has been copied without permission, nothing the Fedora project publishes should refer to that content, else we would be tainting our "Freedom" core value.  Regardless of other arguments, we should ensure that we can ethically and legally refer to any sites we mention in our products.

Comment 34 James Hess 2014-01-19 18:59:01 UTC
If the package  being renamed;  it should be considered -- whether the new naming convention being selected is specific enough,  to avoid confusion with monitoring plugin packages that may be for use with other  unrelated software.

From a usability standpoint... the package name "monitoring-plugins"  seems a highly generic, and therefore: not a very useful  package name -- since it doesn't express the nature of the plugins package.

While the Nagios plugins project seems to have a very long history of using the name:   I suggest renaming without eliminating the 'nagios-' prefix,  to indicate the plugins are for use to accompany or extend nagios.


Otherwise... it is like renaming the  bash package to "shell"; or renaming the GCC C++ package to just "compiler", as if to say the package is now "The canonical  Compiler package... or canonical monitoring plugins package, for a Fedora system".

"nagios-plugins"  was adequately describing which package the extra plugins go with.

Comment 35 Andy Brist 2014-01-19 20:17:34 UTC
(In reply to Sam Kottler from comment #30)
> Additionally, I've decided that I will not be maintaining nagios-plugins in
> EPEL 7, but will be happy to be the monitoring-plugins maintainer.
That is unfortunate, but it is your choice regardless.  If the nagios-plugins package name will indeed be frozen and treated as a transitional package, I think we should offer an option for the upgrade path between the two new packages. I still contend that the name "nagios-plugins" should retain the current source and name through future releases, but offer a choice through the transitional period.  

If a new package name for both projects is a requirement, "nagios-core-plugins" fits the Nagios Enterprises controlled project better than other suggestions as we are also the organization developing and supporting core, as well as continuing to support a rather large number of nagios-plugins users on our forums.  The plugins package's main target is Nagios Core and I feel it would be disingenuous to label it as "nagios-enterprises-plugins" as it is still a free, open source project.

Comment 36 Drew Blessing 2014-01-19 21:17:12 UTC
(In reply to Andy Brist from comment #35)
> (In reply to Sam Kottler from comment #30)
> I still contend that the name "nagios-plugins"
> should retain the current source and name through future releases, but offer
> a choice through the transitional period.  

I agree that nagios-plugins, if kept, should retain the current source and name through future releases. Unfortunately I think you and the community have different definitions of what the "current" source is. I think most would agree the current source is the team behind what is now monitoring-plugins.

Comment 37 Andy Brist 2014-01-19 21:35:13 UTC
(In reply to Drew Blessing from comment #36)
> (In reply to Andy Brist from comment #35)
> > (In reply to Sam Kottler from comment #30)
> > I still contend that the name "nagios-plugins"
> > should retain the current source and name through future releases, but offer
> > a choice through the transitional period.  
> 
> I agree that nagios-plugins, if kept, should retain the current source and
> name through future releases. Unfortunately I think you and the community
> have different definitions of what the "current" source is. I think most
> would agree the current source is the team behind what is now
> monitoring-plugins.
Just to be clear, I was implying "Source0" as it pertains to the bug report.

Comment 38 Michael Friedrich 2014-01-19 21:35:56 UTC
(In reply to Drew Blessing from comment #36)
> I agree that nagios-plugins, if kept, should retain the current source and
> name through future releases. Unfortunately I think you and the community
> have different definitions of what the "current" source is. I think most
> would agree the current source is the team behind what is now
> monitoring-plugins.

You may copy code licensed under GPLv3, and call it a forked version (as the source tarball on nagios-plugins.org shows - luckily they don't need to rename anything, but technically it is a fork). But you must not copy a website which is copyrighted, and then claim to be the official source for a project abusing the content of a different owner. That is illegal. 

In whatever context or light that may lie, I totally agree with comment #33

(In reply to DJ Delorie from comment #33)
> I looked at the current and previous (via archive.org) versions of both
> websites, and saw nothing that permitted copying that content.  If The
> content has been copied without permission, nothing the Fedora project
> publishes should refer to that content, else we would be tainting our
> "Freedom" core value.  Regardless of other arguments, we should ensure that
> we can ethically and legally refer to any sites we mention in our products.

In terms of the package name itself - given the current monitoring tools available in fedora, it's a good choice. Zabbix may use the plugins using wrappers, the Nagios&Forks ecosystem depends on it, Sensu is actually using it, but not in Fedora afaik. It's also reasonable to note that the project identifies itsself as "Monitoring Plugins Development Team" under the monitoring-portal.org domain. That makes it the number one candidate for such a package name, unless some other tool will require the name.

Comment 39 Sam Kottler 2014-01-19 22:23:30 UTC
(In reply to James Hess from comment #34)
> If the package  being renamed;  it should be considered -- whether the new
> naming convention being selected is specific enough,  to avoid confusion
> with monitoring plugin packages that may be for use with other  unrelated
> software.
> 
> From a usability standpoint... the package name "monitoring-plugins"  seems
> a highly generic, and therefore: not a very useful  package name -- since it
> doesn't express the nature of the plugins package.
> 
> While the Nagios plugins project seems to have a very long history of using
> the name:   I suggest renaming without eliminating the 'nagios-' prefix,  to
> indicate the plugins are for use to accompany or extend nagios.

This is not strictly true. Lots of other projects use the tools provided in (what we currently call) nagios-plugins.

> 
> 
> Otherwise... it is like renaming the  bash package to "shell"; or renaming
> the GCC C++ package to just "compiler", as if to say the package is now "The
> canonical  Compiler package... or canonical monitoring plugins package, for
> a Fedora system".

Again, not really true give based on what I said above. To be quite frank, you're going to have to take this issue up with the monitoring-plugins upstream team, but I suspect they will have a similar response.

> 
> "nagios-plugins"  was adequately describing which package the extra plugins
> go with.

Comment 40 Sam Kottler 2014-01-19 22:32:40 UTC
(In reply to Andy Brist from comment #35)
> (In reply to Sam Kottler from comment #30)
> > Additionally, I've decided that I will not be maintaining nagios-plugins in
> > EPEL 7, but will be happy to be the monitoring-plugins maintainer.
> That is unfortunate, but it is your choice regardless.  If the
> nagios-plugins package name will indeed be frozen and treated as a
> transitional package, I think we should offer an option for the upgrade path
> between the two new packages. I still contend that the name "nagios-plugins"
> should retain the current source and name through future releases, but offer
> a choice through the transitional period.  

I agree, but this isn't really something that's easy to automate. It basically involves some 'obsoletes' and telling people to choose one or the other. As I've said, I have no problem leaving nagios-plugins with the current upstream and introducing monitoring-plugins for those users who wish to start consuming the new, debatably original upstream in currently versions in EPEL 6 and current Fedora's. Do people think we need the monitoring-plugins package in EPEL 5? I'd like to avoid having to work with EL 5 as much as possible, but if the community thinks it's worthwhile then I'll happily create the package(s) there, too.

Then, in EPEL 7 and Fedora 21 we can have nagios-core-plugins (maintained by someone else) and monitoring-plugins without nagios-plugins existing at all. Someone else can maintain nagios-core-plugins if they choose to do so; if no one does then it just won't exist.

> 
> If a new package name for both projects is a requirement,
> "nagios-core-plugins" fits the Nagios Enterprises controlled project better
> than other suggestions as we are also the organization developing and

Yes, I agree that nagios-core-plugins accurately represents what's in the package.

> supporting core, as well as continuing to support a rather large number of
> nagios-plugins users on our forums.  The plugins package's main target is
> Nagios Core and I feel it would be disingenuous to label it as
> "nagios-enterprises-plugins" as it is still a free, open source project.

Comment 41 Sam Kottler 2014-01-19 22:34:08 UTC
I've started working with Michael and others in the monitoring-plugins community to help them create the first release of monitoring-plugins; submitting it for review is dependent upon them creating the first release.

Thanks to everyone involved for your patience as we move this very complicated issue forward! I really appreciate it.

Comment 42 Kurt Seifried 2014-01-20 06:56:02 UTC
(In reply to Andy Brist from comment #7)
> (In reply to Michael Friedrich from comment #6)
> > Actually the old Nagios Plugins Development Team was required to rename
> > their project due to the fact that Nagios Enterprises hijacked the DNS and
> > website and kicked them out. 
> 
> The domain was, and continues to be, owned by Nagios Enterprises.
> 
> > Whilst the original memebers are now known as 'Monitoring Plugins
> > Development Team', the newly formed 'Nagios Core Plugin Development Team' is
> > actually providing a fork of their work under the old name.
> 
> nagios-plugins is not a fork, but a rebase with new team members. 
> monitoring-plugins is indeed a fork, as their new name suggests. 
> 
> If you need any further clarification, please contact Nagios enterprises
> directly.
> 
> Thank you kindly.

I would prefer these discussions to happen publicly in a transparent manner, especially as this involves the entire community. 

My concern is with regards to "but a rebase with new team members", how familiar is your team with all the existing code? Will this impact security response times (e.g. the original authors of the code whom are familiar with it vs. a new developer that has perhaps never seen the code before can have a huge impact on the time involved in a security response). If you can clarify this I would appreciate that greatly.

Comment 43 Jean Gabès 2014-01-20 07:38:21 UTC
(In reply to Kurt Seifried from comment #42)
> My concern is with regards to "but a rebase with new team members", how
> familiar is your team with all the existing code? Will this impact security
> response times (e.g. the original authors of the code whom are familiar with
> it vs. a new developer that has perhaps never seen the code before can have
> a huge impact on the time involved in a security response). If you can
> clarify this I would appreciate that greatly.

Hi,

I lead the Shinken project. And in our community the answer is quite easy on this topic: we won't add nagios-plugins in our package and will switch to the "community one.

It's quite easy to understand: nagios inc forked the plugins, but as the trademark owner they for the other to rename. Ok seems legal, I got nothing against it. But what we trust are the guys that maintain the plugins since years, with a really great job.

I got nothing against the new team, but we do not know them, and as far as I know, they never commit nor help this project. So why give them a full access to all the monitoring users when the "known to work well" guys will be pushed away just for a name?

I don't know how packages names are impacted by trademark (don't play on this field with Nagios LLC, they know their job well on this legal part) and if it's a legal problem to keep "nagios" on the community name. But I think at least users should know that the package they are installing is a forked version and not the original team (I don't care about the name, the team matters, not the name). Maybe by setting this nagios-plugins package as virtual implemented by two new Conflicts ones?

If after some time we see that the new team is working well and patches are merged in the two packages why not allowing nagios-plugins to be back in the Shinken installations, but currently it will be "Conflict" in the Shinken EL package if the nagios-plugins is not following the original team behind it. I won't give root access to guys I don't trust.

I'm wondering, is such problem already occurs in Fedora history? Can RedHat legal team help there? (especially for the trademark issue).

Thanks a lot for your help, maintain a package in this moving monitoring world is really not an easy job :p

Comment 44 Jan Wagner 2014-01-20 08:11:13 UTC
(In reply to Jean Gabès from comment #43)
> I don't know how packages names are impacted by trademark (don't play on
> this field with Nagios LLC, they know their job well on this legal part) and
> if it's a legal problem to keep "nagios" on the community name.

Just a theoretical view on this. If distributions are not permited to use the phrase 'nagios' in it's package names, how would they provide a plugins package with upstream source of "Nagios Enterprises, LCC" with 'nagios' in it's project name?

Comment 45 Jean Gabès 2014-01-20 08:54:14 UTC
I think you won't have a problem if it's based on the LLC repo, as Andy Brist (abrist) is asking for it. But I think you should ask your legal dept before use "nagios" and a "forked" version for it (from a LLC point of view).

Maybe packages names are outside trademark things, but don't play trademark names without a legal dept that support you.

Comment 46 Sam Kottler 2014-01-20 09:04:09 UTC
(In reply to Jean Gabès from comment #45)
> I think you won't have a problem if it's based on the LLC repo, as Andy
> Brist (abrist) is asking for it. But I think you should ask your
> legal dept before use "nagios" and a "forked" version for it (from a LLC
> point of view).

I consulted with one of Red Hat's open source lawyers on Friday when this was just starting to get rolling and he confirmed this. Nagios Enterprises, LLC is allowed to use the Nagios trademark in the naming of their projects/products because they own the trademark. Additionally, while problematic from a community perspective (I'm saying that, not him) assuming the licensing is handled properly then there is not legal issue in rebasing, either.

> 
> Maybe packages names are outside trademark things, but don't play trademark
> names without a legal dept that support you.

The package name is a little more subjective in my opinion. I'm okay with it having nagios in the name because it's produced by Nagios Enterprises as was mentioned earlier.

Comment 47 Jan Wagner 2014-01-20 09:24:45 UTC
(In reply to Sam Kottler from comment #46)
> (In reply to Jean Gabès from comment #45)
> > Maybe packages names are outside trademark things, but don't play trademark
> > names without a legal dept that support you.
> 
> The package name is a little more subjective in my opinion. I'm okay with it
> having nagios in the name because it's produced by Nagios Enterprises as was
> mentioned earlier.

What about a solution where:

* a 'monitoring-plugins-*' packages PROVIDES (on package management level) a 'nagios-plugins-*' package 
* a metapackage (just without content) 'nagios-plugins-*' package REQUIRE/DEPEND (on package management level) in a 'monitoring-plugins-*' packages

The question is ... may this harm in trademark terms?

What about all this other 3rd party packages having 'nagios' in it's names or install pathes?

Comment 48 Michael Friedrich 2014-01-20 16:45:09 UTC
(In reply to Kurt Seifried from comment #42)
> (In reply to Andy Brist from comment #7)
> > (In reply to Michael Friedrich from comment #6)
> > > Actually the old Nagios Plugins Development Team was required to rename
> > > their project due to the fact that Nagios Enterprises hijacked the DNS and
> > > website and kicked them out. 
> > 
> > The domain was, and continues to be, owned by Nagios Enterprises.
> > 
> > > Whilst the original memebers are now known as 'Monitoring Plugins
> > > Development Team', the newly formed 'Nagios Core Plugin Development Team' is
> > > actually providing a fork of their work under the old name.
> > 
> > nagios-plugins is not a fork, but a rebase with new team members. 
> > monitoring-plugins is indeed a fork, as their new name suggests. 
> > 
> > If you need any further clarification, please contact Nagios enterprises
> > directly.
> > 
> > Thank you kindly.
> 
> I would prefer these discussions to happen publicly in a transparent manner,
> especially as this involves the entire community. 
> 
> My concern is with regards to "but a rebase with new team members", how
> familiar is your team with all the existing code? Will this impact security
> response times (e.g. the original authors of the code whom are familiar with
> it vs. a new developer that has perhaps never seen the code before can have
> a huge impact on the time involved in a security response). If you can
> clarify this I would appreciate that greatly.

There seems to be an answer from a sales guy being leaked onto the mailinglists but I wouldn't treat that as official statement though.

https://www.monitoring-plugins.org/archive/devel/2014-January/009420.html

For what it's worth, inspired by all the comments on slashdot and reddit, I'll have to add in regards of maintaining the code and project:

The Nagios code, and all of its sub projects such as NRPE, NSCA, NDOUtils and also the Plugins project, contain a huge history of changes. While the plugins project has been moved into a community project, the rest is still maintained by Nagios core developers (or - was, as Andreas Ericsson was kicked out in October 2013, and the "rest" of the nagios team remains unknown, as the compiled list on http://www.nagios.org/about/team sounds more of a list of support, sales & trademark guardians).

In any attempt of fixing a bug, or a security issue even, you need to know the code, its origin, how to debug it, and also - who to ask in case. There's no technical documentation publicly available, nor anything else that would be helpful in this regard - other than mailinglist archives, or git history.

I'm familiar with the Nagios code and its flaws - I've been digging and modifying the core code for the past 4,5 years in Icinga. And so do others maintain the long history of the former Nagios Plugins, now representing that knowledge and power as "Monitoring Plugins Development Team".

If you don't know about the code, and have never patched a series of bugs requiring you to fully understand the code, it's unforseeable if you can catch up with security incidents or bug reports in a decent time manner. I'm not saying that the newly formed Nagios Plugins Development couldn't do that. It's just the feeling that I get when I'm looking into their repositories and grepping for their names in terms of commits.

Likewise, the more fancy comparison for that exists already - thanks to ohloh.
Since they forked off the monitoring-plugins project I would expect at least some contributions in the past. Apparently there are none. 

http://www.ohloh.net/p/monitoring-plugins/contributors?query=&sort=commits

Mine is zero as well. But I am not applying as upstream source for the official nagios-plugins package here.

Comment 49 Andy Brist 2014-01-20 18:05:33 UTC
Just to reiterate, as I think this point has been lost in this large thread:

Nagios Enterprises has and continues to control and own the nagios-plugins project.  Team members may come and go, but the project is indeed controlled by Nagios Enterprises.  The project has been moved completely in house, with direct access to Ethan, the original creator of many of the plugins.  For these reasons alone, the package should remain, unchanged and with the original name.

Comment 50 Sam Kottler 2014-01-20 18:12:57 UTC
(In reply to Andy Brist from comment #49)
> Just to reiterate, as I think this point has been lost in this large thread:
> 
> Nagios Enterprises has and continues to control and own the nagios-plugins
> project.  Team members may come and go, but the project is indeed controlled
> by Nagios Enterprises.  The project has been moved completely in house, with
> direct access to Ethan, the original creator of many of the plugins.  For
> these reasons alone, the package should remain, unchanged and with the
> original name.

The assertion that Ethan works for Nagios Enterprises as a reason to completely turn away from the community makes very little sense. What your company did is entirely not okay in a moral sense from my perspective. So no, the fact that you control the project's name upstream is not a good reason to keep the package name the same. I'm trying to figure out a solution that makes sense for everyone and you're making that difficult; did you and your company honestly expect people to just keep going along with you after a dramatic and hostile fork?

Sorry to be so brash, but you've got to work with me here.

Comment 51 Ethan Galstad 2014-01-20 19:48:45 UTC
I fail to see why a change in the package name would be called for or thought to be a wise idea.  As the original author of many of the plugins in the package, I have been involved with an seen a number of turnovers in the Nagios plugin development team over the past 15 years.

Just because some of the previous plugin developers decided to leave the project to create their own separate project, doesn't necessitate a change to (or removal of) the original project, which has existed much longer than individual developers' involvement in it.

IMO, changing the name of the package would be a huge disservice to the Fedora community, as well as the RHEL customer base.

For those who are interested, we posted a news article about the plugin team changes at http://www.nagios.org/news/77-news-announcements/367-nagios-plugin-team-changes

Comment 52 Jan Wagner 2014-01-20 20:12:23 UTC
(In reply to Ethan Galstad from comment #51)
> I fail to see why a change in the package name would be called for or
> thought to be a wise idea.  As the original author of many of the plugins in
> the package, I have been involved with an seen a number of turnovers in the
> Nagios plugin development team over the past 15 years.

Just to comment on this, your contribution can be reviewed at http://www.ohloh.net/p/monitoring-plugins/contributors?query=ethan&sort=commits for example.

> Just because some of the previous plugin developers decided to leave the
> project to create their own separate project, doesn't necessitate a change

All at once without stating that clearly? Anyways .. your representatives stated [1] you "had to take back control". This fit's with your view of leaving "the project to create their own separate project"?

> to (or removal of) the original project, which has existed much longer than
> individual developers' involvement in it.
> 
> IMO, changing the name of the package would be a huge disservice to the
> Fedora community, as well as the RHEL customer base.

From packaging point of view, this can be managed with correlations in the packaging management, for example with 'provide', 'conflict' and 'break', depending on the packaging system.

> For those who are interested, we posted a news article about the plugin team
> changes at
> http://www.nagios.org/news/77-news-announcements/367-nagios-plugin-team-
> changes

Maybe you are feeling sad about how the story went, it is a
absolutly "unethical behavior of" Nagios Enterprises, LCC how you spead lies about Holger!

Maybe god with you, when it maybe necessary!

[1] https://www.monitoring-plugins.org/archive/devel/2014-January/009420.html

Comment 53 Sam Kottler 2014-01-21 00:11:11 UTC
(In reply to Ethan Galstad from comment #51)
> I fail to see why a change in the package name would be called for or
> thought to be a wise idea.  As the original author of many of the plugins in
> the package, I have been involved with an seen a number of turnovers in the
> Nagios plugin development team over the past 15 years.
> 
> Just because some of the previous plugin developers decided to leave the
> project to create their own separate project, doesn't necessitate a change
> to (or removal of) the original project, which has existed much longer than
> individual developers' involvement in it.

'decided' isn't exactly the word I would have chosen.

> 
> IMO, changing the name of the package would be a huge disservice to the
> Fedora community, as well as the RHEL customer base.

This package doesn't ship in RHEL hence it being in EPEL; thanks for your concern, though. I wish you'd extend that kind of empathy to those who have worked so hard to further your project before you smeared them on your company blog.

> 
> For those who are interested, we posted a news article about the plugin team
> changes at
> http://www.nagios.org/news/77-news-announcements/367-nagios-plugin-team-
> changes

This blog post really is a shame.

Comment 54 Kurt Seifried 2014-01-21 02:50:54 UTC
(In reply to Andy Brist from comment #49)
> Just to reiterate, as I think this point has been lost in this large thread:
> 
> Nagios Enterprises has and continues to control and own the nagios-plugins
> project.  Team members may come and go, but the project is indeed controlled
> by Nagios Enterprises.  The project has been moved completely in house, with
> direct access to Ethan, the original creator of many of the plugins.  For
> these reasons alone, the package should remain, unchanged and with the
> original name.

My concern still stands. 

How familiar is your team with all the existing code? Will this impact security response times (e.g. the original authors of the code whom are familiar with it vs. a new developer that has perhaps never seen the code before can have a huge impact on the time involved in a security response). If you can clarify this I would appreciate that greatly.

I really need an answer to this question. I suspect others do as well.

Comment 55 Andreas Ericsson 2014-01-21 09:59:29 UTC
(In reply to Sam Kottler from comment #24)
> 
> I agree that it's too early to decide on the issue. These are the packages
> in EPEL that depend on nagios-plugins and what do we want to do about them?
> Create community-plugins-* alternatives?
> 

I think that will be absolutely necessary sooner or later, as Nagios Enterprises have made it pretty clear that they will bring in lawyers for pretty much everything using the Nagios name without being directly affiliated with Nagios Enterprises.

Most, if not all, of the plugins in the list fall into that category, and there's no way to protect against a forced rename later. Then there's the problem with the original authors. Most of them won't want their work flying under the nagios banner anymore, since they're mostly community enthusiasts who wrote something useful once upon a time, but have since been shafted by Nagios Enterprises one way or another. I know I have, and I've been directly involved in creating or maintaining several of the plugins in the list in comment #24.

Personally, I'd do a "monitoring" or "network-monitoring" meta-package which provides the paths. The nagios package can depend on that, as can other solutions that in some way or other benefit from the various plugin suites (such as Shinken, Naemon, Icinga, Zenoss etc).

For legal reasons, I'd then rename everything nagiosy except nagios-core and nagios-gui to something neutral, such as "monitoring-" and keep packages from being named "nagios-X" unless Nagios Enterprises themselves add a package review request for a package with their trademark-protected name. The current "nagios-plugins-dhcp" etc should be dropped and "monitoring-plugins-dhcp" should "Provides: nagios-plugins-dhcp" during a transitional period.

I'm more than willing to write the specfiles to make that happen, but I'm unfamiliar with RedHat's procedures in this area.

Comment 56 Andreas Ericsson 2014-01-21 10:47:56 UTC
(In reply to Kurt Seifried from comment #54)
> (In reply to Andy Brist from comment #49)
> > Just to reiterate, as I think this point has been lost in this large thread:
> > 
> > Nagios Enterprises has and continues to control and own the nagios-plugins
> > project.  Team members may come and go, but the project is indeed controlled
> > by Nagios Enterprises.  The project has been moved completely in house, with
> > direct access to Ethan, the original creator of many of the plugins.  For
> > these reasons alone, the package should remain, unchanged and with the
> > original name.
> 
> My concern still stands. 
> 
> How familiar is your team with all the existing code? Will this impact
> security response times (e.g. the original authors of the code whom are
> familiar with it vs. a new developer that has perhaps never seen the code
> before can have a huge impact on the time involved in a security response).
> If you can clarify this I would appreciate that greatly.
> 
> I really need an answer to this question. I suspect others do as well.

The multiple forks of Nagios happened because Nagios Enterprises were completely absent from the community for very long periods (measured in years). I wouldn't trust them to respond to anything that arrives via email from outside their company.

I've taken care of and coordinated most security issues that cropped up in Nagios in the past years (you probably don't remember, but you assigned a few of the cve id's when I asked for them). Since I was kicked from the project in september, several people have failed to get the attention of the maintainers even when sending patches complete with tests for quite severe bugs. Waiting for them to react to security problems would be an exercise in futility.

In addition, the number of patches made by Nagios Enterprises employees to the plugins project totals 23 over the past 12 years, the latest being over a year ago (Ethan's latest contribution was over 7 years ago). Holger Weiss otoh (the former head of nagios-plugins, now the head of monitoring-plugins) has contributed over a hundred patches in the past year alone, with close to 300 since he became a maintainer seven years ago.

So I doubt very, very much if Nagios Enterprises can handle this project anywhere near as good as Holger has, and does.

There's also a political factor to consider here, even though such things rarely belong in technical discussions; Most of the active programmers in the community doesn't like Nagios Enterprises much, so their chances of getting assistance from outside their own company are close to none.

Comment 57 Ethan Galstad 2014-01-21 15:09:53 UTC
Kurt - We've got both C and Perl devs on our team and are quite familiar with the code. We'll be making a new release of the Nagios plugins within the next week or so that will include some important bug fixes that have long gone unapplied.  The current team can easily patch any security holes or bugs that might come up in the future.  

Andreas and Michael - I'm disappointed (albeit not surprised) to see the level of public disdain you have for Nagios.  You are generating some seriously bad karma with the FUD, untruths, and downright hate that you're spreading.  Your actions wouldn't have anything to do with the fact that you each have your own Nagios forks that you'll looking to promote at the expense of the Nagios project, would they? The level to which you're willing to stoop to promote your own agendas is astonishing.

Comment 58 Sam Kottler 2014-01-21 15:36:58 UTC
(In reply to Ethan Galstad from comment #57)
> Kurt - We've got both C and Perl devs on our team and are quite familiar
> with the code. We'll be making a new release of the Nagios plugins within
> the next week or so that will include some important bug fixes that have
> long gone unapplied.  The current team can easily patch any security holes
> or bugs that might come up in the future.  
> 
> Andreas and Michael - I'm disappointed (albeit not surprised) to see the
> level of public disdain you have for Nagios.  You are generating some
> seriously bad karma with the FUD, untruths, and downright hate that you're
> spreading.  Your actions wouldn't have anything to do with the fact that you
> each have your own Nagios forks that you'll looking to promote at the
> expense of the Nagios project, would they? The level to which you're willing
> to stoop to promote your own agendas is astonishing.

Cut it out with the straw man. Your ad hominem attacks are rather hollow so I'd suggest stopping with them. Keep that nasty stuff on the mailing lists your company controls.

I'm not sure whether or not I'll update the package to the latest release because I'm going to have to go through a massive number of commits to look for issues.

Anyways - can we agree to create two new packages and no one will use the nagios-plugins name going forward?

Comment 59 Andreas Ericsson 2014-01-21 16:11:27 UTC
Insofar as I understand it, the RedHat folks can decide what the package will be called in their own distribution, and which package to use. If noone wants to step up and maintain a package named "nagios-plugins" (for whatever reasons), I guess there just won't be one. Fortunately, a substitute which is guaranteed to be 100% compatible already exists, and I'd be happy to maintain that myself, or help anyone else who wants to take that role.

Sam, feel free to email me off-list if you need a hand with the monitoring-plugins package. We already have developers evaluating and working on them.

Comment 60 Michael Friedrich 2014-01-21 22:25:15 UTC
I've been digging into the RPM packaging stuff a bit this evening. Some remarks despite the fact that the 1.5 <-> 1.4.16 contains various patches/changes which might affect Fedora specific patches.

* 'nagios-plugins' requires 'nagios-common'. That's solely for creating the nagios user/group which is then used for setuid root for example for check_icmp. Imho that issue can be resolved by putting the monitoring core user into the very same group.

- Proposal: create 'monitoring-plugins-common' which creates the user/group 'monplug' used for the setuid stuff. All packages depend on that newly created package, instead of pulling nagios-common.


* 1.5 ships 'check_dbi' which incorporates the use of the libdbi database interface and its independent drivers. This is a problem insofar that the default 'monitoring-plugins-dbi' cannot depend whether on mysql, pgsql or sqlite as drivers. Calling 'check_dbi' will result in an error message on an uninstalled driver, and the user is left alone with the search for an applicable driver.

- Proposal: Create configuration packages namely 'monitoring-plugins-dbi-{mysql,pgsql,sqlite}' which then pull the required dependencies like 'libdbi-dbd-{mysql,pgsql,sqlite}'.
That way the user may choose which db driver he/she really needs. Andreas may know about the hassles libdbi causes from Merlin, while I do for like 5 years now having that implemented and supported with Icinga IDOutils for MySQL and PostgreSQL. My spec Files already include these additional working packages.

(Note: I've already decided to help the Monitoring Plugins team maintain check_dbi since I figure we share the same intel with Icinga here. I just didn't have access to a decent RPM to be used within the Icinga 2 Vagrant Boxes for further developments.)

Example:

# /usr/lib64/monitoring/plugins/check_dbi -d mysql -o username=icinga -o password=icinga -o dbname=icinga -q 'SELECT * from icinga_dbversion;'
OK - connection time: 0,003691s, 'SELECT * from icinga_dbversion;' returned 1,000000 in 0,000696s | conntime=0,003691s;;;0; server_version=50171;;;0; query=1,000000;;;; querytime=0,000696s;;;0;


* Prefix for plugins. I'm not entirely sure if it shall be 'monitoring/plugins' or 'monitoring-plugins'. The first would mean that an application/package with the name 'monitoring', the second sounds more resonable. My test packages use /usr/lib64/monitoring/plugins as full prefix, which obviously isn't correct.


* There's a renaming in progress for 'check_nagios' which essentially can be used by any core. Therefore it would be something like 'check_monitoring_core' or something. Since I tried to eliminate the 'nagios' string entirely, I've now named it like that for my testing purposes.


* The path fix for check_log.sh had to be done again. I've re-created the patch and replaced the old one not cleanly applying. 


You'll find the files in a feature branch at my github repo (same license as for the fedora maintained spec file applies, just to be sure)

https://github.com/dnsmichi/monitoring-plugins-rpm/tree/feature/1.5

Sam: 

Feel free to combine it with your packages prepared for review. I've built against current HEAD in 'maint'. My packager's skills far away from perfect but at least the Icinga users use my Icinga and Icinga Web packages in production. 

And last but not least: If there would be problems with bringing the 'monitoring-plugins' packages into EPEL6 or EPEL5 even, I'll have a chat with the Icinga team so that we can build/host them on packages.icinga.org to help spread them amongst the community - not only Icinga, but everyone else appreciating it.

We may coordinate this via email too, if it's easier - and it will reduce the spam level on this bug.

Kind regards,
Michael

Comment 61 Dat Banzhu 2014-01-21 23:15:34 UTC
Mr. Kottler: I genuinely thank you for handling this seemingly simple situation with the appropriate amount of care. 

Allowing Nagios Ent to use the current package name will almost certainly cause issues in regards to compatibility down the road, the difference being if their in-house update causes issues with another platform; they actually kinda have incentive not to make it a priority. AND, rightly so, assuming users choose to install their package and aren't forced into it with a thoughtless upgrade. 

Not everyone out there pays attention to packages at this level, and since the current site is a direct copy of the original, researching it is met with deception and bickering. 

The only responsible thing to do is create new packages, as Sam has already suggested. I personally don't think either party should have a say in that decision. The only remaining decision they should have is to the new packages.

Comment 62 Chris Ravenscroft 2014-01-23 09:01:58 UTC
Hi. I registered an account specifically to comment as a Nagios user, both corporate and personal. I feel that the impact of this change on your user base has been lost in the contributor/company argument.

While I am grateful to Nagios for the project, the bottom line is this: a brand new team means a brand new product. When I update my packages, I typically have a pretty good idea of who I can trust to deliver a stable product based on their track record.

I have, over the years, seen what happens when a closed source product changes hands. It's rarely a change for the better as thew owners lack the knowledge/motivation to maintain the product. I do not see a reason to expect a different outcome with an open source project.

Thus, for stability reasons, when time comes to upgrade, I will go with code continuity, meaning I will follow the departing (departed?) contributors rather than a brand. I am not very happy about the potential dependency changes, though, for quite obvious reasons.

Comment 63 J Chapin 2014-01-23 23:30:13 UTC
As a user of the nagios-plugins package, the behaviour I expect to see is that nagios-enterprises-plugins (or whatever the new maintainer wants to call it) and monitoring-plugins will be created to handle the respective upstream source -- and that nagios-plugins becomes a meta-package to maintain compatibility and avoid breaking tools/scripts users might be using with their current systems.

To me, it seems obvious that the nagios-plugins should point to monitor-plugins. Since the code for each project started out a 1:1 copy, the *only* thing that both matters, and separates the two projects is the developers. Luckily, that makes it easy, since *all* the developers appear to be working on monitor-plugins, it's clear, to me, at least, that nagios-plugins is a fork -- and making a bad faith effort to deliberately confuse the user base. 

I have no horse in this race, other than being a user -- and as a user, I expect that given the option, nagios-plugins points to the original project, regardless of their new name, in order to prevent confusion.

Comment 64 Ethan Galstad 2014-01-24 00:17:22 UTC
Pointing users of the current Nagios plugins package to a different package would not only be a huge disservice to current Nagios users, but it could very likely cause a number of problems and community and customer backlash.  I trust that the package maintainers would not make such a brash decision.

I would also like to point out that there are ulterior motives at play that most people are not aware of at this point.  Michael Friedrich originally opened this bug and he's no doubt playing some cards he's not sharing with everyone.

An explanation of why Nagios made the changes we did, as well as what is playing out behind the scenes, is outlined in this article:

http://nagios-plugins.org/uncomfortable-info-on-the-plugin-team-changes/

For those of you who are interested, the current Nagios plugins team is quite active and is close to a new release.

Comment 65 Mark Hill 2014-01-24 01:35:57 UTC
This must be some kind of joke right? Are there serious considerations to get rid of the nagios-plugins RPM? I thought it was a bad idea before, but now after reading that last comment and associated blog article, I am outraged! And are we really worried that the new team writing the code for these plugins are not going to be up to par? REALLY? I'm pretty sure a fifth-grader could meet the standards the previous team set, It isn't excately a high bar to meet. I promise I am not tyring to be degrading, and I sincerely appreciate the work they did! I just think it is ridiculous to assume that because of the changes that got everyone all upset we should drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins. As other "community members" have already said, I do not want to deal with all of the dependency issues this creates, just because of a little pissing match. 

Sam: I really appreciate you dealing with this, but please, keep a straight head on this.

Comment 66 Priyadi Iman Nurcahyo 2014-01-24 05:36:25 UTC
As a user maintaining several installations of Nagios and Icinga under RHEL, Fedora and CentOS; I agree with comment #29. I expect the nagios-plugins package to follow the current canonical upstream. If upstream decided to change name and URL, I expect any new package release to do the same thing. Whether the package name is changed or not, I would expect the new package to upgrade the already installed older version of the package.

When the 'Netsaint' project decided to change its name to 'Nagios', we all expected any new releases to be named 'Nagios' and seamlessly upgrades the older 'Netsaint' package. In fact, today I can still see RPMs that does a 'Provides' to 'netsaint'.

I don't see why it should be different this time.

The fact that there's another project using the old name left by the original project is entirely different matter. If it is decided to create package for 'the new project that is using the old name', the new package should be packaged under a new name and must not break the already existing packaging arrangement. I just wish 'the new project that is using the old name' does not make the packager's job harder than already it is.

---

(Off topic, but related)

Furthermore, considering the situation, it is my opinion that Nagios should be superseded by one of the forks, although it is not clear which fork to go. I wish the forks are able to unify and cooperate more.

The community had in the past several times decided to move from one project to another that fits better with community, for technical or other reasons. Example: GCC->EGCS->GCC, XFree86->Xorg, Openoffice.org->Libreoffice, and recently MySQL->MariaDB. I think the current situation warrants some consideration about this.

Comment 67 Matthew Brooks 2014-01-24 06:13:45 UTC
[Full Disclosure Up Front: I am one of the Icinga Core Developers]

Give it a rest already Ethan. You miscalculated the response this would get and your attempts to sow confusion to distract people is just getting silly and making you look bad.

The Monitoring Plugins Team started to migrate towards using a new domain name because you and your company have a very *long* history of pulling stunts like this very one. Not to mention that since many other projects now use those very same plugins, having Nagios in the name is actually a bit misleading and can actually cause confusion.

If you think about it, the Monitoring Plugins Team were working on trying to do the very thing you and your company want and demand of everyone with every breath that you guys take, which is to not use the Nagios name... and now you want to turn around and point at that as the reason why you hijacked the domain out from under them and stole their web content while at the same time trying to shame them for it?! Puhlease!! Don't insult our intelligence.

Perhaps you've been in the commercial world so long that you've forgotten, but there's no such thing as competitors in the open source community. At least not in the way you would define it. Sure there are other projects that do similar things and perhaps even the same things in the case of forks, but we all seek the same goal, which is to scratch the technical itches we have using Free Software and maybe interact with some fun and smart people a little bit while we are at it.

So yes, the website you hijacked said that the plugins work with Icinga and others. Leaving aside the fact that there are no competitors when it comes to open Source for a moment, that is hardly promoting them; that is just simple bullet point disclosure of what they work with. If anything, mentioning as many of the monitoring solutions that use the plugins as possible is a benefit to the monitoring plugins project as it shows that it can be used with a diverse range of monitoring solutions, not just one. If that's your excuse for what you did, it's very weak at best.

Look Ethan, we all know you need to put food on the table. We all do. Many of us also have a deep respect for what you contributed to the Open Source Community way back in the day and none of us will discredit you for that or ever say that you don't have a personal right to cash in commercially as you have gone on to do. That's just great and congratulations, we wish you continued success.

That said, each and every one of us have a personal right as individuals to be treated with respect too. Shitting on the good names of other people who have contributed a lot to the Open Source Community is highly disrespectful and abhorrent behavior. While you may be respected for your past contributions, the more you continue on this line of attack (especially the personal ones) the fewer people there will be who can respect you as a person. So if you want to make blog posts talking about acting with honor and having high ethical standards, go ahead, but you might want to put in some work on those qualities yourself first sir... a lot of work.

Just because you got burned by a Trademark doesn't mean you have to continue to take it out on us for all eternity. And you certainly don't need to stoop to the level of engaging in vindictive personal attacks like you have done each and every time you have asserted yours.

Yes, Michael Friedrich originally opened the bug, and yes he is the lead core developer for Icinga. So what? That doesn't make the point he has brought up any less valid. In fact, I'm not at all surprised that he was so fast at picking up on this as he is firmly committed to Open Source network monitoring and he spends most if not all his time working on or with it in some fashion. If there is anyone in the world who has his ear closest to the ground to spot such things in the area of network monitoring, it would be him. The community is all the better for it.

---

As to the other comments here, no one wants to deal with the added headaches this has caused. Unfortunately, this is solely Nagios Enterprises doing and as they have shown historically by their actions, they are not as friendly towards the Open Source Community as they'd like people to think. If you don't like it, you might want to start seeking out a monitoring solution that doesn't play these games or throw out such a constant stream of vitriol.

The fact of the matter is, Nagios Enterprises is a commercially driven company (speaking of ulterior motives) therefore it's in their interest to try to squash alternatives so they can be the only game in town. Without changes being made to the upstream packaging to head it off, what is to stop their next plugins update from refusing to play nice with other monitoring solutions altogether? That's not to say that they will stoop that low, but they are certainly dancing close enough with the bottom as it is.

I'll gladly take Ethan's word that they have a team of developers banging away at the code as we speak. Their first order of business is probably doing what they do with the Nagios core patches the Icinga Team sends them... doing the uncool thing of stripping out every mention of anyone else in the code so no one but them gets credit for the work.

More power to them though; the existence of this new team changes nothing regarding this. The nagios-plugins package that people have installed on their systems right now was developed by another team and the domain has just been hijacked out from under them. As others have said, the upstream should point to the old team not the one that did a hostile takeover.

As to the FUD-laden mention of there being a possibility of backlash, that's pretty doubtful, but it's something that Nagios Enterprises should have considered before doing what they did. One can only hope that if there is any, it is directed at those responsible and is so decisive and overwhelming for them so they think twice next time they are thinking about not playing nice.

I'm not well versed in the fine details of packaging, so I'll defer to Sam and his wisdom in that area. I have every confidence that he can find an equitable way to ensure that the monitoring plugins development team isn't allowed to be quietly strong armed and squashed by a commercial interest while letting the three people who still trust Nagios Enterprises after all of this to select a new package for their plugins going forward.

Comment 68 Sam Kottler 2014-01-24 13:47:59 UTC
(In reply to Priyadi Iman Nurcahyo from comment #66)
> As a user maintaining several installations of Nagios and Icinga under RHEL,
> Fedora and CentOS; I agree with comment #29. I expect the nagios-plugins
> package to follow the current canonical upstream. If upstream decided to
> change name and URL, I expect any new package release to do the same thing.
> Whether the package name is changed or not, I would expect the new package
> to upgrade the already installed older version of the package.
> 
> When the 'Netsaint' project decided to change its name to 'Nagios', we all
> expected any new releases to be named 'Nagios' and seamlessly upgrades the
> older 'Netsaint' package. In fact, today I can still see RPMs that does a
> 'Provides' to 'netsaint'.
> 
> I don't see why it should be different this time.

Because that requires everyone moving to a specific project. Overall, I'm fine with letting users choose if they want to keep using the Nagios Enterprises version.

> 
> The fact that there's another project using the old name left by the
> original project is entirely different matter. If it is decided to create
> package for 'the new project that is using the old name', the new package
> should be packaged under a new name and must not break the already existing
> packaging arrangement. I just wish 'the new project that is using the old
> name' does not make the packager's job harder than already it is.

Absolutely, that's clearly the best route forward in regards to package naming and it's the one I'm currently working on taking.

> 
> ---
> 
> (Off topic, but related)
> 
> Furthermore, considering the situation, it is my opinion that Nagios should
> be superseded by one of the forks, although it is not clear which fork to
> go. I wish the forks are able to unify and cooperate more.
> 
> The community had in the past several times decided to move from one project
> to another that fits better with community, for technical or other reasons.
> Example: GCC->EGCS->GCC, XFree86->Xorg, Openoffice.org->Libreoffice, and
> recently MySQL->MariaDB. I think the current situation warrants some
> consideration about this.

I think you're right and ultimately the monitoring-plugins will get traction behind it (in my opinion) because it's a community project and has known and respected contributors working on it. In the meantime I want users to have the flexibility to make a choice.

Comment 69 Sam Kottler 2014-01-24 13:54:31 UTC
(In reply to Mark Hill from comment #65)
> This must be some kind of joke right? Are there serious considerations to
> get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> now after reading that last comment and associated blog article, I am
> outraged! And are we really worried that the new team writing the code for
> these plugins are not going to be up to par? REALLY? I'm pretty sure a
> fifth-grader could meet the standards the previous team set, It isn't
> excately a high bar to meet. I promise I am not tyring to be degrading, and

"I'm pretty sure a fifth-grader could meet the standards the previous team set" but you're not trying to be degrading...

Anyways, given I don't find your name in any of the SCM logs, email lists, or anything Nagios related (other than promoting Nagios XI on stack overflow) I'm not sure I trust your opinion on this.

> I sincerely appreciate the work they did! I just think it is ridiculous to
> assume that because of the changes that got everyone all upset we should
> drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> As other "community members" have already said, I do not want to deal with
> all of the dependency issues this creates, just because of a little pissing
> match. 

It actually creates virtually no dependency issues AFAIK; can you elaborate?

> 
> Sam: I really appreciate you dealing with this, but please, keep a straight
> head on this.

Comment 70 Priyadi Iman Nurcahyo 2014-01-24 14:15:47 UTC
(In reply to Sam Kottler from comment #68)
> > I don't see why it should be different this time.
> 
> Because that requires everyone moving to a specific project. Overall, I'm
> fine with letting users choose if they want to keep using the Nagios
> Enterprises version.

What I meant is what is going to happen when a user runs 'yum update'? Assuming there are now new packages for both monitoring-plugins and nagios-core-plugins.

I don't recall I've ever seen yum asked me to choose which upgrade path I want to take.

Comment 71 Andreas Ericsson 2014-01-24 14:43:55 UTC
(In reply to Priyadi Iman Nurcahyo from comment #70)
> (In reply to Sam Kottler from comment #68)
> > > I don't see why it should be different this time.
> > 
> > Because that requires everyone moving to a specific project. Overall, I'm
> > fine with letting users choose if they want to keep using the Nagios
> > Enterprises version.
> 
> What I meant is what is going to happen when a user runs 'yum update'?
> Assuming there are now new packages for both monitoring-plugins and
> nagios-core-plugins.
> 

As per Sam's comments above, "yum update" (and "yum upgrade") will get the monitoring-plugins package, since that one is guaranteed to be compatible and is trusted to work as well as or better than the code currently shipped in the package named 'nagios-plugins'.

> I don't recall I've ever seen yum asked me to choose which upgrade path I
> want to take.

The packagers make that decision based on discussions like this. Normally, trust is about people and not about who owns what trademark or controls which DNS. If you want to change so you use the package from another team you have to make an informed decision to do so. That makes sense, since you're in effect saying "I want to start trusting these people now", while a package upgrade that happens from "nagios-plugins" to "monitoring-plugins" has no change in who you trust.

I'm confident that's why Sam seems to have decided that the monitoring-plugins RPM will be the next upgrade to the nagios-plugins RPM. Assuming I've understood his sentiment from his comments, at least.

Comment 72 Sam Kottler 2014-01-24 14:48:11 UTC
(In reply to Andreas Ericsson from comment #71)
> (In reply to Priyadi Iman Nurcahyo from comment #70)
> > (In reply to Sam Kottler from comment #68)
> > > > I don't see why it should be different this time.
> > > 
> > > Because that requires everyone moving to a specific project. Overall, I'm
> > > fine with letting users choose if they want to keep using the Nagios
> > > Enterprises version.
> > 
> > What I meant is what is going to happen when a user runs 'yum update'?
> > Assuming there are now new packages for both monitoring-plugins and
> > nagios-core-plugins.
> > 
> 
> As per Sam's comments above, "yum update" (and "yum upgrade") will get the
> monitoring-plugins package, since that one is guaranteed to be compatible
> and is trusted to work as well as or better than the code currently shipped
> in the package named 'nagios-plugins'.
> 
> > I don't recall I've ever seen yum asked me to choose which upgrade path I
> > want to take.
> 
> The packagers make that decision based on discussions like this. Normally,
> trust is about people and not about who owns what trademark or controls
> which DNS. If you want to change so you use the package from another team

Well put.

> you have to make an informed decision to do so. That makes sense, since
> you're in effect saying "I want to start trusting these people now", while a
> package upgrade that happens from "nagios-plugins" to "monitoring-plugins"
> has no change in who you trust.
> 
> I'm confident that's why Sam seems to have decided that the
> monitoring-plugins RPM will be the next upgrade to the nagios-plugins RPM.
> Assuming I've understood his sentiment from his comments, at least.

That's right. I'd like monitoring-plugins to have a provides for nagios-plugins. nagios-core-plugins will just be its own entity and anyone who chooses to still rely on it can do so.

Comment 73 Scott Wilkerson 2014-01-24 15:50:50 UTC
(In reply to J Chapin from comment #63)
> To me, it seems obvious that the nagios-plugins should point to
> monitor-plugins. Since the code for each project started out a 1:1 copy, the
> *only* thing that both matters, and separates the two projects is the
> developers. Luckily, that makes it easy, since *all* the developers appear
> to be working on monitor-plugins, it's clear, to me, at least, that
> nagios-plugins is a fork -- and making a bad faith effort to deliberately
> confuse the user base. 
> 


This is clearly not true, everyone is missing the point that Nagios Enterprises owned the nagios-plugins project from the beginning, and had a team in place to manage it.

That team changed, but the project is still owned by Nagios Enterprises.  This is even clearly represented by the following change made to the monitoring plugin's site on 2014-01-14 as depicted at the following URL:

https://www.monitoring-plugins.org/repositories/site/commit/web/input/doc/faq/control.md?id=0f0a943d5429cf8db0f7f6cc9bc2679ed9329901

You can see on the left (before they made the change), it clearly stated:
-------
Nagios Enterprises owns the Nagios Plugins project, hence the
domain names of the site belong to Nagios Enterprises. However, the Nagios
Plugins Development Team are responsible for the running of the 		
project. This means that decisions about the web site and the development of 
code related to the project are handled independently by the team.
-------


Nagios Enterprises owns the Nagios Plugins project, and the owner of the project gets to choose who is on the team.

This is how it should be, and I would expect the community to understand that it is Nagios Enterprises responsibility as the project owner to take appropriate actions if the team is not acting in the best interest of the project, which they did.

Let me put this in different terms, removing Nagios, with an analogy;

------------------------

If you owned a project that extended the capabilities, of the programming language Python to add additional functionality. You created it, nurtured it, and then let a team of developers maintain it because they offered to, and at the time seemed fully capable.

Now, some time passes, and you come to realize that, the team you had in place, wasn't going down the path you had intended, starting to divert people to not use Python (which was what your project was all about, extending Python), but instead they were promoting the use of other PHP, Ruby, Java, etc. 

When you ask the team to make the appropriate changes, they refuse.  Additionally, you realize, that they are using a domain they registered 10 months earlier, with a strikingly similar name to your project.
http://www.networksolutions.com/whois/results.jsp?domain=monitoring-plugins.org

As the project owner, what would you do?

I would change the team, get the project back on the intended path, so all of the people who rely on the project get what they expect when they download the project/package.

------------------------

Comment 74 Mark Hill 2014-01-24 16:10:29 UTC
(In reply to Sam Kottler from comment #69)
> (In reply to Mark Hill from comment #65)
> > This must be some kind of joke right? Are there serious considerations to
> > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > now after reading that last comment and associated blog article, I am
> > outraged! And are we really worried that the new team writing the code for
> > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > fifth-grader could meet the standards the previous team set, It isn't
> > excately a high bar to meet. I promise I am not tyring to be degrading, and
> 
> "I'm pretty sure a fifth-grader could meet the standards the previous team
> set" but you're not trying to be degrading...
> 

Fair enough, that was a bit harsh, I let my emotions get the better of me and I apologize.

> Anyways, given I don't find your name in any of the SCM logs, email lists,
> or anything Nagios related (other than promoting Nagios XI on stack
> overflow) I'm not sure I trust your opinion on this.
> 

The sensitive nature of my work requires that I keep a low profile. (I even had to receive clearance to post here) So although you don't see my name publicly, several others who have commented here are familiar with my extensive nagios work. 

> > I sincerely appreciate the work they did! I just think it is ridiculous to
> > assume that because of the changes that got everyone all upset we should
> > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > As other "community members" have already said, I do not want to deal with
> > all of the dependency issues this creates, just because of a little pissing
> > match. 
> 
> It actually creates virtually no dependency issues AFAIK; can you elaborate?
> 

We have a massive nagios infrastructure built (and team dedicated to it). We rely heavily on the nagios-plugins rpm. We have scripts all over the place that use yum to install and update the plugins. And now by the sounds of it, we are going to have to touch each one of these if we want the nagios-plugins from the new team? Does that help clarify my concern?

> > 
> > Sam: I really appreciate you dealing with this, but please, keep a straight
> > head on this.

Again, I really appreciate your work on this Sam. I don't have a stake in this other than the time my team is going to have to spend fixing stuff if you decide to force us to go to 'nagios-core-plugins'. And my biggest concern is what if my team misses one? We are going to have mismatches across our various networks, and anything we have built on top of that will break. And yes, this would be easy to accomplish if are networks were not completely isolated from one another. Several of our network require out-of-band management, so again, I think you understand my concern. This just seems like a very unnecessary headache in the making.

Comment 75 Sam Kottler 2014-01-24 16:16:33 UTC
(In reply to Mark Hill from comment #74)
> (In reply to Sam Kottler from comment #69)
> > (In reply to Mark Hill from comment #65)
> > > This must be some kind of joke right? Are there serious considerations to
> > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > now after reading that last comment and associated blog article, I am
> > > outraged! And are we really worried that the new team writing the code for
> > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > fifth-grader could meet the standards the previous team set, It isn't
> > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > 
> > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > set" but you're not trying to be degrading...
> > 
> 
> Fair enough, that was a bit harsh, I let my emotions get the better of me
> and I apologize.
> 
> > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > or anything Nagios related (other than promoting Nagios XI on stack
> > overflow) I'm not sure I trust your opinion on this.
> > 
> 
> The sensitive nature of my work requires that I keep a low profile. (I even
> had to receive clearance to post here) So although you don't see my name
> publicly, several others who have commented here are familiar with my
> extensive nagios work. 
> 
> > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > assume that because of the changes that got everyone all upset we should
> > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > As other "community members" have already said, I do not want to deal with
> > > all of the dependency issues this creates, just because of a little pissing
> > > match. 
> > 
> > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > 
> 
> We have a massive nagios infrastructure built (and team dedicated to it). We
> rely heavily on the nagios-plugins rpm. We have scripts all over the place
> that use yum to install and update the plugins. And now by the sounds of it,
> we are going to have to touch each one of these if we want the
> nagios-plugins from the new team? Does that help clarify my concern?

It does, thanks. That being said it's just updating a bunch of package names; there won't be any additional process. No paths will change if you stick with the nagios-core-plugins package.

> 
> > > 
> > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > head on this.
> 
> Again, I really appreciate your work on this Sam. I don't have a stake in
> this other than the time my team is going to have to spend fixing stuff if
> you decide to force us to go to 'nagios-core-plugins'. And my biggest
> concern is what if my team misses one? We are going to have mismatches
> across our various networks, and anything we have built on top of that will
> break. And yes, this would be easy to accomplish if are networks were not
> completely isolated from one another. Several of our network require
> out-of-band management, so again, I think you understand my concern. This
> just seems like a very unnecessary headache in the making.

Understood and I totally sympathize with you on that, but this wasn't really my decision. You can talk with Nagios Enterprises about how they're making the lives of their users more difficult - maybe they'll listen.

Comment 76 DJ Delorie 2014-01-24 16:31:14 UTC
> the owner of the project gets to choose who is on the team

In the open source world, this statement is demonstrably false.  It's the people who do the work and gain the trust and respect of the users who decide who is on "the team".  This is why the "Freedom" part of Fedora's core values is so important.  We value the community's ability to do things with software that the original authors may not be interested in, and we build our community by working with those who have the best reputation and most enthusiasm.

In the Fedora world, you don't get credibility by buying a trademark.  You get credibility by doing the work, openly and publically, and by being a valuable part of the community.  We don't care about who owns what name, we care about who has demonstrated that they can be trusted.  If you want to be a valuable contributor to Fedora, you'll have to earn it the hard way, just like everyone else.  Claiming something by fiat is a good way to get nothing at all.

Please go read about Fedora's core values ("About Fedora" on any Fedora web page) and ask yourself: Does changing the team the way you did add to or detract from Fedora's values?

Comment 77 Scott Wilkerson 2014-01-24 16:34:57 UTC
(In reply to Sam Kottler from comment #75)
> (In reply to Mark Hill from comment #74)
> > (In reply to Sam Kottler from comment #69)
> > > (In reply to Mark Hill from comment #65)
> > > > This must be some kind of joke right? Are there serious considerations to
> > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > now after reading that last comment and associated blog article, I am
> > > > outraged! And are we really worried that the new team writing the code for
> > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > 
> > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > set" but you're not trying to be degrading...
> > > 
> > 
> > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > and I apologize.
> > 
> > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > or anything Nagios related (other than promoting Nagios XI on stack
> > > overflow) I'm not sure I trust your opinion on this.
> > > 
> > 
> > The sensitive nature of my work requires that I keep a low profile. (I even
> > had to receive clearance to post here) So although you don't see my name
> > publicly, several others who have commented here are familiar with my
> > extensive nagios work. 
> > 
> > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > assume that because of the changes that got everyone all upset we should
> > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > As other "community members" have already said, I do not want to deal with
> > > > all of the dependency issues this creates, just because of a little pissing
> > > > match. 
> > > 
> > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > 
> > 
> > We have a massive nagios infrastructure built (and team dedicated to it). We
> > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > that use yum to install and update the plugins. And now by the sounds of it,
> > we are going to have to touch each one of these if we want the
> > nagios-plugins from the new team? Does that help clarify my concern?
> 
> It does, thanks. That being said it's just updating a bunch of package
> names; there won't be any additional process. No paths will change if you
> stick with the nagios-core-plugins package.
> 
> > 
> > > > 
> > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > head on this.
> > 
> > Again, I really appreciate your work on this Sam. I don't have a stake in
> > this other than the time my team is going to have to spend fixing stuff if
> > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > concern is what if my team misses one? We are going to have mismatches
> > across our various networks, and anything we have built on top of that will
> > break. And yes, this would be easy to accomplish if are networks were not
> > completely isolated from one another. Several of our network require
> > out-of-band management, so again, I think you understand my concern. This
> > just seems like a very unnecessary headache in the making.
> 
> Understood and I totally sympathize with you on that, but this wasn't really
> my decision. You can talk with Nagios Enterprises about how they're making
> the lives of their users more difficult - maybe they'll listen.

@Sam - How is it that you think Nagios Enterprises is making the lives of their users more difficult?  

Nagios Enterprises wants the nagios-plugins package to continue to exist with the project that they own/maintain.

Nagios Enterprises wants the millions of installs of Nagios and it plugins to continue to use the same package names as always for the projects which they own, no matter who they appoint to the team.

Changing of the package name to not refer to the official Nagios Plugins, with the team the project owner put in place is what would be making the lives of the users more difficult.

A worst case scenario would be to have an install/upgrade of nagios-plugins automatically upgrade to a package created by the Monitoring Plugins team.

This would be akin to running Fedora on your machine and after running yum update, you find you have Linux Mint installed and no longer Fedora...

Would this be what you expected?

Comment 78 Mark Hill 2014-01-24 16:40:46 UTC
(In reply to Sam Kottler from comment #75)
> (In reply to Mark Hill from comment #74)
> > (In reply to Sam Kottler from comment #69)
> > > (In reply to Mark Hill from comment #65)
> > > > This must be some kind of joke right? Are there serious considerations to
> > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > now after reading that last comment and associated blog article, I am
> > > > outraged! And are we really worried that the new team writing the code for
> > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > 
> > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > set" but you're not trying to be degrading...
> > > 
> > 
> > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > and I apologize.
> > 
> > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > or anything Nagios related (other than promoting Nagios XI on stack
> > > overflow) I'm not sure I trust your opinion on this.
> > > 
> > 
> > The sensitive nature of my work requires that I keep a low profile. (I even
> > had to receive clearance to post here) So although you don't see my name
> > publicly, several others who have commented here are familiar with my
> > extensive nagios work. 
> > 
> > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > assume that because of the changes that got everyone all upset we should
> > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > As other "community members" have already said, I do not want to deal with
> > > > all of the dependency issues this creates, just because of a little pissing
> > > > match. 
> > > 
> > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > 
> > 
> > We have a massive nagios infrastructure built (and team dedicated to it). We
> > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > that use yum to install and update the plugins. And now by the sounds of it,
> > we are going to have to touch each one of these if we want the
> > nagios-plugins from the new team? Does that help clarify my concern?
> 
> It does, thanks. That being said it's just updating a bunch of package
> names; there won't be any additional process. No paths will change if you
> stick with the nagios-core-plugins package.
> 

Yep, I understand. The work I am trying to avoid is going to be finding all of the locations where we need to update the package names.

> > 
> > > > 
> > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > head on this.
> > 
> > Again, I really appreciate your work on this Sam. I don't have a stake in
> > this other than the time my team is going to have to spend fixing stuff if
> > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > concern is what if my team misses one? We are going to have mismatches
> > across our various networks, and anything we have built on top of that will
> > break. And yes, this would be easy to accomplish if are networks were not
> > completely isolated from one another. Several of our network require
> > out-of-band management, so again, I think you understand my concern. This
> > just seems like a very unnecessary headache in the making.
> 
> Understood and I totally sympathize with you on that, but this wasn't really
> my decision. You can talk with Nagios Enterprises about how they're making
> the lives of their users more difficult - maybe they'll listen.

We have. We complained several times to them that issues my team was having with the plugins were not being addressed. Maybe those conversations are part of the reason for this? Anyway, I think you know where I would like to see this go, and I will go back to my quiet, peaceful cave and watch how this unfolds from there.

thanks again

Comment 79 Sam Kottler 2014-01-24 16:43:13 UTC
(In reply to Mark Hill from comment #78)
> (In reply to Sam Kottler from comment #75)
> > (In reply to Mark Hill from comment #74)
> > > (In reply to Sam Kottler from comment #69)
> > > > (In reply to Mark Hill from comment #65)
> > > > > This must be some kind of joke right? Are there serious considerations to
> > > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > > now after reading that last comment and associated blog article, I am
> > > > > outraged! And are we really worried that the new team writing the code for
> > > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > > 
> > > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > > set" but you're not trying to be degrading...
> > > > 
> > > 
> > > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > > and I apologize.
> > > 
> > > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > > or anything Nagios related (other than promoting Nagios XI on stack
> > > > overflow) I'm not sure I trust your opinion on this.
> > > > 
> > > 
> > > The sensitive nature of my work requires that I keep a low profile. (I even
> > > had to receive clearance to post here) So although you don't see my name
> > > publicly, several others who have commented here are familiar with my
> > > extensive nagios work. 
> > > 
> > > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > > assume that because of the changes that got everyone all upset we should
> > > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > > As other "community members" have already said, I do not want to deal with
> > > > > all of the dependency issues this creates, just because of a little pissing
> > > > > match. 
> > > > 
> > > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > > 
> > > 
> > > We have a massive nagios infrastructure built (and team dedicated to it). We
> > > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > > that use yum to install and update the plugins. And now by the sounds of it,
> > > we are going to have to touch each one of these if we want the
> > > nagios-plugins from the new team? Does that help clarify my concern?
> > 
> > It does, thanks. That being said it's just updating a bunch of package
> > names; there won't be any additional process. No paths will change if you
> > stick with the nagios-core-plugins package.
> > 
> 
> Yep, I understand. The work I am trying to avoid is going to be finding all
> of the locations where we need to update the package names.

If you're managing lots of machines across several networks you should probably use config management.

> 
> > > 
> > > > > 
> > > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > > head on this.
> > > 
> > > Again, I really appreciate your work on this Sam. I don't have a stake in
> > > this other than the time my team is going to have to spend fixing stuff if
> > > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > > concern is what if my team misses one? We are going to have mismatches
> > > across our various networks, and anything we have built on top of that will
> > > break. And yes, this would be easy to accomplish if are networks were not
> > > completely isolated from one another. Several of our network require
> > > out-of-band management, so again, I think you understand my concern. This
> > > just seems like a very unnecessary headache in the making.
> > 
> > Understood and I totally sympathize with you on that, but this wasn't really
> > my decision. You can talk with Nagios Enterprises about how they're making
> > the lives of their users more difficult - maybe they'll listen.
> 
> We have. We complained several times to them that issues my team was having
> with the plugins were not being addressed. Maybe those conversations are
> part of the reason for this? Anyway, I think you know where I would like to
> see this go, and I will go back to my quiet, peaceful cave and watch how
> this unfolds from there.
> 
> thanks again

Comment 80 Sam Kottler 2014-01-24 16:46:25 UTC
(In reply to Scott Wilkerson from comment #77)
> (In reply to Sam Kottler from comment #75)
> > (In reply to Mark Hill from comment #74)
> > > (In reply to Sam Kottler from comment #69)
> > > > (In reply to Mark Hill from comment #65)
> > > > > This must be some kind of joke right? Are there serious considerations to
> > > > > get rid of the nagios-plugins RPM? I thought it was a bad idea before, but
> > > > > now after reading that last comment and associated blog article, I am
> > > > > outraged! And are we really worried that the new team writing the code for
> > > > > these plugins are not going to be up to par? REALLY? I'm pretty sure a
> > > > > fifth-grader could meet the standards the previous team set, It isn't
> > > > > excately a high bar to meet. I promise I am not tyring to be degrading, and
> > > > 
> > > > "I'm pretty sure a fifth-grader could meet the standards the previous team
> > > > set" but you're not trying to be degrading...
> > > > 
> > > 
> > > Fair enough, that was a bit harsh, I let my emotions get the better of me
> > > and I apologize.
> > > 
> > > > Anyways, given I don't find your name in any of the SCM logs, email lists,
> > > > or anything Nagios related (other than promoting Nagios XI on stack
> > > > overflow) I'm not sure I trust your opinion on this.
> > > > 
> > > 
> > > The sensitive nature of my work requires that I keep a low profile. (I even
> > > had to receive clearance to post here) So although you don't see my name
> > > publicly, several others who have commented here are familiar with my
> > > extensive nagios work. 
> > > 
> > > > > I sincerely appreciate the work they did! I just think it is ridiculous to
> > > > > assume that because of the changes that got everyone all upset we should
> > > > > drop the nagios-plugins rpm and move to nagios-insertyourideahere-plugins.
> > > > > As other "community members" have already said, I do not want to deal with
> > > > > all of the dependency issues this creates, just because of a little pissing
> > > > > match. 
> > > > 
> > > > It actually creates virtually no dependency issues AFAIK; can you elaborate?
> > > > 
> > > 
> > > We have a massive nagios infrastructure built (and team dedicated to it). We
> > > rely heavily on the nagios-plugins rpm. We have scripts all over the place
> > > that use yum to install and update the plugins. And now by the sounds of it,
> > > we are going to have to touch each one of these if we want the
> > > nagios-plugins from the new team? Does that help clarify my concern?
> > 
> > It does, thanks. That being said it's just updating a bunch of package
> > names; there won't be any additional process. No paths will change if you
> > stick with the nagios-core-plugins package.
> > 
> > > 
> > > > > 
> > > > > Sam: I really appreciate you dealing with this, but please, keep a straight
> > > > > head on this.
> > > 
> > > Again, I really appreciate your work on this Sam. I don't have a stake in
> > > this other than the time my team is going to have to spend fixing stuff if
> > > you decide to force us to go to 'nagios-core-plugins'. And my biggest
> > > concern is what if my team misses one? We are going to have mismatches
> > > across our various networks, and anything we have built on top of that will
> > > break. And yes, this would be easy to accomplish if are networks were not
> > > completely isolated from one another. Several of our network require
> > > out-of-band management, so again, I think you understand my concern. This
> > > just seems like a very unnecessary headache in the making.
> > 
> > Understood and I totally sympathize with you on that, but this wasn't really
> > my decision. You can talk with Nagios Enterprises about how they're making
> > the lives of their users more difficult - maybe they'll listen.
> 
> @Sam - How is it that you think Nagios Enterprises is making the lives of
> their users more difficult?  
> 
> Nagios Enterprises wants the nagios-plugins package to continue to exist
> with the project that they own/maintain.
> 
> Nagios Enterprises wants the millions of installs of Nagios and it plugins
> to continue to use the same package names as always for the projects which
> they own, no matter who they appoint to the team.

You should read DJ's remarks from above.

> 
> Changing of the package name to not refer to the official Nagios Plugins,
> with the team the project owner put in place is what would be making the
> lives of the users more difficult.
> 
> A worst case scenario would be to have an install/upgrade of nagios-plugins
> automatically upgrade to a package created by the Monitoring Plugins team.

Yes, this would be a worse case scenario for your employer. It'd be the right thing for the community in my opinion.

> 
> This would be akin to running Fedora on your machine and after running yum
> update, you find you have Linux Mint installed and no longer Fedora...
> 
> Would this be what you expected?

Comment 81 Priyadi Iman Nurcahyo 2014-01-24 16:53:52 UTC
(In reply to Sam Kottler from comment #72)
> > I'm confident that's why Sam seems to have decided that the
> > monitoring-plugins RPM will be the next upgrade to the nagios-plugins RPM.
> > Assuming I've understood his sentiment from his comments, at least.
> 
> That's right. I'd like monitoring-plugins to have a provides for
> nagios-plugins. nagios-core-plugins will just be its own entity and anyone
> who chooses to still rely on it can do so.

That's a relief, Sam. Thank you for your clarification and all your good work.

Comment 82 Chris Ravenscroft 2014-01-25 11:21:38 UTC
> This would be akin to running Fedora on your machine and after running yum
> update, you find you have Linux Mint installed and no longer Fedora...
>
Had you written "CentOS" instead of "Linux Mint", your analogy would make more sense.

I think a more apt analogy would be asking us if we'd prefer going with the latest release of Fedora, under a new name, or get something yet to be determined from a company that owns the name "Fedora"

Comment 83 Michael Friedrich 2014-01-28 22:05:19 UTC
Monitoring Plugins upstream has applied lots of patches. That affects the fedora specific patches:

* monitoring-plugins-0002-Remove-assignment-of-not-parsed-to-jitter.patch becomes obsolete with the removal of check_ntp.pl in https://github.com/monitoring-plugins/monitoring-plugins/commit/43fbde678c608c2d44d9ebd98a710e63d9300f06

* monitoring-plugins-0007-Fix-the-use-lib-statement-and-the-external-ntp-comma.patch is obsolete as the 2 patched variables were used by the now removed check_ntp.pl in https://github.com/monitoring-plugins/monitoring-plugins/commit/43fbde678c608c2d44d9ebd98a710e63d9300f06

* monitoring-plugins-0010-fix-smart-attribute-comparison.patch can be dropped. That's fixed in https://github.com/monitoring-plugins/monitoring-plugins/commit/c4a99b023d03326ad49e03c8731eec19d19a75bf


In terms of packages

* monitoring-plugins-ntp-perl is no more. check_ntp.pl was removed upstream.


I've rebased my rpm build repo towards 1.6 and verified everything working including additional rpm fixes (check the spec %changelog).
https://github.com/dnsmichi/monitoring-plugins-rpm/tree/feature/1.6

Thomas is looking at the check_swap issue later in order to remove another patch. The ugly subst patch could possibly be solved by moving the file generation into autotools.

@Sam
That should help the preparation of your 'monitoring-plugins' package for review. The fedora specific patch count is now down to 3.

Comment 85 Trond H. Amundsen 2014-07-28 16:22:09 UTC
(In reply to Michael Friedrich from comment #32)

> And then there are some additional plugins which require the nagios-plugins
> rpm for providing the directories
> (http://pkgs.fedoraproject.org/cgit/nagios-plugins-openmanage.git/tree/
> nagios-plugins-openmanage.spec#n29)
> 
> * nagios-plugins-openmanage

I'm the maintainer of this one. The nagios plugins directory (e.g. /usr/lib64/nagios/plugins) is owned by:

* EPEL5: nagios-plugins
* All others: nagios-common

I'm pushing an update to nagios-plugins-openmanage, with fixed requires.

-trond

Comment 86 Jaroslav Reznik 2015-03-03 16:58:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 87 Fedora Admin XMLRPC Client 2015-08-31 15:11:08 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 88 Fedora Admin XMLRPC Client 2015-08-31 15:16:13 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 89 Nick Bebout 2015-08-31 21:21:31 UTC
WONTFIX.

This package is nagios-plugins, which will remain using the upstream nagios-plugins.  If the fork which is now called monitoring-plugins wants to be packaged, they can submit a package for review.

Comment 90 Sven Nierlein 2015-08-31 21:33:49 UTC
Unfortunatly it's not as easy as it looks in first place. The original "nagios-
plugins" had to rename the project to now monitoring-plugins because they did
not own the trademarks. Then a fork was created and named again "nagios-
plugins" which now leads to confusion because it's a new project with an old
name.

Comment 91 J Chapin 2015-09-01 14:03:28 UTC
"nagios-plugins" is the new package. The project that was originally called that has been renamed to "monitoring-plugins" -- the original code, and authors are on that project. "Nagios-plugins" -- the new version, is not the same project.

Comment 92 J Chapin 2015-09-01 14:05:55 UTC
I should add that the exact confusion expressed by the current package maintainer is why the new "nagios-plugins" should never be packaged as "nagios-plugins" -- if the *PACKAGE MAINTAINER* is getting confused, the end users are going to have a hard time, too.

Comment 93 DJ Delorie 2015-09-01 17:25:32 UTC
The time for arguing this has long past, any attempt to ressurect this old argument would be petty.  Let the package owner own it already.


Note You need to log in before you can comment on or make changes to this bug.