Hi Adam,
Shame you can't use LDAP or NIS ;) But anyway...
Let me give you one of my working examples of virtual resources and
hopefully it'll give you an idea on how to solve your problem. I've
got Yum repos as virtual resources. Now I don't want every Yum repo on
every server, so I've got a 'yum_repo' class that declares every Yum
repo in my organisation as virtual resources. Then, any other module
that wants to install something from a EPEL for example can "include
yum_repo" and then "realize yumrepo_epel". Doesn't matter how many
classes realize the same Yum repo as it's only declared virtual once.
However, all my yum repos are declared virtual on every node, even if
they are not used.
What you're trying to do is declare virtual users more than once which
is why you're getting an error. You need to have all your users
declared virtual first then allow your modules and classes to 'turn
on' different groups of people. By the looks of your extlookup your
data source is static enough to do this (I think...). So I'd suggest
something like:
class accounts::users {
#Get everyone in your organisation
$everyone = extlookup("everyone")
#Virtualise everyone!
virtualise_user { $everyone: }
}
define virtualise_user($username) {
$extlookup_precedence = [ "people" ]
$person = $extuser = extlookup($name)
@user { $username:
...
}
}
define add_groups_of_users($group) {
$extlookup_precedence = [ "groups" ]
$extgroup = extlookup($group)
#"turn on" everyone in this given group.
#It won't matter if they've already been realized before.
realize User[$extgroup]
}
Then any class or module that wants to turn on a specific group of
people just needs to declare a 'add_groups_of_users' and if there are
overlaps of people in different groups it won't be a problem.
There's a possible problem with my example that I haven't tested that
has to do with how strict the User type is. Can you declare a User (or
a virtual User) with a group that doesn't exist (yet)? If not, then
before you virtualise all your users you'll need to virtualise all
your groups, maybe even "turn on" the group before you "turn on" the
users.
Another problem with this is that virtual users are described once and
only once. With this model you have to know all your user and group
data before you start realizing them and you can't change them easily
once that's done. It is possible to use class inheritance to override
parameters of virtualised resources, but only once. Going by memory
(and this is all untested), but this would result in a multiple
declaration error:
class users {
@user luke {
groups = [ "wheel" ],
}
}
class users::pulse inherits users {
User["luke"] { groups += "pulse" }
}
class users::blah inherits users {
User["luke"] { groups += "blah" }
}
include users::pulse
include users::blah
Lastly, what you're trying to do is complex, especially with Puppet's
"declare once" feature. I tried to do a similar thing with adding and
removing root SSH keys for users: having business groups of staff that
any module could arbitrarily 'turn on'. It turned into a massive
schamozzle of run levels and multiple classes/defines per user. In the
end I just said to myself "this is ridiculous, there's got to be a
better way", found RIP's concat module and never looked back :) That's
not the best idea with things like /etc/passwd, /etc/shadow and /etc/
group as any software you install (MySQL, Postgtres, etc) has local
users in it which you'd have to try manage, but just proposing there
might be a completely different way of achieving what you want.
Hope that helps,
-Luke
--
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.
