Access

There are 4 levels of access:

• View - the ability to see status
• Notification - the ability to receive notifications
• Action - the ability to schedule downtime or acknowledge a problem (used to be known as change)
• Admin - the ability to change configurations

Based on the contact's role, the access control is:

The subset is based on the intersection of the Authorised for Host Groups and Authorised for Service Groups tick boxes, so only services from the specified servicegroups that exist on a host from the specified hostgroups will be included in the subset.

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

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.

From Opsview 3.1, there will be granular access controls. This works by setting contacts with one or more roles. These roles then allow different access levels.

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

These are the access levels:

• VIEWALL - View all (requires reload)
• VIEWSOME - View some (requires reload)
• ACTIONALL - Action all (requires reload)
• ACTIONSOME - Action some (requires reload)
• NOTIFYSOME - Notify some (requires reload)
• CONFIGUREHOSTS - Configure 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 everything, just select the top level hostgroup
  • If you select any monitoring servers, you are only allowed to mark hosts against these particular monitoring servers
• RELOADACCESS - Reload
• ADMINACCESS - Admin access
• 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.

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
  • Reload access
• View all, change some
  • View all
  • Action some
  • Notify some
• View some, change some
  • View some
  • Action some
  • Notify some
• View all, change none
  • View all
  • Notify some
• View some, change none
  • View some
  • Notify some

Existing systems will have existing roles mapped to the appropriate new role during the upgrade.

Note: If you have manually added in different roles, you will have to map them yourself. All other roles will be deleted from the roles table.