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


7.10 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 Aufruf von guix archive).

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

Sobald ein Server zum Veröffentlichen autorisiert wurde (siehe Aufruf von guix archive), kann der Daemon davon Substitute herunterladen:

guix-daemon --substitute-urls=http://example.org:8080

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 Aufruf von guix weather).

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 Aufruf von guix hash):

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 des 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 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.

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 liefert, wenn --cache benutzt wird, die erste Anfrage nach einem Store-Objekt (über dessen .narinfo-URL) den Fehlercode 404, und im Hintergrund wird ein Prozess gestartet, 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.

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.

--nar-path=Pfad

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

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 Aufruf von guix archive). 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 GNU Guile Reference Manual) 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: , Vorige: , Nach oben: Zubehör   [Inhalt][Index]