Bug #13955
applying the same user resource triggers a "changed password" notice every time
| Status: | Closed | Start date: | 04/16/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Gary Larizza | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | ||||
Description
On a Mac OS X 10.7.3 machine running puppet 2.7.12, applying the exact same user resource triggers a “changed password” notice on every run. Here’s some sample output with a test user and a throwaway hash (password ‘b’):
$ sudo puppet apply
user { 'testuser':
ensure => 'present',
comment => 'testuser',
home => '/Users/testuser',
password => 'B5B66261296695D4A530BD3E1FA59524B5AABE534015FD2838F11B89ABE33A3DBF1A9AE8C84BF56CE7CAC52A5E485047F6426AE2090FE1DF093FBEC9E411731983F2C95E',
shell => '/bin/bash',
uid => '1000',
}
notice: /Stage[main]//User[testuser]/ensure: created
notice: Finished catalog run in 4.88 seconds
$ sudo puppet apply
user { 'testuser':
ensure => 'present',
comment => 'testuser',
home => '/Users/testuser',
password => 'B5B66261296695D4A530BD3E1FA59524B5AABE534015FD2838F11B89ABE33A3DBF1A9AE8C84BF56CE7CAC52A5E485047F6426AE2090FE1DF093FBEC9E411731983F2C95E',
shell => '/bin/bash',
uid => '1000',
}
notice: /Stage[main]//User[testuser]/password: changed password
notice: Finished catalog run in 0.60 seconds
I’ve attached full output of sudo ruby --debug /usr/bin/puppet apply --color no --trace --debug.
History
#1
Updated by Clay Caviness about 1 year ago
I’m seeing this with 2.7.10 as well.
NB: It is actually setting it correctly on initial creation, and if I change the password hash it’s applied correctly (i.e., new password works). The issue is multiple applications of the unchanged resource trigger a “changed” notice.
#2
Updated by Daniel Pittman about 1 year ago
- Status changed from Unreviewed to Investigating
- Assignee set to Gary Larizza
#3
Updated by Gary Larizza about 1 year ago
I’m able to replicate this behavior, so I worry we’ve lost idempotence in this provider :(
#4
Updated by Gary Larizza about 1 year ago
Clay, can you try with this string on your end —> ‘b5b66261296695d4a530bd3e1fa59524b5aabe534015fd2838f11b89abe33a3dbf1a9ae8c84bf56ce7cac52a5e485047f6426ae2090fe1df093fbec9e411731983f2c95e’
I believe the problem is….upper case letters (facepalm)
I’ll have to cast the input from resourece[:password] to lower case so we don’t run into this.
#5
Updated by Gary Larizza about 1 year ago
So the problem is that we’re using self.instances to build an array of instances. When you fetch the password from the system, it’s using lower case letters. There is no comparison method (a la ‘def password’) because we’re using prefetching – it will ONLY compare with against our array of resource instances. We also can’t munge the value in the type since this is the user type and the password property – and the hashing mechanism changes between OSes and versions.
I think the solution here might be to re-implement the should method so we can cast things to lower case…but I dunno if we can re-implement should for JUST the password property.
#6
Updated by Gary Larizza about 1 year ago
Yeah, so re-implementing the should method requires doing it for the password property of the user type, which is bad. I think the solution here is to document this and only use lower-case letters in the password hash on 10.7. You CAN use upper-case letters, but it’s going to refresh every time (and the password will actually work just fine).
The function in stdlib to build hashes outputs lowercase letters, and Apple itself will output a hash with lowercase letters, so we’re gonna stick with that :)
#7
Updated by Clay Caviness about 1 year ago
Sounds fine to me.
#8
Updated by Gary Larizza 11 months ago
- Status changed from Investigating to Closed
Closing the ticket as the solution is to use lower-case letters.