Cloud-init and the live server installer

Server
#1

We are working on enabling cloud-init during the subiquity live session.

The motivation for this is to let users of systems with basic terminals complete the installation via SSH. However it also provides other interesting possibilities.

The default cloud.cfg in the live session by default will create a random password for the “installer” account. In other respects, little will change by default – the networking will try to dhcp on all interfaces, and the existing mechanism of configuring the network via ip= arguments will continue to work. But of course, having cloud-init around allows other possibilities such as using cloud-config snippets on the kernel command-line (cc: proxy: some-proxy end-cc) or by providing a cloud-init data source (local or remote).

Having cloud-init running in the live session gives full flexibility to users to automatically do anything in the live-session one could possibly wish for. This led us to thinking that the ‘autoinstall’ config could be provided via cloud-config. Meaning, that one simply provides autoinstall: in the user-data just like any other ephemeral configuration.

This would obsolete the section of the autoinstall design about providing the autoinstall file, as cloud-init supports a great deal of flexibility around how user-data is provided and merged.

The easiest meta-data source to provide is “NoCloud” which is documented at https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html. The user-data files can be put on a filesystem with label CIDATA or served via http (supplying the url on the kernel command line). An minimal example of what the user-data might look like for a simple autoinstall would be:

#cloud-config
autoinstall:
  version: 1
  identity:
    username: user
    password: $crypted_pass

If this is served up at http://10.0.0.1/user-data and an empty file served at http://10.0.0.1/meta-data then your system should be booted with this on the kernel command line:

    ds=nocloud-net;s=http://10.0.0.1/
Server autoinstall design questions
Please review design for automated server installs
#2

Hi Michael,

So I understand, would this cloud-init-based approach be in place of the approach discussed here and here (i.e., those approaches would not be used in any way)?

As I understand it, the alternate Ubuntu installer (based on the original Debian installer & using preseed files) will not be shipped as part of Ubuntu 20.04, and I’m preparing for the new approach.

If there’s any in-progress code, I’d be keen to take a look at it and start testing with it. Thanks very much.

#3

@jwcampbell - I believe this proposal is in addition to the autoinstall work that is already going on. This adds the ability to SSH to a system that is getting installed and can pass your autoinstall data in yet another way.

You can always give the daily Focal images a spin from the link below. We should have beta images out shortly.

http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/

Debian installer images are not going to be supported in 20.04, but we will spin some to have available.

1 Like
#4

Yes, this is more a tweak and a modification to what was proposed before than a replacement. In particular I’ve been keeping the wiki page up to date as the design has evolved.

We’re really close to this being ready for wider testing! I’ll be sure to post in the forum and in each thread on the topic when we are.

1 Like
#5

Hi, I just installed Ubuntu Server 20.04, great job with the new installer and everything. However there is one thing I don’t understand. Why do I have cloud-init installed on my bare metal system? It’s not a cloud! Can I remove it? It is confusing to see it installed, and normally on a server system I don’t want packages I don’t need.

If you are using it to configure the system after the installation, can’t you just run it as the last stage of the installer, without actually installing it?

#6

Despite the name, cloud-init is useful for initialising servers too. You should be able to remove it after first boot has completed. Doing engineering work to reduce the package count of an installed system by 1 does not seem to be worth it to me.

#7

If I install cloud-init on a minimal server I build using the mini.iso, it adds 77 packages. Since the minimal server only had 371 packages to begin with, this is not a light install

The following NEW packages will be installed:
  cloud-guest-utils cloud-init dbus-user-session dconf-gsettings-backend dconf-service dirmngr eatmydata gdisk gir1.2-packagekitglib-1.0 glib-networking glib-networking-common glib-networking-services gnupg gnupg-l10n gnupg-utils gpg
  gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gsettings-desktop-schemas libappstream4 libasn1-8-heimdal libassuan0 libbrotli1 libdconf1 libeatmydata1 libglib2.0-bin libgssapi3-heimdal libgstreamer1.0-0 libhcrypto4-heimdal
  libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libkrb5-26-heimdal libksba8 libldap-2.4-2 libldap-common libnpth0 libpackagekit-glib2-18 libpolkit-agent-1-0 libproxy1v5 libroken18-heimdal libsasl2-2 libsasl2-modules
  libsasl2-modules-db libsoup2.4-1 libstemmer0d libwind0-heimdal packagekit packagekit-tools pinentry-curses policykit-1 python3-attr python3-blinker python3-configobj python3-cryptography python3-distutils python3-importlib-metadata
  python3-jinja2 python3-json-pointer python3-jsonpatch python3-jsonschema python3-jwt python3-lib2to3 python3-markupsafe python3-more-itertools python3-oauthlib python3-pyrsistent python3-requests-unixsocket python3-serial
  python3-setuptools python3-software-properties python3-zipp software-properties-common unattended-upgrades
0 upgraded, 77 newly installed, 0 to remove and 0 not upgraded.
#8

Ubuntu Server is defined as having ubuntu-server metapackage installed.

Anything smaller, is no longer Ubuntu Server product, but a minimal cli Ubuntu Base installation not specific to any particular workload. I worry, when you call something a server, if it doesn’t even have gnupg installed. I mean, how can that server verify any downloads?

mini.iso based installations are now legacy.

#9

gpgv is installed. I assume that’s how

#10

This is patently untrue. The minimal installation using the mini.iso was much more than the minimal cli-base that you refer to and was enough to fulfill the needs of many, who didn’t need the full server install. And yes, gpgv was included in it. With mini.iso going away, the only two options for bare-metal are either build it up from the base-cli image or trim down from the full-server including cloud-init bloatware. This is a very bad decision - Team Ubuntu really needs to rethink this.

#11

We have a separate product Ubuntu Minimal Cloud Images

http://cloud-images.ubuntu.com/minimal/releases/

These are very tiny. And they are intended for non-interactive use, and are slimmer than mini.iso installs ever were.

For example, they remove translations, manpages, and a lot of cruft that is not needed for runtime execution.

Comparing the lxd root tarball regular Ubuntu Server Cloud Image tarball is 303M whilst the Ubuntu Minimal Cloud Image tarball is mere 89M.

We try to embody all of our expertise to build the best artifacts for each usecase. Such that nobody has to spend any amount of time, trying to figure out “how to get a tiny ubuntu”. For small&fast non-interactive workloads it’s the Ubuntu Minimal images.

Why would you start with a full-fat Ubuntu Server install, instead of using the minimal images which are optimized for maximum speed and minimal size?

1 Like
#12

Despite the several cloud images you are providing, there’s nothing that’s equivalent to what we were getting with mini.iso based minimal install. Many of us found it perfect for interactive use without the extras from the full Ubuntu Server release. Now the ubuntu-server meta-package itself has undergone additional bloat owing to cloud-init, which is totally unnecessary for the bare-metal installs. So now there’s an even stronger case for something equivalent to the mini.iso based minimal install (or the ubuntu-standard meta-package, which is what it corresponds to).

The only way to get there presently is to start with the minimal ubuntu base root-fs image, manually set up boot images and loader, unminimise it and finally install the ubuntu-minimal & ubuntu-standard meta-packages. This used to be quite a straightforward process with mini.iso up until now.

Perhaps you should consider ubuntu-minimal or ubuntu-standard (meta-packages) equivalent full disk image for bare-metal (intended for interactive use), which is conspicuously missing from your current lineup? Even a root-fs image would do, as long as it includes the boot images. And please keep cloud-init out of it, if you do decide to do it. There are plenty of options already for those who’re looking for that functionality.

#13

Well OK, that’s not the same thing though. Even if the current installer was changed to not depend on cloud-init, it would still be installing “Ubuntu server” which is a different thing from what mini.iso installs.

#14

I spent a lot of time trying to untangle this topic and I think I was able to summarize all the moving parts in a single blog post. Thanks for everyone’s comments / feedback here, I hope this helps the next person who stumbles across this.

2 Likes