Nächste: Shepherd-Dienste, Vorige: Diensttypen und Dienste, Nach oben: Dienste definieren [Inhalt][Index]
Wir haben bereits einen Überblick über Diensttypen gesehen (siehe
Diensttypen und Dienste). Dieser Abschnitt hier stellt eine
Referenz dar, wie Dienste und Diensttypen manipuliert werden können. Diese
Schnittstelle wird vom Modul (gnu services)
angeboten.
Liefert einen neuen Dienst des angegebenen Typs. Der Typ muss
als <service-type>
-Objekt angegeben werden (siehe unten). Als
Wert kann ein beliebiges Objekt angegeben werden, das die Parameter
dieser bestimmten Instanz dieses Dienstes repräsentiert.
Wenn kein Wert angegeben wird, wird der vom Typ festgelegte Vorgabewert verwendet; verfügt der Typ über keinen Vorgabewert, dann wird ein Fehler gemeldet.
Zum Beispiel bewirken Sie hiermit:
dasselbe wie mit:
In beiden Fällen ist das Ergebnis eine Instanz von
openssh-service-type
mit der vorgegebenen Konfiguration.
Liefert wahr zurück, wenn das Objekt ein Dienst ist.
Liefert den Typ des Dienstes – d.h. ein
<service-type>
-Objekt.
Liefert den Wert, der mit dem Dienst assoziiert wurde. Er repräsentiert die Parameter des Dienstes.
Hier ist ein Beispiel, wie ein Dienst erzeugt und manipuliert werden kann:
(define s (service nginx-service-type (nginx-configuration (nginx nginx) (log-directory log-Verzeichnis) (run-directory run-Verzeichnis) (file config-Datei)))) (service? s) ⇒ #t (eq? (service-kind s) nginx-service-type) ⇒ #t
Die Form modify-services
ist eine nützliche Methode, die Parameter
von einigen der Dienste aus einer Liste wie %base-services
abzuändern
(siehe %base-services
). Sie wird zu einer Liste
von Diensten ausgewertet. Natürlich können Sie dazu auch die üblichen
Listenkombinatoren wie map
und fold
benutzen (siehe
List Library in Referenzhandbuch zu GNU Guile),
modify-services
soll dieses häufig benutzte Muster lediglich durch
eine knappere Syntax unterstützen.
Passt die von Dienste bezeichnete Dienst-Liste entsprechend den angegebenen Klauseln an. Jede Klausel hat die Form:
(Typ Variable => Rumpf)
wobei Typ einen Diensttyp („service type“) bezeichnet – wie zum
Beispiel guix-service-type
– und Variable ein Bezeichner
ist, der im Rumpf an die Dienst-Parameter – z.B. eine
guix-configuration
-Instanz – des ursprünglichen Dienstes mit
diesem Typ gebunden wird.
Der Rumpf muss zu den neuen Dienst-Parametern ausgewertet werden,
welche benutzt werden, um den neuen Dienst zu konfigurieren. Dieser neue
Dienst wird das Original in der resultierenden Liste ersetzen. Weil die
Dienstparameter eines Dienstes mit define-record-type*
erzeugt
werden, können Sie einen kurzen Rumpf schreiben, der zu den neuen
Dienstparametern ausgewertet wird, indem Sie die Funktionalität namens
inherit
benutzen, die von define-record-type*
bereitgestellt
wird.
Klauseln können auch die folgende Form annehmen:
(delete Diensttyp)
Mit so einer Klausel werden alle Dienste mit dem angegebenen Diensttyp aus der Liste der Dienste weggelassen.
Siehe Das Konfigurationssystem nutzen für ein Anwendungsbeispiel.
Als Nächstes ist die Programmierschnittstelle für Diensttypen an der
Reihe. Sie ist etwas, was Sie kennen werden wollen, wenn Sie neue
Dienstdefinitionen schreiben, aber wenn Sie nur Ihre
operating-system
-Deklaration anpassen möchten, brauchen Sie diese
Schnittstelle wahrscheinlich nicht.
Die Repräsentation eines Diensttypen (siehe Diensttypen und Dienste).
name
Dieses Symbol wird nur verwendet, um die Abläufe im System anzuzeigen und die Fehlersuche zu erleichtern.
extensions
Eine nicht-leere Liste von <service-extension>
-Objekten (siehe
unten).
compose
(Vorgabe: #f
)Wenn es auf #f
gesetzt ist, dann definiert der Diensttyp Dienste, die
nicht erweitert werden können – d.h. diese Dienste erhalten ihren
Wert nicht von anderen Diensten.
Andernfalls muss es eine Prozedur sein, die ein einziges Argument
entgegennimmt. Die Prozedur wird durch fold-services
aufgerufen und
ihr wird die Liste von aus den Erweiterungen angesammelten Werten
übergeben. Sie gibt daraufhin einen einzelnen Wert zurück.
extend
(Vorgabe: #f
)Ist dies auf #f
gesetzt, dann können Dienste dieses Typs nicht
erweitert werden.
Andernfalls muss es eine zwei Argumente nehmende Prozedur sein, die von
fold-services
mit dem anfänglichen Wert für den Dienst als erstes
Argument und dem durch Anwendung von compose
gelieferten Wert als
zweites Argument aufgerufen wird. Als Ergebnis muss ein Wert geliefert
werden, der einen zulässigen neuen Parameterwert für die Dienstinstanz
darstellt.
description
Eine Zeichenkette, womöglich geschrieben als Texinfo-Markup, die in ein paar
Sätzen beschreibt, wofür der Dienst gut ist. Diese Zeichenkette ermöglicht
es Nutzern, mittels guix system search
Informationen über den
Dienst zu bekommen (siehe guix system
aufrufen).
default-value
(Vorgabe: &no-default-value
)Der Vorgabewert, der für Instanzen dieses Diensttyps verwendet wird. Dadurch
können Nutzer die service
-Form ohne ihr zweites Argument benutzen:
(service Diensttyp)
Der zurückgelieferte Dienst hat dann den durch den Diensttyp vorgegebenen Vorgabewert.
Siehe den Abschnitt Diensttypen und Dienste für Beispiele.
Liefert eine neue Erweiterung für den Dienst mit dem Zieltyp. Als
Berechner muss eine Prozedur angegeben werden, die ein einzelnes
Argument nimmt: fold-services
ruft sie auf und übergibt an sie den
Wert des erweiternden Dienstes, sie muss dafür einen zulässigen Wert für den
Zieltyp liefern.
Liefert wahr zurück, wenn das Objekt eine Diensterweiterung ist.
Manchmal wollen Sie vielleicht einfach nur einen bestehenden Dienst
erweitern. Dazu müssten Sie einen neuen Diensttyp definieren und die
Erweiterung definieren, für die Sie sich interessieren, was ganz schön
wortreich werden kann. Mit der Prozedur simple-service
können Sie es
kürzer fassen.
Liefert einen Dienst, der den Dienst mit dem Zieltyp um den Wert erweitert. Dazu wird ein Diensttyp mit dem Namen für den einmaligen Gebrauch erzeugt, den der zurückgelieferte Dienst instanziiert.
Zum Beispiel kann mcron (siehe Geplante Auftragsausführung) so um einen zusätzlichen Auftrag erweitert werden:
(simple-service 'my-mcron-job mcron-service-type
#~(job '(next-hour (3)) "guix gc -F 2G"))
Den Kern dieses abstrakten Modells für Dienste bildet die Prozedur
fold-services
, die für das „Kompilieren“ einer Liste von Diensten hin
zu einem einzelnen Verzeichnis verantwortlich ist, in welchem alles
enthalten ist, was Sie zum Booten und Hochfahren des Systems brauchen –
d.h. das Verzeichnis, das der Befehl guix system build
anzeigt
(siehe guix system
aufrufen). Einfach ausgedrückt propagiert
fold-services
Diensterweiterungen durch den Dienstgraphen nach unten
und aktualisiert dabei in jedem Knoten des Graphen dessen Parameter, bis nur
noch der Wurzelknoten übrig bleibt.
Faltet die Dienste wie die funktionale Prozedur fold
zu einem
einzigen zusammen, indem ihre Erweiterungen nach unten propagiert werden,
bis eine Wurzel vom target-type als Diensttyp erreicht wird; dieser so
angepasste Wurzeldienst wird zurückgeliefert.
Als Letztes definiert das Modul (gnu services)
noch mehrere
essenzielle Diensttypen, von denen manche im Folgenden aufgelistet sind:
Die Wurzel des Dienstgraphen. Davon wird das Systemverzeichnis erzeugt, wie
es vom Befehl guix system build
zurückgeliefert wird.
Der Typ des „Boot-Dienstes“, der das Boot-Skript erzeugt. Das Boot-Skript ist das, was beim Booten durch die initiale RAM-Disk ausgeführt wird.
Der Typ des /etc-Dienstes. Dieser Dienst wird benutzt, um im /etc-Verzeichnis Dateien zu platzieren. Er kann erweitert werden, indem man Name-Datei-Tupel an ihn übergibt wie in diesem Beispiel:
(list `("issue" ,(plain-file "issue" "Willkommen!\n")))
Dieses Beispiel würde bewirken, dass eine Datei /etc/issue auf die angegebene Datei verweist.
Der Typ des Dienstes für privilegierte Programme, der eine Liste von ausführbaren Dateien ansammelt, die jeweils als G-Ausdrücke übergeben werden und dann zur Menge der privilegierten Programme auf dem System hinzugefügt werden (siehe Privilegierte Programme).
Der Typ des Dienstes zum Einfügen von Dateien ins Systemprofil – d.h. die Programme unter /run/current-system/profile. Andere Dienste können ihn erweitern, indem sie ihm Listen von ins Systemprofil zu installierenden Paketen übergeben.
Dies ist der Diensttyp des Dienstes, um Provenienz-Metadaten zusammen mit dem eigentlichen System zu speichern. Dazu werden mehrere Dateien unter /run/current-system erstellt:
Sie ist eine „Kanaldatei“, wie sie an guix pull -C
oder
guix time-machine -C
übergeben werden kann, die die zum Erstellen
des Systems notwendigen Kanäle beschreibt, sofern diese Information zur
Verfügung gestanden hat (siehe Kanäle).
Jene Datei entspricht derjenigen, die als Wert für diesen
provenance-service-type
-Dienst mitgegeben wurde. Nach Vorgabe
übergibt guix system reconfigure
automatisch die
Betriebssystemkonfigurationsdatei, die es auf der Befehlszeile bekommen hat.
Hierin sind dieselben Informationen enthalten, die auch in den anderen beiden Dateien stehen, aber in einem leichter zu verarbeitenden Format.
Im Allgemeinen genügen diese zwei Informationen (Kanäle und Konfigurationsdatei), um das Betriebssystem „aus seinem Quellcode heraus“ zu reproduzieren.
Einschränkungen: Sie benötigen diese Informationen, um Ihr Betriebssystem erneut zu erstellen, aber sie alleine reichen nicht immer aus. Insbesondere ist configuration.scm alleine nicht hinreichend, wenn es nicht eigenständig ist, sondern auf externe Guile-Module oder andere Dateien verweist. Wenn Sie erreichen wollen, dass configuration.scm eigenständig wird, empfehlen wir, alle darin verwendeten Module oder Dateien zu Bestandteilen eines Kanals zu machen.
Übrigens sind Provenienzmetadaten „still“ in dem Sinn, dass ihr Vorhandensein nichts an den Bits ändert, die Ihr System ausmachen, abgesehen von den die Metadaten ausmachenden Bits. Zwei verschiedene Betriebssystemkonfigurationen und Kanalangaben können also Bit für Bit dasselbe System erzeugen, aber wenn der
provenance-service-type
benutzt wird, enthalten die beiden Systeme trotzdem unterschiedliche Metadaten und damit nicht mehr den gleichen Dateinamen im Store, was es schwerer macht, ihre Gleichheit zu erkennen.
Dieser Dienst wird automatisch zu Ihrer Betriebssystemkonfiguration
hinzugefügt, wenn Sie guix system reconfigure
, guix
system init
oder guix deploy
benutzen.
Der Diensttyp des Dienstes, der Listen von Paketen mit Kernel-Modulen, die der Kernel laden können soll, sammelt und dafür sorgt, dass der Kernel sie laden kann.
Der Diensttyp ist dazu gedacht, von anderen Diensttypen erweitert zu werden, etwa so:
(simple-service 'installing-module
linux-loadable-module-service-type
(list module-to-install-1
module-to-install-2))
Die Module werden nicht geladen. Sie werden nur zum Kernel-Profil hinzugefügt, damit sie mit anderen Werkzeugen überhaupt erst geladen werden können.
Nächste: Shepherd-Dienste, Vorige: Diensttypen und Dienste, Nach oben: Dienste definieren [Inhalt][Index]