Welcome to docs.opsview.com


The security model for Opsview is based on access levels and the selection of objects.

Access Levels

Access works by setting contacts with a specific role. These roles then allow different access levels.

Roles can be created, deleted or altered by navigating to 'Settings' ⇒ 'Roles' menu item.

Note: If you make changes to a role, an Opsview reload may be required because some changes rely on changes to the underlying Nagios® Core configuration files.

These are the access levels:

  • VIEWALL - View all (R = requires reload). This will also include all business services and business components
  • VIEWSOME - View some (R) - see below for the definition of some
  • ACTIONALL - Action all (R)
  • ACTIONSOME - Action some (R) - see below for the definition of some
    • Action ability includes: setting acknowledgements, editing the built-in wiki. Note, setting downtime requires DOWNTIMESOME
  • DOWNTIMESOME - Can set downtime for their list of objects. See below for the definition of some (R)
  • TESTALL - Can run the Test Service Check function
  • TESTSOME - As TESTALL, but see below for the definition of some
  • TESTCHANGE - Can run the Test Service Check function and have the ability to change the arguments for troubleshooting
  • DASHBOARD - Allows access to the dashboard
  • DASHBOARDEDIT - Allows user to make private changes to their dashboard. See here for details of their abilities
  • VIEWPORTACCESS - Viewport access
  • RRDGRAPHS - RRD graphs
    • If RRD graphs is set to public, then /graph and /rrdgraph will be available to non-logged in users. They will also be allowed to view all hosts and all services
    • If RRD graphs are set to authenticated users, then the hosts and services allowed to be accessed will be restricted to the subset of the host group and service group intersection.
  • NOTIFYSOME - Notify some (R) - see below for the definition of some
  • CONFIGUREHOSTS - Can view configuration for hosts
    • You choose which points in the Hostgroup Hierarchy this roles has, which means only hosts within those hostgroups are allowed to be configured. To be able to configure all hosts, select the top level hostgroup
    • If you select any monitoring servers, you are only allowed to mark hosts against these particular monitoring servers
  • CONFIGUREKEYWORDS - Can view configuration for keywords. Note that a user with this access would be able to get a list of all service checks, hosts and contacts for the system
  • CONFIGUREPROFILES - Can view configuration for shared notification profiles for their role. If the user also has ADMINACCESS, they can see profiles for all roles (A = recommended Admins only as Opsview needs to list all objects for configuring)
  • CONFIGURENETFLOW - Can configure NetFlow
  • CONFIGUREVIEW - Can view configuration of everything else that does not have its own access point above. As new access points are created, less will be covered by CONFIGUREVIEW
  • CONFIGURESAVE - Can save configuration changes. Removing this access effectively gives a view only ability to look at the configuration data (note that some passwords will be visible)
  • ADMINACCESS - Admin access, including audit log access
  • REPORTUSER - Allows access to Opsview Reporting Module
  • REPORTADMIN - Allows administrator access in Opsview Reporting Module
  • NETFLOW - Allows ability to view the NetFlow dashlets
  • PASSWORDSAVE - Can change their own password
  • NAGVIS - Allows access to Nagvis

Note: ADMINACCESS does not allow access to everything. Currently it is used for administrator access, but as more granular access points are added, the items within ADMINACCESS will decrease (but upgrade scripts will ensure that new access points are split appropriately).

On initial systems, these roles will exist:

  • Public (Note: Only RRD graphs and Viewport access make sense to be public)
    • Viewport access
  • Authenticated User
    • RRD graphs
  • Admin role
    • View all
    • Action all
    • Notify some
    • Admin access
    • Configure hosts
    • Configure view
    • Configure save
    • Reload access
    • Nagvis access
  • View all, change some
    • View all
    • Action some
    • Notify some
    • Nagvis access
  • View some, change some
    • View some
    • Action some
    • Notify some
    • Nagvis access
  • View all, change none
    • View all
    • Notify some
    • Nagvis access
  • View some, change none
    • View some
    • Notify some
    • Nagvis access

Selection of objects

For access levels which refer to some, this is the selection of objects based on the role.

The selection consists of the union of:

This allows you to “slice” the services that you can see on a host.

We recommend that you use service groups to match your team function or areas of responsibility (for example: Windows, Unix, Database, Network, Monitoring). You can use the host group hierarchy however you choose: some implementation are based on locations while others are based on priority (production, test, development).

When Opsview sets up notifications, you will receive the relevant host alerts for the services you have access to. If you do not want host notifications, you can disable them at the contact's notification profile.

Note: A contact must have at least 1 service on a host to be within the subset. This means that selecting All hostgroups, but only, say, the Database servicegroup, would mean that a contact can see only hosts with database services. Hosts without any database services would not be in this subset.


All my administrators do not have CONFIGURESAVE

If you have locked out all administrators by removing CONFIGURESAVE, you can add it back to your role by running the following in the opsview database::

mysql> insert into roles_access values (10, 13);

This will add CONFIGURESAVE to the “Admininistrator” role (whose id is usually 10).