We have to deal with running hosts within our clients’ networks where our only access out is through HTTP proxies. Problem is, many proxies by default don’t allow access to non-standard ports (anything except 80 and 443). As such accessing the puppet-master on 8140 fails. This is a pain, but we have no control over it.
How can I run Foreman’s puppet-master on 443?
I’m running Foreman within AWS so tried adding a load balancer on 443 that targeted the puppet-master on 8140. But I think this fails because the puppet-agents somehow check the cert of the master, not the load balancer.
I have thought about running Foreman only on port 80, and then putting a load balancer in front of that on a different address with its own SSL certificate but I see the foreman Apache setup is designed to handle client certificates. So that would break. But I’m not sure if that’s a problem for my situation. If Foreman’s not running on 443 then I could run the puppet-master on 443 (or just pipe 443 to 8140).
I could also run another puppet-master on a separate host, and run that one on 443. But I’m not sure how then to set hosts that Foreman creates to use the alternate puppet-master and the 443 port instead of 8140.
I just don’t know enough about the restrictions / requirements for Foreman and Puppet with SSL to be able to know what is a viable option.
The easiest way is to deploy a foreman proxy + puppet master on a separate host. That frees up port 443. Then register that foreman-proxy to Foreman. It should detect the Puppet feature and allow selection. I’d also advise to remove the Puppet master from the Foreman server.
To test with this a while back I also went a step further by running Foreman, Foreman Proxy and Puppetserver on 3 separate servers. At this point I wouldn’t recommend it, but splitting of the proxy + Puppetserver is a good idea. See the PR for some inspiration:
Thanks @ekohl. I was thinking the best result would be a Foreman and Puppet running on separate servers but couldn’t find anything describing this scenario. What I had read suggested leaving the Puppet CA on the Foreman sever. Would you suggest moving the CA as well onto the Puppet server?
Thanks to your PR above @ekohl and a few other web resources I got it going. I created a gist of what I ran on each server to have Foreman on one, and a smart-proxy + Puppet on the other linked up.
One thing to note. I assume because the puppet CA isn’t on the Foreman server the foreman-installer can’t create the certificates used in the apache2 config. As such apache2 starts on port 80 but not on 443. However, foreman-installer reports Success! and Foreman is running at https://... but in fact it is not. Maybe the installer should check it can connect to the foreman web interface?
To get the oauth-consumer value you can also use foreman-rake config -- -k oauth_consumer_key and foreman-rake config -- -k oauth_consumer_secret.
I would actually advise a slightly different strategy for the setup:
Install Puppet + Foreman Proxy first but don’t register the proxy by adding --foreman-proxy-register-in-foreman false to the foreman-installer command
Install Foreman as you do now
Register the Foreman Proxy running foreman-installer --foreman-proxy-register-in-foreman true --foreman-proxy-oauth-consumer-key OAUTH_KEY --foreman-proxy-oauth-consumer-secret OAUTH_SECRET on that host.
Then I think you can drop the whole SSL setup code you have.
PuppetCA is a networked CA server. Adding the Foreman server to the autosign entires is not great and is not recommended for production. Probably good to add --reset-puppet-autosign-entries after registration.
The puppet symlinks shouldn’t be needed. puppet-agent installs a file in /etc/profile.d/puppet-agent.sh that adds it to $PATH. Your shell doesn’t source it after installing but on a fresh install it should.