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

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021
Ludovic Courtès
Copyright © 2013, 2014, 2016 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 Leo Famulari
Copyright © 2015, 2016, 2017, 2018, 2019, 2020 Ricardo Wurmus
Copyright © 2016 Ben Woodcroft
Copyright © 2016, 2017, 2018, 2021 Chris Marusich
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Efraim Flashner
Copyright © 2016 John Darrington
Copyright © 2016, 2017 Nikita Gillmann
Copyright © 2016, 2017, 2018, 2019, 2020 Jan Nieuwenhuizen
Copyright © 2016, 2017, 2018, 2019, 2020 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 Mathieu Othacehe
Copyright © 2017 Federico Beffa
Copyright © 2017, 2018 Carlo Zancanaro
Copyright © 2017 Thomas Danckaert
Copyright © 2017 humanitiesNerd
Copyright © 2017, 2021 Christopher Lemmer Webber
Copyright © 2017, 2018, 2019, 2020 Marius Bakke
Copyright © 2017, 2019, 2020 Hartmut Goebel
Copyright © 2017, 2019, 2020, 2021 Maxim Cournoyer
Copyright © 2017, 2018, 2019, 2020, 2021 Tobias Geerinckx-Rice
Copyright © 2017 George Clemmer
Copyright © 2017 Andy Wingo
Copyright © 2017, 2018, 2019, 2020 Arun Isaac
Copyright © 2017 nee
Copyright © 2018 Rutger Helling
Copyright © 2018, 2021 Oleg Pykhalov
Copyright © 2018 Mike Gerwitz
Copyright © 2018 Pierre-Antoine Rouby
Copyright © 2018, 2019 Gábor Boskovits
Copyright © 2018, 2019, 2020 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 Guillaume Le Vaillant
Copyright © 2020 Leo Prikler
Copyright © 2019, 2020 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 Brice Waegeneire
Copyright © 2020 R Veera Kumar
Copyright © 2020 Pierre Langlois
Copyright © 2020 pinoaffe
Copyright © 2020 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 Maxime Devos

   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: (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 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: Système de fichiers en réseau,  Next: Intégration continue,  Prev: Services VPN,  Up: Services

10.8.22 Système de fichiers en réseau
-------------------------------------

Le module ‘(gnu services nfs)’ fournit les services suivants, qui sont
tous utilisés pour monter et exporter des arborescences de répertoires
en “network file systems” (NFS).

   Bien qu’il soit possible d’utiliser des composants individuels qui
forment ensemble un service de système de fichiers en réseau, nous
recommandons de configurer un serveur NFS avec ‘nfs-service-type’.

Services NFS
............

Le service NFS s’occupe de paramétrer tous les services composant NFS,
les systèmes de fichiers de configuration du noyau et installe les
fichiers de configuration aux endroit attendus par NFS.

 -- Variable Scheme : nfs-service-type
     Un type de service pour un serveur NFS complet.

 -- Type de données : nfs-configuration
     Ce type de données représente la configuration d’un service NFS et
     de tous ses sous-systèmes.

     Il prend les paramètres suivants :
     ‘nfs-utils’ (par défaut : ‘nfs-utils’)
          Le paquet nfs-utils à utiliser.

     ‘nfs-versions’ (par défaut : ‘'("4.2" "4.1" "4.0")’)
          Si une liste de chaines est fournie, le démon ‘rpc.nfsd’ sera
          limité à la prise en charge des versions données du protocole
          NFS.

     ‘exports’ (par défaut : ‘'()’)
          C’est une liste de répertoires que le serveur NFS devrait
          exporter. Chaque entrée est une liste consistant en deux
          éléments : un nom de répertoire et une chaine de caractères
          contenant toutes les options. Voici un exemple dans lequel le
          répertoire ‘/export’ est servi à tous les clients en
          lecture-seule :

               (nfs-configuration
                (exports
                 '(("/export"
                    "*(ro,insecure,no_subtree_check,crossmnt,fsid=0)"))))

     ‘rpcmountd-port’ (par défaut : ‘#f’)
          Le port réseau que le démon ‘rpc.mountd’ devrait utiliser.

     ‘rpcstatd-port’ (par défaut : ‘#f’)
          Le port réseau que le démon ‘rpc.statd’ devrait utiliser.

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

     ‘idmap-domain’ (par défaut : ‘"localdomain"’)
          Le nom de domaine NFSv4 local.

     ‘nfsd-port’ (par défaut : ‘2049’)
          Le port réseau que le démon ‘nfsd’ devrait utiliser.

     ‘nfsd-threads’ (par défaut : ‘8’)
          Le nombre de thread à utiliser par le démon ‘nfsd’.

     ‘nfsd-tcp?’ (par défaut : ‘#t’)
          Indique si le démon ‘nfsd’ devrait écouter sur une socket TCP.

     ‘nfsd-udp?’ (par défaut : ‘#f’)
          Indique si le démon ‘nfsd’ devrait écouter sur une socket UDP.

     ‘pipefs-directory’ (par défaut : ‘"/var/lib/nfs/rpc_pipefs"’)
          Le répertoire où le système de fichier pipefs doit être monté.

     ‘debug’ (par défaut : ‘'()"’)
          Une liste des sous-systèmes pour lesquels la sortie de
          débogage est activée. C’est une liste de symboles. Ces
          symboles sont valides : ‘nfsd’, ‘nfs’, ‘rpc’, ‘idmap’, ‘statd’
          et ‘mountd’.

   Si vous n’avez pas besoin d’un service NFS complet ou préférez le
construire vous-même vous pouvez utiliser les composants individuels
décrit plus bas.

Service RPC Bind
................

Le service RPC Bind fournit un dispositif pour faire correspondre les
numéros de programmes à des adresses universelles. De nombreux services
liés à NFS utilisent ce dispositif. Donc il est automatiquement démarré
lorsqu’un service qui en dépend est démarré.

 -- Variable Scheme : rpcbind-service-type
     Un type de service pour le démon RPC portmapper.

 -- Type de données : rpcbind-configuration
     Type données représentant la configuration du service RPC Bind. Ce
     type a les paramètres suivants :
     ‘rpcbind’ (par défaut : ‘rpcbind’)
          Le paquet rpcbind à utiliser.

     ‘warm-start?’ (par défaut : ‘#t’)
          Si ce paramètre est ‘#t’, alors le démon lira un fichier
          d’état au démarrage ce qui lui fait recharger les informations
          d’états sauvegardés par une instance précédente.

Pseudo-système de fichiers Pipefs
.................................

Le système de fichiers pipefs est utilisé pour transférer des données
liées à NFS entre le noyau et les programmes en espace utilisateur.

 -- Variable Scheme : pipefs-service-type
     Un type de service pour le pseudo-système de fichiers pipefs.

 -- Type de données : pipefs-configuration
     Type de données représentant la configuration du service du
     pseudo-système de fichiers pipefs. Ce type a les paramètres
     suivants :
     ‘mount-point’ (par défaut : ‘"/var/lib/nfs/rpc_pipefs"’)
          Le répertoire dans lequel le système de fichiers est attaché.

Service de démon GSS
....................

Le démon du “système de sécurité global” (GSS) fournit une sécurité
forte pour les protocoles basés sur des RPC. Avant d’échanger des
requêtes RPC, un client RPC doit établir un contexte sécurisé.
Typiquement cela se fait avec la commande Kerberos ‘kinit’ ou
automatiquement à la connexion avec les services PAM (*note Services
Kerberos::).

 -- Variable Scheme : gss-service-type
     Un type de service pour le démon du système de sécurité global
     (GSS).

 -- Type de données : gss-configuration
     Type de données représentant la configuration du service du démon
     GSS. Ce type a les paramètres suivants :
     ‘nfs-utils’ (par défaut : ‘nfs-utils’)
          Le paquet dans lequel la commande ‘rpc.gssd’ se trouve.

     ‘pipefs-directory’ (par défaut : ‘"/var/lib/nfs/rpc_pipefs"’)
          Le répertoire où le système de fichier pipefs doit être monté.

Service de démon IDMAP
......................

Le service du démon idmap fournit une correspondance entre les ID
utilisateur et les noms d’utilisateurs. Typiquement, cela est requis
pour accéder aux systèmes de fichiers montés via NFSv4.

 -- Variable Scheme : idmap-service-type
     Un type de service pour le démon de correspondance d’identité
     (IDMAP).

 -- Type de données : idmap-configuration
     Type de données représentant la configuration du service du démon
     IDMAP. Ce type a les paramètres suivants :
     ‘nfs-utils’ (par défaut : ‘nfs-utils’)
          Le paquet dans lequel se trouve la commande ‘rpc.idmapd’.

     ‘pipefs-directory’ (par défaut : ‘"/var/lib/nfs/rpc_pipefs"’)
          Le répertoire où le système de fichier pipefs doit être monté.

     ‘domain’ (par défaut : ‘#f’)
          Le nom de domaine NFSv4 local. Il faut que ce soit une chaîne
          de caractères ou ‘#f’. Si la valeur est ‘#f’ le démon
          utilisera le nom de domaine pleinement qualifié de l’hôte.

     ‘verbosity’ (par défaut : ‘0’)
          Le niveau de verbosité du démon.


File: guix.fr.info,  Node: Intégration continue,  Next: Services de gestion de l'énergie,  Prev: Système de fichiers en réseau,  Up: Services

10.8.23 Intégration continue
----------------------------

Cuirass (https://guix.gnu.org/fr/cuirass/) est un outil d’intégration
continue pour Guix. On peut l’utiliser aussi bien pour le développement
que pour fournir des substituts à d’autres (*note Substituts::).

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

 -- Procédure Scheme : cuirass-service-type
     Le type du service Cuirass. Sa valeur doit être un objet
     ‘cuirass-configuration’, décrit ci-dessous.

   Pour ajouter des travaux de construction, vous devez indiquer le
champ ‘specifications’ de la configuration. Par exemple, voici un
exemple qui construira tous les paquets fournis par le canal
‘my-channel’.

     (define %cuirass-specs
       #~(list (specification
                (name "my-channel")
                (build '(channels my-channel))
                (channels
                 (cons (channel
                        (name 'my-channel)
                        (url "https://my-channel.git"))
                       %default-channels)))))

     (service cuirass-service-type
              (cuirass-configuration
               (specifications %cuirass-specs)))

   Pour construire le paquet ‘linux-libre’ défini par le canal Guix par
défaut, on peut utiliser la configuration suivante.

     (define %cuirass-specs
       #~(list (specification
                (name "my-linux")
                (build '(packages "linux-libre")))))

     (service cuirass-service-type
              (cuirass-configuration
               (specifications %cuirass-specs)))

   Les autres possibilités de configuration, ainsi que l’enregistrement
de spécification lui-même sont décrits dans le manuel de Cuirass (*note
(cuirass)Specifications::).

   Tandis que les informations liés aux travaux de construction sont
directement dans les spécifications, les paramètres globaux pour le
processus ‘cuirass’ sont accessibles dans les autres champs de
‘cuirass-configuration’.

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

     ‘cuirass’ (par défaut : ‘cuirass’)
          Le paquet Cuirass à utiliser.

     ‘log-file’ (par défaut : ‘"/var/log/cuirass.log"’)
          Emplacement du fichier de journal.

     ‘web-log-file’ (par défaut : ‘"/var/log/cuirass-web.log"’)
          Emplacement du fichier journal utilisé par l’interface web.

     ‘cache-directory’ (par défaut : ‘"/var/cache/cuirass"’)
          Emplacement du cache du dépôt.

     ‘user’ (par défaut : ‘"cuirass"’)
          Propriétaire du processus ‘cuirass’.

     ‘group’ (par défaut : ‘"cuirass"’)
          Groupe du propriétaire du processus ‘cuirass’.

     ‘interval’ (par défaut : ‘60’)
          Nombre de secondes entre les mises à jour du dépôt suivis des
          travaux de Cuirass.

     ‘parameters’ (par défaut : ‘#f’)
          Lit les paramètres dans le fichier PARAMETERS. Les paramètres
          pris en charges sont décrits ici (*note
          (cuirass)Parameters::).

     ‘remote-server’ (par défaut : ‘#f’)
          Un enregistrement ‘cuirass-remote-server-configuration’ pour
          utiliser le mécanisme de construction distante ou ‘#f’ pour
          utiliser le mécanisme de construction par défaut.

     ‘database’ (par défaut : ‘"dbname=cuirass host=/var/run/postgresql"’)
          Utiliser DATABASE comme base de données contenant les travaux
          et les résultats des constructions passées. Comme Cuirass
          utilise PostgreSQL comme moteur de base de données, DATABASE
          doit être une chaîne de la même forme que ‘"dbname=cuirass
          host=localhost"’.

     ‘port’ (par défaut : ‘8081’)
          Numéro de port utilisé pour le serveur HTTP.

     ‘host’ (par défaut : ‘"localhost"’)
          Écoute sur l’interface réseau de HOST. La valeur par défaut
          est d’accepter les connexions depuis localhost.

     ‘specifications’ (par défaut : ‘#~'()’)
          Une gexp (*note G-Expressions::) qui s’évalue en une liste
          d’enregistrement de spécifications. L’enregistrement de
          spécification est décrit dans le manuel de Cuirass (*note
          (cuirass)Specifications::).

     ‘use-substitutes?’ (par défaut : ‘#f’)
          Cela permet d’utiliser des substituts pour éviter de
          construire toutes les dépendance d’un travail depuis les
          sources.

     ‘one-shot?’ (par défaut : ‘#f’)
          N’évaluer les spécification et construire les dérivations
          qu’une seule fois.

     ‘fallback?’ (par défaut : ‘#f’)
          Lorsque la substitution d’un binaire pré-construit échoue,
          revenir à la construction locale du paquet.

     ‘extra-options’ (par défaut : ‘'()’)
          Options supplémentaires à passer au lancement des processus de
          Cuirass.

Cuirass, construction distante
..............................

Cuirass prend en charge deux mécanisme pour construire les dérivations.

   • Par le démon Guix local. C’est le mécanisme de construction par
     défaut. Une fois les constructions évaluées, elles sont envoyées au
     démon Guix local. Cuirass écoute ensuite la sortie du démon Guix
     pour détecter les divers événements de construction.

   • Par le mécanisme de construction distante. Les constructions ne
     sont pas soumises au démon Guix local. À la place, un serveur
     distant distribue les requêtes de construction aux serveurs
     connectés, en fonction des priorités de construction.

   Pour active ce mode de construction, vous devez passer un
enregistrement ‘cuirass-remote-server-configuration’ au champ
‘remote-server’ de l’enregistrement ‘cuirass-configuration’.
L’enregistrement ‘cuirass-remote-server-configuration’ est décrit plus
bas.

   Ce mode de construction passe mieux à l’échelle que celui par défaut.
C’est le mode de construction utilisé sur la ferme de construction de
GNU Guix <https://ci.guix.gnu.org>. Vous devriez l’utiliser si vous
utilisez Cuirass pour construire un grand nombre de paquets.

 -- Type de données : cuirass-remote-server-configuration
     Le type de données représentant la configuration des serveurs
     distants de Cuirass.

     ‘backend-port’ (par défaut : ‘5555’)
          Le port TCP pour communiquer avec les processus
          ‘remote-worker’ via ZMQ. Sa valeur par défaut est ‘5555’.

     ‘log-port’ (par défaut : ‘5556’)
          Le port TCP du serveur de journalisation. Sa valeur par défaut
          est ‘5556’.

     ‘publish-port’ (par défaut : ‘5557’)
          Le port TCP du serveur de publication. Sa valeur par défaut
          est ‘5557’.

     ‘log-file’ (par défaut : ‘"/var/log/cuirass-remote-server.log"’)
          Emplacement du fichier de journal.

     ‘cache’ (par défaut : ‘"/var/cache/cuirass/remote"’)
          Utiliser le répertoire CACHE pour mettre les journaux en
          cache.

     ‘trigger-url’ (par défaut : ‘#f’)
          Lorsqu’un substitut a été correctement récupéré, cause la
          préparation d’un substitut sur TRIGGER-URL.

     ‘public-key’
     ‘private-key’
          Utilise les FICHIERs spécifiques comme pair de clefs utilisées
          pour signer les éléments avant de les publier.

   Au moins un serveur distant doit aussi être démarré sur une machine
du réseau local pour effectivement effectuer les constructions et
rapporter leur état.

 -- Type de données : cuirass-remote-worker-configuration
     Type de données représentant la configuration des serveurs distants
     de Cuirass.

     ‘cuirass’ (par défaut : ‘cuirass’)
          Le paquet Cuirass à utiliser.

     ‘workers’ (par défaut : ‘1’)
          Démarre WORKERS travailleurs en parallèle.

     ‘server’ (par défaut : ‘#f’)
          Ne pas utiliser Avahi pour découvrir des serveurs et se
          connecter à l’IP ‘server’ donnée à la place.

     ‘systems’ (par défaut : ‘(list (%current-system))’)
          Ne demander des constructions que pour les systèmes SYSTEMS
          donnés.

     ‘log-file’ (par défaut : ‘"/var/log/cuirass-remote-worker.log"’)
          Emplacement du fichier de journal.

     ‘publish-port’ (par défaut : ‘5558’)
          Le port TCP du serveur de publication. La valeur par défaut
          est ‘5558’.

     ‘public-key’
     ‘private-key’
          Utilise les FICHIERs spécifiques comme pair de clefs utilisées
          pour signer les éléments avant de les publier.

Laminar
.......

Laminar (https://laminar.ohwg.net/) est service d’intégration continue
léger et modulaire. Il n’a pas d’interface de configuration web et
utilise plutôt des fichiers de configuration et des scripts sous
contrôle de version.

   Laminar encourage l’utilisation d’outils existants comme bash et cron
au lieu de les réinventer.

 -- Procédure Scheme : laminar-service-type
     Le type du service Laminar. Sa valeur doit être un objet
     ‘laminar-configuration’, décrit ci-dessous.

     Toutes les configurations ont des valeurs par défaut, une
     configuration minimale pour lancer Laminar se trouve plus bas. Par
     défaut, l’interface web est disponible sur le port 8080.

          (service laminar-service-type)

 -- Type de données : laminar-configuration
     Type données qui représente la configuration de Laminar.

     ‘laminar’ (par défaut : ‘laminar’)
          Le paquet Laminar à utiliser.

     ‘home-directory’ (par défaut : ‘"/var/lib/laminar"’)
          Le répertoire de la configuration des travaux et des
          répertoires d’exécution.

     ‘bind-http’ (par défaut : ‘"*:8080"’)
          L’interface et le port ou la socket unix sur laquelle laminard
          écoutera les connexions entrantes sur l’interface web.

     ‘bind-rpc’ (par défaut : ‘"unix-abstract:laminar"’)
          L’interface et le port ou la socket unix sur laquelle laminard
          écoutera les commandes entrantes comme les requêtes de
          construction.

     ‘title’ (par défaut : ‘"Laminar"’)
          Le titre de la page à afficher sur l’interface web.

     ‘keep-rundirs’ (par défaut : ‘0’)
          Indiquez un entier indiquant le nombre de répertoire
          d’exécution garder par tache. Les répertoires avec les numéros
          les plus petits seront supprimé. La valeur par défaut est 0,
          ce qui signifie que tous les répertoires d’exécution seront
          immédiatement supprimés.

     ‘archive-url’ (par défaut : ‘#f’)
          L’interface web servi par laminard utilisera cette URL pour
          former les liens vers les artefacts des travaux archivés.

     ‘base-url’ (par défaut : ‘#f’)
          URL de base à utiliser pour les liens vers laminar.


File: guix.fr.info,  Node: Services de gestion de l'énergie,  Next: Services audio,  Prev: Intégration continue,  Up: Services

10.8.24 Services de gestion de l’énergie
----------------------------------------

Démon TLP
.........

Le module ‘(gnu services pm)’ fournit une définition de service Guix
pour l’outil de gestion d’énergie Linux TLP.

   TLP active plusieurs modes un espace utilisateur et dans le noyau.
Contrairement à ‘upower-service’, ce n’est pas un outil passif de
surveillance, puisqu’il applique des paramètres personnalisés à chaque
fois qu’il détecte une nouvelle source d’énergie. Vous pouvez trouver
plus d’informations sur la page d’accueil de TLP
(https://linrunner.de/en/tlp/tlp.html).

 -- Variable Scheme : tlp-service-type
     Le type de service pour l’outil TLP. Les paramètres par défaut sont
     optimisés pour la durée de la batterie sur la plupart des systèmes,
     mais vous pouvez les modifier comme vous voulez en ajoutant un
     ‘tlp-configuration’ valide :
          (service tlp-service-type
                   (tlp-configuration
                    (cpu-scaling-governor-on-ac (list "performance"))
                    (sched-powersave-on-bat? #t)))

   Chaque définition de paramètre est précédée par son type ; par
exemple, ‘boolean foo’ indique que le paramètre ‘foo’ doit être spécifié
comme un booléen. Les types qui commencent par ‘maybe-’ dénotent des
paramètres qui n’apparaîtront pas dans la configuration de TLP lorsque
leur valeur est ‘'disabled’.

   Les champs de ‘tlp-configuration’ disponibles sont :

 -- paramètre de ‘tlp-configuration’ : package tlp
     Le paquet TLP.

 -- paramètre de ‘tlp-configuration’ : boolean tlp-enable?
     Indiquez vrai si vous souhaitez activer TLP.

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

 -- paramètre de ‘tlp-configuration’ : string tlp-default-mode
     Mode par défaut lorsqu’aucune source d’énergie ne peut être
     détectée. Les possibilités sont AC et BAT.

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

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          disk-idle-secs-on-ac
     Nombre de secondes que le noyau Linux doit attendre après que les
     disques s’arrêtent pour se synchroniser quand il est sur secteur.

     La valeur par défaut est ‘0’.

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          disk-idle-secs-on-bat
     Comme ‘disk-idle-ac’ mais en mode batterie.

     La valeur par défaut est ‘2’.

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          max-lost-work-secs-on-ac
     Périodicité du nettoyage des pages invalidées, en secondes.

     La valeur par défaut est ‘15’.

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          max-lost-work-secs-on-bat
     Comme ‘max-lost-work-secs-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘60’.

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          cpu-scaling-governor-on-ac
     Gouverneur de fréquence d’horloge sur secteur. Avec le pilote
     intel_pstate, les possibilités sont powersave et performance. Avec
     le pilote acpi-cpufreq, les possibilités sont ondemand, powersave,
     performance et conservative.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          cpu-scaling-governor-on-bat
     Comme ‘cpu-scaling-governor-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-scaling-min-freq-on-ac
     Indique la fréquence d’horloge minimale pour le gouverneur sur
     secteur.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-scaling-max-freq-on-ac
     Indique la fréquence d’horloge maximale pour le gouverneur sur
     secteur.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-scaling-min-freq-on-bat
     Indique la fréquence d’horloge minimale pour le gouverneur sur
     batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-scaling-max-freq-on-bat
     Indique la fréquence d’horloge maximale pour le gouverneur sur
     batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-min-perf-on-ac
     Limite le P-état minimum pour contrôler la dissipation de puissance
     dans le CPU, sur secteur. Les valeurs sont indiqués comme un
     pourcentage des performances disponibles.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-max-perf-on-ac
     Limite le P-état maximum pour contrôler la dissipation de puissance
     dans le CPU, sur secteur. Les valeurs sont indiqués comme un
     pourcentage des performances disponibles.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-min-perf-on-bat
     Comme ‘cpu-min-perf-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-non-negative-integer
          cpu-max-perf-on-bat
     Comme ‘cpu-max-perf-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-boolean cpu-boost-on-ac?
     Active la fonctionnalité turbo boost du CPU sur secteur.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-boolean cpu-boost-on-bat?
     Comme ‘cpu-boost-on-ac?’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : boolean sched-powersave-on-ac?
     Permet au noyau Linux de minimiser le nombre de cœurs/hyper-threads
     CPU utilisés lorsque la charge est faible.

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

 -- paramètre de ‘tlp-configuration’ : boolean sched-powersave-on-bat?
     Comme ‘sched-powersave-on-ac?’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : boolean nmi-watchdog?
     Active le chien de garde NMI du noyau Linux.

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

 -- paramètre de ‘tlp-configuration’ : maybe-string phc-controls
     Pour les noyaux Linux avec le correctif PHC, change le voltage du
     CPU. Une valeur serait par exemple ‘"F:V F:V F:V F:V"’.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : string energy-perf-policy-on-ac
     Indique le niveau de performance du CPU par rapport à la politique
     de gestion de l’énergie sur secteur. Les possibilités sont
     performance, normal et powersave.

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

 -- paramètre de ‘tlp-configuration’ : string energy-perf-policy-on-bat
     Comme ‘energy-perf-policy-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : space-separated-string-list
          disks-devices
     Périphériques de disque dur.

 -- paramètre de ‘tlp-configuration’ : space-separated-string-list
          disk-apm-level-on-ac
     Niveau de gestion de l’énergie avancé des disques durs.

 -- paramètre de ‘tlp-configuration’ : space-separated-string-list
          disk-apm-level-on-bat
     Comme ‘disk-apm-bat’ mais en mode batterie.

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          disk-spindown-timeout-on-ac
     Délai d’attente pour arrêter de faire tourner les disques. Une
     valeur doit être spécifiée pour chaque disque dur déclaré.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          disk-spindown-timeout-on-bat
     Comme ‘disk-spindown-timeout-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          disk-iosched
     Sélectionne l’ordonnanceur d’entrées-sorties pour le disque. Une
     valeur doit être spécifiée pour chaque disque déclaré. Les
     possibilités sont par exemple cfq, deadline et noop.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : string sata-linkpwr-on-ac
     Niveau de gestion de l’énergie des lien SATA aggressive (ALPM). Les
     possibilités sont min_power, medium_power et max_performance.

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

 -- paramètre de ‘tlp-configuration’ : string sata-linkpwr-on-bat
     Comme ‘sata-linkpwr-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : maybe-string
          sata-linkpwr-blacklist
     Exclu les périphériques SATA spécifiés de la gestion de l’énergie
     des liens.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-on-off-boolean
          ahci-runtime-pm-on-ac?
     Active la gestion de l’énergie à l’exécution pour les contrôleurs
     AHCI et les disques, sur secteur.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-on-off-boolean
          ahci-runtime-pm-on-bat?
     Comme ‘ahci-runtime-pm-on-ac’ mais en mode batterie.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          ahci-runtime-pm-timeout
     Secondes d’inactivités avant de suspendre les disques.

     La valeur par défaut est ‘15’.

 -- paramètre de ‘tlp-configuration’ : string pcie-aspm-on-ac
     Niveau de gestion de l’énergie des états actifs de PCI Express. Les
     possibilités sont default, performance et powersave.

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

 -- paramètre de ‘tlp-configuration’ : string pcie-aspm-on-bat
     Comme ‘pcie-aspm-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : string radeon-power-profile-on-ac
     Niveau de vitesse de l’horloge des cartes graphiques Radeon. Les
     possibilités sont low, mid, high, auto et default.

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

 -- paramètre de ‘tlp-configuration’ : string
          radeon-power-profile-on-bat
     Comme ‘radeon-power-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : string radeon-dpm-state-on-ac
     Méthode de gestion de l’énergie dynamique de Radeon (DPM). Les
     possibilités sont battery et performance.

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

 -- paramètre de ‘tlp-configuration’ : string radeon-dpm-state-on-bat
     Comme ‘radeon-dpm-state-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : string
          radeon-dpm-perf-level-on-ac
     Niveau de performance de DPM. Les possibilités sont auto, low et
     high.

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

 -- paramètre de ‘tlp-configuration’ : string
          radeon-dpm-perf-level-on-bat
     Comme ‘radeon-dpm-perf-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : on-off-boolean wifi-pwr-on-ac?
     Mode de gestion de l’énergie wifi.

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

 -- paramètre de ‘tlp-configuration’ : on-off-boolean wifi-pwr-on-bat?
     Comme ‘wifi-power-ac?’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : y-n-boolean wol-disable?
     Désactive wake on LAN.

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

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          sound-power-save-on-ac
     Durée d’attente en secondes avant d’activer la gestion de l’énergie
     audio sur les périphériques Intel HDA et AC97. La valeur 0
     désactive la gestion de l’énergie.

     La valeur par défaut est ‘0’.

 -- paramètre de ‘tlp-configuration’ : non-negative-integer
          sound-power-save-on-bat
     Comme ‘sound-powersave-ac’ mais en mode batterie.

     La valeur par défaut est ‘1’.

 -- paramètre de ‘tlp-configuration’ : y-n-boolean
          sound-power-save-controller?
     Désactive le contrôleur en mode de gestion de l’énergie sur les
     périphériques Intel HDA.

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

 -- paramètre de ‘tlp-configuration’ : boolean bay-poweroff-on-bat?
     Active le périphérique optique AltraBay/MediaBay en mode batterie.
     Le périphérique peut être de nouveau alimenté en lâchant (et en
     réinsérant) le levier d’éjection ou en appuyant sur le bouton
     d’éjection sur les modèles plus récents.

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

 -- paramètre de ‘tlp-configuration’ : string bay-device
     Nom du périphérique optique à éteindre.

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

 -- paramètre de ‘tlp-configuration’ : string runtime-pm-on-ac
     Gestion de l’énergie à l’exécution sur les bus PCI(e). Les
     possibilités sont on et auto.

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

 -- paramètre de ‘tlp-configuration’ : string runtime-pm-on-bat
     Comme ‘runtime-pm-ac’ mais en mode batterie.

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

 -- paramètre de ‘tlp-configuration’ : boolean runtime-pm-all?
     Gestion de l’énergie à l’exécution pour tous les bus PCI(e), sauf
     ceux en liste noire.

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

 -- paramètre de ‘tlp-configuration’ : maybe-space-separated-string-list
          runtime-pm-blacklist
     Exclue les adresses des périphériques PCI(e) spécifiés de la
     gestion de l’énergie à l’exécution.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : space-separated-string-list
          runtime-pm-driver-blacklist
     Exclue les périphériques PCI(e) assignés aux pilotes spécifiés de
     la gestion de l’énergie à l’exécution.

 -- paramètre de ‘tlp-configuration’ : boolean usb-autosuspend?
     Active la fonctionnalité de mise en veille automatique de l’USB.

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

 -- paramètre de ‘tlp-configuration’ : maybe-string usb-blacklist
     Exclue les périphériques spécifiés de la mise en veille automatique
     de l’USB.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : boolean usb-blacklist-wwan?
     Exclue les périphériques WWAN de la mise en veille automatique de
     l’USB.

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

 -- paramètre de ‘tlp-configuration’ : maybe-string usb-whitelist
     Inclue les périphériques spécifiés dans la mise en veille
     automatique de l’USB, même s’ils sont déjà exclus par le pilote ou
     via ‘usb-blacklist-wwan?’.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : maybe-boolean
          usb-autosuspend-disable-on-shutdown?
     Active la mise en veille de l’USB avant l’arrêt.

     La valeur par défaut est ‘disabled’.

 -- paramètre de ‘tlp-configuration’ : boolean
          restore-device-state-on-startup?
     Restaure l’état des périphériques radio (bluetooth, wifi, wwan) du
     dernier arrêt au démarrage du système.

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

Démon Thermald
..............

Le module ‘(gnu services pm)’ fournit une interface pour thermald, un
service de gestion de l’horloge CPU qui aide à éviter la surchauffe.

 -- Variable Scheme : thermald-service-type
     C’est le type de service pour thermald
     (https://01.org/linux-thermal-daemon/), le démon de température de
     Linux, responsable du contrôle de l’état thermique des processeurs
     et d’éviter la surchauffe.

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

     ‘ignore-cpuid-check?’ (par défaut : ‘#f’)
          Ignore la vérification des modèles CPU supportés avec cpuid.

     ‘thermald’ (par défaut : THERMALD)
          Objet du paquet de thermald.


File: guix.fr.info,  Node: Services audio,  Next: Services de virtualisation,  Prev: Services de gestion de l'énergie,  Up: Services

10.8.25 Services audio
----------------------

Le module ‘(gnu services audio)’ fournit un service qui lance MPD (le
démon de lecture de musique).

Music Player Daemon
...................

Le démon de lecture de musique (MPD) est un service qui joue de la
musique tout en étant contrôlé depuis la machine locale ou à travers le
réseau par divers clients.

   L’exemple suivant montre comment on peut lancer ‘mpd’ en tant
qu’utilisateur ‘"bob"’ sur le port ‘6666’. Il utilise pulseaudio pour la
sortie audio.

     (service mpd-service-type
              (mpd-configuration
               (user "bob")
               (port "6666")))

 -- Variable Scheme : mpd-service-type
     Le type de service pour ‘mpd’

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

     ‘user’ (par défaut : ‘"mpd"’)
          L’utilisateur qui lance mpd.

     ‘music-dir’ (par défaut : ‘"~/Music"’)
          Le répertoire à scanner pour trouver les fichiers de musique.

     ‘playlist-dir’ (par défaut : ‘"~/.mpd/playlists"’)
          Le répertoire où stocker les playlists.

     ‘db-file’ (par défaut : ‘"~/.mpd/tag_cache"’)
          Emplacement de la base de données de musiques.

     ‘state-file’ (par défaut : ‘"~/.mpd/state"’)
          Emplacement du fichier qui stocke l’état actuel de MPD.

     ‘sticker-file’ (par défaut : ‘"~/.mpd/sticker.sql"’)
          Emplacement de la base de données de stickers.

     ‘port’ (par défaut : ‘"6600"’)
          Le port sur lequel lancer mpd.

     ‘address’ (par défaut : ‘"any"’)
          L’adresse sur laquelle se lie mpd. Pour utiliser un socket
          Unix domain, un chemin absolu peut être spécifié ici.

     ‘outputs’ (par défaut : ‘"(list (mpd-output))"’)
          Les sorties audio que MPD peut utiliser. Par défaut c’est une
          seule sortie audio utilisant pulseaudio.

 -- Type de données : mpd-output
     Type de données représentant une sortie audio de ‘mpd’.

     ‘name’ (par défaut : ‘"MPD"’)
          Le nom de la sortie audio.

     ‘type’ (par défaut : ‘"pulse"’)
          Le type de sortie audio.

     ‘enabled?’ (par défaut : ‘#t’)
          Spécifie si cette sortie audio est activée au démarrage de
          MPD. Par défaut, toutes les sorties audio sont activées. C’est
          le paramètre par défaut s’il n’y a pas de fichier d’état ;
          avec un fichier d’état, l’état précédent est restauré.

     ‘tags?’ (par défaut : ‘#t’)
          Si la valeur est ‘#f’, MPD n’enverra pas les tags à cette
          sortie. C’est utile uniquement pour les greffons de sortie qui
          peuvent recevoir les tags, comme le greffon de sortie ‘httpd’.

     ‘always-on?’ (par défaut : ‘#f’)
          Si la valeur est ‘#t’, alors MPD essaye de garder cette sortie
          audio toujours ouverte. Cela peut être utile pour les serveurs
          de streaming, lorsque vous ne voulez pas déconnecter tous les
          clients même si la lecture est accidentellement interrompue.

     ‘mixer-type’
          Ce champ accepte un symbole qiu spécifie quel mixeur utiliser
          pour cette sortie audio : le mixeur ‘hardware’, le mixeur
          ‘software’, le mixer ‘null’ (permet de gérer le volume, mais
          sans effet ; peut être utilisé pour implémenter un mixer
          externe) ou aucun mixeur (‘none’).

     ‘extra-options’ (par défaut : ‘'()’)
          Une liste d’association de symboles d’options à des valeurs à
          ajouter à la configuration de la sortie audio.

   L’exemple suivant montre comment configurer ‘mpd’ pour fournir une
sortie de streaming audio HTTP.

     (service mpd-service-type
              (mpd-configuration
                (outputs
                  (list (mpd-output
                          (name "streaming")
                          (type "httpd")
                          (mixer-type 'null)
                          (extra-options
                           `((encoder . "vorbis")
                             (port    . "8080"))))))))


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

10.8.26 Services de virtualisation
----------------------------------

Le module ‘(gnu services virtualization)’ fournit des services pour les
démons libvirt et virtlog, ainsi que d’autres services liés à la
virtualisation.

Démon libvirt
.............

‘libvirtd’ est le démon côté serveur du système de gestion de
virtualisation libvirt. Ce démon tourne sur des serveurs hôtes et
effectue les taches de gestion requises pour les clients virtualisés.

 -- Variable Scheme : libvirt-service-type
     C’est le type du démon libvirt (https://libvirt.org). Sa valeur
     doit être un ‘libvirt-configuration’.

          (service libvirt-service-type
                   (libvirt-configuration
                    (unix-sock-group "libvirt")
                    (tls-port "16555")))

   Les champs de ‘libvirt-configuration’ disponibles sont :

 -- paramètre de ‘libvirt-configuration’ : package libvirt
     Paquet libvirt.

 -- paramètre de ‘libvirt-configuration’ : boolean listen-tls?
     Indique s’il faut écouter des connexions TLS sécurisées sur le port
     TCP/IP public. Vous devez remplir le champ ‘listen’ pour que cela
     ait un effet.

     Il est nécessaire de mettre en place une CA et de créer un
     certificat serveur avant d’utiliser cette fonctionnalité.

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

 -- paramètre de ‘libvirt-configuration’ : boolean listen-tcp?
     Écoute des connexions non-chiffrées sur le port TCP/IP public. Vous
     devez remplir le champ ‘listen’ pour que cela ait un effet.

     L’utilisation des sockets TCP requiert une authentification SASL
     par défaut. Seuls les mécanismes SASL qui prennent en charge le
     chiffrement des données sont permis. Il s’agit de DIGEST_MD5 et
     GSSAPI (Kerberos5).

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

 -- paramètre de ‘libvirt-configuration’ : string tls-port
     Port pour accepter les connexions TLS sécurisées. Il peut s’agir
     d’un numéro de port ou d’un nom de service.

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

 -- paramètre de ‘libvirt-configuration’ : string tcp-port
     Port sur lequel accepter les connexions TCP non sécurisées. Cela
     peut être un numéro de port ou un nom de service.

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

 -- paramètre de ‘libvirt-configuration’ : string listen-addr
     Adresse IP ou nom d’hôte utilisé pour les connexions des clients.

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

 -- paramètre de ‘libvirt-configuration’ : boolean mdns-adv?
     Indique s’il faut publier le service libvirt en mDNS.

     Autrement, vous pouvez désactiver cela pour tous les services en
     stoppant le démon Avahi.

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

 -- paramètre de ‘libvirt-configuration’ : string mdns-name
     Nom publié par défaut sur mDNS. Cela doit être unique sur le réseau
     local.

     La valeur par défaut est ‘"Virtualization Host <hostname>"’.

 -- paramètre de ‘libvirt-configuration’ : string unix-sock-group
     Groupe propriétaire du socket Unix domain. Cela peut être utilisé
     pour permettre à un ensemble d’utilisateurs « de confiance » de
     gérer les fonctionnalités sans devenir root.

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

 -- paramètre de ‘libvirt-configuration’ : string unix-sock-ro-perms
     Permission Unix pour le socket en lecture seule. Il est utilisé
     pour surveiller le statut des VM uniquement.

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

 -- paramètre de ‘libvirt-configuration’ : string unix-sock-rw-perms
     Permission Unix pour le socket en lecture-écriture. La valeur par
     défaut n’autorise que root. Si PolicyKit est activé sur le socket,
     la valeur par défaut change et permet tout le monde (c.-à-d. 0777)

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

 -- paramètre de ‘libvirt-configuration’ : string unix-sock-admin-perms
     Permissions Unix pour le socket d’administration. La valeur par
     défaut ne permet que le propriétaire (root), ne la changez pas à
     moins que vous ne soyez sûr de savoir à qui vous exposez cet accès.

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

 -- paramètre de ‘libvirt-configuration’ : string unix-sock-dir
     Le répertoire dans lequel les sockets sont créés.

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

 -- paramètre de ‘libvirt-configuration’ : string auth-unix-ro
     Schéma d’authentification pour les socket Unix en lecture-seule.
     Par défaut les permissions des socket permettent à n’importe qui de
     se connecter

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

 -- paramètre de ‘libvirt-configuration’ : string auth-unix-rw
     Schéma d’authentification pour les socket UNIX en lecture-écriture.
     Par défaut les permissions du socket ne permettent que root. Si le
     support de PolicyKit a été compilé dans libvirt, la valeur par
     défaut utilise l’authentification « polkit ».

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

 -- paramètre de ‘libvirt-configuration’ : string auth-tcp
     Schéma d’authentification pour les sockets TCP. Si vous n’avez pas
     activé SASL, alors tout le trafic TCP est en clair. Ne le faites
     pas en dehors de scénario de développement ou de test.

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

 -- paramètre de ‘libvirt-configuration’ : string auth-tls
     Schéma d’authentification pour les sockets TLS. Les sockets TLS
     sont déjà chiffrés par la couche TLS, et une authentification
     limitée est effectuée avec les certificats.

     Il est possible d’utiliser de n’importe quel mécanisme
     d’authentification SASL en utilisant « sasl » pour cette option

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

 -- paramètre de ‘libvirt-configuration’ : optional-list access-drivers
     Schéma de contrôle d’accès à l’API.

     Par défaut un utilisateur authentifié peut accéder à toutes les
     API. Les pilotes d’accès peuvent placer des restrictions là-dessus.

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

 -- paramètre de ‘libvirt-configuration’ : string key-file
     Chemin de fichier de la clef du serveur. Si la valeur est une
     chaîne vide, aucune clef privée n’est chargée.

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

 -- paramètre de ‘libvirt-configuration’ : string cert-file
     Chemin de fichier de la clef du serveur. Si la chaîne est vide,
     aucun certificat n’est chargé.

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

 -- paramètre de ‘libvirt-configuration’ : string ca-file
     Chemin de fichier de la clef du serveur. Si la chaîne est vide,
     aucun certificat de CA n’est chargé.

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

 -- paramètre de ‘libvirt-configuration’ : string crl-file
     Chemin de la liste de révocation des certificats. Si la chaîne est
     vide, aucun CRL n’est chargé.

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

 -- paramètre de ‘libvirt-configuration’ : boolean tls-no-sanity-cert
     Désactive la vérification de nos propres certificats serveurs.

     Lorsque libvirtd démarre il effectue des vérifications de routine
     sur ses propres certificats.

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

 -- paramètre de ‘libvirt-configuration’ : boolean tls-no-verify-cert
     Désactive la vérification des certificats clients.

     La vérification des certificats clients est le mécanisme
     d’authentification principal. Tout client qui ne présent pas de
     certificat signé par la CA sera rejeté.

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

 -- paramètre de ‘libvirt-configuration’ : optional-list
          tls-allowed-dn-list
     Liste blanche des Distinguished Name x509 autorisés.

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

 -- paramètre de ‘libvirt-configuration’ : optional-list
          sasl-allowed-usernames
     Liste blanche des noms d’utilisateur SASL permis. Le format des
     noms d’utilisateurs dépend du mécanisme d’authentification SASL.

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

 -- paramètre de ‘libvirt-configuration’ : string tls-priority
     Modifie la chaine de priorité TLS par défaut fixée à la
     compilation. La valeur par défaut est typiquement ‘NORMAL’ à moins
     qu’elle n’ait été modifiée à la compilation. Ne l’indiquez que si
     vous voulez que libvirt agisse différemment des paramètres par
     défaut globaux.

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

 -- paramètre de ‘libvirt-configuration’ : integer max-clients
     Nombre maximum de connexions clientes en même temps sur tous les
     sockets.

     La valeur par défaut est ‘5000’.

 -- paramètre de ‘libvirt-configuration’ : integer max-queued-clients
     Longueur maximum de la queue de connexions en attente d’acceptation
     du démon. Remarquez que certains protocoles supportant la
     retransmission peuvent obéir à ce paramètre pour qu’une connexion
     ultérieure réussisse.

     La valeur par défaut est ‘1000’.

 -- paramètre de ‘libvirt-configuration’ : integer max-anonymous-clients
     Longueur maximum de la queue des clients acceptés mais pas
     authentifiés. Indiquez zéro pour désactiver ce paramètre

     La valeur par défaut est ‘20’.

 -- paramètre de ‘libvirt-configuration’ : integer min-workers
     Nombre de processus de travail démarrés initialement.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer max-workers
     Nombre maximum de threads de travail.

     Si le nombre de clients actifs dépasse ‘min-workers’, plus de
     threads seront démarrés, jusqu’à la limite de max_workers.
     Typiquement vous voulez que max_workers soit égal au nombre maximum
     de clients permis.

     La valeur par défaut est ‘20’.

 -- paramètre de ‘libvirt-configuration’ : integer prio-workers
     Nombre de travailleurs prioritaires. Si tous les threads de travail
     du groupe ci-dessus sont bloqués, certains appels marqués comme
     prioritaires (notamment domainDestroy) peuvent être exécutés par ce
     groupe.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer max-requests
     Limite globale totale sur les appels RPC concurrents.

     La valeur par défaut est ‘20’.

 -- paramètre de ‘libvirt-configuration’ : integer max-client-requests
     Limite de requêtes concurrentes depuis une connexion cliente
     unique. Pour éviter qu’un client ne monopolise le serveur, vous
     devriez indiquer une petite partie des paramètres global
     max_requests et max_workers.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer admin-min-workers
     Comme ‘min-workers’ mais pour l’interface d’administration.

     La valeur par défaut est ‘1’.

 -- paramètre de ‘libvirt-configuration’ : integer admin-max-workers
     Comme ‘max-workers’ mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer admin-max-clients
     Comme ‘max-clients’ mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer
          admin-max-queued-clients
     Comme ‘max-queued-clients’ mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer
          admin-max-client-requests
     Comme ‘max-client-requests’ mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer log-level
     Niveau de journalisation. 4 : erreurs, 3 : avertissements, 2 :
     information, 1 : débogage.

     La valeur par défaut est ‘3’.

 -- paramètre de ‘libvirt-configuration’ : string log-filters
     Filtres de journalisation.

     Un filtre qui permet de sélectionner un niveau de journalisation
     différent pour une catégorie donnée. Le format d’un filtre est :

        • x:nom

        • x:+nom

     où ‘nom’ est une chaine de caractères qui correspond à la catégorie
     donnée dans ‘VIR_LOG_INIT()’ au début de chaque fichier source de
     libvirt, p. ex. ‘remote’, ‘qemu’ ou ‘util.json’ (le nom dans le
     filtre peut être une sous-chaine du nom complet de la catégorie,
     pour pouvoir correspondre à plusieurs catégories similaires), le
     préfixe facultatif ‘+’ dit à libvirt d’enregistrer les traces de
     piles pour chaque message qui correspond au nom, et ‘x’ est le
     niveau minimal des messages qui devraient être enregistrés :

        • 1 : DEBUG

        • 2 : INFO

        • 3 : WARNING

        • 4 : ERROR

     On peut définir plusieurs filtres dans une seule déclaration de
     filtres, ils doivent juste être séparés par des espaces.

     La valeur par défaut est ‘"3:remote 4:event"’.

 -- paramètre de ‘libvirt-configuration’ : string log-outputs
     Sorties de débogage.

     Une sortie est l’un des endroits où les journaux sont enregistrés.
     Le format d’une sortie peut être :

     ‘x:stderr’
          la sortie va vers stderr

     ‘x:syslog:nom’
          utilise syslog comme sortie et utilise le nom donné comme
          identifiant

     ‘x:file:chemin_fichier’
          la sortie va vers un fichier, avec le chemin donné

     ‘x:journald’
          la sortie va vers le système de journalisation journald

     Dans tous les cas, le préfixe x est le niveau minimal, qui agit
     comme un filtre

        • 1 : DEBUG

        • 2 : INFO

        • 3 : WARNING

        • 4 : ERROR

     Plusieurs sorties peuvent être définies, elles doivent juste être
     séparées par des espaces.

     La valeur par défaut est ‘"3:stderr"’.

 -- paramètre de ‘libvirt-configuration’ : integer audit-level
     Permet de modifier l’utilisation du sous-système d’audit

        • 0 : désactive tout audit

        • 1 : active l’audit, seulement s’il est activé sur l’hôte

        • 2 : active l’audit, et quitte s’il est désactivé sur l’hôte.

     La valeur par défaut est ‘1’.

 -- paramètre de ‘libvirt-configuration’ : boolean audit-logging
     Envoie les messages d’audit via l’infrastructure de journalisation
     de libvirt.

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

 -- paramètre de ‘libvirt-configuration’ : optional-string host-uuid
     UUID de l’hôte. L’UUID ne doit pas avoir tous ses nombres
     identiques.

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

 -- paramètre de ‘libvirt-configuration’ : string host-uuid-source
     Source où lire l’UUID de l’hôte.

        • ‘smbios’ : récupère l’UUID à partir de ‘dmidecode -s
          system-uuid’

        • ‘machine-id’ : récupère l’UUID à partir de ‘/etc/machine-id’

     Si ‘dmidecode’ ne fournit pas un UUID valide, un UUID temporaire
     sera généré.

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

 -- paramètre de ‘libvirt-configuration’ : integer keepalive-interval
     Un message keepalive est envoyé au client après
     ‘keepalive_interval’ secondes d’inactivité pour vérifier si le
     client répond toujours. Si la valeur est -1, libvirtd n’enverra
     jamais de requête keepalive ; cependant les clients peuvent
     toujours en envoyer et le démon y répondra.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer keepalive-count
     Nombre maximum de messages keepalive qui peuvent être envoyés au
     client sans réponse avant que la connexion ne soit considérée comme
     cassée.

     En d’autres termes, la connexion est approximativement fermée après
     ‘keepalive_interval * (keepalive_count + 1)’ secondes après le
     dernier message reçu de la part du client. Lorsque
     ‘keepalive-count’ est à 0, les connexions seront automatiquement
     fermées après ‘keepalive-interval’ secondes d’inactivité sans
     envoyer le moindre message keepalive.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer
          admin-keepalive-interval
     Comme précédemment, mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer admin-keepalive-count
     Comme précédemment, mais pour l’interface d’administration.

     La valeur par défaut est ‘5’.

 -- paramètre de ‘libvirt-configuration’ : integer ovs-timeout
     Délai d’attente pour les appels Open vSwitch.

     L’utilitaire ‘ovs-vsctl’ est utilisé pour la configuration et son
     option de délai d’attente est à 5 secondes pour éviter qu’une
     attente infinie ne bloque libvirt.

     La valeur par défaut est ‘5’.

Démon Virrlog
.............

Le service virtlogd est un démon côté serveur qui fait partie de
libvirt, utilisé pour gérer les journaux des consoles des machines
virtuelles.

   Ce démon n’est pas utilisé directement par les clients libvirt, mais
il est appelé pour eux par ‘libvirtd’. En maintenant les journaux dans
un démon séparé, le démon ‘libvirtd’ principal peut être redémarré sans
risque de perte de journaux. Le démon ‘virtlogd’ a la possibilité de
ré-exécuter exec() sur lui-même quand il reçoit ‘SIGUSR1’, pour
permettre des mises à jour à chaud sans temps mort.

 -- Variable Scheme : virtlog-service-type
     Le type de service pour le démon virtlogd. Sa valeur doit être un
     ‘virtlog-configuration’.

          (service virtlog-service-type
                   (virtlog-configuration
                    (max-clients 1000)))

 -- paramètre de ‘virtlog-configuration’ : integer log-level
     Niveau de journalisation. 4 : erreurs, 3 : avertissements, 2 :
     information, 1 : débogage.

     La valeur par défaut est ‘3’.

 -- paramètre de ‘virtlog-configuration’ : string log-filters
     Filtres de journalisation.

     Un filtre qui permet de sélectionner plusieurs niveaux de
     journalisation pour une catégorie donnée. Le format d’un filtre est
     :

        • x:nom

        • x:+nom

     où ‘nom’ est une chaîne de caractères qui correspond à la catégorie
     donnée dans ‘VIR_LOG_INIT()’ au début de chaque fichier source de
     libvirt, p. ex. « remote », « qemu » ou « util.json » (le nom dans
     le filtre peut être une sous-chaîne du nom complet de la catégorie,
     pour pouvoir correspondre à plusieurs catégories similaires), le
     préfixe facultatif « + » dit à libvirt d’enregistrer les traces de
     piles pour chaque message qui correspond au nom, et ‘x’ est le
     niveau minimal des messages qui devraient être enregistrés :

        • 1 : DEBUG

        • 2 : INFO

        • 3 : WARNING

        • 4 : ERROR

     On peut définir plusieurs filtres dans une seule déclaration de
     filtres, ils doivent juste être séparés par des espaces.

     La valeur par défaut est ‘"3:remote 4:event"’.

 -- paramètre de ‘virtlog-configuration’ : string log-outputs
     Sorties de débogage.

     Une sortie est l’un des endroits où les journaux sont enregistrés.
     Le format d’une sortie peut être :

     ‘x:stderr’
          la sortie va vers stderr

     ‘x:syslog:nom’
          utilise syslog comme sortie et utilise le nom donné comme
          identifiant

     ‘x:file:chemin_fichier’
          la sortie va vers un fichier, avec le chemin donné

     ‘x:journald’
          la sortie va vers le système de journalisation journald

     Dans tous les cas, le préfixe x est le niveau minimal, qui agit
     comme un filtre

        • 1 : DEBUG

        • 2 : INFO

        • 3 : WARNING

        • 4 : ERROR

     Plusieurs sorties peuvent être définies, elles doivent juste être
     séparées par des espaces.

     La valeur par défaut est ‘"3:stderr"’.

 -- paramètre de ‘virtlog-configuration’ : integer max-clients
     Nombre maximum de connexions clientes en même temps sur tous les
     sockets.

     La valeur par défaut est ‘1024’.

 -- paramètre de ‘virtlog-configuration’ : integer max-size
     Taille de fichier maximale avant roulement.

     La valeur par défaut est ‘2MB’

 -- paramètre de ‘virtlog-configuration’ : integer max-backups
     Nombre maximal de fichiers de sauvegardes à garder.

     La valeur par défaut est ‘3’

Émulation transparente avec QEMU
................................

‘qemu-binfmt-service-type’ fournit le support de l’émulation
transparente de binaires construits pour des architectures différentes —
p. ex. il permet d’exécuter de manière transparente des programmes ARMv7
sur une machine x86_64. Cela se fait en combinant l’émulateur QEMU
(https://www.qemu.org) et la fonctionnalité ‘binfmt_misc’ du noyau
Linux. Cette fonctionnalité ne vous permet que d’émuler GNU/Linux sur
une architecture différente, mais regardez plus bas pour GNU/Hurd.

 -- Variable Scheme : qemu-binfmt-service-type
     Le type du service QEMU/binfmt pour l’émulation transparente. Sa
     valeur doit être un objet ‘qemu-binfmt-configuration’, qui spécifie
     le paquet QEMU à utiliser ainsi que l’architecture que vous voulez
     émuler :

          (service qemu-binfmt-service-type
                   (qemu-binfmt-configuration
                     (platforms (lookup-qemu-platforms "arm" "aarch64"))))

     Dans cet exemple, on active l’émulation transparente pour les
     plateformes ARM et aarch64. Lancer ‘herd stop qemu-binfmt’ l’éteint
     et lancer ‘herd start qemu-binfmt’ le rallume (*note the ‘herd’
     command: (shepherd)Invoking herd.).

 -- Type de données : qemu-binfmt-configuration
     La configuration du service ‘qemu-binfmt’.

     ‘platforms’ (par défaut : ‘'()’)
          La liste des plates-formes émulées par QEMU. Chaque élément
          doit être un objet “platform object” tel que renvoyé par
          ‘lookup-qemu-platforms’ (voir plus bas).

          Par exemple, supposons que vous soyez sur une machine x86_64
          et que vous avez ce services :

               (service qemu-binfmt-service-type
                        (qemu-binfmt-configuration
                          (platforms (lookup-qemu-platforms "arm"))))

          Vous pouvez lancer :

               guix build -s armhf-linux inkscape

          et cela construira Inkscape pour ARMv7 _comme s’il s’agissait
          d’une construction native_, de manière transparente avec QEMU
          pour émuler un CPU ARMv7. Plutôt pratique si vous voulez
          tester un paquet construit pour une architecture à laquelle
          vous n’avez pas accès !

     ‘qemu’ (par défaut : ‘qemu’)
          Le paquet QEMU à utiliser.

 -- Procédure Scheme : lookup-qemu-platforms PLATFORMS...
     Renvoie la liste des objets de plates-formes QEMU correspondant à
     PLATFORMS.... PLATFORMS doit être une liste de chaînes de
     caractères correspondant aux noms de plates-formes, comme ‘"arm"’,
     ‘"sparc"’, ‘"mips64el"’ etc.

 -- Procédure Scheme : qemu-platform? OBJ
     Renvoie vrai s iOBJ est un objet de plate-forme.

 -- Procédure Scheme : qemu-platform-name PLATFORM
     Renvoie le nom de PLATFORM — une chaîne comme ‘"arm"’.

Exécuter le Hurd dans une machine virtuelle
...........................................

Le service ‘hurd-vm’ permet de lancer GNU/Hurd dans une machine
virtuelle (VM), un “childhurd”. Ce service est conçu pour être utilisé
sur GNU/Linux et la configuration du système GNU/Hurd donné est compilée
de manière croisée. La machine virtuelle est un service Shepherd qui a
les noms ‘hurd-vm’ et ‘childhurd’ et qui peut être contrôlé avec les
commandes suivantes :

     herd start hurd-vm
     herd stop childhurd

   Lorsque le service est lancé, vous pouvez voir sa console en vous y
connectant avec un client VNC, par exemple avec :

     guix environment --ad-hoc tigervnc-client -- \
              vncviewer localhost:5900

   La configuration par défaut (voir ‘hurd-vm-configuration’ ci-dessous)
crée un serveur secure shell (SSH) dans votre système GNU/Hurd, que QEMU
(l’émulateur de machine virtuelle) redirige sur le port 10222 de l’hôte.
Ainsi, vous pouvez vous connecter en SSH au childhurd avec :

     ssh root@localhost -p 10022

   Le childhurd est volatile et sans état . il démarre avec un nouveau
système de fichier à chaque fois que vous le redémarrez. Par défaut
cependant, tous les fichiers sous ‘/etc/childhurd’ sur l’hôte sont
copiés tels quels sur le système de fichiers racine du childhurd à son
démarrage. Cela vous permet d’initialiser des « secrets » à l’intérieur
de la VM : les clés hôtes SSH, les clés de substituts autorisés, etc —
voir l’explication de ‘secret-root’ ci-dessous.

 -- Variable Scheme : hurd-vm-service-type
     C’est le type du service du Hurd dans une machine virtuelle. Sa
     valeur doit être un objet ‘hurd-vm-configuration’, qui spécifie le
     système d’exploitation (*note référence de système
     d'exploitation::) et la taille de disque pour la machine virtuelle
     du Hurd, le paquet QEMU à utiliser ainsi que les options pour le
     lancer.

     Par exemple :

          (service hurd-vm-service-type
                   (hurd-vm-configuration
                    (disk-size (* 5000 (expt 2 20))) ;5G
                    (memory-size 1024)))             ;1024MiB

     créerait une image disque assez grande pour construire GNU Hello,
     avec une peu de place en plus.

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

     ‘os’ (par défaut : %HURD-VM-OPERATING-SYSTEM)
          Le système d’exploitation à instancier. La valeur par défaut
          est le système minimal avec un démon OpenSSH permissif en
          écoute sur le port 2222 (*note ‘openssh-service-type’:
          Services réseau.).

     ‘qemu’ (par défaut : ‘qemu-minimal’)
          Le paquet QEMU à utiliser.

     ‘image’ (par défaut : HURD-VM-DISK-IMAGE)
          La procédure utilisée pour construire l’image disque
          construite à partir de cette configuration.

     ‘disk-size’ (par défaut : ‘'guess’)
          La taille de l’image disque.

     ‘memory-size’ (par défaut : ‘512’)
          La taille de mémoire de la machine virtuelle en mébioctets.

     ‘options’ (par défaut : ‘'("--snapshot")’)
          Options supplémentaires pour lancer QEMU.

     ‘id’ (par défaut : ‘#f’)
          Si l’option est indiquée, c’est un entier strictement positif
          utilisé créer plusieurs instances de childhurd. Il est ajouté
          au nom du service, p. ex. ‘childhurd1’.

     ‘net-options’ (par défaut : HURD-VM-NET-OPTIONS)
          La procédure utilisée pour produire une liste d’options réseau
          pour QEMU.

          Par défaut, elle produit

               '("--device" "rtl8139,netdev=net0"
                 "--netdev" "user,id=net0\
                             ,hostfwd=tcp:127.0.0.1:SECRETS-PORT-:1004\
                             ,hostfwd=tcp:127.0.0.1:SSH-PORT-:2222\
                             ,hostfwd=tcp:127.0.0.1:VNC-PORT-:5900")

          avec les ports renvoyés :

               SECRETS-PORT: (+ 11004 (* 1000 ID))
               SSH-PORT: (+ 10022 (* 1000 ID))
               VNC-PORT: (+ 15900 (* 1000 ID))

     ‘secret-root’ (par défaut : ‘/etc/childhurd’)
          Le répertoire racine avec des secrets externes à installer
          dans le childhurd une fois lancé. Les childhurds sont
          volatile, ce qiu signifie qu’à chaque démarrage, les secrets
          comme les clés hôtes SSH et la clé de signature de Guix sont
          recréés.

          Si le répertoire ‘/etc/childhurd’ n’existe pas, le
          ‘secret-service’ qui tourne dans le Childhurd recevra une
          liste vide de secrets.

          Par défaut, le service rempli automatiquement ‘/etc/childhurd’
          avec les secrets non-volatiles suivants, à moins qu’ils
          existent déjà :

               /etc/childhurd/etc/guix/acl
               /etc/childhurd/etc/guix/signing-key.pub
               /etc/childhurd/etc/guix/signing-key.sec
               /etc/childhurd/etc/ssh/ssh_host_ed25519_key
               /etc/childhurd/etc/ssh/ssh_host_ecdsa_key
               /etc/childhurd/etc/ssh/ssh_host_ed25519_key.pub
               /etc/childhurd/etc/ssh/ssh_host_ecdsa_key.pub

          Ces fichiers sont automatiquement envoyés à la VM Hurd invitée
          au démarrage, avec les permissions.

          Avec ces fichiers en place, il ne manque plus grand chose pour
          pouvoir permettre à l’hôte de décharger les constructions
          ‘i586-gnu’ au childhurd :

            1. Autoriser la clé du childhurd sur l’hôte pour que l’hôte
               puisse accepter les constructions venant du childhurd, ce
               qui peut se faire de cette manière :

                    guix archive --authorize < \
                      /etc/childhurd/etc/guix/signing-key.pub

            2. Ajouter le childhurd à ‘/etc/guix/machines.scm’ (*note
               Réglages du délestage du démon::).

          Nous travaillons à rendre cela automatique — contactez nous
          sur <guix-devel@gnu.org> pour en discuter !

   Remarquez que par défaut l’image de la VM est volatile, c.-à-d.
qu’une fois arrêtée le contenu est perdu. Si vous voulez une image avec
état à la place, remplacez les champs ‘image’ et ‘options’ pour enlever
le drapeau ‘--snapshot’ avec quelque chose de ce style-là :

     (service hurd-vm-service-type
              (hurd-vm-configuration
               (image   (const "/out/of/store/writable/hurd.img"))
               (options '())))

Ganeti
......

     Remarque : Ce service est considéré comme étant expérimental. Les
     options de configuration peuvent changer de manière non compatible,
     et tous les paramètres n’ont pas été testés. Si vous utilisez ce
     service, nous vous encourageons à partager votre expérience avec
     <guix-devel@gnu.org>.

   Ganeti est un système de gestion de machines virtuelles. Il est conçu
pour faire tourner les machines virtuelles en continue sur une grappe de
serveurs même dans le cas d’une erreur matérielle, et pour rendre les
taches de maintenance et de récupération faciles. Il consisste en
plusieurs services qui sont décrits plus loin dans cette section. En
plus du service Ganeti, vous aurez besoin du service OpenSSH (*note
‘openssh-service-type’: Services réseau.), et de mettre à jour le
fichier ‘/etc/hosts’ (*note ‘hosts-file’: référence de système
d'exploitation.) avec le nom de la grappe et l’adresse (ou utiliser un
serveur DNS).

   Tous les nœuds participant dans une grappe Ganeti devraient avec la
même configuration de Ganeti et ‘/etc/hosts’. voici un exemple de
configuration pour un nœud d’une grappe Ganeti qui prend en charge
plusieurs moteurs de stockage et installe les “fournisseurs de systèmes”
‘debbotstrap’ et ‘guix’ :

     (use-package-modules virtualization)
     (use-service-modules base ganeti networking ssh)
     (operating-system
       ;; ...
       (host-name "node1")
       (hosts-file (plain-file "hosts" (format #f "
     127.0.0.1       localhost
     ::1             localhost

     192.168.1.200   ganeti.example.com
     192.168.1.201   node1.example.com node1
     192.168.1.202   node2.example.com node2
     ")))

       ;; Installe QEMU pour pouvoir utiliser les instances KVM, ainsi que LVM, DRBD et Ceph
       ;; pour utiliser les moteurs de stockage « plain », « drbd » et « rbd ».
       (packages (append (map specification->package
                              '("qemu" "lvm2" "drbd-utils" "ceph"
                                ;; ajoute les fournisseurs de système debbotstrap et guix.
                                "ganeti-instance-guix" "ganeti-instance-debootstrap"))
                         %base-packages))
       (services
        (append (list (static-networking-service "eth0" "192.168.1.201"
                                                 #:netmask "255.255.255.0"
                                                 #:gateway "192.168.1.254"
                                                 #:name-servers '("192.168.1.252"
                                                                  "192.168.1.253"))

                      ;; Ganeti utilise SSH pour communiquer entre les nœuds.
                      (service openssh-service-type
                               (openssh-configuration
                                (permit-root-login 'without-password)))

                      (service ganeti-service-type
                               (ganeti-configuration
                                ;; cette liste spécifie les chemins du système de fichiers autorisés
                                ;; pour le stockage des images de machines virtuelles.
                                (file-storage-paths '("/srv/ganeti/file-storage"))
                                ;; Cette variable configure une « variante » pour
                                ;; Debootstrap et Guix qui fonctionne avec KVM.
                                (os %default-ganeti-os))))
                %base-services)))

   Nous vous encourageons à lire le guide d’administration de Ganeti
(http://docs.ganeti.org/ganeti/master/html/admin.html) pour apprendre
les diverse options de grappes et les opérations de base. Il y a aussi
un billet de blog
(https://guix.gnu.org/blog/2020/running-a-ganeti-cluster-on-guix/)
décrivant comment configurer et initialiser une petite grappe.

 -- Variable Scheme : ganeti-service-type
     C’est le type de service qui inclus tous les service dont les nœuds
     Ganeti ont besoin.

     Sa valeur est un objet ‘ganeti-configurtaion’ qui définie le paquet
     pour utiliser les opérations en ligne de commande, ainsi que pour
     les divers démons. Les chemins de stockage autorisés et les
     systèmes d’exploitation invités disponibles sont aussi configurés à
     travers ce type de données.

 -- Type de données : ganeti-configuration
     Le service ‘ganeti’ prend les options de configuration suivante :

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser. Il sera installé sur le profil
          du système et rendra ‘gnt-cluster’, ‘gnt-instance’, etc
          disponibles. Remarquez que la valeur spécifiée ici n’affecte
          pas les autres services auxquels se réfère le paquet ‘ganeti’
          (voir plus bas).

     ‘noded-configuration’ (par défaut : ‘(ganeti-noded-configuration)’)
     ‘confd-configuration’ (par défaut : ‘(ganeti-confd-configuration)’)
     ‘wconfd-configuration’ (par défaut : ‘(ganeti-wconfd-configuration)’)
     ‘luxid-configuration’ (par défaut : ‘(ganeti-luxid-configuration)’)
     ‘rapi-configuration’ (par défaut : ‘(ganeti-rapi-configuration)’)
     ‘kvmd-configuration’ (par défaut : ‘(ganeti-kvmd-configuration)’)
     ‘mond-configuration’ (par défaut : ‘(ganeti-mond-configuration)’)
     ‘metad-configuration’ (par défaut : ‘(ganeti-metad-configuration)’)
     ‘watcher-configuration’ (par défaut : ‘(ganeti-watcher-configuration)’)
     ‘cleaner-configuration’ (par défaut : ‘(ganeti-cleaner-configuration)’)

          Ces options contrôlent les divers démons et taches cron
          distribués avec Ganeti. Les valeurs possibles sont détaillées
          plus bas. Pour changer un paramètre, vous devez utiliser le
          type de configuration pour ce service :

               (service ganeti-service-type
                        (ganeti-configuration
                         (rapi-configuration
                          (ganeti-rapi-configuration
                           (interface "eth1"))))
                         (watcher-configuration
                          (ganeti-watcher-configuration
                           (rapi-ip "10.0.0.1"))))

     ‘file-storage-paths’ (par défaut : ‘'()’)
          Liste des répertoire autorisés pour le moteur de stockage de
          fichiers.

     ‘os’ (par défaut : ‘%default-ganeti-os’)
          Liste des enregistrements ‘<ganeti-os>’.

     En résumé ‘ganeti-service-type’ est un raccourci pour la
     déclaration de chaque service individuel :

          (service ganeti-noded-service-type)
          (service ganeti-confd-service-type)
          (service ganeti-wconfd-service-type)
          (service ganeti-luxid-service-type)
          (service ganeti-kvmd-service-type)
          (service ganeti-mond-service-type)
          (service ganeti-metad-service-type)
          (service ganeti-watcher-service-type)
          (service ganeti-cleaner-service-type)

     Plus une extension de service pour ‘etc-service-type’ qui configure
     le moteur de stockage de fichiers et les variantes de systèmes.

 -- Type de données : ganeti-os
     Ce type de données peut être passé au paramètre ‘os’ de
     ‘ganeti-configuration’. Il prend les paramètres suivants :

     ‘name’
          Le nom du fournisseur de système. Il est seulement utilisé
          pour spécifier où la configuration se trouve. Indiquer «
          debootstrap » créera ‘/etc/ganeti/intance-debootstrap’.

     ‘extension’
          Le fichier d’extension pour les variantes de ce type de
          système. Par exemple ‘.conf’ ou ‘.scm’.

     ‘variants’ (par défaut : ‘'()’)
          Une liste d’objets ‘ganeti-os-variant’ pour ce système.

 -- Type de données : ganeti-os-variant
     Type de données représentant une variante de système Ganeti. Il
     prend les paramètres suivants :

     ‘name’
          Le nom de cette variante.

     ‘configuration’
          Un fichier de configuration pour cette variante.

 -- Variable Scheme : %default-debootstrap-hooks
     Cette variable contient les crochet pour configurer le réseau et le
     chargeur d’amorçage GRUB.

 -- variable Scheme : %default-debootstrap-extra-pkgs
     Cette variable contient une liste de paquets requis pour un invité
     complètement virtualisé.

 -- Type de données : debootstrap-configuration

     Ce type de données crée des fichiers de configurations pour le
     fournisseur de système debootstrap.

     ‘hooks’ (par défaut : ‘%default-debootstrap-hooks’)
          Lorsque la valeur n’est pas ‘#f’, cela doit être une
          G-expression qui spécifie un répertoire avec les scripts qui
          seront lancés à l’installation du système. Elle peut aussi
          être une liste de pairs de ‘(nom, simili-fichier)’. Par
          exemple :

               `((99-hello-world . ,(plain-file "#!/bin/sh\necho Hello, World")))

          Cela va créer une répertoire avec un exécutable nommé
          ‘99-hello-world’ et le lancera à chaque fois que cette
          variante est installée. Si la valeur est ‘#f’, les crochets
          dans ‘/etc/ganeti/instance-debootstrap/hooks’ seront utilisés,
          s’ils existent.
     ‘proxy’ (par défaut : ‘#f’)
          Serveur mandataire HTTP facultatif à utiliser.
     ‘mirror’ (par défaut : ‘#f’)
          Le miroir Debian. Habituellement quelque chose comme
          ‘http://ftp.no.debian.org/debian’. La valeur par défaut dépend
          de la distribution.
     ‘arch’ (par défaut : ‘#f’)
          L’architecture pour dpkg. Indiquez ‘armhf’ pour debootstrap
          pour une instnace ARMv7 sur un hôte AArch64. La valeur par
          défaut est l’architecture système actuelle.
     ‘suite’ (par défaut : ‘"stable"’)
          Lorsqu’il est indiqué, ce paramètre doit être une distribution
          Debian comme ‘buster’ ou ‘focal’. Si la valeur est ‘#f’, la
          valeur par défaut du fournisseur de système est utilisée.
     ‘extra-pkgs’ (par défaut : ‘%default-debootstrap-extra-pkgs’)
          Liste des paquets supplémentaires qui seront installés par
          dpkg en plus du système minimal.
     ‘components’ (par défaut : ‘#f’)
          Lorsque la valeur est indiquée, doit être une liste de «
          composants » de répertoires Debian. Par exemple ‘'("main"
          "contrib")’.
     ‘generate-cache?’ (par défaut : ‘#t’)
          Indique s’il faut automatiquement mettre en cache l’archive
          debootstrap générée.
     ‘clean-cache’ (par défaut : ‘14’)
          Supprime le cache après ce nombre de jours. Utilisez ‘#f’ pour
          ne jamais vider le cache.
     ‘partition-style’ (par défaut : ‘'msdos’)
          Le type de partition à créer. Lorsqu’il est indiqué, ce
          paramètre doit être ‘'msdos’, ‘'none’ ou une chaine de
          caractères.
     ‘partition-alignment’ (par défaut : ‘2048’)
          Alignement des partitions en nombre de secteur.

 -- Procédure Scheme : debootstrap-variant NOM CONFIGURATION
     C’est une procédure auxiliaire qui crée un enregistrement
     ‘ganeti-os-variant’. Il prend deux paramètres . un nom et un objet
     ‘debootstrap-configuration’.

 -- Procédure Scheme : debootstrap-os VARIANTS...
     C’est une procédure auxiliaire qui crée un enregistrement
     ‘ganeti-os’. Elle prend une liste de variantes créé avec
     ‘debootstrap-variant’.

 -- Procédure Scheme : guix-variant NAME CONFIGURATION
     C’est une procédure auxiliaire qui crée un enregistrement
     ‘ganeti-os-variant’ à utiliser avec le fournisseur de système Guix.
     Il prend un nom et une G-expression qui renvoie un objet
     simili-fichier (*note file-like objects: G-Expressions.) contenant
     une configuration Guix System.

 -- Procédure Scheme : guix-os VARIANTS...
     C’est une procédure auxiliaire qui crée un enregistrement
     ‘ganeti-os’. Elle prend une liste de variantes produites par
     ‘guix-variant’.

 -- Variable Scheme : %default-debootstrap-variants
     C’est une variable pratique pour que le fournisseur debootstrap
     fonctionne directement sans avoir à déclarer des variantes
     manuellement. Elle contient une seule variante debootrstap avec la
     configuration par défaut :

          (list (debootstrap-variant
                 "default"
                 (debootstrap-configuration)))

 -- Variable Scheme : %default-guix-variants
     C’est une variable pratique pour que le fournisseur Guix fonctionne
     directement sans configuration supplémentaire. Elle crée une
     machine virtuelle qui a un serveur SSH, une console série et
     autorise les clés SSH des hôtes Ganeti.

          (list (guix-variant
                 "default"
                 (file-append ganeti-instance-guix
                              "/share/doc/ganeti-instance-guix/examples/dynamic.scm")))

   Les utilisateur·ice·s peuvent implémenter la prise en charge des
fournisseurs de systèmes inconnus de Guix en étendant les enregistrement
‘ganeti-os’ et ‘ganeti-os-variant’ comme il faut. Par exemple :

     (ganeti-os
      (name "custom")
      (extension ".conf")
      (variants
       (list (ganeti-os-variant
              (name "foo")
              (configuration (plain-file "bar" "this is fine"))))))

   Cela crée ‘/etc/ganeti/instance-custom/variants/foo.conf’ qui pointe
vers un fichier dans le dépôt qui contient ‘this is fine’. Cela crée
aussi ‘/etc/ganeti/instance-custom/variants/variants.list’ qui contient
‘foo’.

   Évidemment cela ne fonctionnera pas avec tous les fournisseurs d’OS
disponibles. Si vous trouvez que cette interface est trop limitée,
contactez-nous sur <guix-devel@gnu.org>.

   Le reste de cette section documente les divers services inclus par
‘ganeti-service-type’.

 -- Variable Scheme : ganeti-noded-service-type
     ‘ganeti-noded’ est le démon responsable des fonctions spécifiques
     au nœud dans le système Ganeti. La valeur de ce service doit être
     un objet ‘ganeti-noded-configuration’.

 -- Type de données : ganeti-noded-configuration
     La configuration du service ‘ganeti-noded’.

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘port’ (par défaut : ‘1811’)
          Port TCP sur lequel le démon de nœud écoute les requêtes
          réseaux.

     ‘address’ (par défaut : ‘"0.0.0.0"’)
          Adresse réseau sur laquelle le démon se lie. L’adresse par
          défaut signifie de se lier à toutes les adresse disponibles.

     ‘interface’ (par défaut : ‘#f’)
          Si une valeur est indiquée, elle doit être une interface
          réseau spécifique (p. ex. ‘eth0’) à laquelle le démon se
          liera.

     ‘max-clients’ (par défaut : ‘20’)
          Cela indique une limite du nombre de connexions clientes
          simultanées que le démon pourra prendre en charge. Les
          connexions au delà de ce nombre sont acceptées, mais aucune
          réponse ne sera envoyée avant que suffisamment de connexions
          ne soient fermées.

     ‘ssl?’ (par défaut : ‘#t’)
          Indique s’il faut utiliser SSL/TLS pour chiffrer les
          communications réseaux. Le certification est automatiquement
          intégré par la grappe et peut être modifié avec ‘gnt-cluster
          renew-crypto’.

     ‘ssl-key’ (par défaut : ‘"/var/lib/ganeti/server.pem"’)
          Cela peut être utilisé pour fournir une clé de chiffrement
          spécifique pour les communications TLS.

     ‘ssl-cert’ (par défaut : ‘"/var/lib/ganeti/server.pem"’)
          Cela peut être utilisé pour fournir un certification
          spécifique pour les communications TLS.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue plus de
          journalisation pour le débogage. Remarque que cela laissera
          fuiter des détails de chiffrement dans les journaux, utilisez
          cette option avec prudence.

 -- Variable Scheme : ganeti-confd-service-type
     ‘ganeti-confd’ répond aux requêtes liées à la configuration de la
     grappe Ganeti. Le but de ce démon est d’avoir une manière rapide et
     très disponible de demander les valeurs de configuration de la
     grappe. Il est automatiquement activé sur tous les “candidats
     maitres”. La valeur de ce service doit être un objet
     ‘ganeti-confd-configuration’.

 -- Type de données : ganeti-confd-configuration
     La configuration du service ‘ganeti-confd’.

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘port’ (par défaut : ‘1814’)
          Le port UDP sur lequel écouter les requêtes réseaux.

     ‘address’ (par défaut : ‘"0.0.0.0"’)
          L’adresse réseau sur laquelle le démon se liera.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-wconfd-service-type
     ‘ganeti-wconfd’ est le démon qui fait autorité sur la configuration
     de la grappe et est la seule entité qui peut y accepter des
     changements. Tous les travaux qui ont besoin de modifier la
     configuration le feront en envoyant les requêtes appropriées à ce
     démon. Il ne tourne que sur le “nœud maitre” et sera
     automatiquement désactivé sur les autres nœuds.

     La valeur de ce service est un objet ‘ganeti-wconfd-configuration’.

 -- Type de données : ganeti-wconfd-configuration
     La configuration du service ‘ganeti-wconfd’.

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘no-voting?’ (par défaut : ‘#f’)
          Le démon refusera de démarrer si la majorité des nœuds de la
          grappe ne sont pas d’accord pour dire qu’il est le nœud
          maitre. Indiquez ‘#t’ pour le démarre même si le quorum n’a
          pas été atteint (dangereux, utilisez avec prudence).

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-luxid-service-type
     ‘ganeti-luxid’ est un démon utilisé pour répondre aux requêtes
     liées à la configuration et à l’état actuel d’une grappe Ganeti. En
     plus, c’est le démon qui fait autorité pour la queue de travaux de
     Ganeti. les travaux peuvent être soumis via ce démon et il les
     programme et les démarre.

     Il prend un objet ‘ganeti-luxid-configuration’.

 -- Type de données : ganeti-luxid-configuration
     La configuration du service ‘ganeti-wconfd’.

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘no-voting?’ (par défaut : ‘#f’)
          Le démon refusera de démarrer s’il ne peut pas vérifier que la
          majorité des nœuds de la grappe pensent qu’il est le nœud
          maitre. Indiquez ‘#t’ pour le démarre malgré tout (cela peut
          être dangereux).

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-rapi-service-type
     ‘ganeti-rapi’ fournit une API à distance pour les grappes Ganeti.
     Il est lancé sur le maitre et peut être utilisé pour effectuer des
     actions programmées sur la grappe via un protocole de RPC basé sur
     JSON.

     La plupart des opérations de requêtes sont permises sans
     authentification (à moins que REQUIRE-AUTHENTIFICATION? ne soit
     indiqué), alors que les opérations en écriture requièrent une
     autorisation explicite via le fichier /VAR/LIB/GANETI/RAPI/USERS.
     voir la documentation de l’API distante de Ganeti
     (http://docs.ganeti.org/ganeti/master/html/rapi.html) pour plus
     d’informations.

     La valeur de ce service doit être un objet
     ‘geneti-rapi-configuration’.

 -- Type de données : ganeti-rapi-configuration
     La configuration du service ‘ganeti-rapi’.

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘require-authentication?’ (par défaut : ‘#f’)
          Indique s’il faut demander une authentification même pour les
          opérations en lecture-seule.

     ‘port’ (par défaut : ‘5080’)
          Le port TCP sur lequel écouter les requêtes de l’API.

     ‘address’ (par défaut : ‘"0.0.0.0"’)
          L’adresse réseau sur laquelle le service de liera. Par défaut
          il écoute sur toutes les adresses.

     ‘interface’ (par défaut : ‘#f’)
          Si une valeur est indiquée, elle doit spécifier une interface
          réseau spécifique comme ‘eth0’ sur laquelle le démon se liera.

     ‘max-clients’ (par défaut : ‘20’)
          Le nombre maximum de requêtes clientes simultanées à prendre
          en charge. Les connexions supplémentaires sont permises, mais
          aucune réponse ne sera envoyée tant qu’il n’y aura pas assez
          de connexions fermées.

     ‘ssl?’ (par défaut : ‘#t’)
          Indique s’il faut utiliser le chiffrement SSL/TLS sur le port
          RAPI.

     ‘ssl-key’ (par défaut : ‘"/var/lib/ganeti/server.pem"’)
          Cela peut être utilisé pour fournir une clé de chiffrement
          spécifique pour les communications TLS.

     ‘ssl-cert’ (par défaut : ‘"/var/lib/ganeti/server.pem"’)
          Cela peut être utilisé pour fournir un certification
          spécifique pour les communications TLS.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue plus de
          journalisation pour le débogage. Remarque que cela laissera
          fuiter des détails de chiffrement dans les journaux, utilisez
          cette option avec prudence.

 -- Variable Scheme : ganeti-kvmd-service-type
     ‘ganeti-kvmd’ doit déterminer si une instance KVM donnée a été
     éteinte par un administrateur ou un utilisateur. Normalement Ganeti
     redémarre une instance qui a été arrêtée par Ganeti lui-même. Si
     l’option de grappe ‘user_shutdown’ est vraie, ce démon vérifie la
     socket ‘QMP’ fournie par QEMU et écoute les évènements
     d’extinction, et marque l’instance “USER down” au lieu de “ERROR
     down” lorsqu’elle s’éteint correctement par elle-même.

     Il prend un objet ‘ganeti-kvmd-configuration’.

 -- Type de données : ganeti-kvmd-configuration

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-mond-service-type
     ‘ganeti-mond’ est un démon facultatif qui propose des
     fonctionnalités de surveillance de Ganeti. Il est responsable des
     collecteurs de données et de la publication des informations
     récupérées sur une interface HTTP.

     Il prend un objet ‘ganeti-mond-configuration’.

 -- Type de données : ganeti-mond-configuration

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘port’ (par défaut : ‘1815’)
          Le port sur lequel le démon écoutera.

     ‘address’ (par défaut : ‘"0.0.0.0"’)
          L’adresse réseau sur laquelle le démon se liera. Par défaut,
          il se lie à toutes les interfaces disponibles.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-metad-service-type
     ‘ganeti-metad’ est un démon facultatif qui peut être utilisé pour
     fournir des informations sur la grappe aux instance ou aux scripts
     d’installation de systèmes.

     Il prend un objet ‘ganeti-metad-configuration’.

 -- Type de données : ganeti-metad-configuration

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘port’ (par défaut : ‘80’)
          Le port sur lequel le démon écoutera.

     ‘address’ (par défaut : ‘#f’)
          Si la valeur est indiquée, le démon se liera à cette adresse
          uniquement. Si la valeur n’est pas indiquée, le comportement
          dépend de la configuration de la grappe.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est vraie, le démon effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-watcher-service-type
     ‘ganeti-watcher’ est un script conçu pour se lancer périodiquement
     et s’assurer de la santé de la grappe. Il redémarrera
     automatiquement les instances qui sont arrêtées sans le
     consentement de Ganeti, et réparera les liens DRBD au cas où un
     nœud a redémarré. Il archive aussi les anciennes tache de la grappe
     et redémarre les démons Ganeti qui ne sont pas lancés. Si le
     paramètres de grappe ‘ensure_node_health’ est indiqué, le gardien
     éteindra aussi les instances et les périphériques DRBD si le nœud
     sur lequel il est lancé est déclaré hors-ligne par un candidat
     maitre.

     Il peut être mis en pause sur tous les nœuds avec ‘gnt-cluster
     watcher-pause’.

     Le service prend un objet ‘ganeti-watcher-configuration’.

 -- Type de données : ganeti-watcher-configuration

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour ce service.

     ‘schedule’ (par défaut : ‘'(next-second-from (next-minute (range 0 60 5)))’)
          Indique quand lancer le script. Par défaut, toutes les cinq
          minutes.

     ‘rapi-ip’ (par défaut : ‘#f’)
          Cette option doit être spécifiée seulement si le démon RAPI
          est configuré pour utiliser une interface ou une adresse
          particulière. Par défaut l’adresse de grappe est utilisée.

     ‘job-age’ (par défaut : ‘(* 6 3600)’)
          Archive les taches de grappe plus vieilles que cela, en
          secondes. Par défaut c’est 6 heure. Cela permet de garder un
          ‘gnt-job list’ gérable.

     ‘verify-disks?’ (par défaut : ‘#t’)
          Si la valeur est ‘#f’, le gardien n’essaiera pas de réparer
          les liens DRBD cassés automatiquement. Les
          administrateur·ice·s devront utiliser ‘gnt-cluster
          verify-disks’ manuellement à la place.

     ‘debug?’ (par défaut : ‘#f’)
          Lorsque la valeur est ‘#t’, le script effectue des actions de
          journalisation supplémentaires pour le débogage.

 -- Variable Scheme : ganeti-cleaner-service-type
     ‘ganeti-cleaner’ est un script conçu pour être lancé périodiquement
     et supprimer les anciens fichiers de la grappe. Ce type de service
     contrôle deux “tache cron” : l’une est conçue pour le nœud maitre
     et purge de manière permanente les ancienne taches de la grappe, et
     l’autre est conçue pour tous les nœuds et supprime les certificats
     X509, les clés et les informations ‘ganeti-watcher’ périmées. Comme
     tous les services Ganeti, on peut l’ajouter même sur les nœuds
     non-maitres car il se désactive tout seul en cas de besoin.

     Il prend un objet ‘ganeti-cleaner-configuration’.

 -- Type de données : ganeti-cleaner-configuration

     ‘ganeti’ (par défaut : ‘ganeti’)
          Le paquet ‘ganeti’ à utiliser pour la commande ‘gnt-cleaner’.

     ‘master-schedule’ (par défaut : ‘"45 1 * * *"’)
          La périodicité à laquelle lancer la tache de nettoyage maitre.
          Par défaut c’est une fois par jour, à 01:45:00.

     ‘node-schedule’ (par défaut : ‘"45 2 * * *"’)
          La périodicité à laquelle lancer la tache de nettoyage des
          nœuds. Par défaut une fois par jour, à 02:45:00.


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

10.8.27 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’ 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’.

 -- Procédure Scheme : git-daemon-service [#:config
          (git-daemon-configuration)]

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

     L’argument facultatif CONFIG devrait être un objet
     ‘<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 représentnt la configuration de
     ‘git-daemon-service’.

     ‘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/foo’ sont des requêtes d’accès au dépôt
          ‘foo’ 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’,
          lancez ‘man git-daemon’ pour plus d’informations.

   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 Scheme : 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/letsencrypt/live/git.my-host.org/fullchain.pem")
                       (ssl-certificate-key
                        "/etc/letsencrypt/live/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
     Texte utilisé comme valeur par défaut pour ‘cgit-repo-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
     Une liste d’enregistrements “cgit-repo” à utiliser avec config.

     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’ :
               maybe-repo-boolean 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’ :
               maybe-repo-boolean 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’ :
               maybe-repo-boolean 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’ :
               maybe-repo-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 ‘disabled’.

      -- paramètre de ‘repository-cgit-configuration’ :
               maybe-repo-boolean 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’ :
               maybe-repo-boolean 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’ (par défaut : GITOLITE)
          Le paquet Gitolite à utiliser.

     ‘user’ (par défaut : GIT)
          Utilisateur pour utiliser Gitolite. Cela sera l’utilisateur à
          utiliser pour accéder à Gitolite par SSH.

     ‘group’ (par défaut : GIT)
          Groupe à utiliser pour Gitolite.

     ‘home-directory’ (par défaut : "/VAR/LIB/GITOLITE")
          Répertoire dans lequel stocker la configuration et les dépôts
          de Gitolite.

     ‘rc-file’ (par défaut : (GITOLITE-RC-FILE))
          Un objet « simili-fichier » (*note file-like objects:
          G-Expressions.) représentant la configuration de Gitolite.

     ‘admin-pubkey’ (par défaut : #F)
          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")

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

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

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

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

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


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

10.8.28 Services de jeu
-----------------------

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

10.8.29 Service PAM de montage
------------------------------

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

 -- Variable : Variable Scheme 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).


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

10.8.30 Services Guix
---------------------

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.

     Remarque : Ce service est expérimental. Les options de
     configuration peuvent changer et être incompatibles, et tous les
     paramètres n’ont pas été testés.

   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 : Variable Scheme 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.

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

 -- Variable : Variable Scheme 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’)
          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’ (par défaut : ‘1’)
          Le nombre de constructions qui peuvent tourner simultanément.

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

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

   Le paquet Guix Build Coordinator contient un script pour demander à
une instance de Guix Data Service les dérivations à construire, puis
pour soumettre les constructions de ces dérivations au coordinateur. Le
type de service ci-dessous vous aide à lancer ce script. C’est un outil
supplémentaire qui peut être utile lors de la construction de
dérivations contenues dans une instance du Guix Data Service.

 -- Variable : Variable Scheme
          guix-build-coordinator-queue-builds-service-type
     Type de service pour le script
     guix-build-coordinator-queue-builds-from-guix-data-service. Sa
     valeur doit être un objet
     ‘guix-build-coordinator-queue-builds-configuration’.

 -- Type de données : guix-build-coordinator-queue-builds-configuration
     Le type de données représentant les options du script qui soumet
     les constructions à partir du guix data service.

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

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

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

     ‘systems’ (par défaut : ‘#f’)
          Les systèmes pour lesquels récupérer des dérivations à
          construire.

     ‘systems-and-targets’ (par défaut : ‘#f’)
          Une liste d’association de paires de systèmes et de cibles
          pour lesquelles chercher des dérivations à construire.

     ‘guix-data-service’ (par défaut : ‘"https://data.guix.gnu.org"’)
          L’instance du Guix Data Service à laquelle demander les
          dérivations à construire.

     ‘processed-commits-file’ (par défaut : ‘"/var/cache/guix-build-coordinator-queue-builds/processed-commits"’)
          Un fichier qui enregistre les commits qui ont été traités,
          pour éviter de les traiter de nouveau inutilement si le
          service est redémarré.

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 : Variable Scheme 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’.


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

10.8.31 Services Linux
----------------------

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

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

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 Scheme : 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 : ‘-1’)
               C’est la priorité de l’espace d’échange créé à partir du
               périphérique zram. ‘swapon’ accepte les valeurs entre -1
               et 32767, avec les valeurs plus grandes indiquant une
               plus grande priorité. Les espaces d’échanges avec une
               plus grande priorité seront utilisés avant celui-ci.


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

10.8.32 Services Hurd
---------------------

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

10.8.33 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 Scheme : 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 Scheme : 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 Scheme : %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 Scheme : 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.

Service Lirc
............

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

 -- Procédure Scheme : lirc-service [#:lirc lirc] [#:device #f]
          [#:driver #f] [#:config-file #f] [#:extra-options '()]
     Renvoie un service qui lance LIRC (http://www.lirc.org), un démon
     qui décode les signaux infrarouges des télécommandes.

     Éventuellement, DEVICE, DRIVER et CONFIG-FILE (le nom du fichier de
     configuration) peuvent être spécifiés. Voir le manuel de ‘lircd’
     pour plus de détails.

     Enfin, EXTRA-OPTIONS est une liste d’options de la ligne de
     commande supplémentaires à passer à ‘lircd’.

Service Spice
.............

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

 -- Procédure Scheme : spice-vdagent-service [#:spice-vdagent]
     Renvoie un service qui lance VDAGENT (https://www.spice-space.org),
     un démon qui permet le partage du presse-papier avec une vm et de
     configurer la résolution d’affichage du client lorsque la fenêtre
     de la console graphique est redimensionnée.

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 Scheme : 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 Scheme : dicod-service-type
     C’est le type de service qui lance le démon ‘dicod’, une
     implémentation du serveur DICT (*note (dico)Dicod::).

 -- Procédure Scheme : dicod-service [#:config (dicod-configuration)]
     Renvoie un service qui lance le démon ‘dicod’, une implémentation
     du serveur DICT (*note (dico)Dicod::).

     L’argument CONFIG facultatif spécifie la configuration pour
     ‘dicod’, qui devrait être un objet ‘<dicod-configuration>’, par
     défaut il sert le dictionnaire international collaboratif de GNU
     pour l’anglais.

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

 -- 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 Scheme : %dicod-database:gcide
     Un objet ‘<dicod-database>’ servant le dictionnaire international
     collaboratif en anglais via le paquet ‘gcide’.

   Voici un exemple de configuration de ‘dicod-service’.

     (dicod-service #:config
       (dicod-configuration
        (handlers (list (dicod-handler
                         (name "wordnet")
                         (module "dictorg")
                         (options
                          (list #~(string-append "dbdir=" #$wordnet))))))
        (databases (list (dicod-database
                          (name "wordnet")
                          (complex? #t)
                          (handler "wordnet")
                          (options '("database=wn")))
                         %dicod-database:gcide))))

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

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

 -- Variable Scheme : 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.

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

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

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

     ‘containerd’ (par défaut : CONTAINERD)
          Le paquet Containerd à utiliser.

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

 -- Variable Scheme : 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 Programmes setuid::) pour que les
     utilisateurs non privilégiés puisse invoquer ‘singularity run’ et
     les commandes similaires.

Service auditd
..............

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

 -- Variable Scheme : 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 Scheme : 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      (string-append (assoc-ref %build-inputs "r-min")
                                                     "/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 Scheme : 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 Guide du
          gestionnaire de paquets Nix (https://nixos.org/nix/manual/).

        • 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-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’.


File: guix.fr.info,  Node: Programmes setuid,  Next: Certificats X.509,  Prev: Services,  Up: Configuration du système

10.9 Programmes setuid
======================

Certains programmes doivent être lancés avec les privilèges « root »
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, ces
exécutables sont “setuid-root”, ce qui signifie qu’ils seront toujours
lancés avec les privilèges root (*note (libc)How Change Persona::, pour
plus d’informations sur le mécanisme setuid).

   Le dépôt lui-même ne _peut pas_ contenir de programmes setuid ; cela
serait un problème de sécurité puisque n’importe quel utilisateur du
système peut écrire une dérivation qui rempli le dépôt (*note Le
dépôt::). Donc, un mécanisme différent est utilisé : au lieu de changer
le bit setuid directement sur les fichiers qui sont dans le dépôt, nous
laissons à l’administrateur système le soit de _déclarer_ les programmes
qui devraient être setuid root.

   Le champ ‘setuid-programs’ d’une déclaration ‘operating-system’
contient une liste de G-expressions qui dénotent les noms des programmes
à rendre setuid-root (*note Utiliser le système de configuration::). Par
exemple, le programme ‘passwd’, qui fait partie du paquet Shadow, peut
être désigné par cette G-expression (*note G-Expressions::) :

     #~(string-append #$shadow "/bin/passwd")

   Un ensemble de programmes par défaut est défini par la variable
‘%setuid-programs’ du module ‘(gnu system)’.

 -- Variable Scheme : %setuid-programs
     Une liste de G-expressions qui dénotent les programmes communément
     setuid-root.

     La liste inclus des commandes comme ‘passwd’, ‘ping’, ‘su’ et
     ‘sudo’.

   Sous le capot, les programmes setuid sont créés dans le répertoire
‘/run/setuid-programs’ au moment de l’activation du système. Les
fichiers dans ce répertoire se réfèrent aux « vrais » binaires, qui sont
dans le dépot.


File: guix.fr.info,  Node: Certificats X.509,  Next: Name Service Switch,  Prev: Programmes setuid,  Up: Configuration du système

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

   Dans Guix, cela se fait en ajoutant un paquet qui fournit les
certificats dans le champ ‘packages’ de la déclaration
‘operating-system’ (*note référence de système d'exploitation::). Guix
inclut l’un de ces paquets, ‘nss-certs’, qui est un ensemble de
certificats de CA fourni par les services de sécurité réseau de Mozilla
(nss).

   Remarquez qu’il ne fait _pas_ partie de ‘%base-packages’, donc vous
devez explicitement l’ajouter. Le répertoire ‘/etc/ssl/certs’, là où la
plupart des applications et bibliothèques vont rechercher les
certificats par défaut, pointe vers les certificats installés
globalement.

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

10.11 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 système
d'exploitation.).

   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 Scheme : %default-nss
     C’est la configuration NSS par défaut, un objet
     ‘name-service-switch’.

 -- Variable Scheme : %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’.

   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

10.12 Disque de RAM initial
===========================

Pour le démarrage, 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 Scheme : %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’
honore 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 :

‘--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é.

‘--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’.

‘--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 Scheme : raw-initrd FILE-SYSTEMS [#:linux-modules '()]
          [#: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 au démarrage. 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.

     Lorsque QEMU-NETWORKING? est vrai, paramètre le réseau avec les
     paramètres QEMU standards. Lorsque VIRTIO? est vrai, charge des
     modules supplémentaires pour que l’initrd puisse être utilisé comme
     client QEMU avec les pilotes I/O para-virtualisés.

     Lorsque VOLATILE-ROOT? est vrai, le système de fichier racine est
     inscriptible mais tous les changements seront perdus.

 -- Procédure Scheme : 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 au démarrage 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 Scheme : expression->initrd EXP [#:guile
          %guile-3.0-static-stripped] [#: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

10.13 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 respectent pas 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’, ‘gru-efi-netboot-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-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-bootloader’ vous permet de démarrer en particulier sur
          des machines Intel en mode BIOS « legacy ».

          ‘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 ‘target’ (*note
          ‘target’: Configuration du chargeur d'amorçage.), qui sera
          servi par un serveur TFTP. Vous pouvez maintenant monter le
          répertoire du serveur TFTP directement sur ‘target’ pour
          déplacer les fichiers requis vers le serveur TFTP
          automatiquement.

          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 système d'exploitation.) et l’initrd (*note
          ‘initrd’: référence de système d'exploitation.)). 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.
          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 export votre répertoire
          ‘target’ — habituellement ‘/boot’ — à 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 dans
          ‘target’.

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

          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 le démarrage réseau.
          Pour cela nous ne pouvons que vous recommander de regarder les
          instructions sur PXE (Preboot eXecution Environment).

     ‘target’
          C’est une chaîne qui dénote la cible sur laquelle installer le
          chargeur d’amorçage.

          L’interprétation dépend du chargeur d’amorçage en question.
          Pour ‘grub-bootloader’ par exemple, cela devrait être un nom
          de périphérique compris par la commande ‘installer’ du
          chargeur d’amorçage, comme ‘/dev/sda’ ou ‘(hd0)’ (*note
          (grub)Invoking grub-install::). Pour ‘grub-efi-bootloader’,
          cela devrait être le point de montage du système de fichiers
          EFI, typiquement ‘/boot/efi’. Pour
          ‘grub-efi-netboot-bootloader’, ‘target’ doit être le point de
          montage correspondant au répertoire racine 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 de démarrage 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 de démarrage 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 de démarrage 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::).

   Si vous voulez lister des entrées du menu de démarrage
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.

     ‘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"
                            ...))

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

10.14 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 comme 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.).

‘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é.

     Cela met en application toute la configuration spécifiée dans FILE
     : les comptes utilisateurs, les services du système, la liste
     globale des paquets, les programmes setuid, etc. La commande
     démarre les services systèmes spécifiés dans FILE qui ne sont pas
     actuellement lancés ; si un service est actuellement exécuté cette
     commande s’arrange pour qu’il soit mis à jour la prochaine fois
     qu’il est stoppé (p. ex par ‘herd stop X’ ou ‘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 aussi 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 au démarrage si vous en avez besoin.

     À 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
     démarrage 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 démarrage,
     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 la cible
     spécifiée dans ‘my-os-config’, à moins que l’option
     ‘--no-bootloader’ ne soit passée.

‘vm’
     Construit une machine virtuelle qui contient le système
     d’exploitation déclaré dans FILE et renvoie un script pour lancer
     cette machine virtuelle (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 -net user,model=virtio-net-pci

     La VM partage sont dépôt avec le système hôte.

     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 à démarrer
     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 de démarrage 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.

‘image’
‘docker-image’
     Renvoie une machine virtuelle, une image disque ou une image Docker
     du système d’exploitation déclaré dans FILE qui se suffit à
     elle-même. Par défaut, ‘guix system’ estime la taille de l’image
     requise pour stocker le système, mais vous pouvez utiliser l’option
     ‘--image-size’ pour spécifier une valeur. Les images Docker sont
     construites pour contenir exactement ce dont elles ont besoin, donc
     l’option ‘--image-size’ est ignorée dans le cas de ‘docker-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 ‘efi-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)/share/firmware/ovmf_x64.bin

     Lorsque vous utilisez le type d’image ‘efi-raw’, une image disque
     brute est produite ; elle peut être copiée telle quelle sur un
     périphérique USB par exemple. En supposant que ‘/dev/sdc’ est le
     périphérique correspondant à une clé USB, on peut copier l’image
     dessus avec la commande suivante :

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

     Lorsque vous utilisez le type d’image ‘qcow2’, l’image renvoyée est
     au format qcow2, que l’émulateur QEMU peut utiliser efficacement.
     *Note Lancer Guix dans une VM::, pour plus d’information sur la
     manière de lancer l’image dans une machine virtuelle. Le chargeur
     d’amorçage ‘grub-bootloader’ est toujours utilisé quelque soit
     celui déclaré dans le fichier ‘operating-system’ passé en argument.
     Cela facilite l’utilisation de QEMU, qui utilise le BIOS SeaBIOS
     par défaut, et s’attend à un chargeur d’amorçage installé dans le
     Master Boot Record (MBR).

     En utilisant ‘docker-image’, 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.

‘conteneur’
     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

          Remarque : Cette option requiert Linux-libre ou supérieur.

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

‘--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é.

     Lorsque cette option est omise, ‘guix system’ utilise le type
     d’image ‘efi-raw’.

     ‘--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 au
     démarrage 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 actuel : son nom de fichier, son
     noyau et chargeur d’amorçage utilisé, etc, ainsi que les
     informations de provenance si elles sont disponibles.

‘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

   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.

‘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

10.15 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 comme 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’.

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

 -- 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"’.
     ‘taille’
          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.


File: guix.fr.info,  Node: Lancer Guix dans une VM,  Next: Définir des services,  Prev: Invoquer guix deploy,  Up: Configuration du système

10.16 Exécuter Guix sur une machine virtuelle
=============================================

Pour exécuter Guix sur une machine virtuelle (VM), on peut soit utiliser
l’image de VM Guix pré-construite sur
‘https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2’
. Cette image est une image compressée au format QCOW. Vous devrez
d’abord la décompresser avec ‘xz -d’ puis la passer à un émulateur comme
QEMU (voir plus bas pour des détails).

   Cette image démarre l’environnement graphique Xfce et contient
certains outils couramment utilisés. Vous pouvez installer plus de
logiciels sur l’image en lançant ‘guix package’ dans un terminal (*note
Invoquer guix package::). Vous pouvez aussi reconfigurer le système à
partir de son fichier de configuration initiale disponible dans
‘/run/current-system/configuration.scm’ (*note Utiliser le système de
configuration::).

   Au lieu d’utiliser cette image pré-construite, on peut construire sa
propre image de machine virtuelle avec ‘guix system vm-image’ (*note
Invoquer guix system::). L’image renvoyée est au format qcow2, que
l’émulateur QEMU (https://qemu.org/) peut utiliser efficacement.

   Si vous construisez votre propre image, vous devez la copier en
dehors du dépôt (*note Le dépôt::) et vous donner la permission d’écrire
sur la copie avant de pouvoir l’utiliser. Lorsque vous invoquez QEMU,
vous devez choisir un émulateur système correspondant à votre
plate-forme matérielle. Voici une invocation minimale de QEMU qui
démarrera le résultat de ‘guix system image -t qcow2’ sur un matériel
x8_64 :

     $ qemu-system-x86_64 \
        -nic user,model=virtio-net-pci \
        -enable-kvm -m 1024 \
        -device virtio-blk,drive=myhd \
        -drive if=none,file=/tmp/qemu-image,id=myhd

   Voici la signification de ces options :

‘qemu-system-x86_64’
     Cela spécifie la plate-forme matérielle à émuler. Elle doit
     correspondre à l’hôte.

‘-nic user,model=virtio-net-pci’
     Active la pile réseau en mode utilisateur non privilégié. Le
     système invité peut accéder à l’hôte mais pas l’inverse. C’est la
     manière la plus simple de mettre le système en ligne. ‘model’
     spécifie le périphérique réseau à émuler : ‘virtio-net-pci’ est un
     périphérique spécial conçu pour les systèmes d’exploitation
     virtualisés et recommandés dans la plupart des cas. En supposant
     que votre plateforme matérielle est x86_64, vous pouvez récupérer
     une liste des modèles d’interfaces réseaux en lançant
     ‘qemu-system-x86_64 -nic model=help’.

‘-enable-kvm’
     Si votre système a des extensions de virtualisation matérielle,
     activer le support des machines virtuelles de Linux (KVM)
     accélérera les choses.

‘-m 1024’
     RAM disponible sur l’OS émulé, en mébioctets. La valeur par défaut
     est 128 Mo, ce qui peut ne pas suffire pour certaines opérations.

‘-device virtio-blk,drive=myhd’
     Crée un lecteur ‘virtio-blk’ nommé « myhd ». ‘virtio-blk’ est un
     mécanisme de « paravirtualisation » pour les périphériques blocs
     qui permet à QEMU d’avoir de meilleures performances que s’il
     émulait un disque complet. Voir la documentation de QEMU et KVM
     pour plus d’info.

‘-drive if=none,file=/tmp/qemu-image,id=myhd’
     Utilise notre image QCOW, le fichier ‘/tmp/qemu-image’, comme
     stockage pour le lecteur « myhd ».

   Le script ‘run-vm.sh’ par défaut renvoyé par une invocation de ‘guix
system vm’ n’ajoute pas le drapeau ‘-nic user’ par défaut. Pour avoir
accès au réseau dans la vm, ajoutez le ‘(dhcp-client-service)’ à votre
définition et démarrez la VM avec ‘$(guix system vm config.scm) -nic
user’. Un problème important avec ‘-nic user’ pour le réseau, est que
‘ping’ ne fonctionnera pas, car il utilise le protocole ICMP. Vous
devrez utiliser une autre commande pour vérifier la connectivité réseau,
par exemple ‘guix download’.

10.16.1 Se connecter par SSH
----------------------------

Pour activer SSH dans une VM vous devez ajouter un serveur SSH comme
‘opennssh-service-type’ à votre VM (*note ‘openssh-service-type’:
Services réseau.). En plus vous devez transférer le port 22, par défaut,
à l’hôte. Vous pouvez faire cela avec

     $(guix system vm config.scm) -nic user,model=virtio-net-pci,hostfwd=tcp::10022-:22

   Pour vous connecter à la VM vous pouvez lancer

     ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 localhost

   Le ‘-p’ donne le port auquel vous voulez vous connecter à ‘ssh’, ‘-o
UserKnownHostsFile=/dev/null’ évite que ‘ssh’ ne se plaigne à chaque
fois que vous modifiez le fichier ‘config.scm’ et ‘-o
StrictHostKeyChecking=no’ évite que vous n’ayez à autoriser une
connexion à un hôte inconnu à chaque fois que vous vous connectez.

10.16.2 Utiliser ‘virt-viewer’ avec Spice
-----------------------------------------

Alternativement au client graphique ‘qemu’ par défaut vous pouvez
utiliser ‘remote-viewer’ du paquet ‘virt-viewer’. Pour vous connecter,
passez le drapeau ‘-spice port=5930,disable-ticketing’ à ‘qemu’. Voir
les sections précédentes pour plus d’informations sur comment faire
cela.

   Spice a aussi de chouettes fonctionnalités comme le partage de votre
presse-papier avec la VM. Pour activer cela vous devrez aussi passer les
drapeaux suivants à ‘qemu’ :

     -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5
     -chardev spicevmc,name=vdagent,id=vdagent
     -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,
     name=com.redhat.spice.0

   Vous devrez également ajouter le ‘(spice-vdagent-service)’ à la
définition de votre système (*note Spice service: Services divers.).


File: guix.fr.info,  Node: Définir des services,  Prev: Lancer Guix dans une VM,  Up: Configuration du système

10.17 Définir des services
==========================

Les sections précédentes montrent les services disponibles et comment on
peut les combiner dans une déclaration ‘operating-system’. Mais, déjà,
comment les définir ? Et qu’est-ce qu’un service au fait ?

* Menu:

* Composition de services::  Le modèle de composition des services.
* Types service et services::  Types et services.
* Référence de service::   Référence de l’API.
* Services Shepherd::        Un type de service particulier.


File: guix.fr.info,  Node: Composition de services,  Next: Types service et services,  Up: Définir des services

10.17.1 Composition de services
-------------------------------

Ici nous définissons un “service” comme étant, assez largement, quelque
chose qui étend la fonctionnalité d’un système d’exploitation. Souvent
un service est un processus — un “démon” — démarré lorsque le système
démarre : un serveur ssh, un serveur web, le démon de construction de
Guix, etc. Parfois un service est un démon dont l’exécution peut être
déclenchée par un autre démon — p. ex. un serveur FTP démarré par
‘inetd’ ou un service D-Bus activé par ‘dbus-daemon’. Parfois, un
service ne correspond pas à un démon. Par exemple, le service « de
comptes » récupère la liste des comptes utilisateurs et s’assure qu’ils
existent bien lorsque le système est lancé ; le service « udev »
récupère les règles de gestion des périphériques et les rend disponible
au démon eudev ; le service ‘/etc’ rempli le répertoire ‘/etc’ du
système.

   Les services de Guix sont connectés par des “extensions”. Par
exemple, le service ssh “étend” le Shepherd — le système
d’initialisation de GuixSD, qui tourne en tant que PID 1 — en lui
donnant les lignes de commande pour démarrer et arrêter le démon ssh
(*note ‘lsh-service’: Services réseau.) ; le service UPower étend le
service D-Bus en lui passant sa spécification ‘.service’ et étend le
service udev en lui passant des règles de gestion de périphériques
(*note ‘upower-service’: Services de bureaux.) ; le démon Guix étend le
Shepherd en lui passant les lignes de commande pour démarrer et arrêter
le démon et étend le service de comptes en lui passant une liste des
comptes utilisateurs de constructions requis (*note Services de base::).

   En définitive, les services et leurs relation « d’extensions »
forment un graphe orienté acyclique (DAG). Si nous représentons les
services comme des boîtes et les extensions comme des flèches, un
système typique pourrait fournir quelque chose comme cela :

[image src="images/service-graph.png" alt="Graphe d'extension des services typique."]

   En bas, on voit le “service système” qui produit le répertoire
contenant tout et lançant et démarrant le système, renvoyé par la
commande ‘guix system build’. *Note Référence de service::, pour
apprendre les autres types de services montrés ici. *Note the ‘guix
system extension-graph’ command: system-extension-graph, pour plus
d’informations sur la manière de générer cette représentation pour une
définition de système d’exploitation particulière.

   Techniquement, on peut définir des “types de services” pour exprimer
ces relations. Il peut y avoir n’importe quel quantité de services d’un
type donné sur le système — par exemple, un système sur lequel tournent
deux instances du serveur ssh de GNU (lsh) a deux instance de
LSH-SERVICE-TYPE, avec des paramètres différents.

   La section suivante décrit l’interface de programmation des types de
services et des services.


File: guix.fr.info,  Node: Types service et services,  Next: Référence de service,  Prev: Composition de services,  Up: Définir des services

10.17.2 Types service et services
---------------------------------

Un “type de service” est un nœud dans le DAG décrit plus haut.
Commençons avec un exemple simple, le type de service pour le démon de
construction de Guix (*note Invoquer guix-daemon::) :

     (define guix-service-type
       (service-type
        (name 'guix)
        (extensions
         (list (service-extension shepherd-root-service-type guix-shepherd-service)
               (service-extension account-service-type guix-accounts)
               (service-extension activation-service-type guix-activation)))
        (default-value (guix-configuration))))

Il définit trois choses :

  1. Un nom, dont le seul but de rendre l’inspection et le débogage plus
     faciles.

  2. Une liste d’“extensions de services”, où chaque extension désigne
     le type de service cible et une procédure qui, étant donné les
     paramètres du service, renvoie une liste d’objets pour étendre le
     service de ce type.

     Chaque type de service a au moins une extension de service. La
     seule exception est le “type de service boot”, qui est le service
     ultime.

  3. Éventuellement, une valeur par défaut pour les instances de ce
     type.

   Dans cet exemple, GUIX-SERVICE-TYPE étend trois services :

‘shepherd-root-service-type’
     La procédure GUIX-SHEPHERD-SERVICE définit comment le service du
     Shepherd est étendu. En fait, elle renvoie un objet
     ‘<shepherd-service>’ qui définit comment ‘guix-daemon’ est démarré
     et stoppé (*note Services Shepherd::).

‘account-service-type’
     Cette extension pour ce service est calculée par GUIX-ACCOUNTS, qui
     renvoie une liste d’objets ‘user-group’ et ‘user-account’
     représentant les comptes des utilisateurs de construction (*note
     Invoquer guix-daemon::).

‘activation-service-type’
     Ici, GUIX-ACTIVATION est une procédure qui renvoie une gexp, qui
     est un bout de code qui s’exécute au moment de l’activation — p.
     ex. lorsque le service est démarré.

   Un service de ce type est instancié de cette manière :

     (service guix-service-type
              (guix-configuration
                (build-accounts 5)
                (extra-options '("--gc-keep-derivations"))))

   Le deuxième argument de la forme ‘service’ est une valeur
représentant les paramètres de cet instance spécifique du service. *Note
‘guix-configuration’: guix-configuration-type, pour plus d’informations
sur le type de données ‘guix-configuration’. Lorsque la valeur est
omise, la valeur par défaut spécifiée par ‘guix-service-type’ est
utilisée :

     (service guix-service-type)

   GUIX-SERVICE-TYPE est très simple car il étend d’autres services mais
ne peut pas être étendu.

   Le type de service pour un service _extensible_ ressemble à ceci :

     (define udev-service-type
       (service-type (name 'udev)
                     (extensions
                      (list (service-extension shepherd-root-service-type
                                               udev-shepherd-service)))

                     (compose concatenate)       ; concatène la liste des règles
                     (extend (lambda (config rules)
                               (match config
                                 (($ <udev-configuration> udev initial-rules)
                                  (udev-configuration
                                   (udev udev)   ; le paquet udev à utiliser
                                   (rules (append initial-rules rules)))))))))

   C’est le type de service pour le le démon de gestion des
périphériques eudev (https://wiki.gentoo.org/wiki/Project:Eudev).
Comparé à l’exemple précédent, en plus d’une extension de
SHEPHERD-ROOT-SERVICE-TYPE, on trouve deux nouveaux champs :

‘compose’
     C’est la procédure pour “composer” la liste des extensions de
     services de ce type.

     Les services peuvent étendre le service udev en lui passant des
     listes de règles ; on compose ces extensions simplement en les
     concaténant.

‘extend’
     Cette procédure définie comme la valeur du service est “étendue”
     avec la composition des extensions.

     Les extensions Udev sont composés en une liste de règles, mais la
     valeur du service udev est elle-même un enregistrement
     ‘<udev-configuration>’. Donc ici, nous étendons cet enregistrement
     en ajoutant la liste des règle contribuées à la liste des règles
     qu’il contient déjà.

‘description’
     C’est une chaîne donnant un aperçu du type de service. Elle peut
     contenir du balisage Texinfo (*note (texinfo)Overview::). La
     commande ‘guix system search’ permet de rechercher dans ces chaînes
     et de les afficher (*note Invoquer guix system::).

   Il ne peut y avoir qu’une instance d’un type de service extensible
comme UDEV-SERVICE-TYPE. S’il y en avait plus, les spécification
‘service-extension’ seraient ambiguës.

   Toujours ici ? La section suivante fournit une référence de
l’interface de programmation des services.


File: guix.fr.info,  Node: Référence de service,  Next: Services Shepherd,  Prev: Types service et services,  Up: Définir des services

10.17.3 Référence de service
----------------------------

Nous avons vu un résumé des types de services (*note Types service et
services::). Cette section fournit une référence sur la manière de
manipuler les services et les types de services. Cette interface est
fournie par le module ‘(gnu services)’.

 -- Procédure Scheme : service TYPE [VALUE]
     Renvoie un nouveau service de type TYPE, un objet ‘<service-type>’
     (voir plus bas). VALUEpeut être n’importe quel objet ; il
     représente les paramètres de cette instance particulière de
     service.

     Lorsque VALUE est omise, la valeur par défaut spécifiée par TYPE
     est utilisée ; si TYPE ne spécifie pas de valeur par défaut, une
     erreur est levée.

     Par exemple ceci :

          (service openssh-service-type)

     est équivalent à ceci :

          (service openssh-service-type
                   (openssh-configuration))

     Dans les deux cas le résultat est une instance de
     ‘openssh-service-type’ avec la configuration par défaut.

 -- Procédure Scheme : service? OBJ
     Renvoie vrai si OBJ est un service.

 -- Procédure Scheme : service-kind SERVICE
     Renvoie le type de SERVICE — c.-à-d. un objet ‘<service-type>’.

 -- Procédure Scheme : service-value SERVICE
     Renvoie la valeur associée à SERVICE. Elle représente ses
     paramètres.

   Voici un exemple de la manière dont un service est créé et manipulé :

     (define s
       (service nginx-service-type
                (nginx-configuration
                 (nginx nginx)
                 (log-directory log-directory)
                 (run-directory run-directory)
                 (file config-file))))

     (service? s)
     ⇒ #t

     (eq? (service-kind s) nginx-service-type)
     ⇒ #t

   La forme ‘modify-services’ fournit une manière pratique de modifier
les paramètres de certains services d’une liste comme %BASE-SERVICES
(*note ‘%base-services’: Services de base.). Elle s’évalue en une liste
de services. Bien sûr, vous pouvez toujours utiliser les combinateurs de
liste standards comme ‘map’ et ‘fold’ pour cela (*note List Library:
(guile)SRFI-1.) ; ‘modify-services’ fournit simplement une manière plus
concise pour ce besoin commun.

 -- Syntaxe Scheme : modify-services SERVICES (TYPE VARIABLE => BODY)
          ...

     Modifie les services listés dans SERVICES en fonction des clauses
     données. Chaque clause à la forme :

          (TYPE VARIABLE => BODY)

     où TYPE est un type de service — p. ex. ‘guix-service-type’ — et
     VARIABLE est un identifiant lié dans BODY aux paramètres du service
     — p. ex. une instance de ‘guix-configuration’ — du service original
     de ce TYPE.

     La variable BODY devrait s’évaluer en de nouveaux paramètres de
     service, qui seront utilisés pour configurer le nouveau service. Ce
     nouveau service remplacera l’original dans la liste qui en résulte.
     Comme les paramètres d’un service sont créés avec
     ‘define-record-type*’, vous pouvez écrire un BODY court qui
     s’évalue en de nouveaux paramètres pour le services en utilisant
     ‘inherit’, fourni par ‘define-record-type*’.

     *Note Utiliser le système de configuration:: pour des exemples
     d’utilisation.

   Suit l’interface de programmation des types de services. Vous devrez
la connaître pour écrire de nouvelles définitions de services, mais pas
forcément lorsque vous cherchez des manières simples de personnaliser
votre déclaration ‘operating-system’.

 -- Type de données : service-type
     C’est la représentation d’un “type de service” (*note Types service
     et services::).

     ‘name’
          C’est un symbole, utilisé seulement pour simplifier
          l’inspection et le débogage.

     ‘extensions’
          Une liste non-vide d’objets ‘<service-extension>’ (voir plus
          bas).

     ‘compose’ (par défaut : ‘#f’)
          S’il s’agit de ‘#f’, le type de service dénote des services
          qui ne peuvent pas être étendus — c.-à-d. qui ne reçoivent pas
          de « valeurs » d’autres services.

          Sinon, ce doit être une procédure à un argument. La procédure
          est appelée par ‘fold-services’ et on lui passe une liste de
          valeurs collectées par les extensions. Elle peut renvoyer
          n’importe quelle valeur simple.

     ‘extend’ (par défaut : ‘#f’)
          Si la valeur est ‘#f’, les services de ce type ne peuvent pas
          être étendus.

          Sinon, il doit s’agir ’une procédure à deux arguments :
          ‘fold-services’ l’appelle et lui passe la valeur initiale du
          service comme premier argument et le résultat de l’application
          de ‘compose’ sur les valeurs d’extension en second argument.
          Elle doit renvoyer une valeur qui est une valeur de paramètre
          valide pour l’instance du service.

     ‘description’
          C’est une chaine, éventuellement avec de la syntaxe Texinfo,
          décrivant une quelques phrases ce que le service fait. Cette
          chaine permet aux utilisateurs de trouver le service à travers
          ‘guix system search’ (*note Invoquer guix system::).

     ‘default-value’ (par défaut : ‘&no-default-value’)
          La valeur par défaut associée aux instances de ce type de
          service. Cela permet d’utiliser la forme ‘service’ sans son
          second argument :

               (service TYPE)

          Le service renvoyé dans ce cas a la valeur par défaut
          spécifiée par TYPE.

     *Note Types service et services::, pour des exemples.

 -- Procédure Scheme : service-extension TARGET-TYPE COMPUTE
     Renvoie une nouvelle extension pour les services de type
     TARGET-TYPE. COMPUTE doit être une procédure à un argument :
     ‘fold-services’ l’appelle et lui passe la valeur associée au
     service qui fournit cette extension ; elle doit renvoyer une valeur
     valide pour le service cible.

 -- Procédure Scheme : service-extension? OBJ
     Renvoie vrai si OBJ est une extension de service.

   Parfois, vous voudrez simplement étendre un service existant. Cela
implique de créer un nouveau type de service et de spécifier l’extension
qui vous intéresse, ce qui peut être assez verbeux ; la procédure
‘simple-service’ fournit un raccourci pour ce cas.

 -- Procédure Scheme : simple-service NAME TARGET VALUE
     Renvoie un service qui étend TARGET avec VALUE. Cela fonctionne en
     créant un type de service singleton NAME, dont le service renvoyé
     est une instance.

     Par exemple, cela étend mcron (*note Exécution de tâches
     planifiées::) avec une tâche supplémentaire :

          (simple-service 'my-mcron-job mcron-service-type
                          #~(job '(next-hour (3)) "guix gc -F 2G"))

   Au cœur de l’abstraction des services se cache la procédure
‘fold-services’, responsable de la « compilation » d’une liste de
services en un répertoire unique qui contient tout ce qui est nécessaire
au démarrage et à l’exécution du système — le répertoire indiqué par la
commande ‘guix system build’ (*note Invoquer guix system::). En soit,
elle propage les extensions des services le long du graphe des services,
en mettant à jour chaque paramètre des nœuds sur son chemin, jusqu’à
atteindre le nœud racine.

 -- Procédure Scheme : fold-services SERVICES [#:target-type
          SYSTEM-SERVICE-TYPE]
     Replie SERVICES en propageant leurs extensions jusqu’à la racine de
     type TARGET-TYPE ; renvoie le service racine ajusté de cette
     manière.

   Enfin, le module ‘(gnu services)’ définie aussi divers types de
services essentiels, dont certains sont listés ci-dessous.

 -- Variable Scheme : system-service-type
     C’est la racine du graphe des services. Il produit le répertoire du
     système renvoyé par la commande ‘guix system build’.

 -- Variable Scheme : boot-service-type
     Le type du service « boot », qui produit le “script de démarrage”.
     Le script de démarrage est ce que le disque de RAM initial lance au
     démarrage.

 -- Variable Scheme : etc-service-type
     Le type du service ‘/etc’. Ce service est utilisé pour créer des
     fichiers dans ‘/etc’ et peut être étendu en lui passant des tuples
     nom/fichier comme ceci :

          (list `("issue" ,(plain-file "issue" "Bienvenue !\n")))

     Dans cet exemple, l’effet serait d’ajouter un fichier ‘/etc/issue’
     pointant vers le fichier donné.

 -- Variable Scheme : setuid-program-service-type
     Le type du « service setuid ». Ce service récupère des listes de
     noms de fichiers exécutables, passés en tant que gexps, et les
     ajoute à l’ensemble des programmes setuid root sur le système
     (*note Programmes setuid::).

 -- Variable Scheme : profile-service-type
     De type du service qui rempli le “profil du système” — c.-à-d. les
     programmes dans ‘/run/current-system/profile’. Les autres services
     peuvent l’étendre en lui passant des listes de paquets à ajouter au
     profil du système.

 -- Variable Scheme : provenance-service-type
     C’est le type de service qui enregistre les “métadonnées de
     provenance” dans le système lui-même. Il crée plusieurs fichiers
     dans ‘/run/current-system’ :

     ‘channels.scm’
          C’est un « fichier de canaux » qui peut être passé à ‘guix
          pull -C’ ou ‘guix time-machine -C’, et qui décrit les canaux
          utilisés pour construire le système, si cette information
          était disponible (*note Canaux::).

     ‘configuration.scm’
          C’est le fichier qui était passé en argument à ce service
          ‘provenance-service-type’. Par défaut, ‘guix system
          reconfigure’ passe automatiquement le fichier de configuration
          du système qu’il a reçu en argument de la ligne de commande.

     ‘provenance’
          Cela contient la même information que les deux autres fichiers
          mais dans un format plus facile à traiter automatiquement.

     En général, ces deux informations (les canaux et le fichier de
     configuration) sont suffisants pour reproduire le système
     d’exploitation « depuis les sources ».

          Limites : Cette information est nécessaire pour reconstruire
          votre système d’exploitation, mais elle n’est pas suffisante.
          En particulier, ‘configuration.scm’ lui-même n’est pas
          suffisant s’il n’est pas auto-contenu — s’il référence des
          modules Guile externes ou des fichiers supplémentaires. Si
          vous voulez que ‘configuration.scm’ soit auto-contenu, nous
          vous recommandons de faire en sorte que les modules et les
          fichiers auxquels il fait référence se trouvent dans un canal.

          De plus, les métadonnées de provenance sont « silencieuses »
          dans le sens où elles ne changent pas les bits contenus dans
          votre système, _en dehors des bits des métadonnées
          elles-mêmes_. Deux configuration de système différents ou des
          ensembles de canaux différents peuvent créer le même système,
          bit-à-bit, mais lorsque ‘provenance-service-type’ est utilisé
          ces deux systèmes auront des métadonnées différentes et donc
          des noms de fichiers dans le dépôt différents, ce qui rend la
          comparaison plus difficile.

     Ce service est automatiquement ajouté à la configuration de votre
     système d’exploitation quand vous utilisez ‘guix system
     reconfigure’, ‘guix system init’ et ‘guix deploy’.


File: guix.fr.info,  Node: Services Shepherd,  Prev: Référence de service,  Up: Définir des services

10.17.4 Services Shepherd
-------------------------

Le module ‘(gnu services shepherd)’ fournit une manière de définir les
services gérés par le GNU Shepherd, qui est le système d’initialisation
— le premier processus démarré lorsque le système démarre, aussi connu
comme étant le PID 1 (*note (shepherd)Introduction::).

   Les services dans le Shepherd peuvent dépendre les uns des autres.
Par exemple, le démon SSH peut avoir besoin d’être démarré après le
démon syslog, qui à son tour doit être démarré après le montage des
systèmes de fichiers. Le système d’exploitation simple déclaré
précédemment (*note Utiliser le système de configuration::) crée un
graphe de service comme ceci :

[image src="images/shepherd-graph.png" alt="Graphe de service typique du shepherd."]

   Vous pouvez générer un tel graphe pour n’importe quelle définition de
système d’exploitation avec la commande ‘guix system shepherd-graph’
(*note ‘guix system shepherd-graph’: system-shepherd-graph.).

   La variable %SHEPHERD-ROOT-SERVICE est un objet de service
représentant le PID 1, de type SHEPHERD-ROOT-SERVICE-TYPE ; il peut être
étendu en lui passant des listes d’objets ‘<shepherd-service>’.

 -- Type de données : shepherd-service
     Le type de données représentant un service géré par le Shepherd.

     ‘provision’
          C’est une liste de symboles dénotant ce que le service
          fournit.

          Ce sont les noms qui peuvent être passés à ‘herd start’, ‘herd
          status’ et les commandes similaires (*note (shepherd)Invoking
          herd::). *Note the ‘provides’ slot: (shepherd)Slots of
          services, pour plus de détails.

     ‘requirement’ (par défaut : ‘'()’)
          Liste de symboles dénotant les services du Shepherd dont
          celui-ci dépend.

     ‘one-shot?’ (par défaut : ‘#f’)
          Indique si ce service est “ponctuel”. Les services ponctuels
          s’arrêtent immédiatement à la fin de leur action ‘start’.
          *Note (shepherd)Slots of services::, pour plus d’infos.

     ‘respawn?’ (par défaut : ‘#t’)
          Indique s’il faut redémarrer le service lorsqu’il s’arrête,
          par exemple si le processus sous-jacent meurt.

     ‘start’
     ‘stop’ (par défaut : ‘#~(const #f)’)
          Les champs ‘start’ et ‘stop’ se réfèrent à la capacité du
          Shepherd de démarrer et d’arrêter des processus (*note
          (shepherd)Service De- and Constructors::). Ils sont donnés
          comme des G-expressions qui sont étendues dans le fichier de
          configuration du Shepherd (*note G-Expressions::).

     ‘actions’ (par défaut : ‘'()’)
          C’est une liste d’objets ‘shepherd-action’ (voir plus bas)
          définissant des “actions” supportées par le service, en plus
          des actions ‘start’ et ‘stop’ standards. Les actions listées
          ici sont disponibles en tant que sous-commande de ‘herd’ :

               herd ACTION SERVICE [ARGUMENTS...]

     ‘auto-start?’ (par défaut : ‘#t’)
          Indique si ce service doit être démarré automatiquement par le
          Shepherd. Si la valeur est ‘#f’, le service doit être démarré
          manuellement avec ‘herd start’.

     ‘documentation’
          Une chaîne de documentation, montrée lorsqu’on lance :

               herd doc SERVICE-NAME

          où SERVICE-NAME est l’un des symboles dans PROVISION (*note
          (shepherd)Invoking herd::).

     ‘modules’ (par défaut : ‘%default-modules’)
          C’est la liste des modules qui doivent être dans le contexte
          lorsque ‘start’ et ‘stop’ sont évalués.

   L’exemple ci-dessous défini un service Shepherd qui lance ‘syslogd’,
le démon de journalisation du système des utilitaires réseau de GNU
(*note ‘syslogd’: (inetutils)syslogd invocation.) :

     (let ((config (plain-file "syslogd.conf" "...")))
       (shepherd-service
         (documentation "Run the syslog daemon (syslogd).")
         (provision '(syslogd))
         (requirement '(user-processes))
         (start #~(make-forkexec-constructor
                    (list #$(file-append inetutils "/libexec/syslogd")
                          "--rcfile" #$config)
                    #:pid-file "/var/run/syslog.pid"))
         (stop #~(make-kill-destructor))))

   Les éléments clés de cet exemple sont les champs ‘start’ et ‘stop’ :
ce sont des bouts de code “échelonné” qui utilisent la procédure
‘make-forkexec-constructor’ fournie par le Shepherd et son dual,
‘make-kill-destructor’ (*note (shepherd)Service De- and Constructors::).
Le champ ‘start’ fera créer un ‘syslogd’ au ‘shepherd’ avec les options
données. Remarquez que nous passons ‘config’ après ‘--rcfile’, qui est
un fichier de configuration déclaré plus haut (le contenu de ce fichier
a été omis). De même, le champ ‘stop’ décrit comment ce service sera
arrêté. Dans ce cas, il est arrêté par l’appel système ‘kill’ sur son
PID. Le code est échelonné par des G-expressions : ‘#~’ échelonne le
code, tandis que ‘#$’ « descend » vers le code hôte (*note
G-Expressions::).

 -- Type de données : shepherd-action
     C’est le type de données qui définie des actions supplémentaires
     implémentées par un service Shepherd (voir au-dessus).

     ‘name’
          Symbole nommant l’action.

     ‘documentation’
          C’est une chaîne de documentation pour l’action. Elle peut
          être consultée avec :

               herd doc SERVICE action ACTION

     ‘procedure’
          Cela devrait être une gexp qui s’évalue en une procédure à au
          moins un argument, la « valeur de lancement » du service
          (*note (shepherd)Slots of services::).

     L’exemple suivant définie une action nommée ‘dire-bonjour’ qui
     salue amicalement l’utilisateur :

          (shepherd-action
            (name 'dire-bonjour)
            (documentation "Dit salut !")
            (procedure #~(lambda (running . args)
                           (format #t "Salut, l'ami ! arguments : ~s\n"
                                   args)
                           #t)))

     En supposant que cette action est ajoutée dans le service
     ‘example’, vous pouvez écrire :

          # herd dire-bonjour example
          Salut, l'ami ! arguments : ()
          # herd dire-bonjour example a b c
          Salut, l'ami ! arguments : ("a" "b" "c")

     Comme vous pouvez le voir, c’est une manière assez sophistiquée de
     dire bonjour. *Note (shepherd)Service Convenience::, pour plus
     d’informations sur les actions.

 -- Variable Scheme : shepherd-root-service-type
     Le type de service pour le « service racine » du Shepherd — c.-à-d.
     le PID 1.

     C’est le type de service que les extensions ciblent lorqu’elles
     veulent créer un service shepherd (*note Types service et
     services::, pour un exemple). Chaque extension doit passer une
     liste de ‘<shepherd-service>’. Sa valeur doit être un
     ‘shepherd-configuration’, décrit plus bas.

 -- Type de données : shepherd-configuration
     Ce type de données représente la configuration du Shepherd.

     ‘shepherd (par défaut : shepherd)’
          Le paquet Shepherd à utiliser.

     ‘services (par défaut : '())’
          Une liste de ‘<shepherd-service>’ à démarrer. Vous devriez
          probablement utiliser le mécanisme d’extensions des services à
          la place (*note Services Shepherd::).

   L’exemple suivant spécifie le paquet Shepherd pour le système
d’exploitation :

     (operating-system
       ;; ...
       (services (append (list openssh-service-type))
                 ;; ...
                 %desktop-services)
       ;; ...
       ;; Utiliser notre propre paquet Shepherd.
       (essential-services
        (modify-services (operating-system-default-essential-services
                          this-operating-system)
          (shepherd-root-service-type config => (shepherd-configuration
                                                 (inherit config)
                                                 (shepherd my-shepherd))))))

 -- Variable Scheme : %shepherd-root-service
     Ce service représente le PID 1.


File: guix.fr.info,  Node: Documentation,  Next: Installer les fichiers de débogage,  Prev: Configuration du système,  Up: Top

11 Documentation
****************

Dans la plupart des cas les paquets installés avec Guix ont une
documentation. Il y a deux formats de documentation principaux : « Info
», un format hypertexte navigable utilisé par les logiciels GNU et les «
pages de manuel » (ou « pages de man »), le format de documentation
linéaire traditionnel chez Unix. Les manuels Info sont disponibles via
la commande ‘info’ ou avec Emacs, et les pages de man sont accessibles
via la commande ‘man’.

   Vous pouvez chercher de la documentation pour les logiciels installés
sur votre système par mot-clef. Par exemple, la commande suivante
recherche des informations sur « TLS » dans les manuels Info :

     $ info -k TLS
     "(emacs)Network Security" -- STARTTLS
     "(emacs)Network Security" -- TLS
     "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_flags
     "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_function
     ...

La commande suivante recherche le même mot-clef dans les pages de man :

     $ man -k TLS
     SSL (7)              - OpenSSL SSL/TLS library
     certtool (1)         - GnuTLS certificate tool
     ...

   Ces recherches sont purement locales à votre ordinateur donc vous
savez que la documentation trouvée correspond à ce qui est effectivement
installé, vous pouvez y accéder hors ligne et votre vie privée est
préservée.

   Une fois que vous avez ces résultats, vous pouvez visualiser la
documentation appropriée avec, disons :

     $ info "(gnutls)Core TLS API"

ou :

     $ man certtool

   Les manuels Info contiennent des sections et des indexs ainsi que des
hyperliens comme ce qu’on trouve sur les pages Web. Le lecteur ‘info’
(*note Info reader: (info-stnd)Top.) et sa contre-partie dans Emacs
(*note (emacs)Misc Help::) fournissent des raccourcis claviers intuitifs
pour naviguer dans les manuels *Note (info)Pour démarrer:: pour trouver
une introduction sur la navigation dans info.

