Bug #1958

directoryservice provider sometimes seems to break the provider selection

Added by Francois Deppierraz almost 3 years ago. Updated almost 2 years ago.

Status:Duplicate Start date:02/11/2009
Priority:High Due date:
Assignee:Luke Kanies % Done:

0%

Category:group
Target version:0.24.8
Affected Puppet version:0.24.7 Branch:
Keywords:
Votes: 0

Description

On some of our Debian etch servers, puppetd stopped running after an upgrade from 0.24.5-3 (Debian version) to 0.24.7 (Debian version).

The provider selection for “group” resources stops right after testing “directoryservice” and without even giving a try at “groupadd” which is the appropriate one on this platform.

# cat test.pp 
group {"blah":
  ensure => present
} 
# puppet --verbose --debug test.pp
info: Loading fact environment
info: Loading fact veid
info: Loading fact manufacturer
info: Loading fact mysqlpasswd
info: Loading fact localsid
info: Loading fact vmware
/usr/lib/ruby/1.8/puppet/provider/group/netinfo.rb
netinfo
/usr/lib/ruby/1.8/puppet/provider/group/ldap.rb
ldap
debug: Failed to load library 'ldap' for feature 'ldap'
/usr/lib/ruby/1.8/puppet/provider/group/directoryservice.rb
directoryservice
debug: Puppet::Type::Group::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::Group::ProviderLdap: true value when expecting false
err: Could not create blah: Could not find a default provider for group
Could not find a default provider for group

Related issues

duplicates Puppet - Bug #1869: Not all providers loaded because of ImportErrors Closed 01/15/2009
duplicated by Puppet - Bug #2030: launchd service provider getting set to Nil Duplicate 02/26/2009

History

Updated by Francois Deppierraz almost 3 years ago

The directoryservice group provider is a likely culprit because removing it does indeed fix the problem.

# mv /usr/lib/ruby/1.8/puppet/provider/group/directoryservice.rb /tmp/
# puppet --verbose --debug test.pp
info: Loading fact environment
info: Loading fact veid
info: Loading fact manufacturer
info: Loading fact mysqlpasswd
info: Loading fact localsid
info: Loading fact vmware
/usr/lib/ruby/1.8/puppet/provider/group/netinfo.rb
netinfo
/usr/lib/ruby/1.8/puppet/provider/group/ldap.rb
ldap
debug: Failed to load library 'ldap' for feature 'ldap'
/usr/lib/ruby/1.8/puppet/provider/group/groupadd.rb
groupadd
debug: Puppet::Type::Group::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::Group::ProviderLdap: true value when expecting false
debug: Creating default schedules
debug: //Group[blah]: Changing ensure
debug: //Group[blah]: 1 change(s)
debug: Group[blah](provider=groupadd): Executing '/usr/sbin/groupadd blah'
notice: //Group[blah]/ensure: created
debug: Finishing transaction 23825719839140 with 1 changes
root@francois:/tmp# 

Updated by James Turnbull almost 3 years ago

Can you run this with a —trace

I can’t replicate the problem.

cat /tmp/group.pp 
group {"blah":
  ensure => present
} 

# puppet --noop --verbose --debug --trace < /tmp/group.pp 
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::Group::ProviderDirectoryservice: file /usr/bin/dscl does not exist
debug: Puppet::Type::Group::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::Group::ProviderLdap: true value when expecting false
debug: Puppet::Type::Group::ProviderPw: file /usr/sbin/pw does not exist
debug: Creating default schedules
debug: //Group[blah]: Changing ensure
debug: //Group[blah]: 1 change(s)
notice: //Group[blah]/ensure: is absent, should be present (noop)
debug: Finishing transaction 69862316953780 with 1 changes

Updated by Francois Deppierraz almost 3 years ago

Here it is, however the actual error is certainly happening prior than that.

# puppet --verbose --debug --trace test.pp
info: Loading fact environment
info: Loading fact veid
info: Loading fact manufacturer
info: Loading fact mysqlpasswd
info: Loading fact localsid
info: Loading fact vmware
/usr/lib/ruby/1.8/puppet/provider/group/netinfo.rb
netinfo
/usr/lib/ruby/1.8/puppet/provider/group/ldap.rb
ldap
debug: Failed to load library 'ldap' for feature 'ldap'
/usr/lib/ruby/1.8/puppet/provider/group/directoryservice.rb
directoryservice
debug: Puppet::Type::Group::ProviderNetinfo: file nireport does not exist
debug: Puppet::Type::Group::ProviderLdap: true value when expecting false
err: Could not create blah: Could not find a default provider for group
/usr/lib/ruby/1.8/puppet/type.rb:1737:in `defaultprovider'
/usr/lib/ruby/1.8/puppet/type.rb:1880:in `default'
/usr/lib/ruby/1.8/puppet/type.rb:651:in `setdefaults'
/usr/lib/ruby/1.8/puppet/type.rb:140:in `eachattr'
/usr/lib/ruby/1.8/puppet/type.rb:135:in `each'
/usr/lib/ruby/1.8/puppet/type.rb:135:in `eachattr'
/usr/lib/ruby/1.8/puppet/type.rb:641:in `setdefaults'
/usr/lib/ruby/1.8/puppet/type.rb:2342:in `initialize'
/usr/lib/ruby/1.8/puppet/type.rb:1131:in `new'
/usr/lib/ruby/1.8/puppet/type.rb:1131:in `create'
/usr/lib/ruby/1.8/puppet/transportable.rb:91:in `to_type'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:497:in `send'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:497:in `to_catalog'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:482:in `each'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:482:in `to_catalog'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:408:in `to_ral'
/usr/bin/puppet:224
Could not find a default provider for group

Updated by Francois Deppierraz almost 3 years ago

I was able to reproduce this bug with the upstream 0.24.7 version. So this bug is not specific to the Debian package.

Updated by Luke Kanies almost 3 years ago

  • Status changed from Unreviewed to Accepted
  • Assignee set to Luke Kanies

In looking at the defaultprovider code in Puppet::Type, there is no kind of error-handling in that method, so if one of the providers were to cause an exception while looking for a default provider, it could break the process itself.

I’ll get this fixed today.

Updated by Francois Deppierraz almost 3 years ago

Thanks Luke !

This is exactly what happened in that case.

Line 19 of lib/puppet/provider/nameservice/directoryservice.rb is:

require ‘facter/util/plist’

which raised a LoadError because of the facter version we’re using (1.3.7) doesn’t contain this class.

Updated by Nigel Kersten almost 3 years ago

So we had this discussion in this issue:

http://projects.reductivelabs.com/issues/1553

and the consensus as far as I understood it was that it was reasonable for puppet to no longer include the plist module, but for facter to include it given that facter is a dependency for puppet already, and that this meant you needed to jump to a newer version of facter.

Updated by Francois Deppierraz almost 3 years ago

nigelk2 wrote:

and the consensus as far as I understood it was that it was reasonable for puppet to no longer include the plist module, but for facter to include it given that facter is a dependency for puppet already, and that this meant you needed to jump to a newer version of facter.

Alright, I just added a note about that in the UPGRADE wiki page.

http://reductivelabs.com/trac/puppet/wiki/UPGRADE?action=diff&version=31

Updated by Luke Kanies almost 3 years ago

  • Status changed from Accepted to Duplicate

I think this is essentially a duplicate of #1869.

Also available in: Atom PDF