On Dec 7, 4:13 pm, jokeeffe <jete.okee...@gmail.com> wrote:

> It probably doesn't need to be virtual but I thought I read in the
> documentation that it was better to do so.

The best practices documentation has at times recommended declaring
users virtually.  I don't know whether it still does now, but even
when it did, it was not recommending the model you showed.

Virtual resources help you out mainly when you want to define a
resource that multiple independent classes may need.  Each resource
(virtual or not) can be *declared* only once, but virtual resources
can be *realized* as many times as desired (including zero).

For users, the recommended model involved creating a class containing
virtual User declarations for all users that Puppet need ever manage.
Any class that needed any user management must then include the class
of virtual users, and realize those users it cares about.  The main
advantage here is centralized user management.

> Basically, at my organization, admins come and go. I was hoping to use
> puppet to get rid of all logins of admins that no longer work for the
> company. So, I was hoping I could just use a simple array to add users
> as time goes by to ensure those user no longer have an account.

Puppet can definitely do this job for you.  I'm not certain whether
the array syntax gains you anything, though, even if it can be made to
work.  Here are some alternatives:

1) If the objective is to minimize the amount of Puppet code required
for this specific task, then I think you could do something like this:

# include this class on all nodes for which the specified users need
to be absent:
class remove_nonusers {

    # defaults for user resources declared within the scope of this
class
    User { ensure => absent }

    # the users that need to be absent; not much more verbose than an
array declaration
    user {
        "bill": ;
        "billy": ;
        "bob": ;
    }
}


2) If you are willing to use Puppet to manage all non-system accounts
on your machines, then you can rely on user purging by putting this in
an appropriate scope:

resources { "user": purge => true, unless_system_user => true }

In that case, Puppet removes any users not known to it and not
considered system accounts (UID < 500 by default).  Using this
approach requires that you tell Puppet which ordinary user accounts
you want to be present, so overall it may require more code than
option 1.  On the other hand, user management is one of the more
common tasks that admins want Puppet to handle, so you may already be
planning or doing this.

--

You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.


Reply via email to