On Thursday, July 11, 2013 1:41:26 PM UTC-5, Forrie wrote: > > I'm having a perplexing problem with Puppet 3.2.2 (agent) on CentOS > 6.3. There are two systems, recently built, that exhibit the same > problem. I'm using the same, very basic and simple config I have on all > of my systems (most of which are CentOS 5). This system has its own ruby > and puppet installation (gem), which is the only real difference. >
I urge you to avoid using gem to manage packages on any system that has a decent native package manager (such as CentOS 6.3). It constitutes a basic system management problem to have multiple package managers with overlapping areas of responsibility. Have you considered using the RHEL/CentOS/etc. RPMs packaged by PuppetLabs? PL maintains its own yum repository to make this easy; see http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html. > > Basically, I can't get the master to generate a certificate. I can > telnet to the puppet inbound port, no problem. > > here's what I see: > > [ puppet master log ] > 10.101.0.10 - - [11/Jul/2013:14:30:50 -0400] "GET /production/certificate/ > de-prod-archive.de-prod.harvard.edu? HTTP/1.1" 404 62 "-" "-" > 10.101.0.10 - - [11/Jul/2013:14:30:50 -0400] "GET /production/certificate/ > de-prod-archive.de-prod.harvard.edu? HTTP/1.1" 404 62 "-" "-" > > [ puppet client log / debug, no-daemonize ] > > Debug: Finishing transaction 69955790206320 > Info: Creating a new SSL key for de-prod-archive.de-prod.harvard.edu > Info: Caching certificate for ca > Info: Caching certificate_request for de-prod-archive.de-prod.harvard.edu > Debug: Using cached certificate for ca > Debug: Using cached certificate for ca > Debug: Using cached certificate for ca > Notice: Did not receive certificate > > 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.
