|Summary:||=net-analyzer/nagios-3.5.1 should provide apache2.4-friendly configuration files|
|Product:||Gentoo Linux||Reporter:||Simon-Pierre Dubé <shaedge>|
|Component:||Current packages||Assignee:||Michael Orlitzky <mjo>|
|Severity:||normal||CC:||creffett, hydrapolic, jstein, shaedge, sysadmin|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||468302|
Description Simon-Pierre Dubé 2016-04-10 18:58:57 UTC
Package provide an old Apache 2.2 configuration in /etc/apache2/modules.d/99_nagios3.conf. The default provided still use old authz_host config "Order" instead of the new Apache 2.4 "Require", making it not to work out of the box. Version 4.1.1 is okay, didn't test versions in between though.
Comment 1 Michael Orlitzky 2016-04-11 12:09:49 UTC
We can't really fix this for the existing nagios-3.5.1 ebuilds because they're marked stable. We would have to make a new revision, then wait a month, and stabilize the new revision. I eventually plan to "fix" this by stabilizing nagios-4.x (now that apache-2.4.x is stable) and then removing the nagios-3.x stuff.
Comment 2 Michael Orlitzky 2016-04-11 12:46:08 UTC
Apache-2.4 is still unstable on ~hppa ~ppc ~ppc64, and ~x86 where nagios-3.5.x is stabilized. I can put in the stabilization request for nagios-4.x as soon as that gets taken care of in bug #468302. If you can, I would suggest upgrading to nagios-4.x now by adding net-analyzer/nagios-4.1.1 and net-analyzer/nagios-core-4.1.1 to your package.accept_keywords. Most of what nagios actually does is provided by the plugins, and your nagios-plugins don't need to be updated, so the migration should be pretty easy. Otherwise, if you wait until we get this all sorted out, nagios-4.1.1 will go stable (and I'll remove 3.5.1) and you'll have to upgrade anyway =)
Comment 3 Simon-Pierre Dubé 2016-04-11 15:00:18 UTC
Thank you for your quick answer. The change needed is quite trivial. I modified the Wiki to reflect the 2 lines modifications needed. https://wiki.gentoo.org/wiki/Nagios/Guide#Restricting_Access_to_the_Nagios_Web_Interface Would it take some stabilization to include a warning in the ebuild in meantime? I went for 4.1.1 anyway as i thought version 3.5.1 is rather old. I'm still in the process of configuring mine to include all the plugins i need. Yet i didn't encounter problems with any plugins so far. I am not surprised, after all, it's simply calling scripts. The only one i am worried about is the nagios-virt, because it's in C and rather old. In any case. Thank you again. If i can be of any further help, don't hesitate writing me.
Comment 4 Michael Orlitzky 2016-04-25 22:39:12 UTC
(In reply to Simon-Pierre Dubé from comment #3) > Thank you for your quick answer. > > The change needed is quite trivial. I modified the Wiki to reflect the 2 > lines modifications needed. > Thanks for doing that! It is indeed pretty easy to fix, but we only get to install one config file at a time -- that's why nagios-4.x now requires apache-2.4.x. > > Would it take some stabilization to include a warning in the ebuild in > meantime? > Normally adding an "ewarn" message would be safe, but I just tried to do it, and there's something messed up in the ebuild. The nagios-core-3.5.1.ebuild has *two* definitions of pkg_postinst()... the first one has a lot of nice logic and informational messages and all that stuff. That's where I tried to add the ewarn (so that it would only show up for people with USE="apache2 web"). The second pkg_postinst() was added by accident and only fixes some permissions. But it overwrites the first definition! To fix it, I would delete the second pkg_postinst() and move its code into the first one. But, that would actually constitute a fairly large change, since the whole big function (now shadowed) would just "appear"... and we can't make big changes to stable ebuilds. (The other thing I could do is copy a bunch of logic into the second pkg_postinst, but I'd rather not do that either.) tl;dr yes we could do it, just not in this case. Sorry!
Comment 5 Michael Orlitzky 2017-07-21 20:27:07 UTC
Nagios 3.5.1 has old security vulnerabilities and will be removed from the tree ASAP (we're just waiting on some lagging arches to handle their keyword requests).