The Foreman for your home (PoC)

Community
1

Have you ever thought about running The Foreman in your living room? On your NAS maybe? To manage your infrastructure, notebooks, appliances the way they should be managed, by code.

I have. My goal was a setup that not only everyone could fire up quickly, but one that would be easy to maintain, simple to upgrade. Because, when you have a family you have limited time to spend in the evening and weekends, don’t you?

Here it is: https://github.com/painless-software/synology-foreman

A Bit of History

In 2018, I originally started with a Vagrant-based setup. It had 2 VMs, one for The Foreman (“enc”), one for the user directory (“identity”) running FreeIPA. The reason was, there was only the foreman-installer back then. It ruled out using Docker, it was literally impossible to run The Foreman in containers.

Roughly a year later, the Foreman Dockerfile took off, which was great news. Remember, we need a setup that is easy to upgrade! There was still a problem, though: I had bought a NAS for my home needs and that would only run Docker alone, or Docker Compose. No way to run Kubernetes, MicroK8s, k3s, OpenShift – what everyone suggested.

Current Status

You can: (from the README)

  1. Create your personal (Docker Compose) setup with a script execution
  2. Run the setup locally (or on any target machine that runs Docker and Python)
  3. Initialize The Foreman with an Ansible playbook you can adapt yourself (so that you could start attaching notebooks to your LAN for installation immediately afterwards)

Where I’m stuck:

  • Configuring TFTP and hosting boot images inside The Foreman, for PXE boot to work and trigger new bare-metal installations.

Unfortunately, I lack the insider knowledge (that makes foreman-installer bootstrapped setups so convenient) for me to go the last mile. – Is there anyone who could give me hints to move forward, or even better, who would have a few evenings to spare for some troubleshooting?

3 Likes
2

Hey @bittner

Of course you write the one week that I am on vacation!
I had been telling a few people about your project.
Welcome and I am happy that you have come to talk to us about your project here.

From a brief conversation with @ohadlevy - the missing part of the project relates to there being no containerized smart proxy. As a workaround, you could create a container on top of the smart proxy with your configuration file, you could also use https://github.com/ohadlevy/smart-proxy/blob/dockerfile/Dockerfile as a starting point.

I’m wondering has anyone else worked on getting the smart proxy into a docker image?

3

I recall @TimoGoebel started with it. It’s mostly about configuration. He started this PR:

I still think that is the correct path forward: declare all settings for every module and plugin with a type to allow configuration using environment variables.

However, I also think that the Smart Proxy may be the hardest to containerize. The model Foreman has is that the Foreman installation itself has very little to no contact to the outside world and doesn’t really store anything outside of the DB. That makes it very easy to containerize (except plugins). The Smart Proxy on the other hand is much more integrated. It reads and writes to files in order to use various services. For example the ISC DHCP integration reads the leases file (with a file monitor) to see which IPs are available.

So it really becomes a question of which Smart Proxy modules do you want to support?

1 Like
4

IIUC, in order to make PXE/TFTP work and later manage machines using Puppet that would be TFTP, Puppet and Puppet CA.

5

As for TFTP, the TFTP manual is still pretty correct. Only the exact wget command is no longer correct since it was changed to curl (that should be updated).

So his means you will need to create a tftp.yml with the correct content and make sure the tftproot is a volume. That’s not really container native (where you probably would want to use environment variables), but it’s a known limitation now.

Then for Puppet the manual is pretty straight forward. You’ll probably want to use a volume for the certificates.

For Puppet CA it’s more complicated. With the puppetca_hostname_whitelisting you must make sure the Smart Proxy can write to autosign.conf used by Puppetserver, which is not ideal (not even with VMs). The puppetca_token_whitelisting implementation is better in that way, but requires more setup. When you use Puppet 6 or higher (and you should since Puppet 5 is EOL), the HTTP implementation is at least as straight forward as the Puppet implementation.