Group ensure value doesn't work like user ensure value

[Dominic Scheirlinck]

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

[Doug Forster]

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.

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

[jcbollinger]

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