Nagios Support Forum

Hello again,

My question de jour involves installing NRPE on client systems using a repo source vs. compiling from source. For obvious reasons, compiling from source isn't a favorable solution, especially given the additional operations that are shown in this document: https://assets.nagios.com/downloads/nag ... _Agent.pdf

As such, we would like to utilize a repo-based version of NRPE. Is there any drawback to installing from repo vs. compiling from source as far as Nagios operability is concerned? Do we gain/lose any functionality? Is there anything different about the source install that's not accounted for in the repo?


Thanks as always,

-- Mike Beebe

Is there any drawback to installing from repo vs. compiling from source as far as Nagios operability is concerned? Do we gain/lose any functionality? Is there anything different about the source install that's not accounted for in the repo?

There are many things that are different - not sure if I will remember all of them.

• Our Linux agent installer script installs NRPE and Nagios Plugins, and NRPE runs under xinetd. When you install NRPE from a repo, you will also need to install Nagios plugins from a repo, e.g.

  Code: Select all

  yum install -y nrpe nagios-plugins-all

  and NRPE will be running as a "standalone daemon".

• When NRPE and plugins are installed from a repo, the paths to the NRPE configs, binary, and plugins are in a different location, e.g. /etc/nagios/nrpe.cfg vs /usr/local/nagios/etc/nrpe.cfg, /usr/sbin/nrpe vs /usr/local/nagios/bin/nrpe, and /usr/lib64/nagios/plugins vs /usr/local/nagios/libexec. This is not a problem by itself, but it may take longer to troubleshoot a possible issue. Some of the paths would vary from distro to distro too, so this adds to the complexity.

• Our Linux agent installer places some "default" commands in a separate config file (/usr/local/nagios/etc/nrpe/common.cfg), where you can add some custom commands. These commands (this file) is used, when you run the Linux Server wizard in Nagios XI against your client machine. If you don't have it, some/all the newly created services may fail. Also, if a future upgrade replaces your "original" config file (nrpe.cfg), you may lose all of your "custom" commands. If they are in a separate config, e.g. common.cfg, you would be safe.

• At the end of the installer script (the official Linux agent script that is), you are asked about the IP address of your Nagios XI server, which is then added to the config automatically. If you install NRPE from a repo, you will need to add IPs manually.

• NRPE runs as a NRPE user when you install it from a repo. If you install NRPE from source, it runs as nagios user. NRPE user is added to the nagios group though, so in most cases you should be fine.

• When you install Nagios plugins from a repo, you will be missing some "extra" plugins, including check_nrpe. There are some additional plugins (not part of the "official" Nagios plugins) that are included in our Linux agent installer. You will be missing all of them.

• If there are important fixes, e.g. security fixes in the latest version of the agent, you may not be able to get them, as the new version may not be available yet in the repo.

I am not sure if these are all of the differences. If anyone thinks of something else, feel free to chime in. Thanks!

Your answer is both enlightening and worrying.

In a modern IT environment, compiling source code isn't scalable or sustainable. I can't use Puppet, for instance, to re-compile NRPE when a new version is released or when a new system is stood up. Worse, the correct way to distribute code -- via either a package manager or from a source repository like Git -- doesn't provide the same packages, or even the same paths, as the compiled code. The fact that this difference is enough to break Nagios monitoring is more than just a little alarming. I can't understand why a company that provides critical IT functionality would adopt a distrubtion methodology straight out of 1995.

Nagios is a huge part our IT infrastructure. We're relying on this product to keep our production systems running and NRPE is absolutely critical to this effort. Scalability is a hard requirement and automation is mandatory. The fact that I can't satisfy either of these objectives worries me greatly. I genuinely like Nagios and believe that the product is the right tool for the job. Perhaps Nagios can re-examine how NRPE is being distributed and at least bring the compiled version and the repo version into compliance with each other. This would make the lives of administrators such as myself much less tear-filled.

Here endeth the lecture.

Thanks,

-- Mike Beebe

Hello Mike,

I'd like to follow up with some other info about this. There are currently a few wizards in XI that give the Linux NRPE Agent as the agent to install and this is because it's the tired and true way. As Ludmil noted above, there are quite a few differences with the compiled agent we give via the tarball install and the default standard nrpe package install.

NRPE is slowly being deprecated by NCPA. With NCPA, we build binary versions of NCPA for almost every operating system (https://nagios.org/ncpa) and it is installable via our nagios repo (https://repo.nagios.com/) and it does have it's own separate wizard in XI. It is also likely that it will eventually replace the other wizards that use the compiled version of NRPE.

Hi Jomann,

Thank you for the insight into the reasoning behind NRPE's distribution. So in your view, is it worth performing a large-scale rollout of NRPE vs. using NCPA to accomplish the same tasks (custom monitors)? Once these checks are in place, I'd rather not revisit them in the future.

Thank you,


-- Mike Beebe

Hi Mike,

As Jake mentioned, while NRPE is and will be still be supported, I would recommend using NCPA on new and future projects as it's easy to install, maintain and we are planning to add new features in the future.

https://www.nagios.org/ncpa/

Let us know if you have any other questions.

I'll read up and thank you all for the information and edification.

Feel free to lock.

-- Mike Beebe

Hi Mike,

Sounds good. Locking.