Nagios compatibility

[Kevin Keane]

Andy Shellam wrote:
>
>> My recommendation: throw out the nagios you did (just keep the files 
>> in the /usr/local/nagios/etc directory), and instead find nagios as 
>> an already-compiled RPM. There really is very little reason to ever 
>> run your own compiled software except to learn. On a production 
>> server, it is outright dangerous to do so because you won't get any 
>> software updates.
>>   
> For the record, I disagree with this statement.  Compiling your own 
> software means you can get updates as quick as they come out from the 
> people who write it.  Sure you have to keep on top of the updates 
> yourself, but that's where a tool such as www.update-scout.com comes 
> in extremely handy.
In theory, that may be true, and for some people this does matter.

In practical terms, though, more often than not, the opposite happens: 
somebody downloads the source code, throws it on a shared drive, writes 
a howto and everybody recompiles off these versions no matter how stale 
they are. I used to work for a company in 2003 that ran RedHat 7.0 (a 
1990s version of RH). Because it didn't include Postgres, they compiled 
Postgres from source - by the time I started there, those sources were 
two years old. And they ran a major telephone exchange and billing 
system off that setup. My boss would have thrown a fit if I had proposed 
to install a newer version of Postgres, because that would have meant 
having to re-test the whole application. At least, with an RPM, the 
vendor would do most of the testing for us.

And also let's not forget the complexity of the upgrade process itself. 
Upgrading an RPM takes a few seconds - especially when you are using 
automatic updates. Recompiling? Maybe half an hour if you are good.
> In my experience package repositories (such as those used by Debian's 
> "apt-get") are not well maintained - for example the OpenSSL version 
> currently in there is 0.9.8c which was released in September 2006.  
> There have been 6 security advisories since.  Similarly the Apache2 
> package is version 2.2.3 - I'm running 2.2.11 now.
Actually, I think this is an advantage rather than a drawback, for most 
users (you may well have specific needs, and of course I can't tell you 
what's right for you!) For most software, the bleeding edge is also 
where the bleeding is happening ;-) There is a reason the enterprise 
Linux versions (SuSE, RedHat) have release cycles of 3 years, and the 
open versions have release cycles of 18 months or so.

Vendors will backport security patches, but quite honestly I would 
rather have a stable system than one that needs to be recompiled on a 
near daily basis - especially for production use. My openSUSE 10.3 
server currently has 757 RPMs installed. With recompiling modules as 
they come out, configuration management would become a nightmare. On a 
weekly basis, I'd have to ask: why isn't my software working any more, 
and which of the 17 modules recompiled yesterday is responsible? No 
thanks. I want to leave the compatibility testing to the vendor. My 
Nagios server (on openSUSE 11.0) is still using 3.0.3. I'm sure I could 
easily find the 3.0.6 RPMs if there was a compelling reason for it. But 
so far, I don't see it.

If I really do need a newer version than the vendor has - I can usually 
find it precompiled as an RPM. As a SUSE guy, I usually find it on 
opensuse.org. I'm usually very reluctant to do this because it cuts me 
off from the vendor's update cycle, but sometimes I really have no 
choice. Fortunately, I've only had to do it for four or five RPMs.
> Compiling your own software also allows you to add in extra features 
> that the packagers didn't deem necessary, and gives you more control 
> over the build.
Granted. I actually have found one single situation where this benefit 
would have made a difference; one RPM has a bug (the openSUSE developers 
forgot to support Kerberos in saslauthd). It's exceedingly rare, at 
least for me - and in this case, the impact was small enough, so 
recompiling still doesn't

YMMV, of course.

-- 
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About

Office: 866-642-7116
http://www.4nettech.com

This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null