Customization

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 and Active Directory.

Theme and white labelling

Opsview Monitor can be themed by updating a custom.css file. This file is retained across upgrades, so it will not be overwritten. However, if there are major changes to Opsview web application, your settings may not work anymore.

The following items can be modified by the instructions below:

Login logo
Login button color
Login background color
Navigation color
Navigation menu logo

An example of a customised theme is here:

{
 /* Login logo */
.login-entry .opsview-logo {
  background-image: url('../images/logo-login.png') !important;
}

/* Login button */
div.login-box button {
  background: #243a72;
}

/* Login background color */
body {
  background: #243a72 !important;
}

/* Navigation color */
div.Navigation, div.Navigation-subCategories, div.u-backgroundColor--brand, div.u-backgroundColor--primary-tint {
  background: #243a72 !important;
}

/* Search Field Color */
.Search--input {
  background: #243a72 !important;
  border: 1px solid #fff !important;
}

/* Bottom Bar */
.ov-panel-purple .x-panel-header {
  background: #243a72!important;
}

/* Active Navbar Item */
.Navigation-categoriesItem.is-active {
  background-color: rgba(91, 107, 149, 0.4) !important;
}

/* User Dropdown */
.Dropdown-item--link {
  background-color: #243a72 !important;
}

/* Active User Dropdown */
.Dropdown-item--link:hover {
  background-color: #1b2b56 !important;
}

Note
You will need to be the root user to make changes to files or to add new images.

Update the file at /opt/opsview/webapp/docroot/static/stylesheets/custom.css with the contents above.

Your Login image should be placed into /opt/opsview/webapp/docroot/static/images/ as logo-login.png. Use a width of 256 pixels by height 120. You can double the dimensions if you want a higher resolution image to be displayed. Ensure the permissions are owner root, group opsview, mode 644.

Your Navigation menu logo should replace /opt/opsview/webapp/docroot/static/theme-opsview/resources/images/opsview/opsview-logo-default.png. Use a width of 56 pixels by height 80 (or double both dimensions for higher resolution).

Note
This file will be overwritten on an upgrade and you will need to apply again.

Examples

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

Login page

Hashtags page

Hashtags page

Hosts List Page

Hosts List

Managing host icons

Opsview Monitor ships with a number of host icons that can be used to help identity device types at a glance (if they are configured on the device on the Host edit page).

You can manage your own host icons by using the /opt/opsview/coreutils/bin/hosticon_admin script on the command line. The host icons themselves must be 40×40 and in PNG format. This script contains its own documentation which can be accessed using hosticon_admin -h.

Adding a host icon

In order to add an icon to Opsview which you have uploaded, use the following command:

hosticon_admin add 'LOGO - hosticon' /path/to/hosticon.png

where:

LOGO - hosticon is the name of the icon to be displayed within the Host edit page dropdown menu
/path/to/hosticon.png is the path to the icon to be uploaded.

Errors you may receive:

Ensure imagemagick (dpkg) or ImageMagick (yum) is installed:

Cannot find necessary binary - is "imagemagick" installed? at /opt/opsview/coreutils/bin/hosticon_admin line 208.

Ensure the command is run as the root user:

source doesnt exist - has it been converted? at /opt/opsview/coreutils/bin/hosticon_admin line 211.

Removing an icon

Host icons are removed from the configuration but they are not removed from the filesystem.

Obtain the exact name of the icon by running the following:

hosticon_admin list

Then run the following:

hosticon_admin remove 'LOGO - hosticon'

Specifying Opsview addresses

Opsview protects itself from spurious HOST headers in the http requests it redirects to https. If users will be accessing the Opsview Web UI with a host that isn’t its hostname then the valid host addresses will need to be configured in user_vars.yml.

As the root user, update the /opt/opsview/deploy/etc/user_vars.yml file and add or amend the following parameter:

opsview_webserver_external_address: "myserver.company.com"

opsview_webserver_external_address:
  - "myserver.company.com"
  - "another.address.com"

Then run:

/opt/opsview/deploy/bin/opsview-deploy /opt/opsview/deploy/lib/playbooks/orchestrator-install.yml

This will make the necessary adjustments to opsview-webserver configuration and restart the service.

Re-homing

It is possible to rehome the Opsview Web application on the master so that Opsview is served at a different location, rather than served at the root level - for example, instead of https://server.example.com/, it can be https://server.example.com/myopsview.

Limitations:

Expects to only be 1 level deep (eg: /services/myopsview is not supported).
Opsview reporting module is not possible to rehome and will be served under /jasperserver.

As the root user, update the /opt/opsview/deploy/etc/user_vars.yml file and add or amend the following parameter:

opsview_webserver_base_prefix: '/myopsview'

Then run:

/opt/opsview/deploy/bin/opsview-deploy /opt/opsview/deploy/lib/playbooks/orchestrator-install.yml

This will make the necessary adjustments to opsview-webserver and opsview-web-app.

Double proxying

When rehomed, you can use Opsview Monitor behind another frontend proxy. As such, when a user accesses the proxy in a browser, the sequence to access Opsview Monitor might be:

External request reaches opsview-external.example.com (your proxy server).
The opsview-external.example.com proxies to opsview-internal.example.com or an ip address (your opsview webserver).

The changes required are:

Setup the proxy configuration for the frontend proxy.
Enable the “Ignore IP in Authentication cookie” feature.

You can use the following example configurations for Apache2 or for NGINX proxies (assuming SSL is used between the proxy and the opsview server). The full installation of the proxy server is not described here since it will be too specific to the infrastructure. The below configuration is required for Opsview to function through a proxy.

Apache 2 proxy

Place the Location configuration in your frontend proxy to forward to your Opsview Monitor server:

<Location /myopsview>
  ProxyPass https://server.os.opsview.com/myopsview retry=5
  ProxyPassReverse https://server.os.opsview.com/myopsview
</Location>
<Location /myopsview/websocket>
  ProxyPass wss://server.os.opsview.com/myopsview/websocket retry=5
  ProxyPassReverse wss://server.os.opsview.com/myopsview/websocket
</Location>
<Location /jasperserver>
  ProxyPass https://server.os.opsview.com/jasperserver retry=5
  ProxyPassReverse https://server.os.opsview.com/jasperserver
</Location>

NGINX proxy

Place the Location configuration in your frontend proxy to forward to your Opsview Monitor server:

 location /myopsview {
        proxy_pass https://server.os.opsview.com/opsview;
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Server $host;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        }
 
location /jasperserver {
    proxy_pass https://server.os.opsview.com/jasperserver;
    proxy_set_header X-Forwarded-Host $host:$server_port;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Server $host;
}

By default, authentication in Opsview Monitor will confirm if the IP address encoded in the request is the same as the browser IP. You need to disable this check if you have forward proxies that mask the browser IP. A symptom of this problem is that you will be able to login to the monitoring pages but access to Reports and Netaudit will return the login page and give the error message:

Authentication to Opsview succeeds, but session is invalid for X

To ignore the IP checking, as the root user, add the following line into /opt/opsview/deploy/etc/user_vars.yml on the Opsview Monitor server:

opsview_session_ignore_ip: True

Then run:

/opt/opsview/deploy/bin/opsview-deploy /opt/opsview/deploy/lib/playbooks/orchestrator-install.yml

Web authentication timeout

By default, Opsview web sessions will expire after one hour of inactivity and the user will be automatically logged out. Sessions will be refreshed any time the web client makes a successful request to the server, for example, when the user navigates to a new page or a dashlet view refreshes.

You can configure the amount of time that a web session can be idle before it expires. This is controlled by adding the following section in user_vars.yml:

opsview_session_manager_config_overrides:
  session_id_ttl: 3600 # Idle timeout for the session in seconds, default 1 hour, recommended to be no less than 5 minutes

Then run as root:

/opt/opsview/deploy/bin/opsview-deploy /opt/opsview/deploy/lib/playbooks/session-manager-install.yml

Note
Any automatic refreshes, such as in Navigator or in Dashboard, will extend the timeout.

Previous article Next article

Customization

Single sign on (SSO) authentication

Theme and white labelling

Examples

Managing host icons

Adding a host icon

Removing an icon

Specifying Opsview addresses

Re-homing

Double proxying

Apache 2 proxy

NGINX proxy

Web authentication timeout

Was this topic helpful?

Your thoughts...

How can we improve this topic?

Your thoughts...

Thank you for your feedback!

Customization

Single sign on (SSO) authentication

Theme and white labelling

Examples

Managing host icons

Adding a host icon

Removing an icon

Specifying Opsview addresses

Re-homing

Double proxying

Apache 2 proxy

NGINX proxy

Ignore IP in Authentication Cookie

Web authentication timeout

Was this topic helpful?

Your thoughts...

How can we improve this topic?

Your thoughts...

Thank you for your feedback!