Installing without sitting in front of it

Measuring an image

Two things are read, and everything else rests on them. How it boots: the image's own bootloader configuration, whichever of the usual three it uses, all of which end in the same three values — a kernel, an initrd and a command line. That command line matters as much as the kernel, because it carries what a live system needs to find itself again; booting the kernel without it gives a machine that comes up into nothing.

What it carries: the root filesystem on the image is mounted, and where that only holds another image, that one too. What is looked for are the things a decision depends on — an installer that can be answered, an init system, a package manager, a kernel. All of it as files that are either there or not.

Answered, or copied

The image brings an installer. Then it is told what to do instead of asking: an answer file, in the language that installer reads. For Debian's netinst that is a preseed, and it is baked into the initrd, because the installer reads it out of its own initrd root before it asks anything at all — no network, no remastered ISO, nothing to serve.

The image brings no installer but a finished system. A live image carries a complete root filesystem — the very thing a graphical installer would have copied onto the disk after all its questions. So there is nothing to answer: the host mounts the one, writes the other, and steps into the copy to finish it. Nothing runs in the guest at any point; the VM is started for the first time when it is already installed.

Only an image with neither is one that cannot be installed unattended, and that is said rather than attempted.

The first boot, for images that are already installed

A cloud image needs none of the above — it is installed already. What it needs is to become this machine, and that happens at its first boot: user, password and SSH keys come from a small provisioning medium Phillux builds for it.

Windows has its own version of the same idea: the setup reads its answer file from every CD drive, so it installs fully automatically with a local user in place.

Templates: capture and pour

Set a VM or a container up, save it as a template, and create from it at will. What really takes work is not the copying but the generalising: a copy that matches the original bit for bit shares with it everything that ought to be unique — machine name, machine identifier, SSH host keys, DHCP identifier. Two such guests on the same network can end up with the same address, and whoever connects by SSH sees a warning about a changed host key, or worse does not see it, because both have the same one.

With containers that can be fixed, because the root filesystem lies open. With VMs everything sits inside the disk, and touching that reliably from outside would mean mounting a foreign filesystem — so there Phillux warns instead of botching it.

A running source is not captured. Copying a disk while it is in use yields the state of a system that lost power — half-written files, open databases — and out of such a template the same broken guest comes as often as you like. When a machine may stand still is the operator's decision, not the software's.