Nagios Support Forum

I am working on a universal utility (shell script) to perform nearly every common "add/delete" function that you can do in the Nagios XI GUI. The mechanism for this is, of course, the manipulation of the appropriate configuration files and then execution of the reconfigure_nagios.sh script. When done properly, this works every time.

I've learned how Nagios keeps reconfigurations isolated through the use of a lock file, which again, works perfectly. However, I have concern that I don't know how to address exactly. A scenario would best explain:

- User A is in the GUI and has made a change to a service Y belonging to host X
- User A then saves the change, but does not apply it yet as they have other changes to make (at this point Nagios XI indicates changes need to be applied)
- User B is using an external automation tool to disable the event handler associated with that same service Y on host X.
- The external tool captures the current state of the host X service Y configuration by looking at the current /usr/local/nagios/etc/services/X.cfg file
- The external tool sets the event_handler_enabled value to 0 and creates a modified X.cfg service configuration file and places it in the /usr/local/nagios/etc/import directory
- The external tool then executes reconfigure_nagios.sh and the change is applied

At this point user A has a certain expectation of the what the state of service Y will be for host X. However, that state was changed "underneath" the GUI by user B and external automation.

While Nagios will certainly function, this can create confusion. In fact, I don't recall ever seeing anything about the effect of multiple GUI users modifying the same object in different manners and how Nagios would handle that. I know that any reconfiguration will be handled serially because only one reconfiguration can be occurring at the same time.

One way to help the external automation stay "in sync" with the GUI would be if it could know that there were pending changes. How would we know that the "Changes detected!" flag was set?

The "Applied" vs "Not Applied" status of an object in the CCM is determined by comparing the last update timestamp in the db against the config file timestamp. If there is a discrepancy (specifically, when last_modified is newer than the config file) then "Not Applied" is displayed. The field in the db is the "last_modified" column in the tbl_service table (for services, obviously change the table depending on the object), nagiosql db. This is for individual files/objects.

For the overall Applied/Not Applied status, you need to look at the postgres db "nagiosxi" for the xi_options table and the "ccm_apply_config_needed" flag.

Hey Trevor, I think this is very useful information, could you please post the complete postgres db query to get the ccm_apply_config_needed flag pls? Thanks.

For those of you unfamiliar with PostgreSQL ( I'm still not sure why it's being used and not the MySQL database), here's a command that will produce a single value you can use to determine if there are pending changes to be applied:

su postgres -c "psql -q -c \"select value from xi_options where name='ccm_apply_config_needed';\" nagiosxi nagiosxi | tr [:blank:] ' ' | sed 's/^ //g' | grep ^[01]"

This assumes you have the authority to su to the postgres user and that the only values the query will produce are "0" or "1". You may need to modify it.

How do I log into the PostgreSQL database from an external workstation? I want to use pgAdmin III to have a look at the database structure in the same way that I'm using SQLyog to look at the MySQL database.

I promise no touching of the tables.

Never mind, I figure it out eventually. For those of you also interested, do the following:

# su - postgres

# psql

postgres=# CREATE USER myuser WITH ENCRYPTED PASSWORD 'mypass' SUPERUSER;

postgres=# grant postgres to mysuser with admin option;


Make backup copies of /var/lib/pgsql/data/pg_hba.conf and /var/lib/pgsql/data/postgresql.conf.

Then edit the /var/lib/pgsql/data/pg_hba.conf file by adding a line similar to the following. You should change the address to something appropriate for your network that restricts access.

host all myuser 192.0.0.0/8 trust

Then edit the /var/lib/pgsql/data/postgresql.conf file and add or modify the following:

listen_addresses = '*'

Restart PostgreSQL and confirm that Nagios is still functioning properly. After doing this, I was able to connect pgAdmin III to the Nagios PostgreSQL database.

If what I've just done above is "dangerous" to the Nagios XI installation, assuming the user doesn't directly modify the PostgreSQL tables, please let me know.

mp4783 wrote:If what I've just done above is "dangerous" to the Nagios XI installation, assuming the user doesn't directly modify the PostgreSQL tables, please let me know.

I can't think of anything from a code perspective that might be dangerous, but aside from that make sure, as always, to consider the network security aspect of it. A strong password, maybe set up iptables to only allow external access from one machine, etc.

From the postgres documentation

if WITH ADMIN OPTION is specified, the member may in turn grant membership in the role to others, and revoke membership in the role as well. Without the admin option, ordinary users cannot do that. However, database superusers can grant or revoke membership in any role to anyone.

Is it your intent to open the permissions or granting of authority to anyone outside of the Nagios XI server? That would expose granting access and permissions to outside of the Nagios XI server.

No, my intention is to provide read-only access to a limited number of views and/or columns, restricting access to an account local to the Nagios XI server itself. I don't have a great deal of PostgreSQL experience, but I'm sure I'll restrict it appropriately.

The access I have obtained, superuser, is merely so that I can see what is available. I have set the "dont_blame_nagios" flag in my head in case I mess something up.