Call for contributors: Ubuntu Server image with Gladys pre-installed (project launched by Howmation)

Development
1

Hi everyone,

I’m writing to ask for some help on a project that’s really close to my heart and could change a lot for new Gladys users.

The idea

Today, installing Gladys on a mini-PC requires going through an Ubuntu installation, then Docker, then Gladys. It’s accessible, but it remains a barrier for many people. The goal of this project is to offer a bootable ISO image that installs Ubuntu Server with Gladys pre-configured: you flash a USB key, boot the mini-PC, choose the disk, plug in the Ethernet, and at the end you open http://gladysassistant.local and Gladys is there. A real « Gladys box » that you make yourself.

Who’s behind it

It’s Howmation who started this project, and frankly, I think it’s a great idea. He has already done a huge amount of work, and the repository is public here: GitHub - GladysAssistant/ubuntu-server-gladys: WIP : Building a simpler OS to install Gladys Assistant · GitHub

Where we are

The core of the system is done. Concretely, in the repository there is already:

  • An installer based on Ubuntu Server LTS amd64, remastered with Subiquity Autoinstall (base image authenticated against Canonical signatures on each build)
  • An automated first boot that installs Docker, retrieves the gladysassistant/gladys:v5 image, and launches Gladys with Watchtower for updates
  • A tty1 console and a web setup page to follow the progress, with the new design already ported (still to be refined)
  • A hardened system by default: no SSH, no default account, locked root, automatic security updates
  • Python unit tests, QEMU integration tests (UEFI installation, first boot, network outage, power outage)
  • GitHub Actions workflows for CI, weekly tests, and release publishing
  • Complete documentation: architecture, build, operations, release, security, hardware checklist

What’s left to do

Howmation told me that the core is there, but we still need to make the CI/CD cleaner and more robust, and finish improving the design. He’s very busy right now with other developments, so the project needs extra hands to move forward. Here are the big topics we need help with:

  1. CI/CD: make the build, QEMU test, and release pipelines more reliable and simpler
  2. Tests on real hardware: the hardware checklist in the repository (docs/HARDWARE-TEST-CHECKLIST.md) needs to be validated on real mini-PCs (Intel N100/N150, Core, AMD Ryzen, NVMe, SATA, Secure Boot enabled or not). If you have a mini-PC on hand, it’s a valuable contribution even without writing a line of code
  3. Setup page design: finish refining the web interface of the first boot
  4. Review and feedback: test the build, read the docs, report what’s not working

How to contribute

  • Clone the repository and read the README and docs/BUILD.md, everything is explained to build the ISO locally
  • Test!
  • Reply to this topic if you want to take one of the above subjects, we’ll coordinate here so I can give you access to the repo!

The goal is to publish this very soon. Everything is already well advanced, we mainly need reviews, tests, and a bit of polish. If you have skills in Ubuntu, Autoinstall, Docker, GitHub Actions, Python, or simply a mini-PC to sacrifice for testing, your help is welcome!

A big thank you to Howmation for starting this project, and thanks in advance to everyone who wants to join in.

2

It might be a bit late to talk about this, but Emmabuntüs had made a USB key for reuse

3

Hi everyone!

I’m reviving this topic, would anyone be interested in taking it over? :slight_smile:

4

Hi.

The base seems very healthy (stable, secure, easy to install).

A question: package updates are automatic but no automatic reboot is planned (so they are never applied). Is this something we plan to do or do we leave the user to manage this reboot?

I made a comment on your PR (to add an admin user) and I opened a new PR for watchtower (open to debate).
I am testing an installation (including these two changes) this afternoon

5

Incredible, thanks @cicoub13 for taking over this project :slight_smile:

I’ve added permissions on this repo to @bertrandda and you

You can move forward without me, and even release a first version of this image whenever you want :wink:

6

Thanks. I couldn’t test because the ISO image build is only possible on Linux.
The idea is to build an ISO and make it available or let people build it themselves?

7

The idea is to simplify the installation as much as possible for people, a bit like what HA does with HAOS. We want the installation step to be reduced to the bare minimum!

So I think we should distribute an ISO, right?

8

Okay, I’ll take over then. I’ll have a few questions and mainly need help hosting the ISO (we’ll see if we can put it on GitHub).

9

Ok, don’t hesitate to ask questions!

To host the ISO, if it works on GitHub that’s better, otherwise I can open a space on Cloudflare R2 to host the ISO, just like we do for the integration store!

10

Hi @pierre-gilles,

As promised, here are my questions before releasing the first version.

1. Administrator Access (your PR #1)

I left a comment on your PR. The original idea remains the same: the user creates their own admin account during installation, OpenSSH is offered but disabled by default, and the ISO contains no accounts or passwords. For SSH, I leave the standard behavior of Ubuntu Server. If the user enables OpenSSH, they can log in with their password or import a key from GitHub or Launchpad. Enforcing a key seems too restrictive for the target audience.

I still have a choice to validate with you: the machine name is still gladys. The installation screen asks for a server name, but we overwrite it to keep a fixed name. Does that work for you, or would you prefer to let the user choose?

2. ISO Hosting

The build and publication can run entirely in GitHub Actions. This is already planned in the release workflow: build, QEMU tests, checksum, and provenance attestation. The problem is that GitHub limits each file in a release to 2 GB, and our ISO is larger. Therefore, it would need to be published in several parts (.part1, .part2) that the user must combine before flashing: cat under Linux or macOS, copy /b under Windows. balenaEtcher cannot flash the parts directly.

For a project whose goal is to simplify installation as much as possible, this step seems excessive. Therefore, I would lean towards your proposal Cloudflare R2:

  • The full ISO would be on R2 with a direct download link, for example download.gladysassistant.com/....
  • The GitHub release would keep the checksum, build-info.json, and the attestation for verification.
  • The release workflow would automatically send the ISO to R2 with each tag.

For this, I would need a bucket, a public domain, and an API token limited to writing to that bucket, which you would add as a secret to the GitHub repo. What do you think?

3. Reboot After Security Updates

I’m asking my question from above again. Security updates are installed automatically, but no reboot is scheduled, so kernel updates are never applied. Do we plan an automatic nightly reboot (for example at 4 a.m., only if necessary), or do we leave it to the user?

4. Watchtower: Deviation from the Official Installation Documentation

In PR #4, Watchtower is pinned to a specific version and limited to the Gladys container only. Since Gladys already manages updates for its containers (zigbee2mqtt, etc.), this seems more consistent: Watchtower no longer updates containers behind Gladys’s back. But this deviates from the official docker-compose documentation, which launches nickfedor/watchtower without a specific version and on all containers. Does this deviation work for the image? Should the official documentation also evolve in the same way?

Thanks!