Unfortunately, this does not work either. Here's a complete standalone
puppet manifest you can do "puppet apply" on. No users are actually being
realized.
I don't believe "User <| group == $name |>" works.
:(
Rajul
node default {
class { 'usergroups':
}
}
class virtusers {
group { 'A': ensure => present }
group { 'B': ensure => present }
group { 'C': ensure => present }
@user { 'one':
ensure => present,
uid => 5001,
groups => [ 'A' ]
}
@user { 'two':
ensure => present,
uid => 5002,
groups => [ 'B' ]
}
@user { 'three':
ensure => present,
uid => 5003,
groups => [ 'C' ]
}
}
class usergroups {
include virtusers
define realize_helper( ) {
User <| group == $name |>
}
### none of these work
#$group_list = [ 'A', 'B' ]
$group_list = 'A'
realize_helper { $group_list: }
}
On Friday, November 16, 2012 11:25:15 AM UTC-8, Rajul Vora wrote:
>
> Yes, I was actually thinking of doing that after I sent my reply to you -
> based on your mymodule::usergroup defined resource idea. Thanks for
> confirming that idea. I'll implement it and it will work for what I am
> trying to do.
>
> Simple is better.
>
> Rajul
>
> On Friday, November 16, 2012 11:16:36 AM UTC-8, jcbollinger wrote:
>>
>>
>>
>> On Friday, November 16, 2012 11:07:18 AM UTC-6, Rajul Vora wrote:
>>>
>>>
>>> Thanks for the effort in explaining these alternatives. I apologize I
>>> didn't do justice to explaining the bigger picture in the first place.
>>>
>>> So here it goes:
>>>
>>> Goal: Use hiera to provision different groups of users in different
>>> environments.
>>>
>>> Approach: First create virtual users from hiera that lists all possible
>>> users and then realizing "collection" of users that are also defined in
>>> hiera using the <| expression |> to combine various groups. I like this
>>> approach because I can list every possible user in a single hiera file so I
>>> can keep the UIDs sequential as I add new users, etc.
>>>
>>> So the main problem here is that the thing that goes between the
>>> spaceship operators is dynamic.
>>>
>>
>>
>> Yes, but to support only what you describe, it doesn't need to be nearly
>> as dynamic as you're trying to make it. Inasmuch as you are choosing which
>> users to realize based on their groups, the defined type example in my
>> previous message should get you most of the way to where you want to go.
>> The key to making it work for you would be to change from using the
>> 'system::realize_users' collection predicate to using a plain array of the
>> user groups you want. For example,
>>
>> production.yaml:
>> mymodule::usergroups:
>> - A
>>
>> qa.yaml:
>> mymodule::usergroups:
>> - A
>> - B
>>
>> dev.yaml:
>> mymodule::usergroups: ALL
>>
>> Then you realize them with a class such as this one:
>>
>> class mymodule::systemusers {
>> $usergroups = hiera('mymodule::usergroups')
>>
>> if $usergroups == 'ALL' {
>> User <| |>
>> } else {
>> mymodule::usergroup { $usergroups: }
>> }
>> }
>>
>> If $usergroups is an array then that calls for one mymodule::usergroup
>> instance per element; if it is a scalar then you will get just one. Also,
>> be aware that it is not a problem to realize / collect the same virtual
>> User multiple times so long as you do not override any properties when you
>> collect. On the other hand, users have only one primary group, so you're
>> not going to have collisions selecting only on group.
>>
>> There are, of course, many other ways to do it, including some involving
>> playing various clever tricks with your data. If all you need is to select
>> users based on values of one property (at a time), however, then the above
>> is a pretty good way.
>>
>>
>> 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/-/lEpYYdoxXO4J.
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.
