[CentOS] CentOS/SNMP update breaks MRTG?

Wed Jul 15 12:58:00 UTC 2009
Les Mikesell <lesmikesell at gmail.com>

Noob Centos Admin wrote:

>> well, i note there's a few versions of rrdtool in the various
>> repositories.   the stock CentOS 5 version 9from upstream) is 1.2.30,
>> while rpmforge has 1.3.7, also a seperate rrdutils package (I have no
>> idea whats in it)
> *sigh* The stuff of nightmares, I did have 1.3.7 installed after
> checking. But searching on this direction finally yielded an important
> piece of information. Somebody posted back in 2008 on a site to IGNORE
> the jrrd problem because OpenNMS supposedly comes with some kind of
> java rrd already installed (which begs the question of why then is the
> jrrd step mentioned in the install guide).

Initially OpenNMS used rrd to keep its data history and it still can as an 
option, but the default now is a built in pure-java version.  The data file 
format is not compatible, though.  Rrdtool uses a binary format that varies by 
processor type where the java jrobin version is portable to anything running 
java.  I don't remember seeing this problem when installing from the opennms yum 
repository, though.

> So I went ahead with the install process which then complained that my
> postgresql was the wrong version, i.e. 8.4 instead of max of 8.3, but
> at least this time it kindly offered a -Q option to ignore the version
> restrictions at my own risk.

Are you getting any benefit from mixing all of these non-stock versions on your 
system?  How many different repositories that contain conflicting versions of 
packages do you use?  Normally epel doesn't overwrite stock packages and opennms 
doesn't - the rest are somewhat dangerous.  I normally leave other 3rd party 
repos disabled and use 'yum --enablerepo=reponame install somepackage' when I 
specifically want something from them (repeat with update periodically) and 
review the list of packages before continuing.

> I did. Then it was on to another problem, with OpenNMS dying on
> startup due to port clash with DHCP. Fortunately again, this was noted
> as something that happens quite often on Linux systems and a quick fix
> was to simply comment out the dhcp configuration.

That is normal - typically you'd run opennms on a machine dedicated to 
monitoring, with perhaps thousands of targets so it wouldn't be running a lot of 
other services.

> After that, it was just the usual matter of opening a port in iptables
> for the opennms/tomcat and FINALLY something was working.
> I'm crossing my fingers that ignoring the jrrd, ignoring the versions
> and ignoring the dhcp monitor isn't going to bite me one of these
> days. For now, "ignore"nce is bliss :D

Removing it won't bother opennms.  It has an assortment of application probes 
that it uses in addition to snmp and is intended to work automatically with 
large numbers of targets - when it discovers a node (or you add it),  it probes 
the application ports to see what is running, then periodically tests again and 
notifies you when something that was previously running stops working.  However, 
it is very configurable and you can add/remove whatever you want.

   Les Mikesell
     lesmikesell at gmail.com