AutomatedServerInstalls
Differences between revisions 9 and 60 (spanning 51 versions)
|
Size: 6988
Comment:
|
← Revision 60 as of 2020-06-11 04:19:11 ⇥
Size: 61
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ||<#FF5555> '''This document is entirely a description of something that does not yet exist''' || = Automated Server Installs for 20.04 (and maybe 18.04.4?) = ||<#FF5555> '''This document is entirely a description of something that does not yet exist''' || Please direct feedback on this proposal to $TBD. <<TableOfContents()>> = Introduction = The server installer for 20.04 supports a new mode of operation: automated installation, autoinstallation for short. You might also know this feature as unattended or handsoff or preseeded installation. Autoinsallation lets you answer all those configuration questions ahead of time in an ''autoinstall file'' and lets the installation process run without any interaction. = Differences from debian-installer preseeding = ''preseeds'' are the way to automate an installer based on debian-installer (aka d-i). autoinstalls for the new server installer differ from preseeds in the following main ways: * the file format is completely different (yaml vs debconf-set-selections format) * when the answer to a question is not present in a preseed, d-i stops and asks the user for input. autoinstalls are not like this: if there is any autoinstall config at all, the installer takes the default for any unanswered question = Providing the autoinstall file = The autoinstall file can be provided in the following ways: * As /autoinstall.cfg in the initrd * As /autoinstall.cfg on the install media (in any partition!) * Via a http or https (or maybe tftp) URL on the kernel command line = Creating an autoinstall file = When any system is installed using the server installer, an autoinstall file for repeating the install is created at {{{/var/log/installer/autoinstall.cfg}}}. Alternatively there is a snap, ``autoinstall-editor``, that can be used to either edit or create from scratch an autoinstall file (it is actually mostly the same code as that that runs the installation in interactive mode). {{{ # start editing new config file $ autoinstall-editor # dump out to stdout a complete autoinstall config file with default answers everywhere $ autoinstall-editor --create # edit existing autoinstall file $ autoinstall-editor autoinstall.cfg }}} = The format of an autoinstall file = The autoinstall file is YAML. Here is an example file that shows off most features: {{{#!yaml version: 1 early_commands: - ping -c1 198.162.1.1 locale: en_US keyboard: layout: en variant: uk network: version: 2 network: eth0: dhcp4: yes proxy: http://squid.internal:3128/ mirror: http://repo.internal/ filesystem: recipe: name: lvm identity: username: mwhudson password: $crypted_pass ssh: authorized_keys: - $key allow_pw: no snaps: - go/stable debconf_selections: | bind9 bind9/run-resolvconf boolean false packages: - libreoffice - dns-server^ late_commands: - touch /autoinstalled }}} Many keys and values correspond straightforwardly to questions the installer asks (e.g. keyboard selection). There are some new options though: * `early_commands`: shell commands run after the installer has started, but before anything else (in particular, before scanning the system for block devices) * `debconf_selections` & `packages`: packages and configuration for them to be installed after installation has completed * `late_commands`: shell commands to run after the install has completed and any updates and packages installed, just before the system reboots == Filesystem configuration == Filesystem configuration is a complex topic and the description of the desired configuration in the autoinstall file can necessarily also be complex. The installer supports "layouts", simple ways of expressing common configurations. === Supported layouts === The two supported layouts at the time of writing are "lvm" and "disk". Each supports a match spec (see below) to define which disk they apply to (if omitted, a disk is chosen arbitrarily). {{{ filesystem: layout: name: lvm match: serial: CT* filesystem: layout: name: disk }}} Supplying no filesystem config is equivalent to choosing the lvm layout with no disk match spec. === action-based config === For full flexibility, the installer allows filesystem configuration to be done using a syntax which is a superset of that supported by curtin, described at https://curtin.readthedocs.io/en/latest/topics/storage.html. The extensions to the curtin syntax are mostly around disk selection. Curtin supported identifying disks by serial (e.g. `Crucial_CT512MX100SSD1_14250C57FECE`) or by path (e.g. `/dev/sdc`) and the server installer supports this as well. The installer additionally supports a ''match spec'' on a disk action that supports more flexible matching. The actions in the filesystem config are processed in the order they are in the autoinstall file. Any disk action is assigned a matching disk -- chosen arbitrarily from the set of unassigned disks if there is more than one, and causing the installation to fail if there is no unassigned matching disk. A match spec supports the following keys: * `model: foo`: matches a disk where ID_VENDOR=foo in udev, supporting globbing * `serial: foo`: matches a disk where ID_SERIAL=foo in udev, supporting globbing (the globbing support distinguishes this from specifying serial: foo directly in the disk action) * `ssd: yes|no`: matches a disk that is or is not an SSD (vs a rotating drive) * `size: largest`: take the largest disk rather than an arbitrary one if there are multiple matches * Anything else? So for example, to match an arbitrary disk it is simply: {{{ - type: disk id: disk0 }}} To match the largest ssd: {{{ - type: disk id: big-fast-disk match: ssd: yes size: largest }}} To match a Seagate drive: {{{ - type: disk id: data-disk match: model: Seagate }}} ``autoinstall-editor`` supports creating and editing configs with arbitrary disk match specs. Another extension to curtin syntax is how the size of partitions or LVM logical volumes are specified. Curtin just takes a size for this, but the server installer allows sizes to be specified as percentages of the containing device, or using min/priority/max as in d-i: (XXX I don't actually understand how min/priority/max works in d-i). {{{ - type: partition id: data-partition device: data-disk size: 75% - type: partition id: boot-partition device: boot-disk size: min: 512M priority: 600M max: 2G }}} = Possible future directions = There are other places we could put the autoinstall config: * As a b64encoded gzipped blob on the kernel command line * Given as a URL via DHCP Possibly the installer should support reporting progress to some endpoint. |
moved to https://ubuntu.com/server/docs/install/autoinstall |
FoundationsTeam/AutomatedServerInstalls (last edited 2020-06-11 04:19:11 by mwhudson)