I upgraded our Puppet master to 3.x a while ago, after the file access issues (allow_ip, etc.) were fixed. I didn't actually test connection of a new client until this past week - where the others are running 2.x agent code and working.
Here are the gems I have presently: builder (3.2.2) daemon_controller (1.1.4) facter (1.7.2) fastthread (1.0.7) fcgi (0.9.1) ffi (1.9.0) hiera (1.2.1) json (1.8.0) json_pure (1.8.0) libvirt-ruby (1.0.2) passenger (4.0.8) puppet (3.2.3) puppet-lint (0.3.2) puppet-module (0.3.4) rack (1.5.2) rack-protection (1.5.0) rake (10.1.0) rgen (0.6.5) rubygems-update (2.0.5) sinatra (1.4.3) sqlite3 (1.3.7) sqlite3-ruby (1.3.3) stomp (1.2.10) tilt (1.4.1) tzinfo (1.0.1) zonefile (1.04) Now, I could re-install the Puppet 3.x code and see if that resolves the problem. I need to be very careful, as I have many 2.x agents that still require the Puppet master running -- so, if I uninstall the gem, then check to see if the directory and /usr/local/bin copies are removed, reinstall and re-run the master and see what happens. I presume /var/lib/puppet doesn't need to be touched in this case, as it's local data. Yes, of course the master that's running Puppet under Passenger (4.0.8) has been restarted multiple times, in the effort to continue debugging this. Though, I note the post above that mentions adding debug to config.ru - which I'm puzzled by. I suppose I could back-out the Passenger process altogether and run a standard Puppet master and see if the problem persists, also. Thanks! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
