On Wednesday, July 11, 2012 3:03:14 PM UTC-5, Jo wrote:
>
> I'm fighting with a ticklish issue. We have some groups and users that
> only belong on some systems. So we made all users virtual and then realize
> them in classes specific to those system types. This works quite well for
> the users, but not for the groups. When you specify a user, you have to
> list all the groups they are in.
> groups => ['support',ops','dev'],
>
> Obviously some groups aren't realized on all systems, so this produces an
> error when usermod is run.
> '/usr/sbin/usermod -G support,ops,dev jrhett' returned 6: usermod: unknown
> group dev
> usermod: unknown group dev
>
> So I tried to get smarter, and put logic to add the group to each member
> under the appropriate class
> Class users::dev inherits users {
> User['jrhett'] { groups +> ['dev'] }
> }
>
> This works… almost. It works for all instances where the user is only
> subclassed once. But if I do the same technique in multiple classes I get
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Parameter 'groups' is already set on User_and_key[jrhett] by
> #<Puppet::Resource::Type:0x7f4feed2d828> at
> /etc/puppet/modules/users/manifests/support.pp:22; cannot redefine at
> /etc/puppet/modules/users/manifests/dev.pp:27 on node s2-d1.company.com
>
> So how can this be achieved, short of using an exec with an unless doing
> another exec to determine if the group exists?
>
>
If it is the case that each user always has the same potential secondary
groups, and you need to narrow the actual secondary groups to those that
are actually present, then I think you could do it without too much pain.
The main ingredients would be a list (array) of the groups that are
supposed to be present, and a custom function that forms the intersection
of two arrays. (Or you could use an inline template and split(), but yuck!)
Hiera would probably provide a good means for building the list of
available groups, which you could then use not only to filter user
definitions but also to drive virtual group realization. Here's a skeleton
of how it might work:
class auth::constants {
$available_groups = hiera('groups')
}
class auth::groups::virtual {
# Virtual group declarations, such as
@group { 'dev':
gid => 4242,
ensure => present
}
}
define auth::concrete_group () {
include 'auth::groups::virtual'
realize Group[$name]
}
class auth::groups {
include 'auth::constants'
auth::concrete_group { $auth::constants::available_groups: }
}
class auth::users::virtual {
include 'auth::constants'
# Virtual user declarations, such as
@user { 'jbolling':
uid => 4200,
gid => 4200,
groups => intersect(['dev', 'support', 'ops'],
$auth::constants::available_groups)
}
}
A few bits are omitted, most notably user realization. The main concept is
to declare what you want in the first place, rather than throwing up
something and trying to tweak it afterward, or trying to build values
incrementally. The latter two approaches tends to work poorly in Puppet
(with certain caveats).
Note also that the above is completely hypothetical. I think it would
work, but it's not based on anything I have actually implemented.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/uo9sWOQTJyMJ.
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.
