The CCM writes all the files out every time is is ran directly from the database. If you've removed every file from the hosts folder and re-ran the apply config and the file that is causing problems still exists then it has to be in the database (or being added to the database before or during the apply config) and being written out when trying to apply configuration.
Not 100% certain it would be in the tbl_host table only. If a service or multiple services were supposed to be using that hostname as the config it may be generating it somehow that way also.
You would not see it in your hosts folder after you tried to apply the config because it reverts all of your configuration files back to the last known good working set (not the database though) so the host that is causing a problem wouldn't show up in your hosts directory.
Do you happen to have anything in the import directory? /usr/local/nagios/etc/import
Config change inconsistency - possible ghost object
Re: Config change inconsistency - possible ghost object
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: Config change inconsistency - possible ghost object
Here is all the info I have about this object. I cannot see it in either the import, hosts or services folders:
In addition to not finding it in the tbl_host above, I took the liberty to find it in the service table and it is not there:
I finally grep-ed for in-uits-sf2 in all of "/usr/local/". I have only found it in log files in "/usr/local/nagios/var/archives/" and then the error seems to come up in a folder called "/usr/local/nagiosxi/nom/checkpoints/nagioscore/errors/":
Hope that helps. I cannot use the web front end to apply configurations. I can use the reconfigure script from the shell with no problem, but have to remove the lock file if the gui is run first.
Code: Select all
[root@esnagxitst01 scripts]# ls -a /usr/local/nagios/etc/import/
. ..
[root@esnagxitst01 scripts]# ls -a /usr/local/nagios/etc/hosts/
. estrain05.uits.iu.edu.cfg iu-uits-sacaz.ads.iu.edu.cfg
.. iu-uits-jt1.ads.iu.edu.cfg iu-uits-sacrr1.ads.iu.edu.cfg
estrain01.uits.iu.edu.cfg iu-uits-jt2.ads.iu.edu.cfg iu-uits-sacrr2.ads.iu.edu.cfg
estrain02.uits.iu.edu.cfg iu-uits-jt3.ads.iu.edu.cfg iu-uits-wjp1.ads.iu.edu.cfg
estrain03.uits.iu.edu.cfg iu-uits-jt4.ads.iu.edu.cfg iu-uits-wjp2.ads.iu.edu.cfg
estrain04.uits.iu.edu.cfg iu-uits-jt5.ads.iu.edu.cfg localhost.cfg
[root@esnagxitst01 scripts]# ls -a /usr/local/nagios/etc/services/|grep sf2
[root@esnagxitst01 scripts]#
Code: Select all
[root@esnagxitst01 scripts]# echo 'Select * FROM tbl_service;' |mysql -u root -pnagiosxi nagiosql >/tmp/services.txt
[root@esnagxitst01 scripts]# grep in-uits-sf2 /tmp/services.txt
[root@esnagxitst01 scripts]#
Code: Select all
./nagiosxi/nom/checkpoints/nagioscore/errors/1442521153.txt:Error: Invalid max_check_attempts value for host 'in-uits-sf2.ads.iu.edu'
./nagiosxi/nom/checkpoints/nagioscore/errors/1442521153.txt:Error: Could not register host (config file '/usr/local/nagios/etc/hosts/in-uits-sf2.ads.iu.edu.cfg', starting on line 16)
Re: Config change inconsistency - possible ghost object
What user are you running the reconfigure script as from shell?Pres-Gas wrote: I cannot use the web front end to apply configurations. I can use the reconfigure script from the shell with no problem, but have to remove the lock file if the gui is run first.
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
Re: Config change inconsistency - possible ghost object
The user is root when I use the shell script. What user does the gui apply run as?
Re: Config change inconsistency - possible ghost object
Pretty darn sure it is apache. Try as that user and see if it works or not. If not, I'd say it is a sudoers file issue.Pres-Gas wrote:The user is root when I use the shell script. What user does the gui apply run as?
Here is what should be in the sudoers file:
Code: Select all
User_Alias NAGIOSXI=nagios
User_Alias NAGIOSXIWEB=apache
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios start
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios stop
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios restart
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios reload
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios status
NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios checkconfig
NAGIOSXI ALL = NOPASSWD:/etc/init.d/ndo2db start
NAGIOSXI ALL = NOPASSWD:/etc/init.d/ndo2db stop
NAGIOSXI ALL = NOPASSWD:/etc/init.d/ndo2db restart
NAGIOSXI ALL = NOPASSWD:/etc/init.d/ndo2db reload
NAGIOSXI ALL = NOPASSWD:/etc/init.d/ndo2db status
NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd start
NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd stop
NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd restart
NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd reload
NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd status
NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/html/includes/components/autodiscovery/scripts/autodiscover_new.php *
NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/upgrade_to_latest.sh
NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/change_timezone.sh
NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh *
NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/reset_config_perms.sh
NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/messages
NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/httpd/error_log
NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/mysqld.log
NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/html/includes/components/autodiscovery/scripts/autodiscover_new.php *
NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
NAGIOSXIWEB ALL = NOPASSWD:/etc/init.d/snmptt restart
NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/scripts/repair_databases.sh
NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh *2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
Re: Config change inconsistency - possible ghost object
Thanks!
We have a centrally managed sudoers file that I had to edit to accommodate for the initial install. However, if there were any changes to the nagiosxi.sudoers they would get changed back. I will have to compare what we already have and make the appropriate changes. I will update here.
Why would a sudoers issue give the screenshot error I do see with a ghost object?
We have a centrally managed sudoers file that I had to edit to accommodate for the initial install. However, if there were any changes to the nagiosxi.sudoers they would get changed back. I will have to compare what we already have and make the appropriate changes. I will update here.
Why would a sudoers issue give the screenshot error I do see with a ghost object?
Re: Config change inconsistency - possible ghost object
No clue and no idea if this is your issue, but since it works as root from commandline, its something that needs checkedPres-Gas wrote:Why would a sudoers issue give the screenshot error I do see with a ghost object?
2 of XI5.6.14 Prod/DR/DEV - Nagios LogServer 2 Nodes
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
See my projects on the Exchange at BanditBBS - Also check out my Nagios stuff on my personal page at Bandit's Home and at github
Re: Config change inconsistency - possible ghost object
I've seen sudoers issues cause problems just like this, also check to make sure you don't have an /etc/sudoers.d/nagiosxi file.
Re: Config change inconsistency - possible ghost object
I wanted to confirm that merging our centrally managed sudoers file fixed this issue. This could be closed.
I wish there would be a way to make it error out in a better way. There was NO indication anywhere that object existed.
Thanks!
I wish there would be a way to make it error out in a better way. There was NO indication anywhere that object existed.
Thanks!