NagiosXI 2024R2.1 Deactivated Services Not Applying

[smithjor]

I am running a mostly fresh install of Nagios XI. I did a manual import of configurations and one database from a Cent OS 9 provided Nagios provided OVA over to a production stable Debian 12 environment. Everything is functioning well for the most part.

I am unsure if I am using Nagios properly when we configure monitoring of our switches/routers we don't want to monitor EVERY interface however we would like the ability to toggle on/off monitoring of individual interfaces. In using the Web GUI wizard we were instructed (Nagios Support) that we should bring in all the interfaces and just disable the ones we don't want to use and we can re-enable them later should we need them monitored.

This has caused our services list to grow quite large we have 3500+ disabled services and now the configuration manager lags out when I open the page and list all services. This is not in of itself exactly a huge issue (yet) and we may just end up deleting some services we don't use (I think this is due to disabled services living inside DB and not as written configs on the server).

The issue I am presently running into is when I add a new switch/network device and bring in all the interfaces as before when I go to disable them it states they are disabled but it won't apply the configuration.

So in the CCM GUI manager when I am looking at the host it shows "Active No" and status "Not applied".

I have tried deleting, re-adding the host, re-running apply config.. making an innocuous change. I am wondering if I have introduced a SQL permissions issue when importing the database from the old server but I am not thinking so. The migration of DB to bring over the disabled services was:

old host:

mysqldump --add-drop-database -u root -pTHATPASSWD nagiosql >/tmp/nagiosql.sql

new host:

mysql -u root -pTHATPASSWD nagiosql < /tmp/nagiosql.sql

We could be going about this entirely the wrong way should we just be deleting and re-adding hosts with the wizard and only enabling ports we want monitored? I could not figure out a clean way within the GUI to re-scan a host environment and add/remove ports from the monitoring configuration.

I appreciate any insight or guidance anyone may be able to provide.

-Jordan

[lgute]

Hi @smithjor,

Thanks for reaching out. Generally, each time a wizard is run on a host, it overwrites the previous setting, so I would expect it to remove deselected service checks. Is this the Network Switch / Router wizard?

[smithjor]

Laura,

Thanks for the response. Yes I have been using the Network Switch / Router wizard and adding EVERYTHING then just disabling/deactivating what we are not presently using.

Does anyone have any idea what could be causing ones not to apply the disabled trait anymore like I am experiencing? I have not yet done deep log diving. With the lag I am experiencing inside CCM in the web GUI I am thinking perhaps database resource issues are approaching being reached but I am not certain.

I still need to do some of the initial nagios recommended tuning such as the ram disk and rrdcache setup.

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

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

Perhaps these will alleviate some of our issues. I am very much hoping NOT to have to create a dedicated MySQL instance or multiple nagios nodes working in tandem at the end of the day our infrastructure and needs are not very large or complex (25-35 network devices, 5-10 vsphere parents, 40 or so vsphere VMs and I would guess we will want 5-15 external websites with transaction monitoring).

[sgardil]

Hey Jordan, sorry your running into an issue.

In the first post you mentioned that applying config was not working when attempting to disable some of the services for your switch. Do you happen to know if applying config has always failed after this point? i.e adding anything new or making any other modification also fails to apply the config? If so it could be worth running the database repair script to see if it fixes your issue.

You mentioned possibly reaching the database limit as well which would cause issues as well with your system if you have no space left on the system. I'll attach some documentation for repairing your database if you want to attempt that route. Just make sure to take a snapshot of your system before making modifications just to be safe. Let us know if this helps.

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

-Sandor

[smithjor]

Sandor,

I actually had run the repair script directly after migration I just neglected to mention it. Disk space is OK. I am unable to determine if the issue was present in our Debian environment "before or after" migration as during the migration process we stopped all importing/creation of new services.

I will try and do some error log tailing on the system when performing the action and see if Nagios gives me any info. I do appreciate the responses thus far however! I will be sure to post anything I glean should it seem relevant.

-J

[sgardil]

Sandor,

I actually had run the repair script directly after migration I just neglected to mention it. Disk space is OK. I am unable to determine if the issue was present in our Debian environment "before or after" migration as during the migration process we stopped all importing/creation of new services.

I will try and do some error log tailing on the system when performing the action and see if Nagios gives me any info. I do appreciate the responses thus far however! I will be sure to post anything I glean should it seem relevant.

-J

Ah got it, well we are glad to help. Do you have snap shots and possible a testing environment that you could see if the issue was present prior to the migration? If so that could be worth a shot to see if the an issue happened during the migration. Sounds good on the relevant information, just make sure since this is a public forum to not share anything sensitive to your systems.

[smithjor]

Just wanted to update on the issue we are soon to be cloning our environment and then we will delete all disabled services and use that going forward as our prod environment. We will keep this other server as our test environment. I will be performing more troubleshooting and testing on the issue eventually but I am divided in focus between projects at the moment.

If I learn more about the issue or a resolution I will certainly update this post.

-Jordan

[smithjor]

We cloned the server, deleted all the old disabled services. I tried adding in a new service and tried to disable it but it will not apply that change.

Is there a specific log I should perhaps be checking/tailing when performing the action to see if we can glean why the system is not working properly?

[smithjor]

I am starting to suspect some sort of permissions issue perhaps.. It seems there are some permissions correction scripts however in my research it appears these could cause issues with my system as it is Debian12 and not Cent OS/RHEL due to the fact different user accounts are used for the apache service (www-data on debian vs apache on RHEL like).

I am going to do some testing, log tailing and dry runs and will report back. I did make a backup and a VM snapshot so I SHOULD be able to recover the system should anything go awry

these are the scripts I am looking at (provided by nagios):
/usr/local/nagiosxi/scripts/reset_config_perms.sh

/usr/local/nagiosxi/scripts/repair_nagiosxi.sh

I feel like the only other thing it could be is a possible SQL account issue... I will keep poking.

[jsimon]

Hi @smithjor,

It looks like this is a configuration issue that we have with Debian 12 systems specifically. The issue is a missing timezone value in the php.ini file. You should be able to fix this on your server by editing this file:

Code: Select all

/etc/php/8.2/cli/php.ini

Uncomment the "date.timezone" line and add your timezone. Note that it needs to be a full IANA timezone identifier, like "America/Chicago", for example. After you save your update to this file, you'll need to restart apache:

Code: Select all

systemctl restart apache2

Let us know if you still have this issue after applying this change. We're looking into modifying our install/upgrade process for Debian 12 to fix this issue going forward.