Puppet users - Nov 2013 - Group ensure value doesn't work like user ensure value

Here''s a bit of manifest code for a user and group. Note the explicit 
ordering between the resources, but also notice we''re not explicitly 
specifying the ensure => present for either:

group {
''something'':;
} -> user {
''something'':
gid    => ''something'';
}

With the explicit ordering, I get:
> Debug: /Group[something]/before: requires User[something]
And without it, I get:
> Debug: /User[something]: Autorequiring Group[something]
So, the ordering at least seems to be noticed. But, regardless (in both 
cases), puppet attempts to add the user first, without attempting to add 
the group:
> Debug: /User[something]: Autorequiring Group[something]
> Info: Applying configuration version ''1383263341''
> Debug: Executing ''/usr/sbin/useradd -g something
something''
> Error: Could not create user something: Execution of
''/usr/sbin/useradd
-g something something'' returned 6: useradd: group
''something'' does not
exist
> Error: /User[something]/ensure: change from absent to present failed: 
Could not create user something: Execution of ''/usr/sbin/useradd -g 
something something'' returned 6: useradd: group
''something'' does not exist

The manifest code above is the only thing in the file, and I''m using 
`puppet apply` to run it to really get it down to a minimal test case.

This seems to be because a group resource without an explicit ensure => 
''present'' will never be created. However, a user resource
without an
explicit ensure will. This seems weirdly inconsistent, and there''s no 
mention of the distinction that I could see in the Type Reference 
documentation. Is it an expected difference between the types? Or just a 
matter of undefined behaviour when ensure isn''t given to resources
(some
ensure present, some do nothing)?


Regards,
Dominic

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/47f430b9-7229-401a-80a0-2e9a8f88e2dc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Dominic,

You may be running into some circular reasoning in how you are trying to
setup the group/user. The user if GID is supplied will require the group.
By linking the user as a dependency of the group causes puppet to choke.

http://docs.puppetlabs.com/references/latest/type.html#user

Autorequires: If Puppet is managing the user’s primary group (as provided
in the gid attribute), the user resource will autorequire that group. If
Puppet is managing any role accounts corresponding to the user’s roles, the
user resource will autorequire those role accounts.


On Thu, Oct 31, 2013 at 6:03 PM, Dominic Scheirlinck
<dominic@vendhq.com>wrote:
> Here''s a bit of manifest code for a user and group. Note the
explicit
> ordering between the resources, but also notice we''re not
explicitly
> specifying the ensure => present for either:
>
> group {
> ''something'':;
> } -> user {
> ''something'':
> gid    => ''something'';
> }
>
> With the explicit ordering, I get:
>
> > Debug: /Group[something]/before: requires User[something]
>
> And without it, I get:
>
> > Debug: /User[something]: Autorequiring Group[something]
>
> So, the ordering at least seems to be noticed. But, regardless (in both
> cases), puppet attempts to add the user first, without attempting to add
> the group:
>
> > Debug: /User[something]: Autorequiring Group[something]
> > Info: Applying configuration version ''1383263341''
> > Debug: Executing ''/usr/sbin/useradd -g something
something''
> > Error: Could not create user something: Execution of
''/usr/sbin/useradd
> -g something something'' returned 6: useradd: group
''something'' does not
> exist
> > Error: /User[something]/ensure: change from absent to present failed:
> Could not create user something: Execution of ''/usr/sbin/useradd
-g
> something something'' returned 6: useradd: group
''something'' does not exist
>
> The manifest code above is the only thing in the file, and I''m
using
> `puppet apply` to run it to really get it down to a minimal test case.
>
> This seems to be because a group resource without an explicit ensure =>
> ''present'' will never be created. However, a user resource
without an
> explicit ensure will. This seems weirdly inconsistent, and there''s
no
> mention of the distinction that I could see in the Type Reference
> documentation. Is it an expected difference between the types? Or just a
> matter of undefined behaviour when ensure isn''t given to resources
(some
> ensure present, some do nothing)?
>
>
> Regards,
> Dominic
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/puppet-users/47f430b9-7229-401a-80a0-2e9a8f88e2dc%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOwhAcq%3D%2BUJsbGxw69nnHMnCB-KNCw1sAvggaKabFyjs_t_GUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

On Friday, November 1, 2013 12:50:03 AM UTC-5, Doug_F
wrote:
>
> Dominic,
>
> You may be running into some circular reasoning in how you are trying to 
> setup the group/user. The user if GID is supplied will require the group. 
> By linking the user as a dependency of the group causes puppet to choke. 
>
> http://docs.puppetlabs.com/references/latest/type.html#user
>
> Autorequires: If Puppet is managing the user’s primary group (as provided 
> in the gid attribute), the user resource will autorequire that group. If 
> Puppet is managing any role accounts corresponding to the user’s roles, the
> user resource will autorequire those role accounts.
>
>
No, Dominic''s issue is not about actually about ordering relationships,
which in fact he demonstrates to be working correctly.  Autorequirements 
are never generated between resource pairs that have an explicit 
relationship declared between them -- this allows users to override 
automatic requirements, which is sometimes important.

I think Dominic is right that there is just an inconsistency here.  If a 
Group''s ''ensure'' parameter is not specified then the
group''s presence on
the system is apparently unmanaged, though I would expect that any other 
properties specified are synced when the target group is in fact present.  
A User, on the other hand, is ensured present if no ensure value is 
explicitly specified.  Neither behavior is documented.

I am uncertain whether the two behaviors are consistent across Puppet 
versions.  I seem to recall that ''ensure'' used to default to
''present'' for
a great many built-in resource types, but my memory could be faulty on 
that.  If behavior is historically consistent, even just within Puppet 3, 
then it is unlikely that PL will change it before Puppet 4, if at all.

The workaround seems to be pretty apparent: explicitly specify your 
''ensure'' values.  I think that''s a pretty good
practice anyway.  It''s
especially good for related resource types such as Group and User, because 
whether you are ensuring present or absent has additional implications on 
how your manifests are written.  If you are ensuring the User present, then 
you must manage it *after* the group (possibly by relying on the 
autorequirement), but if you are ensuring the user absent then it is best 
to manage it *before* the group.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/169dda2a-7234-4c0c-8b6c-c380d7d1cdad%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.