Nagios Support Forum

I agree with the preceding post with the caveat that you won't be able to properly store the hostgroup configuration in Nagios XI. The static functionality does not automatically change the "state" within the Nagios GUI. In other words, the monitoring engine will handle static configurations just fine, but you will not see these configured objects in the Nagios XI GUI.

This highlights one of the difficulties in automating certain things within Nagios XI. They have provided an easy way to import new configurations, but modifying those configurations once they are in the Nagios XI backend database can be difficult. In the case of the reply above, you would have to remove the hosts using the nagiosql_delete_host.php utility, then create the hosts again via the import mechanism. This process is fairly straightforward, but is hardly trivial.

That all said, if you're a risk taker you could directly manipulate the database once you understand what happens when you make the change you need. Nagios have stated categorically that they will not support this option.

One other consideration would be an event_handler that utilized the external command pipeline to modify the running configuration of the Nagios engine. You can change most aspects of the "in flight" configuration through the external command interface. However, these changes do not survive a restart of the Nagios monitoring engine.

mp4783 wrote:You can change most aspects of the "in flight" configuration through the external command interface.

These are mostly run-time state options - like the enabled/disabled status of notification, passive checks, active checks, etc. Most base object configuration though is not changeable.

mp4783 wrote:However, these changes do not survive a restart of the Nagios monitoring engine.

through the cgi.
Well, some of these settings should be saved in retention.dat, so as long as that file exists through restarts, some of these options will persist.

I figured out a solution I'm pretty happy with. Involves a little setup but after that, smooth sailing.

First, I have a script on the various hosts I'm monitoring called "CheckIpAlias". This will return a simple ok/nok (0/1 return code) when I pass it a DNS name. If the system has the IP of the DNS name, it's okay, and if not, not.

I can then use that, in conjunction with && and || for Bash to run things. By running: If the "dns alias> matches, the dummy check returns "live". By the same token, if I run: then I'll get "not live".

Combining the 2 in a nrpe.cfg line, you get: which allows you to run the following from your Nagios server:
./check_nrpe -H Prd1 -c check_alias_dummy -a live_dns

In this way, if the server is live, I get a "live" response and if it doesn't have the live IP address, I get a "not live".

Pretty rudimentary for purposes of an example but, you can then build on that. For my purposes, I've created a new check command (copied from check_nrpe) called check_nrpe_alias. It uses a variable definition I've set in the CCM for the hosts to pass the DNS entry I'm looking for. This new check takes for arguments, the DNS entry for live, the check for a live system and the check for a non-live system. In this way, all my systems can share a standard NRPE config and as the live IP migrates from machine to machine, the checks will automatically update.

Good example is if you only want httpd running on your live server. The live check would ensure you have at least x number of httpd processes running while the non-live check would ensure none are running.

Thank you for the update rlacasse, can we mark this as resolved and lock the topic?

yes, thank you