web interface access and authorization

[Marc Powell]

Hey Olivier,

I haven't tested 3.x extensively yet but I don't see anything in the
documentation about contact permissions that's different than 2.x so
I'll take a stab --


> -----Original Message-----
> From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> bounces at lists.sourceforge.net] On Behalf Of Olivier JAN
> Sent: Wednesday, February 06, 2008 4:23 AM
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] web interface access and authorization
> 
> 
> Hi list,
> 
> I have a question regarding web interface authorization with nagios 3.
> 
> What i understood is that
> 
> - you can have peoples not in contact for a host or service that can
> view all hosts and services but cannot issue commands for them (wiht
> right permissions).
> - You can have peoples define as contact for a host or service than
> can view and command all hosts and services for which they are
contact.
> 

Correct for both.

> The questions are :
> 
> Can you have people as contact for host and service that can view
> those hosts and services but CANNOT issue command on them. How can i
> achieve this ?

Set the 'can_submit_commands' parameter to the contact{} definition as
you like.
http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html#contact

> Can you have people not define as contact for a host and service to
> see only certains hostgroups or servicegroups and don't issue commands
> on them ?

No. There's no facility for limiting what's seen by authorized users
outside of being a contact for the host/service.

--
Marc


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null