Nächste: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]

10.11 guix publish aufrufen

Der Zweck von guix publish ist, es Nutzern zu ermöglichen, ihren Store auf einfache Weise mit anderen zu teilen, die ihn dann als Substitutserver einsetzen können (siehe Substitute).

Wenn guix publish ausgeführt wird, wird dadurch ein HTTP-Server gestartet, so dass jeder mit Netzwerkzugang davon Substitute beziehen kann. Das bedeutet, dass jede Maschine, auf der Guix läuft, auch als Erstellungsfarm fungieren kann, weil die HTTP-Schnittstelle mit Cuirass, der Software, mit der die offizielle Erstellungsfarm ci.guix.gnu.org betrieben wird, kompatibel ist.

Um Sicherheit zu gewährleisten, wird jedes Substitut signiert, so dass Empfänger dessen Authentizität und Integrität nachprüfen können (siehe Substitute). Weil guix publish den Signierschlüssel des Systems benutzt, der nur vom Systemadministrator gelesen werden kann, muss es als der Administratornutzer „root“ gestartet werden. Mit der Befehlszeilenoption --user werden Administratorrechte bald nach dem Start wieder abgelegt.

Das Schlüsselpaar zum Signieren muss erzeugt werden, bevor guix publish gestartet wird. Dazu können Sie guix archive --generate-key ausführen (siehe guix archive aufrufen).

Wird die Befehlszeilenoption --advertise übergeben, teilt der Server anderen Rechnern im lokalen Netzwerk seine Verfügbarkeit mit, über Multicast-DNS (mDNS) und DNS-Service-Discovery (DNS-SD), zurzeit mittels Guile-Avahi (siehe Using Avahi in Guile Scheme Programs).

Die allgemeine Syntax lautet: 

guix publish Optionen…

Wird guix publish ohne weitere Argumente ausgeführt, wird damit ein HTTP-Server gestartet, der auf Port 8080 lauscht: 

guix publish

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

Sobald ein Server zum Veröffentlichen autorisiert wurde, kann der Daemon davon Substitute herunterladen. Siehe Substitute von anderen Servern holen.

Nach den Voreinstellungen komprimiert guix publish Archive erst dann, wenn sie angefragt werden. Dieser „dynamische“ Modus bietet sich an, weil so nichts weiter eingerichtet werden muss und er direkt verfügbar ist. Wenn Sie allerdings viele Clients bedienen wollen, empfehlen wir, dass Sie die Befehlszeilenoption --cache benutzen, die das Zwischenspeichern der komprimierten Archive aktiviert, bevor diese an die Clients geschickt werden – siehe unten für Details. Mit dem Befehl guix weather haben Sie eine praktische Methode zur Hand, zu überprüfen, was so ein Server anbietet (siehe guix weather aufrufen).

Als Bonus dient guix publish auch als inhaltsadressierbarer Spiegelserver für Quelldateien, die in origin-Verbundsobjekten eingetragen sind (siehe origin-Referenz). Wenn wir zum Beispiel annehmen, dass guix publish auf example.org läuft, liefert folgende URL die rohe hello-2.10.tar.gz-Datei mit dem angegebenen SHA256-Hash als ihre Prüfsumme (dargestellt im nix-base32-Format, siehe guix hash aufrufen): 

http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1…ndq1i

Offensichtlich funktionieren diese URLs nur mit solchen Dateien, die auch im Store vorliegen; in anderen Fällen werden sie 404 („Nicht gefunden“) zurückliefern.

Erstellungsprotokolle sind unter /log-URLs abrufbar: 

http://example.org/log/gwspk…-guile-2.2.3

Ist der guix-daemon so eingestellt, dass er Erstellungsprotokolle komprimiert abspeichert, wie es voreingestellt ist (siehe Aufruf von guix-daemon), liefern /log-URLs das unveränderte komprimierte Protokoll, mit einer entsprechenden Content-Type- und/oder Content-Encoding-Kopfzeile. Wir empfehlen dabei, dass Sie den guix-daemon mit --log-compression=gzip ausführen, weil Web-Browser dieses Format automatisch dekomprimieren können, was bei Bzip2-Kompression nicht der Fall ist.

Folgende Befehlszeilenoptionen stehen zur Verfügung:

--port=Port
-p Port

Auf HTTP-Anfragen auf diesem Port lauschen.

--listen=Host

Auf der Netzwerkschnittstelle für den angegebenen Host, also der angegebenen Rechneradresse, lauschen. Vorgegeben ist, Verbindungen mit jeder Schnittstelle zu akzeptieren.

--user=Benutzer
-u Benutzer

So früh wie möglich alle über die Berechtigungen des Benutzers hinausgehenden Berechtigungen ablegen – d.h. sobald der Server-Socket geöffnet und der Signierschlüssel gelesen wurde.

--compression[=Methode[:Stufe]]
-C [Methode[:Stufe]]

Daten auf der angegebenen Kompressions-Stufe mit der angegebenen Methode komprimieren. Als Methode kann entweder lzip, zstd oder gzip angegeben werden. Wird keine Methode angegeben, wird gzip benutzt.

Daten auf der angegebenen Kompressions-Stufe komprimieren. Wird als Stufe null angegeben, wird Kompression deaktiviert. Der Bereich von 1 bis 9 entspricht unterschiedlichen Kompressionsstufen: 1 ist am schnellsten, während 9 am besten komprimiert (aber den Prozessor mehr auslastet). Der Vorgabewert ist 3.

Normalerweise ist die Kompression mit lzip wesentlich besser als bei gzip, dafür wird der Prozessor geringfügig stärker ausgelastet; siehe Vergleichswerte auf dem Webauftritt von lzip. lzip erreicht jedoch nur einen niedrigen Durchsatz bei der Dekompression (in der Größenordnung von 50 MiB/s auf moderner Hardware), was einen Engpass beim Herunterladen über schnelle Netzwerkverbindungen darstellen kann.

Das Kompressionsverhältnis von zstd liegt zwischen dem von lzip und dem von gzip; sein größter Vorteil ist eine hohe Geschwindigkeit bei der Dekompression.

Wenn --cache nicht übergeben wird, werden Daten dynamisch immer erst dann komprimiert, wenn sie abgeschickt werden; komprimierte Datenströme landen in keinem Zwischenspeicher. Um also die Auslastung der Maschine, auf der guix publish läuft, zu reduzieren, kann es eine gute Idee sein, eine niedrige Kompressionsstufe zu wählen, guix publish einen Proxy mit Zwischenspeicher (einen „Caching Proxy“) voranzuschalten, oder --cache zu benutzen. --cache zu benutzen, hat den Vorteil, dass guix publish damit eine Content-Length-HTTP-Kopfzeile seinen Antworten beifügen kann.

Wenn diese Befehlszeilenoption mehrfach angegeben wird, wird jedes Substitut mit allen ausgewählten Methoden komprimiert und jede davon wird bei Anfragen mitgeteilt. Das ist nützlich, weil Benutzer, bei denen nicht alle Kompressionsmethoden unterstützt werden, die passende wählen können.

--cache=Verzeichnis
-c Verzeichnis

Archive und Metadaten (.narinfo-URLs) in das Verzeichnis zwischenspeichern und nur solche Archive versenden, die im Zwischenspeicher vorliegen.

Wird diese Befehlszeilenoption weggelassen, dann werden Archive und Metadaten „dynamisch“ erst auf eine Anfrage hin erzeugt. Dadurch kann die verfügbare Bandbreite reduziert werden, besonders wenn Kompression aktiviert ist, weil die Operation dann durch die Prozessorleistung beschränkt sein kann. Noch ein Nachteil des voreingestellten Modus ist, dass die Länge der Archive nicht im Voraus bekannt ist, guix publish also keine Content-Length-HTTP-Kopfzeile an seine Antworten anfügt, wodurch Clients nicht wissen können, welche Datenmenge noch heruntergeladen werden muss.

Im Gegensatz dazu löst, wenn --cache benutzt wird, die erste Anfrage nach einem Store-Objekt (über dessen .narinfo-URL) den Start eines Hintergrundprozesses aus, der das Archiv in den Zwischenspeicher einlagert (auf Englisch sagen wir „bake the archive“), d.h. seine .narinfo wird berechnet und das Archiv, falls nötig, komprimiert. Sobald das Archiv im Verzeichnis zwischengespeichert wurde, werden nachfolgende Anfragen erfolgreich sein und direkt aus dem Zwischenspeicher bedient, der garantiert, dass Clients optimale Bandbreite genießen.

Die erste Anfrage nach einer .narinfo wird trotzdem 200 zurückliefern, wenn das angefragte Store-Objekt „klein genug“ ist, also kleiner als der Schwellwert für die Zwischenspeicherumgehung, siehe --cache-bypass-threshold unten. So müssen Clients nicht darauf warten, dass das Archiv eingelagert wurde. Bei größeren Store-Objekten liefert die erste .narinfo-Anfrage 404 zurück, was bedeutet, dass Clients warten müssen, bis das Archiv eingelagert wurde.

Der Prozess zum Einlagern wird durch Worker-Threads umgesetzt. Der Vorgabe entsprechend wird dazu pro Prozessorkern ein Thread erzeugt, aber dieses Verhalten kann angepasst werden. Siehe --workers weiter unten.

Wird --ttl verwendet, werden zwischengespeicherte Einträge automatisch gelöscht, sobald die dabei angegebene Zeit abgelaufen ist.

--workers=N

Wird --cache benutzt, wird die Reservierung von N Worker-Threads angefragt, um Archive einzulagern.

--ttl=ttl

Cache-Control-HTTP-Kopfzeilen erzeugen, die eine Time-to-live (TTL) von ttl signalisieren. Für ttl muss eine Dauer (mit dem Anfangsbuchstaben der Maßeinheit der Dauer im Englischen) angegeben werden: 5d bedeutet 5 Tage, 1m bedeutet 1 Monat und so weiter.

Das ermöglicht es Guix, Substitutinformationen ttl lang zwischenzuspeichern. Beachten Sie allerdings, dass guix publish selbst nicht garantiert, dass die davon angebotenen Store-Objekte so lange verfügbar bleiben, wie es die ttl vorsieht.

Des Weiteren können bei Nutzung von --cache die zwischengespeicherten Einträge gelöscht werden, wenn auf sie ttl lang nicht zugegriffen wurde und kein ihnen entsprechendes Objekt mehr im Store existiert.

--negative-ttl=ttl

Eben solche Cache-Control-HTTP-Kopfzeilen für erfolglose (negative) Suchen erzeugen, um eine Time-to-live (TTL) zu signalisieren, wenn Store-Objekte fehlen und mit dem HTTP-Status-Code 404 geantwortet wird. Nach Vorgabe wird für negative Antworten keine TTL signalisiert.

Dieser Parameter kann helfen, die Last auf dem Server und die Verzögerung zu regulieren, weil folgsame Clients angewiesen werden, für diese Zeit geduldig zu warten, wenn ein Store-Objekt fehlt.

--cache-bypass-threshold=Größe

Wird dies in Verbindung mit --cache angegeben, werden Store-Objekte kleiner als die Größe sofort verfügbar sein, obwohl sie noch nicht in den Zwischenspeicher eingelagert wurden. Die Größe gibt die Größe in Bytes an oder ist mit einem Suffix M für Megabyte und so weiter versehen. Die Vorgabe ist 10M.

Durch diese „Zwischenspeicherumgehung“ lässt sich die Verzögerung bis zur Veröffentlichung an Clients reduzieren, auf Kosten zusätzlicher Ein-/Ausgaben und CPU-Auslastung für den Server. Je nachdem, welche Zugriffsmuster Clients haben, werden diese Store-Objekte vielleicht mehrfach zur Einlagerung vorbereitet, ehe eine Kopie davon im Zwischenspeicher verfügbar wird.

Wenn ein Anbieter nur wenige Nutzer unterhält, kann es helfen, den Schwellwert zu erhöhen, oder auch wenn garantiert werden soll, dass es auch für wenig beliebte Store-Objekte Substitute gibt.

--nar-path=Pfad

Den Pfad als Präfix für die URLs von „nar“-Dateien benutzen (siehe Normalisierte Archive).

Vorgegeben ist, dass Nars unter einer URL mit /nar/gzip/…-coreutils-8.25 angeboten werden. Mit dieser Befehlszeilenoption können Sie den /nar-Teil durch den angegebenen Pfad ersetzen.

--public-key=Datei
--private-key=Datei

Die angegebenen Dateien als das Paar aus öffentlichem und privatem Schlüssel zum Signieren veröffentlichter Store-Objekte benutzen.

Die Dateien müssen demselben Schlüsselpaar entsprechen (der private Schlüssel wird zum Signieren benutzt, der öffentliche Schlüssel wird lediglich in den Metadaten der Signatur aufgeführt). Die Dateien müssen Schlüssel im kanonischen („canonical“) S-Ausdruck-Format enthalten, wie es von guix archive --generate-key erzeugt wird (siehe guix archive aufrufen). Vorgegeben ist, dass /etc/guix/signing-key.pub und /etc/guix/signing-key.sec benutzt werden.

--repl[=Port]
-r [Port]

Einen Guile-REPL-Server (siehe REPL Servers in Referenzhandbuch zu GNU Guile) auf diesem Port starten (37146 ist voreingestellt). Dies kann zur Fehlersuche auf einem laufenden „guix publish“-Server benutzt werden.

guix publish auf einem „Guix System“-System zu aktivieren ist ein Einzeiler: Instanziieren Sie einfach einen guix-publish-service-type-Dienst im services-Feld Ihres operating-system-Objekts zur Betriebssystemdeklaration (siehe guix-publish-service-type).

Falls Sie Guix aber auf einer „Fremddistribution“ laufen lassen, folgen Sie folgenden Anweisungen:

Nächste: guix challenge aufrufen, Vorige: guix graph aufrufen, Nach oben: Zubehör   [Inhalt][Index]