duplicates on import

[lmiltchev]

This is the solution I was going to offer. In fact I was testing it to make sure it works as expected, but I ran into some issues with it. For some reason, the service was not deleted on my test box after running:

Code: Select all

cd /usr/local/nagiosxi/scripts
./nagiosql_delete_service --service=<configfile>
./reconfigure_nagios.sh

I am not sure if I have something wrong with my test XI box - it's abused quite a bit.

Can you verify that the "nagiosql_delete_service" script works as expected in your environment?

[kendallchenoweth]

nagiosql_delete_host --host=<host> works but
nagiosql_delete_service only works with the --id arg not the --config arg

It looks like my solution has some holes. I nagiosql_delete_service supposed to take the config?
How do you use this script within the application? If you only use the --id arg, then maybe the --config arg doesn't work (I hope this isn't the case.)

[ssax]

Have you read through this document?

https://assets.nagios.com/downloads/nag ... gement.pdf

Pretty much what you are looking to do.

[kendallchenoweth]

When I click on that link, I get a redirect error. I think I tried this same link on the nagios web page somewhere.

Anyway...

I'm starting to lean towards using the static directory. Let me please explain what I'm trying to accomplish and how and you can poke holes in this approach, please.

I have a QA instance of Nagios with a copy of everything that will be in production. This is a normal Nagios XI using the CCM. I have written a grails app which parses the QA Nagios XI etc configration directory and identifies any new changes from the last time a baseline of the CCM was taken. All of the configuration objects from Nagios XI are transformed into their own files in temporary directories. These individual files/objects can now be placed in source control.

At this point I can

A) copy the changed transformed objects to the import directory of the target production nagios XI server and run reconfigure_nagios.sh. However, I've discovered challenges when I want to delete something (need to call nagiosql_delete_host/service separately) and (nagiossql_delete_host doesn't take config_file as an argument) and any hostname/hostgroup changes to services produce duplicate services on the target system.

or B)
copy the transformed objects to the static directory of the target production system, ignoring the CCM database in production. I can delete individual objects and change (overwrite) individual objects as mere files. If I go this route, I need to write my own static directory backup and restore if the change doesn't pass validation.

I'm currently leaning toward option B, as it bypasses the problems in A and makes it harder for people to make production changes directly on the fly. Does this approach fall into your support model?

What do I lose with option B? Is there a problem with configuration files in subdirectories in the static directory? (I'll try this - it works.)

What do you think? More specifically, what are the drawbacks or flaws or loss of functionality that results from this approach?

Thanks for your time!

[lmiltchev]

If you need to manually maintain your object configuration files, you can place them in the static directory. The advantage is that you can create a large number of configs on a fly (via scripts, etc.), which is very useful in large environments. The disadvantage is that these configs can't be managed via the CCM.

Is there a problem with configuration files in subdirectories in the static directory?

I don't believe this is going to be a problem.

Here's our documentation on manual config file management:

https://assets.nagios.com/downloads/nag ... ios-XI.pdf

[kendallchenoweth]

If we're only going to use the /usr/local/nagios/etc/static content, do you recommend

A) disabling the CCM
and how do you do that?

or

B) deleting everything from the CCM
what's the best way to do that? I assume we just never run the nagios_reconfigure.sh command again?

Is there another preferred option? I don't want to have configuration data mixed between the CCM and the static on the production systems. (I have a system that uses a QA instance of Nagios XI that produces the config files for the production static directory.)

Thanks!

[jolson]

I think that B would be your best plan of action here. If you delete everything from the CCM, a reconfigure_nagios could still be run - but would populate no data since the CCM would be empty.

All management on your end would be done traditionally, through the flat files in your static directory and interacting with nagios primarily to check for errors and restart it:
Error checking:

Code: Select all

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Restarting:

Code: Select all

service nagios restart

[kendallchenoweth]

Great. Can I confirm that all of the object interaction through the Nagios XI (acknowledge/history/graphing/bpi/mass acknowledge, etc) (except for CCM) works the same regardless of where the object is defined? I figure it has to be, but I just want to be sure. With this confirmation, I am done with this thread. Thanks for your help!

-Kendall Chenoweth

[jolson]

Confirmed. All should work exactly as you would expect from XI.

[mazeman]

Hi Nagios Support,

Has the issue of duplicate service definitions when updating via the import directory been fixed in Nagios XI 5? I'm running to the same issue with version 2014R2.7 as we are trying to use a deployment tool to automate the monitoring configuration, but also give Non-CLI/non-config file savy admins (not me ) access to tweak stuff through CCM.

Thanks!

-Kevin