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


8.17.3 Référence de service

Nous avons vu un résumé des types de services (voir 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 du 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 :

est équivalent à ceci :

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 (voir %base-services). 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 (voir List Library dans GNU Guile Reference Manual) ; 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)

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

Voir 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 (voir 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.

Voir 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 (voir 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 (voir 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 (voir 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.

Scheme Variable : provenance-service-type

This is the type of the service that records provenance meta-data in the system itself. It creates several files under /run/current-system:

channels.scm

This is a “channel file” that can be passed to guix pull -C or guix time-machine -C, and which describes the channels used to build the system, if that information was available (voir Canaux).

configuration.scm

This is the file that was passed as the value for this provenance-service-type service. By default, guix system reconfigure automatically passes the OS configuration file it received on the command line.

provenance

This contains the same information as the two other files but in a format that is more readily processable.

In general, these two pieces of information (channels and configuration file) are enough to reproduce the operating system “from source”.

Caveats : This information is necessary to rebuild your operating system, but it is not always sufficient. In particular, configuration.scm itself is insufficient if it is not self-contained—if it refers to external Guile modules or to extra files. If you want configuration.scm to be self-contained, we recommend that modules or files it refers to be part of a channel.

Besides, provenance meta-data is “silent” in the sense that it does not change the bits contained in your system, except for the meta-data bits themselves. Two different OS configurations or sets of channels can lead to the same system, bit-for-bit; when provenance-service-type is used, these two systems will have different meta-data and thus different store file names, which makes comparison less trivial.

This service is automatically added to your operating system configuration when you use guix system reconfigure, guix system init, or guix deploy.


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