On Jul 13, 2010, at 6:54 AM, Marco Marongiu wrote: > Dear puppeteers > > I am trying to build a tree hierarchy of puppetmasters. The architecture > is aimed to distribute the load among a number of datacenters, while > keeping the puppetmasters in sync by means of puppet itself. > > The architecture I am trying to build is: > > - one "main puppetmaster"; > - many "distribution servers", that will be client of the main > puppetmaster, and masters to other clients > - plain clients > > > Unfortunately puppetmasterd gets in the way (maybe thinking it's so > smart?), screwing up the SSL setup. This was discussed yesterday on IRC; > Volcano suspects that there something in the certificates is at the root > of the problem, and that's why I added a certdnsnames directive, but > with no result so far. > > I am testing this setup on VirtualBox VMs on my desktop (which is > actually a luck since I can use snapshot and rewind back and forth to > different working states). The main puppetmaster is called > mastertest.oslo.osa and has address 192.168.56.108; the distribution > server is called distserver.oslo.osa and has address 192.168.56.111. > Both are on each other's /etc/hosts file. > > First, I configure distserver as a plain puppet client of mastertest. A > couple of runs of puppetd --test will bring it up to speed, and it will > work as expected. > > Then, on mastertest, I create a node file for distserver, which will > define it as a distribution server, and run puppetd again. > /etc/puppet/puppet.conf is rewritten so that it contains the following > certdnsnames in the puppetmasterd section: > > certdnsnames="distserver.oslo.osa:distserver" > > while the server directive is the puppetd section is: > > server=mastertest.oslo.osa > > Eventually, after the new puppet.conf is already in place, puppetmasterd > starts, and screws up the SSL setup: > >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Creating a new SSL key for ca >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Using cached certificate for >> ca, good until Sun Jul 05 12:44:33 UTC 2015 >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Expiring the certificate >> cache of ca >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Removing file >> Puppet::SSL::Certificate ca at '/var/lib/puppet/ssl/certs/ca.pem' >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Retrieved certificate does >> not match private key >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Creating a new SSL >> certificate request for ca >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Signed certificate request >> for ca >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Rebuilding inventory file >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Using cached >> certificate_revocation_list for ca, good until >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Using cached certificate for >> ca, good until Sat Jul 11 12:00:38 UTC 2015 >> Jul 13 14:00:38 distserver puppetmasterd[2861]: Using cached certificate for >> distserver.oslo.osa, good until Sat Jul 11 09:25:03 UTC 2015 >> Jul 13 14:00:38 distserver puppetmasterd[2888]: Reopening log files > > (note the "Removing file" line...) > > > Now, next time I run puppetd --test, all I get is: > >> Jul 13 14:01:08 distserver puppetd[3212]: Could not retrieve catalog from >> remote server: undefined method `closed?' for nil:NilClass >> Jul 13 14:01:08 distserver puppetd[3212]: Not using cache on failed catalog >> Jul 13 14:01:08 distserver puppetd[3212]: Could not retrieve catalog; >> skipping run > > Needless to say, if I stop puppetmasterd and put the old, "client" files > back in place into /var/lib/puppet, this machine starts working again as > a client. > > On mastertest (which has a nginx reverse proxy to four puppetmasterd > instances, again for scalability) I see that the request from distserver > is wrong. In fact, for distserver I have: > >> 192.168.56.111 - - [13/Jul/2010:15:30:09 +0200] "-" 400 0 "-" "-" > > while for working clients (e.g.: mastertest itself) I have something like: > >> 192.168.56.109 - - [13/Jul/2010:15:30:28 +0200] "GET >> /production/catalog/mastertest.oslo.osa?facts_format=b64_zlib_yaml&facts=LONG_BASE64_STRING_HERE > > I honestly can't understand what is going on here...
Basically, the puppet packages you are using (and I suspect most others) assume that the client and the server on a given machine are part of the same PKI. It also might be assuming a couple of other things, but my experiments never got that far. > Is there a way to make this all work as intended? WARNING: This fix is almost as destructive as rm -Rf /var/lib/puppet I think everything will just work if you set puppetd and puppetmaster to have a different "ssldir" like this: [main] #remove the ssldir entry from here. [puppetmasterd] ssldir=/var/lib/puppet/ssl_server [puppetd] ssldir=/var/lib/puppet/ssl_client I won't say this is working as intended. The normal way is to make a real PKI that includes all the servers, but this is probably much easier, and will probably do what you want. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
