michaelanthoni.com

As a die hard Nagios user ever since the early beta releases, I was excited when I came across some blog postings relating to Nagios and found Opsview late last summer. At first glance, I was a bit skeptical as there have been many offshoot projects of Nagios over the years as seen in the Nagios Exchange. That’s not too say that those projects aren’t great and/or viable solutions to the shortcomings of Nagios; I’ve got a published project or two registered at Nagios Exchange myself. But after going over some of the documentation for Opsview, I must say I was somewhat impressed as Opsview seemed to be implementing Nagios right. This project looks to take care of a lot of the nitty gritty details that many of the projects in the Nagios Exchange attempt to solve. However, as a relatively advanced Nagios user, I wasn’t sure if it would provide the flexibility I needed so I downloaded the vmware player image of Opsview to take a look. After poking around for a few minutes it seemed to be very flexible indeed and I was sold. However, finding the time to actually begin testing the product in a production environment and then replacing my current Nagios implementation is another story. This week, I was finally able to get Opsview installed and monitoring a subset of my production network for testing purposes.

Overall, the installation went smooth as the documentation is straight forward and using aptitude made the task trivial. During the setup of hosts and services, I did run into some minor issues and was a bit frustrated by the configuration through the web based interface. I guess I’m just used to configuration files instead of all the point and clicking. Hopefully this is where the database comes in, although I am still learning the layout and structure so point and click will have to do for now. I was able to work through my frustrations and issues and did find some help in the opsview-users mailing list. Thats always a good sign, but it’s still a bit early for me to tell whether I will stick with Opsview and migrate my current Nagios implementation over yet. Only time will tell.

Well Openbsd 4.2 has been out for about two months now and I wanted to post this a little sooner but with all the holidays I havent had a chance.

If you’ve upgraded to 4.2 then you have probably ran into the libexpat dependency issue like the rest of us. For those of you who have not upgraded yet, I hope you would read the Upgrade guide as one would expect as this issue is described here.

If you havent read the “gotchas” section, the issue is that the libexpat library has been moved from the base set to the xbase set. Now this presents a problem for people such as myself who do not install the xbase on firewalls and routers. The main problem is that this library is a dependancy to many other packages and is acknowledged with the following statement:

This will impact a large number of users! This was an unfortunate decision whose ramifications were not recognized earlier in the process. For 4.3, libexpat will be part of base43.tgz, solving this problem.

I believe this issue has already been resolved in the -current tree but for those of us who are only running stable we cannot wait the 4 months until the next release cycle and we sure as hell are not installing the xbase set. So what are we to do. I’m sure this is completely unsupported by the OpenBSD folk but this worked fine for me.

Workaround:

Download the xbase set at ftp://ftp.openbsd.org/pub/OpenBSD/4.2/i386/xbase42.tar.gz

Extract the xbase42.tar.gz to a temporary location, say /tmp

#mv xbase42.tar.gz /tmp
#cd /tmp
#tar -zxvf xbase42.tar.gz

There are 3 files in which you need inside the ./xbase42/usr/X11R6/lib directory.

#cd ./xbase42/usr/X11R6/lib
#ls -al libe*

-rw-rw-rw- 1 user group 153436 Aug 8 23:03 libexpat.a
-rw-rw-rw- 1 user group 157767 Aug 8 23:03 libexpat.so.8.0
-rw-rw-rw- 1 user group 183510 Aug 8 23:03 libexpat_pic.a

Copy these 3 files to your /usr/lib directory.

#cp libe* /usr/lib

And whala! A stupid simple solution to a really annoying issue. Now you should be able to install/upgrade your packages as you need without hitting this dependency issue. Other then this little bug the Openbsd 4.2 release has worked great for me.