On Thu, Jun 14, 2012 at 9:12 PM, Scott Merrill <ski...@skippy.net> wrote: > On Thu, Jun 14, 2012 at 5:13 PM, Nan Liu <n...@puppetlabs.com> wrote: >> A few other thing you can try is to run the web brick server and run >> puppet master --debug --no-daemonize on the sub master and see if that >> give any more info. You can also try enabling CA on the sub-master and >> check what you get back from another test client and see what you >> receive the right CA file on initial connection and what CA cert signs >> that client's CSR. That's all I can think of. > > Trying to run `puppet master --debug --no-daemonize` failed. The > process terminated with the same error: > Could not prepare for execution: The certificate retrieved from the > master does not match the agent's private key. > > I revoked the subordinate master's key, and then executed `puppet > agent --test -d` from that subordinate master. I noticed during the > output that it was creating the /var/lib/puppet/ssl/ca directory, > despite having "ca = false" in the puppet.conf file. > > I looked a little closer at the > http://docs.puppetlabs.com/guides/scaling_multiple_masters.html > instructions, and say to my chagrin that the location of the "ca = > false" in my config file was _not_ in the stanza as directed there. I > updated my puppet.conf to strictly follow those instructions: > > [main] > logdir = /var/log/puppet > rundir = /var/run/puppet > ssldir = $vardir/ssl > ca_server = top-level-master.domain > dns_alt_names = 'subordinate-master-1.domain,puppetmaster.domain' > > [agent] > classfile = $vardir/classes.txt > localconfig = $vardir/localconfig > server = top-level-master.domain > > [server] > # for Passenger > ssl_client_header = SSL_CLIENT_S_DN > ssl_client_verify_header = SSL_CLIENT_VERIFY > > [master] > ca = false > > On this subordinate master, I executed `sudo rm -rf > /var/lib/puppet/ssl`; and on the top-level master I executed `puppet > cert clean subordinate-master-1.domain`. > > On the subordinate master, I then executed `puppet agent --test --noop`: > # puppet agent --test --noop > info: Creating a new SSL key for subordinate-master-1.domain > warning: peer certificate won't be verified in this SSL session > info: Caching certificate for ca > warning: peer certificate won't be verified in this SSL session > warning: peer certificate won't be verified in this SSL session > info: Creating a new SSL certificate request for subordinate-master-1.domain > info: Certificate Request fingerprint (md5): > 2D:F2:2A:A5:BD:56:D4:41:5A:B3:22:AA:A5:97:3D:66 > warning: peer certificate won't be verified in this SSL session > err: Could not request certificate: Error 400 on SERVER: CSR > 'subordinate-master-1.domain' contains subject alternative names > (DNS:subordinate-master-1.domain, DNS:puppetmaster.domain), which are > disallowed. Use `puppet cert --allow-dns-alt-names sign > subordinate-master-1.domain` to sign this request. > Exiting; failed to retrieve certificate and waitforcert is disabled > > On the top-level master, I executed `puppet cert --allow-dns-alt-names > sign subordinate-master-1.domain`. On the subordinate master I re-ran > `puppet agent --test --noop`. The certificate, private key, and CA > cert were all installed properly. > > Now on the subordinate master I can run `puppet master --debug > --no-daemonize` without errors. I restarted Apache, and from this > subordinate master I ran `puppet agent --test --noop -d --server > subordinate-master-1.domain --ca_server top-level-master.domain`. No > errors! > > I've repeated this on one of the other subordinate masters I'd > previously -- and erroneously -- configured, and enjoyed the same > success there. > > The client node with which I've been testing can now successfully > connect to the subordinate master without error. > > Thank you very, very much for working through this with me. > > Cheers, > Scott
That's awesome to hear, Scott :) I'm glad you were able to get it setup! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
