Suivant: Services Shepherd, Précédent: Types service et services, Monter: Définir des services [Table des matières][Index]
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).
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 :
est équivalent à ceci :
Dans les deux cas le résultat est une instance de
openssh-service-type avec la configuration par défaut.
Renvoie vrai si obj est un service.
Renvoie le type de service — c.-à-d. un objet <service-type>.
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.
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*.
Les clauses peuvent aussi avoir les formes suivantes :
(delete type)
Cette clause supprime tous les services du type donné de services.
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.
C’est la représentation d’un type de service (voir Types service et services).
nameC’est un symbole, utilisé seulement pour simplifier l’inspection et le débogage.
extensionsUne 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.
descriptionC’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
(voir 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.
Voir Types service et services, pour des exemples.
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.
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.
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.
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.
C’est la racine du graphe des services. Il produit le répertoire du système
renvoyé par la commande guix system build.
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.
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é.
Type for the “privileged-program service”. This service collects lists of executable file names, passed as gexps, and adds them to the set of privileged programs on the system (voir Privileged Programs).
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.
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 :
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
(voir Canaux).
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.
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-typeest 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.
Type du service qui récolte les listes de paquets contenant les modules chargeables par le noyau, et les ajoute à l’ensemble des modules chargeables par le noyau.
Ce type de service est conçu pour être étendu par d’autres types de services, comme ceci :
(simple-service 'installing-module
linux-loadable-module-service-type
(list module-to-install-1
module-to-install-2))
Ce service ne charge pas les modules au démarrage, il ne fait que les ajouter au profil du noyau pour qu’ils puissent être chargés par d’autres moyens.
Suivant: Services Shepherd, Précédent: Types service et services, Monter: Définir des services [Table des matières][Index]