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 [email protected].
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.

Reply via email to