Suivant: Utiliser le dispositif de déchargement, Monter: Paramétrer le démon [Table des matières][Index]
In a standard multi-user setup, Guix and its daemon—the
guix-daemon
program—are installed by the system administrator.
Unprivileged users may use Guix tools to build packages or otherwise access
the store, and the daemon will do it on their behalf, ensuring that the
store is kept in a consistent state, and allowing built packages to be
shared among users.
There are currently two ways to set up and run the build daemon:
guix-daemon
as “root”, letting it run build processes as
unprivileged users taken from a pool of build users—this is the historical
approach;
guix-daemon
as a separate unprivileged user, relying on
Linux’s unprivileged user namespace functionality to set up isolated
environments—this is the option chosen when installing Guix on a
systemd-based distribution with the installation script (voir Installation binaire).
The sections below describe each of these two configurations in more detail and summarize the kind of build isolation they provide.
When guix-daemon
runs as root
, you may not want package
build processes themselves to run as root
too, for obvious security
reasons. To avoid that, a special pool of build users should be
created for use by build processes started by the daemon. Having several
such users allows the daemon to launch distinct build processes under
separate UIDs, which guarantees that they do not interfere with each
other—an essential feature since builds are regarded as pure functions
(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 suivante6 :
# guix-daemon --build-users-group=guixbuild
In this setup, /gnu/store is owned by root
.
The second and preferred option is to run guix-daemon
as an
unprivileged user. It has the advantage of reducing the harm that can be
done should a build process manage to exploit a vulnerability in the
daemon. This option requires the use of Linux’s unprivileged user namespace
mechanism; today it is available and enabled by most GNU/Linux distributions
but can still be disabled. The installation script automatically determines
whether this option is available on your system (voir Installation binaire).
When using this option, you only need to create one user account, and
guix-daemon
will run with the authority of that account:
# groupadd --system guix-daemon # useradd -g guix-daemon -G guix-daemon \ -d /var/empty -s $(which nologin) \ -c "Guix daemon privilege separation user" \ --system guix-daemon
In this configuration, /gnu/store is owned by the guix-daemon
user.
In both cases, the daemon starts build processes without privileges in an isolated or hermetic build environment—a “chroot”. On GNU/Linux, by default, the build environment contains nothing but:
/dev
minimal, créé presque indépendamment du
/dev
de l’hôte7 ;
/proc
; il ne montre que les processus du conteneur car
on utilise une espace de nom séparé pour les PID ;
localhost
à
127.0.0.1
;
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.
All this is usually enough to ensure details of the environment do not influence build processes. In some exceptional cases where more control is needed—typically over the date, kernel, or CPU—you can resort to a virtual build machine (voir virtual build machines).
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 votre machine utilise le système
d’initialisation systemd, copiez le fichier
prefix/lib/systemd/system/guix-daemon.service dans
/etc/systemd/system pour vous assurer que guix-daemon
est
démarré automatiquement. De même, si votre machine utilise le système
d’initialisation Upstart, copiez le fichier
prefix/lib/upstart/system/guix-daemon.conf dans
/etc/init.
« presque », parce que même si l’ensemble des
fichiers qui apparaissent dans le /dev
du chroot sont déterminés à
l’avance, la plupart de ces fichiers ne peut pas être créée si l’hôte ne les
a pas.
Suivant: Utiliser le dispositif de déchargement, Monter: Paramétrer le démon [Table des matières][Index]