2

I have managed to set up multiple puppet masters with one puppet master acting as a CA and clients are able to get a certificate from this CA server but use their designated puppet master to get their manifests. See this question for more info.. multiple puppet masters. However, there are a couple of things I have had to do to get this working correctly and have an error which I'll get to.

First of all, to get inventory working for a puppet-client (PC) connecting to its designated puppet-master (PM), I had to copy the CA certs on PM1 to the PM2 ca directory. I ran this command:

scp root@puppet-master1.test.net:/var/lib/puppet/ssl/ca/ca_cr*.pem  root@puppet-master2.test.net:/var/lib/puppet/ssl/ca/.

Once i have done that, I was able to uncomment the SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFile section of my rack.conf VH file on the PM2. Once I had done this, inventory started to work. Does this sound an acceptable way to do things?

Secondly, in the puppet.conf file, I am setting the designated PM server for the client, for example server = puppet-master2.test.net. Unless there is a better way, this is how it'll work in my production setup. So PC1 will talk to PM1 and PC2 will talk to PM2. This is where I have an error. When PC2 first requests a cert from the CA on PM1, the cert appears and then I sign the cert on the CA on PM1. When I then do a puppet agent --test on PC2 (which has server = puppet-master2.test.net in puppet.conf), I get this error:

Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Error 403 on SERVER: Forbidden request: puppet-master2.test.net(10.1.1.161) access to /certificate_revocation_list/ca [find] at :112

However, if I change the PC2 puppet.conf file and specify server = PM1 and the rerun puppet agent --test, i do not get any errors. I can then revert the change in the puppet.conf file back to server = PM2 and everything seems to run normally.

Do I have to set up some kind of ProxyPassMatch on PM2 for requests made from clients to /certificate_revocation_list/* and redirect them to PM1? Or how can I fix this error?

Cheers, Oli

Community
  • 1
Oli
  • 418
  • 3
  • 15

1 Answers1

1

Once i have done that, I was able to uncomment the SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFile section of my rack.conf VH file on the PM2. Once I had done this, inventory started to work. Does this sound an acceptable way to do things?

Shouldn't need to do that - the revocation list and root certificate should already be on the secondary master. Try these file locations on PM2:

SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile    /var/lib/puppet/ssl/certs/ca.pem
SSLCARevocationFile     /var/lib/puppet/ssl/crl.pem

Secondly, in the puppet.conf file, I am setting the designated PM server for the client, for example server = puppet-master2.test.net. Unless there is a better way, this is how it'll work in my production setup.

Which puppet version are you on? 3.0's SRV record feature is an excellent solution to this problem, allowing you to give clients a set of masters they can choose from, with weights and priorities.

Do I have to set up some kind of ProxyPassMatch on PM2 for requests made from clients to /certificate_revocation_list/* and redirect them to PM1? Or how can I fix this error?

This is a bad default in auth.conf - the proxied connection isn't authenticated, and the default is to force authentication for the CRL (which is not sensitive). Add this to your auth.conf on PM1:

path /certificate_revocation_list
auth any
method find
allow *
Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • `Which puppet version are you on? 3.0's SRV record feature is an excellent solution to this problem, allowing you to give clients a set of masters they can choose from, with weights and priorities.` - Yes I saw a previous post you wrote on this. I am using 3.0.1 but unfortunately, our main sites uses a flat dns structure. I am going to using server = PMx and script this based on host IP. Should be easy enough. – Oli Dec 20 '12 at 09:55
  • I updated the cert locations as you suggested. In fact, that makes complete sense to me now. As the PMs are not a CA server, the certs are just in another, or should I say, the correct place. I updated the /certificate_revocation_list in auth.conf on the PM CA and that has also worked. Basically, I have everything working and in the way that I set out in the very beginning - see this post - [puppet-setup](http://serverfault.com/questions/448916/puppet-master-slave-setup). To be honest, I wouldn;t have been able to do this without your help and I am really grateful. Thanks very much Shane! – Oli Dec 20 '12 at 10:22
  • @Oli Great to hear! One note on the SRV records - they should actually work pretty well for your setup. If you set the `srv_domain` to `test.net` in the puppet.conf and set `use_srv_records` to `true`, the clients will look at `_x-puppet._tcp.test.net`. You can then set DNS records like this: `_x-puppet._tcp.test.net. IN SRV 0 5 8140 puppet-master1.test.net.` and `_x-puppet._tcp.test.net. IN SRV 0 5 8140 puppet-master2.test.net.`, to have your agents randomly select a puppet master when they run (and if one master is down every node will still be able to run against the other master). – Shane Madden Dec 20 '12 at 17:18
  • Ah - So I would like to play this slightly differently. I have 2 subnets (Site A and Site B). Both these sites use the same DNS server (housed in site A). 2 different geo locations. Site A goes to PM1 and site B goes to PM2 rather than agents randomly using either PMs. Otherwise traffic will be going over the WAN and we have multiple geo sites 10k's apart. My problem is that the site uses the same DNS server I suppose, but DNS traffic is OK. Nodes checking in every 30mins could be different. I really like the idea though and it'll be of use for other sites.. The format `_x-puppet`. Why the x? – Oli Dec 21 '12 at 08:54
  • @Oli In that case, maybe have two different sets of SRV records nodes in site A configured with a `srv_domain` of `site-a.test.net`, with its SRV records (`_x-puppet._tcp.site-a.test.net`) configured to have the local puppet master at a higher priority, to always be used unless it's down? The `x` in `_x-puppet` is because it's not registered as a service with the IANA - see [here](http://projects.puppetlabs.com/issues/3669#note-19). – Shane Madden Dec 21 '12 at 21:13