Hello,

Just curious...

How have you guys solved the "centrally manage" the sudoers file dilemma?

Rsync?
Rdist?
NFS?

I was thinking about using rysnc, but I am curious about how some of you have done it...

-C

HIIII!!!!1 ME AGAIN!!!!

There are sudoers schema extensions for ldap... not perfect in their implementation, but near perfect in theory.

in fact though, if you don't want sudoers IN ldap, you should still be looking to use centralized groups within sudoers. Never use lists of local users etc, always link to centralized groups and then administer group memberships centrally.

Rdist was pretty much designed to do exactly what you're looking at doing and it would be relatively easy in the future to add additional files you need to keep sync'd up.

That being said, imho with that many machines a centralized login solution like ldap might be better long term if you have the expertise to implement it (if you're going to go that route for sudors it would make sense to move most of the system files (passwd, groups, shadow, hosts, services, etc) onto ldap too to centralize everything.)

Ah...I didn't know that!

Is it a plugin? Where can I read more information about this? Since we are moving out Unix/Linux account to RHDS (actually CDS); it would be GREAT to centrally manage it with LDAP...since I have it in place...

My current plan was just to rdist the file and script the checking of the permissions....

But the LDAP solution _does_ sound better!

-C

It's not a plugin, no, and you'd want to understand why it wouldn't be. It's a schema extension, so additional objectClasses and attributes designed to hold the data.

http://www.gratisoft.us/sudo/man/sudoers.ldap.html

LQ been playing around this evening, so not sure if you saw my addition about using ldap groups if not completely ldap.

And once you're its friend, you'll find that most things can go into ldap. You will sounds very very dull when your response to most things is "stick it in ldap"

You could also think about using a centralized configuration management approach and put the sudo configuration under such a software.

Options might be:

* puppet: http://reductivelabs.com/products/puppet/

* cfengine: http://www.cfengine.org/getstarted.php

I also found this...

http://kbase.redhat.com/faq/docs/DOC-2057

Could that be used?

I'll probably set up a test machine soon to test this out...

Also...is there anything I need to do to sudo to make this work?

-C

I would think that that is the same as what I originally mentioned. Note that you still need to configure nsswitch.conf etc to permit sudo to go to ldap in the first place. The KB does suggest this might already be patched in the normal sudo version.

Thanks acid_kewpie !

Looks like I'll be doing some reading for a while

-C

There's a lot of good stuff out there on LDAP and centralizing login services, the only real problem I see on an on-going basis is that a lot of them are incomplete and missing an item here and there.

That's especially true of a lot of the tutorials online I've found that utilize ldap for passwd/group setups.

Good luck!

That's very true...

I would like to implement sudo within LDAP, but I have a lot of reading and testing ahead of me...

In the mean time I have added a posixGroup called suadmins (for Sudo Admins) and joined users who are to have sudo access to that group...then in the "master" sudoers file I have...

Then rsync them...

Seems to be working ok so far...

But I would really like to implement sudo within LDAP.

-C

Yeah, that's a great middle ground. A challenge that I've got at the moment, which may well be of concern to you is auditing the use of sudo. as you've got ALL=(ALL) anyone in that group can do anything as root, including opening a shell. Now once that shell is open you will have no audit trail of anythign they do, unlike a normal sudo command which is logged. How do you keep an audit trail? Most feasible way I've seen is to use a tool like rootsh, and only let the admins run that. That way they can get a root shell, without a nasty hack like running "sudo su -" to get to root, and everything they do in that mode is safely logged for inspection. One neat thing I liked doing was to modify the default prompt to say that if there is a $SUDO_USER variable in the environment they are in, then add that to the PS1 as well as the normal, so you have [dave as root@localhost]$ instead, which gives feedback directly to the user, turning root into more of an enhanced mode of themselves, rather than a seperate account.

Might be overkill for you, but maybe not, and I'm still very much trying to suss a nice solution.

Very true...

The audit aspect has got me puzzled for the time being...

We have a team of 6 developers so the auditing thing is "not so bad" at the moment...

However, I know that the rsync thing is not a permanent solution (hopefully).
That's not a bad idea...I was thinking about using "!" in the sudoers file...that way they can't "sudo su -"

Hopefully I can integrate this sudo thing soon :-)

in a situation like that, there's always a way to make another shell. a symlink or something to get around it. Nothing's perfect.

And there is the biggest problem in IT