AutomatedServerInstalls
Differences between revisions 7 and 60 (spanning 53 versions)
|
Size: 6846
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 (or unattended, or hands-off) installation, autoinstallation for short. This 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 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 And maybe these ways if people think they would be useful: * As a b64encoded gzipped blob on the kernel command line * Given as a URL via DHCP = 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: - rm -rf /etc/init.d }}} 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 XXX should support reporting status to some endpoint? == 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 "recipes", simple ways of expressing common configurations. === Supported recipes === The two supported recipes 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: recipe: name: lvm match: serial: CT* filesystem: recipe: name: disk }}} Supplying no filesystem config is equivalent to choosing the lvm recipe 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 }}} |
moved to https://ubuntu.com/server/docs/install/autoinstall |
FoundationsTeam/AutomatedServerInstalls (last edited 2020-06-11 04:19:11 by mwhudson)