Opsview Knowledge Center


How to customise Opsview Monitor

Single Sign On (SSO) Authentication

Opsview Monitor can use LDAP and Active Directory for Single Sign On (SSO) functionality.

For information around configuration, testing, troubleshooting and more - see Section LDAP / Active Directory

Theme/White Labelling

Opsview Monitor can be themed by updating the /usr/local/nagios/share/stylesheets/custom.css file. This file is retained across upgrades, so it will not be overwritten.

The following items can be updated/modified:

  • Login page logo
  • Header logo
  • Navigation button colours
  • Login button colour
  • Background colour

An example of a customised theme is here:

/* Navigation bar and login background color */
.main_navigation .x-btn-default-toolbar-small,
.usermenudropdown .x-menu-body,
.hostgroups_hostsummary .x-panel-header-default
{ background: #243a72!important; }
/* Navigation buttons */
.searchtop .x-btn-glyph,
.menumain .x-btn-glyph,
.usermenu .x-btn-glyph,
.usermenu .x-btn-inner,
.usermenudropdown .x-menu-item-text,
.usermenudropdown .x-menu-item-glyph
{ color: white!important; }
/* Login button */
div.login-box button
{ background: #80ba01; }
/* Login logo */
{ width: 276px; height: 110px; background-image: url('../images/my_image_name.png'); margin: 2em auto; }
/* Navigation logo */
{ width: 204px; height: 25px; background-image: url('../images/my_image_name.png'); background-size: 100%; }

Login and Banner images should be placed in /usr/local/nagios/share/images.

To change the logos, upload your login and navigation logos to:

  • Login page logo: /usr/local/nagios/share/images/my_image_name.png - width: 276 x height: 110.
  • Navigation logo: /usr/local/nagios/share/images/my_image_name.png - width: 204 x height: 25.

The image sizes will rescale if they are not exact.

Note: You may need to clear the browser cache for the image to be seen.


Using modified images and the above CSS file, we can have a system that looks like:

Login page

Hashtags page


If you are upgrading to Opsview Monitor 5.x, you will be prompted to either override your custom.css file or keep the existing one. If you wish to keep a copy of your custom.css file, please make a copy using the command:

cp /usr/local/nagios/share/stylesheets/custom.css /usr/local/nagios/share/stylesheets/custom.css.bak

Once backed up, you will need to press 'Y' to update the file, as below:

Configuration file '/usr/local/nagios/share/stylesheets/custom.css'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** custom.css (Y/I/N/O/D/Z) [default=N] ? Y

If you do not update the file, your old custom.css may cause problems with how the User Interface is rendered.

Apache SSL Config

As part of Opsview's configuration, Apache can be configured to use an SSL certificate. If you are planning to use a self signed certificate there are numerous guides available to follow and create a self signed certificate e.g. http://www.akadia.com/services/ssh_test_certificate.html or https://letsencrypt.org.

In order to set up Apache to use SSL, the following steps are required. Before starting, we recommend that you have your SSL certificate and Server key available:

  1. Change the /usr/local/opsview-web/etc/apache_proxy_ssl.conf and add the path to where the certificates are stored on your server. By default we recommend that you store the server.crt and server.key file in the directory mentioned in the path.By default the SSL certificates are stored at the location specified in /usr/local/opsview-web/etc/apache_proxy_ssl.conf


SSLCertificateFile /usr/local/opsview-web/etc/ssl/server.crt
SSLCertificateKeyFile /usr/local/opsview-web/etc/ssl/server.key
  1. The /etc/apache2/sites-available/opsview.conf file contents should be as mentioned below. You will require sudo access to finish this task. The /etc/apache2/sites-available/opsview.conf file contents should be as mentioned below.


<VirtualHost *:443>
Include /usr/local/opsview-web/etc/apache_proxy_ssl.conf

You will require sudo access to finish this task. This file may be located at different places depending on the OS; some common directory paths are mentioned below:

Debian/Ubuntu: /etc/apache2/sites-available/opsview.conf or /etc/apache2/sites-available/opsview depending on the version of Apache you are using (2.4 or 2.2).

Centos/Redhat: /etc/httpd/conf.d/opsview.conf

  1. For debian/ubuntu make sure mod_ssl is enabled by issuing the command a2enmod ssl as it is not enabled by default.

  2. For RPMs make sure the mod_ssl package is installed as it is not installed by default.

  3. For Centos7 make sure that if there is a file called ssl.conf.disabled in the /etc/httpd/conf.d directory, it is renamed as ssl.conf. If it is not, the GUI will not be accessible

  4. Restart apache and open the Opsview Monitor GUI in a browser with "https://" at the start of the URL.

Notes: /usr/local/opsview-web/etc/apache_proxy_ssl.conf is overwritten on upgrades.


It is possible to rehome the Opsview Web application on the master so that Opsview is anchored to a different location, rather than anchored to the root level, for example, to use 'http://server/myopsview' rather than 'https://server/'.

As the nagios user, create the Opsview Web configuration file "/usr/local/opsview-web/opsview_web_local.yml" if it doesn't exist

Add the lines:

override_base_prefix: /myopsview
start_url: /myopsview/monitoring

Note: Initial spaces are important - compare with opsview_web.yml if necesasry

Restart opsview-web as the 'nagios':

$ opsview_watchdog opsview-web restart

If you are using Apache's proxy configuration, you will need to change the following lines from the file /usr/local/opsview-web/etc/apache_proxy.conf:

--- apache_proxy.conf    2016-05-04 16:06:12.545434797 +0000
+++ apache_proxy.conf.rehomed    2016-05-04 16:08:25.052361825 +0000
@@ -28,7 +28,7 @@
 #AddOutputFilterByType DEFLATE application/x+javascript

 # Any files in here will be served by Apache
-DocumentRoot /usr/local/nagios/share
+Alias /myopsview /usr/local/nagios/share
 <Directory /usr/local/nagios/share>
     Require all granted
@@ -39,16 +39,16 @@

 # Don't proxy error pages as these are served statically
-ProxyPass /error_pages !
-ProxyPass /javascript !
-ProxyPass /stylesheets !
-ProxyPass /help !
-ProxyPass /images !
-ProxyPass /xml !
-ProxyPass /favicon.ico !
-ProxyPass /graphs !
-ProxyPass /static !
-ProxyPass /media !
+ProxyPass /myopsview/error_pages !
+ProxyPass /myopsview/javascript !
+ProxyPass /myopsview/stylesheets !
+ProxyPass /myopsview/help !
+ProxyPass /myopsview/images !
+ProxyPass /myopsview/xml !
+ProxyPass /myopsview/favicon.ico !
+ProxyPass /myopsview/graphs !
+ProxyPass /myopsview/static !
+ProxyPass /myopsview/media !

 # Development files
 ProxyPass /discovery/workspace !
@@ -116,8 +116,8 @@
 ErrorDocument 505 /error_pages/handle_error.cgi?error=505

 # Remove retry=5 for apache < 2.2 as not available in older versions
-ProxyPass / retry=5
-ProxyPassReverse /
+ProxyPass /myopsview retry=5
+ProxyPassReverse /myopsview
 #ProxyPreserveHost On
 # We need to set the two entries below to disable keepalive between Apache and Opsview Web
 # This manifests itself as an HTTP request with a 0 response. Seen during performance testing

Restart Apache (this is OS specific).

You may get some errors about overlapping Aliases - in this case, move the ''Alias /myopsview /usr/local/nagios/share'' to the bottom of the configuration.

Opsview web will now be served off /myopsview.

Authentication using Client SSL Certificates

Opsview can be configured to authenticate users with an SSL Client Certificate instead of or in addition to an AuthTKT cookie, LDAP or the in-built authentication routine. Note that each user must still exist in the Opsview system, with a username matching that in the SSL Client Certificate Common Name field.

Apache Configuration

The first step is to set up Apache for SSL; see 3.9..3. Apache SSL Config. After this is complete and working, you then need to set up Client Certificate authentication. The process of certification creation is outside the scope of this document, but there are many examples on-line to help.

Once this is done, you must add some additional configuration so that the Opsview application is able to see the Username of the authenticated user. The following directives should be added to the Opsview SSL configuration file for Apache, and then Apache should be restarted:

# NOTE: the following line must be amended to this value from the default
SSLVerifyClient optional 
SSLOptions StdEnvVars

# Headers must added to the proxy request to Opsview, as Opsview cannot see 
# the external user certificate nor the Apache environment. Make sure to 
# munset headers first to avoid abuse.
RequestHeader unset X-REMOTE_USER
RequestHeader unset X-SSL_CLIENT_S_DN_CN

When Apache authenticates a user itself, it sets the ''REMOTE_USER'' environment variable. However the Opsview application cannot see the server environment, so the above configuration copies that variable into an HTTP Request Header which Opsview can see. Note that first the Request Header is erased (unset), to prevent remote clients from forging the authenticated username.

Opsview Configuration

The next step is to configure a new authentication realm for Opsview which uses the Apache authenticated username. This is similar to setting up an authentication realm for LDAP.

You need to edit ''/usr/local/opsview-web/opsview_web_local.yml'' on your Opsview master server to include the following, and then restart the ''opsview-web'' service:

        class: 'Upstream::Headers'
        user_header: 'X-REMOTE_USER'

Users Configuration in Opsview

For each user in the Opsview application that you wish to use this feature, the user Realm configuration must be changed.

Go to "Settings =>Contacts", then select the user. Change the Authentication Realm to be certificate.

You will notice that on the Opsview login page, when a client visits with a trusted SSL Certificate, the username field will automatically be filled-in. If the user is configured with the "''certificate''" realm, then they can immediately click the "Sign in" button (without a password). If the user is not configured with this authentication realm, then they must still enter a password.

Authentication Fallback

If you'd like users to have the choice of either using Client SSL Certificate, or traditional Password, this is also possible.

You should configure at least two Authentication Realms. One will be for normal password authentication, and the other is the certificate entry shown above. To these we add a third realm to configure the fallback list.

For example, the ''/usr/local/opsview-web/opsview_web_local.yml'' file on your Opsview master server could look like this:

authentication:<br>  realms:
        class: 'Upstream::Headers'<br>        user_header: 'X-REMOTE_USER'
        class: Password
        password_field: password
        password_type: self_check
        class: LDAP
      # etc...
          class: Fallback
          realms: ['certificate', 'ldap']

For the example above, if the user's browser has access to a compatible Client SSL Certificate then they can use it, or else enter a normal Password.

To enable this feature for a user, go to Settings, Contacts, then select the user. Change the Authentication Realm to be "''fallback''".

More realms can be configured and added to the realms list. Opsview will try each entry in turn until either one succeeds for authenticaiton, or all fail.