Mon retour d'expérience sur Yunohost

Ce blog est hébergé sur une instance Yunohost, j’avais envie d’expliquer pourquoi j’avais fait ce choix, comment je m’y étais pris, ce que je pensais du projet…​

Yunohost, qu’est-ce que c’est?

Je vais forcément moins bien l’expliquer que la page dédiée au sujet, du coup sans trop m’étendre je dirais que Yunohost (Ynh pour les intimes) est une suite d’outils intégrés sur un système d’exploitation (Debian en l’occurence) pour faciliter l’hébergement de services web ou autres.

Cela ouvre la possibilité de s’autohéberger à des gens qui n’ont pas forcément toutes les compétences ou le temps pour gérer indépendemment toutes les briques qui composent Ynh.

Ynh offre entre autres:

  • Une authentification centralisée et un filtrage de l’accès aux applications web

  • Une interface d’administration simple web ou en ligne de commande

  • Un catalogue d’applications installables en quelques clics (ou commandes)

  • Une gestion automatique des certificats HTTPS avec letsencrypt

  • Une gestion simplifiée des mises à jour du système et des applications

L’avant Yunohost

Pour expliquer comment j’en suis arrivé à Yunohost, je vais commencer par un état des lieux avant Ynh.

J’avais des services — pour la plupart web mais pas que — installés sur divers serveurs, avec diverses technologies (conteneurs, machines virtuelles, physiques), sur diverses distributions GNU/Linux. Ces services m’étaient au départ exclusivement destinés et n’étaient que des tests suite à des découvertes au détour des internets. Certains étaient nés d’un besoin et d’une volonté de quitter l’emprise des géants du net. J’ai ainsi commencé par Nextcloud, Piwigo, Zimbra/Kolab, Mumble et d’autres.

Le lancement de la campagne dégooglisons Internet de framasoft n’a fait qu’accélérer ces déploiements de test qui finissaient par avoir une petite vie dans un coin de serveur.

Au fur et à mesure j’ai ouvert ces services à des proches et puis j’ai testé de nouvelles façon de les installer, de les gérer et ça a fini par devenir un joyeux bordel.

Plusieurs problèmes ont fait surface:

  • Impossible de tenir tout ça à jour. Même en automatisant mes installations je n’avais aucune gestion unifiée et tout tenir à jour aurait pris beaucoup trop de temps et d’énergie.

  • Trop de comptes à gérer. C’est assez pénible d’avoir un compte pour chacune des applications qu’on utilise.

  • Impossible de tout sauvegarder correctement. Du fait de la diversité des environnements, des technologies, des méthodes, la sauvegarde était trop compliquée à gérer. Je ne parle même pas des restaurations…​

La décision de migrer, le choix technique

J’avais déjà testé Yunohost rapidement il y a quelques années, et ce n’était pas suffisamment abouti à mon goût, il n’y avait que trop peu d’applications disponibles et mon joyeux bordel ne se résumait encore qu’à quelques applications sur une machine virtuelle.

J’avais déjà dans l’idée depuis plusieurs mois sinon années de regrouper toutes mes applications, de monter un ldap, de me créer de beaux playbooks pour déployer et gérer tout ça mais la montagne de boulot à abattre, de compétences à assimiler, le manque d’heures dans les journées (qui a eu l’idée de n’en mettre que 24, tsss…​), …​ je n’avais pas la motivation et je ne voyais pas le bout du tunnel.

Puis il y a queques mois j’ai testé Ynh à nouveau et j’y ai vu une solution à tous mes problèmes:

  • Toutes les applications s’installent de la même façon

  • Toutes les applications se sauvegardent de la même façon

  • Une base centralisée d’utilisateurs

  • Les mises à jour sont gérées quasi-automatiquement

Restait à savoir maintenant comment procéder et où héberger la bête.

Le où, était assez simple: j’avais déjà deux serveur dédiés chez OVH.

Pour le comment, j’ai d’abord pensé à un conteneur lxc (mais avec lxd) mais j’ai très vite compris que ça n’allait pas être possible ou que ça allait nécessiter pas mal de bidouille, Ynh réalise certaines tâches en faisant des montages de systèmes de fichiers et ça ne fait pas bon ménage avec les conteneurs.

J’ai opté pour la virtualisation, c’est ce que j’avais déjà fait sur un de mes serveurs dédiés et ça apporte de la souplesse avec la possibilité de faire des snapshots avant les grosses opérations.

J’allais donc faire la même chose sur le deuxième serveur mais cette fois-ci avec KVM pour hyperviseur et non Esxi comme le premier.

Je me retrouve donc avec deux machines virtuelles: une pour une instance de test et une pour ma prod, chacune accessible sur sa propre adresse IP grâce aux IP failover. J’explique comment je m’y suis pris dans un autre article de ce blog.

Les applications

Parmi les applications proposées dans le catalogue Ynh, certaines étaient des évidences car je les avais déjà déployées et je les utilisais déjà avant de passer à Ynh:

  • Nextcloud pour la synchro de fichiers entre tous mes appareils

  • Piwigo pour partager mes photos avec mes proches

  • Blogotext qui me servait d’abord pour le blog mais désormais je n’utilise plus que la partie liens, le blog étant remplacé par ce site généré avec Hugo et Asciidoctor

  • Firefox Sync pour garder mes profils firefox au chaud chez moi et non chez Mozilla

  • Gitlab pour …​ quasiment tout ce que je fais: développements, playbooks ansible, scripts, fichiers de configuration, …​

  • La messagerie. Ce n’est pas vraiment une application, c’est installé d’office. En revanche j’ai installé Sogo pour avoir simplement la synchro Caldav et Carddav ainsi qu’une interface web sympa et complète. D’ailleurs la doc Ynh sur la configuration pour la messagerie est parfaite, je m’en sors avec un 10/10 aux differents tests.

  • Freshrss pour gérer tous mes flux préférés

  • Des outils de partage divers: lutim, lufi, zerobin

  • Unattended-upgrades: pour les mises à jour automatiques du système avec un e-mail qui récapitule le tout

  • Mumble pour le chat audio en remplacement de teamspeak

D’autres que je n’avais pas encore déployées:

  • Mastodon pour remplacer twitter qui ne m’avait jamais attiré étant trop centralisé

  • Wallabag pour remplacer pocket que je n’avais jamais utilisé dans Firefox

  • Etherpad pour la prise de note et leur édition collaborative. A noter le greffon Mypads qui ajoute à Etherpad tout ce qui lui manquait: gestion d’accès et liste des pads

D’autres que j’ai testées mais finalement pas utilisées pour des raisons diverses et variées:

  • Matomo: parce que c’est une usine à gaz, parce que je me suis dit que finalement je n’irais pas forcément voir ce qu’il y a dedans, parce que je n’avais pas envie de le gérer et finalement pas le besoin.

  • PeerTube: je comptais m’en servir pour héberger des vidéos personnelles à partager avec mes proches, je voulais donc la déployer en application privée (nécessite un compte sur l’instance Yunohost pour y accéder) mais un bug fait que ça ne fonctionne pas autrement qu’en public. Je réessaierai plus tard.

  • Borg: je n’ai pas réussi le faire fonctionner pour mes sauvegarde externalisées. Finalement j’ai créé un paquet restic que je lui préfère, même si restic ne propose pas la compression, ce n’est pas ce que je recherche, je veux surtout un outil simple à utiliser pour mes sauvegardes.

  • Synapse: trop usine à gaz à mon goût et puis autant utiliser xmpp qui est installé d’office comme la messagerie et qu’en plus je connais déjà.

  • Calibre-web: j’ai eu des bugs à l’ajout d’utilisateurs. J’essaierai sûrement de trouver une solution, je trouve sympa l’idée de partager une bibliotèque numérique

  • Jitsi Meet: J’ai fait quelques tests non concluants, connexion perdue, pas de son, …​ ça venait peut-être de moi, l’appli nécessite une configuration particulière niveau DNS notamment mais je n’avais pas envie de chercher. Il faudra que je réessaye à l’occasion car j’aimerais éviter d’utiliser skype pour contacter ma famille à la Réunion. En attendant j’utiliserai une autre instance.

  • Minetest: ça fait déjà pas mal de choses sur le serveur, je ne pense pas qu’il reste suffisamment de ressources pour Minetest. Je l’hébergerai ailleurs

  • Owntracks: pour partager des positions GPS. la version packagée ne propose pas la seule fonctionalité qui pouvait m’intéresser, le partage aux amis. De plus (plutôt moins) l’application Android utilisait google maps.

  • Pilea: Pour visualiser et analyser ma consommation électrique via mon compteur Linky. Ne semble pas fonctionner, aucune donnée ne remonte

  • z-push: pour la synchro active-sync, ça me semblait être une bonne idée mais au final avec les bons outils caldav et carddav suffisent et au moins on reste sur des protocoles ouverts.

  • collabora-online: pour l’édition dans le navigateur des fichiers libreoffice. Pour l’instant il y a un bug avec l’application dans Nextcloud

Concernant les données, j’ai géré les migrations au cas par cas. Pour certaines applications le contenu importait peu, pour d’autres j’ai fait au plus simple.

J’ai tout fait manuellement puisque je n’avais pas beaucoup de comptes à migrer et pas énormément de données. J’en ai profité pour faire du nettoyage, je suis passé de près de cent projets dans Gitlab à moins de cinquante et d’environ 300 liens dans Blogotext à moins de cinquante également.

Ça a pris un peu de temps mais je pense que créer des scripts de migration pour chaque appli aurait été beaucoup plus long.

Les problèmes rencontrés

J’ai eu quelques petits problèmes jusque-là, rien de bien méchant.

J’utilise thunderbird comme client de messagerie sur mes postes de travail et parfois j’avais un message d’erreur, un problème de connexion au serveur.

J’ai ignoré le problème car ça arrivait assez rarement et puis ça a fini par survenir plus souvent, surtout à partir du moment ou j’ai créé des sous-répertoires dans ma boîte de réception. Sur mon client android j’ai fini par avoir un message explicite, il s’agissait d’une limite de connexion atteinte par utilisateur et par IP.

Pour le corriger, dans /etc/dovecot/dovecot.conf, j’ai modifié mail_max_userip_connections = 10 en mail_max_userip_connections = 50

J’avais essayé de faire la modification dans les fichiers /etc/dovecot/conf.d/20-imap.conf et /etc/dovecot/conf.d/20-managesieve.conf mais ça n’était jamais pris en compte par dovecot, on peut le vérifier en exécutant dovecot -a | grep 'mail_max_userip_connections.

En regardant un peu plus en détail, les fichiers de /etc/dovecot/conf.d ne sont jamais inclus dans dovecot.conf donc je ne vois pas comment ça aurait pu marcher.

J’ai eu aussi suite à un redémarrage du serveur un petit souci avec Gitlab qui ne démarrait pas.

Il s’agissait du service gitlab-runsvdir qui ne voulait pas se lancer. En essayant de le lancer manuellement il restait bloqué. J’ai dû tuer le process et redémarrer le service: killall runsvdir; systemctl start gitlab-runsvdir.service

Autre problème mais qui pour l’instant n’est pas bloquant, la version de Nextcloud packagée est en retard par rapport à celle des développeurs à cause de la version de PHP disponible sur Debian Stretch. Je n’ai pas besoin de la dernière version de Nextcloud pour l’instant mais je serais quand même rassuré quand ce souci sera résolu.

De manière générale, c’est une limitation de Yunohost. Comme les applications sont repackagées, cela ajoute une couche de complexité quand il faut déboguer un problème. Cependant j’y vois plus d’avantages que d’inconvénients.

Et la suite?

Je suis tout à fait satisfait de Yunohost, je trouve que c’est un superbe projet avec une communauté sympa. Je compte donc y participer, il y a plein de choses à faire:

  • Aider à tester le déploiement et la mise à niveau vers Debian Buster. Même si Debian Stretch est encore supporté il faudra bien passer la vitesse supérieure un jour.

  • Aider à packager d’autres applications, ou aider à améliorer l’intégration de certaines applications. J’aimerais bien en savoir un peu plus sur la gestion du Single Sign On

  • Aider à traduire la documentation ou les applications

  • Aider à corriger les bugs qui m’ont empêché d’utiliser certaines applications

  • Aider sur le forum

Bref, que de choses intéressantes, je n’ai pas l’habitude de m’ennuyer et ce n’est pas près de changer!