Puppet

Duplicates #3083.

Can you update that ticket with:

• Platform
• Ruby version

[root@vulcan ~]# puppetd —version 0.25.4 [root@vulcan ~]# puppetmasterd —version 0.25.4 [root@vulcan ~]# ruby —version ruby 1.8.7 (2009-12-24 patchlevel 248) [i686-linux]

Test case:

site.pp

[root@vulcan ~]# cat /etc/puppet/manifests/site.pp import “classes/*”

node default {

    include foo

}

foo.pp

[root@vulcan ~]# cat /etc/puppet/manifests/classes/foo.pp class foo {

    file { "/etc/hosts":
            owner => "root",
            group => "root",
            mode => 644,
    }

}

Platform:

[root@vulcan ~]# cat /etc/redhat-release Red Hat Enterprise Linux AS release 3 (Taroon) [root@vulcan ~]# uname -a Linux vulcan 2.4.21-4.EL #1 Fri Oct 3 17:52:56 EDT 2003 i686 athlon i386 GNU/Linux

This ticket appear to offer a cleaner route to a fix, so I’m reversing the duplicated/duplicates direction.

When I try this in as close the same environment as I can at the moment, it works. Is there anything in you puppet.conf that may be of interest, are you doing anything with clever links or mounts in your puppet directories, or are there any other items that you can think of that might shed some light on this?

Had an issue with name resolution on this system. The system was setup with a different IP than what the DNS A and PTR specified. In any case, ruby 1.8.7p72 generated a trace that contained a getaddrinfo error, which tipped me off. p286 generates the trace pasted above. puppet’s exception handling for getaddrinfo could probably be handled better, but I think this can be closed now.

Derek —

Just to clarify: did fixing the DNS resolve the issue (you no longer get the “undefined method `closed?‘ for nil:NilClass” error)?

— Markus

Markus,

Yes, that’s correct. Thanks for looking at it, anyway.

Regards

Derek —

Thanks for you help clarifying this issue.

— Markus

Just need to chime in: I am trying to set up puppetmaster&puppet on my laptop for easy offline hacking, and I am running into the same problem, in addition to two other weird errors that seem related (+trace attached):

# puppetd --no-daemonize --onetime --verbose
err: Could not retrieve catalog from remote server: undefined method `closed?' for nil:NilClass
notice: Using cached catalog
info: Applying configuration version '1268237961'
err: //puppet/File[/etc/default/puppet]: Failed to retrieve current state of resource: undefined method `closed?' for nil:NilClass Could not retrieve file metadata for puppet:///modules/puppet/etc_default_puppet: undefined method `closed?' for nil:NilClass at /etc/puppet/modules/puppet/manifests/init.pp:75
err: //puppet::server/File[/etc/puppet/auth.conf]: Failed to retrieve current state of resource: undefined method `closed?' for nil:NilClass Could not retrieve file metadata for puppet:///modules/puppet/auth.conf: undefined method `closed?' for nil:NilClass at /etc/puppet/modules/puppet/manifests/server.pp:75
notice: //puppet/Service[puppet]: Dependency file[/etc/default/puppet] has 1 failures
warning: //puppet/Service[puppet]: Skipping because of failed dependencies
notice: Finished catalog run in 0.63 seconds

The configuration is identical to what’s running on puppetmaster.madduck.net, where everything is working fine.

I specifically configured DNS to make everything work backwards and forwards:

% facter fqdn
lapse.rw.madduck.net
% dig @localhost +short a lapse.rw.madduck.net
127.0.0.1
% dig @localhost +short -x 127.0.0.1
lapse.rw.madduck.net.
localhost.
% dig @localhost +short a localhost
127.0.0.1

Therefore, DNS cannot be the real cause of this problem, right?

PS: the WYSIWIG markup editor is useless and doesn’t let me do pre-formatted text. Sorry about that.

Just use < pre > and < /pre> tags. Works fine for me. I’ve updated your entry.

I found my problem with ruby debug mode. Running puppetd with ruby —debug is enlightening (“there is other code out there that generates more warnings than my own!”), but it did include this gem (not sure whether pun intended):

Exception `OpenSSL::SSL::SSLError' at /usr/lib/ruby/1.8/openssl/ssl.rb:123 - hostname was not match with the server certificate

Sure thing, once I started connecting to the proper hostname (which still resolves to localhost), everything was fine.

I think it would make sense to convert this bug report into a wishlist requesting better error reporting.

So the fix for young players was specifying in puppet.conf:

server=f.q.d.n

Concur with Martin on error reporting.

I can also reproduce the SSL error Martin got, but when using my fqdn as the server name, I still get the following. It happens randomly for anywhere from none to all of my file definitions:

info: Applying configuration version '1268253124'
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
Exception `Errno::ECONNRESET' at /usr/local/lib/ruby/1.8/openssl/buffering.rb:237 - Connection reset by peer
Exception `Errno::ECONNRESET' at /usr/local/lib/ruby/1.8/net/http.rb:1061 - Connection reset by peer
Exception `NoMethodError' at /usr/local/lib/ruby/1.8/net/http.rb:1060 - undefined method `closed?' for nil:NilClass
Exception `Puppet::Error' at /usr/local/lib/ruby/gems/1.8/gems/puppet-0.25.4/lib/puppet/parameter.rb:401 - undefined method `closed?' for nil:NilClass Could not retrieve file metadata for puppet:///modules/inspircd/inspircd.conf: undefined method `closed?' for nil:NilClass at /home/puppetmaster/conf/modules/inspircd/manifests/init.pp:8
err: //inspircd/File[/home/procrast/inspircd/conf/inspircd.conf]: Failed to retrieve current state of resource: undefined method `closed?' for nil:NilClass Could not retrieve file metadata for puppet:///modules/inspircd/inspircd.conf: undefined method `closed?' for nil:NilClass at /home/puppetmaster/conf/modules/inspircd/manifests/init.pp:8

This only happens when making a connection to a puppetmasterd on the same machine as the puppetd. Clients on other machines have zero problems.

For reference: This is a known bug in 1.8.7. See: http://redmine.ruby-lang.org/issues/show/2708

Fixes issue for me also + Jesse.

Pushing in commit:“ae0b0bf23e418e8c6665e9dc135148b78bdbd913” in branch 0.25.x