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