Opsview Knowledge Center

Roles

Brief Overview of Roles in Opsview Monitor

The configuration, addition and deletion of Roles is done via the 'Users and Roles' section of Settings:

Once within Users and Roles, click on the 'Roles' tab, after which the list of Roles will be visible:

In this table, you can choose to edit or delete a Role using the contextual menu, add a new Role using the 'Add New' button, export the list of Roles via the 'Export' button, and also filter the list of Roles using the filters within the column headers:

Adding a New Role

To add a new Role, click on the 'Add New' button:

Once clicked, this button will display the 'New Role' configuration window:

There are six tabs within the 'New Role' window:

  • Role: Assign a name and description to the Role. If Multi-tenancy is enabled, it will be displayed
    here.
  • BSM: Define the access control and visibility for Business Service Monitoring, i.e. can Users within this Role add Business Services or Components, and also which Business Services can they see when logged in.
  • Status Access: Defines what Users who are assigned this Role can do within Opsview Monitor when logged in; e.g. can they view dashboards, create dashboards, send notifications, etc.
  • Status Objects: Defines which objects the Users within this Role can see, including Host Groups, Service Groups, and Hashtags.
  • Configuration: Defines which objects and sections the Users within this Role can configure, e.g. can they access the 'Hashtags' section of Settings.
  • Administration: The administrative options are defined within this tab, such as determining if Users within this Role can reload Opsview.

First, give the Role a name and an informative description within the 'Role' tab, as shown below:

Note: We can ignore the 'Multi-tenancy' line as we are creating a 'standard' Role.

Next, click on the 'BSM' tab:

If the 'BSM' checkbox ('Allows ability to view BSM analysis screens') is not checked, then the rest of
the options will be hidden. The 'Authorised for Business Services' section is where you can determine which Business Services the User can view (via dashboards), and which ones they can both view and edit. In our example, we are not going to configure any access for editing and viewing BSM items.

You can control which Business Services are available for a Role from a 'top down' or from a
'bottom up' approach.

Top Down

Choose the specific business service in the Authorised for Business Services field. If you select View All, then all Business Services will be available including any new Business Services created in
the future. Access to the Business Service will allow visibility of all components of the Business Service.

Bottom Up

Components will be automatically selected based on your existing status object permissions (based on Host Group / Service Group intersection or Hashtags). Note: The 'intersection' is explained in detail within the 'Status Objects' tab.

Permission for components is automatically granted based on the existing status object definitions. If VIEWALL is specified, then all components are visible. Otherwise, it is based on the Host
Group/Service Group intersection and Hashtags. You need to see all hosts for the component to be
visible.

Note: If the component consists of 20 Service Checks, then the User will need to have permission to all 20 Service Checks in order for the component to be visible.

If you select the 'Grant permissions to Business Services' checkbox, then the Business Services
associated with all your components will be visible.

Next, click on the 'Status Access' tab:

Within this tab you can configure what access rights Users of this Role have, i.e. can they create and edit dashboards, can they view Flow data, can they send notifications, and so on. In this tab, we need to check 'VIEWSOME' ('Allows viewing of status information for some objects'), where 'some objects' are the items they are allowed to view as per the 'Status Objects' tab.

We should also check, NAVOPTIONS, RRDGRAPHS, TESTSOME, DOWNTIMESOME, and ACTIONSOME.

Next, click the 'Status Objects' tab:

Within Status Objects, you will need to set the combination of Host Groups and Service Groups; for
example, if we want to restrict Users to view only 'Application ' Opsview' service checks that are on
hosts within 'Monitoring Servers' Host Group, then we would select the above.

Alternatively, we can tag those Hosts and Service Checks with a Hashtag, i.e. 'opsview-servers', and
then select that within 'Authorised for Hashtags'.

Next, click on the 'Configuration' tab:

Within the Configuration tab, you can define the Host Groups that Users can edit (and thus the
hosts within). You can also define other items Users can configure within the monitoring software, i.e can they edit the hosts they have access to view, can they edit other Users, and so forth.

Finally, click on the 'Administrator' tab:

This tab controls administrator access such as granting Users access to RELOAD (i.e. the ability apply the changes), save new passwords or view reporting.

Once you have configured the above six tabs, click 'Submit Changes' and your new Role will be
created:

We can now apply this new Role to a test User, as below:

Note the Role is set to 'Opsview Servers'. After saving the new User and completing a reload, you can now log in with the new User and see that the permissions have been correctly applied:

Current Role Definitions

Note: If you make changes to a role, an Opsview reload may be required because some changes rely on changes to the underlying configuration files (marked by '(R)' below).

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 acknowledgments, editing the built-in wiki. Note, setting downtime requires DOWNTIMESOME
  • DOWNTIMEALL - See DOWNTIMESOME (R)
  • 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 the user to make private changes to their dashboard.
  • VIEWPORTACCESS - Viewport access
  • RRDGRAPHS - RRD graphs
    • If RRD graphs are 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 role 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 Hashtags (formerly called 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)
  • CONFIGUREHOSTGROUPS
  • CONFIGURECONTACTS
  • CONFIGUREROLES (A)
  • CONFIGURETENANCIES
  • 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)
  • RELOADACCESS - Reload
  • 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:

  • the intersection of the Authorised for Host Groups and Authorised for Service Groups tick boxes, so only services from the specified service groups that exist on a host from the specified hostgroups will be included in the subset
  • the list of authorized keywords

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 host groups, but only, say, the Database Service Group, would mean that a Contact can see only Hosts with database services. Hosts without any database services would not be in this subset.

Troubleshooting

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 'Administrator' role (whose id is usually 10).

Roles

Brief Overview of Roles in Opsview Monitor