Nagvis automatic authentication problems

[lmiltchev]

Results below. I have updated Nagvis. I went from the included 1.5 version to to version 1.8.5

The procedure described above works with NagVis 1.5.9, the version included in XI. Other versions of NagVis are not supported and there is no guarantee that the same method will work in version 1.8.5.

[Atria]

So are you saying you are unable to assist me with this? I tried to get to the NagVis forum to ask a question but I'm unable to register an account.

[tmcdonald]

If I had to give an official answer, it would be something like:

NagVis is not a Nagios product, so we cannot guarantee any functionality. We will do what we can to support the versions that ship with our software, but we have not necessarily tested any other versions. Any bugs that do appear, or any features that are not present, will need to be addressed by the NagVis developers.

So the unfortunate answer is that there is not a ton we can do with this upgraded version. We have to be somewhat firm with what degree of support we provide for third-party software, especially when we venture into untested waters. Was there a specific reason you upgraded?

[Atria]

Actually I was unable to access the general configuration menu in Nagvis.

[lmiltchev]

The way you access the general configuration menu in NagVis is by clicking on "WUI" under the "Open" menu first:

example01.PNG

then, clicking on the "General Configuration" under "Options" menu:

example02.PNG

example03.PNG

Hope this helps.

[Atria]

That's the thing, I would get an error if I tried to access that menu. I opened a post here and someone asked what version I had. When I looked I saw I was on 1.5 and updated to 1.8.5 which eliminates the WUI. I was able to see in the journal after trying to execute with the rewritelock command

Code: Select all

-- Subject: Unit httpd.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit httpd.service has begun starting up.
Nov 09 13:36:59 monitoring.atriacom.com httpd[17567]: AH00526: Syntax error on line 58 of /etc/httpd/conf.d/nagvis.conf:
Nov 09 13:36:59 monitoring.atriacom.com httpd[17567]: Invalid command 'RewriteLock', perhaps misspelled or defined by a module not i
Nov 09 13:36:59 monitoring.atriacom.com systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Nov 09 13:36:59 monitoring.atriacom.com kill[17571]: kill: cannot find process ""
Nov 09 13:36:59 monitoring.atriacom.com systemd[1]: httpd.service: control process exited, code=exited status=1
Nov 09 13:36:59 monitoring.atriacom.com systemd[1]: Failed to start The Apache HTTP Server.
-- Subject: Unit httpd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit httpd.service has failed.
-- 
-- The result is failed.

[lmiltchev]

Can you run the following command and show us the output?

Code: Select all

php --version

Thanks!

[lmiltchev]

Actually, I believe the issue is not in the php version but the apache version... Are you runing apache 2.4?

Code: Select all

httpd -v

Directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath have been replaced with a single Mutex directive. You will need to evaluate any use of these removed directives in your 2.2 configuration to determine if they can just be deleted or will need to be replaced using Mutex.

https://httpd.apache.org/docs/2.4/upgrading.html

I found this article, which has some info on using Mutex instead of RewriteLock.

[Atria]

results from an httpd -V

Code: Select all

Server version: Apache/2.4.6 (CentOS)
Server built:   Aug 24 2015 18:11:25
Server's Module Magic Number: 20120211:24
Server loaded:  APR 1.4.8, APR-UTIL 1.5.2
Compiled using: APR 1.4.8, APR-UTIL 1.5.2
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/run/httpd/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

results from a php -v

Code: Select all

PHP 5.4.16 (cli) (built: Jun 23 2015 21:17:27) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

[lmiltchev]

OK, you can try the following "workaround".

1. Add the following line (if it is not already there) in the "/etc/httpd/conf/httpd.conf" file:

Code: Select all

Mutex default

2. Make the following changes in the "/etc/httpd/conf.d/nagvis.conf":

Comment out the following two lines:

Code: Select all

#  Order allow,deny
#  Allow from all

and add this line below them:

Code: Select all

Require all granted

Comment out the lines below, so that they look like this:

Code: Select all

#  AuthName "NagVis Access"
#  AuthType Basic
#  AuthUserFile /usr/local/nagiosxi/etc/htpasswd.users
#  Require valid-user

On the bottom of the file (below the "</Directory>" line), add:

Code: Select all

Mutex file:/var/log default
RewriteRule     /nagvis/ - [E=REMOTE_USER:nagiosadmin]

3. Comment out the following line in the "/usr/local/nagvis/etc/nagvis.ini.php" file, so it is going to look like this:

Code: Select all

;logonenvvar="PHP_AUTH_USER"

4. Restart apache:

Code: Select all

service httpd restart

Word of caution: This is just a "workaround". I am not sure if it is the best/proper way to do it. Apache is not my forte.
FYI, an upgraded NagVis with automatic login (not using rewrites) is in the works, so this should not be an issue in the future releases of XI.