Suivant: , Précédent: , Monter: Utilitaires   [Table des matières][Index]


9.10 Invoquer 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 publie 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

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 tache 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 expriment 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.

--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 :


Suivant: , Précédent: , Monter: Utilitaires   [Table des matières][Index]