This role provides a means to provision a Foreman or Satellite server with an organization and some content
This role requires the following Ansible Collections in order to work:
- 'theforeman.foreman' 3.4.0 or higher
- 'ansible.utils' 2.6.0 or higher
- 'ansible.posix' 1.4.0 or higher
Tested with Ansible 2.12 and higher
This role supports Foreman 3.2 / Katello 4.4 and up or Red Hat Satellite 6.11 and up.
Other requirements on the Ansible controller:
- python-netaddr (for subnet related tasks)
Check out the example inventory and playbooks for some guidance! Or read my blog post.
If you want to install Satellite via the Offline Installation ISO, make sure you have configured RHEL repo's from a Installation ISO or mirror as well.
When this role is used to create new content views and composites, the following strategy is applied:
- Content views are created with the same name as the product they contain
- Repositories that are newly created will be synchronized after creation (asynchronously)
- Composite content views that are newly created will be promoted to all lifecycle environments in the organization
The idea behind this is that COVs are the only things that are associated with clients. The Base CVs themselves are only present in the Library and should not be promoted to any other environment.
All created COVs have auto_publish enabled and sample playbooks to 'tag' a new version and publish it are provided.
For Host discovery, register the following records in DNS to allow the FDI to report to the correct server:
- For Foreman servers:
_x-foreman._tcp.dev.example.com 600 IN SRV 0 5 443 foreman.dev.example.com
- For Foreman Smart Proxies:
_x-foreman._tcp.dev.example.com 600 IN SRV 0 5 8443 fm-proxy.dev.example.com
If your environment does not work with these records, you can also set foreman_discovery_image_autodetect to false. This will use the default settings for Foreman. Those might break when using Smart Proxies.
Some of the settings used for Smart Proxies are shared with the Foreman server. In order to prevent duplicate settings, the following inventory is suggested
[foreman]
foreman.infra.example.com
[foreman_proxies]
fm-proxy.dev.example.com
[foreman_infra]
[foreman_infra:children]
foreman
foreman_proxies
Then put all the Global settings for Foreman in the group_vars for foreman_infra, which will then be available to both the Server and the Proxies. You can then create host_vars for each Foreman system (Server or Proxies) that contain the instance specific settings.
Sometimes the installer is unable to succesfully complete the configuration of the Foreman services. The Ansible tasks have been configured (unless you're running a version of Foreman/Satellite that does not support --detailed-exitcodes) to trigger on that.
When an issue occurs, you can follow the following steps to localize the issue:
- Run
foreman-installermanually, no arguments are required. This will give a general direction where to look - Check the logs in /var/log/foreman-installer
- Restart the Foreman services, this will sometimes 'reset' things after which Foreman will succesfully wrap up the installer.
For specific things, see below
Testing has shown that various settings can have an effect on whether a host can boot from the network.
We have tested the following setups:
-
Discovery:
-
KVM
- BIOS: works with default settings configured by this role. Can also be used with iPXE.
- UEFI: is a bit iffy, you might run into some issues trying to load the FDI from PXE as TFTP will timeout. iPXE works fine.
-
HyperV:
- Gen1 (BIOS): works with the default settings configured. Can also be used with iPXE.
- Gen2 (UEFI): requires iPXE, you must disable SecureBoot.
-
-
OS Deployment:
-
KVM
- BIOS: works with default settings configured by this role. Can also be used with iPXE.
- UEFI: use
pxe_loader: 'Grub2 UEFI'with default settings by this role. Can also be used with iPXE.
-
HyperV:
- Gen1 (BIOS): works with the default settings configured by this role up to CentOS7, CentOS8 and up requires Gen2.
- Gen2 (UEFI): requires iPXE, you must disable SecureBoot.
-
-
Boot local
-
KVM
- BIOS: works fine. Can also used with iPXE.
- UEFI: use
pxe_loader: 'Grub2 UEFI'with default settings by this role. iPXE may hang in UEFI system menu: https://community.theforeman.org/t/ipxe-does-not-boot-local-hard-disk-on-uefi/21437
-
HyperV:
- Gen1: works fine.
- Gen2: works fine, you must disable SecureBoot.
-
To enable iPXE set foreman_deploy_ipxe: true and use pxe_loader: 'None' for your OSes
Remove all the OSes from Hosts -> Operating systems (you can't delete the one where the foreman server is in)
Because the Foreman modules can't see the current password set for password fields, these cannot be compared.
Therefore these always changes (Operating systems, Upstream repo credentials etc.). This can cause extra actions depending on the resource changed. This hasn't proven problematic so far, but the play execution can take a little longer because of it.
As the Host Groups are the combined result of Activation Keys, Operating Systems and Lifecycles, the amount of configurability is limited. At time of writing the role will configure all hostgroups with the same Partition Table.
An example for a deployment with a different Partition Table is shown below:
# The partition table below is set to ignore
# all disks except the first one for automatic partitioning.
# Please note that it is does not autodetect disk types (vd or sd)
# so you'll have to hardcode the disk to be used
foreman_partition_tables:
- name: 'Kickstart default first disk only'
os_family: 'Redhat'
layout: |
<%#
kind: ptable
name: Kickstart default first disk only
model: Ptable
description: Managed by Ansible, your changes will be lost
%>
zerombr
clearpart --all --initlabel
ignoredisk --use-only=sda
autopart <%= host_param('autopart_options') %>
foreman_operating_systems:
- name: 'CentOS'
major_version: 7
arch:
- 'x86_64'
os_family: 'Redhat'
kickstart: true
kickstart_repo: 'CentOS7-Base'
partitions:
- 'Kickstart default first disk only'
root_pass: 'some_password'
parameters:
- name: 'autopart_options'
value: '--nohome'