Appel à contributeurs : image Ubuntu Server avec Gladys pré-installé (projet lancé par Howmation)

Développement
1

Salut à tous,

Je vous écris pour demander un coup de main sur un projet qui me tient vraiment à cœur, et qui pourrait changer beaucoup de choses pour les nouveaux utilisateurs de Gladys.

L’idée

Aujourd’hui, installer Gladys sur un mini-PC demande de passer par une installation d’Ubuntu, puis Docker, puis Gladys. C’est accessible, mais ça reste une barrière pour beaucoup de monde. L’objectif de ce projet, c’est de proposer une image ISO bootable qui installe Ubuntu Server avec Gladys pré-configuré : on flashe une clé USB, on boote le mini-PC, on choisit le disque, on branche l’Ethernet, et à la fin on ouvre http://gladysassistant.local et Gladys est là. Une vraie « box Gladys » qu’on fabrique soi-même.

Qui est derrière

C’est Howmation qui a lancé ce chantier, et franchement je trouve que c’est une super idée. Il a déjà fait un travail énorme, et le dépôt est public ici : GitHub - GladysAssistant/ubuntu-server-gladys: WIP : Building a simpler OS to install Gladys Assistant · GitHub

Où on en est

Le cœur du système est fait. Concrètement, dans le dépôt il y a déjà :

  • Un installeur basé sur Ubuntu Server LTS amd64, remasterisé avec Subiquity Autoinstall (image de base authentifiée contre les signatures Canonical à chaque build)
  • Un premier démarrage automatisé qui installe Docker, récupère l’image gladysassistant/gladys:v5 et lance Gladys avec Watchtower pour les mises à jour
  • Une console tty1 et une page web de setup pour suivre la progression, avec le nouveau design déjà porté (encore à peaufiner)
  • Un système durci par défaut : pas de SSH, pas de compte par défaut, root verrouillé, mises à jour de sécurité automatiques
  • Des tests unitaires Python, des tests d’intégration QEMU (installation UEFI, premier boot, coupure réseau, coupure de courant)
  • Des workflows GitHub Actions pour la CI, les tests hebdomadaires et la publication de release
  • Une documentation complète : architecture, build, opérations, release, sécurité, checklist matériel

Ce qu’il reste à faire

Howmation m’avait dit que le cœur était là, mais qu’il fallait encore rendre la CI/CD plus propre et plus robuste, et finir d’améliorer le design. Il est très pris en ce moment avec d’autres développements, donc le projet a besoin de bras pour avancer. Voici les gros sujets sur lesquels on a besoin d’aide :

  1. CI/CD : fiabiliser et simplifier les pipelines de build, de test QEMU et de release
  2. Tests sur vrai matériel : la checklist matériel du dépôt (docs/HARDWARE-TEST-CHECKLIST.md) doit être validée sur de vrais mini-PC (Intel N100/N150, Core, AMD Ryzen, NVMe, SATA, Secure Boot activé ou non). Si vous avez un mini-PC sous la main, c’est une contribution précieuse même sans écrire une ligne de code
  3. Design de la page de setup : finir de peaufiner l’interface web du premier démarrage
  4. Relecture et retours : tester le build, lire la doc, signaler ce qui coince

Comment contribuer

  • Cloner le dépôt et lire le README et docs/BUILD.md, tout est expliqué pour construire l’ISO localement
  • Tester !
  • Répondre à ce sujet si vous voulez prendre un des sujets ci-dessus, on se coordonnera ici pour que je vous donnes les droits sur le repo !

L’objectif, c’est de publier ça très vite. Tout est déjà bien avancé, il manque surtout de la relecture, des tests et un peu de polish. Si vous avez des compétences en Ubuntu, Autoinstall, Docker, GitHub Actions, Python ou tout simplement un mini-PC à sacrifier pour des tests, votre aide est la bienvenue !

Un grand merci à Howmation pour avoir lancé ce projet, et merci d’avance à tous ceux qui voudront s’y joindre.

2

C’est peut-être un peu tard pour en parler mais emmabuntus avait fait une clé USB de réemploi
Utilisation des clés USB de réemploi Emmabuntüs – Emmabuntüs](Utilisation des clés USB de réemploi Emmabuntüs – Emmabuntüs)

3

Salut à tous !

Je me permets de relancer ce sujet, est-ce que quelqu’un serait intéressé par le reprendre ? :slight_smile:

4

Bonjour.

La base me paraît très saine (stable, sécurisée, facile à installer).

Une question : les updates de paquets sont automatiques mais aucun reboot n’est prévu de manière automatique (donc ils ne sont jamais appliqués). Est-ce qu’on prévoit ça ou on laisse l’utilisateur gérer ce reboot ?

J’ai fait un commentaire sur ta PR (pour ajouter un user admin) et j’ai ouvert une nouvelle PR pour watchtower (ouvert au débat).
Je teste une installation (comprenant ces deux changements) cette après-midi

5

Incroyable merci @cicoub13 d’avoir repris ce chantier :slight_smile:

J’ai ajouté les droits sur ce repo à @bertrandda et toi

Vous pouvez avancer sans moi, et même sortir une première version de cette image quand vous voulez :wink:

6

Merci. Je n’ai pas pu tester car le build de l’image iso est possible uniquement sur Linux.
L’idée est de build une iso et de la mettre à disposition ou de laisser les gens la build ?

7

L’idée c’est de simplifier au maximum l’installation pour les gens, un peu comme ce que fait HA avec HAOS, on veut que l’étape d’installation soit réduite au stricte nécessaire !

Donc je pense qu’il faut distribuer un iso non ?

8

Ok, je reprends la main alors. J’aurai quelques questions et surtout besoin d’aide pour héberger l’iso (à voir si on peut la mettre sur GitHub)

9

Ok, n’hésite pas pour les questions!

Pour héberger l’iso, si ça passe sur Github c’est mieux, sinon je peux ouvrir un espace sur Cloudflare R2 pour héberger l’iso, comme on fait pour le store d’intégration!

10

Salut @pierre-gilles,

Comme promis, voici mes questions avant de sortir une première version.

1. Accès administrateur (ta PR #1)

J’ai laissé un commentaire sur ta PR. L’idée de départ ne change pas : l’utilisateur crée son propre compte admin à l’installation, OpenSSH est proposé mais désactivé par défaut, et l’ISO ne contient aucun compte ni mot de passe. Pour SSH, je laisse le comportement standard d’Ubuntu Server. Si l’utilisateur active OpenSSH, il peut se connecter avec son mot de passe, ou importer une clé depuis GitHub ou Launchpad. Imposer une clé me semble trop contraignant pour le public visé.

Il me reste un choix à valider avec toi : le nom de la machine est toujours gladys. L’écran d’installation demande un nom de serveur, mais on l’écrase pour garder un nom fixe. Ça te va, ou tu préfères laisser l’utilisateur le choisir ?

2. Hébergement de l’ISO

Le build et la publication peuvent tourner entièrement dans GitHub Actions. C’est déjà prévu dans le workflow de release : build, tests QEMU, checksum et attestation de provenance. Le problème, c’est que GitHub limite chaque fichier d’une release à 2 Go, et notre ISO est plus grosse. Il faudrait donc la publier découpée en plusieurs morceaux (.part1, .part2) que l’utilisateur doit recoller avant de flasher : cat sous Linux ou macOS, copy /b sous Windows. balenaEtcher ne sait pas flasher les morceaux directement.

Pour un projet dont le but est de simplifier l’installation au maximum, cette étape me semble de trop. Je pencherais donc pour ta proposition Cloudflare R2 :

  • L’ISO complète serait sur R2 avec un lien de téléchargement direct, par exemple download.gladysassistant.com/....
  • La release GitHub garderait le checksum, build-info.json et l’attestation, pour la vérification.
  • Le workflow de release enverrait l’ISO sur R2 automatiquement à chaque tag.

Pour ça, il me faudrait un bucket, un domaine public, et un token API limité en écriture à ce bucket, que tu ajouterais comme secret sur le repo GitHub. Qu’est-ce que tu en penses ?

3. Redémarrage après les mises à jour de sécurité

Je relance ma question d’au-dessus. Les mises à jour de sécurité s’installent automatiquement, mais aucun redémarrage n’est prévu, donc les mises à jour du noyau ne s’appliquent jamais. Est-ce qu’on prévoit un redémarrage automatique la nuit (par exemple à 4h, seulement si c’est nécessaire), ou on laisse l’utilisateur s’en charger ?

4. Watchtower : écart avec la doc d’installation officielle

Dans la PR #4, Watchtower est figé sur une version précise et limité au seul conteneur Gladys. Comme Gladys gère déjà elle-même les mises à jour de ses conteneurs (zigbee2mqtt, etc.), ça me paraît plus cohérent : Watchtower ne met plus à jour des conteneurs dans le dos de Gladys. Mais ça s’écarte de la doc docker-compose officielle, qui lance nickfedor/watchtower sans version précise et sur tous les conteneurs. Est-ce que cet écart te convient pour l’image ? Est-ce qu’il faudrait aussi faire évoluer la doc officielle dans le même sens ?

Merci !