Version-Release number of selected component (if applicable): nagios-4.3.2-5.el6.x86_64 How reproducible: always Additional info: 1. /etc/nagios/objects/localhost.cfg is intended as an example. It doesn't belong there: having it in /etc/nagios/objects/ triggers (possibly unnecessary) monitoring of localhost, editing it triggers creation of .rpmnew, etc. 2. /etc/nagios/objects/contacts.cfg defines one contact: nagiosadmin with ``` email nagios@localhost ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ****** ``` -- as above, editing it in place creates rpm update conflict. Since nagios does not seem to allow overriding existing definitions, I can't leave those files alone and override localhost and nagiosadmin in /etc/nagios/conf.d/
Thanks. I will look at removing in update.
There's more to it I'm afraid: the default in /etc/nagios/nagios.cfg is process_performance_data=0 If I try to override it in /etc/nagios/conf.d/10_main.cfg I get ``` Reading configuration data... Read main config file okay... Error: Unexpected token or statement in file '/etc/nagios/conf.d/10_main.cfg' on line 4. Error: Invalid max_check_attempts value for host ... ``` If I edit in in the main config file, it works. So it looks like nagios config parsing can't quite deal with conf.d (The other thing that doesn't work is having a cfg_dir=blah in a file included with cfg_dir -- i.e. we had "cfg_dir=/etc/nagios/host" in nagios.cfg, once I moved that to conf.d/10_main.cfg, it dumped a similar error trace.) :(
The second part sounds like something to open up upstream. I am not sure I can fix that easily.
No, I think at this point nagios just doesn't support conf.d/ scheme: it only works if all user-configurable settings go in conf.d, and/or if settings in conf.d override the settings in main config. Nether seems to be the case here. Unless you can convince the upstream to rewrite their config parsing stuff so that files in conf.d are processed after nagios.conf and override existing settings, I just don't see this working. :(
OK I am trying to see where this came in and it looks like it was added first in 2008 and then re-added in Apr 24 2013. Since this is something we (Fedora) did versus upstream.. I apologize for sending you upstream. I will just remove this from our side.
No worries. I'd love to have a working conf.d/ for this, this particular upgrade is a perfect example of why (I'm still picking up the pieces), it may be worth sending them a feature request.
OK to 'fix' this would require a rewrite of the configs as shipped from upstream as the files are used with the default are written to assume there is a localhost.config. This gets pulled in from shipping a nagios.cfg which upstream maintains which cascades down. I am going to comment out the nagios email address as the system can work with minimal work with out, but otherwise I need to come up with a complete working out of the box "config" set so that nagios will start up. This will likely require a minimal.cfg which defines a service, a host and a contact Checking objects... Error: There are no services defined! Checked 0 services. Error: There are no hosts defined! Checked 0 hosts. Checked 0 host groups. Checked 0 service groups. Error: There are no contacts defined! Checked 0 contacts. Checked 0 contact groups. Checked 0 commands. Checked 0 time periods. Checked 0 host escalations. Checked 0 service escalations. Checking for circular paths... Checked 0 hosts Checked 0 service dependencies Checked 0 host dependencies Checked 0 timeperiods Checking global event handlers... Checking obsessive compulsive processor commands... Checking misc settings...
Stephen, is it just me and if not, do you want this as a separate bug: my commands.cfg.rpmnew has ``` command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s ... ``` whereas ``` # which mail /bin/mail # ls -l /usr/bin/mail ls: cannot access /usr/bin/mail: No such file or directory ``` This is on centos 6.
nagios-4.3.4-13.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-41e9ecf98a
nagios-4.3.4-13.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-41e9ecf98a
nagios-4.4.2-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0346a55d0f
nagios-4.4.2-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0346a55d0f
nagios-4.4.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d661b588d2
nagios-4.4.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d661b588d2
nagios-4.4.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.