This is guix.de.info, produced by makeinfo version 6.7 from
guix.de.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

   Es ist Ihnen gestattet, dieses Dokument zu vervielfältigen,
weiterzugeben und/oder zu verändern, unter den Bedingungen der GNU Free
Documentation License, entweder gemäß Version 1.3 der Lizenz oder (nach
Ihrer Option) einer späteren Version, die von der Free Software
Foundation veröffentlicht wurde, ohne unveränderliche Abschnitte, ohne
vorderen Umschlagtext und ohne hinteren Umschlagtext. Eine Kopie der
Lizenz finden Sie im Abschnitt mit dem Titel „GNU Free Documentation
License“.
INFO-DIR-SECTION Systemadministration
START-INFO-DIR-ENTRY
* Guix: (guix.de).           Installierte Software und Systemkonfigurationen
                               verwalten.
* guix package: (guix.de)guix package aufrufen.  Pakete installieren,
                                                   entfernen und
                                                   aktualisieren.
* guix gc: (guix.de)guix gc aufrufen.  Unbenutzten Plattenspeicher wieder
                                         freigeben.
* guix pull: (guix.de)guix pull aufrufen.  Die Liste verfügbarer Pakete
                                             aktualisieren.
* guix system: (guix.de)guix system aufrufen.  Die
                                                 Betriebssystemkonfiguration
                                                 verwalten.
* guix deploy: (guix.de)guix deploy aufrufen.  Betriebssystemkonfigurationen
                                                 entfernter Rechner verwalten.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Softwareentwicklung
START-INFO-DIR-ENTRY
* guix environment: (guix.de)guix environment aufrufen.  Umgebungen für
                                                           Entwickler
                                                           erstellen
* guix build: (guix.de)guix build aufrufen.  Erstellen von Paketen.
* guix pack: (guix.de)guix pack aufrufen.  Bündel aus Binärdateien
                                             erstellen.
END-INFO-DIR-ENTRY



File: guix.de.info,  Node: DNS-Dienste,  Next: VPN-Dienste,  Prev: Zertifikatsdienste,  Up: Dienste

10.8.20 DNS-Dienste
-------------------

Das Modul ‘(gnu services dns)’ stellt Dienste zur Verfügung, die mit dem
“Domain Name System” (DNS) zu tun haben. Es bietet einen Server-Dienst
an, mit dem ein _autoritativer_ DNS-Server für mehrere Zonen betrieben
werden kann, jeweils als untergeordneter „Slave“ oder als „Master“.
Dieser Dienst benutzt Knot DNS (https://www.knot-dns.cz/). Außerdem wird
ein zwischenspeichernder und weiterleitender DNS-Server für das LAN
bereitgestellt, der dnsmasq
(http://www.thekelleys.org.uk/dnsmasq/doc.html) benutzt.

Knot-Dienst
...........

Eine Beispielkonfiguration eines autoritativen Servers für zwei Zonen,
eine „Master“, eine „Slave“, wäre:

     (define-zone-entries example.org.zone
     ;; Name TTL Class Type Data
       ("@"  ""  "IN"  "A"  "127.0.0.1")
       ("@"  ""  "IN"  "NS" "ns")
       ("ns" ""  "IN"  "A"  "127.0.0.1"))

     (define master-zone
       (knot-zone-configuration
         (domain "example.org")
         (zone (zone-file
                 (origin "example.org")
                 (entries example.org.zone)))))

     (define slave-zone
       (knot-zone-configuration
         (domain "plop.org")
         (dnssec-policy "default")
         (master (list "plop-master"))))

     (define plop-master
       (knot-remote-configuration
         (id "plop-master")
         (address (list "208.76.58.171"))))

     (operating-system
       ;; ...
       (services (cons* (service knot-service-type
                          (knot-configuration
                            (remotes (list plop-master))
                            (zones (list master-zone slave-zone))))
                        ;; ...
                        %base-services)))

 -- Scheme-Variable: knot-service-type
     Dies ist der Diensttyp für den Knot-DNS-Server.

     Knot DNS ist ein autoritativer DNS-Server, das heißt, er kann
     mehrere Zonen bedienen, also mehrere Domainnamen, die Sie von einem
     Registrar kaufen würden. Dieser Server ist kein „Resolver“, er
     dient also nur zur Auflösung von Namen, für die er autoritativ ist.
     Dieser Server kann so konfiguriert werden, dass er Zonen als
     „Master“-Server oder als „Slave“-Server bereitstellt, je nachdem,
     wie er für die jeweilige Zone eingestellt ist. Server für
     „Slave“-Zonen erhalten ihre Daten von „Master“-Servern und stellen
     mit ihnen einen autoritativen Server zur Verfügung. Für einen
     „Resolver“ macht es keinen Unterschied, ob er Namen auflöst, indem
     er einen „Master“ oder einen „Slave“ danach fragt.

     Die folgenden Datentypen werden benutzt, um den Knot-DNS-Server zu
     konfigurieren:

 -- Datentyp: knot-key-configuration
     Datentyp, der einen Schlüssel repräsentiert. Dieser Typ hat die
     folgenden Parameter:

     ‘id’ (Vorgabe: ‘""’)
          Ein Identifikator, mit dem sich andere Konfigurationsfelder
          auf diesen Schlüssel beziehen können. IDs müssen eindeutig
          sein und dürfen _nicht_ leer sein.

     ‘algorithm’ (Vorgabe: ‘#f’)
          Der Algorithmus, der benutzt werden soll. Wählen Sie zwischen
          ‘#f’, ‘'hmac-md5’, ‘'hmac-sha1’, ‘'hmac-sha224’,
          ‘'hmac-sha256’, ‘'hmac-sha384’ und ‘'hmac-sha512’.

     ‘secret’ (Vorgabe: ‘""’)
          Was dabei der geheime Schlüssel sein soll.

 -- Datentyp: knot-acl-configuration
     Datentyp, der die Konfiguration einer Zugriffssteuerungsliste
     („Access Control List“, ACL) repräsentiert. Dieser Typ hat die
     folgenden Parameter:

     ‘id’ (Vorgabe: ‘""’)
          Ein Identifikator, mit dem sich andere Konfigurationsfelder
          auf diesen Schlüssel beziehen können. IDs müssen eindeutig
          sein und dürfen _nicht_ leer sein.

     ‘address’ (Vorgabe: ‘'()’)
          Eine geordnete Liste aus IP-Adresse, Netzwerk-Subnetzen oder
          Netzwerkbereichen, die jeweils als Zeichenketten angegeben
          werden. Die Anfrage muss zu einem davon passen. Ein leerer
          Wert bedeutet, dass die Adresse nicht passen muss.

     ‘key’ (Vorgabe: ‘'()’)
          Eine geordnete Liste von Referenzen auf Schlüssel, die jeweils
          als Zeichenketten angegeben werden. Die Zeichenkette muss zu
          einem Schlüsselidentifikator passen, der in einem der
          ‘knot-key-configuration’-Objekte definiert wurde. Wenn kein
          Schlüssel angegeben wird, bedeutet das, dass kein Schlüssel zu
          dieser Zugriffssteuerungsliste passen muss.

     ‘action’ (Vorgabe: ‘'()’)
          Eine geordete Liste der Aktionen, die von dieser
          Zugriffssteuerungsliste zugelassen oder gesperrt werden.
          Mögliche Werte sind Listen aus null oder mehr Elementen, die
          jeweils ‘'transfer’, ‘'notify’ oder ‘'update’ sind.

     ‘deny?’ (Vorgabe: ‘#f’)
          Wenn dies auf wahr steht, werden mit der
          Zugriffssteuerungsliste Einschränkungen festgelegt, d.h.
          aufgelistet Aktionen werden gesperrt. Steht es auf falsch,
          werden aufgelistete Aktionen zugelassen.

 -- Datentyp: zone-entry
     Datentyp, der einen Eintrag in einer Zonendatei repräsentiert.
     Dieser Typ verfügt über die folgenden Parameter:

     ‘name’ (Vorgabe: ‘"@"’)
          Der Name des Eintrags. ‘"@"’ bezieht sich auf den Ursprung der
          Zone. Namen sind relativ zum Ursprung der Zone. Zum Beispiel
          bezieht sich in einer Zone ‘example.org’ der Eintrag
          ‘"ns.example.org"’ tatsächlich auf
          ‘ns.example.org.example.org’. Namen, die auf einen Punkt
          enden, sind absolut. Das bedeutet, dass sich
          ‘"ns.example.org."’ auf ‘ns.example.org’ bezieht.

     ‘ttl’ (Vorgabe: ‘""’)
          Wie lange dieser Eintrag zwischengespeichert werden darf, d.h.
          seine „Time-To-Live“ (TTL). Ist sie nicht festgelegt, wird die
          voreingestellte TTL benutzt.

     ‘class’ (Vorgabe: ‘"IN"’)
          Welche Klasse der Eintrag hat. Derzeit unterstützt Knot nur
          ‘"IN"’ und teilweise ‘"CH"’.

     ‘type’ (Vorgabe: ‘"A"’)
          Der Typ des Eintrags. Zu den üblichen Typen gehören A (für
          eine IPv4-Adresse), AAAA (für eine IPv6-Adresse), NS (der
          Namens-Server) und MX („Mail eXchange“ für E-Mails). Viele
          andere Typen sind auch definiert.

     ‘data’ (Vorgabe: ‘""’)
          Die Daten, die im Eintrag stehen, zum Beispiel eine IP-Adresse
          bei einem A-Eintrag oder ein Domain-Name bei einem NS-Eintrag.
          Bedenken Sie, dass Domain-Namen relativ zum Ursprung angegeben
          werden, außer wenn sie auf einen Punkt enden.

 -- Datentyp: zone-file
     Datentyp, der den Inhalt einer Zonendatei repräsentiert. Dieser Typ
     verfügt über die folgenden Parameter:

     ‘entries’ (Vorgabe: ‘'()’)
          Die Liste der Einträge. Für den SOA-Eintrag wird automatisch
          gesorgt, also müssen Sie ihn nicht zur Liste der Einträge
          hinzufügen. In der Liste sollte vermutlich ein Eintrag für
          Ihren primären autoritativen DNS-Server stehen. Abgesehen vom
          direkten Aufzählen der Einträge können Sie
          ‘define-zone-entries’ verwenden, um ein Objekt zu definieren,
          worin eine Liste von Einträgen leichter angegeben werden kann,
          und was sie dann im ‘entries’-Feld des ‘zone-file’ angeben
          können.

     ‘origin’ (Vorgabe: ‘""’)
          Der Name Ihrer Zone. Dieser Parameter darf nicht leer sein.

     ‘ns’ (Vorgabe: ‘"ns"’)
          Die Domain Ihres primären autoritativen DNS-Servers. Der Name
          wird relativ zum Ursprung angegeben, außer wenn er auf einen
          Punkt endet. Dieser primäre DNS-Server _muss_ verpflichtend
          einem NS-Eintrag in der Zone entsprechen, dem eine IP-Adresse
          in der Liste der Einträge zugeordnet werden muss.

     ‘mail’ (Vorgabe: ‘"hostmaster"’)
          Eine E-Mail-Adresse, unter der man Sie als für diese Zone
          Verantwortlichen („Besitzer“/„Owner“) kontaktieren kann. Sie
          wird zu ‘<mail>@<origin>’ umgeschrieben.

     ‘serial’ (Vorgabe: ‘1’)
          Die Seriennummer der Zone. Da sie von sowohl „Slaves“ als auch
          „Resolvern“ benutzt wird, um bei Änderungen auf dem Laufenden
          zu bleiben, ist es notwendig, dass sie _niemals_ kleiner
          gemacht wird. Erhöhen Sie sie, wann immer Sie eine Änderung an
          Ihrer Zone durchführen.

     ‘refresh’ (Vorgabe: ‘(* 2 24 3600)’)
          Die Häufigkeit, wie oft Slaves eine Zonenübertragung („Zone
          Transfer“) durchführen. Als Wert wird eine Anzahl von Sekunden
          angegeben. Sie kann über eine Multiplikation oder mit
          ‘(string->duration)’ angegeben werden.

     ‘retry’ (Vorgabe: ‘(* 15 60)’)
          Nach welcher Zeitperiode ein Slave versuchen wird, Kontakt mit
          seinem Master aufzunehmen, wenn er ihn beim ersten Mal nicht
          erreichen kann.

     ‘expiry’ (Vorgabe: ‘(* 14 24 3600)’)
          Die Voreinstellung, welche TTL für Einträge verwendet werden
          soll. Bestehende Einträge werden für höchstens diese
          Zeitspanne als korrekt angesehen. Nach Ablauf dieser
          Zeitspanne werden „Resolver“ ihren Zwischenspeicher als
          ungültig markieren und erneut prüfen, ob der Eintrag noch
          existiert.

     ‘nx’ (Vorgabe: ‘3600’)
          Die voreingestellte TTL der _nicht_ existierenden Einträge.
          Sie stellt normalerweise eine kurze Verzögerung dar, weil Sie
          möchten, dass neue Domains für jeden schnell erkannt werden.

 -- Datentyp: knot-remote-configuration
     Datentyp, der die Konfiguration eines entfernten Servers („Remote“)
     repräsentiert. Dieser Typ verfügt über die folgenden Parameter:

     ‘id’ (Vorgabe: ‘""’)
          Ein Identifikator, mit dem man sich in anderen
          Konfigurationsfeldern auf diesen entfernten Server („Remote“)
          beziehen kann. IDs müssen eindeutig sein und dürfen _nicht_
          leer sein.

     ‘address’ (Vorgabe: ‘'()’)
          Eine geordnete Liste der Empfänger-IP-Adressen. Adressen
          werden der Reihe nach durchprobiert. Optional kann eine
          Portnummer nach dem Trennzeichen @ angegeben werden, zum
          Beispiel als ‘(list "1.2.3.4" "2.3.4.5@53")’. Die Vorgabe ist
          53.

     ‘via’ (Vorgabe: ‘'()’)
          Eine geordnete Liste der Quell-IP-Adressen. Eine leere Liste
          wird Knot eine sinnvolle Quell-IP-Adresse auswählen lassen.
          Optional kann eine Portnummer nach dem Trennzeichen @
          angegeben werden. Die Vorgabe wird zufällig ausgewählt.

     ‘key’ (Vorgabe: ‘#f’)
          Ein Verweis auf einen Schlüssel („Key“), also eine
          Zeichenkette, die den Identifikator eines Schlüssels enthält,
          der in einem ‘knot-key-configuration’-Feld festgelegt wurde.

 -- Datentyp: knot-keystore-configuration
     Datentyp, der einen Schlüsselspeicher („Keystore“) repräsentiert,
     um DNSSEC-Schlüssel zu fassen. Dieser Typ verfügt über die
     folgenden Parameter:

     ‘id’ (Vorgabe: ‘""’)
          Der Identifikator des Schlüsselspeichers. Er darf nicht leer
          gelassen werden.

     ‘backend’ (Vorgabe: ‘'pem’)
          Die Art von Hintergrundspeicher, in dem Schlüssel eingetragen
          werden. Sie kann ‘'pem’ oder ‘'pkcs11’ sein.

     ‘config’ (Vorgabe: ‘"/var/lib/knot/keys/keys"’)
          Die Zeichenkette mit der Konfiguration des
          Hintergrundspeichers. Ein Beispiel für die PKCS#11 ist
          ‘"pkcs11:token=knot;pin-value=1234
          /gnu/store/…/lib/pkcs11/libsofthsm2.so"’. Für pem als
          Hintergrundspeicher repräsentiert die Zeichenkette einen Pfad
          im Dateisystem.

 -- Datentyp: knot-policy-configuration
     Datentyp, der die DNSSEC-Richtlinie repräsentiert. Knot DNS kann
     Ihre Zonen automatisch signieren. Der Dienst kann Ihre Schlüssel
     automatisch erzeugen und verwalten oder Schlüssel benutzen, die Sie
     selbst erzeugen.

     DNSSEC wird in der Regel mit zwei Schlüsseln implementiert: Ein
     Schlüssel, mit dem Schlüssel signiert werden („Key Signing Key“,
     KSK), signiert den zweiten Schlüssel, einen Schlüssel, der Zonen
     signiert („Zone Signing Key“, ZSK), mit dem die Zone signiert wird.
     Damit er als vertrauenswürdig angesehen wird, muss der KSK in der
     Elternzone stehen (meistens ist das eine Top-Level-Domain). Wenn
     Ihr Registrar DNSSEC unterstützt, müssen Sie ihm den Hash Ihres KSK
     übermitteln, damit er einen DS-Eintrag für Ihre Zone hinzufügen
     kann. Das passiert nicht automatisch und muss jedes Mal wiederholt
     werden, wenn Sie Ihren KSK ändern.

     Die Richtlinie legt auch fest, wie lange Ihre Schlüssel gültig
     bleiben. Normalerweise kann der ZSK leicht geändert werden und
     benutzt kryptografisch schwächere Funktionen (also niedrigere
     Parameter), damit Einträge schnell signiert werden können, wodurch
     man sie oft verändern kann. Der KSK setzt jedoch eine manuelle
     Interaktion mit dem Registrar voraus, also werden sie weniger oft
     geändert und verwenden stärkere Parameter, weil mit ihnen nur ein
     einziger Eintrag signiert wird.

     Dieser Typ verfügt über die folgenden Parameter:

     ‘id’ (Vorgabe: ‘""’)
          Der Identifikator der Richtlinie. Er darf nicht leer sein.

     ‘keystore’ (Vorgabe: ‘"default"’)
          Eine Referenz auf einen Schlüsselspeicher („Keystore“), also
          eine Zeichenkette, die den Identifikator eines
          Schlüsselspeichers enthält, der in einem
          ‘knot-keystore-configuration’-Feld gespeichert ist. Der
          Identifikator ‘"default"’ sorgt dafür, dass der vorgegebene
          Schlüsselspeicher verwendet wird (eine KASP-Datenbank, die
          durch diesen Dienst eingerichtet wurde).

     ‘manual?’ (Vorgabe: ‘#f’)
          Ob Schlüssel manuell verwaltet werden sollen; andernfalls
          werden sie automatisch verwaltet.

     ‘single-type-signing?’ (Vorgabe: ‘#f’)
          Wenn es auf ‘#t’ steht, werden dieselben Schlüssel als KSK und
          ZSK verwendet („Single-Type Signing Scheme“).

     ‘algorithm’ (Vorgabe: ‘"ecdsap256sha256"’)
          Ein Algorithmus für zum Signieren verwendete Schlüssel und
          ausgestellte Signaturen.

     ‘ksk-size’ (Vorgabe: ‘256’)
          Die Länge des KSK. Beachten Sie, dass dieser Wert für den
          vorgegebenen Algorithmus korrekt ist, aber für andere
          Algorithmen _nicht_ sicher wäre.

     ‘zsk-size’ (Vorgabe: ‘256’)
          Die Länge des ZSK. Beachten Sie, dass dieser Wert für den
          vorgegebenen Algorithmus korrekt ist, aber für andere
          Algorithmen _nicht_ sicher wäre.

     ‘dnskey-ttl’ (Vorgabe: ‘'default’)
          Der TTL-Wert für DNSKEY-Einträge, die die Wurzel der Zone
          betreffen. Der besondere Wert ‘'default’ bedeutet, dass
          dieselbe TTL wie für den SOA-Eintrag der Zone verwendet wird.

     ‘zsk-lifetime’ (Vorgabe: ‘(* 30 24 3600)’)
          Die Zeitspanne zwischen der Veröffentlichung eines ZSK und dem
          Anfang des nächsten Schlüsselübergangs („Key Rollover“).

     ‘propagation-delay’ (Vorgabe: ‘(* 24 3600)’)
          Eine zusätzliche Verlängerung, die bei jedem Schritt im
          Schlüsselübergang („Key Rollover“) gewartet wird. Dieser Wert
          sollte hoch genug sein, damit in dieser Zeit Daten vom
          Master-Server alle Slaves erreichen.

     ‘rrsig-lifetime’ (Vorgabe: ‘(* 14 24 3600)’)
          Wie lange neu ausgestellte Signaturen gültig bleiben.

     ‘rrsig-refresh’ (Vorgabe: ‘(* 7 24 3600)’)
          Wie lange im Voraus vor einem Auslaufen der Signatur diese
          Signatur erneuert werden soll.

     ‘nsec3?’ (Vorgabe: ‘#f’)
          Ist es auf ‘#t’ gesetzt, wird NSEC3 statt NSEC benutzt.

     ‘nsec3-iterations’ (Vorgabe: ‘5’)
          Wie oft zusätzlich gehasht werden soll.

     ‘nsec3-salt-length’ (Vorgabe: ‘8’)
          Wie lange das kryptografische „Salt“ sein soll, als Anzahl von
          Oktetten. Es wird vor dem Hashen an den Namen des
          ursprünglichen Besitzers angehängt.

     ‘nsec3-salt-lifetime’ (Vorgabe: ‘(* 30 24 3600)’)
          Wie lange das neu ausgestellte Salt-Feld gültig bleiben soll.

 -- Datentyp: knot-zone-configuration
     Datentyp, der eine durch Knot verfügbar gemachte Zone
     repräsentiert. Dieser Typ verfügt über die folgenden Parameter:

     ‘domain’ (Vorgabe: ‘""’)
          Die Domain, die durch diese Konfiguration zur Verfügung
          gestellt wird. Sie darf nicht leer sein.

     ‘file’ (Vorgabe: ‘""’)
          Die Datei, in der diese Zone abgespeichert wird. Dieser
          Parameter wird bei Master-Zonen ignoriert. Bleibt er leer,
          wird die vom Domain-Namen abhängige Voreinstellung benutzt.

     ‘zone’ (Vorgabe: ‘(zone-file)’)
          Der Inhalt der Zonendatei. Dieser Parameter wird bei
          Slave-Zonen ignoriert. Er muss ein Verbundsobjekt vom Typ
          ‘zone-file’ enthalten.

     ‘master’ (Vorgabe: ‘'()’)
          Eine Liste von als „Master“ geltenden entfernten Servern. Ist
          sie leer, ist diese Zone ein Master, sonst ein Slave. Es
          handelt sich um eine Liste von Identifikatoren entfernter
          Server („Remotes“).

     ‘ddns-master’ (Vorgabe: ‘#f’)
          Der vorrangige „Master“. Ist dies leer, wird hierfür der erste
          Master aus der Liste der Master benutzt.

     ‘notify’ (Vorgabe: ‘'()’)
          Eine Liste der Identifikatoren von entfernten Slave-Servern
          („Remotes“).

     ‘acl’ (Vorgabe: ‘'()’)
          Eine Liste von Identifikatoren von Zugriffssteuerungslisten.

     ‘semantic-checks?’ (Vorgabe: ‘#f’)
          Wenn dies festgelegt ist, werden für die Zone mehr semantische
          Überprüfungen durchgeführt.

     ‘disable-any?’ (Vorgabe: ‘#f’)
          Wenn dies gesetzt ist, werden Anfragen vom Typ ANY gesperrt.

     ‘zonefile-sync’ (Vorgabe: ‘0’)
          Wie lange nach einer Änderung der im Arbeitsspeicher
          zwischengespeicherten Daten gewartet wird, bis die Daten auf
          die Platte geschrieben werden. Bei 0 werden sie sofort
          synchronisiert.

     ‘zonefile-load’ (Vorgabe: ‘#f’)
          Wie die in der Zonendatei gespeicherten Daten benutzt werden,
          wenn die Zone geladen wird. Mögliche Werte sind:

             • ‘#f’ sorgt dafür, dass nach der Voreinstellung von Knot
               verfahren wird,
             • ‘'none’ bewirkt, dass die Zonendatei überhaupt nicht
               benutzt wird,
             • ‘'difference’ lässt den Unterschied zwischen den bereits
               vorliegenden Daten und dem gespeicherten Inhalt der Zone
               berechnen, welcher dann zum vorliegenden Zoneninhalt
               hinzugenommen wird,
             • ‘'difference-no-serial’ für dasselbe wie bei
               ‘'difference’, aber die SOA-Seriennummer in der
               Zonendatei wird ignoriert und der Server kümmert sich
               automatisch darum.
             • ‘'whole’ lässt den ganzen Inhalt der Zone aus der
               Zonendatei auslesen.

     ‘journal-content’ (Vorgabe: ‘#f’)
          Wie in den Aufzeichnungen die Zone und Änderungen daran
          gespeichert werden sollen. Mögliche Werte sind ‘'none’, um
          keine Aufzeichnungen zu führen, ‘'changes’, um Änderungen zu
          speichern, und ‘'all’, wodurch der gesamte Inhalt gespeichert
          wird. Für ‘#f’ wird dieser Wert nicht gesetzt, so dass der in
          Knot voreingestellte Wert benutzt wird.

     ‘max-journal-usage’ (Vorgabe: ‘#f’)
          Die maximale Größe, die Aufzeichnungen für die
          Wiederherstellbarkeit („Journal“) auf der Platte einnehmen
          können. Für ‘#f’ wird dieser Wert nicht gesetzt, so dass der
          in Knot voreingestellte Wert benutzt wird.

     ‘max-journal-depth’ (Vorgabe: ‘#f’)
          Wie viele Aufzeichnungen höchstens im Änderungsverlauf
          gespeichert werden. Für ‘#f’ wird dieser Wert nicht gesetzt,
          so dass der in Knot voreingestellte Wert benutzt wird.

     ‘max-zone-size’ (Vorgabe: ‘#f’)
          Die maximale Größe der Zonendatei. Diese Beschränkung wird auf
          eingehende Übertragungen und Aktualisierungen angewandt. Für
          ‘#f’ wird dieser Wert nicht gesetzt, so dass der in Knot
          voreingestellte Wert benutzt wird.

     ‘dnssec-policy’ (Vorgabe: ‘#f’)
          Ein Verweis auf ein ‘knot-policy-configuration’-Verbundsobjekt
          oder der besondere Name ‘"default"’, um die Voreinstellung von
          Knot zu verwenden. Wenn dies als der Wert ‘#f’ angegeben
          wurde, findet in dieser Zone kein Signieren mit DNSSEC statt.

     ‘serial-policy’ (Vorgabe: ‘'increment’)
          Eine Richtlinie; entweder ‘'increment’ (Seriennummer
          hochzählen) oder ‘'unixtime’ (Unix-Zeitstempel verwenden).

 -- Datentyp: knot-configuration
     Datentyp, der die Konfiguration von Knot repräsentiert. Dieser Typ
     verfügt über die folgenden Parameter:

     ‘knot’ (Vorgabe: ‘knot’)
          Das Knot-Paket.

     ‘run-directory’ (Vorgabe: ‘"/var/run/knot"’)
          Das Laufzeit-Verzeichnis („run“-Verzeichnis). In diesem
          Verzeichnis werden die PID-Datei mit dem Prozessidentifikator
          und Sockets gespeichert.

     ‘includes’ (Vorgabe: ‘'()’)
          Eine flache Liste von Zeichenketten oder dateiartigen
          Objekten, die oben in der Konfigurationsdatei eingebunden
          werden müssen.

          Hiermit können Geheimnisse abseits von Guix’
          Zuständigkeitsbereich gespeichert werden. Zum Beispiel können
          Sie geheime Schlüssel so in einer externen Datei speichern,
          die nicht von Guix verwaltet und daher auch nicht von jedem in
          ‘/gnu/store’ ausgelesen werden kann — Sie können etwa Ihre
          geheime Schlüsselkonfiguration in ‘/etc/knot/secrets.conf’
          speichern und diese Datei dann zu Ihrer ‘includes’-Liste
          hinzufügen.

          Sie können mit dem Schlüsselverwaltungsprogramm ‘keymgr’ aus
          dem Knot-Paket einen geheimen TSIG-Schlüssel erzeugen lassen
          (für ‘nsupdate’ und Zonentransfers). Beachten Sie, dass das
          Paket _nicht_ automatisch durch den Dienst installiert wird.
          Das folgende Beispiel zeigt, wie man einen neuen
          TSIG-Schlüssel erzeugen lässt:

               keymgr -t meingeheimnis > /etc/knot/secrets.conf
               chmod 600 /etc/knot/secrets.conf

          Außerdem sollten Sie bedenken, dass der erzeugte Schlüssel den
          Namen MEINGEHEIMNIS bekommt, dieser Name also auch im KEY-Feld
          des ‘knot-acl-configuration’-Verbundsobjekts und an anderen
          Stellen verwendet werden muss, wo auf den Schlüssel verwiesen
          wird.

          Sie können die ‘includes’ auch benutzen, um von der
          Guix-Schnittstelle nicht unterstützte Einstellungen
          festzulegen.

     ‘listen-v4’ (Vorgabe: ‘"0.0.0.0"’)
          Eine IP-Adresse, auf der gelauscht werden soll.

     ‘listen-v6’ (Vorgabe: ‘"::"’)
          Eine IP-Adresse, auf der gelauscht werden soll.

     ‘listen-port’ (Vorgabe: ‘53’)
          Ein Port, auf dem gelauscht werden soll.

     ‘keys’ (Vorgabe: ‘'()’)
          Die Liste der ‘knot-key-configuration’-Objekte, die von dieser
          Konfiguration benutzt werden sollen.

     ‘acls’ (Vorgabe: ‘'()’)
          Die Liste der ‘knot-acl-configuration’-Objekte, die von dieser
          Konfiguration benutzt werden sollen.

     ‘remotes’ (Vorgabe: ‘'()’)
          Die Liste der ‘knot-remote-configuration’-Objekte, die von
          dieser Konfiguration benutzt werden sollen.

     ‘zones’ (Vorgabe: ‘'()’)
          Die Liste der ‘knot-zone-configuration’-Objekte, die von
          dieser Konfiguration benutzt werden sollen.

Knot-Resolver-Dienst
....................

 -- Scheme-Variable: knot-resolver-service-type
     Dies ist der Diensttyp des Knot-Resolver-Dienstes, dessen Wert ein
     ‘knot-resolver-configuration’-Objekt wie in diesem Beispiel sein
     sollte:

          (service knot-resolver-service-type
                   (knot-resolver-configuration
                     (kresd-config-file (plain-file "kresd.conf" "
          net.listen('192.168.0.1', 5353)
          user('knot-resolver', 'knot-resolver')
          modules = { 'hints > iterate', 'stats', 'predict' }
          cache.size = 100 * MB
          "))))

     Weitere Informationen finden Sie in seinem Handbuch
     (https://knot-resolver.readthedocs.org/en/stable/daemon.html#configuration).

 -- Datentyp: knot-resolver-configuration
     Der Datentyp, der die Konfiguration von knot-resolver
     repräsentiert.

     ‘package’ (Vorgabe: KNOT-RESOLVER)
          Das Paketobjekt des Knot-DNS-Resolvers.

     ‘kresd-config-file’ (Vorgabe: %kresd.conf)
          Dateiartiges Objekt der zu nutzenden
          kresd-Konfigurationsdatei. Nach Vorgabe lauscht der
          Knot-Resolver auf ‘127.0.0.1’ und ‘::1’.

     ‘garbage-collection-interval’ (Vorgabe: 1000)
          Wie viele Millisekunden ‘kres-cache-gc’ zwischen Bereinigungen
          seines Zwischenspeichers wartet.

Dnsmasq-Dienst
..............

 -- Scheme-Variable: dnsmasq-service-type
     Dies ist der Diensttyp des dnsmasq-Dienstes, dessen Wert ein
     ‘dnsmasq-configuration’-Objekt wie in diesem Beispiel sein sollte:

          (service dnsmasq-service-type
                   (dnsmasq-configuration
                     (no-resolv? #t)
                     (servers '("192.168.1.1"))))

 -- Datentyp: dnsmasq-configuration
     Repräsentiert die dnsmasq-Konfiguration.

     ‘package’ (Vorgabe: DNSMASQ)
          Paketobjekt des dnsmasq-Servers.

     ‘no-hosts?’ (Vorgabe: ‘#f’)
          Ist es auf wahr gesetzt, werden keine Rechnernamen
          („Hostnames“) aus /etc/hosts ausgelesen.

     ‘port’ (Vorgabe: ‘53’)
          Der Port, auf dem gelauscht werden soll. Wird dies auf null
          gesetzt, werden keinerlei DNS-Anfragen beantwortet und es
          bleiben nur DHCP- und/oder TFTP-Funktionen.

     ‘local-service?’ (Vorgabe: ‘#t’)
          DNS-Anfragen nur von Rechnern akzeptieren, deren Adresse auf
          einem lokalen Subnetz liegt, d.h. einem Subnetz, für dem auf
          dem Server eine Schnittstelle existiert.

     ‘listen-addresses’ (Vorgabe: ‘'()’)
          Lässt auf den angegebenen IP-Adressen lauschen.

     ‘resolv-file’ (Vorgabe: ‘"/etc/resolv.conf"’)
          Aus welcher Datei die IP-Adresse der zu verwendenden
          Namensserver gelesen werden sollen.

     ‘no-resolv?’ (Vorgabe: ‘#f’)
          Wenn es auf wahr steht, wird das RESOLV-FILE nicht gelesen.

     ‘servers’ (Vorgabe: ‘'()’)
          Geben Sie die IP-Adresse von anzufragenden Servern direkt an.

     ‘addresses’ (Vorgabe: ‘'()’)
          Geben Sie in jedem Eintrag eine IP-Adresse an, die für jeden
          Rechner mit einer der angegebenen Domains zurückgeliefert
          werden soll. Anfragen nach den Domains werden niemals
          weitergegeben, sondern werden immer mit der festgelegten
          IP-Adresse beantwortet.

          Dies ist nützlich, um für Rechnernamen lokale Umleitungen
          einzurichten, wie in diesem Beispiel:

               (service dnsmasq-service-type
                        (dnsmasq-configuration
                          (addresses
                            '(; Weiterleitung auf lokalen Webserver.
                              "/example.org/127.0.0.1"
                              ; Weiterleitung einer Subdomain auf eine bestimmte IP.
                              "/subdomain.example.org/192.168.1.42"))))

          Beachten Sie, dass die Regeln in ‘/etc/hosts’ Vorrang haben.

     ‘cache-size’ (Vorgabe: ‘150’)
          Bestimmt die Größe des Zwischenspeichers von dnsmasq. Wird die
          Zwischenspeichergröße auf null festgelegt, wird kein
          Zwischenspeicher benutzt.

     ‘negative-cache?’ (Vorgabe: ‘#t’)
          Ist dies auf falsch gesetzt, werden Negativergebnisse nicht
          zwischengespeichert.

     ‘tftp-enable?’ (Vorgabe: ‘#f’)
          Ob der eingebaute TFTP-Server aktiviert werden soll.

     ‘tftp-no-fail?’ (Vorgabe: ‘#f’)
          Wenn dies wahr ist und der TFTP-Server nicht gestartet werden
          kann, gilt dnsmasq trotzdem _nicht_ als fehlgeschlagen.

     ‘tftp-single-port?’ (Vorgabe: ‘#f’)
          Ob nur ein einzelner Port für TFTP benutzt werden soll.

     ‘tftp-secure?’ (Vorgabe: ‘#f’)
          Wenn dies wahr ist, kann nur auf solche Dateien zugegriffen
          werden, die dem Benutzerkonto gehören, das den dnsmasq-Prozess
          ausführt.

          Wird dnsmasq durch den Administratornutzer root ausgeführt,
          gelten andere Regeln: ‘tftp-secure?’ wirkt sich nicht aus,
          aber es kann nur auf Dateien zugegriffen werden, auf die jeder
          Benutzer zugreifen darf (das „world-readable bit“ ist
          gesetzt).

     ‘tftp-max’ (Vorgabe: ‘#f’)
          Wenn dies gesetzt ist, gibt es die Maximalzahl gleichzeitig
          zugelassener Verbindungen an.

     ‘tftp-mtu’ (Vorgabe: ‘#f’)
          Wenn es gesetzt ist, gibt es die MTU für TFTP-Pakete an, also
          die Maximalgröße für Netzwerkschnittstellen.

     ‘tftp-no-blocksize?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der TFTP-Server die Blockgröße _nicht_
          mit dem Client aushandeln.

     ‘tftp-lowercase?’ (Vorgabe: ‘#f’)
          Ob alle Dateinamen in TFTP-Anfragen in Kleinbuchstaben
          umgesetzt werden sollen.

     ‘tftp-port-range’ (Vorgabe: ‘#f’)
          Wenn es gesetzt ist, wird jeder dynamische Port (einer pro
          Client) aus dem angegebenen Bereich (‘"<von>,<bis>"’)
          genommen.

     ‘tftp-root’ (Vorgabe: ‘/var/empty,lo’)
          Relativ zu welchem Verzeichnis die Dateien für die Übertragung
          per TFTP gesucht werden. Wenn dies gesetzt ist, werden
          TFTP-Pfade, die ‘..’ enthalten, abgelehnt, damit Clients
          keinen Zugriff auf Dateien außerhalb des angegebenen
          Wurzelverzeichnisses haben. Absolute Pfade (solche, die mit
          ‘/’ beginnen) sind erlaubt, aber sie müssen in der TFTP-Root
          liegen. Wenn das optionale Argument ‘interface’ angegeben
          wird, wird das Verzeichnis nur für TFTP-Anfragen über diese
          Schnittstelle benutzt.

     ‘tftp-unique-root’ (Vorgabe: ‘#f’)
          Wenn es gesetzt ist, wird entsprechend die IP- oder
          Hardware-Adresse des TFTP-Clients als eine Pfadkomponente ans
          Ende der TFTP-Root angehängt. Das ist nur gültig, wenn eine
          TFTP-Root gesetzt ist und das Verzeichnis existiert. Die
          Voreinstellung ist, die IP-Adresse anzuhängen (wie üblich als
          punktgetrenntes Quadrupel).

          Ist zum Beispiel ‘tftp-root’ ‘/tftp’ und fragt Client
          ‘1.2.3.4’ die Datei ‘meinedatei’ an, dann wird effektiv als
          Pfad ‘/tftp/1.2.3.4/meinedatei’ abgerufen, wenn
          ‘/tftp/1.2.3.4’ existiert, oder ‘/tftp/meinedatei’
          andernfalls. Wird ‘=mac’ angegeben, wird stattdessen die
          MAC-Adresse angehängt (in Kleinbuchstaben und durch Striche
          getrennt, aufgefüllt mit der Ziffer null), z.B.
          ‘01-02-03-04-aa-bb’. Beachten Sie, dass MAC-Adressen nur
          aufgelöst werden können, wenn sich der Client im lokalen
          Netzwerk befindet oder von dnsmasq eine Adresse per DHCP
          zugewiesen bekommen hat.

ddclient-Dienst
...............

Der im Folgenden beschriebene ddclient-Dienst führt den ddclient-Daemon
aus, der dafür sorgt, dass DNS-Einträge für Dienstanbieter wie Dyn
(https://dyn.com/dns/) automatisch aktualisiert werden.

   Das folgende Beispiel zeigt, wie man den Dienst mit seiner
Vorgabekonfiguration instanziiert:

     (service ddclient-service-type)

   Beachten Sie, dass der ddclient auf Zugangsdaten zugreifen muss, die
in einer “Geheimnisdatei” („Secret File“) stehen; nach Vorgabe wird sie
in ‘/etc/ddclient/secrets’ gesucht (siehe ‘secret-file’ unten). Es wird
erwartet, dass Sie diese Datei manuell erstellen, ohne Guix dafür zu
benutzen (theoretisch _könnten_ Sie die Datei zu einem Teil Ihrer
Dienstkonfiguration machen, indem Sie z.B. ‘plain-file’ benutzen, aber
dann könnte jeder über ‘/gnu/store’ ihren Inhalt einsehen). Siehe die
Beispiele im Verzeichnis ‘share/ddclient’ des ‘ddclient’-Pakets.

   Verfügbare ‘ddclient-configuration’-Felder sind:

 -- ‘ddclient-configuration’-Parameter: „package“ ddclient
     Das ddclient-Paket.

 -- ‘ddclient-configuration’-Parameter: Ganze-Zahl daemon
     Nach wie viel Zeit ddclient erneut versuchen wird, IP und
     Domain-Namen zu überprüfen.

     Die Vorgabe ist ‘300’.

 -- ‘ddclient-configuration’-Parameter: Boolescher-Ausdruck syslog
     Ob die Ausgabe an Syslog gehen soll.

     Die Vorgabe ist ‘#t’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette mail
     An welchen Benutzer Mitteilungen gemailt werden sollen.

     Die Vorgabe ist ‘"root"’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette mail-failure
     Den Nutzer per Mail bei fehlgeschlagenen Aktualisierungen
     benachrichtigen.

     Die Vorgabe ist ‘"root"’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette pid
     PID-Datei für den ddclient.

     Die Vorgabe ist ‘"/var/run/ddclient/ddclient.pid"’.

 -- ‘ddclient-configuration’-Parameter: Boolescher-Ausdruck ssl
     SSL-Unterstützung aktivieren.

     Die Vorgabe ist ‘#t’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette user
     Gibt den Namen oder Identifikator des Benutzerkontos an, unter dem
     das ddclient-Programm laufen soll.

     Die Vorgabe ist ‘"ddclient"’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette group
     Die Gruppe des Benutzers, mit dem das ddclient-Programm läuft.

     Die Vorgabe ist ‘"ddclient"’.

 -- ‘ddclient-configuration’-Parameter: Zeichenkette secret-file
     Die Geheimnisdatei („Secret File“), die an die erzeugte
     ‘ddclient.conf’-Datei angehängt wird. Diese Datei enthält die
     Zugangsdaten, die ddclient benutzen soll. Es wird erwartet, dass
     Sie sie manuell erzeugen.

     Die Vorgabe ist ‘"/etc/ddclient/secrets.conf"’.

 -- ‘ddclient-configuration’-Parameter: Liste extra-options
     Zusätzliche Einstellungsoptionen, die an die ‘ddclient.conf’-Datei
     angehängt werden.

     Die Vorgabe ist ‘()’.


File: guix.de.info,  Node: VPN-Dienste,  Next: Network File System,  Prev: DNS-Dienste,  Up: Dienste

10.8.21 VPN-Dienste
-------------------

Das Modul ‘(gnu services vpn)’ stellt Dienste zur Verfügung, die mit
“Virtual Private Networks” (VPNs) zu tun haben.

OpenVPN
.......

Hiermit wird ein _Client_-Dienst angeboten, mit dem sich Ihre Maschine
mit einem VPN verbinden kann, sowie ein _Server_-Dienst, mit dem Sie auf
Ihrer Maschine ein VPN betreiben können.

 -- Scheme-Prozedur: openvpn-client-service [#:config
          (openvpn-client-configuration)]

     Liefert einen Dienst, der den VPN-Daemon ‘openvpn’ als Client
     ausführt.

 -- Scheme-Prozedur: openvpn-server-service [#:config
          (openvpn-server-configuration)]

     Liefert einen Dienst, der den VPN-Daemon ‘openvpn’ als Server
     ausführt.

     Beide können zeitgleich laufen gelassen werden.

   Verfügbare ‘openvpn-client-configuration’-Felder sind:

 -- ‘openvpn-client-configuration’-Parameter: „package“ openvpn
     Das OpenVPN-Paket.

 -- ‘openvpn-client-configuration’-Parameter: Zeichenkette pid-file
     Die Datei für den Prozessidentifikator („PID“) von OpenVPN.

     Die Vorgabe ist ‘"/var/run/openvpn/openvpn.pid"’.

 -- ‘openvpn-client-configuration’-Parameter: Protokoll proto
     Das Protokoll (UDP oder TCP), das benutzt werden soll, um einen
     Kommunikationskanal zwischen Clients und Servern herzustellen.

     Die Vorgabe ist ‘udp’.

 -- ‘openvpn-client-configuration’-Parameter: Gerät dev
     Der Gerätetyp, mit dem die VPN-Verbindung repräsentiert werden
     soll.

     Die Vorgabe ist ‘tun’.

   Wenn Ihnen einige dieser Dateien fehlen (etwa weil Sie stattdessen
Benutzername und Passwort benutzen), dann können Sie jedes der folgenden
drei Felder unterdrücken, indem Sie dafür ‘'disabled’ angeben.

 -- ‘openvpn-client-configuration’-Parameter: Vielleicht-Zeichenkette ca
     Die Zertifikatsautorität, mit der Verbindungen geprüft werden.

     Die Vorgabe ist ‘"/etc/openvpn/ca.crt"’.

 -- ‘openvpn-client-configuration’-Parameter: Vielleicht-Zeichenkette
          cert
     Das Zertifikat der Maschine, auf der der Daemon läuft. Es sollte
     von der in ‘ca’ angegebenen Zertifikatsautorität signiert sein.

     Die Vorgabe ist ‘"/etc/openvpn/client.crt"’.

 -- ‘openvpn-client-configuration’-Parameter: Vielleicht-Zeichenkette
          key
     Der Schlüssel der Maschine, auf der der Daemon läuft. Er muss der
     Schlüssel zum in ‘cert’ angegebenen Zertifikat sein.

     Die Vorgabe ist ‘"/etc/openvpn/client.key"’.

 -- ‘openvpn-client-configuration’-Parameter: Boolescher-Ausdruck
          comp-lzo?
     Ob der Kompressionsalgorithmus lzo benutzt werden soll.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-client-configuration’-Parameter: Boolescher-Ausdruck
          persist-key?
     Die Schlüsseldateien nach Auftreten von SIGUSR1 oder –ping-restart
     _nicht_ erneut einlesen.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-client-configuration’-Parameter: Boolescher-Ausdruck
          persist-tun?
     Nach dem Auftreten von SIGUSR1 oder –ping-restart TUN/TAP-Geräte
     _nicht_ schließen und wieder öffnen und auch keine
     Start-/Stop-Skripte ausführen.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-client-configuration’-Parameter: Boolescher-Ausdruck
          fast-io?
     (Experimentell) Schreibzugriffe durch Datenverkehr bei TUN/TAP/UDP
     optimieren, indem ein Aufruf von poll/epoll/select vor der
     Schreiboperation eingespart wird.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-client-configuration’-Parameter: Zahl verbosity
     Ausführlichkeitsstufe.

     Die Vorgabe ist ‘3’.

 -- ‘openvpn-client-configuration’-Parameter:
          „tls-auth“-Clienteinstellung tls-auth
     Eine weitere HMAC-Authentifizierung zusätzlich zum
     TLS-Steuerungskanal einsetzen, um das System vor gezielten
     Überlastungsangriffen („Denial of Service“) zu schützen.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-client-configuration’-Parameter: Vielleicht-Zeichenkette
          auth-user-pass
     Beim Server eine Authentisierung über Benutzername/Passwort
     durchführen. Die Option nimmt eine Datei, welche Benutzername und
     Passwort auf zwei Zeilen enthält. Benutzen Sie dafür _kein_
     dateiartiges Objekt, weil es in den Store eingelagert würde, wo es
     jeder Benutzer einsehen könnte.

     Der Vorgabewert ist ‘'disabled’ (d.h. deaktiviert).

 -- ‘openvpn-client-configuration’-Parameter: Schlüsselprüfung
          verify-key-usage?
     Ob sichergestellt werden soll, dass das Server-Zertifikat auch über
     eine Erweiterung („Extension“) verfügt, dass es für die Nutzung als
     Server gültig ist.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-client-configuration’-Parameter: bind bind?
     Ob an immer dieselbe, feste lokale Portnummer gebunden wird.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-client-configuration’-Parameter: Erneut-Auflösen
          resolv-retry?
     Ob, wenn die Server-Adresse nicht aufgelöst werden konnte, die
     Auflösung erneut versucht wird.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-client-configuration’-Parameter:
          „openvpn-remote-configuration“-Liste remote
     Eine Liste entfernter Server, mit denen eine Verbindung hergestellt
     werden soll.

     Die Vorgabe ist ‘()’.

     Verfügbare ‘openvpn-remote-configuration’-Felder sind:

      -- ‘openvpn-remote-configuration’-Parameter: Zeichenkette name
          Der Servername.

          Die Vorgabe ist ‘"my-server"’.

      -- ‘openvpn-remote-configuration’-Parameter: Zahl port
          Die Portnummer, auf der der Server lauscht.

          Die Vorgabe ist ‘1194’.

   Verfügbare ‘openvpn-server-configuration’-Felder sind:

 -- ‘openvpn-server-configuration’-Parameter: „package“ openvpn
     Das OpenVPN-Paket.

 -- ‘openvpn-server-configuration’-Parameter: Zeichenkette pid-file
     Die Datei für den Prozessidentifikator („PID“) von OpenVPN.

     Die Vorgabe ist ‘"/var/run/openvpn/openvpn.pid"’.

 -- ‘openvpn-server-configuration’-Parameter: Protokoll proto
     Das Protokoll (UDP oder TCP), das benutzt werden soll, um einen
     Kommunikationskanal zwischen Clients und Servern herzustellen.

     Die Vorgabe ist ‘udp’.

 -- ‘openvpn-server-configuration’-Parameter: Gerät dev
     Der Gerätetyp, mit dem die VPN-Verbindung repräsentiert werden
     soll.

     Die Vorgabe ist ‘tun’.

   Wenn Ihnen einige dieser Dateien fehlen (etwa weil Sie stattdessen
Benutzername und Passwort benutzen), dann können Sie jedes der folgenden
drei Felder unterdrücken, indem Sie dafür ‘'disabled’ angeben.

 -- ‘openvpn-server-configuration’-Parameter: Vielleicht-Zeichenkette ca
     Die Zertifikatsautorität, mit der Verbindungen geprüft werden.

     Die Vorgabe ist ‘"/etc/openvpn/ca.crt"’.

 -- ‘openvpn-server-configuration’-Parameter: Vielleicht-Zeichenkette
          cert
     Das Zertifikat der Maschine, auf der der Daemon läuft. Es sollte
     von der in ‘ca’ angegebenen Zertifikatsautorität signiert sein.

     Die Vorgabe ist ‘"/etc/openvpn/client.crt"’.

 -- ‘openvpn-server-configuration’-Parameter: Vielleicht-Zeichenkette
          key
     Der Schlüssel der Maschine, auf der der Daemon läuft. Er muss der
     Schlüssel zum in ‘cert’ angegebenen Zertifikat sein.

     Die Vorgabe ist ‘"/etc/openvpn/client.key"’.

 -- ‘openvpn-server-configuration’-Parameter: Boolescher-Ausdruck
          comp-lzo?
     Ob der Kompressionsalgorithmus lzo benutzt werden soll.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-server-configuration’-Parameter: Boolescher-Ausdruck
          persist-key?
     Die Schlüsseldateien nach Auftreten von SIGUSR1 oder –ping-restart
     _nicht_ erneut einlesen.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-server-configuration’-Parameter: Boolescher-Ausdruck
          persist-tun?
     Nach dem Auftreten von SIGUSR1 oder –ping-restart TUN/TAP-Geräte
     _nicht_ schließen und wieder öffnen und auch keine
     Start-/Stop-Skripte ausführen.

     Die Vorgabe ist ‘#t’.

 -- ‘openvpn-server-configuration’-Parameter: Boolescher-Ausdruck
          fast-io?
     (Experimentell) Schreibzugriffe durch Datenverkehr bei TUN/TAP/UDP
     optimieren, indem ein Aufruf von poll/epoll/select vor der
     Schreiboperation eingespart wird.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-server-configuration’-Parameter: Zahl verbosity
     Ausführlichkeitsstufe.

     Die Vorgabe ist ‘3’.

 -- ‘openvpn-server-configuration’-Parameter:
          „tls-auth“-Servereinstellung tls-auth
     Eine weitere HMAC-Authentifizierung zusätzlich zum
     TLS-Steuerungskanal einsetzen, um das System vor gezielten
     Überlastungsangriffen („Denial of Service“) zu schützen.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-server-configuration’-Parameter: Zahl port
     Gibt die Portnummer an, auf der der Server lauscht.

     Die Vorgabe ist ‘1194’.

 -- ‘openvpn-server-configuration’-Parameter: IP-und-Maske server
     Eine IP-Adresse gefolgt von deren Maske, die das Subnetz im
     virtuellen Netzwerk angibt.

     Die Vorgabe ist ‘"10.8.0.0 255.255.255.0"’.

 -- ‘openvpn-server-configuration’-Parameter: cidr6 server-ipv6
     Eine CIDR-Notation, mit der das IPv6-Subnetz im virtuellen Netzwerk
     angegeben wird.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-server-configuration’-Parameter: Zeichenkette dh
     Die Datei mit den Diffie-Hellman-Parametern.

     Die Vorgabe ist ‘"/etc/openvpn/dh2048.pem"’.

 -- ‘openvpn-server-configuration’-Parameter: Zeichenkette
          ifconfig-pool-persist
     Die Datei, in der Client-IPs eingetragen werden.

     Die Vorgabe ist ‘"/etc/openvpn/ipp.txt"’.

 -- ‘openvpn-server-configuration’-Parameter: Zugang redirect-gateway?
     Wenn dies auf wahr steht, fungiert der Server als Zugang
     („Gateway“) für seine Clients.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-server-configuration’-Parameter: Boolescher-Ausdruck
          client-to-client?
     Wenn dies auf wahr steht, ist es zugelassen, dass Clients
     untereinander innerhalb des VPNs kommunizieren.

     Vorgegeben ist ‘#f’.

 -- ‘openvpn-server-configuration’-Parameter: Aufrechterhaltung
          keepalive
     Lässt ping-artige Nachrichtigen in beide Richtungen über die
     Leitung übertragen, damit beide Seiten bemerken, wenn der
     Kommunikationspartner offline geht. Für ‘keepalive’ muss ein Paar
     angegeben werden. Das erste Element ist die Periode, nach der das
     Pingsignal wieder gesendet werden soll, und das zweite ist eine
     Zeitbegrenzung, in der eines ankommen muss, damit die andere Seite
     nicht als offline gilt.

 -- ‘openvpn-server-configuration’-Parameter: Zahl max-clients
     Wie viele Clients es höchstens geben kann.

     Die Vorgabe ist ‘100’.

 -- ‘openvpn-server-configuration’-Parameter: Zeichenkette status
     Die Datei für einen Zustandsbericht („Status File“). Diese Datei
     enthält einen kurzen Bericht über die momentane Verbindung. Sie
     wird jede Minute gekürzt und neu geschrieben.

     Die Vorgabe ist ‘"/var/run/openvpn/status"’.

 -- ‘openvpn-server-configuration’-Parameter:
          „openvpn-ccd-configuration“-Liste client-config-dir
     Die Liste der Konfigurationen für einige Clients.

     Die Vorgabe ist ‘()’.

     Verfügbare ‘openvpn-ccd-configuration’-Felder sind:

      -- ‘openvpn-ccd-configuration’-Parameter: Zeichenkette name
          Der Client-Name.

          Die Vorgabe ist ‘"client"’.

      -- ‘openvpn-ccd-configuration’-Parameter: IP-und-Maske iroute
          Das eigene Netzwerk des Clients.

          Vorgegeben ist ‘#f’.

      -- ‘openvpn-ccd-configuration’-Parameter: IP-und-Maske
               ifconfig-push
          VPN-IP-Adresse des Clients.

          Vorgegeben ist ‘#f’.

Wireguard
.........

 -- Scheme-Variable: wireguard-service-type
     Ein Diensttyp für eine Schnittstelle über einen Wireguard-Tunnel.
     Sein Wert muss ein ‘wireguard-configuration’-Verbundsobjekt wie in
     diesem Beispiel sein:

          (service wireguard-service-type
                   (wireguard-configuration
                    (peers
                     (list
                      (wireguard-peer
                       (name "my-peer")
                       (endpoint "my.wireguard.com:51820")
                       (public-key "hzpKg9X1yqu1axN6iJp0mWf6BZGo8m1wteKwtTmDGF4=")
                       (allowed-ips '("10.0.0.2/32")))))))

 -- Datentyp: wireguard-configuration
     Der Datentyp, der die Konfiguration des Wireguard-Dienstes
     repräsentiert.

     ‘wireguard’
          Das Wireguard-Paket, was für diesen Dienst benutzt werden
          soll.

     ‘interface’ (Vorgabe: ‘"wg0"’)
          Der Name der VPN-Schnittstelle.

     ‘addresses’ (Vorgabe: ‘'("10.0.0.1/32")’)
          Welche IP-Adressen obiger Schnittstelle zugeordnet werden.

     ‘private-key’ (Vorgabe: ‘"/etc/wireguard/private.key"’)
          Die Datei mit dem privaten Schlüssel für die Schnittstelle.
          Wenn die angegebene Datei nicht existiert, wird sie
          automatisch erzeugt.

     ‘peers’ (Vorgabe: ‘'()’)
          Die zugelassenen Netzwerkteilnehmer auf dieser Schnittstelle.
          Dies ist eine Liste von WIREGUARD-PEER-Verbundsobjekten.

 -- Datentyp: wireguard-peer
     Der Datentyp, der einen an die angegebene Schnittstelle
     angeschlossenen Netzwerkteilnehmer („Peer“) repräsentiert.

     ‘name’
          Die Bezeichnung für den Netzwerkteilnehmer.

     ‘endpoint’ (Vorgabe: ‘#f’)
          Optional der Endpunkt des Netzwerkteilnehmers, etwa
          ‘"demo.wireguard.com:51820"’.

     ‘public-key’
          Der öffentliche Schlüssel des Netzwerkteilnehmers, dargestellt
          als eine base64-kodierte Zeichenkette.

     ‘allowed-ips’
          Eine Liste der IP-Adressen, von denen für diesen
          Netzwerkteilnehmer eingehende Kommunikation zugelassen wird
          und an die ausgehende Kommunikation für diesen
          Netzwerkteilnehmer gerichtet wird.


File: guix.de.info,  Node: Network File System,  Next: Kontinuierliche Integration,  Prev: VPN-Dienste,  Up: Dienste

10.8.22 Network File System
---------------------------

Das Modul ‘(gnu services nfs)’ stellt die folgenden Dienste zur
Verfügung, die meistens dazu benutzt werden, Verzeichnisbäume als
Netzwerkdateisysteme, englisch “Network File Systems” (NFS), einzubinden
oder an andere zu exportieren.

   Obwohl man auch die einzelnen Komponenten eines
Network-File-System-Dienstes separat einrichten kann, raten wir dazu,
einen NFS-Server mittels ‘nfs-service-type’ zu konfigurieren.

NFS-Dienst
..........

Der NFS-Dienst sorgt dafür, dass alle NFS-Komponentendienste, die
Konfiguration des NFS-Kernels und Dateisysteme eingerichtet werden, und
er installiert an den von NFS erwarteten Orten Konfigurationsdateien.

 -- Scheme-Variable: nfs-service-type
     Ein Diensttyp für einen vollständigen NFS-Server.

 -- Datentyp: nfs-configuration
     Dieser Datentyp repräsentiert die Konfiguration des NFS-Dienstes
     und all seiner Subsysteme.

     Er hat folgende Parameter:
     ‘nfs-utils’ (Vorgabe: ‘nfs-utils’)
          Das nfs-utils-Paket, was benutzt werden soll.

     ‘nfs-versions’ (Vorgabe: ‘'("4.2" "4.1" "4.0")’)
          Wenn eine Liste von Zeichenketten angegeben wird, beschränkt
          sich der ‘rpc.nfsd’-Daemon auf die Unterstützung der
          angegebenen Versionen des NFS-Protokolls.

     ‘exports’ (Vorgabe: ‘'()’)
          Diese Liste von Verzeichnissen soll der NFS-Server
          exportieren. Jeder Eintrag ist eine Liste, die zwei Elemente
          enthält: den Namen eines Verzeichnisses und eine Zeichenkette
          mit allen Optionen. Ein Beispiel, wo das Verzeichnis ‘/export’
          an alle NFS-Clients nur mit Lesezugriff freigegeben wird,
          sieht so aus:

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

     ‘rpcmountd-port’ (Vorgabe: ‘#f’)
          Welchen Netzwerk-Port der ‘rpc.mountd’-Daemon benutzen soll.

     ‘rpcstatd-port’ (Vorgabe: ‘#f’)
          Welchen Netzwerk-Port der ‘rpc.statd’-Daemon benutzen soll.

     ‘rpcbind’ (Vorgabe: ‘rpcbind’)
          Das rpcbind-Paket, das benutzt werden soll.

     ‘idmap-domain’ (Vorgabe: ‘"localdomain"’)
          Der lokale NFSv4-Domainname.

     ‘nfsd-port’ (Vorgabe: ‘2049’)
          Welchen Netzwerk-Port der ‘nfsd’-Daemon benutzen soll.

     ‘nfsd-threads’ (Vorgabe: ‘8’)
          Wie viele Threads der ‘rpc.statd’-Daemon benutzen soll.

     ‘nfsd-tcp?’ (Vorgabe: ‘#t’)
          Ob der ‘nfsd’-Daemon auf einem TCP-Socket lauschen soll.

     ‘nfsd-udp?’ (Vorgabe: ‘#f’)
          Ob der ‘nfsd’-Daemon auf einem UDP-Socket lauschen soll.

     ‘pipefs-directory’ (Vorgabe: ‘"/var/lib/nfs/rpc_pipefs"’)
          Das Verzeichnis, unter dem das Pipefs-Dateisystem eingebunden
          wurde.

     ‘debug’ (Vorgabe: ‘'()"’)
          Eine Liste der Subsysteme, für die Informationen zur
          Fehlersuche bereitgestellt werden sollen, als Liste von
          Symbolen. Jedes der folgenden Symbole ist gültig: ‘nfsd’,
          ‘nfs’, ‘rpc’, ‘idmap’, ‘statd’ oder ‘mountd’.

   Wenn Sie keinen vollständigen NFS-Dienst benötigen oder ihn selbst
einrichten wollen, können Sie stattdessen die im Folgenden
dokumentierten Komponentendienste benutzen.

RPC-Bind-Dienst
...............

Mit dem RPC-Bind-Dienst können Programmnummern auf universelle Adressen
abgebildet werden. Viele Dienste, die mit dem NFS zu tun haben, benutzen
diese Funktion, daher wird sie automatisch gestartet, sobald ein davon
abhängiger Dienst startet.

 -- Scheme-Variable: rpcbind-service-type
     Ein Diensttyp für den RPC-Portplaner-Daemon („Portmapper“).

 -- Datentyp: rpcbind-configuration
     Datentyp, der die Konfiguration des RPC-Bind-Dienstes
     repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
     ‘rpcbind’ (Vorgabe: ‘rpcbind’)
          Das rpcbind-Paket, das benutzt werden soll.

     ‘warm-start?’ (Vorgabe: ‘#t’)
          Wenn dieser Parameter ‘#t’ ist, wird der Daemon beim Starten
          eine Zustandsdatei („State File“) lesen, aus der er die von
          der vorherigen Instanz gespeicherten Zustandsinformationen
          wiederherstellt.

Pipefs-Pseudodateisystem
........................

Mit dem Pipefs-Dateisystem können NFS-bezogene Daten zwischen dem Kernel
und Programmen auf der Anwendungsebene (dem „User Space“) übertragen
werden.

 -- Scheme-Variable: pipefs-service-type
     Ein Diensttyp für das Pseudodateisystem „Pipefs“.

 -- Datentyp: pipefs-configuration
     Datentyp, der die Konfiguration des
     Pipefs-Pseudodateisystemdienstes repräsentiert. Dieser Typ verfügt
     über die folgenden Parameter:
     ‘mount-point’ (Vorgabe: ‘"/var/lib/nfs/rpc_pipefs"’)
          Das Verzeichnis, unter dem das Dateisystem eingebunden werden
          soll.

GSS-Daemon-Dienst
.................

Der Daemon des “Global Security System” (GSS) ermöglicht starke
Informationssicherheit für RPC-basierte Protokolle. Vor dem Austausch
von Anfragen über entfernte Prozeduraufrufe („Remote Procedure Calls“,
kurz RPC) muss ein RPC-Client einen Sicherheitskontext („Security
Context“) herstellen. Typischerweise wird dazu der ‘kinit’-Befehl von
Kerberos benutzt, oder er wird automatisch bei der Anmeldung über
PAM-Dienste hergestellt (siehe *note Kerberos-Dienste::).

 -- Scheme-Variable: gss-service-type
     Ein Diensttyp für den Daemon des Global Security System (GSS).

 -- Datentyp: gss-configuration
     Datentyp, der die Konfiguration des GSS-Daemon-Dienstes
     repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
     ‘nfs-utils’ (Vorgabe: ‘nfs-utils’)
          Das Paket, in dem der Befehl ‘rpc.gssd’ gesucht werden soll.

     ‘pipefs-directory’ (Vorgabe: ‘"/var/lib/nfs/rpc_pipefs"’)
          Das Verzeichnis, unter dem das Pipefs-Dateisystem eingebunden
          wurde.

IDMAP-Daemon-Dienst
...................

Der idmap-Daemon-Dienst ermöglicht eine Abbildung zwischen
Benutzeridentifikatoren und Benutzernamen. Er wird in der Regel dafür
benötigt, auf über NFSv4 eingebundene Dateisysteme zuzugreifen.

 -- Scheme-Variable: idmap-service-type
     Ein Diensttyp für den Identity-Mapper-Daemon (IDMAP).

 -- Datentyp: idmap-configuration
     Datentyp, der die Konfiguration des IDMAP-Daemon-Dienstes
     repräsentiert. Dieser Typ verfügt über die folgenden Parameter:
     ‘nfs-utils’ (Vorgabe: ‘nfs-utils’)
          Das Paket, in dem der Befehl ‘rpc.idmapd’ gesucht werden soll.

     ‘pipefs-directory’ (Vorgabe: ‘"/var/lib/nfs/rpc_pipefs"’)
          Das Verzeichnis, unter dem das Pipefs-Dateisystem eingebunden
          wurde.

     ‘domain’ (Vorgabe: ‘#f’)
          Der lokale NFSv4-Domain-Name. Für ihn muss eine Zeichenkette
          oder ‘#f’ angegeben werden. Wenn ‘#f’ angegeben wird, benutzt
          der Daemon den vollständigen Domain-Namen („Fully Qualified
          Domain Name“) des Rechners.

     ‘verbosity’ (Vorgabe: ‘0’)
          Die Ausführlichkeitsstufe des Daemons.


File: guix.de.info,  Node: Kontinuierliche Integration,  Next: Dienste zur Stromverbrauchsverwaltung,  Prev: Network File System,  Up: Dienste

10.8.23 Kontinuierliche Integration
-----------------------------------

Cuirass (https://guix.gnu.org/cuirass/) ist ein Werkzeug zur
kontinuierlichen Integration für Guix. Es kann sowohl bei der
Entwicklung helfen als auch beim Anbieten von Substituten für andere
(siehe *note Substitute::).

   Das Modul ‘(gnu services cuirass)’ stellt den folgenden Dienst zur
Verfügung:

 -- Scheme-Prozedur: cuirass-service-type
     Der Diensttyp des Cuirass-Dienstes. Sein Wert muss ein
     ‘cuirass-configuration’-Verbundsobjekt sein, wie im Folgenden
     beschrieben.

   Um Erstellungsaufträge („Build Jobs“) hinzuzufügen, müssen Sie sie im
‘specifications’-Feld der Konfiguration eintragen. Mit dem folgenden
Beispiel würden alle Pakete aus dem Kanal ‘my-channel’ erstellt.

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

   Um das Paket ‘linux-libre’, das im vorgegebenen Guix-Kanal definiert
ist, zu erstellen, schreibe man die folgende Konfiguration.

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

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

   Für eine Beschreibung der anderen Konfigurationsmöglichkeiten und des
Spezifikations-Verbundsobjektes selbst, siehe das *note
(cuirass)Specifications::.

   Die Informationen, die sich auf Erstellungsaufträge beziehen, werden
direkt in deren Spezifikation festgelegt, aber globale Einstellungen des
‘cuirass’-Prozesses sind über andere Felder der ‘cuirass-configuration’
zugänglich.

 -- Datentyp: cuirass-configuration
     Datentyp, der die Konfiguration von Cuirass repräsentiert.

     ‘cuirass’ (Vorgabe: ‘cuirass’)
          Das Cuirass-Paket, das benutzt werden soll.

     ‘log-file’ (Vorgabe: ‘"/var/log/cuirass.log"’)
          An welchen Ort die Protokolldatei geschrieben wird.

     ‘web-log-file’ (Vorgabe: ‘"/var/log/cuirass-web.log"’)
          An welchem Ort die Protokolldatei der Weboberfläche
          gespeichert wird.

     ‘cache-directory’ (Vorgabe: ‘"/var/cache/cuirass"’)
          Ort, wo Repositorys zwischengespeichert werden.

     ‘user’ (Vorgabe: ‘"cuirass"’)
          Besitzer des ‘cuirass’-Prozesses.

     ‘group’ (Vorgabe: ‘"cuirass"’)
          Gruppe des Besitzers des ‘cuirass’-Prozesses.

     ‘interval’ (Vorgabe: ‘60’)
          Anzahl der Sekunden, bevor ein Repository wieder neu geladen
          wird und danach Cuirass-Aufträge behandelt werden.

     ‘parameters’ (Vorgabe: ‘#f’)
          Parameter aus der angegebenen Parameterdatei lesen. Die
          unterstützten Parameter werden im *note (cuirass)Parameters::
          beschrieben.

     ‘remote-server’ (Vorgabe: ‘#f’)
          Ein ‘cuirass-remote-server-configuration’-Verbundsobjekt, um
          den Mechanismus für entfernte Erstellungen zu benutzen, oder
          ‘#f’, um den voreingestellten Erstellungsmechanismus zu
          benutzen.

     ‘database’ (Vorgabe: ‘"dbname=cuirass host=/var/run/postgresql"’)
          DATABASE als die Datenbank mit den Aufträgen und bisherigen
          Erstellungsergebnissen benutzen. Weil Cuirass als
          Datenbanktreiber PostgreSQL benutzt, muss DATABASE eine
          Zeichenkette sein wie ‘"dbname=cuirass host=localhost"’.

     ‘port’ (Vortrag: ‘8081’)
          Portnummer, die vom HTTP-Server benutzt wird.

     ‘host’ (Vorgabe: ‘"localhost"’)
          Auf der Netzwerkschnittstelle für den Rechnernamen HOST
          lauschen. Nach Vorgabe werden Verbindungen vom lokalen Rechner
          ‘localhost’ akzeptiert.

     ‘specifications’ (Vorgabe: ‘#~'()’)
          Ein G-Ausdruck (siehe *note G-Ausdrücke::), der zu einer Liste
          von Spezifikations-Verbundsobjekten ausgewertet wird.
          Spezifikations-Verbundsobjekte werden im *note
          (cuirass)Specifications:: beschrieben.

     ‘use-substitutes?’ (Vorgabe: ‘#f’)
          Hierdurch wird zugelassen, Substitute zu benutzen, damit
          _nicht_ jede Abhängigkeit eines Auftrags erst aus ihrem
          Quellcode heraus erstellt werden muss.

     ‘one-shot?’ (Vorgabe: ‘#f’)
          Spezifikationen nur einmal auswerten und Ableitungen nur
          einmal erstellen.

     ‘fallback?’ (Vorgabe: ‘#f’)
          Pakete lokal erstellen, wenn das Substituieren einer
          vorerstellten Binärdatei fehlschlägt.

     ‘extra-options’ (Vorgabe: ‘'()’)
          Zusätzliche Befehlszeilenoptionen, die beim Ausführen des
          Cuirass-Prozesses mitgegeben werden sollen.

Cuirass, entfernte Erstellung mit
.................................

Cuirass kennt zwei Mechanismen, wie damit Ableitungen erstellt werden
können.

   • Den lokalen Guix-Daemon benutzen. Dies ist der voreingestellte
     Erstellungsmechanismus. Sobald Erstellungsaufträge ausgewertet
     wurden, werden sie an den Guix-Daemon auf dem lokalen Rechner
     geschickt. Cuirass lauscht dann auf die Ausgabe des Guix-Daemons,
     um die verschiedenen Ereignisse bei der Erstellung zu erkennen.

   • Den Mechanismus für entfernte Erstellungen benutzen. Die
     Erstellungsaufträge werden _nicht_ beim lokalen Guix-Daemon
     eingereicht. Stattdessen teilt ein entfernter Server die
     Erstellungsanfragen den verbundenen entfernten Arbeitermaschinen
     zu, entsprechend ihren Erstellungsprioritäten.

   Um diesen Erstellungsmodus zu aktivieren, übergeben Sie ein
‘cuirass-remote-server-configuration’-Verbundsobjekt für das Argument
‘remote-server’ des ‘cuirass-configuration’-Verbundsobjektes. Der
‘cuirass-remote-server-configuration’-Verbund wird im Folgenden
beschrieben.

   Dieser Erstellungsmodus skaliert wesentlich besser als der
Vorgabemodus. Mit diesem Erstellungsmodus wird auch die Erstellungfarm
von GNU Guix auf <https://ci.guix.gnu.org> betrieben. Er sollte dann
bevorzugt werden, wenn Sie mit Cuirass eine große Anzahl von Paketen
erstellen möchten.

 -- Datentyp: cuirass-remote-server-configuration
     Der Datentyp, der die Konfiguration des
     Cuirass-„remote-server“-Prozesses repräsentiert.

     ‘backend-port’ (Vorgabe: ‘5555’)
          Der TCP-Port, um mit ‘remote-worker’-Prozessen mit ZMQ zu
          kommunizieren.

     ‘log-port’ (Vorgabe: ‘5556’)
          Der TCP-Port des Protokollservers.

     ‘publish-port’ (Vorgabe: ‘5557’)
          Der TCP-Port des „Publish“-Servers, um Substitute mit anderen
          zu teilen.

     ‘log-file’ (Vorgabe: ‘"/var/log/cuirass-remote-server.log"’)
          An welchen Ort die Protokolldatei geschrieben wird.

     ‘cache’ (Vorgabe: ‘"/var/cache/cuirass/remote"’)
          Im CACHE-Verzeichnis Erstellungsprotokolldateien speichern.

     ‘trigger-url’ (Vorgabe: ‘#f’)
          Sobald ein Substitut erfolgreich heruntergeladen wurde, wird
          dessen Einlagerung als Narinfo („bake the substitute“) auf
          TRIGGER-URL direkt ausgelöst.

     ‘public-key’
     ‘private-key’
          Die angegebenen DATEIen als das Paar aus öffentlichem und
          privatem Schlüssel zum Signieren veröffentlichter
          Store-Objekte benutzen.

   Mindestens eine entfernte Arbeitermaschine („remote worker“) muss auf
irgendeiner Maschine im lokalen Netzwerk gestartet werden, damit
tatsächlich Erstellungen durchgeführt werden und deren Status gemeldet
wird.

 -- Datentyp: cuirass-remote-worker-configuration
     Der Datentyp, der die Konfiguration des
     Cuirass-„remote-worker“-Prozesses repräsentiert.

     ‘cuirass’ (Vorgabe: ‘cuirass’)
          Das Cuirass-Paket, das benutzt werden soll.

     ‘workers’ (Vorgabe: ‘1’)
          WORKERS-viele parallele Arbeiterprozesse starten.

     ‘server’ (Vorgabe: ‘#f’)
          Keine Maschinen über Avahi ermitteln, sondern stattdessen eine
          Verbindung zum Server unter der in ‘server’ angegebenen
          IP-Adresse aufbauen.

     ‘systems’ (Vorgabe: ‘(list (%current-system))’)
          Nur Erstellungen für die in SYSTEMS angegebenen Systeme
          anfragen.

     ‘log-file’ (Vorgabe: ‘"/var/log/cuirass-remote-worker.log"’)
          An welchen Ort die Protokolldatei geschrieben wird.

     ‘publish-port’ (Vorgabe: ‘5558’)
          Der TCP-Port des „Publish“-Servers, um Substitute mit anderen
          zu teilen.

     ‘public-key’
     ‘private-key’
          Die angegebenen DATEIen als das Paar aus öffentlichem und
          privatem Schlüssel zum Signieren veröffentlichter
          Store-Objekte benutzen.

Laminar
.......

Laminar (https://laminar.ohwg.net/) ist ein sparsamer und modularer
Dienst zur Kontinuierlichen Integration. Statt einer Weboberfläche zur
Konfiguration werden versionskontrollierte Konfigurationsdateien und
Skripte verwendet.

   Laminar ermutigt dazu, bestehende Werkzeuge wie bash und cron zu
benutzen statt das Rad neu zu erfinden.

 -- Scheme-Prozedur: laminar-service-type
     Der Diensttyp des Laminar-Dienstes. Sein Wert muss ein
     ‘laminar-configuration’-Verbundsobjekt sein, wie im Folgenden
     beschrieben.

     Alle Konfigurationswerte haben bereits vorgegebene Einstellungen.
     Eine minimale Konfiguration, um Laminar aufzusetzen, sehen Sie
     unten. Nach Vorgabe läuft die Weboberfläche auf Port 8080.

          (service laminar-service-type)

 -- Datentyp: laminar-configuration
     Datentyp, der die Konfiguration von Laminar repräsentiert.

     ‘laminar’ (Vorgabe: ‘laminar’)
          Das Laminar-Paket, das benutzt werden soll.

     ‘home-directory’ (Vorgabe: ‘"/var/lib/laminar"’)
          Das Verzeichnis mit Auftragskonfigurationen und
          Verzeichnissen, in denen Aufträge ausgeführt werden
          („run“-Verzeichnissen).

     ‘bind-http’ (Vorgabe: ‘"*:8080"’)
          Die Netzwerkschnittstelle mit Port oder der Unix-Socket, wo
          laminard auf eingehende Verbindungen zur Web-Oberfläche
          lauschen soll.

     ‘bind-rpc’ (Vorgabe: ‘"unix-abstract:laminar"’)
          Die Netzwerkschnittstelle mit Port oder der Unix-Socket, wo
          laminard auf eingehende Befehle z.B. zum Auslösen einer
          Erstellung lauschen soll.

     ‘title’ (Vorgabe: ‘"Laminar"’)
          Der Seitentitel, der auf der Web-Oberfläche angezeigt wird.

     ‘keep-rundirs’ (Vorgabe: ‘0’)
          Setzen Sie dies auf eine ganze Zahl, die festlegt, wie viele
          Ausführungsverzeichnisse pro Auftrag vorgehalten werden. Die
          mit der niedrigsten Nummer werden gelöscht. Die Vorgabe ist 0,
          d.h. alle Ausführungsverzeichnisse werden sofort gelöscht.

     ‘archive-url’ (Vorgabe: ‘#f’)
          Die von laminard angebotene Weboberfläche wird aus dieser URL
          die Verweise auf Artefakte archivierter Aufträge
          zusammensetzen.

     ‘base-url’ (Vorgabe: ‘#f’)
          Was Laminar in Verweisen auf eigene Seiten als Basis-URL
          verwenden soll.


File: guix.de.info,  Node: Dienste zur Stromverbrauchsverwaltung,  Next: Audio-Dienste,  Prev: Kontinuierliche Integration,  Up: Dienste

10.8.24 Dienste zur Stromverbrauchsverwaltung
---------------------------------------------

TLP-Daemon
..........

Das Modul ‘(gnu services pm)’ stellt eine Guix-Dienstdefinition für das
Linux-Werkzeug TLP zur Stromverbrauchsverwaltung zur Verfügung.

   TLP macht mehrere Stromspar-Modi auf Anwendungsebene („User Space“)
und im Kernel verfügbar. Im Gegensatz zum ‘upower-service’ handelt es
sich um kein passives Werkzeug zur Überwachung, sondern TLP passt selbst
jedes Mal Einstellungen an, wenn eine neue Stromquelle erkannt wird.
Mehr Informationen finden Sie auf der TLP-Homepage
(https://linrunner.de/en/tlp/tlp.html).

 -- Scheme-Variable: tlp-service-type
     Der Diensttyp für das TLP-Werkzeug. In der Vorgabeeinstellung wird
     die Akkulaufzeit für die meisten Systeme optimiert, aber Sie können
     sie nach Belieben anpassen, indem Sie eine gültige
     ‘tlp-configuration’ hinzufügen:
          (service tlp-service-type
                   (tlp-configuration
                    (cpu-scaling-governor-on-ac (list "performance"))
                    (sched-powersave-on-bat? #t)))

   Im Folgenden ist jeder Parameterdefinition ihr Typ vorangestellt. Zum
Beispiel bedeutet ‘Boolescher-Ausdruck foo’, dass der Parameter ‘foo’
als boolescher Ausdruck festgelegt werden sollte. Typen, die mit
‘Vielleicht-’ beginnen, bezeichnen Parameter, die nicht in der
TLP-Konfigurationsdatei vorkommen, wenn ‘'disabled’ als ihr Wert
angegeben wurde.

   Verfügbare ‘tlp-configuration’-Felder sind:

 -- ‘tlp-configuration’-Parameter: „package“ tlp
     Das TLP-Paket.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck tlp-enable?
     Setzen Sie dies auf wahr, wenn Sie TLP aktivieren möchten.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette tlp-default-mode
     Der vorgegebene Modus, wenn keine Stromversorgung gefunden werden
     kann. Angegeben werden können AC (am Stromnetz) und BAT
     (Batterie/Akku).

     Die Vorgabe ist ‘"AC"’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          disk-idle-secs-on-ac
     Die Anzahl an Sekunden, die der Linux-Kernel warten muss, bis er
     sich mit dem Plattenspeicher synchronisiert, wenn die
     Stromversorgung auf AC steht.

     Die Vorgabe ist ‘0’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          disk-idle-secs-on-bat
     Wie ‘disk-idle-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘2’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          max-lost-work-secs-on-ac
     Periodizität, mit der im Zwischenspeicher geänderte Speicherseiten
     („Dirty Pages“) synchronisiert werden („Cache Flush“), ausgedrückt
     in Sekunden.

     Die Vorgabe ist ‘15’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          max-lost-work-secs-on-bat
     Wie ‘max-lost-work-secs-on-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘60’.

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          cpu-scaling-governor-on-ac
     Regulator der Frequenzskalierung der CPUs („Frequency Scaling
     Governor“) im AC-Modus. Beim intel_pstate-Treiber stehen powersave
     (stromsparend) und performance (leistungsfähig) zur Auswahl. Beim
     acpi-cpufreq-Treiber stehen ondemand, powersave, performance und
     conservative zur Auswahl.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          cpu-scaling-governor-on-bat
     Wie ‘cpu-scaling-governor-on-ac’, aber für den BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-scaling-min-freq-on-ac
     Legt die minimale verfügbare Frequenz für den Skalierungsregulator
     im AC-Modus fest.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-scaling-max-freq-on-ac
     Legt die maximale verfügbare Frequenz für den Skalierungsregulator
     im AC-Modus fest.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-scaling-min-freq-on-bat
     Legt die minimale verfügbare Frequenz für den Skalierungsregulator
     im BAT-Modus fest.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-scaling-max-freq-on-bat
     Legt die maximale verfügbare Frequenz für den Skalierungsregulator
     im BAT-Modus fest.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-min-perf-on-ac
     Beschränkt den minimalen Leistungszustand („P-State“), um die
     Stromverteilung („Power Dissipation“) der CPU im AC-Modus zu
     regulieren. Werte können als Prozentsatz bezüglich der verfügbaren
     Leistung angegeben werden.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-max-perf-on-ac
     Beschränkt den maximalen Leistungszustand („P-State“), um die
     Stromverteilung („Power Dissipation“) der CPU im AC-Modus zu
     regulieren. Werte können als Prozentsatz bezüglich der verfügbaren
     Leistung angegeben werden.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-min-perf-on-bat
     Wie ‘cpu-min-perf-on-ac’ im BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Nichtnegative-ganze-Zahl
          cpu-max-perf-on-bat
     Wie ‘cpu-max-perf-on-ac’ im BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Boolescher-Ausdruck
          cpu-boost-on-ac?
     Die CPU-Turbo-Boost-Funktionen im AC-Modus aktivieren.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Boolescher-Ausdruck
          cpu-boost-on-bat?
     Wie ‘cpu-boost-on-ac?’ im BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck
          sched-powersave-on-ac?
     Dem Linux-Kernel erlauben, die Anzahl benutzter CPU-Kerne und
     Hyperthreads anzupassen, wenn er unter leichter Last steht.

     Vorgegeben ist ‘#f’.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck
          sched-powersave-on-bat?
     Wie ‘sched-powersave-on-ac?’, aber für den BAT-Modus.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck nmi-watchdog?
     Ob die rechtzeitige Behandlung nichtmaskierbarer Unterbrechungen
     durch den „NMI-Watchdog“ des Linux-Kernels überprüft werden soll.

     Vorgegeben ist ‘#f’.

 -- ‘tlp-configuration’-Parameter: Vielleicht-Zeichenkette phc-controls
     Auf Linux-Kernels, auf die der PHC-Patch angewandt wurde, wird
     hierdurch die Prozessorspannung angepasst. Ein Beispielwert wäre
     ‘"F:V F:V F:V F:V"’.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Zeichenkette energy-perf-policy-on-ac
     Legt das Verhältnis von Prozessorleistung zu Stromsparsamkeit im
     AC-Modus fest. Angegeben werden können performance (hohe Leistung),
     normal, powersave (wenig Stromverbrauch).

     Die Vorgabe ist ‘"performance"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette
          energy-perf-policy-on-bat
     Wie ‘energy-perf-policy-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘"powersave"’.

 -- ‘tlp-configuration’-Parameter:
          Leerzeichengetrennte-Zeichenketten-Liste disks-devices
     Festplattengeräte.

 -- ‘tlp-configuration’-Parameter:
          Leerzeichengetrennte-Zeichenketten-Liste disk-apm-level-on-ac
     Stufe für das „Advanced Power Management“ auf Festplatten.

 -- ‘tlp-configuration’-Parameter:
          Leerzeichengetrennte-Zeichenketten-Liste disk-apm-level-on-bat
     Wie ‘disk-apm-bat’, aber für den BAT-Modus.

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          disk-spindown-timeout-on-ac
     Zeitspanne, bis die Festplatte inaktiv wird (ein „Spin-Down“). Für
     jede deklarierte Festplatte muss hier je ein Wert angegeben werden.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          disk-spindown-timeout-on-bat
     Wie ‘disk-spindown-timeout-on-ac’, aber für den BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          disk-iosched
     Ein-/Ausgaben-Planungsprogramm für Plattengeräte auswählen. Für
     jede deklarierte Festplatte muss ein Wert angegeben werden. Möglich
     sind zum Beispiel cfq, deadline und noop.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Zeichenkette sata-linkpwr-on-ac
     Stufe des „Aggressive Link Power Management“ (ALPM) für SATA.
     Angegeben werden können min_power (wenigster Stromverbrauch),
     medium_power (mittlerer Stromverbrauch), max_performance (maximale
     Leistung).

     Die Vorgabe ist ‘"max_performance"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette sata-linkpwr-on-bat
     Wie ‘sata-linkpwr-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘"min_power"’.

 -- ‘tlp-configuration’-Parameter: Vielleicht-Zeichenkette
          sata-linkpwr-blacklist
     Bestimmte SATA-Geräte („SATA-Host-Devices“) vom Link Power
     Management ausschließen.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-An-Aus-Boolescher-Ausdruck
          ahci-runtime-pm-on-ac?
     Verwaltung des Stromverbrauchs zur Laufzeit für
     AHCI-Steuerungseinheiten („Controller“) und AHCI-Platten im
     AC-Modus aktivieren.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-An-Aus-Boolescher-Ausdruck
          ahci-runtime-pm-on-bat?
     Wie ‘ahci-runtime-pm-on-ac’ im BAT-Modus.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          ahci-runtime-pm-timeout
     Nach wie vielen Sekunden der Inaktivität die Platten in den
     Ruhezustand gehen („Suspended“).

     Die Vorgabe ist ‘15’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette pcie-aspm-on-ac
     Stufe des „PCI Express Active State Power Management“. Zur Auswahl
     stehen default (Voreinstellung), performance (hohe Leistung),
     powersave (wenig Stromverbrauch).

     Die Vorgabe ist ‘"performance"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette pcie-aspm-on-bat
     Wie ‘pcie-aspm-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘"powersave"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette
          radeon-power-profile-on-ac
     Taktgeschwindigkeitsstufe („Clock Speed Level“) für Radeon-Grafik.
     Zur Auswahl stehen low (niedrig), mid (mittel), high (hoch), auto
     (automatisch), default (Voreinstellung).

     Die Vorgabe ist ‘"high"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette
          radeon-power-profile-on-bat
     Wie ‘radeon-power-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘"low"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette radeon-dpm-state-on-ac
     Methode für die dynamische Energieverwaltung („Dynamic Power
     Management“, DPM) auf Radeon. Zur Auswahl stehen battery
     (Batterie), performance (Leistung).

     Die Vorgabe ist ‘"performance"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette radeon-dpm-state-on-bat
     Wie ‘radeon-dpm-state-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘"battery"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette
          radeon-dpm-perf-level-on-ac
     Leistungsstufe („Performance Level“) des Radeon-DPM. Zur Auswahl
     stehen auto (automatisch), low (niedrig), high (hoch).

     Die Voreinstellung ist ‘"auto"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette
          radeon-dpm-perf-level-on-bat
     Wie ‘radeon-dpm-perf-ac’, aber für den BAT-Modus.

     Die Voreinstellung ist ‘"auto"’.

 -- ‘tlp-configuration’-Parameter: An-Aus-Boolescher-Ausdruck
          wifi-pwr-on-ac?
     WLAN-Stromsparmodus.

     Vorgegeben ist ‘#f’.

 -- ‘tlp-configuration’-Parameter: An-Aus-Boolescher-Ausdruck
          wifi-pwr-on-bat?
     Wie ‘wifi-power-ac?’, aber für den BAT-Modus.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Ja-Nein-Boolescher-Ausdruck
          wol-disable?
     Rechnerstart nach Netzwerkanforderung („Wake on LAN“) deaktivieren.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          sound-power-save-on-ac
     Nach wie vielen Sekunden der Stromsparmodus für die
     Audioverarbeitung auf Intel-HDA- und AC97-Geräten aktiviert wird.
     Ein Wert von 0 deaktiviert den Stromsparmodus.

     Die Vorgabe ist ‘0’.

 -- ‘tlp-configuration’-Parameter: Nichtnegative-ganze-Zahl
          sound-power-save-on-bat
     Wie ‘sound-powersave-ac’, aber für den BAT-Modus.

     Die Vorgabe ist ‘1’.

 -- ‘tlp-configuration’-Parameter: Ja-Nein-Boolescher-Ausdruck
          sound-power-save-controller?
     Steuerungseinheit („Controller“) im Stromsparmodus auf
     Intel-HDA-Geräten deaktivieren.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck
          bay-poweroff-on-bat?
     Optisches Laufwerk in einer UltraBay/MediaBay im BAT-Modus
     aktivieren. Laufwerke können erneut gestartet werden, indem Sie den
     Hebel zum Auswerfen lösen (und wieder einsetzen) oder, auf neueren
     Modellen, indem Sie den Knopf zum Auswerfen des eingelegten
     Datenträgers drücken.

     Vorgegeben ist ‘#f’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette bay-device
     Name des Geräts für das optische Laufwerk, das gestartet werden
     soll.

     Die Vorgabe ist ‘"sr0"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette runtime-pm-on-ac
     Laufzeitenergieverwaltung („Runtime Power Management“) von
     PCI(e)-Bus-Geräten. Zur Auswahl stehen on (angeschaltet) und auto
     (automatisch).

     Die Vorgabe ist ‘"on"’.

 -- ‘tlp-configuration’-Parameter: Zeichenkette runtime-pm-on-bat
     Wie ‘runtime-pm-ac’, aber für den BAT-Modus.

     Die Voreinstellung ist ‘"auto"’.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck runtime-pm-all?
     Runtime Power Management for all PCI(e) bus devices, except
     blacklisted ones.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter:
          Vielleicht-Leerzeichengetrennte-Zeichenketten-Liste
          runtime-pm-blacklist
     Die angegebenen PCI(e)-Geräteadressen von der
     Laufzeitenergieverwaltung („Runtime Power Management“) ausnehmen.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter:
          Leerzeichengetrennte-Zeichenketten-Liste
          runtime-pm-driver-blacklist
     PCI(e)-Geräte von der Laufzeitenergieverwaltung („Runtime Power
     Management“) ausnehmen, wenn sie den angegebenen Treibern
     zugeordnet sind.

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck usb-autosuspend?
     USB-Geräte automatisch in den Ruhezustand versetzen
     („USB-Autosuspend“).

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Vielleicht-Zeichenkette usb-blacklist
     Die angegebenen Geräte vom USB-Autosuspend ausnehmen.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck
          usb-blacklist-wwan?
     WWAN-Geräte vom USB-Autosuspend ausnehmen.

     Die Vorgabe ist ‘#t’.

 -- ‘tlp-configuration’-Parameter: Vielleicht-Zeichenkette usb-whitelist
     Für die angegebenen Geräte USB-Autosuspend aktivieren, selbst wenn
     Autosuspend durch den Treiber oder wegen ‘usb-blacklist-wwan?’
     deaktiviert werden würde.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Vielleicht-Boolescher-Ausdruck
          usb-autosuspend-disable-on-shutdown?
     USB-Autosuspend vor dem Herunterfahren aktivieren.

     Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

 -- ‘tlp-configuration’-Parameter: Boolescher-Ausdruck
          restore-device-state-on-startup?
     Zustand von funkfähigen Geräten (Bluetooth, WLAN, WWAN) vom letzten
     Herunterfahren beim Hochfahren des Systems wiederherstellen.

     Vorgegeben ist ‘#f’.

Thermald-Daemon
...............

Das Modul ‘(gnu services pm)’ stellt eine Schnittstelle zu Thermald zur
Verfügung, einem Dienst zur CPU-Frequenzskalierung („CPU Frequency
Scaling“), mit dem Überhitzung verhindert wird.

 -- Scheme-Variable: thermald-service-type
     Dies ist der Diensttyp für Thermald
     (https://01.org/linux-thermal-daemon/), den “Linux Thermal Daemon”,
     der für die Hitzeregulierung von Prozessoren zuständig ist. Er
     ändert deren thermischen Zustand („Thermal State“) und verhindert,
     dass sie überhitzen.

 -- Datentyp: thermald-configuration
     Datentyp, der die Konfiguration des ‘thermald-service-type’
     repräsentiert.

     ‘ignore-cpuid-check?’ (Vorgabe: ‘#f’)
          Ergebnis der Prüfung per CPUID auf unterstützte
          Prozessormodelle ignorieren.

     ‘thermald’ (Vorgabe: THERMALD)
          Paketobjekt von thermald.


File: guix.de.info,  Node: Audio-Dienste,  Next: Virtualisierungsdienste,  Prev: Dienste zur Stromverbrauchsverwaltung,  Up: Dienste

10.8.25 Audio-Dienste
---------------------

Das Modul ‘(gnu services audio)’ stellt einen Dienst zur Verfügung, um
MPD (den Music Player Daemon) zu starten.

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

Der Music Player Daemon (MPD) ist ein Dienst, der Musik abspielen kann
und der dabei vom lokalen Rechner oder über das Netzwerk durch
verschiedene Clients angesteuert werden kann.

   Das folgende Beispiel zeigt, wie man ‘mpd’ als Benutzer ‘"bob"’ auf
Port ‘6666’ ausführen könnte. Dabei wird Pulseaudio zur Ausgabe
verwendet.

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

 -- Scheme-Variable: mpd-service-type
     Der Diensttyp für ‘mpd’.

 -- Datentyp: mpd-configuration
     Datentyp, der die Konfiguration von ‘mpd’ repräsentiert.

     ‘user’ (Vorgabe: ‘"mpd"’)
          Das Benutzerkonto, mit dem mpd ausgeführt wird.

     ‘music-dir’ (Vorgabe: ‘"~/Music"’)
          Das Verzeichis, in dem nach Musikdateien gesucht wird.

     ‘playlist-dir’ (Vorgabe: ‘"~/.mpd/playlists"’)
          Das Verzeichnis, um Wiedergabelisten („Playlists“) zu
          speichern.

     ‘db-file’ (Vorgabe: ‘"~/.mpd/tag_cache"’)
          Der Ort, an dem die Musikdatenbank gespeichert wird.

     ‘state-file’ (Vorgabe: ‘"~/.mpd/state"’)
          Der Ort, an dem die Datei mit dem aktuellen Zustand von MPD
          gespeichert wird.

     ‘sticker-file’ (Vorgabe: ‘"~/.mpd/sticker.sql"’)
          Der Ort, an dem die Sticker-Datenbank gespeichert wird.

     ‘port’ (Vorgabe: ‘"6600"’)
          Der Port, auf dem mpd ausgeführt wird.

     ‘address’ (Vorgabe: ‘"any"’)
          Die Adresse, an die sich mpd binden wird. Um einen Unix-Socket
          zu benutzen, kann hier ein absoluter Pfad angegeben werden.

     ‘outputs’ (Vorgabe: ‘"(list (mpd-output))"’)
          Welche Tonausgaben MPD benutzen kann. Vorgegeben ist eine
          einzelne Ausgabe, die Pulseaudio benutzt.

 -- Datentyp: mpd-output
     Datentyp, der eine Tonausgabe von ‘mpd’ repräsentiert.

     ‘name’ (Vorgabe: ‘"MPD"’)
          Der Name der Tonausgabe.

     ‘type’ (Vorgabe: ‘"pulse"’)
          Der Typ der Tonausgabe.

     ‘enabled?’ (Vorgabe: ‘#t’)
          Gibt an, ob diese Tonausgabe aktiviert sein soll, wenn MPD
          gestartet wird. Vorgegeben ist, alle Tonausgaben zu
          aktivieren. Das entspricht der Voreinstellung, wenn keine
          Zustandsdatei existiert; mit Zustandsdatei wird der Zustand
          von früher wiederhergestellt.

     ‘tags?’ (Vorgabe: ‘#t’)
          Wenn es auf ‘#f’ steht, sendet MPD keine Tags an diese
          Ausgabe. Dies wird nur berücksichtigt, wenn das Ausgabe-Plugin
          Tags empfangen kann, wie beim ‘httpd’-Ausgabe-Plugin.

     ‘always-on?’ (Vorgabe: ‘#f’)
          Wenn es auf ‘#t’ steht, versucht MPD, diese Tonausgabe immer
          offen zu lassen. Das kann bei Streaming-Servern helfen, wo man
          _nicht_ will, dass die Verbindung zu allen Zuhörern abbricht,
          nur weil das Abspielen aus irgendeinem Grund angehalten wurde.

     ‘mixer-type’
          Für dieses Feld wird ein Symbol akzeptiert, das das für diese
          Tonausgabe zu benutzende Mischpult („Mixer“) bezeichnet. Zur
          Wahl stehen das ‘hardware’-Mischpult, das
          ‘software’-Mischpult, das ‘null’-Mischpult oder kein Mischpult
          (‘none’). Mit dem ‘null’-Mischpult kann die Lautstärke
          eingestellt werden, aber ohne Auswirkung; das kann als Trick
          benutzt werden, um ein externes Mischpult zu implementieren.

     ‘extra-options’ (Vorgabe: ‘'()’)
          Eine assoziative Liste, die Optionssymbole auf Zeichenketten
          abbildet. Sie wird an die Tonausgabenkonfiguration angehängt.

   Das folgende Beispiel zeigt eine Konfiguration von ‘mpd’, die eine
HTTP-Audiostreaming-Tonausgabe anbietet.

     (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.de.info,  Node: Virtualisierungsdienste,  Next: Versionskontrolldienste,  Prev: Audio-Dienste,  Up: Dienste

10.8.26 Virtualisierungsdienste
-------------------------------

Das Modul ‘(gnu services virtualization)’ bietet Dienste für die Daemons
von libvirt und virtlog, sowie andere virtualisierungsbezogene Dienste.

Libvirt-Daemon
..............

‘libvirtd’ ist die serverseitige Daemon-Komponente des libvirt-Systems
zur Virtualisierungsverwaltung. Dieser Daemon läuft auf als Wirt
dienenden Servern und führt anfallende Verwaltungsaufgaben für
virtualisierte Gäste durch.

 -- Scheme-Variable: libvirt-service-type
     Dies ist der Diensttyp des libvirt-Daemons (https://libvirt.org).
     Sein Wert muss ein ‘libvirt-configuration’-Verbundsobjekt sein.

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

   Verfügbare ‘libvirt-configuration’-Felder sind:

 -- ‘libvirt-configuration’-Parameter: „package“ libvirt
     Libvirt-Paket.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck listen-tls?
     Option zum Lauschen auf sichere TLS-Verbindungen über den
     öffentlichen TCP/IP-Port. ‘listen’ muss gesetzt sein, damit dies
     eine Wirkung hat.

     Bevor Sie diese Funktionalität nutzen können, muss eine
     Zertifikatsautorität eingerichtet worden sein und
     Server-Zertifikate ausgestellt worden sein.

     Die Vorgabe ist ‘#t’.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck listen-tcp?
     Auf unverschlüsselte TCP-Verbindungen auf dem öffentlichen
     TCP/IP-Port lauschen. ‘listen’ muss gesetzt sein, damit dies eine
     Wirkung hat.

     Nach Voreinstellung kann auf dem TCP-Socket nur gelauscht werden,
     wenn SASL-Authentifizierung möglich ist. Nur solche
     SASL-Mechanismen, die Datenverschlüsselung unterstützen, sind
     zugelassen. Das sind DIGEST_MD5 und GSSAPI (Kerberos5).

     Vorgegeben ist ‘#f’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette tls-port
     Der Port, um sichere TLS-Verbindungen zu akzeptieren. Dies kann
     eine Portnummer oder ein Dienstname sein.

     Die Vorgabe ist ‘"16514"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette tcp-port
     Der Port, um unsichere TCP-Verbindungen zu akzeptieren. Dies kann
     eine Portnummer oder ein Dienstname sein.

     Die Vorgabe ist ‘"16509"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette listen-addr
     IP-Adresse oder Rechnername („Hostname“), der für von Clients
     ausgehende Verbindungen benutzt wird.

     Die Vorgabe ist ‘"0.0.0.0"’.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck mdns-adv?
     Einstellung, ob der libvirt-Dienst mDNS-Mitteilungen sendet.

     Dies kann alternativ für alle Dienste auf einem Rechner deaktiviert
     werden, indem man den Avahi-Daemon anhält.

     Vorgegeben ist ‘#f’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette mdns-name
     Der voreingestellte Name in mDNS-Mitteilungen. Er muss auf dem
     direkten Broadcast-Netzwerk eindeutig sein.

     Die Vorgabe ist ‘"Virtualization Host <Rechnername>"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette unix-sock-group
     Besitzergruppe des UNIX-Sockets. Diese Einstellung kann benutzt
     werden, um einer als vertrauenswürdig geltenden Gruppe von
     Benutzern Zugriff auf Verwaltungsfunktionen zu gewähren, ohne dass
     diese als Administratornutzer root ausgeführt werden müssen.

     Die Vorgabe ist ‘"root"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette unix-sock-ro-perms
     UNIX-Socket-Berechtigungen für den Socket nur mit Lesezugriff
     („read only“). Dies wird nur zur Überwachung des Zustands der VM
     benutzt.

     Die Vorgabe ist ‘"0777"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette unix-sock-rw-perms
     UNIX-Socket-Berechtigungen für den Socket mit Schreib- und
     Lesezugriff („read/write“). Nach Vorgabe kann nur der
     Administratornutzer root zugreifen. Wenn auf dem Socket PolicyKit
     aktiviert ist, wird die Vorgabe geändert, dass jeder zugreifen kann
     (z.B. zu 0777)

     Die Vorgabe ist ‘"0770"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette
          unix-sock-admin-perms
     UNIX-Socket-Berechtigungen für den Administrator-Socket. Nach
     Vorgabg hat nur der Besitzer (der Administratornutzer root) hierauf
     Zugriff; ändern Sie es nur, wenn Sie sicher wissen, wer dann alles
     Zugriff bekommt.

     Die Vorgabe ist ‘"0777"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette unix-sock-dir
     Das Verzeichnis, in dem Sockets gefunden werden können bzw.
     erstellt werden.

     Die Vorgabe ist ‘"/var/run/libvirt"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette auth-unix-ro
     Authentifizierungsschema für nur lesbare UNIX-Sockets. Nach Vorgabe
     gestatten es die Socket-Berechtigungen jedem Nutzer, sich zu
     verbinden.

     Die Vorgabe ist ‘"polkit"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette auth-unix-rw
     Authentifizierungsschema für UNIX-Sockets mit Schreib- und
     Lesezugriff. Nach Vorgabe erlauben die Socket-Berechtigungen nur
     dem Administratornutzer root Zugriff. Wenn libvirt mit
     Unterstützung für PolicyKit kompiliert wurde, ist die Vorgabe,
     Authentifizierung über „polkit“ durchzuführen.

     Die Vorgabe ist ‘"polkit"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette auth-tcp
     Authentifizierungsschema für TCP-Sockets. Wenn Sie SASL nicht
     aktivieren, dann wird alle TCP-Kommunikation im Klartext
     verschickt. Tun Sie dies _nicht_, außer Sie benutzen libvirt nur
     als Entwickler oder zum Testen.

     Die Vorgabe ist ‘"sasl"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette auth-tls
     Authentifizierungsschema für TLS-Sockets. Für TLS-Sockets wird
     bereits durch die TLS-Schicht Verschlüsselung bereitgestellt und
     eingeschränkte Authentifizierung wird über Zertifikate
     durchgeführt.

     Es ist möglich, auch hier den SASL-Authentifizierungsmechanismus
     anzuwenden, indem Sie für diese Option „sasl“ eintragen.

     Die Vorgabe ist ‘"none"’, d.h. keine zusätzliche Authentifizierung.

 -- ‘libvirt-configuration’-Parameter: Optional-nichtleere-Liste
          access-drivers
     Welche Schemata zur Zugriffskontrolle auf Programmierschnittstellen
     (APIs) benutzt werden.

     Nach Vorgabe kann ein authentifizierter Nutzer auf alle
     Programmierschnittstellen zugreifen. Zugriffstreiber können dies
     einschränken.

     Die Vorgabe ist ‘()’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette key-file
     Pfad zur Schlüsseldatei für den Server. Wenn er auf eine leere
     Zeichenkette gesetzt ist, dann wird kein privater Schlüssel
     geladen.

     Die Vorgabe ist ‘""’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette cert-file
     Pfad zur Zertifikatsdatei für den Server. Wenn er auf eine leere
     Zeichenkette gesetzt ist, dann wird kein Zertifikat geladen.

     Die Vorgabe ist ‘""’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette ca-file
     Pfad zur Datei mit dem Zertifikat der Zertifikatsautorität. Wenn er
     auf eine leere Zeichenkette gesetzt ist, dann wird kein Zertifikat
     der Zertifikatsautorität geladen.

     Die Vorgabe ist ‘""’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette crl-file
     Pfad zur Zertifikatssperrliste („Certificate Revocation List“).
     Wenn er auf eine leere Zeichenkette gesetzt ist, dann wird keine
     Zertifikatssperrliste geladen.

     Die Vorgabe ist ‘""’.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck
          tls-no-sanity-cert
     Keine Überprüfung unseres eigenen Serverzertifikats durchführen.

     Beim Start vom libvirtd prüft dieser, ob bei seinem eigenen
     Zertifikat alles in Ordnung ist.

     Vorgegeben ist ‘#f’.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck
          tls-no-verify-cert
     Keine Überprüfung von Clientzertifikaten durchführen.

     Die Überprüfung des Zertifikats eines Clients ist der primäre
     Authentifizierungsmechanismus. Jeder Client, der kein von der
     Zertifikatsautorität signiertes Zertifikat vorweist, wird
     abgelehnt.

     Vorgegeben ist ‘#f’.

 -- ‘libvirt-configuration’-Parameter: Optional-nichtleere-Liste
          tls-allowed-dn-list
     Liste der erlaubten Einträge für den „Distinguished Name“ bei x509.

     Die Vorgabe ist ‘()’.

 -- ‘libvirt-configuration’-Parameter: Optional-nichtleere-Liste
          sasl-allowed-usernames
     Liste der erlaubten Einträge für SASL-Benutzernamen. Wie
     Benutzernamen aussehen müssen, ist abhängig vom jeweiligen
     SASL-Mechanismus.

     Die Vorgabe ist ‘()’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette tls-priority
     Dies wird vorrangig statt der beim Kompilieren voreingestellten
     TLS-Prioritätszeichenkette verwendet. Die Voreinstellung ist in der
     Regel ‘"NORMAL"’, solange dies nicht bei der Erstellung geändert
     wurde. Ändern Sie dies nur, wenn die Einstellungen für libvirt von
     den globalen Voreinstellungen abweichen sollen.

     Die Vorgabe ‘"NORMAL"’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-clients
     Maximalzahl gleichzeitiger Client-Verbindungen, die für alle
     Sockets zusammen zugelassen werden sollen.

     Die Vorgabe ist ‘5000’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-queued-clients
     Maximale Länge der Warteschlange für Verbindungen, die darauf
     warten, vom Daemon angenommen zu werden. Beachten Sie, dass sich
     manche Protokolle, die Neuübertragung unterstützen, danach richten
     könnten, damit ein erneuter Verbindungsversuch angenommen wird.

     Die Vorgabe ist ‘1000’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-anonymous-clients
     Maximale Länge der Warteschlange für Clients, die angenommen
     wurden, aber noch nicht authentifiziert wurden. Setzen Sie dies auf
     null, um diese Funktionalität abzuschalten.

     Die Vorgabe ist ‘20’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl min-workers
     Anzahl an Arbeiter-Threads, die am Anfang gestartet werden sollen.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-workers
     Maximale Anzahl an Arbeiter-Threads.

     Wenn die Anzahl aktiver Clients die ‘min-workers’ übersteigt,
     werden weitere Threads erzeugt, bis die max_workers-Beschränkung
     erreicht wurde. Typischerweise würden Sie für max_workers die
     maximale Anzahl zugelassener Clients angeben.

     Die Vorgabe ist ‘20’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl prio-workers
     Die Anzahl priorisierter Arbeiter-Threads. Wenn alle Arbeiter aus
     diesem Pool festhängen, können manche, mit hoher Priorität
     versehene Aufrufe (speziell domainDestroy) in diesem Pool hier
     ausgeführt werden.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-requests
     Wie viele nebenläufige RPC-Aufrufe global ausgeführt werden können.

     Die Vorgabe ist ‘20’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl max-client-requests
     Wie viele nebenläufige Anfragen von einer einzelnen
     Client-Verbindung ausgehen können. Um zu verhindern, dass ein
     einzelner Client den gesamten Server für sich beansprucht, sollte
     der Wert hier nur einen kleinen Teil der globalen max_requests- und
     max_workers-Parameter ausmachen.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl admin-min-workers
     Wie bei ‘min-workers’, aber für die Administratorschnittstelle.

     Die Vorgabe ist ‘1’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl admin-max-workers
     Wie bei ‘max-workers’, aber für die Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl admin-max-clients
     Wie bei ‘max-clients’, aber für die Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl
          admin-max-queued-clients
     Wie bei ‘max-queued-clients’, aber für die
     Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl
          admin-max-client-requests
     Wie bei ‘max-client-requests’, aber für die
     Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl log-level
     Protokollstufe. 4 für Fehler, 3 für Warnungen, 2 für Informationen,
     1 zur Fehlersuche.

     Die Vorgabe ist ‘3’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette log-filters
     Protokollfilter.

     Ein Filter ermöglicht es, für eine bestimmte Kategorie von
     Protokollen eine andere Protokollierungsstufe festzulegen. Filter
     müssen eines der folgenden Formate haben:

        • x:Name

        • x:+Name

     wobei ‘Name’ eine Zeichenkette ist, die zu einer in der
     Umgebungsvariablen ‘VIR_LOG_INIT()’ am Anfang jeder Quelldatei von
     libvirt angegebenen Kategorie passen muss, z.B. ‘"remote"’,
     ‘"qemu"’ oder ‘"util.json"’ (der Name im Filter kann auch nur ein
     Teil des vollständigen Kategoriennamens sein, wodurch mehrere,
     ähnliche passende Kategoriennamen möglich sind). Das optionale
     Präfix „+“ bedeutet, dass libvirt eine Rückverfolgung (d.h. ein
     „Stack Trace“) für jede zum Namen passende Nachricht ins Protokoll
     schreiben soll. ‘x’ benennt jeweils die kleinste Stufe, deren
     passende Nachrichten protokolliert werden sollen.

        • 1: Fehlersuche („DEBUG“)

        • 2: Informationen („INFO“)

        • 3: Warnungen („WARNING“)

        • 4: Fehler („ERROR“)

     Mehrere Filter können in einer einzelnen Filteranweisung definiert
     werden; sie müssen nur durch Leerzeichen voneinander getrennt
     werden.

     Die Vorgabe ist ‘"3:remote 4:event"’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette log-outputs
     Ausgaben für die Protokollierung.

     Eine Ausgabe ist einer der Orte, wohin Informationen aus der
     Protokollierung gespeichert werden. Eine Ausgabe kann auf eine der
     folgenden Arten angegeben werden:

     ‘x:stderr’
          Protokolle werden auf der Standardausgabe („Stderr“)
          ausgegeben.

     ‘x:syslog:Name’
          Syslog wird zur Ausgabe benutzt. Der Name dient dabei als
          Identifikator für libvirt-Protokolle.

     ‘x:file:Dateipfad’
          Protokolle werden in die Datei unter dem angegebenen Dateipfad
          ausgegeben.

     ‘x:journald’
          Die Ausgabe läuft über das journald-Protokollsystem.

     In allen Fällen steht das x vorne für die kleinste Stufe und wirkt
     als Filter.

        • 1: Fehlersuche („DEBUG“)

        • 2: Informationen („INFO“)

        • 3: Warnungen („WARNING“)

        • 4: Fehler („ERROR“)

     Mehrere Ausgaben können definiert werden, dazu müssen sie nur durch
     Leerzeichen getrennt hier angegeben werden.

     Die Vorgabe ist ‘"3:stderr"’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl audit-level
     Ermöglicht Anpassungen am Auditierungs-Subsystem.

        • 0: Jegliche Auditierung deaktivieren.

        • 1: Auditierung nur aktivieren, wenn sie beim Wirtssystem
          aktiviert ist.

        • 2: Auditierung aktivieren. Beenden, wenn das Wirtssystem
          Auditierung deaktiviert hat.

     Die Vorgabe ist ‘1’.

 -- ‘libvirt-configuration’-Parameter: Boolescher-Ausdruck audit-logging
     Audit-Nachrichten über die Protokollinfrastruktur von libvirt
     versenden.

     Vorgegeben ist ‘#f’.

 -- ‘libvirt-configuration’-Parameter: Optional-nichtleere-Zeichenkette
          host-uuid
     Für das Wirtssystem zu verwendende UUID. Bei der UUID dürfen nicht
     alle Ziffern gleich sein.

     Die Vorgabe ist ‘""’.

 -- ‘libvirt-configuration’-Parameter: Zeichenkette host-uuid-source
     Die Quelle, von der die UUID des Wirtssystems genommen wird.

        • ‘smbios’: Die UUID von ‘dmidecode -s system-uuid’ holen.

        • ‘machine-id’: Die UUID aus ‘/etc/machine-id’ holen.

     Falls ‘dmidecode’ keine gültige UUID liefert, wird eine temporäre
     UUID generiert.

     Die Vorgabe ist ‘"smbios"’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl keepalive-interval
     Einem Client wird eine Nachricht zum Aufrechterhalten der
     Verbindung gesendet, nachdem ‘keepalive_interval’ Sekunden lang
     keine Aktivität stattgefunden hat. Damit kann überprüft werden, ob
     der Client noch antwortet. Wird dieses Feld auf -1 gesetzt, wird
     libvirtd niemals Aufrechterhaltungsanfragen senden; Clients können
     diese aber weiterhin dem Daemon schicken und er wird auf diese
     antworten.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl keepalive-count
     Wie viele Aufrechterhaltungsnachrichten höchstens zum Client
     geschickt werden dürfen, ohne dass eine Antwort zurückgekommen ist,
     bevor die Verbindung als abgebrochen gilt.

     Mit anderen Worten wird die Verbindung ungefähr dann automatisch
     geschlossen, wenn ‘keepalive_interval * (keepalive_count + 1)’
     Sekunden seit der letzten vom Client empfangenen Nachricht
     vergangen sind. Wenn ‘keepalive-count’ auf 0 gesetzt ist, werden
     Verbindungen dann automatisch geschlossen, wenn
     ‘keepalive-interval’ Sekunden der Inaktivität vorausgegangen sind,
     ohne dass eine Aufrechterhaltungsnachricht versandt wurde.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl
          admin-keepalive-interval
     Wie oben, aber für die Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl admin-keepalive-count
     Wie oben, aber für die Administratorschnittstelle.

     Die Vorgabe ist ‘5’.

 -- ‘libvirt-configuration’-Parameter: Ganze-Zahl ovs-timeout
     Zeitbeschränkung für Aufrufe über Open vSwitch.

     Das Werkzeug ‘ovs-vsctl’ wird zur Konfiguration benutzt; die dort
     eingestellte Zeitbeschränkung ist nach Voreinstellung auf 5
     Sekunden festgelegt, um zu verhindern, dass libvirt durch
     unbegrenztes Warten blockiert werden kann.

     Die Vorgabe ist ‘5’.

Virtlog-Daemon
..............

Der virtlogd-Dienst ist eine serverseitige Daemon-Komponente von
libvirt, die benutzt wird, um Protokolle der Konsolen von virtuellen
Maschinen zu verwalten.

   Dieser Daemon wird von libvirt-Clientanwendungen nicht direkt
benutzt, sondern wird an deren Stelle vom ‘libvirtd’ aufgerufen. Indem
die Protokolle in einem eigenständigen Daemon vorgehalten werden, kann
der eigentliche ‘libvirtd’-Daemon neu gestartet werden, ohne dass man
riskiert, Protokolle zu verlieren. Der ‘virtlogd’-Daemon hat die
Fähigkeit, sich selbst erneut mit exec() zu starten, wenn er ‘SIGUSR1’
empfängt, damit Aktualisierungen ohne Ausfall möglich sind.

 -- Scheme-Variable: virtlog-service-type
     Dies ist der Diensttyp des virtlog-Daemons. Sein Wert muss eine
     ‘virtlog-configuration’ sein.

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

 -- ‘virtlog-configuration’-Parameter: Ganze-Zahl log-level
     Protokollstufe. 4 für Fehler, 3 für Warnungen, 2 für Informationen,
     1 zur Fehlersuche.

     Die Vorgabe ist ‘3’.

 -- ‘virtlog-configuration’-Parameter: Zeichenkette log-filters
     Protokollfilter.

     Ein Filter ermöglicht es, für eine bestimmte Kategorie von
     Protokollen eine andere Protokollierungsstufe festzulegen. Filter
     müssen eines der folgenden Formate haben:

        • x:Name

        • x:+Name

     wobei ‘Name’ eine Zeichenkette ist, die zu einer in der
     Umgebungsvariablen ‘VIR_LOG_INIT()’ am Anfang jeder Quelldatei von
     libvirt angegebenen Kategorie passen muss, z.B. „remote“, „qemu“
     oder „util.json“ (der Name im Filter kann auch nur ein Teil des
     vollständigen Kategoriennamens sein, wodurch mehrere, ähnliche
     passende Kategoriennamen möglich sind). Das optionale Präfix „+“
     bedeutet, dass libvirt eine Rückverfolgung (d.h. ein „Stack Trace“)
     für jede zum Namen passende Nachricht ins Protokoll schreiben soll.
     ‘x’ benennt jeweils die kleinste Stufe, deren passende Nachrichten
     protokolliert werden sollen.

        • 1: Fehlersuche („DEBUG“)

        • 2: Informationen („INFO“)

        • 3: Warnungen („WARNING“)

        • 4: Fehler („ERROR“)

     Mehrere Filter können in einer einzelnen Filteranweisung definiert
     werden; sie müssen nur durch Leerzeichen voneinander getrennt
     werden.

     Die Vorgabe ist ‘"3:remote 4:event"’.

 -- ‘virtlog-configuration’-Parameter: Zeichenkette log-outputs
     Ausgaben für die Protokollierung.

     Als Ausgabe bezeichnen wir einen der Orte, an denen
     Protokollinformationen gespeichert werden. Eine Ausgabe wird auf
     eine der folgenden Arten angegeben:

     ‘x:stderr’
          Protokolle werden auf der Standardausgabe („Stderr“)
          ausgegeben.

     ‘x:syslog:Name’
          Syslog wird zur Ausgabe benutzt. Der Name dient dabei als
          Identifikator für libvirt-Protokolle.

     ‘x:file:Dateipfad’
          Protokolle werden in die Datei unter dem angegebenen Dateipfad
          ausgegeben.

     ‘x:journald’
          Die Ausgabe läuft über das journald-Protokollsystem.

     In allen Fällen steht das x vorne für die kleinste Stufe und wirkt
     als Filter.

        • 1: Fehlersuche („DEBUG“)

        • 2: Informationen („INFO“)

        • 3: Warnungen („WARNING“)

        • 4: Fehler („ERROR“)

     Mehrere Ausgaben können definiert werden, dazu müssen sie nur durch
     Leerzeichen getrennt hier angegeben werden.

     Die Vorgabe ist ‘"3:stderr"’.

 -- ‘virtlog-configuration’-Parameter: Ganze-Zahl max-clients
     Maximalzahl gleichzeitiger Client-Verbindungen, die für alle
     Sockets zusammen zugelassen werden sollen.

     Die Vorgabe ist ‘1024’.

 -- ‘virtlog-configuration’-Parameter: Ganze-Zahl max-size
     Wie groß eine Protokolldatei werden darf, bevor eine neue begonnen
     wird.

     Die Vorgabe ist ‘2MB’.

 -- ‘virtlog-configuration’-Parameter: Ganze-Zahl max-backups
     Wie viele Dateien mit Sicherungskopien gespeichert bleiben sollen.

     Die Vorgabe ist ‘3’.

Transparente Emulation mit QEMU
...............................

Mit ‘qemu-binfmt-service-type’ wird transparente Emulation von
Programm-Binärdateien, die für unterschiedliche Architekturen erstellt
wurden, ermöglicht. Z.B. können Sie ein ARMv7-Programm „einfach so“
transparent auf einer x86_64-Maschine ausführen. Dazu wird der
QEMU-Emulator (https://www.qemu.org) mit der
‘binfmt_misc’-Funktionalität des Kernels Linux kombiniert. Mit dieser
Funktionalität können Sie jedoch nur ein GNU/Linux-System, das auf einer
anderen Architektur läuft, emulieren. Unterstützung für GNU/Hurd ist
auch möglich, lesen Sie dazu unten weiter.

 -- Scheme-Variable: qemu-binfmt-service-type
     Dies ist der Diensttyp des QEMU/binfmt-Dienstes für transparente
     Emulation. Sein Wert muss ein ‘qemu-binfmt-configuration’-Objekt
     sein, das das QEMU-Paket angibt, das benutzt werden soll, sowie die
     Architektur, die wir emulieren möchten.

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

     In diesem Beispiel aktivieren wir transparente Emulation für die
     Plattformen ARM und aarch64. Wenn wir ‘herd stop qemu-binfmt’
     ausführen, wird diese abgeschaltet, und mit ‘herd start
     qemu-binfmt’ wird sie wieder aktiv (siehe *note den ‘herd’-Befehl:
     (shepherd)Invoking herd.).

 -- Datentyp: qemu-binfmt-configuration
     Dies ist die Konfiguration des ‘qemu-binfmt’-Dienstes.

     ‘platforms’ (Vorgabe: ‘'()’)
          Die Liste der emulierten QEMU-Plattformen. Jeder Eintrag muss
          ein “Plattformobjekt” sein, wie ‘lookup-qemu-platforms’ eines
          zurückliefert (siehe unten).

          Wenn wir zum Beispiel annehmen, Sie arbeiten auf einer
          x86_64-Maschine und haben diesen Dienst eingerichtet:

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

          Dann können Sie das hier ausführen:

               guix build -s armhf-linux inkscape

          und alles verhält sich so, als würden Sie Inkscape für ARMv7
          _wie „nativ“ auf einem ARM-Rechner erstellen_, wozu QEMU
          transparent benutzt wird, um den ARMv7-Prozessor zu emulieren.
          Das ist ganz schön praktisch, wenn Sie testen wollen, ob ein
          Paket für eine Architektur erstellt werden kann, die Ihnen
          nicht zur Verfügung steht.

     ‘qemu’ (Vorgabe: ‘qemu’)
          Das QEMU-Paket, das benutzt werden soll.

 -- Scheme-Prozedur: lookup-qemu-platforms PLATTFORMEN…
     Liefert die Liste der QEMU-Plattformobjekte, die den PLATTFORMEN…
     entsprechen. PLATTFORMEN muss eine Liste von Zeichenketten sein,
     die den Namen der Plattformen entsprechen, wie z.B. ‘"arm"’,
     ‘"sparc"’, ‘"mips64el"’ und so weiter.

 -- Scheme-Prozedur: qemu-platform? OBJEKT
     Liefert wahr, wenn das OBJEKT ein Plattformobjekt ist.

 -- Scheme-Prozedur: qemu-platform-name PLATTFORM
     Liefert den Namen der PLATTFORM, also eine Zeichenkette wie z.B.
     ‘"arm"’.

GNU Hurd in einer virtuellen Maschine
.....................................

Der ‘hurd-vm’-Dienst bietet Unterstützung, um GNU/Hurd in einer
virtuellen Maschine (VM) laufen zu lassen, als eine sogenannte
„Kind-Hurd“, englisch “Childhurd”. Der Dienst ist für die Nutzung mit
GNU/Linux-Systemen gedacht; die angegebene GNU/Hurd-Konfiguration wird
cross-kompiliert. Die virtuelle Maschine läuft als ein Shepherd-Dienst,
der durch Namen wie ‘hurd-vm’ und ‘childhurd’ bezeichnet wird und mit
Befehlen wie den folgenden gesteuert werden kann:

     herd start hurd-vm
     herd stop childhurd

   Während der Dienst läuft, können Sie seine Konsole anzeigen lassen,
indem Sie sich über einen VNC-Client mit ihm verbinden, z.B. durch den
Befehl:

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

   Die Vorgabekonfiguration (siehe ‘hurd-vm-configuration’ unten) lässt
einen Server für Secure Shell (SSH) in Ihrem GNU/Hurd-System laufen,
welchen QEMU (der Emulator für virtuelle Maschinen) an Port 10222 des
Wirtssystems weitergibt. So können Sie sich mit der Childhurd über SSH
verbinden:

     ssh root@localhost -p 10022

   Die Childhurd ist flüchtig und zustandslos: Jedes Mal, wenn Sie sie
neu starten, hat sie wieder ihr ursprüngliches Wurzeldateisystem. Nur
die Dateien unter ‘/etc/childhurd’ im Wirtssystem werden nach Vorgabe in
das Wurzeldateisystem der Childhurd übernommen, wenn sie startet. So
können Sie einen Startwert für „Geheimnisse“ in der VM angeben:
SSH-Host-Schlüssel, Autorisierungsschlüssel für Substitute und so
weiter — siehe die Erklärung zu ‘secret-root’ unten.

 -- Scheme-Variable: hurd-vm-service-type
     Dies ist der Diensttyp zum
     Hurd-in-einer-virtuellen-Maschine-Dienst. Dessen Wert muss ein
     ‘hurd-vm-configuration’-Objekt sein, das das Betriebssystem
     festlegt (siehe *note „operating-system“-Referenz::) und die
     Plattengröße für die virtuelle Hurd-Maschine, das zu nutzende
     QEMU-Paket sowie die Befehlszeilenoptionen, um sie auszuführen.

     Zum Beispiel:

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

     würde zur Erzeugung eines Disk-Images führen, dessen Größe für die
     Erstellung von GNU Hello ausreichend ist und das noch ein wenig
     zusätzlichen Arbeitsspeicher zur Verfügung stellt.

 -- Datentyp: hurd-vm-configuration
     Der Datentyp, der die Konfiguration des ‘hurd-vm-service-type’
     repräsentiert.

     ‘os’ (Vorgabe: %HURD-VM-OPERATING-SYSTEM)
          Welches Betriebssystem instanziiert werden soll. Nach Vorgabe
          wird ein minimales „Bare-Bones“-System mit uneingeschränktem
          OpenSSH-Secure-Shell-Daemon, der auf Port 2222 lauscht (siehe
          *note ‘openssh-service-type’: Netzwerkdienste.).

     ‘qemu’ (Vorgabe: ‘qemu-minimal’)
          Das QEMU-Paket, das benutzt werden soll.

     ‘image’ (Vorgabe: HURD-VM-DISK-IMAGE)
          Die Prozedur, um das Disk-Image aus dieser Konfiguration zu
          erstellen.

     ‘disk-size’ (Vorgabe: ‘'guess’)
          Die Größe des Disk-Images.

     ‘memory-size’ (Vorgabe: ‘512’)
          Die Größe des Arbeitsspeichers der virtuellen Maschine in
          Mebibyte.

     ‘options’ (Vorgabe: ‘'("--snapshot")’)
          Weitere Befehlszeilenoptionen, mit denen QEMU ausgeführt wird.

     ‘id’ (Vorgabe: ‘#f’)
          Wenn das Feld gesetzt ist, muss es eine positive ganze Zahl
          größer null sein, womit Childhurd-Instanzen parametrisiert
          werden. Es wird an den Dienstnamen angehängt, z.B.
          ‘childhurd1’.

     ‘net-options’ (Vorgabe: HURD-VM-NET-OPTIONS)
          Die Prozedur, um die Liste der QEMU-Netzwerkoptionen zu
          erzeugen.

          Nach Vorgabe liefert sie

               '("--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")

          mit Portweiterleitungen:

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

     ‘secret-root’ (Vorgabe: ‘/etc/childhurd’)
          Das Wurzelverzeichnis von Geheimnissen, die auf der Childhurd
          „out of band“, d.h. abseits vom Zuständigkeitsbereich der
          Childhurd, installiert werden sollen, sobald sie gestartet
          wurde. Childhurds sind flüchtig, d.h. bei jedem Start würden
          Geheimnisse wie die SSH-Host-Schlüssel und Signierschlüssel
          von Guix neu angelegt.

          Wenn das Verzeichnis ‘/etc/childhurd’ _nicht_ existiert, wird
          dem im Childhurd laufenden ‘secret-service’-Dienst eine leere
          Liste von Geheimnissen geschickt.

          Üblicherweise wird er benutzt, um in ‘"/etc/childhurd"’ einen
          Dateibaum aus _nicht_ flüchtigen Geheimnissen einzufügen, wenn
          diese noch _nicht_ existieren:

               /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

          Diese Dateien werden automatisch an die Gast-Hurd-VM
          geschickt, wenn sie bootet, einschließlich der
          Dateiberechtigungen.

          Wenn diese Dateien platziert wurden, fehlen nur noch wenige
          Dinge, damit das Wirtssystem ‘i586-gnu’-Erstellungen auf die
          Childhurd auslagern kann:

            1. Der Schlüssel der Childhurd muss auf dem Wirtssystem
               authentifiziert werden, damit das Wirtssystem von der
               Childhurd stammende Erstellungsergebnisse annimmt. Das
               geht so:

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

            2. Die Childhurd muss zu ‘/etc/guix/machines.scm’
               hinzugefügt werden (siehe *note Auslagern des Daemons
               einrichten::).

          Wir arbeiten daran, dass das automatisch passiert. Reden Sie
          mit uns unter <guix-devel@gnu.org>, wenn Sie dabei
          mitdiskuttieren möchten!

   Beachten Sie, dass nach Vorgabe ein flüchtiges Abbild für die
virtuelle Maschine benutzt wird, also dessen Inhalt verloren geht,
sobald sie gestoppt wurde. Wenn Sie stattdessen ein zustandsbehaftetes
Abbild möchten, ändern Sie die Felder ‘image’ und ‘options’ in der
Konfiguration, so dass keine ‘--snapshot’-Befehlszeilenoption übergeben
wird, z.B. so:

     (service hurd-vm-service-type
              (hurd-vm-configuration
               (image   (const "/nicht/im/store/mit/schreibzugriff/hurd.img"))
               (options '())))

Ganeti
......

     Anmerkung: Dieser Dienst gilt als experimentell. Die
     Konfigurationsoptionen könnten in Zukunft noch auf eine Weise
     abgeändert werden, die keine Kompatibilität mit dem momentanen
     Verhalten gewährleistet, und nicht alle Funktionalitäten wurden
     gründlich getestet. Wenn Sie ihn benutzen, ermutigen wir Sie, Ihre
     Erfahrungen mit uns über <guix-devel@gnu.org> zu teilen.

   Ganeti ist ein System zur Verwaltung virtueller Maschinen. Es ist
dafür gedacht, virtuelle Maschinen auf einem Server-Cluster am Laufen zu
halten, selbst wenn Hardware ausfällt, und deren Wartung und
Wiederherstellung einfach zu machen. Es besteht aus mehreren Diensten,
die später in diesem Abschnitt beschrieben werden. Zusätzlich zum
Ganeti-Dienst brauchen Sie den OpenSSH-Dienst (siehe *note
‘openssh-service-type’: Netzwerkdienste.) und müssen in die Datei
‘/etc/hosts’ (siehe *note ‘hosts-file’: „operating-system“-Referenz.)
den Namen des Clusters mit Adresse eintragen lassen (oder Sie verwenden
einen eigenen DNS-Server).

   Alle Knoten, die an einem Ganeti-Cluster teilnehmen, sollten dieselbe
Konfiguration von Ganeti und ‘/etc/hosts’ aufweisen. Hier ist eine
Beispielkonfiguration für einen Ganeti-Clusterknoten, der mehrere
Hintergrundsysteme für Speichergeräte unterstützt und die
“Betriebssystemanbieter” („OS providers“) ‘debootstrap’ sowie ‘guix’
installiert hat:

     (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
     ")))

       ;; QEMU installieren, damit wir auf KVM aufsetzende Instanzen benutzen
       ;; können, sowie LVM, DRBD und Ceph, damit wir die Speicher-Hintergrundsysteme
       ;; "plain", "drbd" und "rbd" benutzen können.
       (packages (append (map specification->package
                              '("qemu" "lvm2" "drbd-utils" "ceph"
                                ;; Betriebssystemanbieter debootstrap und 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 benutzt SSH für die Kommunikation zwischen Knoten.
                      (service openssh-service-type
                               (openssh-configuration
                                (permit-root-login 'without-password)))

                      (service ganeti-service-type
                               (ganeti-configuration
                                ;; Diese Liste führt die Pfade im Dateisystem auf,
                                ;; wo Abbilder virtueller Maschinen gespeichert
                                ;; werden.
                                (file-storage-paths '("/srv/ganeti/file-storage"))
                                ;; In dieser Variablen konfigurieren wir eine einzige
                                ;; „Variante“ jeweils für sowohl Debootstrap als auch
                                ;; Guix, die KVM benutzt.
                                (os %default-ganeti-os))))
                %base-services)))

   Benutzern wird geraten, die Anleitung für Ganeti-Administratoren
(http://docs.ganeti.org/ganeti/master/html/admin.html) zu lesen, um die
verschiedenen Optionen für Ganeti-Cluster und die häufigen Operationen
zu erlernen. Es gibt auch einen Blogeintrag
(https://guix.gnu.org/blog/2020/running-a-ganeti-cluster-on-guix/), der
beschreibt, wie man einen kleinen Cluster konfiguriert und
initialisiert.

 -- Scheme-Variable: ganeti-service-type
     Dieser Diensttyp umfasst all die verschiedenen Dienste, die auf
     Ganeti-Knoten ausgeführt werden sollen.

     Sein Wert ist ein ‘ganeti-configuration’-Objekt, das das Paket für
     den Betrieb über die Befehlszeile sowie die Konfiguration der
     einzelnen Daemons festlegt. Auch werden zulässige Pfade für die
     Speicherung in Dateien sowie verfügbare Gastbetriebssysteme über
     diesen Datentyp konfiguriert.

 -- Datentyp: ganeti-configuration
     Der ‘ganeti’-Dienst akzeptiert folgende Konfigurationsoptionen:

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Welches ‘ganeti’-Paket benutzt werden soll. Es wird ins
          Systemprofil installiert und macht die Befehlszeilenwerkzeuge
          ‘gnt-cluster’, ‘gnt-instance’ usw. verfügbar. Beachten Sie,
          dass der hier angegebene Wert keinen Einfluss auf die anderen
          Dienste hat; jeder legt sein eigenes ‘ganeti’-Paket fest
          (siehe unten).

     ‘noded-configuration’ (Vorgabe: ‘(ganeti-noded-configuration)’)
     ‘confd-configuration’ (Vorgabe: ‘(ganeti-confd-configuration)’)
     ‘wconfd-configuration’ (Vorgabe: ‘(ganeti-wconfd-configuration)’)
     ‘luxid-configuration’ (Vorgabe: ‘(ganeti-luxid-configuration)’)
     ‘rapi-configuration’ (Vorgabe: ‘(ganeti-rapi-configuration)’)
     ‘kvmd-configuration’ (Vorgabe: ‘(ganeti-kvmd-configuration)’)
     ‘mond-configuration’ (Vorgabe: ‘(ganeti-mond-configuration)’)
     ‘metad-configuration’ (Vorgabe: ‘(ganeti-metad-configuration)’)
     ‘watcher-configuration’ (Vorgabe: ‘(ganeti-watcher-configuration)’)
     ‘cleaner-configuration’ (Vorgabe: ‘(ganeti-cleaner-configuration)’)

          Mit diesen Optionen stellen Sie die verschiedenen Daemons und
          Cron-Aufträge ein, die mit Ganeti eingerichtet werden. Die
          möglichen Werte dafür werden im Folgenden genau beschrieben.
          Um eine Einstellung zu ändern, müssen Sie den
          Konfigurationstyp für den jeweiligen Dienst verwenden:

               (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’ (Vorgabe: ‘'()’)
          Liste zulässiger Verzeichnisse für das in Dateien speichernde
          Hintergrundsystem („File Storage Backend“).

     ‘os’ (Vorgabe: ‘%default-ganeti-os’)
          Liste von ‘<ganeti-os>’-Verbundsobjekten.

     Im Kern ist ‘ganeti-service-type’ eine Kurzform davon, jeden Dienst
     einzeln zu deklarieren:

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

     Außerdem enthalten ist eine Diensterweiterung für den
     ‘etc-service-type’, der das Hintergrundsystem für die Speicherung
     in Dateien und die Betriebssystemvarianten festlegt.

 -- Datentyp: ganeti-os
     Dieser Datentyp wird verwendet, um ihn an den ‘os’-Parameter der
     ‘ganeti-configuration’ zu übergeben. Er umfasst die folgenden
     Parameter:

     ‘name’
          Der Name dieses Betriebssystemanbieters. Sein einziger Zweck
          ist, anzugeben, wohin die Konfigurationsdateien geschrieben
          werden. Wird „debootstrap“ angegeben, wird
          ‘/etc/ganeti/instance-debootstrap’ erstellt.

     ‘extension’
          Welche Dateinamenserweiterung die Varianten dieser Art von
          Betriebssystem benutzen, zum Beispiel ‘.conf’ oder ‘.scm’.

     ‘variants’ (Vorgabe: ‘'()’)
          Die Liste der ‘ganeti-os-variant’-Objekte für dieses
          Betriebssystem.

 -- Datentyp: ganeti-os-variant
     Der Datentyp für eine Variante einer Art von Betriebssystem. Er
     nimmt die folgenden Parameter:

     ‘name’
          Der Name dieser Variante.

     ‘configuration’
          Eine Konfigurationsdatei für diese Variante.

 -- Scheme-Variable: %default-debootstrap-hooks
     Diese Variable enthält Anknüpfungspunkte („Hooks“), um das Netzwerk
     zu konfigurieren und den GRUB-Bootloader einzurichten.

 -- Scheme-Variable: %default-debootstrap-extra-pkgs
     Diese Variable führt eine Liste von Paketen auf, die für ein
     gänzlich virtualisiertes Gastsystem sinnvoll sind.

 -- Datentyp: debootstrap-configuration

     Mit diesem Datentyp werden Konfigurationsdateien erzeugt, die für
     den debootstrap-Betriebssystemanbieter geeignet sind.

     ‘hooks’ (Vorgabe: ‘%default-debootstrap-hooks’)
          Wenn es nicht auf ‘#f’ steht, muss hier ein G-Ausdruck
          angegeben werden, der ein Verzeichnis mit Scripts (sogenannten
          „Hooks“, d.h. Anknüpfungspunkte) festlegt, welche bei der
          Installation des Betriebssystems ausgeführt werden. Es kann
          auch eine Liste von Paaren der Form ‘(Name .
          dateiartiges-Objekt)’ angegeben werden. Zum Beispiel:

               `((99-hallo-welt . ,(plain-file "#!/bin/sh\necho Hallo Welt")))

          Damit wird ein Verzeichnis mit einer ausführbaren Datei namens
          ‘99-hallo-welt’ festgelegt, die jedes Mal ausgeführt wird,
          wenn diese Variante installiert wird. Wird hier ‘#f’
          angegeben, werden die in
          ‘/etc/ganeti/instance-debootstrap/hooks’ vorgefundenen
          Anknüpfungspunkte benutzt, falls vorhanden.
     ‘proxy’ (Vorgabe: ‘#f’)
          Optional; welcher HTTP-Proxy genutzt werden soll.
     ‘mirror’ (Vorgabe: ‘#f’)
          Der Spiegelserver für Debian. Üblicherweise wird etwas wie
          ‘http://ftp.no.debian.org/debian’ angegeben. Die
          Voreinstellung hängt von der Distribution ab.
     ‘arch’ (Vorgabe: ‘#f’)
          Die dpkg-Architektur. Setzen Sie dies z.B. auf ‘armhf’, um
          eine ARMv7-Instanz auf einem AArch64-Wirtssystem via
          debootstrap einzurichten. Bei der Vorgabeeinstellung wird die
          aktuelle Systemarchitektur übernommen.
     ‘suite’ (Vorgabe: ‘"stable"’)
          Wenn dieses Feld gesetzt ist, muss dafür eine
          Debian-Distributions-„Suite“ wie ‘buster’ oder ‘focal’
          angegeben werden. Steht es auf ‘#f’, wird die Voreinstellung
          für den Betriebssystemanbieter benutzt.
     ‘extra-pkgs’ (Vorgabe: ‘%default-debootstrap-extra-pkgs’)
          Liste zusätzlicher Pakete, die durch dpkg zusätzlich zum
          minimalen System installiert werden.
     ‘components’ (Vorgabe: ‘#f’)
          Ist dies gesetzt, muss es eine Liste von Bereichen eines
          Debian-Repositorys sein, etwa ‘'("main" "contrib")’.
     ‘generate-cache?’ (Vorgabe: ‘#t’)
          Ob das generierte debootstrap-Archiv automatisch
          zwischengespeichert werden soll.
     ‘clean-cache’ (Vorgabe: ‘14’)
          Nach wie vielen Tagen der Zwischenspeicher verworfen werden
          soll. Geben Sie ‘#f’ an, damit der Zwischenspeicher niemals
          bereinigt wird.
     ‘partition-style’ (Vorgabe: ‘'msdos’)
          Der Partitionstyp der anzulegenden Partition. Wenn er
          festgelegt ist, muss er entweder ‘'msdos’ oder ‘'none’ lauten
          oder eine Zeichenkette angegeben werden.
     ‘partition-alignment’ (Vorgabe: ‘2048’)
          Auf wie viele Sektoren die Partition ausgerichtet werden soll.

 -- Scheme-Prozedur: debootstrap-variant NAME KONFIGURATION
     Diese Hilfsprozedur erzeugt ein ‘ganeti-os-variant’-Verbundsobjekt.
     Sie nimmt zwei Parameter entgegen: einen Namen und ein
     ‘debootstrap-configuration’-Objekt.

 -- Scheme-Prozedur: debootstrap-os VARIANTEN…
     Diese Hilfsprozedur erzeugt ein ‘ganeti-os’-Verbundsobjekt. Sie
     nimmt eine Liste von mit ‘debootstrap-variant’ erzeugten Varianten
     entgegen.

 -- Scheme-Prozedur: guix-variant NAME KONFIGURATION
     Diese Hilfsprozedur erzeugt ein ‘ganeti-os-variant’-Verbundsobjekt,
     das für den vorgegebenen Guix-Betriebssystemanbieter gedacht ist.
     Als Parameter anzugeben sind ein Name und ein G-Ausdruck, der ein
     „dateiartiges“ Objekt (siehe *note dateiartige Objekte:
     G-Ausdrücke.) mit einer Konfiguration für Guix System liefert.

 -- Scheme-Prozedur: guix-os VARIANTEN…
     Diese Hilfsprozedur erzeugt ein ‘ganeti-os’-Verbundsobjekt. Sie
     nimmt eine Liste von durch ‘guix-variant’ erzeugten Varianten
     entgegen.

 -- Scheme-Variable: %default-debootstrap-variants
     Zur Erleichterung kann diese Variable benutzt werden, damit der
     debootstrap-Anbieter sofort funktioniert, ohne dass seine Nutzer
     Varianten selbst deklarieren müssen. Enthalten ist eine einzige
     debootstrap-Variante mit der Standardkonfiguration:

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

 -- Scheme-Variable: %default-guix-variants
     Zur Erleichterung kann diese Variable benutzt werden, damit der
     Guix-Betriebssystemanbieter sofort und ohne weitere Konfiguration
     funktioniert. Damit wird eine virtuelle Maschine mit einem
     SSH-Server, einer seriellen Konsole und bereits autorisierten
     Ganeti-Wirts-SSH-Schlüsseln erzeugt.

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

   Benutzer können die Unterstützung für Guix _nicht_ bekannte
Betriebssystemanbieter implementieren, indem sie entsprechende
Erweiterungen für die ‘ganeti-os’- und ‘ganeti-os-variant’-Verbundstypen
implementieren. Ein Beispiel:

     (ganeti-os
      (name "eigenes-os")
      (extension ".conf")
      (variants
       (list (ganeti-os-variant
              (name "foo")
              (configuration (plain-file "bar" "das genügt"))))))

   Damit wird ‘/etc/ganeti/instance-eigenes-os/variants/foo.conf’
erzeugt, das auf eine Datei im Store mit dem Inhalt ‘das genügt’
verweist. Außerdem wird
‘/etc/ganeti/instance-eigenes-os/variants/variants.list’ mit dem Inhalt
‘foo’ erzeugt.

   Natürlich kann man Betriebssystemanbieter finden, für die das nicht
ausreicht. Wenn Sie sich durch die Schnittstelle in Ihren Möglichkeiten
eingeschränkt fühlen, schreiben Sie bitte an <guix-devel@gnu.org>.

   Der übrige Teil dieses Abschnitts beschreibt die verschiedenen
Dienste, aus denen sich der ‘ganeti-service-type’ zusammensetzt.

 -- Scheme-Variable: ganeti-noded-service-type
     ‘ganeti-noded’ ist der Daemon, der für knotenbezogene Funktionen
     des Ganeti-Systems da ist. Sein Wert muss ein
     ‘ganeti-noded-configuration’-Objekt sein.

 -- Datentyp: ganeti-noded-configuration
     Dies ist die Konfiguration des ‘ganeti-noded’-Dienstes für Ganetis
     Knoten-Daemon.

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘port’ (Vorgabe: ‘8081’)
          Der TCP-Port, auf dem der Knoten-Daemon (‘noded’) auf
          Netzwerkanfragen lauscht.

     ‘address’ (Vorgabe: ‘"0.0.0.0"’)
          An welche Netzwerkadresse sich der Daemon binden wird. Die
          Vorgabeeinstellung bedeutet, sich an alle verfügbaren Adressen
          zu binden.

     ‘interface’ (Vorgabe: ‘#f’)
          Wenn dieses Feld gesetzt ist, muss es eine bestimmte
          Netzwerkschnittstelle angeben (z.B. ‘eth0’), an die sich der
          Daemon binden wird.

     ‘max-clients’ (Vorgabe: ‘20’)
          Legt eine Maximalzahl gleichzeitiger Client-Verbindungen fest,
          um die sich der Daemon kümmert. Darüber hinaus werden
          Verbindungen zwar akzeptiert, aber erst beantwortet, wenn
          genügend viele Verbindungen wieder geschlossen wurden.

     ‘ssl?’ (Vorgabe: ‘#t’)
          Ob SSL/TLS benutzt werden soll, um Netzwerkkommunikation zu
          verschlüsseln. Das Zertifikat wird automatisch vom Cluster
          eingespielt und kann über ‘gnt-cluster renew-crypto’ rotiert
          werden.

     ‘ssl-key’ (Vorgabe: ‘"/var/lib/ganeti/server.pem"’)
          Hiermit kann ein bestimmter Schlüssel für mit TLS
          verschlüsselte Kommunikation festgelegt werden.

     ‘ssl-cert’ (Vorgabe: ‘"/var/lib/ganeti/server.pem"’)
          Hiermit kann ein bestimmtes Zertifikat für mit TLS
          verschlüsselte Kommunikation festgelegt werden.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht dies auf wahr, führt der Daemon zum Zweck der
          Fehlersuche ausführlichere Protokolle. Beachten Sie, dass
          dadurch Details der Verschlüsselung in die Protokolldateien
          fließen können. Seien Sie vorsichtig!

 -- Scheme-Variable: ganeti-confd-service-type
     ‘ganeti-confd’ beantwortet Anfragen, die mit der Konfiguration
     eines Ganeti-Clusters zu tun haben. Der Zweck dieses Daemons ist,
     eine hochverfügbare und schnelle Methode zum Anfragen von
     Cluster-Konfigurationswerten zu bieten. Er wird automatisch auf
     allen Kandidaten für die Rolle des „Master“-Knotens aktiviert. Der
     Wert dieses Dienstes muss ein ‘ganeti-confd-configuration’-Objekt
     sein.

 -- Datentyp: ganeti-confd-configuration
     Dies ist die Konfiguration des ‘ganeti-confd’-Dienstes.

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘port’ (Vorgabe: ‘8081’)
          Der UDP-Port, auf dem auf Netzwerkanfragen gelauscht werden
          soll.

     ‘address’ (Vorgabe: ‘"0.0.0.0"’)
          An welche Netzwerkadresse sich der Daemon binden soll.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-wconfd-service-type
     ‘ganeti-wconfd’ ist der Daemon, der mit autoritativem Wissen über
     die Cluster-Konfiguration ausgestattet ist, und die einzige
     Entität, die Änderungen daran akzeptieren kann. Alle Aufträge, die
     die Konfiguration ändern müssen, tun dies, indem sie entsprechende
     Anfragen an den Daemon stellen. Er läuft nur auf dem
     „Master“-Knoten und deaktiviert sich auf allen anderen Knoten
     automatisch.

     Der Wert dieses Dienstes muss ein
     ‘ganeti-wconfd-configuration’-Objekt sein.

 -- Datentyp: ganeti-wconfd-configuration
     Dies ist die Konfiguration des ‘ganeti-wconfd’-Dienstes.

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘no-voting?’ (Vorgabe: ‘#f’)
          Der Daemon wird das Starten verweigern, sofern die Mehrheit
          der Knoten _nicht_ anerkennt, dass er auf dem Master-Knoten
          läuft. Setzen Sie dies auf ‘#t’, um ihn selbst dann zu
          starten, wenn sich keine Mehrheit dafür findet (das ist
          gefährlich; hoffentlich wissen Sie, was Sie tun).

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-luxid-service-type
     Der Daemon ‘ganeti-luxid’ ist dazu da, Anfragen zur Konfiguration
     und zum aktuellen Zustand des laufenden Ganeti-Clusters zu
     beantworten. Des Weiteren ist es der autoritative Daemon für
     Ganetis Auftragsliste. Aufträge können über diesen Daemon
     eingereicht werden und werden von ihm geplant und gestartet.

     Er nimmt ein ‘ganeti-luxid-configuration’-Objekt entgegen.

 -- Datentyp: ganeti-luxid-configuration
     Dies ist die Konfiguration des ‘ganeti-wconfd’-Dienstes.

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘no-voting?’ (Vorgabe: ‘#f’)
          Der Daemon verweigert das Starten, wenn er sich nicht sicher
          sein kann, dass die Mehrheit der Cluster-Knoten überzeugt ist,
          dass er auf dem Master-Knoten läuft. Setzen Sie dies auf ‘#t’,
          um solche Hinweise zu ignorieren (das kann gefährlich sein!).

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-rapi-service-type
     ‘ganeti-rapi’ bietet eine Schnittstelle für entfernte Aufrufe
     (englisch “Remote API”) für Ganeti-Cluster. Sie läuft auf dem
     Master-Knoten und mit ihr können Aktionen auf dem Cluster
     programmatisch mittels eines JSON-basierten Protokolls für
     entfernte Prozeduraufrufe durchgeführt werden.

     Die meisten Anfrageoperationen werden ohne Authentisierung
     zugelassen (außer wenn REQUIRE-AUTHENTICATION? gesetzt ist),
     wohingegen Schreibzugriffe einer ausdrücklichen Authentisierung
     durch die Datei ‘/var/lib/ganeti/rapi/users’ bedürfen. Siehe die
     Dokumentation der Ganeti Remote API
     (http://docs.ganeti.org/ganeti/master/html/rapi.html) für mehr
     Informationen.

     Der Wert dieses Dienstes muss ein
     ‘ganeti-rapi-configuration’-Objekt sein.

 -- Datentyp: ganeti-rapi-configuration
     Dies ist die Konfiguration des ‘ganeti-rapi’-Dienstes.

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘require-authentication?’ (Vorgabe: ‘#f’)
          Ob selbst für Nur-Lese-Operationen eine Authentisierung
          verlangt werden soll.

     ‘port’ (Vorgabe: ‘5080’)
          Der TCP-Port, auf dem auf API-Anfragen gelauscht werden soll.

     ‘address’ (Vorgabe: ‘"0.0.0.0"’)
          An welche Netzwerkadresse sich der Dienst binden soll. Nach
          Vorgabe wird auf allen konfigurierten Adressen gelauscht.

     ‘interface’ (Vorgabe: ‘#f’)
          Wenn dies gesetzt ist, muss es eine bestimmte
          Netzwerkschnittstelle angeben wie z.B. ‘eth0’, an die sich der
          Daemon binden wird.

     ‘max-clients’ (Vorgabe: ‘20’)
          Die Maximalzahl gleichzeitiger Verbindungen, um die sich der
          Dienst kümmern darf. Weitere Verbindungen sind möglich, über
          sie wird aber erst dann geantwortet, wenn genügend viele
          Verbindungen wieder geschlossen wurden.

     ‘ssl?’ (Vorgabe: ‘#t’)
          Ob SSL-/TLS-Verschlüsselung auf dem RAPI-Port eingesetzt
          werden soll.

     ‘ssl-key’ (Vorgabe: ‘"/var/lib/ganeti/server.pem"’)
          Hiermit kann ein bestimmter Schlüssel für mit TLS
          verschlüsselte Kommunikation festgelegt werden.

     ‘ssl-cert’ (Vorgabe: ‘"/var/lib/ganeti/server.pem"’)
          Hiermit kann ein bestimmtes Zertifikat für mit TLS
          verschlüsselte Kommunikation festgelegt werden.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht dies auf wahr, führt der Daemon zum Zweck der
          Fehlersuche ausführlichere Protokolle. Beachten Sie, dass
          dadurch Details der Verschlüsselung in die Protokolldateien
          fließen können. Seien Sie vorsichtig!

 -- Scheme-Variable: ganeti-kvmd-service-type
     ‘ganeti-kvmd’ ist dafür verantwortlich, festzustellen, wenn eine
     gegebene KVM-Instanz durch einen Administrator oder Nutzer
     geschlossen wurde. Normalerweise wird Ganeti Instanzen neu starten,
     die nicht über ihn selbst gestoppt wurden. Wenn die Cluster-Option
     ‘user_shutdown’ wahr ist, beobachtet der Daemon den durch QEMU
     bereitgestellten ‘QMP’-Socket und lauscht auf Abschalteereignisse.
     Solche Instanzen werden von ihm als durch den Benutzer
     heruntergefahren (“USER_down”) markiert statt als durch Fehler
     beendet (“ERROR_down”), wenn sie von selbst ordnungsgemäß
     heruntergefahren sind.

     Der Dienst benutzt ein ‘ganeti-kvmd-configuration’-Objekt.

 -- Datentyp: ganeti-kvmd-configuration

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-mond-service-type
     ‘ganeti-mond’ ist ein optionaler Daemon, mit dem Ganetis
     Überwachungsfunktionalität gewährleistet wird. Er ist dafür
     verantwortlich, Datensammler auszuführen und die gesammelten
     Informationen über eine HTTP-Schnittstelle bereitzustellen.

     Der Dienst benutzt ein ‘ganeti-mond-configuration’-Objekt.

 -- Datentyp: ganeti-mond-configuration

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘port’ (Vorgabe: ‘1815’)
          Der Port, auf dem der Daemon lauschen wird.

     ‘address’ (Vorgabe: ‘"0.0.0.0"’)
          Die Netzwerkadresse, an die sich der Daemon binden soll, nach
          Vorgabe an alle verfügbaren.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-metad-service-type
     ‘ganeti-metad’ ist ein optionaler Daemon, der benutzt werden kann,
     um Informationen über den Cluster an Instanzen oder an
     Betriebssysteminstallationsskripte weiterzugeben.

     Dazu nimmt er ein ‘ganeti-metad-configuration’-Objekt.

 -- Datentyp: ganeti-metad-configuration

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘port’ (Vorgabe: ‘80’)
          Der Port, auf dem der Daemon lauschen wird.

     ‘address’ (Vorgabe: ‘#f’)
          Wenn es gesetzt ist, wird sich der Daemon nur an diese Adresse
          binden. Ist es _nicht_ gesetzt, hängt das Verhalten von der
          Cluster-Konfiguration ab.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht es auf wahr, wird der Daemon zum Zweck der Fehlersuche
          ausführlicher protokollieren.

 -- Scheme-Variable: ganeti-watcher-service-type
     ‘ganeti-watcher’ ist ein Skript, das dafür gedacht ist, regelmäßig
     ausgeführt zu werden und die Verfügbarkeit des Clusters
     sicherzustellen. Instanzen, die ohne Ganetis Zustimmung abgebrochen
     sind, werden durch es automatisch neu gestartet und
     DRBD-Verbindungen werden repariert, wenn ein Knoten neu gestartet
     wurde. Außerdem werden alte Cluster-Aufträge archiviert und nicht
     laufende Ganeti-Daemons erneut gestartet. Wenn der
     Cluster-Parameter ‘ensure_node_health’ gesetzt ist, wird der
     Watcher auch Instanzen und DRBD-Geräte herunterfahren, wenn der
     Knoten zwar läuft, aber von bekannten Kandidaten auf die Rolle des
     Master-Knotens als offline deklariert wurde.

     Er kann mit ‘gnt-cluster watcher pause’ auf allen Knoten pausiert
     werden.

     Der Dienst benutzt ein ‘ganeti-watcher-configuration’-Objekt.

 -- Datentyp: ganeti-watcher-configuration

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Das ‘ganeti’-Paket, was für diesen Dienst benutzt werden soll.

     ‘schedule’ (Vorgabe: ‘'(next-second-from (next-minute (range 0 60 5)))’)
          Wie oft das Skript ausgeführt werden soll. Nach Vorgabe läuft
          es alle fünf Minuten.

     ‘rapi-ip’ (Vorgabe: ‘#f’)
          Diese Option muss nur dann angegeben werden, wenn der
          RAPI-Daemon so konfiguriert wurde, dass er eine bestimmte
          Schnittstelle oder Adresse verwenden soll. Nach Vorgabe wird
          die Adresse des Clusters verwendet.

     ‘job-age’ (Vorgabe: ‘(* 6 3600)’)
          Cluster-Aufträge archivieren, die älter als diese Anzahl
          Sekunden sind. Die Vorgabe beträgt 6 Stunden. Dadurch wird
          gewährleistet, dass man ‘gnt-job list’ noch sinnvoll bedienen
          kann.

     ‘verify-disks?’ (Vorgabe: ‘#t’)
          Steht dies auf ‘#f’, wird der Watcher _nicht_ versuchen,
          fehlgeschlagene DRBD-Verbindungen automatisch zu reparieren.
          Administratoren müssen stattdessen ‘gnt-cluster verify-disks’
          manuell aufrufen.

     ‘debug?’ (Vorgabe: ‘#f’)
          Steht dies auf ‘#t’, so führt das Skript zum Zweck der
          Fehlersuche ausführlichere Protokolle.

 -- Scheme-Variable: ganeti-cleaner-service-type
     ‘ganeti-cleaner’ ist ein Skript, das regelmaßig ausgeführt werden
     soll, um alte Dateien vom Cluster zu entfernen. Dieser Diensttyp
     steuert zwei “cron-Aufträge” (“cron jobs”): einer, um alte
     Cluster-Aufträge auf dem Master-Knoten andauernd zu löschen, und
     einer, der auf allen Knoten ausgelaufene X509-Zertifikate,
     -Schlüssel sowie veraltete Informationen des ‘ganeti-watcher’
     entfernt. Wie alle Ganeti-Dienste kann man ihn ohne Probleme auch
     auf Nicht-Master-Knoten in die Konfiguration mit aufnehmen, denn er
     deaktiviert sich selbst, wenn er nicht gebraucht wird.

     Der Dienst benutzt ein ‘ganeti-cleaner-configuration’-Objekt.

 -- Datentyp: ganeti-cleaner-configuration

     ‘ganeti’ (Vorgabe: ‘ganeti’)
          Welches ‘ganeti’-Paket für den Befehl ‘gnt-cleaner’ benutzt
          werden soll.

     ‘master-schedule’ (Vorgabe: ‘"45 1 * * *"’)
          Wie oft der Bereinigungsauftrag für den Master durchgeführt
          werden soll. Vorgegeben ist einmal täglich um 01:45:00 Uhr.

     ‘node-schedule’ (Vorgabe: ‘"45 2 * * *"’)
          Wie oft der Bereinigungsauftrag für Knoten durchgeführt werden
          soll. Vorgegeben ist einmal täglich um 02:45:00 Uhr.


File: guix.de.info,  Node: Versionskontrolldienste,  Next: Spieldienste,  Prev: Virtualisierungsdienste,  Up: Dienste

10.8.27 Versionskontrolldienste
-------------------------------

Das Modul ‘(gnu services version-control)’ stellt einen Dienst zur
Verfügung, der einen Fernzugriff auf lokale Git-Repositorys ermöglicht.
Dafür gibt es drei Möglichkeiten: den ‘git-daemon-service’, der Zugang
zu Repositorys über das ungesicherte, TCP-basierte ‘git://’-Protokoll
gewährt, das Erweitern des ‘nginx’-Webservers, um ihn als Proxy für
Anfragen an das ‘git-http-backend’ einzusetzen, oder mit dem
‘cgit-service-type’ eine Weboberfläche zur Verfügung zu stellen.

 -- Scheme-Prozedur: git-daemon-service [#:config
          (git-daemon-configuration)]

     Liefert einen Dienst, der ‘git daemon’ ausführt. Der Befehl startet
     den Git-Daemon, einen einfachen TCP-Server, um Repositorys über das
     Git-Protokoll für anonymen Zugriff zugänglich zu machen.

     Das optionale Argument CONFIG sollte ein
     ‘<git-daemon-configuration>’-Objekt sein. Nach Vorgabe wird
     Lese-Zugriff auf exportierte(1) Repositorys in ‘/srv/git’ gewährt.

 -- Datentyp: git-daemon-configuration
     Datentyp, der die Konfiguration für ‘git-daemon-service’
     repräsentiert.

     ‘package’ (Vorgabe: ‘git’)
          Paketobjekt des verteilten Versionskontrollsystems Git.

     ‘export-all?’ (Vorgabe: ‘#f’)
          Ob Zugriff auf alle Git-Repositorys gewährt werden soll,
          selbst wenn keine ‘git-daemon-export-ok’-Datei in ihrem
          Verzeichnis gefunden wird.

     ‘base-path’ (Vorgabe: ‘/srv/git’)
          Ob alle Pfadanfragen behandelt werden sollen, als wären sie
          relativ zum angegebenen Pfad. Wenn Sie ‘git daemon’ mit
          ‘(base-path "/srv/git")’ auf ‘example.com’ ausführen und
          später versuchen, ‘git://example.com/hello.git’ zu pullen,
          wird der Git-Daemon den Pfad als ‘/srv/git/hello.git’
          interpretieren.

     ‘user-path’ (Vorgabe: ‘#f’)
          Ob die ‘~benutzerkonto’-Notation in Anfragen verwendet werden
          darf. Wird hier die leere Zeichenkette angegeben, werden
          Anfragen an ‘git://host/~alice/foo’ als Anfragen verstanden,
          auf das ‘foo’-Repository im Persönlichen Verzeichnis des
          ‘alice’-Benutzerkontos verstanden. Wird ‘(user-path "pfad")’
          angegeben, wird dieselbe Anfrage als eine Anfrage verstanden,
          auf das ‘PFAD/foo’-Repository im Persönlichen Verzeichnis des
          ‘alice’-Benutzerkontos zuzugreifen.

     ‘listen’ (Vorgabe: ‘'()’)
          Ob auf bestimmte IP-Adressen oder Rechnernamen („Hostnames“)
          gelauscht werden soll. Vorgegeben ist auf allen.

     ‘port’ (Vorgabe: ‘#f’)
          Ob auf einer alternativen Portnummer gelauscht werden soll.
          Vorgegeben ist 9418.

     ‘whitelist’ (Vorgabe: ‘'()’)
          Wenn dies nicht leer gelassen wird, wird nur der Zugriff auf
          die aufgelisteten Verzeichnisse gewährt.

     ‘extra-options’ (Vorgabe: ‘'()’)
          Zusätzliche Befehlszeilenoptionen, die dem ‘git daemon’
          mitgegeben werden sollen. Bitte führen Sie ‘man git-daemon’
          aus, um weitere Informationen zu erhalten.

   Zugriffe über das ‘git://’-Protokoll werden nicht authentifiziert.
Wenn Sie von einem Repository pullen, dass Sie über ‘git://’ geholt
haben, wissen Sie nicht, ob die empfangenen Daten modifiziert wurden
oder auch nur vom angegebenen Rechner kommen, und Ihre Verbindung kann
abgehört werden. Es ist besser, eine authentifizierte und verschlüsselte
Übertragungsart zu verwenden, zum Beispiel ‘https’. Obwohl Git es Ihnen
ermöglicht, Repositorys über schlichte dateibasierte Webserver
anzubieten, gibt es ein schnelleres Protokoll, das vom
‘git-http-backend’-Programm implementiert wird. Dieses Programm dient
als Hintergrundsystem für einen ordentlichen Git-Webdienst. Es wurde so
konstruiert, dass es über einen FastCGI-Proxy abrufbar ist. Siehe *note
Web-Dienste:: für weitere Informationen, wie Sie den benötigten
‘fcgiwrap’-Daemon ausführen.

   Guix hat einen separaten Konfigurationsdatentyp, um Git-Repositorys
über HTTP anzubieten.

 -- Datentyp: git-http-configuration
     Datentyp, der in Zukunft die Konfiguration eines
     ‘git-http-service-type’ repräsentieren soll; zurzeit kann damit
     Nginx über ‘git-http-nginx-location-configuration’ eingerichtet
     werden.

     ‘package’ (Vorgabe: GIT)
          Paketobjekt des verteilten Versionskontrollsystems Git.

     ‘git-root’ (Vorgabe: ‘/srv/git’)
          Das Verzeichnis, das die Git-Repositorys enthält, die der
          Allgemeinheit zugänglich gemacht werden sollen.

     ‘export-all?’ (Vorgabe: ‘#f’)
          Ob alle Git-Repositorys in GIT-ROOT zugänglich gemacht werden
          sollen, selbst wenn keine ‘git-daemon-export-ok’-Datei in
          ihrem Verzeichnis gefunden wird.

     ‘uri-path’ (Vorgabe: ‘/git/’)
          Präfix für Pfade beim Git-Zugriff. Beim vorgegebenen Präfix
          ‘/git/’ wird ‘http://SERVER/git/REPO.git’ auf
          ‘/srv/git/REPO.git’ abgebildet. Anfragen, deren URI-Pfade
          nicht mit dem Präfix beginnen, werden nicht an die Git-Instanz
          weitergereicht.

     ‘fcgiwrap-socket’ (Vorgabe: ‘127.0.0.1:9000’)
          Der Socket, auf dem der ‘fcgiwrap’-Daemon lauscht. Siehe *note
          Web-Dienste::.

   Es gibt zurzeit keinen ‘git-http-service-type’, stattdessen können
Sie eine ‘nginx-location-configuration’ aus einer
‘git-http-configuration’ heraus erstellen und als Location zu einem
Webserver hinzufügen.

 -- Scheme-Prozedur: git-http-nginx-location-configuration
          [config=(git-http-configuration)] Eine
          ‘nginx-location-configuration’
     berechnen, die der angegebenen Git-HTTP-Konfiguration entspricht.
     Ein Beispiel für eine nginx-Dienstdefinition, um das vorgegebene
     ‘/srv/git’-Verzeichnis über HTTPS anzubieten, könnte so aussehen:

          (service nginx-service-type
                   (nginx-configuration
                    (server-blocks
                     (list
                      (nginx-server-configuration
                       (listen '("443 ssl"))
                       (server-name "git.mein-rechner.org")
                       (ssl-certificate
                        "/etc/letsencrypt/live/git.mein-rechner.org/fullchain.pem")
                       (ssl-certificate-key
                        "/etc/letsencrypt/live/git.mein-rechner.org/privkey.pem")
                       (locations
                        (list
                         (git-http-nginx-location-configuration
                          (git-http-configuration (uri-path "/"))))))))))

     Für dieses Beispiel nehmen wir an, dass Sie Ihr TLS-Zertifikat über
     Let’s Encrypt beziehen. Siehe *note Zertifikatsdienste::. Der
     vorgegebene ‘certbot’-Dienst leitet alle HTTP-Anfragen nach
     ‘git.mein-rechner.org’ auf HTTPS um. Zu Ihren Systemdiensten werden
     Sie auch einen ‘fcgiwrap’-Proxy hinzufügen müssen. Siehe *note
     Web-Dienste::.

Cgit-Dienst
...........

Cgit (https://git.zx2c4.com/cgit/) ist eine in C geschriebene
Weboberfläche als Vordergrundsystem für Git-Repositorys.

   Im folgenden Beispiel wird der Dienst mit den vorgegebenen Werten
eingerichtet. Nach Vorgabe kann auf Cgit auf Port 80 unter
‘http://localhost:80’ zugegriffen werden.

     (service cgit-service-type)

   Der Typ ‘Dateiobjekt’ bezeichnet entweder ein dateiartiges Objekt
(siehe *note dateiartige Objekte: G-Ausdrücke.) oder eine Zeichenkette.

   Verfügbare ‘cgit-configuration’-Felder sind:

 -- ‘cgit-configuration’-Parameter: „package“ package
     Das CGIT-Paket.

 -- ‘cgit-configuration’-Parameter: „nginx-server-configuration-list“
          nginx
     NGINX-Konfiguration.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt about-filter
     Gibt einen Befehl an, der zur Formatierung des Inhalts der
     Übersichtsseiten aufgerufen wird (sowohl auf oberster Ebene und für
     jedes Repository).

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette agefile
     Gibt einen Pfad relativ zu jedem Repository-Pfad an, unter dem eine
     Datei gespeichert sein kann, die Datum und Uhrzeit des jüngsten
     Commits im Repository angibt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt auth-filter
     Gibt einen Befehl an, der aufgerufen wird, um Benutzer zu
     authentifizieren.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette branch-sort
     Wenn diese Option auf ‘age’ gesetzt wurde, wird die Liste der
     Branch-Referenzen nach Datum sortiert, und wenn sie auf ‘name’
     gesetzt wurde, wird nach dem Branch-Namen sortiert.

     Die Vorgabe ist ‘"name"’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette cache-root
     Pfad, unter dem Cgit-Zwischenspeichereinträge abgelegt werden.

     Die Vorgabe ist ‘"/var/cache/cgit"’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-static-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherungen für
     Repository-Seiten mit fester SHA1-Summe gültig bleiben, auf die
     zugegriffen wird („Time-to-live“).

     Die Vorgabe ist ‘-1’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-dynamic-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherungen für
     Repository-Seiten mit veränderlicher SHA1-Summe gültig bleiben, auf
     die zugegriffen wird.<

     Die Vorgabe ist ‘5’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-repo-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherungen für
     die Übersichtsseiten („summary“) von Repositorys gültig bleiben.

     Die Vorgabe ist ‘5’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-root-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherung der
     Seite mit dem Repository-Index gültig bleibt.

     Die Vorgabe ist ‘5’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-scanrc-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherung des
     Ergebnisses einer Suche in einem Pfad nach Git-Repositorys gültig
     bleibt.

     Die Vorgabe ist ‘15’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-about-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherungen für
     die Beschreibungsseiten („about“) von Repositorys gültig bleiben.

     Die Vorgabe ist ‘15’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-snapshot-ttl
     Zahl, die angibt, wie viele Minuten die Zwischenspeicherungen für
     die Snapshots von Repositorys gültig bleiben.

     Die Vorgabe ist ‘5’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl cache-size
     Wie viele Einträge der Cgit-Zwischenspeicher höchstens haben kann.
     Wird ‘0’ festgelegt, wird _nicht_ zwischengespeichert.

     Die Vorgabe ist ‘0’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          case-sensitive-sort?
     Ob beim Sortieren von Objekten in der Repository-Liste die
     Groß-/Kleinschreibung beachtet werden soll.

     Die Vorgabe ist ‘#t’.

 -- ‘cgit-configuration’-Parameter: Liste clone-prefix
     Liste gemeinsamer Präfixe, von denen ein Repository geklont werden
     kann. D.h. dass, wenn eines mit einer Repository-URL kombiniert
     wird, eine gültige URL zum Klonen des Repositorys entsteht.

     Die Vorgabe ist ‘()’.

 -- ‘cgit-configuration’-Parameter: Liste clone-url
     Liste von Schablonen, aus denen eine ‘clone-url’ entsteht.

     Die Vorgabe ist ‘()’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt commit-filter
     Befehl, mit dem Commit-Nachrichten formatiert werden.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette commit-sort
     Wenn diese Option als ‘date’ festgelegt wird, wird das Commit-Log
     streng nach Datum geordnet. Wenn sie auf ‘topo’ gesetzt ist, wird
     es streng topologisch geordnet.

     Defaults to ‘"git log"’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt css
     URL, die angibt, welches CSS-Dokument von jeder Cgit-Seite
     eingebunden werden soll.

     Die Vorgabe ist ‘"/share/cgit/cgit.css"’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt email-filter
     Gibt einen Befehl an, um die Namen und E-Mail-Adressen der
     Commiter, Autoren und Tagger zu formatieren, die an verschiedenen
     Stellen in der Oberfläche von Cgit vorkommen.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck embedded?
     Wenn diese Option auf ‘#t’ gesetzt ist, wird Cgit ein HTML-Fragment
     erzeugen, das für die Einbettung in andere HTML-Seiten geeignet
     ist.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-commit-graph?
     Wenn diese Option auf ‘#t’ gesetzt ist, wird Cgit den Graphen der
     Commit-Historie links von den Commit-Nachrichten auf den
     Commit-Log-Seiten mit ASCII-Zeichen darstellen.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-filter-overrides?
     Wenn diese Option auf ‘#t’ gesetzt ist, können alle
     Filtereinstellungen durch die cgitrc-Dateien für das jeweilige
     Repository geändert werden.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-follow-links?
     Wenn diese Option auf ‘#t’ gesetzt ist, können Benutzer in der
     Log-Ansicht einer Datei folgen („–follow“).

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-http-clone?
     Wenn es auf ‘#t’ gesetzt ist, kann Cgit als Endpunkt für eine
     Dumb-HTTP-Übertragung mit „git clone“ benutzt werden.

     Die Vorgabe ist ‘#t’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-index-links?
     Wenn diese Option auf ‘#t’ gesetzt ist, legt Cgit für jedes
     Repository zusätzlich Hyperlinks „summary“, „commit“, „tree“ im
     Repository-Index an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-index-owner?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit den Besitzer für
     jedes Repository im Repository-Index an.

     Die Vorgabe ist ‘#t’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-log-filecount?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit für jeden Commit
     auf den Repository-Log-Seiten die geänderten Dateien an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-log-linecount?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit für jeden Commit
     auf den Repository-Log-Seiten die Anzahl der hinzugefügten und
     entfernten Zeilen an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-remote-branches?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit unter den
     „summary“- und „ref“-Seiten entfernte Branches an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-subject-links?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit für Links auf
     Eltern-Commits die Betreffzeile des Eltern-Commits als Linktext in
     der Commit-Ansicht an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-html-serving?
     Flag which, when set to ‘#t’, will make cgit use the subject of the
     parent commit as link text when generating links to parent commits
     in commit view.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-tree-linenumbers?
     Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit für jeden Blob
     aus reinem Text Links auf dessen Zeilennummern in der Baumansicht
     („tree“) an.

     Die Vorgabe ist ‘#t’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          enable-git-config?
     Flag which, when set to ‘#f’, will allow cgit to use Git config to
     set any repo specific settings.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’ parameter: file-object favicon
     URL, auf der ein Cgit-Symbol für die Anzeige in einem Webbrowser zu
     finden ist.

     Die Vorgabe ist ‘"/favicon.ico"’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette footer
     Der Inhalt der für diese Option angegebenen Datei wird wortwörtlich
     am Ende jeder Seite eingefügt (d.h. er ersetzt die vorgegebene
     Mitteilung „generated by …“).

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette head-include
     Der Inhalt der für diese Option angegebenen Datei wird wortwörtlich
     im HTML-HEAD-Bereich jeder Seite eingefügt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette header
     Der Inhalt der für diese Option angegebenen Datei wird wortwörtlich
     am Anfang jeder Seite eingefügt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt include
     Der Name einer Konfigurationsdatei, deren Inhalt eingefügt werden
     soll, bevor die übrige hier angegebene Konfiguration eingelesen
     wird.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette index-header
     Der Inhalt der mit dieser Option angegebenen Datei wird
     wortwörtlich oberhalb des Repository-Index eingefügt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette index-info
     Der Inhalt der mit dieser Option angegebenen Datei wird
     wortwörtlich unterhalb der Überschrift auf jeder
     Repository-Index-Seite eingefügt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck local-time?
     Wenn diese Option auf ‘#t’ gesetzt ist, gibt Cgit die Zeitstempel
     von Commits und Tags in der Zeitzone des Servers an.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’ parameter: file-object logo
     URL, unter der ein Bild zu finden ist, das auf allen Cgit-Seiten
     als Logo zu sehen sein wird.

     Die Vorgabe ist ‘"/share/cgit/cgit.png"’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette logo-link
     URL, die geladen wird, wenn jemand auf das Logo-Bild klickt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt owner-filter
     Befehl, der aufgerufen wird, um die Besitzerspalte auf der
     Hauptseite zu formatieren.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-atom-items
     Anzahl der Objekte, die in der Atom-Feed-Ansicht angezeigt werden
     sollen.

     Die Vorgabe ist ‘10’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-commit-count
     Anzahl der Einträge, die in der Log-Ansicht pro Seite angezeigt
     werden sollen.

     Die Vorgabe ist ‘50’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-message-length
     Anzahl der Zeichen, die in der Log-Ansicht von jeder
     Commit-Nachricht angezeigt werden sollen.

     Die Vorgabe ist ‘80’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-repo-count
     Gibt an, wie viele Einträge auf jeder Seite der
     Repository-Index-Seiten stehen.

     Die Vorgabe ist ‘50’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-repodesc-length
     Gibt die maximale Anzahl der Zeichen an, die von jeder
     Repository-Beschreibung auf den Repository-Index-Seiten angezeigt
     werden sollen.

     Die Vorgabe ist ‘80’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl max-blob-size
     Gibt die maximale Größe eines Blobs in Kilobytes an, für den HTML
     angezeigt werden soll.

     Die Vorgabe ist ‘0’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette max-stats
     Maximaler Zeitraum für Statistiken. Gültige Werte sind ‘week’
     (Woche), ‘month’ (Monat), ‘quarter’ (Quartal) und ‘year’ (Jahr).

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Mimetype-Assoziative-Liste mimetype
     Mimetype je für die angegebene Dateinamenserweiterung.

     Die Vorgabe ist ‘((gif "image/gif") (html "text/html") (jpg
     "image/jpeg") (jpeg "image/jpeg") (pdf "application/pdf") (png
     "image/png") (svg "image/svg+xml"))’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt mimetype-file
     Gibt an, welche Datei zur automatischen Auflösung des Mimetypes
     benutzt werden soll.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette module-link
     Text, der als Formatzeichenkette für einen Hyperlink benutzt wird,
     wenn in einer Verzeichnisauflistung ein Submodul ausgegeben wird.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck nocache?
     Wenn dies auf ‘#t’ gesetzt ist, wird nicht zwischengespeichert.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck noplainemail?
     Wenn dies auf ‘#t’ gesetzt ist, werden keine vollen E-Mail-Adressen
     angezeigt.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck noheader?
     Wenn diese Option auf ‘#t’ gesetzt ist, wird Cgit die
     Standardseitenkopf auf allen Seiten weglassen.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Projektliste project-list
     Eine Liste der Unterverzeichnisse innerhalb des mit
     ‘repository-directory’ festgelegten Verzeichnisses, relativ dazu
     angegeben, die als Git-Repositorys geladen werden sollen. Eine
     leere Liste bedeutet, dass alle Unterverzeichnisse geladen werden.

     Die Vorgabe ist ‘()’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt readme
     Text, der als voreingestellter Wert für ‘cgit-repo-readme’ benutzt
     wird.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck remove-suffix?
     Wenn es auf ‘#t’ gesetzt ist und ‘repository-directory’ aktiviert
     ist, wird, wenn Repositorys mit einem Suffix von ‘.git’ gefunden
     werden, dieses Suffix von der URL und dem Namen weggelassen.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl renamelimit
     Maximale Anzahl der Dateien, die bei der Erkennung von
     Umbenennungen berücksichtigt werden.

     Die Vorgabe ist ‘-1’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette repository-sort
     Auf welche Art Repositorys in jedem Abschnitt sortiert werden.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Robots-Liste robots
     Text, der als Inhalt des ‘robots’-Meta-Tags dienen soll.

     Die Vorgabe ist ‘("noindex" "nofollow")’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette root-desc
     Welcher Text unterhalb der Überschrift auf Repository-Index-Seiten
     ausgegeben wird.

     Die Vorgabe ist ‘"a fast webinterface for the git dscm"’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette root-readme
     Der Inhalt der mit dieser Option angegebenen Datei wird
     wortwörtlich unter dem „about“-Link auf der Repository-Index-Seite
     angezeigt.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette root-title
     Welcher Text als Überschrift auf Repository-Index-Seiten ausgegeben
     werden soll.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck scan-hidden-path
     Wenn es auf ‘#t’ gesetzt ist und repository-directory aktiviert
     ist, wird repository-directory in Verzeichnissen rekursiv schauen,
     deren Name mit einem Punkt beginnt. Ansonsten werden solche
     Verzeichnisse unter repository-directory als „versteckt“ betrachtet
     und ignoriert. Beachten Sie, dass dies keine Wirkung auf das
     ‘.git’-Verzeichnis in _nicht_ auf „bare“ gestellten Repositorys
     hat.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Liste snapshots
     Dieser Text gibt an, für welche Snapshot-Formate Cgit Links
     erzeugt.

     Die Vorgabe ist ‘()’.

 -- ‘cgit-configuration’-Parameter: Repository-Verzeichnis
          repository-directory
     Der Name des Verzeichnisses, in dem nach Repositorys gesucht wird
     (wird als ‘scan-path’ in die Einstellungen übernommen).

     Die Vorgabe ist ‘"/srv/git"’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette section
     Der Name des aktuellen Abschnitts („section“) für Repositorys —
     alle später definierten Repositorys werden den aktuellen
     Abschnittsnamen erben.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette section-sort
     Wenn diese Option auf ‘#t’ gesetzt wird, werden die Abschnitte in
     Repository-Auflistungen nach Namen sortiert.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl section-from-path
     Wenn diese Zahl vor „repository-directory“ definiert wurde, gibt
     sie an, wie viele Pfadelemente jedes Repository-Pfads für den
     Abschnittsnamen voreingestellt verwendet werden.

     Die Vorgabe ist ‘0’.

 -- ‘cgit-configuration’-Parameter: Boolescher-Ausdruck
          side-by-side-diffs?
     Wenn es auf ‘#t’ gesetzt ist, werden Diffs nach Voreinstellung in
     Nebeneinanderdarstellung („side by side“) statt als
     zusammengeführte „Unidiffs“ angezeigt.

     Vorgegeben ist ‘#f’.

 -- ‘cgit-configuration’-Parameter: Dateiobjekt source-filter
     Gibt einen Befehl an, der aufgerufen wird, um Klartext-Blobs in der
     Baumansicht („tree“) zu formatieren.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl summary-branches
     Gibt die Anzahl der Branches an, die in der „summary“-Ansicht eines
     Repositorys zu sehen sein sollen.

     Die Vorgabe ist ‘10’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl summary-log
     Gibt die Anzahl der Log-Einträge an, die in der „summary“-Ansicht
     eines Repositorys zu sehen sein sollen.

     Die Vorgabe ist ‘10’.

 -- ‘cgit-configuration’-Parameter: Ganze-Zahl summary-tags
     Gibt die Anzahl in der „summary“-Ansicht eines Repositorys
     anzuzeigender Tags an.

     Die Vorgabe ist ‘10’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette strict-export
     Wenn dieser Dateiname angegeben wird, muss eine Datei diesen Namens
     in einem Repository enthalten sein, damit es angezeigt wird.

     Die Vorgabe ist ‘""’.

 -- ‘cgit-configuration’-Parameter: Zeichenkette virtual-root
     Wird diese URL angegeben, wird sie als Wurzel für alle Cgit-Links
     verwendet.

     Die Vorgabe ist ‘"/"’.

 -- ‘cgit-configuration’-Parameter:
          „repository-cgit-configuration“-Liste repositories
     Eine Liste von “cgit-repo”-Verbundsobjekten, die innerhalb der
     Konfiguration benutzt werden sollen.

     Die Vorgabe ist ‘()’.

     Verfügbare ‘repository-cgit-configuration’-Felder sind:

      -- ‘repository-cgit-configuration’-Parameter: Repo-Liste snapshots
          Eine Maske, die für dieses Repository auf die Snapshots gelegt
          wird, für die Cgit Links erzeugt. Dadurch kann die globale
          Einstellung ‘snapshots’ eingeschränkt werden.

          Die Vorgabe ist ‘()’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               source-filter
          Die Voreinstellung für ‘source-filter’ ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               url
          Die relative URL, mit der auf das Repository zugegriffen wird.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               about-filter
          Die Voreinstellung für ‘about-filter’ ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               branch-sort
          Wenn diese Option auf ‘age’ gesetzt wurde, wird die Liste der
          Branch-Referenzen nach Datum sortiert, und wenn sie auf ‘name’
          gesetzt wurde, wird nach dem Branch-Namen sortiert.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Liste clone-url
          Eine Liste von URLs, von denen das Repository geklont werden
          kann.

          Die Vorgabe ist ‘()’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               commit-filter
          Die Voreinstellung für ‘commit-filter’ ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               commit-sort
          Wenn diese Option als ‘date’ festgelegt wird, wird das
          Commit-Log streng nach Datum geordnet. Wenn sie auf ‘topo’
          gesetzt ist, wird es streng topologisch geordnet.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               defbranch
          Der Name des voreingestellten Branches dieses Repositorys.
          Wenn kein solcher Branch im Repository existiert, wird der
          erste Branchname in sortierter Reihenfolge voreingestellt.
          Nach Vorgabe wird der Branch voreingestellt, auf den HEAD
          zeigt, oder „master“, wenn es keinen passenden HEAD gibt.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               desc
          Der Wert, der als Repository-Beschreibung angezeigt werden
          soll.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               homepage
          Der Wert, der als Repository-Homepage angezeigt werden soll.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               email-filter
          Die Voreinstellung für ‘email-filter’ ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck enable-commit-graph?
          Eine Option, mit der die globale Einstellung für
          ‘enable-commit-graph?’ deaktiviert werden kann.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck enable-log-filecount?
          Eine Option, mit der die globale Einstellung für
          ‘enable-log-filecount?’ deaktiviert werden kann.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck enable-log-linecount?
          Eine Option, mit der die globale Einstellung für
          ‘enable-log-linecount?’ deaktiviert werden kann.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck
               enable-remote-branches?
          Wenn diese Option auf ‘#t’ gesetzt ist, zeigt Cgit unter den
          „summary“- und „ref“-Seiten entfernte Branches an.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck enable-subject-links?
          Eine Option, mit der die globale Einstellung für
          ‘enable-subject-links?’ deaktiviert werden kann.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Vielleicht-Repo-Boolescher-Ausdruck enable-html-serving?
          Eine Option, mit der die globale Einstellung für
          ‘enable-html-serving?’ deaktiviert werden kann.

          Der Vorgabewert ist ‘disabled’ (d.h. deaktiviert).

      -- ‘repository-cgit-configuration’-Parameter:
               Repo-Boolescher-Ausdruck hide?
          Wenn diese Option auf ‘#t’ gesetzt ist, wird das Repository im
          Repository-Index verborgen.

          Vorgegeben ist ‘#f’.

      -- ‘repository-cgit-configuration’-Parameter:
               Repo-Boolescher-Ausdruck ignore?
          Wenn diese Option auf ‘#t’ gesetzt ist, wird das Repository
          ignoriert.

          Vorgegeben ist ‘#f’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               logo
          URL, unter der ein Bild zu finden ist, das auf allen Seiten
          dieses Repositorys als Logo zu sehen sein wird.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               logo-link
          URL, die geladen wird, wenn jemand auf das Logo-Bild klickt.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Dateiobjekt
               owner-filter
          Die Voreinstellung für ‘owner-filter’ ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               module-link
          Text, der als Formatzeichenkette für einen Hyperlink benutzt
          wird, wenn in einer Verzeichnisauflistung ein Submodul
          ausgegeben wird. Die Argumente für diese Formatzeichenkette
          sind Pfad und SHA1 des Submodul-Commits.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: module-link-Pfad
               module-link-path
          Text, der als Formatzeichenkette für einen Hyperlink benutzt
          wird, wenn in einer Verzeichnisauflistung ein Submodul mit dem
          angegebenen Unterverzeichnispfad ausgegeben wird.

          Die Vorgabe ist ‘()’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               max-stats
          Die Voreinstellung für den maximalen Zeitraum für Statistiken
          ersetzen.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               name
          Welcher Wert als Repository-Name angezeigt werden soll.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               owner
          Ein Wert, um den Besitzer des Repositorys zu identifizieren.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               path
          Ein absoluter Pfad zum Repository-Verzeichnis.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               readme
          Ein Pfad (relativ zum Repository), der eine Datei angibt,
          deren Inhalt wortwörtlich auf der „About“-Seite dieses
          Repositorys eingefügt werden soll.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Zeichenkette
               section
          Der Name des aktuellen Abschnitts („section“) für Repositorys
          — alle später definierten Repositorys werden den aktuellen
          Abschnittsnamen erben.

          Die Vorgabe ist ‘""’.

      -- ‘repository-cgit-configuration’-Parameter: Repo-Liste
               extra-options
          Zusätzliche Optionen werden an die cgitrc-Datei angehängt.

          Die Vorgabe ist ‘()’.

 -- ‘cgit-configuration’-Parameter: Liste extra-options
     Zusätzliche Optionen werden an die cgitrc-Datei angehängt.

     Die Vorgabe ist ‘()’.

   Aber es könnte auch sein, dass Sie schon eine ‘cgitrc’ haben und zum
Laufen bringen wollen. In diesem Fall können Sie eine
‘opaque-cgit-configuration’ als Verbundsobjekt an ‘cgit-service-type’
übergeben. Wie der Name schon sagt, bietet eine opake Konfiguration
keinerlei Unterstützung für Reflexion.

   Verfügbare ‘opaque-cgit-configuration’-Felder sind:

 -- ‘opaque-cgit-configuration’-Parameter: „package“ cgit
     Das cgit-Paket.

 -- ‘opaque-cgit-configuration’-Parameter: Zeichenkette string
     Der Inhalt für ‘cgitrc’ als eine Zeichenkette.

   Wenn zum Beispiel Ihre ‘cgitrc’ nur aus der leeren Zeichenkette
bestehen soll, könnten Sie einen Cgit-Dienst auf diese Weise
instanziieren:

     (service cgit-service-type
              (opaque-cgit-configuration
               (cgitrc "")))

Gitolite-Dienst
...............

Gitolite (https://gitolite.com/gitolite/) ist ein Werkzeug, um
Git-Repositorys anderen auf einem zentralen Server anzubieten.

   Gitolite kann mehrere Nutzer mit mehreren Repositorys bedienen und
unterstützt flexible Konfigurationsmöglichkeiten der Berechtigungen der
Repository-Nutzer.

   Das folgende Beispiel richtet Gitolite für den voreingestellten
‘git’-Benutzer und den angegebenen öffentlichen SSH-Schlüssel ein.

     (service gitolite-service-type
              (gitolite-configuration
                (admin-pubkey (plain-file
                                "ihrname.pub"
                                "ssh-rsa AAAA… guix@example.com"))))

   Sie konfigurieren Gitolite, indem Sie ein besonderes Admin-Repository
anpassen. Sie können es zum Beispiel klonen, indem Sie, wenn Sie
Gitolite auf ‘example.com’ eingerichtet haben, den folgenden Befehl zum
Klonen des Admin-Repositorys ausführen:

     git clone git@example.com:gitolite-admin

   Wenn der Gitolite-Dienst aktiviert wird, wird der mitgegebene
‘admin-pubkey’ ins ‘keydir’-Verzeichnis vom „gitolite-admin“-Repository
eingefügt. Wenn sich dadurch das Repository ändert, wird die Änderung
mit der Commit-Nachricht „gitolite setup by GNU Guix“ commitet.

 -- Datentyp: gitolite-configuration
     Repräsentiert die Konfiguration vom ‘gitolite-service-type’.

     ‘package’ (Vorgabe: GITOLITE)
          Welches Gitolite-Paket benutzt werden soll.

     ‘user’ (Vorgabe: GIT)
          Welches Benutzerkonto für Gitolite benutzt werden soll. Mit
          diesem Benutzer werden Sie über SSH auf Gitolite zugreifen.

     ‘group’ (Vorgabe: GIT)
          Gruppe für Gitolite.

     ‘home-directory’ (Vorgabe: "/VAR/LIB/GITOLITE")
          Das Verzeichnis, in dem die Gitolite-Konfiguration und
          Repositorys gespeichert werden sollen.

     ‘rc-file’ (Vorgabe: (GITOLITE-RC-FILE))
          Ein dateiartiges Objekt (siehe *note dateiartige Objekte:
          G-Ausdrücke.), das die Konfiguration für Gitolite
          repräsentiert.

     ‘admin-pubkey’ (Vorgabe: #F)
          Ein dateiartiges Objekt (siehe *note dateiartige Objekte:
          G-Ausdrücke.), mit dem Gitolite eingerichtet werden kann. Er
          wird in das ‘keydir’-Verzeichnis im
          „gitolite-admin“-Repository eingefügt.

          Um einen SSH-Schlüssel als Zeichenkette anzugeben, benutzen
          Sie die ‘plain-file’-Funktion.

               (plain-file "ihrname.pub" "ssh-rsa AAAA… guix@example.com")

 -- Datentyp: gitolite-rc-file
     Repräsentiert die Gitolie-RC-Datei.

     ‘umask’ (Vorgabe: ‘#o0077’)
          Dies legt fest, welche Berechtigungen Gitolite an die
          Repositorys und deren Inhalt vergibt.

          Für einen Wert wie ‘#o0027’ wird die Gruppe, die Gitolite
          benutzt (nach Vorgabe: ‘git’) Lesezugriff erhalten. Das ist
          nötig, wenn Sie Gitolite mit Software wie Cgit oder Gitweb
          kombinieren.

     ‘git-config-keys’ (Vorgabe: ‘""’)
          Mit Gitolite können Sie Werte für Git-Konfigurationen über das
          ‘config’-Schlüsselwort festlegen. Mit dieser Einstellung
          können Sie steuern, welche Konfigurationsschlüssel akzeptiert
          werden.

     ‘roles’ (Vorgabe: ‘'(("READERS" . 1) ("WRITERS" . ))’)
          Legt fest, welche Rollennamen für Nutzer möglich sind, wenn
          Sie den Befehl perms ausführen.

     ‘enable’ (Vorgabe: ‘'("help" "desc" "info" "perms" "writable" "ssh-authkeys" "git-config" "daemon" "gitweb")’)
          Diese Einstellung legt die innerhalb von Gitolite zur
          Verfügung gestellten Befehle fest.

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

   (1) Das geschieht, indem die magische Datei ‘git-daemon-export-ok’ im
Repository erzeugt wird.


File: guix.de.info,  Node: Spieldienste,  Next: PAM-Einbindedienst,  Prev: Versionskontrolldienste,  Up: Dienste

10.8.28 Spieldienste
--------------------

„The Battle for Wesnoth“-Dienst
...............................

The Battle for Wesnoth (https://wesnoth.org) ist ein in einer
Fantasy-Welt angesiedeltes, rundenbasiertes, taktisches Strategiespiel.
Es verfügt über mehrere Einzelspielerkampagnen und Mehrspielerspiele
(über das Netzwerk und lokal).

 -- Variable: Scheme-Variable wesnothd-service-type
     Diensttyp für den wesnothd-Dienst. Als Wert muss ein
     ‘wesnothd-configuration’-Objekt benutzt werden. Um wesnothd mit
     seiner Vorgabekonfiguration auszuführen, instanziieren Sie es als:

          (service wesnothd-service-type)

 -- Datentyp: wesnothd-configuration
     Datentyp, der die Konfiguration von ‘wesnothd’ repräsentiert.

     ‘package’ (Vorgabe: ‘wesnoth-server’)
          Das Paket, das für den Wesnoth-Server benutzt werden soll.

     ‘port’ (Vorgabe: ‘15000’)
          Der Port, an den der Server gebunden wird.


File: guix.de.info,  Node: PAM-Einbindedienst,  Next: Guix-Dienste,  Prev: Spieldienste,  Up: Dienste

10.8.29 PAM-Einbindedienst
--------------------------

Das Modul ‘(gnu services pam-mount)’ stellt einen Dienst zur Verfügung,
mit dem Benutzer Datenträger beim Anmelden einbinden können. Damit
sollte es möglich sein, jedes vom System unterstützte Datenträgerformat
einzubinden.

 -- Variable: Scheme-Variable pam-mount-service-type
     Diensttyp für PAM-Einbindeunterstützung.

 -- Datentyp: pam-mount-configuration
     Datentyp, der die Konfiguration für PAM-Einbindungen („PAM Mount“)
     repräsentiert.

     Sie hat folgende Parameter:

     ‘rules’
          Die Konfigurationsregeln, um
          ‘/etc/security/pam_mount.conf.xml’ zu erzeugen.

          Die Konfigurationsregeln sind SXML-Elemente (siehe *note
          (guile)SXML::) und nach Vorgabe wird für niemanden etwas beim
          Anmelden eingebunden:

               `((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"))))

          Es müssen ‘volume’-Elemente eingefügt werden, um Datenträger
          automatisch bei der Anmeldung einzubinden. Hier ist ein
          Beispiel, mit dem die Benutzerin ‘alice’ ihr verschlüsseltes
          ‘HOME’-Verzeichnis einbinden kann, und der Benutzer ‘bob’ die
          Partition einbinden kann, wo er seine Daten abspeichert.

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

          Die vollständige Liste möglicher Optionen finden Sie in der
          Handbuchseite („man page“) für pam_mount.conf
          (http://pam-mount.sourceforge.net/pam_mount.conf.5.html).


File: guix.de.info,  Node: Guix-Dienste,  Next: Linux-Dienste,  Prev: PAM-Einbindedienst,  Up: Dienste

10.8.30 Guix-Dienste
--------------------

Guix-Erstellungskoordinator
...........................

Der Guix-Erstellungskoordinator
(https://git.cbaines.net/guix/build-coordinator/) („Guix Build
Coordinator“) hilft dabei, Erstellungen von Ableitungen auf Maschinen zu
verteilen, auf denen ein “Agent” läuft. Der Erstellungs-Daemon wird
weiterhin benutzt, um die Ableitungen zu erstellen, der
Guix-Erstellungskoordinator verwaltet nur die Zuteilung der Erstellungen
und den Umgang mit den Ergebnissen.

     Anmerkung: Dieser Dienst gilt als experimentell. Die
     Konfigurationsoptionen könnten in Zukunft noch auf eine Weise
     abgeändert werden, die keine Kompatibilität mit dem momentanen
     Verhalten gewährleistet, und nicht alle Funktionalitäten wurden
     gründlich getestet.

   Der Guix-Erstellungskoordinator setzt sich aus einem “Koordinator”
und mindestens einem verbundenen “Agentenprozess” zusammen. Der
Koordinatorprozess kümmert sich um Clients, die Erstellungen einreichen,
und teilt Erstellungen den Agenten zu. Die Agentenprozesse kommunizieren
mit einem Erstellungs-Daemon, welcher die Erstellungen eigentlich
durchführt und die Ergebnisse an den Koordinator zurückgibt.

   Es gibt ein Skript, um die Koordinatorkomponente des
Guix-Erstellungskoordinators auszuführen, aber der Dienst für Guix
benutzt stattdessen sein eigenes Guile-Skript, was in der Konfiguration
benutzte G-Ausdrücke besser integriert.

 -- Variable: Scheme-Variable guix-build-coordinator-service-type
     Diensttyp für den Guix-Erstellungskoordinator. Sein Wert muss ein
     ‘guix-build-coordinator-configuration’-Objekt sein.

 -- Datentyp: guix-build-coordinator-configuration
     Der Datentyp, der die Konfiguration des
     Guix-Erstellungskoordinators repräsentiert.

     ‘package’ (Vorgabe: ‘guix-build-coordinator’)
          Das zu verwendende Guix-Erstellungskoordinator-Paket.

     ‘user’ (Vorgabe: ‘"guix-build-coordinator"’)
          Das Systembenutzerkonto, mit dem der Dienst ausgeführt wird.

     ‘group’ (Vorgabe: ‘"guix-build-coordinator"’)
          Die Systembenutzergruppe, mit der der Dienst ausgeführt wird.

     ‘database-uri-string’ (Vorgabe: ‘"sqlite:///var/lib/guix-build-coordinator/guix_build_coordinator.db"’)
          Die URI für die Datenbank.

     ‘agent-communication-uri’ (Vorgabe: ‘"http://0.0.0.0:8745"’)
          Die URI, die beschreibt, wie auf Anfragen von Agentenprozessen
          gelauscht wird.

     ‘client-communication-uri’ (Vorgabe: ‘"http://127.0.0.1:8746"’)
          Die URI, die beschreibt, wie auf Anfragen von Clients
          gelauscht wird. Mit der Client-API können Erstellungen
          eingereicht werden und derzeit findet dabei keine
          Authentifizierung statt. Das sollten Sie bedenken, wenn Sie
          hieran Einstellungen vornehmen.

     ‘allocation-strategy’ (Vorgabe: ‘#~basic-build-allocation-strategy’)
          Ein G-Ausdruck für die zu nutzende Zuteilungsstrategie.
          Angegeben wird eine Prozedur, die den Datenspeicher als
          Argument nimmt und in den Zuteilungsplan in der Datenbank
          einfügt.

     ‘hooks’ (Vorgabe: ’())
          Eine assoziative Liste mit Hooks. Mit ihnen kann infolge
          bestimmter Ereignisse beliebiger Code ausgeführt werden, z.B.
          wenn ein Erstellungsergebnis verarbeitet wird.

     ‘guile’ (Vorgabe: ‘guile-3.0-latest’)
          Mit welchem Guile-Paket der Guix-Erstellungskoordinator
          ausgeführt wird.

 -- Variable: Scheme-Variable guix-build-coordinator-agent-service-type
     Diensttyp für einen Guix-Erstellungskoordinator-Agenten. Als Wert
     muss ein ‘guix-build-coordinator-agent-configuration’-Objekt
     angegeben werden.

 -- Datentyp: guix-build-coordinator-agent-configuration
     Der Datentyp, der die Konfiguration eines
     Guix-Erstellungskoordinator-Agenten repräsentiert.

     ‘package’ (Vorgabe: ‘guix-build-coordinator’)
          Das zu verwendende Guix-Erstellungskoordinator-Paket.

     ‘user’ (Vorgabe: ‘"guix-build-coordinator-agent"’)
          Das Systembenutzerkonto, mit dem der Dienst ausgeführt wird.

     ‘coordinator’ (Vorgabe: ‘"http://localhost:8745"’)
          Das Passwort, das zum Herstellen einer Verbindung mit dem
          Koordinator verwendet werden soll.

     ‘authentication’
          Ein Verbundsobjekt, das beschreibt, wie sich dieser Agent beim
          Koordinator authentisiert. Mögliche Verbundsfelder werden im
          Folgenden beschrieben.

     ‘systems’ (Vorgabe: ‘#f’)
          Die Systeme, für die dieser Agent Erstellungen übernehmen
          soll. Voreingestellt verwendet der Agentenprozess den
          Systemtyp, auf dem er aktuell läuft.

     ‘max-parallel-builds’ (Vorgabe: ‘1’)
          Die Anzahl der Erstellungen, die parallel ausgeführt werden
          sollen.

     ‘derivation-substitute-urls’ (Vorgabe: ‘#f’)
          URLs, von denen versucht werden soll, Substitute für
          Ableitungen herunterzuladen, wenn die Ableitungen noch nicht
          vorliegen.

     ‘non-derivation-substitute-urls’ (Vorgabe: ‘#f’)
          URLs, von denen versucht werden soll, Substitute für
          Erstellungseingaben herunterzuladen, wenn die
          Eingabe-Store-Objekte noch nicht vorliegen.

 -- Datentyp: guix-build-coordinator-agent-password-auth
     Der Datentyp, der einen Agenten repräsentiert, der sich bei einem
     Koordinator über eine UUID und ein Passwort authentisiert.

     ‘uuid’
          Die UUID des Agenten. Sie sollte durch den Koordinatorprozess
          erzeugt worden sein, in der Datenbank des Koordinators
          eingetragen sein und von dem Agenten benutzt werden, für den
          sie gedacht ist.

     ‘password’
          Das Passwort, das zum Herstellen einer Verbindung mit dem
          Koordinator verwendet werden soll.

 -- Datentyp: guix-build-coordinator-agent-password-file-auth
     Der Datentyp, der einen Agenten repräsentiert, der sich bei einem
     Koordinator über eine UUID und ein aus einer Datei gelesenes
     Passwort authentisiert.

     ‘uuid’
          Die UUID des Agenten. Sie sollte durch den Koordinatorprozess
          erzeugt worden sein, in der Datenbank des Koordinators
          eingetragen sein und von dem Agenten benutzt werden, für den
          sie gedacht ist.

     ‘password-file’
          Eine Datei mit dem Passwort, um sich mit dem Koordinator zu
          verbinden.

 -- Datentyp: guix-build-coordinator-agent-dynamic-auth
     Der Datentyp, der einen Agenten repräsentiert, der sich bei einem
     Koordinator über einen dynamischen Authentisierungs-Token und den
     Agentennamen authentisiert.

     ‘agent-name’
          Der Name des Agenten. Er wird benutzt, um den passenden
          Eintrag in der Datenbank für ihn zu finden. Gibt es noch
          keinen Eintrag, wird automatisch einer hinzugefügt.

     ‘token’
          Dynamischer Authentisierungs-Token. Er wird in der Datenbank
          des Koordinators erzeugt und vom Agenten zur Authentisierung
          benutzt.

 -- Datentyp: guix-build-coordinator-agent-dynamic-auth-with-file
     Der Datentyp, der einen Agenten repräsentiert, der sich bei einem
     Koordinator über einen aus einer Datei gelesenen dynamischen
     Authentisierungs-Token und den Agentennamen authentisiert.

     ‘agent-name’
          Der Name des Agenten. Er wird benutzt, um den passenden
          Eintrag in der Datenbank für ihn zu finden. Gibt es noch
          keinen Eintrag, wird automatisch einer hinzugefügt.

     ‘token-file’
          Eine Datei, in der der dynamische Authentisierungs-Token
          enthalten ist. Er wird in der Datenbank des Koordinators
          erzeugt und vom Agenten zur Authentisierung benutzt.

   Das Paket des Guix-Erstellungskoordinators enthält ein Skript, mit
dem eine Instanz des Guix-Datendienstes („Guix Data Service“) nach zu
erstellenden Ableitungen angefragt werden kann, woraufhin Erstellungen
für selbige Ableitungen beim Koordinator eingereicht werden. Der
folgende Diensttyp hilft dabei, dieses Skript einzusetzen. Es ist ein
weiteres Werkzeug, das beim Erstellen von Ableitungen von Nutzen sein
kann, die in einer Instanz des Guix-Datendienstes vorhanden sind.

 -- Variable: Scheme-Variable
          guix-build-coordinator-queue-builds-service-type
     Der Diensttyp für das Skript
     guix-build-coordinator-queue-builds-from-guix-data-service. Als
     Wert muss ein
     ‘guix-build-coordinator-queue-builds-configuration’-Objekt benutzt
     werden.

 -- Datentyp: guix-build-coordinator-queue-builds-configuration
     Der Datentyp, der die Optionen an das Skript
     guix-build-coordinator-queue-builds-from-guix-data-service
     repräsentiert.

     ‘package’ (Vorgabe: ‘guix-build-coordinator’)
          Das zu verwendende Guix-Erstellungskoordinator-Paket.

     ‘user’ (Vorgabe: ‘"guix-build-coordinator-queue-builds"’)
          Das Systembenutzerkonto, mit dem der Dienst ausgeführt wird.

     ‘coordinator’ (Vorgabe: ‘"http://localhost:8745"’)
          Das Passwort, das zum Herstellen einer Verbindung mit dem
          Koordinator verwendet werden soll.

     ‘systems’ (Vorgabe: ‘#f’)
          Für welche Systeme zu erstellende Ableitungen übernommen
          werden sollen.

     ‘systems-and-targets’ (Vorgabe: ‘#f’)
          Eine assoziative Liste aus Paaren aus System und
          Zielplattform, für die zu erstellende Ableitungen übernommen
          werden sollen.

     ‘guix-data-service’ (Vorgabe: ‘"https://data.guix.gnu.org"’)
          Die Instanz des Guix-Datendienstes, die nach zu erstellenden
          Ableitungen angefragt werden soll.

     ‘processed-commits-file’ (Vorgabe: ‘"/var/cache/guix-build-coordinator-queue-builds/processed-commits"’)
          Eine Datei, in die gespeichert wird, welche Commits bereits
          verarbeitet wurden, um sie nicht unnötig ein weiteres Mal zu
          verarbeiten, wenn der Dienst neu gestartet wird.

Guix-Datendienst
................

Der Guix-Datendienst (http://data.guix.gnu.org) („Guix Data Service“)
verarbeitet und speichert Daten über GNU Guix und stellt diese zur
Verfügung. Dazu gehören Informationen über Pakete, Ableitungen sowie
durch Linting erkannte Paketfehler.

   Die Daten werden in einer PostgreSQL-Datenbank gespeichert und stehen
über eine Weboberfläche zur Verfügung.

 -- Variable: Scheme-Variable guix-data-service-type
     Diensttyp für den Guix-Datendienst. Sein Wert muss ein
     ‘guix-data-service-configuration’-Objekt sein. Der Dienst kann
     optional den getmail-Dienst erweitern und die
     guix-commits-Mailing-Liste benutzen, um bei Änderungen am
     Guix-Git-Repository auf dem Laufenden zu bleiben.

 -- Datentyp: guix-data-service-configuration
     Der Datentyp, der die Konfiguration des Guix-Datendienstes
     repräsentiert.

     ‘package’ (Vorgabe: ‘guix-data-service’)
          Das zu verwendende Guix-Datendienst-Paket.

     ‘user’ (Vorgabe: ‘"guix-data-service"’)
          Das Systembenutzerkonto, mit dem der Dienst ausgeführt wird.

     ‘group’ (Vorgabe: ‘"guix-data-service"’)
          Die Systembenutzergruppe, mit der der Dienst ausgeführt wird.

     ‘port’ (Vorgabe: ‘8765’)
          Der Port, an den der Webdienst gebunden wird.

     ‘host’ (Vorgabe: ‘"127.0.0.1"’)
          Die Netzwerkschnittstelle („Host“), an die der Webdienst
          gebunden wird.

     ‘getmail-idle-mailboxes’ (Vorgabe: ‘#f’)
          Wenn es festgelegt ist, wird es als Liste der Postfächer
          („Mailboxes“) eingerichtet, die der getmail-Dienst beobachtet.

     ‘commits-getmail-retriever-configuration’ (Vorgabe: ‘#f’)
          Wenn es festgelegt ist, bezeichnet dies das
          ‘getmail-retriever-configuration’-Objekt, mit dem getmail
          eingerichtet wird, um E-Mails von der
          „guix-commits“-Mailing-Liste zu beziehen.

     ‘extra-options’ (Vorgabe: ’())
          Zusätzliche Befehlszeilenoptionen für ‘guix-data-service’.

     ‘extra-process-jobs-options’ (Vorgabe: ’())
          Zusätzliche Befehlszeilenoptionen für
          ‘guix-data-service-process-jobs’.


File: guix.de.info,  Node: Linux-Dienste,  Next: Hurd-Dienste,  Prev: Guix-Dienste,  Up: Dienste

10.8.31 Linux-Dienste
---------------------

Early-OOM-Dienst
................

Early OOM (https://github.com/rfjakob/earlyoom), auch bekannt als
Earlyoom, ist ein minimalistischer Out-Of-Memory-Daemon (OOM), um auf
Anwendungsebene („User Space“) Programme abzuwürgen, wenn einem der
freie Arbeitsspeicher ausgeht (ein „OOM-Killer“). Er stellt eine
Alternative zum im Kernel eingebauten OOM-Killer dar, mit der das System
in einem solchen Fall besser weiterhin auf Benutzereingaben reagieren
kann und die konfigurierbarer ist.

 -- Scheme-Variable: earlyoom-service-type
     Der Diensttyp, um ‘earlyoom’, den Early-OOM-Daemon, auszuführen.
     Als Wert muss ein ‘earlyoom-configuration’-Objekt angegeben werden,
     wie unten beschrieben. So kann der Dienst mit seiner
     Vorgabekonfiguration instanziieret werden:

          (service earlyoom-service-type)

 -- Datentyp: earlyoom-configuration
     Dies ist das Verbundsobjekt mit der Konfiguration des
     ‘earlyoom-service-type’.

     ‘earlyoom’ (Vorgabe: EARLYOOM)
          Das Earlyoom-Paket, das benutzt werden soll.

     ‘minimum-available-memory’ (Vorgabe: ‘10’)
          Der Schwellwert, wie viel Arbeitsspeicher mindestens
          _verfügbar_ bleiben muss, in Prozent.

     ‘minimum-free-swap’ (Vorgabe: ‘10’)
          Der Schwellwert, wie viel Swap-Speicher mindestens frei
          bleiben muss, in Prozent.

     ‘prefer-regexp’ (Vorgabe: ‘#f’)
          Ein regulärer Ausdruck (als eine Zeichenkette), der auf die
          Namen jener Prozesse passt, die als Erste abgewürgt werden
          sollen.

     ‘avoid-regexp’ (Vorgabe: ‘#f’)
          Ein regulärer Ausdruck (als eine Zeichenkette), der auf die
          Namen jener Prozesse passt, die _nicht_ abgewürgt werden
          sollen.<

     ‘memory-report-interval’ (Vorgabe: ‘0’)
          Das Intervall in Sekunden, in dem ein Bericht über den
          Speicher ausgegeben werden soll. Nach Vorgabe ist es
          deaktiviert.

     ‘ignore-positive-oom-score-adj?’ (Vorgabe: ‘#f’)
          Ein boolescher Wert, der angibt, ob die in
          ‘/proc/*/oom_score_adj’ festgelegten Anpassungen nach oben
          ignoriert werden sollen.

     ‘show-debug-messages?’ (Vorgabe: ‘#f’)
          Ein boolescher Ausdruck, der angibt, ob Nachrichten zur
          Fehlersuche ausgegeben werden sollen. Die Protokolle werden
          unter ‘/var/log/earlyoom.log’ gespeichert.

     ‘send-notification-command’ (Vorgabe: ‘#f’)
          Hiermit kann ein eigener Befehl eingestellt werden, um
          Benachrichtigungen zu senden.

Kernelmodul-Ladedienst
......................

Mit dem Kernelmodul-Ladedienst („Kernel Module Loader Service“) können
Sie veranlassen, dass hinzuladbare Kernelmodule beim Systemstart geladen
werden. Das bietet sich besonders für Module an, die nicht automatisch
geladen werden („Autoload“), sondern manuell geladen werden müssen, wie
es z.B. bei ‘ddcci’ der Fall ist.

 -- Scheme-Variable: kernel-module-loader-service-type
     Der Diensttyp, um hinzuladbare Kernelmodule beim Systemstart über
     ‘modprobe’ zu laden. Als Wert muss eine Liste von Zeichenketten
     angegeben werden, die den Modulnamen entsprechen. Um zum Beispiel
     die durch ‘ddcci-driver-linux’ zur Verfügung gestellten Treiber zu
     laden und dabei durch Übergabe bestimmter Parameter den Modus zur
     Fehlersuche zu aktivieren, können Sie Folgendes benutzen:

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

Dienst für Zram-Geräte
......................

Der Dienst für Zram-Geräte macht ein komprimiertes Swap-Gerät im
Arbeitsspeicher verfügbar. Mehr Informationen finden Sie in der
Linux-Kernel-Dokumentation über Zram-Geräte
(https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html).

 -- Scheme-Variable: zram-device-service-type
     Dieser Dienst erzeugt das Zram-Blockgerät, formatiert es als
     Swap-Speicher und aktiviert es als ein Swap-Gerät. Der Wert des
     Dienstes ist ein ‘zram-device-configuration’-Verbundsobjekt.

      -- Datentyp: zram-device-configuration
          Dieser Datentyp repräsentiert die Konfiguration des
          zram-device-Dienstes.

          ‘size’ (Vorgabe: ‘"1G"’)
               Wie viel Speicher Sie für das Zram-Gerät verfügbar machen
               möchten. Angegeben werden kann eine Zeichenkette oder
               eine Zahl mit der Anzahl Bytes oder mit einem Suffix,
               z.B. ‘"512M"’ oder ‘1024000’.
          ‘compression-algorithm’ (Vorgabe: ‘'lzo’)
               Welchen Kompressionsalgorithmus Sie verwenden möchten.
               Alle Konfigurationsmöglichkeiten lassen sich hier nicht
               aufzählen, aber der Linux-Libre-Kernel von Guix
               unterstützt unter anderem die häufig benutzten ‘'lzo’,
               ‘'lz4’ und ‘'zstd’.
          ‘memory-limit’ (Vorgabe: ‘0’)
               Wie viel Arbeitsspeicher dem Zram-Gerät höchstens zur
               Verfügung steht. Wenn es auf 0 steht, entfällt die
               Beschränkung. Obwohl im Allgemeinen von einem
               Kompressionsverhältnis von 2:1 ausgegangen wird, kann es
               passieren, dass _nicht_ komprimierbare Daten den
               Swap-Speicher füllen. Mit diesem Feld kann das begrenzt
               werden. Es nimmt eine Zeichenkette oder eine Anzahl
               Bytes; ein Suffix kann angegeben werden, z.B. ‘"2G"’.
          ‘priority’ (Vorgabe: ‘-1’)
               Die Priorität des Swap-Geräts, das aus dem Zram-Gerät
               erzeugt wird. ‘swapon’ akzeptiert Werte zwischen -1 und
               32767, dabei stehen höhere Werte für eine höhere
               Priorität. Höher priorisierter Speicher wird in der Regel
               zuerst benutzt.


File: guix.de.info,  Node: Hurd-Dienste,  Next: Verschiedene Dienste,  Prev: Linux-Dienste,  Up: Dienste

10.8.32 Hurd-Dienste
--------------------

 -- Scheme-Variable: hurd-console-service-type
     Diensttyp, mit dem der fantastische ‘VGA’-Konsolen-Client auf Hurd
     ausgeführt wird.

     Der Wert des Dienstes ist ein
     ‘hurd-console-configuration’-Verbundsobjekt.

 -- Datentyp: hurd-console-configuration
     Dieser Datentyp repräsentiert die Konfiguration des
     hurd-console-Dienstes.

     ‘hurd’ (Vorgabe: HURD)
          Das zu verwendende Hurd-Paket.

 -- Scheme-Variable: hurd-getty-service-type
     Der Diensttyp, um ein TTY über Hurds ‘getty’-Programm zu starten.

     Der Wert des Dienstes ist ein
     ‘hurd-getty-configuration’-Verbundsobjekt.

 -- Datentyp: hurd-getty-configuration
     Dieser Datentyp repräsentiert die Konfiguration des
     hurd-getty-Dienstes.

     ‘hurd’ (Vorgabe: HURD)
          Das zu verwendende Hurd-Paket.

     ‘tty’
          Der Name der Konsole, auf der dieses Getty läuft — z.B.
          ‘"tty1"’.

     ‘baud-rate’ (Vorgabe: ‘38400’)
          Eine ganze Zahl, die die Baud-Rate des TTYs angibt.


File: guix.de.info,  Node: Verschiedene Dienste,  Prev: Hurd-Dienste,  Up: Dienste

10.8.33 Verschiedene Dienste
----------------------------

Fingerabdrucklese-Dienst
........................

Das Modul ‘(gnu services authentication)’ stellt einen DBus-Dienst zur
Verfügung, mit dem Fingerabdrücke mit Hilfe eines Fingerabdrucksensors
gelesen und identifiziert werden können.

 -- Scheme-Variable: fprintd-service-type
     Der Diensttyp für ‘fprintd’, mit dem Fingerabdrücke gelesen werden
     können.

          (service fprintd-service-type)

Systemsteuerungsdienst
......................

Das Modul ‘(gnu services sysctl)’ stellt einen Dienst zur Verfügung, um
Kernelparameter zur Boot-Zeit einzustellen.

 -- Scheme-Variable: sysctl-service-type
     Der Diensttyp für ‘sysctl’, das Kernel-Parameter unter ‘/proc/sys/’
     anpasst. Um IPv4-Weiterleitung („Forwarding“) zu aktivieren, kann
     er auf diese Weise instanziiert werden:

          (service sysctl-service-type
                   (sysctl-configuration
                     (settings '(("net.ipv4.ip_forward" . "1")))))

     Weil ‘sysctl-service-type’ in den Listen vorgegebener Dienste
     vorkommt, sowohl in ‘%base-services’ als auch in
     ‘%desktop-services’, können Sie ‘modify-services’ benutzen, um
     seine Konfiguration zu ändern und die Kernel-Parameter einzutragen,
     die Sie möchten (siehe *note ‘modify-services’: Service-Referenz.).

          (modify-services %base-services
            (sysctl-service-type config =>
                                 (sysctl-configuration
                                   (settings (append '(("net.ipv4.ip_forward" . "1"))
                                                     %default-sysctl-settings)))))

 -- Datentyp: sysctl-configuration
     Der Datentyp, der die Konfiguration von ‘sysctl’ repräsentiert.

     ‘sysctl’ (Vorgabe: ‘(file-append procps "/sbin/sysctl"’)
          Die ausführbare Datei für ‘sysctl’, die benutzt werden soll.

     ‘settings’ (Vorgabe: ‘%default-sysctl-settings’)
          Eine assoziative Liste, die Kernel-Parameter und ihre Werte
          festlegt.

 -- Scheme-Variable: %default-sysctl-settings
     Eine assoziative Liste, die die vorgegebenen ‘sysctl’-Parameter auf
     Guix System enthält.

PC/SC-Smart-Card-Daemon-Dienst
..............................

Das Modul ‘(gnu services security-token)’ stellt den folgenden Dienst
zur Verfügung, um ‘pcscd’ auszuführen, den PC/SC-Smart-Card-Daemon.
‘pcscd’ ist das Daemonprogramm für die Rahmensysteme pcsc-lite und
MuscleCard. Es handelt sich um einen Ressourcenverwaltungsdienst, der
die Kommunikation mit Smart-Card-Lesegeräten, Smart Cards und
kryptographischen Tokens steuert, die mit dem System verbunden sind.

 -- Scheme-Variable: pcscd-service-type
     Diensttyp für den ‘pcscd’-Dienst. Als Wert muss ein
     ‘pcscd-configuration’-Objekt angegeben werden. Um pcscd mit seiner
     Vorgabekonfiguration auszuführen, instanziieren Sie ihn als:

          (service pcscd-service-type)

 -- Datentyp: pcscd-configuration
     Repräsentiert die Konfiguration von ‘pcscd’.

     ‘pcsc-lite’ (Vorgabe: ‘pcsc-lite’)
          Das „pcsc-lite“-Paket, das pcscd zur Verfügung stellt.
     ‘usb-drivers’ (Vorgabe: ‘(list ccid)’)
          Die Liste der Pakete, die USB-Treiber für pcscd zur Verfügung
          stellen. Es wird erwartet, dass sich Treiber unter
          ‘pcsc/drivers’ innerhalb des Store-Verzeichnisses des Pakets
          befinden.

Lirc-Dienst
...........

Das Modul ‘(gnu services lirc)’ stellt den folgenden Dienst zur
Verfügung.

 -- Scheme-Prozedur: lirc-service [#:lirc lirc] [#:device #f] [#:driver
          #f] [#:config-file #f]  [#:extra-options '()]
     Liefert einen Dienst, der LIRC (http://www.lirc.org) ausführt,
     einen Dienst zum Dekodieren von Infrarot-Signalen aus
     Fernbedienungen.

     Optional können DEVICE (Gerät), DRIVER (Treiber) und CONFIG-FILE
     (Name der Konfigurationsdatei) festgelegt werden. Siehe das
     Handbuch von ‘lircd’ für Details.

     Schließlich enthält EXTRA-OPTIONS eine Liste zusätzlicher
     Befehlszeilenoptionen, die an ‘lircd’ übergeben werden.

Spice-Dienst
............

Das Modul ‘(gnu services spice)’ stellt den folgenden Dienst bereit.

 -- Scheme-Prozedur: spice-vdagent-service [#:spice-vdagent]
     Liefert einen Dienst, der VDAGENT (https://www.spice-space.org)
     ausführt, einen Daemon, um die Zwischenablage mit einer virtuellen
     Maschine zu teilen und die Auflösung des Anzeigegeräts des
     Gastsystems umzustellen, wenn sich die Größe des grafischen
     Konsolenfensters ändert.

inputattach-Dienst
..................

Der inputattach-Dienst (https://linuxwacom.github.io/) macht es Ihnen
möglich, Eingabegeräte wie Wacom-Tabletts, Tastbildschirme
(„Touchscreens“) oder Joysticks mit dem Xorg-Anzeigeserver zu benutzen.

 -- Scheme-Variable: inputattach-service-type
     Der Diensttyp für den Dienst, der ‘inputattach’ auf einem Gerät
     ausführt und Ereignisse davon weiterleitet.

 -- Datentyp: inputattach-configuration
     ‘device-type’ (Vorgabe: ‘"wacom"’)
          Der Typ des Geräts, mit dem eine Verbindung hergestellt werden
          soll. Führen Sie ‘inputattach --help’ aus dem
          ‘inputattach’-Paket aus, um eine Liste unterstützter
          Gerätetypen zu sehen.

     ‘device’ (Vorgabe: ‘"/dev/ttyS0"’)
          Die Gerätedatei, um sich mit dem Gerät zu verbinden.

     ‘baud-rate’ (Vorgabe: ‘#f’)
          Welche Baudrate für die serielle Verbindung benutzt werden
          soll. Es sollte eine Zahl oder ‘#f’ angegeben werden.

     ‘log-file’ (Vorgabe: ‘#f’)
          Wenn es wahr ist, muss es der Name einer Datei sein, in die
          Protokollnachrichten geschrieben werden sollen.

Wörterbuchdienst
................

Das Modul ‘(gnu services dict)’ stellt den folgenden Dienst zur
Verfügung:

 -- Scheme-Variable: dicod-service-type
     Dies ist der Diensttyp für einen Dienst, der den ‘dicod’-Daemon
     ausführt. Dabei handelt es sich um eine Implementierung eines
     DICT-Servers (siehe das *note (dico)Dicod::).

 -- Scheme-Prozedur: dicod-service [#:config (dicod-configuration)]
     Liefert einen Dienst, der den ‘dicod’-Daemon ausführt. Dabei
     handelt es sich um eine Implementierung eines DICT-Servers (siehe
     das *note (dico)Dicod::).

     Das optionale Argument CONFIG gibt die Konfiguration für ‘dicod’
     an, welche ein ‘<dicod-configuration>’-Objekt sein sollte. Nach
     Vorgabe wird als Wörterbuch das „GNU Collaborative International
     Dictionary of English“ angeboten.

     Sie können in Ihre ‘~/.dico’-Datei ‘open localhost’ eintragen,
     damit ‘localhost’ zum voreingestellten Server des ‘dico’-Clients
     wird (siehe das *note (dico)Initialization File::).

 -- Datentyp: dicod-configuration
     Der Datentyp, der die Konfiguration von dicod repräsentiert.

     ‘dico’ (Vorgabe: DICO)
          Paketobjekt des GNU-Dico-Wörterbuchservers.

     ‘interfaces’ (Vorgabe: ’("LOCALHOST"))
          Hierfür muss die Liste der IP-Adressen, Ports und
          möglicherweise auch Socket-Dateinamen angegeben werden, auf
          die gelauscht werden soll (siehe *note ‘listen’ directive:
          (dico)Server Settings.).

     ‘handlers’ (Vorgabe: ’())
          Liste der ‘<dicod-handler>’-Objekte, die Handler
          (Modulinstanzen) bezeichnen.

     ‘databases’ (Vorgabe: (LIST %DICOD-DATABASE:GCIDE))
          Liste der ‘<dicod-database>’-Objekte, die anzubietende
          Wörterbücher bezeichnen.

 -- Datentyp: dicod-handler
     Der Datentyp, der einen Wörterbuch-Handler (eine Modulinstanz)
     repräsentiert.

     ‘name’
          Der Name des Handlers (der Modulinstanz).

     ‘module’ (Vorgabe: #F)
          Der Name des dicod-Moduls (der Instanz) des Handlers. Wenn er
          ‘#f’ ist, heißt das, das Modul hat denselben Namen wie der
          Handler (siehe *note (dico)Module::).

     ‘options’
          Liste der Zeichenketten oder G-Ausdrücke, die die Argumente
          für den Modul-Handler repräsentieren.

 -- Datentyp: dicod-database
     Datentyp, der eine Wörterbuchdatenbank repräsentiert.

     ‘name’
          Der Name der Datenbank, der in DICT-Befehlen benutzt wird.

     ‘handler’
          Der Name des dicod-Handlers (der Modulinstanz), die von dieser
          Datenbank benutzt wird (siehe *note (dico)Handlers::).

     ‘complex?’ (Vorgabe: #F)
          Ob die Datenbankkonfiguration komplex ist. In diesem Fall muss
          für die komplexe Konfiguration auch ein entsprechendes
          ‘<dicod-handler>’-Objekt existieren, ansonsten nicht.

     ‘options’
          Liste der Zeichenketten oder G-Ausdrücke, die die Argumente
          für die Datenbank repräsentiert (siehe *note
          (dico)Databases::).

 -- Scheme-Variable: %dicod-database:gcide
     Ein ‘<dicod-database>’-Objekt, um das „GNU Collaborative
     International Dictionary of English“ anzubieten. Dazu wird das
     ‘gcide’-Paket benutzt.

   Im Folgenden sehen Sie eine Beispielkonfiguration für einen
‘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))))

Docker-Dienst
.............

Das Modul ‘(gnu services docker)’ stellt die folgenden Dienste zur
Verfügung.

 -- Scheme-Variable: docker-service-type

     Dies ist der Diensttyp des Dienstes, um Docker
     (https://www.docker.com) auszuführen, einen Daemon, der
     Anwendungsbündel in isolierten Umgebungen ausführen kann (manchmal
     auch als „Container“ bezeichnet).

 -- Datentyp: docker-configuration
     Dies ist der Datentyp, der die Konfiguration von Docker und
     Containerd repräsentiert.

     ‘package’ (Vorgabe: ‘docker’)
          Das Docker-Daemon-Paket, was benutzt werden soll.

     ‘package’ (Vorgabe: ‘docker-cli’)
          Das Docker-Client-Paket, was benutzt werden soll.

     ‘containerd’ (Vorgabe: CONTAINERD)
          Das Containerd-Paket, was benutzt werden soll.

     ‘proxy’ (Vorgabe: DOCKER-LIBNETWORK-CMD-PROXY)
          Das Paket des mit Benutzerrechten (im „User-Land“)
          ausgeführten Docker-Netzwerkproxys, das verwendet werden soll.

     ‘enable-proxy?’ (Vorgabe: ‘#t’)
          Den mit Benutzerrechten (im „User-Land“) ausgeführten
          Docker-Netzwerkproxy an- oder abschalten.

     ‘debug?’ (Vorgabe: ‘#f’)
          Ausgaben zur Fehlersuche an- oder abschalten.

     ‘enable-iptables?’ (Vorgabe: ‘#t’)
          Das Hinzufügen von iptables-Regeln durch Docker an- oder
          abschalten.

 -- Scheme-Variable: singularity-service-type
     Dies ist der Diensttyp für den Dienst, mit dem Sie Singularity
     (https://www.sylabs.io/singularity/) ausführen können, ein
     Docker-ähnliches Werkzeug, um Anwendungsbündel (auch bekannt als
     „Container“) auszuführen. Der Wert für diesen Dienst ist das
     Singularity-Paket, das benutzt werden soll.

     Der Dienst installiert keinen Daemon, sondern er installiert
     Hilfsprogramme als setuid-root (siehe *note Setuid-Programme::),
     damit auch „unprivilegierte“ Nutzer ohne besondere Berechtigungen
     ‘singularity run’ und ähnliche Befehle ausführen können.

Auditd-Dienst
.............

Das Modul ‘(gnu services auditd)’ stellt den folgenden Dienst zur
Verfügung.

 -- Scheme-Variable: auditd-service-type

     Dies ist der Diensttyp des Dienstes, mit dem auditd
     (https://people.redhat.com/sgrubb/audit/) ausgeführt wird, ein
     Daemon, der sicherheitsrelevante Informationen auf Ihrem System
     sammelt.

     Beispiele für Dinge, über die Informationen gesammelt werden
     sollen:

       1. Dateizugriffe
       2. Betriebssystemaufrufe („System Calls“)
       3. Aufgerufene Befehle
       4. Fehlgeschlagene Anmeldeversuche
       5. Filterung durch die Firewall
       6. Netzwerkzugriff

     ‘auditctl’ aus dem ‘audit’-Paket kann benutzt werden, um zu
     überwachende Ereignisse (bis zum nächsten Neustart) hinzuzufügen
     oder zu entfernen. Um über Ereignisse dauerhaft Informationen
     sammeln zu lassen, schreiben Sie die Befehlszeilenargumente für
     auditctl in eine Datei namens ‘audit.rules’ im Verzeichnis für
     Konfigurationen (siehe unten). ‘aureport’ aus dem ‘audit’-Paket
     kann benutzt werden, um einen Bericht über alle aufgezeichneten
     Ereignisse anzuzeigen. Nach Vorgabe speichert der Audit-Daemon
     Protokolle in die Datei ‘/var/log/audit.log’.

 -- Datentyp: auditd-configuration
     Dies ist der Datentyp, der die Konfiguration von auditd
     repräsentiert.

     ‘audit’ (Vorgabe: ‘audit’)
          Das zu verwendende audit-Paket.

     ‘configuration-directory’ (Vorgabe: ‘%default-auditd-configuration-directory’)
          Das Verzeichnis mit der Konfigurationsdatei für das
          audit-Paket. Sie muss den Namen ‘auditd.conf’ tragen und
          optional kann sie ein paar Audit-Regeln enthalten, die beim
          Start instanziierrt werden sollen.

R-Shiny-Dienst
..............

Das Modul ‘(gnu services science)’ stellt den folgenden Dienst bereit.

 -- Scheme-Variable: rshiny-service-type

     Dies ist der Diensttyp eines Dienstes, um eine mit ‘r-shiny’
     erzeugte Web-Anwendung („Webapp“) auszuführen. Dieser Dienst legt
     die Umgebungsvariable ‘R_LIBS_USER’ fest und führt das eingestellte
     Skript aus, um ‘runApp’ aufzurufen.

      -- Datentyp: rshiny-configuration
          Dies ist der Datentyp, der die Konfiguration von rshiny
          repräsentiert.

          ‘package’ (Vorgabe: ‘r-shiny’)
               Das zu benutzende Paket.

          ‘binary’ (Vorgabe: ‘"rshiny"’)
               Der Name der Binärdatei oder des Shell-Skripts, das sich
               in ‘Paket/bin/’ befindet und beim Starten des Dienstes
               ausgeführt werden soll.

               Die übliche Art, diese Datei erzeugen zu lassen, ist
               folgende:

                    …
                    (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))))

Nix-Dienst
..........

Das Modul ‘(gnu services nix)’ stellt den folgenden Dienst zur
Verfügung:

 -- Scheme-Variable: nix-service-type

     Dies ist der Diensttyp für den Dienst, der den Erstellungs-Daemon
     der Nix-Paketverwaltung (https://nixos.org/nix/) ausführt. Hier ist
     ein Beispiel, wie man ihn benutzt:

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

     Nach ‘guix system reconfigure’ können Sie Nix für Ihr Benutzerkonto
     konfigurieren:

        • Fügen Sie einen Nix-Kanal ein und aktualisieren Sie ihn. Siehe
          Nix Package Manager Guide (https://nixos.org/nix/manual/).

        • Erzeugen Sie eine symbolische Verknüpfung zu Ihrem Profil und
          aktivieren Sie das Nix-Profil:

          $ ln -s "/nix/var/nix/profiles/per-user/$USER/profile" ~/.nix-profile
          $ source /run/current-system/profile/etc/profile.d/nix.sh

 -- Datentyp: nix-configuration
     Dieser Datentyp repräsentiert die Konfiguration des Nix-Daemons.

     ‘nix’ (Vorgabe: ‘nix’)
          Das zu verwendende Nix-Paket.

     ‘sandbox’ (Vorgabe: ‘#t’)
          Gibt an, ob Erstellungen nach Voreinstellung in einer
          isolierten Umgebung („Sandbox“) durchgeführt werden sollen.

     ‘build-sandbox-items’ (Vorgabe: ‘'()’)
          Dies ist eine Liste von Zeichenketten oder Objekten, die an
          das ‘build-sandbox-items’-Feld der Konfigurationsdatei
          angehängt werden.

     ‘extra-config’ (Vorgabe: ‘'()’)
          Dies ist eine Liste von Zeichenketten oder Objekten, die an
          die Konfigurationsdatei angehängt werden. Mit ihnen wird
          zusätzlicher Text wortwörtlich zur Konfigurationsdatei
          hinzugefügt.

     ‘extra-options’ (Vorgabe: ‘'()’)
          Zusätzliche Befehlszeilenoptionen für ‘nix-service-type’.


File: guix.de.info,  Node: Setuid-Programme,  Next: X.509-Zertifikate,  Prev: Dienste,  Up: Systemkonfiguration

10.9 Setuid-Programme
=====================

Manche Programme müssen mit Administratorrechten (also den
Berechtigungen des „root“-Benutzers) ausgeführt werden, selbst wenn
Nutzer ohne besondere Berechtigungen sie starten. Ein bekanntes Beispiel
ist das Programm ‘passwd’, womit Nutzer ihr Passwort ändern können, wozu
das Programm auf die Dateien ‘/etc/passwd’ und ‘/etc/shadow’ zugreifen
muss — was normalerweise nur der „root“-Nutzer darf, aus
offensichtlichen Gründen der Informationssicherheit. Deswegen sind diese
ausführbaren Programmdateien “setuid-root”, d.h. sie laufen immer mit
den Administratorrechten des root-Nutzers, egal wer sie startet (siehe
*note (libc)How Change Persona:: für mehr Informationen über den
setuid-Mechanismus).

   Der Store selbst kann _keine_ setuid-Programme enthalten: Das wäre
eine Sicherheitslücke, weil dann jeder Nutzer auf dem System Ableitungen
schreiben könnte, die in den Store solche Dateien einfügen würden (siehe
*note Der Store::). Wir benutzen also einen anderen Mechanismus: Statt
auf den ausführbaren Dateien im Store selbst deren setuid-Bit zu setzen,
lassen wir den Systemadministrator _deklarieren_, welche Programme mit
setuid-root gestartet werden.

   Das Feld ‘setuid-programs’ einer ‘operating-system’-Deklaration
enthält eine Liste von G-Ausdrücken, die die Namen der Programme
angeben, die setuid-root sein sollen (siehe *note Das
Konfigurationssystem nutzen::). Zum Beispiel kann das Programm ‘passwd’,
was Teil des Shadow-Pakets ist, durch diesen G-Ausdruck bezeichnet
werden (siehe *note G-Ausdrücke::):

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

   Eine vorgegebene Menge von setuid-Programmen wird durch die Variable
‘%setuid-programs’ aus dem Modul ‘(gnu system)’ definiert.

 -- Scheme-Variable: %setuid-programs
     Eine Liste von G-Ausdrücken, die übliche Programme angeben, die
     setuid-root sein müssen.

     Die Liste enthält Befehle wie ‘passwd’, ‘ping’, ‘su’ und ‘sudo’.

   Intern erzeugt Guix die eigentlichen setuid-Programme im Verzeichnis
‘/run/setuid-programs’, wenn das System aktiviert wird. Die Dateien in
diesem Verzeichnis verweisen auf die „echten“ Binärdateien im Store.


File: guix.de.info,  Node: X.509-Zertifikate,  Next: Name Service Switch,  Prev: Setuid-Programme,  Up: Systemkonfiguration

10.10 X.509-Zertifikate
=======================

Über HTTPS verfügbare Webserver (also HTTP mit gesicherter
Transportschicht, englisch „Transport-Layer Security“, kurz TLS) senden
Client-Programmen ein “X.509-Zertifikat”, mit dem der Client den Server
dann _authentifizieren_ kann. Dazu verifiziert der Client, dass das
Zertifikat des Servers von einer sogenannten Zertifizierungsstelle
signiert wurde (“Certificate Authority”, kurz CA). Damit er aber die
Signatur der Zertifizierungsstelle verifizieren kann, muss jeder Client
das Zertifikat der Zertifizierungsstelle besitzen.

   Web-Browser wie GNU IceCat liefern ihre eigenen CA-Zertifikate mit,
damit sie von Haus aus Zertifikate verifizieren können.

   Den meisten anderen Programmen, die HTTPS sprechen können — ‘wget’,
‘git’, ‘w3m’ etc. — muss allerdings erst mitgeteilt werden, wo die
CA-Zertifikate installiert sind.

   In Guix müssen Sie dazu ein Paket, das Zertifikate enthält, in das
‘packages’-Feld der ‘operating-system’-Deklaration des Betriebssystems
hinzufügen (siehe *note „operating-system“-Referenz::). Guix liefert ein
solches Paket mit, ‘nss-certs’, was als Teil von Mozillas „Network
Security Services“ angeboten wird.

   Beachten Sie, dass es _nicht_ zu den ‘%base-packages’ gehört, Sie es
also ausdrücklich hinzufügen müssen. Das Verzeichnis ‘/etc/ssl/certs’,
wo die meisten Anwendungen und Bibliotheken ihren Voreinstellungen
entsprechend nach Zertifikaten suchen, verweist auf die global
installierten Zertifikate.

   Unprivilegierte Benutzer, wie die, die Guix auf einer
Fremddistribution benutzen, können sich auch lokal ihre eigenen Pakete
mit Zertifikaten in ihr Profil installieren. Eine Reihe von
Umgebungsvariablen muss dazu definiert werden, damit Anwendungen und
Bibliotheken wissen, wo diese Zertifikate zu finden sind. Und zwar folgt
die OpenSSL-Bibliothek den Umgebungsvariablen ‘SSL_CERT_DIR’ und
‘SSL_CERT_FILE’, manche Anwendungen benutzen stattdessen aber ihre
eigenen Umgebungsvariablen. Das Versionskontrollsystem Git liest den Ort
zum Beispiel aus der Umgebungsvariablen ‘GIT_SSL_CAINFO’ aus. Sie würden
typischerweise also so etwas ausführen:

     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"

   Ein weiteres Beispiel ist R, was voraussetzt, dass die
Umgebungsvariable ‘CURL_CA_BUNDLE’ auf ein Zertifikatsbündel verweist,
weshalb Sie etwas wie hier ausführen müssten:

     guix install nss-certs
     export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"

   Für andere Anwendungen möchten Sie die Namen der benötigten
Umgebungsvariablen vielleicht in deren Dokumentation nachschlagen.


File: guix.de.info,  Node: Name Service Switch,  Next: Initiale RAM-Disk,  Prev: X.509-Zertifikate,  Up: Systemkonfiguration

10.11 Name Service Switch
=========================

Das Modul ‘(gnu system nss)’ enthält Anbindungen für die Konfiguration
des “Name Service Switch” (NSS) der libc (siehe *note (libc)NSS
Configuration File::). Kurz gesagt ist der NSS ein Mechanismus, mit dem
die libc um neue „Namens“-Auflösungsmethoden für Systemdatenbanken
erweitert werden kann; dazu gehören Rechnernamen (auch bekannt als
„Host“-Namen), Dienstnamen, Benutzerkonten und mehr (siehe *note
Systemdatenbanken und der Name Service Switch: (libc)Name Service
Switch.).

   Die NSS-Konfiguration legt für jede Systemdatenbank fest, mit welcher
Methode der Name nachgeschlagen („aufgelöst“) werden kann und welche
Methoden zusammenhängen — z.B. unter welchen Umständen der NSS es mit
der nächsten Methode auf seiner Liste versuchen sollte. Die
NSS-Konfiguration wird im Feld ‘name-service-switch’ von
‘operating-system’-Deklarationen angegeben (siehe *note
‘name-service-switch’: „operating-system“-Referenz.).

   Zum Beispiel konfigurieren die folgenden Deklarationen den NSS so,
dass er das ‘nss-mdns’-Backend
(https://0pointer.de/lennart/projects/nss-mdns/) benutzt, wodurch er auf
‘.local’ endende Rechnernamen über Multicast-DNS (mDNS) auflöst:

     (name-service-switch
        (hosts (list %files    ;zuerst in /etc/hosts nachschlagen

                     ;; Wenn das keinen Erfolg hatte, es
                     ;; mit 'mdns_minimal' versuchen.
                     (name-service
                       (name "mdns_minimal")

                       ;; 'mdns_minimal' ist die Autorität für
                       ;; '.local'. Gibt es not-found ("nicht
                       ;; gefunden") zurück, müssen wir die
                       ;; nächsten Methoden gar nicht erst
                       ;; versuchen.
                       (reaction (lookup-specification
                                  (not-found => return))))

                     ;; Ansonsten benutzen wir DNS.
                     (name-service
                       (name "dns"))

                     ;; Ein letzter Versuch mit dem
                     ;; "vollständigen" 'mdns'.
                     (name-service
                       (name "mdns")))))

   Keine Sorge: Die Variable ‘%mdns-host-lookup-nss’ (siehe unten)
enthält diese Konfiguration bereits. Statt das alles selst einzutippen,
können Sie sie benutzen, wenn alles, was Sie möchten, eine
funktionierende Namensauflösung für ‘.local’-Rechner ist.

   Beachten Sie dabei, dass es zusätzlich zum Festlegen des
‘name-service-switch’ in der ‘operating-system’-Deklaration auch
erforderlich ist, den ‘avahi-service-type’ zu benutzen (siehe *note
‘avahi-service-type’: Netzwerkdienste.). Es genügt auch, wenn Sie die
‘%desktop-services’ benutzen, weil er darin enthalten ist (siehe *note
Desktop-Dienste::). Dadurch wird ‘nss-mdns’ für den Name Service Cache
Daemon nutzbar (siehe *note ‘nscd-service’: Basisdienste.).

   Um sich eine lange Konfiguration zu ersparen, können Sie auch einfach
die folgenden Variablen für typische NSS-Konfigurationen benutzen.

 -- Scheme-Variable: %default-nss
     Die vorgegebene Konfiguration des Name Service Switch als ein
     ‘name-service-switch’-Objekt.

 -- Scheme-Variable: %mdns-host-lookup-nss
     Die Name-Service-Switch-Konfiguration mit Unterstützung für
     Rechnernamensauflösung über „Multicast DNS“ (mDNS) für auf ‘.local’
     endende Rechnernamen.

   Im Folgenden finden Sie eine Referenz, wie eine
Name-Service-Switch-Konfiguration aussehen muss. Sie hat eine direkte
Entsprechung zum Konfigurationsdateiformat der C-Bibliothek, lesen Sie
weitere Informationen also bitte im Handbuch der C-Bibliothek nach
(siehe *note (libc)NSS Configuration File::). Gegenüber dem
Konfigurationsdateiformat des libc-NSS bekommen Sie mit unserer Syntax
nicht nur ein warm umklammerndes Gefühl, sondern auch eine statische
Analyse: Wenn Sie Syntax- und Schreibfehler machen, werden Sie darüber
benachrichtigt, sobald Sie ‘guix system’ aufrufen.

 -- Datentyp: name-service-switch

     Der Datentyp, der die Konfiguration des Name Service Switch (NSS)
     der libc repräsentiert. Jedes im Folgenden aufgeführte Feld
     repräsentiert eine der unterstützten Systemdatenbanken.

     ‘aliases’
     ‘ethers’
     ‘group’
     ‘gshadow’
     ‘hosts’
     ‘initgroups’
     ‘netgroup’
     ‘networks’
     ‘password’
     ‘public-key’
     ‘rpc’
     ‘services’
     ‘shadow’
          Das sind die Systemdatenbanken, um die sich NSS kümmern kann.
          Jedes dieser Felder muss eine Liste aus
          ‘<name-service>’-Objekten sein (siehe unten).

 -- Datentyp: name-service

     Der einen eigentlichen Namensdienst repräsentierende Datentyp
     zusammen mit der zugehörigen Auflösungsaktion.

     ‘name’
          Eine Zeichenkette, die den Namensdienst bezeichnet (siehe
          *note (libc)Services in the NSS configuration::).

          Beachten Sie, dass hier aufgeführte Namensdienste für den nscd
          sichtbar sein müssen. Dazu übergeben Sie im Argument
          ‘#:name-services’ des ‘nscd-service’ die Liste der Pakete, die
          die entsprechenden Namensdienste anbieten (siehe *note
          ‘nscd-service’: Basisdienste.).

     ‘reaction’
          Eine mit Hilfe des Makros ‘lookup-specification’ angegebene
          Aktion (siehe *note (libc)Actions in the NSS configuration::).
          Zum Beispiel:

               (lookup-specification (unavailable => continue)
                                     (success => return))


File: guix.de.info,  Node: Initiale RAM-Disk,  Next: Bootloader-Konfiguration,  Prev: Name Service Switch,  Up: Systemkonfiguration

10.12 Initiale RAM-Disk
=======================

Um ihn zu initialisieren (zu „bootstrappen“), wird für den Kernel
Linux-Libre eine “initiale RAM-Disk” angegeben (kurz “initrd”). Eine
initrd enthält ein temporäres Wurzeldateisystem sowie ein Skript zur
Initialisierung. Letzteres ist dafür zuständig, das echte
Wurzeldateisystem einzubinden und alle Kernel-Module zu laden, die dafür
nötig sein könnten.

   Mit dem Feld ‘initrd-modules’ einer ‘operating-system’-Deklaration
können Sie angeben, welche Kernel-Module für Linux-libre in der initrd
verfügbar sein müssen. Insbesondere müssen hier die Module aufgeführt
werden, um die Festplatte zu betreiben, auf der sich Ihre
Wurzelpartition befindet — allerdings sollte der vorgegebene Wert der
‘initrd-modules’ in dem meisten Fällen genügen. Wenn Sie aber zum
Beispiel das Kernel-Modul ‘megaraid_sas’ zusätzlich zu den vorgegebenen
Modulen brauchen, um auf Ihr Wurzeldateisystem zugreifen zu können,
würden Sie das so schreiben:

     (operating-system
       ;; …
       (initrd-modules (cons "megaraid_sas" %base-initrd-modules)))

 -- Scheme-Variable: %base-initrd-modules
     Der Vorgabewert für die Liste der Kernel-Module, die in der initrd
     enthalten sein sollen.

   Wenn Sie noch systemnähere Anpassungen durchführen wollen, können Sie
im Feld ‘initrd’ einer ‘operating-system’-Deklaration angeben, was für
eine Art von initrd Sie benutzen möchten. Das Modul ‘(gnu system
linux-initrd)’ enthält drei Arten, eine initrd zu erstellen: die
abstrakte Prozedur ‘base-initrd’ und die systemnahen Prozeduren
‘raw-initrd’ und ‘expression->initrd’.

   Mit der Prozedur ‘base-initrd’ sollten Sie die häufigsten
Anwendungszwecke abdecken können. Wenn Sie zum Beispiel ein paar
Kernel-Module zur Boot-Zeit laden lassen möchten, können Sie das
‘initrd’-Feld auf diese Art definieren:

     (initrd (lambda (file-systems . rest)
               ;; Eine gewöhnliche initrd, aber das Netzwerk wird
               ;; mit den Parametern initialisiert, die QEMU
               ;; standardmäßig erwartet.
               (apply base-initrd file-systems
                      #:qemu-networking? #t
                      rest)))

   Die Prozedur ‘base-initrd’ kann auch mit üblichen Anwendungszwecken
umgehen, um das System als QEMU-Gastsystem zu betreiben oder als ein
„Live“-System ohne ein dauerhaft gespeichertes Wurzeldateisystem.

   Die Prozedur ‘base-initrd’ baut auf der Prozedur ‘raw-initrd’ auf.
Anders als ‘base-initrd’ hat ‘raw-initrd’ keinerlei
Zusatzfunktionalitäten: Es wird kein Versuch unternommen, für die initrd
notwendige Kernel-Module und Pakete automatisch hinzuzunehmen.
‘raw-initrd’ kann zum Beispiel benutzt werden, wenn ein Nutzer eine
eigene Konfiguration des Linux-Kernels verwendet und die
Standard-Kernel-Module, die mit ‘base-initrd’ hinzugenommen würden,
nicht verfügbar sind.

   Die initiale RAM-Disk, wie sie von ‘base-initrd’ oder ‘raw-initrd’
erzeugt wird, richtet sich nach verschiedenen Optionen, die auf der
Kernel-Befehlszeile übergeben werden (also über GRUBs ‘linux’-Befehl
oder die ‘-append’-Befehlszeilenoption von QEMU). Erwähnt werden
sollten:

‘--load=BOOT’
     Die initiale RAM-Disk eine Datei BOOT, in der ein Scheme-Programm
     steht, laden lassen, nachdem das Wurzeldateisystem eingebunden
     wurde.

     Guix übergibt mit dieser Befehlszeilenoption die Kontrolle an ein
     Boot-Programm, das die Dienstaktivierungsprogramme ausführt und
     anschließend den GNU Shepherd startet, das Initialisierungssystem
     („init“-System) von Guix System.

‘--root=WURZEL’
     Das mit WURZEL bezeichnete Dateisystem als Wurzeldateisystem
     einbinden. WURZEL kann ein Geratename wie ‘/dev/sda1’, eine
     Dateisystembezeichnung (d.h. ein Dateisystem-„Label“) oder eine
     Dateisystem-UUID sein. Wird nichts angegeben, wird der Gerätename
     aus dem Wurzeldateisystem der Betriebssystemdeklaration benutzt.

‘--system=SYSTEM’
     ‘/run/booted-system’ und ‘/run/current-system’ auf das SYSTEM
     zeigen lassen.

‘modprobe.blacklist=MODULE…’
     Die initiale RAM-Disk sowie den Befehl ‘modprobe’ (aus dem
     kmod-Paket) anweisen, das Laden der angegebenen MODULE zu
     verweigern. Als MODULE muss eine kommagetrennte Liste von
     Kernel-Modul-Namen angegeben werden — z.B. ‘usbkbd,9pnet’.

‘--repl’
     Eine Lese-Auswerten-Schreiben-Schleife (englisch „Read-Eval-Print
     Loop“, kurz REPL) von der initialen RAM-Disk starten, bevor diese
     die Kernel-Module zu laden versucht und das Wurzeldateisystem
     einbindet. Unsere Marketingabteilung nennt das “boot-to-Guile”. Der
     Schemer in Ihnen wird das lieben. Siehe *note (guile)Using Guile
     Interactively:: für mehr Informationen über die REPL von Guile.

   Jetzt wo Sie wissen, was für Funktionalitäten eine durch
‘base-initrd’ und ‘raw-initrd’ erzeugte initiale RAM-Disk so haben kann,
möchten Sie vielleicht auch wissen, wie man sie benutzt und weiter
anpasst:

 -- Scheme-Prozedur: raw-initrd DATEISYSTEME [#:linux-modules '()]
          [#:mapped-devices '()]  [#:keyboard-layout #f]
          [#:helper-packages '()] [#:qemu-networking? #f]
          [#:volatile-root? #f]
     Liefert eine Ableitung, die eine rohe („raw“) initrd erstellt.
     DATEISYSTEME bezeichnet eine Liste von durch die initrd
     einzubindenden Dateisystemen, unter Umständen zusätzlich zum auf
     der Kernel-Befehlszeile mit ‘--root’ angegebenen Wurzeldateisystem.
     LINUX-MODULES ist eine Liste von Kernel-Modulen, die zur Boot-Zeit
     geladen werden sollen. MAPPED-DEVICES ist eine Liste von
     Gerätezuordnungen, die hergestellt sein müssen, bevor die unter
     FILE-SYSTEMS aufgeführten Dateisysteme eingebunden werden (siehe
     *note Zugeordnete Geräte::). HELPER-PACKAGES ist eine Liste von
     Paketen, die in die initrd kopiert werden. Darunter kann
     ‘e2fsck/static’ oder andere Pakete aufgeführt werden, mit denen
     durch die initrd das Wurzeldateisystem auf Fehler hin geprüft
     werden kann.

     Ist es auf einen wahren Wert gesetzt, dann muss KEYBOARD-LAYOUT
     eine Tastaturbelegung als ‘<keyboard-layout>’-Verbundsobjekt
     angeben, die die gewünschte Tastaturbelegung für die Konsole
     bezeichnet. Sie wird verwendet, noch bevor die Gerätezuordnungen in
     MAPPED-DEVICES hergestellt werden und bevor die Dateisysteme in
     FILE-SYSTEMS eingebunden werden, damit der Anwender dabei die
     gewollte Tastaturbelegung beim Eingeben einer Passphrase und bei
     der Nutzung einer REPL verwenden kann.

     Wenn QEMU-NETWORKING? wahr ist, wird eine Netzwerkverbindung mit
     den Standard-QEMU-Parametern hergestellt. Wenn VIRTIO? wahr ist,
     werden zusätzliche Kernel-Module geladen, damit die initrd als ein
     QEMU-Gast paravirtualisierte Ein-/Ausgabetreiber benutzen kann.

     Wenn VOLATILE-ROOT? wahr ist, ist Schreiben auf das
     Wurzeldateisystem möglich, aber Änderungen daran bleiben nicht
     erhalten.

 -- Scheme-Prozedur: base-initrd DATEISYSTEME [#:mapped-devices '()]
          [#:keyboard-layout #f]  [#:qemu-networking? #f]
     [#:volatile-root? #f]  [#:linux-modules ’()] Liefert eine allgemein
     anwendbare, generische initrd als dateiartiges Objekt mit den
     Kernel-Modulen aus LINUX. Die FILE-SYSTEMS sind eine Liste von
     durch die initrd einzubindenden Dateisystemen, unter Umständen
     zusätzlich zum Wurzeldateisystem, das auf der Kernel-Befehlszeile
     mit ‘--root’ angegeben wurde. Die MAPPED-DEVICES sind eine Liste
     von Gerätezuordnungen, die hergestellt sein müssen, bevor die
     FILE-SYSTEMS eingebunden werden.

     Ist es auf einen wahren Wert gesetzt, dann muss KEYBOARD-LAYOUT
     eine Tastaturbelegung als ‘<keyboard-layout>’-Verbundsobjekt
     angeben, die die gewünschte Tastaturbelegung für die Konsole
     bezeichnet. Sie wird verwendet, noch bevor die Gerätezuordnungen in
     MAPPED-DEVICES hergestellt werden und bevor die Dateisysteme in
     FILE-SYSTEMS eingebunden werden, damit der Anwender dabei die
     gewollte Tastaturbelegung beim Eingeben einer Passphrase und bei
     der Nutzung einer REPL verwenden kann.

     QEMU-NETWORKING? und VOLATILE-ROOT? verhalten sich wie bei
     ‘raw-initrd’.

     In die initrd werden automatisch alle Kernel-Module eingefügt, die
     für die unter FILE-SYSTEMS angegebenen Dateisysteme und die
     angegebenen Optionen nötig sind. Zusätzliche Kernel-Module können
     unter den LINUX-MODULES aufgeführt werden. Diese werden zur initrd
     hinzugefügt und zur Boot-Zeit in der Reihenfolge geladen, in der
     sie angegeben wurden.

   Selbstverständlich betten die hier erzeugten und benutzten initrds
ein statisch gebundenes Guile ein und das Initialisierungsprogramm ist
ein Guile-Programm. Dadurch haben wir viel Flexibilität. Die Prozedur
‘expression->initrd’ erstellt eine solche initrd für ein an sie
übergebenes Programm.

 -- Scheme-Prozedur: expression->initrd G-AUSDRUCK [#:guile
          %guile-3.0-static-stripped] [#:name "guile-initrd"] Liefert
          eine
     Linux-initrd (d.h. ein gzip-komprimiertes cpio-Archiv) als
     dateiartiges Objekt, in dem GUILE enthalten ist, womit der
     G-AUSDRUCK nach dem Booten ausgewertet wird. Alle vom G-AUSDRUCK
     referenzierten Ableitungen werden automatisch in die initrd
     kopiert.


File: guix.de.info,  Node: Bootloader-Konfiguration,  Next: Aufruf von guix system,  Prev: Initiale RAM-Disk,  Up: Systemkonfiguration

10.13 Bootloader-Konfiguration
==============================

Das Betriebssystem unterstützt mehrere Bootloader. Der gewünschte
Bootloader wird mit der ‘bootloader-configuration’-Deklaration
konfiguriert. Alle Felder dieser Struktur sind für alle Bootloader
gleich außer dem einen Feld ‘bootloader’, das angibt, welcher Bootloader
konfiguriert und installiert werden soll.

   Manche der Bootloader setzen nicht alle Felder einer
‘bootloader-configuration’ um. Zum Beispiel ignoriert der
extlinux-Bootloader das ‘theme’-Feld, weil er keine eigenen Themen
unterstützt.

 -- Datentyp: bootloader-configuration
     Der Typ der Deklaration einer Bootloader-Konfiguration.

     ‘bootloader’
          Der zu benutzende Bootloader als ein ‘bootloader’-Objekt.
          Zurzeit werden ‘grub-bootloader’, ‘grub-efi-bootloader’,
          ‘grub-efi-netboot-bootloader’, ‘extlinux-bootloader’ und
          ‘u-boot-bootloader’ unterstützt.

          Verfügbare Bootloader werden in den Modulen ‘(gnu bootloader
          …)’ beschrieben. Insbesondere enthält ‘(gnu bootloader
          u-boot)’ Definitionen für eine Vielzahl von ARM- und
          AArch64-Systemen, die den U-Boot-Bootloader
          (https://www.denx.de/wiki/U-Boot/) benutzen.

          ‘grub-efi-bootloader’ macht es möglich, auf modernen Systemen
          mit “Unified Extensible Firmware Interface” (UEFI) zu booten.
          Sie sollten das hier benutzen, wenn im Installationsabbild ein
          Verzeichnis ‘/sys/firmware/efi’ vorhanden ist, wenn Sie davon
          auf Ihrem System booten.

          Mit ‘grub-bootloader’ können Sie vor allem auf Intel-basierten
          Maschinen im alten „Legacy“-BIOS-Modus booten.

          Mit ‘grub-efi-netboot-bootloader’ können Sie Ihr System via
          TFTP über das Netzwerk booten. Zusammen mit einem über NFS
          eingebundenen Wurzeldateisystem können Sie damit ein
          Guix-System ohne Plattenlaufwerk einrichten.

          Bei der Installation des ‘grub-efi-netboot-bootloader’ wird
          der Inhalt des als ‘target’ angegebenen
          TFTP-Wurzelverzeichnisses erzeugt (siehe *note ‘target’:
          Bootloader-Konfiguration.), so dass es von einem TFTP-Server
          bereitgestellt werden kann. Vielleicht möchten Sie dazu Ihr
          TFTP-Serververzeichnis zuvor als ‘target’ einbinden, damit die
          benötigten Dateien direkt auf den TFTP-Server aufgespielt
          werden.

          Wenn Sie außerdem vorhaben, ein NFS-Wurzeldateisystem zu
          benutzen (eigentlich auch, wenn Sie bloß den Store von einer
          NFS-Freigabe laden möchten), dann muss der TFTP-Server auch
          die Datei ‘/boot/grub/grub.cfg’ und die anderen Dateien vom
          Store zur Verfügung stellen, etwa GRUBs Hintergrundbild, den
          Kernel (siehe *note ‘kernel’: „operating-system“-Referenz.)
          und auch die initrd (siehe *note ‘initrd’:
          „operating-system“-Referenz.). Auf all diese Store-Dateien
          greift GRUB via TFTP über ihren normalen Store-Pfad zu, z.B.
          über ‘tftp://tftp-server/gnu/store/…-initrd/initrd.cpio.gz’.

          Um das möglich zu machen, erzeugt Guix zwei symbolische
          Verknüpfungen. Die erste ist
          ‘target’‘/efi/Guix/boot/grub/grub.cfg’, die auf
          ‘../../../boot/grub/grub.cfg’ zeigt, wobei das ‘target’ dem
          Pfad ‘/boot’ entsprechen kann. In diesem Fall verlässt die
          Verknüpfung das zugänglich gemachte TFTP-Wurzelverzeichnis
          _nicht_, in den anderen Fällen schon. Die zweite Verknüpfung
          ist ‘target’‘/gnu/store’ und zeigt auf ‘../gnu/store’. Diese
          Verknüpfung verlässt das zugänglich gemachte
          TFTP-Wurzelverzeichnis.

          Die Annahme hinter all dem ist, dass Sie einen NFS-Server
          haben, der das Wurzelverzeichnis für Ihr Guix-System
          exportiert, und außerdem einen TFTP-Server haben, der das als
          ‘target’ angegebene Verzeichnis liefert — normalerweise ist
          das ‘/boot’ —, was in demselben Wurzelverzeichnis Ihres
          Guix-Systems gespeichert vorliegt. In dieser Konstellation
          werden die symbolischen Verknüpfungen funktionieren.

          Bei anderen Konstellationen werden Sie Ihre eigene
          Bootloader-Installationsprozedur programmieren müssen, die
          sich darum kümmert, die nötigen Dateien aus dem Store über
          TFTP zugänglich zu machen, zum Beispiel indem diese in das
          TFTP-Wurzeldateisystem unter ‘target’ kopiert werden.

          Es ist wichtig, anzumerken, dass symbolische Verknüpfungen
          nach außerhalb des TFTP-Wurzelverzeichnisses vielleicht erst
          in der Konfiguration zugelassen werden müssen. Außerdem wird
          durch die Store-Verknüpfung der gesamte Store über TFTP
          offengelegt. Beides hat Auswirkungen auf die
          Informationssicherheit, welche Sie bedenken sollten.

          Abgesehen vom ‘grub-efi-netboot-bootloader’ und den bereits
          erwähnten TFTP- und NFS-Servern brauchen Sie auch einen
          passend eingerichteten DHCP-Server, der das Booten über das
          Netzwerk möglich macht. Derzeit können wir Ihnen bei all dem
          nur empfehlen, Anleitungen über die PXE (Preboot eXecution
          Environment) ausfindig zu machen.

     ‘target’
          Eine Zeichenkette, die angibt, auf welches Ziel der Bootloader
          installiert werden soll.

          Was das bedeutet, hängt vom jeweiligen Bootloader ab. Für
          ‘grub-bootloader’ sollte hier zum Beispiel ein Gerätename
          angegeben werden, der vom ‘installer’-Befehl des Bootloaders
          verstanden wird, etwa ‘/dev/sda’ oder ‘(hd0)’ (siehe *note
          (grub)Invoking grub-install::). Für ‘grub-efi-bootloader’
          sollte der Einhängepunkt des EFI-Dateisystems angegeben
          werden, in der Regel ‘/boot/efi’. Für
          ‘grub-efi-netboot-bootloader’ sollte ‘target’ der
          Einhängepunkt sein, unter dem das TFTP-Wurzelverzeichnis Ihres
          TFTP-Servers erreichbar ist.

     ‘menu-entries’ (Vorgabe: ‘()’)
          Eine möglicherweise leere Liste von ‘menu-entry’-Objekten
          (siehe unten), die für Menüeinträge stehen, die im
          Bootloader-Menü auftauchen sollen, zusätzlich zum aktuellen
          Systemeintrag und dem auf vorherige Systemgenerationen
          verweisenden Eintrag.

     ‘default-entry’ (Vorgabe: ‘0’)
          Die Position des standardmäßig ausgewählten Bootmenü-Eintrags.
          An Position 0 steht der Eintrag der aktuellen
          Systemgeneration.

     ‘timeout’ (Vorgabe: ‘5’)
          Wie viele Sekunden lang im Menü auf eine Tastatureingabe
          gewartet wird, bevor gebootet wird. 0 steht für sofortiges
          Booten, für -1 wird ohne Zeitbeschränkung gewartet.

     ‘keyboard-layout’ (Vorgabe: ‘#f’)
          Wenn dies auf ‘#f’ gesetzt ist, verwendet das Menü des
          Bootloaders (falls vorhanden) die Vorgabe-Tastaturbelegung,
          normalerweise US English („qwerty“).

          Andernfalls muss es ein ‘keyboard-layout’-Objekt sein (siehe
          *note Tastaturbelegung::).

               Anmerkung: Dieses Feld wird derzeit von Bootloadern außer
               ‘grub’ und ‘grub-efi’ ignoriert.

     ‘theme’ (Vorgabe: #F)
          Ein Objekt für das im Bootloader anzuzeigende Thema. Wird kein
          Thema angegeben, benutzen manche Bootloader vielleicht ein
          voreingestelltes Thema; GRUB zumindest macht es so.

     ‘terminal-outputs’ (Vorgabe: ‘'(gfxterm)’)
          Die Ausgabeterminals, die für das Boot-Menü des Bootloaders
          benutzt werden, als eine Liste von Symbolen. GRUB akzeptiert
          hier diese Werte: ‘console’, ‘serial’, ‘serial_{0–3}’,
          ‘gfxterm’, ‘vga_text’, ‘mda_text’, ‘morse’ und ‘pkmodem’.
          Dieses Feld entspricht der GRUB-Variablen
          ‘GRUB_TERMINAL_OUTPUT’ (siehe *note (grub)Simple
          configuration::).

     ‘terminal-inputs’ (Vorgabe: ‘'()’)
          Die Eingabeterminals, die für das Boot-Menü des Bootloaders
          benutzt werden, als eine Liste von Symbolen. GRUB verwendet
          hier das zur Laufzeit bestimmte Standardterminal. GRUB
          akzeptiert sonst diese Werte: ‘console’, ‘serial’,
          ‘serial_{0-3}’, ‘at_keyboard’ und ‘usb_keyboard’. Dieses Feld
          entspricht der GRUB-Variablen ‘GRUB_TERMINAL_INPUT’ (siehe
          *note (grub)Simple configuration::).

     ‘serial-unit’ (Vorgabe: ‘#f’)
          Die serielle Einheit, die der Bootloader benutzt, als eine
          ganze Zahl zwischen 0 und 3, einschließlich. Für GRUB wird sie
          automatisch zur Laufzeit ausgewählt; derzeit wählt GRUB die 0
          aus, die COM1 entspricht (siehe *note (grub)Serial
          terminal::).

     ‘serial-speed’ (Vorgabe: ‘#f’)
          Die Geschwindigkeit der seriellen Schnittstelle als eine ganze
          Zahl. GRUB bestimmt den Wert standardmäßig zur Laufzeit;
          derzeit wählt GRUB 9600 bps (siehe *note (grub)Serial
          terminal::).

   Sollten Sie zusätzliche Bootmenü-Einträge über das oben beschriebene
‘menu-entries’-Feld hinzufügen möchten, müssen Sie diese mit der
‘menu-entry’-Form erzeugen. Stellen Sie sich zum Beispiel vor, Sie
wollten noch eine andere Distribution booten können (schwer
vorstellbar!), dann könnten Sie einen Menüeintrag wie den Folgenden
definieren:

     (menu-entry
       (label "Die _andere_ Distribution")
       (linux "/boot/old/vmlinux-2.6.32")
       (linux-arguments '("root=/dev/sda2"))
       (initrd "/boot/old/initrd"))

   Details finden Sie unten.

 -- Datentyp: menu-entry
     Der Typ eines Eintrags im Bootloadermenü.

     ‘label’
          Die Beschriftung, die im Menü gezeigt werden soll — z.B.
          ‘"GNU"’.

     ‘linux’ (Vorgabe: ‘#f’)
          Das Linux-Kernel-Abbild, was gebootet werden soll, zum
          Beispiel:

               (file-append linux-libre "/bzImage")

          Für GRUB kann hier auch ein Gerät ausdrücklich zum Dateipfad
          angegeben werden, unter Verwendung von GRUBs Konventionen zur
          Gerätebenennung (siehe *note (grub)Naming convention::), zum
          Beispiel:

               "(hd0,msdos1)/boot/vmlinuz"

          Wenn das Gerät auf diese Weise ausdrücklich angegeben wird,
          wird das ‘device’-Feld gänzlich ignoriert.

     ‘linux-arguments’ (Vorgabe: ‘()’)
          Die Liste zusätzlicher Linux-Kernel-Befehlszeilenargumente —
          z.B. ‘("console=ttyS0")’.

     ‘initrd’ (Vorgabe: ‘#f’)
          Ein G-Ausdruck oder eine Zeichenkette, die den Dateinamen der
          initialen RAM-Disk angibt, die benutzt werden soll (siehe
          *note G-Ausdrücke::).

     ‘device’ (Vorgabe: ‘#f’)
          Das Gerät, auf dem Kernel und initrd zu finden sind — d.h. bei
          GRUB die Wurzel (“root”) dieses Menüeintrags (siehe *note
          (grub)root::).

          Dies kann eine Dateisystembezeichnung (als Zeichenkette), eine
          Dateisystem-UUID (als Bytevektor, siehe *note Dateisysteme::)
          oder ‘#f’ sein, im letzten Fall wird der Bootloader auf dem
          Gerät suchen, das die vom ‘linux’-Feld benannte Datei enthält
          (siehe *note (grub)search::). Ein vom Betriebssystem
          vergebener Gerätename wie ‘/dev/sda1’ ist aber _nicht_
          erlaubt.

     ‘multiboot-kernel’ (Vorgabe: ‘#f’)
          Der Kernel, der im Multiboot-Modus gebootet werden soll (siehe
          *note (grub)multiboot::). Wenn dieses Feld gesetzt ist, wird
          ein Multiboot-Menüeintrag erzeugt. Zum Beispiel:

               (file-append mach "/boot/gnumach")

     ‘multiboot-arguments’ (Vorgabe: ‘()’)
          Liste zusätzlicher Befehlszeilenoptionen für den
          Multiboot-Kernel.

     ‘multiboot-modules’ (Vorgabe: ‘()’)
          Die Liste der Befehle zum Laden von Multiboot-Modulen. Zum
          Beispiel:

               (list (list (file-append hurd "/hurd/ext2fs.static") "ext2fs"
                            …)
                     (list (file-append libc "/lib/ld.so.1") "exec"
                            …))

   Zurzeit lässt nur GRUB sein Aussehen durch Themen anpassen.
GRUB-Themen werden mit der ‘grub-theme’-Form erzeugt, die hier noch
nicht vollständig dokumentiert ist.

 -- Datentyp: grub-theme
     Der Datentyp, der die Konfiguration des GRUB-Themas repräsentiert.

     ‘gfxmode’ (Vorgabe: ‘'("auto")’)
          Welcher ‘gfxmode’ für GRUB eingestellt werden soll (als eine
          Liste von Zeichenketten mit Bildschirmauflösungen, siehe *note
          (grub)gfxmode::).

 -- Scheme-Prozedur: grub-theme
     Liefert das vorgegebene GRUB-Thema, das vom Betriebssystem benutzt
     wird, wenn kein ‘theme’-Feld im
     ‘bootloader-configuration’-Verbundsobjekt angegeben wurde.

     Es wird von einem feschen Hintergrundbild begleitet, das die Logos
     von GNU und Guix zeigt.

   Um zum Beispiel eine andere Auflösung als vorgegeben zu verwenden,
würden Sie so etwas schreiben:

     (bootloader
      (bootloader-configuration
      ;; …
      (theme (grub-theme
              (inherit (grub-theme))
              (gfxmode '("1024x786x32" "auto"))))))


File: guix.de.info,  Node: Aufruf von guix system,  Next: Aufruf von guix deploy,  Prev: Bootloader-Konfiguration,  Up: Systemkonfiguration

10.14 ‘guix system’ aufrufen
============================

Sobald Sie eine Betriebssystemdeklaration geschrieben haben, wie wir sie
in den vorangehenden Abschnitten gesehen haben, kann diese
“instanziiert” werden, indem Sie den Befehl ‘guix system’ aufrufen.
Zusammengefasst:

     guix system OPTIONEN… AKTION DATEI

   DATEI muss der Name einer Datei sein, in der eine
Betriebssystemdeklaration als ‘operating-system’-Objekt steht. AKTION
gibt an, wie das Betriebssystem instanziiert wird. Derzeit werden
folgende Werte dafür unterstützt:

‘search’
     Verfügbare Diensttypendefinitionen anzeigen, die zum angegebenen
     regulären Ausdruck passen, sortiert nach Relevanz:

          $ 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

          …

     Wie auch bei ‘guix package --search’ wird das Ergebnis im
     ‘recutils’-Format geliefert, so dass es leicht ist, die Ausgabe zu
     filtern (siehe *note GNU-recutils-Datenbanken: (recutils)Top.).

‘reconfigure’
     Das in der DATEI beschriebene Betriebssystem erstellen, aktivieren
     und zu ihm wechseln(1).

          Anmerkung: Es ist sehr zu empfehlen, ‘guix pull’ einmal
          auszuführen, bevor Sie ‘guix system reconfigure’ zum ersten
          Mal aufrufen (siehe *note Aufruf von guix pull::). Wenn Sie
          das nicht tun, könnten Sie nach dem Abschluss von
          ‘reconfigure’ eine ältere Version von Guix vorfinden, als Sie
          vorher hatten.

     Dieser Befehl setzt die in der DATEI festgelegte Konfiguration
     vollständig um: Benutzerkonten, Systemdienste, die Liste globaler
     Pakete, setuid-Programme und so weiter. Der Befehl startet die in
     der DATEI angegebenen Systemdienste, die aktuell nicht laufen; bei
     aktuell laufenden Diensten wird sichergestellt, dass sie
     aktualisiert werden, sobald sie das nächste Mal angehalten wurden
     (z.B. durch ‘herd stop X’ oder ‘herd restart X’).

     Dieser Befehl erzeugt eine neue Generation, deren Nummer (wie ‘guix
     system list-generations’ sie anzeigt) um eins größer als die der
     aktuellen Generation ist. Wenn die so nummerierte Generation
     bereits existiert, wird sie überschrieben. Dieses Verhalten
     entspricht dem von ‘guix package’ (siehe *note Aufruf von guix
     package::).

     Des Weiteren wird für den Bootloader ein Menüeintrag für die neue
     Betriebssystemkonfiguration hinzugefügt, außer die
     Befehlszeilenoption ‘--no-bootloader’ wurde übergeben. Bei GRUB
     werden Einträge für ältere Konfigurationen in ein Untermenü
     verschoben, so dass Sie auch eine ältere Systemgeneration beim
     Booten noch hochfahren können, falls es notwendig wird.

     Nach Abschluss wird das neue System unter ‘/run/current-system’
     verfügbar gemacht. Das Verzeichnis enthält “Provenienz-Metadaten”:
     Dazu gehören die Liste der Kanäle, die benutzt wurden (siehe *note
     Kanäle::) und die DATEI selbst, wenn sie verfügbar ist. Sie können
     sie auf diese Weise ansehen:

          guix system describe

     Diese Informationen sind nützlich, falls Sie später inspizieren
     möchten, wie diese spezielle Generation erstellt wurde. Falls die
     DATEI eigenständig ist, also keine anderen Dateien zum
     Funktionieren braucht, dann können Sie tatsächlich die Generation N
     Ihres Betriebssystems später erneut erstellen mit:

          guix time-machine \
            -C /var/guix/profiles/system-N-link/channels.scm -- \
            system reconfigure \
            /var/guix/profiles/system-N-link/configuration.scm

     Sie können sich das als eine Art eingebaute Versionskontrolle
     vorstellen! Ihr System ist nicht nur ein binäres Erzeugnis: _Es
     enthält seinen eigenen Quellcode_. Siehe *note
     ‘provenance-service-type’: Service-Referenz. für mehr Informationen
     zur Provenienzverfolgung.

     Nach Voreinstellung können Sie durch ‘reconfigure’ Ihr System
     _nicht auf eine ältere Version aktualisieren_ und somit
     herabstufen, denn dadurch könnten Sicherheitslücken eingeführt und
     Probleme mit „zustandsbehafteten“ Diensten wie z.B.
     Datenbankverwaltungssystemen ausgelöst werden. Sie können das
     Verhalten ändern, indem Sie ‘--allow-downgrades’ übergeben.

‘switch-generation’
     Zu einer bestehenden Systemgeneration wechseln. Diese Aktion
     wechselt das Systemprofil atomar auf die angegebene
     Systemgeneration. Hiermit werden auch die bestehenden Menüeinträge
     des Bootloaders umgeordnet. Der Menüeintrag für die angegebene
     Systemgeneration wird voreingestellt und die Einträge der anderen
     Generationen werden in ein Untermenü verschoben, sofern der
     verwendete Bootloader dies unterstützt. Das nächste Mal, wenn das
     System gestartet wird, wird die hier angegebene Systemgeneration
     hochgefahren.

     Der Bootloader selbst wird durch diesen Befehl _nicht_ neu
     installiert. Es wird also lediglich der bereits installierte
     Bootloader mit einer neuen Konfigurationsdatei benutzt werden.

     Die Zielgeneration kann ausdrücklich über ihre Generationsnummer
     angegeben werden. Zum Beispiel würde folgender Aufruf einen Wechsel
     zur Systemgeneration 7 bewirken:

          guix system switch-generation 7

     Die Zielgeneration kann auch relativ zur aktuellen Generation
     angegeben werden, in der Form ‘+N’ oder ‘-N’, wobei ‘+3’ zum
     Beispiel „3 Generationen weiter als die aktuelle Generation“
     bedeuten würde und ‘-1’ „1 Generation vor der aktuellen Generation“
     hieße. Wenn Sie einen negativen Wert wie ‘-1’ angeben, müssen Sie
     ‘--’ der Befehlszeilenoption voranstellen, damit die negative Zahl
     nicht selbst als Befehlszeilenoption aufgefasst wird. Zum Beispiel:

          guix system switch-generation -- -1

     Zurzeit bewirkt ein Aufruf dieser Aktion _nur_ einen Wechsel des
     Systemprofils auf eine bereits existierende Generation und ein
     Umordnen der Bootloader-Menüeinträge. Um die Ziel-Systemgeneration
     aber tatsächlich zu benutzen, müssen Sie Ihr System neu hochfahren,
     nachdem Sie diese Aktion ausgeführt haben. In einer zukünftigen
     Version von Guix wird diese Aktion einmal dieselben Dinge tun, wie
     ‘reconfigure’, also etwa Dienste aktivieren und deaktivieren.

     Diese Aktion schlägt fehl, wenn die angegebene Generation nicht
     existiert.

‘roll-back’
     Zur vorhergehenden Systemgeneration wechseln. Wenn das System das
     nächste Mal hochgefahren wird, wird es die vorhergehende
     Systemgeneration benutzen. Dies ist die Umkehrung von ‘reconfigure’
     und tut genau dasselbe, wie ‘switch-generation’ mit dem Argument
     ‘-1’ aufzurufen.

     Wie auch bei ‘switch-generation’ müssen Sie derzeit, nachdem Sie
     diese Aktion aufgerufen haben, Ihr System neu starten, um die
     vorhergehende Systemgeneration auch tatsächlich zu benutzen.

‘delete-generations’
     Systemgenerationen löschen, wodurch diese zu Kandidaten für den
     Müllsammler werden (siehe *note Aufruf von guix gc:: für
     Informationen, wie Sie den „Müllsammler“ laufen lassen).

     Es funktioniert auf die gleiche Weise wie ‘guix package
     --delete-generations’ (siehe *note ‘--delete-generations’: Aufruf
     von guix package.). Wenn keine Argumente angegeben werden, werden
     alle Systemgenerationen außer der aktuellen gelöscht:

          guix system delete-generations

     Sie können auch eine Auswahl treffen, welche Generationen Sie
     löschen möchten. Das folgende Beispiel hat die Löschung aller
     Systemgenerationen zur Folge, die älter als zwei Monate sind:

          guix system delete-generations 2m

     Wenn Sie diesen Befehl ausführen, wird automatisch der Bootloader
     mit einer aktualisierten Liste von Menüeinträgen neu erstellt —
     z.B. werden im Untermenü für die „alten Generationen“ in GRUB die
     gelöschten Generationen nicht mehr aufgeführt.

‘build’
     Die Ableitung des Betriebssystems erstellen, einschließlich aller
     Konfigurationsdateien und Programme, die zum Booten und Starten
     benötigt werden. Diese Aktion installiert jedoch nichts davon.

‘init’
     In das angegebene Verzeichnis alle Dateien einfügen, um das in der
     DATEI angegebene Betriebssystem starten zu können. Dies ist
     nützlich bei erstmaligen Installationen von „Guix System“. Zum
     Beispiel:

          guix system init my-os-config.scm /mnt

     Hiermit werden alle Store-Objekte nach ‘/mnt’ kopiert, die von der
     in ‘my-os-config.scm’ angegebenen Konfiguration vorausgesetzt
     werden. Dazu gehören Konfigurationsdateien, Pakete und so weiter.
     Auch andere essenzielle Dateien, die auf dem System vorhanden sein
     müssen, damit es richtig funktioniert, werden erzeugt — z.B. die
     Verzeichnisse ‘/etc’, ‘/var’ und ‘/run’ und die Datei ‘/bin/sh’.

     Dieser Befehl installiert auch den Bootloader auf dem in
     ‘my-os-config’ angegebenen Ziel, außer die Befehlszeilenoption
     ‘--no-bootloader’ wurde übergeben.

‘vm’
     Eine virtuelle Maschine (VM) erstellen, die das in der DATEI
     deklarierte Betriebssystem enthält, und ein Skript liefern, das
     diese virtuelle Maschine startet.

          Anmerkung: Die Aktion ‘vm’ sowie solche, die weiter unten
          genannt werden, können KVM-Unterstützung im Kernel Linux-libre
          ausnutzen. Insbesondere sollte, wenn die Maschine
          Hardware-Virtualisierung unterstützt, das entsprechende
          KVM-Kernelmodul geladen sein und das Gerät ‘/dev/kvm’ muss
          dann existieren und dem Benutzer und den Erstellungsbenutzern
          des Daemons müssen Berechtigungen zum Lesen und Schreiben
          darauf gegeben werden (siehe *note Einrichten der
          Erstellungsumgebung::).

     An das Skript übergebene Argumente werden an QEMU weitergereicht,
     wie Sie am folgenden Beispiel sehen können. Damit würde eine
     Netzwerkverbindung aktiviert und 1 GiB an RAM für die emulierte
     Maschine angefragt:

          $ /gnu/store/…-run-vm.sh -m 1024 -smp 2 -net user,model=virtio-net-pci

     Die virtuelle Maschine verwendet denselben Store wie das
     Wirtssystem.

     Mit den Befehlszeilenoptionen ‘--share’ und ‘--expose’ können
     weitere Dateisysteme zwischen dem Wirtssystem und der VM geteilt
     werden: Der erste Befehl gibt ein mit Schreibzugriff zu teilendes
     Verzeichnis an, während der letzte Befehl nur Lesezugriff auf das
     gemeinsame Verzeichnis gestattet.

     Im folgenden Beispiel wird eine virtuelle Maschine erzeugt, die auf
     das Persönliche Verzeichnis des Benutzers nur Lesezugriff hat, wo
     das Verzeichnis ‘/austausch’ aber mit Lese- und Schreibzugriff dem
     Verzeichnis ‘$HOME/tmp’ auf dem Wirtssystem zugeordnet wurde:

          guix system vm my-config.scm \
             --expose=$HOME --share=$HOME/tmp=/austausch

     Für GNU/Linux ist das vorgegebene Verhalten, direkt in den Kernel
     zu booten, wodurch nur ein sehr winziges „Disk-Image“ (eine Datei
     mit einem Abbild des Plattenspeichers der virtuellen Maschine) für
     das Wurzeldateisystem nötig wird, weil der Store des Wirtssystems
     davon eingebunden werden kann.

     Mit der Befehlszeilenoption ‘--full-boot’ wird erzwungen, einen
     vollständigen Bootvorgang durchzuführen, angefangen mit dem
     Bootloader. Dadurch wird mehr Plattenplatz verbraucht, weil dazu
     ein Disk-Image mindestens mit dem Kernel, initrd und
     Bootloader-Datendateien erzeugt werden muss. Mit der
     Befehlszeilenoption ‘--image-size’ kann die Größe des Disk-Images
     angegeben werden.

‘image’
‘docker-image’
     Ein eigenständiges Disk-Image für eine virtuelle Maschine, ein
     allgemeines Disk-Image oder ein Docker-Abbild für das in der DATEI
     deklarierte Betriebssystem liefern. Das vorgegebene Verhalten von
     ‘guix system’ ist, die Größe des Images zu schätzen, die zum
     Speichern des Systems benötigt wird, aber Sie können mit der
     Befehlszeilenoption ‘--image-size’ selbst Ihre gewünschte Größe
     bestimmen. Docker-Abbilder werden aber so erstellt, dass sie gerade
     nur das enthalten, was für sie nötig ist, daher wird die
     Befehlszeilenoption ‘--image-size’ im Fall von ‘docker-image’
     ignoriert.

     Mit dem Befehl ‘image’ können mehrere Abbildtypen erzeugt werden.
     Der Abbildtyp kann durch die Befehlszeilenoption ‘--image-type’
     ausgewählt werden. Vorgegeben ist ‘efi-raw’. Für den Wert ‘iso9660’
     kann mit der Befehlszeilenoption ‘--label’ eine Datenträgerkennung
     („Volume ID“) angegeben werden. Nach Vorgabe wird das
     Wurzeldateisystem eines Abbilds als nicht-flüchtig eingebunden.
     Wenn die Befehlszeilenoption ‘--volatile’ angegeben wird, dann sind
     Änderungen daran bloß flüchtig. Bei der Verwendung von ‘image’ wird
     auf dem erzeugten Abbild derjenige Bootloader installiert, der in
     der ‘operating-system’-Definition angegeben wurde. Das folgende
     Beispiel zeigt, wie Sie ein Abbild erzeugen, das als Bootloader
     ‘grub-efi-bootloader’ benutzt, und es mit QEMU starten:

          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

     Wenn Sie den Abbildtyp ‘efi-raw’ anfordern, wird ein rohes
     Disk-Image hergestellt; es kann zum Beispiel auf einen USB-Stick
     kopiert werden. Angenommen ‘/dev/sdc’ ist das dem USB-Stick
     entsprechende Gerät, dann kann das Disk-Image mit dem folgenden
     Befehls darauf kopiert werden:

          # dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress

     Durch die Befehlszeilenoption ‘--list-image-types’ werden alle
     verfügbaren Abbildtypen aufgelistet.

     Wenn Sie den Abbildtypen ‘qcow2’ benutzen, wird ein Abbild im
     qcow2-Format geliefert, das vom QEMU-Emulator effizient benutzt
     werden kann. Siehe *note Guix in einer VM starten:: für weitere
     Informationen, wie Sie das Abbild in einer virtuellen Maschine
     ausführen. Als Bootloader wird immer ‘grub-bootloader’ benutzt,
     egal was in der als Argument übergebenen ‘operating-system’-Datei
     deklariert wurde. Der Grund dafür ist, dass dieser besser mit QEMU
     funktioniert, das als BIOS nach Voreinstellung SeaBIOS benutzt, wo
     erwartet wird, dass ein Bootloader in den Master Boot Record (MBR)
     installiert wurde.

     Wenn Sie ein ‘docker-image’ anfordern, wird ein Abbild für Docker
     hergestellt. Guix erstellt das Abbild von Grund auf und _nicht_ aus
     einem vorerstellten Docker-Basisabbild heraus, daher enthält es
     _exakt_ das, was Sie in der Konfigurationsdatei für das
     Betriebssystem angegeben haben. Sie können das Abbild dann wie
     folgt laden und einen Docker-Container damit erzeugen:

          image_id="$(docker load < guix-system-docker-image.tar.gz)"
          container_id="$(docker create $image_id)"
          docker start $container_id

     Dieser Befehl startet einen neuen Docker-Container aus dem
     angegebenen Abbild. Damit wird das Guix-System auf die normale
     Weise hochgefahren, d.h. zunächst werden alle Dienste gestartet,
     die Sie in der Konfiguration des Betriebssystems angegeben haben.
     Sie können eine interaktive Shell in dieser isolierten Umgebung
     bekommen, indem Sie ‘docker exec’ benutzen:

          docker exec -ti $container_id /run/current-system/profile/bin/bash --login

     Je nachdem, was Sie im Docker-Container ausführen, kann es nötig
     sein, dass Sie ihn mit weitergehenden Berechtigungen ausstatten.
     Wenn Sie zum Beispiel Software mit Guix innerhalb des
     Docker-Containers erstellen wollen, müssen Sie an ‘docker create’
     die Befehlszeilenoption ‘--privileged’ übergeben.

     Zuletzt bewirkt die Befehlszeilenoption ‘--network’, dass durch
     ‘guix system docker-image’ ein Abbild erzeugt wird, was sein
     Netzwerk mit dem Wirtssystem teilt und daher auf Dienste wie nscd
     oder NetworkManager verzichten sollte.

‘container’
     Liefert ein Skript, um das in der DATEI deklarierte Betriebssystem
     in einem Container auszuführen. Mit Container wird hier eine Reihe
     ressourcenschonender Isolierungsmechanismen im Kernel Linux-libre
     bezeichnet. Container beanspruchen wesentlich weniger Ressourcen
     als vollumfängliche virtuelle Maschinen, weil der Kernel,
     Bibliotheken in gemeinsam nutzbaren Objektdateien („Shared
     Objects“) sowie andere Ressourcen mit dem Wirtssystem geteilt
     werden können. Damit ist also eine „dünnere“ Isolierung möglich.

     Zurzeit muss das Skript als Administratornutzer „root“ ausgeführt
     werden, damit darin mehr als nur ein einzelner Benutzer und eine
     Benutzergruppe unterstützt wird. Der Container teilt seinen Store
     mit dem Wirtssystem.

     Wie bei der Aktion ‘vm’ (siehe *note guix system vm::) können
     zusätzlich weitere Dateisysteme zwischen Wirt und Container geteilt
     werden, indem man die Befehlszeilenoptionen ‘--share’ und
     ‘--expose’ verwendet:

          guix system container my-config.scm \
             --expose=$HOME --share=$HOME/tmp=/austausch

          Anmerkung: Diese Befehlszeilenoption funktioniert nur mit
          Linux-libre 3.19 oder neuer.

   Unter den OPTIONEN können beliebige gemeinsame Erstellungsoptionen
aufgeführt werden (siehe *note Gemeinsame Erstellungsoptionen::). Des
Weiteren kann als OPTIONEN Folgendes angegeben werden:

‘--expression=AUSDRUCK’
‘-e AUSDRUCK’
     Als Konfiguration des Betriebssystems das „operating-system“
     betrachten, zu dem der AUSDRUCK ausgewertet wird. Dies ist eine
     Alternative dazu, die Konfiguration in einer Datei festzulegen.
     Hiermit wird auch das Installationsabbild des Guix-Systems
     erstellt, siehe *note Ein Abbild zur Installation erstellen::).

‘--system=SYSTEM’
‘-s SYSTEM’
     Versuchen, für das angegebene SYSTEM statt für denselben Systemtyp
     wie auf dem Wirtssystem zu erstellen. Dies funktioniert wie bei
     ‘guix build’ (siehe *note Aufruf von guix build::).

‘--derivation’
‘-d’
     Liefert den Namen der Ableitungsdatei für das angegebene
     Betriebssystem, ohne dazu etwas zu erstellen.

‘--save-provenance’
     Wie zuvor erläutert, speichern ‘guix system init’ und ‘guix system
     reconfigure’ Provenienzinformationen immer über einen dedizierten
     Dienst (siehe *note ‘provenance-service-type’: Service-Referenz.).
     Andere Befehle tun das nach Voreinstellung jedoch _nicht_. Wenn Sie
     zum Beispiel ein Abbild für eine virtuelle Maschine mitsamt
     Provenienzinformationen erzeugen möchten, können Sie dies
     ausführen:

          guix system image -t qcow2 --save-provenance config.scm

     Auf diese Weise wird im erzeugten Abbild im Prinzip „sein eigener
     Quellcode eingebettet“, in Form von Metadaten in
     ‘/run/current-system’. Mit diesen Informationen kann man das Abbild
     neu erzeugen, um sicherzugehen, dass es tatsächlich das enthält,
     was davon behauptet wird. Man könnte damit auch eine Abwandlung des
     Abbilds erzeugen.

‘--image-type=TYP’
‘-t TYP’
     Für die Aktion ‘image’ wird ein Abbild des angegebenen TYPs
     erzeugt.

     Wird diese Befehlszeilenoption nicht angegeben, so benutzt ‘guix
     system’ den Abbildtyp ‘efi-raw’.

     ‘--image-type=iso9660’ erzeugt ein Abbild im Format ISO-9660, was
     für das Brennen auf CDs und DVDs geeignet ist.

‘--image-size=GRÖSSE’
     Für die Aktion ‘image’ wird hiermit festgelegt, dass ein Abbild der
     angegebenen GRÖSSE erstellt werden soll. Die GRÖSSE kann als Zahl
     die Anzahl Bytes angeben oder mit einer Einheit als Suffix versehen
     werden (siehe *note Größenangaben: (coreutils)Block size.).

     Wird keine solche Befehlszeilenoption angegeben, berechnet ‘guix
     system’ eine Schätzung der Abbildgröße anhand der Größe des in der
     DATEI deklarierten Systems.

‘--network’
‘-N’
     Für die Aktion ‘container’ dürfen isolierte Umgebungen (auch
     bekannt als „Container“) auf das Wirtsnetzwerk zugreifen, d.h. es
     wird kein Netzwerknamensraum für sie erzeugt.

‘--root=DATEI’
‘-r DATEI’
     Die DATEI zu einer symbolischen Verknüpfung auf das Ergebnis machen
     und als Müllsammlerwurzel registrieren.

‘--skip-checks’
     Die Konfiguration _nicht_ vor der Installation zur Sicherheit auf
     Fehler prüfen.

     Das vorgegebene Verhalten von ‘guix system init’ und ‘guix system
     reconfigure’ sieht vor, die Konfiguration zur Sicherheit auf Fehler
     hin zu überprüfen, die ihr Autor übersehen haben könnte: Es wird
     sichergestellt, dass die in der ‘operating-system’-Deklaration
     erwähnten Dateisysteme tatsächlich existieren (siehe *note
     Dateisysteme::) und dass alle Linux-Kernelmodule, die beim Booten
     benötigt werden könnten, auch im ‘initrd-modules’-Feld aufgeführt
     sind (siehe *note Initiale RAM-Disk::). Mit dieser
     Befehlszeilenoption werden diese Tests allesamt übersprungen.

‘--allow-downgrades’
     An ‘guix system reconfigure’ die Anweisung erteilen,
     Systemherabstufungen zuzulassen.

     Nach Voreinstellung können Sie mit ‘reconfigure’ Ihr System nicht
     auf eine ältere Version aktualisieren und somit herabstufen. Dazu
     werden die Provenienzinformationen Ihres Systems herangezogen (wie
     sie auch von ‘guix system describe’ angezeigt werden) und mit denen
     aus Ihrem ‘guix’-Befehl verglichen (wie sie ‘guix describe’
     anzeigt). Wenn die Commits von ‘guix’ nicht Nachfolger derer Ihres
     Systems sind, dann bricht ‘guix system reconfigure’ mit einer
     Fehlermeldung ab. Wenn Sie ‘--allow-downgrades’ übergeben, können
     Sie diese Sicherheitsüberprüfungen umgehen.

          Anmerkung: Sie sollten verstehen, was es für die Sicherheit
          Ihres Rechners bedeutet, ehe Sie ‘--allow-downgrades’
          benutzen.

‘--on-error=STRATEGIE’
     Beim Auftreten eines Fehlers beim Einlesen der DATEI die angegebene
     STRATEGIE verfolgen. Als STRATEGIE dient eine der Folgenden:

     ‘nothing-special’
          Nichts besonderes; der Fehler wird kurz gemeldet und der
          Vorgang abgebrochen. Dies ist die vorgegebene Strategie.

     ‘backtrace’
          Ebenso, aber zusätzlich wird eine Rückverfolgung des Fehlers
          (ein „Backtrace“) angezeigt.

     ‘debug’
          Nach dem Melden des Fehlers wird der Debugger von Guile zur
          Fehlersuche gestartet. Von dort können Sie Befehle ausführen,
          zum Beispiel können Sie sich mit ‘,bt’ eine Rückverfolgung
          („Backtrace“) anzeigen lassen und mit ‘,locals’ die Werte
          lokaler Variabler anzeigen lassen. Im Allgemeinen können Sie
          mit Befehlen den Zustand des Programms inspizieren. Siehe
          *note (guile)Debug Commands:: für eine Liste verfügbarer
          Befehle zur Fehlersuche.

   Sobald Sie Ihre Guix-Installation erstellt, konfiguriert, neu
konfiguriert und nochmals neu konfiguriert haben, finden Sie es
vielleicht hilfreich, sich die auf der Platte verfügbaren — und im
Bootmenü des Bootloaders auswählbaren — Systemgenerationen auflisten zu
lassen:

‘describe’
     Die aktuelle Systemgeneration beschreiben: ihren Dateinamen, den
     Kernel und den benutzten Bootloader etc. sowie
     Provenienzinformationen, falls verfügbar.

‘list-generations’
     Eine für Menschen verständliche Zusammenfassung jeder auf der
     Platte verfügbaren Generation des Betriebssystems ausgeben. Dies
     ähnelt der Befehlszeilenoption ‘--list-generations’ von ‘guix
     package’ (siehe *note Aufruf von guix package::).

     Optional kann ein Muster angegeben werden, was dieselbe Syntax wie
     ‘guix package --list-generations’ benutzt, um damit die Liste
     anzuzeigender Generationen einzuschränken. Zum Beispiel zeigt der
     folgende Befehl Generationen an, die bis zu 10 Tage alt sind:

          $ guix system list-generations 10d

   Der Befehl ‘guix system’ hat sogar noch mehr zu bieten! Mit folgenden
Unterbefehlen wird Ihnen visualisiert, wie Ihre Systemdienste
voneinander abhängen:

‘extension-graph’
     Auf die Standardausgabe den “Diensterweiterungsgraphen” des in der
     DATEI definierten Betriebssystems ausgeben (siehe *note
     Dienstkompositionen:: für mehr Informationen zu
     Diensterweiterungen). Vorgegeben ist, ihn im Dot-/Graphviz-Format
     auszugeben, aber Sie können ein anderes Format mit
     ‘--graph-backend’ auswählen, genau wie bei ‘guix graph’ (siehe
     *note ‘--backend’: Aufruf von guix graph.):

     Der Befehl:

          $ guix system extension-graph DATEI | xdot -

     zeigt die Erweiterungsrelation unter Diensten an.

‘shepherd-graph’
     Auf die Standardausgabe den “Abhängigkeitsgraphen” der
     Shepherd-Dienste des in der DATEI definierten Betriebssystems
     ausgeben. Siehe *note Shepherd-Dienste:: für mehr Informationen
     sowie einen Beispielgraphen.

     Auch hier wird nach Vorgabe die Ausgabe im Dot-/Graphviz-Format
     sein, aber Sie können ein anderes Format mit ‘--graph-backend’
     auswählen.

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

   (1) Diese Aktion (und die dazu ähnlichen Aktionen ‘switch-generation’
und ‘roll-back’) sind nur auf Systemen nutzbar, auf denen „Guix System“
bereits läuft.

