Bug #4402

directoryservice user provider on darwin 10.4 (tiger) won't manage passwords

Added by eric sorenson over 1 year ago. Updated 3 months ago.

Status:Needs More Information Start date:07/30/2010
Priority:Normal Due date:
Assignee:eric sorenson % Done:

0%
Category:provider
Target version:-
Affected Puppet version:0.25.5 Branch:
Keywords:directoryservice, osx, tiger, 10.4
Votes: 0

Description

I’m seeing an odd problem trying to update passwords on my tiger systems w/0.25.5 – the following steps reproduce the problem:

passwd root
new password: changeme

dscl . -read /Users/root GeneratedUID 

cp /var/db/shadow/hash/ /var/tmp/root.pass

passwd root
new password: 

echo 'user { "root": password => file("/var/tmp/root.pass") }' | puppet --debug

debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl -url . -list /Users'
debug: Puppet::Type::User::ProviderDirectoryservice: Executing '/usr/bin/dscl -url . -read /Users/root'
debug: //User[root]: Changing password
debug: //User[root]: 1 change(s)
debug: User[root](provider=directoryservice): Executing '/usr/bin/dscl -url . -read /Users/root GeneratedUID'
err: //User[root]/password: change from [[BIG GIANT STRING]] to [[CONTENTS OF /var/tmp/root.pass]] failed: The directoryservice provider can not handle attribute password at line 1
debug: Finishing transaction 10895500 with 1 changes

The same code works on Leopard, so this is puzzling.

The provider clearly has :manages_password and there’s a ‘password=’ method in the parent nameservice/directoryservice.rb so we should be good, right?

History

#1
Updated by Igal Koshevoy over 1 year ago

  • Assignee set to James Turnbull

James: Can you please reassign this issue to the Puppet project?

#2
Updated by eric sorenson over 1 year ago

  • Assignee deleted (James Turnbull)

Doh, I was perusing dashboard stuff when I filed this issue, didn’t realise it would be associated with the wrong project. Sorry.

#3
Updated by James Turnbull over 1 year ago

  • Project changed from Puppet Dashboard to Puppet

#4
Updated by James Turnbull over 1 year ago

  • Status changed from Unreviewed to Investigating
  • Assignee set to Jeff McCune

Jeff – any ideas?

#5
Updated by Jeff McCune over 1 year ago

  • Category set to provider
  • Assignee deleted (Jeff McCune)
  • Affected Puppet version set to 0.25.5
  • Keywords changed from directoryservice osx to directoryservice, osx, tiger, 10.4

Yes, I’m thinking the dscl execution vector being used works OK on 10.5 and 10.6, but there’s an argument in there dscl on 10.4 doesn’t like.

Unfortunately, I have no access to a Tiger (10.4) mac OS X workstation. I’m going to assign this back to the community and hope someone with access to a 10.4 system could verify this hypothesis.

I recommend installing the ruby-debug gem, and calling “debugger” around: lib/puppet/provider/nameservice/directoryservice.rb:361

Please find out what the execution vector looks like, then try and call manually in the shell. I suspect one of the arguments is not valid on 10.4 and needs to be adjusted.

-Jeff

#6
Updated by eric sorenson over 1 year ago

I modified puppet/provider.rb thusly, to get the name of the method that’s failing out with NoMethodError.


diff --git a/lib/puppet/property.rb b/lib/puppet/property.rb
index 7d5edcf..6618de9 100644
--- a/lib/puppet/property.rb
+++ b/lib/puppet/property.rb
@@ -92,9 +92,9 @@ class Puppet::Property < Puppet::Parameter
     def call_provider(value)
         begin
             provider.send(self.class.name.to_s + "=", value)
-        rescue NoMethodError
-            self.fail "The %s provider can not handle attribute %s" %
-                [provider.class.name, self.class.name]
+        rescue NoMethodError => e
+            self.fail "The %s provider can not handle attribute %s [Exception: %s]" %
+                [provider.class.name, self.class.name, e.name]
         end
     end

And now I see this, which looks kind of like an empty array?

The directoryservice provider can not handle attribute password (Failed invoking []) at /Users/eric/./user-test.pp:1

Still digging but I wanted to post progress here. It’s going to be really hard for me to get ruby-debug on these hosts so I’m kind of reduced to puts debugging.

#7
Updated by James Turnbull 3 months ago

  • Status changed from Investigating to Needs More Information
  • Assignee set to eric sorenson

Hi eric – is this still a problem? Did you ever get any closer to root cause?

#8
Updated by eric sorenson 3 months ago

Yes, this is still going on; I worked around it in the manifests by defining alternate user resources without a password attribute for tiger hosts. Have not progressed on troubleshooting; it’s probably sufficient to see if other people can repro. If so, throw a warning and skip it the way a missing ruby-shadow does on Linux, rather than trying and failing. Tiger’s pretty far off the reservation now.

Also available in: Atom PDF