Opened 7 years ago

Closed 7 years ago

#29 closed (fixed)

site admins have inconsistent privileges in nagios installations

Reported by: chaos@bbn.com Owned by: jonmills@renci.org
Priority: major Milestone: EG-ADM-1
Component: Administration Version: SPIRAL4
Keywords: Cc:
Dependencies:

Description

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 multisite.mk.
    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 jbs@bbn.com 7 years ago.

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by jbs@bbn.com

Attachment: check-mk-error.png added

comment:1 Changed 7 years ago by jbs@bbn.com

I've attached a screenshot of my login error.

comment:2 Changed 7 years ago by chaos@bbn.com

Owner: changed from somebody to jonmills@renci.org

comment:3 Changed 7 years ago by jonmills@renci.org

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 7 years ago by jonmills@renci.org

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 7 years ago by chaos@bbn.com

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 7 years ago by jonmills@renci.org

Script is re-enabled.

comment:7 Changed 7 years ago by chaos@bbn.com

Testing today, i see:

  • The cgolubit account can log into https://bbn-hn.exogeni.net/rack_bbn/check_mk/, and sees "cgolubit (admin)", so that's fixed.
  • The cgolubit account can log into https://rci-hn.exogeni.net/rack_rci/check_mk/, and sees the same behavior jbs saw at rci last week, namely the error:
    Your username (cgolubit) is listed more than once in multisite.mk. 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 7 years ago by chaos@bbn.com

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 7 years ago by jonmills@renci.org

Status: newassigned

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

comment:10 Changed 7 years ago by chaos@bbn.com

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 7 years ago by jonmills@renci.org

Chaos,

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 7 years ago by chaos@bbn.com

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 multisite.mk. This is not allowed. Please check your config.

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

comment:13 Changed 7 years ago by chaos@bbn.com

Hmm. I tried to revisit this just now to get a status check. Now when i login to https://rci-hn.exogeni.net/rack_rci/omd/ 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, rciadmin@renci.org 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 7 years ago by jonmills@renci.org

I actually believe that this ticket is remedied.

Please test again by attempting to log first into bbn-hn.exogeni.net/rack_bbn/check_mk. If that is successful, then attempt to log into control.exogeni.net/monitor/check_mk. You should, at a minimum, be able to see everything under the 'BBN' site heading.

If you wish to compare bbn-hn.exogeni.net/rack_bbn to rci-hn.exogeni.net/rack_rci, 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 7 years ago by chaos@bbn.com

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.