This is guix.fr.info, produced by makeinfo version 6.8 from
guix.fr.texi.

Copyright © 2012–2025 Ludovic Courtès
Copyright © 2013, 2014, 2016, 2024 Andreas Enge
Copyright © 2013 Nikita Karetnikov
Copyright © 2014, 2015, 2016 Alex Kost
Copyright © 2015, 2016 Mathieu Lirzin
Copyright © 2014 Pierre-Antoine Rault
Copyright © 2015 Taylan Ulrich Bayırlı/Kammer
Copyright © 2015, 2016, 2017, 2019, 2020, 2021, 2023, 2025 Leo Famulari
Copyright © 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023 Ricardo
Wurmus
Copyright © 2016 Ben Woodcroft
Copyright © 2016, 2017, 2018, 2021 Chris Marusich
Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2025 Efraim
Flashner
Copyright © 2016 John Darrington
Copyright © 2016, 2017 Nikita Gillmann
Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025
Janneke Nieuwenhuizen
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Julien Lepiller
Copyright © 2016 Alex ter Weele
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Christopher Baines
Copyright © 2017, 2018, 2019 Clément Lassieur
Copyright © 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe
Copyright © 2017 Federico Beffa
Copyright © 2017, 2018, 2024, 2025 Carlo Zancanaro
Copyright © 2017 Thomas Danckaert
Copyright © 2017 humanitiesNerd
Copyright © 2017, 2021 Christine Lemmer-Webber
Copyright © 2017, 2018, 2019, 2020, 2021, 2022 Marius Bakke
Copyright © 2017, 2019, 2020, 2022 Hartmut Goebel
Copyright © 2017, 2019–2025 Maxim Cournoyer
Copyright © 2017–2022 Tobias Geerinckx-Rice
Copyright © 2017 George Clemmer
Copyright © 2017 Andy Wingo
Copyright © 2017, 2018, 2019, 2020, 2023, 2024, 2025 Arun Isaac
Copyright © 2017 nee
Copyright © 2018 Rutger Helling
Copyright © 2018, 2021, 2023, 2025 Oleg Pykhalov
Copyright © 2018 Mike Gerwitz
Copyright © 2018 Pierre-Antoine Rouby
Copyright © 2018, 2019 Gábor Boskovits
Copyright © 2018, 2019, 2020, 2022, 2023, 2024 Florian Pelz
Copyright © 2018 Laura Lazzati
Copyright © 2018 Alex Vong
Copyright © 2019 Josh Holland
Copyright © 2019, 2020 Diego Nicola Barbato
Copyright © 2019 Ivan Petkov
Copyright © 2019 Jakob L. Kreuze
Copyright © 2019 Kyle Andrews
Copyright © 2019 Alex Griffin
Copyright © 2019, 2020, 2021, 2022 Guillaume Le Vaillant
Copyright © 2020 Liliana Marie Prikler
Copyright © 2019, 2020, 2021, 2022, 2023 Simon Tournier
Copyright © 2020 Wiktor Żelazny
Copyright © 2020 Damien Cassou
Copyright © 2020 Jakub Kądziołka
Copyright © 2020 Jack Hill
Copyright © 2020 Naga Malleswari
Copyright © 2020, 2021 Brice Waegeneire
Copyright © 2020 R Veera Kumar
Copyright © 2020, 2021, 2022 Pierre Langlois
Copyright © 2020 pinoaffe
Copyright © 2020, 2023 André Batista
Copyright © 2020, 2021 Alexandru-Sergiu Marton
Copyright © 2020 raingloom
Copyright © 2020 Daniel Brooks
Copyright © 2020 John Soo
Copyright © 2020 Jonathan Brielmaier
Copyright © 2020 Edgar Vincent
Copyright © 2021, 2022 Maxime Devos
Copyright © 2021 B. Wilson
Copyright © 2021 Xinglu Chen
Copyright © 2021 Raghav Gururajan
Copyright © 2021 Domagoj Stolfa
Copyright © 2021 Hui Lu
Copyright © 2021 pukkamustard
Copyright © 2021 Alice Brenon
Copyright © 2021-2023 Josselin Poiret
Copyright © 2021, 2023 muradm
Copyright © 2021, 2022 Andrew Tropin
Copyright © 2021 Sarah Morgensen
Copyright © 2022 Remco van ’t Veer
Copyright © 2022 Aleksandr Vityazev
Copyright © 2022 Philip M^{c}Grath
Copyright © 2022 Karl Hallsby
Copyright © 2022 Justin Veilleux
Copyright © 2022 Reily Siegel
Copyright © 2022 Simon Streit
Copyright © 2022 (
Copyright © 2022 John Kehayias
Copyright © 2022⁠–⁠2023 Bruno Victal
Copyright © 2022 Ivan Vilata-i-Balaguer
Copyright © 2023-2025 Giacomo Leidi
Copyright © 2022 Antero Mejr
Copyright © 2023 Karl Hallsby
Copyright © 2023 Nathaniel Nicandro
Copyright © 2023 Tanguy Le Carrour
Copyright © 2023-2024 Zheng Junjie
Copyright © 2023 Brian Cully
Copyright © 2023 Felix Lechner
Copyright © 2023 Foundation Devices, Inc.
Copyright © 2023 Thomas Ieong
Copyright © 2023 Saku Laesvuori
Copyright © 2023 Graham James Addis
Copyright © 2023-2025 Tomas Volf
Copyright © 2024, 2025 Herman Rimm
Copyright © 2024 Matthew Trzcinski
Copyright © 2024 Richard Sent
Copyright © 2024 Dariqq
Copyright © 2024 Denis ’GNUtoo’ Carikli
Copyright © 2024 Fabio Natali
Copyright © 2024 Arnaud Daby-Seesaram
Copyright © 2024-2025 Nigko Yerden
Copyright © 2024 Troy Figiel
Copyright © 2024 Sharlatan Hellseher
Copyright © 2024 45mg
Copyright © 2024 Greg Hogan
Copyright © 2025 Sören Tempel
Copyright © 2025 Rostislav Svoboda
Copyright © 2025 Zacchaeus
Copyright © 2025 Sergio Pastor Pérez
Copyright © 2024 Evgeny Pisemsky
Copyright © 2025 jgart
Copyright © 2025 Artur Wroblewski
Copyright © 2025 Edouard Klein
Copyright © 2025 Rodion Goritskov
Copyright © 2025 dan
Copyright © 2025 Noé Lopez

   Vous avez la permission de copier, distribuer ou modifier ce document
sous les termes de la Licence GNU Free Documentation, version 1.3 ou
toute version ultérieure publiée par la Free Software Foundation ; sans
section invariante, texte de couverture et sans texte de quatrième de
couverture. Une copie de la licence est incluse dans la section
intitulée « GNU Free Documentation License ».
INFO-DIR-SECTION Administration système
START-INFO-DIR-ENTRY
* Guix.fr: (guix.fr).        Gérer les logiciels installés et la
                               configuration du système.
* guix package: (guix.fr)Invoquer guix package.  Installer, supprimer et
                                                   mettre à jour des paquets.
* guix gc: (guix.fr)Invoquer guix gc.  Récupérer de l’espace disque
                                         inutilisé.
* guix pull: (guix.fr)Invoquer guix pull.  Mettre à jour la liste des
                                             paquets disponibles.
* guix system: (guix.fr)Invoquer guix system.  Gérer la configuration du
                                                 système d’exploitation.
* guix deploy: (guix.fr)Invoquer guix deploy.  Gérer la configuration du
                                                 système d’exploitation
                                                 d’hôtes distants.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Développement logiciel
START-INFO-DIR-ENTRY
* guix shell: (guix.fr)Invoquer guix shell.  Créer des environnements
                                               logiciels.
* guix environment: (guix.fr)Invoquer guix environment.  Construire des
                                                           environnements de
                                                           construction avec
                                                           Guix.
* guix build: (guix.fr)Invoquer guix build.  Construire des paquets.
* guix pack: (guix.fr) Invoquer guix pack.  Créer des lots binaires.
END-INFO-DIR-ENTRY


File: guix.fr.info,  Node: Services de contrôle de version,  Next: Services de jeu,  Prev: Services de virtualisation,  Up: Services

11.10.32 Services de contrôle de version
----------------------------------------

Le module ‘(gnu services version-control)’ fournit un service pour
permettre l’accès à distance à des dépôts Git locaux. Il y a trois
options : en utilisant ‘git-daemon-service-type’ qui fournit un accès
aux dépôts via le protocole non sécurisé ‘git://’ basé sur TCP, en
étendant le serveur web ‘nginx’ pour relayer les requêtes vers
‘git-http-backend’ ou en fournissant une interface web avec
‘cgit-service-type’.

 -- Variable : git-daemon-service-type
     Type de service qui lance ‘git daemon’, un serveur TCP simple pour
     exposer des dépôts sur le protocole Git pour des accès anonymes.

     La valeur de ce service est un enregistrement
     ‘<git-daemon-configuration>’, par défaut il permet l’accès en
     lecture-seule aux dépôts exportés(1) dans ‘/srv/git’.

 -- Type de données : git-daemon-configuration
     Type de données qui représente la configuration de
     ‘git-daemon-service-type’.

     ‘package’ (par défaut : ‘git’)
          Objet de paquet du système de contrôle de version distribué
          Git.

     ‘export-all?’ (par défaut : ‘#f’)
          Indique s’il faut permettre l’accès à tous les dépôts Git,
          même s’ils n’ont pas le fichier ‘git-daemon-export-ok’.

     ‘base-path’ (par défaut : ‘/srv/git’)
          Indique s’il faut traduire toutes les requêtes de chemins
          relativement au chemin actuel. Si vous lancez ‘git daemon’
          avec ‘(base-path "/srv/git")’ sur ‘example.com’, et que vous
          essayez ensuite de récupérer ‘git://example.com/hello.git’, le
          démon git interprètera ce chemin comme étant
          ‘/srv/git/hello.git’.

     ‘user-path’ (par défaut : ‘#f’)
          Indique s’il faut permettre la notation ‘~user’ dans les
          requêtes. Lorsque spécifié avec une chaine vide, les requêtes
          à ‘git://host/~alice/toto’ sont des requêtes d’accès au dépôt
          ‘toto’ dans le répertoire personnel de l’utilisateur ‘alice’.
          Si (USER-PATH "CHEMIN") est spécifié, la même requête est
          interprétée comme accédant au répertoire ‘CHEMIN/foo’ dans le
          répertoire personnel de l’utilisateur ‘alice’.

     ‘listen’ (par défaut : ‘'()’)
          Indique s’il faut écouter sur des adresses IP ou des noms
          d’hôtes particuliers, par défaut tous.

     ‘port’ (par défaut : ‘#f’)
          Indique s’il faut écouter sur un port particulier, par défaut
          le 9418.

     ‘whitelist’ (par défaut : ‘'()’)
          Si la liste n’est pas vide, n’autoriser l’accès qu’aux
          dossiers spécifiés.

     ‘extra-options’ (par défaut : ‘'()’)
          Options supplémentaires qui seront passées à ‘git daemon’(2).

   Le protocole ‘git://’ ne permet pas l’authentification. Lorsque vous
récupérez un dépôt via ‘git://’, vous ne pouvez pas savoir si les
données que vous recevez ont été modifiées ou si elles viennent bien de
l’hôte spécifié, et votre connexion pourrait être espionnée. Il est
préférable d’utiliser un protocole de transport authentifié et chiffré,
comme ‘https’. Bien que Git vous permette de servir des dépôts avec un
serveur web peu sophistiqué basé sur les fichiers, il y a un protocole
plus rapide implémenté par le programme ‘git-http-backend’. Ce programme
est le moteur des services web Git corrects. Il est conçu pour se
trouver derrière un mandataire FastCGI. *Note Services web:: pour plus
d’informations sur la manière de lancer le démon ‘fcgiwrap’ nécessaire.

   Guix a un type de données de configuration séparé pour servir des
dépôts Git par HTTP.

 -- Type de données : git-http-configuration
     Type de données représentant la configuration d’un futur
     ‘git-http-service-type’ ; il peut actuellement être utilisé pour
     configurer Nginx à travers ‘git-http-nginx-location-configuration’.

     ‘package’ (par défaut : GIT)
          Objet de paquet du système de contrôle de version distribué
          Git.

     ‘git-root’ (par défaut : ‘/srv/git’)
          Répertoire contenant les dépôts Git à exposer au monde.

     ‘export-all?’ (par défaut : ‘#f’)
          Indique s’il faut exposer l’accès de tous les dépôts Git dans
          GIT-ROOT, même s’ils n’ont pas le fichier
          ‘git-daemon-export-ok’.

     ‘uri-path’ (par défaut : ‘/git/’)
          Préfixe du chemin pour l’accès Git. Avec le préfixe ‘/git/’
          par défaut, cela traduira ‘http://SERVER/git/REPO.git’ en
          ‘/srv/git/REPO.git’. Les requêtes dont les chemins d’URI ne
          commencent pas par ce préfixe ne seront pas passées à cette
          instance de Git.

     ‘fcgiwrap-socket’ (par défaut : ‘127.0.0.1:9000’)
          Le socket sur lequel le démon ‘fcgiwrap’ écoute. *Note
          Services web::.

   Il n’y a pas de ‘git-http-service-type’, actuellement ; à la place
vous pouvez créer un ‘nginx-location-configuration’ à partir d’un
‘git-http-configuration’ puis ajouter cela au serveur web.

 -- Procédure : git-http-nginx-location-configuration
          [config=(git-http-configuration)]
     Calcule un ‘nginx-location-configuration’ qui correspond à la
     configuration http Git donnée. Voici un exemple de définition de
     service nginx qui sert le répertoire ‘/srv/git’ par défaut en HTTPS
     :

          (service nginx-service-type
                   (nginx-configuration
                    (server-blocks
                     (list
                      (nginx-server-configuration
                       (listen '("443 ssl"))
                       (server-name "git.my-host.org")
                       (ssl-certificate
                        "/etc/certs/git.my-host.org/fullchain.pem")
                       (ssl-certificate-key
                        "/etc/certs/git.my-host.org/privkey.pem")
                       (locations
                        (list
                         (git-http-nginx-location-configuration
                          (git-http-configuration (uri-path "/"))))))))))

     Ce exemple suppose que vous utilisez Let’s Encrypt pour récupérer
     votre certificat TLS. *Note Services de certificats::. Le service
     ‘certbot’ par défaut redirigera tout le trafic HTTP de
     ‘git.my-host.org’ en HTTPS. Vous devrez aussi ajouter un mandataire
     ‘fcgiwrap’ à vos services systèmes. *Note Services web::.

Service Cgit
............

Cgit (https://git.zx2c4.com/cgit/) est une interface web pour des dépôts
Git écrite en C.

   L’exemple suivant configurera le service avec les valeurs par défaut.
Par défaut, on peut accéder à Cgit sur le port (‘http://localhost:80’).

     (service cgit-service-type)

   Le type ‘file-object’ désigne soit un objet simili-fichier (*note
file-like objects: G-Expressions.), soit une chaîne.

   Les champs de ‘cgit-configuration’ disponibles sont :

 -- paramètre de cgit-configuration : package package
     Le paquet cgit.

 -- paramètre de cgit-configuration : nginx-server-configuration-list
          nginx
     Configuration Nginx.

 -- paramètre de cgit-configuration : file-object about-filter
     Spécifie une commande qui doit être invoquée pour formater le
     contenu des pages « à propos » (au plus haut niveau et pour chaque
     dépôt).

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string agefile
     Spécifie un chemin, relativement à chaque dépôt, qui peut être
     utilisé pour spécifier la date et l’heure du plus récent commit du
     dépôt.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : file-object auth-filter
     Spécifie une commande qui sera invoquée pour authentifier l’accès
     au dépôt.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string branch-sort
     Drapeau qui, lorsqu’il vaut ‘age’, active le trie par date dans la
     liste des branches, et le trie par nom lorsqu’il vaut ‘name’.

     La valeur par défaut est ‘"name"’.

 -- paramètre de cgit-configuration : string cache-root
     Chemin utilisé pour stocker les entrées de cache de cgit.

     La valeur par défaut est ‘"/var/cache/cgit"’.

 -- paramètre de cgit-configuration : integer cache-static-ttl
     Nombre qui spécifie le temps de vie, en minute, des versions en
     cache des pages du dépôt accédées par leur SHA-1.

     La valeur par défaut est ‘-1’.

 -- paramètre de cgit-configuration : integer cache-dynamic-ttl
     Nombre qui spécifie le temps de vie, en minutes, des version en
     cache des pages du dépôt accédées sans leur SHA1.

     La valeur par défaut est ‘5’.

 -- paramètre de cgit-configuration : integer cache-repo-ttl
     Nombre qui spécifie le temps de vie, en minute, des version en
     cache de la page de résumé du dépôt.

     La valeur par défaut est ‘5’.

 -- paramètre de cgit-configuration : integer cache-root-ttl
     Nombre qui spécifie le temps de vie, en minutes, de la version en
     cache de la page d’index du dépôt.

     La valeur par défaut est ‘5’.

 -- paramètre de cgit-configuration : integer cache-scanrc-ttl
     Nombre qui spécifie le temps de vie, en minutes, de la version en
     cache du résultat du scan d’un chemin dans le dépôt Git.

     La valeur par défaut est ‘15’.

 -- paramètre de cgit-configuration : integer cache-about-ttl
     Nombre qui spécifie le temps de vie, en minutes, de la version en
     cache de la page « à propos » du dépôt.

     La valeur par défaut est ‘15’.

 -- paramètre de cgit-configuration : integer cache-snapshot-ttl
     Nombre qui spécifie le temps de vie, en minutes, de la version en
     cache des archives.

     La valeur par défaut est ‘5’.

 -- paramètre de cgit-configuration : integer cache-size
     Le nombre maximum d’entrées dans le cache de cgit. Lorsque la
     valeur est ‘0’, le cache est désactivé.

     La valeur par défaut est ‘0’.

 -- paramètre de cgit-configuration : boolean case-sensitive-sort?
     Indique si le tri des éléments est sensible à la casse.

     La valeur par défaut est ‘#t’.

 -- paramètre de cgit-configuration : list clone-prefix
     Liste des préfixes communs qui, lorsqu’ils sont combinés à l’URL du
     dépôt, génèrent des URL de clone valides pour le dépôt.

     La valeur par défaut est ‘'()’.

 -- paramètre de cgit-configuration : list clone-url
     Liste des modèles ‘clone-url’.

     La valeur par défaut est ‘'()’.

 -- paramètre de cgit-configuration : file-object commit-filter
     Commande qui sera invoquée pour formater les messages de commit.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string commit-sort
     Drapeau qui, s’il vaut ‘date’, active le tri par date strict dans
     le messages de commit, et le tri topologique strict lorsqu’il vaut
     ‘topo’.

     La valeur par défaut est ‘"git log"’.

 -- paramètre de cgit-configuration : file-object css
     URL qui spécifie le document css à inclure dans les pages cgit.

     La valeur par défaut est ‘"/share/cgit/cgit.css"’.

 -- paramètre de cgit-configuration : file-object email-filter
     Spécifie une commande qui sera invoquée pour formater les noms et
     l’adresse de courriel des commiteurs, des auteurs et des taggueurs,
     représentés à plusieurs endroits dans l’interface cgit.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : boolean embedded?
     Drapeau qui, s’il vaut ‘#t’, fera générer un fragment HTML à cgit
     qu’il sera possible d’inclure dans d’autres pages HTML.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-commit-graph?
     Drapeau qui, lorsqu’il vaut ‘#t’, fera afficher un historique en
     ASCII-art à gauche des messages de commit dans la page de log du
     dépôt.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-filter-overrides?
     Drapeau qui, lorsqu’il vaut ‘#t’, permet à tous les paramètres de
     filtrage d’être modifiés dans des fichiers cgitrc spécifiques au
     dépôt.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-follow-links?
     Drapeau qui, s’il vaut ‘#t’, permet aux utilisateurs de suivre un
     fichier dans la vue « log ».

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-http-clone?
     Si la valeur est ‘#t’, cgit agira comme un point d’accès HTTP idiot
     pour les clones Git.

     La valeur par défaut est ‘#t’.

 -- paramètre de cgit-configuration : boolean enable-index-links?
     Drapeau qui, s’il vaut ‘#t’, fera générer des liens « résumé », «
     commit » et « arborescence » supplémentaires poru chaque dépôt dans
     l’index des dépôts.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-index-owner?
     Drapeau qui, s’il vaut ‘#t’, fera afficher le propriétaire de
     chaque dépôt dans l’index des dépôts.

     La valeur par défaut est ‘#t’.

 -- paramètre de cgit-configuration : boolean enable-log-filecount?
     Drapeau qui, s’il vaut ‘#t’, fera afficher à cgit le nombre de
     fichiers modifiés pour chaque commit sur la page de log du dépôt.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-log-linecount?
     Drapeau qui, s’il vaut ‘#t’, fera afficher à cgit le nombre de
     lignes ajoutées et enlevées pour chaque commit de la page de log du
     dépôt.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-remote-branches?
     Drapeau qui, s’il vaut ‘#t’, fera afficher les branches distantes
     dans les vues du résumé et des références.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-subject-links?
     Drapeau qui, s’il vaut ‘1’, fera utiliser à cgit le sujet du commit
     parent comme texte du lien lors de la génération des liens vers les
     commits parents dans la vue des commits.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-html-serving?
     Drapeau qui, s’il vaut ‘#t’, fera utiliser à cgit l esujet du
     commit parent comme texte du lien lors de la génération des liens
     vers le commit parent dans la vue des commits.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean enable-tree-linenumbers?
     Drapeau qui, s’il vaut ‘#t’, fera générer à cgit des liens vers le
     numéro de ligne pour les blobs en texte brut affichés dans la vue
     de l’arborescence.

     La valeur par défaut est ‘#t’.

 -- paramètre de cgit-configuration : boolean enable-git-config?
     Drapeau qui, s’il vaut ‘#t’, permettra à cgit d’utiliser la
     configuration Git pour spécifier des paramètres spécifiques au
     dépôt.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : file-object favicon
     URL utilisée comme lien vers un icône pour cgit.

     La valeur par défaut est ‘"/favicon.ico"’.

 -- paramètre de cgit-configuration : string footer
     Le contenu du fichier spécifié avec cette option sera inclus
     directement au bas de toutes les pages (c.-à-d. qu’il remplace le
     message « généré par … » générique).

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string head-include
     Le contenu du fichier spécifié dans cette option sera inclus
     directement dans la section HEAD HTML de toutes les pages.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string header
     Le contenu du fichier spécifié avec cette option sera inclus
     directement au début de toutes les pages.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : file-object include
     Nom d’un fichier de configuration à inclure avant que le reste du
     fichier de configuration actuel ne soit analysé.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string index-header
     Le contenu du fichier spécifié avec cette option sera inclus
     directement au dessus de l’index des dépôts.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string index-info
     Le contenu du fichier spécifié avec cette option sera inclus
     directement en dessous de l’en-tête sur la page d’index du dépôt.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : boolean local-time?
     Drapeau qui, s’il vaut ‘#t’, fera afficher à cgit l’heure et la
     date de commit et de tag dans le fuseau horaire du serveur.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : file-object logo
     URL qui spécifie la source d’une image utilisé comme logo sur
     toutes les pages cgit.

     La valeur par défaut est ‘"/share/cgit/cgit.png"’.

 -- paramètre de cgit-configuration : string logo-link
     URL chargée lors du clic sur l’image du logo de cgit.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : file-object owner-filter
     Commande qui sera invoquée pour formater la colonne propriétaire
     sur la page principale.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : integer max-atom-items
     Nombre d’éléments à afficher dans la vue des flux atom.

     La valeur par défaut est ‘10’.

 -- paramètre de cgit-configuration : integer max-commit-count
     Nombre d’éléments à lister par page dans la vue « log ».

     La valeur par défaut est ‘50’.

 -- paramètre de cgit-configuration : integer max-message-length
     Nombre caractères de messages de commit à afficher dans la vue «
     log ».

     La valeur par défaut est ‘80’.

 -- paramètre de cgit-configuration : integer max-repo-count
     Spécifie le nombre d’éléments à lister par page sur la page de
     l’index des dépôts.

     La valeur par défaut est ‘50’.

 -- paramètre de cgit-configuration : integer max-repodesc-length
     Spécifie le nombre maximum de caractères de description de dépôts à
     afficher sur la page d’index des dépôts.

     La valeur par défaut est ‘80’.

 -- paramètre de cgit-configuration : integer max-blob-size
     Spécifie la taille maximale d’un blob pour lequel afficher du HTML
     en kilo-octets.

     La valeur par défaut est ‘0’.

 -- paramètre de cgit-configuration : string max-stats
     Période de statistiques maximale. Les valeurs valides sont ‘week’,
     ‘month’, ‘quarter’ et ‘year’.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : mimetype-alist mimetype
     Type mime pour l’extension de fichier spécifiée.

     La valeur par défaut est ‘'((gif "image/gif") (html "text/html")
     (jpg "image/jpeg") (jpeg "image/jpeg") (pdf "application/pdf") (png
     "image/png") (svg "image/svg+xml"))’.

 -- paramètre de cgit-configuration : file-object mimetype-file
     Spécifie le fichier à utiliser pour la recherche automatique de
     type mime.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string module-link
     Texte qui sera utilisé comme chaîne de formatage pour un lien
     hypertexte lorsqu’un sous-module est affiché dans la liste du
     répertoire.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : boolean nocache?
     Si la valeur est ‘#t’, le cache est désactivé.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean noplainemail?
     Si la valeur est ‘#t’, l’affichage des adresse de courriel des
     auteurs sera désactivé.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : boolean noheader?
     Drapeau qui, s’il vaut ‘#t’, fera omettre à cgit l’en-tête standard
     sur toutes les pages.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : project-list project-list
     UNe liste de sous-répertoires dans ‘repository-directory’,
     relativement à lui, qui devrait être chargé comme des dépôts Git.
     Une liste vide signifie que tous les sous-répertoires seront
     chargés.

     La valeur par défaut est ‘'()’.

 -- paramètre de cgit-configuration : file-object readme
     Text which will be used as default ‘repository-cgit-configuration’
     ‘readme’.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : boolean remove-suffix?
     Si la valeur est ‘#t’ et que ‘repository-directory’ est activé, si
     un dépôt avec un suffixe de ‘.git’ est trouvé, ce suffixe sera
     supprimé de l’URL et du nom.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : integer renamelimit
     Nombre maximum de fichiers à considérer lors de la détection des
     renommages.

     La valeur par défaut est ‘-1’.

 -- paramètre de cgit-configuration : string repository-sort
     La manière dont les dépôt de chaque section sont rangés.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : robots-list robots
     Texte utilisé comme contenu du méta-attribut ‘robots’.

     La valeur par défaut est ‘'("noindex" "nofollow")’.

 -- paramètre de cgit-configuration : string root-desc
     Texte affiché en dessous de l’en-tête de la page d’index des
     dépôts.

     La valeur par défaut est ‘"a fast webinterface for the git dscm"’.

 -- paramètre de cgit-configuration : string root-readme
     Le contenu du fichier spécifié avec cette option sera inclus
     directement en dessous du lien « à propos » sur la page d’index du
     dépôt.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string root-title
     Texte affiché sur la page d’index des dépôts.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : boolean scan-hidden-path
     Si la valeur est ‘#t’ et que repository-directory est activé,
     repository-directory recherchera de manière récursive dans les
     répertoires dont le nom commence par un point. Sinon,
     repository-directory restera hors de ces répertoires, considérés
     comme « cachés ». Remarquez que cela ne s’applique pas au
     répertoire « .git » dans le dépôts non bruts.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : list snapshots
     Texte qui spécifie l’ensemble des formats d’archives par défaut
     pour lesquelles cgit générera un lien.

     La valeur par défaut est ‘'()’.

 -- paramètre de cgit-configuration : repository-directory
          repository-directory
     Nom du répertoire à scanner pour trouver les dépôts (représente
     ‘scan-path’).

     La valeur par défaut est ‘"/srv/git"’.

 -- paramètre de cgit-configuration : string section
     Le nom de la section de dépôts actuelle — tous les dépôts définis
     après ce point hériterons du nom de section actuel.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string section-sort
     Drapeau qui, s’il vaut ‘1’, triera les sections dans la liste des
     dépôts par nom.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : integer section-from-path
     Un nombre qui, s’il est défini avant repository-directory,
     spécifier combien d’éléments de chemin de chaque chemin de dépôt
     utiliser comme nom de section par défaut.

     La valeur par défaut est ‘0’.

 -- paramètre de cgit-configuration : boolean side-by-side-diffs?
     Si la valeur est ‘#t’, afficher des diffs côte à côte au lieu des
     unidiffs par défaut.

     La valeur par défaut est ‘#f’.

 -- paramètre de cgit-configuration : file-object source-filter
     Spécifie une commande qui sera invoquée pour formater les blobs en
     texte brut dans la vue de l’arborescence.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : integer summary-branches
     Spécifie le nombre de branches à afficher dans la vue « résumé » du
     dépôt.

     La valeur par défaut est ‘10’.

 -- paramètre de cgit-configuration : integer summary-log
     Spécifie le nombre d’élément du journal à afficher dans la vue «
     résumé » du dépôt.

     La valeur par défaut est ‘10’.

 -- paramètre de cgit-configuration : integer summary-tags
     Spécifie le nombre de tags à afficher dans la vue « résumé » du
     dépôt.

     La valeur par défaut est ‘10’.

 -- paramètre de cgit-configuration : string strict-export
     Nom de fichier qui, s’il est spécifié, doit être présent dans le
     dépôt pour que cgit accorde l’accès à ce dépôt.

     La valeur par défaut est ‘""’.

 -- paramètre de cgit-configuration : string virtual-root
     URL qui, si elle est spécifiée, sera utilisée comme racine pour
     tous les liens cgit.

     La valeur par défaut est ‘"/"’.

 -- paramètre de cgit-configuration : repository-cgit-configuration-list
          repositories
     A list of ‘repository-cgit-configuration’ records.

     La valeur par défaut est ‘'()’.

     Les champs de ‘repository-cgit-configuration’ disponibles sont :

      -- paramètre de repository-cgit-configuration : repo-list
               snapshots
          Un masque de formats d’archives pour ce dépôt pour lesquelles
          cgit générera un lien, restreint par le paramètre ‘snapshots’
          global.

          La valeur par défaut est ‘'()’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               source-filter
          Modifie le ‘source-filter’ par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string url
          URL relative utilisée pour accéder au dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               about-filter
          Modifie le paramètre ‘about-filter’ par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               branch-sort
          Drapeau qui, s’il vaut ‘age’, active le tri par date dans la
          liste des branches, et lorsqu’il vaut ‘name’, le tri par nom.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-list
               clone-url
          Un liste d’URL qui peuvent être utilisées pour cloner ce
          dépôt.

          La valeur par défaut est ‘'()’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               commit-filter
          Modifie le paramètre ‘commit-filter’ par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               commit-sort
          Drapeau qui, s’il vaut ‘date’, active le tri par date strict
          dans le messages de commit, et le tri topologique strict
          lorsqu’il vaut ‘topo’.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               defbranch
          Le nom de la branche par défaut de ce dépôt. Si cette branche
          n’existe pas dans le dépôt, le premier nom de branche (trié)
          sera utilisé par défaut. Par défaut la branche pointée par
          HEAD, ou « master » s’il n’y a pas de HEAD convenable.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string desc
          La valeur à afficher comme description du dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               homepage
          La valeur à afficher comme page d’accueil du dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               email-filter
          Modifie le paramètre ‘email-filter’ par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-commit-graph?
          Un drapeau qui peut être utilisé pour désactiver le paramètre
          ‘enable-commit-graph?’ global.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-log-filecount?
          Un drapeau qui peut être utilisé pour désactiver le paramètre
          ‘enable-log-filecount?’ global.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-log-linecount?
          Un drapeau qui peut être utilisé pour désactiver le paramètre
          ‘enable-log-linecount?’ global.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-remote-branches?
          Drapeau qui, s’il vaut ‘#t’, fera afficher les branches
          distantes dans les vues du résumé et des références.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-subject-links?
          Un drapeau qui peut être utilisé pour modifier le paramètre
          ‘enable-subject-links?’ global.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration :
               peut-être-booléen-repo enable-html-serving?
          Un drapeau qui peut être utilisé pour modifier le paramètre
          ‘enable-html-serving?’ global.

          La valeur par défaut est ‘disabled’.

      -- paramètre de repository-cgit-configuration : repo-boolean hide?
          Drapeau qui, s’il vaut ‘#t’, cache le dépôt de l’index des
          dépôts.

          La valeur par défaut est ‘#f’.

      -- paramètre de repository-cgit-configuration : repo-boolean
               ignore?
          Drapeau qui, s’il vaut ‘#t’, ignore le dépôt.

          La valeur par défaut est ‘#f’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               logo
          URL qui spécifie la source d’une image qui sera utilisée comme
          logo sur les pages de ce dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               logo-link
          URL chargée lors du clic sur l’image du logo de cgit.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-file-object
               owner-filter
          Modifie le paramètre ‘owner-filter’ par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               module-link
          Texte qui sera utilisé comme chaîne de formatage pour un lien
          hypertexte lorsqu’un sous-module est affiché dans une liste de
          fichiers. Les arguments pour la chaîne de formatage sont le
          chemin et le SHA1 du commit du sous-module.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : module-link-path
               module-link-path
          Texte qui sera utilisé comme chaîne de formatage lorsqu’un
          sous-module avec un chemin spécifié sera affiché dans une
          liste de fichiers.

          La valeur par défaut est ‘'()’.

      -- paramètre de repository-cgit-configuration : repo-string
               max-stats
          Modifie la période de statistique maximale par défaut.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string name
          La valeur à afficher comme nom de dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string owner
          Une valeur utilisée pour identifier le propriétaire du dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string path
          Un chemin absolu vers le répertoire du dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string readme
          Un chemin (relatif au dépôt) qui spécifie un fichier à inclure
          directement comme page « À propos » pour ce dépôt.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-string
               section
          Le nom de la section de dépôts actuelle — tous les dépôts
          définis après ce point hériterons du nom de section actuel.

          La valeur par défaut est ‘""’.

      -- paramètre de repository-cgit-configuration : repo-list
               extra-options
          Options supplémentaires ajoutées à la fin du fichier cgitrc.

          La valeur par défaut est ‘'()’.

 -- paramètre de cgit-configuration : list extra-options
     Options supplémentaires ajoutées à la fin du fichier cgitrc.

     La valeur par défaut est ‘'()’.

   Cependant, vous pourriez vouloir simplement récupérer un ‘cgitrc’ et
l’utiliser. Dans ce cas, vous pouvez passer un
‘opaque-cgit-configuration’ comme enregistrement à ‘cgit-service-type’.
Comme son nom l’indique, une configuration opaque n’a pas de capacité de
réflexion facile.

   Les champs de ‘opaque-cgit-configuration’ disponibles sont :

 -- paramètre de opaque-cgit-configuration : package cgit
     Le paquet cgit.

 -- paramètre de opaque-cgit-configuration : string string
     Le contenu de ‘cgitrc’, en tant que chaîne de caractère.

   Par exemple, si votre ‘cgitrc’ est juste la chaîne vide, vous pouvez
instancier un service cgit ainsi :

     (service cgit-service-type
              (opaque-cgit-configuration
               (cgitrc "")))

Service Gitolite
................

Gitolite (https://gitolite.com/gitolite/) est un outil pour héberger des
dépôts Git sur un serveur central.

   Gitolite peut gérer plusieurs dépôts et utilisateurs et supporte une
configuration flexible des permissions pour les utilisateurs sur ces
dépôts.

   L’exemple suivant configure Gitolite en utilisant l’utilisateur ‘git’
par défaut et la clef SSH fournie.

     (service gitolite-service-type
              (gitolite-configuration
                (admin-pubkey (plain-file
                                "yourname.pub"
                                "ssh-rsa AAAA... guix@example.com"))))

   Gitolite est configuré via un dépôt d’administration spécial que vous
pouvez cloner. Par exemple, si vous hébergez Gitolite sur ‘example.com’,
vous pouvez lancer la commande suivante pour cloner le dépôt
d’administration.

     git clone git@example.com:gitolite-admin

   Lorsque le service Gitolite est activé, la clef ‘admin-pubkey’
fournie sera insérée dans le répertoire ‘keydir’ du dépôt
gitolite-admin. Si cela change le dépôt, un commit sera effectué avec le
message « gitolite setup by GNU Guix ».

 -- Type de données : gitolite-configuration
     Type de données représentant la configuration de
     ‘gitolite-service-type’.

     ‘package’ (default: ‘gitolite’)
          Le paquet Gitolite à utiliser. Il y a des dépendances
          facultatives à Gitolite qui ne sont pas incluses dans le
          paquet par défaut comme Redis et git-annex. Ces
          fonctionnalités peuvent devenir disponibles en utilisant la
          procédure ‘make-gitolite’ dans le module ‘(gnu packages
          version-control)’ pour produire une variante de Gitolite avec
          les dépendances supplémentaires souhaitées.

          Le code suivant renvoie un paquet dans lequel les programmes
          Redis et git-annex peuvent être invoqués par les scripts de
          Gitolite :

               (use-modules (gnu packages databases)
                            (gnu packages haskell-apps)
                            (gnu packages version-control))
               (make-gitolite (list redis git-annex))

     ‘user’ (default: ‘"git"’)
          Utilisateur pour utiliser Gitolite. Cela sera l’utilisateur à
          utiliser pour accéder à Gitolite par SSH.

     ‘group’ (default: ‘"git"’)
          Groupe à utiliser pour Gitolite.

     ‘home-directory’ (default: ‘"/var/lib/gitolite"’)
          Répertoire dans lequel stocker la configuration et les dépôts
          de Gitolite.

     ‘rc-file’ (default: ‘(gitolite-rc-file)’)
          Un objet « simili-fichier » (*note file-like objects:
          G-Expressions.) représentant la configuration de Gitolite.

     ‘git-config’ (default: ‘(gitolite-git-configuration)’)
          A “file-like” object (*note file-like objects:
          G-Expressions.), representing the git configuration for
          Gitolite.

     ‘admin-pubkey’
          Un objet « simili-fichier » (*note file-like objects:
          G-Expressions.) utilisé pour paramétrer Gitolite. Il sera
          inséré dans le répertoire ‘keydir’ dans le dépôt
          gitolite-admin.

          Pour spécifier la clef SSH comme chaîne de caractère, utilisez
          la fonction ‘plain-file’.

               (plain-file "yourname.pub" "ssh-rsa AAAA... guix@example.com")

          The file has to have ‘.pub’ extension.

     ‘admin-name’ (default: ‘#f’)
          Usually the key name is derived by taking a base name of the
          ‘admin-pubkey’. The resulting file name is the name of the
          gitolite user. You can use this field to override the
          automatic name.

 -- Type de données : gitolite-rc-file
     Type de données représentant le fichier RC de Gitolite.

     ‘umask’ (par défaut : ‘#o0077’)
          Cela contrôle les permissions que Gitolite propose sur les
          dépôts et leur contenu.

          Une valeur comme ‘#o0027’ donnera accès en lecture au groupe
          utilisé par Gitolite (par défaut : ‘git’). Cela est nécessaire
          lorsque vous utilise Gitolite avec un logiciel comme cgit ou
          gitweb.

     ‘local-code’ (par défaut : ‘"$rc{GL_ADMIN_BASE}/local"’)
          Vous permet d’ajouter vos propres programmes non essentiels,
          voire d’écraser les programmes fournis par défaut avec vos
          propres programmes.

          Fournissez le chemin COMPLET à cette variable. Par défaut, le
          répertoire appelé « local » dans votre clone gitolite est
          utilisé, ce qui permet de le versionner et de vous permettre
          de le modifier sans avoir à vous connecter au serveur.

     ‘unsafe-pattern’ (par défaut : ‘#f’)
          Une expression régulière en Perl qui correspond aux
          configurations non sures dans le fichier de configuration.
          Voir la documentation de Gitolite
          (https://gitolite.com/gitolite/git-config.html#compensating-for-unsafe_patt)
          pour plus d’informations.

          Lorsque la valeur n’est pas ‘#f’, elle devrait être une chaîne
          contenant une expression régulière en Perl, comme
          ‘"[`~#\$\&()|;<>]"’, qui est la valeur par défaut utilisée par
          gitolite. Elle rejette les caractères spéciaux dans la
          configuration qui pourraient être interprétés par un shell, ce
          qui est utile lorsque vous partagez la charge d’administration
          avec d’autres personnes qui n’ont pas accès à un shell sur le
          serveur.

     ‘git-config-keys’ (par défaut : ‘""’)
          Gitolite vous permet de modifier les configurations git avec
          le mot-clef ‘config’. Ce paramètre vous permet de contrôler
          les clefs de configuration acceptables.

     ‘log-extra’ (default: ‘#f’)
          Whether gitolite should log extra details.

          For historical reasons, this field defaults to ‘#f’. The
          default value from gitolite however is ‘1’ (written as ‘#t’ in
          this configuration).

     ‘host-name’ (par défaut : ‘#f’)
          The host name of this gitolite instance. It is used by the
          mirroring feature.

     ‘roles’ (par défaut : ‘'(("READERS" . 1) ("WRITERS" . ))’)
          Indique les noms des rôles qui peuvent être utilisés par les
          utilisateurs avec la commande perms.

     ‘enable’ (par défaut : ‘'("help" "desc" "info" "perms" "writable" "ssh-authkeys" "git-config" "daemon" "gitweb")’)
          Ce paramètre contrôle les commandes et les fonctionnalités à
          activer dans Gitolite.

     ‘extra-content’ (par défaut : ‘""’)
          Extra content to add verbatim into the ‘%RC’ hash.

 -- Data Type : gitolite-git-configuration
     Data type representing the git configuration file for gitolite.

     ‘name’ (default: ‘"GNU GNU"’)
          User name used for commits (e.g. during setting up the admin
          repository).

     ‘email’ (default: ‘"guix@localhost"’)
          Email used for commits (e.g. during setting up the admin
          repository).

     ‘default-branch’ (default: ‘#f’)
          If true, set the ‘init.defaultBranch’ option to that value.
          Common values are ‘"master"’ and ‘"main"’.

     ‘receive-fsck-objects’ (default: ‘#f’)
          If it is set to true, git-receive-pack will check all received
          objects.

     ‘extra-content’ (par défaut : ‘""’)
          Extra content to add verbatim into the git configuration file.

Service Gitile
..............

Gitile (https://git.lepiller.eu/gitile) est une forge Git qui permet de
visualiser le contenu de dépôts Git dans votre navigateur web.

   Gitile fonctionne mieux en tandem avec Gitolite, et servira les
dépôts publics de Gitolite par défaut. Le service devrait écouter
uniquement sur un port local, et vous devriez configurer un serveur web
pour servir les ressources statiques. Le service gitile fournit une
manière pratique d’étendre le service Nginx pour cela (*note NGINX::).

   L’exemple suivant configurera Gitile pour servir les dépôts d’un
emplacement personnalisé, avec quelques messages par défaut pour la page
d’accueil et les pieds de page.

     (service gitile-service-type
              (gitile-configuration
                (repositories "/srv/git")
                (base-git-url "https://myweb.site/git")
                (index-title "My git repositories")
                (intro '((p "This is all my public work!")))
                (footer '((p "This is the end")))
                (nginx
                  (nginx-server-configuration
                    (ssl-certificate
                      "/etc/certs/myweb.site/fullchain.pem")
                    (ssl-certificate-key
                      "/etc/certs/myweb.site/privkey.pem")
                    (listen '("443 ssl http2" "[::]:443 ssl http2"))
                    (locations
                      (list
                        ;; Allow for https anonymous fetch on /git/ urls.
                        (git-http-nginx-location-configuration
                          (git-http-configuration
                            (uri-path "/git/")
                            (git-root "/var/lib/gitolite/repositories")))))))))

   En plus de l’enregistrement de configuration, vous devriez configurer
vos dépôts git pour contenir certaines informations facultatives. Tout
d’abord, vos dépôts publics doivent contenir le fichier magique
‘git-daemon-export-ok’ qui permet à Git d’exporter le dépôt. Gitile
utiliser la présence de ce fichier pour détecter les dépôts publics
qu’il doit rendre accessibles. Pour cela, avec Gitolite par exemple,
modifiez votre ‘conf/gitolite.conf’ pour inclure ceci dans les dépôts
que vous voulez rendre publics :

     repo toto
         R = daemon

   En plus, Gitile peut lire la configuration du dépôt pour afficher des
informations supplémentaires sur les page du dépôt. Gitile utilise
l’espace de nom gitweb pour sa configuration. Par exemple, vous pouvez
utiliser cela dans votre ‘conf/gitolite.conf’ :

     repo toto
         R = daemon
         desc = Une description longue, éventuellement avec du <i>HTML</i>, qui se trouvera sur la page d'accueil
         config gitweb.name = Le projet Toto
         config gitweb.synopsis = Une description courte, affichée sur la page principale du projet

   N’oubliez pas de commiter et de pousser les changement quand vous
êtes satisfait. Vous pourrez avoir besoin de changer la configuration de
gitolite pour permettre aux options précédentes d’être acceptées. Une
manière de faire est d’ajouter la définition de service suivante :

     (service gitolite-service-type
               (gitolite-configuration
                 (admin-pubkey (local-file "key.pub"))
                 (rc-file
                   (gitolite-rc-file
                     (umask #o0027)
                     ;; Permet d'indique n'importe quelle clé de configuration
                     (git-config-keys ".*")
                     ;; Admet n'importe quel texte comme valeur de configuration valide
                     (unsafe-patt "^$")))))

 -- Type de données : gitile-configuration
     Type de données représentant la configuration de
     ‘gitile-service-type’.

     ‘package’ (par défaut : GITILE)
          Le paquet Gitile à utiliser.

     ‘host’ (par défaut : ‘"localhost"’)
          L’hôte sur lequel gitile écoute.

     ‘port’ (par défaut : ‘8080’)
          Le port sur lequel gitile écoute.

     ‘database’ (par défaut : ‘"/var/lib/gitile/gitile-db.sql"’)
          L’emplacement de la base de données.

     ‘repositories’ (par défaut : ‘"/var/lib/gitolite/repositories"’)
          L’emplacement des dépôts. Notez que seuls les dépôts publics
          seront affichés par Gitile. Pour rendre un dépôt public,
          ajouter un fichier vide ‘git-daemon-export-ok’ à la racine de
          ce dépôt.

     ‘git-owner-validation?’ (default: ‘#t’)
          Whether to check for the service user’s ownership of
          repositories. By default, Git will refuse to process a
          repository owned by another user.

     ‘base-git-url’
          L’URL git de base qui sera utilisée pour afficher les
          commandes de clonage.

     ‘index-title’ (par défaut : ‘"Index"’)
          La titre de la page pour la page d’index qui répertorie tous
          les dépôts disponibles.

     ‘intro’ (par défaut : ‘'()’)
          Le contenu de l’introduction, sous la forme d’une liste
          d’expressions sxml. C’est ce qui est affiché au-dessus de la
          liste des dépôts, sur la page d’index.

     ‘footer’ (par défaut : ‘'()’)
          Le contenu du pied-de-page, sous la forme d’une liste
          d’expressions sxml. Il apparaît sur chaque page servie par
          Gitile.

     ‘nginx’
          Un bloc de serveur nginx qui sera étendu et utilisé comme
          serveur mandataire inverse par Gitile pour servir ses pages,
          et comme serveur web normal pour servir ses ressources
          statiques.

          Vous pouvez utiliser ce bloc pour ajouter d’autres URLs
          personnalisées à votre domaine, comme une URL ‘/git/’ pour les
          clonages anonymes, ou pour servir tout autre fichier que vous
          voudriez servir.

   ---------- Footnotes ----------

   (1) En créant le fichier magique ‘git-daemon-export-ok’ dans le
répertoire du dépôt.

   (2) Lancez ‘man git-daemon’ pour plus d’informations.


File: guix.fr.info,  Node: Services de jeu,  Next: Service PAM de montage,  Prev: Services de contrôle de version,  Up: Services

11.10.33 Services de jeu
------------------------

Services Joycond
................

Le service joycond permet d’appairer des contrôleurs Nintendo joycon par
Bluetooth (*note Services de bureaux:: pour paramétrer le Bluetooth).

 -- Type de données : joycond-configuration
     Type de données représentant la configuration de ‘joycond’.

     ‘package’ (par défaut : ‘joycond’)
          Le paquet joycond à utiliser.

 -- Variable : joycond-service-type
     Service type for the joycond service. It also extends the
     ‘udev-service-type’ with the ‘joycond’ package (provided via the
     ‘joycond-configuration’ configuration), so that joycond controllers
     can be detected and used by an unprivileged user.

Le service de la Bataille pour Wesnoth
......................................

La Bataille pour Wesnoth (https://wesnoth.org) est un jeu de stratégie
en tour par tour dans un univers fantastique, avec plusieurs campagnes
solo et des parties multijoueurs (en réseau et en local).

 -- Variable : wesnothd-service-type
     Type de service pour le service wesnothd. Sa valeur doit être un
     objet ‘wesnothd-configuration’. Pour lancer wesnothd avec la
     configuration par défaut, instanciez-le ainsi :

          (service wesnothd-service-type)

 -- Type de données : wesnothd-configuration
     Type de donées représentant la configuration de ‘wesnothd’.

     ‘package’ (par défaut : ‘wesnoth-server’)
          Le paquet de serveur de wesnoth à utiliser.

     ‘port’ (par défaut : ‘15000’)
          Le pour sur lequel lier le serveur.


File: guix.fr.info,  Node: Service PAM de montage,  Next: Services Guix,  Prev: Services de jeu,  Up: Services

11.10.34 Service PAM de montage
-------------------------------

Le module ‘(gnu services pam-mount)’ fournit un service qui permet de
monter des volumes à la connexion de l’utilisateur·rice. Il peut monter
n’importe quel format de volume pris en charge par le système.

 -- Variable : pam-mount-service-type
     Type de service pour la prise en charge de PAM Mount.

 -- Type de données : pam-mount-configuration
     Type de données représentant la configuration de PAM Mount.

     Il prend les paramètres suivants :

     ‘rules’
          Les règles de configuration utilisées pour générer
          ‘/etc/security/pam_mount.conf.xml’.

          Les règles de configuration sont des éléments SXML (*note
          (guile)SXML::), et les valeurs par défaut ne montent rien pour
          personne à la connexion :

               `((debug (@ (enable "0")))
                 (mntoptions (@ (allow ,(string-join
                                         '("nosuid" "nodev" "loop"
                                           "encryption" "fsck" "nonempty"
                                           "allow_root" "allow_other")
                                         ","))))
                 (mntoptions (@ (require "nosuid,nodev")))
                 (logout (@ (wait "0")
                            (hup "0")
                            (term "no")
                            (kill "no")))
                 (mkmountpoint (@ (enable "1")
                                  (remove "true"))))

          Certains éléments de ‘volume’ doivent être ajoutés pour
          automatiquement monter des volumes à la connexion. voici un
          exemple qui permet à l’utilisatrice ‘alice’ de monter son
          répertoire ‘HOME’ chiffré et permet à l’utilisateur ‘bob’ de
          monter la partition où il stocke ses données :

               (define pam-mount-rules
               `((debug (@ (enable "0")))
                           (volume (@ (user "alice")
                                      (fstype "crypt")
                                      (path "/dev/sda2")
                                      (mountpoint "/home/alice")))
                           (volume (@ (user "bob")
                                      (fstype "auto")
                                      (path "/dev/sdb3")
                                      (mountpoint "/home/bob/data")
                                      (options "defaults,autodefrag,compress")))
                           (mntoptions (@ (allow ,(string-join
                                                   '("nosuid" "nodev" "loop"
                                                     "encryption" "fsck" "nonempty"
                                                     "allow_root" "allow_other")
                                                   ","))))
                           (mntoptions (@ (require "nosuid,nodev")))
                           (logout (@ (wait "0")
                                      (hup "0")
                                      (term "no")
                                      (kill "no")))
                           (mkmountpoint (@ (enable "1")
                                            (remove "true")))))

               (service pam-mount-service-type
                        (pam-mount-configuration
                          (rules pam-mount-rules)))

          La liste complète des options disponibles se trouve sur la
          page de manuel de pam_mount.conf
          (http://pam-mount.sourceforge.net/pam_mount.conf.5.html).

PAM Mount Volume Service
------------------------

PAM mount volumes are automatically mounted at login by the PAM login
service according to a set of per-volume rules. Because they are mounted
by PAM the password entered during login may be used directly to mount
authenticated volumes, such as ‘cifs’, using the same credentials.

   These volumes will be added in addition to any volumes directly
specified in ‘pam-mount-rules’.

   Here is an example of a rule which will mount a remote CIFS share
from ‘//remote-server/share’ into a sub-directory of ‘/shares’ named
after the user logging in:

     (simple-service 'pam-mount-remote-share pam-mount-volume-service-type
                     (list (pam-mount-volume
                            (secondary-group "users")
                            (file-system-type "cifs")
                            (server "remote-server")
                            (file-name "share")
                            (mount-point "/shares/%(USER)")
                            (options "nosuid,nodev,seal,cifsacl"))))

 -- Data Type : pam-mount-volume-service-type
     Configuration for a single volume to be mounted. Any fields not
     specified will be omitted from the run-time PAM configuration. See
     the man page
     (http://pam-mount.sourceforge.net/pam_mount.conf.5.html) for the
     default values when unspecified.

     ‘user-name’ (type: maybe-string)
          Mount the volume for the given user.

     ‘user-id’ (type: maybe-integer-or-range)
          Mount the volume for the user with this ID. This field may
          also be specified as a pair of ‘(start . end)’ indicating a
          range of user IDs for whom to mount the volume.

     ‘primary-group’ (type: maybe-string)
          Mount the volume for users with this primary group name.

     ‘group-id’ (type: maybe-integer-or-range)
          Mount the volume for the users with this primary group ID.
          This field may also be specified as a cons cell of ‘(start .
          end)’ indicating a range of group ids for whom to mount the
          volume.

     ‘secondary-group’ (type: maybe-string)
          Mount the volume for users who are members of this group as
          either a primary or secondary group.

     ‘file-system-type’ (type: maybe-string)
          The file system type for the volume being mounted (e.g.,
          ‘cifs’)

     ‘no-mount-as-root?’ (type: maybe-boolean)
          Whether or not to mount the volume with root privileges. This
          is normally disabled, but may be enabled for mounts of type
          ‘fuse’, or other user-level mounts.

     ‘server’ (type: maybe-string)
          The name of the remote server to mount the volume from, when
          necessary.

     ‘file-name’ (type: maybe-string)
          The location of the volume, either local or remote, depending
          on the ‘file-system-type’.

     ‘mount-point’ (type: maybe-string)
          Where to mount the volume in the local file-system. This may
          be set to ‘~’ to indicate the home directory of the user
          logging in. If this field is omitted then ‘/etc/fstab’ is
          consulted for the mount destination.

     ‘options’ (type: maybe-string)
          The options to be passed as-is to the underlying mount
          program.

     ‘ssh?’ (type: maybe-boolean)
          Enable this option to pass the login password to SSH for use
          with mounts involving SSH (e.g., ‘sshfs’).

     ‘cipher’ (type: maybe-string)
          Cryptsetup cipher name for the volume. To be used with the
          ‘crypt’ ‘file-system-type’.

     ‘file-system-key-cipher’ (type: maybe-string)
          Cipher name used by the target volume.

     ‘file-system-key-hash’ (type: maybe-string)
          SSL hash name used by the target volume.

     ‘file-system-key-file-name’ (type: maybe-string)
          File name of the file system key for the target volume.


File: guix.fr.info,  Node: Services Guix,  Next: Services Linux,  Prev: Service PAM de montage,  Up: Services

11.10.35 Services Guix
----------------------

Shared Cache Service
....................

Running ‘guix pull’, ‘guix time-machine’, ‘guix system reconfigure’, and
‘guix home reconfigure’ pulls the complete Git version control history
of your channels in ‘$HOME/.cache/guix/checkouts’. If you have multiple
user accounts (typically ‘root’ and a main user account for your
personal computer), or if multiple users are using the system (typically
on a shared server), then this can quickly waste a lot of space.

   The ‘shared-cache’ service lets you prevent this waste by either
sharing or exposing a specific user’s cache to the other users.

   In the context of this service, _sharing_ and _exposing_ have the
same meaning as with ‘guix shell’: making the shared cache directory
read-only if you use mode ‘'expose’ (the default), and writable if you
use mode ‘'share’, (*note ‘--expose’ and ‘--share’: Invoquer guix
shell.).

   Whatever mode you choose, from the point of view of the user, the
cache appears writable. With ‘'expose’, any write will be stored in a
user-owned overlay directory next to mountpoint, whereas with ‘'share’,
writes will be propagated back to the sharing user’s cache.

     Attention : Use the ‘'share’ option _if and only if_ users on the
     machine trust each other. This is a hard requirement since, with
     this option, any user could “poison” the shared cache to indirectly
     gain access to other user’s data and privileges.

     Attention : Using ‘'share’ is meant for a single-seat computer
     where the single user has unprivileged user accounts—e.g. one for
     work and one for gaming. Even then, channels from one will leak
     into the other’s cache. Use with caution.

     Attention : ‘'share’ will not work for multiple concurrent
     invocation of ‘guix’, e.g. if two user accounts run ‘guix time
     machine’ at the same time, the results will be fun but not useful.

   Here is an example configuration that exposes ‘root’’s guix checkout
cache to ‘alice’ and ‘bob’:

     (operating-system
       ;; ...
          (services
           (cons*
            (service shared-cache-service-type
                  (shared-cache-configuration
                    (users (list (user-cache (user "alice"))
                                 (user-cache (user "bob"))))))
                         %desktop-services)))

   The service can also be extended by providing a list of ‘user-cache’,
allowing for easier splitting of configuration.

     (operating-system
       ;; ...
       (services
        (cons*
         (simple-service 'bob-shared-guix-cache shared-cache-service-type
                         (list (user-cache (user "bob"))))
         %desktop-services)))

 -- Variable : shared-cache-service-type
     Service type for sharing a subdirectory of ‘~/.cache/’ between
     multiple users.

     This service allows different system users to share the contents of
     the user cache, avoiding duplication and saving disk space. It can
     be configured in either “share” mode, where all users write to the
     same cache, or “expose” mode, where users get a read-only view with
     a writable overlay. Its value must be a
     ‘shared-cache-configuration’ object.

 -- Data Type : shared-cache-configuration
     Data type representing the configuration of the shared cache.

     ‘mode’ (default: ‘'expose’)
          Either ‘'share’ (read-write, dangerous) or ‘'expose’
          (read-only with per-user overlay, the default). In share mode,
          all writes go to the shared directory. In expose mode, only
          reads use the shared directory; writes go to a user-owned
          overlay.

     ‘shared-directory’ (default: ‘"/root/.cache"’)
          The source cache directory that is shared between users. Each
          user will see some or all of its subdirectories mounted into
          their own ‘~/.cache’.

     ‘users’ (default: ‘'()’)
          The list of users that will benefit from the shared directory.
          This must be a list of ‘user-info’ records.

 -- Data Type : user-info
     Data type representing the configuration for a single user
     benefitting from a shared cache.

     ‘user’
          The username of the user.

     ‘location’ (default: ‘"/home/USER/.cache"’)
          The cache directory of the user.

     ‘group’ (default: ‘"users"’)
          The primary group of the user.

     ‘directories’ (default: ‘'("guix/checkouts")’)
          List of subdirectories of the ‘shared-cache-configuration’’s
          ‘shared-directory’ (whose default is ‘/root/.cache’) to mount
          under LOCATION (whose default is ‘~/.cache/’) for the user.

Build Farm Front-End (BFFE)
...........................

The Build Farm Front-End (https://git.cbaines.net/guix/bffe/) assists
with building Guix packages in bulk. It’s responsible for submitting
builds and displaying the status of the build farm.

 -- Variable : bffe-service-type
     Service type for the Build Farm Front-End. Its value must be a
     ‘bffe-configuration’ object.

 -- Data Type : bffe-configuration
     Data type representing the configuration of the Build Farm
     Front-End.

     ‘package’ (default: ‘bffe’)
          The Build Farm Front-End package to use.

     ‘user’ (default: ‘"bffe"’)
          L’utilisateur qui lance le service.

     ‘group’ (default: ‘"bffe"’)
          Le groupe système qui lance le service.

     ‘arguments’
          A list of arguments to the Build Farm Front-End. These are
          passed to the ‘run-bffe-service’ procedure when starting the
          service.

          For example, the following value directs the Build Farm
          Front-End to submit builds for derivations available from
          ‘data.guix.gnu.org’ to the Build Coordinator instance assumed
          to be running on the same machine.

               (list
                #:build
                (list
                 (build-from-guix-data-service
                  (data-service-url "https://data.guix.gnu.org")
                  (build-coordinator-url "http://127.0.0.1:8746")
                  (branches '("master"))
                  (systems '("x86_64-linux" "i686-linux"))
                  (systems-and-targets
                   (map (lambda (target)
                          (cons "x86_64-linux" target))
                        '("aarch64-linux-gnu"
                          "i586-pc-gnu")))))
                #:web-server-args
                '(#:event-source "https://example.com"
                  #:controller-args
                  (#:title "example.com build farm")))

     ‘extra-environment-variables’ (par défaut : ’())
          Extra environment variables to set via the shepherd service.

Guix Build Coordinator
......................

Le Guix Build Coordinator
(https://git.cbaines.net/guix/build-coordinator/) aide à distribuer la
construction de dérivations entre machines sur lesquelles tourne un
“agent”. Le démon de construction est toujours utilisé pour construire
les dérivations, mais Guix Build Coordinator gère l’allocation des
construction et des résultats.

   Le coordinateur des constructions Guix consiste en un “coordinateur”,
et un ou plus processus “agents” connectés. Le coordinateur gère les
clients qui soumettent des constructions, et alloue les constructions
aux agents. Les processus agents parlent au démon de construction pour
effectuer les constructions, puis envoie les résultats au coordinateur.

   Il y a un script pour lancer le composant du coordinateur de Guix
Build Coordinator, mais le service Guix utilise un script Guile
personnalisé à la place, pour fournir une meilleure intégration avec les
G-expressions utilisées dans la configuration.

 -- Variable : guix-build-coordinator-service-type
     Le type de service pour Guix Build Coordinator. Sa valeur doit être
     un ‘guix-build-coordinator-configuration’.

 -- Type de données : guix-build-coordinator-configuration
     Le type de données représentant la configuration de Guix Build
     Coordinator.

     ‘package’ (par défaut : ‘guix-build-coordinator’)
          Le paquet Guix Build Coordinator à utiliser.

     ‘user’ (par défaut : ‘"guix-build-coordinator"’)
          L’utilisateur qui lance le service.

     ‘group’ (par défaut : ‘"guix-build-coordinator"’)
          Le groupe système qui lance le service.

     ‘database-uri-string’ (par défaut : ‘"sqlite:///var/lib/guix-build-coordinator/guix_build_coordinator.db"’)
          L’URI à utiliser pour la base de données.

     ‘agent-communication-uri’ (par défaut : ‘"http://0.0.0.0:8745"’)
          L’URI décrivant comment écouter les requêtes des processus
          agents.

     ‘client-communication-uri’ (par défaut : ‘"http://127.0.0.1:8746"’)
          L’URI décrivant comme écouter les requêtes des clients. L’API
          cliente permet de soumettre des constructions et n’est pas
          actuellement authentifiée, donc faites attention lors de la
          configuration de cette valeur.

     ‘allocation-strategy’ (par défaut : ‘#~basic-build-allocation-strategy’)
          Une G-expression pour la stratégie d’allocation à utiliser.
          C’est une procédure qui prend le stockage de données en
          argument et rempli le plan d’allocation dans la base de
          données.

     ‘hooks’ (par défaut : ’())
          Une liste d’association de crochets. Ils fournissent une
          manière d’exécuter du code arbitraire en fonction
          d’évènements, comme le traitement des résultats des
          constructions.

     ‘parallel-hooks’ (par défaut : ’())
          Les crochets peuvent être configurés pour être lancés en
          parallèle. Ce paramètre est une liste d’association de
          crochets à lancer en parallèle, où la clé est le symbole pour
          le crochet et la valeur est le nombre de threads à lancer.

     ‘listen-repl’ (default: #F)
          Port or filename to spawn a REPL listening on, pass ‘#t’ to
          listen on the default port or ‘#f’ to disable.

     ‘guile’ (par défaut : ‘guile-3.0-latest’)
          Le paquet Guile à utiliser pour lancer Guix Build Coordinator.

     ‘extra-environment-variables’ (par défaut : ’())
          Extra environment variables to set via the shepherd service.

 -- Variable : guix-build-coordinator-agent-service-type
     Le type de service pour un agent Guix Build Coordinator. Sa valeur
     doit être un ‘guix-build-coordinator-agent-configuration’.

 -- Type de données : guix-build-coordinator-agent-configuration
     Type de données représentant la configuration d’un agent Guix Build
     Coordinator.

     ‘package’ (par défaut : ‘guix-build-coordinator/agent-only’)
          Le paquet Guix Build Coordinator à utiliser.

     ‘user’ (par défaut : ‘"guix-build-coordinator-agent"’)
          L’utilisateur qui lance le service.

     ‘coordinator’ (par défaut : ‘"http://localhost:8745"’)
          L’URI à utiliser lors de la connexion au coordinateur.

     ‘authentification’
          Enregistrement décrivant comme cet agent devrait
          s’authentifier avec le coordinateur. Les types
          d’enregistrement possibles sont décrit plus bas.

     ‘systems’ (par défaut : ‘#f’)
          Les systèmes pour lesquels cet agent devrait récupérer les
          constructions. Le processus de l’agent utilisera le système
          actuel comme valeur par défaut.

     ‘max-parallel-builds’ (default: ‘#f’)
          Le nombre de constructions qui peuvent tourner simultanément.

     ‘max-parallel-uploads’ (default: ‘#f’)
          The number of uploads to perform in parallel.

     ‘max-allocated-builds’ (par défaut : ‘#f’)
          Le nombre maximum de constructions que cette agent peut
          allouer.

     ‘max-1min-load-average’ (par défaut : ‘#f’)
          Valeur moyenne de charge à vérifier avant de commencer de
          nouvelles construction. Si la valeur moyenne à une minute
          dépasse cette valeur, l’agent attendra avant de commencer de
          nouvelles constructions.

          Cela sera non spécifié si la valeur est ‘#f’, et l’agent
          utilisera le nombre de cœurs rapportés par le système comme la
          moyenne de charge à 1 minute maximale.

     ‘derivation-substitute-urls’ (par défaut : ‘#f’)
          URL à partir desquelles essayer de récupérer les substituts
          pour les dérivations, si les dérivation ne sont pas déjà
          disponibles.

     ‘non-derivation-substitute-urls’ (par défaut : ‘#f’)
          URL à partir desquelles essayer de chercher les substituts
          pour les entrées des constructions, si les éléments du dépôt
          des entrées ne sont pas déjà disponibles.

     ‘extra-options’ (par défaut : ’())
          Extra command line options for ‘guix-build-coordinator-agent’.

 -- Type de données : guix-build-coordinator-agent-password-auth
     Type de données représentant un moyen d’authentification avec un
     coordinateur pour les agents, via un UUID et un mot de passe.

     ‘uuid’
          L’UUID de l’agent. Il devrait être généré par le processus du
          coordinateur, stocké dans la base du coordinateur et utilisé
          par l’agent prévu.

     ‘password’
          Le mot de passe à utiliser lors de la connexion au
          coordinateur.

 -- Type de données : guix-build-coordinator-agent-password-file-auth
     Type de données représentant un moyen d’authentification avec un
     coordinateur via un UUID et un mot de passe lu depuis un fichier.

     ‘uuid’
          L’UUID de l’agent. Il devrait être généré par le processus du
          coordinateur, stocké dans la base du coordinateur et utilisé
          par l’agent prévu.

     ‘password-file’
          Un fichier contenant le mot de passe à utiliser pour la
          connexion avec le coordinateur.

 -- Type de données : guix-build-coordinator-agent-dynamic-auth
     Type de données représentant un moyen d’authentification à un
     coordinateur via un jeton d’authentification dynamique et le nom de
     l’agent.

     ‘agent-name’
          Nom d’un agent, c’est utilisé pour le faire correspondre à une
          entrée existante dans la base de données s’il existe.
          Lorsqu’aucune entrée n’est trouvée, une nouvelle entrée est
          ajoutée automatiquement.

     ‘token’
          Jeton d’authentification dynamique, créé et stocké dans la
          base de données du coordinateur, et utilisé par l’agent pour
          s’authentifier.

 -- Type de données :
          guix-build-coordinator-agent-dynamic-auth-with-file
     Type de données représentant une méthode d’authentification à un
     coordinateur via un jeton d’authentification dynamique lu depuis un
     fichier et un nom d’agent.

     ‘agent-name’
          Nom d’un agent, c’est utilisé pour le faire correspondre à une
          entrée existante dans la base de données s’il existe.
          Lorsqu’aucune entrée n’est trouvée, une nouvelle entrée est
          ajoutée automatiquement.

     ‘token-file’
          Fichier contenant le jeton d’authentification dynamique, créé
          et stocké dans la base de données du coordinateur, et utilisé
          par l’agent pour s’authentifier.

Guix Data Service
.................

Le Guix Data Service (http://data.guix.gnu.org) traite, stocke et
fournit des données à propos de GNU Guix. Cela comprend des informations
sur les paquets, les dérivations et les messages d’avertissement de
formatage.

   Les données sont stockées dans une base PostgreSQL, et sont
disponibles à travers une interface web.

 -- Variable : guix-data-service-type
     Le type de service pour le Guix Data Service. Sa valeur doit être
     un objet ‘guix-data-service-configuration’. Le service étend
     éventuellement le service getmail, car la liste de diffusion
     guix-commits est utilisée pour récupérer les changement dans le
     dépôt git de Guix.

 -- Type de données : guix-data-service-configuration
     Le type de données représentant la configuration du Guix Data
     Service.

     ‘package’ (par défaut : ‘guix-data-service’)
          Le paquet Guix Data Service à utiliser.

     ‘user’ (par défaut : ‘"guix-data-service"’)
          L’utilisateur qui lance le service.

     ‘group’ (par défaut : ‘"guix-data-service"’)
          Le groupe système qui lance le service.

     ‘port’ (par défaut : ‘8765’)
          Le port sur lequel lier le service web.

     ‘host’ (par défaut : ‘"127.0.0.1"’)
          L’hôte sur lequel lier le service web.

     ‘getmail-idle-mailboxes’ (par défaut : ‘#f’)
          Si une valeur est indiquée, c’est la liste des boites de
          courriel que le service getmail récupère.

     ‘commits-getmail-retriever-configuration’ (par défaut : ‘#f’)
          Si la valeur est indiquée, c’est l’objet
          ‘getmail-retriever-configuration’ avec lequel configurer
          getmail pour récupérer les courriels à part de la liste de
          diffusion guix-commits.

     ‘extra-options’ (par défaut : ’())
          Liste d’options supplémentaires de la ligne de commande pour
          ‘guix-data-service’.

     ‘extra-process-jobs-options’ (par défaut : ’())
          Liste d’options supplémentaires de la ligne de commande pour
          ‘guix-data-service-process-jobs’.

     ‘git-repositories’ (default: #F)
          List of git-repository information to insert into the
          database.

     ‘build-servers’ (default: #F)
          List of build-server information to insert into the database.

Guix Home Service
.................

The Guix Home service is a way to let Guix System deploy the home
environment of one or more users (*note Configuration du dossier
personnel::, for more on Guix Home). That way, the system configuration
embeds declarations of the home environment of those users and can be
used to deploy everything consistently at once, saving users the need to
run ‘guix home reconfigure’ independently.

   ‘guix home’ can operate on the home environment configured for
current user via this service, but its effect won’t last beyond the next
system activation. This can be used for quick testing and may avoid the
need of keeping a separate home configuration.

 -- Variable : guix-home-service-type
     Service type for the Guix Home service. Its value must be a list of
     lists containing user and home environment pairs. The key of each
     pair is a string representing the user to deploy the configuration
     under and the value is a home-environment configuration.

          (use-modules (gnu services guix))

          (define my-home
            (home-environment
              ...))

          (operating-system
            (services (append (list (service guix-home-service-type
                                             `(("alice" ,my-home))))
                              %base-services)))

     This service can be extended by other services to add additional
     home environments, as in this example:

          (simple-service 'my-extra-home guix-home-service-type
                          `(("bob" ,my-extra-home)))

Nar Herder
..........

Nar Herder (https://git.cbaines.net/guix/nar-herder/about/) est un
utilitaire pour gérer une collection de nars.

 -- Variable : nar-herder-type
     Le type de service pour le Guix Data Service. Sa valeur doit être
     un objet ‘nar-herder-configuration’. Le service étend
     éventuellement le service getmail, car la liste de diffusion
     guix-commits est utilisée pour récupérer les changement dans le
     dépôt git de Guix.

 -- Type de données : nar-herder-configuration
     Le type de données représentant la configuration du Guix Data
     Service.

     ‘package’ (par défaut : ‘nar-herder’)
          Le paquet Nar Herder à utiliser.

     ‘user’ (par défaut : ‘"nar-herder"’)
          L’utilisateur qui lance le service.

     ‘group’ (par défaut : ‘"nar-herder"’)
          Le groupe système qui lance le service.

     ‘port’ (par défaut : ‘8734’)
          Le pour sur lequel lier le serveur.

     ‘host’ (par défaut : ‘"127.0.0.1"’)
          L’hôte sur lequel lier le serveur.

     ‘control-port’ (default: ‘8734’)
          The port to bind the control server to.

     ‘control-host’ (default: ‘"127.0.0.1"’)
          The host to bind the control server to.

     ‘mirror’ (par défaut : ‘#f’)
          URL facultative de l’autre instance de Nar Herder qui doit
          être répliquée. Cela signifie que cette instance de Nar Herder
          téléchargera sa base de données et la gardera à jour.

     ‘database’ (par défaut : ‘"/var/lib/nar-herder/nar_herder.db"’)
          Emplacement de la base de données. Si cette instance de Nar
          Herder en réplique une autre, la base de données sera
          téléchargée si elle n’existe pas. Si cette instance de Nar
          Herder n’en réplique pas une autre, une base de données vide
          sera créée.

     ‘database-dump’ (par défaut : ‘"/var/lib/nar-herder/nar_herder_dump.db"’)
          Emplacement de la décharge de la base de données. Elle est
          crée et régulièrement mise à jour en prenant une copie de la
          base de données. C’est la version de la base de données qui
          est disponible au téléchargement.

     ‘storage’ (par défaut : ‘#f’)
          Emplacement facultatif dans lequel stocker les nars.

     ‘storage-limit’ (par défaut : ‘"none"’)
          Limite en octets pour les nars stockés dans l’emplacement de
          stockage. Cela peut valoir « none » pour qu’il n’y ait pas de
          limite.

          Lorsque l’emplacement de stockage dépasse cette taille, les
          nars sont supprimés en fonction des critères de suppression
          des nars.

     ‘storage-nar-removal-criteria’ (par défaut : ‘'()’)
          Critères utilisés pour supprimer les nars de l’emplacement de
          stockage. Ils sont utilisés en plus de la limite de stockage.

          Lorsque l’emplacement de stockage dépasse la limite de taille,
          les nars passeront aux critères de suppression et ceux qui
          correspondent aux critères seront supprimés. Cela continue
          jusqu’à ce que l’emplacement de stockage repasse en dessous de
          la limite de taille.

          Chaque critère est spécifié par une chaine, puis un signe
          égal, puis une autre chaine. Actuellement, seul un critère est
          pris en charge, vérifier si un nar est stocké sur une autre
          instance de Nar Herder.

     ‘ttl’ (par défaut : ‘#f’)
          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 ou de l’utilisatrice de
          garder les informations de substituts en cache pendant TTL.

     ‘new-ttl’ (default: ‘#f’)
          If specified, this will override the ‘ttl’ setting when used
          for the ‘Cache-Control’ headers, but this value will be used
          when scheduling the removal of nars.

          Use this setting when the TTL is being reduced to avoid
          removing nars while clients still have cached narinfos.

     ‘negative-ttl’ (par défaut : ‘#f’)
          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é.

     ‘log-level’ (par défaut : ‘'DEBUG’)
          Niveau de journalisation à utiliser, spécifie un niveau de
          journalisation comme ‘'INFO’ pour arrêter de journaliser les
          requêtes individuelles.

     ‘cached-compressions’ (default: ‘'()’)
          Activate generating cached nars with different compression
          details from the stored nars. This is a list of
          nar-herder-cached-compression-configuration records.

     ‘min-uses’ (default: ‘3’)
          When cached-compressions are enabled, generate cached nars
          when at least this number of requests are made for a nar.

     ‘workers’ (default: ‘2’)
          Number of cached nars to generate at a time.

     ‘nar-source’ (default: ‘#f’)
          Location to fetch nars from when computing cached
          compressions. By default, the storage location will be used.

     ‘extra-environment-variables’ (par défaut : ‘'()’)
          Extra environment variables to set via the shepherd service.

 -- Data Type : nar-herder-cached-compression-configuration
     Data type representing the cached compression configuration.

     ‘type’
          Type of compression to use, e.g. ‘'zstd’.

     ‘workers’ (par défaut : ‘#f’)
          Level of the compression to use.

     ‘directory’ (default: ‘#f’)
          Location to store the cached nars. If unspecified, they will
          be stored in /var/cache/nar-herder/nar/TYPE.

     ‘directory-max-size’ (default: ‘#f’)
          Maximum size in bytes of the directory.

     ‘unused-removal-duration’ (default: ‘#f’)
          If a cached nar isn’t used for ‘unused-removal-duration’, it
          will be scheduled for removal.

          UNUSED-REMOVAL-DURATION must denote a duration: ‘5d’ means 5
          days, ‘1m’ means 1 month, and so on.

     ‘ttl’ (par défaut : ‘#f’)
          If specified this overrides the ‘ttl’ used for narinfos when
          this cached compression is available.

     ‘new-ttl’ (default: ‘#f’)
          As with the ‘new-ttl’ option for ‘nar-herder-configuration’,
          this value will override the ‘ttl’ when used for narinfo
          requests.


File: guix.fr.info,  Node: Services Linux,  Next: Services Hurd,  Prev: Services Guix,  Up: Services

11.10.36 Services Linux
-----------------------

VFS Mapping Service
...................

The VFS (Virtual File System) Mapping service allows you to bind a file
name under a different name in the global namespace. For example, this
is used by the Shared Cache Service (*note Services Guix::) to bind the
‘root’ user’s cache over another user’s cache. Another use case may be
to expose game data from the store over your home directory, and apply
modifications there.

   The service has three _policies_ to choose from with respect to
access rights on the bound over path:

‘'bind’
     Use a bind mount; the ownership and file permissions of the
     destination are the same as the source.

‘'translate’
     Use bindfs to make the destination appear as owned by the target
     user and group. Writes will be propagated back to the source as if
     made by the original owner.

‘'overlay’
     Use an overlay to make the destination appear as owned by the
     target user and group. Writes will not appear in the source, but
     will be stored in a target-user-owned ‘-overlay’ suffixed directory
     near the destination.

   Here is an example configuration that exposes the default data
directory of ‘tuxpaint’ under the home directory of ‘alice’. Any
modification made by Alice to the brushes or stamps will not propagate
back to the store (which is read-only anyway).

     (operating-system
       ;; ...
       (services
        (cons*
         (service vfs-mapping-service-type
                  (vfs-mapping-configuration
                   (bindings (list (vfs-mapping
                                    (source      #~(string-append #$tuxpaint
                                                                  "/share/tuxpaint"))
                                    (destination "/home/alice/.tuxpaint")
                                    (user        "alice")
                                    (policy      'overlay)
                                    (name        "alice-tuxpaint-overlay"))))))
         %desktop-services)))

   The service can also be extended by providing a list of
‘vfs-mapping’, allowing for easier splitting of configuration.

     (operating-system
       ;; ...
       (services
        (cons*
         (simple-service 'bob-too-wants-to-hack-on-tuxpaint
                         vfs-mapping-service-type
                         (list (vfs-mapping
                                (source      #~(string-append #$tuxpaint "/share/tuxpaint"))
                                (destination "/home/bob/.tuxpaint")
                                (user        "bob")
                                (policy      'overlay)
                                (name        "bob-tuxpaint-overlay"))))
         %desktop-services)))

   The ‘source’ file name must exist for the service to start. The
‘destination’ directory will be created if it does not exist.

 -- Variable : vfs-mapping-service-type
     Service type for binding a directory in multiple places on the file
     system.

     The access rights are either the same in source and destination
     (‘'bind’), or writes are translated back to the source as if made
     by the source’s owner (‘'translate’), or kept in an overlay
     directory near the destination (‘'overlay’). The service’s value
     must be a ‘vfs-mapping-configuration’ object.

 -- Data Type : vfs-mapping-configuration
     Data type representing the configuration of the vfs-mapping
     service.

     ‘bindfs’ (default: ‘#~(string-append #$bindfs "/bin/bindfs")’)
          The ‘bindfs’ command to use for mounting.

     ‘fusermount’ (default: ‘#~(string-append #$fuse-2 "/bin/fusermount")’)
          The ‘fusermount’ command to use.

     ‘umount’ (default: ‘#~(string-append #$util-linux+udev "/bin/umount")’)
          The ‘umount’ command to use.

     ‘bindings’ (default: ‘'()’)
          A list of ‘vfs-mapping’ records.

 -- Data Type : vfs-mapping
     Data type representing the configuration for a single shared
     directory.

     ‘source’
          The source file name to be shared.

     ‘destination’
          The destination at which the contents of ‘source’ will be
          exposed.

     ‘policy’ (default: ‘'translate’)
          Either ‘'bind’ (same ownership and access rights for ‘source’
          and ‘destination’), ‘'translate’ (read-write, with writes
          translated as if made by ‘source’’s owner), or ‘'overlay’
          (read-only with ‘user’-owned writable overlay).

     ‘user’ (default: ‘#f’)
          The user that will own the ‘destination’ directory, and appear
          to own its content. It must be kept at its default ‘#f’ value
          when using the ‘'bind’ policy.

     ‘group’ (default: ‘"users"’)
          The group that will own the ‘destination’ directory, and
          appear to own its content.

     ‘name’ (default: ‘"<src>-[<policy>]-><dst>"’)
          The name of the shepherd service to mount and unmount the
          binding.

     ‘requirement’ (default: ‘'(file-systems user-homes)’)
          The list of services that Shepherd ought to provision before
          trying to mount.

Service Early OOM
.................

Early OOM (https://github.com/rfjakob/earlyoom), aussi appelé Earlyoom,
est un démon de gestion du remplissage mémoire (OOM) minimaliste qui se
lance en espace utilisateur et fournit une alternative plus rapide et
configurable que le gestionnaire du noyau. Il est utile pour éviter que
le système ne cesse de répondre lorsqu’il n’a plus de mémoire.

 -- Variable : earlyoom-service-type
     Le type de service pour le service ‘earlyoom’, le démon Early OOM.
     Sa valeur doit être un objet ‘earlyoom-configuration’, décrit plus
     bas. Vous pouvez instancier le service avec sa configuration par
     défaut avec :

          (service earlyoom-service-type)

 -- Type de données : earlyoom-configuration
     La configuration pour ‘earlyoom-service-type’.

     ‘earlyoom’ (par défaut : EARLYOOM)
          Le paquet Earlyoom à utiliser.

     ‘minimum-available-memory’ (par défaut : ‘10’)
          La limite de mémoire _disponible_ minimum, en pourcentage.

     ‘minimum-free-swap’ (par défaut : ‘10’)
          La limite d’espace d’échange libre minimum, en pourcentage.

     ‘prefer-regexp’ (par défaut : ‘#f’)
          Une expression régulière (une chaine) qui correspond aux noms
          des processus à tuer en priorité.

     ‘avoid-regexp’ (par défaut : ‘#f’)
          Une expression régulière (une chaine) des noms des processus
          qui ne doivent _pas_ être tués.

     ‘memory-report-interval’ (par défaut : ‘0’)
          L’intervalle en seconde d’affichage du rapport mémoire. Il est
          désactivé par défaut.

     ‘ignore-positive-oom-score-adj?’ (par défaut : ‘#f’)
          Un booléen indiquant si les ajustements positifs indiqués dans
          ‘/proc/*/oom_score_adj’ doivent être ignorés.

     ‘show-debug-messages?’ (par défaut : ‘#f’)
          Un booléen indiquant si les messages de débogages doivent être
          affichés. Les journaux sont sauvegardés dans
          ‘/var/log/earlyoom.log’.

     ‘send-notification-command’ (par défaut : ‘#f’)
          On peut utiliser cette option pour fournir une commande
          personnalisée pour envoyer les notifications.

fstrim Service
..............

The command ‘fstrim’ can be used to discard (or “trim”) unused blocks on
a mounted file system.

     Attention : Running ‘fstrim’ frequently, or even using ‘mount -o
     discard’, might negatively affect the lifetime of poor-quality SSD
     devices. For most desktop and server systems a sufficient trimming
     frequency is once a week. Note that not all devices support a
     queued trim, so each trim command incurs a performance penalty on
     whatever else might be trying to use the disk at the time.

 -- Variable : fstrim-service-type
     Type for a service that periodically runs ‘fstrim’, whose value
     must be an ‘<fstrim-configuration>’ object. The service can be
     instantiated in its default configuration with:

          (service fstrim-service-type)

 -- Data Type : fstrim-configuration
     Available ‘fstrim-configuration’ fields are:

     ‘package’ (default: ‘util-linux’) (type: file-like)
          The package providing the ‘fstrim’ command.

     ‘schedule’ (default: ‘"0 0 * * 0"’) (type: Shepherd calendar event)
          Schedule for launching ‘fstrim’, expressed as a string in
          traditional cron syntax or as a gexp evaluating to a Shepherd
          calendar event (*note (shepherd)Timers::). By default this is
          set to run weekly on Sunday at 00:00.

     ‘listed-in’ (default: ‘'("/etc/fstab" "/proc/self/mountinfo")’) (type: maybe-list-of-strings)
          List of files in fstab or kernel mountinfo format. All missing
          or empty files are silently ignored. The evaluation of the
          list _stops_ after the first non-empty file. File systems with
          ‘X-fstrim.notrim’ mount option in fstab are skipped.

     ‘verbose?’ (default: ‘#t’) (type: boolean)
          Verbose execution.

     ‘quiet-unsupported?’ (default: ‘#t’) (type: boolean)
          Suppress error messages if trim operation (ioctl) is
          unsupported.

     ‘extra-arguments’ (type: maybe-list-of-strings)
          Extra options to append to ‘fstrim’ (run ‘man fstrim’ for more
          information).

Service de chargement de modules du noyau
.........................................

Le service de chargement de modules du noyau vous permet de charger des
modules du noyau au démarrage. C’est particulièrement utile pour les
modules qui ne sont pas chargés automatiquement et qui doivent être
chargés manuellement, comme c’est le cas avec ‘ddcci’.

 -- Variable : kernel-module-loader-service-type
     Le type de service pour charger des modules du noyau au démarrage
     avec ‘modprobe’. Sa valeur doit être une liste de chaines de
     caractères représentant les noms des modules. Par exemple pour
     charger les pilotes fournis par ‘ddcci-driver-linux’, en mode
     débogage en passant certains paramètres au module, on peut faire :

          (use-modules (gnu) (gnu services))
          (use-package-modules linux)
          (use-service-modules linux)

          (define ddcci-config
            (plain-file "ddcci.conf"
                        "options ddcci dyndbg delay=120"))

          (operating-system
            ...
            (services (cons* (service kernel-module-loader-service-type
                                      '("ddcci" "ddcci_backlight"))
                             (simple-service 'ddcci-config etc-service-type
                                             (list `("modprobe.d/ddcci.conf"
                                                     ,ddcci-config)))
                             %base-services))
            (kernel-loadable-modules (list ddcci-driver-linux)))

Cachefilesd Service
...................

The Cachefilesd service starts a daemon that caches network file system
data locally. It is especially useful for NFS and AFS shares, where it
reduces latencies for repeated access when reading files.

   The daemon can be configured as follows:

     (service cachefilesd-service-type
              (cachefilesd-configuration
                (cache-directory "/var/cache/fscache")))

 -- Variable : cachefilesd-service-type
     The service type for starting ‘cachefilesd’. The value for this
     service type is a ‘cachefilesd-configuration’, whose only required
     field is CACHE-DIRECTORY.

 -- Data Type : cachefilesd-configuration
     Available ‘cachefilesd-configuration’ fields are:

     ‘cachefilesd’ (default: ‘cachefilesd’) (type: file-like)
          The cachefilesd package to use.

     ‘debug-output?’ (default: ‘#f’) (type: boolean)
          Print debugging output to stderr.

     ‘use-syslog?’ (default: ‘#t’) (type: boolean)
          Log to syslog facility instead of stdout.

     ‘scan?’ (default: ‘#t’) (type: boolean)
          Scan for cacheable objects.

     ‘cache-directory’ (type: maybe-string)
          Location of the cache directory.

     ‘cache-name’ (default: ‘"CacheFiles"’) (type: maybe-string)
          Name of cache (keep unique).

     ‘security-context’ (type: maybe-string)
          SELinux security context.

     ‘pause-culling-for-block-percentage’ (default: ‘7’) (type: maybe-non-negative-integer)
          Pause culling when available blocks exceed this percentage.

     ‘pause-culling-for-file-percentage’ (default: ‘7’) (type: maybe-non-negative-integer)
          Pause culling when available files exceed this percentage.

     ‘resume-culling-for-block-percentage’ (default: ‘5’) (type: maybe-non-negative-integer)
          Start culling when available blocks drop below this
          percentage.

     ‘resume-culling-for-file-percentage’ (default: ‘5’) (type: maybe-non-negative-integer)
          Start culling when available files drop below this percentage.

     ‘pause-caching-for-block-percentage’ (default: ‘1’) (type: maybe-non-negative-integer)
          Pause further allocations when available blocks drop below
          this percentage.

     ‘pause-caching-for-file-percentage’ (default: ‘1’) (type: maybe-non-negative-integer)
          Pause further allocations when available files drop below this
          percentage.

     ‘log2-table-size’ (default: ‘12’) (type: maybe-non-negative-integer)
          Size of tables holding cullable objects in logarithm of base
          2.

     ‘cull?’ (default: ‘#t’) (type: boolean)
          Create free space by culling (consumes system load).

     ‘trace-function-entry-in-kernel-module?’ (default: ‘#f’) (type: boolean)
          Trace function entry in the kernel module (for debugging).

     ‘trace-function-exit-in-kernel-module?’ (default: ‘#f’) (type: boolean)
          Trace function exit in the kernel module (for debugging).

     ‘trace-internal-checkpoints-in-kernel-module?’ (default: ‘#f’) (type: boolean)
          Trace internal checkpoints in the kernel module (for
          debugging).

Service Rasdaemon
.................

Le service Rasdaemon fournit un démon qui surveille les rapports RAS
(Reliability, Availability, and Serviceability) de la plateforme dans
les événements de trace du noyau Linux, et les envoie à syslogd.

   La fiabilité, la disponibilité et la serviabilité est un concept
utilisé sur les serveur conçu pour mesurer leur robustesse.

   La *fiabilité* est la probabilité pour qu’un système produise les
résultats attendus :

   • Généralement mesuré en temps moyen entre échecs (Mean Time Between
     Failures, MTBF) et
   • Amélioré par les fonctionnalités qui aident à éviter, à détecter et
     à réparer les fautes matérielles

   La *disponibilité* est la probabilité pour qu’un système soit
opérationnel à un moment donné :

   • Généralement mesuré en pourcentage de temps d’arrêt par période de
     temps et
   • Utilise souvent des mécanismes de détection et de correction des
     fautes matérielles à l’exécution.

   La *serviabilité* est la simplicité et la rapidité avec laquelle un
système peut être réparé ou maintenu :

   • Généralement mesuré en temps moyen entre réparations (Mean Time
     Between Repair, MTBR).

   Entre autres mesures de surveillance, les plus courantes sont :

   • Le CPU — détecte les erreurs d’exécution d’instructions et au
     niveau des caches L1/L2/L3 ;
   • La mémoire — ajoute des codes correcteurs d’erreur (error
     correction codes, ECC) et corrige les erreurs ;
   • Les entrées-sorties — ajoute des sommes de contrôles CRC pour les
     données transférées ;
   • Le stockage — RAID, systèmes de fichiers journalisés, sommes de
     contrôle, SMART (Self-Monitoring, Analysis and Reporting
     Technology).

   En surveillant le nombre de détection d’erreurs, il est possible
d’identifier si la probabilité d’erreurs matérielles augmente, et dans
ce cas, d’effectuer une maintenance préventive pour remplacecr un
composant dégradé tant que les erreurs peuvent être corrigées.

   Pour des informations détaillées sur les types d’événements d’erreur
récupérés et comment les comprendre, voir le guide de l’administrateur
du noyau sur
<https://www.kernel.org/doc/html/latest/admin-guide/ras.html>.

 -- Variable : rasdaemon-service-type
     Le type de service pour le service ‘rasdaemon’. Il accepte un objet
     ‘rasdaemon-configuration’. Instantiez-le avec

          (service rasdaemon-service-type)

     chargera une configuration par défaut, qui surveille tous les
     événements et les enregistre avec syslogd.

 -- Type de données : rasdaemon-configuration
     Type de données représentant la configuration de ‘rasdaemon’.

     ‘record?’ (par défaut : ‘#f’)

          Un booléen indiquant s’il faut enregistrer les événements dans
          une base de données SQLite. Cela donne un accès plus structuré
          aux informations contenues dans le fichier journal.
          L’emplacement de la base de données est codée en dur :
          ‘/var/lib/rasdaemon/ras-mc_event.db’.

Service Zram
............

Le service de périphérique Zram fournit un périphérique de swap
compressé en mémoire système. La documentation du noyau Linux a plus
d’information à propos de ces périphériques zram
(https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html).

 -- Variable : zram-device-service-type
     Ce service crée un périphérique de bloc zram, le formate en swap et
     active l’espace d’échange. La valeur du service est un
     enregistrement ‘zram-device-configuration’.

      -- Type de données : zram-device-configuration
          C’est le type de données représentant la configuration du
          service zram-device.

          ‘size’ (par défaut : ‘"1G"’)
               C’est l’espace que vous voulez fournir à votre
               périphérique zram. Il accepte une chaine et peut être un
               nombre d’octets ou utiliser un suffixe, p. ex. : ‘"512M"’
               ou ‘"1024000"’.
          ‘compression-algorithm’ (par défaut : ‘'lzo’)
               C’est l’algorithme de compression à utiliser. Il est
               difficile de lister toutes les possibilités, mais les
               options habituelles prises en charge par le noyau Linux
               Libre de Guix sont ‘'lzo’, ‘'lz4’ et ‘'zstd’.
          ‘memory-limit’ (par défaut : ‘0’)
               C’est la quantité de mémoire maximal que le périphérique
               zram peut utiliser. le mettre à « 0 » désactive la
               limite. Bien qu’il soit généralement accepté que la
               compression aura un ratio de 2 pour 1, il est possible
               que des données non-comprimables soient écrites en espace
               d’échange et c’est une méthode pour limiter la quantité
               de mémoire qui peut être utilisée. Le paramètre accepte
               une chaine qui peut être un nombre d’octets ou utiliser
               un suffixe, p. ex. ‘"2G"’.
          ‘priority’ (par défaut : ‘#f’)
               C’est la priorité du périphérique d’échange créé à partir
               du périphérique zram. *Note Espace d'échange:: pour une
               description des priorités des espaces d’échange. Vous
               voudrez peut-être indiquer une priorité spécifique pour
               le périphérique zram, sinon il pourrait ne pas être
               utilisé du tout pour les raisons qui y sont décrites.


File: guix.fr.info,  Node: Services Hurd,  Next: Services divers,  Prev: Services Linux,  Up: Services

11.10.37 Services Hurd
----------------------

 -- Variable : hurd-console-service-type
     Ce service démarre le client ‘VGA’ sophistiqué en console sur le
     Hurd.

     La valeur du service est un enregistrement
     ‘hurd-console-configuration’.

 -- Type de données : hurd-console-configuration
     C’est le type de données représentant la configuration de
     hurd-console-service.

     ‘hurd’ (par défaut : HURD)
          Le paquet Hurd à utiliser.

 -- Variable : hurd-getty-service-type
     Ce service démarre un tty avec le programme ‘getty’.

     La valeur du service est un enregistrement
     ‘hurd-getty-configuration’.

 -- Type de données : hurd-getty-configuration
     Ce type de données représente la configuration de
     hurd-getty-service.

     ‘hurd’ (par défaut : HURD)
          Le paquet Hurd à utiliser.

     ‘tty’
          Le nom de la console sur laquelle tourne ce Getty, p. ex.
          ‘"tty1"’.

     ‘baud-rate’ (par défaut : ‘38400’)
          Un entier spécifiant le taux de Baud de ce tty.


File: guix.fr.info,  Node: Services divers,  Prev: Services Hurd,  Up: Services

11.10.38 Services divers
------------------------

Service d’empreintes digitales
..............................

Le module ‘(gnu services authentication)’ fournit un service DBus pour
lire et identifier les empreintes digitales via un lecteur d’empreinte.

 -- Variable : fprintd-service-type
     Le type de service pour ‘fprintd’, qui fournit des capacités de
     lecture d’empreinte.

          (service fprintd-service-type)

Service de contrôle du système
..............................

Le module ‘(gnu services sysctl)’ fournit un service pour configurer les
paramètres du noyau au démarrage.

 -- Variable : sysctl-service-type
     Le type de service pour ‘sysctl’, qui modifie les paramètres du
     noyau dans ‘/proc/sys/’. Pour activer le transfert d’IPv4, vous
     pouvez l’instancier ainsi :

          (service sysctl-service-type
                   (sysctl-configuration
                     (settings '(("net.ipv4.ip_forward" . "1")))))

     Comme le service ‘sysctl-service-type’ fait partie des services par
     défaut, ‘%base-services’ et ‘%desktop-services’, vous pouvez
     utiliser ‘modify-services’ pour changer sa configuration et ajouter
     les paramètres du noyau que vous voulez (*note ‘modify-services’:
     Référence de service.).

          (modify-services %base-services
            (sysctl-service-type config =>
                                 (sysctl-configuration
                                   (settings (append '(("net.ipv4.ip_forward" . "1"))
                                                     %default-sysctl-settings)))))

 -- Type de données : sysctl-configuration
     Le type de données représentant la configuration de ‘sysctl’.

     ‘sysctl’ (par défaut : ‘(file-append procps "/sbin/sysctl"’)
          L’exécutable ‘sysctl’ à utiliser.

     ‘settings’ (par défaut : ‘%default-sysctl-settings’)
          Une liste d’association spécifiant les paramètres du noyau et
          leur valeur.

 -- Variable : %default-sysctl-settings
     Une liste d’association spécifiant les paramètres ‘sysctl’ par
     défaut sur le système Guix.

Service du démon PC/SC Smart Card
.................................

Le module ‘(gnu services security-token)’ fournit le service suivant qui
lance ‘pcscd’, le démon PC/SC Smart Card. ‘pcscd’ est le démon pour
pcsc-lite et MuscleCard. C’est un gestionnaire de ressource qui
coordonne les communications avec les lecteurs de smart cards, les smart
cards et les jetons cryptographiques connectés au système.

 -- Variable : pcscd-service-type
     Le type de service pour le service ‘pcscd’. Sa valeur doit être un
     objet ‘pcscd-configuration’. Pour lancer pcscd dans sa
     configuration par défaut, instantiez-le avec :

          (service pcscd-service-type)

 -- Type de données : pcscd-configuration
     Type de données représentant la configuration de ‘pcscd’.

     ‘pcsc-lite’ (par défaut : ‘pcsc-lite’)
          Le paquet pcsc-lite qui fournit pcscd.
     ‘usb-drivers’ (par défaut : ‘(list ccid)’)
          Liste des paquets qui fournissent des pilotes USB à pcscd. Les
          pilotes doivent être dans ‘pcsc/drivers’ dans le répertoire du
          dépôt du paquet.

LIRC Service
............

Le module ‘(gnu services lirc)’ fournit le service suivant.

 -- Variable : lirc-service-type
     Type for a service that runs LIRC (http://www.lirc.org), a daemon
     that decodes infrared signals from remote controls.

     The value for this service is a ‘<lirc-configuration>’ object.

 -- Data Type : lirc-configuration
     Data type representing the configuration of ‘lircd’.

     ‘lirc’ (default: ‘lirc’) (type: file-like)
          Package object for ‘lirc’.

     ‘device’ (default: ‘#f’) (type: string)
     ‘driver’ (default: ‘#f’) (type: string)
     ‘config-file’ (default: ‘#f’) (type: string-or-file-like)
          TODO. See ‘lircd’ manual for details.

     ‘extra-options’ (default: ‘'()’) (type: list-of-string)
          Additional command-line options to pass to ‘lircd’.

SPICE Service
.............

Le module ‘(gnu services spice)’ fournit le service suivant.

 -- Variable : spice-vdagent-service-type
     Type of the service that runs VDAGENT
     (https://www.spice-space.org), a daemon that enables sharing the
     clipboard with a vm and setting the guest display resolution when
     the graphical console window resizes.

 -- Data Type : spice-vdagent-configuration
     Data type representing the configuration of
     ‘spice-vdagent-service-type’.

     ‘spice-vdagent’ (default: ‘spice-vdagent’) (type: file-like)
          Package object for VDAGENT.

service inputattach
...................

Le service inputattach (https://linuxwacom.github.io/) vous permet
d’utiliser des périphériques d’entrée comme les tablettes Wacom, les
écrans tactiles ou les joysticks avec le serveur d’affichage Xorg.

 -- Variable : inputattach-service-type
     Type d’un service qui lance ‘inputattach’ sur un appareil et envie
     les événements qu’il reçoit.

 -- Type de données : inputattach-configuration
     ‘device-type’ (par défaut : ‘"wacom"’)
          Le type du périphérique à gérer. Lancez ‘inputattach --help’,
          du paquet ‘inputattach’, pour voir la liste des types de
          périphériques supportés.

     ‘device’ (par défaut : ‘"/dev/ttyS0"’)
          Le fichier de périphérique pour s’y connecter.

     ‘baud-rate’ (par défaut : ‘#f’)
          Taux de Baud à utiliser pour la connexion série. Cela doit
          être un nombre ou ‘#f’.

     ‘log-file’ (par défaut : ‘#f’)
          Si la valeur est vraie, cela doit être le nom d’un fichier où
          enregistrer les messages.

Service de dictionnaire
.......................

Le module ‘(gnu services dict)’ fournit le service suivant :

 -- Variable : dicod-service-type
     C’est le type de service qui lance le démon ‘dicod’, une
     implémentation du serveur DICT (*note (dico)Dicod::).

     Vous pouvez ajouter ‘open localhost’ à votre fichier ‘~/.dico’ pour
     faire de ‘localhost’ le serveur par défaut du client ‘dico’ (*note
     (dico)Initialization File::).

          Remarque : This service is also available for Guix Home, where
          it runs directly with your user privileges (*note
          ‘home-dicod-service-type’: Miscellaneous Home Services.).

 -- Type de données : dicod-configuration
     Type de données représentant la configuration de dicod.

     ‘dico’ (par défaut : DICO)
          Objet de paquet du serveur de dictionnaire GNU Dico.

     ‘interfaces’ (par défaut : ’("LOCALHOST"))
          C’est la liste des adresses IP et des ports et éventuellement
          des noms de fichiers de socket sur lesquels écouter (*note
          ‘listen’ directive: (dico)Server Settings.).

     ‘handlers’ (par défaut : ’())
          Liste des objets ‘<dicod-handler>’ qui définissent des
          gestionnaires (des instances de modules).

     ‘databases’ (par défaut : (LIST %DICOD-DATABASE:GCIDE))
          Liste d’objets ‘<dicod-database>’ qui définissent des
          dictionnaires à servir.

 -- Type de données : dicod-handler
     Type de données représentant un gestionnaire de dictionnaire
     (instance de module).

     ‘name’
          Nom du gestionnaire (instance de module).

     ‘module’ (par défaut : #F)
          Nom du module dicod du gestionnaire (instance). Si la valeur
          est ‘#f’, le module a le même nom que le gestionnaire. (*note
          (dico)Modules::).

     ‘options’
          Liste de chaînes ou de gexps représentant les arguments pour
          le gestionnaire de module

 -- Type de données : dicod-database
     Type de données représentant une base de données de dictionnaire.

     ‘name’
          Nom de la base de données, qui sera utilisée dans les commande
          DICT.

     ‘handler’
          Nom du gestionnaire dicod (instance de module) utilisé par
          cette base de données (*note (dico)Handlers::).

     ‘complex?’ (par défaut : #F)
          Indique si la configuration est pour une base de données
          complexe. La configuration complexe a besoin d’un objet
          ‘<dicod-handler>’ correspondant, sinon inutile.

     ‘options’
          Liste de chaînes ou de gexps représentant les arguments pour
          la base de données (*note (dico)Databases::).

 -- Variable : %dicod-database:gcide
     Un objet ‘<dicod-database>’ servant le dictionnaire international
     collaboratif en anglais via le paquet ‘gcide’.

 -- Procedure : dicod-freedict-database dictionary-name
     Returns a record of type ‘dicod-database’ for purpose of
     configuring a database for the FreeDict multilingual dictionary
     named by DICTIONARY-NAME, a string such as ‘"kur-eng"’ for the
     Kurdish-to-English dictionary, into a service of type
     ‘dicod-service-type’.

 -- Variable : %dicod-databases:freedict
     A relatively large list of records of type ‘dicod-database’, made
     available for users who wish to configure all the FreeDict
     multilingual dictionaries provided by the ‘freedict-dictionaries’
     package into a service of type ‘dicod-service-type’.

   The following is an example ‘dicod-service-type’ configuration,
extending a ‘dicod’ daemon serving databases for the wordnet and gcide
dictionaries, as well as a selection of FreeDict multilingual
dictionaries.

     (service dicod-service-type
              (dicod-configuration
               (handlers (list
                          (dicod-handler
                           (name "wordnet")
                           (module "wordnet")
                           (options
                            (list #~(string-append "wnhome=" #$wordnet))))))
               (databases (cons*
                           (dicod-database
                            (name "wordnet")
                            (complex? #t)
                            (handler "wordnet"))
                           %dicod-database:gcide
                           (map
                            dicod-freedict-database
                            '("fra-eng" "eng-fra" "eng-spa" "spa-eng"))))))

Service Docker
..............

Le module ‘(gnu services docker)’ fournit les services suivants.

 -- Variable : containerd-service-type

     This service type operates containerd containerd
     (https://containerd.io), a daemon responsible for overseeing the
     entire container lifecycle on its host system. This includes image
     handling, storage management, container execution, supervision,
     low-level storage operations, network connections, and more.

 -- Data Type : containerd-configuration
     This is the data type representing the configuration of containerd.

     ‘containerd’ (default: ‘containerd’)
          The containerd daemon package to use.

     ‘debug?’ (par défaut : ‘#f’)
          Indique s’il faut activer la sortie de débogage.

     ‘environment-variables’ (par défaut : ‘'()’)
          List of environment variables to set for ‘containerd’.

          Cela doit être une liste de chaines où chaque chaine a pour
          forme ‘CLÉ=VALEUR’ comme dans cet exemple :

               (list "HTTP_PROXY=socks5://127.0.0.1:9150"
                     "HTTPS_PROXY=socks5://127.0.0.1:9150")

 -- Variable : docker-service-type

     C’est le type du service qui lance Docker (https://www.docker.com),
     un démon qui peut exécuter des lots applicatifs (aussi appelés «
     conteneurs ») dans des environnements isolés.

     The ‘containerd-service-type’ service need to be added to a system
     configuration, otherwise a message about not any service provides
     ‘containerd’ will be displayed during ‘guix system reconfigure’.

 -- Type de données : docker-configuration
     Le type de données qui représente la configuration de Docker et
     Containerd.

     ‘docker’ (par défaut : ‘docker’)
          Le paquet du démon Docker à utiliser.

     ‘docker-cli’ (par défaut : ‘docker-cli’)
          Le paquet du client Docker à utiliser.

     ‘containerd’ (par défaut : CONTAINERD)
          This field is deprecated in favor of ‘containerd-service-type’
          service.

     ‘proxy’ (par défaut : DOCKER-LIBNETWORK-CMD-PROXY)
          Le paquet du mandataire réseau en espace utilisateur de Docker
          à utiliser.

     ‘enable-proxy?’ (par défaut : ‘#t’)
          Indique s’il faut utiliser le mandataire réseau en espace
          utilisateur de Docker.

     ‘debug?’ (par défaut : ‘#f’)
          Indique s’il faut activer la sortie de débogage.

     ‘enable-iptables?’ (par défaut : ‘#t’)
          Indique s’il faut ajouter des règles iptables.

     ‘environment-variables’ (par défaut : ‘'()’)
          Liste de variables d’environnement à initialiser pour
          ‘dockerd’.

          Cela doit être une liste de chaines où chaque chaine a pour
          forme ‘CLÉ=VALEUR’ comme dans cet exemple :

               (list "LANGUAGE=eo:ca:eu"
                     "TMPDIR=/tmp/dockerd")

     ‘config-file’ (type: maybe-file-like)
          JSON configuration file pass to ‘dockerd’.

 -- Variable : singularity-service-type
     C’est le type de service qui vous permet de lancer Singularity
     (https://www.sylabs.io/singularity/), un outil similaire à Docker
     pour créer et lancer des lots applicatifs (aussi appelés «
     conteneurs »). la valeur de ce service est le paquet Singularity à
     utiliser.

     Le service n’installe pas de démon : à la place, il installe des
     utilitaires en setuid-root (*note Privileged Programs::) pour que
     les utilisateurs non privilégiés puisse invoquer ‘singularity run’
     et les commandes similaires.

Rootless Podman Service
.......................

The ‘(gnu services containers)’ module provides the following service.

 -- Variable : rootless-podman-service-type
     This is the service type for Podman (https://podman.io) is a
     container management tool.

     In addition to providing a drop-in replacement for Docker, Podman
     offers the ability to run containers in “root-less” mode, meaning
     that regular users can deploy containers without elevated
     privileges. It does so mainly by leveraging two Linux kernel
     features: unprivileged user namespaces, and subordinate user and
     group IDs (*note the subordinate user and group ID service:
     subordinate-user-group-ids.).

     The ‘rootless-podman-service-type’ sets up the system to allow
     unprivileged users to run ‘podman’ commands:

          (use-service-modules containers dbus desktop networking ...)
          (use-modules (gnu system accounts))  ;for 'subid-range'

          (operating-system
            ;; ...
            (users (cons (user-account
                          (name "alice")
                          (comment "Bob's sister")
                          (group "users")

                          ;; Adding the account to the "cgroup" group
                          ;; makes it possible to run podman commands.
                          (supplementary-groups '("cgroup" "wheel"
                                                  "audio" "video")))
                         %base-user-accounts))
            (services
              (cons* (service dbus-root-service-type)
                     (service dhcpcd-service-type)
                     (service elogind-service-type)
                     (service iptables-service-type)
                     (service rootless-podman-service-type
                              (rootless-podman-configuration
                                (subgids
                                 (list (subid-range (name "alice"))))
                                (subuids
                                 (list (subid-range (name "alice"))))))
                     %base-services)))

     The ‘iptables-service-type’ is required for Podman to be able to
     setup its own networks. Due to the change in user groups and file
     systems it is recommended to reboot (or at least logout), before
     trying to run Podman commands.

     To test your installation you can run:

          $ podman run -it --rm docker.io/alpine cat /etc/*release*
          NAME="Alpine Linux"
          ID=alpine
          VERSION_ID=3.20.2
          PRETTY_NAME="Alpine Linux v3.20"
          HOME_URL="https://alpinelinux.org/"
          BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

 -- Data Type : rootless-podman-configuration
     Available ‘rootless-podman-configuration’ fields are:

     ‘podman’ (default: ‘podman’) (type: package-or-#f)
          The Podman package that will be installed in the system
          profile. Pass ‘#f’ to not install Podman.

     ‘group-name’ (default: ‘"cgroup"’) (type: string)
          The name of the group that will own /sys/fs/cgroup resources.
          Users that want to use rootless Podman have to be in this
          group.

     ‘containers-registries’ (type: lowerable)
          A string or a gexp evaluating to the path of Podman’s
          ‘containers/registries.conf’ configuration file.

     ‘containers-storage’ (type: lowerable)
          A string or a gexp evaluating to the path of Podman’s
          ‘containers/storage.conf’ configuration file.

     ‘containers-policy’ (type: lowerable)
          A string or a gexp evaluating to the path of Podman’s
          ‘containers/policy.json’ configuration file.

     ‘pam-limits’ (type: list-of-pam-limits-entries)
          The PAM limits to be set for rootless Podman.

     ‘subgids’ (default: ‘()’) (type: list-of-subid-ranges)
          A list of subid ranges representing the subgids that will be
          available for each configured user.

     ‘subuids’ (default: ‘()’) (type: list-of-subid-ranges)
          A list of subid ranges representing the subuids that will be
          available for each configured user.

OCI backed services
...................

Should you wish to manage your Open Container Initiative (OCI)
containers with the same consistent interface you use for your other
Shepherd services, OCI-SERVICE-TYPE is the tool to use: given an OCI
container image, it will run it in a Shepherd service. One example where
this is useful: it lets you run services that are available as OCI
images but not yet packaged for Guix.

 -- Variable : oci-service-type

     This is a thin wrapper around Docker’s or Podman’s CLI that
     executes OCI images backed processes as Shepherd Services.

          (simple-service 'oci-provisioning
                          oci-service-type
                          (oci-extension
                            (networks
                              (list
                                (oci-network-configuration (name "monitoring"))))
                            (containers
                             (list
                              (oci-container-configuration
                               (network "monitoring")
                               (image
                                (oci-image
                                  (repository "guile")
                                  (tag "3")
                                  (value (specifications->manifest '("guile")))
                                  (pack-options '(#:symlinks (("/bin/guile" -> "bin/guile"))
                                                  #:max-layers 2))))
                               (entrypoint "/bin/guile")
                               (command
                                '("-c" "(display \"hello!\n\")")))
                              (oci-container-configuration
                                (image "prom/prometheus")
                                (network "host")
                                (ports
                                 '(("9000" . "9000")
                                   ("9090" . "9090"))))
                              (oci-container-configuration
                                (image "grafana/grafana:10.0.1")
                                (network "host")
                                (volumes
                                 '("/var/lib/grafana:/var/lib/grafana")))))))

     In this example three different Shepherd services are going to be
     added to the system. Each ‘oci-container-configuration’ record
     translates to a ‘docker run’ or ‘podman run’ invocation and its
     fields directly map to options. You can refer to the Docker
     (https://docs.docker.com/engine/reference/commandline/run) or
     Podman
     (https://docs.podman.io/en/stable/markdown/podman-run.1.html)
     upstream documentation for semantics of each value. If the images
     are not found, they will be pulled. You can refer to the Docker
     (https://docs.docker.com/engine/reference/commandline/pull/) or
     Podman
     (https://docs.podman.io/en/stable/markdown/podman-pull.1.html)
     upstream documentation for semantics. The services with ‘(network
     "host")’ are going to be attached to the host network and are
     supposed to behave like native processes with regard to networking.

 -- Data Type : oci-configuration
     Available ‘oci-configuration’ fields are:

     ‘runtime’ (default: ‘'docker’) (type: symbol)
          The OCI runtime to use to run commands. It can be either
          ‘'docker’ or ‘'podman’.

     ‘runtime-cli’ (type: maybe-package-or-string)
          The OCI runtime command line to be installed in the system
          profile and used to provision OCI resources, it can be either
          a package or a string representing an absolute file name to
          the runtime binary entrypoint. When unset it will default to
          ‘docker-cli’ package for the ‘'docker’ runtime or to ‘podman’
          package for the ‘'podman’ runtime.

     ‘runtime-extra-arguments’ (default: ‘'()’) (type: list)
          A list of strings, gexps or file-like objects that will be
          placed after each ‘docker’ or ‘podman’ invokation.

     ‘user’ (type : peut-être-chaine)
          The user name under whose authority OCI commands will be run.
          This field will override the ‘user’ field of
          ‘oci-configuration’.

     ‘group’ (type: maybe-string)
          The group name under whose authority OCI commands will be run.
          When using the ‘'podman’ OCI runtime, this field will be
          ignored and the default group of the user configured in the
          ‘user’ field will be used. This field will override the
          ‘group’ field of ‘oci-configuration’.

     ‘subuids-range’ (type: maybe-subid-range)
          An optional ‘subid-range’ record allocating subuids for the
          user from the ‘user’ field. When unset, with the rootless
          Podman OCI runtime, it defaults to ‘(subid-range (name
          "oci-container"))’.

     ‘subgids-range’ (type: maybe-subid-range)
          An optional ‘subid-range’ record allocating subgids for the
          user from the ‘user’ field. When unset, with the rootless
          Podman OCI runtime, it defaults to ‘(subid-range (name
          "oci-container"))’.

     ‘containers’ (default: ‘'()’) (type: list-of-oci-containers)
          The list of ‘oci-container-configuration’ records representing
          the containers to provision. The use of the ‘oci-extension’
          record should be preferred for most cases.

     ‘networks’ (default: ‘'()’) (type: list-of-oci-networks)
          The list of ‘oci-network-configuration’ records representing
          the containers to provision. The use of the ‘oci-extension’
          record should be preferred for most cases.

     ‘volumes’ (default: ‘'()’) (type: list-of-oci-volumes)
          The list of ‘oci-volumes-configuration’ records representing
          the containers to provision. The use of the ‘oci-extension’
          record should be preferred for most cases.

     ‘verbose?’ (default: ‘#f’) (type: boolean)
          When true, additional output will be printed, allowing to
          better follow the flow of execution.

 -- Data Type : oci-extension
     Available ‘oci-extension’ fields are:

     ‘containers’ (default: ‘'()’) (type: list-of-oci-containers)
          The list of ‘oci-container-configuration’ records representing
          the containers to provision.

     ‘networks’ (default: ‘'()’) (type: list-of-oci-networks)
          The list of ‘oci-network-configuration’ records representing
          the containers to provision.

     ‘volumes’ (default: ‘'()’) (type: list-of-oci-volumes)
          The list of ‘oci-volumes-configuration’ records representing
          the containers to provision.

 -- Data Type : oci-container-configuration
     Available ‘oci-container-configuration’ fields are:

     ‘user’ (default: ‘"oci-container"’) (type: string)
          The user under whose authority docker commands will be run.

     ‘group’ (default: ‘"docker"’) (type: string)
          The group under whose authority docker commands will be run.

     ‘command’ (default: ‘'()’) (type: list-of-strings)
          Overwrite the default command (‘CMD’) of the image.

     ‘entrypoint’ (default: ‘""’) (type: string)
          Overwrite the default entrypoint (‘ENTRYPOINT’) of the image.

     ‘host-environment’ (default: ‘'()’) (type: list)
          Set environment variables in the host environment where
          ‘docker run’ or ‘podman run’ are invoked. This is especially
          useful to pass secrets from the host to the container without
          having them on the OCI runtime command line, for example: by
          setting the ‘MYSQL_PASSWORD’ on the host and by passing ‘--env
          MYSQL_PASSWORD’ through the ‘extra-arguments’ field, it is
          possible to securely set values in the container environment.
          This field’s value can be a list of pairs or strings, even
          mixed:

               (list '("LANGUAGE" . "eo:ca:eu")
                     "JAVA_HOME=/opt/java")

          Pair members can be strings, gexps or file-like objects.
          Strings are passed directly to ‘make-forkexec-constructor’.

     ‘environment’ (default: ‘'()’) (type: list)
          Set environment variables inside the container. This can be a
          list of pairs or strings, even mixed:

               (list '("LANGUAGE" . "eo:ca:eu")
                     "JAVA_HOME=/opt/java")

          Pair members can be strings, gexps or file-like objects.
          Strings are passed directly to the OCI runtime CLI. You can
          refer to the Docker
          (https://docs.docker.com/engine/reference/commandline/run/#env)
          or Podman
          (https://docs.podman.io/en/stable/markdown/podman-run.1.html#env-e-env)
          upstream documentation for semantics.

     ‘image’ (type: string-or-oci-image)
          The image used to build the container. It can be a string or
          an ‘oci-image’ record. Strings are resolved by the OCI
          runtime, and follow the usual format
          ‘myregistry.local:5000/testing/test-image:tag’.

     ‘provision’ (default: ‘""’) (type: string)
          Set the name of the provisioned Shepherd service.

     ‘requirement’ (default: ‘'()’) (type: list-of-symbols)
          Set additional Shepherd services dependencies to the
          provisioned Shepherd service.

     ‘log-file’ (type: maybe-string)
          When ‘log-file’ is set, it names the file to which the
          service’s standard output and standard error are redirected.
          ‘log-file’ is created if it does not exist, otherwise it is
          appended to.

     ‘auto-start?’ (default: ‘#t’) (type: boolean)
          Whether this service should be started automatically by the
          Shepherd. If it is ‘#f’, the service has to be started
          manually with ‘herd start’.

     ‘respawn?’ (default: ‘#f’) (type: boolean)
          Whether to have Shepherd restart the service when it stops,
          for instance when the underlying process dies.

     ‘shepherd-actions’ (default: ‘'()’) (type: list-of-shepherd-actions)
          This is a list of ‘shepherd-action’ records defining actions
          supported by the service.

     ‘network’ (default: ‘""’) (type: string)
          Set an OCI network for the spawned container.

     ‘ports’ (default: ‘'()’) (type: list)
          Set the port or port ranges to expose from the spawned
          container. This can be a list of pairs or strings, even mixed:

               (list '("8080" . "80")
                     "10443:443")

          Pair members can be strings, gexps or file-like objects.
          Strings are passed directly to the OCI runtime CLI. You can
          refer to the Docker
          (https://docs.docker.com/engine/reference/commandline/run/#publish)
          or Podman
          (https://docs.podman.io/en/stable/markdown/podman-run.1.html#publish-p-ip-hostport-containerport-protocol)
          upstream documentation for semantics.

     ‘volumes’ (default: ‘'()’) (type: list)
          Set volume mappings for the spawned container. This can be a
          list of pairs or strings, even mixed:

               (list '("/root/data/grafana" . "/var/lib/grafana")
                     "/gnu/store:/gnu/store")

          Pair members can be strings, gexps or file-like objects.
          Strings are passed directly to the OCI runtime CLI. You can
          refer to the Docker
          (https://docs.docker.com/engine/reference/commandline/run/#volume)
          or Podman
          (https://docs.podman.io/en/stable/markdown/podman-run.1.html#volume-v-source-volume-host-dir-container-dir-options)
          upstream documentation for semantics.

     ‘container-user’ (default: ‘""’) (type: string)
          Set the current user inside the spawned container. You can
          refer to the Docker
          (https://docs.docker.com/engine/reference/run/#user) or Podman
          (https://docs.podman.io/en/stable/markdown/podman-run.1.html#user-u-user-group)
          upstream documentation for semantics.

     ‘workdir’ (default: ‘""’) (type: string)
          Set the current working directory for the spawned Shepherd
          service. You can refer to the Docker
          (https://docs.docker.com/engine/reference/run/#workdir) or
          Podman
          (https://docs.podman.io/en/stable/markdown/podman-run.1.html#workdir-w-dir)
          upstream documentation for semantics.

     ‘extra-arguments’ (default: ‘'()’) (type: list)
          A list of strings, gexps or file-like objects that will be
          directly passed to the ‘docker run’ or ‘podman run’
          invokation.

 -- Data Type : oci-network-configuration
     Available ‘oci-network-configuration’ fields are:

     ‘name’ (type : string)
          The name of the OCI network to provision.

     ‘driver’ (type: maybe-string)
          The driver to manage the network.

     ‘gateway’ (type: maybe-string)
          IPv4 or IPv6 gateway for the subnet.

     ‘internal?’ (default: ‘#f’) (type: boolean)
          Restrict external access to the network

     ‘ip-range’ (type: maybe-string)
          Allocate container ip from a sub-range in CIDR format.

     ‘ipam-driver’ (type: maybe-string)
          IP Address Management Driver.

     ‘ipv6?’ (default: ‘#f’) (type: boolean)
          Enable IPv6 networking.

     ‘subnet’ (type: maybe-string)
          Subnet in CIDR format that represents a network segment.

     ‘labels’ (default: ‘'()’) (type: list)
          The list of labels that will be used to tag the current
          volume.

     ‘extra-arguments’ (default: ‘'()’) (type: list)
          A list of strings, gexps or file-like objects that will be
          directly passed to the ‘docker network create’ or ‘podman
          network create’ invokation.

 -- Data Type : oci-volume-configuration
     Available ‘oci-volume-configuration’ fields are:

     ‘name’ (type : string)
          The name of the OCI volume to provision.

     ‘labels’ (default: ‘'()’) (type: list)
          The list of labels that will be used to tag the current
          volume.

     ‘extra-arguments’ (default: ‘'()’) (type: list)
          A list of strings, gexps or file-like objects that will be
          directly passed to the ‘docker volume create’ or ‘podman
          volume create’ invokation.

 -- Data Type : oci-image
     Available ‘oci-image’ fields are:

     ‘repository’ (type: string)
          A string like ‘myregistry.local:5000/testing/test-image’ that
          names the OCI image.

     ‘tag’ (default: ‘"latest"’) (type: string)
          A string representing the OCI image tag. Defaults to ‘latest’.

     ‘value’ (type: oci-lowerable-image)
          A ‘manifest’ or ‘operating-system’ record that will be lowered
          into an OCI compatible tarball. Otherwise this field’s value
          can be a file-like object that evaluates to an OCI compatible
          tarball.

     ‘pack-options’ (default: ‘'()’) (type: list)
          An optional set of keyword arguments that will be passed to
          the ‘docker-image’ procedure from ‘guix scripts pack’. They
          can be used to replicate ‘guix pack’ behavior:

               (oci-image
                 (repository "guile")
                 (tag "3")
                 (value
                   (specifications->manifest '("guile")))
                 (pack-options '(#:symlinks (("/bin/guile" -> "bin/guile"))
                                 #:max-layers 2)))

          If the ‘value’ field is an ‘operating-system’ record, this
          field’s value will be ignored.

     ‘system’ (default: ‘""’) (type: string)
          Attempt to build for a given system, e.g. "i686-linux"

     ‘target’ (default: ‘""’) (type: string)
          Attempt to cross-build for a given triple, e.g.
          "aarch64-linux-gnu"

     ‘grafts?’ (default: ‘#f’) (type: boolean)
          Whether to allow grafting or not in the pack build.

Subordinate User and Group ID Service
.....................................

Among the virtualization facilities implemented by the Linux kernel is
the concept of “subordinate IDs”. Subordinate IDs allow for mapping user
and group IDs inside process namespaces to user and group IDs of the
host system. Subordinate user ID ranges (subuids) allow users to map
virtual user IDs inside containers to the user ID of an unprivileged
user of the host system. Subordinate group ID ranges (subgids), instead
map virtual group IDs to the group ID of an unprivileged user on the
host system. You can access ‘subuid(5)’ and ‘subgid(5)’ Linux man pages
for more details.

   The ‘(gnu system shadow)’ module exposes the ‘subids-service-type’,
its configuration record ‘subids-configuration’ and its extension record
‘subids-extension’.

   With ‘subids-service-type’, subuids and subgids ranges can be
reserved for users that desire so:

     (use-modules (gnu system shadow)     ;for 'subids-service-type'
                  (gnu system accounts)   ;for 'subid-range'
                  ...)

     (operating-system
       ;; ...
       (services
         (list
           (simple-service 'alice-bob-subids
                           subids-service-type
                           (subids-extension
                             (subgids
                              (list
                               (subid-range (name "alice"))))
                             (subuids
                              (list
                               (subid-range (name "alice"))
                               (subid-range (name "bob")
                                            (start 100700)))))))))

   Users (definitely other services), usually, are supposed to extend
the service instead of adding subids directly to ‘subids-configuration’,
unless the want to change the default behavior for root. With default
settings the ‘subids-service-type’ adds, if it’s not already there, a
configuration for the root account to both ‘/etc/subuid’ and
‘/etc/subgid’, possibly starting at the minimum possible subid.
Otherwise the root subuids and subgids ranges are fitted wherever
possible.

   The above configuration will yield the following:

     # cat /etc/subgid
     root:100000:65536
     alice:165536:65536
     # cat /etc/subuid
     root:100000:700
     bob:100700:65536
     alice:166236:65536

 -- Data Type : subids-configuration

     With default settings the ‘subids-service-type’ adds, if it’s not
     already there, a configuration for the root account to both
     ‘/etc/subuid’ and ‘/etc/subgid’, possibly starting at the minimum
     possible subid. To disable the default behavior and provide your
     own definition for the root subid ranges you can set to ‘#f’ the
     ‘add-root?’ field:

          (use-modules (gnu system shadow)     ;for 'subids-service-type'
                       (gnu system accounts)   ;for 'subid-range'
                       ...)

          (operating-system
            ;; ...
            (services
              (list
                (service subids-service-type
                         (subids-configuration
                          (add-root? #f)
                          (subgids
                            (subid-range (name "root")
                                         (start 120000)
                                         (count 100)))
                          (subuids
                            (subid-range (name "root")
                                         (start 120000)
                                         (count 100)))))
                (simple-service 'alice-bob-subids
                                subids-service-type
                                (subids-extension
                                  (subgids
                                   (list
                                    (subid-range (name "alice"))))
                                  (subuids
                                   (list
                                    (subid-range (name "alice"))
                                    (subid-range (name "bob")
                                                 (start 100700)))))))))

     Available ‘subids-configuration’ fields are:

     ‘add-root?’ (default: ‘#t’) (type: boolean)
          Whether to automatically configure subuids and subgids for
          root.

     ‘subgids’ (default: ‘'()’) (type: list-of-subid-ranges)
          The list of ‘subid-range’s that will be serialized to
          ‘/etc/subgid’. If a range doesn’t specify a start it will be
          fitted based on its number of requested subids. If a range
          doesn’t specify a count the default size of 65536 will be
          assumed.

     ‘subuids’ (default: ‘'()’) (type: list-of-subid-ranges)
          The list of ‘subid-range’s that will be serialized to
          ‘/etc/subuid’. If a range doesn’t specify a start it will be
          fitted based on its number of requested subids. If a range
          doesn’t specify a count the default size of 65536 will be
          assumed.

 -- Data Type : subids-extension

     Available ‘subids-extension’ fields are:

     ‘subgids’ (default: ‘'()’) (type: list-of-subid-ranges)
          The list of ‘subid-range’s that will be appended to
          ‘subids-configuration-subgids’. Entries with the same name are
          deduplicated upon merging.

     ‘subuids’ (default: ‘'()’) (type: list-of-subid-ranges)
          The list of ‘subid-range’s that will be appended to
          ‘subids-configuration-subuids’. Entries with the same name are
          deduplicated upon merging.

 -- Data Type : subid-range

     The ‘subid-range’ record is defined at ‘(gnu system accounts)’.
     Available fields are:

     ‘name’ (type : string)
          The name of the user or group that will own this range.

     ‘start’ (default: ‘#f’) (type: integer)
          The first requested subid. When false the first available
          subid with enough contiguous subids will be assigned.

     ‘count’ (default: ‘#f’) (type: integer)
          The number of total allocated subids. When #f the default of
          65536 will be assumed .

Service auditd
..............

Le module ‘(gnu services auditd)’ fournit le service suivant.

 -- Variable : auditd-service-type

     C’est le type du service qui lance auditd
     (https://people.redhat.com/sgrubb/audit/), un démon qui suit les
     informations de sécurité de votre système.

     Exemples de ce qui peut être suivi :

       1. Les accès aux fichiers
       2. Les appels système
       3. Les commandes invoquées
       4. Les tentatives de connexion échouées
       5. Le filtrage du pare-feu
       6. Les accès réseau

     ‘auditctl’ du paquet ‘audit’ peut être utilisé pour ajouter ou
     supprimer des évènements à suivre (jusqu’au prochain redémarrage).
     Pour suivre les évènements de manière permanente, ajoutez des
     arguments à la commande auditctl dans un fichier nommé
     ‘audit.rules’ dans le répertoire de configuration (voir plus bas).
     ‘aureport’ du paquet ‘audit’ peut être utilisé pour visualiser un
     rapport de tous les évènements enregistrés. le démon d’audit
     enregistre par défaut dans le fichier ‘/var/log/audit.log’.

 -- Type de données : auditd-configuration
     Le type de données qui représente la configuration de auditd.

     ‘audit’ (par défaut : ‘audit’)
          Le paquet audit à utiliser.

     ‘configuration-directory’ (par défaut : ‘%default-auditd-configuration-directory’)
          Le répertoire contenant le fichier de configuration du paquet
          audit, qui doit être nommé ‘auditd.conf’, et éventuellement
          des règles d’audit à instancier au démarrage.

Service R-Shiny
...............

Le module ‘(gnu services science)’ fournit le service suivant.

 -- Variable : rshiny-service-type

     C’est le type de service utilisé pour lancer une appli web créée
     avec ‘r-shiny’. Ce service initialise la variable d’environnement
     ‘R_LIBS_USER’ et lance le script fournit pour appeler ‘runApp’.

      -- Type de données : rshiny-configuration
          Le type de données qui représente la configuration de rshiny.

          ‘package’ (par défaut : ‘r-shiny’)
               Le paquet à utiliser.

          ‘binary’ (par défaut : ‘"rshiny"’)
               Le nom du binaire ou du script shell situé dans
               ‘package/bin/’ à lancer au démarrage du service.

               La manière habituelle de créer ce fichier est :

                    ...
                    (let* ((out       (assoc-ref %outputs "out"))
                           (targetdir (string-append out "/share/" ,name))
                           (app       (string-append out "/bin/" ,name))
                           (Rbin      (search-input-file %build-inputs "/bin/Rscript")))
                      ;; ...
                      (mkdir-p (string-append out "/bin"))
                      (call-with-output-file app
                        (lambda (port)
                          (format port
                    "#!~a
                    library(shiny)
                    setwd(\"~a\")
                    runApp(launch.browser=0, port=4202)~%\n"
                          Rbin targetdir))))

Service Nix
...........

Le module ‘(gnu services nix)’ fournit le service suivant.

 -- Variable : nix-service-type

     C’est le type du service qui lance le démon de construction du
     gestionnaire de paquets Nix (https://nixos.org/nix/). Voici un
     exemple qui montre comment l’utiliser :

          (use-modules (gnu))
          (use-service-modules nix)
          (use-package-modules package-management)

          (operating-system
            ;; ...
            (packages (append (list nix)
                              %base-packages))

            (services (append (list (service nix-service-type))
                              %base-services)))

     Après ‘guix system reconfigure’, configurez Nix pour votre
     utilisateur :

        • Ajoutez un canal Nix et mettez-le à jour. Voir Nix channels
          (https://wiki.nixos.org/wiki/Nix_channels) for more
          information about the available channels. If you would like to
          use the unstable Nix channel you can do this by running:

               $ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
               $ nix-channel --update

        • Create your Nix profile directory:

               $ sudo mkdir -p /nix/var/nix/profiles/per-user/$USER
               $ sudo chown $USER:root /nix/var/nix/profiles/per-user/$USER

        • Créez un lien symbolique vers votre profil et activez le
          profil de Nix :

               $ ln -s "/nix/var/nix/profiles/per-user/$USER/profile" ~/.nix-profile
               $ source /run/current-system/profile/etc/profile.d/nix.sh

 -- Type de données : nix-configuration
     Ce type de données représente la configuration du démon Nix.

     ‘nix’ (par défaut : ‘nix’)
          Le paquet Nix à utiliser.

     ‘sandbox’ (par défaut : ‘#t’)
          Spécifie si les constructions sont effectuées dans un bac à
          sable par défaut.

     ‘build-directory’ (par défaut : ‘"/tmp"’)
          Le répertoire où les répertoires de construction sont stockés
          pendant les constructions. Il est utile de le modifier par
          exemple si l’emplacement par défaut n’a pas assez d’espace
          pour contenir l’arborescence de construction de gros paquets.

          Cela fonctionne de la même manière que la variable
          d’environnement ‘TPMDIR’ pour ‘guix-daemon’. *note ‘TPMDIR’:
          Réglages de l'environnement de construction, pour plus
          d’information.

     ‘build-sandbox-items’ (par défaut : ‘'()’)
          C’est une liste de chaines de caractères ou d’objets ajoutés
          au champ ‘build-sandbox-items’ du fichier de configuration.

     ‘extra-config’ (par défaut : ‘'()’)
          C’est une liste de chaînes de caractères ou d’objets ajoutés
          au fichier de configuration. Elle est utile pour ajouter du
          texte supplémentaire directement dans le fichier de
          configuration.

     ‘extra-options’ (par défaut : ‘'()’)
          Options supplémentaires de la ligne de commande pour
          ‘nix-service-type’.

Service Fail2Ban
................

‘fail2ban’ (http://www.fail2ban.org/) scanne les fichiers journaux (p.
ex. ‘/var/log/apache/error_log’) et bannit les adresses IP qui montrent
des signes de malhonnêteté — des échecs de connexion répétés, des
tentatives d’utiliser des exploits, etc.

   Le type de service ‘fail2ban-service-type’ est fournit par le module
‘(gnu services security)’.

   Ce type de service lance le démon ‘fail2ban’. Il peut être configuré
de plusieurs façon qui sont :

Configuration basique
     Les paramètres de base du service Fail2Ban peut être configurés via
     sa configuration ‘fail2ban’, qui est documentée ci-dessous.

Extensions personnalisées des prisons
     La fonction ‘fail2ban-jail-service’ peut être utilisée pour ajouter
     de nouvelles prisons Fail2Ban.

Mécanisme d’extension du Shepherd
     Les développeurs de services peuvent étendre le type de service
     ‘fail2ban-service-type’ lui-même avec le mécanisme d’extension
     habituel des services.

 -- Variable : fail2ban-service-type

     C’est le type de service qui lance le démon ‘fail2ban’. Voici un
     exemple de configuration de base explicite :

          (append
           (list
            (service fail2ban-service-type
                     (fail2ban-configuration
                      (extra-jails
                       (list
                        (fail2ban-jail-configuration
                         (name "sshd")
                         (enabled? #t))))))
            ;; Il n'y a pas de dépendance implicite à un service SSH,
            ;; donc il faut en fournir un.
            (service openssh-service-type))
           %base-services)

 -- Procédure : fail2ban-jail-service svc-type jail
     Étend SVC-TYPE, un objet ‘<service-type>’ avec JAIL, un objet
     ‘fail2ban-jail-configuration’.

     Par exemple :

          (append
           (list
            (service
             ;; La procédure « fail2ban-jail-service » peut étendre n'importe quel type de service
             ;; avec une prison fail2ban. Cela supprime la nécessité d'étendre les services explicitement
             ;; avec le fail2ban-service-type.
             (fail2ban-jail-service
              openssh-service-type
              (fail2ban-jail-configuration
               (name "sshd")
               (enabled? #t)))
             (openssh-configuration ...))))

   Ci-dessous se trouve la référence des différents enregistrement de
configuration ‘jail-service-type’.

 -- Type de données : fail2ban-configuration
     Les champs de ‘fail2ban-configuration’ disponibles sont :

     ‘fail2ban’ (par défaut : ‘fail2ban’) (type : paquet)
          Le paquet ‘fail2ban’ à utiliser. Il est utilisé à la fois pour
          les binaires et pour la configuration de base par défaut qui
          doit être étendue avec des objets
          ‘<fail2ban-jail-configuration>’.

     ‘run-directory’ (par défaut : ‘"/var/run/fail2ban"’) (type : chaine)
          Le répertoire d’état pour le démon ‘fail2ban’.

     ‘jails’ (par défaut : ‘'()’) (type : liste-de-fail2ban-jail-configurations)
          Instances de ‘<fail2ban-jail-configuration>’ collectées par
          les extensions.

     ‘extra-jails’ (par défaut : ‘'()’) (type : liste-de-fail2ban-jail-configurations)
          Instances de ‘<fail2ban-jail-configuration>’ fournies
          explicitement.

     ‘extra-content’ (par défaut : ‘'()’) (type : text-config)
          Contenu brut supplémentaire à ajouter à la fin du fichier
          ‘jail.local’, à fournir sous forme d’une liste de
          simili-fichiers.

 -- Type de données : fail2ban-ignore-cache-configuration
     Les champs de ‘fail2ban-ignore-cache-configuration’ disponibles
     sont :

     ‘key’ (type : chaine)
          Clé de cache.

     ‘max-count’ (type : entier)
          Taille du cache.

     ‘max-time’ (type : entier)
          Durée du cache.

 -- Type de données : fail2ban-jail-action-configuration
     Les champs de ‘fail2ban-jail-action-configuration’ disponibles sont
     :

     ‘name’ (type : string)
          Nom de l’action.

     ‘arguments’ (par défaut : ‘'()’) (type : liste-d’arguments)
          Arguments de l’action.

 -- Type de données : fail2ban-jail-configuration
     Les champs de ‘fail2ban-jail-configuration’ disponibles sont :

     ‘name’ (type : string)
          Nom requis de cette configuration de prison.

     ‘enabled?’ (par défaut : ‘#t’) (type : booléen)
          Spécifie si cette prison est activée.

     ‘backend’ (type : peut-être-symbole)
          Le moteur à utiliser pour détecter les changements dans
          ‘log-path’. La valeur par défaut est ’auto. Pour consulter les
          valeurs par défaut de la configuration de prison, consultez le
          fichier ‘/etc/fail2ban/jail.conf’ du paquet ‘fail2ban’.

     ‘max-retry’ (type : peut-être-entier)
          Le nombre d’échecs avant qu’un hôte ne soit banni (p. ex.
          ‘(max-retry 5)’).

     ‘max-matches’ (type : peut-être-entier)
          Le nombre de correspondances stockées dans le ticket
          (accessible avec l’étiquette ‘<matches>’) dans l’action.

     ‘find-time’ (type : peut-être-chaine)
          La fenêtre pendant laquelle le compte de tentative maximale
          doit être atteint pour qu’une adresse IP soit bannie. Un hôte
          est banni s’il a généré ‘max-retry’ pendant les dernières
          ‘find-time’ secondes (p. ex. ‘»find-time "10m")’). Elle peut
          être fournie en seconde ou avec le « format temporel abrégé »
          de Fail2ban, décrit dans ‘man 5 jail.conf’.

     ‘ban-time’ (type : peut-être-chaine)
          La durée, en secondes ou au format temporel abrégé, qu’un
          bannissement doit durer (p. ex. ‘(ban-time "10m")’).

     ‘ban-time-increment?’ (type : peut-être-booléen)
          Indique s’il faut considérer les bannissements passés pour
          calculer un incrément du temps de bannissement par défaut
          d’une adresse IP particulière.

     ‘ban-time-factor’ (type : peut-être-chaine)
          Le coefficient à utiliser pour calculer un temps de
          bannissement exponentiel.

     ‘ban-time-formula’ (type : peut-être-chaine)
          C’est la formule utilisée pour calculer la prochaine valeur
          d’une durée de bannissement.

     ‘ban-time-multipliers’ (type : peut-être-chaine)
          Utilisé pour calculer la prochaine valeur de la durée du
          bannissement au lieu de la formule.

     ‘ban-time-max-time’ (type : peut-être-chaine)
          Le nombre maximum de secondes qu’un bannissement peut durer.

     ‘ban-time-rnd-time’ (type : peut-être-chaine)
          Le nombre maximum de secondes maximum qu’un bannissement à
          durée aléatoire peut durer. C’est utile pour arrêter les
          robots « intelligents » qui calculent le moment exacte où une
          adresse IP peut être dé-bannie.

     ‘ban-time-overall-jails?’ (type : peut-être-booléen)
          Lorsque la valeur est vraie, elle spécifie que la recherche
          d’une adresse IP dans la base de donnée doit se faire dans
          toutes les prisons. Sinon, seule la prison actuelle pour
          l’adresse IP bannie est prise en compte.

     ‘ignore-self?’ (type : peut-être-booléen)
          Ne jamais bannir l’adresse IP de la machine locale.

     ‘ignore-ip’ (par défaut : ‘'()’) (type : liste-de-chaines)
          Une liste d’adresse IP, de masques CIDR ou d’hôtes DNS à
          ignorer. ‘fail2ban’ ne bannira par un hôte qui correspond à
          une adresse de cette liste.

     ‘ignore-cache’ (type : peut-être-fail2ban-ignore-cache-configuration)
          fournit des paramètres de cache pour ignorer les vérifications
          d’échecs.

     ‘filter’ (type : peut-fail2ban-jail-filter-configuration)
          Le filtre à utiliser par la prison, spécifiée par un objet
          ‘<fail2ban-jail-filter-configuration>’. Par défaut, les
          prisons ont un nom qui correspond au nom de leur filtre.

     ‘log-time-zone’ (type : peut-être-chaine)
          Le fuseau horaire par défaut pour les lignes de journaux qui
          n’en indiquent pas.

     ‘log-encoding’ (type : peut-être-symbole)
          L’encodage des journaux traités par la prison. Les valeurs
          possibles sont : ‘'ascii’, ‘'utf-8’ et ‘'auto’.

     ‘log-path’ (par défaut : ‘'()’) (type : liste-de-chaines)
          Le nom de fichier des journaux à surveiller.

     ‘action’ (par défaut : ‘'()’) (type : liste-de-fail2ban-jail-action)
          Une liste de ‘<fail2ban-jail-action-configuration>’.

     ‘extra-content’ (par défaut : ‘'()’) (type : text-config)
          Contenu supplémentaire pour la configuration de la prison, à
          fournir sous la forme d’une liste de simili-fichiers.

 -- Type de données : fail2ban-jail-filter-configuration
     Les champs de ‘fail2ban-jail-filter-configuration’ disponibles sont
     :

     ‘name’ (type : string)
          Filtre à utiliser.

     ‘mode’ (type : peut-être-chaine)
          Mode de filtrage.

Resize File System Service
..........................

This service type lets you resize a live file system during boot, which
can be convenient if a Guix image is flashed on an SD Card (e.g. for an
embedded device) or uploaded to a VPS. In both cases the medium the
image will reside upon may be larger than the image you want to produce.

   For an embedded device booting from an SD card you may use something
like:
     (service resize-file-system-service-type
              (resize-file-system-configuration
               (file-system
                (file-system (device (file-system-label "root"))
                             (type "ext4")))))

     Attention : Be extra cautious to use the correct device and type.
     The service has little error handling of its own and relies on the
     underlying tools. Wrong use could end in loss of data or the
     corruption of the operating system.

   Partitions and file systems are grown to the maximum size available.
File systems can only grow when they are on the last partition on a
device and have empty space available.

   This service supports the ext2, ext3, ext4, btrfs, and bcachefs file
systems.

‘file-system’ (type: file-system)
     The file-system object to resize (*note Systèmes de fichiers::).
     This object must have the ‘device’ and ‘type’ fields set. Other
     fields are ignored.

‘cloud-utils’ (default: ‘cloud-utils’) (type: file-like)
     The cloud-utils package to use. This package is used for the
     ‘growpart’ command.

‘e2fsprogs’ (default: ‘e2fsprogs’) (type: file-like)
     The e2fsprogs package to use, used for resizing ext2, ext3, and
     ext4 file systems.

‘btrfs-progs’ (default: ‘btrfs-progs’) (type: file-like)
     The btrfs-progs package to use, used for resizing the btrfs file
     system.

‘bcachefs-tools’ (default: ‘bcachefs-tools’) (type: file-like)
     The bcachefs-tools package to use, used for resizing the bcachefs
     file system.

Backup Services
...............

The ‘(gnu services backup)’ module offers services for backing up file
system trees. For now, it provides the ‘restic-backup-service-type’.

   With ‘restic-backup-service-type’, you can periodically back up
directories and files with Restic (https://restic.net/), which supports
end-to-end encryption and deduplication. Consider the following
configuration:

     (use-service-modules backup ...) ;for 'restic-backup-service-type'
     (use-package-modules sync ...)   ;for 'rclone'

     (operating-system
       ;; ...
       (packages (append (list rclone)    ;for use by restic
                         %base-packages))
       (services
         (list
           (service restic-backup-service-type
                    (restic-backup-configuration
                      (jobs
                        (list (restic-backup-job
                                (name "remote-ftp")
                                (repository "rclone:remote-ftp:backup/restic")
                                (password-file "/root/.restic")
                                ;; Every day at 23.
                                (schedule "0 23 * * *")
                                (files '("/root/.restic"
                                         "/root/.config/rclone"
                                         "/etc/ssh/ssh_host_rsa_key"
                                         "/etc/ssh/ssh_host_rsa_key.pub"
                                         "/etc/guix/signing-key.pub"
                                         "/etc/guix/signing-key.sec"))))))))))

   Each ‘restic-backup-job’ translates to a Shepherd timer which sets
the ‘RESTIC_PASSWORD’ environment variable by reading the first line of
‘password-file’ and runs ‘restic backup’, creating backups using rclone
of all the files listed in the ‘files’ field.

   The ‘restic-backup-service-type’ provides the ability to
instantaneously trigger a backup with the ‘trigger’ Shepherd action:

     sudo herd trigger remote-ftp

 -- Data Type : restic-backup-configuration
     Available ‘restic-backup-configuration’ fields are:

     ‘jobs’ (default: ‘'()’) (type: list-of-restic-backup-jobs)
          The list of backup jobs for the current system.

 -- Data Type : restic-backup-job
     Available ‘restic-backup-job’ fields are:

     ‘restic’ (default: ‘restic’) (type: package)
          The restic package to be used for the current job.

     ‘user’ (default: ‘"root"’) (type: string)
          The user used for running the current job.

     ‘group’ (default: ‘"root"’) (type: string)
          The group used for running the current job.

     ‘log-file’ (type: maybe-string)
          The file system path to the log file for this job. By default
          the file will have be ‘/var/log/restic-backup/JOB-NAME.log’,
          where JOB-NAME is the name defined in the ‘name’ field. For
          Guix Home services it defaults to
          ‘$XDG_STATE_HOME/shepherd/restic-backup/JOB-NAME.log’.

     ‘max-duration’ (type: maybe-number)
          The maximum duration in seconds that a job may last. Past
          ‘max-duration’ seconds, the job is forcefully terminated.

     ‘wait-for-termination?’ (default: ‘#f’) (type: boolean)
          Wait until the job has finished before considering executing
          it again; otherwise, perform it strictly on every occurrence
          of event, at the risk of having multiple instances running
          concurrently.

     ‘repository’ (type: string)
          The restic repository target of this job.

     ‘name’ (type : string)
          A string denoting a name for this job.

     ‘password-file’ (type: string)
          Name of the password file, readable by the configured ‘user’,
          that will be used to set the ‘RESTIC_PASSWORD’ environment
          variable for the current job.

     ‘schedule’ (type: gexp-or-string)
          A string or a gexp representing the frequency of the backup.
          Gexp must evaluate to ‘calendar-event’ records or to strings.
          Strings must contain Vixie cron date lines.

     ‘requirement’ (type: maybe-list-of-symbols)
          The list of Shepherd services that this backup job depends
          upon. When unset it defaults to ‘'()’, for Guix Home.
          Otherwise to ‘'(user-processes file-systems)’.

     ‘files’ (default: ‘'()’) (type: list-of-lowerables)
          The list of files or directories to be backed up. It must be a
          list of values that can be lowered to strings.

     ‘verbose?’ (default: ‘#f’) (type: boolean)
          Whether to enable verbose output for the current backup job.

     ‘extra-flags’ (default: ‘'()’) (type: list-of-lowerables)
          A list of values that are lowered to strings. These will be
          passed as command-line arguments to the current job ‘restic
          backup’ invocation.

DLNA/UPnP Services
..................

The ‘(gnu services upnp)’ module offers services related to UPnP
(Universal Plug and Play) and DLNA (Digital Living Network Alliance),
networking protocols that can be used for media streaming and device
interoperability within a local network. For now, this module provides
the ‘readymedia-service-type’.

   ReadyMedia (https://minidlna.sourceforge.net/) (formerly known as
MiniDLNA) is a DLNA/UPnP-AV media server. The project’s daemon,
‘minidlnad’, can serve media files (audio, pictures, and video) to
DLNA/UPnP-AV clients available on the network. ‘readymedia-service-type’
is a Guix service that wraps around ReadyMedia’s ‘minidlnad’.

   Consider the following configuration:
     (use-service-modules upnp ...)

     (operating-system
       ...
       (services
        (list (service readymedia-service-type
                       (readymedia-configuration
                        (media-directories
                         (list (readymedia-media-directory
                                (path "/media/audio")
                                (types '(A)))
                               (readymedia-media-directory
                                (path "/media/video")
                                (types '(V)))
                               (readymedia-media-directory
                                (path "/media/misc"))))
                        (extra-config '(("notify_interval" . "60")))))
              ...)))

   This sets up the ReadyMedia daemon to serve files from the media
folders specified in ‘media-directories’. The ‘media-directories’ field
is mandatory. All other fields (such as network ports and the server
name) come with a predefined default and can be omitted.

     Remarque : This service is also available for Guix Home, where it
     runs directly with your user privileges (*note
     ‘home-readymedia-service-type’: Miscellaneous Home Services.).

 -- Data Type : readymedia-configuration
     Available ‘readymedia-configuration’ fields are:

     ‘readymedia’ (default: ‘readymedia’) (type: package)
          The ReadyMedia package to be used for the service.

     ‘friendly-name’ (default: ‘#f’) (type: maybe-string)
          A custom name that will be displayed on connected clients.

     ‘media-directories’ (type: list)
          The list of media folders to serve content from. Each item is
          a ‘readymedia-media-directory’.

     ‘cache-directory’ (default: ‘"/var/cache/readymedia"’) (type: string)
          A folder for ReadyMedia’s cache files. If not existing
          already, the folder will be created as part of the service
          activation and the ReadyMedia user will be assigned ownership.

     ‘log-directory’ (default: ‘"/var/log/readymedia"’) (type: string)
          A folder for ReadyMedia’s log files. If not existing already,
          the folder will be created as part of the service activation
          and the ReadyMedia user will be assigned ownership.

     ‘port’ (default: ‘#f’) (type: maybe-integer)
          A custom port that the service will be listening on.

     ‘extra-config’ (default: ‘'()’) (type: alist)
          An association list of further options, as accepted by
          ReadyMedia.

 -- Data Type : readymedia-media-directory
     A ‘media-directories’ entry includes a folder ‘path’ and,
     optionally, the ‘types’ of media files included within the folder.

     ‘path’ (type: string)
          The media folder location.

     ‘types’ (default: ‘'()’) (type: list)
          A list indicating the types of file included in the media
          folder. Valid values are combinations of individual media
          types, i.e. symbol ‘A’ for audio, ‘P’ for pictures, ‘V’ for
          video. An empty list means that no type is specified.


File: guix.fr.info,  Node: Privileged Programs,  Next: Certificats X.509,  Prev: Services,  Up: Configuration du système

11.11 Privileged Programs
=========================

Certains programmes doivent être lancés avec des privilèges élevés même
lorsqu’ils sont lancés par un utilisateur non privilégié. Un exemple
notoire est le programme ‘passwd’, que les utilisateurs peuvent appeler
pour modifier leur mot de passe et qui doit accéder à ‘/etc/passwd’ et
‘/etc/shadow’ — ce qui est normalement réservé à root, pour des raisons
de sécurité évidentes. Pour contourner cela, ‘passwd’ devrait être
“setuid-root”, ce qui signifie qu’il sera toujours lancé avec les
privilèges root (*note (libc)How Change Persona::, pour plus
d’informations sur le mécanisme setuid).

   The store itself _cannot_ contain privileged programs: that would be
a security issue since any user on the system can write derivations that
populate the store (*note Le dépôt::). Thus, a different mechanism is
used: instead of directly granting permissions to files that are in the
store, we let the system administrator _declare_ which programs should
be entrusted with these additional privileges.

   Le champ ‘privileged-programs’ d’une déclaration ‘operating-system’
contient une liste de ‘<privileged-program>’ qui dénotent les noms des
programmes qui auront le bit setuid ou setgid (*note Utiliser le système
de configuration::). Par exemple, le programme ‘mount.nfs’, qui fait
partie du paquet nfs-utils, avec le bit setuid root, peut être désigné
comme ceci :

     (privileged-program
       (program (file-append nfs-utils "/sbin/mount.nfs"))
       (setuid? #t))

   Ensuite, pour rendre ‘mount.nfs’ setuid sur votre système, ajoutez
l’exemple précédent à votre déclaration de système d’exploitation en
l’ajoutant aux ‘%default-privileged-programs’ de cette façon :

     (operating-system
       ;; Certains champs omis...
       (privileged-programs
         (append (list (privileged-program
                         (program (file-append nfs-utils "/sbin/mount.nfs"))
                         (setuid? #t)))
                 %default-privileged-programs)))

 -- Type de données : privileged-program
     This data type represents a program with special privileges, such
     as setuid

     ‘program’
          A file-like object to which all given privileges should apply.

     ‘setuid?’ (par défaut : ‘#f’)
          Indique s’il faut activer le bit setuid.

     ‘setgid?’ (par défaut : ‘#f’)
          Indique s’il faut active le bit setgid.

     ‘user’ (par défaut : ‘0’)
          L’UID (entier) ou le nom d’utilisateur (chaîne) du
          propriétaire du programme, root par défaut.

     ‘group’ (par défaut : ‘0’)
          Le GID (entier) ou le nom du groupe (chaîne) pour le groupe
          propriétaire du programme, root par défaut.

     ‘capabilities’ (default: ‘#f’)
          A string representing the program’s POSIX capabilities, as
          described by the ‘cap_to_text(3)’ man page from the libcap
          package, or ‘#f’ to make no changes.

   A default set of privileged programs is defined by the
‘%default-privileged-programs’ variable of the ‘(gnu system)’ module.

 -- Variable : Variable Scheme %default-privileged-programs
     A list of ‘<privileged-program>’ denoting common programs with
     elevated privileges.

     La liste inclus des commandes comme ‘passwd’, ‘ping’, ‘su’ et
     ‘sudo’.

   Under the hood, the actual privileged programs are created in the
‘/run/privileged/bin’ directory at system activation time. The files in
this directory refer to the “real” binaries, which are in the store.


File: guix.fr.info,  Node: Certificats X.509,  Next: Name Service Switch,  Prev: Privileged Programs,  Up: Configuration du système

11.12 Certificats X.509
=======================

Les serveurs web disponibles par HTTPS (c’est-à-dire HTTP sur le
mécanisme de la couche de transport sécurisée, TLS) envoient aux clients
un “certificat X.509” que les clients peuvent utiliser pour
_authentifier_ le serveur. Pour cela, les clients vérifient que le
certificat du serveur est signé par une “autorité de certification” (AC
ou CA). Mais pour vérifier la signature de la CA, les clients doivent
d’abord avoir récupéré le certificat de la CA.

   Les navigateurs web comme GNU IceCat incluent leur propre liste de
certificats, pour qu’ils puissent vérifier les signatures des CA
directement.

   Cependant, la plupart des autres programmes qui peuvent parler HTTPS
— ‘wget’, ‘git’, ‘w3m’, etc — doivent savoir où trouver les certificats
des CA.

   For users of Guix System, this is done by adding a package that
provides certificates to the ‘packages’ field of the ‘operating-system’
declaration (*note référence de operating-system::). Guix includes one
such package, ‘nss-certs’, which is a set of CA certificates provided as
part of Mozilla’s Network Security Services.

   This package is part of ‘%base-packages’, so there is no need to
explicitly add it. The ‘/etc/ssl/certs’ directory, which is where most
applications and libraries look for certificates by default, points to
the certificates installed globally.

   Les utilisateurs non privilégiés, dont les utilisateurs de Guix sur
une distro externe, peuvent aussi installer leur propre paquet de
certificats dans leur profil. Un certain nombre de variables
d’environnement doivent être définies pour que les applications et les
bibliothèques puissent les trouver. En particulier, la bibliothèque
OpenSSL prend en compte les variables ‘SSL_CERT_DIR’ et ‘SSL_CERT_FILE’.
Certaines applications ajoutent leurs propres variables, par exemple le
système de contrôle de version Git prend en compte le lot de certificats
pointé par la variable d’environnement ‘GIT_SSL_CAINFO’. Ainsi, vous
lanceriez quelque chose comme ceci :

     guix install nss-certs
     export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
     export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
     export GIT_SSL_CAINFO="$SSL_CERT_FILE"

   Un autre exemple serait R, qui a besoin que la variable
d’environnement ‘CURL_CA_BUNDLE’ pointe sur le lot de certificats, donc
vous lanceriez quelque chose comme ceci :

     guix install nss-certs
     export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"

   Pour d’autres applications vous pourriez avoir besoin de chercher la
variable d’environnement requise dans leur documentation.


File: guix.fr.info,  Node: Name Service Switch,  Next: Disque de RAM initial,  Prev: Certificats X.509,  Up: Configuration du système

11.13 Name Service Switch
=========================

Le module ‘(gnu system nss)’ fournit des liaisons pour le fichier de
configuration du “name service switch” ou “NSS” de la libc (*note
(libc)NSS Configuration File::). En résumé, NSS est un mécanisme qui
permet à la libc d’être étendue avec de nouvelles méthodes de résolution
de « noms » dans les bases de données du système, comme les noms
d’hôtes, les noms des services, les comptes utilisateurs et bien plus
(*note System Databases and Name Service Switch: (libc)Name Service
Switch.).

   La configuration de NSS spécifie, pour chaque base de données du
système, quelle méthode de résolution utiliser, et comment les diverses
méthodes sont enchaînées — par exemple, sous certaines circonstances,
NSS devrait essayer la méthode suivante de la liste. La configuration de
NSS est donnée dans le champ ‘name-service-switch’ de la déclaration
‘operating-system’ (*note ‘name-service-switch’: référence de
operating-system.).

   Par exemple, la déclaration ci-dessous configure NSS pour utiliser le
moteur ‘nss-mdns’ (https://0pointer.de/lennart/projects/nss-mdns/), qui
supporte la résolution de nom d’hôte sur le DNS multicast (mDNS) pour
les noms d’hôtes terminant par ‘.local’ :

     (name-service-switch
        (hosts (list %files    ; d'abord, vérifier /etc/hosts

                     ;; Si ce qui précède n'a pas fonctionné, essayer
                     ;; avec « mdns_minimal ».
                     (name-service
                       (name "mdns_minimal")

                       ;; « mdns_minimal » fait autorité pour
                       ;; « .local ».  Lorsqu'il renvoie « pas trouvé »,
                       ;; inutile d'essayer la méthode suivante.
                       (reaction (lookup-specification
                                  (not-found => return))))

                     ;; Puis revenir sur DNS.
                     (name-service
                       (name "dns"))

                     ;; Enfin, essayer avec « mdns complet ».
                     (name-service
                       (name "mdns")))))

   Ne vous inquiétez pas : la variable ‘%mdns-host-lookup-nss’ (voir
plus bas) contient cette configuration, donc vous n’avez pas besoin de
tout taper si vous voulez simplement que la résolution de nom en
‘.local’ fonctionne.

   Remarquez que dans ce cas, en plus de mettre en place le
‘name-service-switch’ de la déclaration ‘operating-system’, vous devez
aussi utiliser ‘avahi-service-type’ (*note ‘avahi-service’: Services
réseau.), ou ‘%desktop-services’ qui l’inclut (*note Services de
bureaux::). Cela rend ‘nss-mdns’ accessible au démon de cache du service
de nom (*note ‘nscd-service’: Services de base.).

   Pour votre confort, les variables suivantes contiennent des
configurations NSS typiques.

 -- Variable : %default-nss
     C’est la configuration NSS par défaut, un objet
     ‘name-service-switch’.

 -- Variable : %mdns-host-lookup-nss
     C’est la configuration NSS avec le support de la résolution de noms
     sur DNS multicast (mDNS) pour les noms d’hôtes en ‘.local’.

   Furthermore, mDNS lookups could be restricted to IPv4 or IPv6
protocols using the procedure ‘mdns-host-lookup-nss’.

 -- Procedure : mdns-host-lookup-nss [#:ipv6? #t] [#:ipv4? #t] Return a
          name-service-switch object with
     mDNS lookup restricted to specified protocols.

   La référence pour la configuration de NSS est donnée ci-dessous.
C’est une correspondance directe avec le format de fichier de la
bibliothèque C, donc référez-vous au manuel de la bibliothèque C pour
plus d’informations (*note (libc)NSS Configuration File::). Comparé au
format de fichier de configuration de NSS, cette configuration a
l’avantage non seulement d’ajouter ces bonnes vieilles parenthèses, mais
aussi des vérifications statiques ; vous saurez s’il y a des erreurs de
syntaxe et des coquilles dès que vous lancerez ‘guix system’.

 -- Type de données : name-service-switch

     C’est le type de données représentant la configuration de NSS.
     Chaque champ ci-dessous représente l’un des système de bases de
     données supportés.

     ‘aliases’
     ‘ethers’
     ‘group’
     ‘gshadow’
     ‘hosts’
     ‘initgroups’
     ‘netgroup’
     ‘networks’
     ‘password’
     ‘public-key’
     ‘rpc’
     ‘services’
     ‘shadow’
          Les bases de données du système gérées par NSS. Chaque champ
          doit être une liste d’objets ‘<name-service>’ (voir plus bas).

 -- Type de données : name-service

     C’est le type de données représentant un service de noms et
     l’action de résolution associée.

     ‘name’
          Une chaîne dénotant le service de nom (*note (libc)Services in
          the NSS configuration::).

          Remarquez que les services de dnoms listés ici doivent être
          visibles à nscd. Cela se fait en passant la liste des paquets
          fournissant les services de noms à l’argument
          ‘#:name-services’ de ‘nscd-service’ (*note ‘nscd-service’:
          Services de base.).

     ‘reaction’
          Une action spécifiée par la macro ‘lookup-specification’
          (*note (libc)Actions in the NSS configuration::). Par exemple
          :

               (lookup-specification (unavailable => continue)
                                     (success => return))


File: guix.fr.info,  Node: Disque de RAM initial,  Next: Configuration du chargeur d'amorçage,  Prev: Name Service Switch,  Up: Configuration du système

11.14 Disque de RAM initial
===========================

Pour l’amorçage, on passe au noyau Linux-Libre un “disque de RAM
initial” ou “initrd”. Un initrd contient un système de fichier racine
temporaire ainsi qu’un script d’initialisation. Ce dernier est
responsable du montage du vrai système de fichier racine et du
chargement des modules du noyau qui peuvent être nécessaires à cette
tâche.

   Le champ ‘initrd-modules’ d’une déclaration ‘operating-system’ vous
permet de spécifier les modules du noyau Linux-Libre qui doivent être
disponibles dans l’initrd. En particulier, c’est là où vous devez lister
les modules requis pour effectivement piloter le disque dur où se trouve
la partition racine — bien que la valeur par défaut de ‘initrd-modules’
couvre la plupart des cas. Par exemple, en supposant que vous ayez
besoin du module ‘megaraid_sas’ en plus des modules par défaut pour
accéder à votre système de fichiers racine, vous écririez :

     (operating-system
       ;; ...
       (initrd-modules (cons "megaraid_sas" %base-initrd-modules)))

 -- Variable : %base-initrd-modules
     C’est la liste des modules du noyau inclus dans l’initrd par
     défaut.

   En plus, si vous avez besoin de paramétrages plus bas niveau, le
champ ‘initrd’ d’une déclaration ‘operating-system’ vous permet de
spécifier quel initrd vous voudriez utiliser. Le module ‘(gnu system
linux-initrd)’ fournit trois manières de construire un initrd : la
procédure ‘base-initrd’ de haut niveau et les procédures ‘raw-initrd’ et
‘expression->initrd’ de bas niveau.

   La procédure ‘base-initrd’ est conçue pour couvrir la plupart des
usages courants. Par exemple, si vous voulez ajouter des modules du
noyau à charger au démarrage, vous pouvez définir le champ ‘initrd’ de
votre déclaration de système d’exploitation ainsi :

     (initrd (lambda (file-systems . rest)
               ;; Crée un initrd standard mais paramètre le réseau
               ;; avec les paramètres que QEMU attend par défaut.
               (apply base-initrd file-systems
                      #:qemu-networking? #t
                      rest)))

   La procédure ‘base-initrd’ gère aussi les cas d’utilisation courants
qui concernent l’utilisation du système comme client QEMU, ou comme un
système « live » avec un système de fichier racine volatile.

   La procédure ‘base-initrd’ est construite à partir de la procédure
‘raw-initrd’. Contrairement à ‘base-initrd’, ‘raw-initrd’ ne fait rien à
haut-niveau, comme essayer de deviner les modules du noyau et les
paquets qui devraient être inclus dans l’initrd. Un exemple
d’utilisation de ‘raw-initrd’ serait si un utilisateur a une
configuration personnalisée du noyau Linux et que les modules du noyau
inclus par défaut par ‘base-initrd’ ne sont pas disponibles.

   Le disque de RAM initial produit par ‘base-initrd’ ou ‘raw-initrd’
prend en compte plusieurs options passées par la ligne de commande du
noyau Linux (c’est-à-dire les arguments passés via la commande ‘linux’
de GRUB ou l’option ‘-append’ de QEMU), notamment :

‘gnu.load=BOOT’
     Dit au disque de RAM initial de charger BOOT, un fichier contenant
     un programme Scheme, une fois qu’il a monté le système de fichier
     racine.

     Guix utilise cette option pour donner le contrôle à un programme de
     démarrage qui lance les programmes d’activation de services puis
     démarre le GNU Shepherd, le système d’initialisation.

‘root=ROOT’
     Monte ROOT comme système de fichier racine. ROOT peut être un nom
     de périphérique comme ‘/dev/sda1’, une étiquette de système de
     fichiers ou un UUID de système de fichiers. Lorsque ce n’est pas
     spécifié, le nom de périphérique du système de fichier racine de la
     déclaration de système d’exploitation est utilisé.

‘rootfstype=TYPE’
     Indique le type du système de fichiers racine. Il remplace le champ
     ‘type’ du système de fichiers racine spécifié dans la déclaration
     ‘operating-system’, s’il existe.

‘rootflags=OPTIONS’
     Indique les _options_ de montage du système de fichiers racine.
     Elles remplacent le champ ‘options’ du système de fichiers racine
     spécifié dans la déclaration ‘operating-system’ s’il existe.

‘fsck.mode=MODE’
     Contrôle s’il faut vérifier ou pas le système de fichier ROOT avant
     de le monter. MODE peut valoir ‘skip’ (ne jamais vérifier), ‘force’
     (toujours vérifier), ou ‘auto’ pour respecter le réglage ‘check?’
     de l’objet ‘<file-system>’ pour la racine (*note Systèmes de
     fichiers::) et n’exécuter une analyse complète que si le système de
     fichier n’a pas été éteint proprement.

     ‘auto’ est la valeur par défaut si cette option n’est pas
     renseignée ou si MODE n’a pas l’une des valeurs ci-dessus.

‘fsck.repair=NIVEAU’
     Le niveau de réparation à effectuer automatiquement si des erreurs
     sont détectées dans le système de fichier ROOT. LEVEL prend les
     valeurs ‘no’ (ne pas écrire du tout sur ROOT si possible), ‘yes’
     (réparer autant que possible), ou ‘preen’ pour réparer les
     problèmes considérés réparables automatiquement sans risque.

     ‘preen’ est la valeur par défaut si cette option n’est pas
     renseignée ou si LEVEL n’est pas l’une des valeurs ci-dessus.

‘gnu.system=SYSTÈME’
     S’assure que ‘/run/booted-system’ et ‘/run/current-system’ pointent
     vers SYSTEM.

‘modprobe.blacklist=MODULES...’
     Dit au disque de RAM initial ainsi qu’à la commande ‘modprobe’ (du
     paquet kmod) de refuser de charger MODULES. MODULES doit être une
     liste de noms de modules séparés par des virgules — p. ex.
     ‘usbkbd,9pnet’.

‘gnu.repl’
     Démarre une boucle lecture-évaluation-affichage (REPL) depuis le
     disque de RAM initial avant qu’il n’essaye de charger les modules
     du noyau et de monter le système de fichiers racine. Notre équipe
     commerciale appelle cela “boot-to-Guile”. Le Schemeur en vous va
     adorer. *Note (guile)Using Guile Interactively::, pour plus
     d’information sur le REPL de Guile.

   Maintenant que vous connaissez toutes les fonctionnalités des disques
de RAM initiaux produits par ‘base-initrd’ et ‘raw-initrd’, voici
comment l’utiliser le personnalisé plus avant.

 -- Procédure : raw-initrd file-systems [#:linux-modules '()]
          [#:pre-mount #t] [#:mapped-devices '()] [#:keyboard-layout #f]
          [#:helper-packages '()] [#:qemu-networking? #f]
          [#:volatile-root? #f]
     Renvoie une dérivation qui construit un initrd. FILE-SYSTEMS est
     une liste de systèmes de fichiers à monter par l’initrd,
     éventuellement en plus du système de fichier racine spécifié sur la
     ligne de commande du noyau via ‘root’. LINUX-MODULES est une liste
     de modules du noyau à charger à l’amorçage. MAPPED-DEVICES est une
     liste de correspondances de périphériques à réaliser avant que les
     FILE-SYSTEMS ne soient montés (*note Périphériques mappés::).
     HELPER-PACKAGES est une liste de paquets à copier dans l’initrd.
     Elle peut inclure ‘e2fsck/static’ ou d’autres paquets requis par
     l’initrd pour vérifier le système de fichiers racine.

     Lorsque la valeur est vraie, KEYBOARD-LAYOUT est un enregistrement
     ‘<keyboard-layout>’ dénotant la disposition du clavier désirée pour
     la console. Cela est effectuée avant que les MAPPED-DEVICES ne
     soient créés et avant que les FILE-SYSTEMS ne soient montés, de
     sorte que, si l’utilisateur au besoin de saisir une phrase de passe
     ou d’utiliser le REPL, cela arrive avec la disposition du clavier
     voulue.

     When QEMU-NETWORKING? is true, set up networking with the standard
     QEMU parameters.

     Lorsque VOLATILE-ROOT? est vrai, le système de fichier racine est
     inscriptible mais tous les changements seront perdus.

 -- Procédure : base-initrd file-systems [#:mapped-devices '()]
          [#:keyboard-layout #f] [#:qemu-networking? #f]
          [#:volatile-root? #f] [#:linux-modules '()]
     Renvoie un objet simili-fichier contenant un initrd générique, avec
     les modules du noyau de LINUX. FILE-SYSTEMS est une liste de
     systèmes de fichiers à monter par l’initrd, éventuellement en plus
     du système de fichiers racine spécifié sur la ligne de commande du
     noyau via ‘root’. MAPPED-DEVICES est une liste de correspondances
     de périphériques à réaliser avant de monter les FILE-SYSTEMS.

     Lorsque la valeur est vraie, KEYBOARD-LAYOUT est un enregistrement
     ‘<keyboard-layout>’ dénotant la disposition du clavier désirée pour
     la console. Cela est effectuée avant que les MAPPED-DEVICES ne
     soient créés et avant que les FILE-SYSTEMS ne soient montés, de
     sorte que, si l’utilisateur au besoin de saisir une phrase de passe
     ou d’utiliser le REPL, cela arrive avec la disposition du clavier
     voulue.

     QEMU-NETWORKING? et VOLATILE-ROOT? se comportent comme pour
     ‘raw-initrd’.

     L’initrd est automatiquement remplie avec tous les modules du noyau
     requis pour FILE-SYSTEMS et pour les options données. On peut
     lister des modules supplémentaires dans LINUX-MODULES. Ils seront
     ajoutés à l’initrd et chargés à l’amorçage dans l’ordre dans lequel
     ils apparaissent.

   Inutile de le dire, les initrds que nous produisons et utilisons
incluent une version de Guile liée statiquement, et le programme
d’initialisation est un programme Guile. Cela donne beaucoup de
flexibilité. La procédure ‘expression->initrd’ construit un tel initrd,
étant donné le programme à lancer dans cet initrd.

 -- Procédure : expression->initrd exp [#:guile %guile-static-initrd]
          [#:name "guile-initrd"]
     Renvoie un objet simili-fichier contenant un initrd Linux (une
     archive cpio compressée avec gzip) contenant GUILE et qui évalue
     EXP, une G-expression, au démarrage. Toutes les dérivations
     référencées par EXP sont automatiquement copiées dans l’initrd.


File: guix.fr.info,  Node: Configuration du chargeur d'amorçage,  Next: Invoquer guix system,  Prev: Disque de RAM initial,  Up: Configuration du système

11.15 Configuration du chargeur d’amorçage
==========================================

Le système d’exploitation supporte plusieurs chargeurs d’amorçage. La
configuration du chargeur d’amorçage se fait avec la déclaration
‘bootloader-configuration’. Tous les champs de cette structure sont
indépendants du chargeur d’amorçage sauf un, ‘bootloader’ qui indique le
chargeur d’amorçage à configurer et à installer.

   Certains chargeurs d’amorçage ne prennent pas en compte tous les
champs de ‘bootloader-configuration’. Par exemple, le chargeur
d’amorçage extlinux ne supporte pas les thèmes et ignore donc le champ
‘theme’.

 -- Type de données : bootloader-configuration
     Le type d’une déclaration de configuration de chargeur d’amorçage.

     ‘bootloader’
          Le chargeur d’amorçage à utiliser, en tant qu’objet
          ‘bootloader’. Pour l’instant ‘grub-bootloader’,
          ‘grub-efi-bootloader’, ‘grub-efi-removable-bootloader’,
          ‘gru-efi-netboot-bootloader’,
          ‘grub-efi-netboot-removable-bootloader’, ‘extlinux-bootloader’
          et ‘u-boot-bootloader’ sont pris en charge.

          Les chargeurs d’amorçage disponibles sont décrits dans les
          modules ‘(gnu bootloader ...)’. En particulier, ‘(gnu
          bootloader u-boot)’ contient des définitions de chargeurs
          d’amorçage pour une large gamme de systèmes ARM et AArch, à
          l’aide du chargeur d’amorçage U-Boot
          (https://www.denx.de/wiki/U-Boot/).

          ‘grub-bootloader’ vous permet de démarrer en particulier sur
          des machines Intel en mode BIOS « legacy ».

          ‘grub-efi-bootloader’ permet de démarrer sur un système
          moderne qui utilise l’UEFI (“Unified Extensible Firmware
          Interface”). C’est ce que vous devriez utiliser si l’image
          d’installation contient un répertoire ‘/sys/firmware/efi’
          lorsque vous démarrez dessus sur votre machine.

          ‘grub-efi-removable-bootloader’ vous permet de démarrer votre
          système à partir d’un média amovible en écrivant le fichier
          GRUB à l’emplacement spécifié par UEFI ‘/EFI/BOOT/BOOTX64.efi’
          du répertoire d’amorçage, typiquement ‘/boot/efi’. C’est aussi
          utile pour certains micrologiciels UEFI qui « oublient » la
          configuration de leur stockage non-volatile. Comme pour
          ‘grub-efi-bootloader’, cela peut aussi être utilisé si le
          répertoire ‘/sys/firmware/efi’ est disponible.

               Remarque : Cela _remplacera_ le fichier GRUB des autres
               systèmes d’exploitation qui placent aussi un fichier GRUB
               dans l’emplacement spécifié par UEFI. Cela les rends
               impossible à démarrer.

          ‘grub-efi-netboot-bootloader’ vous permet de démarrer votre
          système via le réseau avec TFTP. En plus d’un système de
          fichier racine NFS, cela vous permet de démarrer un système
          Guix sans disque.

          L’installation de ‘ggrub-efi-netboot-bootloader’ génère le
          contenu du répertoire racine TFTP sur ‘targets’ (*note
          ‘targets’: Configuration du chargeur d'amorçage.) sous le
          répertoire ‘efi/Guix’, qui sera servi par un serveur TFTP.
          Vous pouvez maintenant monter les répertoires du serveur TFTP
          directement sur ‘targets’ pour déplacer les fichiers requis
          vers le serveur TFTP automatiquement pendant l’installation.

          Si vous voulez aussi utiliser un système de fichier racine NFS
          (en fait si vous montez le dépôt depuis un partage NFS), alors
          le serveur TFTP doit aussi servir le fichier
          ‘/boot/grub/grub.cfg’ et d’autres fichiers à partir du dépôt
          (comme l’image de fond de GRUB, le noyau (*note ‘kernel’:
          référence de operating-system.) et l’initrd (*note ‘initrd’:
          référence de operating-system.)). Tous ces fichiers du dépôt
          seront accessibles pour GRUB à travers TFTP avec leurs chemins
          normaux, par exemple
          ‘tftp://tftp-server/gnu/store/…-initrd/initrd.cpio.gz’.

          Deux liens symboliques sont créés pour rendre cela possible.
          Pour chaque cible du champ ‘targets’, le premier lien est
          ‘target’‘/efi/Guix/boot/grub/grub.cfg’ pointant vers
          ‘../../../boot/grub/grub.cfg’, où ‘target’ peut être ‘/boot’.
          Dans ce cas le lien ne quitte pas le répertoire racine du
          serveur TFTP. Le second lien est ‘target’‘/gnu/store’ qui
          pointe vers ‘../gnu/store’. Ce lien est en dehors du
          répertoire racine du serveur TFTP.

          L’hypothèse derrière tout ceci est que vous avez un serveur
          NFS qui exporte le système de fichiers racine de votre système
          Guix, et en plus, un serveur TFTP qui exporte vos répertoires
          ‘targets’ — habituellement ‘/boot’ uniquement — à partir du
          même système de fichiers racine que votre système Guix. Dans
          ce cas les liens symboliques vont fonctionner.

          Pour d’autres cas vous devrez programmer votre propre
          installateur de chargeur d’amorçage qui rende les fichiers
          nécessaires du dépôt disponibles à travers TFTP, par exemple
          en les copiant vers la racine du répertoire de TFTP pour vos
          ‘targets’.

          Il est important de remarquer que les liens symboliques
          pointant hors du répertoire racine de TFTP peuvent ne pas être
          permis par dans configuration de votre serveur TFTP. De plus
          le lien vers le dépôt expose la totalité de celui-ci à travers
          TFTP. Ces deux points sont à prendre en compte pour les
          aspects de sécurité. Nous vous conseillons de désactiver tout
          accès TFTP en écriture !

          Remarquez que ce chargeur d’amorçage ne modifiera pas le «
          gestionnaire de d’amorçage UEFI » du système.

          En dehors de ‘grub-efi-netboot-bootloader’, des serveurs TFTP
          et NFS déjà mentionnés, vous pouvez utiliser un serveur DHCP
          correctement configuré pour permettre l’amorçage réseau. Pour
          cela nous ne pouvons que vous recommander de regarder les
          instructions sur PXE (Preboot eXecution Environment).

          Si une partition système EFI (ESP) ou une partition similaire
          avec un système de fichiers FAT est montée dans ‘targets’,
          alors le liens symboliques ne peuvent pas être créés. Dans ce
          cas tout sera préparé pour l’amorçage à partir du stockage
          local, de la même manière que ‘grub-efi-bootloader’, à la
          différence que tous les binaires GRUB sont copiés dans
          ‘targets’, ce qui est nécessaire pour démarrer depuis le
          réseau.

          ‘grub-efi-netboot-removable-bootloader’ est identique à
          ‘grub-efi-netboot-bootloader’ en dehors du fait que le
          sous-répertoire ‘efi/boot’ sera utilisé au lieu de ‘efi/Guix’
          pour se conformer aux spécifications UEFI pour les média
          amovibles.

               Remarque : Cela _remplacera_ le fichier GRUB des autres
               systèmes d’exploitation qui placent aussi un fichier GRUB
               dans l’emplacement spécifié par UEFI. Cela les rends
               impossible à démarrer.

     ‘targets’
          C’est une liste de chaînes qui dénotent les cibles sur
          lesquelles installer le chargeur d’amorçage.

          L’interprétation des cibles dépend du chargeur d’amorçage en
          question. Pour ‘grub-bootloader’ par exemple, cela devrait
          être le nom des périphériques compris par la commande
          ‘installer’ du chargeur d’amorçage, comme ‘/dev/sda’ ou
          ‘(hd0)’ (*note (grub)Invoking grub-install::). Pour
          ‘grub-efi-bootloader’ et ‘grub-efi-removable-bootloader’, cela
          devrait être les points de montage des systèmes de fichiers
          EFI, typiquement ‘/boot/efi’. Pour
          ‘grub-efi-netboot-bootloader’, ‘targets’ doit contenir les
          points de montage correspondant aux répertoires racines de
          TFTP sur votre serveur TFTP.

     ‘menu-entries’ (par défaut : ‘'()’)
          Une liste éventuellement vide d’objets ‘menu-entry’ (voir plus
          bas), dénotant les entrées qui doivent apparaître dans le menu
          du chargeur d’amorçage, en plus de l’entrée pour le système
          actuel et l’entrée pointant vers les générations précédentes.

     ‘default-entry’ (par défaut : ‘0’)
          L’index de l’entrée du menu d’amorçage par défaut. L’index 0
          correspond au système actuel.

     ‘timeout’ (par défaut : ‘5’)
          Le nombre de secondes à attendre une entrée clavier avant de
          démarrer. Indiquez 0 pour démarre immédiatement, et -1 pour
          attendre indéfiniment.

     ‘keyboard-layout’ (par défaut : ‘#f’)
          Si c’est ‘#f’, le menu du chargeur d’amorçage (s’il y en a un)
          utilise la disposition du clavier par défaut, normalement pour
          l’anglais américain (« qwerty »).

          Sinon, cela doit être un objet ‘keyboard-layout’ (*note
          Disposition du clavier::).

               Remarque : Cette option est actuellement ignorée par les
               chargeurs d’amorçage autre que ‘grub’ et ‘grub-efi’.

     ‘theme’ (par défaut : #F)
          L’objet de thème du chargeur d’amorçage décrivant le thème
          utilisé. Si aucun thème n’est fournit, certains chargeurs
          d’amorçage peuvent utiliser un thème par défaut, c’est le cas
          de GRUB.

     ‘terminal-outputs’ (par défaut : ‘'(gfxterm)’)
          Les terminaux de sortie utilisés par le menu d’amorçage du
          chargeur d’amorçage, en tant que liste de symboles. GRUB
          accepte les valeurs ‘console’, ‘serial’, ‘serial_{0-3}’,
          ‘gfxterm’, ‘vga_text’, ‘mda_text’, ‘morse’ et ‘pkmodem’. Ce
          champ correspond à la variable GRUB ‘GRUB_TERMINAL_OUTPUT’
          (*note (grub)Simple configuration::).

     ‘terminal-inputs’ (par défaut : ‘'()’)
          Les terminaux d’entrée utilisés par le menu d’amorçage du
          chargeur d’amorçage, en tant que liste de symboles. Pour GRUB,
          la valeur par défaut est le terminal natif de la plate-forme
          déterminé à l’exécution. GRUB accepte les valeurs ‘console’,
          ‘serial’, ‘serial_{0-3}’, ‘at_keyboard’ et ‘usb_keyboard’. Ce
          champ correspond à la variable GRUB ‘GRUB_TERMINAL_INPUT’
          (*note (grub)Simple configuration::).

     ‘serial-unit’ (par défaut : ‘#f’)
          L’unitié série utilisée par le chargeur d’amorçage, en tant
          qu’entier entre 0 et 3. Pour GRUB, il est choisi à
          l’exécution ; actuellement GRUB choisi 0, ce qui correspond à
          COM1 (*note (grub)Serial terminal::).

     ‘serial-speed’ (par défaut : ‘#f’)
          La vitesse de l’interface série, en tant qu’entier. Pour GRUB,
          la valeur par défaut est choisie à l’exécution ; actuellement
          GRUB choisi 9600 bps (*note (grub)Serial terminal::).

     ‘device-tree-support?’ (par défaut : ‘#t’)
          Indique s’il faut prendre en charge le chargement des fichiers
          device tree (https://en.wikipedia.org/wiki/Devicetree) de
          Linux.

          Cette option est activée par défaut. Dans certains cas qui
          impliquent le chargeur d’amorçage ‘u-boot’, où l’arborescence
          de l’appareil est déjà chargée en RAM, il peut être pratique
          de désactiver cette option en indiquant ‘#f’.

     ‘extra-initrd’ (default: ‘#f’)
          File name of an additional initrd to load during the boot. It
          may or may not point to a file in the store, but the main use
          case is for out-of-store files containing secrets.

          In order to be able to provide decryption keys for LUKS
          devices, they need to be available in the initial RAM disk.
          However they cannot be stored inside the usual initrd, since
          it is stored in the store and being world-readable (as files
          in the store are) is not a desired property for an initrd
          containing decryption keys. You can therefore use this field
          to instruct GRUB to also load a manually created initrd not
          stored in the store.

          For any use case not involving secrets, you should use regular
          initrd (*note ‘initrd’: référence de operating-system.)
          instead.

          Suitable image can be created for example like this:

               echo /key-file.bin | cpio -oH newc >/key-file.cpio
               chmod 0000 /key-file.cpio

          After it is created, you can use it in this manner:

               ;; Operating system with encrypted boot partition
               (operating-system
                 ...
                 (bootloader (bootloader-configuration
                              (bootloader grub-efi-bootloader)
                              (targets '("/boot/efi"))
                              ;; Load the initrd with a key file...
                              (extra-initrd "/key-file.cpio")))
                 (mapped-devices
                  (list (mapped-device
                         (source (uuid "12345678-1234-1234-1234-123456789abc"))
                         (target "my-root")
                         (type luks-device-mapping)
                         ;; ... and use it to unlock the root device.
                         (arguments '(#:key-file "/key-file.bin"))))))

          Be careful when using this option, since pointing to a file
          that is not readable by the grub while booting will cause the
          boot to fail and require a manual edit of the initrd line in
          the grub menu.

          Currently only supported by GRUB.

   Si vous voulez lister des entrées du menu d’amorçage supplémentaires
via le champ ‘menu-entries’ ci-dessus, vous devrez les créer avec la
forme ‘menu-entry’. Par exemple, imaginons que vous souhaitiez pouvoir
démarrer sur une autre distro (c’est difficile à concevoir !), vous
pourriez alors définir une entrée du menu comme ceci :

     (menu-entry
       (label "L'autre distro")
       (linux "/boot/old/vmlinux-2.6.32")
       (linux-arguments '("root=/dev/sda2"))
       (initrd "/boot/old/initrd"))

   Les détails suivent.

 -- Type de données : menu-entry
     Le type d’une entrée dans le menu du chargeur d’amorçage.

     ‘label’
          L’étiquette à montrer dans le menu — p. ex. ‘"GNU"’.

     ‘linux’ (par défaut : ‘#f’)
          L’image du noyau Linux à démarrer, par exemple :

               (file-append linux-libre "/bzImage")

          Pour GRUB, il est aussi possible de spécifier un périphérique
          explicitement dans le chemin de fichier avec la convention de
          nommage de GRUB (*note (grub)Naming convention::), par exemple
          :

               "(hd0,msdos1)/boot/vmlinuz"

          Si le périphérique est spécifié explicitement comme au-dessus,
          le champ ‘device’ est complètement ignoré.

     ‘linux-arguments’ (par défaut : ‘'()’)
          La liste des arguments de la ligne de commande du noyau
          supplémentaires — p. ex. ‘'("console=ttyS0")’.

     ‘initrd’ (par défaut : ‘#f’)
          Une G-expression ou une chaîne dénotant le nom de fichier du
          disque de RAM initial à utiliser (*note G-Expressions::).

     ‘device’ (par défaut : ‘#f’)
          Le périphérique où le noyau et l’initrd se trouvent — c.-à-d.
          pour GRUB, l’option “root” de cette entrée de menu (*note
          (grub)root::).

          Cela peut être une étiquette de système de fichiers (une
          chaîne), un UUID de système de fichiers (un vecteur d’octets,
          *note Systèmes de fichiers::) ou ‘#f’, auquel cas le chargeur
          d’amorçage recherchera le périphérique contenant le fichier
          spécifié par le champ ‘linux’ (*note (grub)search::). Cela ne
          doit _pas_ être un nom de périphérique donné par l’OS comme
          ‘/dev/sda1’.

     ‘multiboot-kernel’ (par défaut : ‘#f’)
          Le noyau à démarrer en mode Multiboot (*note
          (grub)multiboot::). Lorsque ce champ est spécifié, une entrée
          de menu Multiboot est générée. Par exemple :

               (file-append mach "/boot/gnumach")

     ‘multiboot-arguments’ (par défaut : ‘'()’)
          Liste d’arguments de la ligne de commande supplémentaires pour
          le multiboot-kernel.

          For example, when running in QEMU it can be useful to use a
          text-based console (use options ‘--nographic’ ‘--serial
          mon:stdio’):

               '("console=com0")

          To use the new and still experimental rumpdisk user-level disk
          driver (https://darnassus.sceen.net/~hurd-web/rump_kernel/)
          instead of GNU Mach’s in-kernel IDE driver, set
          ‘kernel-arguments’ to:

               '("noide")

          Of course, these options can be combined:

               '("console=com0" "noide")

     ‘multiboot-modules’ (par défaut : ‘'()’)
          Liste de commandes pour charger les modules Multiboot. Par
          exemple :

               (list (list (file-append hurd "/hurd/ext2fs.static") "ext2fs"
                            ...)
                     (list (file-append libc "/lib/ld.so.1") "exec"
                            ...))

     ‘chain-loader’ (par défaut : ‘#f’)
          Une chaine qui peut être acceptée par la directive
          ‘chainloader’ de ‘grub’. Cela n’a aucun effet si le champ
          ‘linux’ ou ‘multiboot-kernel’ est renseigné. Voici un exemple
          de chargement chainé d’un autre système GNU/Linux.

               (bootloader
                (bootloader-configuration
                 ;; ...
                 (menu-entries
                  (list
                   (menu-entry
                    (label "GNU/Linux")
                    (device (uuid "1C31-A17C" 'fat))
                    (chain-loader "/EFI/GNULinux/grubx64.efi"))))))

   Pour l’instant seul GRUB prend en charge les thèmes. On crée un thème
GRUB avec la forme ‘grub-theme’, qui n’est pas encore complètement
documentée.

 -- Type de données : grub-theme
     Type de données représentant la configuration du thème GRUB.

     ‘gfxmode’ (par défaut : ‘'("auto")’)
          Le ‘gfxmode’ de GRUB à utiliser (une liste de chaines de
          résolution d’écran, *note (grub)gfxmode::).

 -- Procédure : grub-theme
     Renvoie le thème par défaut de GRUB utilisé par le système
     d’exploitation si aucun champ ‘theme’ n’est spécifié dans
     l’enregistrement ‘bootloader-configuration’.

     Il contient une image de fond sympathique avec les logos de GNU et
     de Guix.

   Par exemple, pour changer la résolution par défaut, vous pouvez
utiliser quelque chose comme

     (bootloader
      (bootloader-configuration
      ;; ...
      (theme (grub-theme
              (inherit (grub-theme))
              (gfxmode '("1024x786x32" "auto"))))))


File: guix.fr.info,  Node: Invoquer guix system,  Next: Invoquer guix deploy,  Prev: Configuration du chargeur d'amorçage,  Up: Configuration du système

11.16 Invoquer ‘guix system’
============================

Une fois que vous avez écrit une déclaration de système d’exploitation
comme nous l’avons vu dans les sections précédentes, elle peut être
instanciée avec la commande ‘guix system’. Voici le résumé de la
commande :

     guix system OPTIONS... ACTION FILE

   FILE doit être le nom d’un fichier contenant une déclaration
‘operating-system’. ACTION spécifie comment le système d’exploitation
est instancié. Actuellement les valeurs suivantes sont supportées :

‘search’
     Affiche les définitions des types de services disponibles qui
     correspondent aux expressions régulières données, triées par
     pertinence :

          $ guix system search console
          name: console-fonts
          location: gnu/services/base.scm:806:2
          extends: shepherd-root
          description: Install the given fonts on the specified ttys (fonts are per
          + virtual console on GNU/Linux).  The value of this service is a list of
          + tty/font pairs.  The font can be the name of a font provided by the `kbd'
          + package or any valid argument to `setfont', as in this example:
          +
          +      '(("tty1" . "LatGrkCyr-8x16")
          +        ("tty2" . (file-append
          +                      font-tamzen
          +                      "/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
          +        ("tty3" . (file-append
          +                      font-terminus
          +                      "/share/consolefonts/ter-132n"))) ; for HDPI
          relevance: 9

          name: mingetty
          location: gnu/services/base.scm:1190:2
          extends: shepherd-root
          description: Provide console login using the `mingetty' program.
          relevance: 2

          name: login
          location: gnu/services/base.scm:860:2
          extends: pam
          description: Provide a console log-in service as specified by its
          + configuration value, a `login-configuration' object.
          relevance: 2

          ...

     Comme pour ‘guix package --search’, le résultat est écrit au format
     ‘recutils’, ce qui rend facile le filtrage de la sortie (*note GNU
     recutils databases: (recutils)Top.).

‘edit’
     Modifier ou visualiser la définition d’un type de service donné.

     Par exemple, la commande plus bas ouvre votre éditeur, spécifié par
     la variable d’environnement ‘EDITOR’, sur la définition du type de
     service ‘openssh’ :

          guix system edit openssh

‘reconfigure’
     Construit le système d’exploitation décrit dans FILE, l’active et
     passe dessus(1).

          Remarque : Il est grandement recommandé de lancer ‘guix pull’
          une fois avant de lancer ‘guix system reconfigure’ pour la
          première fois (*note Invoquer guix pull::). Sans cela, vous
          verriez une version plus ancienne de Guix une fois
          ‘reconfigure’ terminé.

     This effects all the configuration specified in FILE: user
     accounts, system services, global package list, privileged
     programs, etc. The command starts system services specified in FILE
     that are not currently running; if a service is currently running
     this command will arrange for it to be upgraded the next time it is
     stopped (e.g. by ‘herd stop X’ or ‘herd restart X’).

     Cette commande crée une nouvelle génération dont le numéro est un
     de plus que la génération actuelle (rapportée par ‘guix system
     list-generations’). Si cette génération existe déjà, elle sera
     réécrite. Ce comportement correspond à celui de ‘guix package’
     (*note Invoquer guix package::).

     Elle ajoute une entrée de menu du chargeur d’amorçage pour la
     nouvelle configuration, à moins que ‘--no-bootloader’ ne soit
     passé. Pour GRUB, elle déplace les entrées pour les anciennes
     configurations dans un sous-menu, ce qui vous permet de choisir une
     ancienne génération à l’amorçage si vous en avez besoin.

     On Linux, ‘guix system reconfigure’ also loads the new system for
     fast reboot via kexec: running ‘reboot --kexec’ will boot the new
     system by directly executing its kernel, thus bypassing the BIOS
     initialization phase and bootloader (*note (shepherd)Invoking
     reboot::). You can avoid this behavior by passing the ‘--no-kexec’
     option.

     À la fin, le nouveau système d’exploitation est déployé dans
     ‘/run/current-system’. Ce répertoire contient les “métadonnées de
     provenance” : la liste des canaux utilisés (*note Canaux::) et
     FICHIER lui-même, s’il est disponible. Vous pouvez les voir avec :

          guix system describe

     Cette information est utile si vous voulez plus tard inspecter
     comment une génération particulière a été construite. En fait, en
     supposant que FILE est auto-contenu, vous pouvez reconstruire la
     génération N de votre système d’exploitation avec :

          guix time-machine \
            -C /var/guix/profiles/system-N-link/channels.scm -- \
            system reconfigure \
            /var/guix/profiles/system-N-link/configuration.scm

     Vous pouvez considérer cela comme une sorte de contrôle de version
     intégré ! Votre système n’est pas seulement un artéfact binaire :
     _il contient ses propres sources_. *Note ‘provenance-service-type’:
     Référence de service, pour plus d’informations sur le suivi de
     provenance.

     Par défaut, ‘reconfigure’ _vous empêche de faire revenir en arrière
     votre système_, ce qui pourrait (ré)introduire des vulnérabilités
     de sécurité et cause des problèmes avec les services « avec état »
     comme les systèmes de gestion de bases de données. Vous pouvez
     contrôler ce comportement en passant ‘--allow-downgrades’.

‘switch-generation’
     Passe à une génération existante du système. Cette action change
     automatiquement le profil système vers la génération spécifiée.
     Elle réarrange aussi les entrées existantes du menu du chargeur
     d’amorçage du système. Elle fait de l’entrée du menu pour la
     génération spécifiée l’entrée par défaut et déplace les entrées
     pour les autres générations dans un sous-menu, si cela est pris en
     charge par le chargeur d’amorçage utilisé. Lors du prochain
     amorçage du système, la génération du système spécifiée sera
     utilisée.

     Le chargeur d’amorçage lui-même n’est pas réinstallé avec cette
     commande. Ainsi, le chargeur d’amorçage est utilisé avec un fichier
     de configuration plus à jour.

     La génération cible peut être spécifiée explicitement par son
     numéro de génération. Par exemple, l’invocation suivante passerait
     à la génération 7 du système :

          guix system switch-generation 7

     La génération cible peut aussi être spécifiée relativement à la
     génération actuelle avec la forme ‘+N’ ou ‘-N’, où ‘+3’ signifie «
     trois générations après la génération actuelle » et ‘-1’ signifie «
     une génération précédent la génération actuelle ». Lorsque vous
     spécifiez un nombre négatif comme ‘-1’, il doit être précédé de
     ‘--’ pour éviter qu’il ne soit compris comme une option. Par
     exemple :

          guix system switch-generation -- -1

     Actuellement, l’effet de l’invocation de cette action est
     _uniquement_ de passer au profil du système vers une autre
     génération existante et de réarranger le menu du chargeur
     d’amorçage. Pour vraiment commencer à utiliser la génération
     spécifiée, vous devez redémarrer après avoir lancé cette action.
     Dans le futur, elle sera corrigée pour faire la même chose que
     ‘reconfigure’, comme réactiver et désactiver les services.

     Cette action échouera si la génération spécifiée n’existe pas.

‘roll-back’
     Passe à la génération précédente du système. Au prochain amorçage,
     la génération précédente sera utilisée. C’est le contraire de
     ‘reconfigure’, et c’est exactement comme invoquer
     ‘switch-generation’ avec pour argument ‘-1’.

     Actuellement, comme pour ‘switch-generation’, vous devez redémarrer
     après avoir lancé cette action pour vraiment démarrer sur la
     génération précédente du système.

‘delete-generations’
     Supprimer des générations du système, ce qui les rend disponibles
     pour le ramasse-miettes (*note Invoquer guix gc::, pour des
     informations sur la manière de lancer le « ramasse-miettes »).

     Cela fonctionne comme pour ‘guix package --delete-generations’
     (*note ‘--delete-generations’: Invoquer guix package.). Avec aucun
     argument, toutes les générations du système sauf la génération
     actuelle sont supprimées :

          guix system delete-generations

     Vous pouvez aussi choisir les générations que vous voulez
     supprimer. L’exemple plus bas supprime toutes les génération du
     système plus vieilles que deux mois :

          guix system delete-generations 2m

     Lancer cette commande réinstalle automatiquement le chargeur
     d’amorçage avec une liste à jour d’entrées de menu — p. ex. le
     sous-menu « anciennes générations » dans GRUB ne liste plus les
     générations qui ont été supprimées.

‘build’
     Construit la dérivation du système d’exploitation, ce qui comprend
     tous les fichiers de configuration et les programmes requis pour
     démarrer et lancer le système. Cette action n’installe rien.

‘init’
     Rempli le répertoire donné avec tous les fichiers nécessaires à
     lancer le système d’exploitation spécifié dans FILE. C’est utile
     pour la première installation de Guix System. Par exemple :

          guix system init my-os-config.scm /mnt

     copie tous les éléments du dépôt requis par la configuration
     spécifiée dans ‘my-os-config.scm’ dans ‘/mnt’. Cela comprend les
     fichiers de configuration, les paquets, etc. Elle crée aussi
     d’autres fichiers essentiels requis pour que le système fonctionne
     correctement — p. ex. les répertoires ‘/etc’, ‘/var’ et ‘/run’ et
     le fichier ‘/bin/sh’.

     Cette commande installe aussi le chargeur d’amorçage sur les cibles
     spécifiées dans ‘my-os-config’, à moins que l’option
     ‘--no-bootloader’ ne soit passée.

‘installer’
     Run the installer. Usually the installer is built as an ‘iso’
     image, copied to a USB Stick or DVD, and booted from (*note
     Installation depuis une clef USB ou un DVD::). If your machine
     already runs Guix and you still want to run the installer, e.g.,
     for testing purposes, you can skip the step of creating an ‘iso’
     and run for instance:

          guix system installer --dry-run

          Remarque : If you do not use ‘--dry-run’ then you need to run
          as root. Be _very careful_ when running the installer as root,
          it can cause data loss or render your system unbootable!

‘vm’
     Construit une machine virtuelle (VM) qui contient le système
     d’exploitation déclaré dans FILE et renvoie un script pour lancer
     cette VM.

          Remarque : Les actions ‘vm’ et les autres plus bas peuvent
          utiliser la prise en charge KVM du noyau Linux-libre. Plus
          spécifiquement, si la machine prend en charge la
          virtualisation matérielle, le module noyau KVM correspondant
          devrait être chargé, et le nœud de périphérique ‘/dev/kvm’
          devrait exister et être lisible et inscriptible pour
          l’utilisateur et pour les utilisateurs de construction du
          démon (*note Réglages de l'environnement de construction::).

     Les arguments passés au script sont passés à QEMU comme dans
     l’exemple ci-dessous, qui active le réseau et demande 1 Go de RAM
     pour la machine émulée :

          $ /gnu/store/...-run-vm.sh -m 1024 -smp 2 -nic user,model=virtio-net-pci

     Il est possible de combiner les deux étapes en une :

          $ $(guix system vm my-config.scm) -m 1024 -smp 2 -nic user,model=virtio-net-pci

     La VM partage sont dépôt avec le système hôte.

     Par défaut, le système de fichiers racine de la VM sera monté de
     manière volatile ; l’option ‘--persistent’ peut être fournie pour
     le rendre persistent à la place. Dans ce cas, le fichier d’image
     disque VM sera copiée à partir du dépôt vers le répertoire ‘TMPDIR’
     pour le rendre inscriptible.

     Vous pouvez partager des fichiers supplémentaires entre l’hôte et
     la VM avec les options en ligne de commande ‘--share’ et ‘--expose’
     : la première spécifie un répertoire à partager avec accès en
     écriture, tandis que le deuxième fournit un accès en lecture-seule
     au répertoire partagé.

     L’exemple ci-dessous crée une VM dans laquelle le répertoire
     personnel de l’utilisateur est accessible en lecture-seule, et où
     le répertoire ‘/exchange’ est une correspondance en
     lecture-écriture à ‘$HOME/tmp’ sur l’hôte :

          guix system vm my-config.scm \
             --expose=$HOME --share=$HOME/tmp=/exchange

     Sur GNU/Linux, le comportement par défaut consiste à amorcer
     directement sur le noyau ; cela a l’avantage de n’avoir besoin que
     d’une toute petite image disque puisque le dépôt de l’hôte peut
     ensuite être monté.

     L’option ‘--full-boot’ force une séquence d’amorçage complète, en
     commençant par le chargeur d’amorçage. Cela requiert plus d’espace
     disque puisqu’une image racine contenant au moins le noyau,
     l’initrd et les fichiers de données du chargeur d’amorçage doit
     être créé.

     On peut utiliser l’option ‘--image-size’ pour spécifier la taille
     de l’image.

     The ‘--no-graphic’ option will instruct ‘guix system’ to spawn a
     headless VM that will use the invoking tty for IO. Among other
     things, this enables copy-pasting, and scrollback. Use the ‘ctrl-a’
     prefix to issue QEMU commands; e.g. ‘ctrl-a h’ prints a help,
     ‘ctrl-a x’ quits the VM, and ‘ctrl-a c’ switches between the QEMU
     monitor and the VM.

‘image’
     La commande ‘image’ peut produire divers types d’images. Vous
     pouvez choisir le type d’image en utilisant l’option
     ‘--image-type’. Sa valeur par défaut est ‘mbr-hybrid-raw’. Lorsque
     sa valeur est ‘iso9660’, vous pouvez utiliser l’option ‘--label’
     pour spécifier un identifiant de volume avec ‘image’. Par défaut,
     le système de fichiers racine d’une image disque est montée en
     non-volatile ; vous pouvez fournir l’option ‘--volatile’ pour la
     rendre volatile. Si vous utilisez ‘image’, le chargeur d’amorçage
     installé sur l’image générée est celui de la définition
     ‘operating-system’ fournie. L’exemple suivant montre comment
     générer une image qui utilise le chargeur d’amorçage
     ‘grub-efi-bootloader’ et la démarrer avec QEMU :

          image=$(guix system image --image-type=qcow2 \
                  gnu/system/examples/lightweight-desktop.tmpl)
          cp $image /tmp/my-image.qcow2
          chmod +w /tmp/my-image.qcow2
          qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
                             -bios $(guix build ovmf-x86-64)/share/firmware/ovmf_x64.bin

     When using the ‘mbr-hybrid-raw’ image type, a raw disk image is
     produced; it can be copied as is to a USB stick, for instance.
     Assuming ‘/dev/sdc’ is the device corresponding to a USB stick, one
     can copy the image to it using the following command:

          # dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress

     La commande ‘--list-image-types’ liste tous les types d’images
     disponibles.

     When using the ‘qcow2’ image type, the returned image is in qcow2
     format, which the QEMU emulator can efficiently use. *Note Lancer
     Guix dans une VM::, for more information on how to run the image in
     a virtual machine. The ‘grub-bootloader’ bootloader is always used
     independently of what is declared in the ‘operating-system’ file
     passed as argument. This is to make it easier to work with QEMU,
     which uses the SeaBIOS BIOS by default, expecting a bootloader to
     be installed in the Master Boot Record (MBR). In case the virtual
     machine is going to be AArch64, you might want to take a look at
     ‘qcow2-gpt’ image type that installs bootloader only in EFI.

     En utilisant le type d’image ‘docker’, on produit une image Docker.
     Guix construit l’image de zéro, et non à partir d’une image Docker
     de base pré-existante. En conséquence, elle contient _exactly_ ce
     que vous avez défini dans le fichier de configuration du système.
     Vous pouvez ensuite charger l’image et lancer un conteneur Docker
     avec des commande comme :

          image_id="$(docker load < guix-system-docker-image.tar.gz)"
          container_id="$(docker create $image_id)"
          docker start $container_id

     Cette commande démarre un nouveau conteneur Docker à partir de
     l’image spécifiée. Il démarrera le système Guix de la manière
     habituelle, ce qui signifie qu’il démarrera tous les services que
     vous avez définis dans la configuration du système d’exploitation.
     Vous pouvez obtenir un shell interactif dans le conteneur en
     utilisant ‘docker exec’ :

          docker exec -ti $container_id /run/current-system/profile/bin/bash --login

     En fonction de ce que vous lancez dans le conteneur Docker, il peut
     être nécessaire de donner des permissions supplémentaires au
     conteneur. Par exemple, si vous voulez construire des paquets avec
     Guix dans le conteneur Docker, vous devriez passer ‘--privileged’ à
     ‘docker create’.

     Enfin, l’option ‘--network’ s’applique à ‘guix system docker-image’
     : elle produit une image où le réseau est partagé avec l’hôte, et
     donc sans services comme nscd ou NetworkManager.

‘container’
     Renvoie un script qui lance le système d’exploitation déclaré dans
     FILE dans un conteneur. Les conteneurs sont un ensemble de
     mécanismes d’isolation légers fournis par le noyau Linux-libre. Les
     conteneurs sont substantiellement moins gourmands en ressources que
     les machines virtuelles complètes car le noyau, les objets partagés
     et d’autres ressources peuvent être partagés avec le système hôte ;
     cela signifie aussi une isolation moins complète.

     Actuellement, le script doit être lancé en root pour pouvoir
     supporter plus d’un utilisateur et d’un groupe. Le conteneur
     partage son dépôt avec le système hôte.

     Comme avec l’action ‘vm’ (*note guix system vm::), des systèmes de
     fichiers supplémentaires peuvent être partagés entre l’hôte et le
     conteneur avec les options ‘--share’ et ‘--expose’ :

          guix system container my-config.scm \
             --expose=$HOME --share=$HOME/tmp=/exchange

     Les options ‘--share’ et ‘--expose’ peuvent aussi être passées au
     script généré pour effectuer un montage lié de répertoires
     supplémentaires dans le conteneur.

     The generated script also supports the ‘--pid-file’ option to write
     the container process ID to a file. This can be used, along with
     ‘guix container exec’ to execute scripts within the container
     (*note Invoquer guix container::).

          Remarque : The ‘container’ action requires Linux-libre 3.19 or
          newer.

   OPTIONS peut contenir n’importe quelle option commune de construction
(*note Options de construction communes::). En plus, OPTIONS peut
contenir l’une de ces options :

‘--expression=EXPR’
‘-e EXPR’
     Considère le système d’exploitation en lequel s’évalue EXPR. C’est
     une alternative à la spécification d’un fichier qui s’évalue en un
     système d’exploitation. C’est utilisé pour générer l’installateur
     du système Guix (*note Construire l'image d'installation::).

‘--system=SYSTÈME’
‘-s SYSTÈME’
     Essaye de construire pour SYSTEM au lieu du type du système hôte.
     Cela fonction comme pour ‘guix build’ (*note Invoquer guix
     build::).

‘--target=TRIPLET’
     Effectuer une compilation croisée pour TRIPLET qui doit être un
     triplet GNU valide, comme ‘""aarch64-linux-gnu""’ (*note GNU
     configuration triplets: (autoconf)Specifying target triplets.).

‘--derivation’
‘-d’
     Renvoie le nom du fichier de dérivation du système d’exploitation
     donné sans rien construire.

‘--save-provenance’
     Comme nous en avons parlé précédemment, ‘guix system init’ et ‘guix
     system reconfigure’ enregistrent toujours les informations de
     provenance via un service dédié (*note ‘provenance-service-type’:
     Référence de service.). Cependant, d’autres commande ne le font pas
     par défaut. Si vous voulez, disons, créer une image de machine
     virtuelle contenant les informations de provenance, vous pouvez
     lancer :

          guix system image -t qcow2 --save-provenance config.scm

     De cette façon, l’image qui en résulte va effectivement « intégrer
     sa propre source » sous la forme de méta-données dans
     ‘/run/current-system’. Avec cette information, on peut reconstruire
     l’image pour s’assurer qu’elle contient vraiment ce qu’elle prétend
     contenir ; ou on peut utiliser ça pour dériver une variante de
     l’image.

‘--image-type=TYPE’
‘-t TYPE’
     Pour l’action ‘image’, crée une image du TYPE donné.

     When this option is omitted, ‘guix system’ uses the
     ‘mbr-hybrid-raw’ image type.

     ‘--image-type=iso9660’ produit une image ISO-9660, qu’il est
     possible de graver sur un CD ou un DVD.

‘--image-size=SIZE’
     Pour l’action ‘image’, crée une image de la taille donnée SIZE.
     SIZE peut être un nombre d’octets ou contenir un suffixe d’unité
     (*note size specifications: (coreutils)Block size.).

     Lorsque cette option est omise, ‘guix system’ calcule une
     estimation de la taille de l’image en fonction de la taille du
     système déclaré dans FILE.

‘--network’
‘-N’
     Pour l’action ‘container’, permet aux conteneurs d’accéder au
     réseau de l’hôte, c’est-à-dire, ne crée pas d’espace de nom réseau.

‘--root=FICHIER’
‘-r FICHIER’
     Fait de FICHIER un lien symbolique vers le résultat, et
     l’enregistre en tant que racine du ramasse-miettes.

‘--skip-checks’
     Passe les vérifications de sécurité avant l’installation.

     Par défaut, ‘guix system init’ et ‘guix system reconfigure’
     effectuent des vérifications de sécurité : ils s’assurent que les
     systèmes de fichiers qui apparaissent dans la déclaration
     ‘operating-system’ existent vraiment (*note Systèmes de fichiers::)
     et que les modules de noyau Linux qui peuvent être requis à
     l’amorçage sont listés dans ‘initrd-modules’ (*note Disque de RAM
     initial::). Passer cette option saute ces vérifications
     complètement.

‘--allow-downgrades’
     Dit à ‘guix system reconfigure’ de permettre le retour en arrière
     du système.

     Par défaut, ‘reconfigure’ vous empêche de faire revenir votre
     système en arrière. Il fait cela en comparant les informations de
     provenance de votre système (décrites par ‘guix system describe’)
     avec celles de la commande ‘guix’ (décrites par ‘guix describe’).
     Si les commits de ‘guix’ ne descendent pas de ceux utilisés pour
     votre système, ‘guix system reconfigure’ renvoie une erreur. Passer
     ‘--allow-downgrades’ vous permet de passer ces tests.

          Remarque : Assurez-vous de comprendre les implications de sa
          sécurité avant d’utiliser ‘--allow-downgrades’.

‘--on-error=STRATEGY’
     Applique STRATEGY lorsqu’une erreur arrive lors de la lecture de
     FILE. STRATEGY peut être l’une des valeurs suivantes :

     ‘nothing-special’
          Rapporte l’erreur de manière concise et quitte. C’est la
          stratégie par défaut.

     ‘backtrace’
          Pareil, mais affiche aussi une trace de débogage.

     ‘debug’
          Rapporte l’erreur et entre dans le débogueur Guile. À partir
          de là, vous pouvez lancer des commandes comme ‘,bt’ pour
          obtenir une trace de débogage, ‘,locals’ pour afficher les
          valeurs des variables locales et plus généralement inspecter
          l’état du programme. *Note (guile)Debug Commands::, pour une
          liste de commandes de débogage disponibles.

   Une fois que vous avez construit, re-configuré et re-re-configuré
votre installation Guix, vous pourriez trouver utile de lister les
générations du système disponibles sur le disque — et que vous pouvez
choisir dans le menu du chargeur d’amorçage :

‘describe’
     Décrit la génération du système lancé : son nom de fichier, son
     noyau et chargeur d’amorçage utilisé, etc, ainsi que les
     informations de provenance si elles sont disponibles.

     le drapeau ‘--list-intalled’ est disponible, avec la même syntaxe
     que celui utilisé dans ‘guix package --list-installed’ (*note
     Invoquer guix package::). Lorsque le drapeau est utilisé, la
     description incluera une liste des paquets qui sont actuellement
     installés dans le profil du système, avec un filtre facultatif sur
     une expression régulière.

          Remarque : La génération du système _en cours_ — référencé par
          ‘/run/current-system’ — n’est pas nécessairement la génération
          _actuelle_ du système — référencée par
          ‘/var/guix/profiles/system’ : elles sont différentes si par
          exemple, vous choisissez dans le menu du chargeur d’amorçage
          de démarrer une ancienne génération.

          Elles peuvent aussi être différentes de la génération du
          système _démarrée_ — référencée par ‘/run/booted-system’ — par
          exemple parce que vous avez reconfiguré le système entre
          temps.

‘list-generations’
     Affiche un résumé de chaque génération du système d’exploitation
     disponible sur le disque, dans un format lisible pour un humain.
     C’est similaire à l’option ‘--list-generations’ de ‘guix package’
     (*note Invoquer guix package::).

     Éventuellement, on peut spécifier un motif, avec la même syntaxe
     utilisée pour ‘guix package --list-generations’, pour restreindre
     la liste des générations affichées. Par exemple, la commande
     suivante affiche les générations de moins de 10 jours :

          $ guix system list-generations 10d

     Le drapeau ‘--list-installed’ peut aussi être spécifié, avec la
     même syntaxe que celle utilisée dans ‘guix package
     --list-installed’. Cela peut être utile si vous essayez de
     déterminer si un paquet a été ajouté au système.

   La commande ‘guix system’ a même plus à proposer ! Les sous-commandes
suivantes vous permettent de visualiser comme vos services systèmes sont
liés les uns aux autres :

‘extension-graph’
     Émettre vers la sortie standard le “graphe d’extension de service”
     du système d’exploitation défini dans FILE (*note Composition de
     services::, pour plus d’informations sur les extensions de
     service). Par défaut, le format de sortie est le format
     Dot/Graphviz, mais vous pouvez choisir un autre format avec
     ‘--graph-backend’, comme avec ‘guix graph’ (*note ‘--backend’:
     Invoquer guix graph.) :

     La commande :

          $ guix system extension-graph FILE | xdot -

     montre les relations d’extension entre les services.

          Remarque : Le programme ‘dot’ est fournit par le paquet
          ‘graphviz’.

‘shepherd-graph’
     Affiche le “graphe de dépendance” des services shepherd du système
     d’exploitation défini dans FILE sur la sortie standard. *Note
     Services Shepherd::, pour plus d’informations et un exemple de
     graphe.

     Encore une fois, le format de sortie par défaut est Dot/Graphviz,
     mais vous pouvez passer ‘--graph-backend’ pour en choisir un autre.

   ---------- Footnotes ----------

   (1) Cette action (et les action liées que sont ‘switch-generation’ et
‘roll-back’) ne sont utilisables que sur les systèmes sous Guix System.


File: guix.fr.info,  Node: Invoquer guix deploy,  Next: Lancer Guix dans une VM,  Prev: Invoquer guix system,  Up: Configuration du système

11.17 Invoquer ‘guix deploy’
============================

Nous avons déjà vu les déclarations de ‘operating-system’ utilisées pour
gérer la configuration d’une machine localement. Supposez que vous ayez
besoin de configurer plusieurs machines — peut-être que vous gérez un
service web comprenant plusieurs serveurs. ‘guix deploy’ vous permet
d’utiliser les mêmes déclarations de systèmes d’exploitation pour gérer
plusieurs hôtes distants en même temps dans le même « déploiement »
logique.

     Remarque : La fonctionnalité décrite dans cette section est
     toujours en cours de développement et est sujette à changement.
     Contactez-nous sur <guix-devel@gnu.org> !

     guix deploy FICHIER

   Une telle invocation déploiera les machines en lesquelles le code de
FICHIER s’évalue. Par exemple, FICHIER peut contenir une définition
comme celle-ci :

     ;; Ceci est le déploiement Guix d'un système « minimal » sans
     ;; serveur d'affichage X11, vers une machine dont le démon SSH
     ;; écoute sur localhost:2222. Une configuration comme celle-ci
     ;; est appropriée pour les machines virtuelles dont les ports sont relayés
     ;; vers l'interface de bouclage de l'hôte.

     (use-service-modules networking ssh)
     (use-package-modules bootloaders)

     (define %system
       (operating-system
        (host-name "gnu-deployed")
        (timezone "Etc/UTC")
        (bootloader (bootloader-configuration
                     (bootloader grub-bootloader)
                     (target '("/dev/vda"))
                     (terminal-outputs '(console))))
        (file-systems (cons (file-system
                             (mount-point "/")
                             (device "/dev/vda1")
                             (type "ext4"))
                            %base-file-systems))
        (services
         (append (list (service dhcp-client-service-type)
                       (service openssh-service-type
                                (openssh-configuration
                                 (permit-root-login #t)
                                 (allow-empty-passwords? #t))))
                 %base-services))))

     (list (machine
            (operating-system %system)
            (environment managed-host-environment-type)
            (configuration (machine-ssh-configuration
                            (host-name "localhost")
                            (system "x86_64-linux")
                            (user "alice")
                            (identity "./id_rsa")
                            (port 2222)))))

   Le fichier devrait s’évaluer en une liste d’objets MACHINE. Cet
exemple, lors du déploiement, créera une nouvelle génération sur le
système distant en réalisant la déclaration ‘operating-system’
‘%system’. ‘environment’ et ‘configuration’ spécifient comment la
machine devrait être provisionnée — c.-à-d. comment les ressources sont
créées et gérées. L’exemple ci-dessus ne crée aucune ressource, car un
‘'managed-host’ est une machine qui fait déjà tourner le système Guix et
est disponible sur le réseau. Cela est un cas particulièrement simple ;
un déploiement plus complexe pourrait impliquer, par exemple, le
démarrage de machines virtuels chez un fournisseur de serveurs privés
virtuels (VPS). Dans ce cas, une type d’ENVIRONNEMENT différent devrait
être utilisé.

   Prenez note que vous devez d’abord générer une paire de clés sur la
machine coordinatrice pour permettre au démon d’exporter les archives
signées des fichiers du dépôt (*note Invoquer guix archive::), bien que
cette étape soit automatique sur Guix System :

     # guix archive --generate-key

Chaque machine cible doit autoriser la clé de la machine maître afin
qu’elle accepte les objets de stockage qu’elle reçoit du coordinateur :

     # guix archive --authorize < coordinator-public-key.txt

   ‘user’, dans cet exemple, spécifie le nom du compte utilisateur à
utiliser pour se connecter lors du déploiement. Sa valeur par défaut est
‘root’, mais la connexion SSH en root peut être interdite dans certains
cas. Pour contourner cela, ‘guix deploy’ peut se connecter en tant
qu’utilisateur non-privilégié et utiliser ‘sudo’ pour récupérer les
privilèges. Cela ne fonctionnera que si ‘sudo’ est actuellement installé
sur la machine distante et peut être invoqué de manière non interactive
par ‘user’. C’est-à-dire que la ligne ‘sudoers’ permettant à ‘user’
d’utiliser ‘sudo’ doit contenir l’attribut ‘NOPASSWD’. Cela peut se
faire avec le bout de configuration du système d’exploitation suivant :

     (use-modules ...
                  (gnu system))               ;pour %sudoers-specification

     (define %user "username")

     (operating-system
       ...
       (sudoers-file
          (plain-file "sudoers"
                      (string-append (plain-file-content %sudoers-specification)
                                     (format #f "~a ALL = NOPASSWD: ALL~%"
                                             %user)))))


   Pour plus d’informations sur le format du fichier ‘sudoers’,
consultez ‘man sudoers’.

   Une fois que vous avez déployé un système sur un ensemble de
machines, vous trouverez utile de lancer une commande sur chacune. Les
options ‘--execute’ ou ‘-x’ vous le permet. L’exemple ci-dessous lance
‘uname -a’ sur toutes les machines listées dans le fichier de
déploiement :

     guix deploy FICHIER -x -- uname -a

   Ce que vous devrez souvent faire après un déploiement est de
redémarrer les services spécifiques sur toutes les machines, ce qui peut
se faire de cette manière :

     guix deploy FILE -x -- herd restart SERVICE

   La commande ‘guix deploy -x’ renvoie zéro si et seulement si la
commande réussi sur toutes les machines.

   You may also wish to roll back configurations on machines to a
previous generation. You can do that using the ‘--roll-back’ or ‘-r’
option like so:

     guix deploy --roll-back FILE

   Voici les types de données que vous devrez connaitre pour écrire un
fichier de déploiement.

 -- Type de données : machine
     C’est le type de données représentant une seule machine dans un
     déploiement Guix hétérogène.

     ‘operating-system’
          L’objet de la configuration du système d’exploitation à
          déployer.

     ‘environment’
          Un ‘environment-type’ décrit comment la machine est
          provisionnée.

     ‘configuration’ (par défaut : ‘#f’)
          Un objet décrivant la configuration de l’environnement de la
          machine. Si l’objet ‘environment’ a une configuration par
          défaut, vous pouvez utiliser ‘#f’. Si vous utilisez ‘#f’ mais
          que l’environnement n’a pas de configuration par défaut, une
          erreur sera renvoyée.

 -- Type de données : machine-ssh-configuration
     C’est le type de données représentant les paramètres du client SSH
     pour une machine qui a pour ‘environment’
     ‘managed-host-environment-type’.

     ‘host-name’
     ‘build-locally?’ (par défaut : ‘#t’)
          Si la valeur est fausse, les dérivations du système seront
          construites sur la machine qui est déployée.
     ‘system’
          Le type de système décrivant l’architecture de la machine
          déployée pour—par exemple, ‘"x86_64-linux"’.
     ‘authorize?’ (par défaut : ‘#t’)
          Si la valeur est vraie, la clé de signature du coordinateur
          sera ajoutée au porteclé des ACL de la machine distante.
     ‘port’ (par défaut : ‘22’)
     ‘user’ (par défaut : ‘"root"’)
     ‘identity’ (par défaut : ‘#f’)
          Si spécifié, le chemin d’accès à la clé privée SSH à utiliser
          pour s’authentifier auprès de l’hôte distant.

     ‘host-key’ (par défaut : ‘#f’)
          Cela devrait être la clé de l’hôte SSH de la machine, qui
          ressemble à cela :

               ssh-ed25519 AAAAC3Nz... root@example.org

          Quand ‘host-key’ est ‘#f’, le serveur est authentifié avec le
          fichier ‘~/.ssh/known_hosts’, exactement comme le ferait le
          client ‘ssh’ OpenSSH.

     ‘allow-downgrades?’ (par défaut : ‘#f’)
          Autoriser ou non d’éventuels déclassements.

          Comme ‘guix sysetm reconfigure’, ‘guix deploy’ compare les
          commits du canal actuellement déployé sur l’hôte distant
          (renvoyé par ‘guix system describe’) à ceux utilisés (renvoyés
          par ‘guix describe’) pour déterminer si les commits
          actuellement utilisés descendent de ceux déployés. Lorsque ce
          n’est pas le cas et que ‘allow-downgrades?’ est faux, cela
          lève une erreur. Cela permet de s’assurer que vous ne déployez
          pas accidentellement une version plus ancienne version les
          machines distantes.

     ‘safety-checks?’ (par défaut : ‘#t’)
          Indique s’il faut lancer des « vérifications de cohérence »
          avant le déploiement. Cela comprend la vérification que les
          périphériques et les systèmes de fichiers référencés dans la
          configuration du système d’exploitation existent vraiment sur
          la machine cible, et la vérification que les modules Linux
          nécessaires à l’accès aux périphériques de stockage à
          l’amorçage se trouvent dans le champ ‘initrd-modules’ du
          système d’exploitation.

          Ces vérification s’assurent que vous ne déployez pas par
          inadvertance un système qui ne pourra pas démarrer. Soyez
          prudent avant de les désactiver !

 -- Type de données : digital-ocean-configuration
     C’est le type de données décrivant le Droplet qui devrait être créé
     pour une machine avec un ‘environment’ valant
     ‘digital-ocean-environment-type’.

     ‘ssh-key’
          Le chemin vers la clé SSH privée à utiliser pour
          s’authentifier avec l’hôte distant. Dans le futur, le champ
          pourrait ne plus exister.
     ‘tags’
          Une liste « d’attributs » qui identifient la machine de
          manière unique. Il faut faire attention à ce que deux machine
          du déploiement n’aient pas le même ensemble d’attributs.
     ‘region’
          Le nom d’une région de Digital Ocean, comme ‘"nyc3"’.
     ‘size’
          Le nom d’une taille de Digital Ocean, comme ‘"s-1vcpu-1gb"’
     ‘enable-ipv6?’
          Indique s’il faut créer une IPv6 pour le droplet.

 -- Data Type : hetzner-configuration
     This is the data type describing the server that should be created
     for a machine with an ‘environment’ of ‘hetzner-environment-type’.
     It allows you to configure deployment to a VPS (virtual private
     server) hosted by Hetzner (https://www.hetzner.com).

     ‘allow-downgrades?’ (par défaut : ‘#f’)
          Autoriser ou non d’éventuels déclassements.

     ‘authorize?’ (par défaut : ‘#t’)
          If true, the public signing key ‘"/etc/guix/signing-key.pub"’
          of the machine that invokes ‘guix deploy’ will be added to the
          operating system ACL keyring of the target machine.

     ‘build-locally?’ (par défaut : ‘#t’)
          If true, system derivations will be built on the machine that
          invokes ‘guix deploy’, otherwise derivations are build on the
          target machine. Set this to ‘#f’ if the machine you are
          deploying from has a different architecture than the target
          machine and you can’t build derivations for the target
          architecture by other means, like offloading (*note Réglages
          du déchargement du démon::) or emulation (*note Transparent
          Emulation with QEMU: transparent-emulation-qemu.).

     ‘delete?’ (default: ‘#t’)
          If true, the server will be deleted when an error happens in
          the provisioning phase. If false, the server will be kept in
          order to debug any issues.

     ‘ipv4’ (default: ‘#t’)
     ‘ipv6’ (default: ‘#t’)
          When false, no public IP address is attached. Specify the name
          of an existing primary ip to attach it to the machine. Other
          values would create a new address automatically.

     ‘labels’ (default: ‘'()’)
          A user defined alist of key/value pairs attached to the SSH
          key and the server on the Hetzner API. Keys and values must be
          strings, e.g. ‘'(("environment" . "development"))’. For more
          information, see Labels (https://docs.hetzner.cloud/#labels).

     ‘location’ (default: ‘"fsn1"’)
          The name of a location
          (https://docs.hetzner.com/cloud/general/locations) to create
          the server in. For example, ‘"fsn1"’ corresponds to the
          Hetzner site in Falkenstein, Germany, while ‘"sin"’
          corresponds to its site in Singapore.

     ‘server-type’ (default: ‘"cx42"’)
          The name of the server type
          (https://docs.hetzner.com/cloud/servers/overview#server-types)
          this virtual server should be created with. For example,
          ‘"cx42"’ corresponds to a x86_64 server that has 8 VCPUs, 16
          GB of memory and 160 GB of storage, while ‘"cax31"’ to the
          AArch64 equivalent. Other server types and their current
          prices can be found here
          (https://www.hetzner.com/cloud/#pricing). The ‘"cpx11"’ server
          type is currently not supported, since its rescue system is
          too small to bootstrap a Guix system from.

     ‘ssh-key’ (default: ‘#f’)
          If specified, the file name of the SSH private key to use to
          authenticate with the remote host.

     ‘ssh-public-key’ (default: extracted from ‘ssh-key’)
          If specified, either a public key as returned by
          ‘string->public-key’ or the path to the SSH public key to use
          to authenticate with the remote host.

     When deploying a machine for the first time, the following steps
     are taken to provision a server for the machine on the Hetzner
     Cloud (https://www.hetzner.com/cloud) service:

        • Create the SSH key of the machine on the Hetzner API.

        • Create a server for the machine on the Hetzner API.

        • Format the root partition of the disk using the file system of
          the machine’s operating system. Supported file systems are
          btrfs and ext4.

        • Install a minimal Guix operating system on the server using
          the rescue mode
          (https://docs.hetzner.com/cloud/servers/getting-started/rescue-system).
          This minimal system is used to install the machine’s operating
          system, after rebooting.

        • Reboot the server and apply the machine’s operating system on
          the server.

     Once the server has been provisioned and SSH is available,
     deployment continues by delegating it to the
     ‘managed-host-environment-type’.

     Servers on the Hetzner Cloud service can be provisioned on the
     AArch64 architecture using UEFI boot mode, or on the x86_64
     architecture using BIOS boot mode. The ‘(gnu machine hetzner)’
     module exports the ‘%hetzner-os-arm’ and ‘%hetzner-os-x86’
     operating systems that are compatible with those two architectures,
     and can be used as a base for defining your custom operating
     system.

     The following example shows the definition of two machines that are
     deployed on the Hetzner Cloud service. The first one uses the
     ‘%hetzner-os-arm’ operating system to run a server with 16 shared
     vCPUs and 32 GB of RAM on the ‘aarch64’ architecture, the second
     one uses the ‘%hetzner-os-x86’ operating system on a server with 16
     shared vCPUs and 32 GB of RAM on the ‘x86_64’ architecture.

          (use-modules (gnu machine)
                       (gnu machine hetzner))

          (list (machine
                 (operating-system %hetzner-os-arm)
                 (environment hetzner-environment-type)
                 (configuration (hetzner-configuration
                                 (server-type "cax41")
                                 (ssh-key "/home/charlie/.ssh/id_rsa"))))
                (machine
                 (operating-system %hetzner-os-x86)
                 (environment hetzner-environment-type)
                 (configuration (hetzner-configuration
                                 (server-type "cpx51")
                                 (ssh-public-key "/home/charlie/.ssh/id_rsa.pub")))))

     Passing this file to ‘guix deploy’ with the environment variable
     ‘GUIX_HETZNER_API_TOKEN’ set to a valid Hetzner API key
     (https://docs.hetzner.com/cloud/api/getting-started/generating-api-token)
     should provision two machines for you.

