expiry attribut of users applied every time

[digrouz]

Hello,

I have class users with manage some user accounts. for some of them i have set the expiry attribut in the past '2012-01-01' to disable the account.

The problem is that puppet set this expiration date at every run:
...
/Stage[main]/Users/User[xxxxx]/expiry: defined 'expiry' as '2012-01-01'
...


What is wrong?

Thanks in advance.

[Jeff McCune]

What operating system is this on? I'd like to try and reproduce the issue.

A common issue is that the input string doesn't match the string
Puppet is getting back from the system so Puppet always thinks there
is a mis-match. In these cases, it might help to use the `puppet
resource user foo` command to see what value for expiry Puppet is
receiving from the system.

-Jeff

[digrouz]

I'm experencing this issue on both Red Hat 5 and 6.

I'll post the output of the puppet resource user foo tomorrow when i'll be at work.

it seems that this is an active bug: http://projects.puppetlabs.com/issues/11675#change-73099

[digrouz]

Hello,

Here is the output. It seems strange as puppet resource user foo does not return something about expiry. Even if it's set correctly as chage -l is showing. Does this help?

[root@host ~]# puppet resource user foo
user { 'foo':
  ensure           => 'present',
  comment          => 'userfoo',
  gid              => '2111',
  groups           => ['group1'],
  home             => '/home/foo',
  password         => '$6$Poreu0cX$LOCKEDBYPUPPET',
  password_max_age => '99999',
  password_min_age => '0',
  shell            => '/bin/bash',
  uid              => '2113',
}
[root@host ~]# chage -l foo
Last password change                                    : Jul 27, 2012
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : Jan 01, 2012
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

[Jeff McCune]

Nicholas,

An easy way to reproduce the problem is to run `puppet resource` a number of consecutive times.  We expect subsequent executions of Puppet to be idempotent, but they're clearly not:

root@puppetmaster:~# puppet resource user jefftest expiry=2012-01-01

/User[jefftest]/expiry: defined 'expiry' as '2012-01-01'

user { 'jefftest':

  ensure => 'present',

}

root@puppetmaster:~# puppet resource user jefftest expiry=2012-01-01

/User[jefftest]/expiry: defined 'expiry' as '2012-01-01'

user { 'jefftest':

  ensure => 'present',

}

root@puppetmaster:~# puppet resource user jefftest expiry=2012-01-01

/User[jefftest]/expiry: defined 'expiry' as '2012-01-01'

user { 'jefftest':

  ensure => 'present',

}

A common trick I employ in situations like these is to run with debugging turned on.  This should display the value Puppet thinks the parameter _should_ be, which is what we specify in the manifest or on the command line, versus what the parameter _is_ on the system.  If they mis-match, then I change my manifest to match the "is" value and that usually makes Puppet idempotent again.

Unfortunately, in this case we're not getting the "is" values in the debug output.  =(

root@puppetmaster:~# puppet resource user jefftest expiry=2012-01-01 --debug

Debug: Puppet::Type::User::ProviderLdap: true value when expecting false

Debug: Puppet::Type::User::ProviderPw: file pw does not exist

Debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist

Debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does not exist

Debug: Loaded state in 0.00 seconds

Debug: Executing '/usr/sbin/usermod -e 2012-01-01 jefftest'

/User[jefftest]/expiry: defined 'expiry' as '2012-01-01'

Debug: Finishing transaction 70035535867960

Debug: Storing state

Debug: Stored state in 0.00 seconds

user { 'jefftest':

  ensure => 'present',

}

So then I dive into the ruby debugger.  I used ack to search for "defined '" in the l ib/ directory and came up with this:

https://github.com/puppetlabs/puppet/blob/3.0.x/lib/puppet/property.rb#L104-106

So Puppet is thinking the current value from the system is totally absent.  We can't make this idempotent as a result.  This is definitely a bug, would you mind filing it?  If so, I'd be happy to do so on your behalf, but bugs from users are always better than bugs I report.

Please feel free to add me as a watcher, I'll update it with the information I found.

Hope this helps,

-Jeff

[Stefan Schulte]

On Thu, Oct 11, 2012 at 10:47:41AM -0700, Jeff McCune wrote:
> Nicholas,
>
> [...]

> We can't make this idempotent as a result. This is definitely a bug,
> would you mind filing it? If so, I'd be happy to do so on your behalf, but
> bugs from users are always better than bugs I report.
>
> Please feel free to add me as a watcher, I'll update it with the
> information I found.
>
> Hope this helps,
> -Jeff
>

As Nicolas stated there already is a bug report:
http://projects.puppetlabs.com/issues/11675#change-73099

Puppet simply does not check the current state at (it is not even
implemented anywhere in the code, at least I have not found it)

-Stefan

[Jeff McCune]

On Oct 11, 2012, at 12:13 PM, Stefan Schulte

<stefan....@taunusstein.net> wrote:

> On Thu, Oct 11, 2012 at 10:47:41AM -0700, Jeff McCune wrote:
>> Nicholas,
>>
>> [...]
>> We can't make this idempotent as a result. This is definitely a bug,
>> would you mind filing it? If so, I'd be happy to do so on your behalf, but
>> bugs from users are always better than bugs I report.
>>
>> Please feel free to add me as a watcher, I'll update it with the
>> information I found.
>>
>> Hope this helps,
>> -Jeff
>
> As Nicolas stated there already is a bug report:
> http://projects.puppetlabs.com/issues/11675#change-73099

Ah thanks. I missed that while on my phone.

> Puppet simply does not check the current state at (it is not even
> implemented anywhere in the code, at least I have not found it)

I'll try and get this fixed as soon as possible. That's really disappointing.

> -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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[digrouz]

Hello,

Any updates when the fix will be implemented?

[Stefan Schulte]

On Wed, Dec 12, 2012 at 04:19:17AM -0800, digrouz wrote:
> Hello,
>
> Any updates when the fix will be implemented?
>
>

Hi digrouz,

I am currently assigned to the ticket
http://projects.puppetlabs.com/issues/11675 and have done some work
already. The problem is that I first have to improve the test coverage
to do any real changes so it is more work than I had expected.

I hope I'll have a pull request ready around christmas.

-Stefan