Foreman 2.1 installation w/ existing puppetserver

Support
,
#1

Greetings! I’ve been running puppet for a few years now and had looked at Foreman previously but felt I didn’t need it. I’m revisiting now, and intrigued by many of the features I find that would be quite useful in my small-ish (~75 node) environment. Currently I run a puppet server on a VM with /etc/puppetlabs/code existing as a Mercurial repository that a coworker and I push to for updates. I also run puppetdb and puppetboard, the latter of which I’d probably retire upon deploying Foreman since it would be redundant. Finally that host also houses a cobbler server and its associated tftpd, the former would also be getting replaced by Foreman.

I’ve done a test install on a separate machine to get a feel for it, and having searched the forums and documentation am looking for the best way to replace the current services on my provisioning machine with Foreman. I’m not terribly concerned with the fact histories in puppetdb, I mostly use it to gather things like SSH host keys though occasionally I do browse it for information if I had to start over with a fresh puppetdb I wouldn’t be heartbroken. And the cobbler tftp tree isn’t much concern either since all the information that feeds cobbler is in puppet currently. The big question is obviously puppetserver itself, namely how to go about installing Foreman on this machine either without disturbing the existing puppetserver, or with copying the appropriate data off and back again so I don’t have to recert all of the clients.

I’ve seen some recommendations such as installing on a separate machine and having it talk to the puppet server via the smart proxy, but since this host will be doing bare metal provisioning as well and PXEbooting, I don’t want to have to change the pxeboot information for every host in DHCP (we do not control the DHCP servers but have to request changes through another system). So the ideal would be to have it all on one host, which I know is possible, I just don’t want to clobber things if I can help it. I’m also not concerned with an outage even of a day or two (for any of the services) since we don’t provision things constantly so we can coordinate the outage to be between deployments.

OS: RHEL7
Puppet Labs puppet6 Repository baseurl=http://yum.puppet.com/puppet6/el/7/x86_64
RPMs:
puppetdb-termini-6.12.0-1.el7.noarch
puppet-agent-6.18.0-1.el7.x86_64
puppetdb-terminus-3-1.el7.noarch
puppetdb-6.12.0-1.el7.noarch
puppetserver-6.13.0-1.el7.noarch

#2

If this isn’t the appropriate place to ask a question like this, is there somewhere else I should be asking?

#3

Hey @srhuston

No, this is the right place.
I’m sorry that this was missed. Let me see if I can find some help.

#4

I am one of those Melanie asked for help, but I was unfortunately busy the last days as Germany got hit by the second wave of Corona. :frowning:

I agree that having all on the new Foreman system can make things easier, especially as the environment is not so big.

So lets look on the “problems” and how I would solve it.

Not sure how Mercurial works, but if the central repository is on the old puppet master I would simple move everything to the new one, if it is only a local checkout, simply check it out on the new machine. So no need to change anything here about your workflow.

PuppetDB is not required by Foreman, but it sounds like your Puppet code depends on it. So simply migrate it also to the new machine if it is on the old one and install and configure the PuppetDB plugin to Foreman, so it will remove nodes from PuppetDB when deleted in Foreman.

Cobbler and its TFP can simply be replaced. Not having the control over DHCP is no problem as long as the nextserver is configured probably. So here you will very likely change your workflow as you will use Foreman and its templates to create PXE config and TFTP content instead of your existing Puppet modules.

So I only see one problem with the existing hosts if you create a new puppetserver and this are the certificates required for communication. Based on when you created the CA for Puppet I would not bother with keeping it and create a new one, but this would require deployment of the new certificate on all hosts. This can be done with puppet, but as it is not so easy, I would do it “manually”. So to not have to do more steps than necessary I would switch autosigning on for all systems on the puppetserver and then run a ssh loop, deleting the old certificates (or easier their directory) and run puppet once to create the certificates (in case of doubt with noop). This will also create all the hosts in Foreman via a report. If you want them to be managed already have a look at the default hostgroup plugin.

I hope this helps and it should be quite easy to replace your old setup with the new one.

2 Likes
#5

Oh no! I hope you are staying healthy.

Since I initially posted, I finished my experiments with Foreman and moved on to trying to install it on a test machine that already has a working puppetserver installation. While I did have problems with the database (my existing and thus test system use rh-postgresql96-postgresql and Foreman wants rh-postgresql12-postgresql) I was able to muddle through things and end up with, I believe, a working Foreman installation while keeping the puppetserver active as well. There’s some merging I’ll have to do with the puppet.conf file to get started (Foreman installs itself in there, while at least temporarily I’ll need to keep my existing LDAP ENC as I migrate the appropriate data) but my main concern - making sure the CA stays the same and the SSL certs don’t change - seems to be alleviated as the environment I have setup for my existing puppetserver seems close enough to how Foreman would install it to be a good fit.

Thanks for the insight! I will continue with things, hopefully today since I had to take a day off for other work, and with any luck be able to write up a howto for what I did that might be adaptable into something for the documentation as one of the scenarios in section 3.2.3.

1 Like