Unattended installations
Version 29 (Ohad Levy, 11/15/2011 10:42 am)
| 1 | 4 | Ohad Levy | {{toc}} |
|---|---|---|---|
| 2 | 4 | Ohad Levy | |
| 3 | 1 | h1. How do I use unattended installations (Kickstart, jumpstart, preseed)? |
|
| 4 | 1 | ||
| 5 | 21 | Ohad Levy | 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. |
| 6 | 1 | ||
| 7 | 27 | Ohad Levy | Foreman automates network boot processes using PXEboot, gPXE, (or native Solaris net:dhcp). |
| 8 | 1 | ||
| 9 | 26 | Ohad Levy | |
| 10 | 27 | Ohad Levy | You probably want to look into installing the [[Smart-Proxy:Wiki|Smart Proxy]] (which could be on the same machine as well). |
| 11 | 26 | Ohad Levy | a nice summary about the process can be found in the following "blog post":http://engineering.yakaz.com/managing-an-infrastructure-datacenter-with-foreman-and-puppet.html |
| 12 | 26 | Ohad Levy | |
| 13 | 26 | Ohad Levy | |
| 14 | 3 | Ohad Levy | h2. Whats inside the provisioning templates (Kickstart / jumpstart /preseed, pxelinux etc) ? |
| 15 | 3 | Ohad Levy | |
| 16 | 1 | 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. |
|
| 17 | 4 | Ohad Levy | |
| 18 | 1 | if you want to see the kickstart/preseed etc you may use the spoof parameter, just point your browser to: |
|
| 19 | 1 | ||
| 20 | 28 | Ohad Levy | <pre>http://foreman/unattended/provision?spoof=123.321.123.321</pre> |
| 21 | 1 | ||
| 22 | 4 | Ohad Levy | * 123.321.123.321 is the hosts IP Address (the one you want to build). |
| 23 | 1 | * usually you want to see the page source, the browser might display the file in html which will result in hard to read output. |
|
| 24 | 1 | ||
| 25 | 1 | h2. Modifying/Creating the template |
|
| 26 | 1 | ||
| 27 | 18 | Justin Sherrill | See [[TemplateWriting]] |
| 28 | 5 | Ohad Levy | |
| 29 | 22 | Frank Sweetser | h3. Template association to hosts |
| 30 | 22 | Frank Sweetser | |
| 31 | 22 | Frank Sweetser | The guiding principle within Foreman is that we don't want to associate templates with hosts directly. |
| 32 | 22 | Frank Sweetser | There are 4 ways to associate a template with a host |
| 33 | 22 | Frank Sweetser | |
| 34 | 22 | Frank Sweetser | # Though a host group. |
| 35 | 22 | Frank Sweetser | # Though an environment. |
| 36 | 22 | Frank Sweetser | # Though a combination of a host group and an environment (such as web servers in development mode). |
| 37 | 22 | Frank Sweetser | # Though an operating system. |
| 38 | 22 | Frank Sweetser | |
| 39 | 22 | Frank Sweetser | Therefore, there are few steps which are required in order to relate hosts and templates. |
| 40 | 22 | Frank Sweetser | |
| 41 | 22 | Frank Sweetser | # Make sure you define at least one operating systems. |
| 42 | 22 | Frank Sweetser | # Create each template and associate the valid operating systems to it. |
| 43 | 22 | Frank Sweetser | # Optionally, associate the template with hostgroups and/or environments. |
| 44 | 22 | Frank Sweetser | # Edit the relevant operating system and define a default/fallback template for each relevant template type. |
| 45 | 22 | Frank Sweetser | |
| 46 | 22 | Frank Sweetser | A special type of a template is called "PXE Default File" which is the default PXE template. |
| 47 | 22 | Frank Sweetser | The included example will setup PXE menus for each configured host group (allowing you to deploy hosts without puppet if you require that functionality). |
| 48 | 22 | Frank Sweetser | |
| 49 | 23 | Paul Kelly | h3. Dynamic disk partitioning |
| 50 | 5 | Ohad Levy | |
| 51 | 10 | Ohad Levy | It is possible to use a script (e.g a kickstart post script) instead of a static partition table. |
| 52 | 10 | Ohad Levy | see [[Dynamic disk partioning]] |
| 53 | 20 | Ohad Levy | |
| 54 | 20 | Ohad Levy | *Note* Kickstart requires that Foreman port would be 80, therefor you should probably configure foreman using passenger or alternative technologies. |
| 55 | 1 | (Examples could be found in our reference "Foreman Puppet module":http://github.com/ohadlevy/puppet-foreman |
|
| 56 | 23 | Paul Kelly | |
| 57 | 24 | Paul Kelly | h2. Solaris |
| 58 | 24 | Paul Kelly | |
| 59 | 24 | Paul Kelly | h3. Media notes |
| 60 | 24 | Paul Kelly | |
| 61 | 24 | Paul Kelly | A Solaris distribution should be declared in the same form as a Linux distribution. There should be an http based access URL, (the path variable,) so that the smart-proxy can |
| 62 | 24 | Paul Kelly | download the required components for the build. As the Solaris jumpstart process is performed via NFS rather than TFTP the distribution media must also be made available for |
| 63 | 24 | Paul Kelly | ReadOnly mounting on the clients. The fields describing this alternative access naming scheme are revealed on the Media page when a Solaris operating system is selected. The |
| 64 | 24 | Paul Kelly | Solaris build can proceed via a conventional package build, where the packages selected are the SUWNCreq minimal install, or a flash build. The flash archives are located under |
| 65 | 24 | Paul Kelly | the distribution directory by default but can be located anywhere that can be accessed via NFS. |
| 66 | 24 | Paul Kelly | |
| 67 | 24 | Paul Kelly | h3. jumpstart files |
| 68 | 23 | Paul Kelly | |
| 69 | 23 | Paul Kelly | The Solaris jumpstart process is occurs in two phases; a diskless client is first booted and then in phase two, the host mounts its build media and configuration files from an NFS location and proceeds with the build. Foreman provides a skeleton configuration directory structure suitable for NFS mounting on the host. In this structure are files that are customised to forward configuration requests to the Foreman instance. This directory tree, located at .../foreman/extra/jumpstart, should be NFS shared to the subnet that contains any potential Solaris clients. Some customization of this directory tree may be required. See [[Solaris_jumpstart_directory]] |
| 70 | 25 | Paul Kelly | |
| 71 | 25 | Paul Kelly | h3. Model consolidation |
| 72 | 25 | Paul Kelly | |
| 73 | 25 | Paul Kelly | When Foreman imports a host that has not been configured and built by Foremen it will attempt to determine the model of that machine by analyzing the facts that are associated with the host. This can often result in many badly named models all referring to what should be a single manufacturers model. A rake task has been provided that attempts to consolidate all these duplicate malformed names into a single sensible model together with the appropriate Solaris vendor class and Solaris hardware model. See [[models_consolidate|rake models::consolidate]] |
| 74 | 29 | Ohad Levy | |
| 75 | 29 | Ohad Levy | h3. using gPXE |
| 76 | 29 | Ohad Levy | |
| 77 | 29 | Ohad Levy | see [[gPXE]] |
