Hi Tobias.
I have expanded on the Altinity patch by adding a 'can_submit_commands'
and 'can_submit_commands_strict' option to contact groups. The
limitation of having a can_submit_commands option on the user is that
it's an all or nothing option. A user is either view-only for all
devices, or not.
I will be using can_submit_commands_strict for people who need to be
able to submit commands for the servers and services they manage, but
also be able to only view some other servers and devices. I don't want
the users to be able to view ALL devices.
*can_submit_commands_strict:* You grant users full access to all or
some systems, but want to restrict them from issuing commands for a few
devices.
If a device has multiple contact groups defined and any one of them
denies submit commands with can_submit_commands_strict 0, then the user
is denied even if the user belongs to a group that permits it.
*can_submit_commands:* You grant users read/only access to all systems,
but you want to allow the user to issue commands for a few devices.
With can_submit_commands, if a device has multiple contact groups
defined and any one of them allows submit commands, the user can submit
commands. If there was only one contact group listed and it had
can_submit_commands set to 0, the user would not be able to submit commands.
Is this what you are looking for?
Alex
Tobias Klausmann wrote:
Hi!
I've got a problem that I don't how to solve best in Nagios. I
think other people have run into the same problem (I know that
someone has run into a /similar/ problem).
I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500
services). Thing is, our projects/(host|service)groups vary
wildly in who is responsible for them. Unfortunately, all these
projects are also heavily intertwined in their dependencies.
Say we have a web mail project A. This consists of several
web servers, databases and the like. It is heavily dependent on
the LDAP project B and the mail server project C. While B and C
have the same group of admins, project A is managed by an
entirely different group of people.
As such, we have configured Nagios that the group that is
responsible for project can only see the machines of project A and
the "B-and-C-people" can only see B and C.
Everything is peachy.
Except. Sometimes, project A may look like it's broken (pages
time out etc). But in reality, there's a spam attack and the
project B (the LDAP infrastructure) is so slow it simply grinds
to a halt. In this case it would obviously be nice if the people
from project A could see that project B is slow. Yet they should
not be able to change the notification options/acknowledgements
etc etc of projects B or C.
The altinity people have created a patch for the "view some,
change none" scenario[0]. Unfortunately, what I'd need is a
mechanism for the "view some, change a few" scenario I outlined
above.
How do others deal with this kind of problem? I'm sure we're not
the only ones who've run into it.
As of currently, our best guess would be to create
pseudo-accounts (like john.foo and john.foo-admin) and hack the
CGI(s) to only allow the commands from -admin accounts which are
in the notification list (with notification options set to "n").
We already do this to let people see machines they don't
mailed/paged/called about.
Regards,
Tobias
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
_______________________________________________
Nagios-users mailing list
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
