groups dependencies at user creation

[eduardo]

Dears all,

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 ?.


I appreciate any help,
eduardo.

[Tim Mooney]

In regard to: [Puppet Users] groups dependencies at user creation, eduardo...:

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.M...@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

[eduardo]

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.

> Tim Mooney                                             Tim.Moo...@ndsu.edu

[eduardo]

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.

[Tim Mooney]

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.M...@ndsu.edu

[Nan Liu]

On Tue, Jul 3, 2012 at 10:46 AM, Tim Mooney <Tim.M...@ndsu.edu> 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

[eduardo]

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 <n...@puppetlabs.com> wrote:

[eduardo]

It's important to say that updssh::user_keys , updssh::check_groups
and updssh::load_ssh_key are defined resource types.

[jcbollinger]

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

[eduardo]

Thanks you John, I'm taking notes.

Best Regards,
eduardo.

> automatically, and the order in which the Puppet agent *applies* resources

[Stefan Schulte]

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

[eduardo]

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 <stefan.schu...@taunusstein.net>
wrote:

[eduardo]

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 <stefan.schu...@taunusstein.net>
wrote: