Comme dit précédemment, la configuration de Guix se fait via le langage Guile. Cela peut sembler surprenant aux premiers abords, mais personnellement je trouve cela très intéressant.

Déjà, pourquoi un langage de type Scheme et non quelque chose de plus "classique" (comme Python par exemple) ? Les langages de la famille des Lisp sont généralement beaucoup plus flexibles que leurs homologues d’autres familles, et ont une syntaxe concise et cohérente.
Si vous n’avez pas l’habitude de Lisp/Scheme, insistez un peu, c’est juste une famille de langages différente de ce qu’on a l’habitude de voir. Et ces langages ont beaucoup d’avantages.

De manière générale, je préfère configurer si possible mes outils avec un vrai langage de programmation et non avec des DSL limités inventés pour l’occasion (coucou Prometheus). C’est d’ailleurs pour moi la grande force d’outils comme Riemann, dont les idées n’ont malheureusement pas été reprises dans d’autres outils de monitoring.

Avant de pouvoir tester la distribution, il faut d’abord l’installer.
Une solution serait d’installer la distribution sur votre ordinateur. Cela peut marcher, mais GuixSD est une distribution founissant une quantité limitée de drivers (la distribution faisant partie du projet GNU, les drivers propriétaires en sont exclus), cela peut donc vous poser des problèmes.

Il est également possible d’installer Guix, le package manager de GuixSD (qui est la distribution), sur une distribution comme Debian ou Ubuntu, ce qui permet de l’utiliser tout en conservant une autre distribution comme distribution principale.
J’avais testé celle solution (Guix + Debian) il y a quelques années, mais j’avais rencontré de nombreux problèmes de conflits entre les packages venant de Guix et ceux venant de Debian, je pense donc que ce n’est pas une bonne idée.

La dernière solution est de déployer GuixSD sur un environnement contrôlé: le Cloud. Ici, pas besoin de drivers, et ça nous permettra de tester facilement la distribution. C’est la solution que nous allons explorer dans cet article.

Nous allons tout d’abord créer une image GuixSD qui sera ensuite envoyée sur le Cloud. Une solution pourrait être de démarrer avec par exemple KVM l’iso d’installation de GuixSD, et de suivre le manuel (que vous trouverez ici).

Mais comme d’habitude, on va essayer d’automatiser un peu la chose, et nous allons construire notre image avec Packer. Cela nous permettra de reconstruire à tout moment notre image si besoin, en une commande.

Si vous ne connaissez pas Packer, je vous recommande la lecture de mon article sur le sujet qui donne un bon aperçu de l’outil.

On peut maintenant démarrer notre machine virtuelle, et commencer à jouer avec en se connectant dessus en SSH (en utilisant le mot de passe défini précédemment).

A la base, j’avais prévu un article beaucoup plus conséquent sur GuixSD (installation de packages, de services, intégration Ansible, rollbacks…​). Mais après avoir passé pas mal de soirées à jouer avec la distribution, j’arrive aux conclusions suivantes:

Documentation

Le manque de documentation fait qu’il est quasiment impossible de comprendre comment utiliser la distribution (configurer un service, ou comment construire un package par exemple).

La documentation de GuixSD se limite généralement à une documentation des fonctions Guile pour intéragir avec les différents sous modules. Très bien, écrire du code je sais faire. Mais ensuite, j’en fais quoi ? Où est ce que je dois mettre mes fichiers de configurations, où est ce que je dois les référencer ? C’est quoi les bonnes pratiques ? Mystère.
Il manque selon moi toute la documentation "utilisateur". Donner une collection de fonctions Scheme et leurs paramètres n’est pas suffisant si on ne sait pas quoi en faire.

Quand vous avez un problème, vous trouverez peut être quelqu’un ayant eu le même problème ou la même question sur les logs IRC de Guix, ou bien quelqu’un aura donné une solution sur un site web. Sinon, vous serez bloqué.

Ne pouvant pas me permettre de repasser mes soirées pendant encore 2 semaines à lire des historiques de logs IRC et le code source GuixSD pour essayer de comprendre quoi faire, j’ai donc abandonné et livre donc un article incomplet. Cela ne m’était jamais arrivé, même mon article sur eBPF avait été plus facile à écrire.

Quelques exemples de points de blocages.

Packages

Il y a peu de documentation sur comment packager une application. A force de chercher, j’ai réussi à packager un simple shell script que je place dans un dossier bin. A la base, je voulais coder une simple implémentation de cloud-init en shell et pouvoir configurer ma machine Guix de cette façon (clés SSH notamment) sur Exoscale. Je mets le code du package (qui a l’air de marcher) ici, ça servira peut être à quelqu’un:

Services

Prenons l’exemple des services. Vous trouverez dans la documentation de Guix ou de shepherd (le daemon gérant les services dans Guix) une liste de fonctions pour configurer un service, mais pas vraiment d’exemples. La section example contient FIXME: This needs a lot of work., et l’exemple donné à base de make <service> ne fonctionne pas, j’ai jamais réussi à trouver quel module importer pour le faire marcher.
Ce problème d’import se rencontre d’ailleurs partout dans GuixSD, les exemples dans la documentation sont généralement mis sans la liste des modules à importer, donc le code est de fait inutilisable.

Je voulais à la base définir un service pour le package exo-init définit précédemment, et pouvoir lancer ce script à chaque démarrage de la machine. Déjà, je n’ai jamais trouvé comment configurer un service lors de l’installation du package, j’ai juste réussi à écrire cela en m’inspirant de différentes sources trouvées à droite à gauche (dont le code source de Guix):

A noter: je voulais au début ne passer aucun paramètre à exo-init-service-type mais ça n’a pas l’air possible, je passe donc un paramètre non utilisé.

Et même une fois le service écrit, j’en fais quoi ? Je dois l’installer manuellement pour chaque utilisateur ? Je dois le définir dans /etc/config.scm ? Je n’ai pas la réponse à ces questions.

Bugs

Le coup de grâce a été un bug que je rencontre actuellement sur un template GuixSD tout neuf. Toutes les commandes guix package finissent en:

Un guix gc --delete /gnu/store/b09qkb8r06l64p809nysp67ihmvrib2f-guile-gdbm-ffi-20120209.fa1d5b6.drv permet de supprimer ce fichier, mais il revient lors d’une installation de package.

Donc en gros je ne peux plus rien faire sur la machine. Je me dis donc tiens, c’est le moment de tester les rollbacks !. Je lance donc guix package --list-generations (commande trouvée dans l’article partagé précemment), j’obtiens maintenant:

(╯°□°）╯︵ ┻━┻

Les idées de GuixSD sont très bonnes, le choix de Scheme pour la configuration est super. Mais pour faire marcher le machin, faut s’accrocher. Et encore, je faisais mes tests sur un cloud, donc aucun problème de drivers ou autre, et pas de risque de flinguer ma machine.

Peut être que je referais une tentative dans quelques années ?