Puppet

Very strange things happen here: I can’t reproduce it on my sid development machine, which has ruby 1.8.6, but it happens on all etch installations i tried it on. The latter have ruby 1.8.5

Also I coded up a few specs (attached) for the provider parameter, which work on every(!) installation i tested.

Yes! I could now pinpoint the cause of this bug, although I’m still not sure of the background details.

I have a custom user and group provider for smbldap, which gets loaded via pluginsync. for some weird reason puppet realizes that there should be such a provider, but fails to load it. Observe:

There is no config referencing

/var/puppet

root@backuppc:~/trunk# RUBYLIB=./lib/ PATH=./bin/:$PATH ./bin/puppet --genconfig | grep /var/puppet
    # The default value is '/var/puppet'.
root@backuppc:~/trunk# 

Especially vardir and libdir are set correctly:

root@backuppc:~/trunk# RUBYLIB=./lib/ PATH=./bin/:$PATH ./bin/puppet --configprint vardir
/var/lib/puppet
root@backuppc:~/trunk# RUBYLIB=./lib/ PATH=./bin/:$PATH ./bin/puppet --configprint libdir
/var/lib/puppet/lib
root@backuppc:~/trunk# ls -la /var/lib/puppet/lib/puppet/provider/*/smbldap.rb
-rw-r--r-- 1 root root  376 2007-10-09 11:19 /var/lib/puppet/lib/puppet/provider/group/smbldap.rb
-rw-r--r-- 1 root root 1086 2007-10-09 11:19 /var/lib/puppet/lib/puppet/provider/user/smbldap.rb
root@backuppc:~/trunk# 

But(!) if I try to run puppet on the user_test.pp this happens:

root@backuppc:~/trunk# RUBYLIB=./lib/ PATH=./bin/:$PATH strace -f -o ~/tmp/user_test.trace ./bin/puppet --debug ~/tmp/user_test.pp 
err: //User[bin]: Failed to retrieve current state of resource: undefined method @exists?' for #
debug: Finishing transaction -607094328 with 0 changes
root@backuppc:~/trunk# grep '/var.*puppet.*smbldap' ~/tmp/user_test.trace 
2872  stat64("/var/puppet/lib/puppet/provider/user/smbldap.rb", 0xbfc4563c) = -1 ENOENT (No such file or directory)
2872  stat64("/var/puppet/lib/puppet/provider/user/smbldap.so", 0xbfc4563c) = -1 ENOENT (No such file or directory)
2872  stat64("/var/puppet/lib/puppet/provider/group/smbldap.rb", 0xbfc4977c) = -1 ENOENT (No such file or directory)
2872  stat64("/var/puppet/lib/puppet/provider/group/smbldap.so", 0xbfc4977c) = -1 ENOENT (No such file or directory)
root@backuppc:~/trunk# 

As you can see, puppet is very confused about where to look for the plugins.

Setting the “—libdir /var/lib/puppet”(!!) on the command line allows puppet to find the providers and get on with it:

root@backuppc:~/trunk# RUBYLIB=./lib/ PATH=./bin/:$PATH ./bin/puppet --debug --libdir /var/lib/puppet ~/tmp/user_test.pp 
debug: Puppet::Type::User::ProviderPw: Not suitable: missing pw
debug: Puppet::Type::User::ProviderDirectoryservice: Not suitable: operatingsystem not in darwin
debug: Puppet::Type::User::ProviderNetinfo: Not suitable: missing nireport
Setting provider for User[bin] to useradd
debug: Finishing transaction -607381908 with 0 changes
root@backuppc:~/trunk#

h3. Summary

There are several problems here:

1. when libdir is set to “/var/lib/puppet/lib”, puppet becomes confused about where to look for plugins: it tries

   /var/puppet/lib

   instead
2. when —libdir is set to “/var/lib/puppet”, puppet again becomes confused about where to look for plugins: it tries

   /var/lib/puppet/lib

   instead, which is conicidentally the right path on my system
3. last but not least: when puppet believes a provider to be there, but fails to find it, it dies a horrible but silent death

Sorry that I didn’t split this up into new bugs, but I’m heading for my flight now.

I’ve figured out the problem here — I’m not calling hooks for values set in the configuration file.

This is a reasonable oversight, because values can shadow each other (e.g., conflicting values can be set in ‘puppetmasterd’ and ‘main’), but it’s really a design flaw.

I’ll figure out how to fix it.

Fixed in [3790ce1c6463e0d44ae0151fdc24000b9d5ede27] and [7a4ae082c216d68092f140ed1f5cca40ffb1a09e].