AutomatedServerInstalls
7334
Comment:
|
7260
|
Deletions are marked like this. | Additions are marked like this. |
Line 43: | Line 43: |
= Quick start = So you just want to try it out? Well we have [[/QuickStart|the page for you]]. |
|
Line 64: | Line 68: |
Technically speaking the config does not have a textual format, but cloud-init config is usually provided as YAML so that is the syntax the documentation uses. | Technically speaking the config is not defined as a textual format, but cloud-init config is usually provided as YAML so that is the syntax the documentation uses. |
Line 66: | Line 70: |
A minimal config (for a single disk system) is: | A minimal config is: |
Line 71: | Line 75: |
username: mwhudson | hostname: hostname username: username |
Line 118: | Line 123: |
` username: mwhudson`<<BR>> | ` hostname: hostname`<<BR>> ` username: username`<<BR>> |
Line 149: | Line 155: |
There are other things we could do by default in a system with multiple disks (create an LVM VG incorporating all of them, just install on one disk picked at random, install on the largest disk, etc etc). |
This document is a description of something that only partially exists at this stage |
Automated Server Installs for 20.04
This document is a description of something that only partially exists at this stage |
Please direct feedback on this proposal to community.ubuntu.com or the ubuntu-server mailing list.
Contents
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.
Autoinstallation lets you answer all those configuration questions ahead of time with autoinstall config 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 format is completely different (cloud-init config, usually 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: by default, if there is any autoinstall config at all, the installer takes the default for any unanswered question (and fails if there is no default). You can designate particular sections in the config as "interactive", which means the installer will still stop and ask about those.
Providing the autoinstall config
The autoinstall config is provided via cloud-init configuration, which is almost endlessly flexible. In most scenarios the easiest way will be to provide user-data via the nocloud data source.
The autoinstall config should be provided under the 'autoinstall' key in the config. For example:
#cloud-config autoinstall: version: 1 ...
Running a truly automatic autoinstall
Even if a fully noninteractive autoinstall config is found, the server installer will ask for confirmation before writing to the disks unless 'autoinstall' is present on the kernel command line. This is to make it harder to accidentally create a USB stick that will reformat a machine it is plugged into at boot. It is expected that most autoinstalls will be done via netboot, where the kernel command line is controlled by the netboot config -- just remember to put 'autoinstall' in there!
Quick start
So you just want to try it out? Well we have the page for you.
Creating an autoinstall config
When any system is installed using the server installer, an autoinstall file for repeating the install is created at /var/log/installer/autoinstall-user-data.
The snap described here does not yet exist |
Alternatively there is a snap, autoinstall-editor, that can be used to either edit or create from scratch an autoinstall config (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 with default answers everywhere $ autoinstall-editor --create > my-autoinstall.yaml # edit existing autoinstall config $ autoinstall-editor my-autoinstall.yaml
The structure of an autoinstall config
The autoinstall config has full documentation.
Technically speaking the config is not defined as a textual format, but cloud-init config is usually provided as YAML so that is the syntax the documentation uses.
A minimal config is:
version: 1 identity: hostname: hostname username: username password: $crypted_pass
Here is an example file that shows off most features:
version: 1
reporting:
hook:
type: webhook
endpoint: http://example.com/endpoint/path
early-commands:
- ping -c1 198.162.1.1
locale: en_US
keyboard:
layout: en
variant: uk
network:
version: 2
network:
ethernets:
enp0s25:
dhcp4: yes
enp3s0:
enp4s0:
bonds:
bond0:
dhcp4: yes
interfaces:
- enp3s0
- enp4s0
parameters:
mode: active-backup
primary: enp3s0
proxy: http://squid.internal:3128/
apt:
primary:
- arches: [default]
- uri: http://repo.internal/
sources:
my-ppa.list:
source: "deb http://ppa.launchpad.net/curtin-dev/test-archive/ubuntu $RELEASE main"
keyid: B59D 5F15 97A5 04B7 E230 6DCA 0620 BBCF 0368 3F77
storage:
layout:
name: lvm
identity:
hostname: hostname
username: username
password: $crypted_pass
ssh:
install-server: yes
authorized-keys:
- $key
allow-pw: no
snaps:
- go/stable
debconf-selections: |
bind9 bind9/run-resolvconf boolean false
packages:
- libreoffice
- dns-server^
user-data:
disable_root: false
late-commands:
- sed -ie 's/GRUB_TIMEOUT=.*/GRUB_TIMEOUT=30/' /target/etc/default/grub
error-commands:
- tar c /var/log/installer | nc 192.168.0.1 1000
Many keys and values correspond straightforwardly to questions the installer asks (e.g. keyboard selection). See the reference for details of those that do not.
Error handling
Progress through the installer is reported via the reporting system, including errors. In addition, when a fatal error occurs, the ConfigReference#error-commands are executed and the traceback printed to the console. The server then just waits.
Possible future directions
We might want to extend the 'match specs' for disks to cover other ways of selecting disks.
We could support kickstart compatibility as in kickseed.
FoundationsTeam/AutomatedServerInstalls (last edited 2020-06-11 04:19:11 by mwhudson)