2.2.1 Установка окружения сборки

В случае стандартной многопользовательской установки Guix и его демон (программа guix-daemon) установливаются системным администратором; /gnu/store принадлежит root, и guix-daemon запущен от root. Непривилегированные пользователи могут пользоваться инструментами Guix, чтобы собирать пакеты или получить доступ к складу с какой-либо целью, и демон выполнит это по их запросу, убедившись, что склад находится в должном состоянии, и разрешив сборку пакетов и разделение их между пользователями.

Когда guix-daemon запущен от root, возможно, из соображений безопасности вы не примете того, что процессы сборки пакетов тоже выполняются от root. Чтобы избежать этого, необходимо создать специальных пользователей для сборки. Ими будет пользоваться процесс сборки, запускаемый демоном. Эти пользователи сборки не должны иметь оболочки и домашней директории — они просто будут использоваться, когда демон сбрасывает привилегии root в процессе сборки. Наличие нескольких таких пользователей позволит демону запускать отдельные процессы сборки под отдельными UID, что гарантирует, что они не будут помехой друг другу — важная особенность, учитывая, что сборка рассматривается как чистая функция (see Введение).

В системе GNU/Linux набор пользователей для сборки может быть создан так (используя синтаксис команды Bash 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

Число пользователей для сборки определяет, сколько задач сборки может быть запущено параллельно. Это задаётся опцией --max-jobs (see --max-jobs). Чтобы использовать guix system vm и подобные, вам потребуется добавить пользователей для сборки в группу kvm, так чтобы они имели доступ к /dev/kvm, используя -G guixbuild,kvm вместо -G guixbuild (see Invoking guix system).

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

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

Так демон стартует процессы сборки в chroot под одним из пользователей группы guixbuilder. В GNU/Linux по умолчанию окружение chroot содержит только следующее:

• минимальный состав директории /dev, созданной максимально независимо от исходной /dev⁷;
• директория /proc; она показывает только процессы контейнера, так как используется отдельное пространство имён процессов PID;
• /etc/passwd с записью о текущем пользователе и пользователе nobody;
• /etc/group с записью о группе пользователя;
• /etc/hosts с записью, которая адресует localhost на 127.0.0.1;
• директория /tmp, доступная для записи.

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

Можно указать директорию, в которую демон сохраняет деревья сборки через переменную окружения TMPDIR. Однако дерево сборки внутри chroot всегда называется /tmp/guix-build-name.drv-0, где name - это имя деривации, то есть, например, coreutils-8.24. Так значение TMPDIR не проникает внутрь окружения сборки, что предотвращает расхождения и случаях, когда процессы сборки имеют иные имена их деревьев сборки.

Демон также уважаем переменную окружения http_proxy, когда выполняет скачивание по HTTP как для дериваций с фиксированным результатом (see Деривации), так и для подстановок (see Подстановки).

Если вы устанавливаете Guix как непривилегированный пользователь, всё ещё возможно запустить guix-daemon с указанием --disable-chroot. Однако процессы сборки не будут изолированы один от другого, а также от остальной системы. Так процессы сборки смогут внести помехи в работу друг друга, смогут получить доступ к программам, библиотекам и другим файлам, доступным в системе, что конечно, делает затруднительным рассмотрение сборки как чистой функции.