Public lightweight sway developer desktop with OSTree and podman/toolbox

Introduction

One and a half year ago I switched to a self-built OSTree based minimal i3 desktop and never looked back. Despite running Fedora updates-testing and finding/reporting lots of regressions, I have never had a situation where a simple rpm-ostree rollback would not have saved the day. There is zero cruft accumulating, neither due to upgrade drift from config files nor due to piling up added/changed files in /usr. And development or trying something out are now more flexible and comfortable than ever, mostly thanks to the progress in the container space.

While that bedrock has stayed the same during that time, technology development has not stopped, so it is time to look into what changed since then.

Sway window manager

Sway is a tiling wayland compositor/window manager which is mostly compatible to i3. I had tried that a few times, and previously always ran into some trouble (like, keyboard not working at all), but my last attempt in April finally worked, and I kept it.

It looks and works quite a bit more nicely, mostly thanks to waybar having great defaults and kanshi dynamically configuring displays (something that I never bothered to set up for X.org/i3). It also needs fewer moving parts: There is no need for a display manager any more, I just replaced that with these ~/.bashrc lines:

# auto-start sway on tty1
if [ "$(tty)" = "/dev/tty1" ]; then
    export PATH=$PATH:~/bin
    export `gnome-keyring-daemon --start --components=ssh`
    exec sway > $XDG_RUNTIME_DIR/sway.log 2>&1
fi

I.e. when my computer boots, I just log into VT1, and it starts sway there.

My sway config is public; if you are interested, please have a look!

Sway desktop screenshot

Development

podman containers and especially the toolbox utility on top of it have matured since then, and are now super comfortable. There is no need any more to carefully set up and configure mock/schroot to bind-mount your home dir or parts of /dev or /run when you want to test out stuff – toolbox does all that for you, and on top of it is faster as it builds on top of standard container images rather than bootstrapping everything from scratch.

Also, I can now build and use toolboxes (i.e. “special” containers) for my Linux stuff in pretty much exactly the same way: build-cockpit-toolbox for Fedora, and build-debian-toolbox for Debian or Ubuntu. I run these scripts once a week to rebuild the containers from scratch. When I want to do Fedora/cockpit development, I do toolbox enter -c devel (conveniently aliased to ts as in “toolbox shell”), and for Debian I can do toolbox enter -c sid.

❱❱❱ toolbox list
IMAGE ID      IMAGE NAME                                        CREATED
3ac100502d21  registry.fedoraproject.org/f33/fedora-toolbox:33  3 weeks ago

CONTAINER ID  CONTAINER NAME  CREATED         STATUS   IMAGE NAME
0a17a515c32c  devel           34 minutes ago  running  registry.fedoraproject.org/f33/fedora-toolbox:33
03def0263a0d  sid             34 minutes ago  running  docker.io/debian:sid

Things like VMs or libvirt have worked well in standard containers for pretty much ever, but thanks to toolbox’es clever setup even graphical programs work just fine out of the box (for both Wayland and X.org). So whenever I want to try the latest GIMP, calibre, or need Geogebra or Google Chrome for a quick thing, they are just a dnf/apt/pip/tar install away, and don’t cause permanent clutter.

Maintenance

Until recently I built my OSTree on my laptop itself into a temporary repo, then upgraded to that, and threw it all away. This works fine, but I wanted to move this off my machine, automate it fully, and publish the repository. My server runs Debian 10, which does not yet have podman, lxd, or another easy unprivileged container tool. But why not let this stuff run on public infra?

For work I have used GitHub Actions a lot lately, and that works just as well for building OSTrees, with some tricks. So I added a workflow to my workstation-ostree-config project, mirrored it to GitHub, and voilà – it runs automatically every Saturday morning now, and I can trigger it in the web UI with a convenient button. My server then fetches the zip artifact and unpacks it into https://piware.de/ostree/pitti-workstation/ , from where it is easy to use:

sudo ostree remote add --no-gpg-verify piware https://piware.de/ostree/pitti-workstation/
sudo rpm-ostree rebase piware:pitti-desktop

After that, rpm-ostree upgrade is all it takes, and is a matter of seconds only.

Once Debian 11 is released, I’ll move the whole build process to my server, as that is altogether more efficient and avoids keeping secrets around (in this case, a GitHub token to be able to download the workflow artifact).

Home