We are not configured to auto-sign certificates. Clearly, the client is making a connection to the master:
10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] "GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1" 404 62 "-" "-" 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] "GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1" 404 62 "-" "-" 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] "GET /production/certificate/de-prod-archive.ourdomain.com? HTTP/1.1" 404 62 "-" "-" Correct, our Master is upgraded to the latest Puppet 3.2.3, as is this particular agent. I've tried starting clean/fresh on the agent (removing /var/lib/puppet) and that has no effect. The older clients are working just fine. puppet cert list, continues to not see the inbound request from this particular agent. our auth.conf certificate rules are fairly standard: # allow access to the CA certificate; unauthenticated nodes need this # in order to validate the puppet master's certificate path /certificate/ca auth any method find allow * # allow nodes to retrieve the certificate they requested earlier path /certificate/ auth any method find allow * # allow nodes to request a new certificate path /certificate_request auth any method find, save allow * Unless something changed between versions that I missed, I believe this should be working. I even hard-coded the servername in the puppet.conf, which has no effect on this agent. The logs above suggest it's looking for the actual certificate, but I don't see the request in the "puppet cert list" queue. Very puzzled. Thanks. [ .. ] > > And your master is configured to autosign certificates? Because that's > not the default, and you didn't say anything about signing them manually. > You can check whether there are any outstanding certificate requests by > running > > puppet cert list > > on the master. > > In fact, did you recently upgrade your master to its current version? As > in, since the working clients were issued their certs? If so, then perhaps > the upgrade somehow reset the master's certificate management configuration > to the default of not autosigning. > > > >> >> I've Googled around for this error, but I don't see a solution to my >> issue -- I wonder if I'm missing a ruby gem, or if there is generally >> something wrong with running this on CentOS 6 (that would be odd). >> >> I have tried completely removing /var/lib/puppet on the agent and >> starting over, that has no effect. >> >> The puppet.conf I'm using on all my systems: >> >> >> [main] >> server = my-server.name.com >> >> vardir = /var/lib/puppet >> >> logdir = /var/log/puppet >> >> rundir = /var/run/puppet >> >> ssldir = $vardir/ssl >> >> [agent] >> >> classfile = $vardir/classes.txt >> >> localconfig = $vardir/localconfig >> >> syslogfacility = local4 >> >> report = true >> >> listen = true >> >> >> Am I missing something? Granted, the older clients are running 2.7.x, >> so perhaps I've missed something in the upgrade docs and I need to add to >> the *.conf file. The master server is running Puppet 3.2.2 under >> Passenger 4.0.8, all the other clients are connecting just fine. Iptables >> is not a factor here, either. >> >> > > I am disinclined to think that the problem is actually at the agent. That > the other agents are working is not a counterindication, for the place > where the process seems to be failing is outside the path that is > ordinarily traversed in servicing catalog requests. > > > John > > -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
