Hi!
On Tue, 31 Oct 2006, Az wrote:
> > 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.
> Is that to say that "view _all_, change some" wouldn't work for you?
> That's how we're working at present, out-of-the-box. While restricting
> viewing might reduce mental clutter for those concerned*, I can't see
> why being able to see everything is a big deal (unless you're displaying
> some super sensitive information in Nagios which is a totally different
> topic).
Well it's not super sensitive but when we started deploying
Nagios we were very happy to not clutter the webpages for everybody
(how we Nagios admins cope is another story ;)). We're currently
looking into hacking cmd.cgi to
a) log all issued commands with username and ip
and
b) do some permission checking
Unfortunately b) will leave us with yet another othogonal user
account type. Currently, most users have three accounts:
first.last, first.last-sms, first.last-email, first.last-phone.
The first account allows them to log onto the website and view
stuff, the other three are used to configure the respective
notification types (the first account has notifications disabled
entirely). This has the advantage that not everybody that wants
to see a host has to get any of the used notification types.
Unfortunately, you can not easily pull apart "view" and "disable
stuff" this way, hence my initial question.
The Nagios permission system is a bit lacking in this respect. As
far as I can tell from Ethan's presentation about 3.0, that won't
change (much) with the next version. It's not like I have the
perfect way to specify such fine-grained perms in my head,
either.
> *Our service centre can see everything, but we used service groups to
> provide "rolled up" views to keep it simple for them. All our engineers
> can see everything so when they spot an issue with someone elses kits
> that impacts their own, they can find out what the issue is and who to
> poke in the eye with a burnt stick to get it fixed. We found that trying
> to hide stuff just blinkered people and made them only responsive to
> their own issues ("not my server. not my problem.") which results in
> poor customer service at the end of the day.
While I agree with you mostly, we also offer Nagios monitoring to
our customers. This is turn means that we have to seperate them
in some way (it wouldn't be cool if all customers saw each
other's hosts and services). This is a hard requirement that I
can't move a single inch on (rather: my boss won't let me).
We're now looking at seperating our own Nagios and that for the
customers. That way, we'd get the "have N accounts for everybody"
to be a little more manageable. For our internal stuff, we'd go
the route you described (everybody seeing everything). Seeing as
about 90% of what we monitor is our own stuff, that would make
quite a difference.
Regards,
Tobias
--
Never touch a burning system.
-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nagios-users mailing list
Nagios-users@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
