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.

• Ubuntu et Raspberry Pi 2/3/4 : nouvelles images, outil de personnalisation, catalogue d'appliances, etc.

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.

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.

• Paquets AppImage, Snap et Flatpak : quels avantages, inconvénients et différences ?

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é) :

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.

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.