On Nov 4, 4:34 am, Patrick <[email protected]> wrote:
> On Nov 4, 2010, at 12:28 AM, hywl51 wrote:
>
> > Hi, all
>
> > I want to control the user accounts on our company servers with
> > puppet. The complete requirements are the following:
>
> > 1. Assuming that one user run " useradd ...." on the server to create
> > a new account named "newuser".
> > 2. Puppet will konw the new user created soon, and restore the server
> > status to the before. That is, puppet will delete the new user.
>
> > I am not sure if puppet could fullfill this requirement. Could anyone
> > give me some advices.
>
> Puppet isn't good at requests phrased that way. I don't use puppet to say,
> "make X stay how it currently is". Instead you say, "Make X be the state I
> declare."
That's quite right. However, Puppet supports the state you declare
encompassing exactly a specific set of users, or even exactly a
specific set of users having UIDs greater than a minimum threshold.
PROVIDED THAT you use Puppet to manage all the ordinary user accounts
you _do_ want, you can instruct it that no other non-system accounts
should be present. Do so by adding this metaresource to your
manifest:
resources { "user":
purge => true,
unless_system_user => 499
}
The value of the 'unless_system_user' property is the numerically
greatest UID that is considered a "system" user (administrative and
system services accounts), and thus not to be deleted. 499 is the
correct value for the standard setup of RedHat-family Linuxes; for
some other systems it would be 99, or perhaps some other number. Read
the docs for (a bit) more detail.
I suspect that this will not remove user home directories, but that's
not documented and I have not tested it.
You should be able to do the same for groups, if you wish, but I don't
think there is a built-in concept of system groups parallel to that of
system users.
> You could push out /etc/passwd and /etc/group with Puppet, but you would need
> to be careful.
Indeed so.
Alternatively, you could perhaps take an altogether different approach
by relying on LDAP or NIS for user authentication. That would work
best if the same set of users should have access to all the systems
you're managing, or if you can at least categorize the systems into a
small number of sets that each share a common pool of users (each set
would then need its own NIS or LDAP domain). This assumes that your
local administrative accounts are not empowered to add new users in
LDAP/NIS.
As a third alternative, it ought to be possible to address the
underlying problem with judicious configuration of sudo, or, if that's
not sufficient, with SELinux (if you're using Linux). With these
approaches the objective would be to grant users the ability to
perform the tasks they need to perform, without empowering them to
manage users.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
