2.3 Aufruf von guix-daemon

Das Programm guix-daemon implementiert alle Funktionalitäten, um auf den Store zuzugreifen. Dazu gehört das Starten von Erstellungsprozessen, das Ausführen des Müllsammlers, das Abfragen, ob ein Erstellungsergebnis verfügbar ist, etc. Normalerweise wird er so als Administratornutzer (root) gestartet:

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

Sie können den Daemon auch über das systemd-Protokoll zur „Socket-Aktivierung“ starten (siehe make-systemd-constructor in The GNU Shepherd Manual).

Details, wie Sie ihn einrichten, finden Sie im Abschnitt Den Daemon einrichten.

Standardmäßig führt guix-daemon Erstellungsprozesse mit unterschiedlichen UIDs aus, die aus der Erstellungsgruppe stammen, deren Name mit --build-users-group übergeben wurde. Außerdem läuft jeder Erstellungsprozess in einer chroot-Umgebung, die nur die Teilmenge des Stores enthält, von der der Erstellungsprozess abhängt, entsprechend seiner Ableitung (siehe Ableitungen), und ein paar bestimmte Systemverzeichnisse, darunter standardmäßig auch /dev und /dev/pts. Zudem ist die Erstellungsumgebung auf GNU/Linux eine isolierte Umgebung, d.h. ein Container: Nicht nur hat sie ihren eigenen Dateisystembaum, sie hat auch einen separaten Namensraum zum Einhängen von Dateisystemen, ihren eigenen Namensraum für PIDs, für Netzwerke, etc. Dies hilft dabei, reproduzierbare Erstellungen zu garantieren (siehe Funktionalitäten).

Wenn der Daemon im Auftrag des Nutzers eine Erstellung durchführt, erzeugt er ein Erstellungsverzeichnis, entweder in /tmp oder im Verzeichnis, das durch die Umgebungsvariable TMPDIR angegeben wurde. Dieses Verzeichnis wird mit dem Container geteilt, solange die Erstellung noch läuft, allerdings trägt es im Container stattdessen immer den Namen „/tmp/guix-build-NAME.drv-0“.

Nach Abschluss der Erstellung wird das Erstellungsverzeichnis automatisch entfernt, außer wenn die Erstellung fehlgeschlagen ist und der Client --keep-failed angegeben hat (siehe --keep-failed).

Der Daemon lauscht auf Verbindungen und erstellt jeweils einen Unterprozess für jede von einem Client begonnene Sitzung (d.h. von einem der guix-Unterbefehle). Der Befehl guix processes zeigt Ihnen eine Übersicht solcher Systemaktivitäten; damit werden Ihnen alle aktiven Sitzungen und Clients gezeigt. Weitere Informationen finden Sie unter guix processes aufrufen.

Die folgenden Befehlszeilenoptionen werden unterstützt:

--build-users-group=Gruppe

Verwende die Benutzerkonten aus der Gruppe, um Erstellungsprozesse auszuführen (siehe Erstellungsbenutzer).

--no-substitutes ¶

Benutze keine Substitute für Erstellungsergebnisse. Das heißt, dass alle Objekte lokal erstellt werden müssen, und kein Herunterladen von vorab erstellten Binärdateien erlaubt ist (siehe Substitute).

Wenn der Daemon mit --no-substitutes ausgeführt wird, können Clients trotzdem Substitute explizit aktivieren über den entfernten Prozeduraufruf set-build-options (siehe Der Store).

--substitute-urls=URLs

URLs als standardmäßige, leerzeichengetrennte Liste der Quell-URLs für Substitute benutzen. Wenn diese Befehlszeilenoption nicht angegeben wird, wird ‘https://bordeaux.guix.gnu.org https://ci.guix.gnu.org’ verwendet.

Das hat zur Folge, dass Substitute von den URLs heruntergeladen werden können, solange sie mit einer Signatur versehen sind, der vertraut wird (siehe Substitute).

Siehe Substitute von anderen Servern holen für weitere Informationen, wie der Daemon konfiguriert werden kann, um Substitute von anderen Servern zu beziehen.

--no-offload

Nicht versuchen, an andere Maschinen ausgelagerte Erstellungen zu benutzen (siehe Nutzung der Auslagerungsfunktionalität). Somit wird lokal erstellt, statt Erstellungen auf entfernte Maschinen auszulagern.

--cache-failures

Fehler bei der Erstellung zwischenspeichern. Normalerweise werden nur erfolgreiche Erstellungen gespeichert.

Wenn diese Befehlszeilenoption benutzt wird, kann guix gc --list-failures benutzt werden, um die Menge an Store-Objekten abzufragen, die als Fehlschläge markiert sind; guix gc --clear-failures entfernt Store-Objekte aus der Menge zwischengespeicherter Fehlschläge. Siehe guix gc aufrufen.

--cores=n

-c n

n CPU-Kerne zum Erstellen jeder Ableitung benutzen; 0 heißt, so viele wie verfügbar sind.

Der Vorgabewert ist 0, jeder Client kann jedoch eine abweichende Anzahl vorgeben, zum Beispiel mit der Befehlszeilenoption --cores von guix build (siehe Aufruf von guix build).

Dadurch wird die Umgebungsvariable NIX_BUILD_CORES im Erstellungsprozess definiert, welcher sie benutzen kann, um intern parallele Ausführungen zuzulassen – zum Beispiel durch Nutzung von make -j$NIX_BUILD_CORES.

--max-jobs=n

-M n

Höchstenss n Erstellungsaufträge parallel bearbeiten. Der Vorgabewert liegt bei 1. Wird er auf 0 gesetzt, werden keine Erstellungen lokal durchgeführt, stattdessen lagert der Daemon sie nur aus (siehe Nutzung der Auslagerungsfunktionalität) oder sie schlagen einfach fehl.

--max-silent-time=Sekunden

Wenn der Erstellungs- oder Substitutionsprozess länger als Sekunden-lang keine Ausgabe erzeugt, wird er abgebrochen und ein Fehler beim Erstellen gemeldet.

Der Vorgabewert ist 3600 (eine Stunde).

Clients können einen anderen Wert als den hier angegebenen verwenden lassen (siehe --max-silent-time).

--timeout=Sekunden

Entsprechend wird hier der Erstellungs- oder Substitutionsprozess abgebrochen und als Fehlschlag gemeldet, wenn er mehr als Sekunden-lang dauert.

Vorgegeben sind 24 Stunden.

Clients können einen anderen Wert verwenden lassen (siehe --timeout).

--rounds=N

Jede Ableitung n-mal hintereinander erstellen und einen Fehler melden, wenn nacheinander ausgewertete Erstellungsergebnisse nicht Bit für Bit identisch sind. Beachten Sie, dass Clients wie guix build einen anderen Wert verwenden lassen können (siehe Aufruf von guix build).

Wenn dies zusammen mit --keep-failed benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen /gnu/store/…-check. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden.

--debug

Informationen zur Fehlersuche ausgeben.

Dies ist nützlich, um Probleme beim Starten des Daemons nachzuvollziehen; Clients könn aber auch ein abweichenden Wert verwenden lassen, zum Beispiel mit der Befehlszeilenoption --verbosity von guix build (siehe Aufruf von guix build).

--chroot-directory=Verzeichnis

Füge das Verzeichnis zum chroot von Erstellungen hinzu.

Dadurch kann sich das Ergebnis von Erstellungsprozessen ändern – zum Beispiel, wenn diese optionale Abhängigkeiten aus dem Verzeichnis verwenden, wenn sie verfügbar sind, und nicht, wenn es fehlt. Deshalb ist es nicht empfohlen, dass Sie diese Befehlszeilenoption verwenden, besser sollten Sie dafür sorgen, dass jede Ableitung alle von ihr benötigten Eingabgen deklariert.

--disable-chroot

Erstellungen ohne chroot durchführen.

Diese Befehlszeilenoption zu benutzen, wird nicht empfohlen, denn auch dadurch bekämen Erstellungsprozesse Zugriff auf nicht deklarierte Abhängigkeiten. Sie ist allerdings unvermeidlich, wenn guix-daemon auf einem Benutzerkonto ohne ausreichende Berechtigungen ausgeführt wird.

--log-compression=Typ

Erstellungsprotokolle werden entsprechend dem Typ komprimiert, der entweder gzip, bzip2 oder none (für keine Kompression) sein muss.

Sofern nicht --lose-logs angegeben wurde, werden alle Erstellungsprotokolle in der localstatedir gespeichert. Um Platz zu sparen, komprimiert sie der Daemon standardmäßig automatisch mit gzip.

--discover[=yes|no]

Ob im lokalen Netzwerk laufende Substitutserver mit mDNS und DNS-SD ermittelt werden sollen oder nicht.

Diese Funktionalität ist noch experimentell. Trotzdem sollten Sie bedenken:

1. Es könnte schneller bzw. günstiger sein, als Substitute von entfernten Servern zu beziehen.
2. Es gibt keine Sicherheitsrisiken, weil nur echte Substitute benutzt werden können (siehe Substitutauthentifizierung).
3. Wenn ein Angreifer Ihnen sein guix publish in Ihrem LAN mitteilt, kann er Ihnen keine bösartigen Programmdateien unterjubeln, aber er kann lernen, welche Software Sie installieren.
4. Server können Ihnen Substitute über unverschlüsseltes HTTP anbieten, wodurch auch jeder andere in Ihrem LAN vielleicht mitschneiden könnte, welche Software Sie installieren.

Das Erkennen von Substitutservern können Sie auch nachträglich zur Laufzeit an- oder abschalten („on“ oder „off“), indem Sie dies ausführen:

herd discover guix-daemon on
herd discover guix-daemon off

--disable-deduplication ¶

Automatische Dateien-„Deduplizierung“ im Store ausschalten.

Standardmäßig werden zum Store hinzugefügte Objekte automatisch „dedupliziert“: Wenn eine neue Datei mit einer anderen im Store übereinstimmt, wird die neue Datei stattdessen als harte Verknüpfung auf die andere Datei angelegt. Dies reduziert den Speicherverbrauch auf der Platte merklich, jedoch steigt andererseits die Auslastung bei der Ein-/Ausgabe im Erstellungsprozess geringfügig. Durch diese Option wird keine solche Optimierung durchgeführt.

--gc-keep-outputs[=yes|no]

Gibt an, ob der Müllsammler (Garbage Collector, GC) die Ausgaben lebendiger Ableitungen behalten muss („yes“) oder nicht („no“).

Für yes behält der Müllsammler die Ausgaben aller lebendigen Ableitungen im Store – die .drv-Dateien. Der Vorgabewert ist aber no, so dass Ableitungsausgaben nur vorgehalten werden, wenn sie von einer Müllsammlerwurzel aus erreichbar sind. Siehe den Abschnitt guix gc aufrufen für weitere Informationen zu Müllsammlerwurzeln.

--gc-keep-derivations[=yes|no]

Gibt an, ob der Müllsammler (GC) Ableitungen behalten muss („yes“), wenn sie lebendige Ausgaben haben, oder nicht („no“).

Für yes, den Vorgabewert, behält der Müllsammler Ableitungen – z.B. .drv-Dateien –, solange zumindest eine ihrer Ausgaben lebendig ist. Dadurch können Nutzer den Ursprung der Dateien in ihrem Store nachvollziehen. Setzt man den Wert auf no, wird ein bisschen weniger Speicher auf der Platte verbraucht.

Auf diese Weise überträgt sich, wenn --gc-keep-derivations auf yes steht, die Lebendigkeit von Ausgaben auf Ableitungen, und wenn --gc-keep-outputs auf yes steht, die Lebendigkeit von Ableitungen auf Ausgaben. Stehen beide auf yes, bleiben so alle Erstellungsvoraussetzungen wie Quelldateien, Compiler, Bibliotheken und andere Erstellungswerkzeuge lebendiger Objekte im Store erhalten, ob sie von einer Müllsammlerwurzel aus erreichbar sind oder nicht. Entwickler können sich so erneute Erstellungen oder erneutes Herunterladen sparen.

--impersonate-linux-2.6

Auf Linux-basierten Systemen wird hiermit vorgetäuscht, dass es sich um Linux 2.6 handeln würde, indem der Kernel für einen uname-Systemaufruf als Version der Veröffentlichung mit 2.6 antwortet.

Dies kann hilfreich sein, um Programme zu erstellen, die (normalerweise zu Unrecht) von der Kernel-Versionsnummer abhängen.

--lose-logs

Keine Protokolle der Erstellungen vorhalten. Normalerweise würden solche in localstatedir/guix/log gespeichert.

--system=System

Verwende System als aktuellen Systemtyp. Standardmäßig ist dies das Paar aus Befehlssatz und Kernel, welches beim Aufruf von configure erkannt wurde, wie zum Beispiel x86_64-linux.

--listen=Endpunkt

Lausche am Endpunkt auf Verbindungen. Dabei wird der Endpunkt als Dateiname eines Unix-Sockets verstanden, wenn er mit einem / (Schrägstrich) beginnt. Andernfalls wird der Endpunkt als Rechnername (d.h. Hostname) oder als Rechnername-Port-Paar verstanden, auf dem gelauscht wird. Hier sind ein paar Beispiele:

--listen=/gnu/var/daemon

Lausche auf Verbindungen am Unix-Socket /gnu/var/daemon, falls nötig wird er dazu erstellt.

--listen=localhost ¶

Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die localhost entspricht, auf Port 44146.

--listen=128.0.0.42:1234

Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die 128.0.0.42 entspricht, auf Port 1234.

Diese Befehlszeilenoption kann mehrmals wiederholt werden. In diesem Fall akzeptiert guix-daemon Verbindungen auf allen angegebenen Endpunkten. Benutzer können bei Client-Befehlen angeben, mit welchem Endpunkt sie sich verbinden möchten, indem sie die Umgebungsvariable GUIX_DAEMON_SOCKET festlegen (siehe GUIX_DAEMON_SOCKET).

Anmerkung: Das Daemon-Protokoll ist weder authentifiziert noch verschlüsselt. Die Benutzung von --listen=Rechner eignet sich für lokale Netzwerke, wie z.B. in Rechen-Clustern, wo sich nur solche Knoten mit dem Daemon verbinden, denen man vertraut. In Situationen, wo ein Fernzugriff auf den Daemon durchgeführt wird, empfehlen wir, über Unix-Sockets in Verbindung mit SSH zuzugreifen.

Wird --listen nicht angegeben, lauscht guix-daemon auf Verbindungen auf dem Unix-Socket, der sich unter localstatedir/guix/daemon-socket/socket befindet.