BitFolk » Xen Shell

The forthcoming release of Ubuntu 22.04 (21 April) does away with debian-installer. Actually that was deprecated in 20.04 and removed in 21.10 I think. Anyway, no more step by step install with Debian installer.

We're going to have to embrace cloud-init, where the stock official Ubuntu Server cloud image is booted with a separate data volume that contains all custom data and then it configures it on first boot.

Eventually we'd like to offer a way for customers to supply their own cloud-init user-data but in the interests of making Ubuntu 22.04 usable for new installs as soon as possible, the first version of this is just going to do the minimal amount of customisation.

The minimal required information is:

• Fully-qualified domain name of the host, e.g. foobar.vps.bitfolk.space
• SSH public key(s) for authorized_keys or a password, both for default user (ubuntu)

In an ideal world we would not allow password auth, but I'd say about half of new installs do not supply an SSH public key and actually have their password emailed to them in clear text.

So the procedure I'm thinking is:

xen_shell> install ubuntu_jammy
Fully-qualified domain name of new install? [foobar.vps.bitfolk.space]
Password for user 'ubuntu'?
Proceed with install? WILL WIPE YOUR DISKS! [y/N]

The name suggestion will come from the reverse DNS of their main IP, if set, so they can just press return to keep the same name.

As is standard for the Ubuntu cloud image, SSH password auth will remain disabled so even though a password is asked for it will not be possible to log in by SSH using it. They would have to log in by the Xen console and either manually enable password auth or add an SSH public key.

Any SSH public keys that are present in the Panel would be added to ~ubuntu/.ssh/authorized_keys

Once confirmed:

• the config volume will be generated
• their xvda overwritten with the (unmodified) cloud image
• their VM booted with config volume attached as /dev/xvdz
• their VM should boot and configure everything and leave user at login prompt

Subsequent boots will not have the config volume attached. To re-run this process they would have to use the Xen Shell's install command again.

Is this an acceptable way for the initial implementation to work?

Suggestions for how it should work in some future version are welcome, but I am especially interested in what the minimal first approach should be like.