Suivant: Invoquer guix challenge
, Précédent: Invoque guix graph
, Monter: Utilitaires [Table des matières][Index]
guix publish
Le but de guix publish
est de vous permettre de partager
facilement votre dépôt avec d’autres personnes qui peuvent ensuite
l’utiliser comme serveur de substituts (voir Substituts).
Lorsque guix publish
est lancé, il crée un serveur HTTP qui permet
à n’importe qui avec un accès réseau d’y récupérer des substituts. Cela
signifie que toutes les machines qui font tourner Guix peuvent aussi agir
comme une ferme de construction, puisque l’interface HTTP est compatible
avec Cuirass, le logiciel derrière la ferme de construction
ci.guix.gnu.org
.
Pour des raisons de sécurité, chaque substitut est signé, ce qui permet aux
destinataires de vérifier leur authenticité et leur intégrité
(voir Substituts). Parce que guix publish
utilise la clé de
signature du système, qui n’est lisible que par l’administrateur système, il
doit être lancé en root ; l’option --user
lui fait abandonner les
privilèges de root dès le début.
La pair de clefs pour les signatures doit être générée avant de lancer
guix publish
, avec guix archive --generate-key
(voir Invoquer guix archive
).
Lorsque vous passez l’option --advertise, le serveur annonce sa disponibilité sur le réseau local en utilisant le DNS multicast (mDNS) et le protocole de découvert de service DNS (DNS-SD), actuellement via Guile-Avahi (voir Using Avahi in Guile Scheme Programs).
La syntaxe générale est :
guix publish options…
Lancer guix publish
sans arguments supplémentaires lancera un
serveur HTTP sur le port 8080 :
guix publish
guix publish
peut aussi être démarré avec le protocole d’«
activation par socket » de systemd (voir make-systemd-constructor
dans le manuel de GNU Shepherd).
Une fois qu’un serveur de publication a été autorisé, le démon peut télécharger des substituts à partir de lui. Voir Récupérer des substituts d’autres serveurs.
Par défaut, guix publish
compresse les archives à la volée quand
il les sert. Ce mode « à la volée » est pratique puisqu’il ne demande
aucune configuration et est disponible immédiatement. Cependant, lorsqu’il
s’agit de servir beaucoup de clients, nous recommandons d’utiliser l’option
--cache, qui active le cache des archives avant de les envoyer aux
clients — voir les détails plus bas. La commande guix weather
fournit un manière pratique de vérifier ce qu’un serveur fournit
(voir Invoquer guix weather
).
En bonus, guix publish
sert aussi un miroir adressé par le contenu
des fichiers source référencées dans les enregistrements origin
(voir Référence de origin
). Par exemple, en supposant que guix
publish
tourne sur example.org
, l’URL suivante renverra le fichier
brut hello-2.10.tar.gz avec le hash SHA256 donné (représenté sous le
format nix-base32
, voir Invoquer guix hash
) :
http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1…ndq1i
Évidemment, ces URL ne fonctionnent que pour des fichiers dans le dépôt ; dans les autres cas, elles renvoie une erreur 404 (« Introuvable »).
Les journaux de construction sont disponibles à partir des URL /log
comme ceci :
http://example.org/log/gwspk…-guile-2.2.3
Lorsque guix-daemon
est configuré pour sauvegarder les journaux de
construction compressés, comme c’est le cas par défaut (voir Invoquer guix-daemon
), les URL /log
renvoient le journal compressé tel-quel,
avec une en-tête Content-Type
et/ou Content-Encoding
appropriée. Nous recommandons de lancer guix-daemon
avec
--log-compression=gzip parce que les navigateurs web les
décompressent automatiquement, ce qui n’est pas le cas avec la compression
bzip2.
Les options suivantes sont disponibles :
--port=port
-p port
Écoute les requêtes HTTP sur le port.
--listen=hôte
Écoute sur l’interface réseau de hôte. Par défaut, la commande accepte les connexions de n’importe quelle interface.
--user=utilisateur
-u utilisateur
Charge les privilèges de utilisateur le plus vite possible — c.-à-d. une fois que la socket du serveur est ouverte et que la clef de signature a été lue.
--compression[=méthode[:niveau]]
-C [méthode[:niveau]]
Compresser les données en utilisant les method et level donnés.
method est l’un des codes lzip
, zstd
ou gzip
;
lorsque method est omis, gzip
est utilisé.
Lorsque level est égal à zéro, désactivez la compression. La plage de 1 à 9 correspond à différents niveaux de compression : 1 est le plus rapide, et 9 est le meilleur (gourmand en CPU). Le niveau par défaut est 3.
Habituellement, lzip
compresse notablement mieux que gzip
pour
une légère augmentation de l’utilisation du CPU. voir
benchmarks on the lzip Web
page. Cependant, lzip
permet un faible débit à la décompression (de
l’ordre de 50 Mio/s sur du matériel récent), ce qui peut être le
facteur limitant pour quelqu’un qui télécharge sur un réseau rapide.
Le ratio de compression de zstd
est entre celui de lzip
et
celui de gzip
; son avantage principal est sa
high vitesse de décompression.
À moins que --cache ne soit utilisé, la compression se fait à la
volée et les flux compressés ne sont pas cachés. Ainsi, pour réduire la
charge sur la machine qui fait tourner guix publish
, c’est une
bonne idée de choisir un niveau de compression faible, de lancer
guix publish
derrière un serveur de cache ou d’utiliser
--cache. Utilise --cache a l’avantage qu’il permet à
guix publish
d’ajouter l’en-tête HTTP Content-Length
à sa
réponse.
Cette option peut être répétée, auquel cas chaque substitut est compressé en utilisant toutes les méthodes sélectionnées, et toutes sont annoncées. Cette option est utile lorsque les utilisateur·rice·s ne supportent pas toutes les méthodes de compression : il·elle·s peuvent sélectionner celle qu’elles supportent.
--cache=répertoire
-c répertoire
Cache les archives et les métadonnées (les URL .narinfo
) dans
répertoire et ne sert que les archives dans ce cache.
Lorsque cette option est omise, les archives et les métadonnées sont crées à
la volée. Cela réduit la bande passante disponible, surtout quand la
compression est activée puisqu’elle pourrait être limitée par le CPU. Un
autre inconvénient au mode par défaut est que la taille des archives n’est
pas connue à l’avance, donc guix publish
n’ajoute pas l’en-tête
Content-Length
à ses réponses, ce qui empêche les clients de savoir
la quantité de données à télécharger.
À l’inverse, lorsque --cache est utilisée, la première requête pour
un élément du dépôt (via une URL .narinfo
) déclenche une tâche de
fond pour créer l’archive — en calculant son .narinfo
et en
compressant l’archive au besoin. Une fois l’archive en cache dans
répertoire, les requêtes suivantes réussissent et sont servies
directement depuis le cache, ce qui garanti que les clients ont la meilleure
bande passante possible.
Cette première requête .narinfo
renvoie quand même 200, si l’élément
du dépôt est « assez petit », sous la limite de contournement du cache —
voir --cache-bypass-threshold plus bas. De cette manière, les
clients n’ont pas besoin d’attendre que l’archive soit prête. Pour les
éléments plus gros, la première requête .narinfo
renvoie 404, ce qui
signifie que les clients doivent attendre jusqu’à ce que l’archive soit
prête.
Le processus de création est effectué par des threads de travail. Par défaut, un thread par cœur du CPU est créé, mais cela peut être personnalisé. Voir --workers plus bas.
Lorsque l’option --ttl est utilisée, les entrées cachées sont automatiquement supprimées lorsqu’elles expirent.
--workers=N
Lorsque --cache est utilisée, demande l’allocation de N thread de travail pour créer les archives.
--ttl=ttl
Produit des en-têtes HTTP Cache-Control
qui annoncent une durée de
vie (TTL) de ttl. ttl peut dénoter une durée : 5d
signifie 5 jours, 1m
signifie un mois, etc.
Cela permet au Guix de l’utilisateur de garder les informations en cache
pendant ttl. Cependant, remarquez que guix publish
ne garanti
pas lui-même que les éléments du dépôt qu’il fournit seront toujours
disponible pendant la durée ttl.
En plus, lorsque --cache est utilisée, les entrées cachées qui n’ont pas été demandé depuis ttl et n’ont pas d’élément correspondant dans le dépôt peuvent être supprimées.
--negative-ttl=ttl
Produit de la même manière des en-têtes HTTP Cache-Control
pour
annoncer la durée de vie (TLL) d’une recherche négative — des entrées
du dépôt manquantes, pour lesquelles une erreur 404 est renvoyée. Par
défaut, aucun TTL négatif n’est annoncé.
Ce paramètre peut aider à ajuster la charge du serveur et la latence des substituts en demandant aux clients coopératifs d’être plus ou moins patients quand un élément du dépôt manque.
--cache-bypass-threshold=taille
Avec --cache, les éléments du dépôt plus petits que taille
sont immédiatement disponibles, même s’ils ne sont pas en cache.
taille est une taille en octets, ou peut utiliser un suffixe comme
M
pour les mégaoctets, etc. La valeur par défaut est 10M
.
Le « contournement du cache » vous permet de réduire le délai de publication pour les clients au prix d’utilisation accrue des I/O et du CPU sur le serveur : en fonction des accès clients, ces éléments peuvent être créés plusieurs fois avant qu’une copie ne soit disponible dans le cache.
Augmenter la limite peut être utile pour les sites qui ont peu d’utilisateurs, ou pour garantir que les utilisateurs reçoivent les substituts même pour les éléments qui ne sont pas populaires.
--nar-path=chemin
Utilise chemin comme préfixe des URL de fichier « nar » (voir normalized archives).
Par défaut, les nars sont présents à l’URL comme
/nar/gzip/…-coreutils-8.25
. Cette option vous permet de
changer la partie /nar
en chemin.
--public-key=fichier
--private-key=fichier
Utilise les fichiers spécifiques comme pair de clefs utilisées pour signer les éléments avant de les publier.
Les fichiers doivent correspondre à la même pair de clefs (la clef privée
est utilisée pour signer et la clef publique est seulement ajouté aux
métadonnées de la signature). Ils doivent contenir les clefs dans le format
s-expression canonique produit par guix archive --generate-key
(voir Invoquer guix archive
). Par défaut,
/etc/guix/signing-key.pub et /etc/guix/signing-key.sec sont
utilisés.
--repl[=port]
-r [port]
Crée un serveur REPL Guile (voir REPL Servers dans GNU Guile
Reference Manual) sur pport (37146 par défaut). C’est surtout utile
pour déboguer un serveur guix publish
qui tourne.
Activer guix publish
sur un système Guix est vraiment une seule
ligne : instanciez simplement un service guix-publish-service-type
dans le champs services
de votre déclaration operating-system
(voir guix-publish-service-type
).
Si vous utilisez plutôt Guix sur une « distro étrangère », suivez ces instructions :
# ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service \ /etc/systemd/system/ # systemctl start guix-publish && systemctl enable guix-publish
# ln -s ~root/.guix-profile/lib/upstart/system/guix-publish.conf /etc/init/ # start guix-publish
Suivant: Invoquer guix challenge
, Précédent: Invoque guix graph
, Monter: Utilitaires [Table des matières][Index]