2.2.1 Configuração do ambiente de compilação

Em uma configuração multiusuário padrão, o Guix e seu daemon – o programa guix-daemon – são instalados pelo administrador do sistema; /gnu/store é de propriedade de root e guix-daemon é executado como root. Usuários desprivilegiados podem usar ferramentas Guix para criar pacotes ou acessar o armazém, e o daemon fará isso em seu nome, garantindo que o armazém seja mantido em um estado consistente e permitindo que pacotes construídos sejam compartilhados entre os usuários.

Quando guix-daemon é executado como root, você pode não querer que os próprios processos de compilação de pacotes também sejam executados como root, por razões óbvias de segurança. Para evitar isso, um conjunto especial de usuários de compilação deve ser criado para uso pelos processos de construção iniciados pelo daemon. Esses usuários de compilação não precisam ter um shell e um diretório inicial: eles serão usados apenas quando o daemon der um privilégio root nos processos de compilação. Ter vários desses usuários permite que o daemon ative processos de compilação distintos sob UIDs separados, o que garante que eles não interfiram uns com os outros - um recurso essencial, pois as compilações são consideradas funções puras (veja Introdução).

Em um sistema GNU/Linux, um conjunto de usuários de construção pode ser criado assim (usando a sintaxe Bash e os comandos 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 build user $i" --system    \
            guixbuilder$i;
  done

O número de usuários de compilação determina quantos trabalhos de compilação podem ser executados em paralelo, conforme especificado pela opção --max-jobs (veja --max-jobs). Para usar guix system vm e comandos relacionados, você pode precisar adicionar os usuários de compilação ao grupo kvm para que eles possam acessar /dev/kvm, usando -G guixbuild,kvm em vez de -G guixbuild (veja Invoking guix system).

The guix-daemon program may then be run as root with the following command⁶:

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

Dessa forma, o daemon inicia os processos de compilação em um chroot, sob um dos usuários guixbuilder. No GNU/Linux, por padrão, o ambiente chroot contém nada além de:

• um diretório /dev mínimo, criado principalmente independentemente do /dev do hospedeiro⁷;
• o diretório /proc; mostra apenas os processos do contêiner desde que um espaço de nome PID separado é usado;
• /etc/passwd com uma entrada para o usuário atual e uma entrada para o usuário nobody;
• /etc/group com uma entrada para o grupo de usuários;
• /etc/hosts com uma entrada que mapeia localhost para 127.0.0.1;
• um diretório /tmp com permissão de escrita.

The chroot does not contain a /home directory, and the HOME environment variable is set to the non-existent /homeless-shelter. This helps to highlight inappropriate uses of HOME in the build scripts of packages.

All this 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 (veja virtual build machines).

You can influence the directory where the daemon stores build trees via the TMPDIR environment variable. However, the build tree within the chroot is always called /tmp/guix-build-name.drv-0, where name is the derivation name—e.g., coreutils-8.24. This way, the value of TMPDIR does not leak inside build environments, which avoids discrepancies in cases where build processes capture the name of their build tree.

The daemon also honors the http_proxy and https_proxy environment variables for HTTP and HTTPS downloads it performs, be it for fixed-output derivations (veja Derivações) or for substitutes (veja Substitutos).

If you are installing Guix as an unprivileged user, it is still possible to run guix-daemon provided you pass --disable-chroot. However, build processes will not be isolated from one another, and not from the rest of the system. Thus, build processes may interfere with each other, and may access programs, libraries, and other files available on the system—making it much harder to view them as pure functions.