Nächste: , Nach oben: Den Daemon einrichten   [Inhalt][Index]

2.2.1 Einrichten der Erstellungsumgebung

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:

  1. running guix-daemon as “root”, letting it run build processes as unprivileged users taken from a pool of build users—this is the historical approach;
  2. running 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 (siehe Aus Binärdatei installieren).

The sections below describe each of these two configurations in more detail and summarize the kind of build isolation they provide.

Daemon Running as Root

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 (siehe Einführung).

Auf einem GNU/Linux-System kann ein Pool von Erstellungsbenutzern wie folgt erzeugt werden (mit Bash-Syntax und den Befehlen von shadow): 

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

Die Anzahl der Erstellungsbenutzer entscheidet, wie viele Erstellungsaufträge parallel ausgeführt werden können, wie es mit der Befehlszeilenoption --max-jobs vorgegeben werden kann (siehe --max-jobs). Um guix system vm und ähnliche Befehle nutzen zu können, müssen Sie die Erstellungsbenutzer unter Umständen zur kvm-Benutzergruppe hinzufügen, damit sie Zugriff auf /dev/kvm haben, mit -G guixbuild,kvm statt -G guixbuild (siehe guix system aufrufen).

Das Programm guix-daemon kann mit dem folgenden Befehl als root gestartet werden6: 

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

In this setup, /gnu/store is owned by root.

Daemon Running Without Privileges

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 (siehe Aus Binärdatei installieren).

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.

The Isolated Build Environment

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:

Im chroot ist kein /home-Verzeichnis enthalten und die Umgebungsvariable HOME ist auf das nicht existierende Verzeichnis /homeless-shelter festgelegt. Dadurch fallen unangemessene Verwendungen von HOME in den Erstellungs-Skripts von Paketen auf.

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 (siehe virtual build machines).

Sie können beeinflussen, in welchem Verzeichnis der Daemon Verzeichnisbäume zur Erstellung unterbringt, indem sie den Wert der Umgebungsvariablen TMPDIR ändern. Allerdings heißt innerhalb des chroots der Erstellungsbaum immer /tmp/guix-build-Name.drv-0, wobei Name der Ableitungsname ist – z.B. coreutils-8.24. Dadurch hat der Wert von TMPDIR keinen Einfluss auf die Erstellungsumgebung, wodurch Unterschiede vermieden werden, falls Erstellungsprozesse den Namen ihres Erstellungsbaumes einfangen.

Der Daemon befolgt außerdem den Wert der Umgebungsvariablen http_proxy und https_proxy für von ihm durchgeführte HTTP- und HTTPS-Downloads, sei es für Ableitungen mit fester Ausgabe (siehe Ableitungen) oder für Substitute (siehe Substitute).

Fußnoten

(6)

Wenn Ihre Maschine systemd als „init“-System verwendet, genügt es, die Datei prefix/lib/systemd/system/guix-daemon.service nach /etc/systemd/system zu kopieren, damit guix-daemon automatisch gestartet wird. Ebenso können Sie, wenn Ihre Maschine Upstart als „init“-System benutzt, die Datei prefix/lib/upstart/system/guix-daemon.conf nach /etc/init kopieren.

(7)

„Größtenteils“, denn obwohl die Menge an Dateien, die im /dev des chroots vorkommen, fest ist, können die meisten dieser Dateien nur dann erstellt werden, wenn das Wirtssystem sie auch hat.

Nächste: Nutzung der Auslagerungsfunktionalität, Nach oben: Den Daemon einrichten   [Inhalt][Index]