- How do I use unattended installations (Kickstart, jumpstart, preseed)?
- Whats inside the provisioning templates (Kickstart / jumpstart /preseed, pxelinux etc) ?
- Installation on NAT/Proxied networks
- Modifying/Creating the template
- Specific distribution unattended installation details
- 3 state boot for managing unknown hardware
- See also :
- Troubleshooting Flowchart
How do I use unattended installations (Kickstart, jumpstart, preseed)?¶
Foreman manages the host creation process by controlling a host's DHCP, DNS, TFTP boot files, Puppet CA and node classification. This is whole process is handled in the core foreman program and in several satellite proxies running at various locations within the organization. More details can be found on the Foreman_Architecture page.
Foreman automates network boot processes using PXEboot, gPXE, (or native Solaris net:dhcp).
You probably want to look into installing the Smart Proxy (which could be on the same machine as well).
Whats inside the provisioning templates (Kickstart / jumpstart /preseed, pxelinux etc) ?¶
These files are all generated dynamically based on the setting of each host in Foreman, things like partition tables and root password can be unique per server.
if you want to see the kickstart/preseed etc you may use the spoof parameter, just point your browser to:
- 123.321.123.321 is the hosts IP Address (the one you want to build).
- usually you want to see the page source, the browser might display the file in html which will result in hard to read output.
Installation on NAT/Proxied networks¶
By default, Foreman uses the IP of the incoming request to identify the machine, and render the appropriate template (which is why the 'spoof' parameter is needed to view it in your browser, as above). If your target (the machine being built) is not on the same subnet as Foreman, this can be a problem.
Foreman 1.1 has added UUID tokens support to the install methods to work around this, it is disabled by default, but can be enabled by altering 'token_duration' in the Settings page. This is the number of minutes an install token will be valid for (0 disables the function). A token is generated on a TFTP server when a host is put into the build mode and then it is kept for all subsequent requests, therefore each host has a unique identificator for all phases of the provisioning.
The tokens have an expiry duration so that a host which fails its build cannot have its installation template data (potentially containing root passwords and so on) stolen at a later date by a lucky guess or brute force of the UUID token. We suggest 60 minutes is usually enough for most installs, but if you are not so security minded, you could set a very large number here. In any case, a new token is generated every time the Build button is clicked for the host; it is then deleted when the build is complete, or when the build is cancelled (via a second click of Build).
Enabling this function will alter the foreman_url() function in the templates to include the current token for the host. If you have replaced the foreman_url() calls in your templates with hardcoded URLs, you should append:
?token=<%= @host.token %>
to your templates.
Modifying/Creating the template¶
Template association to hosts¶
The guiding principle within Foreman is that we don't want to associate templates with hosts directly.
There are 4 ways to associate a template with a host
- Though a host group.
- Though an environment.
- Though a combination of a host group and an environment (such as web servers in development mode).
- Though an operating system.
Therefore, there are few steps which are required in order to relate hosts and templates.
- Make sure you define at least one operating systems.
- Create each template and associate the valid operating systems to it.
- Optionally, associate the template with hostgroups and/or environments.
- Edit the relevant operating system and define a default/fallback template for each relevant template type.
A special type of a template is called "PXE Default File" which is the default PXE template.
The included example will setup PXE menus for each configured host group (allowing you to deploy hosts without puppet if you require that functionality).
Dynamic disk partitioning¶
It is possible to use a script (e.g a kickstart post script) instead of a static partition table.
see Dynamic disk partioning
Note Kickstart requires that Foreman port would be 80, therefor you should probably configure foreman using passenger or alternative technologies.
(Examples could be found in our reference Foreman Puppet module
Specific distribution unattended installation details¶
- Kickstart based unattended installation
- Preseed based unattended installation
- Solaris Unattended installation
- Yast based unattended installation
Edit config/settings.yaml and add this line:
and restart your foreman instance.
3 state boot for managing unknown hardware¶
See 3 state boot