Opened 12 years ago

Closed 12 years ago

#29 closed (fixed)

site admins have inconsistent privileges in nagios installations

Reported by: Owned by:
Priority: major Milestone: EG-ADM-1
Component: Administration Version: SPIRAL4
Keywords: Cc:


We attempted to access and view the following nagios installations:

using the following accounts:

  • chaos: a member of xoadmins (admin at all racks)
  • jbs: a member of bbnadmins (site admin at BBN)
  • cgolubit: a recently-created member of bbnadmins (site admin at BBN)

In testing these accounts, we see the following behavior which seems unexpected:

  1. When logged into the BBN rack, the cgolubit account sees the status "cgolubit (guest)", while the jbs account sees the status "jbs (admin)". I would expect those two accounts to have identical behavior.
  2. The service contact list for an arbitrary service contains chaos and jbs (as expected), but does not contain cgolubit. Therefore, if notifications were being sent, cgolubit would not receive them.
  3. The chaos account can login to the RENCI rack and gets status "chaos (admin)". The cgolubit account can login and gets status "cgolubit (user)". However, the jbs account cannot login, seeing the error:
    Your username (jbs) is listed more than once in
    This is not allowed. Please check your config.

Nagios behavior for site admins should be consistent, and ideally should be populated automatically so that new site admins and new sites see reasonable behavior.

Attachments (1)

check-mk-error.png (1.3 MB) - added by 12 years ago.

Download all attachments as: .zip

Change History (16)

Changed 12 years ago by

Attachment: check-mk-error.png added

comment:1 Changed 12 years ago by

I've attached a screenshot of my login error.

comment:2 Changed 12 years ago by

Owner: changed from somebody to

comment:3 Changed 12 years ago by

This is broken on purpose, and upon your request.

We disabled the LDAP user sync script on bbn_hn because Chaos wanted to receive alerts, and no one else wanted to be bombarded by them.

If the LDAP sync script were enabled, it would have picked up new user 'cgolubit' and would have added that user, along with normalizing all the user accounts that Nagios knows about.

comment:4 Changed 12 years ago by

What we need is an LDAP schema extension that allows us to store per-user notification preferences. That could then be parsed by the sync script and built into the Nagios contact objects. Right now the notification enable/disable feature is on a per-LDAP-group basis, because that was as much as we could implement without a schema extension.

comment:5 Changed 12 years ago by

Ah, okay. In that case, i think now that i've seen some notifications and gotten to watch them go by for awhile, i'd prefer to make a new ticket noting that we need that functionality, and re-enable LDAP user sync so we can test other things that rely on it.

Sound good?

comment:6 Changed 12 years ago by

Script is re-enabled.

comment:7 Changed 12 years ago by

Testing today, i see:

  • The cgolubit account can log into, and sees "cgolubit (admin)", so that's fixed.
  • The cgolubit account can log into, and sees the same behavior jbs saw at rci last week, namely the error:
    Your username (cgolubit) is listed more than once in This is not allowed. Please check your config.
  • Interestingly, if i login to RCI using safari, i see the same error, but it is not fatal, and i also see a login and some status. I'm attaching that screencap for information.

So it looks like the RCI rack nagios configuration for site admins still throws the error mentioned previously.

comment:8 Changed 12 years ago by

Enh, i was futzing with Safari trying to get a good screencap, and stopped being able to reproduce the different view. Now Safari looks just like Firefox as reported by Josh.

comment:9 Changed 12 years ago by

Status: newassigned

I'm not able to explain or reproduce the 'listed more than once in' problem. I can read the list of usernames in /omd/sites/rack_rci/etc/check_mk/multisite.d/, and clearly see that there are no duplicates.

comment:10 Changed 12 years ago by

Well, i don't know: i definitely still see the problem with the cgolubit account. It's not necessarily that important for site admins to be able to login to rci's nagios UI (presumably they should be using the one at their own site), but if that is going to be the recommended way for site admins to get any type of information, it should be fixed.

Let me know if you want to borrow the cgolubit account (or create your own account in bbnadmins) to reproduce the symptoms.

comment:11 Changed 12 years ago by


I established different privilege levels from the beginning. So by design, I never intended for a single user account to have the same privileges across racks, unless they are in 'xoadmins' LDAP group.

For instance, let's look at the way Check_MK is configured at BBN:

## ## Multisite built from LDAP ##

admin_users += [

"anirban", "cgolubit", "chaos", "ckh", "hpd", "ibaldin", "jbs", "jonmills", "lnevers", "pruth", "tupty", "viviano", "vjo",


users += [ ]

You see that both 'chaos' and 'cgolubit' are both admins, because it's your local rack. Now let's look at RCI:

## ## Multisite built from LDAP ##

admin_users += [

"anirban", "chaos", "ckh", "ibaldin", "jonmills", "pruth", "viviano", "vjo",


users += [

"cgolubit", "hpd", "jbs", "lnevers", "tupty",


Here 'chaos' is still and admin, because she is in 'xoadmins' group. But 'cgolubit' is now just a user instead of an admin, but this isn't her rack.

comment:12 Changed 12 years ago by

Sure. What you've defined sounds fine, and i have no problem with that. But i'm still seeing:

Your username (cgolubit) is listed more than once in This is not allowed. Please check your config.

at rci-hn as cgolubit, and wish i weren't.

comment:13 Changed 12 years ago by

Hmm. I tried to revisit this just now to get a status check. Now when i login to as either chaos or cgolubit, i get:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

comment:14 Changed 12 years ago by

I actually believe that this ticket is remedied.

Please test again by attempting to log first into If that is successful, then attempt to log into You should, at a minimum, be able to see everything under the 'BBN' site heading.

If you wish to compare to, you should note that, as a member of bbnadmins group, you will appear as an 'admin' on the former and as a 'guest' on the latter. And as a guest, you may be able to see some or all objects, but you will not be able to issue commands to them. *That is by design*

comment:15 Changed 12 years ago by

Resolution: fixed
Status: assignedclosed

Jonathan: yes, this looks like it's now fixed (as user chaos, who was taken out of xoadmins and returned to bbnadmins only at some point). I agree that admin on the local rack and guest on remote racks is fine behavior: the issue was just the internal server error, and it looks like that has indeed been fixed.

Josh (jbs) verified that this works for him too.

Note: See TracTickets for help on using tickets.