Config files not being deleted

[XenoPhage]

I think I've discovered a bug in 2012R1.6 ... I just removed a bunch of hosts and services from our Nagios install. After removing everything, I applied the configuration. Nagios reported a failure and I opened up the log to see what the problem was.

Turns out, the config files for the hosts I removed were still present. I had to manually delete the config files on the server and then apply the configuration again for the changes to take effect.

So have I run into a bug, or did I do something wrong?

[BanditBBS]

I have seen the same behavior. I easily fixed like you did and never filed a bug report. Didn't have time to test and make sure it was a bug.

[slansing]

Thank you for giving us a heads up on this, is it a recurring problem for you? How many Hosts/Services were you deleting at once? Also, can you post your system profile from the Admin section of the XI interface?

[XenoPhage]

I believe I deleted about a dozen hosts. This might be the first time I've deleted something from nagiosxi, not entirely sure.

Profile is as follows :

System:
Nagios XI Version : 2012R1.6
horcrux2.lafayette.edu 2.6.32-279.19.1.el6.x86_64 x86_64
Red Hat Enterprise Linux Server release 6.4 (Santiago)
Gnome is not installed
Apache Information
PHP Version: 5.3.3
Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Server Name: x.x.x
Server Address: x.x.x.x
Server Port: 443
Date/Time
PHP Timezone: America/New_York
PHP Time: Fri, 29 Mar 2013 16:03:15 -0400
System Time: Fri, 29 Mar 2013 16:03:15 -0400
Nagios XI Data
nagios (pid 2348) is running...
NPCD running (pid 5322).
ndo2db (pid 5409) is running...
CPU Load 15: 1.31
Total Hosts: 1079
Total Services: 3265
Function 'get_base_uri' returns: https://x.x.x/nagiosxi/
Function 'get_base_url' returns: https://x.x.x/nagiosxi/
Function 'get_backend_url(internal_call=false)' returns: https://x.x.x/nagiosxi/includes/compone ... rofile.php
Function 'get_backend_url(internal_call=true)' returns: https://localhost/nagiosxi/backend/
Ping Test localhost
Running:

/bin/ping -c 3 localhost 2>&1

PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.033 ms

--- localhost.localdomain ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.032/0.036/0.044/0.007 ms
Test wget To locahost
WGET From URL: https://localhost/nagiosql/index.php
Running:

/usr/bin/wget https://localhost/nagiosql/index.php

--2013-03-29 16:03:17-- https://localhost/nagiosql/index.php
Resolving localhost... ::1, 127.0.0.1
Connecting to localhost|::1|:443... connected.
ERROR: cannot verify localhost's certificate, issued by `CA':
Unable to locally verify the issuer's authority.
ERROR: certificate common name `x.x.x' doesn't match requested host name `localhost'.
To connect to localhost insecurely, use `--no-check-certificate'.

[scottwilkerson]

It may be hard to determine now, but if this happens again lets look at the permissions on the files that didn't delete.

Also, lets make sure that apache is still a member of the nagios group

Code: Select all

cat /etc/group|grep apache

[XenoPhage]

It may be hard to determine now, but if this happens again lets look at the permissions on the files that didn't delete.

I can't speak to the files that were deleted, but the rest of the files are owned by apache, group nagios. I will say that I have not hand-edited or hand-created any files here, so I would expect that those files were set the same way.

Also, lets make sure that apache is still a member of the nagios group

Code: Select all

cat /etc/group|grep apache

Code: Select all

apache:x:48:
nagios:x:1000:nagios,apache
nagcmd:x:1001:nagios,apache,snmptt

[abrist]

Those permissions are correct. If you see this behavior again let us know. If you can give us the steps to reproduce the issue, even better.