[Puppet Users] Re: groups dependencies at user creation
Thanks you very much Stefan. Testing were tell me something like that
exactly. But I can't reach an autorequiring reason like you did by
debug output.
It's a shame not having had prior nevertheless you are not only
clarifying me about that but also simplify my recipe. So finally I can
rest without any fear about not have Group -> User dependencies
explicitly in it, in fact puppet is smart enough as i was suspecting .
I appreciate all help, this time particularly to Stefan.
Best Regards,
eduardo.
On 7 jul, 11:19, Stefan Schulte
wrote:
> On Mon, Jul 02, 2012 at 12:20:40PM -0500, Tim Mooney wrote:
> > > How to ensure groups dependencies at user creation ?.
>
> > If you were just talking about the user's default group, then it would
> > be one of the few cases where puppet establishes an ordering relation
> > for you automatically. In other words:
>
> > user { 'foo':
> > gid => 'bar',
> > }
>
> > automatically ensures that group 'bar' is present before user 'foo'.
>
> > I don't know if that same thing is true for supplemental groups
>
> It is also true for supplemental groups. You can see puppet creates the
> relationship when you run puppet agent / puppet apply in debug mode.
>
> So when I run
>
> # puppet apply -vd --noop << EOF
> group { ['foo', 'bar']:ensure => present }
> user { 'bob': groups => [ 'foo', 'bar' ], ensure => present }
> EOF
>
> I get
>
> debug: /Stage[main]//User[bob]: Autorequiring Group[bar]
> debug: /Stage[main]//User[bob]: Autorequiring Group[foo]
>
> -Stefan
--
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.
[Puppet Users] Re: groups dependencies at user creation
Dears all,
Thanks nan your your suggestion, I took it (again) in account trying
to do something better. Thanks john for your puppet's lesson. I'd
never been worked with declarative system, noticeably it's demand a
different way of think than in typical imperative system.
I have done a new version having :
1) Custom function having input groups membership for all users
comming from ENC. Return an array having unique items (groups). I
prefer this instead of modify ENC for explicitness reason of input
json.
2) New defined type (main_groups) to ensuring group existence. I
discard 'defined' function like john suggest me. I suggest to
PuppetLabs team write a caution or warning about defined function at
documents.
3) New defined type (dep_groups) just like nan suggested to me, which
it's to ensuring dependencies.
Testing are good and i hope this approach can be less hurtful for
puppet design and obviously for my good health.
I appreciate all your help
Best Regards,
eduardo.
PD : The following are details of this approach .
-
class updssh( $users ) {
$all_groups = inline_template(
"<% users.each do |usr| -%><% usr.each do |k,v| -%><%= usr[k]
['groups'] %>;<% end -%><% end -%>")
# Custom function groups_uniq take all groups field values having
user's membership
# Return array having unique items(groups)
$groups_uniq = groups_uniq($all_groups)
# Ensuring group existence for membership of users
main_groups { $groups_uniq: }
# guarantee main groups existence for user's membership
define main_groups {
$group = $title
group { $group:
ensure => present
}
}
-
define updssh::add_user ( $email , $groups ) {
$username = $title
$usr_grp = inline_template(
"<% groups.each do |grp| -%><%= username %>_<%= grp %>,<
% end -%>
")
$usr_groups = split($usr_grp, ',')
dep_groups { $usr_groups: }
...
}
# Ensuring dependencies
define dep_groups {
$arr = split($title, '_')
$username = $arr[0]
$group = $arr[1]
notify {"Ensuring dependencies ${title}": }
Group[$group] -> User[$username]
}
-
On 7 jul, 11:19, Stefan Schulte
wrote:
> On Mon, Jul 02, 2012 at 12:20:40PM -0500, Tim Mooney wrote:
> > > How to ensure groups dependencies at user creation ?.
>
> > If you were just talking about the user's default group, then it would
> > be one of the few cases where puppet establishes an ordering relation
> > for you automatically. In other words:
>
> > user { 'foo':
> > gid => 'bar',
> > }
>
> > automatically ensures that group 'bar' is present before user 'foo'.
>
> > I don't know if that same thing is true for supplemental groups
>
> It is also true for supplemental groups. You can see puppet creates the
> relationship when you run puppet agent / puppet apply in debug mode.
>
> So when I run
>
> # puppet apply -vd --noop << EOF
> group { ['foo', 'bar']:ensure => present }
> user { 'bob': groups => [ 'foo', 'bar' ], ensure => present }
> EOF
>
> I get
>
> debug: /Stage[main]//User[bob]: Autorequiring Group[bar]
> debug: /Stage[main]//User[bob]: Autorequiring Group[foo]
>
> -Stefan
--
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.
[Puppet Users] Re: groups dependencies at user creation
Thanks you John, I'm taking notes.
Best Regards,
eduardo.
On 5 jul, 09:48, jcbollinger wrote:
> On Tuesday, July 3, 2012 4:43:24 PM UTC-5, eduardo wrote:
>
> > Thanks your answers.
> > I don't figure out how avoid execute because i have a massive input
> > account by ENC json setting all users and membership of each one of
> > them. I had to make uniq entries array to avoid Duplicate definition
> > error condition because many users could (in fact are) belong to a
> > same group.
>
> That sounds like a different issue. Certainly you should be sure that your
> ENC does not emit redundant data, but the involvement of an ENC or lots of
> data does not speak to the solution Nan suggested.
>
> > May be i miss something but i think that i can benefit from working
> > with defined resource types
> > (vs classes) so the same nesting call is setting dependencies
> > implicitly.
>
> Likely you can indeed benefit from careful application of defined types,
> but that doesn't really have anything to do with implicit dependencies
> (a.k.a. "autorequires").
>
>
>
> > For example a big picture of nesting call in my recipe is something
> > like :
>
> > class updssh( $users ) -> Parameter class having json as input.
> > └── user_keys { $arrays_users: } Call it foreach user.
> > ├── updssh::check_groups { $usr_groups: } Call it for ensure
> > membership of user
> > └── updssh::load_ssh_key{ $user_ssh : Call it to set account
> > (create/update)
>
> Your language and naming shows that you are thinking of classes and
> resources as actions, but that conflicts with Puppet's design. Puppet
> classes and resources are things (nouns). That includes defined type
> instances. Class and resource declarations are not instructions to Puppet
> to do something (not even Execs), but rather descriptions of the state that
> the target node is supposed to be in. You need to understand this to
> master Puppet.
>
> > So I don't see dependencies like any problem because the nesting call
> > is doing by self.
> > Testing are tell me that nevertheless , i'm wondering , Am i wrong ?
>
> Are you asking whether you need to express the relationships between User
> resources and the Group resources representing their secondary groups?
> Yes, you do. Puppet does not generate those particular relationships
> automatically, and the order in which the Puppet agent *applies* resources
> is constrained only by resource relationships. In particular, that order
> has nothing to do with the order in which resource declarations were
> parsed. You need to be sure the secondary groups should already exist
> before you manage users that are supposed to belong to them, so you need to
> declare relationships between them.
>
> > Even knowing it's the first version i have to confess that i'm happy
> > with it because not only resolve dependencies by self but also it
> > create groups that don't exist. Also i enjoy using functions like
> > 'defined' which it's great to check current status.
>
> I'm glad you're pleased (now), but you are setting yourself up for pain.
> In particular, you should avoid the 'defined' function at all costs, as it
> introduces problematic and unneeded parse-order dependencies. With an ENC
> at your disposal, 'defined' doesn't even give you anything that you cannot
> easily achieve by other means.
>
> It's not clear to me what practical problems you may now be facing, so I'm
> going to leave it at commentary for the time being.
>
> John
--
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.
[Puppet Users] Re: groups dependencies at user creation
On Tuesday, July 3, 2012 4:43:24 PM UTC-5, eduardo wrote:
>
> Thanks your answers.
> I don't figure out how avoid execute because i have a massive input
> account by ENC json setting all users and membership of each one of
> them. I had to make uniq entries array to avoid Duplicate definition
> error condition because many users could (in fact are) belong to a
> same group.
>
That sounds like a different issue. Certainly you should be sure that your
ENC does not emit redundant data, but the involvement of an ENC or lots of
data does not speak to the solution Nan suggested.
> May be i miss something but i think that i can benefit from working
> with defined resource types
> (vs classes) so the same nesting call is setting dependencies
> implicitly.
>
Likely you can indeed benefit from careful application of defined types,
but that doesn't really have anything to do with implicit dependencies
(a.k.a. "autorequires").
>
> For example a big picture of nesting call in my recipe is something
> like :
>
> class updssh( $users ) -> Parameter class having json as input.
> └── user_keys { $arrays_users: } Call it foreach user.
> ├── updssh::check_groups { $usr_groups: } Call it for ensure
> membership of user
> └── updssh::load_ssh_key{ $user_ssh : Call it to set account
> (create/update)
>
Your language and naming shows that you are thinking of classes and
resources as actions, but that conflicts with Puppet's design. Puppet
classes and resources are things (nouns). That includes defined type
instances. Class and resource declarations are not instructions to Puppet
to do something (not even Execs), but rather descriptions of the state that
the target node is supposed to be in. You need to understand this to
master Puppet.
> So I don't see dependencies like any problem because the nesting call
> is doing by self.
> Testing are tell me that nevertheless , i'm wondering , Am i wrong ?
>
Are you asking whether you need to express the relationships between User
resources and the Group resources representing their secondary groups?
Yes, you do. Puppet does not generate those particular relationships
automatically, and the order in which the Puppet agent *applies* resources
is constrained only by resource relationships. In particular, that order
has nothing to do with the order in which resource declarations were
parsed. You need to be sure the secondary groups should already exist
before you manage users that are supposed to belong to them, so you need to
declare relationships between them.
> Even knowing it's the first version i have to confess that i'm happy
> with it because not only resolve dependencies by self but also it
> create groups that don't exist. Also i enjoy using functions like
> 'defined' which it's great to check current status.
>
I'm glad you're pleased (now), but you are setting yourself up for pain.
In particular, you should avoid the 'defined' function at all costs, as it
introduces problematic and unneeded parse-order dependencies. With an ENC
at your disposal, 'defined' doesn't even give you anything that you cannot
easily achieve by other means.
It's not clear to me what practical problems you may now be facing, so I'm
going to leave it at commentary for the time being.
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/-/cHEwQzBaMk4J.
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.
[Puppet Users] Re: groups dependencies at user creation
It's important to say that updssh::user_keys , updssh::check_groups
and updssh::load_ssh_key are defined resource types.
On 3 jul, 17:43, eduardo wrote:
> Thanks your answers.
> I don't figure out how avoid execute because i have a massive input
> account by ENC json setting all users and membership of each one of
> them. I had to make uniq entries array to avoid Duplicate definition
> error condition because many users could (in fact are) belong to a
> same group.
>
> May be i miss something but i think that i can benefit from working
> with defined resource types
> (vs classes) so the same nesting call is setting dependencies
> implicitly.
>
> For example a big picture of nesting call in my recipe is something
> like :
>
> class updssh( $users ) -> Parameter class having json as input.
> └── user_keys { $arrays_users: } Call it foreach user.
> ├── updssh::check_groups { $usr_groups: } Call it for ensure
> membership of user
> └── updssh::load_ssh_key{ $user_ssh : Call it to set account
> (create/update)
>
> So I don't see dependencies like any problem because the nesting call
> is doing by self.
> Testing are tell me that nevertheless , i'm wondering , Am i wrong ?
>
> Even knowing it's the first version i have to confess that i'm happy
> with it because not only resolve dependencies by self but also it
> create groups that don't exist. Also i enjoy using functions like
> 'defined' which it's great to check current status.
>
> Regards,
> eduardo.
>
> On 3 jul, 13:57, Nan Liu wrote:
>
>
>
>
>
>
>
> > On Tue, Jul 3, 2012 at 10:46 AM, Tim Mooney wrote:
> > > In regard to: [Puppet Users] Re: groups dependencies at user creation,...:
>
> > >> Thanks tim for answer me, The fact is $groups is an array, so when i
> > >> try something like this
>
> > >> --
> > >> Group[$groups] -> User[$username]
>
> > >> user { $username:
> > >> comment => "$email",
> > >> home => "/home/$username",
> > >> shell => "/bin/bash",
> > >> password => "!!",
> > >> groups => $groups
> > >> }
>
> > >> --
>
> > >> I'd got :
>
> > >> err: Could not retrieve catalog from remote server: Error 400 on
> > >> SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
> > >> for relationship on 'User[ppuser7]' on node casa
>
> > > I was afraid that might be the case, but thought it was worth a try.
>
> > > Does this work better:
>
> > > $groups_as_array = split($groups, ',')
> > > Groups[$groups_as_array] -> User[$username]
>
> > AFAIK, the short hand syntax doesn't support array values, and you
> > need something like a define resource type to wrap this.
>
> > define group_dep($username) {
> > Groups[$name] -> User[$username]
>
> > }
>
> > group_dep { $group_as_array :
> > username => $username,
>
> > }
>
> > Nan
--
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.
[Puppet Users] Re: groups dependencies at user creation
Thanks your answers.
I don't figure out how avoid execute because i have a massive input
account by ENC json setting all users and membership of each one of
them. I had to make uniq entries array to avoid Duplicate definition
error condition because many users could (in fact are) belong to a
same group.
May be i miss something but i think that i can benefit from working
with defined resource types
(vs classes) so the same nesting call is setting dependencies
implicitly.
For example a big picture of nesting call in my recipe is something
like :
class updssh( $users ) -> Parameter class having json as input.
└── user_keys { $arrays_users: } Call it foreach user.
├── updssh::check_groups { $usr_groups: } Call it for ensure
membership of user
└── updssh::load_ssh_key{ $user_ssh : Call it to set account
(create/update)
So I don't see dependencies like any problem because the nesting call
is doing by self.
Testing are tell me that nevertheless , i'm wondering , Am i wrong ?
Even knowing it's the first version i have to confess that i'm happy
with it because not only resolve dependencies by self but also it
create groups that don't exist. Also i enjoy using functions like
'defined' which it's great to check current status.
Regards,
eduardo.
On 3 jul, 13:57, Nan Liu wrote:
> On Tue, Jul 3, 2012 at 10:46 AM, Tim Mooney wrote:
> > In regard to: [Puppet Users] Re: groups dependencies at user creation,...:
>
> >> Thanks tim for answer me, The fact is $groups is an array, so when i
> >> try something like this
>
> >> --
> >> Group[$groups] -> User[$username]
>
> >> user { $username:
> >> comment => "$email",
> >> home => "/home/$username",
> >> shell => "/bin/bash",
> >> password => "!!",
> >> groups => $groups
> >> }
>
> >> --
>
> >> I'd got :
>
> >> err: Could not retrieve catalog from remote server: Error 400 on
> >> SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
> >> for relationship on 'User[ppuser7]' on node casa
>
> > I was afraid that might be the case, but thought it was worth a try.
>
> > Does this work better:
>
> > $groups_as_array = split($groups, ',')
> > Groups[$groups_as_array] -> User[$username]
>
> AFAIK, the short hand syntax doesn't support array values, and you
> need something like a define resource type to wrap this.
>
> define group_dep($username) {
> Groups[$name] -> User[$username]
>
> }
>
> group_dep { $group_as_array :
> username => $username,
>
> }
>
> Nan
--
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.
Re: [Puppet Users] Re: groups dependencies at user creation
On Tue, Jul 3, 2012 at 10:46 AM, Tim Mooney wrote:
> In regard to: [Puppet Users] Re: groups dependencies at user creation,...:
>
>
>> Thanks tim for answer me, The fact is $groups is an array, so when i
>> try something like this
>>
>> --
>>Group[$groups] -> User[$username]
>>
>>user { $username:
>>comment => "$email",
>>home=> "/home/$username",
>>shell => "/bin/bash",
>>password => "!!",
>>groups => $groups
>>}
>>
>> --
>>
>> I'd got :
>>
>> err: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
>> for relationship on 'User[ppuser7]' on node casa
>
>
> I was afraid that might be the case, but thought it was worth a try.
>
> Does this work better:
>
> $groups_as_array = split($groups, ',')
> Groups[$groups_as_array] -> User[$username]
AFAIK, the short hand syntax doesn't support array values, and you
need something like a define resource type to wrap this.
define group_dep($username) {
Groups[$name] -> User[$username]
}
group_dep { $group_as_array :
username => $username,
}
Nan
--
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.
Re: [Puppet Users] Re: groups dependencies at user creation
In regard to: [Puppet Users] Re: groups dependencies at user creation,...:
Thanks tim for answer me, The fact is $groups is an array, so when i
try something like this
--
Group[$groups] -> User[$username]
user { $username:
comment => "$email",
home=> "/home/$username",
shell => "/bin/bash",
password => "!!",
groups => $groups
}
--
I'd got :
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
for relationship on 'User[ppuser7]' on node casa
I was afraid that might be the case, but thought it was worth a try.
Does this work better:
$groups_as_array = split($groups, ',')
Groups[$groups_as_array] -> User[$username]
? I have my doubts, but it's what I would try next.
Note that split() is part of the default set of functions that are part
of puppet. For more info on functions, see
http://docs.puppetlabs.com/references/stable/function.html
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
[Puppet Users] Re: groups dependencies at user creation
Dears all, I'd got a solution , far away from the best because it's
based on execute method and also because it's not use Group[$groups] -
> User[$username] dependencies way.
Testing something like this are good :
$a_groups = inline_template(
"<% groups.each do |grp| -%> <%= username %>_<%= grp %>,<
% end -%>")
$usr_groups = split($a_groups, ',')
updssh::check_groups { $usr_groups: }
-
define updssh::check_groups {
$arr = split($title, '_')
$usr = $arr[0]
$group = $arr[1]
if ! defined(Group[$group]) {
group { $group:
ensure => present
}
}
}
I'm pretty sure it's a first one version that it's giving to me a
chance to go on.
Best Regards,
eduardo.
On 2 jul, 17:06, eduardo wrote:
> Thanks tim for answer me, The fact is $groups is an array, so when i
> try something like this
>
> --
> Group[$groups] -> User[$username]
>
> user { $username:
> comment => "$email",
> home => "/home/$username",
> shell => "/bin/bash",
> password => "!!",
> groups => $groups
> }
>
> --
>
> I'd got :
>
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
> for relationship on 'User[ppuser7]' on node casa
>
> Is there any way to work around ?.
>
> Regards,
> eduardo.
>
> On 2 jul, 13:20, Tim Mooney wrote:
>
>
>
>
>
>
>
> > In regard to: [Puppet Users] groups dependencies at user creation,
> > eduardo...:
>
> > > I'm trying to create new users members of some groups so it's need
> > > to ensure they exist before user creation.
>
> > > I have something like :
>
> > >
> > > define updssh::add_user ( $email , $groups ) {
>
> > > $username = $title
>
> > > user { $username:
> > > comment => "$email",
> > > home => "/home/$username",
> > > shell => "/bin/bash",
> > > password => "!!",
> > > groups => $groups
> > > }
>
> > > --
>
> > > How to ensure groups dependencies at user creation ?.
>
> > If you were just talking about the user's default group, then it would
> > be one of the few cases where puppet establishes an ordering relation
> > for you automatically. In other words:
>
> > user { 'foo':
> > gid => 'bar',
> > }
>
> > automatically ensures that group 'bar' is present before user 'foo'.
>
> > I don't know if that same thing is true for supplemental groups, but if
> > it's not, I would first try using the -> notation to establish ordering,
> > like this
>
> > Group[$groups] -> User[$username]
>
> > Does that work for you?
>
> > Tim
> > --
> > Tim Mooney tim.moo...@ndsu.edu
> > Enterprise Computing & Infrastructure 701-231-1076 (Voice)
> > Room 242-J6, IACC Building 701-231-8541 (Fax)
> > North Dakota State University, Fargo, ND 58105-5164
--
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.
[Puppet Users] Re: groups dependencies at user creation
Thanks tim for answer me, The fact is $groups is an array, so when i
try something like this
--
Group[$groups] -> User[$username]
user { $username:
comment => "$email",
home=> "/home/$username",
shell => "/bin/bash",
password => "!!",
groups => $groups
}
--
I'd got :
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
for relationship on 'User[ppuser7]' on node casa
Is there any way to work around ?.
Regards,
eduardo.
On 2 jul, 13:20, Tim Mooney wrote:
> In regard to: [Puppet Users] groups dependencies at user creation, eduardo...:
>
>
>
>
>
>
>
>
>
> > I'm trying to create new users members of some groups so it's need
> > to ensure they exist before user creation.
>
> > I have something like :
>
> >
> > define updssh::add_user ( $email , $groups ) {
>
> > $username = $title
>
> > user { $username:
> > comment => "$email",
> > home => "/home/$username",
> > shell => "/bin/bash",
> > password => "!!",
> > groups => $groups
> > }
>
> > --
>
> > How to ensure groups dependencies at user creation ?.
>
> If you were just talking about the user's default group, then it would
> be one of the few cases where puppet establishes an ordering relation
> for you automatically. In other words:
>
> user { 'foo':
> gid => 'bar',
> }
>
> automatically ensures that group 'bar' is present before user 'foo'.
>
> I don't know if that same thing is true for supplemental groups, but if
> it's not, I would first try using the -> notation to establish ordering,
> like this
>
> Group[$groups] -> User[$username]
>
> Does that work for you?
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure 701-231-1076 (Voice)
> Room 242-J6, IACC Building 701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
--
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.
