Der Store (Referenzhandbuch zu GNU Guix)

9.9 Der Store

Konzeptionell ist der Store der Ort, wo Ableitungen nach erfolgreicher Erstellung gespeichert werden – standardmäßig finden Sie ihn in /gnu/store. Unterverzeichnisse im Store werden Store-Objekte oder manchmal auch Store-Pfade genannt. Mit dem Store ist eine Datenbank assoziiert, die Informationen enthält wie zum Beispiel, welche Store-Pfade jeder Store-Pfad jeweils referenziert, und eine Liste, welche Store-Objekte gültig sind, also Ergebnisse erfolgreicher Erstellungen sind. Die Datenbank befindet sich in localstatedir/guix/db, wobei localstatedir das mit --localstatedir bei der Ausführung von „configure“ angegebene Zustandsverzeichnis ist, normalerweise /var.

Auf den Store wird nur durch den Daemon im Auftrag seiner Clients zugegriffen (siehe Aufruf von guix-daemon). Um den Store zu verändern, verbinden sich Clients über einen Unix-Socket mit dem Daemon, senden ihm entsprechende Anfragen und lesen dann dessen Antwort – so etwas nennt sich entfernter Prozeduraufruf (englisch „Remote Procedure Call“ oder kurz RPC).

Anmerkung: Benutzer dürfen niemals Dateien in /gnu/store direkt verändern, sonst wären diese nicht mehr konsistent und die Grundannahmen im funktionalen Modell von Guix, dass die Objekte unveränderlich sind, wären dahin (siehe Einführung).

Siehe guix gc --verify für Informationen, wie die Integrität des Stores überprüft und nach versehentlichen Veränderungen unter Umständen wiederhergestellt werden kann.

Das Modul (guix store) bietet Prozeduren an, um sich mit dem Daemon zu verbinden und entfernte Prozeduraufrufe durchzuführen. Diese werden im Folgenden beschrieben. Das vorgegebene Verhalten von open-connection, und daher allen guix-Befehlen, ist, sich mit dem lokalen Daemon oder dem an der in der Umgebungsvariablen GUIX_DAEMON_SOCKET angegeben URL zu verbinden.

Umgebungsvariable: GUIX_DAEMON_SOCKET

Ist diese Variable gesetzt, dann sollte ihr Wert ein Dateipfad oder eine URI sein, worüber man sich mit dem Daemon verbinden kann. Ist der Wert der Pfad zu einer Datei, bezeichnet dieser einen Unix-Socket, mit dem eine Verbindung hergestellt werden soll. Ist er eine URI, so werden folgende URI-Schemata unterstützt:

file

unix

Für Unix-Sockets. file:///var/guix/daemon-socket/socket kann gleichbedeutend auch als /var/guix/daemon-socket/socket angegeben werden.

guix ¶

Solche URIs benennen Verbindungen über TCP/IP ohne Verschlüsselung oder Authentifizierung des entfernten Rechners. Die URI muss den Hostnamen, also den Rechnernamen des entfernten Rechners, und optional eine Portnummer angeben (sonst wird als Vorgabe der Port 44146 benutzt):

guix://master.guix.example.org:1234

Diese Konfiguration ist für lokale Netzwerke wie etwa in Rechen-Clustern geeignet, wo sich nur vertrauenswürdige Knoten mit dem Erstellungs-Daemon z.B. unter master.guix.example.org verbinden können.

Die Befehlszeilenoption --listen von guix-daemon kann benutzt werden, damit er auf TCP-Verbindungen lauscht (siehe --listen).

ssh ¶

Mit solchen URIs kann eine Verbindung zu einem entfernten Daemon über SSH hergestellt werden. Diese Funktionalität setzt Guile-SSH voraus (siehe Voraussetzungen) sowie eine funktionierende guile-Binärdatei, deren Ort im PATH der Zielmaschine eingetragen ist. Authentisierung über einen öffentlichen Schlüssel oder GSSAPI ist möglich. Eine typische URL sieht so aus:

ssh://charlie@guix.example.org:22

Was guix copy betrifft, richtet es sich nach den üblichen OpenSSH-Client-Konfigurationsdateien (siehe guix copy aufrufen).

In Zukunft könnten weitere URI-Schemata unterstützt werden.

Anmerkung: Die Fähigkeit, sich mit entfernten Erstellungs-Daemons zu verbinden, sehen wir als experimentell an, Stand 1.4.0. Bitte diskutieren Sie mit uns jegliche Probleme oder Vorschläge, die Sie haben könnten (siehe Mitwirken).

Scheme-Prozedur: open-connection [Uri] [#:reserve-space? #t]

Sich mit dem Daemon über den Unix-Socket an Uri verbinden (einer Zeichenkette). Wenn reserve-space? wahr ist, lässt ihn das etwas zusätzlichen Speicher im Dateisystem reservieren, damit der Müllsammler auch dann noch funktioniert, wenn die Platte zu voll wird. Liefert ein Server-Objekt.

Uri nimmt standardmäßig den Wert von %default-socket-path an, was dem bei der Installation mit dem Aufruf von configure ausgewählten Vorgabeort entspricht, gemäß den Befehlszeilenoptionen, mit denen configure aufgerufen wurde.

Scheme-Prozedur: close-connection Server: Die Verbindung zum Server trennen.

Scheme-Variable: current-build-output-port: Diese Variable ist an einen SRFI-39-Parameter gebunden, der auf den Scheme-Port verweist, an den vom Daemon empfangene Erstellungsprotokolle und Fehlerprotokolle geschrieben werden sollen.

Prozeduren, die entfernte Prozeduraufrufe durchführen, nehmen immer ein Server-Objekt als ihr erstes Argument.

Scheme-Prozedur: valid-path? Server Pfad

Liefert #t, wenn der Pfad ein gültiges Store-Objekt benennt, und sonst #f (ein ungültiges Objekt kann auf der Platte gespeichert sein, tatsächlich aber ungültig sein, zum Beispiel weil es das Ergebnis einer abgebrochenen oder fehlgeschlagenen Erstellung ist).

Ein &store-protocol-error-Fehlerzustand wird ausgelöst, wenn der Pfad nicht mit dem Store-Verzeichnis als Präfix beginnt (/gnu/store).

Scheme-Prozedur: add-text-to-store Server Name Text [Referenzen]: Den Text im Store in einer Datei namens Name ablegen und ihren Store-Pfad zurückliefern. Referenzen ist die Liste der Store-Pfade, die der Store-Pfad dann referenzieren soll.

Scheme-Prozedur: build-derivations Store Ableitungen [Modus] Die Ableitungen erstellen (eine Liste von: <derivation>-Objekten, .drv-Dateinamen oder Paaren aus je Ableitung und Ausgabe. Dabei gilt der angegebene Modus – vorgegeben ist (build-mode normal).

Es sei erwähnt, dass im Modul (guix monads) eine Monade sowie monadische Versionen obiger Prozeduren angeboten werden, damit an Code, der auf den Store zugreift, bequemer gearbeitet werden kann (siehe Die Store-Monade).

Dieser Abschnitt ist im Moment noch unvollständig.