Aufruf an Mitwirkende: Ubuntu-Server-Image mit vorinstalliertem Gladys (Projekt gestartet von Howmation)

Entwicklung
1

Hallo zusammen,

Ich schreibe euch, um um Hilfe für ein Projekt zu bitten, das mir wirklich am Herzen liegt und das viel für neue Gladys-Nutzer ändern könnte.

Die Idee

Heute erfordert die Installation von Gladys auf einem Mini-PC die Installation von Ubuntu, dann Docker und dann Gladys. Das ist zugänglich, aber es bleibt eine Hürde für viele. Das Ziel dieses Projekts ist es, ein bootfähiges ISO-Image anzubieten, das Ubuntu Server mit vorkonfiguriertem Gladys installiert: Man flashte einen USB-Stick, bootet den Mini-PC, wählt die Festplatte aus, verbindet das Ethernet und am Ende öffnet man http://gladysassistant.local und Gladys ist da. Eine echte «Gladys-Box», die man selbst herstellt.

Wer steckt dahinter

Das ist Howmation, der dieses Projekt gestartet hat, und ich finde, das ist eine super Idee. Er hat bereits eine enorme Arbeit geleistet, und das Repository ist öffentlich hier: https://github.com/GladysAssistant/ubuntu-server-gladys

Wo wir stehen

Der Kern des Systems ist fertig. Konkret gibt es im Repository bereits:

  • Einen Installer basierend auf Ubuntu Server LTS amd64, remastered mit Subiquity Autoinstall (Basis-Image authentifiziert gegen Canonical-Signaturen bei jedem Build)
  • Ein automatisches erstes Boot, das Docker installiert, das Image gladysassistant/gladys:v5 abruft und Gladys mit Watchtower für Updates startet
  • Eine tty1-Konsole und eine Webseite für die Einrichtung, um den Fortschritt zu verfolgen, mit dem neuen Design bereits portiert (noch zu verfeinern)
  • Ein standardmäßig gehärtetes System: kein SSH, kein Standardkonto, root gesperrt, automatische Sicherheitsupdates
  • Python-Einheitstests, QEMU-Integrationstests (UEFI-Installation, erstes Boot, Netzwerkausfall, Stromausfall)
  • GitHub Actions-Workflows für CI, wöchentliche Tests und Release-Veröffentlichung
  • Eine vollständige Dokumentation: Architektur, Build, Betrieb, Release, Sicherheit, Hardware-Checkliste

Was noch zu tun ist

Howmation sagte mir, dass der Kern da ist, aber dass die CI/CD noch sauberer und robuster gemacht werden muss und das Design fertiggestellt werden muss. Er ist im Moment sehr beschäftigt mit anderen Entwicklungen, daher braucht das Projekt Hände, um voranzukommen. Hier sind die großen Themen, bei denen wir Hilfe benötigen:

  1. CI/CD: Build-, QEMU-Test- und Release-Pipelines zuverlässiger und einfacher machen
  2. Tests auf echtem Hardware: Die Hardware-Checkliste des Repositories (docs/HARDWARE-TEST-CHECKLIST.md) muss auf echten Mini-PCs validiert werden (Intel N100/N150, Core, AMD Ryzen, NVMe, SATA, Secure Boot aktiviert oder nicht). Wenn ihr einen Mini-PC zur Hand habt, ist das eine wertvolle Beitrag, auch ohne eine Zeile Code zu schreiben
  3. Design der Setup-Seite: Die Weboberfläche des ersten Boots abschließen
  4. Korrekturlesen und Feedback: Build testen, Dokumentation lesen, melden, was nicht funktioniert

Wie kann man beitragen

  • Repository klonen und README und docs/BUILD.md lesen, alles ist erklärt, um das ISO lokal zu bauen
  • Testen!
  • Auf dieses Thema antworten, wenn ihr eines der oben genannten Themen übernehmen wollt, wir werden uns hier koordinieren, damit ich euch die Rechte auf dem Repository gebe!

Das Ziel ist es, das sehr bald zu veröffentlichen. Alles ist bereits gut vorangekommen, es fehlt vor allem Korrekturlesen, Tests und ein bisschen Polish. Wenn ihr Kenntnisse in Ubuntu, Autoinstall, Docker, GitHub Actions, Python oder einfach nur einen Mini-PC zum Testen opfern wollt, ist eure Hilfe willkommen!

Ein großes Dankeschön an Howmation für den Start dieses Projekts und im Voraus an alle, die sich daran beteiligen möchten.

2

Vielleicht ist es ein bisschen spät, darüber zu sprechen, aber Emmabuntüs hatte einen USB-Stick zum Wiederverwenden erstellt

3

Hallo zusammen!

Ich möchte dieses Thema gerne wieder aufgreifen. Wäre jemand daran interessiert, es weiterzuführen? :slight_smile:

4

Hallo.

Die Basis scheint mir sehr solide (stabil, sicher, einfach zu installieren).

Eine Frage: Die Paket-Updates sind automatisch, aber es ist kein automatischer Neustart vorgesehen (daher werden sie nie angewendet). Plant ihr das oder überlässt ihr den Neustart dem Benutzer?

Ich habe einen Kommentar zu deinem PR (für die Hinzufügung eines Admin-Benutzers) gemacht und einen neuen PR für watchtower eröffnet (offen für Diskussionen).
Ich teste heute Nachmittag eine Installation (inklusive dieser beiden Änderungen)

5

Unglaublich, danke @cicoub13, dass du dich um dieses Projekt kümmerst :slight_smile:

Ich habe @bertrandda und dir die Rechte für dieses Repo gegeben

Ihr könnt ohne mich weitermachen, und sogar eine erste Version dieses Bildes veröffentlichen, wann immer ihr wollt :wink:

6

Danke. Ich konnte es nicht testen, da der Build der ISO-Image nur unter Linux möglich ist.
Die Idee ist, eine ISO zu builden und sie zur Verfügung zu stellen oder die Leute selbst builden zu lassen?

7

Die Idee ist, die Installation für die Leute so weit wie möglich zu vereinfachen, ein bisschen so, wie HA es mit HAOS macht. Wir wollen, dass der Installationsschritt auf das absolut Notwendige reduziert wird!

Sollten wir also eine ISO-Datei verteilen, oder?

8

Okay, ich übernehme dann mal wieder. Ich habe ein paar Fragen und vor allem brauche ich Hilfe beim Hosting der ISO (mal sehen, ob wir sie auf GitHub stellen können).

9

Okay, zögere nicht, Fragen zu stellen!

Wenn es auf GitHub funktioniert, ist das besser. Andernfalls kann ich einen Speicherplatz auf Cloudflare R2 für die ISO einrichten, so wie wir es für den Integrations-Store machen!

10

Hallo @pierre-gilles,

Wie versprochen, hier sind meine Fragen, bevor ich eine erste Version veröffentliche.

1. Administratorzugriff (dein PR #1)

Ich habe einen Kommentar zu deinem PR hinterlassen. Die ursprüngliche Idee bleibt gleich: Der Benutzer erstellt sein eigenes Admin-Konto während der Installation, OpenSSH wird angeboten, aber standardmäßig deaktiviert, und das ISO-Image enthält kein Konto oder Passwort. Bei SSH lasse ich das Standardverhalten von Ubuntu Server. Wenn der Benutzer OpenSSH aktiviert, kann er sich mit seinem Passwort anmelden oder einen Schlüssel von GitHub oder Launchpad importieren. Ein erzwungener Schlüssel scheint mir für die Zielgruppe zu restriktiv.

Ich habe noch eine Entscheidung mit dir zu klären: Der Name der Maschine ist immer noch gladys. Der Installationsbildschirm fragt nach einem Servernamen, aber wir überschreiben ihn, um einen festen Namen beizubehalten. Ist das in Ordnung für dich, oder möchtest du dem Benutzer die Wahl lassen?

2. Hosting des ISO-Images

Der Build und die Veröffentlichung können vollständig in GitHub Actions laufen. Das ist bereits im Release-Workflow vorgesehen: Build, QEMU-Tests, Prüfsumme und Herkunftsnachweis. Das Problem ist, dass GitHub jede Datei eines Releases auf 2 GB begrenzt und unser ISO-Image größer ist. Es müsste also in mehrere Teile aufgeteilt und veröffentlicht werden (.part1, .part2), die der Benutzer vor dem Flashen zusammenfügen muss: cat unter Linux oder macOS, copy /b unter Windows. balenaEtcher kann die Teile nicht direkt flashen.

Für ein Projekt, dessen Ziel es ist, die Installation so einfach wie möglich zu gestalten, erscheint mir dieser Schritt überflüssig. Ich würde daher zu deinem Vorschlag Cloudflare R2 tendieren:

  • Das vollständige ISO-Image wäre auf R2 mit einem direkten Download-Link, z. B. download.gladysassistant.com/....
  • Die GitHub-Release würde die Prüfsumme, build-info.json und den Herkunftsnachweis für die Überprüfung behalten.
  • Der Release-Workflow würde das ISO-Image automatisch an R2 bei jedem Tag senden.

Dafür bräuchte ich einen Bucket, eine öffentliche Domain und ein API-Token, das auf das Schreiben in diesen Bucket beschränkt ist, das du als Geheimnis im GitHub-Repo hinzufügen könntest. Was hältst du davon?

3. Neustart nach Sicherheitsupdates

Ich wiederhole meine Frage von oben. Sicherheitsupdates werden automatisch installiert, aber kein Neustart ist vorgesehen, daher werden Kernel-Updates nie angewendet. Planen wir einen automatischen Neustart in der Nacht (z. B. um 4 Uhr, nur wenn nötig), oder überlassen wir das dem Benutzer?

4. Watchtower: Abweichung von der offiziellen Installationsdokumentation

In PR #4 ist Watchtower auf eine bestimmte Version festgelegt und auf den Gladys-Container beschränkt. Da Gladys bereits selbst die Updates seiner Container (zigbee2mqtt, etc.) verwaltet, erscheint mir das konsistenter: Watchtower aktualisiert keine Container mehr hinter Gladys’ Rücken. Aber das weicht von der offiziellen docker-compose-Dokumentation ab, die nickfedor/watchtower ohne feste Version und für alle Container startet. Ist diese Abweichung für das Image in Ordnung? Sollte die offizielle Dokumentation auch in die gleiche Richtung weiterentwickelt werden?

Danke!

11

Ich würde vorschlagen, es standardmäßig zu aktivieren

Sehr gut!

Ich füge das hinzu! Allerdings muss man darauf achten, das Bild nur auf einem festen Pfad zu pushen, denn sonst sammeln sich Dateien auf dem R2 an, und ich zahle pro GB, das wird schnell teuer :grin:

Ich bin nicht für einen automatischen Neustart. Gladys steuert das Haus und läuft oft ohne Bildschirm oder jemanden, der überwacht: Wenn ein nächtlicher Neustart nicht neu startet (Kernel, Festplatte, USB-Dongle), bleibt die Box außer Betrieb, ohne dass der Benutzer es weiß. Ein Neustart sollte durchgeführt werden, wenn der Benutzer da ist, um zu überprüfen, dass alles wieder läuft.

Andererseits könnte man das auf der Anwendungsebene verwalten: Gladys kann /var/run/reboot-required erkennen und ein Banner mit einem Button „Jetzt neu starten“ anzeigen :slight_smile:

Ja, das ist für mich in Ordnung, um auf den Gladys-Container + Watchtower zu beschränken, der sich meiner Meinung nach selbst aktualisieren sollte. Der einzige Punkt, bei dem ich skeptisch bin, ist, die Version von Watchtower festzulegen, denn wie wir in der Vergangenheit gesehen haben, entwickelt sich die Docker-API manchmal weiter, und eine ältere Version von Watchtower könnte nicht mehr funktionieren. Man sollte lieber die neueste Version verwenden?

12

@cicoub13 Alles klar, ich habe die Anmeldedaten im GitHub-Secret hinterlegt:

R2_STORAGE_TOKEN

Dieses Token hat Lese- und Schreibrechte für einen R2-Bucket gladys-assistant-os-images, der unter folgender Domain verfügbar ist:

download.gladysassistant.com

Für die Speicherung der Bilder denke ich, dass wir zwei feste Pfade haben können:

  • Eine Datei für das Produktionsimage
  • Eine Datei für „Test“-Builds

Jeder Push überschreibt das vorherige Image, so vermeiden wir, dass unnötige Gigabyte an Dateien gespeichert werden.

Zögere nicht, wenn du noch etwas anderes brauchst :slight_smile:

13

Vielen Dank @pierre-gilles für die Entscheidungen und den Bucket! Hier ist, was integriert wurde:

  • Konto und SSH: Der Installer fordert zur Erstellung eines Administrator-Kontos auf, und OpenSSH ist standardmäßig aktiviert. Wie bei einem Standard-Ubuntu-Server verbindet man sich mit dem Passwort oder mit importierten Schlüsseln von GitHub/Launchpad. Die ISO enthält weiterhin keine Identifikatoren.

  • Hostname: Die Maschine heißt immer gladys, unabhängig vom im Installer eingegebenen Namen. Man verbindet sich mit ssh <benutzer>@gladys.local.

  • Watchtower: Er aktualisiert nur Gladys und sich selbst und bleibt auf latest. Container, die von Integrationen erstellt wurden, werden nicht mehr aktualisiert. Die Container-Logs sind auf 10 MB × 3 Dateien begrenzt.

  • Neustart: Nichts automatisch. Die Dokumentation erklärt, dass /var/run/reboot-required anzeigt, dass ein Neustart erforderlich ist, und dass man ihn mit sudo reboot startet. Ich habe ein Issue für die Schaltfläche „Jetzt neu starten“ eröffnet: Show a "Restart now" banner when the host needs a reboot · Issue #3267 · GladysAssistant/Gladys · GitHub

  • Download: Die ISO wird auf R2 unter zwei festen Pfaden veröffentlicht, die bei jeder Veröffentlichung überschrieben werden:

    • stabil: https://download.gladysassistant.com/gladys-assistant-installer-amd64.iso
    • test: https://download.gladysassistant.com/test/gladys-assistant-installer-amd64.iso

    Ein Tag vX.Y.Z-rc.N veröffentlicht die Test-ISO. Ein Tag vX.Y.Z veröffentlicht die stabile ISO mit der GitHub-Release.

Eine Anforderung für R2: Die ISO ist größer als 2 GB. Wrangler ist auf etwa 300 MB begrenzt, daher erfolgt der Upload über die S3-API von R2 (multipart upload). Dafür benötige ich eine Information in GitHub zusätzlich zu R2_STORAGE_TOKEN:

  • R2_ACCOUNT_ID: Die Cloudflare-Konto-ID, die zur Konstruktion des Endpunkts https://<id>.r2.cloudflarestorage.com dient;

Nächster Schritt: Eine v0.1.0-rc.1 zum Testen auf echtem Hardware. Freiwillige, die einen Mini-PC zur Hand haben, sind herzlich willkommen!

14

@cicoub13 … Testen, gerne, habe hier noch einen von diesen kleinen Rechner rumfahren. Ein Futro S920 mit 256 GB SSD und 8 GB RAM und der braucht so oder so was Neues, warum nicht ein ISO von Euch.

Grüße

Tom

15

Alles klar, das ist im Repo verfügbar :white_check_mark:

16

Ein erstes Testbild ist hier verfügbar: https://download.gladysassistant.com/test/gladys-assistant-installer-amd64.iso

17

Getestet auf VM und es funktioniert :white_check_mark:

Bildschirmfoto 2026-10-26 um 11.50.29
Bildschirmfoto 2026-10-26 um 11.50.291133×648 61.6 KB

Bildschirmfoto 2026-10-26 um 14.07.43
Bildschirmfoto 2026-10-26 um 14.07.43447×395 3.79 KB

18

Toll das :heart_eyes:

19

Kleines Problem mit der nicht berücksichtigten Sprache, ich korrigiere das :france:

20

Ich habe es gerade auf einem Beelink S13 getestet, und ehrlich gesagt, großartige Arbeit bis jetzt, das ist Spitze! :raising_hands:

Hier sind meine Rückmeldungen, Schritt für Schritt:

1) Sprachauswahl

Französisch ist standardmäßig ausgewählt: ist das Absicht, oder wird das automatisch erkannt?

Wenn es Absicht ist, denke ich, es wäre besser, Englisch standardmäßig zu setzen. Man wirft uns oft genug vor, zu „französisch“ zu sein, man muss wirklich international first denken :smiley:

IMG_4329
IMG_43291920×1080 385 KB

2) Benutzerkonto erstellen

Es scheint, dass „gladys“ standardmäßig übernommen wird, egal was hier eingegeben wird. Könnten wir diese Felder vorbefüllen und sperren, um nur das Passwort auswählen zu lassen?

Ein weiterer Punkt: Der Ubuntu-Installer ist seit 26.04 mit AZERTY-Tastaturen kaputt. Selbst wenn man AZERTY im ersten Schritt auswählt, bleibt die Tastatur auf QWERTY. Die einzige Lösung, die ich gefunden habe, ist, die Shell (oben rechts) zu öffnen und dann loadkeys fr und exit einzugeben.

Es wäre gut, das zu beheben, wenn möglich. Ich weiß, dass es nicht unsere Schuld ist, aber wir haben viele französische Benutzer, die darauf stoßen werden :smiley:

IMG_4331
IMG_43311920×1080 408 KB

3) Festplattenauswahl

Ich weiß, dass dieser Schritt zum Prozess gehört, aber ich frage mich, inwieweit man ihn ausblenden oder vereinfachen könnte. So bleibt es für Anfänger sehr technisch.

IMG_4330
IMG_43301920×1080 375 KB

4) Nach dem Neustart

Hier ist es super gemacht: ultra einfach, mit einer sehr klaren Nachricht, und es geht viel schneller als mit einem klassischen Ubuntu. Großartig!! :partying_face:

5) SSH-Verbindung

Einige Anmerkungen nach der SSH-Verbindung:

  • Speicherplatz: Die Festplatte nutzt nicht den gesamten verfügbaren Speicherplatz. Ich sehe 100 GB zugewiesen, obwohl mein Beelink 500 GB hat.
  • Docker: sudo docker ps fragt nach meinem Passwort. Das könnte man vereinfachen (über die sudoers, zum Beispiel).

Falls es als Inspiration dienen kann, hier ist das Skript, das ich zum Installieren der Boot-Kits verwende: Install Gladys mini-PC · GitHub

Allgemeinere Rückmeldungen

Designmäßig bleibt der Installer sehr nah an Ubuntu Server. Könnten wir ihn mehr an die Farben von Gladys anpassen, mit passenderen Nachrichten? Wenn es nicht möglich ist, kein Problem :wink:

Nochmals großartige Arbeit, es kommt wirklich gut voran! :rocket: