My experience evaluating Nagios Log Server
Posted: Thu Oct 08, 2015 6:29 pm
Hello, my site deploys Nagios XI and we are fairly happy with it. I have been asked to evaluate Nagios Log Server to potentially add to our monitoring infrastructure. Based on my experience I will be recommending that we stay away from this product, and I thought you might like to know why.
I obtained the trial copy source tarball, extracted it, and ran the installer. The first thing I noticed was that it had installed to /usr/local, which is against our site policy. No problem, I thought, I'll just uninstall and re-install in the right place. So I looked for the uninstallation script, only to discover that one isn't provided. So I tried removing it by hand, but it installs a variety of components in a variety of locations, started by a variety of methods, and I couldn't be sure I'd removed it completely.
So I re-imaged my test server, recopied the tarball over, and took a look at the install script, noticing that it defines a variable $proddir pointing to the web root and $backenddir pointing to the installation target directory. Thinking I'd solved the problem, I edit $backenddir to point to /opt/nagioslogserver and re-run the installer on the new clean image. The install script completes, but... hmm, the web interface is telling me "Database Offline". It seems there's a component called elasticsearch which isn't running.
So I try to start elasticsearch by hand, only to discover that the init.d script for this component is hard-coded to look in /usr/local. I gamely fixed the init.d script only to discover that the PHP scripts contain hard-coded references to /usr/local. In fact, the whole package contains a hardcoded /usr/local directory pathname in 77 places.
Guys, not hard-coding details such as directory pathnames is Coding 101-level stuff. Other users use different directory layouts and conventions than you do. This ought not to be news.
As a further complication, the installer also created a nagios user and group, assigning it the lowest available UID and GID on this test system and assigning it file/group ownership of the installation directories. We surely cannot be your only customer with centrally assigned UIDs and GIDs. In order to avoid a major inconsistency, I would have to delete and recreate the nagios user with the right UID/GID, then manually go around the installation directories chown'ing them all to the correct UID/GID.
It was that point that I gave up, as it was clear that there was no way to install the software in a manner consistent with my site's practices and policies. In two decades of Unix administration I've never seen software that you could not install into a directory of your choosing until now -- your installer has literally zero configurable parameters. Even if I were willing to make the modifications necessary to get the software working, I would be in constant fear that it's going to break due to some incorrect, uncorrectable assumption about how we do things here. "Streamlined deployment" does not and ought not to mean "Do everything our way, or no way at all".
I will be evaluating a competitor next, and I see that the first page of their installation manual describes how to change the installation directory. Perhaps you should take some inspiration from your competitors here.
I obtained the trial copy source tarball, extracted it, and ran the installer. The first thing I noticed was that it had installed to /usr/local, which is against our site policy. No problem, I thought, I'll just uninstall and re-install in the right place. So I looked for the uninstallation script, only to discover that one isn't provided. So I tried removing it by hand, but it installs a variety of components in a variety of locations, started by a variety of methods, and I couldn't be sure I'd removed it completely.
So I re-imaged my test server, recopied the tarball over, and took a look at the install script, noticing that it defines a variable $proddir pointing to the web root and $backenddir pointing to the installation target directory. Thinking I'd solved the problem, I edit $backenddir to point to /opt/nagioslogserver and re-run the installer on the new clean image. The install script completes, but... hmm, the web interface is telling me "Database Offline". It seems there's a component called elasticsearch which isn't running.
So I try to start elasticsearch by hand, only to discover that the init.d script for this component is hard-coded to look in /usr/local. I gamely fixed the init.d script only to discover that the PHP scripts contain hard-coded references to /usr/local. In fact, the whole package contains a hardcoded /usr/local directory pathname in 77 places.
Guys, not hard-coding details such as directory pathnames is Coding 101-level stuff. Other users use different directory layouts and conventions than you do. This ought not to be news.
As a further complication, the installer also created a nagios user and group, assigning it the lowest available UID and GID on this test system and assigning it file/group ownership of the installation directories. We surely cannot be your only customer with centrally assigned UIDs and GIDs. In order to avoid a major inconsistency, I would have to delete and recreate the nagios user with the right UID/GID, then manually go around the installation directories chown'ing them all to the correct UID/GID.
It was that point that I gave up, as it was clear that there was no way to install the software in a manner consistent with my site's practices and policies. In two decades of Unix administration I've never seen software that you could not install into a directory of your choosing until now -- your installer has literally zero configurable parameters. Even if I were willing to make the modifications necessary to get the software working, I would be in constant fear that it's going to break due to some incorrect, uncorrectable assumption about how we do things here. "Streamlined deployment" does not and ought not to mean "Do everything our way, or no way at all".
I will be evaluating a competitor next, and I see that the first page of their installation manual describes how to change the installation directory. Perhaps you should take some inspiration from your competitors here.