2.4.1 Réglages de l’environnement de construction

Dans une installation standard multi-utilisateur·rice·s, Guix et son démon — le programme guix-daemon — sont installés par la personne qui administre le système ; /gnu/store appartient à root et guix-daemon est lancé en root. Les utilisateur·rice·s non-privilégié·e·s peuvent utiliser les outils Guix pour construire des paquets ou accéder au dépôt et le démon le fera pour leur compte en s’assurant que le dépôt garde un état cohérent et permet le partage des paquets déjà construits entre les utilisateur·rice·s.

Alors que guix-daemon tourne en root, vous n’avez pas forcément envie que les processus de construction de paquets tournent aussi en root, pour des raisons de sécurité évidentes. Pour éviter cela, vous devriez créer une réserve spéciale de comptes de construction que les processus de construction démarrés par le démon utiliseront. Ces comptes de construction n’ont pas besoin d’un shell ou d’un répertoire personnel ; ils seront seulement utilisés quand le démon délaissera ses privilèges root dans les processus de construction. En ayant plusieurs de ces comptes, vous permettez au démon de lancer des processus de construction distincts sous des UID différent, ce qui garanti qu’aucune interférence n’ait lieu entre les uns et les autres — une fonctionnalité essentielle puisque les constructions sont supposées être des fonctions pures (voir Introduction).

Sur un système GNU/Linux, on peut créer une réserve de comptes de construction comme ceci (avec la syntaxe Bash et les commandes shadow) :

# groupadd --system guixbuild
# for i in $(seq -w 1 10);
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s $(which nologin)    \
            -c "Compte de construction Guix $i" --system    \
            guixbuilder$i;
  done

Le nombre de comptes de construction détermine le nombre de tâches de constructions qui peuvent tourner en parallèle, tel que spécifié par l’option --max-jobs (voir --max-jobs). Pour utiliser guix system vm et les commandes liées, vous devrez ajouter les comptes de construction au groupe kvm pour qu’ils puissent accéder à /dev/kvm avec -G guixbuild,kvm plutôt que -G guixbuild (voir Invoquer guix system).

Le programme guix-daemon peut ensuite être lancé en root avec la commande suivante⁶ :

# guix-daemon --build-users-group=guixbuild

De cette façon, le démon démarre les processus de construction dans un chroot, sous un des comptes guixbuilder. Sur GNU/Linux par défaut, l’environnement chroot ne contient rien d’autre que :

• un répertoire /dev minimal, créé presque indépendamment du /dev de l’hôte⁷ ;
• le répertoire /proc ; il ne montre que les processus du conteneur car on utilise une espace de nom séparé pour les PID ;
• /etc/passwd avec une entrée pour le compte actuel et une entrée pour le compte nobody ;
• /etc/group avec une entrée pour le groupe de ce compte ;
• /etc/hosts avec une entrée qui fait correspondre localhost à 127.0.0.1 ;
• un répertoire /tmp inscriptible.

Le chroot ne contient pas de dossier /home, et la variable d’environnement HOME est initialisée au répertoire /homeless-shelter inexistant. Cela permet de mettre en valeur les utilisations inappropriées de HOME dans les scripts de construction des paquets.

Vous pouvez influencer le répertoire où le démon stocke les arbres de construction via la variable d’environnement TMPDIR. Cependant, l’arbre de construction dans le chroot sera toujours appelé /tmp/guix-build-nom.drv-0, où nom est le nom de la dérivation — p.ex., coreutils-8.24. De cette façon, la valeur de TMPDIR ne fuite pas à l’intérieur des environnements de construction, ce qui évite des différences lorsque le processus de construction retient le nom de leur répertoire de construction.

Le démon prend aussi en compte la variable d’environnement https_proxy pour ses téléchargements HTTP et HTTPS, que ce soit pour les dérivations à sortie fixes (voir Dérivations) ou pour les substituts (voir Substituts).

Si vous installez Guix en tant qu’utilisateur·rice non privilégié·ée, il est toujours possible d’exécuter guix-daemon à condition de passer --disable-chroot. Cependant, les processus de compilation ne seront pas isolés les uns des autres, ni du reste du système. Ainsi, les processus de compilation peuvent interférer les uns avec les autres, et peuvent accéder à des programmes, des bibliothèques et d’autres fichiers disponibles sur le système - ce qui rend beaucoup plus difficile de les considérer comme des fonctions pures.