Appliances Ubuntu : comment faire d'une bonne idée une aberration

The Canonical way
Systèmes 7 min
Appliances Ubuntu : comment faire d'une bonne idée une aberration

Il y a quelques mois, Canonical déclarait sa flamme au Raspberry Pi. On y apprenait qu'Ubuntu serait adapté aux machines de la fondation, actuelles ou à venir. Une offre à destination des entreprises était esquissée, tout comme l'arrivée d'appliances. Elles sont disponibles... basées sur Ubuntu Core.

S'amuser avec un Raspberry Pi c'est bien, en faire la plateforme de projets concrets c'est mieux. C'était en substance le discours tenu par Canonical au début de l'année. La société expliquait alors avoir de grands projets pour ces Single Board Computers (SBC), dont celui de proposer des appliances clé en main.

Appliances pour Raspberry Pi : une bonne idée, peu suivie

Comprendre : des couches applicatives installées par-dessus Ubuntu et prêtes à l'emploi. La promesse était de permettre la conception de solutions sécurisées, se mettant à jour automatiquement et n'ayant qu'un but précis. Parées pour une distribution à grande échelle en somme.

Le mois dernier, une première liste était annoncée. Nous avions alors misé sur son évolution rapide. Raté, elle n'a pas bougé d'un iota : seuls AdGuard, Mosquitto, Nextcloud, OpenHAB ou Plex Media Server sont disponibles. C'est un bon début, assez diversifié, mais un peu juste.

Ubuntu Appliances

Chacun devrait néanmoins trouver un projet qui l'intéresse dans ces exemples, qui vont du service MQTT à la solution de stockage et de gestion de documents, en passant par la domotique, le multimédia ou le respect de la vie privée. Nous comprenions donc mal ce caractère confidentiel.

Canonical avait pourtant poussé à la création d'appliances, via une procédure simple et communautaire : techniquement, n'importe quelle application peut être transformée en appliance, le dispositif se basant sur Ubuntu Core et ses Snaps. La publication passe par Snapcraft. Chacun peut proposer ses idées, mais sur le Discourse prévu à cet effet, les suggestions ne se bousculent pas.

Surtout, rares sont ceux à avoir évoqué l'arrivée des appliances. Et lorsqu'ils l'ont fait, ils n'ont manifestement pas testé la procédure. Nous avons donc sauté le pas pour comprendre ce qui coince.

Les appliances ne sont pas spécifiques aux Raspberry Pi

Il faut tout d'abord noter une chose, qui n'était pas clairement dite lorsque Canonical a évoqué ses appliances dans son billet consacré au Raspberry Pi : elles peuvent être utilisées avec d'autres systèmes. Canonical évoque deux autre cas, les NUC d'Intel et Multipass.

Chaque appliance a droit à une page dédiée. On y voit les systèmes et architectures où elle peut être installée, la conformité avec les lois relatives à la vie privée (comme le RGPD en Europe), l'image de base utilisée, la date de publication, les snaps utilisés, etc. Une série de liens renvoie vers les pages d'instructions pour l'installation.

Elles sont détaillées pour trois systèmes : macOS, Ubuntu et Windows. C'est aussi sur cette page que l'on récupère les images, dans un format compresse (.xz). Celle des Raspberry Pi 2 (qui n'est pas toujours très bien mise en avant) est différentes des Pi 3 et 4 (qui sont, eux, 64 bits). Dans le cas des NUC, il s'agit d'une image x86-64.

La procédure la plus simple passe par le gestionnaire de machines virtuelles maison Multipass. Y lancer une appliance ne nécessite que trois lignes de commandes. Par exemple pour Adguard :

sudo snap install multipass
multipass launch appliance:adguard-home
multipass shell adguard-home

Et pour accéder au shell : 

multipass shell adguard-home

Une fois la procédure terminée, l'application est utilisable. On aurait tout de même apprécié d'avoir une image prête à être utilisée avec n'importe quel hyperviseur. 

La douloureuse question de la connexion distante

Dans le cas des NUC/RPi, ça se complique. Pour une raison simple : il s'agit de machines classiques, et une ligne de commande générique ne suffit pas pour s'y connecter via SSH. Il faut disposer d'un couple identifiant/mot de passe ou d'une paire de clés de chiffrement reconnue.

Dès l'annonce des appliances, nous attendions Canonical sur ce point. Car nous l'avions vu lors de nos essais de distributions sur Raspberry Pi, Ubuntu n'a pas toujours été la championne des installations headless, gérée à distance. Elle est plutôt habituée à un long processus de questions/réponses.

Heureusement sur les versions récentes, des efforts ont été faits, sans pour autant en arriver au point de Manjaro qui a intégré un onboarding OEM. Sur la procédure d'installation classique, un couple identifiant/mot de passe est activé par défaut, à modifier ensuite. Cela allait-il évoluer avec l'arrivée des appliances ?

Eh bien oui. Mais nous ne nous attendions pas à un choix si aberrant.

Compte Ubuntu obligatoire, une installation complexe

Pour une raison simple : l'utilisateur doit disposer d'un compte Ubuntu et y avoir déclaré la clé publique d'une paire de clé de connexion via OpenSSH (hors Ed25519, non géré) :

Compte Ubuntu

Pourquoi ? Parce que lorsque l'appliance sera installée, elle ira récupérer cette clé publique sur les serveurs de Canonical pour l'ajouter à la liste de celles reconnues par le système. Une connexion internet sera ainsi obligatoire. Pour se connecter, l'utilisateur devra utiliser le pseudo de son compte Ubuntu et sa clé privée :

ssh <Ubuntu SSO user name>@<device IP address>

Pourquoi ne pas permettre d'intégrer directement la clé privée dans l'image, de proposer un outil pour l'intégrer lors du transfert de l'image ou n'importe quel autre dispositif qui ne nécessiterait pas de connexion internet, et de lier l'appliance à un compte Ubuntu ?

Pourquoi faire simple quand on peut faire compliqué ? Tout simplement parce que c'est la manière de faire d'Ubuntu Core depuis quelques années. Si l'on comprend l'intérêt d'une telle méthode pour des développeurs qui doivent de toutes façons passer par des services Ubuntu à un moment donné (pour publier leurs snaps), elle ne devrait pas être la seule proposée. Encore moins lorsqu'il s'agit d'utiliser une machine au sein du réseau local. 

Une solution trop complexe à tous les niveaux

Ce surcroit de complications se retrouve ailleurs. Car contrairement à la solution exploitant Multipass, l'initialisation d'une appliance est tout sauf aisée. Ce, dès le transfert de l'image.

Aisé pour Raspberry Pi (via l'outil officiel Imager), c'est une autre paire de manche pour PC. Car Imager ne permet pas le transfert sur un HDD/SSD interne, uniquement une carte microSD ou clé USB. L'équipe préconise donc d'utiliser une clé USB Ubuntu Desktop Live. Elle permettra d'accéder à un système avec un terminal où l'on pourra transférer sur le HDD/SSD l'image de l'appliance via les outils xzcat et dd vers le HDD/SSD...

En réalité, il est plus simple d'utiliser un adaptateur USB ou une version récente de balenaEtcher qui permet l'écriture d'images vers un périphérique de stockage interne.

  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation
  • Ubuntu Appliance Initialisation

Mais cette complexité est habituelle, non spécifique aux appliances Ubuntu. C'est ensuite que l'on découvre qu'il faut que la machine soit reliée à un clavier, un écran et une connexion internet pour valider sa configuration initiale : la connexion réseau, l'identifiant du compte Ubuntu permettant de récupérer les clés publiques qui serviront ensuite à la connexion distante. Là aussi, du fait d'Ubuntu Core. On aurait préféré une procédure headless native.

On comprend mieux le désamour pour cette fonctionnalité. Elle est donc plutôt à fuir en l'état, sauf si vous utilisez Multipass auquel cas elle est assez simple à prendre en main. Sinon, il est sans doute préférable d'installer Ubuntu Server et d'y configurer le ou les Snap dont vous avez besoin. 

  • Introduction
  • Appliances pour Raspberry Pi : une bonne idée, peu suivie
  • Les appliances ne sont pas spécifiques aux Raspberry Pi
  • La douloureuse question de la connexion distante
  • Compte Ubuntu obligatoire, une installation complexe
  • Une solution trop complexe à tous les niveaux
S'abonner à partir de 3,75 €
9 commentaires
Avatar de eres Abonné
Avatar de ereseres- 23/07/20 à 15:18:08
#1

Coté appliance, mon amour va pour les solutions Bitnami, mais effectivement ils se sont progressivement éloignés des solutions trop ouvertes (linux, windows, macos X) pour se recentrer sur les VMs (puis être racheté peut être pas pour le meilleur par VMWare).
C'est super difficile de créer des solutions modulaires, sécurisées et multi cibles même en se centrant sous Linux.
J'avais financé une petite équipe pour tester cette possibilité en... 2003, sous Debian. Mais on avait vite abandonné car trop compliqué, et fini par basculer sur un socle VPS Vz.
Cela ne s'est pas simplifié avec les années... et mes cheveux blancs.

Édité par eres le 23/07/2020 à 15:18
Avatar de David_L Équipe
Avatar de David_LDavid_L- 23/07/20 à 15:26:42
#2

undefined

Disons que si encore Canonical faisait de la dépendance à un SSO pour effectuer un déploiement de l'appliance à distance, genre : je boote sur une image minimale, je m'y connecte en SSH, je donne les paramètres du compte Ubuntu et pouf ça déploie... je ne dis pas. Mais bon, là on ajoute le besoin d'une connexion web et d'un clavier/souris juste pour récupérer une clé publique.

Le tout sans résoudre le gros du problème : le déploiement de l'image (qui reste simple sur RPi mais pas sur une machine avec HDD/SSD, même si ce serait sans doute facile à proposer de manière automatisée avec une clé USB prévue pour ça).

Avatar de Dandu Abonné
Avatar de DanduDandu- 23/07/20 à 17:24:35
#3

C'est marrant qu'ils proposent pas de version 64 bits pour les Raspberry Pi 2. Parce que ça fait un moment que la fondation vend une version 64 bits (le 1.2) qui est dans les faits un Pi 2 (pas de Wi-Fi, etc.) mais avec un SoC de Pi 3 ralentit.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 23/07/20 à 18:19:29
#4

undefined

Ça évite d’avoir à expliquer 😬 Par contre l’image RPi 3/4 doit fonctionner dessus non ?

Avatar de HollyFredD Abonné
Avatar de HollyFredDHollyFredD- 24/07/20 à 07:29:54
#5

Petite coquille : "MQQT" vs "MQTT"

Avatar de David_L Équipe
Avatar de David_LDavid_L- 24/07/20 à 08:02:45
#6

undefined

Il y a un bouton pour signaler les erreurs ;)) (mais c'est corrigé)

Avatar de HollyFredD Abonné
Avatar de HollyFredDHollyFredD- 24/07/20 à 11:21:56
#7

Vu! Je le saurai pour la prochaine fois en effet.

Avatar de Dandu Abonné
Avatar de DanduDandu- 27/07/20 à 07:47:28
#8

undefined

Faudrait que j'essaye. Je ne sais pas si la gestion du Wi-Fi/Bluetooth (absente) peut pas poser des soucis.

Avatar de seb128 Abonné
Avatar de seb128seb128- 27/07/20 à 10:22:29
#9

undefined

Une raison simple, lorsque ce système existe on se retrouve avec des fabricants qui s'en servent en production et des appareils dans le commerce où toutes les unités vendues sont basées sur la même clé avec les problèmes de sécurité évidents qui en découlent...

undefined

En même temps ces appliances sont habituellement destinées à être installées sur de cartes embarquées style Raspberry et non comme un OS de bureau ...

undefined

C'est la solution recommandée pour de l'expérimentation oui. Ubuntu Core est plutôt destiné à des machines en production

Il n'est plus possible de commenter cette actualité.

2000 - 2020 INpact MediaGroup - SARL de presse, membre du SPIIL. N° de CPPAP 0321 Z 92244.

Marque déposée. Tous droits réservés. Mentions légales et contact