We Serve All Flavours!

Adding Sprinkles

In the interests of “integration”, and because I wish to demonstrate yet more capabilities of cloud-init, I’m going to pre-emptively work around a long-standing bug (LP: #1974064) which I frequently run into, preventing links in PDFs from opening in the browser. But only if that browser is a snap … as Firefox is. Furthermore (without giving too much away from future posts in this series) there still appear to be some integration issues between the snapped Firefox and Wayland based environments in some of the desktops. So, in the interests of a level playing field for everyone we’re going to get cloud-init to install Firefox from a deb on first boot.

We need to add an apt source (the Firefox stable PPA), and add some configuration to pin its items higher than the archive’s. Thankfully, this is pretty simple to derive from all those guides out there showing how to do this on an already running system:

apt:
  sources:
    mozillateam:
      source: 'ppa:mozillateam/ppa'

write_files:
  - path: /etc/apt/preferences.d/firefox
    content: |
      Package: firefox*
      Pin: release o=LP-PPA-mozillateam
      Pin-Priority: 501

      Package: firefox*
      Pin: release o=Ubuntu
      Pin-Priority: -1

Now we can ditch that weird snap section in our configuration, and just stick firefox in the list of packages to install.

One other tip I’m going to add here, but which I won’t be adding to the experimental configurations as published, because the vast majority of people won’t want this, is configuration for an apt proxy (specifically apt-cacher-ng). To be clear, for most people I don’t recommend running this (a couple of times a month it sends my server into a bit of a tizz and needs kicking), but if you’re going to be repeatedly installing the same large packages (as I frequently do for packaging work, or in this case when installing several desktop packages which have similar bases) it can save a huge amount of time and bandwidth. Anyway, this is what the relevant snippet looks like:

apt:
  conf: |
    Acquire::http { Proxy "http://myproxy.local:3142"; }

Obviously, replace myproxy.local with the address of your local proxy.

Below is the full configuration we’ll be using (minus the apt-cacher configuration), with a fairly obvious placeholder for the desktop package. I’ll publish full configurations (including the config.txt, cmdline.txt, and network-config, largely derived from the prior post) in each section in case you want to play along at home. Just place these on the boot partition of an Ubuntu Server for Pi (23.04 or later) card [1] and adjust the highlighted lines to your tastes:

 1#cloud-config
 2
 3hostname: miss-piggy
 4
 5locale: en_GB.UTF-8
 6timezone: Europe/London
 7
 8keyboard:
 9  model: pc105
10  layout: gb
11  options: ctrl:nocaps
12
13user:
14  name: "dave"
15  lock_passwd: false
16  gecos: "Dave Jones"
17  plain_text_passwd: raspberry
18  sudo: "ALL=(ALL:ALL) ALL"
19
20ssh_import_id:
21  - lp:waveform
22
23apt:
24  sources:
25    mozillateam:
26      source: 'ppa:mozillateam/ppa'
27
28write_files:
29  - path: /etc/apt/preferences.d/firefox
30    content: |
31      Package: firefox*
32      Pin: release o=LP-PPA-mozillateam
33      Pin-Priority: 501
34
35      Package: firefox*
36      Pin: release o=Ubuntu
37      Pin-Priority: -1
38  - path: /home/dave/.profile
39    append: true
40    defer: true
41    content: |
42      export MOZ_ENABLE_WAYLAND=1
43
44package_update: true
45package_upgrade: true
46package_reboot_if_required: true
47
48packages:
49  - YOUR-DESKTOP-PACKAGE-HERE
50  - ubuntu-raspi-settings-desktop
51  - firefox

Bear in mind your first boot is going to install a lot of things, and it will take at least an hour (more like an hour and a half) even on a good A1-compliant SD card.

99 Flakes

One wrinkle I forgot to mention in the prior post is that of networking. The server images we’re basing this on use netplan, and start off by having it “render” the network configuration via networkd (part of systemd).

However, every Ubuntu desktop flavour ultimately winds up using Network Manager for its network configuration. While netplan is capable of rendering a configuration via Network Manager, that’s probably not what you ultimately want as your network configuration wouldn’t be editable via the Network Manager GUI (only the netplan YAML configuration files).

Why not change the initial netplan configuration to render through Network Manager instead? This won’t work because at first boot, the card is just Ubuntu Server for Pi and doesn’t contain Network Manager. That only gets installed along with the chosen desktop flavour, but that act requires a network to already be configured. Dependency cycles!

The fix is simple enough. Once the desktop has booted, and you’re all snugly logged in for the first time, run the following to delete the generated netplan configuration and re-apply the (now empty) settings:

$ sudo rm /etc/netplan/50-cloud-init.yaml
$ sudo netplan apply

At this point networkd will stop “managing” the interfaces and Network Manager will take them over. In the case of a simple DHCP-based Ethernet connection, it should reconfigure automatically and you’ll be back up and running in seconds. However, if you performed your initial set up over WiFi you’ll now need to go into the GUI network settings for your flavour (wherever that is — it can usually be found from the system-tray though) and re-enter your WiFi credentials.

This is one of the ways that this Frankenstein-like desktop setup differs from the official desktop releases. There are a few others (dual seeds, user creation differences, root-fs sizing, probably a few others that I’ve forgotten!), and if anyone’s interested I can go through them, but this is the only one that’s affected the use of the desktop during my explorations.

The Taste Test

What should I look for in a desktop? I can’t define this universally, so I’ll just go with what works for me. My personal workflow is probably a strange mix of deeply anachronistic, and semi-modern. On the one hand, I spend the vast majority of my time in a terminal window. On the other, I eschew office applications in favour of doing office-y work in a web-browser. Google Sheets for any spreadsheet work (though I have been known to dip into sc for trivial bits), and when I absolutely have to touch a word-processor [2], Google Docs.

I could almost get away with working on a Chromebook, but not quite. If I have PDFs to deal with (and between Canonical’s hiring push, and various hardware data-sheets, I get through quite a few of these), I use an honest-to-goodness standalone PDF reader, instead of the (usually horribly slow) built-in PDF readers in browsers. Sometimes I even … brace yourself … print them [3]!

I also play most of my music, served from the home server, in a standalone application, and the same goes for most films I watch (there are some good web-based systems for this, but browsers are heavy and I work on a Pi so I tend to try and limit my use of them to text-based duties). Most of my file manipulation is done from the command line, but sometimes for simpler stuff (especially involving external storage) I’ll resort to the file browser.

So, I’ll be looking for:

• A decent terminal — this is pretty much a given; it’d hardly be a Linux distro without a decent terminal!
• A decent browser — again, pretty much a given as we’ll be installing Firefox anyway.
• Some decent media applications — music player, video player, a standalone PDF viewer, preferably a good file browser for managing it all.
• Integration — I want to be able to click a link from my terminal, or in a PDF, and have it open in the web-browser. I’d like to be able to open files, archives, and videos straight from the file-browser, even from network shares (ideally without messing around with network mounts). The home server has all sorts of services for this (NFS, SMB, DLNA, etc. all advertised over avahi) so there should be plenty of opportunity here. I also want to be able to print stuff without jumping through tons of hoops (again, the printers here are network-accessible and advertised over avahi).
• Performance — it’s a Pi, so I can’t expect the world here, but the video player should handle 720p or 1080p sources in full-screen, smoothly. The music player should play without stuttering, and generally things shouldn’t feel (too) sluggish. The browser is an exception here: modern browsers are ridiculously (over-)complex beasts and I’ll allow some lee-way for this.
• Reliability — The more bugs I run into, the more points I’ll dock. Erm … are we doing points? Well, any bugs I run into I’ll point out. And possibly report, if I can figure out what to file ‘em against!

Now, with all that extra gubbins out of the way, on with the tests!

The Flavours

These are the flavours I’m intending to cover, which will become links to the relevant article:

• Lubuntu — the LXQt flavour
• Xubuntu — the XFCE flavour
• Ubuntu Budgie — the Budgie flavour
• Ubuntu Unity — the Unity flavour
• Kubuntu — the KDE flavour
• Ubuntu Studio — the creator’s flavour
• Ubuntu — comparison to the official GNOME-based image