Defines seem to be more like what you are after... Something like:
# Use the type object to define anything that doesn't change...
User {
shell => "/bin/bash",
schedule => daily
}
# Then a define with the stuff you want...
# Assuming $HOME and $fileserver are defined somewhere accessible...
define active_user($uid, $gid, $gecos) {
user { "$title":
comment => "$gecos",
uid => $uid,
gid => $gid
ensure => present,
home => "$basehomedir/$title",
managehome => true,
require => Group[$gid]
}
group { $title:
allowdupe => false,
ensure => present,
gid => $gid,
schedule => weekly
}
file { "$HOME/$title":
source => "$fileserver/public/home/$title",
recurse => true,
require => [ User[$title], Group[$title] ],
owner => $title,
group => $title;
}
}
# Then all you should need is something like:
active_user{ "fakeuser": uid => 1234, gid => 1234, gecos => "Fake
User" }
This is a quick go at your issue off the top of my head... You might
want to check it over
a bit before using it...
Also, for the ssh_authorised_keys - behaviour for that was changed in
0.24.8 - you now
need to specify the file to put the key into. For example:
ssh_authorized_key { "keyname":
ensure => present,
key => "...",
type => "ssh-rsa",
user => "smeg",
target => "$basehomedir/$user/.ssh/authorized_keys",
}
Hope that helps...
On Aug 5, 8:04 am, Bryan Allen <b...@mirrorshades.net> wrote:
> +------------------------------------------------------------------------------
> | On 2009-08-04 07:36:26, Mike Harding wrote:
> |
> | I have about 30 dev. and operation users on my machines, is there a
> | recipe anywhere for doing this? The best practices doc on the wiki is
> | incomplete and confusing.
> |
> | Also, any workaround for the ssh_authorized_key bug in 24.8? All I
> | really want to do is create users, home directories and put ssh keys
> | in them, but it tries to add the keys first, so it doesn't work.
>
> You didn't show us what you're doing, I don't think. Code, please. :)
>
> Personally, I have a class per user. Each of that user's files are managed in
> that class. e.g.,
>
> class fakeuser {
> user { fakeuser:
> allowdupe => false,
> comment => "FAKE USER",
> ensure => present,
> uid => 9999,
> gid => 9999,
> shell => "/bin/bash",
> home => "$HOME/fakeuser",
> groups => [ "axle" ],
> membership => minimum,
> require => [ Group["fakeuser"], Group["axle"] ],
> }
>
> group { fakeuser:
> allowdupe => false,
> ensure => present,
> gid => 9999,
> }
>
> file {
> "$HOME/fakeuser":
> source => "$fileserver/public/home/fakeuser",
> recurse => true,
> require => [ User["fakeuser"], Group["fakeuser"] ],
> owner => fakeuser,
> group => fakeuser;
> }
>
> }
>
> Any other files in their dir would then
>
> require => [ User["fakeuser"], Group["fakeuser"], File["$HOME/fakeuser"]
> ],
>
> or what have you.
>
> Users are then grouped in different classes (generic for all users, dev for
> development, etc) which are included on the appropriate node, or service
> class,
> depending.
>
> My Puppet install is very old and requires refactory. I'm sure I should be
> using something better, like User::fakeuser or something. :)
>
> Cheers.
> --
> bda
> cyberpunk is dead. long live cyberpunk.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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
-~----------~----~----~----~------~----~------~--~---
