Nächste: , Vorige: , Nach oben: Dienste definieren   [Inhalt][Index]


12.18.3 Service-Referenz

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.

Scheme-Prozedur: service Typ [Wert]

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.

Scheme-Prozedur: service? Objekt

Liefert wahr zurück, wenn das Objekt ein Dienst ist.

Scheme-Prozedur: service-kind Dienst

Liefert den Typ des Dienstes – d.h. ein <service-type>-Objekt.

Scheme-Prozedur: service-value Dienst

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.

Scheme-Syntax: modify-services Dienste (Typ Variable => Rumpf) …

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.

Datentyp: service-type

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.

Scheme-Prozedur: service-extension Zieltyp Berechner 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.

Scheme-Prozedur: service-extension? Objekt

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.

Scheme-Prozedur: simple-service Name Zieltyp Wert

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.

Scheme-Prozedur: fold-services Dienste [#:target-type system-service-type] 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:

Scheme-Variable: system-service-type

Die Wurzel des Dienstgraphen. Davon wird das Systemverzeichnis erzeugt, wie es vom Befehl guix system build zurückgeliefert wird.

Scheme-Variable: boot-service-type

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.

Scheme-Variable: etc-service-type

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.

Scheme-Variable: setuid-program-service-type

Der Typ des Dienstes für setuid-Programme, der eine Liste von ausführbaren Dateien ansammelt, die jeweils als G-Ausdrücke übergeben werden und dann zur Menge der setuid- oder setgid-gesetzten Programme auf dem System hinzugefügt werden (siehe Setuid-Programme).

Scheme-Variable: profile-service-type

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.

Scheme-Variable: provenance-service-type

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:

channels.scm

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

configuration.scm

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.

provenance

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.

Scheme-Variable: linux-loadable-module-service-type

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]