No web UI after upgrade 1.3 => 1.4

[weveland]

So I just ran the upgrade against my Nagios Log Server v1.3 following the upgrade instructions herehttps://assets.nagios.com/downloads/nag ... Server.pdf.

However after starting up the server all I get when I try to go to https://nagiosls.mydomain.local/nagioslogserver is a 404 error stating "The requested URL /nagioslogserver/login was not found on this server."

Any ideas? This is kinda a production down thing, but still within my maintenance window.

[jolson]

Check on the apache configs and ensure that they were update appropriately:

Code: Select all

[root@localhost nagioslogserver]# cat /etc/httpd/conf.d/nagioslogserver.conf
Alias /nagioslogserver "/var/www/html/nagioslogserver/www/"

<Directory "/var/www/html/nagioslogserver/www/">
#  SSLRequireSSL
   Options FollowSymLinks
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

RewriteEngine on
RewriteCond $1 !^(index\.php|scripts|media|app|js|css|img|font|vendor|config.js)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule nagioslogserver/(.*)$ /var/www/html/nagioslogserver/www/index.php/$1 [L,QSA]

If you have SSL enabled, follow this document (especially the redirect steps at the bottom).
https://assets.nagios.com/downloads/nag ... Server.pdf

Let me know if you're still having problems after the above. Thanks!

[weveland]

They are indeed the same.

353abd821b0f3310090ab0946f554e87 nagioslogserver.conf.test
353abd821b0f3310090ab0946f554e87 /etc/httpd/conf.d/nagioslogserver.conf

However my ssl.conf file was totally changed.

Putting the redirect back in place for the default VirtualHost and putting a link back to my cert and key worked to get it back up.

Any idea why ssl.conf got wiped?

Wayne

[weveland]

This is what was received via stdout when upgrading.



[root@nagiosls nagioslogserver]# ./upgrade
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
* base: bay.uchicago.edu
* extras: centos.mirrors.tds.net
* updates: centos.host-engine.com
base | 3.7 kB 00:00
extras | 3.4 kB 00:00
updates | 3.4 kB 00:00
updates/primary_db | 3.3 MB 00:00
Package pyOpenSSL-0.13.1-2.el6.x86_64 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 0:1.0.1e-42.el6 will be updated
---> Package openssl.x86_64 0:1.0.1e-42.el6_7.2 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================================================================
Package Arch Version Repository Size
====================================================================================================================================================
Updating:
openssl x86_64 1.0.1e-42.el6_7.2 updates 1.5 M

Transaction Summary
====================================================================================================================================================
Upgrade 1 Package(s)

Total download size: 1.5 M
Downloading Packages:
openssl-1.0.1e-42.el6_7.2.x86_64.rpm | 1.5 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : openssl-1.0.1e-42.el6_7.2.x86_64 1/2
Cleanup : openssl-1.0.1e-42.el6.x86_64 2/2
Verifying : openssl-1.0.1e-42.el6_7.2.x86_64 1/2
Verifying : openssl-1.0.1e-42.el6.x86_64 2/2

Updated:
openssl.x86_64 0:1.0.1e-42.el6_7.2

Complete!
You are using pip version 7.1.0, however version 7.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting elasticsearch-curator==3.4.0
/usr/lib/python2.6/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/late ... ormwarning.
InsecurePlatformWarning
Downloading elasticsearch_curator-3.4.0-py2.py3-none-any.whl (43kB)
100% |████████████████████████████████| 45kB 3.2MB/s
Collecting click>=3.3 (from elasticsearch-curator==3.4.0)
Downloading click-6.2-py2.py3-none-any.whl (70kB)
100% |████████████████████████████████| 73kB 2.7MB/s
Collecting elasticsearch<2.1.0,>=1.8.0 (from elasticsearch-curator==3.4.0)
Downloading elasticsearch-2.0.0-py2.py3-none-any.whl (58kB)
100% |████████████████████████████████| 61kB 4.0MB/s
Collecting urllib3<2.0,>=1.8 (from elasticsearch<2.1.0,>=1.8.0->elasticsearch-curator==3.4.0)
Downloading urllib3-1.14-py2.py3-none-any.whl (89kB)
100% |████████████████████████████████| 90kB 2.4MB/s
Installing collected packages: click, urllib3, elasticsearch, elasticsearch-curator
Found existing installation: urllib3 1.10.4
Uninstalling urllib3-1.10.4:
Successfully uninstalled urllib3-1.10.4
Found existing installation: elasticsearch 1.6.0
Uninstalling elasticsearch-1.6.0:
Successfully uninstalled elasticsearch-1.6.0
Found existing installation: elasticsearch-curator 1.2.2
Uninstalling elasticsearch-curator-1.2.2:
Successfully uninstalled elasticsearch-curator-1.2.2
Successfully installed click-6.2 elasticsearch-2.0.0 elasticsearch-curator-3.4.0 urllib3-1.14
Archive: sourceguardian/ixed4.lin.x86-64.zip
inflating: /usr/lib64/php/modules/ixed.5.3.lin
Sourceguardian extension found for PHP version 5.3
Sourceguardian extension already in php.ini
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
Upgrading Kibana...
Kibana upgraded OK
Stopping elasticsearch: [ OK ]
Starting elasticsearch: [ OK ]

Nagios Log Server Upgrade Complete!

You can access the Nagios Log Server web interface by visiting:
http://192.168.100.8/nagioslogserver/

[root@nagiosls nagioslogserver]# curl -XPUT localhost:9200/_cluster/settings -d '
> {
> "transient" : {
> "cluster.routing.allocation.enable" : "all"
> }
> }'
{"acknowledged":true,"persistent":{},"transient":{"cluster":{"routing":{"allocation":{"enable":"all"}}}}}[root@nagiosls nagioslogserver]#
[root@nagiosls nagioslogserver]#

[weveland]

I've walked through all the upgrade scripts I could find. There wasn't anything I saw that would modify the ssl.conf file. The file is owned by the mod_ssl package and that wasn't updated either, just openssl and other related packages.

[jolson]

I also have no idea what may have caused this, the openssl update seems suspicious only because it has 'ssl' in the name - nothing should be touching the ssl.conf file.

I can confirm that this behavior is not present in my lab machine - I tested a 1.3 -> 1.4 upgrade with no issues.

Any luck chasing this down? If you have custom cronjobs/scripts running on the box, could you verify that they wouldn't randomly delete the ssl.conf file?

Jesse

[weveland]

Not so far. Closest I have is possibly certmonger, but that's just a guess at best. All our machines are tied to a FreeIPA domain controller. That also runs a certificate manager which is managed on the local clients by certmonger. This updates configurations and installs new certificates for services on domain systems. I don't have a running audit trail of that file so not much to go on here.

--
W

[ssax]

mod_ssl is the package that provides the /etc/httpd/conf.d/ssl.conf file, did your upgrade log show httpd being upgraded? If so, mod_ssl would be updated as well which may replace that, was there any ssl.conf.rpmsave or anything else in there?

[weveland]

Last install date for those two packages:
httpd-2.2.15-45.el6.centos.x86_64 Thu 06 Aug 2015 04:51:42 PM EDT
mod_ssl-2.2.15-45.el6.centos.x86_64 Thu 06 Aug 2015 04:51:42 PM EDT

Doesn't look like it was modified by a RPM package, so no rpmsave/rpmnew.


Honestly guys, don't spend too much time looking into this. I've got an old snapshot but I'd lose too much data to rollback. It's working, I've notated it for next time I upgrade. I went through your upgrade scripts and I couldn't find anything that would have changed that file. So I'm seriously at a loss, either I had done my redirect differently last time and I didn't notate it, or something changed it. But I've been accessing it via HTTPS since the beginning, so it was working.

--
W

[jolson]

I'll keep an eye out for similar cases moving forward - through all of our testing we've yet to see this happen - thanks for the information. May I close this case?