Installing via foreman-installer vs. installing via theforeman/foreman Puppet module?


We’re setting up a fresh Foreman server to provide a new Puppet Master for our Puppet environment.

The Foreman docs recommend that we install Foreman via the foreman-installer. But I also see that a Puppet module is available

Is there any reason why we would not want to install via the Puppet Module at Why is the Foreman Installer the preferred method?

We’ve been using Foreman for years, but don’t keep a close eye on Foreman developments.
It’s our belief that Puppet manifests make it easier to apply smaller, incremental changes compared to the Foreman Installer.

Also, it’s not always clear what files are managed by the Foreman Installer. Since we only run the Foreman Installer occasionally, we may inadvertently revert a critical configuration away a config file without realizing it. It’s harder to do this with a Puppet manifest.

Am I looking at this the wrong way?


Or, to approach this another way: If I install via foreman-installer the first time can I somehow dump the config into a Puppet manifest which I could maintain with the theforeman/foreman module?

Then I could just maintain everything from a manifest moving forward.


The installer uses the same puppet modules, but there are also some hooks that live outside of puppet modules, that might be useful. I think this is even more important when you install katello. But in general, you can use puppet modules standalone as well. There’s no easy way to get installer’s values and convert them to puppet parameters automatically, but installer has answer file, where it stores all such values. So you could take this file and convert it manually.


cat `grep answer_file /etc/foreman-installer/scenarios.d/last_scenario.yaml  | awk '{ print $2; }' 

If you run this before you run installer for the first time, you’ll get default recommended values. After first run, it also contain values that were used as defaults for your system.


Okay, I will do something like that.

Running foreman-installer was super easy. I suppose what I’ll do now is to try and copy the correct modules to my production environment, write a manifest, and then run in no-op mode to see if I accidentally changed anything that is managed by Foreman Installer.


Hi, @Marek_Hulan hoping you could shed a little more light. I’m trying to translate the values from foreman-answers.yaml into some Puppet manifests.

If I understand the foreman-answers.yaml format correctly, it contains a number of top-level directives with names like foreman:, :foreman::cli:, foreman_proxy:, puppet:, followed by a section applying to that top-level directive. For my own server, I wanted to stick with the defaults as much as possible, and thus my own file doesn’t have that many differences from a default. Here are some example sections from my own file:

  puppetrun: false
  unattended: true
  version: installed
  repo: '1.18'
  gpgcheck: true
  custom_repo: true
  version: present
  version: present
  user: puppet
  group: puppet
  dir: "/etc/puppetlabs/puppet"

Am I correct in assuming that these top level directives, like foreman: and puppet: are referring to Puppet modules such as theforeman/foreman and theforeman/puppet, and the parameters underneith are essentially the same as the Puppet parameters for those modules?


Yes, you got it exactly right. Top level modules are foreman, foreman_proxy and puppet. The key that contains :: instantiate some subclass from one of these modules, handy for plugins or cli setup.


Our installer is indeed effectively a wrapper around puppet modules with some hooks and migrations. These migrations allow us to move parameters when we rename them or change some data when needed.

As the maintainer of the installer and its puppet module I consider this a supported way of deploying Foreman. It’s how I run my personal Foreman instance and I know we have quite a few production users doing the same thing. It does mean you need to keep up with our modules, but we try to make this easier by publishing a for every module. We also keep compatibility with older releases (current - 1 at least) so you can update your modules before updating the entire installation.

Internally Kafo has code to generate a hiera answers file because in the end it’s essentially puppet apply kafo_configure.pp with hiera set up. It’s a pretty straight forward conversion (as you already noticed) and ideally we’d provide some command line utility to convert it for these use cases.


Alright I’ll proceed this way then.

If someone changed a setting in the GUI, can I somehow compare that change against what I have in my manifests, or export the values?

I see that foreman_config_entry can be used to set settings under Administer > Settings. Is that something I could use to configure Administer > LDAP Settings or Administer > Role also?


There’s no versioning or export of smart class parameters, but we audit changes and log all requests.


Yes, every setting can be enforced that way. We don’t have an easy parameter available now to just set a hash of them, but you can write it in your own profile class.


Sounds good. I’ve made some progress but I’ve also run into a few roadblocks.

Can anyone point me to examples or blogs which can show some of the common implementations of this?