The Opsview application creates two cookies - a session cookie and an auth_tkt cookie.

The auth_tkt allows a username to be encoded within a hash key which is stored as a cookie. This hash can be deconstructed to get the username and a timestamp. Web applications with the shared secret can then re-hash this data with the expected IP address and compare the hashes - if they match, then the user is considered authenticated. This provides single sign on as the username can be used in other applications.

If login is successful, the session cookie is setup and the ticket is created so two cookies will be sent back to the browser.

This ticket cookie will get renewed based on the renew_ticket_after time. The ticket gets expired after the expires value. These are in the opsview_web.yml file.

However, this does not apply for API calls. API calls can work either by having the session cookie or by sending the authentication information within the XML.

On the master, there exists a nagios user, with a nagios group - this should be created as part of the install process. CGIs should be delivered via Catalyst - this keeps the architecture clean as the webserver can be moved to a different server from the application server. This also means that the CGIs will be invoked with the Catalyst user, which is nagios. This is equivalent to Apache using suexec for CGIs.

On slaves, there is a nagios user, nagios group and a nagcmd group. The nagcmd group should be also within the group for the Apache user, if you want the slaves to have CGI access to Nagios and NMIS. As part of install_slave, setup the nagcmd group for any files that need it. So theory is that group permissions will always be set correctly assuming CGIs are directly accessible on slaves, but local policy will then decide if the nagcmd group is allowed within Apache (thus allowing CGI access at a single point).