Here is what I use.

I have different environments, production doesn't have access to ldap
and requires user accounts on the hosts, the office network still
installs the accounts but ldap is also used for groups and so (in case
ldap goes missing we can still access the local hosts).  I have common
sudo files for types of hosts (web, sql,etc) and use sudo..local files
if I really have to get around giving someone access when I don't want
to put them in a group (on ldap or a group of hosts).

#
# Class: users
#
import '*.pp'

class users {

  define add_user($uid,$pword,$groups) {

    include virt_users
    include virt_groups

    $username = $title

    user { $username:
      comment    => "puppet created account for $username",
      home       => "/home/$username",
      shell      => "/bin/bash",
      uid        => $uid,
      password   => $pword,
      groups     => $groups,
    }

    group { $username:
      gid     => $uid,
      require => User[$username]
    }

    # This uses the custom fact in user/lib/facter/nfs_home.rb.
    # If the fact is not nfs_home defined (ie, no nfs mount of home on
node)
    # then create the home directory and add the files.
    if ! $nfs_home  {
      file { "/home/$username":
        ensure       => directory,
        owner        => $username,
        group        => $username,
        mode         => 750,
        recurse      => true,
        recurselimit => 2,
        require      => [User[$username], Group[$username]],
        source       => "puppet:///modules/users/home/$username"
      }

      file { "/home/$username/.ssh":
        ensure  => directory,
        owner   => $username,
        group   => $username,
        mode    => 700,
      }

      file { "/home/$username/.ssh/authorized_keys":
        ensure  => file,
        owner   => $username,
        group   => $username,
        mode    => 600,
        source  => "puppet:///modules/users/home/$username/.ssh/
authorized_keys"
      }
    }
  }
}

I then break my accounts up into groups like so:

class sysAdmins inherits users {
  users::add_user { "someguy":
    pword  => '<a password hash from /etc/shadow or ldap>',
    uid    => UIDNUMBER,
    groups => [ 'wheel', 'some other group' ]
  }

Then in the node definitions I include them:
node default {
  include sysAdmins
}

I can override the defaults by adding another class:
class Operators inherits sysAdmins {
  realize ( Group ["somevirtgroup"] )
  realize ( User["somevirtuser"] )

  Add_user["someguy"] { groups => [ 'wheel', 'somevirtgroup' ] }
}

then include that on the node:
node somenode inherits default {
  include Operators
}

That will add someguy's virtual group.

This way we get user accounts on the hosts set with passwords and ssh
keys (that individuals have created on their desktops), plus access to
sudo rules with what ever password/user/group restrictions we
require.

Cheers,
DenMat

On Sep 21, 9:43 am, Daniel Pittman <dan...@rimspace.net> wrote:
> Andreas Mohrhard <anu...@gmail.com> writes:
> > I'm currently evaluating puppet for use in our server environment (2+
> > physical machines and something over a dozen xen instances). I want to use
> > it mainly for managing the ssh keys and creating and maintaining accounts
> > for the developers and admins (which work in like 3 groups).  So i got three
> > groups of users (admin, test, production) or something.
>
> [...]
>
> > I read up on user and group creation and ssh key distribution. The only
> > thing i cant wrap my head around is how i should handle passwords.
>
> I would strongly advise that you deploy an LDAP backed PAM and NSS system,
> rather than trying to do all this locally.  While it introduces another
> dependency into your boot process and network, it substantially reduces the
> complexity of doing all this.
>
> > Until the point where sudo comes in I wont need any passwords at all in
> > everyday use but allowing the users to simply sudo without a password seems
> > a bit strange to me.
>
> It would not fit our business security requirements, but it might fit yours,
> and is certainly the simplest option.
>
> > So the users would need a password. Or I could simply allow root login to
> > our dev/test/ production machines from login.example.com thus eliminating
> > the need for sudo and the passwords.
>
> Bad idea: shared accounts always lead to trouble, even if it is only the
> trouble of having to distribute the password when someone goes to work for the
> competition. ;
>
> > Is that possible to do with puppet or have I any weird ideas in there?
> > I'm open for suggestions.
>
> The only local password distribution model I have ever seen work was where you
> changed the password on the master system, then distributed the changed hash
> to all the client machines.
>
> In the puppet world that would mean "on the puppetmaster", and "reading
> /etc/shadow somehow".
>
> Don't do that though.
>          Daniel
> --
> ✣ Daniel Pittman            ✉ dan...@rimspace.net            ☎ +61 401 155 707
>                ♽ made with 100 percent post-consumer electrons

-- 
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