multiple puppet masters

I would like to set up an additional puppet master but have the CA server handled by only 1 puppet master. I have set this up as per the documentation here:

http://docs.puppetlabs.com/guides/scaling_multiple_masters.html

I have configured my second puppet master as follows:

[main]
...
ca = false
ca_server = puppet-master1.test.net

I am using passenger so I am a bit confused how the virtual-host.conf file should look for my second puppet-master2.test.net. Here is mine (updated as per Shane Maddens answer):

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-3.0.18/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.18
PassengerRuby /usr/bin/ruby

Listen 8140

<VirtualHost *:8140>

    ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-master1.test.net:8140/$1

    SSLEngine on
    SSLProtocol -ALL +SSLv3 +TLSv1
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

    SSLCertificateFile      /var/lib/puppet/ssl/certs/puppet-master2.test.net.pem
    SSLCertificateKeyFile   /var/lib/puppet/ssl/private_keys/puppet-master2.test.net.pem
    #SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
    #SSLCACertificateFile    /var/lib/puppet/ssl/ca/ca_crt.pem
    # If Apache complains about invalid signatures on the CRL, you can try disabling
    # CRL checking by commenting the next line, but this is not recommended.
    #SSLCARevocationFile     /var/lib/puppet/ssl/ca/ca_crl.pem
    SSLVerifyClient optional
    SSLVerifyDepth  1
    # The `ExportCertData` option is needed for agent certificate expiration warnings
    SSLOptions +StdEnvVars +ExportCertData

    # This header needs to be set if using a loadbalancer or proxy
    RequestHeader unset X-Forwarded-For

    RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
    RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
    RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

    DocumentRoot /etc/puppet/rack/public/
    RackBaseURI /
    <Directory /etc/puppet/rack/>
            Options None
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>
</VirtualHost>

I have commented out the #SSLCertificateChainFile, #SSLCACertificateFile & #SSLCARevocationFile - this is not a CA server so not sure I need this. How would I get passenger to work with these?

I would like to use ProxyPassMatch which I have configured as per the documentation. I don't want to specify a ca server in every puppet.conf file.

I am getting this error when trying to get create a cert from a puppet client pointing to the second puppet master server (puppet-master2.test.net):

[root@puppet-client2 ~]# puppet agent --test
Error: Could not request certificate: Could not intern from s: nested asn1 error
Exiting; failed to retrieve certificate and waitforcert is disabled

On the puppet client I have this

[main]

server = puppet-master2.test.net

What have I missed?

Cheers, Oli

This part of the documentation..

ProxyPassMatch ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppet_ca/
ProxyPassReverse ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppet_ca/

..is actually wrong in several ways. ProxyPassReverse can't take a regex (and isn't needed anyway), it's not actually using the requested URL in the request that's sent to the CA, and it can trigger unintentional proxying for non-certificate-related API calls for a node that has certificate in its name.

Instead, use this:

ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-master1.test.net:8140/$1

Put it inside your <VirtualHost> block, and you can get rid of the <Proxy balancer://puppet_ca>.

The error you're getting means that you're getting something other than a certificate back from the attempt to retrieve your certificate -- this could be caused by the configuration problem above, but might also be indicative of a different error. Get that config changed out, blow away your /var/lib/puppet/ssl on the client (since the certificate request probably failed too) and see if it's working - if not, add --verbose to a run and we'll see what's going on.

Nope.

Don't do this. If you're looking to scale puppet by having multiple masters, you're going the wrong way about it. I'm well aware that puppetlabs have produced a document that you linked saying how they recommend doing MM puppet, but it's actually far easier to go masterless.

So the best way to scale puppet is to go masterless, where you have a central git (or other DVCS) repository, and clone down a copy of your manifests, and run them locally with puppet apply.

multiple puppet masters

Related

Recent Posts