Launchpad Entry: foundations-lucid-puppet-installer
Created: MathiasGug
Contributors:
Packages affected:
Summary
Release Note
Rationale
User stories
- Henri, a system administrator, uses puppet to manage all of his services located in different data centers. He can start the Ubuntu Server iso and can manually register with his puppet infrastructure during the installation.
- Jacob, a system administrator, uses puppet to manage all of his services located in different data centers. He uses a preseeding infrastructure to automatically boot strap the installation of all machines. He uses d-i support for puppet to automatically setup his systems with the existing puppet infrastructure.
Assumptions
Design
We'll leverage existing d-i infrastructure as much as possible.
preseed service on the puppet master
Relevant client information is included in a preseed file send to the client by a service running on the puppet master. The preseed service works from the client manifest and include the following information in preseed format:
- list of apt repositories
- list of packages to install
- list of preseeded debconf answers to the packages
- late_command script to run the puppet client in the target at the end
- puppet client configuration:
- (optional) generate a csr and a private key to include in the preseed
initial authentication
Implementation
See the Work Items in the blueprint.
Test/Demo Plan
Unresolved issues
BoF agenda and discussion
UDS Session notes
The installer can leverage a puppet infrastructure during the install process: locating the master, registering the node and possibly download manifests to complete the installation.
Discovery
- avahi integration (puppetmasterd)
- dns srv records
- manual discovery
Registration
- request created by the installer and (manual) validation on the master. Impact on first boot?
- pre-registered nodes for unattended installation.
Configuration
- can recipes be run from the installer? Should the installer just create the minimal puppet configuration so that configuration can happen during the first boot (unattended installation/boot)? Bootstrap: certificate request. Looks up puppet as a dns record. Sort of configuration: compiled on the server, shipped to the client via json/yaml. Could the preseed config system be used for that? Some parts of the puppet client could be integrated in the installer: list of packages to be installed by puppet could be handled by d-i instead, apt sources.list. Trimmed down the puppet manifests to a d-i understandable format - add a daemon on the puppetmaster to do the translation. Installer changes are then kept to a minimum. Make sure no private information gets into the preseed file. Bootstrap: private key and certificate generation. There is a CA on the puppetmaster. Generate a private key on the client. How to trust the requests?
- preseed a certificate.
- Is there a REST interface to Puppet? There could be a URL that would generate the cert? (details of interface don't matter though)
- As of puppet 0.25.0, the whole interface is RESTful for 0.25.x clients.
- tag puppet configuration items as bootstrap
run puppet in the chroot at the end of the install before reboot. when to generate a csr? Usually pre-generated.
Bootstrap:
- Point D-I to a cgi script that will generate the csr on the fly. Send the key and the csr, but not the cert.
- run puppet at the end in the chroot and use the standard ssl negotiation.
- Suggestion: ask the user whether to run puppet or wait for reboot to run it.
Note that daemons should not be started in the chroot during install - but that's OK because the installer's in-target program already neuters reasonable attempts to do this.
Feedback to the installer when the client is waiting for the master to sign the request (progress updates via debconf):
- For now, we don't really know the total number of steps, so we'll have to have an indeterminate progress bar with changing informational messages.