Satellite 6.2 Feature Overview: Applying Custom Configuration via the installer.
Requirements:
- Satellite 6.2.8 or newer.
- foreman-installer-1.11.0.15-2 or newer.
Applying custom configuration to your Satellite
The installer for Satellite is Puppet-based which means that every time you run it, it corrects anything that’s not in the expected state. Having an installer based on configuration management is often valuable -- but it can result in surprising behavior when you modify a managed file and find out after the next upgrade it’s back to the default.
This is most often apparent for users who have complex DNS or DHCP configurations that are beyond the simple cases the installer can configure. We have two options to help you there: --foreman-proxy-dns-managed=false and --foreman-proxy-dhcp-managed=false. If you specify these, we’ll leave your DHCP and DNS configurations alone.
If you forget, there’s no worries - every file the installer replaces will be saved in the filebucket. In the installer logs anytime we overwrite a file, you'll see an entry like this:
/Stage[main]/Dhcp/File[/etc/dhcp/dhcpd.conf]: Filebucketed /etc/dhcp/dhcpd.conf to puppet with sum 622d9820b8e764ab124367c68f5fa3a1
The old file is restorable with this command:
puppet filebucket -l restore /etc/dhcp/dhcpd.conf 622d9820b8e764ab124367c68f5fa3a1
See this KCS solution for more information about the filebucket.
However, we can’t have a managed flag for everything - Satellite needs to manage Apache and Puppet for the application to work correctly. Additionally, not every puppet class that’s part of the installer has command line options you can see. Some, like the foreman_proxy puppet class is at the “top-level,” of the installer, however there are a number of puppet classes that are used internally as libraries such as apache, postgresql, qpid and puppet.
You generally don’t need to worry about these - the defaults work for most. However, in some cases you may need to make small changes. For example, to customize Apache to meet internal security guidelines. You’ll find yourself pulling out your hair every time the satellite-installer helpfully reverts your changes to our defaults.
You can now configure the deeper layers of the installer with a YAML file in /etc/foreman-installer/custom-hiera.yaml and those changes will persist across installer runs.
How does it work?
The YAML file consists of entries, one per line, in the format of:
<puppet class>::<parameter name>: <your value>
Some of the most commonly requested things are listed below:
Apache
To set the ServerTokens directive to only return the Product name, add this line to custom-hiera.yaml:
apache::server_tokens: Prod
To turn off server signature entirely:
apache::server_signature: Off
And finally to turn off TRACE:
apache::trace_enable: Off
Puppet
To enable the future parser:
puppet::server_parser: future
Pulp
Pulp workers
To configure the number of pulp workers:
pulp::num_workers: 8
The puppet modules for the installer are stored in /usr/share/foreman-installer/modules and /usr/share/katello-installer-base/modules, you can look at the .pp files for documentation of the parameters and see the kinds of values they expect. If you have specific questions about whether a particular value is safe to alter, you can contact Red Hat support.
Setting some values may have unintended consequences that affect the performance or functionality of Satellite. Consider the impact of the changes before you apply them, and test them in a non-production environment first. If you do not have a non-production Satellite environment, you can leverage the --noop & --verbose switches to the installer to ensure your changes will be applied.
If your changes cause problems, remove the offending lines from the custom-hiera.yaml and run the installer again.
Candlepin/tomcat
Be aware there is a This content is not included.bug that installer does not restart tomcat service upon changing configuration, thus not really applying the change from custom-hiera.yaml.
Xinetd
To enable logging in xinetd.
xinetd::log_type: SYSLOG authpriv
xinetd::log_on_failure: HOST
xinetd::log_on_success: HOST PID EXIT DURATION