\input texinfo @c =========================================================================== @c @c This file was generated with po4a. Translate the source file. @c @c =========================================================================== @c -*-texinfo-*- @c %**start of header @setfilename guix.de.info @documentencoding UTF-8 @documentlanguage de @frenchspacing on @settitle Referenzhandbuch zu GNU Guix @c %**end of header @include version-de.texi @c Identifier of the OpenPGP key used to sign tarballs and such. @set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 @set KEY-SERVER pool.sks-keyservers.net @c The official substitute server used by default. @set SUBSTITUTE-SERVER ci.guix.de.info @copying Copyright @copyright{} 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès@* Copyright @copyright{} 2013, 2014, 2016 Andreas Enge@* Copyright @copyright{} 2013 Nikita Karetnikov@* Copyright @copyright{} 2014, 2015, 2016 Alex Kost@* Copyright @copyright{} 2015, 2016 Mathieu Lirzin@* Copyright @copyright{} 2014 Pierre-Antoine Rault@* Copyright @copyright{} 2015 Taylan Ulrich Bayırlı/Kammer@* Copyright @copyright{} 2015, 2016, 2017 Leo Famulari@* Copyright @copyright{} 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus@* Copyright @copyright{} 2016 Ben Woodcroft@* Copyright @copyright{} 2016, 2017, 2018 Chris Marusich@* Copyright @copyright{} 2016, 2017, 2018, 2019 Efraim Flashner@* Copyright @copyright{} 2016 John Darrington@* Copyright @copyright{} 2016, 2017 ng0@* Copyright @copyright{} 2016, 2017, 2018, 2019 Jan Nieuwenhuizen@* Copyright @copyright{} 2016 Julien Lepiller@* Copyright @copyright{} 2016 Alex ter Weele@* Copyright @copyright{} 2016, 2017, 2018, 2019 Christopher Baines@* Copyright @copyright{} 2017, 2018 Clément Lassieur@* Copyright @copyright{} 2017, 2018 Mathieu Othacehe@* Copyright @copyright{} 2017 Federico Beffa@* Copyright @copyright{} 2017, 2018 Carlo Zancanaro@* Copyright @copyright{} 2017 Thomas Danckaert@* Copyright @copyright{} 2017 humanitiesNerd@* Copyright @copyright{} 2017 Christopher Allan Webber@* Copyright @copyright{} 2017, 2018 Marius Bakke@* Copyright @copyright{} 2017 Hartmut Goebel@* Copyright @copyright{} 2017 Maxim Cournoyer@* Copyright @copyright{} 2017, 2018 Tobias Geerinckx-Rice@* Copyright @copyright{} 2017 George Clemmer@* Copyright @copyright{} 2017 Andy Wingo@* Copyright @copyright{} 2017, 2018, 2019 Arun Isaac@* Copyright @copyright{} 2017 nee@* Copyright @copyright{} 2018 Rutger Helling@* Copyright @copyright{} 2018 Oleg Pykhalov@* Copyright @copyright{} 2018 Mike Gerwitz@* Copyright @copyright{} 2018 Pierre-Antoine Rouby@* Copyright @copyright{} 2018 Gábor Boskovits@* Copyright @copyright{} 2018 Florian Pelz@* Copyright @copyright{} 2018 Laura Lazzati@* Copyright @copyright{} 2018 Alex Vong@* 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«. @end copying @dircategory Systemadministration @direntry * 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. @end direntry @dircategory Softwareentwicklung @direntry * 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 direntry @titlepage @title Referenzhandbuch zu GNU Guix @subtitle Den funktionalen Paketmanager GNU Guix benutzen @author Die GNU-Guix-Entwickler @page @vskip 0pt plus 1filll Edition @value{EDITION} @* @value{UPDATED} @* @insertcopying @end titlepage @contents @c ********************************************************************* @node Top @top GNU Guix Dieses Dokument beschreibt GNU Guix, Version @value{VERSION}, ein Werkzeug zur funktionalen Verwaltung von Softwarepaketen, das für das GNU-System geschrieben wurde. @c TRANSLATORS: You can replace the following paragraph with information on @c how to join your own translation team and how to report issues with the @c translation. Dieses Handbuch ist auch auf Englisch (siehe @ref{Top,,, guix, GNU Guix Reference Manual}) und Französisch verfügbar (siehe @ref{Top,,, guix.fr, Manuel de référence de GNU Guix}). Wenn Sie es in Ihre eigene Sprache übersetzen möchten, dann sind Sie beim @uref{https://translationproject.org/domain/guix-manual.html, Translation Project} herzlich willkommen. @menu * Einführung:: Was ist Guix überhaupt? * Installation:: Guix installieren. * Systeminstallation:: Das ganze Betriebssystem installieren. * Paketverwaltung:: Pakete installieren, aktualisieren usw. * Entwicklung:: Von Guix unterstützte Softwareentwicklung. * Programmierschnittstelle:: Guix in Scheme verwenden. * Zubehör:: Befehle zur Paketverwaltung. * Systemkonfiguration:: Das Betriebssystem konfigurieren. * Dokumentation:: Wie man Nutzerhandbücher von Software liest. * Dateien zur Fehlersuche installieren:: Womit man seinen Debugger füttert. * Sicherheitsaktualisierungen:: Sicherheits-Patches schnell einspielen. * Bootstrapping:: GNU/Linux von Grund auf selbst erstellen. * Portierung:: Guix auf andere Plattformen und Kernels bringen. * Mitwirken:: Ihre Hilfe ist nötig! * Danksagungen:: Danke! * GNU-Lizenz für freie Dokumentation:: Die Lizenz dieses Handbuchs. * Konzeptverzeichnis:: Konzepte. * Programmierverzeichnis:: Datentypen, Funktionen und Variable. @detailmenu --- Detaillierte Liste der Knoten --- Einführung * Auf Guix-Art Software verwalten:: Was Guix besonders macht. * GNU-Distribution:: Die Pakete und Werkzeuge. Installation * Aus Binärdatei installieren:: Guix installieren, ohne Zeit zu verlieren! * Voraussetzungen:: Zum Erstellen und Benutzen von Guix nötige Software. * Den Testkatalog laufen lassen:: Guix testen. * Den Daemon einrichten:: Wie man die Umgebung des Erstellungs-Daemons einrichtet. * Aufruf des guix-daemon:: Den Erstellungs-Daemon laufen lassen. * Anwendungen einrichten:: Anwendungsspezifische Einstellungen. Den Daemon einrichten * Einrichten der Erstellungsumgebung:: Die isolierte Umgebung zum Erstellen vorbereiten. * Auslagern des Daemons einrichten:: Erstellungen auf entfernte Maschinen auslagern. * SELinux-Unterstützung:: Wie man eine SELinux-Richtlinie für den Daemon einrichtet. Systeminstallation * Einschränkungen:: Was Sie erwarten dürfen. * Hardware-Überlegungen:: Unterstützte Hardware. * Installation von USB-Stick oder DVD:: Das Installationsmedium vorbereiten. * Vor der Installation:: Netzwerkanbindung, Partitionierung etc. * Geführte grafische Installation:: Leichte grafische Installation. * Manuelle Installation:: Manuelle Installation für Zauberer. * Nach der Systeminstallation:: Wenn die Installation erfolgreich war. * Guix in einer VM installieren:: Ein »Guix System«-Spielplatz. * Ein Abbild zur Installation erstellen:: Wie ein solches entsteht. Manuelle Installation * Tastaturbelegung und Netzwerkanbindung und Partitionierung:: Erstes Einrichten. * Fortfahren mit der Installation:: Installieren. Paketverwaltung * Funktionalitäten:: Wie Guix Ihr Leben schöner machen wird. * Aufruf von guix package:: Pakete installieren, entfernen usw. * Substitute:: Vorerstelle Binärdateien herunterladen. * Pakete mit mehreren Ausgaben.:: Ein Quellpaket, mehrere Ausgaben. * Aufruf von guix gc:: Den Müllsammler laufen lassen. * Aufruf von guix pull:: Das neueste Guix samt Distribution laden. * Kanäle:: Die Paketsammlung anpassen. * Untergeordnete:: Mit einer anderen Version von Guix interagieren. * Aufruf von guix describe:: Informationen über Ihre Guix-Version anzeigen. * Aufruf von guix archive:: Import und Export von Store-Dateien. Substitute * Offizieller Substitut-Server:: Eine besondere Quelle von Substituten. * Substitut-Server autorisieren:: Wie man Substitute an- und abschaltet. * Substitutauthentifizierung:: Wie Guix Substitute verifiziert. * Proxy-Einstellungen:: Wie Sie Substitute über einen Proxy beziehen. * Fehler bei der Substitution:: Was passiert, wenn die Substitution fehlschlägt. * Vom Vertrauen gegenüber Binärdateien:: Wie können Sie diesem binären Blob trauen? Entwicklung * Aufruf von guix environment:: Entwicklungsumgebungen einrichten. * Aufruf von guix pack:: Software-Bündel erstellen. Programmierschnittstelle * Paketmodule:: Pakete aus Sicht des Programmierers. * Pakete definieren:: Wie Sie neue Pakete definieren. * Erstellungssysteme:: Angeben, wie Pakete erstellt werden. * Der Store:: Den Paket-Store verändern. * Ableitungen:: Systemnahe Schnittstelle für Paketableitungen. * Die Store-Monade:: Rein funktionale Schnittstelle zum Store. * G-Ausdrücke:: Erstellungsausdrücke verarbeiten. * Aufruf von guix repl:: Interaktiv an Guix herumbasteln. Pakete definieren * »package«-Referenz:: Der Datentyp für Pakete. * »origin«-Referenz:: Datentyp für Paketursprünge. Zubehör * Aufruf von guix build:: Pakete aus der Befehlszeile heraus erstellen. * Aufruf von guix edit:: Paketdefinitionen bearbeiten. * Aufruf von guix download:: Herunterladen einer Datei und Ausgabe ihres Hashes. * Aufruf von guix hash:: Den kryptografischen Hash einer Datei berechnen. * Aufruf von guix import:: Paketdefinitionen importieren. * Aufruf von guix refresh:: Paketdefinitionen aktualisieren. * Aufruf von guix lint:: Fehler in Paketdefinitionen finden. * Aufruf von guix size:: Plattenplatzverbrauch profilieren. * Aufruf von guix graph:: Den Paketgraphen visualisieren. * Aufruf von guix publish:: Substitute teilen. * Aufruf von guix challenge:: Die Substitut-Server anfechten. * Aufruf von guix copy:: Mit einem entfernten Store Dateien austauschen. * Aufruf von guix container:: Prozesse isolieren. * Aufruf von guix weather:: Die Verfügbarkeit von Substituten einschätzen. * Aufruf von guix processes:: Auflisten der Client-Prozesse Aufruf von @command{guix build} * Gemeinsame Erstellungsoptionen:: Erstellungsoptionen für die meisten Befehle. * Paketumwandlungsoptionen:: Varianten von Paketen erzeugen. * Zusätzliche Erstellungsoptionen:: Optionen spezifisch für »guix build«. * Fehlschläge beim Erstellen untersuchen:: Praxiserfahrung bei der Paketerstellung. Systemkonfiguration * Das Konfigurationssystem nutzen:: Ihr GNU-System anpassen. * »operating-system«-Referenz:: Details der Betriebssystem-Deklarationen. * Dateisysteme:: Die Dateisystemeinbindungen konfigurieren. * Zugeordnete Geräte:: Näheres zu blockorientierten Speichermedien. * Benutzerkonten:: Benutzerkonten festlegen. * Tastaturbelegung:: Wie das System Tastendrücke interpretiert. * Locales:: Sprache und kulturelle Konventionen. * Dienste:: Systemdienste festlegen. * Setuid-Programme:: Mit Administratorrechten startende Programme. * X.509-Zertifikate:: HTTPS-Server authentifizieren. * Name Service Switch:: Den Name Service Switch von libc konfigurieren. * Initiale RAM-Disk:: Linux-libre hochfahren. * Bootloader-Konfiguration:: Den Bootloader konfigurieren. * Aufruf von guix system:: Instanziierung einer Systemkonfiguration. * Guix in einer VM starten:: Wie man »Guix System« in einer virtuellen Maschine startet. * Dienste definieren:: Neue Dienstdefinitionen hinzufügen. Dienste * Basisdienste:: Essenzielle Systemdienste. * Geplante Auftragsausführung:: Der mcron-Dienst. * Log-Rotation:: Der rottlog-Dienst. * Netzwerkdienste:: Netzwerkeinrichtung, SSH-Daemon etc. * X Window:: Grafische Anzeige. * Druckdienste:: Unterstützung für lokale und entfernte Drucker. * Desktop-Dienste:: D-Bus- und Desktop-Dienste. * Tondienste:: Dienste für ALSA und Pulseaudio. * Datenbankdienste:: SQL-Datenbanken, Schlüssel-Wert-Speicher etc. * Mail-Dienste:: IMAP, POP3, SMTP und so weiter. * Kurznachrichtendienste:: Dienste für Kurznachrichten. * Telefondienste:: Telefoniedienste. * Überwachungsdienste:: Dienste zur Systemüberwachung. * Kerberos-Dienste:: Kerberos-Dienste. * Web-Dienste:: Web-Server. * Zertifikatsdienste:: TLS-Zertifikate via Let’s Encrypt. * DNS-Dienste:: DNS-Daemons. * VPN-Dienste:: VPN-Daemons. * Network File System:: Dienste mit Bezug zum Netzwerkdateisystem. * Kontinuierliche Integration:: Der Cuirass-Dienst. * Dienste zur Stromverbrauchsverwaltung:: Den Akku schonen. * Audio-Dienste:: Der MPD. * Virtualisierungsdienste:: Dienste für virtuelle Maschinen. * Versionskontrolldienste:: Entfernten Zugang zu Git-Repositorys bieten. * Spieldienste:: Spielserver. * Verschiedene Dienste:: Andere Dienste. Dienste definieren * Dienstkompositionen:: Wie Dienste zusammengestellt werden. * Diensttypen und Dienste:: Typen und Dienste. * Service-Referenz:: Referenz zur Programmierschnittstelle. * Shepherd-Dienste:: Eine spezielle Art von Dienst. @end detailmenu @end menu @c ********************************************************************* @node Einführung @chapter Einführung @cindex Zweck GNU Guix@footnote{»Guix« wird wie »geeks« ausgesprochen, also als »ɡiːks« in der Notation des Internationalen Phonetischen Alphabets (IPA).} ist ein Werkzeug zur Verwaltung von Softwarepaketen für das GNU-System und eine Distribution desselbigen GNU-Systems. Guix macht es @emph{nicht} mit besonderen Berechtigungen ausgestatteten, »unprivilegierten« Nutzern leicht, Softwarepakete zu installieren, zu aktualisieren oder zu entfernen, zu einem vorherigen Satz von Paketen zurückzuwechseln, Pakete aus ihrem Quellcode heraus zu erstellen und hilft allgemein bei der Erzeugung und Wartung von Software-Umgebungen. @cindex Guix System @cindex GuixSD, was jetzt Guix System heißt @cindex Guix System Distribution, welche jetzt Guix System heißt Sie können GNU@tie{}Guix auf ein bestehendes GNU/Linux-System aufsetzen, wo es die bereits verfügbaren Werkzeuge ergänzt, ohne zu stören (siehe @ref{Installation}), oder Sie können es als eine eigenständige Betriebssystem-Distribution namens @dfn{Guix@tie{}System} verwenden@footnote{Der Name @dfn{Guix@tie{}System} wird auf englische Weise ausgesprochen. Früher hatten wir »Guix System« als »Guix System Distribution« bezeichnet und mit »GuixSD« abgekürzt. Wir denken mittlerweile aber, dass es sinnvoller ist, alles unter der Fahne von Guix zu gruppieren, weil schließlich »Guix System« auch über den Befehl @command{guix system} verfügbar ist, selbst wenn Sie Guix auf einer fremden Distribution benutzen!}. Siehe @ref{GNU-Distribution}. @menu * Auf Guix-Art Software verwalten:: Was Guix besonders macht. * GNU-Distribution:: Die Pakete und Werkzeuge. @end menu @node Auf Guix-Art Software verwalten @section Auf Guix-Art Software verwalten @cindex Benutzeroberflächen Guix bietet eine befehlszeilenbasierte Paketverwaltungsschnittstelle (siehe @ref{Aufruf von guix package}), Werkzeuge als Hilfestellung bei der Software-Entwicklung (siehe @ref{Entwicklung}), Befehlszeilenwerkzeuge für fortgeschrittenere Nutzung (siehe @ref{Zubehör}) sowie Schnittstellen zur Programmierung in Scheme (siehe @ref{Programmierschnittstelle}). @cindex Erstellungs-Daemon Der @dfn{Erstellungs-Daemon} ist für das Erstellen von Paketen im Auftrag von Nutzern verantwortlich (siehe @ref{Den Daemon einrichten}) und für das Herunterladen vorerstellter Binärdateien aus autorisierten Quellen (siehe @ref{Substitute}). @cindex Erweiterbarkeit der Distribution @cindex Anpassung, von Paketen Guix enthält Paketdefinitionen für viele Pakete, von GNU und nicht von GNU, die alle @uref{https://www.gnu.org/philosophy/free-sw.html, die Freiheit des Computernutzers respektieren}. Es ist @emph{erweiterbar}: Nutzer können ihre eigenen Paketdefinitionen schreiben (siehe @ref{Pakete definieren}) und sie als unabhängige Paketmodule verfügbar machen (siehe @ref{Paketmodule}). Es ist auch @emph{anpassbar}: Nutzer können spezialisierte Paketdefinitionen aus bestehenden @emph{ableiten}, auch von der Befehlszeile (siehe @ref{Paketumwandlungsoptionen}). @cindex funktionale Paketverwaltung @cindex Isolierung Intern implementiert Guix die Disziplin der @dfn{funktionalen Paketverwaltung}, zu der Nix schon die Pionierarbeit geleistet hat (siehe @ref{Danksagungen}). In Guix wird der Prozess, ein Paket zu erstellen und zu installieren, als eine @emph{Funktion} im mathematischen Sinn aufgefasst. Diese Funktion hat Eingaben, wie zum Beispiel Erstellungs-Skripts, einen Compiler und Bibliotheken, und liefert ein installiertes Paket. Als eine reine Funktion hängt sein Ergebnis allein von seinen Eingaben ab — zum Beispiel kann er nicht auf Software oder Skripts Bezug nehmen, die nicht ausdrücklich als Eingaben übergeben wurden. Eine Erstellungsfunktion führt immer zum selben Ergebnis, wenn ihr die gleiche Menge an Eingaben übergeben wurde. Sie kann die Umgebung des laufenden Systems auf keine Weise beeinflussen, zum Beispiel kann sie keine Dateien außerhalb ihrer Erstellungs- und Installationsverzeichnisse verändern. Um dies zu erreichen, laufen Erstellungsprozesse in isolieren Umgebungen (sogenannte @dfn{Container}), wo nur ausdrückliche Eingaben sichtbar sind. @cindex Store Das Ergebnis von Paketerstellungsfunktionen wird im Dateisystem @dfn{zwischengespeichert} in einem besonderen Verzeichnis, was als @dfn{der Store} bezeichnet wird (siehe @ref{Der Store}). Jedes Paket wird in sein eigenes Verzeichnis im Store installiert — standardmäßig ist er unter @file{/gnu/store} zu finden. Der Verzeichnisname enthält einen Hash aller Eingaben, anhand derer das Paket erzeugt wurde, somit hat das Ändern einer Eingabe einen völlig anderen Verzeichnisnamen zur Folge. Dieses Vorgehen ist die Grundlage für die Guix auszeichnenden Funktionalitäten: Unterstützung transaktionsbasierter Paketaktualisierungen und -rücksetzungen, Installation von Paketen als einfacher Nutzer sowie Garbage Collection für Pakete (siehe @ref{Funktionalitäten}). @node GNU-Distribution @section GNU-Distribution @cindex Guix System Mit Guix kommt eine Distribution des GNU-Systems, die nur aus freier Software@footnote{Die Bezeichnung »frei« steht hier für die @url{http://www.gnu.org/philosophy/free-sw.html,Freiheiten, die Nutzern der Software geboten werden}.} besteht. Die Distribution kann für sich allein installiert werden (siehe @ref{Systeminstallation}), aber Guix kann auch auf einem bestehenden GNU/Linux-System installiert werden. Wenn wir die Anwendungsfälle unterscheiden möchten, bezeichnen wir die alleinstehende Distribution als »Guix@tie{}System« (mit englischer Aussprache). Die Distribution stellt den Kern der GNU-Pakete, also insbesondere GNU libc, GCC und Binutils, sowie zahlreiche zum GNU-Projekt gehörende und nicht dazu gehörende Anwendungen zur Verfügung. Die vollständige Liste verfügbarer Pakete können Sie @url{http://www.gnu.org/software/guix/packages,online} einsehen, oder indem Sie @command{guix package} ausführen (siehe @ref{Aufruf von guix package}): @example guix package --list-available @end example Unser Ziel ist, eine zu 100% freie Software-Distribution von Linux-basierten und von anderen GNU-Varianten anzubieten, mit dem Fokus darauf, das GNU-Projekt und die enge Zusammenarbeit seiner Bestandteile zu befördern, sowie die Programme und Werkzeuge hervorzuheben, die die Nutzer dabei unterstützen, von dieser Freiheit Gebrauch zu machen. Pakete sind zur Zeit auf folgenden Plattformen verfügbar: @table @code @item x86_64-linux Intel/AMD-@code{x86_64}-Architektur, Linux-Libre als Kernel, @item i686-linux Intel-32-Bit-Architektur (IA-32), Linux-Libre als Kernel, @item armhf-linux ARMv7-A-Architektur mit »hard float«, Thumb-2 und NEON, für die EABI »hard-float application binary interface«, mit Linux-Libre als Kernel. @item aarch64-linux 64-Bit-ARMv8-A-Prozessoren, little-endian, Linux-Libre als Kernel. Derzeit ist dies noch in der Erprobungsphase mit begrenzter Unterstützung. Unter @ref{Mitwirken} steht, wie Sie dabei helfen können! @item mips64el-linux 64-Bit-MIPS-Prozessoren, little-endian, insbesondere die Loongson-Reihe, n32-ABI, mit Linux-Libre als Kernel. @end table Mit Guix@tie{}System @emph{deklarieren} Sie alle Aspekte der Betriebssystemkonfiguration und Guix kümmert sich darum, die Konfiguration auf transaktionsbasierte, reproduzierbare und zustandslose Weise zu instanziieren (siehe @ref{Systemkonfiguration}). Guix System benutzt den Kernel Linux-libre, das Shepherd-Initialisierungssystem (siehe @ref{Einführung,,, shepherd, The GNU Shepherd Manual}), die wohlbekannten GNU-Werkzeuge mit der zugehörigen Werkzeugkette sowie die grafische Umgebung und Systemdienste Ihrer Wahl. Guix System ist auf allen oben genannten Plattformen außer @code{mips64el-linux} verfügbar. @noindent Informationen, wie auf andere Architekturen oder Kernels portiert werden kann, finden Sie im Abschnitt @ref{Portierung}. Diese Distribution aufzubauen basiert auf Kooperation, und Sie sind herzlich eingeladen, dabei mitzumachen! Im Abschnitt @ref{Mitwirken} stehen weitere Informationen, wie Sie uns helfen können. @c ********************************************************************* @node Installation @chapter Installation @cindex Guix installieren @quotation Anmerkung Wir empfehlen, dieses @uref{https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh, Shell-basierte Installationsskript} zu benutzen, um Guix auf ein bestehendes GNU/Linux-System zu installieren — im Folgenden als @dfn{Fremddistribution} bezeichnet.@footnote{Dieser Abschnitt bezieht sich auf die Installation des Paketverwaltungswerkzeugs, das auf ein bestehendes GNU/Linux-System aufsetzend installiert werden kann. Wenn Sie stattdessen das vollständige GNU-Betriebssystem installieren möchten, lesen Sie @ref{Systeminstallation}.} Das Skript automatisiert das Herunterladen, das Installieren und die anfängliche Konfiguration von Guix. Es sollte als der Administratornutzer »root« ausgeführt werden. @end quotation @cindex Fremddistribution @cindex Verzeichnisse auf einer Fremddistribution Wenn es auf einer Fremddistribution installiert wird, ergänzt GNU@tie{}Guix die verfügbaren Werkzeuge, ohne dass sie sich gegenseitig stören. Guix’ Daten befinden sich ausschließlich in zwei Verzeichnissen, üblicherweise @file{/gnu/store} und @file{/var/guix}; andere Dateien auf Ihrem System wie @file{/etc} bleiben unberührt. Sobald es installiert ist, kann Guix durch Ausführen von @command{guix pull} aktualisiert werden (siehe @ref{Aufruf von guix pull}). Sollten Sie es vorziehen, die Installationsschritte manuell durchzuführen, oder falls Sie Anpassungen daran vornehmen möchten, könnten sich die folgenden Unterabschnitte als nützlich erweisen. Diese beschreiben die Software-Voraussetzungen von Guix und wie man es manuell installiert, so dass man es benutzen kann. @menu * Aus Binärdatei installieren:: Guix installieren, ohne Zeit zu verlieren! * Voraussetzungen:: Zum Erstellen und Benutzen von Guix nötige Software. * Den Testkatalog laufen lassen:: Guix testen. * Den Daemon einrichten:: Wie man die Umgebung des Erstellungs-Daemons einrichtet. * Aufruf des guix-daemon:: Den Erstellungs-Daemon laufen lassen. * Anwendungen einrichten:: Anwendungsspezifische Einstellungen. @end menu @node Aus Binärdatei installieren @section Aus Binärdatei installieren @cindex Guix aus Binärdateien installieren @cindex Installations-Skript Dieser Abschnitt beschreibt, wie sich Guix auf einem beliebigen System aus einem alle Komponenten umfassenden Tarball installieren lässt, der Binärdateien für Guix und all seine Abhängigkeiten liefert. Dies geht in der Regel schneller, als Guix aus seinen Quelldateien zu installieren, was in den nächsten Abschnitten beschrieben wird. Vorausgesetzt wird hier lediglich, dass GNU@tie{}tar und Xz verfügbar sind. Die Installation läuft so ab: @enumerate @item @cindex Guix-Binärdatei herunterladen Laden Sie den binären Tarball von @indicateurl{https://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{System}.tar.xz} herunter, wobei @var{System} für @code{x86_64-linux} steht, falls Sie es auf einer Maschine mit @code{x86_64}-Architektur einrichten, auf der bereits der Linux-Kernel läuft, oder entsprechend für andere Maschinen. @c The following is somewhat duplicated in ``System Installation''. Achten Sie darauf, auch die zugehörige @file{.sig}-Datei herunterzuladen und verifizieren Sie damit die Authentizität des Tarballs, ungefähr so: @example $ wget https://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{System}.tar.xz.sig $ gpg --verify guix-binary-@value{VERSION}.@var{System}.tar.xz.sig @end example Falls dieser Befehl fehlschlägt, weil Sie nicht über den nötigen öffentlichen Schlüssel verfügen, können Sie ihn mit diesem Befehl importieren: @example $ gpg --keyserver @value{KEY-SERVER} \ --recv-keys @value{OPENPGP-SIGNING-KEY-ID} @end example @noindent @c end authentication part und den Befehl @code{gpg --verify} erneut ausführen. @item Nun müssen Sie zum Administratornutzer @code{root} wechseln. Abhängig von Ihrer Distribution müssen Sie dazu etwa @code{su -} oder @code{sudo -i} ausführen. Danach führen Sie als @code{root}-Nutzer aus: @example # cd /tmp # tar --warning=no-timestamp -xf \ guix-binary-@value{VERSION}.@var{System}.tar.xz # mv var/guix /var/ && mv gnu / @end example Dadurch wird @file{/gnu/store} (siehe @ref{Der Store}) und @file{/var/guix} erzeugt. Letzteres enthält ein fertiges Guix-Profil für den Administratornutzer @code{root} (wie im nächsten Schritt beschrieben). Entpacken Sie den Tarball @emph{nicht} auf einem schon funktionierenden Guix-System, denn es würde seine eigenen essenziellen Dateien überschreiben. Die Befehlszeilenoption @code{--warning=no-timestamp} stellt sicher, dass GNU@tie{}tar nicht vor »unplausibel alten Zeitstempeln« warnt (solche Warnungen traten bei GNU@tie{}tar 1.26 und älter auf, neue Versionen machen keine Probleme). Sie treten auf, weil alle Dateien im Archiv als Änderungszeitpunkt null eingetragen bekommen haben (das bezeichnet den 1. Januar 1970). Das ist Absicht, damit der Inhalt des Archivs nicht davon abhängt, wann es erstellt wurde, und es somit reproduzierbar wird. @item Machen Sie das Profil als @file{~root/.config/guix/current} verfügbar, wo @command{guix pull} es aktualisieren kann (siehe @ref{Aufruf von guix pull}): @example # mkdir -p ~root/.config/guix # ln -sf /var/guix/profiles/per-user/root/current-guix \ ~root/.config/guix/current @end example »Sourcen« Sie @file{etc/profile}, um @code{PATH} und andere relevante Umgebungsvariable zu ergänzen: @example # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \ source $GUIX_PROFILE/etc/profile @end example @item Erzeugen Sie Nutzergruppe und Nutzerkonten für die Erstellungs-Benutzer wie folgt (siehe @ref{Einrichten der Erstellungsumgebung}). @item Führen Sie den Daemon aus, und lassen Sie ihn automatisch bei jedem Hochfahren starten. Wenn Ihre Wirts-Distribution systemd als »init«-System verwendet, können Sie das mit folgenden Befehlen veranlassen: @c Versions of systemd that supported symlinked service files are not @c yet widely deployed, so we should suggest that users copy the service @c files into place. @c @c See this thread for more information: @c http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html @example # cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \ /etc/systemd/system/ # systemctl start guix-daemon && systemctl enable guix-daemon @end example Wenn Ihre Wirts-Distribution als »init«-System Upstart verwendet: @example # initctl reload-configuration # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \ /etc/init/ # start guix-daemon @end example Andernfalls können Sie den Daemon immer noch manuell starten, mit: @example # ~root/.config/guix/current/bin/guix-daemon \ --build-users-group=guixbuild @end example @item Stellen Sie den @command{guix}-Befehl auch anderen Nutzern Ihrer Maschine zur Verfügung, zum Beispiel so: @example # mkdir -p /usr/local/bin # cd /usr/local/bin # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix @end example Es ist auch eine gute Idee, die Info-Version dieses Handbuchs ebenso verfügbar zu machen: @example # mkdir -p /usr/local/share/info # cd /usr/local/share/info # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ; do ln -s $i ; done @end example Auf diese Art wird, unter der Annahme, dass bei Ihnen @file{/usr/local/share/info} im Suchpfad eingetragen ist, das Ausführen von @command{info guix.de} dieses Handbuch öffnen (siehe @ref{Other Info Directories,,, texinfo, GNU Texinfo} hat weitere Details, wie Sie den Info-Suchpfad ändern können). @item @cindex Substitute, deren Autorisierung Um Substitute von @code{@value{SUBSTITUTE-SERVER}} oder einem Spiegelserver davon zu benutzen (siehe @ref{Substitute}), müssen sie erst autorisiert werden: @example # guix archive --authorize < \ ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER}.pub @end example @item Alle Nutzer müssen womöglich ein paar zusätzliche Schritte ausführen, damit ihre Guix-Umgebung genutzt werden kann, siehe @ref{Anwendungen einrichten}. @end enumerate Voilà, die Installation ist fertig! Sie können nachprüfen, dass Guix funktioniert, indem Sie ein Beispielpaket in das root-Profil installieren: @example # guix package -i hello @end example Das @code{guix}-Paket muss im Profil von @code{root} installiert bleiben, damit es nicht vom Müllsammler geholt wird, denn ohne den @command{guix}-Befehl wären Sie lahmgelegt. Anders gesagt, entfernen Sie @code{guix} @emph{nicht} mit @code{guix package -r guix}. Der Tarball zur Installation aus einer Binärdatei kann einfach durch Ausführung des folgenden Befehls im Guix-Quellbaum (re-)produziert und verifiziert werden: @example make guix-binary.@var{System}.tar.xz @end example @noindent …@: was wiederum dies ausführt: @example guix pack -s @var{System} --localstatedir \ --profile-name=current-guix guix @end example Siehe @ref{Aufruf von guix pack} für weitere Informationen zu diesem praktischen Werkzeug. @node Voraussetzungen @section Voraussetzungen Dieser Abschnitt listet Voraussetzungen auf, um Guix aus seinem Quellcode zu erstellen. Der Erstellungsprozess für Guix ist derselbe wie für andere GNU-Software und wird hier nicht beschrieben. Bitte lesen Sie die Dateien @file{README} und @file{INSTALL} im Guix-Quellbaum, um weitere Details zu erfahren. @cindex Offizielle Webpräsenz GNU Guix kann von seiner Webpräsenz unter @url{http://www.gnu.org/software/guix/} heruntergeladen werden. GNU Guix hat folgende Pakete als Abhängigkeiten: @itemize @item @url{http://gnu.org/software/guile/, GNU Guile}, Version 2.2.x, @item @url{https://notabug.org/cwebber/guile-gcrypt, Guile-Gcrypt}, Version 0.1.0 oder neuer, @item @uref{http://gnutls.org/, GnuTLS}, im Speziellen dessen Anbindungen für Guile (siehe @ref{Guile Preparations, how to install the GnuTLS bindings for Guile,, gnutls-guile, GnuTLS-Guile}), @item @uref{https://notabug.org/guile-sqlite3/guile-sqlite3, Guile-SQLite3}, Version 0.1.0 oder neuer, @item @c FIXME: Specify a version number once a release has been made. @uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, vom August 2017 oder neuer, @item @uref{https://savannah.nongnu.org/projects/guile-json/, Guile-JSON}, @item @url{http://zlib.net, zlib}, @item @url{http://www.gnu.org/software/make/, GNU Make}. @end itemize Folgende Abhängigkeiten sind optional: @itemize @item @c Note: We need at least 0.10.2 for 'channel-send-eof'. Unterstützung für das Auslagern von Erstellungen (siehe @ref{Auslagern des Daemons einrichten}) und @command{guix copy} (siehe @ref{Aufruf von guix copy}) hängt von @uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH}, Version 0.10.2 oder neuer, ab. @item Wenn @url{http://www.bzip.org, libbz2} verfügbar ist, kann @command{guix-daemon} damit Erstellungsprotokolle komprimieren. @end itemize Sofern nicht @code{--disable-daemon} beim Aufruf von @command{configure} übergeben wurde, benötigen Sie auch folgende Pakete: @itemize @item @url{http://gnupg.org/, GNU libgcrypt}, @item @url{http://sqlite.org, SQLite 3}, @item @url{http://gcc.gnu.org, GCC's g++} mit Unterstützung für den C++11-Standard. @end itemize @cindex Zustandsverzeichnis Sollten Sie Guix auf einem System konfigurieren, auf dem Guix bereits installiert ist, dann stellen Sie sicher, dasselbe Zustandsverzeichnis wie für die bestehende Installation zu verwenden. Benutzen Sie dazu die Befehlszeilenoption @code{--localstatedir} des @command{configure}-Skripts (siehe @ref{Directory Variables, @code{localstatedir},, standards, GNU Coding Standards}). Das @command{configure}-Skript schützt vor ungewollter Fehlkonfiguration der @var{localstatedir}, damit sie nicht versehentlich Ihren Store verfälschen (siehe @ref{Der Store}). @cindex Nix, Kompatibilität Wenn eine funktionierende Installation of @url{http://nixos.org/nix/, the Nix package manager} verfügbar ist, können Sie Guix stattdessen mit @code{--disable-daemon} konfigurieren. In diesem Fall ersetzt Nix die drei oben genannten Abhängigkeiten. Guix ist mit Nix kompatibel, daher ist es möglich, denselben Store für beide zu verwenden. Dazu müssen Sie an @command{configure} nicht nur denselben Wert für @code{--with-store-dir} übergeben, sondern auch denselben Wert für @code{--localstatedir}. Letzterer ist deswegen essenziell, weil er unter anderem angibt, wo die Datenbank liegt, in der sich die Metainformationen über den Store befinden. Für Nix sind die Werte standardmäßig @code{--with-store-dir=/nix/store} und @code{--localstatedir=/nix/var}. Beachten Sie, dass @code{--disable-daemon} nicht erforderlich ist, wenn Sie die Absicht haben, den Store mit Nix zu teilen. @node Den Testkatalog laufen lassen @section Den Testkatalog laufen lassen @cindex Testkatalog Nachdem @command{configure} und @code{make} erfolgreich durchgelaufen sind, ist es ratsam, den Testkatalog auszuführen. Er kann dabei helfen, Probleme mit der Einrichtung oder Systemumgebung zu finden, oder auch Probleme in Guix selbst — und Testfehler zu melden ist eine wirklich gute Art und Weise, bei der Verbesserung von Guix mitzuhelfen. Um den Testkatalog auszuführen, geben Sie Folgendes ein: @example make check @end example Testfälle können parallel ausgeführt werden. Sie können die Befehlszeiltenoption @code{-j} von GNU@tie{}make benutzen, damit es schneller geht. Der erste Durchlauf kann auf neuen Maschinen ein paar Minuten dauern, nachfolgende Ausführungen werden schneller sein, weil der für die Tests erstellte Store schon einige Dinge zwischengespeichert haben wird. Es ist auch möglich, eine Teilmenge der Tests laufen zu lassen, indem Sie die @code{TESTS}-Variable des Makefiles ähnlich wie in diesem Beispiel definieren: @example make check TESTS="tests/store.scm tests/cpio.scm" @end example Standardmäßig werden Testergebnisse pro Datei angezeigt. Um die Details jedes einzelnen Testfalls zu sehen, können Sie wie in diesem Beispiel die @code{SCM_LOG_DRIVER_FLAGS}-Variable des Makefiles definieren: @example make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no" @end example Kommt es zum Fehlschlag, senden Sie bitte eine E-Mail an @email{bug-guix@@gnu.org} und fügen Sie die Datei @file{test-suite.log} als Anhang bei. Bitte geben Sie dabei in Ihrer Nachricht die benutzte Version von Guix an sowie die Versionsnummern der Abhängigkeiten (siehe @ref{Voraussetzungen}). Guix wird auch mit einem Testkatalog für das ganze System ausgeliefert, der vollständige Instanzen des »Guix System«-Betriebssystems testet. Er kann nur auf Systemen benutzt werden, auf denen Guix bereits installiert ist, mit folgendem Befehl: @example make check-system @end example @noindent Oder, auch hier, indem Sie @code{TESTS} definieren, um eine Teilmenge der auszuführenden Tests anzugeben: @example make check-system TESTS="basic mcron" @end example Diese Systemtests sind in den @code{(gnu tests @dots{})}-Modulen definiert. Sie funktionieren, indem Sie das getestete Betriebssystem mitsamt schlichter Instrumentierung in einer virtuellen Maschine (VM) ausführen. Die Tests können aufwendige Berechnungen durchführen oder sie günstig umgehen, je nachdem, ob für ihre Abhängigkeiten Substitute zur Verfügung stehen (siehe @ref{Substitute}). Manche von ihnen nehmen viel Speicherplatz in Anspruch, um die VM-Abbilder zu speichern. Auch hier gilt: Falls Testfehler auftreten, senden Sie bitte alle Details an @email{bug-guix@@gnu.org}. @node Den Daemon einrichten @section Den Daemon einrichten @cindex Daemon Operationen wie das Erstellen eines Pakets oder Laufenlassen des Müllsammlers werden alle durch einen spezialisierten Prozess durchgeführt, den @dfn{Erstellungs-Daemon}, im Auftrag seiner Kunden (den Clients). Nur der Daemon darf auf den Store und seine zugehörige Datenbank zugreifen. Daher wird jede den Store verändernde Operation durch den Daemon durchgeführt. Zum Beispiel kommunizieren Befehlszeilenwerkzeuge wie @command{guix package} und @command{guix build} mit dem Daemon (mittels entfernter Prozeduraufrufe), um ihm Anweisungen zu geben, was er tun soll. Folgende Abschnitte beschreiben, wie Sie die Umgebung des Erstellungs-Daemons ausstatten sollten. Siehe auch @ref{Substitute} für Informationen darüber, wie Sie es dem Daemon ermöglichen, vorerstellte Binärdateien herunterzuladen. @menu * Einrichten der Erstellungsumgebung:: Die isolierte Umgebung zum Erstellen vorbereiten. * Auslagern des Daemons einrichten:: Erstellungen auf entfernte Maschinen auslagern. * SELinux-Unterstützung:: Wie man eine SELinux-Richtlinie für den Daemon einrichtet. @end menu @node Einrichten der Erstellungsumgebung @subsection Einrichten der Erstellungsumgebung @cindex Erstellungsumgebung In einem normalen Mehrbenutzersystem werden Guix und sein Daemon — das Programm @command{guix-daemon} — vom Systemadministrator installiert; @file{/gnu/store} gehört @code{root} und @command{guix-daemon} läuft als @code{root}. Nicht mit erweiterten Rechten ausgestattete Nutzer können Guix-Werkzeuge benutzen, um Pakete zu erstellen oder anderweitig auf den Store zuzugreifen, und der Daemon wird dies für sie erledigen und dabei sicherstellen, dass der Store in einem konsistenten Zustand verbleibt und sich die Nutzer erstellte Pakete teilen. @cindex Erstellungsbenutzer Wenn @command{guix-daemon} als Administratornutzer @code{root} läuft, wollen Sie aber vielleicht dennoch nicht, dass Paketerstellungsprozesse auch als @code{root} ablaufen, aus offensichtlichen Sicherheitsgründen. Um dies zu vermeiden, sollte ein besonderer Pool aus @dfn{Erstellungsbenutzern} geschaffen werden, damit vom Daemon gestartete Erstellungsprozesse ihn benutzen. Diese Erstellungsbenutzer müssen weder eine Shell noch ein Persönliches Verzeichnis zugewiesen bekommen, sie werden lediglich benutzt, wenn der Daemon @code{root}-Rechte in Erstellungsprozessen ablegt. Mehrere solche Benutzer zu haben, ermöglicht es dem Daemon, verschiedene Erstellungsprozessen unter verschiedenen Benutzeridentifikatoren (UIDs) zu starten, was garantiert, dass sie einander nicht stören — eine essenzielle Funktionalität, da Erstellungen als reine Funktionen angesehen werden (siehe @ref{Einführung}). Auf einem GNU/Linux-System kann ein Pool von Erstellungsbenutzern wie folgt erzeugt werden (mit Bash-Syntax und den Befehlen von @code{shadow}): @c See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00239.html @c for why `-G' is needed. @example # groupadd --system guixbuild # for i in `seq -w 1 10`; do useradd -g guixbuild -G guixbuild \ -d /var/empty -s `which nologin` \ -c "Guix-Erstellungsbenutzer $i" --system \ guixbuilder$i; done @end example @noindent Die Anzahl der Erstellungsbenutzer entscheidet, wieviele Erstellungsaufträge parallel ausgeführt werden können, wie es mit der Befehlszeilenoption @option{--max-jobs} vorgegeben werden kann (siehe @ref{Aufruf des guix-daemon, @option{--max-jobs}}). Um @command{guix system vm} und ähnliche Befehle nutzen zu können, müssen Sie die Erstellungsbenutzer unter Umständen zur @code{kvm}-Benutzergruppe hinzufügen, damit sie Zugriff auf @file{/dev/kvm} haben, mit @code{-G guixbuild,kvm} statt @code{-G guixbuild} (siehe @ref{Aufruf von guix system}). Das Programm @code{guix-daemon} kann mit dem folgenden Befehl als @code{root} gestartet werden@footnote{Wenn Ihre Maschine systemd als »init«-System verwendet, genügt es, die Datei @file{@var{prefix}/lib/systemd/system/guix-daemon.service} in @file{/etc/systemd/system} zu platzieren, damit @command{guix-daemon} automatisch gestartet wird. Ebenso können Sie, wenn Ihre Maschine Upstart als »init«-System benutzt, die Datei @file{@var{prefix}/lib/upstart/system/guix-daemon.conf} in @file{/etc/init} platzieren.}: @example # guix-daemon --build-users-group=guixbuild @end example @cindex chroot @noindent Auf diese Weise startet der Daemon Erstellungsprozesse in einem chroot als einer der @code{guixbuilder}-Benutzer. Auf GNU/Linux enthält die chroot-Umgebung standardmäßig nichts außer: @c Keep this list in sync with libstore/build.cc! ----------------------- @itemize @item einem minimalen @code{/dev}-Verzeichnis, was größtenteils vom @code{/dev} des Wirtssystems unabhängig erstellt wurde@footnote{»Größtenteils«, denn obwohl die Menge an Dateien, die im @code{/dev} des chroots vorkommen, fest ist, können die meisten dieser Dateien nur dann erstellt werden, wenn das Wirtssystem sie auch hat.}, @item dem @code{/proc}-Verzeichnis, es zeigt nur die Prozesse des Containers, weil ein separater Namensraum für Prozess-IDs (PIDs) benutzt wird, @item @file{/etc/passwd} mit einem Eintrag für den aktuellen Benutzer und einem Eintrag für den Benutzer @file{nobody}, @item @file{/etc/group} mit einem Eintrag für die Gruppe des Benutzers, @item @file{/etc/hosts} mit einem Eintrag, der @code{localhost} auf @code{127.0.0.1} abbildet, @item einem @file{/tmp}-Verzeichnis mit Schreibrechten. @end itemize Sie können beeinflussen, in welchem Verzeichnis der Daemon Verzeichnisbäume zur Erstellung unterbringt, indem sie den Wert der Umgebungsvariablen @code{TMPDIR} ändern. Allerdings heißt innerhalb des chroots der Erstellungsbaum immer @file{/tmp/guix-build-@var{Name}.drv-0}, wobei @var{Name} der Ableitungsname ist — z.B.@: @code{coreutils-8.24}. Dadurch hat der Wert von @code{TMPDIR} keinen Einfluss auf die Erstellungsumgebung, wodurch Unterschiede vermieden werden, falls Erstellungsprozesse den Namen ihres Erstellungsbaumes einfangen. @vindex http_proxy Der Daemon befolgt außerdem den Wert der Umgebungsvariablen @code{http_proxy} für von ihm durchgeführte HTTP-Downloads, sei es für Ableitungen mit fester Ausgabe (siehe @ref{Ableitungen}) oder für Substitute (siehe @ref{Substitute}). Wenn Sie Guix als ein Benutzer ohne erweiterte Rechte installieren, ist es dennoch möglich, @command{guix-daemon} auszuführen, sofern Sie @code{--disable-chroot} übergeben. Allerdings können Erstellungsprozesse dann nicht voneinander und vom Rest des Systems isoliert werden. Daher können sich Erstellungsprozesse gegenseitig stören und auf Programme, Bibliotheken und andere Dateien zugreifen, die dem restlichen System zur Verfügung stehen — was es deutlich schwerer macht, sie als @emph{reine} Funktionen aufzufassen. @node Auslagern des Daemons einrichten @subsection Nutzung der Auslagerungsfunktionalität @cindex auslagern @cindex Build-Hook Wenn erwünscht, kann der Erstellungs-Daemon Ableitungserstellungen auf andere Maschinen @dfn{auslagern}, auf denen Guix läuft, mit Hilfe des @code{offload}-@dfn{Build-Hooks}@footnote{Diese Funktionalität ist nur verfügbar, wenn @uref{https://github.com/artyom-poptsov/guile-ssh, Guile-SSH} vorhanden ist.}. Wenn diese Funktionalität aktiviert ist, wird eine nutzerspezifizierte Liste von Erstellungsmaschinen aus @file{/etc/guix/machines.scm} gelesen. Wann immer eine Erstellung angefragt wird, zum Beispiel durch @code{guix build}, versucht der Daemon, sie an eine der Erstellungsmaschinen auszulagern, die die Einschränkungen der Ableitung erfüllen, insbesondere ihren Systemtyp — z.B.@: @file{x86_64-linux}. Fehlende Voraussetzungen für die Erstellung werden über SSH auf die Zielmaschine kopiert, welche dann mit der Erstellung weitermacht. Hat sie Erfolg damit, so werden die Ausgabe oder Ausgaben der Erstellung zurück auf die ursprüngliche Maschine kopiert. Die Datei @file{/etc/guix/machines.scm} sieht normalerweise so aus: @example (list (build-machine (name "eightysix.example.org") (system "x86_64-linux") (host-key "ssh-ed25519 AAAAC3Nza@dots{}") (user "bob") (speed 2.)) ;unglaublich schnell! (build-machine (name "meeps.example.org") (system "mips64el-linux") (host-key "ssh-rsa AAAAB3Nza@dots{}") (user "alice") (private-key (string-append (getenv "HOME") "/.ssh/identität-für-guix")))) @end example @noindent Im obigen Beispiel geben wir eine Liste mit zwei Erstellungsmaschinen vor, eine für die @code{x86_64}-Architektur und eine für die @code{mips64el}-Architektur. Tatsächlich ist diese Datei — wenig überraschend! — eine Scheme-Datei, die ausgewertet wird, wenn der @code{offload}-Hook gestartet wird. Der Wert, den sie zurückliefert, muss eine Liste von @code{build-machine}-Objekten sein. Obwohl dieses Beispiel eine feste Liste von Erstellungsmaschinen zeigt, könnte man auch auf die Idee kommen, etwa mit DNS-SD eine Liste möglicher im lokalen Netzwerk entdeckter Erstellungsmaschinen zu liefern (siehe @ref{Einführung, Guile-Avahi,, guile-avahi, Using Avahi in Guile Scheme Programs}). Der Datentyp @code{build-machine} wird im Folgenden weiter ausgeführt. @deftp {Datentyp} build-machine Dieser Datentyp repräsentiert Erstellungsmaschinen, an die der Daemon Erstellungen auslagern darf. Die wichtigen Felder sind: @table @code @item name Der Hostname (d.h.@: der Rechnername) der entfernten Maschine. @item system Der Systemtyp der entfernten Maschine — z.B.@: @code{"x86_64-linux"}. @item user Das Benutzerkonto, mit dem eine Verbindung zur entfernten Maschine über SSH aufgebaut werden soll. Beachten Sie, dass das SSH-Schlüsselpaar @emph{nicht} durch eine Passphrase geschützt sein darf, damit nicht-interaktive Anmeldungen möglich sind. @item host-key Dies muss der @dfn{öffentliche SSH-Host-Schlüssel} der Maschine im OpenSSH-Format sein. Er wird benutzt, um die Identität der Maschine zu prüfen, wenn wir uns mit ihr verbinden. Er ist eine lange Zeichenkette, die ungefähr so aussieht: @example ssh-ed25519 AAAAC3NzaC@dots{}mde+UhL hint@@example.org @end example Wenn auf der Maschine der OpenSSH-Daemon, @command{sshd}, läuft, ist der Host-Schlüssel in einer Datei wie @file{/etc/ssh/ssh_host_ed25519_key.pub} zu finden. Wenn auf der Maschine der SSH-Daemon von GNU@tie{}lsh, nämlich @command{lshd}, läuft, befindet sich der Host-Schlüssel in @file{/etc/lsh/host-key.pub} oder einer ähnlichen Datei. Er kann ins OpenSSH-Format umgewandelt werden durch @command{lsh-export-key} (siehe @ref{Converting keys,,, lsh, LSH Manual}): @example $ lsh-export-key --openssh < /etc/lsh/host-key.pub ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV@dots{} @end example @end table Eine Reihe optionaler Felder kann festgelegt werden: @table @asis @item @code{port} (Vorgabe: @code{22}) Portnummer des SSH-Servers auf der Maschine. @item @code{private-key} (Vorgabe: @file{~root/.ssh/id_rsa}) Die Datei mit dem privaten SSH-Schlüssel, der beim Verbinden zur Maschine genutzt werden soll, im OpenSSH-Format. Dieser Schlüssel darf nicht mit einer Passphrase geschützt sein. Beachten Sie, dass als Vorgabewert der private Schlüssel @emph{des root-Benutzers} genommen wird. Vergewissern Sie sich, dass er existiert, wenn Sie die Standardeinstellung verwenden. @item @code{compression} (Vorgabe: @code{"zlib@@openssh.com,zlib"}) @itemx @code{compression-level} (Vorgabe: @code{3}) Die Kompressionsmethoden auf SSH-Ebene und das angefragte Kompressionsniveau. Beachten Sie, dass Auslagerungen SSH-Kompression benötigen, um beim Übertragen von Dateien an Erstellungsmaschinen und zurück weniger Bandbreite zu benutzen. @item @code{daemon-socket} (Vorgabe: @code{"/var/guix/daemon-socket/socket"}) Dateiname des Unix-Sockets, auf dem @command{guix-daemon} auf der Maschine lauscht. @item @code{parallel-builds} (Vorgabe: @code{1}) Die Anzahl der Erstellungen, die auf der Maschine parallel ausgeführt werden können. @item @code{speed} (Vorgabe: @code{1.0}) Ein »relativer Geschwindigkeitsfaktor«. Der Auslagerungsplaner gibt tendenziell Maschinen mit höherem Geschwindigkeitsfaktor den Vorrang. @item @code{features} (Vorgabe: @code{'()}) Eine Liste von Zeichenketten, die besondere von der Maschine unterstützte Funktionalitäten bezeichnen. Ein Beispiel ist @code{"kvm"} für Maschinen, die über die KVM-Linux-Module zusammen mit entsprechender Hardware-Unterstützung verfügen. Ableitungen können Funktionalitäten dem Namen nach anfragen und werden dann auf passenden Erstellungsmaschinen eingeplant. @end table @end deftp Der Befehl @code{guix} muss sich im Suchpfad der Erstellungsmaschinen befinden. Um dies nachzuprüfen, können Sie Folgendes ausführen: @example ssh build-machine guix repl --version @end example Es gibt noch eine weitere Sache zu tun, sobald @file{machines.scm} eingerichtet ist. Wie zuvor erklärt, werden beim Auslagern Dateien zwischen den Stores der Maschinen hin- und hergeschickt. Damit das funktioniert, müssen Sie als Erstes ein Schlüsselpaar auf jeder Maschine erzeugen, damit der Daemon signierte Archive mit den Dateien aus dem Store versenden kann (siehe @ref{Aufruf von guix archive}): @example # guix archive --generate-key @end example @noindent Jede Erstellungsmaschine muss den Schlüssel der Hauptmaschine autorisieren, damit diese Store-Objekte von der Hauptmaschine empfangen kann: @example # guix archive --authorize < öffentlicher-schlüssel-hauptmaschine.txt @end example @noindent Andersherum muss auch die Hauptmaschine den jeweiligen Schlüssel jeder Erstellungsmaschine autorisieren. Der ganze Umstand mit den Schlüsseln soll ausdrücken, dass sich Haupt- und Erstellungsmaschinen paarweise gegenseitig vertrauen. Konkret kann der Erstellungs-Daemon auf der Hauptmaschine die Echtheit von den Erstellungsmaschinen empfangener Dateien gewährleisten (und umgekehrt), und auch dass sie nicht sabotiert wurden und mit einem autorisierten Schlüssel signiert wurden. @cindex Auslagerung testen Um zu testen, ob Ihr System funktioniert, führen Sie diesen Befehl auf der Hauptmaschine aus: @example # guix offload test @end example Dadurch wird versucht, zu jeder Erstellungsmaschine eine Verbindung herzustellen, die in @file{/etc/guix/machines.scm} angegeben wurde, sichergestellt, dass auf jeder Guile und die Guix-Module nutzbar sind, und jeweils versucht, etwas auf die Erstellungsmaschine zu exportieren und von dort zu imporieren. Dabei auftretende Fehler werden gemeldet. Wenn Sie stattdessen eine andere Maschinendatei verwenden möchten, geben Sie diese einfach auf der Befehlszeile an: @example # guix offload test maschinen-qualif.scm @end example Letztendlich können Sie hiermit nur die Teilmenge der Maschinen testen, deren Name zu einem regulären Ausdruck passt: @example # guix offload test maschinen.scm '\.gnu\.org$' @end example @cindex Auslagerungs-Lagebericht Um die momentane Auslastung aller Erstellungs-Hosts anzuzeigen, führen Sie diesen Befehl auf dem Hauptknoten aus: @example # guix offload status @end example @node SELinux-Unterstützung @subsection SELinux-Unterstützung @cindex SELinux, Policy für den Daemon @cindex Mandatory Access Control, SELinux @cindex Sicherheit, des guix-daemon Guix enthält eine SELinux-Richtliniendatei (»Policy«) unter @file{etc/guix-daemon.cil}, die auf einem System installiert werden kann, auf dem SELinux aktiviert ist, damit Guix-Dateien gekennzeichnet sind und um das erwartete Verhalten des Daemons anzugeben. Da Guix System keine Grundrichtlinie (»Base Policy«) für SELinux bietet, kann diese Richtlinie für den Daemon auf Guix System nicht benutzt werden. @subsubsection Installieren der SELinux-Policy @cindex SELinux, Policy installieren Um die Richtlinie (Policy) zu installieren, führen Sie folgenden Befehl mit Administratorrechten aus: @example semodule -i etc/guix-daemon.cil @end example Kennzeichnen Sie dann das Dateisystem neu mit @code{restorecon} oder einem anderen, von Ihrem System angebotenen Mechanismus. Sobald die Richtlinie installiert ist, das Dateisystem neu gekennzeichnet wurde und der Daemon neugestartet wurde, sollte er im Kontext @code{guix_daemon_t} laufen. Sie können dies mit dem folgenden Befehl nachprüfen: @example ps -Zax | grep guix-daemon @end example Beobachten Sie die Protokolldateien von SELinux, wenn Sie einen Befehl wie @code{guix build hello} ausführen, um sich zu überzeugen, dass SELinux alle notwendigen Operationen gestattet. @subsubsection Einschränkungen @cindex SELinux, Einschränkungen Diese Richtlinie ist nicht perfekt. Im Folgenden finden Sie eine Liste von Einschränkungen oder merkwürdigen Verhaltensweisen, die bedacht werden sollten, wenn man die mitgelieferte SELinux-Richtlinie für den Guix-Daemon einspielt. @enumerate @item @code{guix_daemon_socket_t} wird nicht wirklich benutzt. Keine der Socket-Operationen benutzt Kontexte, die irgendetwas mit @code{guix_daemon_socket_t} zu tun haben. Es schadet nicht, diese ungenutzte Kennzeichnung zu haben, aber es wäre besser, für die Kennzeichnung auch Socket-Regeln festzulegen. @item @code{guix gc} kann nicht auf beliebige Verknüpfungen zu Profilen zugreifen. Die Kennzeichnung des Ziels einer symbolischen Verknüpfung ist notwendigerweise unabhängig von der Dateikennzeichnung der Verknüpfung. Obwohl alle Profile unter $localstatedir gekennzeichnet sind, erben die Verknüpfungen auf diese Profile die Kennzeichnung desjenigen Verzeichnisses, in dem sie sich befinden. Für Verknüpfungen im Persönlichen Verzeichnis des Benutzers ist das @code{user_home_t}, aber Verknüpfungen aus dem Persönlichen Verzeichnis des Administratornutzers, oder @file{/tmp}, oder das Arbeitsverzeichnis des HTTP-Servers, etc., funktioniert das nicht. @code{guix gc} würde es nicht gestattet, diese Verknüpfungen auszulesen oder zu verfolgen. @item Die vom Daemon gebotene Funktionalität, auf TCP-Verbindungen zu lauschen, könnte nicht mehr funktionieren. Dies könnte zusätzliche Regeln brauchen, weil SELinux Netzwerk-Sockets anders behandelt als Dateien. @item Derzeit wird allen Dateien mit einem Namen, der zum regulären Ausdruck @code{/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon} passt, die Kennzeichnung @code{guix_daemon_exec_t} zugewiesen, wodurch @emph{jede beliebige} Datei mit diesem Namen in irgendeinem Profil gestattet wäre, in der Domäne @code{guix_daemon_t} ausgeführt zu werden. Das ist nicht ideal. Ein Angreifer könnte ein Paket erstellen, dass solch eine ausführbare Datei enthält, und den Nutzer überzeugen, es zu installieren und auszuführen. Dadurch käme es in die Domäne @code{guix_daemon_t}. Ab diesem Punkt könnte SELinux nicht mehr verhindern, dass es auf Dateien zugreift, auf die Prozesse in dieser Domäne zugreifen dürfen. Wir könnten zum Zeitpunkt der Installation eine wesentlich restriktivere Richtlinie generieren, für die nur @emph{genau derselbe} Dateiname des gerade installierten @code{guix-daemon}-Programms als @code{guix_daemon_exec_t} gekennzeichnet würde, statt einen vieles umfassenden regulären Ausdruck zu benutzen. Aber dann müsste der Administratornutzer zum Zeitpunkt der Installation jedes Mal die Richtlinie installieren oder aktualisieren müssen, sobald das Guix-Paket aktualisiert wird, dass das tatsächlich in Benutzung befindliche @code{guix-daemon}-Programm enthält. @end enumerate @node Aufruf des guix-daemon @section Aufruf von @command{guix-daemon} Das Programm @command{guix-daemon} implementiert alle Funktionalitäten, um auf den Store zuzugreifen. Dazu gehört das Starten von Erstellungsprozessen, das Ausführen des Müllsammlers, das Abfragen, ob ein Erstellungsergebnis verfügbar ist, etc. Normalerweise wird er so als Administratornutzer (@code{root}) gestartet: @example # guix-daemon --build-users-group=guixbuild @end example @noindent Details, wie Sie ihn einrichten, finden Sie im Abschnitt @ref{Den Daemon einrichten}. @cindex chroot @cindex Container, Erstellungsumgebung @cindex Erstellungsumgebung @cindex Reproduzierbare Erstellungen Standardmäßig führt @command{guix-daemon} Erstellungsprozesse mit unterschiedlichen UIDs aus, die aus der Erstellungsgruppe stammen, deren Name mit @code{--build-users-group} übergeben wurde. Außerdem läuft jeder Erstellungsprozess in einer chroot-Umgebung, die nur die Teilmenge des Stores enthält, von der der Erstellungsprozess abhängt, entsprechend seiner Ableitung (siehe @ref{Programmierschnittstelle, derivation}), und ein paar bestimmte Systemverzeichnisse, darunter standardmäßig auch @file{/dev} und @file{/dev/pts}. Zudem ist die Erstellungsumgebung auf GNU/Linux ein @dfn{Container}: Nicht nur hat er seinen eigenen Dateisystembaum, er hat auch einen separaten Namensraum zum Einhängen von Dateisystemen, seinen eigenen Namensraum für PIDs, für Netzwerke, etc. Dies hilft dabei, reproduzierbare Erstellungen zu garantieren (siehe @ref{Funktionalitäten}). Wenn der Daemon im Auftrag des Nutzers eine Erstellung durchführt, erzeugt er ein Erstellungsverzeichnis, entweder in @file{/tmp} oder im Verzeichnis, das durch die Umgebungsvariable @code{TMPDIR} angegeben wurde. Dieses Verzeichnis wird mit dem Container geteilt, solange die Erstellung noch läuft, allerdings trägt es im Container stattdessen immer den Namen »/tmp/guix-build-NAME.drv-0«. Nach Abschluss der Erstellung wird das Erstellungsverzeichnis automatisch entfernt, außer wenn die Erstellung fehlgeschlagen ist und der Client @option{--keep-failed} angegeben hat (siehe @ref{Aufruf von guix build, @option{--keep-failed}}). Der Daemon lauscht auf Verbindungen und erstellt jeweils einen Unterprozess für jede von einem Client begonnene Sitzung (d.h.@: von einem der @command{guix}-Unterbefehle). Der Befehl @command{guix processes} zeigt Ihnen eine Übersicht solcher Systemaktivitäten; damit werden Ihnen alle aktiven Sitzungen und Clients gezeigt. Weitere Informationen finden Sie unter @ref{Aufruf von guix processes}. Die folgenden Befehlszeilenoptionen werden unterstützt: @table @code @item --build-users-group=@var{Gruppe} Verwende die Benutzerkonten aus der @var{Gruppe}, um Erstellungsprozesse auszuführen (siehe @ref{Den Daemon einrichten, build users}). @item --no-substitutes @cindex Substitute Benutze keine Substitute für Erstellungsergebnisse. Das heißt, dass alle Objekte lokal erstellt werden müssen, und kein Herunterladen von vorab erstellten Binärdateien erlaubt ist (siehe @ref{Substitute}). Wenn der Daemon mit @code{--no-substitutes} ausgeführt wird, können Clients trotzdem Substitute explizit aktivieren über den entfernten Prozeduraufruf @code{set-build-options} (siehe @ref{Der Store}). @item --substitute-urls=@var{URLs} @anchor{daemon-substitute-urls} @var{URLs} als standardmäßige, leerzeichengetrennte Liste der Quell-URLs für Substitute benutzen. Wenn diese Befehlszeilenoption @emph{nicht} angegeben wird, wird @indicateurl{https://@value{SUBSTITUTE-SERVER}} verwendet. Das hat zur Folge, dass Substitute von den @var{URLs} heruntergeladen werden können, solange sie mit einer Signatur versehen sind, der vertraut wird (siehe @ref{Substitute}). @cindex Build-Hook @item --no-build-hook Den @dfn{Build-Hook} nicht benutzen. »Build-Hook« ist der Name eines Hilfsprogramms, das der Daemon starten kann und an das er Erstellungsanfragen übermittelt. Durch diesen Mechanismus können Erstellungen an andere Maschinen ausgelagert werden (siehe @ref{Auslagern des Daemons einrichten}). @item --cache-failures Fehler bei der Erstellung zwischenspeichern. Normalerweise werden nur erfolgreiche Erstellungen gespeichert. Wenn diese Befehlszeilenoption benutzt wird, kann @command{guix gc --list-failures} benutzt werden, um die Menge an Store-Objekten abzufragen, die als Fehlschläge markiert sind; @command{guix gc --clear-failures} entfernt Store-Objekte aus der Menge zwischengespeicherter Fehlschläge. Siehe @ref{Aufruf von guix gc}. @item --cores=@var{n} @itemx -c @var{n} @var{n} CPU-Kerne zum Erstellen jeder Ableitung benutzen; @code{0} heißt, so viele wie verfügbar sind. Der Vorgabewert ist @code{0}, jeder Client kann jedoch eine abweichende Anzahl vorgeben, zum Beispiel mit der Befehlszeilenoption @code{--cores} von @command{guix build} (siehe @ref{Aufruf von guix build}). Dadurch wird die Umgebungsvariable @code{NIX_BUILD_CORES} im Erstellungsprozess definiert, welcher sie benutzen kann, um intern parallele Ausführungen zuzulassen — zum Beispiel durch Nutzung von @code{make -j$NIX_BUILD_CORES}. @item --max-jobs=@var{n} @itemx -M @var{n} Höchstenss @var{n} Erstellungsaufträge parallel bearbeiten. Der Vorgabewert liegt bei @code{1}. Wird er auf @code{0} gesetzt, werden keine Erstellungen lokal durchgeführt, stattdessen lagert der Daemon sie nur aus (siehe @ref{Auslagern des Daemons einrichten}) oder sie schlagen einfach fehl. @item --max-silent-time=@var{Sekunden} Wenn der Erstellungs- oder Substitutionsprozess länger als @var{Sekunden}-lang keine Ausgabe erzeugt, wird er abgebrochen und ein Fehler beim Erstellen gemeldet. Der Vorgabewert ist @code{0}, was bedeutet, dass es keine Zeitbeschränkung gibt. Clients können einen anderen Wert als den hier angegebenen verwenden lassen (siehe @ref{Gemeinsame Erstellungsoptionen, @code{--max-silent-time}}). @item --timeout=@var{Sekunden} Entsprechend wird hier der Erstellungs- oder Substitutionsprozess abgebrochen und als Fehlschlag gemeldet, wenn er mehr als @var{Sekunden}-lang dauert. Der Vorgabewert ist @code{0}, was bedeutet, dass es keine Zeitbeschränkung gibt. Clients können einen anderen Wert verwenden lassen (siehe @ref{Gemeinsame Erstellungsoptionen, @code{--timeout}}). @item --rounds=@var{N} Jede Ableitung @var{n}-mal hintereinander erstellen und einen Fehler melden, wenn nacheinander ausgewertete Erstellungsergebnisse nicht Bit für Bit identisch sind. Beachten Sie, dass Clients wie @command{guix build} einen anderen Wert verwenden lassen können (siehe @ref{Aufruf von guix build}). Wenn dies zusammen mit @option{--keep-failed} benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen @file{/gnu/store/@dots{}-check}. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden. @item --debug Informationen zur Fehlersuche ausgeben. Dies ist nützlich, um Probleme beim Starten des Daemons nachzuvollziehen; Clients könn aber auch ein abweichenden Wert verwenden lassen, zum Beispiel mit der Befehlszeilenoption @code{--verbosity} von @command{guix build} (siehe @ref{Aufruf von guix build}). @item --chroot-directory=@var{Verzeichnis} Füge das @var{Verzeichnis} zum chroot von Erstellungen hinzu. Dadurch kann sich das Ergebnis von Erstellungsprozessen ändern — zum Beispiel, wenn diese optionale Abhängigkeiten aus dem @var{Verzeichnis} verwenden, wenn sie verfügbar sind, und nicht, wenn es fehlt. Deshalb ist es nicht empfohlen, dass Sie diese Befehlszeilenoption verwenden, besser sollten Sie dafür sorgen, dass jede Ableitung alle von ihr benötigten Eingabgen deklariert. @item --disable-chroot Erstellungen ohne chroot durchführen. Diese Befehlszeilenoption zu benutzen, wird nicht empfohlen, denn auch dadurch bekämen Erstellungsprozesse Zugriff auf nicht deklarierte Abhängigkeiten. Sie ist allerdings unvermeidlich, wenn @command{guix-daemon} auf einem Benutzerkonto ohne ausreichende Berechtigungen ausgeführt wird. @item --log-compression=@var{Typ} Erstellungsprotokolle werden entsprechend dem @var{Typ} komprimiert, der entweder @code{gzip}, @code{bzip2} oder @code{none} (für keine Kompression) sein muss. Sofern nicht @code{--lose-logs} angegeben wurde, werden alle Erstellungsprotokolle in der @var{localstatedir} gespeichert. Um Platz zu sparen, komprimiert sie der Daemon standardmäßig automatisch mit bzip2. @item --disable-deduplication @cindex Deduplizieren Automatische Dateien-»Deduplizierung« im Store ausschalten. Standardmäßig werden zum Store hinzugefügte Objekte automatisch »dedupliziert«: Wenn eine neue Datei mit einer anderen im Store übereinstimmt, wird die neue Datei stattdessen als harte Verknüpfung auf die andere Datei angelegt. Dies reduziert den Speicherverbrauch auf der Platte merklich, jedoch steigt andererseits die Auslastung bei der Ein-/Ausgabe im Erstellungsprozess geringfügig. Durch diese Option wird keine solche Optimierung durchgeführt. @item --gc-keep-outputs[=yes|no] Gibt an, ob der Müllsammler (Garbage Collector, GC) die Ausgaben lebendiger Ableitungen behalten muss (»yes«) oder nicht (»no«). @cindex GC-Wurzeln @cindex Müllsammlerwurzeln Für »yes« behält der Müllsammler die Ausgaben aller lebendigen Ableitungen im Store — die @code{.drv}-Dateien. Der Vorgabewert ist aber »no«, so dass Ableitungsausgaben nur vorgehalten werden, wenn sie von einer Müllsammlerwurzel aus erreichbar sind. Siehe den Abschnitt @ref{Aufruf von guix gc} für weitere Informationen zu Müllsammlerwurzeln. @item --gc-keep-derivations[=yes|no] Gibt an, ob der Müllsammler (GC) Ableitungen behalten muss (»yes«), wenn sie lebendige Ausgaben haben, oder nicht (»no«). Für »yes«, den Vorgabewert, behält der Müllsammler Ableitungen — z.B.@: @code{.drv}-Dateien —, solange zumindest eine ihrer Ausgaben lebendig ist. Dadurch können Nutzer den Ursprung der Dateien in ihrem Store nachvollziehen. Setzt man den Wert auf »no«, wird ein bisschen weniger Speicher auf der Platte verbraucht. Auf diese Weise überträgt sich, wenn @code{--gc-keep-derivations} auf »yes« steht, die Lebendigkeit von Ausgaben auf Ableitungen, und wenn @code{--gc-keep-outputs} auf »yes« steht, die Lebendigkeit von Ableitungen auf Ausgaben. Stehen beide auf »yes«, bleiben so alle Erstellungsvoraussetzungen wie Quelldateien, Compiler, Bibliotheken und andere Erstellungswerkzeuge lebendiger Objekte im Store erhalten, ob sie von einer Müllsammlerwurzel aus erreichbar sind oder nicht. Entwickler können sich so erneute Erstellungen oder erneutes Herunterladen sparen. @item --impersonate-linux-2.6 Auf Linux-basierten Systemen wird hiermit vorgetäuscht, dass es sich um Linux 2.6 handeln würde, indem der Kernel für einen @code{uname}-Systemaufruf als Version der Veröffentlichung mit 2.6 antwortet. Dies kann hilfreich sein, um Programme zu erstellen, die (normalerweise zu Unrecht) von der Kernel-Versionsnummer abhängen. @item --lose-logs Keine Protokolle der Erstellungen vorhalten. Normalerweise würden solche in @code{@var{localstatedir}/guix/log} gespeichert. @item --system=@var{System} Verwende @var{System} als aktuellen Systemtyp. Standardmäßig ist dies das Paar aus Befehlssatz und Kernel, welches beim Aufruf von @code{configure} erkannt wurde, wie zum Beispiel @code{x86_64-linux}. @item --listen=@var{Endpunkt} Lausche am @var{Endpunkt} auf Verbindungen. Dabei wird der @var{Endpunkt} als Dateiname eines Unix-Sockets verstanden, wenn er mit einem @code{/} (Schrägstrich) beginnt. Andernfalls wird der @var{Endpunkt} als Hostname (d.h.@: Rechnername) oder als Hostname-Port-Paar verstanden, auf dem gelauscht wird. Hier sind ein paar Beispiele: @table @code @item --listen=/gnu/var/daemon Lausche auf Verbindungen am Unix-Socket @file{/gnu/var/daemon}, falls nötig wird er dazu erstellt. @item --listen=localhost @cindex Daemon, Fernzugriff @cindex Fernzugriff auf den Daemon @cindex Daemon, Einrichten auf Clustern @cindex Cluster, Einrichtung des Daemons Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die @code{localhost} entspricht, auf Port 44146. @item --listen=128.0.0.42:1234 Lausche auf TCP-Verbindungen an der Netzwerkschnittstelle, die @code{128.0.0.42} entspricht, auf Port 1234. @end table Diese Befehlszeilenoption kann mehrmals wiederholt werden. In diesem Fall akzeptiert @command{guix-daemon} Verbindungen auf allen angegebenen Endpunkten. Benutzer können bei Client-Befehlen angeben, mit welchem Endpunkt sie sich verbinden möchten, indem sie die Umgebungsvariable @code{GUIX_DAEMON_SOCKET} festlegen (siehe @ref{Der Store, @code{GUIX_DAEMON_SOCKET}}). @quotation Anmerkung Das Daemon-Protokoll ist @emph{weder authentifiziert noch verschlüsselt}. Die Benutzung von @code{--listen=@var{Host}} eignet sich für lokale Netzwerke, wie z.B.@: in Rechen-Clustern, wo sich nur solche Knoten mit dem Daemon verbinden, denen man vertraut. In Situationen, wo ein Fernzugriff auf den Daemon durchgeführt wird, empfehlen wir, über Unix-Sockets in Verbindung mit SSH zuzugreifen. @end quotation Wird @code{--listen} nicht angegeben, lauscht @command{guix-daemon} auf Verbindungen auf dem Unix-Socket, der sich unter @file{@var{localstatedir}/guix/daemon-socket/socket} befindet. @end table @node Anwendungen einrichten @section Anwendungen einrichten @cindex Fremddistribution Läuft Guix aufgesetzt auf einer GNU/Linux-Distribution außer Guix System — einer sogenannten @dfn{Fremddistribution} —, so sind ein paar zusätzliche Schritte bei der Einrichtung nötig. Hier finden Sie manche davon. @subsection Locales @anchor{locales-and-locpath} @cindex Locales, nicht auf Guix System @vindex LOCPATH @vindex GUIX_LOCPATH Über Guix installierte Pakete benutzen nicht die Daten zu Regions- und Spracheinstellungen (Locales) des Wirtssystems. Stattdessen müssen Sie erst eines der Locale-Pakete installieren, die für Guix verfügbar sind, und dann den Wert Ihrer Umgebungsvariablen @code{GUIX_LOCPATH} passend festlegen: @example $ guix package -i glibc-locales $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale @end example Beachten Sie, dass das Paket @code{glibc-locales} Daten für alle von GNU@tie{}libc unterstützten Locales enthält und deswegen um die 110@tie{}MiB wiegt. Alternativ gibt es auch @code{glibc-utf8-locales}, was kleiner, aber auf ein paar UTF-8-Locales beschränkt ist. Die Variable @code{GUIX_LOCPATH} spielt eine ähnliche Rolle wie @code{LOCPATH} (siehe @ref{Locale Names, @code{LOCPATH},, libc, The GNU C Library Reference Manual}). Es gibt jedoch zwei wichtige Unterschiede: @enumerate @item @code{GUIX_LOCPATH} wird nur von der libc in Guix beachtet und nicht der von Fremddistributionen bereitgestellten libc. Mit @code{GUIX_LOCPATH} können Sie daher sicherstellen, dass die Programme der Fremddistribution keine inkompatiblen Locale-Daten von Guix laden. @item libc hängt an jeden @code{GUIX_LOCPATH}-Eintrag @code{/X.Y} an, wobei @code{X.Y} die Version von libc ist — z.B.@: @code{2.22}. Sollte Ihr Guix-Profil eine Mischung aus Programmen enthalten, die an verschiedene libc-Versionen gebunden sind, wird jede nur die Locale-Daten im richtigen Format zu laden versuchen. @end enumerate Das ist wichtig, weil das Locale-Datenformat verschiedener libc-Versionen inkompatibel sein könnte. @subsection Name Service Switch @cindex Name Service Switch, glibc @cindex NSS (Name Service Switch), glibc @cindex nscd (Name Service Caching Daemon) @cindex Name Service Caching Daemon (nscd) Wenn Sie Guix auf einer Fremddistribution verwenden, @emph{empfehlen wir stärkstens}, dass Sie den @dfn{Name Service Cache Daemon} der GNU-C-Bibliothek, @command{nscd}, laufen lassen, welcher auf dem Socket @file{/var/run/nscd/socket} lauschen sollte. Wenn Sie das nicht tun, könnten mit Guix installierte Anwendungen Probleme beim Auflösen von Hostnamen (d.h.@: Rechnernamen) oder Benutzerkonten haben, oder sogar abstürzen. Die nächsten Absätze erklären warum. @cindex @file{nsswitch.conf} Die GNU-C-Bibliothek implementiert einen @dfn{Name Service Switch} (NSS), welcher einen erweiterbaren Mechanismus zur allgemeinen »Namensauflösung« darstellt: Hostnamensauflösung, Benutzerkonten und weiteres (siehe @ref{Name Service Switch,,, libc, The GNU C Library Reference Manual}). @cindex Network Information Service (NIS) @cindex NIS (Network Information Service) Für die Erweiterbarkeit unterstützt der NSS @dfn{Plugins}, welche neue Implementierungen zur Namensauflösung bieten: Zum Beispiel ermöglicht das Plugin @code{nss-mdns} die Namensauflösung für @code{.local}-Hostnamen, das Plugin @code{nis} gestattet die Auflösung von Benutzerkonten über den Network Information Service (NIS) und so weiter. Diese zusätzlichen »Auflösungsdienste« werden systemweit konfiguriert in @file{/etc/nsswitch.conf} und alle auf dem System laufenden Programme halten sich an diese Einstellungen (siehe @ref{NSS Configuration File,,, libc, The GNU C Reference Manual}). Wenn sie eine Namensauflösung durchführen — zum Beispiel, indem sie die @code{getaddrinfo}-Funktion in C aufrufen — versuchen die Anwendungen als Erstes, sich mit dem nscd zu verbinden; ist dies erfolgreich, führt nscd für sie die weiteren Namensauflösungen durch. Falls nscd nicht läuft, führen sie selbst die Namensauflösungen durch, indem sie die Namensauflösungsdienste in ihren eigenen Adressraum laden und ausführen. Diese Namensauflösungsdienste — die @file{libnss_*.so}-Dateien — werden mit @code{dlopen} geladen, aber sie kommen von der C-Bibliothek des Wirtssystems und nicht von der C-Bibliothek, mit der die Anwendung gebunden wurde (also der C-Bibliothek von Guix). Und hier kommt es zum Problem: Wenn die Anwendung mit der C-Bibliothek von Guix (etwa glibc 2.24) gebunden wurde und die NSS-Plugins von einer anderen C-Bibliothek (etwa @code{libnss_mdns.so} für glibc 2.22) zu laden versucht, wird sie vermutlich abstürzen oder die Namensauflösungen werden unerwartet fehlschlagen. Durch das Ausführen von @command{nscd} auf dem System wird, neben anderen Vorteilen, dieses Problem der binären Inkompatibilität vermieden, weil diese @code{libnss_*.so}-Dateien vom @command{nscd}-Prozess geladen werden, nicht in den Anwendungen selbst. @subsection X11-Schriftarten @cindex Schriftarten Die Mehrheit der grafischen Anwendungen benutzen Fontconfig zum Finden und Laden von Schriftarten und für die Darstellung im X11-Client. Im Paket @code{fontconfig} in Guix werden Schriftarten standardmäßig in @file{$HOME/.guix-profile} gesucht. Um es grafischen Anwendungen, die mit Guix installiert wurden, zu ermöglichen, Schriftarten anzuzeigen, müssen Sie die Schriftarten auch mit Guix installieren. Essenzielle Pakete für Schriftarten sind unter anderem @code{gs-fonts}, @code{font-dejavu} und @code{font-gnu-freefont-ttf}. Um auf Chinesisch, Japanisch oder Koreanisch verfassten Text in grafischen Anwendungen anzeigen zu können, möchten Sie vielleicht @code{font-adobe-source-han-sans} oder @code{font-wqy-zenhei} installieren. Ersteres hat mehrere Ausgaben, für jede Sprachfamilie eine (siehe @ref{Pakete mit mehreren Ausgaben.}). Zum Beispiel installiert folgender Befehl Schriftarten für chinesische Sprachen: @example guix package -i font-adobe-source-han-sans:cn @end example @cindex @code{xterm} Ältere Programme wie @command{xterm} benutzen kein Fontconfig, sondern X-Server-seitige Schriftartendarstellung. Solche Programme setzen voraus, dass der volle Name einer Schriftart mit XLFD (X Logical Font Description) angegeben wird, z.B.@: so: @example -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1 @end example Um solche vollen Namen für die in Ihrem Guix-Profil installierten TrueType-Schriftarten zu verwenden, müssen Sie den Pfad für Schriftarten (Font Path) des X-Servers anpassen: @c Note: 'xset' does not accept symlinks so the trick below arranges to @c get at the real directory. See . @example xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir)) @end example @cindex @code{xlsfonts} Danach können Sie den Befehl @code{xlsfonts} ausführen (aus dem Paket @code{xlsfonts}), um sicherzustellen, dass dort Ihre TrueType-Schriftarten aufgeführt sind. @cindex @code{fc-cache} @cindex Font-Cache Nach der Installation der Schriftarten müssen Sie unter Umständen den Schriftarten-Zwischenspeicher (Font-Cache) erneuern, um diese in Anwendungen benutzen zu können. Gleiches gilt, wenn mit Guix installierte Anwendungen anscheinend keine Schriftarten finden können. Um das Erneuern des Font-Caches zu erzwingen, führen Sie @code{fc-cache -f} aus. Der Befehl @code{fc-cache} wird vom Paket @code{fontconfig} angeboten. @subsection X.509-Zertifikate @cindex @code{nss-certs} Das Paket @code{nss-certs} bietet X.509-Zertifikate, womit Programme die Identität von Web-Servern authentifizieren können, auf die über HTTPS zugegriffen wird. Wenn Sie Guix auf einer Fremddistribution verwenden, können Sie dieses Paket installieren und die relevanten Umgebungsvariablen festlegen, damit Pakete wissen, wo sie Zertifikate finden. Unter @ref{X.509-Zertifikate} stehen genaue Informationen. @subsection Emacs-Pakete @cindex @code{emacs} Wenn Sie mit Guix Pakete für Emacs installieren, werden deren elisp-Dateien entweder in @file{$HOME/.guix-profile/share/emacs/site-lisp/} oder in Unterverzeichnissen von @file{$HOME/.guix-profile/share/emacs/site-lisp/guix.d/} gespeichert. Letzteres Verzeichnis gibt es, weil es Tausende von Emacs-Paketen gibt und sie alle im selben Verzeichnis zu speichern vielleicht nicht verlässlich funktioniert (wegen Namenskonflikten). Daher halten wir es für richtig, für jedes Paket ein anderes Verzeichnis zu benutzen. Das Emacs-Paketsystem organisiert die Dateistruktur ähnlich (siehe @ref{Package Files,,, emacs, The GNU Emacs Manual}). Standardmäßig »weiß« Emacs (wenn er mit Guix installiert wurde), wo diese Pakete liegen, Sie müssen also nichts selbst konfigurieren. Wenn Sie aber aus irgendeinem Grund mit Guix installierte Pakete nicht automatisch laden lassen möchten, können Sie Emacs mit der Befehlszeilenoption @code{--no-site-file} starten (siehe @ref{Init File,,, emacs, The GNU Emacs Manual}). @subsection GCC-Toolchain @cindex GCC @cindex ld-wrapper Guix bietet individuelle Compiler-Pakete wie etwa @code{gcc}, aber wenn Sie einen vollständigen Satz an Werkzeugen zum Kompilieren und Binden von Quellcode brauchen, werden Sie eigentlich das Paket @code{gcc-toolchain} haben wollen. Das Paket bietet eine vollständige GCC-Toolchain für die Entwicklung mit C/C++, einschließlich GCC selbst, der GNU-C-Bibliothek (Header-Dateien und Binärdateien samt Symbolen zur Fehlersuche/Debugging in der @code{debug}-Ausgabe), Binutils und einen Wrapper für den Binder/Linker. Der Zweck des Wrappers ist, die an den Binder übergebenen Befehlszeilenoptionen mit @code{-L} und @code{-l} zu überprüfen und jeweils passende Argumente mit @code{-rpath} anzufügen, womit dann der echte Binder aufgerufen wird. Standardmäßig weigert sich der Binder-Wrapper, mit Bibliotheken außerhalb des Stores zu binden, um »Reinheit« zu gewährleisten. Das kann aber stören, wenn man die Toolchain benutzt, um mit lokalen Bibliotheken zu binden. Um Referenzen auf Bibliotheken außerhalb des Stores zu erlauben, müssen Sie die Umgebungsvariable @code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} setzen. @c TODO What else? @c ********************************************************************* @node Systeminstallation @chapter Systeminstallation @cindex Installieren von Guix System @cindex Guix System, Installation Dieser Abschnitt beschreibt, wie Sie »Guix System« auf einer Maschine installieren. Guix kann auch als Paketverwaltungswerkzeug ein bestehendes GNU/Linux-System ergänzen, mehr dazu finden Sie im Abschnitt @ref{Installation}. @ifinfo @quotation Anmerkung @c This paragraph is for people reading this from tty2 of the @c installation image. Sie lesen diese Dokumentation mit einem Info-Betrachter. Details, wie Sie ihn bedienen, erfahren Sie, indem Sie die Eingabetaste (auch »Return« oder »Enter« genannt) auf folgender Verknüpfung drücken: @ref{Top, Info reader,, info-stnd, Stand-alone GNU Info}. Drücken Sie danach @kbd{l}, um hierher zurückzukommen. Führen Sie alternativ @command{info info} auf einer anderen Konsole (tty) aus, um dieses Handbuch offen zu lassen. @end quotation @end ifinfo @menu * Einschränkungen:: Was Sie erwarten dürfen. * Hardware-Überlegungen:: Unterstützte Hardware. * Installation von USB-Stick oder DVD:: Das Installationsmedium vorbereiten. * Vor der Installation:: Netzwerkanbindung, Partitionierung etc. * Geführte grafische Installation:: Leichte grafische Installation. * Manuelle Installation:: Manuelle Installation für Zauberer. * Nach der Systeminstallation:: Wenn die Installation erfolgreich war. * Guix in einer VM installieren:: Ein »Guix System«-Spielplatz. * Ein Abbild zur Installation erstellen:: Wie ein solches entsteht. @end menu @node Einschränkungen @section Einschränkungen We consider Guix System to be ready for a wide range of ``desktop'' and server use cases. The reliability guarantees it provides---transactional upgrades and rollbacks, reproducibility---make it a solid foundation. Nevertheless, before you proceed with the installation, be aware of the following noteworthy limitations applicable to version @value{VERSION}: @itemize @item Der Logical Volume Manager (LVM) wird nicht unterstützt. @item Immer mehr Systemdienste sind verfügbar (siehe @ref{Dienste}), aber manche könnten noch fehlen. @item GNOME, Xfce, LXDE, and Enlightenment are available (@pxref{Desktop-Dienste}), as well as a number of X11 window managers. However, KDE is currently missing. @end itemize More than a disclaimer, this is an invitation to report issues (and success stories!), and to join us in improving it. @xref{Mitwirken}, for more info. @node Hardware-Überlegungen @section Hardware-Überlegungen @cindex Hardwareunterstützung von Guix System GNU@tie{}Guix legt den Fokus darauf, die Freiheit des Nutzers auf seinem Rechner zu respektieren. Es baut auf Linux-libre als Kernel auf, wodurch nur Hardware unterstützt wird, für die Treiber und Firmware existieren, die freie Software sind. Heutzutage wird ein großer Teil der handelsüblichen Hardware von GNU/Linux-libre unterstützt — von Tastaturen bis hin zu Grafikkarten, Scannern und Ethernet-Adaptern. Leider gibt es noch Bereiche, wo die Hardwareanbieter ihren Nutzern die Kontrolle über ihren eigenen Rechner verweigern. Solche Hardware wird von Guix System nicht unterstützt. @cindex WLAN, Hardware-Unterstützung One of the main areas where free drivers or firmware are lacking is WiFi devices. WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the @code{ath9k} Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the @code{b43-open} Linux-libre driver. Free firmware exists for both and is available out-of-the-box on Guix System, as part of @code{%base-firmware} (@pxref{»operating-system«-Referenz, @code{firmware}}). @cindex RYF, Respects Your Freedom Die @uref{https://www.fsf.org/, Free Software Foundation} betreibt @uref{https://www.fsf.org/ryf, @dfn{Respects Your Freedom}} (RYF), ein Zertifizierungsprogramm für Hardware-Produkte, die Ihre Freiheit und Privatsphäre respektieren und sicherstellen, dass Sie die Kontrolle über Ihr Gerät haben. Wir ermutigen Sie dazu, die Liste RYF-zertifizierter Geräte zu beachten. Eine weitere nützliche Ressource ist die Website @uref{https://www.h-node.org/, H-Node}. Dort steht ein Katalog von Hardware-Geräten mit Informationen darüber, wie gut sie von GNU/Linux unterstützt werden. @node Installation von USB-Stick oder DVD @section Installation von USB-Stick oder DVD Sie können ein ISO-9660-Installationsabbild von @indicateurl{https://alpha.gnu.org/gnu/guix/guix-system-install-@value{VERSION}.@var{System}.iso.xz} herunterladen, dass Sie auf einen USB-Stick aufspielen oder auf eine DVD brennen können, wobei Sie für @var{System} eines der folgenden schreiben müssen: @table @code @item x86_64-linux für ein GNU/Linux-System auf Intel/AMD-kompatiblen 64-Bit-Prozessoren, @item i686-linux für ein 32-Bit-GNU/Linux-System auf Intel-kompatiblen Prozessoren. @end table @c start duplication of authentication part from ``Binary Installation'' Laden Sie auch die entsprechende @file{.sig}-Datei herunter und verifizieren Sie damit die Authentizität Ihres Abbilds, indem Sie diese Befehle eingeben: @example $ wget https://alpha.gnu.org/gnu/guix/guix-system-install-@value{VERSION}.@var{System}.iso.xz.sig $ gpg --verify guix-system-install-@value{VERSION}.@var{System}.iso.xz.sig @end example Falls dieser Befehl fehlschlägt, weil Sie nicht über den nötigen öffentlichen Schlüssel verfügen, können Sie ihn mit diesem Befehl importieren: @example $ gpg --keyserver @value{KEY-SERVER} \ --recv-keys @value{OPENPGP-SIGNING-KEY-ID} @end example @noindent @c end duplication und den Befehl @code{gpg --verify} erneut ausführen. Dieses Abbild enthält die Werkzeuge, die Sie zur Installation brauchen. Es ist dafür gedacht, @emph{so wie es ist} auf einen hinreichend großen USB-Stick oder eine DVD kopiert zu werden. @unnumberedsubsec Kopieren auf einen USB-Stick Um das Abbild auf einen USB-Stick zu kopieren, führen Sie folgende Schritte durch: @enumerate @item Entpacken Sie das Abbild mit dem @command{xz}-Befehl: @example xz -d guix-system-install-@value{VERSION}.@var{System}.iso.xz @end example @item Stecken Sie einen USB-Stick in Ihren Rechner ein, der mindestens 1@tie{}GiB groß ist, und bestimmen Sie seinen Gerätenamen. Ist der Gerätename des USB-Sticks @file{/dev/sdX}, dann kopieren Sie das Abbild mit dem Befehl: @example dd if=guix-system-install-@value{VERSION}.@var{System}.iso of=/dev/sdX sync @end example Sie benötigen in der Regel Administratorrechte, um auf @file{/dev/sdX} zuzugreifen. @end enumerate @unnumberedsubsec Auf eine DVD brennen Um das Abbild auf eine DVD zu kopieren, führen Sie diese Schritte durch: @enumerate @item Entpacken Sie das Abbild mit dem @command{xz}-Befehl: @example xz -d guix-system-install-@value{VERSION}.@var{System}.iso.xz @end example @item Legen Sie eine unbespielte DVD in Ihren Rechner ein und bestimmen Sie ihren Gerätenamen. Angenommen der Name des DVD-Laufwerks ist @file{/dev/srX}, kopieren Sie das Abbild mit: @example growisofs -dvd-compat -Z /dev/srX=guix-system-install-@value{VERSION}.@var{System}.iso @end example Der Zugriff auf @file{/dev/srX} setzt in der Regel Administratorrechte voraus. @end enumerate @unnumberedsubsec Das System starten Sobald das erledigt ist, sollten Sie Ihr System neu starten und es vom USB-Stick oder der DVD hochfahren (»booten«) können. Dazu müssen Sie wahrscheinlich beim Starten des Rechners in das BIOS- oder UEFI-Boot-Menü gehen, von wo aus Sie auswählen können, dass vom USB-Stick gebootet werden soll. Lesen Sie den Abschnitt @ref{Guix in einer VM installieren}, wenn Sie Guix System stattdessen in einer virtuellen Maschine (VM) installieren möchten. @node Vor der Installation @section Vor der Installation Wenn Sie Ihren Rechner gebootet haben, können Sie sich vom grafischen Installationsprogramm durch den Installationsvorgang führen lassen, was den Einstieg leicht macht (siehe @ref{Geführte grafische Installation}). Alternativ können Sie sich auch für einen »manuellen« Installationsvorgang entscheiden, wenn Sie bereits mit GNU/Linux vertraut sind und mehr Kontrolle haben möchten, als sie das grafische Installationsprogramm bietet (siehe @ref{Manuelle Installation}). Das grafische Installationsprogramm steht Ihnen auf TTY1 zur Verfügung. Auf den TTYs 3 bis 6 können Sie vor sich eine Eingabeaufforderung für den Administratornutzer »root« sehen, nachdem Sie @kbd{strg-alt-f3}, @kbd{strg-alt-f4} usw.@: gedrückt haben. TTY2 zeigt Ihnen dieses Handbuch, das Sie über die Tastenkombination @kbd{strg-alt-f2} erreichen. In dieser Dokumentation können Sie mit den Steuerungsbefehlen Ihres Info-Betrachters blättern (siehe @ref{Top,,, info-stnd, Stand-alone GNU Info}). Auf dem Installationssystem läuft der GPM-Maus-Daemon, wodurch Sie Text mit der linken Maustaste markieren und ihn mit der mittleren Maustaste einfügen können. @quotation Anmerkung Für die Installation benötigen Sie Zugang zum Internet, damit fehlende Abhängigkeiten Ihrer Systemkonfiguration heruntergeladen werden können. Im Abschnitt »Netzwerkkonfiguration« weiter unten finden Sie mehr Informationen dazu. @end quotation @node Geführte grafische Installation @section Geführte grafische Installation Das grafische Installationsprogramm ist mit einer textbasierten Benutzeroberfläche ausgestattet. Es kann Sie mit Dialogfeldern durch die Schritte führen, mit denen Sie GNU@tie{}Guix System installieren. Die ersten Dialogfelder ermöglichen es Ihnen, das System aufzusetzen, wie Sie es bei der Installation benutzen: Sie können die Sprache und Tastaturbelegung festlegen und die Netzwerkanbindung einrichten, die während der Installation benutzt wird. Das folgende Bild zeigt den Dialog zur Einrichtung der Netzwerkanbindung. @image{images/installer-network,5in,, Netzwerkanbindung einrichten mit dem grafischen Installationsprogramm} Mit den danach kommenden Schritten können Sie Ihre Festplatte partitionieren, wie im folgenden Bild gezeigt, und auswählen, ob Ihre Dateisysteme verschlüsselt werden sollen oder nicht. Sie können Ihren Rechnernamen und das Administratorpasswort (das »root«-Passwort) festlegen und ein Benutzerkonto einrichten, und noch mehr. @image{images/installer-partitions,5in,, Partitionieren mit dem grafischen Installationsprogramm} Beachten Sie, dass Sie mit dem Installationsprogramm jederzeit den aktuellen Installationsschritt verlassen und zu einem vorherigen Schritt zurückkehren können, wie Sie im folgenden Bild sehen können. @image{images/installer-resume,5in,, Mit einem Installationsschritt fortfahren} Sobald Sie fertig sind, erzeugt das Installationsprogramm eine Betriebssystemkonfiguration und zeigt sie an (siehe @ref{Das Konfigurationssystem nutzen}). Zu diesem Zeitpunkt können Sie auf »OK« drücken und die Installation wird losgehen. Ist sie erfolgreich, können Sie neu starten und Ihr neues System genießen. Siehe @ref{Nach der Systeminstallation} für Informationen, wie es weitergeht! @node Manuelle Installation @section Manuelle Installation Dieser Abschnitt beschreibt, wie Sie GNU@tie{}Guix System auf manuelle Weise auf Ihrer Maschine installieren. Diese Alternative setzt voraus, dass Sie bereits mit GNU/Linux, der Shell und üblichen Administrationswerkzeugen vertraut sind. Wenn Sie glauben, dass das nichts für Sie ist, dann möchten Sie vielleicht das geführte grafische Installationsprogramm benutzen (siehe @ref{Geführte grafische Installation}). Das Installationssystem macht Eingabeaufforderungen auf den TTYs 3 bis 6 zugänglich, auf denen Sie als Administratornutzer Befehle eingeben können; Sie erreichen diese, indem Sie die Tastenkombinationen @kbd{strg-alt-f3}, @kbd{strg-alt-f4} und so weiter benutzen. Es enthält viele übliche Werkzeuge, mit denen Sie diese Aufgabe bewältigen können. Da es sich auch um ein vollständiges »Guix System«-System handelt, können Sie aber auch andere Pakete mit dem Befehl @command{guix package} nachinstallieren, wenn Sie sie brauchen (siehe @ref{Aufruf von guix package}). @menu * Tastaturbelegung und Netzwerkanbindung und Partitionierung:: Erstes Einrichten. * Fortfahren mit der Installation:: Installieren. @end menu @node Tastaturbelegung und Netzwerkanbindung und Partitionierung @subsection Tastaturbelegung, Netzwerkanbindung und Partitionierung Bevor Sie das System installieren können, wollen Sie vielleicht die Tastaturbelegung ändern, eine Netzwerkverbindung herstellen und die Zielfestplatte partitionieren. Dieser Abschnitt wird Sie durch diese Schritte führen. @subsubsection Tastaturbelegung @cindex Tastaturbelegung Das Installationsabbild verwendet die US-amerikanische QWERTY-Tastaturbelegung. Wenn Sie dies ändern möchten, können Sie den @command{loadkeys}-Befehl benutzen. Mit folgendem Befehl würden Sie zum Beispiel die Dvorak-Tastaturbelegung auswählen: @example loadkeys dvorak @end example Schauen Sie sich an, welche Dateien im Verzeichnis @file{/run/current-system/profile/share/keymaps} stehen, um eine Liste verfügbarer Tastaturbelegungen zu sehen. Wenn Sie mehr Informationen brauchen, führen Sie @command{man loadkeys} aus. @subsubsection Netzwerkkonfiguration Führen Sie folgenden Befehl aus, um zu sehen, wie Ihre Netzwerkschnittstellen benannt sind: @example ifconfig -a @end example @noindent @dots{} oder mit dem GNU/Linux-eigenen @command{ip}-Befehl: @example ip a @end example @c http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20 Der Name kabelgebundener Schnittstellen (engl. Interfaces) beginnt mit dem Buchstaben @samp{e}, zum Beispiel heißt die dem ersten fest eingebauten Ethernet-Adapter entsprechende Schnittstelle @samp{eno1}. Drahtlose Schnittstellen werden mit einem Namen bezeichnet, der mit dem Buchstaben @samp{w} beginnt, etwa @samp{w1p2s0}. @table @asis @item Kabelverbindung Um ein kabelgebundenes Netzwerk einzurichten, führen Sie den folgenden Befehl aus, wobei Sie statt @var{Schnittstelle} den Namen der kabelgebundenen Schnittstelle eintippen, die Sie benutzen möchten. @example ifconfig @var{Schnittstelle} up @end example @item Drahtlose Verbindung @cindex WLAN @cindex WiFi Um Drahtlosnetzwerke einzurichten, können Sie eine Konfigurationsdatei für das Konfigurationswerkzeug des @command{wpa_supplicant} schreiben (wo Sie sie speichern, ist nicht wichtig), indem Sie eines der verfügbaren Textbearbeitungsprogramme wie etwa @command{nano} benutzen: @example nano wpa_supplicant.conf @end example Zum Beispiel können Sie die folgende Formulierung in der Datei speichern, die für viele Drahtlosnetzwerke funktioniert, sofern Sie die richtige SSID und Passphrase für das Netzwerk eingeben, mit dem Sie sich verbinden möchten: @example network=@{ ssid="@var{meine-ssid}" key_mgmt=WPA-PSK psk="geheime Passphrase des Netzwerks" @} @end example Starten Sie den Dienst für Drahtlosnetzwerke und lassen Sie ihn im Hintergrund laufen, indem Sie folgenden Befehl eintippen (ersetzen Sie dabei @var{Schnittstelle} durch den Namen der Netzwerkschnittstelle, die Sie benutzen möchten): @example wpa_supplicant -c wpa_supplicant.conf -i @var{Schnittstelle} -B @end example Führen Sie @command{man wpa_supplicant} aus, um mehr Informationen zu erhalten. @end table @cindex DHCP Zu diesem Zeitpunkt müssen Sie sich eine IP-Adresse beschaffen. Auf einem Netzwerk, wo IP-Adressen automatisch @i{via} DHCP zugewiesen werden, können Sie das hier ausführen: @example dhclient -v @var{Schnittstelle} @end example Versuchen Sie, einen Server zu pingen, um zu prüfen, ob sie mit dem Internet verbunden sind und alles richtig funktioniert: @example ping -c 3 gnu.org @end example Einen Internetzugang herzustellen, ist in jedem Fall nötig, weil das Abbild nicht alle Software und Werkzeuge enthält, die nötig sein könnten. @cindex Über SSH installieren Wenn Sie möchten, können Sie die weitere Installation auch per Fernwartung durchführen, indem Sie einen SSH-Server starten: @example herd start ssh-daemon @end example Vergewissern Sie sich vorher, dass Sie entweder ein Passwort mit @command{passwd} festgelegt haben, oder dass Sie für OpenSSH eine Authentifizierung über öffentliche Schlüssel eingerichtet haben, bevor Sie sich anmelden. @subsubsection Plattenpartitionierung Sofern nicht bereits geschehen, ist der nächste Schritt, zu partitionieren und dann die Zielpartition zu formatieren. Auf dem Installationsabbild sind mehrere Partitionierungswerkzeuge zu finden, einschließlich (siehe @ref{Overview,,, parted, GNU Parted User Manual}), @command{fdisk} und @command{cfdisk}. Starten Sie eines davon und partitionieren Sie Ihre Festplatte oder sonstigen Massenspeicher: @example cfdisk @end example Wenn Ihre Platte mit einer »GUID Partition Table« (GPT) formatiert ist, und Sie vorhaben, die BIOS-basierte Variante des GRUB-Bootloaders zu installieren (was der Vorgabe entspricht), stellen Sie sicher, dass eine Partition als BIOS-Boot-Partition ausgewiesen ist (siehe @ref{BIOS installation,,, grub, GNU GRUB manual}). @cindex EFI, Installation @cindex UEFI, Installation @cindex ESP, EFI-Systempartition Falls Sie stattdessen einen EFI-basierten GRUB installieren möchten, muss auf der Platte eine FAT32-formatierte @dfn{EFI-Systempartition} (ESP) vorhanden sein. Diese Partition kann unter dem Pfad @file{/boot/efi} eingebunden (»gemountet«) werden und die @code{esp}-Flag der Partition muss gesetzt sein. Dazu würden Sie beispielsweise in @command{parted} eintippen: @example parted /dev/sda set 1 esp on @end example @quotation Anmerkung @vindex grub-bootloader @vindex grub-efi-bootloader Falls Sie nicht wissen, ob Sie einen EFI- oder BIOS-basierten GRUB installieren möchten: Wenn bei Ihnen das Verzeichnis @file{/sys/firmware/efi} im Dateisystem existiert, möchten Sie vermutlich eine EFI-Installation durchführen, wozu Sie in Ihrer Konfiguration @code{grub-efi-bootloader} benutzen. Ansonsten sollten Sie den BIOS-basierten GRUB benutzen, der mit @code{grub-bootloader} bezeichnet wird. Siehe @ref{Bootloader-Konfiguration}, wenn Sie mehr Informationen über Bootloader brauchen. @end quotation Sobald Sie die Platte fertig partitioniert haben, auf die Sie installieren möchten, müssen Sie ein Dateisystem auf Ihrer oder Ihren für Guix System vorgesehenen Partition(en) erzeugen@footnote{Derzeit unterstützt Guix System nur die Dateisystemtypen ext4 und btrfs. Insbesondere funktioniert Guix-Code, der Dateisystem-UUIDs und -Labels ausliest, nur auf diesen Dateisystemtypen.}. Wenn Sie eine ESP brauchen und dafür die Partition @file{/dev/sda1} vorgesehen haben, müssen Sie diesen Befehl ausführen: @example mkfs.fat -F32 /dev/sda1 @end example Geben Sie Ihren Dateisystemen auch besser eine Bezeichnung (»Label«), damit Sie sie zuverlässig wiedererkennen und später in den @code{file-system}-Deklarationen darauf Bezug nehmen können (siehe @ref{Dateisysteme}). Dazu benutzen Sie typischerweise die Befehlszeilenoption @code{-L} des Befehls @command{mkfs.ext4} oder entsprechende Optionen für andere Befehle. Wenn wir also annehmen, dass @file{/dev/sda2} die Partition ist, auf der Ihr Wurzeldateisystem (englisch »root«) wohnen soll, können Sie dort mit diesem Befehl ein Dateisystem mit der Bezeichnung @code{my-root} erstellen: @example mkfs.ext4 -L my-root /dev/sda2 @end example @cindex verschlüsselte Partition Falls Sie aber vorhaben, die Partition mit dem Wurzeldateisystem zu verschlüsseln, können Sie dazu die Cryptsetup-/LUKS-Werkzeuge verwenden (siehe @inlinefmtifelse{html, @uref{https://linux.die.net/man/8/cryptsetup, @code{man cryptsetup}}, @code{man cryptsetup}}, um mehr darüber zu erfahren). Angenommen Sie wollen die Partition für das Wurzeldateisystem verschlüsselt auf @file{/dev/sda2} installieren, dann brauchen Sie eine Befehlsfolge ähnlich wie diese: @example cryptsetup luksFormat /dev/sda2 cryptsetup open --type luks /dev/sda2 my-partition mkfs.ext4 -L my-root /dev/mapper/my-partition @end example Sobald das erledigt ist, binden Sie dieses Dateisystem als Installationsziel mit dem Einhängepunkt @file{/mnt} ein, wozu Sie einen Befehl wie hier eintippen (auch hier unter der Annahme, dass @code{my-root} die Bezeichnung des künftigen Wurzeldateisystems ist): @example mount LABEL=my-root /mnt @end example Binden Sie auch alle anderen Dateisysteme ein, die Sie auf dem Zielsystem benutzen möchten, mit Einhängepunkten relativ zu diesem Pfad. Wenn Sie sich zum Beispiel für einen Einhängepunkt @file{/boot/efi} für die EFI-Systempartition entschieden haben, binden Sie sie jetzt als @file{/mnt/boot/efi} ein, damit @code{guix system init} sie später findet. Wenn Sie zudem auch vorhaben, eine oder mehrere Swap-Partitionen zu benutzen (siehe @ref{Memory Concepts, swap space,, libc, The GNU C Library Reference Manual}), initialisieren Sie diese nun mit @command{mkswap}. Angenommen Sie haben eine Swap-Partition auf @file{/dev/sda3}, dann würde der Befehl so lauten: @example mkswap /dev/sda3 swapon /dev/sda3 @end example Alternativ können Sie eine Swap-Datei benutzen. Angenommen, Sie wollten die Datei @file{/swapdatei} im neuen System als eine Swapdatei benutzen, dann müssten Sie Folgendes ausführen@footnote{Dieses Beispiel wird auf vielen Arten von Dateisystemen funktionieren (z.B.@: auf ext4). Auf Dateisystemen mit Copy-on-Write (wie z.B.@: btrfs) können sich die nötigen Schritte unterscheiden. Details finden Sie in der Dokumentation auf den Handbuchseiten von @command{mkswap} und @command{swapon}.}: @example # Das bedeutet 10 GiB Swapspeicher. "count" anpassen zum ändern. dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240 # Zur Sicherheit darf nur der Administrator lesen und schreiben. chmod 600 /mnt/swapfile mkswap /mnt/swapfile swapon /mnt/swapfile @end example Bedenken Sie, dass, wenn Sie die Partition für das Wurzeldateisystem (»root«) verschlüsselt und eine Swap-Datei in diesem Dateisystem wie oben beschrieben erstellt haben, die Verschlüsselung auch die Swap-Datei schützt, genau wie jede andere Datei in dem Dateisystem. @node Fortfahren mit der Installation @subsection Fortfahren mit der Installation Wenn die Partitionen des Installationsziels bereit sind und dessen Wurzeldateisystem unter @file{/mnt} eingebunden wurde, kann es losgehen mit der Installation. Führen Sie zuerst aus: @example herd start cow-store /mnt @end example Dadurch wird @file{/gnu/store} copy-on-write, d.h.@: dorthin von Guix erstellte Pakete werden in ihrer Installationsphase auf dem unter @file{/mnt} befindlichen Zieldateisystem gespeichert, statt den Arbeitsspeicher auszulasten. Das ist nötig, weil die erste Phase des Befehls @command{guix system init} (siehe unten) viele Dateien nach @file{/gnu/store} herunterlädt oder sie erstellt, Änderungen am @file{/gnu/store} aber bis dahin wie das übrige Installationssystem nur im Arbeitsspeicher gelagert werden konnten. Als Nächstes müssen Sie eine Datei bearbeiten und dort eine Deklaration des Betriebssystems, das Sie installieren möchten, hineinschreiben. Zu diesem Zweck sind im Installationssystem drei Texteditoren enthalten. Wir empfehlen, dass Sie GNU nano benutzen (siehe @ref{Top,,, nano, GNU nano Manual}), welcher Syntax und zueinander gehörende Klammern hervorheben kann. Andere mitgelieferte Texteditoren, die Sie benutzen können, sind GNU Zile (ein Emacs-Klon) und nvi (ein Klon des ursprünglichen @command{vi}-Editors von BSD). Wir empfehlen sehr, dass Sie diese Datei im Zieldateisystem der Installation speichern, etwa als @file{/mnt/etc/config.scm}, weil Sie Ihre Konfigurationsdatei im frisch installierten System noch brauchen werden. Der Abschnitt @ref{Das Konfigurationssystem nutzen} gibt einen Überblick über die Konfigurationsdatei. Die in dem Abschnitt diskutierten Beispielkonfigurationen sind im Installationsabbild im Verzeichnis @file{/etc/configuration} zu finden. Um also mit einer Systemkonfiguration anzufangen, die einen grafischen »Display-Server« (eine »Desktop«-Arbeitsumgebung) bietet, könnten Sie so etwas ausführen: @example # mkdir /mnt/etc # cp /etc/configuration/desktop.scm /mnt/etc/config.scm # nano /mnt/etc/config.scm @end example Achten Sie darauf, was in Ihrer Konfigurationsdatei steht, und besonders auf Folgendes: @itemize @item Ihre @code{bootloader-configuration}-Form muss sich auf dasjenige Ziel beziehen, auf das Sie GRUB installieren möchten. Sie sollte genau dann @code{grub-bootloader} nennen, wenn Sie GRUB im alten BIOS-Modus installieren, und für neuere UEFI-Systeme sollten Sie @code{grub-efi-bootloader} nennen. Bei Altsystemen bezeichnet das @code{target}-Feld ein Gerät wie @code{/dev/sda}, bei UEFI-Systemen bezeichnet es den Pfad zu einer eingebundenen EFI-Partition wie @code{/boot/efi}; stellen Sie sicher, dass die ESP tatsächlich dort eingebunden ist und ein @code{file-system}-Eintrag dafür in Ihrer Konfiguration festgelegt wurde. @item Dateisystembezeichnungen müssen mit den jeweiligen @code{device}-Feldern in Ihrer @code{file-system}-Konfiguration übereinstimmen, sofern Sie in Ihrer @code{file-system}-Konfiguration die Prozedur @code{file-system-label} für ihre @code{device}-Felder benutzen. @item Gibt es verschlüsselte Partitionen oder RAID-Partitionen, dann müssen sie im @code{mapped-devices}-Feld genannt werden (siehe @ref{Zugeordnete Geräte}). @end itemize Wenn Sie damit fertig sind, Ihre Konfigurationsdatei vorzubereiten, können Sie das neue System initialisieren (denken Sie daran, dass zukünftige Wurzeldateisystem muss unter @file{/mnt} wie bereits beschrieben eingebunden sein): @example guix system init /mnt/etc/config.scm /mnt @end example @noindent Dies kopiert alle notwendigen Dateien und installiert GRUB auf @file{/dev/sdX}, sofern Sie nicht noch die Befehlszeilenoption @option{--no-bootloader} benutzen. Weitere Informationen finden Sie im Abschnitt @ref{Aufruf von guix system}. Der Befehl kann das Herunterladen oder Erstellen fehlender Softwarepakete auslösen, was einige Zeit in Anspruch nehmen kann. Sobald der Befehl erfolgreich — hoffentlich! — durchgelaufen ist, können Sie mit dem Befehl @command{reboot} das neue System booten lassen. Der Administratornutzer @code{root} hat im neuen System zunächst ein leeres Passwort, und Passwörter der anderen Nutzer müssen Sie später setzen, indem Sie den Befehl @command{passwd} als @code{root} ausführen, außer Ihre Konfiguration enthält schon Passwörter (siehe @ref{user-account-password, user account passwords}). Siehe @ref{Nach der Systeminstallation} für Informationen, wie es weiter geht! @node Nach der Systeminstallation @section Nach der Systeminstallation Sie haben es geschafft: Sie haben Guix System erfolgreich gebootet! Von jetzt an können Sie Guix System aktualisieren, wann Sie möchten, indem Sie zum Beispiel das hier ausführen: @example guix pull sudo guix system reconfigure /etc/config.scm @end example @noindent Dadurch wird eine neue Systemgeneration aus den neuesten Paketen und Diensten erstellt (siehe @ref{Aufruf von guix system}). Wir empfehlen, diese Schritte regelmäßig zu wiederholen, damit Ihr System die aktuellen Sicherheitsaktualisierungen benutzt (siehe @ref{Sicherheitsaktualisierungen}). @c See . @quotation Anmerkung @cindex sudo, Wirkung auf @command{guix pull} Beachten Sie, dass bei Nutzung von @command{sudo guix} der @command{guix}-Befehl des aktiven Benutzers ausgeführt wird und @emph{nicht} der des Administratornutzers »root«, weil @command{sudo} die Umgebungsvariable @code{PATH} unverändert lässt. Um ausdrücklich das @command{guix}-Programm des Administrators aufzurufen, müssen Sie @command{sudo -i guix @dots{}} eintippen. @end quotation Besuchen Sie uns auf @code{#guix} auf dem Freenode-IRC-Netzwerk oder auf der Mailing-Liste @file{guix-devel@@gnu.org}, um uns Rückmeldung zu geben! @node Guix in einer VM installieren @section Guix in einer virtuellen Maschine installieren @cindex virtuelle Maschine, Guix System installieren @cindex Virtual Private Server (VPS) @cindex VPS (Virtual Private Server) Wenn Sie Guix System auf einer virtuellen Maschine (VM) oder einem »Virtual Private Server« (VPS) statt auf Ihrer echten Maschine installieren möchten, ist dieser Abschnitt hier richtig für Sie. Um eine virtuelle Maschine für @uref{http://qemu.org/,QEMU} aufzusetzen, mit der Sie Guix System in ein »Disk-Image« installieren können (also in eine Datei mit einem Abbild eines Plattenspeichers), gehen Sie so vor: @enumerate @item Zunächst laden Sie das Installationsabbild des Guix-Systems wie zuvor beschrieben herunter und entpacken es (siehe @ref{Installation von USB-Stick oder DVD}). @item Legen Sie nun ein Disk-Image an, das das System nach der Installation enthalten soll. Um ein qcow2-formatiertes Disk-Image zu erstellen, benutzen Sie den Befehl @command{qemu-img}: @example qemu-img create -f qcow2 guixsd.img 50G @end example Die Datei, die Sie herausbekommen, wird wesentlich kleiner als 50 GB sein (typischerweise kleiner als 1 MB), vergrößert sich aber, wenn der virtualisierte Speicher gefüllt wird. @item Starten Sie das USB-Installationsabbild auf einer virtuellen Maschine: @example qemu-system-x86_64 -m 1024 -smp 1 \ -net user -net nic,model=virtio -boot menu=on \ -drive file=guix-system-install-@value{VERSION}.@var{System}.iso \ -drive file=guixsd.img @end example Halten Sie obige Reihenfolge der @option{-drive}-Befehlszeilenoptionen für die Laufwerke ein. Drücken Sie auf der Konsole der virtuellen Maschine schnell die @kbd{F12}-Taste, um ins Boot-Menü zu gelangen. Drücken Sie dort erst die Taste @kbd{2} und dann die Eingabetaste @kbd{RET}, um Ihre Auswahl zu bestätigen. @item Sie sind nun in der virtuellen Maschine als Administratornutzer @code{root} angemeldet und können mit der Installation wie gewohnt fortfahren. Folgen Sie der Anleitung im Abschnitt @ref{Vor der Installation}. @end enumerate Wurde die Installation abgeschlossen, können Sie das System starten, das sich nun als Abbild in der Datei @file{guixsd.img} befindet. Der Abschnitt @ref{Guix in einer VM starten} erklärt, wie Sie das tun können. @node Ein Abbild zur Installation erstellen @section Ein Abbild zur Installation erstellen @cindex Installationsabbild Das oben beschriebene Installationsabbild wurde mit dem Befehl @command{guix system} erstellt, genauer gesagt mit: @example guix system disk-image --file-system-type=iso9660 \ gnu/system/install.scm @end example Die Datei @file{gnu/system/install.scm} finden Sie im Quellbaum von Guix. Schauen Sie sich die Datei und auch den Abschnitt @ref{Aufruf von guix system} an, um mehr Informationen über das Installationsabbild zu erhalten. @section Abbild zur Installation für ARM-Rechner erstellen Viele ARM-Chips funktionieren nur mit ihrer eigenen speziellen Variante des @uref{http://www.denx.de/wiki/U-Boot/, U-Boot}-Bootloaders. Wenn Sie ein Disk-Image erstellen und der Bootloader nicht anderweitig schon installiert ist (auf einem anderen Laufwerk), ist es ratsam, ein Disk-Image zu erstellen, was den Bootloader enthält, mit dem Befehl: @example guix system disk-image --system=armhf-linux -e '((@@ (gnu system install) os-with-u-boot) (@@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' @end example @code{A20-OLinuXino-Lime2} ist der Name des Chips. Wenn Sie einen ungültigen Namen eingeben, wird eine Liste möglicher Chip-Namen ausgegeben. @c ********************************************************************* @node Paketverwaltung @chapter Paketverwaltung @cindex Pakete Der Zweck von GNU Guix ist, Benutzern die leichte Installation, Aktualisierung und Entfernung von Software-Paketen zu ermöglichen, ohne dass sie ihre Erstellungsprozeduren oder Abhängigkeiten kennen müssen. Guix kann natürlich noch mehr als diese offensichtlichen Funktionalitäten. Dieses Kapitel beschreibt die Hauptfunktionalitäten von Guix, sowie die von Guix angebotenen Paketverwaltungswerkzeuge. Zusätzlich von den im Folgenden beschriebenen Befehlszeilen-Benutzerschnittstellen (siehe @ref{Aufruf von guix package, @code{guix package}}) können Sie auch mit der Emacs-Guix-Schnittstelle (siehe @ref{Top,,, emacs-guix, The Emacs-Guix Reference Manual}) arbeiten, nachdem Sie das Paket @code{emacs-guix} installiert haben (führen Sie zum Einstieg in Emacs-Guix den Emacs-Befehl @kbd{M-x guix-help} aus): @example guix package -i emacs-guix @end example @menu * Funktionalitäten:: Wie Guix Ihr Leben schöner machen wird. * Aufruf von guix package:: Pakete installieren, entfernen usw. * Substitute:: Vorerstelle Binärdateien herunterladen. * Pakete mit mehreren Ausgaben.:: Ein Quellpaket, mehrere Ausgaben. * Aufruf von guix gc:: Den Müllsammler laufen lassen. * Aufruf von guix pull:: Das neueste Guix samt Distribution laden. * Kanäle:: Die Paketsammlung anpassen. * Untergeordnete:: Mit einer anderen Version von Guix interagieren. * Aufruf von guix describe:: Informationen über Ihre Guix-Version anzeigen. * Aufruf von guix archive:: Import und Export von Store-Dateien. @end menu @node Funktionalitäten @section Funktionalitäten Wenn Sie Guix benutzen, landet jedes Paket schließlich im @dfn{Paket-Store} in seinem eigenen Verzeichnis — der Name ist ähnlich wie @file{/gnu/store/xxx-package-1.2}, wobei @code{xxx} eine Zeichenkette in Base32-Darstellung ist. Statt diese Verzeichnisse direkt anzugeben, haben Nutzer ihr eigenes @dfn{Profil}, welches auf diejenigen Pakete zeigt, die sie tatsächlich benutzen wollen. Diese Profile sind im Persönlichen Verzeichnis des jeweiligen Nutzers gespeichert als @code{$HOME/.guix-profile}. Zum Beispiel installiert @code{alice} GCC 4.7.2. Dadurch zeigt dann @file{/home/alice/.guix-profile/bin/gcc} auf @file{/gnu/store/@dots{}-gcc-4.7.2/bin/gcc}. Auf demselben Rechner hat @code{bob} bereits GCC 4.8.0 installiert. Das Profil von @code{bob} zeigt dann einfach weiterhin auf @file{/gnu/store/@dots{}-gcc-4.8.0/bin/gcc} — d.h.@: beide Versionen von GCC koexistieren auf demselben System, ohne sich zu stören. Der Befehl @command{guix package} ist das zentrale Werkzeug, um Pakete zu verwalten (siehe @ref{Aufruf von guix package}). Es arbeitet auf dem eigenen Profil jedes Nutzers und kann @emph{mit normalen Benutzerrechten} ausgeführt werden. @cindex Transaktionen Der Befehl stellt die offensichtlichen Installations-, Entfernungs- und Aktualisierungsoperationen zur Verfügung. Jeder Aufruf ist tatsächlich eine eigene @emph{Transaktion}: Entweder die angegebene Operation wird erfolgreich durchgeführt, oder gar nichts passiert. Wenn also der Prozess von @command{guix package} während der Transaktion beendet wird, oder es zum Stromausfall während der Transaktion kommt, dann bleibt der alte, nutzbare Zustands des Nutzerprofils erhalten. Zudem kann jede Pakettransaktion @emph{zurückgesetzt} werden (Rollback). Wird also zum Beispiel durch eine Aktualisierung eine neue Version eines Pakets installiert, die einen schwerwiegenden Fehler zur Folge hat, können Nutzer ihr Profil einfach auf die vorherige Profilinstanz zurücksetzen, von der sie wissen, dass sie gut lief. Ebenso unterliegt bei Guix auch die globale Systemkonfiguration transaktionellen Aktualisierungen und Rücksetzungen (siehe @ref{Das Konfigurationssystem nutzen}). Alle Pakete im Paket-Store können vom @emph{Müllsammler} (Garbage Collector) gelöscht werden. Guix ist in der Lage, festzustellen, welche Pakete noch durch Benutzerprofile referenziert werden, und entfernt nur diese, die nachweislich nicht mehr referenziert werden (siehe @ref{Aufruf von guix gc}). Benutzer können auch ausdrücklich alte Generationen ihres Profils löschen, damit die zugehörigen Pakete vom Müllsammler gelöscht werden können. @cindex Reproduzierbarkeit @cindex Reproduzierbare Erstellungen Guix verfolgt einen @dfn{rein funktionalen} Ansatz bei der Paketverwaltung, wie er in der Einleitung beschrieben wurde (siehe @ref{Einführung}). Jedes Paketverzeichnis im @file{/gnu/store} hat einen Hash all seiner bei der Erstellung benutzten Eingaben im Namen — Compiler, Bibliotheken, Erstellungs-Skripts etc. Diese direkte Entsprechung ermöglicht es Benutzern, eine Paketinstallation zu benutzen, die sicher dem aktuellen Stand ihrer Distribution entspricht. Sie maximiert auch die @dfn{Reproduzierbarkeit der Erstellungen} zu maximieren: Dank der isolierten Erstellungsumgebungen, die benutzt werden, resultiert eine Erstellung wahrscheinlich in bitweise identischen Dateien, auch wenn sie auf unterschiedlichen Maschinen durchgeführt wird (siehe @ref{Aufruf des guix-daemon, container}). @cindex Substitute Auf dieser Grundlage kann Guix @dfn{transparent Binär- oder Quelldateien ausliefern}. Wenn eine vorerstellte Binärdatei für ein @file{/gnu/store}-Objekt von einer externen Quelle verfügbar ist — ein @dfn{Substitut} —, lädt Guix sie einfach herunter und entpackt sie, andernfalls erstellt Guix das Paket lokal aus seinem Quellcode (siehe @ref{Substitute}). Weil Erstellungsergebnisse normalerweise Bit für Bit reproduzierbar sind, müssen die Nutzer den Servern, die Substitute anbieten, nicht blind vertrauen; sie können eine lokale Erstellung erzwingen und Substitute @emph{anfechten} (siehe @ref{Aufruf von guix challenge}). Kontrolle über die Erstellungsumgebung ist eine auch für Entwickler nützliche Funktionalität. Der Befehl @command{guix environment} ermöglicht es Entwicklern eines Pakets, schnell die richtige Entwicklungsumgebung für ihr Paket einzurichten, ohne manuell die Abhängigkeiten des Pakets in ihr Profil installieren zu müssen (siehe @ref{Aufruf von guix environment}). @cindex Nachbildung, von Software-Umgebungen @cindex Provenienzverfolgung, von Software-Artefakten Ganz Guix und all seine Paketdefinitionen stehen unter Versionskontrolle und @command{guix pull} macht es möglich, auf dem Verlauf der Entwicklung von Guix selbst »in der Zeit zu reisen« (siehe @ref{Aufruf von guix pull}). Dadurch kann eine Instanz von Guix auf einer anderen Maschine oder zu einem späteren Zeitpunkt genau nachgebildet werden, wodurch auch @emph{vollständige Software-Umgebungen gänzlich nachgebildet} werden können, mit genauer @dfn{Provenienzverfolgung}, wo diese Software herkommt. @node Aufruf von guix package @section Invoking @command{guix package} @cindex Installieren von Paketen @cindex Entfernen von Paketen @cindex Paketinstallation @cindex Paketentfernung Der Befehl @command{guix package} ist ein Werkzeug, womit Nutzer Pakete installieren, aktualisieren, entfernen und auf vorherige Konfigurationen zurücksetzen können. Dabei wird nur das eigene Profil des Nutzers verwendet, und es funktioniert mit normalen Benutzerrechten, ohne Administratorrechte (siehe @ref{Funktionalitäten}). Die Syntax ist: @example guix package @var{Optionen} @end example @cindex Transaktionen In erster Linie geben die @var{Optionen} an, welche Operationen in der Transaktion durchgeführt werden sollen. Nach Abschluss wird ein neues Profil erzeugt, aber vorherige @dfn{Generationen} des Profils bleiben verfügbar, falls der Benutzer auf sie zurückwechseln will. Um zum Beispiel @code{lua} zu entfernen und @code{guile} und @code{guile-cairo} in einer einzigen Transaktion zu installieren: @example guix package -r lua -i guile guile-cairo @end example @command{guix package} unterstützt auch ein @dfn{deklaratives Vorgehen}, wobei der Nutzer die genaue Menge an Paketen, die verfügbar sein sollen, festlegt und über die Befehlszeilenoption @option{--manifest} übergibt (siehe @ref{profile-manifest, @option{--manifest}}). @cindex Profil Für jeden Benutzer wird automatisch eine symbolische Verknüpfung zu seinem Standardprofil angelegt als @file{$HOME/.guix-profile}. Diese symbolische Verknüpfung zeigt immer auf die aktuelle Generation des Standardprofils des Benutzers. Somit können Nutzer @file{$HOME/.guix-profile/bin} z.B.@: zu ihrer Umgebungsvariablen @code{PATH} hinzufügen. @cindex Suchpfade Wenn Sie nicht die Guix System Distribution benutzen, sollten Sie in Betracht ziehen, folgende Zeilen zu Ihrem @file{~/.bash_profile} hinzuzufügen (siehe @ref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}), damit in neu erzeugten Shells alle Umgebungsvariablen richtig definiert werden: @example GUIX_PROFILE="$HOME/.guix-profile" ; \ source "$HOME/.guix-profile/etc/profile" @end example Ist Ihr System für mehrere Nutzer eingerichtet, werden Nutzerprofile an einem Ort gespeichert, der als @dfn{Müllsammlerwurzel} registriert ist, auf die @file{$HOME/.guix-profile} zeigt (siehe @ref{Aufruf von guix gc}). Dieses Verzeichnis ist normalerweise @code{@var{localstatedir}/guix/profiles/per-user/@var{Benutzer}}, wobei @var{localstatedir} der an @code{configure} als @code{--localstatedir} übergebene Wert ist und @var{Benutzer} für den jeweiligen Benutzernamen steht. Das @file{per-user}-Verzeichnis wird erstellt, wenn @command{guix-daemon} gestartet wird, und das Unterverzeichnis @var{Benutzer} wird durch @command{guix package} erstellt. Als @var{Optionen} kann vorkommen: @table @code @item --install=@var{Paket} @dots{} @itemx -i @var{Paket} @dots{} Die angegebenen @var{Paket}e installieren. Jedes @var{Paket} kann entweder einfach durch seinen Paketnamen aufgeführt werden, wie @code{guile}, oder als Paketname gefolgt von einem At-Zeichen @@ und einer Versionsnummer, wie @code{guile@@1.8.8} oder auch nur @code{guile@@1.8} (in letzterem Fall wird die neueste Version mit Präfix @code{1.8} ausgewählt.) Wird keine Versionsnummer angegeben, wird die neueste verfügbare Version ausgewählt. Zudem kann im @var{Paket} ein Doppelpunkt auftauchen, gefolgt vom Namen einer der Ausgaben des Pakets, wie @code{gcc:doc} oder @code{binutils@@2.22:lib} (siehe @ref{Pakete mit mehreren Ausgaben.}). Pakete mit zugehörigem Namen (und optional der Version) werden unter den Modulen der GNU-Distribution gesucht (siehe @ref{Paketmodule}). @cindex propagierte Eingaben Manchmal haben Pakete @dfn{propagierte Eingaben}: Als solche werden Abhängigkeiten bezeichnet, die automatisch zusammen mit dem angeforderten Paket installiert werden (im Abschnitt @ref{package-propagated-inputs, @code{propagated-inputs} in @code{package} objects} sind weitere Informationen über propagierte Eingaben in Paketdefinitionen zu finden). @anchor{package-cmd-propagated-inputs} Ein Beispiel ist die GNU-MPC-Bibliothek: Ihre C-Headerdateien verweisen auf die der GNU-MPFR-Bibliothek, welche wiederum auf die der GMP-Bibliothek verweisen. Wenn also MPC installiert wird, werden auch die MPFR- und GMP-Bibliotheken in das Profil installiert; entfernt man MPC, werden auch MPFR und GMP entfernt — außer sie wurden noch auf andere Art ausdrücklich vom Nutzer installiert. Abgesehen davon setzen Pakete manchmal die Definition von Umgebungsvariablen für ihre Suchpfade voraus (siehe die Erklärung von @code{--search-paths} weiter unten). Alle fehlenden oder womöglich falschen Definitionen von Umgebungsvariablen werden hierbei gemeldet. @item --install-from-expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Das Paket installieren, zu dem der @var{Ausdruck} ausgewertet wird. Beim @var{Ausdruck} muss es sich um einen Scheme-Ausdruck handeln, der zu einem @code{}-Objekt ausgewertet wird. Diese Option ist besonders nützlich, um zwischen gleichnamigen Varianten eines Pakets zu unterscheiden, durch Ausdrücke wie @code{(@@ (gnu packages base) guile-final)}. Beachten Sie, dass mit dieser Option die erste Ausgabe des angegebenen Pakets installiert wird, was unzureichend sein kann, wenn eine bestimmte Ausgabe eines Pakets mit mehreren Ausgaben gewünscht ist. @item --install-from-file=@var{Datei} @itemx -f @var{Datei} Das Paket installieren, zu dem der Code in der @var{Datei} ausgewertet wird. Zum Beispiel könnte die @var{Datei} eine Definition wie diese enthalten (siehe @ref{Pakete definieren}): @example @verbatiminclude package-hello.scm @end example Entwickler könnten es für nützlich erachten, eine solche @file{guix.scm}-Datei im Quellbaum ihres Projekts abzulegen, mit der Zwischenstände der Entwicklung getestet und reproduzierbare Erstellungsumgebungen aufgebaut werden können (siehe @ref{Aufruf von guix environment}). @item --remove=@var{Paket} @dots{} @itemx -r @var{Paket} @dots{} Die angegebenen @var{Paket}e entfernen. Wie auch bei @code{--install} kann jedes @var{Paket} neben dem Paketnamen auch eine Versionsnummer und/oder eine Ausgabe benennen. Zum Beispiel würde @code{-r glibc:debug} die @code{debug}-Ausgabe von @code{glibc} aus dem Profil entfernen. @item --upgrade[=@var{Regexp} @dots{}] @itemx -u [@var{Regexp} @dots{}] @cindex Pakete aktualisieren Alle installierten Pakete aktualisieren. Wenn einer oder mehr reguläre Ausdrücke (Regexps) angegeben wurden, werden nur diejenigen installierten Pakete aktualisiert, deren Name zu einer der @var{Regexp}s passt. Siehe auch weiter unten die Befehlszeilenoption @code{--do-not-upgrade}. Beachten Sie, dass das Paket so auf die neueste Version unter den Paketen gebracht wird, die in der aktuell installierten Distribution vorliegen. Um jedoch Ihre Distribution zu aktualisieren, sollten Sie regelmäßig @command{guix pull} ausführen (siehe @ref{Aufruf von guix pull}). @item --do-not-upgrade[=@var{Regexp} @dots{}] In Verbindung mit der Befehlszeilenoption @code{--upgrade}, führe @emph{keine} Aktualisierung von Paketen durch, deren Name zum regulären Ausdruck @var{Regexp} passt. Um zum Beispiel alle Pakete im aktuellen Profil zu aktualisieren mit Ausnahme derer, die »emacs« im Namen haben: @example $ guix package --upgrade . --do-not-upgrade emacs @end example @item @anchor{profile-manifest}--manifest=@var{Datei} @itemx -m @var{Datei} @cindex Profildeklaration @cindex Profilmanifest Erstellt eine neue Generation des Profils aus dem vom Scheme-Code in @var{Datei} gelieferten Manifest-Objekt. Dadurch könnrn Sie den Inhalt des Profils @emph{deklarieren}, statt ihn durch eine Folge von Befehlen wie @code{--install} u.Ä. zu generieren. Der Vorteil ist, dass die @var{Datei} unter Versionskontrolle gestellt werden kann, auf andere Maschinen zum Reproduzieren desselben Profils kopiert werden kann und Ähnliches. @c FIXME: Add reference to (guix profile) documentation when available. Der Code in der @var{Datei} muss ein @dfn{Manifest}-Objekt liefern, was ungefähr einer Liste von Paketen entspricht: @findex packages->manifest @example (use-package-modules guile emacs) (packages->manifest (list emacs guile-2.0 ;; Eine bestimmte Paketausgabe nutzen. (list guile-2.0 "debug"))) @end example @findex specifications->manifest In diesem Beispiel müssen wir wissen, welche Module die Variablen @code{emacs} und @code{guile-2.0} definieren, um die richtige Angabe mit @code{use-package-modules} machen zu können, was umständlich sein kann. Wir können auch normale Paketnamen angeben und sie durch @code{specifications->manifest} zu den entsprechenden Paketobjekten auflösen, zum Beispiel so: @example (specifications->manifest '("emacs" "guile@@2.2" "guile@@2.2:debug")) @end example @item --roll-back @cindex rücksetzen @cindex Zurücksetzen von Transaktionen @cindex Transaktionen, zurücksetzen Wechselt zur vorherigen @dfn{Generation} des Profils zurück — d.h.@: macht die letzte Transaktion rückgängig. In Verbindung mit Befehlszeilenoptionen wie @code{--install} wird zuerst zurückgesetzt, bevor andere Aktionen durchgeführt werden. Ein Rücksetzen der ersten Generation, die installierte Pakete enthält, wechselt das Profil zur @dfn{nullten Generation}, die keinerlei Dateien enthält, abgesehen von Metadaten über sich selbst. Nach dem Zurücksetzen überschreibt das Installieren, Entfernen oder Aktualisieren von Paketen vormals zukünftige Generationen, d.h.@: der Verlauf der Generationen eines Profils ist immer linear. @item --switch-generation=@var{Muster} @itemx -S @var{Muster} @cindex Generationen Wechselt zu der bestimmten Generation, die durch das @var{Muster} bezeichnet wird. Als @var{Muster} kann entweder die Nummer einer Generation oder eine Nummer mit vorangestelltem »+« oder »-« dienen. Letzteres springt die angegebene Anzahl an Generationen vor oder zurück. Zum Beispiel kehrt @code{--switch-generation=+1} nach einem Zurücksetzen wieder zur neueren Generation zurück. Der Unterschied zwischen @code{--roll-back} und @code{--switch-generation=-1} ist, dass @code{--switch-generation} keine nullte Generation erzeugen wird; existiert die angegebene Generation nicht, bleibt schlicht die aktuelle Generation erhalten. @item --search-paths[=@var{Art}] @cindex Suchpfade Führe die Definitionen von Umgebungsvariablen auf, in Bash-Syntax, die nötig sein könnten, um alle installierten Pakete nutzen zu können. Diese Umgebungsvariablen werden benutzt, um die @dfn{Suchpfade} für Dateien festzulegen, die von einigen installierten Paketen benutzt werden. Zum Beispiel braucht GCC die Umgebungsvariablen @code{CPATH} und @code{LIBRARY_PATH}, um zu wissen, wo sich im Benutzerprofil Header und Bibliotheken befinden (siehe @ref{Environment Variables,,, gcc, Using the GNU Compiler Collection (GCC)}). Wenn GCC und, sagen wir, die C-Bibliothek im Profil installiert sind, schlägt @code{--search-paths} also vor, diese Variablen jeweils auf @code{@var{profile}/include} und @code{@var{profile}/lib} verweisen zu lassen. Die typische Nutzung ist, in der Shell diese Variablen zu definieren: @example $ eval `guix package --search-paths` @end example Als @var{Art} kann entweder @code{exact}, @code{prefix} oder @code{suffix} gewählt werden, wodurch die gelieferten Definitionen der Umgebungsvariablen entweder exakt die Einstellungen für Guix meldet, oder sie als Präfix oder Suffix an den aktuellen Wert dieser Variablen anhängt. Gibt man keine @var{Art} an, wird der Vorgabewert @code{exact} verwendet. Diese Befehlszeilenoption kann auch benutzt werden, um die @emph{kombinierten} Suchpfade mehrerer Profile zu berechnen. Betrachten Sie dieses Beispiel: @example $ guix package -p foo -i guile $ guix package -p bar -i guile-json $ guix package -p foo -p bar --search-paths @end example Der letzte Befehl oben meldet auch die Definition der Umgebungsvariablen @code{GUILE_LOAD_PATH}, obwohl für sich genommen weder @file{foo} noch @file{bar} zu dieser Empfehlung führen würden. @item --profile=@var{Profil} @itemx -p @var{Profil} Auf @var{Profil} anstelle des Standardprofils des Benutzers arbeiten. @cindex Kollisionen, in einem Profil @cindex Paketkollisionen in Profilen @cindex Profilkollisionen @item --allow-collisions Kollidierende Pakete im neuen Profil zulassen. Benutzung auf eigene Gefahr! Standardmäßig wird @command{guix package} @dfn{Kollisionen} als Fehler auffassen und melden. Zu Kollisionen kommt es, wenn zwei oder mehr verschiedene Versionen oder Varianten desselben Pakets im Profil landen. @item --bootstrap Erstellt das Profil mit dem Bootstrap-Guile. Diese Option ist nur für Entwickler der Distribution nützlich. @end table Zusätzlich zu diesen Aktionen unterstützt @command{guix package} folgende Befehlszeilenoptionen, um den momentanen Zustand eines Profils oder die Verfügbarkeit von Paketen nachzulesen: @table @option @item --search=@var{Regexp} @itemx -s @var{Regexp} @cindex Suche nach Paketen Führt alle verfügbaren Pakete auf, deren Name, Zusammenfassung oder Beschreibung zum regulären Ausdruck @var{Regexp} passt, ohne Groß- und Kleinschreibung zu unterscheiden und sortiert nach ihrer Relevanz. Alle Metadaten passender Pakete werden im @code{recutils}-Format geliefert (siehe @ref{Top, GNU recutils databases,, recutils, GNU recutils manual}). So können bestimmte Felder mit dem Befehl @command{recsel} extrahiert werden, zum Beispiel: @example $ guix package -s malloc | recsel -p name,version,relevance name: jemalloc version: 4.5.0 relevance: 6 name: glibc version: 2.25 relevance: 1 name: libgc version: 7.6.0 relevance: 1 @end example Ebenso kann der Name aller zu den Bedingungen der GNU@tie{}LGPL, Version 3, verfügbaren Pakete ermittelt werden: @example $ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"' name: elfutils name: gmp @dots{} @end example Es ist auch möglich, Suchergebnisse näher einzuschränken, indem Sie @code{-s} mehrmals übergeben. Zum Beispiel liefert folgender Befehl eines Liste von Brettspielen: @example $ guix package -s '\' -s game | recsel -p name name: gnubg @dots{} @end example Würden wir @code{-s game} weglassen, bekämen wir auch Software-Pakete aufgelistet, die mit »printed circuit boards« (elektronischen Leiterplatten) zu tun haben; ohne die spitzen Klammern um @code{board} bekämen wir auch Pakete, die mit »keyboards« (Tastaturen, oder musikalischen Keyboard) zu tun haben. Es ist Zeit für ein komplexeres Beispiel. Folgender Befehl sucht kryptografische Bibliotheken, filtert Haskell-, Perl-, Python- und Ruby-Bibliotheken heraus und gibt Namen und Zusammenfassung passender Pakete aus: @example $ guix package -s crypto -s library | \ recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis @end example @noindent Siehe @ref{Selection Expressions,,, recutils, GNU recutils manual}, es enthält weitere Informationen über @dfn{Auswahlausdrücke} mit @code{recsel -e}. @item --show=@var{Paket} Zeigt Details über das @var{Paket} aus der Liste verfügbarer Pakete, im @code{recutils}-Format (siehe @ref{Top, GNU recutils databases,, recutils, GNU recutils manual}). @example $ guix package --show=python | recsel -p name,version name: python version: 2.7.6 name: python version: 3.3.5 @end example Sie können auch den vollständigen Namen eines Pakets angeben, um Details nur über diese Version angezeigt zu bekommen: @example $ guix package --show=python@@3.4 | recsel -p name,version name: python version: 3.4.3 @end example @item --list-installed[=@var{Regexp}] @itemx -I [@var{Regexp}] Listet die derzeit installierten Pakete im angegebenen Profil auf, die zuletzt installierten Pakete zuletzt. Wenn ein regulärer Ausdruck @var{Regexp} angegeben wird, werden nur installierte Pakete aufgeführt, deren Name zu @var{Regexp} passt. Zu jedem installierten Paket werden folgende Informationen angezeigt, durch Tabulatorzeichen getrennt: der Paketname, die Version als Zeichenkette, welche Teile des Pakets installiert sind (zum Beispiel @code{out}, wenn die Standard-Paketausgabe installiert ist, @code{include}, wenn seine Header installiert sind, usw.)@: und an welchem Pfad das Paket im Store zu finden ist. @item --list-available[=@var{Regexp}] @itemx -A [@var{Regexp}] Listet Pakete auf, die in der aktuell installierten Distribution dieses Systems verfügbar sind (siehe @ref{GNU-Distribution}). Wenn ein regulärer Ausdruck @var{Regexp} angegeben wird, werden nur Pakete aufgeführt, deren Name zum regulären Ausdruck @var{Regexp} passt. Zu jedem Paket werden folgende Informationen getrennt durch Tabulatorzeichen ausgegeben: der Name, die Version als Zeichenkette, die Teile des Programms (siehe @ref{Pakete mit mehreren Ausgaben.}) und die Stelle im Quellcode, an der das Paket definiert ist. @item --list-generations[=@var{Muster}] @itemx -l [@var{Muster}] @cindex Generationen Liefert eine Liste der Generationen zusammen mit dem Datum, an dem sie erzeugt wurden; zu jeder Generation werden zudem die installierten Pakete angezeigt, zuletzt installierte Pakete zuletzt. Beachten Sie, dass die nullte Generation niemals angezeigt wird. Zu jedem installierten Paket werden folgende Informationen durch Tabulatorzeichen getrennt angezeigt: der Name des Pakets, die Version als Zeichenkette, welcher Teil des Pakets installiert ist (siehe @ref{Pakete mit mehreren Ausgaben.}) und an welcher Stelle sich das Paket im Store befindet. Wenn ein @var{Muster} angegeben wird, liefert der Befehl nur dazu passende Generationen. Gültige Muster sind zum Beispiel: @itemize @item @emph{Ganze Zahlen und kommagetrennte ganze Zahlen}. Beide Muster bezeichnen Generationsnummern. Zum Beispiel liefert @code{--list-generations=1} die erste Generation. Durch @code{--list-generations=1,8,2} werden drei Generationen in der angegebenen Reihenfolge angezeigt. Weder Leerzeichen noch ein Komma am Schluss der Liste ist erlaubt. @item @emph{Bereiche}. @code{--list-generations=2..9} gibt die angegebenen Generationen und alles dazwischen aus. Beachten Sie, dass der Bereichsanfang eine kleinere Zahl als das Bereichsende sein muss. Sie können auch kein Bereichsende angeben, zum Beispiel liefert @code{--list-generations=2..} alle Generationen ab der zweiten. @item @emph{Zeitdauern}. Sie können auch die letzten @emph{N}@tie{}Tage, Wochen oder Monate angeben, indem Sie eine ganze Zahl gefolgt von jeweils »d«, »w« oder »m« angeben (dem ersten Buchstaben der Maßeinheit der Dauer im Englischen). Zum Beispiel listet @code{--list-generations=20d} die Generationen auf, die höchstens 20 Tage alt sind. @end itemize @item --delete-generations[=@var{Muster}] @itemx -d [@var{Muster}] Wird kein @var{Muster} angegeben, werden alle Generationen außer der aktuellen entfernt. Dieser Befehl akzeptiert dieselben Muster wie @option{--list-generations}. Wenn ein @var{Muster} angegeben wird, werden die passenden Generationen gelöscht. Wenn das @var{Muster} für eine Zeitdauer steht, werden diejenigen Generationen gelöscht, die @emph{älter} als die angegebene Dauer sind. Zum Beispiel löscht @code{--delete-generations=1m} die Generationen, die mehr als einen Monat alt sind. Falls die aktuelle Generation zum Muster passt, wird sie @emph{nicht} gelöscht. Auch die nullte Generation wird niemals gelöscht. Beachten Sie, dass Sie auf gelöschte Generationen nicht zurückwechseln können. Dieser Befehl sollte also nur mit Vorsicht benutzt werden. @end table Zu guter Letzt können Sie, da @command{guix package} Erstellungsprozesse zu starten vermag, auch alle gemeinsamen Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}) verwenden. Auch Paketumwandlungsoptionen wie @option{--with-source} sind möglich (siehe @ref{Paketumwandlungsoptionen}). Beachten Sie jedoch, dass die verwendeten Paketumwandlungsoptionen verloren gehen, nachdem Sie die Pakete aktualisiert haben. Damit Paketumwandlungen über Aktualisierungen hinweg erhalten bleiben, sollten Sie Ihre eigene Paketvariante in einem Guile-Modul definieren und zur Umgebungsvariablen @code{GUIX_PACKAGE_PATH} hinzufügen (siehe @ref{Pakete definieren}). @node Substitute @section Substitute @cindex Substitute @cindex vorerstellte Binärdateien Guix kann transparent Binär- oder Quelldateien ausliefern. Das heißt, Dinge können sowohl lokal erstellt, als auch als vorerstellte Objekte von einem Server heruntergeladen werden, oder beides gemischt. Wir bezeichnen diese vorerstellten Objekte als @dfn{Substitute} — sie substituieren lokale Erstellungsergebnisse. In vielen Fällen geht das Herunterladen eines Substituts wesentlich schneller, als Dinge lokal zu erstellen. Substitute können alles sein, was das Ergebnis einer Ableitungserstellung ist (siehe @ref{Ableitungen}). Natürlich sind sie üblicherweise vorerstellte Paket-Binärdateien, aber wenn zum Beispiel ein Quell-Tarball das Ergebnis einer Ableitungserstellung ist, kann auch er als Substitut verfügbar sein. @menu * Offizieller Substitut-Server:: Eine besondere Quelle von Substituten. * Substitut-Server autorisieren:: Wie man Substitute an- und abschaltet. * Substitutauthentifizierung:: Wie Guix Substitute verifiziert. * Proxy-Einstellungen:: Wie Sie Substitute über einen Proxy beziehen. * Fehler bei der Substitution:: Was passiert, wenn die Substitution fehlschlägt. * Vom Vertrauen gegenüber Binärdateien:: Wie können Sie diesem binären Blob trauen? @end menu @node Offizieller Substitut-Server @subsection Offizieller Substitut-Server @cindex Hydra @cindex Build-Farm Der Server @code{@value{SUBSTITUTE-SERVER}} ist die Fassade für eine offizielle »Build-Farm«, ein Erstellungswerk, das kontinuierlich Guix-Pakete für einige Prozessorarchitekturen erstellt und sie als Substitute zur Verfügung stellt. Dies ist die standardmäßige Quelle von Substituten; durch Übergeben der Befehlszeilenoption @option{--substitute-urls} an entweder den @command{guix-daemon} (siehe @ref{daemon-substitute-urls,, @code{guix-daemon --substitute-urls}}) oder Client-Werkzeuge wie @command{guix package} (siehe @ref{client-substitute-urls,, die Befehlszeilenoption @option{--substitute-urls} beim Client}) kann eine abweichende Einstellung benutzt werden. Substitut-URLs können entweder HTTP oder HTTPS sein. HTTPS wird empfohlen, weil die Kommunikation verschlüsselt ist; umgekehrt kann bei HTTP die Kommunikation belauscht werden, wodurch der Angreifer zum Beispiel erfahren könnte, ob Ihr System über noch nicht behobene Sicherheitsschwachstellen verfügt. Substitute von der offiziellen Build-Farm sind standardmäßig erlaubt, wenn Sie die Guix-System-Distribution verwenden (siehe @ref{GNU-Distribution}). Auf Fremddistributionen sind sie allerdings standardmäßig ausgeschaltet, solange Sie sie nicht ausdrücklich in einem der empfohlenen Installationsschritte erlaubt haben (siehe @ref{Installation}). Die folgenden Absätze beschreiben, wie Sie Substitute für die offizielle Build-Farm an- oder ausschalten; dieselbe Prozedur kann auch benutzt werden, um Substitute für einen beliebigen anderen Substitutsserver zu erlauben. @node Substitut-Server autorisieren @subsection Substitut-Server autorisieren @cindex Sicherheit @cindex Substitute, deren Autorisierung @cindex Access Control List (ACL), für Substitute @cindex ACL (Access Control List), für Substitute Um es Guix zu gestatten, Substitute von @code{@value{SUBSTITUTE-SERVER}} oder einem Spiegelserver davon herunterzuladen, müssen Sie den zugehörigen öffentlichen Schlüssel zur Access Control List (ACL, Zugriffssteuerungsliste) für Archivimporte hinzufügen, mit Hilfe des Befehls @command{guix archive} (siehe @ref{Aufruf von guix archive}). Dies impliziert, dass Sie darauf vertrauen, dass @code{@value{SUBSTITUTE-SERVER}} nicht kompromittiert wurde und echte Substitute liefert. Der öffentliche Schlüssel für @code{@value{SUBSTITUTE-SERVER}} wird zusammen mit Guix installiert, in das Verzeichnis @code{@var{prefix}/share/guix/hydra.gnu.org.pub}, wobei @var{prefix} das bei der Installation angegebene Präfix von Guix ist. Wenn Sie Guix aus seinem Quellcode heraus installieren, sollten Sie sichergehen, dass Sie die GPG-Signatur (auch »Beglaubigung« genannt) von @file{guix-@value{VERSION}.tar.gz} prüfen, worin sich dieser öffentliche Schlüssel befindet. Dann können Sie so etwas wie hier ausführen: @example # guix archive --authorize < @var{prefix}/share/guix/@value{SUBSTITUTE-SERVER}.pub @end example @quotation Anmerkung Genauso enthält die Datei @file{hydra.gnu.org.pub} den öffentlichen Schlüssel für eine unabhängige Build-Farm, die auch vom Guix-Projekt betrieben wird. Sie ist unter @indicateurl{https://mirror.hydra.gnu.org} erreichbar ist. @end quotation Sobald es eingerichtet wurde, sollte sich die Ausgabe eines Befehls wie @code{guix build} von so etwas: @example $ guix build emacs --dry-run Folgende Ableitungen würden erstellt: /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv @dots{} @end example @noindent in so etwas verwandeln: @example $ guix build emacs --dry-run 112.3 MB würden heruntergeladen: /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3 /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16 /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7 @dots{} @end example @noindent Das zeigt an, dass Substitute von @code{@value{SUBSTITUTE-SERVER}} nutzbar sind und für zukünftige Erstellungen heruntergeladen werden, wann immer es möglich ist. @cindex Substitute, wie man sie ausschaltet Der Substitutsmechanismus kann global ausgeschaltet werden, indem Sie dem @code{guix-daemon} beim Starten die Befehlszeilenoption @code{--no-substitutes} übergeben (siehe @ref{Aufruf des guix-daemon}). Er kann auch temporär ausgeschaltet werden, indem Sie @code{--no-substitutes} an @command{guix package}, @command{guix build} und andere Befehlszeilenwerkzeuge übergeben. @node Substitutauthentifizierung @subsection Substitutauthentifizierung @cindex digitale Signaturen Guix erkennt, wenn ein verfälschtes Substitut benutzt würde, und meldet einen Fehler. Ebenso werden Substitute ignoriert, die nich signiert sind, oder nicht mit einem in der ACL aufgelisteten Schlüssel signiert sind. Es gibt nur eine Ausnahme: Wenn ein unautorisierter Server Substitute anbietet, die @emph{Bit für Bit identisch} mit denen von einem autorisierten Server sind, können sie auch vom unautorisierten Server heruntergeladen werden. Zum Beispiel, angenommen wir haben zwei Substitutserver mit dieser Befehlszeilenoption ausgewählt: @example --substitute-urls="https://a.example.org https://b.example.org" @end example @noindent @cindex Reproduzierbare Erstellungen Wenn in der ACL nur der Schlüssel für @code{b.example.org} aufgeführt wurde, aber @code{a.example.org} @emph{exakt dieselben} Substitute anbietet, wird Guix auch Substitute von @code{a.example.org} herunterladen, weil es in der Liste zuerst kommt und als Spiegelserver für @code{b.example.org} aufgefasst werden kann. In der Praxis haben unabhängige Maschinen bei der Erstellung normalerweise dieselben Binärdateien als Ergebnis, dank bit-reproduzierbarer Erstellungen (siehe unten). Wenn Sie HTTPS benutzen, wird das X.509-Zertifikat des Servers @emph{nicht} validiert (mit anderen Worten, die Identität des Servers wird nicht authentifiziert), entgegen dem, was HTTPS-Clients wie Web-Browser normalerweise tun. Da Guix Substitutinformationen selbst überprüft, wie oben erklärt, wäre es unnötig (wohingegen mit X.509-Zertifikaten geprüft wird, ob ein Domain-Name zu öffentlichen Schlüsseln passt). @node Proxy-Einstellungen @subsection Proxy-Einstellungen @vindex http_proxy Substitute werden über HTTP oder HTTPS heruntergeladen. Die Umgebungsvariable @code{http_proxy} kann in der Umgebung von @command{guix-daemon} definiert werden und wirkt sich dann auf das Herunterladen von Substituten aus. Beachten Sie, dass der Wert von @code{http_proxy} in der Umgebung, in der @command{guix build}, @command{guix package} und andere Client-Befehle ausgeführt werden, @emph{keine Rolle spielt}. @node Fehler bei der Substitution @subsection Fehler bei der Substitution Selbst wenn ein Substitut für eine Ableitung verfügbar ist, schlägt die versuchte Substitution manchmal fehl. Das kann aus vielen Gründen geschehen: die Substitutsserver könnten offline sein, das Substitut könnte kürzlich gelöscht worden sein, die Netzwerkverbindunge könnte unterbrochen worden sein, usw. Wenn Substitute aktiviert sind und ein Substitut für eine Ableitung zwar verfügbar ist, aber die versuchte Substitution fehlschlägt, kann Guix versuchen, die Ableitung lokal zu erstellen, je nachdem, ob @code{--fallback} übergeben wurde (siehe @ref{fallback-option,, common build option @code{--fallback}}). Genauer gesagt, wird keine lokale Erstellung durchgeführt, solange kein @code{--fallback} angegeben wurde, und die Ableitung wird als Fehlschlag angesehen. Wenn @code{--fallback} übergeben wurde, wird Guix versuchen, die Ableitung lokal zu erstellen, und ob die Ableitung erfolgreich ist oder nicht, hängt davon ab, ob die lokale Erstellung erfolgreich ist oder nicht. Beachten Sie, dass, falls Substitute ausgeschaltet oder erst gar kein Substitut verfügbar ist, @emph{immer} eine lokale Erstellung durchgeführt wird, egal ob @code{--fallback} übergeben wurde oder nicht. Um eine Vorstellung zu bekommen, wieviele Substitute gerade verfügbar sind, können Sie den Befehl @command{guix weather} benutzen (siehe @ref{Aufruf von guix weather}). Dieser Befehl zeigt Statistiken darüber an, wie es um die von einem Server verfügbaren Substitute steht. @node Vom Vertrauen gegenüber Binärdateien @subsection Vom Vertrauen gegenüber Binärdateien @cindex Vertrauen, gegenüber vorerstellten Binärdateien Derzeit hängt die Kontrolle jedes Individuums über seine Rechner von Institutionen, Unternehmen und solchen Gruppierungen ab, die über genug Macht und Entschlusskraft verfügen, die Rechnerinfrastruktur zu sabotieren und ihre Schwachstellen auszunutzen. Auch wenn es bequem ist, Substitute von @code{@value{SUBSTITUTE-SERVER}} zu benutzen, ermuntern wir Nutzer, auch selbst Erstellungen durchzuführen oder gar ihre eigene Build-Farm zu betreiben, damit @code{@value{SUBSTITUTE-SERVER}} ein weniger interessantes Ziel wird. Eine Art, uns zu helfen, ist, die von Ihnen erstellte Software mit dem Befehl @command{guix publish} zu veröffentlichen, damit andere eine größere Auswahl haben, von welchem Server sie Substitute beziehen möchten (siehe @ref{Aufruf von guix publish}). Guix hat die richtigen Grundlagen, um die Reproduzierbarkeit von Erstellungen zu maximieren (siehe @ref{Funktionalitäten}). In den meisten Fällen sollten unabhängige Erstellungen eines bestimmten Pakets zu bitweise identischen Ergebnissen führen. Wir können also mit Hilfe einer vielschichtigen Menge an unabhängigen Paketerstellungen die Integrität unseres Systems besser gewährleisten. Der Befehl @command{guix challenge} hat das Ziel, Nutzern zu ermöglichen, Substitutserver zu beurteilen, und Entwickler dabei zu unterstützen, nichtdeterministische Paketerstellungen zu finden (siehe @ref{Aufruf von guix challenge}). Ebenso ermöglicht es die Befehlszeilenoption @option{--check} von @command{guix build}, dass Nutzer bereits installierte Substitute auf Echtheit zu prüfen, indem sie lokal nachgebaut werden (siehe @ref{build-check, @command{guix build --check}}). In Zukunft wollen wir, dass Guix Binärdateien an und von Nutzern peer-to-peer veröffentlichen kann. Wenn Sie mit uns dieses Projekt diskutieren möchten, kommen Sie auf unsere Mailing-Liste @email{guix-devel@@gnu.org}. @node Pakete mit mehreren Ausgaben. @section Pakete mit mehreren Ausgaben. @cindex mehrere Ausgaben, bei Paketen @cindex Paketausgaben @cindex Ausgaben Oft haben in Guix definierte Pakete eine einzige @dfn{Ausgabe} — d.h.@: aus dem Quellpaket entsteht genau ein Verzeichnis im Store. Wenn Sie @command{guix package -i glibc} ausführen, wird die Standard-Paketausgabe des GNU-libc-Pakets installiert; die Standardausgabe wird @code{out} genannt, aber ihr Name kann weggelassen werden, wie sie an obigem Befehl sehen. In diesem speziellen Fall enthält die Standard-Paketausgabe von @code{glibc} alle C-Headerdateien, gemeinsamen Bibliotheken (»Shared Libraries«), statischen Bibliotheken (»Static Libraries«), Dokumentation für Info sowie andere zusätzliche Dateien. Manchmal ist es besser, die verschiedenen Arten von Dateien, die aus einem einzelnen Quellpaket hervorgehen, in getrennte Ausgaben zu unterteilen. Zum Beispiel installiert die GLib-C-Bibliothek (die von GTK und damit zusammenhängenden Paketen benutzt wird) mehr als 20 MiB an HTML-Seiten mit Referenzdokumentation. Um den Nutzern, die das nicht brauchen, Platz zu sparen, wird die Dokumentation in einer separaten Ausgabe abgelegt, genannt @code{doc}. Um also die Hauptausgabe von GLib zu installieren, zu der alles außer der Dokumentation gehört, ist der Befehl: @example guix package -i glib @end example @cindex Dokumentation Der Befehl, um die Dokumentation zu installieren, ist: @example guix package -i glib:doc @end example Manche Pakete installieren Programme mit unterschiedlich großem »Abhängigkeiten-Fußabdruck«. Zum Beispiel installiert das Paket WordNet sowohl Befehlszeilenwerkzeuge als auch grafische Benutzerschnittstellen (GUIs). Erstere hängen nur von der C-Bibliothek ab, während Letztere auch von Tcl/Tk und den zu Grunde liegenden X-Bibliotheken abhängen. Jedenfalls belassen wir deshalb die Befehlszeilenwerkzeuge in der Standard-Paketausgabe, während sich die GUIs in einer separaten Ausgabe befinden. So können Benutzer, die die GUIs nicht brauchen, Platz sparen. Der Befehl @command{guix size} kann dabei helfen, solche Situationen zu erkennen (siehe @ref{Aufruf von guix size}). @command{guix graph} kann auch helfen (siehe @ref{Aufruf von guix graph}). In der GNU-Distribution gibt es viele solche Pakete mit mehreren Ausgaben. Andere Konventionen für Ausgabenamen sind zum Beispiel @code{lib} für Bibliotheken und eventuell auch ihre Header-Dateien,, @code{bin} für eigenständige Programme und @code{debug} für Informationen zur Fehlerbehandlung (siehe @ref{Dateien zur Fehlersuche installieren}). Die Ausgaben eines Pakets stehen in der dritten Spalte der Anzeige von @command{guix package --list-available} (siehe @ref{Aufruf von guix package}). @node Aufruf von guix gc @section @command{guix gc} aufrufen @cindex Müllsammler @cindex Plattenspeicher Pakete, die zwar installiert sind, aber nicht benutzt werden, können vom @dfn{Müllsammler} entfernt werden. Mit dem Befehl @command{guix gc} können Benutzer den Müllsammler ausdrücklich aufrufen, um Speicher im Verzeichnis @file{/gnu/store} freizugeben. Dies ist der @emph{einzige} Weg, Dateien aus @file{/gnu/store} zu entfernen — das manuelle Entfernen von Dateien kann den Store irreparabel beschädigen! @cindex GC-Wurzeln @cindex Müllsammlerwurzeln Der Müllsammler kennt eine Reihe von @dfn{Wurzeln}: Jede Datei in @file{/gnu/store}, die von einer Wurzel aus erreichbar ist, gilt als @dfn{lebendig} und kann nicht entfernt werden; jede andere Datei gilt als @dfn{tot} und ist ein Kandidat, gelöscht zu werden. Die Menge der Müllsammlerwurzeln (kurz auch »GC-Wurzeln«, von englisch »Garbage Collector«) umfasst Standard-Benutzerprofile; standardmäßig werden diese Müllsammlerwurzeln durch symbolische Verknüpfungen in @file{/var/guix/gcroots} dargestellt. Neue Müllsammlerwurzeln können zum Beispiel mit @command{guix build --root} festgelegt werden (siehe @ref{Aufruf von guix build}). Der Befehl @command{guix gc --list-roots} listet sie auf. Bevor Sie mit @code{guix gc --collect-garbage} Speicher freimachen, wollen Sie vielleicht alte Generationen von Benutzerprofilen löschen, damit alte Paketerstellungen von diesen Generationen entfernt werden können. Führen Sie dazu @code{guix package --delete-generations} aus (siehe @ref{Aufruf von guix package}). Unsere Empfehlung ist, dass Sie den Müllsammler regelmäßig laufen lassen und wenn Sie wenig freien Speicherplatz zur Verfügung haben. Um zum Beispiel sicherzustellen, dass Sie mindestens 5@tie{}GB auf Ihrer Platte zur Verfügung haben, benutzen Sie einfach: @example guix gc -F 5G @end example Es ist völlig sicher, dafür eine nicht interaktive, regelmäßige Auftragsausführung vorzugeben (siehe @ref{Geplante Auftragsausführung} für eine Erklärung, wie man das tun kann). @command{guix gc} ohne Befehlszeilenargumente auszuführen, lässt so viel Müll wie möglich sammeln, aber das ist oft nicht, was man will, denn so muss man unter Umständen Software erneut erstellen oder erneut herunterladen, weil der Müllsammler sie als »tot« ansieht, sie aber zur Erstellung anderer Software wieder gebraucht wird — das trifft zum Beispiel auf die Compiler-Toolchain zu. Der Befehl @command{guix gc} hat drei Arbeitsmodi: Er kann benutzt werden, um als Müllsammler tote Dateien zu entfernen (das Standardverhalten), um ganz bestimmte, angegebene Datein zu löschen (mit der Befehlszeilenoption @code{--delete}), um Müllsammlerinformationen auszugeben oder fortgeschrittenere Anfragen zu verarbeiten. Die Müllsammler-Befehlszeilenoptionen sind wie folgt: @table @code @item --collect-garbage[=@var{Minimum}] @itemx -C [@var{Minimum}] Lässt Müll sammeln — z.B.@: nicht erreichbare Dateien in @file{/gnu/store} und seinen Unterverzeichnissen. Wird keine andere Befehlszeilenoption angegeben, wird standardmäßig diese durchgeführt. Wenn ein @var{Minimum} angegeben wurde, hört der Müllsammler auf, sobald @var{Minimum} Bytes gesammelt wurden. Das @var{Minimum} kann die Anzahl der Bytes bezeichnen oder mit einer Einheit als Suffix versehen sein, wie etwa @code{MiB} für Mebibytes und @code{GB} für Gigabytes (siehe @ref{Block size, size specifications,, coreutils, GNU Coreutils}). Wird kein @var{Minimum} angegeben, sammelt der Müllsammler allen Müll. @item --free-space=@var{Menge} @itemx -F @var{Menge} Sammelt Müll, bis die angegebene @var{Menge} an freiem Speicher in @file{/gnu/store} zur Verfügung steht, falls möglich; die @var{Menge} ist eine Speichergröße wie @code{500MiB}, wie oben beschrieben. Wenn die angegebene @var{Menge} oder mehr bereits in @file{/gnu/store} frei verfügbar ist, passiert nichts. @item --delete-generations[=@var{Dauer}] @itemx -d [@var{Dauer}] Bevor der Müllsammelvorgang beginnt, werden hiermit alle Generationen von allen Benutzerprofilen gelöscht, die älter sind als die angegebene @var{Dauer}; wird es als Administratornutzer »root« ausgeführt, geschieht dies mit den Profilen @emph{von allen Benutzern}. Zum Beispiel löscht der folgende Befehl alle Generationen Ihrer Profile, die älter als zwei Monate sind (ausgenommen die momentanen Generationen), und schmeißt dann den Müllsammler an, um Platz freizuräumen, bis mindestens 10 GiB verfügbar sind: @example guix gc -d 2m -F 10G @end example @item --delete @itemx -D Versucht, alle als Argumente angegebenen Dateien oder Verzeichnisse im Store zu löschen. Dies schlägt fehl, wenn manche der Dateien oder Verzeichnisse nicht im Store oder noch immer lebendig sind. @item --list-failures Store-Objekte auflisten, die zwischengespeicherten Erstellungsfehlern entsprechen. Hierbei wird nichts ausgegeben, sofern der Daemon nicht mit @option{--cache-failures} gestartet wurde (siehe @ref{Aufruf des guix-daemon, @option{--cache-failures}}). @item --list-roots Die Müllsammlerwurzeln auflisten, die dem Nutzer gehören. Wird der Befehl als Administratornutzer ausgeführt, werden @emph{alle} Müllsammlerwurzeln aufgelistet. @item --clear-failures Die angegebenen Store-Objekte aus dem Zwischenspeicher für fehlgeschlagene Erstellungen entfernen. Auch diese Option macht nur Sinn, wenn der Daemon mit @option{--cache-failures} gestartet wurde. Andernfalls passiert nichts. @item --list-dead Zeigt die Liste toter Dateien und Verzeichnisse an, die sich noch im Store befinden — das heißt, Dateien, die von keiner Wurzel mehr erreichbar sind. @item --list-live Zeige die Liste lebendiger Store-Dateien und -Verzeichnisse. @end table Außerdem können Referenzen unter bestehenden Store-Dateien gefunden werden: @table @code @item --references @itemx --referrers @cindex Paketabhängigkeiten Listet die referenzierten bzw. sie referenzierenden Objekte der angegebenen Store-Dateien auf. @item --requisites @itemx -R @cindex Abschluss Listet alle Voraussetzungen der als Argumente übergebenen Store-Dateien auf. Voraussetzungen sind die Store-Dateien selbst, ihre Referenzen sowie die Referenzen davon, rekursiv. Mit anderen Worten, die zurückgelieferte Liste ist der @dfn{transitive Abschluss} dieser Store-Dateien. Der Abschnitt @ref{Aufruf von guix size} erklärt ein Werkzeug, um den Speicherbedarf des Abschlusses eines Elements zu ermitteln. Siehe @ref{Aufruf von guix graph} für ein Werkzeug, um den Referenzgraphen zu veranschaulichen. @item --derivers @cindex Ableitung Liefert die Ableitung(en), die zu den angegebenen Store-Objekten führen (siehe @ref{Ableitungen}). Zum Beispiel liefert dieser Befehl: @example guix gc --derivers `guix package -I ^emacs$ | cut -f4` @end example @noindent die @file{.drv}-Datei(en), die zum in Ihrem Profil installierten @code{emacs}-Paket führen. Beachten Sie, dass es auch sein kann, dass keine passenden @file{.drv}-Dateien existieren, zum Beispiel wenn diese Dateien bereits dem Müllsammler zum Opfer gefallen sind. Es kann auch passieren, dass es mehr als eine passende @file{.drv} gibt, bei Ableitungen mit fester Ausgabe. @end table Zuletzt können Sie mit folgenden Befehlszeilenoptionen die Integrität des Stores prüfen und den Plattenspeicherverbrauch im Zaum halten. @table @option @item --verify[=@var{Optionen}] @cindex Integrität, des Stores @cindex Integritätsprüfung Die Integrität des Stores verifizieren Standardmäßig wird sichergestellt, dass alle Store-Objekte, die in der Datenbank des Daemons als gültig markiert wurden, auch tatsächlich in @file{/gnu/store} existieren. Wenn angegeben, müssen die @var{Optionen} eine kommagetrennte Liste aus mindestens einem der Worte @code{contents} und @code{repair} sein. Wenn Sie @option{--verify=contents} übergeben, berechnet der Daemon den Hash des Inhalts jedes Store-Objekts und vergleicht ihn mit dem Hash in der Datenbank. Sind die Hashes ungleich, wird eine Datenbeschädigung gemeldet. Weil dabei @emph{alle Dateien im Store} durchlaufen werden, kann der Befehl viel Zeit brauchen, besonders auf Systemen mit langsamer Platte. @cindex Store, reparieren @cindex Datenbeschädigung, Behebung Mit @option{--verify=repair} oder @option{--verify=contents,repair} versucht der Daemon, beschädigte Store-Objekte zu reparieren, indem er Substitute für selbige herunterlädt (siehe @ref{Substitute}). Weil die Reparatur nicht atomar und daher womöglich riskant ist, kann nur der Systemadministrator den Befehl benutzen. Eine weniger aufwendige Alternative, wenn Sie wissen, welches Objekt beschädigt ist, ist, @command{guix build --repair} zu benutzen (siehe @ref{Aufruf von guix build}). @item --optimize @cindex Deduplizieren Den Store durch Nutzung harter Verknüpfungen für identische Dateien optimieren — mit anderen Worten wird der Store @dfn{dedupliziert}. Der Daemon führt Deduplizierung automatisch nach jeder erfolgreichen Erstellung und jedem Importieren eines Archivs durch, sofern er nicht mit @code{--disable-deduplication} (siehe @ref{Aufruf des guix-daemon, @code{--disable-deduplication}}) gestartet wurde. Diese Befehlszeilenoption brauchen Sie also in erster Linie dann, wenn der Daemon zuvor mit @code{--disable-deduplication} gestartet worden ist. @end table @node Aufruf von guix pull @section @command{guix pull} aufrufen @cindex Aktualisieren von Guix @cindex Updaten von Guix @cindex @command{guix pull} @cindex pull Nach der Installation oder Aktualisierung wird stets die neueste Version von Paketen verwendet, die in der aktuell installierten Distribution verfügbar ist. Um die Distribution und die Guix-Werkzeuge zu aktualisieren, führen Sie @command{guix pull} aus. Der Befehl lädt den neuesten Guix-Quellcode einschließlich Paketbeschreibungen herunter und installiert ihn. Quellcode wird aus einem @uref{https://git-scm.com, Git}-Repository geladen, standardmäßig dem offiziellen Repository von GNU@tie{}Guix, was Sie aber auch ändern können. Danach wird @command{guix package} Pakete und ihre Versionen entsprechend der gerade heruntergeladenen Kopie von Guix benutzen. Nicht nur das, auch alle Guix-Befehle und Scheme-Module werden aus der neuesten Version von Guix kommen. Neue @command{guix}-Unterbefehle, die durch die Aktualisierung hinzugekommen sind, werden also auch verfügbar. Jeder Nutzer kann seine Kopie von Guix mittels @command{guix pull} aktualisieren, wodurch sich nur für den Nutzer etwas verändert, der @command{guix pull} ausgeführt hat. Wenn also zum Beispiel der Administratornutzer @code{root} den Befehl @command{guix pull} ausführt, hat das keine Auswirkungen auf die für den Benutzer @code{alice} sichtbare Guix-Version, und umgekehrt. Das Ergebnis von @command{guix pull} ist ein als @file{~/.config/guix/current} verfügbares @dfn{Profil} mit dem neuesten Guix. Stellen Sie sicher, dass es am Anfang Ihres Suchpfades steht, damit Sie auch wirklich das neueste Guix und sein Info-Handbuch sehen (siehe @ref{Dokumentation}): @example export PATH="$HOME/.config/guix/current/bin:$PATH" export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH" @end example Die Befehlszeilenoption @code{--list-generations} oder kurz @code{-l} listet ältere von @command{guix pull} erzeugte Generationen auf, zusammen mit Informationen zu deren Provenienz. @example $ guix pull -l Generation 1 Jun 10 2018 00:18:18 guix 65956ad repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe Generation 2 Jun 11 2018 11:02:49 guix e0cc7f6 repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d 2 new packages: keepalived, libnfnetlink 6 packages upgraded: emacs-nix-mode@@2.0.4, guile2.0-guix@@0.14.0-12.77a1aac, guix@@0.14.0-12.77a1aac, heimdal@@7.5.0, milkytracker@@1.02.00, nix@@2.0.4 Generation 3 Jun 13 2018 23:31:07 (current) guix 844cc1c repository URL: https://git.savannah.gnu.org/git/guix.git branch: origin/master commit: 844cc1c8f394f03b404c5bb3aee086922373490c 28 new packages: emacs-helm-ls-git, emacs-helm-mu, @dots{} 69 packages upgraded: borg@@1.1.6, cheese@@3.28.0, @dots{} @end example Im Abschnitt @ref{Aufruf von guix describe, @command{guix describe}} werden andere Möglichkeiten erklärt, sich den momentanen Zustand von Guix beschreiben zu lassen. Das Profil @code{~/.config/guix/current} verhält sich genau wie jedes andere Profil, das von @command{guix package} erzeugt wurde (siehe @ref{Aufruf von guix package}). Das bedeutet, Sie können seine Generationen auflisten und es auf die vorherige Generation — also das vorherige Guix — zurücksetzen und so weiter: @example $ guix package -p ~/.config/guix/current --roll-back switched from generation 3 to 2 $ guix package -p ~/.config/guix/current --delete-generations=1 deleting /var/guix/profiles/per-user/charlie/current-guix-1-link @end example Der Befehl @command{guix pull} wird in der Regel ohne Befehlszeilenargumente aufgerufen, aber er versteht auch folgende Befehlszeilenoptionen: @table @code @item --url=@var{URL} @itemx --commit=@var{Commit} @itemx --branch=@var{Branch} Download code for the @code{guix} channel from the specified @var{url}, at the given @var{commit} (a valid Git commit ID represented as a hexadecimal string), or @var{branch}. @cindex @file{channels.scm}, Konfigurationsdatei @cindex Konfigurationsdatei für Kanäle Diese Befehlszeilenoptionen sind manchmal bequemer, aber Sie können Ihre Konfiguration auch in der Datei @file{~/.config/guix/channels.scm} oder über die Option @option{--channels} angeben (siehe unten). @item --channels=@var{Datei} @itemx -C @var{Datei} Die Liste der Kanäle aus der angegebenen @var{Datei} statt aus @file{~/.config/guix/channels.scm} auslesen. Die @var{Datei} muss Scheme-Code enthalten, der zu einer Liste von Kanalobjekten ausgewertet wird. Siehe @ref{Kanäle} für nähere Informationen. @item --list-generations[=@var{Muster}] @itemx -l [@var{Muster}] Alle Generationen von @file{~/.config/guix/current} bzw., wenn ein @var{Muster} angegeben wird, die dazu passenden Generationen auflisten. Die Syntax für das @var{Muster} ist dieselbe wie bei @code{guix package --list-generations} (siehe @ref{Aufruf von guix package}). Im Abschnitt @ref{Aufruf von guix describe, @command{guix describe}} wird eine Möglichkeit erklärt, sich Informationen nur über die aktuelle Generation anzeigen zu lassen. @item --profile=@var{Profil} @itemx -p @var{Profil} Auf @var{Profil} anstelle von @file{~/.config/guix/current} arbeiten. @item --dry-run @itemx -n Anzeigen, welche(r) Commit(s) für die Kanäle benutzt würde(n) und was jeweils erstellt oder substituiert würde, ohne es tatsächlich durchzuführen. @item --system=@var{System} @itemx -s @var{System} Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die Erstellung durchführt. @item --verbose Ausführliche Informationen ausgeben und Erstellungsprotokolle auf der Standardfehlerausgabe ausgeben. @item --bootstrap Das neueste Guix mit dem Bootstrap-Guile erstellen. Diese Befehlszeilenoption ist nur für Guix-Entwickler von Nutzen. @end table Mit Hilfe von @dfn{Kanälen} können Sie bei @command{guix pull} anweisen, von welchem Repository und welchem Branch Guix aktualisiert werden soll, sowie von welchen @emph{weiteren} Repositorys Paketmodule bezogen werden sollen. Im Abschnitt @ref{Kanäle} finden Sie nähere Informationen. Außerdem unterstützt @command{guix pull} alle gemeinsamen Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}). @node Kanäle @section Kanäle @cindex Kanäle @cindex @file{channels.scm}, Konfigurationsdatei @cindex Konfigurationsdatei für Kanäle @cindex @command{guix pull}, Konfigurationsdatei @cindex Konfiguration von @command{guix pull} Guix und die Sammlung darin verfügbarer Pakete können Sie durch Ausführen von @command{guix pull} aktualisieren (siehe @ref{Aufruf von guix pull}). Standardmäßig lädt @command{guix pull} Guix selbst vom offiziellen Repository von GNU@tie{}Guix herunter und installiert es. Diesen Vorgang können Sie anpassen, indem Sie @dfn{Kanäle} in der Datei @file{~/.config/guix/channels.scm} angeben. Ein Kanal enthält eine Angabe einer URL und eines Branches eines zu installierenden Git-Repositorys und Sie können @command{guix pull} veranlassen, die Aktualisierungen von einem oder mehreren Kanälen zu beziehen. Mit anderen Worten können Kanäle benutzt werden, um Guix @emph{anzupassen} und zu @emph{erweitern}, wie wir im Folgenden sehen werden. @subsection Einen eigenen Guix-Kanal benutzen Der Kanal namens @code{guix} gibt an, wovon Guix selbst — seine Befehlszeilenwerkzeuge und seine Paketsammlung — heruntergeladen werden sollten. Wenn Sie zum Beispiel mit Ihrer eigenen Kopie des Guix-Repositorys arbeiten möchten und diese auf @code{example.org} zu finden ist, und zwar im Branch namens @code{super-hacks}, dann schreiben Sie folgende Spezifikation in @code{~/.config/guix/channels.scm}: @lisp ;; 'guix pull' mein eigenes Repository benutzen lassen. (list (channel (name 'guix) (url "https://example.org/my-guix.git") (branch "super-hacks"))) @end lisp @noindent Ab dann wird @command{guix pull} seinen Code vom Branch @code{super-hacks} des Repositorys auf @code{example.org} beziehen. @subsection Weitere Kanäle angeben @cindex Paketsammlung erweitern (Kanäle) @cindex Eigene Pakete (Kanäle) @cindex Kanäle, für eigene Pakete Sie können auch @emph{weitere Kanäle} als Bezugsquelle angeben. Sagen wir, Sie haben ein paar eigene Paketvarianten oder persönliche Pakete, von denen Sie meinen, dass sie @emph{nicht} geeignet sind, ins Guix-Projekt selbst aufgenommen zu werden, die Ihnen aber dennoch wie andere Pakete auf der Befehlszeile zur Verfügung stehen sollen. Dann würden Sie zunächst Module mit diesen Paketdefinitionen schreiben (siehe @ref{Paketmodule}) und diese dann in einem Git-Repository verwalten, welches Sie selbst oder jeder andere dann als zusätzlichen Kanal eintragen können, von dem Pakete geladen werden. Klingt gut, oder? @c What follows stems from discussions at @c as well as @c earlier discussions on guix-devel@gnu.org. @quotation Warnung Bevor Sie, verehrter Nutzer, ausrufen: »Wow, das ist @emph{soooo coool}!«, und Ihren eigenen Kanal der Welt zur Verfügung stellen, möchten wir Ihnen auch ein paar Worte der Warnung mit auf den Weg geben: @itemize @item Bevor Sie einen Kanal veröffentlichen, überlegen Sie sich bitte erst, ob Sie die Pakete nicht besser zum eigentlichen Guix-Projekt beisteuern (siehe @ref{Mitwirken}). Das Guix-Projekt ist gegenüber allen Arten freier Software offen und zum eigentlichen Guix gehörende Pakete stehen allen Guix-Nutzern zur Verfügung, außerdem profitieren sie von Guix’ Qualitätssicherungsprozess. @item Wenn Sie Paketdefinitionen außerhalb von Guix betreuen, sehen wir Guix-Entwickler es als @emph{Ihre Aufgabe an, deren Kompatibilität sicherzstellen}. Bedenken Sie, dass Paketmodule und Paketdefinitionen nur Scheme-Code sind, der verschiedene Programmierschnittstellen (APIs) benutzt. Wir nehmen uns das Recht heraus, diese APIs jederzeit zu ändern, damit wir Guix besser machen können, womöglich auf eine Art, wodurch Ihr Kanal nicht mehr funktioniert. Wir ändern APIs nie einfach so, werden aber auch @emph{nicht} versprechen, APIs nicht zu verändern. @item Das bedeutet auch, dass Sie, wenn Sie einen externen Kanal verwenden und dieser kaputt geht, Sie dies bitte @emph{den Autoren des Kanals} und nicht dem Guix-Projekt melden. @end itemize Wir haben Sie gewarnt! Allerdings denken wir auch, dass externe Kanäle eine praktische Möglichkeit sind, die Paketsammlung von Guix zu ergänzen und Ihre Verbesserungen mit anderen zu teilen, wie es dem Grundgedanken @uref{https://www.gnu.org/philosophy/free-sw.html, freier Software} entspricht. Bitte schicken Sie eine E-Mail an @email{guix-devel@@gnu.org}, wenn Sie dies diskutieren möchten. @end quotation Um einen Kanal zu benutzen, tragen Sie ihn in @code{~/.config/guix/channels.scm} ein, damit @command{guix pull} diesen Kanal @emph{zusätzlich} zu den standardmäßigen Guix-Kanälen als Paketquelle verwendet: @vindex %default-channels @lisp ;; Meine persönlichen Pakete zu denen von Guix dazunehmen. (cons (channel (name 'meine-persönlichen-pakete) (url "https://example.org/personal-packages.git")) %default-channels) @end lisp @noindent Beachten Sie, dass der obige Schnipsel (wie immer!)@: Scheme-Code ist; mit @code{cons} fügen wir einen Kanal zur Liste der Kanäle hinzu, an die die Variable @code{%default-channels} gebunden ist (siehe @ref{Pairs, @code{cons} and lists,, guile, GNU Guile Reference Manual}). Mit diesem Dateiinhalt wird @command{guix pull} nun nicht mehr nur Guix, sondern auch die Paketmodule aus Ihrem Repository erstellen. Das Ergebnis in @file{~/.config/guix/current} ist so die Vereinigung von Guix und Ihren eigenen Paketmodulen. @example $ guix pull --list-generations @dots{} Generation 19 Aug 27 2018 16:20:48 guix d894ab8 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300 meine-persönlichen-pakete dd3df5e repository URL: https://example.org/personal-packages.git branch: master commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb 11 new packages: mein-gimp, mein-emacs-mit-coolen-features, @dots{} 4 packages upgraded: emacs-racket-mode@@0.0.2-2.1b78827, @dots{} @end example @noindent Obige Ausgabe von @command{guix pull} zeigt an, dass Generation@tie{}19 sowohl Guix als auch Pakete aus dem Kanal @code{meine-persönlichen-pakete} enthält. Unter den aufgeführten neuen und aktualisierten Paketen kommen vielleicht manche wie @code{mein-gimp} und @code{mein-emacs-mit-coolen-features} aus @code{meine-persönlichen-pakete}, während andere aus dem Standard-Guix-Kanal kommen. Um einen Kanal zu erzeugen, müssen Sie ein Git-Repository mit Ihren eigenen Paketmodulen erzeugen und den Zugriff darauf ermöglichen. Das Repository kann beliebigen Inhalt haben, aber wenn es ein nützlicher Kanal sein soll, muss es Guile-Module enthalten, die Pakete exportieren. Sobald Sie anfangen, einen Kanal zu benutzen, verhält sich Guix, als wäre das Wurzelverzeichnis des Git-Repositorys des Kanals in Guiles Ladepfad enthalten (siehe @ref{Load Paths,,, guile, GNU Guile Reference Manual}). Wenn Ihr Kanal also zum Beispiel eine Datei als @file{my-packages/my-tools.scm} enthält, die ein Guile-Modul definiert, dann wird das Modul unter dem Namen @code{(my-packages my-tools)} verfügbar sein und Sie werden es wie jedes andere Modul benutzen können (siehe @ref{Module,,, guile, GNU Guile Reference Manual}). @cindex Abhängigkeiten, bei Kanälen @cindex Metadaten, bei Kanälen @subsection Kanalabhängigkeiten deklarieren Kanalautoren können auch beschließen, die Paketsammlung von anderen Kanälen zu erweitern. Dazu können sie in einer Metadatendatei @file{.guix-channel} deklarieren, dass ihr Kanal von anderen Kanälen abhängt. Diese Datei muss im Wurzelverzeichnis des Kanal-Repositorys platziert werden. Die Metadatendatei sollte einen einfachen S-Ausdruck wie diesen enthalten: @lisp (channel (version 0) (dependencies (channel (name irgendeine-sammlung) (url "https://example.org/erste-sammlung.git")) (channel (name eine-andere-sammlung) (url "https://example.org/zweite-sammlung.git") (branch "testing")))) @end lisp Im Beispiel oben wird deklariert, dass dieser Kanal von zwei anderen Kanälen abhängt, die beide automatisch geladen werden. Die vom Kanal angebotenen Module werden in einer Umgebung kompiliert, in der die Module all dieser deklarierten Kanäle verfügbar sind. Um Verlässlichkeit und Wartbarkeit zu gewährleisten, sollen Sie darauf verzichten, eine Abhängigkeit von Kanälen herzustellen, die Sie nicht kontrollieren, außerdem sollten Sie sich auf eine möglichst kleine Anzahl von Abhängigkeiten beschränken. @subsection Guix nachbilden @cindex Festsetzen, bei Kanälen @cindex Nachbilden von Guix @cindex Reproduzierbarkeit von Guix Die Ausgabe von @command{guix pull --list-generations} oben zeigt genau, aus welchen Commits diese Guix-Instanz erstellt wurde. Wir können Guix so zum Beispiel auf einer anderen Maschine nachbilden, indem wir eine Kanalspezifikation in @file{~/.config/guix/channels.scm} angeben, die auf diese Commits »festgesetzt« ist. @lisp ;; Ganz bestimmte Commits der relevanten Kanäle installieren. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300")) (channel (name 'meine-persönlichen-pakete) (url "https://example.org/personal-packages.git") (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb"))) @end lisp Der Befehl @command{guix describe --format=channels} kann diese Kanalliste sogar direkt erzeugen (siehe @ref{Aufruf von guix describe}). Somit läuft auf beiden Maschinen @emph{genau dasselbe Guix} und es hat Zugang zu @emph{genau denselben Paketen}. Die Ausgabe von @command{guix build gimp} auf der einen Maschine wird Bit für Bit genau dieselbe wie die desselben Befehls auf der anderen Maschine sein. Das bedeutet auch, dass beide Maschinen Zugang zum gesamten Quellcode von Guix und daher auch transitiv Zugang zum Quellcode jedes davon definierten Pakets haben. Das verleiht Ihnen Superkräfte, mit denen Sie die Provenienz binärer Artefakte sehr feinkörnig nachverfolgen können und Software-Umgebungen nach Belieben nachbilden können. Sie können es als eine Art Fähigkeit zur »Meta-Reproduzierbarkeit« auffassen, wenn Sie möchten. Der Abschnitt @ref{Untergeordnete} beschreibt eine weitere Möglichkeit, diese Superkräfte zu nutzen. @node Untergeordnete @section Untergeordnete @c TODO: Remove this once we're more confident about API stability. @quotation Anmerkung Die hier beschriebenen Funktionalitäten sind in der Version @value{VERSION} bloß eine »Technologie-Vorschau«, daher kann sich die Schnittstelle in Zukunft noch ändern. @end quotation @cindex Untergeordnete @cindex Mischen von Guix-Versionen Manchmal könnten Sie Pakete aus der gerade laufenden Fassung von Guix mit denen mischen wollen, die in einer anderen Guix-Version verfügbar sind. Guix-@dfn{Untergeordnete} ermöglichen dies, indem Sie verschiedene Guix-Versionen beliebig mischen können. @cindex untergeordnete Pakete Aus technischer Sicht ist ein »Untergeordneter« im Kern ein separater Guix-Prozess, der über eine REPL (siehe @ref{Aufruf von guix repl}) mit Ihrem Haupt-Guix-Prozess verbunden ist. Das Modul @code{(guix inferior)} ermöglicht es Ihnen, Untergeordnete zu erstellen und mit ihnen zu kommunizieren. Dadurch steht Ihnen auch eine hochsprachliche Schnittstelle zur Verfügung, um die von einem Untergeordneten angebotenen Pakete zu durchsuchen und zu verändern — @dfn{untergeordnete Pakete}. In Kombination mit Kanälen (siehe @ref{Kanäle}) bieten Untergeordnete eine einfache Möglichkeit, mit einer anderen Version von Guix zu interagieren. Nehmen wir zum Beispiel an, Sie wollen das aktuelle @code{guile}-Paket in Ihr Profil installieren, zusammen mit dem @code{guile-json}, wie es in einer früheren Guix-Version existiert hat — vielleicht weil das neuere @code{guile-json} eine inkompatible API hat und Sie daher Ihren Code mit der alten API benutzen möchten. Dazu könnten Sie ein Manifest für @code{guix package --manifest} schreiben (siehe @ref{Aufruf von guix package}); in diesem Manifest würden Sie einen Untergeordneten für diese alte Guix-Version erzeugen, für die Sie sich interessieren, und aus diesem Untergeordneten das @code{guile-json}-Paket holen: @lisp (use-modules (guix inferior) (guix channels) (srfi srfi-1)) ;für die Prozedur 'first' (define channels ;; Dies ist die alte Version, aus der wir ;; guile-json extrahieren möchten. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) (define inferior ;; Ein Untergeordneter, der obige Version repräsentiert. (inferior-for-channels channels)) ;; Daraus erzeugen wir jetzt ein Manifest mit dem aktuellen ;; »guile«-Paket und dem alten »guile-json«-Paket. (packages->manifest (list (first (lookup-inferior-packages inferior "guile-json")) (specification->package "guile"))) @end lisp Bei seiner ersten Ausführung könnte für @command{guix package --manifest} erst der angegebene Kanal erstellt werden müssen, bevor der Untergeordnete erstellt werden kann; nachfolgende Durchläufe sind wesentlich schneller, weil diese Guix-Version bereits zwischengespeichert ist. Folgende Prozeduren werden im Modul @code{(guix inferior)} angeboten, um einen Untergeordneten zu öffnen: @deffn {Scheme-Prozedur} inferior-for-channels @var{Kanäle} @ [#:cache-directory] [#:ttl] Liefert einen Untergeordneten für die @var{Kanäle}, einer Liste von Kanälen. Dazu wird der Zwischenspeicher im Verzeichnis @var{cache-directory} benutzt, dessen Einträge nach @var{ttl} Sekunden gesammelt werden dürfen. Mit dieser Prozedur wird eine neue Verbindung zum Erstellungs-Daemon geöffnet. Als Nebenwirkung erstellt oder substituiert diese Prozedur unter Umständen Binärdateien für die @var{Kanäle}, was einige Zeit in Anspruch nehmen kann. @end deffn @deffn {Scheme-Prozedur} open-inferior @var{Verzeichnis} @ [#:command "bin/guix"] Öffnet das untergeordnete Guix mit dem Befehl @var{command} im angegebenen @var{Verzeichnis} durch Ausführung von @code{@var{Verzeichnis}/@var{command} repl} oder entsprechend. Liefert @code{#f}, wenn der Untergeordnete nicht gestartet werden konnte. @end deffn @cindex untergeordnete Pakete Die im Folgenden aufgeführten Prozeduren ermöglichen es Ihnen, untergeordnete Pakete abzurufen und zu verändern. @deffn {Scheme-Prozedur} inferior-packages @var{Untergeordneter} Liefert die Liste der Pakete in @var{Untergeordneter}. @end deffn @deffn {Scheme-Prozedur} lookup-inferior-packages @var{Untergeordneter} @var{Name} @ [@var{Version}] Liefert die sortierte Liste der untergeordneten Pakete in @var{Untergeordneter}, die zum Muster @var{Name} in @var{Untergeordneter} passen, dabei kommen höhere Versionsnummern zuerst. Wenn @var{Version} auf wahr gesetzt ist, werden nur Pakete geliefert, deren Versionsnummer mit dem Präfix @var{Version} beginnt. @end deffn @deffn {Scheme-Prozedur} inferior-package? @var{Objekt} Liefert wahr, wenn das @var{obj} ein Untergeordneter ist. @end deffn @deffn {Scheme-Prozedur} inferior-package-name @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-version @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-synopsis @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-description @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-home-page @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-location @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-inputs @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-native-inputs @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-propagated-inputs @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-transitive-propagated-inputs @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-native-search-paths @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-transitive-native-search-paths @var{Paket} @deffnx {Scheme-Prozedur} inferior-package-search-paths @var{Paket} Diese Prozeduren sind das Gegenstück zu den Zugriffsmethoden des Verbunds »package« für Pakete (siehe @ref{»package«-Referenz}). Die meisten davon funktionieren durch eine Abfrage auf dem Untergeordneten, von dem das @var{Paket} kommt, weshalb der Untergeordnete noch lebendig sein muss, wenn Sie diese Prozeduren aufrufen. @end deffn Untergeordnete Pakete können transparent wie jedes andere Paket oder dateiartige Objekt in G-Ausdrücken verwendet werden (siehe @ref{G-Ausdrücke}). Sie werden auch transparent wie reguläre Pakete von der Prozedur @code{packages->manifest} behandelt, welche oft in Manifesten benutzt wird (siehe @ref{Aufruf von guix package, siehe die Befehlszeilenoption @option{--manifest} von @command{guix package}}). Somit können Sie ein untergeordnetes Paket ziemlich überall dort verwenden, wo Sie ein reguläres Paket einfügen würden: in Manifesten, im Feld @code{packages} Ihrer @code{operating-system}-Deklaration und so weiter. @node Aufruf von guix describe @section @command{guix describe} aufrufen @cindex Reproduzierbarkeit @cindex Nachbilden von Guix Sie könnten sich des Öfteren Fragen stellen wie: »Welche Version von Guix benutze ich gerade?« oder »Welche Kanäle benutze ich?« Diese Informationen sind in vielen Situationen nützlich: wenn Sie eine Umgebung auf einer anderen Maschine oder mit einem anderen Benutzerkonto @emph{nachbilden} möchten, wenn Sie einen Fehler melden möchten, wenn Sie festzustellen versuchen, welche Änderung an den von Ihnen verwendeten Kanälen diesen Fehler verursacht hat, oder wenn Sie Ihren Systemzustand zum Zweck der Reproduzierbarkeit festhalten möchten. Der Befehl @command{guix describe} gibt Ihnen Antwort auf diese Fragen. Wenn Sie ihn aus einem mit @command{guix pull} bezogenen @command{guix} heraus ausführen, zeigt Ihnen @command{guix describe} die Kanäle an, aus denen es erstellt wurde, jeweils mitsamt ihrer Repository-URL und Commit-ID (siehe @ref{Kanäle}): @example $ guix describe Generation 10 Sep 03 2018 17:32:44 (current) guix e0fa68c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e0fa68c7718fffd33d81af415279d6ddb518f727 @end example Wenn Sie mit dem Versionskontrollsystem Git vertraut sind, erkennen Sie vielleicht die Ähnlichkeit zu @command{git describe}; die Ausgabe ähnelt auch der von @command{guix pull --list-generations} eingeschränkt auf die aktuelle Generation (siehe @ref{Aufruf von guix pull, die Befehlszeilenoption @option{--list-generations}}). Weil die oben gezeigte Git-Commit-ID eindeutig eine bestimmte Version von Guix bezeichnet, genügt diese Information, um die von Ihnen benutzte Version von Guix zu beschreiben, und auch, um sie nachzubilden. Damit es leichter ist, Guix nachzubilden, kann Ihnen @command{guix describe} auch eine Liste der Kanäle statt einer menschenlesbaren Beschreibung wie oben liefern: @example $ guix describe -f channels (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "e0fa68c7718fffd33d81af415279d6ddb518f727"))) @end example @noindent Sie können die Ausgabe in einer Datei speichern, die Sie an @command{guix pull -C} auf einer anderen Maschine oder zu einem späteren Zeitpunkt übergeben, wodurch dann eine Instanz @emph{von genau derselben Guix-Version} installiert wird (siehe @ref{Aufruf von guix pull, die Befehlszeilenoption @option{-C}}). Daraufhin können Sie, weil Sie jederzeit dieselbe Version von Guix installieren können, auch gleich @emph{eine vollständige Softwareumgebung genau nachbilden}. Wir halten das trotz aller Bescheidenheit für @emph{klasse} und hoffen, dass Ihnen das auch gefällt! Die genauen Befehlszeilenoptionen, die @command{guix describe} unterstützt, lauten wie folgt: @table @code @item --format=@var{Format} @itemx -f @var{Format} Die Ausgabe im angegebenen @var{Format} generieren, was eines der Folgenden sein muss: @table @code @item human für menschenlesbare Ausgabe, @item Kanäle eine Liste von Kanalspezifikationen erzeugen, die an @command{guix pull -C} übergeben werden oder als @file{~/.config/guix/channels.scm} eingesetzt werden können (siehe @ref{Aufruf von guix pull}), @item json @cindex JSON generiert eine Liste von Kanalspezifikationen im JSON-Format, @item recutils generiert eine Liste von Kanalspezifikationen im Recutils-Format. @end table @item --profile=@var{Profil} @itemx -p @var{Profil} Informationen über das @var{Profil} anzeigen. @end table @node Aufruf von guix archive @section @command{guix archive} aufrufen @cindex @command{guix archive} @cindex Archivdateien Der Befehl @command{guix archive} ermöglicht es Nutzern, Dateien im Store in eine einzelne Archivdatei zu @dfn{exportieren} und diese später auf einer Maschine, auf der Guix läuft, zu @dfn{importieren}. Insbesondere können so Store-Objekte von einer Maschine in den Store einer anderen Maschine übertragen werden. @quotation Anmerkung Wenn Sie nach einer Möglichkeit suchen, Archivdateien für andere Werkzeuge als Guix zu erstellen, finden Sie Informationen dazu im Abschnitt @ref{Aufruf von guix pack}. @end quotation @cindex Store-Objekte exportieren Führen Sie Folgendes aus, um Store-Dateien als ein Archiv auf die Standardausgabe zu exportieren: @example guix archive --export @var{Optionen} @var{Spezifikationen}... @end example @var{Spezifikationen} sind dabei entweder die Namen von Store-Dateien oder Paketspezifikationen wie bei @command{guix package} (siehe @ref{Aufruf von guix package}). Zum Beispiel erzeugt der folgende Befehl ein Archiv der @code{gui}-Ausgabe des Pakets @code{git} sowie die Hauptausgabe von @code{emacs}: @example guix archive --export git:gui /gnu/store/...-emacs-24.3 > groß.nar @end example Wenn die angegebenen Pakete noch nicht erstellt worden sind, werden sie durch @command{guix archive} automatisch erstellt. Der Erstellungsprozess kann durch die gemeinsamen Erstellungsoptionen gesteuert werden (siehe @ref{Gemeinsame Erstellungsoptionen}). Um das @code{emacs}-Paket auf eine über SSH verbundene Maschine zu übertragen, würde man dies ausführen: @example guix archive --export -r emacs | ssh die-maschine guix archive --import @end example @noindent Auf gleiche Art kann auch ein vollständiges Benutzerprofil von einer Maschine auf eine andere übertragen werden: @example guix archive --export -r $(readlink -f ~/.guix-profile) | \ ssh die-maschine guix-archive --import @end example @noindent Jedoch sollten Sie in beiden Beispielen beachten, dass alles, was zu @code{emacs}, dem Profil oder deren Abhängigkeiten (wegen @code{-r}) gehört, übertragen wird, egal ob es schon im Store der Zielmaschine vorhanden ist oder nicht. Mit der Befehlszeilenoption @code{--missing} lässt sich herausfinden, welche Objekte im Ziel-Store noch fehlen. Der Befehl @command{guix copy} vereinfacht und optimiert diesen gesamten Prozess, ist also, was Sie in diesem Fall wahrscheinlich eher benutzen wollten (siehe @ref{Aufruf von guix copy}). @cindex Nar, Archivformat @cindex Normalisiertes Archiv (Nar) Archive werden als »Normalisiertes Archiv«, kurz »Nar«, formatiert. Diese Technik folgt einem ähnlichen Gedanken wie beim »tar«-Format, unterscheidet sich aber auf eine für unsere Zwecke angemessene Art. Erstens werden im Nar-Format nicht sämtliche Unix-Metadaten aller Dateien aufgenommen, sondern nur der Dateityp (ob es sich um eine reguläre Datei, ein Verzeichnis oder eine symbolische Verknüpfung handelt). Unix-Dateiberechtigungen sowie Besitzer und Gruppe werden nicht gespeichert. Zweitens entspricht die Reihenfolge, in der der Inhalt von Verzeichnissen abgelegt wird, immer der Reihenfolge, in der die Dateinamen gemäß der C-Locale sortiert würden. Dadurch wird die Erstellung von Archivdateien völlig deterministisch. @c FIXME: Add xref to daemon doc about signatures. Beim Exportieren versieht der Daemon den Inhalt des Archivs mit einer digitalen Signatur, auch Beglaubigung genannt. Diese digitale Signatur wird an das Archiv angehängt. Beim Importieren verifiziert der Daemon die Signatur und lehnt den Import ab, falls die Signatur ungültig oder der signierende Schlüssel nicht autorisiert ist. Die wichtigsten Befehlszeilenoptionen sind: @table @code @item --export Exportiert die angegebenen Store-Dateien oder Pakete (siehe unten) und schreibt das resultierende Archiv auf die Standardausgabe. Abhängigkeiten @emph{fehlen} in der Ausgabe, außer wenn @code{--recursive} angegeben wurde. @item -r @itemx --recursive Zusammen mit @code{--export} wird @command{guix archive} hiermit angewiesen, Abhängigkeiten der angegebenen Objekte auch ins Archiv aufzunehmen. Das resultierende Archiv ist somit eigenständig; es enthält den Abschluss der exportierten Store-Objekte. @item --import Ein Archiv von der Standardeingabe lesen und darin enthaltende Dateien in den Store importieren. Der Import bricht ab, wenn das Archiv keine gültige digitale Signatur hat oder wenn es von einem öffentlichen Schlüssel signiert wurde, der keiner der autorisierten Schlüssel ist (siehe @code{--authorize} weiter unten). @item --missing Eine Liste der Store-Dateinamen von der Standardeingabe lesen, je ein Name pro Zeile, und auf die Standardausgabe die Teilmenge dieser Dateien schreiben, die noch nicht im Store vorliegt. @item --generate-key[=@var{Parameter}] @cindex Signieren, von Archiven Ein neues Schlüsselpaar für den Daemon erzeugen. Dies ist erforderlich, damit Archive mit @code{--export} exportiert werden können. Beachten Sie, dass diese Option normalerweise einige Zeit in Anspruch nimmt, da erst Entropie für die Erzeugung des Schlüsselpaares gesammelt werden muss. Das erzeugte Schlüsselpaar wird typischerweise unter @file{/etc/guix} gespeichert, in den Dateien @file{signing-key.pub} (für den öffentlichen Schlüssel) und @file{signing-key.sec} (für den privaten Schlüssel, der geheim gehalten werden muss). Wurden keine @var{Parameters} angegeben, wird ein ECDSA-Schlüssel unter Verwendung der Kurve Ed25519 erzeugt, oder, falls die Libgcrypt-Version älter als 1.6.0 ist, ein 4096-Bit-RSA-Schlüssel. Sonst geben die @var{Parameter} für Libgcrypt geeignete Parameter für @code{genkey} an (siehe @ref{General public-key related Functions, @code{gcry_pk_genkey},, gcrypt, The Libgcrypt Reference Manual}). @item --authorize @cindex Autorisieren, von Archiven Mit dem auf der Standardeingabe übergebenen öffentlichen Schlüssel signierte Importe autorisieren. Der öffentliche Schlüssel muss als »advanced«-formatierter S-Ausdruck gespeichert sein, d.h.@: im selben Format wie die Datei @file{signing-key.pub}. Die Liste autorisierter Schlüssel wird in der Datei @file{/etc/guix/acl} gespeichert, die auch von Hand bearbeitet werden kann. Die Datei enthält @url{http://people.csail.mit.edu/rivest/Sexp.txt, »advanced«-formatierte S-Ausdrücke} und ist als eine Access Control List für die @url{http://theworld.com/~cme/spki.txt, Simple Public-Key Infrastructure (SPKI)} aufgebaut. @item --extract=@var{Verzeichnis} @itemx -x @var{Verzeichnis} Ein Archiv mit einem einzelnen Objekt lesen, wie es von Substitutservern geliefert wird (siehe @ref{Substitute}) und ins @var{Verzeichnis} entpacken. Dies ist eine systemnahe Operation, die man nur selten direkt benutzt; siehe unten. Zum Beispiel entpackt folgender Befehl das Substitut für Emacs, wie es von @code{@value{SUBSTITUTE-SERVER}} geliefert wird, nach @file{/tmp/emacs}: @example $ wget -O - \ https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-emacs-24.5 \ | bunzip2 | guix archive -x /tmp/emacs @end example Archive mit nur einem einzelnen Objekt unterscheiden sich von Archiven für mehrere Dateien, wie sie @command{guix archive --export} erzeugt; sie enthalten nur ein einzelnes Store-Objekt und @emph{keine} eingebettete Signatur. Beim Entpacken findet also @emph{keine} Signaturprüfung statt und ihrer Ausgabe sollte so erst einmal nicht vertraut werden. Der eigentliche Zweck dieser Operation ist, die Inspektion von Archivinhalten von Substitutservern möglich zu machen, auch wenn diesen unter Umständen nicht vertraut wird. @end table @c ********************************************************************* @node Entwicklung @chapter Entwicklung @cindex Softwareentwicklung Wenn Sie ein Software-Entwickler sind, gibt Ihnen Guix Werkzeuge an die Hand, die Sie für hilfreich erachten dürften — ganz unabhängig davon, in welcher Sprache Sie entwickeln. Darum soll es in diesem Kapitel gehen. Der Befehl @command{guix environment} stellt eine bequeme Möglichkeit dar, wie Sie eine @dfn{Entwicklungsumgebung} aufsetzen können, in der all die Abhängigkeiten und Werkzeuge enthalten sind, die Sie brauchen, wenn Sie an Ihrem Lieblingssoftwarepaket arbeiten. Der Befehl @command{guix pack} macht es Ihnen möglich, @dfn{Anwendungsbündel} zu erstellen, die leicht an Nutzer verteilt werden können, die kein Guix benutzen. @menu * Aufruf von guix environment:: Entwicklungsumgebungen einrichten. * Aufruf von guix pack:: Software-Bündel erstellen. @end menu @node Aufruf von guix environment @section @command{guix environment} aufrufen @cindex reproduzierbare Erstellungsumgebungen @cindex Entwicklungsumgebungen @cindex @command{guix environment} @cindex Umgebung, Paketerstellungsumgebung Der Zweck von @command{guix environment} ist es, Hacker beim Aufbau einer reproduzierbaren Entwicklungsumgebung zu unterstützen, ohne dass diese ihr Paketprofil verunreinigen müssen. Das Werkzeug @command{guix environment} nimmt eines oder mehrere Pakete entgegen und erstellt erst all ihre Eingaben, um dann eine Shell-Umgebung herzustellen, in der diese benutzt werden können. Die allgemeine Syntax lautet: @example guix environment @var{Optionen} @var{Paket}@dots{} @end example Folgendes Beispiel zeigt, wie eine neue Shell gestartet wird, auf der alles für die Entwicklung von GNU@tie{}Guile eingerichtet ist: @example guix environment guile @end example Wenn benötigte Abhängigkeiten noch nicht erstellt worden sind, wird @command{guix environment} sie automatisch erstellen lassen. Die Umgebung der neuen Shell ist eine ergänzte Version der Umgebung, in der @command{guix environment} ausgeführt wurde. Sie enthält neben den existierenden Umgebungsvariablen auch die nötigen Suchpfade, um das angegebene Paket erstellen zu können. Um eine »reine« Umgebung zu erstellen, in der die ursprünglichen Umgebungsvariablen nicht mehr vorkommen, kann die Befehlszeilenoption @code{--pure} benutzt werden@footnote{Manchmal ergänzen Nutzer fälschlicherweise Umgebungsvariable wie @code{PATH} in ihrer @file{~/.bashrc}-Datei. Das hat zur Folge, dass wenn @code{guix environment} Bash startet, selbige @file{~/.bashrc} von Bash gelesen wird und die neuen Umgebungen somit »verunreinigt«. Es ist ein Fehler, solche Umgebungsvariable in @file{.bashrc} zu definieren, stattdessen sollten sie in @file{.bash_profile} geschrieben werden, was nur von Login-Shells mit »source« geladen wird. Siehe @ref{Bash Startup Files,,, bash, The GNU Bash Reference Manual} für Details über beim Starten von Bash gelesene Dateien}. @vindex GUIX_ENVIRONMENT @command{guix environment} definiert die Variable @code{GUIX_ENVIRONMENT} in der neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer @file{.bashrc} festzulegen (siehe @ref{Bash Startup Files,,, bash, The GNU Bash Reference Manual}): @example if [ -n "$GUIX_ENVIRONMENT" ] then export PS1="\u@@\h \w [dev]\$ " fi @end example @noindent …@: oder um ihr Profil durchzusehen: @example $ ls "$GUIX_ENVIRONMENT/bin" @end example Des Weiteren kann mehr als ein Paket angegeben werden. In diesem Fall wird die Vereinigung der Eingaben der jeweiligen Pakete zugänglich gemacht. Zum Beispiel erzeugt der folgende Befehl eine Shell, in der alle Abhängigkeiten von sowohl Guile als auch Emacs verfügbar sind: @example guix environment guile emacs @end example Manchmal will man keine interaktive Shell-Sitzung. Ein beliebiger Befehl kann aufgerufen werden, indem man nach Angabe der Pakete noch @code{--} vor den gewünschten Befehl schreibt, um ihn von den übrigen Argumenten abzutrennen: @example guix environment guile -- make -j4 @end example In anderen Situationen ist es bequemer, aufzulisten, welche Pakete in der Umgebung benötigt werden. Zum Beispiel führt der folgende Befehl @command{python} aus einer Umgebung heraus aus, in der Python@tie{}2.7 und NumPy enthalten sind: @example guix environment --ad-hoc python2-numpy python-2.7 -- python @end example Man kann auch sowohl die Abhängigkeiten eines Pakets haben wollen, als auch ein paar zusätzliche Pakete, die nicht Erstellungs- oder Laufzeitabhängigkeiten davon sind, aber trotzdem bei der Entwicklung nützlich sind. Deshalb hängt die Wirkung von der Position der Befehlszeilenoption @code{--ad-hoc} ab. Pakete, die links von @code{--ad-hoc} stehen, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden. Pakete, die rechts stehen, werden selbst zur Umgebung hinzugefügt. Zum Beispiel erzeugt der folgende Befehl eine Guix-Entwicklungsumgebung, die zusätzlich Git und strace umfasst: @example guix environment guix --ad-hoc git strace @end example Manchmal ist es wünschenswert, die Umgebung so viel wie möglich zu isolieren, um maximale Reinheit und Reproduzierbarkeit zu bekommen. Insbesondere ist es wünschenswert, den Zugriff auf @file{/usr/bin} und andere Systemressourcen aus der Entwicklungsumgebung heraus zu verhindern, wenn man Guix auf einer fremden Wirtsdistribution benutzt, die nicht Guix System ist. Zum Beispiel startet der folgende Befehl eine Guile-REPL in einer isolierten Umgebung, einem sogenannten »Container«, in der nur der Store und das aktuelle Arbeitsverzeichnis eingebunden sind: @example guix environment --ad-hoc --container guile -- guile @end example @quotation Anmerkung Die Befehlszeilenoption @code{--container} funktioniert nur mit Linux-libre 3.19 oder neuer. @end quotation Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst. @table @code @item --root=@var{Datei} @itemx -r @var{Datei} @cindex persistente Umgebung @cindex Müllsammlerwurzel, für Umgebungen Die @var{Datei} zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren. Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie »persistent« zu machen. Wird diese Option weggelassen, ist die Umgebung nur, solange die Sitzung von @command{guix environment} besteht, vor dem Müllsammler sicher. Das bedeutet, wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, müssen Sie vielleicht Pakete neu erstellen oder neu herunterladen. @ref{Aufruf von guix gc} hat mehr Informationen über Müllsammlerwurzeln. @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der @var{Ausdruck} ausgewertet wird. Zum Beispiel startet dies: @example guix environment -e '(@@ (gnu packages maths) petsc-openmpi)' @end example eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc. Wenn man dies ausführt: @example guix environment --ad-hoc -e '(@@ (gnu) %base-packages)' @end example bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind. Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden: @example guix environment --ad-hoc -e '(list (@@ (gnu packages bash) bash) "include")' @end example @item --load=@var{Datei} @itemx -l @var{Datei} Eine Umgebung erstellen für das Paket oder die Liste von Paketen, zu der der Code in der @var{Datei} ausgewertet wird. Zum Beispiel könnte die @var{Datei} eine Definition wie diese enthalten (siehe @ref{Pakete definieren}): @example @verbatiminclude environment-gdb.scm @end example @item --manifest=@var{Datei} @itemx -m @var{Datei} Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der @var{Datei} geliefert wird. Dies verhält sich ähnlich wie die gleichnamige Option des Befehls @command{guix package} (siehe @ref{profile-manifest, @option{--manifest}}) und benutzt auch dieselben Manifestdateien. @item --ad-hoc Alle angegebenen Pakete in der resultierenden Umgebung einschließen, als wären sie Eingaben eines @i{ad hoc} definierten Pakets. Diese Befehlszeilenoption ist nützlich, um schnell Umgebungen aufzusetzen, ohne dafür einen Paketausdruck schreiben zu müssen, der die gewünschten Eingaben enthält. Zum Beispiel wird mit diesem Befehl: @example guix environment --ad-hoc guile guile-sdl -- guile @end example @command{guile} in einer Umgebung ausgeführt, in der sowohl Guile als auch Guile-SDL zur Verfügung stehen. Beachten Sie, dass in diesem Beispiel implizit die vorgegebene Ausgabe von @code{guile} und @code{guile-sdl} verwendet wird, es aber auch möglich ist, eine bestimmte Ausgabe auszuwählen — z.B.@: wird mit @code{glib:bin} die Ausgabe @code{bin} von @code{glib} gewählt (siehe @ref{Pakete mit mehreren Ausgaben.}). Diese Befehlszeilenoption kann mit dem standardmäßigen Verhalten von @command{guix environment} verbunden werden. Pakete, die vor @code{--ad-hoc} aufgeführt werden, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden, was dem standardmäßigen Verhalten entspricht. Pakete, die danach aufgeführt werden, werden selbst zur Umgebung hinzugefügt. @item --pure Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit @option{--preserve} angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts. @item --preserve=@var{Regexp} @itemx -E @var{Regexp} Wenn das hier zusammen mit @option{--pure} angegeben wird, bleiben die zum regulären Ausdruck @var{Regexp} passenden Umgebungsvariablen erhalten — mit anderen Worten werden sie auf eine »weiße Liste« von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden. @example guix environment --pure --preserve=^SLURM --ad-hoc openmpi @dots{} \ -- mpirun @dots{} @end example In diesem Beispiel wird @command{mpirun} in einem Kontext ausgeführt, in dem die einzig definierten Umgebungsvariablen @code{PATH} und solche sind, deren Name mit @code{SLURM} beginnt, sowie die üblichen besonders »kostbaren« Variablen (@code{HOME}, @code{USER}, etc.). @item --search-paths Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht. @item --system=@var{System} @itemx -s @var{System} Versuchen, für das angegebene @var{System} zu erstellen — z.B.@: @code{i686-linux}. @item --container @itemx -C @cindex container Den @var{Befehl} in einer isolierten Umgebung (einem sogenannten »Container«) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption @code{--user} nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei @file{/etc/passwd}. Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption @option{--user} wird übergeben (siehe unten). @item --network @itemx -N Bei isolierten Umgebungen (»Containern«) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät. @item --link-profile @itemx -P Bei isolierten Umgebungen (»Containern«) wird das Umgebungsprofil im Container als @file{~/.guix-profile} verknüpft. Das ist äquivalent dazu, den Befehl @command{ln -s $GUIX_ENVIRONMENT ~/.guix-profile} im Container auszuführen. Wenn das Verzeichnis bereits existiert, schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser Fehler wird immer eintreten, wenn @command{guix environment} im persönlichen Verzeichnis des Benutzers aufgerufen wurde. Bestimmte Pakete sind so eingerichtet, dass sie in @code{~/.guix-profile} nach Konfigurationsdateien und Daten suchen,@footnote{Zum Beispiel inspiziert das Paket @code{fontconfig} das Verzeichnis @file{~/.guix-profile/share/fonts}, um zusätzliche Schriftarten zu finden.} weshalb @code{--link-profile} benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten. @item --user=@var{Benutzer} @itemx -u @var{Benutzer} Bei isolierten Umgebungen (»Containern«) wird der Benutzername @var{Benutzer} anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in @file{/etc/passwd} im Container wird also den Namen @var{Benutzer} enthalten und das persönliche Verzeichnis wird den Namen @file{/home/BENUTZER} tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. @var{Benutzer} muss auf dem System nicht existieren. Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils @code{--share} und @code{--expose}), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu @file{/home/BENUTZER} erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses. @example # wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren cd $HOME/wd guix environment --container --user=foo \ --expose=$HOME/test \ --expose=/tmp/target=$HOME/target @end example Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Privatsphäre und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden. @item --expose=@var{Quelle}[=@var{Ziel}] Bei isolierten Umgebungen (»Containern«) wird das Dateisystem unter @var{Quelle} vom Wirtssystem als Nur-Lese-Dateisystem @var{Ziel} im Container zugänglich gemacht. Wenn kein @var{Ziel} angegeben wurde, wird die @var{Quelle} auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt. Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis @file{/austausch} nur für Lesezugriffe zugänglich gemacht wurde: @example guix environment --container --expose=$HOME=/austausch --ad-hoc guile -- guile @end example @item --share=@var{Quelle}[=@var{Ziel}] Bei isolierten Umgebungen (»Containern«) wird das Dateisystem unter @var{Quelle} vom Wirtssystem als beschreibbares Dateisystem @var{Ziel} im Container zugänglich gemacht. Wenn kein @var{Ziel} angegeben wurde, wird die @var{Quelle} auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt. Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis @file{/austausch} sowohl für Lese- als auch für Schreibzugriffe zugänglich gemacht wurde: @example guix environment --container --share=$HOME=/austausch --ad-hoc guile -- guile @end example @end table @command{guix environment} unterstützt auch alle gemeinsamen Erstellungsoptionen, die von @command{guix build} unterstützt werden (siehe @ref{Gemeinsame Erstellungsoptionen}), und die Paketumwandlungsoptionen (siehe @ref{Paketumwandlungsoptionen}). @node Aufruf von guix pack @section @command{guix pack} aufrufen Manchmal möchten Sie Software an Leute weitergeben, die (noch!) nicht das Glück haben, Guix zu benutzen. Mit Guix würden sie nur @command{guix package -i @var{irgendetwas}} einzutippen brauchen, aber wenn sie kein Guix haben, muss es anders gehen. Hier kommt @command{guix pack} ins Spiel. @quotation Anmerkung Wenn Sie aber nach einer Möglichkeit suchen, Binärdateien unter Maschinen auszutauschen, auf denen Guix bereits läuft, sollten Sie einen Blick auf die Abschnitte @ref{Aufruf von guix copy}, @ref{Aufruf von guix publish} und @ref{Aufruf von guix archive} werfen. @end quotation @cindex Pack @cindex Bündel @cindex Anwendungsbündel @cindex Software-Bündel Der Befehl @command{guix pack} erzeugt ein gut verpacktes @dfn{Software-Bündel}: Konkret wird dadurch ein Tarball oder eine andere Art von Archiv mit den Binärdateien der Software erzeugt, die Sie sich gewünscht haben, zusammen mit all ihren Abhängigkeiten. Der resultierende Archiv kann auch auf jeder Maschine genutzt werden, die kein Guix hat, und jeder kann damit genau dieselben Binärdateien benutzen, die Ihnen unter Guix zur Verfügung stehen. Das Bündel wird dabei auf eine Bit für Bit reproduzierbare Art erzeugt, damit auch jeder nachprüfen kann, dass darin wirklich diejenigen Binärdateien enthalten sind, von denen Sie es behaupten. Um zum Beispiel ein Bündel mit Guile, Emacs, Geiser und all ihren Abhängigkeiten zu erzeugen, führen Sie diesen Befehl aus: @example $ guix pack guile emacs geiser @dots{} /gnu/store/@dots{}-pack.tar.gz @end example Als Ergebnis erhalten Sie einen Tarball mit einem Verzeichnis @file{/gnu/store}, worin sich alles relevanten Pakete befinden. Der resultierende Tarball enthält auch ein @dfn{Profil} mit den drei angegebenen Paketen; es ist dieselbe Art von Profil, die auch @command{guix package -i} erzeugen würde. Mit diesem Mechanismus wird auch der binäre Tarball zur Installation von Guix erzeugt (siehe @ref{Aus Binärdatei installieren}). Benutzer des Bündels müssten dann aber zum Beispiel @file{/gnu/store/@dots{}-profile/bin/guile} eintippen, um Guile auszuführen, was Ihnen zu unbequem sein könnte. Ein Ausweg wäre, dass Sie etwa eine symbolische Verknüpfung @file{/opt/gnu/bin} auf das Profil anlegen: @example guix pack -S /opt/gnu/bin=bin guile emacs geiser @end example @noindent Benutzer müssten dann nur noch @file{/opt/gnu/bin/guile} eintippen, um Guile zu genießen. @cindex pfad-agnostische Binärdateien, mit @command{guix pack} Doch was ist, wenn die Empfängerin Ihres Bündels keine Administratorrechte auf ihrer Maschine hat, das Bündel also nicht ins Wurzelverzeichnis ihres Dateisystems entpacken kann? Dann möchten Sie vielleicht die Befehlszeilenoption @code{--relocatable} benutzen (siehe weiter unten). Mit dieser Option werden @dfn{pfad-agnostische Binärdateien} erzeugt, die auch in einem beliebigen anderen Verzeichnis in der Dateisystemhierarchie abgelegt und von dort ausgeführt werden können. In obigem Beispiel würden Benutzer Ihren Tarball in ihr Persönliches Verzeichnis (das »Home«-Verzeichnis) entpacken und von dort den Befehl @file{./opt/gnu/bin/guile} ausführen. @cindex Docker, ein Abbild erstellen mit guix pack Eine weitere Möglichkeit ist, das Bündel im Format eines Docker-Abbilds (englisch Docker-Image) zu erzeugen. Das geht mit dem folgenden Befehl: @example guix pack -f docker guile emacs geiser @end example @noindent Das Ergebnis ist ein Tarball, der dem Befehl @command{docker load} übergeben werden kann. In der @uref{https://docs.docker.com/engine/reference/commandline/load/, Dokumentation von Docker} finden Sie nähere Informationen. @cindex Singularity, ein Abbild erstellen mit guix pack @cindex SquashFS, ein Abbild erstellen mit guix pack Und noch eine weitere Möglichkeit ist, dass Sie ein SquashFS-Abbild mit folgendem Befehl erzeugen: @example guix pack -f squashfs guile emacs geiser @end example @noindent Das Ergebnis ist ein SquashFS-Dateisystemabbild, dass entweder als Dateisystem eingebunden oder mit Hilfe der @uref{http://singularity.lbl.gov, Singularity-Container-Ausführungsumgebung} als Dateisystemcontainer benutzt werden kann, mit Befehlen wie @command{singularity shell} oder @command{singularity exec}. Es gibt mehrere Befehlszeilenoptionen, mit denen Sie Ihr Bündel anpassen können: @table @code @item --format=@var{Format} @itemx -f @var{Format} Generiert ein Bündel im angegebenen @var{Format}. Die verfügbaren Formate sind: @table @code @item tarball Das standardmäßig benutzte Format. Damit wird ein Tarball generiert, der alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält. @item docker Generiert einen Tarball gemäß der @uref{https://github.com/docker/docker/blob/master/image/spec/v1.2.md, Docker Image Specification}, d.h.@: der Spezifikation für Docker-Abbilder. @item squashfs Generiert ein SquashFS-Abbild, das alle angegebenen Binärdateien und symbolischen Verknüpfungen enthält, sowie leere Einhängepunkte für virtuelle Dateisysteme wie procfs. @end table @cindex pfad-agnostische Binärdateien @item --relocatable @itemx -R Erzeugt @dfn{pfad-agnostische Binärdateien} — also »portable« Binärdateien, die an einer beliebigen Stelle in der Dateisystemhierarchie platziert und von dort ausgeführt werden können. Wenn diese Befehlszeilenoption einmal übergeben wird, funktionieren die erzeugten Binärdateien nur dann, wenn @dfn{Benutzernamensräume} des Linux-Kernels unterstützt werden. Wenn sie @emph{zweimal}@footnote{Es gibt einen Trick, wie Sie sich das merken können: @code{-RR}, womit PRoot-Unterstützung hinzugefügt wird, kann man sich als Abkürzung für »Rundum Relocatable« oder englisch »Really Relocatable« vorstellen. Ist das nicht prima?} übergeben wird, laufen die Binärdateien notfalls mit PRoot, wenn keine Benutzernamensräume zur Verfügung stehen, funktionieren also ziemlich überall — siehe unten für die Auswirkungen. Zum Beispiel können Sie ein Bash enthalltendes Bündel erzeugen mit: @example guix pack -RR -S /mybin=bin bash @end example @noindent …@: Sie können dieses dann auf eine Maschine ohne Guix kopieren und als normaler Nutzer aus Ihrem Persönlichen Verzeichnis (auch »Home«-Verzeichnis genannt) dann ausführen mit: @example tar xf pack.tar.gz ./meine-bin/sh @end example @noindent Wenn Sie in der so gestarteten Shell dann @code{ls /gnu/store} eintippen, sehen Sie, dass Ihnen angezeigt wird, in @file{/gnu/store} befänden sich alle Abhängigkeiten von @code{bash}, obwohl auf der Maschine überhaupt kein Verzeichnis @file{/gnu/store} existiert! Dies ist vermutlich die einfachste Art, mit Guix erstellte Software für eine Maschine ohne Guix auszuliefern. @quotation Anmerkung Wenn die Voreinstellung verwendet wird, funktionieren pfad-agnostische Binärdateien nur mit @dfn{Benutzernamensräumen} (englisch @dfn{User namespaces}), einer Funktionalität des Linux-Kernels, mit der Benutzer ohne besondere Berechtigungen Dateisysteme einbinden (englisch »mount«) oder die Wurzel des Dateisystems wechseln können (»change root«, kurz »chroot«). Alte Versionen von Linux haben diese Funktionalität noch nicht unterstützt und manche Distributionen von GNU/Linux schalten sie ab. Um pfad-agnostische Binärdateien zu erzeugen, die auch ohne Benutzernamensräume funktionieren, können Sie die Befehlszeilenoption @option{--relocatable} oder @option{-R} @emph{zweimal} angeben. In diesem Fall werden die Binärdateien zuerst überprüfen, ob Benutzernamensräume unterstützt werden, und sonst notfalls PRoot benutzen, um das Programm auszuführen, wenn Benutzernamensräume nicht unterstützt werden. Das Programm @uref{https://proot-me.github.io/, PRoot} bietet auch Unterstützung für Dateisystemvirtualisierung, indem der Systemaufruf @code{ptrace} auf das laufende Programm angewendet wird. Dieser Ansatz funktioniert auch ohne besondere Kernel-Unterstützung, aber das Programm braucht mehr Zeit, um selbst Systemaufrufe durchzuführen. @end quotation @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird. Der Zweck hiervon ist derselbe wie bei der gleichnamigen Befehlszeilenoption in @command{guix build} (siehe @ref{Zusätzliche Erstellungsoptionen, @code{--expression} in @command{guix build}}). @item --manifest=@var{Datei} @itemx -m @var{Datei} Die Pakete benutzen, die im Manifest-Objekt aufgeführt sind, das vom Scheme-Code in der angegebenen @var{Datei} geliefert wird. Dies hat einen ähnlichen Zweck wie die gleichnamige Befehlszeilenoption in @command{guix package} (siehe @ref{profile-manifest, @option{--manifest}}) und benutzt dieselben Regeln für Manifest-Dateien. Damit können Sie eine Reihe von Paketen einmal definieren und dann sowohl zum Erzeugen von Profilesn als auch zum Erzeugen von Archiven benutzen, letztere für Maschinen, auf denen Guix nicht installiert ist. Beachten Sie, dass Sie @emph{entweder} eine Manifest-Datei @emph{oder} eine Liste von Paketen angeben können, aber nicht beides. @item --system=@var{System} @itemx -s @var{System} Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die Erstellung durchführt. @item --target=@var{Tripel} @cindex Cross-Kompilieren Lässt für das angegebene @var{Tripel} cross-erstellen, dieses muss ein gültiges GNU-Tripel wie z.B.@: @code{"mips64el-linux-gnu"} sein (siehe @ref{Specifying target triplets, GNU configuration triplets,, autoconf, Autoconf}). @item --compression=@var{Werkzeug} @itemx -C @var{Werkzeug} Komprimiert den resultierenden Tarball mit dem angegebenen @var{Werkzeug} — dieses kann @code{gzip}, @code{bzip2}, @code{xz}, @code{lzip} oder @code{none} für keine Kompression sein. @item --symlink=@var{Spezifikation} @itemx -S @var{Spezifikation} Fügt die in der @var{Spezifikation} festgelegten symbolischen Verknüpfungen zum Bündel hinzu. Diese Befehlszeilenoption darf mehrmals vorkommen. Die @var{Spezifikation} muss von der Form @code{@var{Quellort}=@var{Zielort}} sein, wobei der @var{Quellort} der Ort der symbolischen Verknüpfung, die erstellt wird, und @var{Zielort} das Ziel der symbolischen Verknüpfung ist. Zum Beispiel wird mit @code{-S /opt/gnu/bin=bin} eine symbolische Verknüpfung @file{/opt/gnu/bin} auf das Unterverzeichnis @file{bin} im Profil erzeugt. @item --save-provenance Provenienzinformationen für die auf der Befehlszeile übergebenen Pakete speichern. Zu den Provenienzinformationen gehören die URL und der Commit jedes benutzten Kanals (siehe @ref{Kanäle}). Provenienzinformationen werden in der Datei @file{/gnu/store/@dots{}-profile/manifest} im Bündel zusammen mit den üblichen Paketmetadaten abgespeichert — also Name und Version jedes Pakets, welche Eingaben dabei propagiert werden und so weiter. Die Informationen nützen den Empfängern des Bündels, weil sie dann wissen, woraus das Bündel (angeblich) besteht. Der Vorgabe nach wird diese Befehlszeilenoption @emph{nicht} verwendet, weil Provenienzinformationen genau wie Zeitstempel nichts zum Erstellungsprozess beitragen. Mit anderen Worten gibt es unendlich viele Kanal-URLs und Commit-IDs, aus denen dasselbe Bündel stammen könnte. Wenn solche »stillen« Metadaten Teil des Ausgabe sind, dann wird also die bitweise Reproduzierbarkeit von Quellcode zu Binärdateien eingeschränkt. @item --localstatedir @itemx --profile-name=@var{Name} Das »lokale Zustandsverzeichnis« @file{/var/guix} ins resultierende Bündel aufnehmen, speziell auch das Profil @file{/var/guix/profiles/per-user/root/@var{Name}} — der vorgegebene @var{Name} ist @code{guix-profile}, was @file{~root/.guix-profile} entspricht. @file{/var/guix} enthält die Store-Datenbank (siehe @ref{Der Store}) sowie die Müllsammlerwurzeln (siehe @ref{Aufruf von guix gc}). Es ins Bündel aufzunehmen, bedeutet, dass der enthaltene Store »vollständig« ist und von Guix verwaltet werden kann, andernfalls wäre der Store im Bündel »tot« und nach dem Auspacken des Bündels könnte Guix keine Objekte mehr dort hinzufügen oder entfernen. Ein Anwendungsfall hierfür ist der eigenständige, alle Komponenten umfassende binäre Tarball von Guix (siehe @ref{Aus Binärdatei installieren}). @item --bootstrap Mit den Bootstrap-Binärdateien das Bündel erstellen. Diese Option ist nur für Guix-Entwickler nützlich. @end table Außerdem unterstützt @command{guix pack} alle gemeinsamen Erstellungsoptionen (siehe @ref{Gemeinsame Erstellungsoptionen}) und alle Paketumwandlungsoptionen (siehe @ref{Paketumwandlungsoptionen}). @c ********************************************************************* @node Programmierschnittstelle @chapter Programmierschnittstelle GNU Guix bietet mehrere Programmierschnittstellen (APIs) in der Programmiersprache Scheme an, mit denen Software-Pakete definiert, erstellt und gesucht werden können. Die erste Schnittstelle erlaubt es Nutzern, ihre eigenen Paketdefinitionen in einer Hochsprache zu schreiben. Diese Definitionen nehmen Bezug auf geläufige Konzepte der Paketverwaltung, wie den Namen und die Version eines Pakets, sein Erstellungssystem (Build System) und seine Abhängigkeiten (Dependencies). Diese Definitionen können dann in konkrete Erstellungsaktionen umgewandelt werden. Erstellungsaktionen werden vom Guix-Daemon für dessen Nutzer durchgeführt. Bei einer normalen Konfiguration hat der Daemon Schreibzugriff auf den Store, also das Verzeichnis @file{/gnu/store}, Nutzer hingegen nicht. Die empfohlene Konfiguration lässt den Daemon die Erstellungen in chroot-Umgebungen durchführen, mit eigenen Benutzerkonten für »Erstellungsbenutzer«, um gegenseitige Beeinflussung der Erstellung und des übrigen Systems zu minimieren. @cindex Ableitung Systemnahe APIs stehen zur Verfügung, um mit dem Daemon und dem Store zu interagieren. Um den Daemon anzuweisen, eine Erstellungsaktion durchzuführen, versorgen ihn Nutzer jeweils mit einer @dfn{Ableitung}. Eine Ableitung ist, wie durchzuführende Erstellungsaktionen, sowie die Umgebungen, in denen sie durchzuführen sind, in Guix eigentlich intern dargestellt werden. Ableitungen verhalten sich zu Paketdefinitionen vergleichbar mit Assembler-Code zu C-Programmen. Der Begriff »Ableitung« kommt daher, dass Erstellungsergebnisse daraus @emph{abgeleitet} werden. Dieses Kapitel beschreibt der Reihe nach all diese Programmierschnittstellen (APIs), angefangen mit hochsprachlichen Paketdefinitionen. @menu * Paketmodule:: Pakete aus Sicht des Programmierers. * Pakete definieren:: Wie Sie neue Pakete definieren. * Erstellungssysteme:: Angeben, wie Pakete erstellt werden. * Der Store:: Den Paket-Store verändern. * Ableitungen:: Systemnahe Schnittstelle für Paketableitungen. * Die Store-Monade:: Rein funktionale Schnittstelle zum Store. * G-Ausdrücke:: Erstellungsausdrücke verarbeiten. * Aufruf von guix repl:: Interaktiv an Guix herumbasteln. @end menu @node Paketmodule @section Paketmodule Aus Programmierersicht werden die Paketdefinitionen der GNU-Distribution als Guile-Module in Namensräumen wie @code{(gnu packages @dots{})} sichtbar gemacht@footnote{Beachten Sie, dass Pakete unter dem Modulnamensraum @code{(gnu packages @dots{})} nicht notwendigerweise auch »GNU-Pakete« sind. Dieses Schema für die Benennung von Modulen folgt lediglich den üblichen Guile-Konventionen: @code{gnu} bedeutet, dass die Module als Teil des GNU-Systems ausgeliefert werden, und @code{packages} gruppiert Module mit Paketdefinitionen.} (siehe @ref{Module, Guile modules,, guile, GNU Guile Reference Manual}). Zum Beispiel exportiert das Modul @code{(gnu packages emacs)} eine Variable namens @code{emacs}, die an ein @code{}-Objekt gebunden ist (@pxref{Pakete definieren}). The @code{(gnu packages @dots{})} module name space is automatically scanned for packages by the command-line tools. For instance, when running @code{guix package -i emacs}, all the @code{(gnu packages @dots{})} modules are scanned until one that exports a package object whose name is @code{emacs} is found. This package search facility is implemented in the @code{(gnu packages)} module. @cindex Anpassung, von Paketen @cindex package module search path Users can store package definitions in modules with different names---e.g., @code{(my-packages emacs)}@footnote{Note that the file name and module name must match. For instance, the @code{(my-packages emacs)} module must be stored in a @file{my-packages/emacs.scm} file relative to the load path specified with @option{--load-path} or @code{GUIX_PACKAGE_PATH}. @xref{Modules and the File System,,, guile, GNU Guile Reference Manual}, for details.}. There are two ways to make these package definitions visible to the user interfaces: @enumerate @item By adding the directory containing your package modules to the search path with the @code{-L} flag of @command{guix package} and other commands (@pxref{Gemeinsame Erstellungsoptionen}), or by setting the @code{GUIX_PACKAGE_PATH} environment variable described below. @item By defining a @dfn{channel} and configuring @command{guix pull} so that it pulls from it. A channel is essentially a Git repository containing package modules. @xref{Kanäle}, for more information on how to define and use channels. @end enumerate @code{GUIX_PACKAGE_PATH} works similarly to other search path variables: @defvr {Environment Variable} GUIX_PACKAGE_PATH This is a colon-separated list of directories to search for additional package modules. Directories listed in this variable take precedence over the own modules of the distribution. @end defvr The distribution is fully @dfn{bootstrapped} and @dfn{self-contained}: each package is built based solely on other packages in the distribution. The root of this dependency graph is a small set of @dfn{bootstrap binaries}, provided by the @code{(gnu packages bootstrap)} module. For more information on bootstrapping, @pxref{Bootstrapping}. @node Pakete definieren @section Pakete definieren Mit den Modulen @code{(guix packages)} und @code{(guix build-system)} können Paketdefinitionen auf einer hohen Abstraktionsebene geschrieben werden. Zum Beispiel sieht die Paketdefinition bzw. das @dfn{Rezept} für das Paket von GNU Hello so aus: @example (define-module (gnu packages hello) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) #:use-module (guix licenses) #:use-module (gnu packages gawk)) (define-public hello (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (arguments '(#:configure-flags '("--enable-silent-rules"))) (inputs `(("gawk" ,gawk))) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+))) @end example @noindent Auch ohne ein Experte in Scheme zu sein, könnten Leser erraten haben, was die verschiedenen Felder dabei bedeuten. Dieser Ausdruck bindet die Variable @code{hello} an ein @code{}-Objekt, was an sich nur ein Verbund (Record) ist (siehe @ref{SRFI-9, Scheme records,, guile, GNU Guile Reference Manual}). Die Felder dieses Paket-Objekts lassen sich mit den Prozeduren aus dem Modul @code{(guix packages)} auslesen, zum Beispiel liefert @code{(package-name hello)} — Überraschung! — @code{"hello"}. Mit etwas Glück können Sie die Definition vielleicht teilweise oder sogar ganz aus einer anderen Paketsammlung importieren, indem Sie den Befehl @code{guix import} verwenden (siehe @ref{Aufruf von guix import}). In obigem Beispiel wurde @var{hello} in einem eigenen Modul ganz für sich alleine definiert, und zwar @code{(gnu packages hello)}. Technisch gesehen muss es nicht unbedingt in einem solchen Modul definiert werden, aber es ist bequem, denn alle Module unter @code{(gnu packages @dots{})} werden automatisch von den Befehlszeilenwerkzeugen gefunden (siehe @ref{Paketmodule}). Ein paar Dinge sind noch erwähnenswert in der obigen Paketdefinition: @itemize @item Das @code{source}-Feld für die Quelle des Pakets ist ein @code{}-Objekt, was den Paketursprung angibt (siehe @ref{»origin«-Referenz} für eine vollständige Referenz). Hier wird dafür die Methode @code{url-fetch} aus dem Modul @code{(guix download)} benutzt, d.h.@: die Quelle ist eine Datei, die über FTP oder HTTP heruntergeladen werden soll. Das Präfix @code{mirror://gnu} lässt @code{url-fetch} einen der GNU-Spiegelserver benutzen, die in @code{(guix download)} definiert sind. Das Feld @code{sha256} legt den erwarteten SHA256-Hashwert der herunterzuladenden Datei fest. Ihn anzugeben ist Pflicht und er ermöglicht es Guix, die Integrität der Datei zu überprüfen. Die Form @code{(base32 @dots{})} geht der base32-Darstellung des Hash-Wertes voraus. Sie finden die base32-Darstellung mit Hilfe der Befehle @code{guix download} (siehe @ref{Aufruf von guix download}) und @code{guix hash} (siehe @ref{Aufruf von guix hash}). @cindex Patches Wenn nötig kann in der @code{origin}-Form auch ein @code{patches}-Feld stehen, wo anzuwendende Patches aufgeführt werden, sowie ein @code{snippet}-Feld mit einem Scheme-Ausdruck mit den Anweisungen, wie der Quellcode zu modifizieren ist. @item @cindex GNU-Erstellungssystem Das Feld @code{build-system} legt fest, mit welcher Prozedur das Paket erstellt werden soll (siehe @ref{Erstellungssysteme}). In diesem Beispiel steht @var{gnu-build-system} für das wohlbekannte GNU-Erstellungssystem, wo Pakete mit der üblichen Befehlsfolge @code{./configure && make && make check && make install} konfiguriert, erstellt und installiert werden. @item Das Feld @code{arguments} gibt an, welche Optionen dem Erstellungssystem mitgegeben werden sollen (siehe @ref{Erstellungssysteme}). In diesem Fall interpretiert @var{gnu-build-system} diese als Auftrag, @file{configure} mit der Befehlszeilenoption @code{--enable-silent-rules} auszuführen. @cindex quote @cindex Maskierung @findex ' @findex quote Was hat es mit diesen einfachen Anführungszeichen (@code{'}) auf sich? Sie gehören zur Syntax von Scheme und führen eine wörtlich zu interpretierende Datenlisten ein; dies nennt sich Maskierung oder Quotierung. @code{'} ist synonym mit @code{quote}. @ref{Expression Syntax, quoting,, guile, GNU Guile Reference Manual} enthält weitere Details. Hierbei ist also der Wert des @code{arguments}-Feldes eine Liste von Argumenten, die an das Erstellungssystem weitergereicht werden, wie bei @code{apply} (siehe @ref{Fly Evaluation, @code{apply},, guile, GNU Guile Reference Manual}). Ein Doppelkreuz gefolgt von einem Doppelpunkt (@code{#:}) definiert ein Scheme-@dfn{Schlüsselwort} (siehe @ref{Keywords,,, guile, GNU Guile Reference Manual}) und @code{#:configure-flags} ist ein Schlüsselwort, um eine Befehlszeilenoption an das Erstellungssystem mitzugeben (siehe @ref{Coding With Keywords,,, guile, GNU Guile Reference Manual}). @item Das Feld @code{inputs} legt Eingaben an den Erstellungsprozess fest — d.h.@: Abhängigkeiten des Pakets zur Erstellungs- oder Laufzeit. Hier definieren wir eine Eingabe namens @code{"gawk"}, deren Wert wir auf den Wert der @var{gawk}-Variablen festlegen; @var{gawk} ist auch selbst wiederum an ein @code{}-Objekt als Variablenwert gebunden. @cindex Backquote (Quasimaskierung) @findex ` @findex quasiquote @cindex Komma (Demaskierung) @findex , @findex unquote @findex ,@@ @findex unquote-splicing Auch mit @code{`} (einem Backquote, stattdessen kann man auch das längere Synonym @code{quasiquote} schreiben) können wir eine wörtlich als Daten interpretierte Liste im @code{inputs}-Feld einführen, aber bei dieser »Quasimaskierung« kann @code{,} (ein Komma, oder dessen Synonym @code{unquote}) benutzt werden, um den ausgewerteten Wert eines Ausdrucks in diese Liste einzufügen (siehe @ref{Expression Syntax, unquote,, guile, GNU Guile Reference Manual}). Beachten Sie, dass GCC, Coreutils, Bash und andere essenzielle Werkzeuge hier nicht als Eingaben aufgeführt werden müssen. Stattdessen sorgt schon @var{gnu-build-system} dafür, dass diese vorhanden sein müssen (siehe @ref{Erstellungssysteme}). Sämtliche anderen Abhängigkeiten müssen aber im @code{inputs}-Feld aufgezählt werden. Jede hier nicht angegebene Abhängigkeit wird während des Erstellungsprozesses schlicht nicht verfügbar sein, woraus ein Erstellungsfehler resultieren kann. @end itemize Siehe @ref{»package«-Referenz} für eine umfassende Beschreibung aller erlaubten Felder. Sobald eine Paketdefinition eingesetzt wurde, können Sie das Paket mit Hilfe des Befehlszeilenwerkzeugs @code{guix build} dann auch tatsächlich erstellen (siehe @ref{Aufruf von guix build}) und dabei jegliche Erstellungsfehler, auf die Sie stoßen, beseitigen (siehe @ref{Fehlschläge beim Erstellen untersuchen}). Sie können den Befehl @command{guix edit} benutzen, um leicht zur Paketdefinition zurückzuspringen (siehe @ref{Aufruf von guix edit}). Unter @ref{Paketrichtlinien} finden Sie mehr Informationen darüber, wie Sie Paketdefinitionen testen, und unter @ref{Aufruf von guix lint} finden Sie Informationen, wie Sie prüfen, ob eine Definition alle Stilkonventionen einhält. @vindex GUIX_PACKAGE_PATH Zuletzt finden Sie unter @ref{Kanäle} Informationen, wie Sie die Distribution um Ihre eigenen Pakete in einem »Kanal« erweitern. Zu all dem sei auch erwähnt, dass Sie das Aktualisieren einer Paketdefinition auf eine vom Anbieter neu veröffentlichte Version mit dem Befehl @command{guix refresh} teilweise automatisieren können (siehe @ref{Aufruf von guix refresh}). Hinter den Kulissen wird die einem @code{}-Objekt entsprechende Ableitung zuerst durch @code{package-derivation} berechnet. Diese Ableitung wird in der @code{.drv}-Datei unter @file{/gnu/store} gespeichert. Die von ihr vorgeschriebenen Erstellungsaktionen können dann durch die Prozedur @code{build-derivations} umgesetzt werden (siehe @ref{Der Store}). @deffn {Scheme-Prozedur} package-derivation @var{Store} @var{Paket} [@var{System}] Das @code{}-Objekt zum @var{Paket} für das angegebene @var{System} liefern (siehe @ref{Ableitungen}). Als @var{Paket} muss ein gültiges @code{}-Objekt angegeben werden und das @var{System} muss eine Zeichenkette sein, die das Zielsystem angibt — z.B.@: @code{"x86_64-linux"} für ein auf x86_64 laufendes, Linux-basiertes GNU-System. @var{Store} muss eine Verbindung zum Daemon sein, der die Operationen auf dem Store durchführt (siehe @ref{Der Store}). @end deffn @noindent @cindex Cross-Kompilieren Auf ähnliche Weise kann eine Ableitung berechnet werden, die ein Paket für ein anderes System cross-erstellt. @deffn {Scheme-Prozedur} package-cross-derivation @var{Store} @ @var{Paket} @var{Ziel} [@var{System}] Liefert das @code{}-Objekt, um das @var{Paket} zu cross-erstellen vom @var{System} aus für das @var{Ziel}-System. Als @var{Ziel} muss ein gültiges GNU-Tripel angegeben werden, was die Ziel-Hardware und das zugehörige Betriebssystem beschreibt, wie z.B.@: @code{"mips64el-linux-gnu"} (siehe @ref{Configuration Names, GNU configuration triplets,, configure, GNU Configure and Build System}). @end deffn @cindex Paketumwandlungen @cindex Eingaben umschreiben @cindex Abhängigkeitsbaum umschreiben Pakete können auf beliebige Art verändert werden. Ein Beispiel für eine nützliche Veränderung ist das @dfn{Umschreiben von Eingaben}, womit der Abhängigkeitsbaum eines Pakets umgeschrieben wird, indem bestimmte Eingaben durch andere ersetzt werden: @deffn {Scheme-Prozedur} package-input-rewriting @var{Ersetzungen} @ [@var{umgeschriebener-Name}] Eine Prozedur liefern, die für ein ihr übergebenes Paket dessen direkte und indirekte Abhängigkeit (aber nicht dessen implizite Eingaben) gemäß den @var{Ersetzungen} umschreibt. @var{Ersetzungen} ist eine Liste von Paketpaaren; das erste Element eines Paares ist das zu ersetzende Paket und das zweite ist, wodurch es ersetzt werden soll. Optional kann als @var{umgeschriebener-Name} eine ein Argument nehmende Prozedur angegeben werden, die einen Paketnamen nimmt und den Namen nach dem Umschreiben zurückliefert. @end deffn @noindent Betrachten Sie dieses Beispiel: @example (define libressl-statt-openssl ;; Dies ist eine Prozedur, mit der OPENSSL durch LIBRESSL ;; rekursiv ersetzt wird. (package-input-rewriting `((,openssl . ,libressl)))) (define git-mit-libressl (libressl-statt-openssl git)) @end example @noindent Hier definieren wir zuerst eine Umschreibeprozedur, die @var{openssl} durch @var{libressl} ersetzt. Dann definieren wir damit eine @dfn{Variante} des @var{git}-Pakets, die @var{libressl} statt @var{openssl} benutzt. Das ist genau, was auch die Befehlszeilenoption @option{--with-input} tut (siehe @ref{Paketumwandlungsoptionen, @option{--with-input}}). The following variant of @code{package-input-rewriting} can match packages to be replaced by name rather than by identity. @deffn {Scheme-Prozedur} package-input-rewriting/spec @var{Ersetzungen} Return a procedure that, given a package, applies the given @var{replacements} to all the package graph (excluding implicit inputs). @var{replacements} is a list of spec/procedures pair; each spec is a package specification such as @code{"gcc"} or @code{"guile@@2"}, and each procedure takes a matching package and returns a replacement for that package. @end deffn The example above could be rewritten this way: @example (define libressl-statt-openssl ;; Rekursiv alle Pakete namens "openssl" durch LibreSSL ersetzen. (package-input-rewriting/spec `(("openssl" . ,(const libressl))))) @end example The key difference here is that, this time, packages are matched by spec and not by identity. In other words, any package in the graph that is called @code{openssl} will be replaced. Eine allgemeiner anwendbare Prozedur, um den Abhängigkeitsgraphen eines Pakets umzuschreiben, ist @code{package-mapping}. Sie unterstützt beliebige Änderungen an den Knoten des Graphen. @deffn {Scheme-Prozedur} package-mapping @var{Prozedur} [@var{Schnitt?}] Liefert eine Prozedur, die, wenn ihr ein Paket übergeben wird, die an @code{package-mapping} übergebene @var{Prozedur} auf alle vom Paket abhängigen Pakete anwendet. Die Prozedur liefert das resultierende Paket. Wenn @var{Schnitt?} für ein Paket davon einen wahren Wert liefert, findet kein rekursiver Abstieg in dessen Abhängigkeiten statt. @end deffn @menu * »package«-Referenz:: Der Datentyp für Pakete. * »origin«-Referenz:: Datentyp für Paketursprünge. @end menu @node »package«-Referenz @subsection @code{package}-Referenz Dieser Abschnitt fasst alle in @code{package}-Deklarationen zur Verfügung stehenden Optionen zusammen (siehe @ref{Pakete definieren}). @deftp {Datentyp} package Dieser Datentyp steht für ein Paketrezept. @table @asis @item @code{name} Der Name des Pakets als Zeichenkette. @item @code{version} Die Version des Pakets als Zeichenkette. @item @code{source} Ein Objekt, das beschreibt, wie der Quellcode des Pakets bezogen werden soll. Meistens ist es ein @code{origin}-Objekt, welches für eine aus dem Internet heruntergeladene Datei steht (siehe @ref{»origin«-Referenz}). Es kann aber auch ein beliebiges anderes »dateiähnliches« Objekt sein, wie z.B.@: ein @code{local-file}, was eine Datei im lokalen Dateisystem bezeichnet (siehe @ref{G-Ausdrücke, @code{local-file}}). @item @code{build-system} Das Erstellungssystem, mit dem das Paket erstellt werden soll (siehe @ref{Erstellungssysteme}). @item @code{arguments} (Vorgabe: @code{'()}) Die Argumente, die an das Erstellungssystem übergeben werden sollen. Dies ist eine Liste, typischerweise eine Reihe von Schlüssel-Wert-Paaren. @item @code{inputs} (Vorgabe: @code{'()}) @itemx @code{native-inputs} (Vorgabe: @code{'()}) @itemx @code{propagated-inputs} (Vorgabe: @code{'()}) @cindex Eingaben, von Paketen In diesen Feldern werden die Abhängigkeiten des Pakets aufgeführt. Jedes dieser Felder enthält eine Liste von Tupeln, wobei jedes Tupel eine Bezeichnung für die Eingabe (als Zeichenkette) als erstes Element, dann ein »package«-, »origin«- oder »derivation«-Objekt (Paket, Ursprung oder Ableitung) als zweites Element und optional die Benennung der davon zu benutzenden Ausgabe umfasst; letztere hat als Vorgabewert @code{"out"} (siehe @ref{Pakete mit mehreren Ausgaben.} für mehr Informationen zu Paketausgaben). Im folgenden Beispiel etwa werden drei Eingaben festgelegt: @example `(("libffi" ,libffi) ("libunistring" ,libunistring) ("glib:bin" ,glib "bin")) ;Ausgabe "bin" von Glib @end example @cindex Cross-Kompilieren, Paketabhängigkeiten Die Unterscheidung zwischen @code{native-inputs} und @code{inputs} ist wichtig, damit Cross-Kompilieren möglich ist. Beim Cross-Kompilieren werden als @code{inputs} aufgeführte Abhängigkeiten für die Ziel-Prozessorarchitektur (@emph{target}) erstellt, andersherum werden als @code{native-inputs} aufgeführte Abhängigkeiten für die Prozessorarchitektur der erstellenden Maschine (@emph{build}) erstellt. @code{native-inputs} listet typischerweise die Werkzeuge auf, die während der Erstellung gebraucht werden, aber nicht zur Laufzeit des Programms gebraucht werden. Beispiele sind Autoconf, Automake, pkg-config, Gettext oder Bison. @command{guix lint} kann melden, ob wahrscheinlich Fehler in der Auflistung sind (siehe @ref{Aufruf von guix lint}). @anchor{package-propagated-inputs} Schließlich ist @code{propagated-inputs} ähnlich wie @code{inputs}, aber die angegebenen Pakete werden automatisch mit ins Profil installiert, wenn das Paket installiert wird, zu dem sie gehören (siehe @ref{package-cmd-propagated-inputs, @command{guix package}} für Informationen darüber, wie @command{guix package} mit propagierten Eingaben umgeht). Dies ist zum Beispiel nötig, wenn eine C-/C++-Bibliothek Header-Dateien einer anderen Bibliothek braucht, um mit ihr kompilieren zu können, oder wenn sich eine pkg-config-Datei auf eine andere über ihren @code{Requires}-Eintrag bezieht. Noch ein Beispiel, wo @code{propagated-inputs} nützlich ist, sind Sprachen, die den Laufzeit-Suchpfad @emph{nicht} zusammen mit dem Programm abspeichern (@emph{nicht} wie etwa im @code{RUNPATH} bei ELF-Dateien), also Sprachen wie Guile, Python, Perl und weitere. Damit auch in solchen Sprachen geschriebene Bibliotheken zur Laufzeit den von ihnen benötigten Code finden können, müssen deren Laufzeit-Abhängigkeiten in @code{propagated-inputs} statt in @code{inputs} aufgeführt werden. @item @code{outputs} (Vorgabe: @code{'("out")}) Die Liste der Benennungen der Ausgaben des Pakets. Der Abschnitt @ref{Pakete mit mehreren Ausgaben.} beschreibt übliche Nutzungen zusätzlicher Ausgaben. @item @code{native-search-paths} (Vorgabe: @code{'()}) @itemx @code{search-paths} (Vorgabe: @code{'()}) Eine Liste von @code{search-path-specification}-Objekten, die Umgebungsvariable für von diesem Paket beachtete Suchpfade (»search paths«) beschreiben. @item @code{replacement} (Vorgabe: @code{#f}) Dies muss entweder @code{#f} oder ein package-Objekt sein, das als Ersatz (@dfn{replacement}) dieses Pakets benutzt werden soll. Im Abschnitt @ref{Sicherheitsaktualisierungen, grafts} wird dies erklärt. @item @code{synopsis} Eine einzeilige Beschreibung des Pakets. @item @code{description} Eine ausführlichere Beschreibung des Pakets. @item @code{license} @cindex Lizenz, von Paketen Die Lizenz des Pakets; benutzt werden kann ein Wert aus dem Modul @code{(guix licenses)} oder eine Liste solcher Werte. @item @code{home-page} Die URL, die die Homepage des Pakets angibt, als Zeichenkette. @item @code{supported-systems} (Vorgabe: @var{%supported-systems}) Die Liste der vom Paket unterstützten Systeme als Zeichenketten der Form @code{Architektur-Kernel}, zum Beispiel @code{"x86_64-linux"}. @item @code{maintainers} (Vorgabe: @code{'()}) Die Liste der Betreuer (Maintainer) des Pakets als @code{maintainer}-Objekte. @item @code{location} (Vorgabe: die Stelle im Quellcode, wo die @code{package}-Form steht) Wo im Quellcode das Paket definiert wurde. Es ist sinnvoll, dieses Feld manuell zuzuweisen, wenn das Paket von einem anderen Paket erbt, weil dann dieses Feld nicht automatisch berichtigt wird. @end table @end deftp @deffn {Scheme Syntax} this-package When used in the @emph{lexical scope} of a package field definition, this identifier resolves to the package being defined. The example below shows how to add a package as a native input of itself when cross-compiling: @example (package (name "guile") ;; ... ;; When cross-compiled, Guile, for example, depends on ;; a native version of itself. Add it here. (native-inputs (if (%current-target-system) `(("self" ,this-package)) '()))) @end example It is an error to refer to @code{this-package} outside a package definition. @end deffn @node »origin«-Referenz @subsection @code{origin}-Referenz Dieser Abschnitt fasst alle Optionen zusammen, die in @code{origin}-Deklarationen zur Verfügung stehen (siehe @ref{Pakete definieren}). @deftp {Datentyp} origin Mit diesem Datentyp wird ein Ursprung, von dem Quellcode geladen werden kann, beschrieben. @table @asis @item @code{uri} Ein Objekt, was die URI des Quellcodes enthält. Der Objekttyp hängt von der @code{Methode} ab (siehe unten). Zum Beispiel sind, wenn die @var{url-fetch}-Methode aus @code{(guix download)} benutzt wird, die gültigen Werte für @code{uri}: eine URL dargestellt als Zeichenkette oder eine Liste solcher URLs. @item @code{method} Eine Prozedur, die die URI verwertet. Beispiele sind unter anderem: @table @asis @item @var{url-fetch} aus @code{(guix download)} Herunterladen einer Datei von einer HTTP-, HTTPS- oder FTP-URL, die im @code{uri}-Feld angegeben wurde. @vindex git-fetch @item @var{git-fetch} aus @code{(guix git-download)} Das im @code{uri}-Feld spezifizierte Repository des Git-Versionskontrollsystems klonen und davon den im @code{uri}-Feld als ein @code{git-reference}-Objekt angegebenen Commit benutzen; eine @code{git-reference} sieht so aus: @example (git-reference (url "git://git.debian.org/git/pkg-shadow/shadow") (commit "v4.1.5.1")) @end example @end table @item @code{sha256} Ein Bytevektor, der den SHA-256-Hash der Quelldateien enthält. Typischerweise wird hier mit der @code{base32}-Form der Bytevektor aus einer Base-32-Zeichenkette generiert. Diese Informationen liefert Ihnen der Befehl @code{guix download} (siehe @ref{Aufruf von guix download}) oder @code{guix hash} (siehe @ref{Aufruf von guix hash}). @item @code{file-name} (Vorgabe: @code{#f}) Der Dateiname, unter dem der Quellcode abgespeichert werden sollte. Wenn er auf @code{#f} steht, wird ein vernünftiger Name automatisch gewählt. Falls der Quellcode von einer URL geladen wird, wird der Dateiname aus der URL genommen. Wenn der Quellcode von einem Versionskontrollsystem bezogen wird, empfiehlt es sich, den Dateinamen ausdrücklich anzugeben, weil dann keine sprechende Benennung automatisch gefunden werden kann. @item @code{patches} (Vorgabe: @code{'()}) Eine Liste von Dateinamen, Ursprüngen oder dateiähnlichen Objekten (siehe @ref{G-Ausdrücke, file-like objects}) mit Patches, welche auf den Quellcode anzuwenden sind. Die Liste von Patches kann nicht von Parametern der Erstellung abhängen. Insbesondere kann sie nicht vom Wert von @code{%current-system} oder @code{%current-target-system} abḧängen. @item @code{snippet} (Vorgabe: @code{#f}) Ein im Quellcode-Verzeichnis auszuführender G-Ausdruck (siehe @ref{G-Ausdrücke}) oder S-Ausdruck. Hiermit kann der Quellcode bequem modifiziert werden, manchmal ist dies bequemer als mit einem Patch. @item @code{patch-flags} (Vorgabe: @code{'("-p1")}) Eine Liste der Befehlszeilenoptionen, die dem @code{patch}-Befehl übergeben werden sollen. @item @code{patch-inputs} (Vorgabe: @code{#f}) Eingabepakete oder -ableitungen für den Patch-Prozess. Bei @code{#f} werden die üblichen Patcheingaben wie GNU@tie{}Patch bereitgestellt. @item @code{modules} (Vorgabe: @code{'()}) Eine Liste von Guile-Modulen, die während des Patch-Prozesses und während der Ausführung des @code{snippet}-Felds geladen werden sollten. @item @code{patch-guile} (Vorgabe: @code{#f}) Welches Guile-Paket für den Patch-Prozess benutzt werden sollte. Bei @code{#f} wird ein vernünftiger Vorgabewert angenommen. @end table @end deftp @node Erstellungssysteme @section Erstellungssysteme @cindex Erstellungssystem Jede Paketdefinition legt ein @dfn{Erstellungssystem} (»build system«) sowie dessen Argumente fest (siehe @ref{Pakete definieren}). Das @code{build-system}-Feld steht für die Erstellungsprozedur des Pakets sowie für weitere implizite Eingaben für die Erstellungsprozedur. Erstellungssysteme sind @code{}-Objekte. Die Schnittstelle, um solche zu erzeugen und zu verändern, ist im Modul @code{(guix build-system)} zu finden, und die eigentlichen Erstellungssysteme werden jeweils von ihren eigenen Modulen exportiert. @cindex Bag (systemnahe Paketrepräsentation) Intern funktionieren Erstellungssysteme, indem erst Paketobjekte zu @dfn{Bags} kompiliert werden. Eine Bag (deutsch: Beutel, Sack) ist wie ein Paket, aber mit weniger Zierrat — anders gesagt ist eine Bag eine systemnähere Darstellung eines Pakets, die sämtliche Eingaben des Pakets einschließlich vom Erstellungssystem hinzugefügter Eingaben enthält. Diese Zwischendarstellung wird dann zur eigentlichen Ableitung kompiliert (siehe @ref{Ableitungen}). Erstellungssysteme akzeptieren optional eine Liste von @dfn{Argumenten}. In Paketdefinitionen werden diese über das @code{arguments}-Feld übergeben (siehe @ref{Pakete definieren}). Sie sind in der Regel Schlüsselwort-Argumente (siehe @ref{Optional Arguments, keyword arguments in Guile,, guile, GNU Guile Reference Manual}). Der Wert dieser Argumente wird normalerweise vom Erstellungssystem in der @dfn{Erstellungsschicht} ausgewertet, d.h.@: von einem durch den Daemon gestarteten Guile-Prozess (siehe @ref{Ableitungen}). Das häufigste Erstellungssystem ist @var{gnu-build-system}, was die übliche Erstellungsprozedur für GNU-Pakete und viele andere Pakete darstellt. Es wird vom Modul @code{(guix build-system gnu)} bereitgestellt. @defvr {Scheme-Variable} gnu-build-system @var{gnu-build-system} steht für das GNU-Erstellungssystem und Varianten desselben (siehe @ref{Configuration, configuration and makefile conventions,, standards, GNU Coding Standards}). @cindex Erstellungsphasen Kurz gefasst werden Pakete, die es benutzen, konfiguriert, erstellt und installiert mit der üblichen Befehlsfolge @code{./configure && make && make check && make install}. In der Praxis braucht man oft noch ein paar weitere Schritte. Alle Schritte sind in voneinander getrennte @dfn{Phasen} unterteilt. Erwähnt werden sollten@footnote{Bitte schauen Sie in den Modulen unter @code{(guix build gnu-build-system)}, wenn Sie mehr Details zu Erstellungsphasen brauchen.}: @table @code @item unpack Den Quell-Tarball entpacken und das Arbeitsverzeichnis wechseln in den entpackten Quellbaum. Wenn die Quelle bereits ein Verzeichnis ist, wird es in den Quellbaum kopiert und dorthin gewechselt. @item patch-source-shebangs »Shebangs« in Quelldateien beheben, damit Sie sich auf die richtigen Store-Dateipfade beziehen. Zum Beispiel könnte @code{#!/bin/sh} zu @code{#!/gnu/store/@dots{}-bash-4.3/bin/sh} geändert werden. @item configure Das Skript @file{configure} mit einigen vorgegebenen Befehlszeilenoptionen ausführen, wie z.B.@: mit @code{--prefix=/gnu/store/@dots{}}, sowie mit den im @code{#:configure-flags}-Argument angegebenen Optionen. @item build @code{make} ausführen mit den Optionen aus der Liste in @code{#:make-flags}. Wenn das Argument @code{#:parallel-build?} auf wahr gesetzt ist (was der Vorgabewert ist), wird @code{make -j} zum Erstellen ausgeführt. @item check @code{make check} (oder statt @code{check} ein anderes bei @code{#:test-target} angegebenes Ziel) ausführen, außer falls @code{#:tests? #f} gesetzt ist. Wenn das Argument @code{#:parallel-tests?} auf wahr gesetzt ist (der Vorgabewert), führe @code{make check -j} aus. @item install @code{make install} mit den in @code{#:make-flags} aufgelisteten Optionen ausführen. @item patch-shebangs Shebangs in den installierten ausführbaren Dateien beheben. @item strip Symbole zur Fehlerbehebung aus ELF-Dateien entfernen (außer @code{#:strip-binaries?} ist auf falsch gesetzt) und in die @code{debug}-Ausgabe kopieren, falls diese verfügbar ist (siehe @ref{Dateien zur Fehlersuche installieren}). @end table @vindex %standard-phases Das erstellungsseitige Modul @code{(guix build gnu-build-system)} definiert @var{%standard-phases} als die vorgegebene Liste der Erstellungsphasen. @var{%standard-phases} ist eine Liste von Paaren aus je einem Symbol und einer Prozedur. Letztere implementiert die eigentliche Phase. Die Liste der Phasen, die für ein bestimmtes Paket verwendet werden sollen, kann vom Parameter @code{#:phases} überschrieben werden. Zum Beispiel werden bei Übergabe von: @example #:phases (modify-phases %standard-phases (delete 'configure)) @end example alle oben beschriebenen Phasen benutzt außer der @code{configure}-Phase. Zusätzlich stellt dieses Erstellungssystem sicher, dass die »Standard«-Umgebung für GNU-Pakete zur Verfügung steht. Diese umfasst Werkzeuge wie GCC, libc, Coreutils, Bash, Make, Diffutils, grep und sed (siehe das Modul @code{(guix build-system gnu)} für eine vollständige Liste). Wir bezeichnen sie als @dfn{implizite Eingaben} eines Pakets, weil Paketdefinitionen sie nicht aufführen müssen. @end defvr Andere @code{}-Objekte werden definiert, um andere Konventionen und Werkzeuge von Paketen für freie Software zu unterstützen. Die anderen Erstellungssysteme erben den Großteil vom @var{gnu-build-system} und unterscheiden sich hauptsächlich darin, welche Eingaben dem Erstellungsprozess implizit hinzugefügt werden und welche Liste von Phasen durchlaufen wird. Manche dieser Erstellungssysteme sind im Folgenden aufgeführt. @defvr {Scheme-Variable} ant-build-system Diese Variable wird vom Modul @code{(guix build-system ant)} exportiert. Sie implementiert die Erstellungsprozedur für Java-Pakete, die mit dem @url{http://ant.apache.org/, Ant build tool} erstellt werden können. Sowohl @code{ant} als auch der @dfn{Java Development Kit} (JDK), wie er vom Paket @code{icedtea} bereitgestellt wird, werden zu den Eingaben hinzugefügt. Wenn andere Pakete dafür benutzt werden sollen, können sie jeweils mit den Parametern @code{#:ant} und @code{#:jdk} festgelegt werden. Falls das ursprüngliche Paket über keine nutzbare Ant-Erstellungsdatei (»Ant-Buildfile«) verfügt, kann aus der Angabe im Parameter @code{#:jar-name} eine minimale Ant-Erstellungsdatei @file{build.xml} erzeugt werden, in der die für die Erstellung durchzuführenden Aufgaben (Tasks) für die Erstellung des angegebenen Jar-Archivs stehen. In diesem Fall kann der Parameter @code{#:source-dir} benutzt werden, um das Unterverzeichnis mit dem Quellcode anzugeben; sein Vorgabewert ist »src«. Der Parameter @code{#:main-class} kann mit einer minimalen Ant-Erstellungsdatei benutzt werden, um die Hauptklasse des resultierenden Jar-Archivs anzugeben. Dies ist nötig, wenn die Jar-Datei ausführbar sein soll. Mit dem Parameter @code{#:test-include} kann eine Liste angegeben werden, welche Junit-Tests auszuführen sind. Der Vorgabewert ist @code{(list "**/*Test.java")}. Mit @code{#:test-exclude} kann ein Teil der Testdateien ignoriert werden. Der Vorgabewert ist @code{(list "**/Abstract*.java")}, weil abstrakte Klassen keine ausführbaren Tests enthalten können. Der Parameter @code{#:build-target} kann benutzt werden, um die Ant-Aufgabe (Task) anzugeben, die während der @code{build}-Phase ausgeführt werden soll. Vorgabe ist, dass die Aufgabe (Task) »jar« ausgeführt wird. @end defvr @defvr {Scheme-Variable} android-ndk-build-system @cindex Android-Distribution @cindex Android-NDK-Erstellungssystem Diese Variable wird von @code{(guix build-system android-ndk)} exportiert. Sie implementiert eine Erstellungsprozedur für das Android NDK (Native Development Kit) benutzende Pakete mit einem Guix-spezifischen Erstellungsprozess. Für das Erstellungssystem wird angenommen, dass Pakete die zu ihrer öffentlichen Schnittstelle gehörenden Header-Dateien im Unterverzeichnis "include" der Ausgabe "out" und ihre Bibliotheken im Unterverzeichnis "lib" der Ausgabe "out" platzieren. Ebenso wird angenommen, dass es keine im Konflikt stehenden Dateien unter der Vereinigung aller Abhängigkeiten gibt. Derzeit wird Cross-Kompilieren hierfür nicht unterstützt, also wird dabei vorausgesetzt, dass Bibliotheken und Header-Dateien dieselben wie im Wirtssystem sind. @end defvr @defvr {Scheme-Variable} asdf-build-system/source @defvrx {Scheme-Variable} asdf-build-system/sbcl @defvrx {Scheme-Variable} asdf-build-system/ecl Diese Variablen, die vom Modul @code{(guix build-system asdf)} exportiert werden, implementieren Erstellungsprozeduren für Common-Lisp-Pakete, welche @url{https://common-lisp.net/project/asdf/, »ASDF«} benutzen. ASDF dient der Systemdefinition für Common-Lisp-Programme und -Bibliotheken. Das Erstellungssystem @code{asdf-build-system/source} installiert die Pakete in Quellcode-Form und kann @i{via} ASDF mit jeder Common-Lisp-Implementierung geladen werden. Die anderen Erstellungssysteme wie @code{asdf-build-system/sbcl} installieren binäre Systeme in dem Format, das von einer bestimmten Implementierung verstanden wird. Diese Erstellungssysteme können auch benutzt werden, um ausführbare Programme zu erzeugen oder um Lisp-Abbilder mit einem vorab geladenen Satz von Paketen zu erzeugen. Das Erstellungssystem benutzt gewisse Namenskonventionen. Bei Binärpaketen sollte dem Paketnamen die Lispimplementierung als Präfix vorangehen, z.B.@: @code{sbcl-} für @code{asdf-build-system/sbcl}. Zudem sollte das entsprechende Quellcode-Paket mit der Konvention wie bei Python-Paketen (siehe @ref{Python-Module}) ein @code{cl-} als Präfix bekommen. Für Binärpakete sollte für jedes System ein Guix-Paket definiert werden. Wenn für einen Ursprung im @code{origin} mehrere Systeme enthalten sind, können Paketvarianten geschrieben werden, mit denen alle Systeme erstellt werden. Quellpakete, die @code{asdf-build-system/source} benutzen, können mehrere Systeme enthalten. Um ausführbare Programme und Abbilder zu erzeugen, können die erstellungsseitigen Prozeduren @code{build-program} und @code{build-image} benutzt werden. Sie sollten in einer Erstellungsphase nach der @code{create-symlinks}-Phase aufgerufen werden, damit das gerade erstellte System Teil des resultierenden Abbilds sein kann. An @code{build-program} muss eine Liste von Common-Lisp-Ausdrücken über das Argument @code{#:entry-program} übergeben werden. Wenn das System nicht in seiner eigenen gleichnamigen @code{.asd}-Datei definiert ist, sollte der Parameter @code{#:asd-file} benutzt werden, um anzugeben, in welcher Datei das System definiert ist. Außerdem wird bei Paketen, für deren Tests ein System in einer separaten Datei definiert wurde, dieses System geladen, bevor die Tests ablaufen, wenn es im Parameter @code{#:test-asd-file} steht. Ist dafür kein Wert gesetzt, werden die Dateien @code{-tests.asd}, @code{-test.asd}, @code{tests.asd} und @code{test.asd} durchsucht, wenn sie existieren. Wenn aus irgendeinem Grund der Paketname nicht den Namenskonventionen folgen kann, kann der Parameter @code{#:asd-system-name} benutzt werden, um den Namen des Systems anzugeben. @end defvr @defvr {Scheme-Variable} cargo-build-system @cindex Rust-Programmiersprache @cindex Cargo (Rust-Erstellungssystem) Diese Variable wird vom Modul @code{(guix build-system cargo)} exportiert. Damit können Pakete mit Cargo erstellt werden, dem Erstellungswerkzeug der @uref{https://www.rust-lang.org, Rust-Programmiersprache}. In seiner @code{configure}-Phase ersetzt dieses Erstellungssystem in der Datei @file{Carto.toml} angegebene Abhängigkeiten durch Eingaben im Guix-Paket. Die Phase @code{install} installiert die Binärdateien und auch den Quellcode und die @file{Cargo.toml}-Datei. @end defvr @cindex Clojure (Programmiersprache) @cindex einfaches Clojure-Erstellungssystem @defvr {Scheme-Variable} clojure-build-system Diese Variable wird durch das Modul @code{(guix build-system clojure)} exportiert. Sie implementiert eine einfache Erstellungsprozedur für in @uref{https://clojure.org/, Clojure} geschriebene Pakete mit dem guten alten @code{compile} in Clojure. Cross-Kompilieren wird noch nicht unterstützt. Das Erstellungssystem fügt @code{clojure}, @code{icedtea} und @code{zip} zu den Eingaben hinzu. Sollen stattdessen andere Pakete benutzt werden, können diese jeweils mit den Parametern @code{#:clojure}, @code{#:jdk} und @code{#:zip} spezifiziert werden. Eine Liste der Quellcode-Verzeichnisse, Test-Verzeichnisse und Namen der Jar-Dateien können jeweils über die Parameter @code{#:source-dirs}, @code{#:test-dirs} und @code{#:jar-names} angegeben werden. Das Verzeichnis, in das kompiliert wird, sowie die Hauptklasse können jeweils mit den Parametern @code{#:compile-dir} und @code{#:main-class} angegeben werden. Andere Parameter sind im Folgenden dokumentiert. Dieses Erstellungssystem ist eine Erweiterung des @var{ant-build-system}, bei der aber die folgenden Phasen geändert wurden: @table @code @item build Diese Phase ruft @code{compile} in Clojure auf, um Quelldateien zu kompilieren, und führt @command{jar} aus, um Jar-Dateien aus sowohl Quelldateien als auch kompilierten Dateien zu erzeugen, entsprechend der jeweils in @code{#:aot-include} und @code{#:aot-exclude} festgelegten Listen aus in der Menge der Quelldateien eingeschlossenen und ausgeschlossenen Bibliotheken. Die Ausschlussliste hat Vorrang vor der Einschlussliste. Diese Listen setzen sich aus Symbolen zusammen, die für Clojure-Bibliotheken stehen oder dem Schlüsselwort @code{#:all} entsprechen, was für alle im Quellverzeichis gefundenen Clojure-Bibliotheken steht. Der Parameter @code{#:omit-source?} entscheidet, ob Quelldateien in die Jar-Archive aufgenommen werden sollten. @item check In dieser Phase werden Tests auf die durch Einschluss- und Ausschlussliste @code{#:test-include} bzw. @code{#:test-exclude} angegebenen Dateien ausgeführt. Deren Bedeutung ist analog zu @code{#:aot-include} und @code{#:aot-exclude}, außer dass das besondere Schlüsselwort @code{#:all} jetzt für alle Clojure-Bibliotheken in den Test-Verzeichnissen steht. Der Parameter @code{#:tests?} entscheidet, ob Tests ausgeführt werden sollen. @item install In dieser Phase werden alle zuvor erstellten Jar-Dateien installiert. @end table Zusätzlich zu den bereits angegebenen enthält dieses Erstellungssystem noch eine weitere Phase. @table @code @item install-doc Diese Phase installiert alle Dateien auf oberster Ebene, deren Basisnamen ohne Verzeichnisangabe zu @var{%doc-regex} passen. Ein anderer regulärer Ausdruck kann mit dem Parameter @code{#:doc-regex} verwendet werden. All die so gefundenen oder (rekursiv) in den mit @code{#:doc-dirs} angegebenen Dokumentationsverzeichnissen liegenden Dateien werden installiert. @end table @end defvr @defvr {Scheme-Variable} cmake-build-system Diese Variable wird von @code{(guix build-system cmake)} exportiert. Sie implementiert die Erstellungsprozedur für Pakete, die das @url{http://www.cmake.org, CMake-Erstellungswerkzeug} benutzen. Das Erstellungssystem fügt automatisch das Paket @code{cmake} zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter @code{#:cmake} geändert werden. Der Parameter @code{#:configure-flags} wird als Liste von Befehlszeilenoptionen aufgefasst, die an den Befehl @command{cmake} übergeben werden. Der Parameter @code{#:build-type} abstrahiert, welche Befehlszeilenoptionen dem Compiler übergeben werden; der Vorgabewert ist @code{"RelWithDebInfo"} (kurz für »release mode with debugging information«), d.h.@: kompiliert wird für eine Produktionsumgebung und Informationen zur Fehlerbehebung liegen bei, was ungefähr @code{-O2 -g} entspricht, wie bei der Vorgabe für Autoconf-basierte Pakete. @end defvr @defvr {Scheme-Variable} dune-build-system Diese Variable wird vom Modul @code{(guix build-system dune)} exportiert. Sie unterstützt es, Pakete mit @uref{https://dune.build/, Dune} zu erstellen, einem Erstellungswerkzeug für die Programmiersprache OCaml, und ist als Erweiterung des unten beschriebenen OCaml-Erstellungssystems @code{ocaml-build-system} implementiert. Als solche können auch die Parameter @code{#:ocaml} und @code{#:findlib} an dieses Erstellungssystem übergeben werden. Das Erstellungssystem fügt automatisch das Paket @code{dune} zu den Eingaben hinzu. Welches Paket benutzt wird, kann mit dem Parameter @code{#:dune} geändert werden. There is no @code{configure} phase because dune packages typically don't need to be configured. The @code{#:build-flags} parameter is taken as a list of flags passed to the @code{dune} command during the build. The @code{#:jbuild?} parameter can be passed to use the @code{jbuild} command instead of the more recent @code{dune} command while building a package. Its default value is @code{#f}. The @code{#:package} parameter can be passed to specify a package name, which is useful when a package contains multiple packages and you want to build only one of them. This is equivalent to passing the @code{-p} argument to @code{dune}. @end defvr @defvr {Scheme-Variable} go-build-system Diese Variable wird vom Modul @code{(guix build-system go)} exportiert. Mit ihr ist eine Erstellungsprozedur für Go-Pakete implementiert, die dem normalen @url{https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies, Go-Erstellungsmechanismus} entspricht. Beim Aufruf wird ein Wert für den Schlüssel @code{#:import-path} und manchmal auch für @code{#:unpack-path} erwartet. Der @url{https://golang.org/doc/code.html#ImportPaths, »import path«} entspricht dem Dateisystempfad, den die Erstellungsskripts des Pakets und darauf Bezug nehmende Pakete erwarten; durch ihn wird ein Go-Paket eindeutig bezeichnet. Typischerweise setzt er sich aus einer Kombination der entfernten URI des Paketquellcodes und der Dateisystemhierarchie zusammen. Manchmal ist es nötig, den Paketquellcode in ein anderes als das vom »import path« bezeichnete Verzeichnis zu entpacken; diese andere Verzeichnisstruktur sollte dann als @code{#:unpack-path} angegeben werden. Pakete, die Go-Bibliotheken zur Verfügung stellen, sollten ihren Quellcode auch in die Erstellungsausgabe installieren. Der Schlüssel @code{#:install-source?}, sein Vorgabewert ist @code{#t}, steuert, ob Quellcode installiert wird. Bei Paketen, die nur ausführbare Dateien liefern, kann der Wert auf @code{#f} gesetzt werden. @end defvr @defvr {Scheme-Variable} glib-or-gtk-build-system Diese Variable wird vom Modul @code{(guix build-system glib-or-gtk)} exportiert. Sie ist für Pakete gedacht, die GLib oder GTK benutzen. Dieses Erstellungssystem fügt die folgenden zwei Phasen zu denen von @var{gnu-build-system} hinzu: @table @code @item glib-or-gtk-wrap Die Phase @code{glib-or-gtk-wrap} stellt sicher, dass Programme in @file{bin/} in der Lage sind, GLib-»Schemata« und @uref{https://developer.gnome.org/gtk3/stable/gtk-running.html, GTK-Module} zu finden. Dazu wird für das Programm ein Wrapper-Skript erzeugt, dass das eigentliche Programm mit den richtigen Werten für die Umgebungsvariablen @code{XDG_DATA_DIRS} und @code{GTK_PATH} aufruft. Es ist möglich, bestimmte Paketausgaben von diesem Wrapping-Prozess auszunehmen, indem Sie eine Liste ihrer Namen im Parameter @code{#:glib-or-gtk-wrap-excluded-outputs} angeben. Das ist nützlich, wenn man von einer Ausgabe weiß, dass sie keine Binärdateien enthält, die GLib oder GTK benutzen, und diese Ausgabe durch das Wrappen ohne Not eine weitere Abhängigkeit von GLib und GTK bekäme. @item glib-or-gtk-compile-schemas Mit der Phase @code{glib-or-gtk-compile-schemas} wird sichergestellt, dass alle @uref{https://developer.gnome.org/gio/stable/glib-compile-schemas.html, GSettings-Schemata} für GLib kompiliert werden. Dazu wird das Programm @command{glib-compile-schemas} ausgeführt. Es kommt aus dem Paket @code{glib:bin}, was automatisch vom Erstellungssystem importiert wird. Welches @code{glib}-Paket dieses @command{glib-compile-schemas} bereitstellt, kann mit dem Parameter @code{#:glib} spezifiziert werden. @end table Beide Phasen finden nach der @code{install}-Phase statt. @end defvr @defvr {Scheme-Variable} guile-build-system Dieses Erstellungssystem ist für Guile-Pakete gedacht, die nur aus Scheme-Code bestehen und so schlicht sind, dass sie nicht einmal ein Makefile und erst recht keinen @file{configure}-Skript enthalten. Hierzu wird Scheme-Code mit @command{guild compile} kompiliert (siehe @ref{Compilation,,, guile, GNU Guile Reference Manual}) und die @file{.scm}- und @file{.go}-Dateien an den richtigen Pfad installiert. Auch Dokumentation wird installiert. Das Erstellungssystem unterstützt Cross-Kompilieren durch die Befehlszeilenoption @code{--target} für @command{guild compile}. Mit @code{guile-build-system} erstellte Pakete müssen ein Guile-Paket in ihrem @code{native-inputs}-Feld aufführen. @end defvr @defvr {Scheme-Variable} minify-build-system Diese Variable wird vom Modul @code{(guix build-system minify)} exportiert. Sie implementiert eine Prozedur zur Minifikation einfacher JavaScript-Pakete. Es fügt @code{uglify-js} zur Menge der Eingaben hinzu und komprimiert damit alle JavaScript-Dateien im @file{src}-Verzeichnis. Ein anderes Programm zur Minifikation kann verwendet werden, indem es mit dem Parameter @code{#:uglify-js} angegeben wird; es wird erwartet, dass das angegebene Paket den minifizierten Code auf der Standardausgabe ausgibt. Wenn die Eingabe-JavaScript-Dateien nicht alle im @file{src}-Verzeichnis liegen, kann mit dem Parameter @code{#:javascript-files} eine Liste der Dateinamen übergeben werden, auf die das Minifikationsprogramm aufgerufen wird. @end defvr @defvr {Scheme-Variable} ocaml-build-system Diese Variable wird vom Modul @code{(guix build-system ocaml)} exportiert. Mit ihr ist ein Erstellungssystem für @uref{https://ocaml.org, OCaml}-Pakete implementiert, was bedeutet, dass es die richtigen auszuführenden Befehle für das jeweilige Paket auswählt. OCaml-Pakete können sehr unterschiedliche Befehle erwarten. Dieses Erstellungssystem probiert manche davon durch. Wenn im Paket eine Datei @file{setup.ml} auf oberster Ebene vorhanden ist, wird @code{ocaml setup.ml -configure}, @code{ocaml setup.ml -build} und @code{ocaml setup.ml -install} ausgeführt. Das Erstellungssystem wird annehmen, dass die Datei durch @uref{http://oasis.forge.ocamlcore.org/, OASIS} erzeugt wurde, und wird das Präfix setzen und Tests aktivieren, wenn diese nicht abgeschaltet wurden. Sie können Befehlszeilenoptionen zum Konfigurieren und Erstellen mit den Parametern @code{#:configure-flags} und @code{#:build-flags} übergeben. Der Schlüssel @code{#:test-flags} kann übergeben werden, um die Befehlszeilenoptionen zu ändern, mit denen die Tests aktiviert werden. Mit dem Parameter @code{#:use-make?} kann dieses Erstellungssystem für die build- und install-Phasen abgeschaltet werden. Verfügt das Paket über eine @file{configure}-Datei, wird angenommen, dass diese von Hand geschrieben wurde mit einem anderen Format für Argumente als bei einem Skript des @code{gnu-build-system}. Sie können weitere Befehlszeilenoptionen mit dem Schlüssel @code{#:configure-flags} hinzufügen. Falls dem Paket ein @file{Makefile} beiliegt (oder @code{#:use-make?} auf @code{#t} gesetzt wurde), wird dieses benutzt und weitere Befehlszeilenoptionen können mit dem Schlüssel @code{#:make-flags} zu den build- und install-Phasen hinzugefügt werden. Letztlich gibt es in manchen Pakete keine solchen Dateien, sie halten sich aber an bestimmte Konventionen, wo ihr eigenes Erstellungssystem zu finden ist. In diesem Fall führt Guix’ OCaml-Erstellungssystem @code{ocaml pkg/pkg.ml} oder @code{ocaml pkg/build.ml} aus und kümmert sich darum, dass der Pfad zu dem benötigten findlib-Modul passt. Weitere Befehlszeilenoptionen können über den Schlüssel @code{#:build-flags} übergeben werden. Um die Installation kümmert sich @command{opam-installer}. In diesem Fall muss das @code{opam}-Paket im @code{native-inputs}-Feld der Paketdefinition stehen. Beachten Sie, dass die meisten OCaml-Pakete davon ausgehen, dass sie in dasselbe Verzeichnis wie OCaml selbst installiert werden, was wir in Guix aber nicht so haben wollen. Solche Pakete installieren ihre @file{.so}-Dateien in das Verzeichnis ihres Moduls, was für die meisten anderen Einrichtungen funktioniert, weil es im OCaml-Compilerverzeichnis liegt. Jedoch können so in Guix die Bibliotheken nicht gefunden werden, deswegen benutzen wir @code{CAML_LD_LIBRARY_PATH}. Diese Umgebungsvariable zeigt auf @file{lib/ocaml/site-lib/stubslibs} und dorthin sollten @file{.so}-Bibliotheken installiert werden. @end defvr @defvr {Scheme-Variable} python-build-system Diese Variable wird vom Modul @code{(guix build-system python)} exportiert. Sie implementiert mehr oder weniger die konventionelle Erstellungsprozedur, wie sie für Python-Pakete üblich ist, d.h.@: erst wird @code{python setup.py build} ausgeführt und dann @code{python setup.py install --prefix=/gnu/store/@dots{}}. Für Pakete, die eigenständige Python-Programme nach @code{bin/} installieren, sorgt dieses Erstellungssystem dafür, dass die Programme in ein Wrapper-Skript verpackt werden, welches die eigentlichen Programme mit einer Umgebungsvariablen @code{PYTHONPATH} aufruft, die alle Python-Bibliotheken auflistet, von denen die Programme abhängen. Welches Python-Paket benutzt wird, um die Erstellung durchzuführen, kann mit dem Parameter @code{#:python} bestimmt werden. Das ist nützlich, wenn wir erzwingen wollen, dass ein Paket mit einer bestimmten Version des Python-Interpretierers arbeitet, was nötig sein kann, wenn das Programm nur mit einer einzigen Interpretiererversion kompatibel ist. Standardmäßig ruft Guix @code{setup.py} auf, was zu @code{setuptools} gehört, ähnlich wie es auch @command{pip} tut. Manche Pakete sind mit setuptools (und pip) inkompatibel, deswegen können Sie diese Einstellung abschalten, indem Sie den Parameter @code{#:use-setuptools} auf @code{#f} setzen. @end defvr @defvr {Scheme-Variable} perl-build-system Diese Variable wird vom Modul @code{(guix build-system perl)} exportiert. Mit ihr wird die Standard-Erstellungsprozedur für Perl-Pakete implementiert, welche entweder darin besteht, @code{perl Build.PL --prefix=/gnu/store/@dots{}} gefolgt von @code{Build} und @code{Build install} auszuführen, oder @code{perl Makefile.PL PREFIX=/gnu/store/@dots{}} gefolgt von @code{make} und @code{make install} auszuführen, je nachdem, ob eine Datei @code{Build.PL} oder eine Datei @code{Makefile.PL} in der Paketdistribution vorliegt. Den Vorrang hat erstere, wenn sowohl @code{Build.PL} als auch @code{Makefile.PL} in der Paketdistribution existieren. Der Vorrang kann umgekehrt werden, indem @code{#t} für den Parameter @code{#:make-maker?} angegeben wird. Der erste Aufruf von @code{perl Makefile.PL} oder @code{perl Build.PL} übergibt die im Parameter @code{#:make-maker-flags} bzw. @code{#:module-build-flags} angegebenen Befehlszeilenoptionen, je nachdem, was verwendet wird. Welches Perl-Paket dafür benutzt wird, kann mit @code{#:perl} angegeben werden. @end defvr @defvr {Scheme-Variable} r-build-system Diese Variable wird vom Modul @code{(guix build-system r)} exportiert. Sie entspricht einer Implementierung der durch @uref{http://r-project.org, R}-Pakete genutzten Erstellungsprozedur, die wenig mehr tut, als @code{R CMD INSTALL --library=/gnu/store/@dots{}} in einer Umgebung auszuführen, in der die Umgebungsvariable @code{R_LIBS_SITE} die Pfade aller R-Pakete unter den Paketeingaben enthält. Tests werden nach der Installation mit der R-Funktion @code{tools::testInstalledPackage} ausgeführt. @end defvr @defvr {Scheme-Variable} rakudo-build-system This variable is exported by @code{(guix build-system rakudo)} It implements the build procedure used by @uref{https://rakudo.org/, Rakudo} for @uref{https://perl6.org/, Perl6} packages. It installs the package to @code{/gnu/store/@dots{}/NAME-VERSION/share/perl6} and installs the binaries, library files and the resources, as well as wrap the files under the @code{bin/} directory. Tests can be skipped by passing @code{#f} to the @code{tests?} parameter. Which rakudo package is used can be specified with @code{rakudo}. Which perl6-tap-harness package used for the tests can be specified with @code{#:prove6} or removed by passing @code{#f} to the @code{with-prove6?} parameter. Which perl6-zef package used for tests and installing can be specified with @code{#:zef} or removed by passing @code{#f} to the @code{with-zef?} parameter. @end defvr @defvr {Scheme-Variable} texlive-build-system Diese Variable wird vom Modul @code{(guix build-system texlive)} exportiert. Mit ihr werden TeX-Pakete in Stapelverarbeitung (»batch mode«) mit der angegebenen Engine erstellt. Das Erstellungssystem setzt die Variable @code{TEXINPUTS} so, dass alle TeX-Quelldateien unter den Eingaben gefunden werden können. Standardmäßig wird @code{luatex} auf allen Dateien mit der Dateiendung @code{ins} ausgeführt. Eine andere Engine oder ein anderes Format kann mit dem Argument @code{#:tex-format} angegeben werden. Verschiedene Erstellungsziele können mit dem Argument @code{#:build-targets} festgelegt werden, das eine Liste von Dateinamen erwartet. Das Erstellungssystem fügt nur @code{texlive-bin} und @code{texlive-latex-base} zu den Eingaben hinzu (beide kommen aus dem Modul @code{(gnu packages tex}). Für beide kann das zu benutzende Paket jeweils mit den Argumenten @code{#:texlive-bin} oder @code{#:texlive-latex-base} geändert werden. Der Parameter @code{#:tex-directory} sagt dem Erstellungssystem, wohin die installierten Dateien im texmf-Verzeichnisbaum installiert werden sollen. @end defvr @defvr {Scheme-Variable} ruby-build-system Diese Variable wird vom Modul @code{(guix build-system ruby)} exportiert. Sie steht für eine Implementierung der RubyGems-Erstellungsprozedur, die für Ruby-Pakete benutzt wird, wobei @code{gem build} gefolgt von @code{gem install} ausgeführt wird. Das @code{source}-Feld eines Pakets, das dieses Erstellungssystem benutzt, verweist typischerweise auf ein Gem-Archiv, weil Ruby-Entwickler dieses Format benutzen, wenn sie ihre Software veröffentlichen. Das Erstellungssystem entpackt das Gem-Archiv, spielt eventuell Patches für den Quellcode ein, führt die Tests aus, verpackt alles wieder in ein Gem-Archiv und installiert dieses. Neben Gem-Archiven darf das Feld auch auf Verzeichnisse und Tarballs verweisen, damit es auch möglich ist, unveröffentlichte Gems aus einem Git-Repository oder traditionelle Quellcode-Veröffentlichungen zu benutzen. Welches Ruby-Paket benutzt werden soll, kann mit dem Parameter @code{#:ruby} festgelegt werden. Eine Liste zusätzlicher Befehlszeilenoptionen für den Aufruf des @command{gem}-Befehls kann mit dem Parameter @code{#:gem-flags} angegeben werden. @end defvr @defvr {Scheme-Variable} waf-build-system Diese Variable wird durch das Modul @code{(guix build-system waf)} exportiert. Damit ist eine Erstellungsprozedur rund um das @code{waf}-Skript implementiert. Die üblichen Phasen — @code{configure}, @code{build} und @code{install} — sind implementiert, indem deren Namen als Argumente an das @code{waf}-Skript übergeben werden. Das @code{waf}-Skript wird vom Python-Interpetierer ausgeführt. Mit welchem Python-Paket das Skript ausgeführt werden soll, kann mit dem Parameter @code{#:python} angegeben werden. @end defvr @defvr {Scheme-Variable} scons-build-system Diese Variable wird vom Modul @code{(guix build-system scons)} exportiert. Sie steht für eine Implementierung der Erstellungsprozedur, die das SCons-Softwarekonstruktionswerkzeug (»software construction tool«) benutzt. Das Erstellungssystem führt @code{scons} aus, um das Paket zu erstellen, führt mit @code{scons test} Tests aus und benutzt @code{scons install}, um das Paket zu installieren. Zusätzliche Optionen, die an @code{scons} übergeben werden sollen, können mit dem Parameter @code{#:scons-flags} angegeben werden. Die Python-Version, die benutzt werden soll, um SCons auszuführen, kann festgelegt werden, indem das passende SCons-Paket mit dem Parameter @code{#:scons} ausgewählt wird. @end defvr @defvr {Scheme-Variable} haskell-build-system Diese Variable wird vom Modul @code{(guix build-system haskell)} exportiert. Sie bietet Zugang zur Cabal-Erstellungsprozedur, die von Haskell-Paketen benutzt wird, was bedeutet, @code{runhaskell Setup.hs configure --prefix=/gnu/store/@dots{}} und @code{runhaskell Setup.hs build} auszuführen. Statt das Paket mit dem Befehl @code{runhaskell Setup.hs install} zu installieren, benutzt das Erstellungssystem @code{runhaskell Setup.hs copy} gefolgt von @code{runhaskell Setup.hs register}, um keine Bibliotheken im Store-Verzeichnis des Compilers zu speichern, auf dem keine Schreibberechtigung besteht. Zusätzlich generiert das Erstellungssystem Dokumentation durch Ausführen von @code{runhaskell Setup.hs haddock}, außer @code{#:haddock? #f} wurde übergeben. Optional können an Haddock Parameter mit Hilfe des Parameters @code{#:haddock-flags} übergeben werden. Wird die Datei @code{Setup.hs} nicht gefunden, sucht das Erstellungssystem stattdessen nach @code{Setup.lhs}. Welcher Haskell-Compiler benutzt werden soll, kann über den @code{#:haskell}-Parameter angegeben werden. Als Vorgabewert verwendet er @code{ghc}. @end defvr @defvr {Scheme-Variable} dub-build-system Diese Variable wird vom Modul @code{(guix build-system dub)} exportiert. Sie verweist auf eine Implementierung des Dub-Erstellungssystems, das von D-Paketen benutzt wird. Dabei werden @code{dub build} und @code{dub run} ausgeführt. Die Installation wird durch manuelles Kopieren der Dateien durchgeführt. Welcher D-Compiler benutzt wird, kann mit dem Parameter @code{#:ldc} festgelegt werden, was als Vorgabewert @code{ldc} benutzt. @end defvr @defvr {Scheme-Variable} emacs-build-system Diese Variable wird vom Modul @code{(guix build-system emacs)} exportiert. Darin wird eine Installationsprozedur ähnlich der des Paketsystems von Emacs selbst implementiert (siehe @ref{Packages,,, emacs, The GNU Emacs Manual}). Zunächst wird eine Datei @code{@var{Paket}-autoloads.el} erzeugt, dann werden alle Emacs-Lisp-Dateien zu Bytecode kompiliert. Anders als beim Emacs-Paketsystem werden die Info-Dokumentationsdateien in das Standardverzeichnis für Dokumentation verschoben und die Datei @file{dir} gelöscht. Jedes Paket wird in sein eigenes Verzeichnis unter @file{share/emacs/site-lisp/guix.d} installiert. @end defvr @defvr {Scheme-Variable} font-build-system Diese Variable wird vom Modul @code{(guix build-system font)} exportiert. Mit ihr steht eine Installationsprozedur für Schriftarten-Pakete zur Verfügung für vom Anbieter vorkompilierte TrueType-, OpenType- und andere Schriftartendateien, die nur an die richtige Stelle kopiert werden müssen. Dieses Erstellungssystem kopiert die Schriftartendateien an den Konventionen folgende Orte im Ausgabeverzeichnis. @end defvr @defvr {Scheme-Variable} meson-build-system Diese Variable wird vom Modul @code{(guix build-system meson)} exportiert. Sie enthält die Erstellungsprozedur für Pakete, die @url{http://mesonbuild.com, Meson} als ihr Erstellungssystem benutzen. Mit ihr werden sowohl Meson als auch @uref{https://ninja-build.org/, Ninja} zur Menge der Eingaben hinzugefügt; die Pakete dafür können mit den Parametern @code{#:meson} und @code{#:ninja} geändert werden, wenn nötig. Das vorgegebene Meson-Paket ist @code{meson-for-build}, ein besonderes Paket, dessen Besonderheit darin besteht, den @code{RUNPATH} von Binärdateien und Bibliotheken @emph{nicht} zu entfernen, wenn sie installiert werden. Dieses Erstellungssystem ist eine Erweiterung für das @var{gnu-build-system}, aber mit Änderungen an den folgenden Phasen, die Meson-spezifisch sind: @table @code @item configure Diese Phase führt den @code{meson}-Befehl mit den in @code{#:configure-flags} angegebenen Befehlszeilenoptionen aus. Die Befehlszeilenoption @code{--build-type} wird immer auf @code{plain} gesetzt, solange nichts anderes mit dem Parameter @code{#:build-type} angegeben wurde. @item build Diese Phase ruft @code{ninja} auf, um das Paket standardmäßig parallel zu erstellen. Die Vorgabeeinstellung, dass parallel erstellt wird, kann verändert werden durch Setzen von @code{#:parallel-build?}. @item check Diese Phase führt @code{ninja} mit dem als @code{#:test-target} spezifizierten Ziel für Tests auf, der Vorgabewert ist das Ziel namens @code{"test"}. @item install Diese Phase führt @code{ninja install} aus und kann nicht verändert werden. @end table Dazu fügt das Erstellungssystem noch folgende neue Phasen: @table @code @item fix-runpath In dieser Phase wird sichergestellt, dass alle Binärdateien die von ihnen benötigten Bibliotheken finden können. Die benötigten Bibliotheken werden in den Unterverzeichnissen des Pakets, das erstellt wird, gesucht, und zum @code{RUNPATH} hinzugefügt, wann immer es nötig ist. Auch werden diejenigen Referenzen zu Bibliotheken aus der Erstellungsphase wieder entfernt, die bei @code{meson-for-build} hinzugefügt wurden, aber eigentlich zur Laufzeit nicht gebraucht werden, wie Abhängigkeiten nur für Tests. @item glib-or-gtk-wrap Diese Phase ist dieselbe, die auch im @code{glib-or-gtk-build-system} zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter @code{#:glib-or-gtk?} aktiviert werden. @item glib-or-gtk-compile-schemas Diese Phase ist dieselbe, die auch im @code{glib-or-gtk-build-system} zur Verfügung gestellt wird, und mit Vorgabeeinstellungen wird sie nicht durchlaufen. Wenn sie gebraucht wird, kann sie mit dem Parameter @code{#:glib-or-gtk?} aktiviert werden. @end table @end defvr @defvr {Scheme Variable} linux-module-build-system @var{linux-module-build-system} allows building Linux kernel modules. @cindex Erstellungsphasen This build system is an extension of @var{gnu-build-system}, but with the following phases changed: @table @code @item configure This phase configures the environment so that the Linux kernel's Makefile can be used to build the external kernel module. @item build This phase uses the Linux kernel's Makefile in order to build the external kernel module. @item install This phase uses the Linux kernel's Makefile in order to install the external kernel module. @end table It is possible and useful to specify the Linux kernel to use for building the module (in the "arguments" form of a package using the linux-module-build-system, use the key #:linux to specify it). @end defvr Letztlich gibt es für die Pakete, die bei weitem nichts so komplexes brauchen, ein »triviales« Erstellungssystem. Es ist in dem Sinn trivial, dass es praktisch keine Hilfestellungen gibt: Es fügt keine impliziten Eingaben hinzu und hat kein Konzept von Erstellungsphasen. @defvr {Scheme-Variable} trivial-build-system Diese Variable wird vom Modul @code{(guix build-system trivial)} exportiert. Diesem Erstellungssystem muss im Argument @code{#:builder} ein Scheme-Ausdruck übergeben werden, der die Paketausgabe(n) erstellt — wie bei @code{build-expression->derivation} (siehe @ref{Ableitungen, @code{build-expression->derivation}}). @end defvr @node Der Store @section Der Store @cindex Store @cindex Store-Objekte @cindex Store-Pfade Konzeptionell ist der @dfn{Store} der Ort, wo Ableitungen nach erfolgreicher Erstellung gespeichert werden — standardmäßig finden Sie ihn in @file{/gnu/store}. Unterverzeichnisse im Store werden @dfn{Store-Objekte} oder manchmal auch @dfn{Store-Pfade} genannt. Mit dem Store ist eine Datenbank assoziiert, die Informationen enthält wie zum Beispiel, welche Store-Pfade jeder Store-Pfad jeweils referenziert, und eine Liste, welche Store-Objekte @emph{gültig} sind, also Ergebnisse erfolgreicher Erstellungen sind. Die Datenbank befindet sich in @file{@var{localstatedir}/guix/db}, wobei @var{localstatedir} das mit @option{--localstatedir} bei der Ausführung von »configure« angegebene Zustandsverzeichnis ist, normalerweise @file{/var}. Auf den Store wird @emph{nur} durch den Daemon im Auftrag seiner Clients zugegriffen (siehe @ref{Aufruf des guix-daemon}). Um den Store zu verändern, verbinden sich Clients über einen Unix-Socket mit dem Daemon, senden ihm entsprechende Anfragen und lesen dann dessen Antwort — so etwas nennt sich entfernter Prozeduraufruf (englisch »Remote Procedure Call« oder kurz RPC). @quotation Anmerkung Benutzer dürfen @emph{niemals} Dateien in @file{/gnu/store} direkt verändern, sonst wären diese nicht mehr konsistent und die Grundannahmen im funktionalen Modell von Guix, dass die Objekte unveränderlich sind, wären dahin (siehe @ref{Einführung}). Siehe @ref{Aufruf von guix gc, @command{guix gc --verify}} für Informationen, wie die Integrität des Stores überprüft und nach versehentlichen Veränderungen unter Umständen wiederhergestellt werden kann. @end quotation Das Modul @code{(guix store)} bietet Prozeduren an, um sich mit dem Daemon zu verbinden und entfernte Prozeduraufrufe durchzuführen. Diese werden im Folgenden beschrieben. Das vorgegebene Verhalten von @code{open-connection}, und daher allen @command{guix}-Befehlen, ist, sich mit dem lokalen Daemon oder dem an der in der Umgebungsvariablen @code{GUIX_DAEMON_SOCKET} angegeben URL zu verbinden. @defvr {Umgebungsvariable} GUIX_DAEMON_SOCKET Ist diese Variable gesetzt, dann sollte ihr Wert ein Dateipfad oder eine URI sein, worüber man sich mit dem Daemon verbinden kann. Ist der Wert der Pfad zu einer Datei, bezeichnet dieser einen Unix-Socket, mit dem eine Verbindung hergestellt werden soll. Ist er eine URI, so werden folgende URI-Schemata unterstützt: @table @code @item file @itemx unix Für Unix-Sockets. @code{file:///var/guix/daemon-socket/socket} kann gleichbedeutend auch als @file{/var/guix/daemon-socket/socket} angegeben werden. @item guix @cindex Daemon, Fernzugriff @cindex Fernzugriff auf den Daemon @cindex Daemon, Einrichten auf Clustern @cindex Cluster, Einrichtung des Daemons Solche URIs benennen Verbindungen über TCP/IP ohne Verschlüsselung oder Authentifizierung des entfernten Rechners. Die URI muss den Hostnamen, also den Rechnernamen des entfernten Rechners, und optional eine Port-Nummer angeben (sonst wird als Vorgabe der Port 44146 benutzt): @example guix://master.guix.example.org:1234 @end example Diese Konfiguration ist für lokale Netzwerke wie etwa in Rechen-Clustern geeignet, wo sich nur vertrauenswürdige Knoten mit dem Erstellungs-Daemon z.B.@: unter @code{master.guix.example.org} verbinden können. Die Befehlszeilenoption @code{--listen} von @command{guix-daemon} kann benutzt werden, damit er auf TCP-Verbindungen lauscht (siehe @ref{Aufruf des guix-daemon, @code{--listen}}). @item ssh @cindex SSH-Zugriff auf Erstellungs-Daemons Mit solchen URIs kann eine Verbindung zu einem entfernten Daemon über SSH hergestellt werden@footnote{Diese Funktionalitäts setzt Guile-SSH voraus (siehe @ref{Voraussetzungen}).}. Eine typische URL sieht so aus: @example ssh://charlie@@guix.example.org:22 @end example Was @command{guix copy} betrifft, richtet es sich nach den üblichen OpenSSH-Client-Konfigurationsdateien (siehe @ref{Aufruf von guix copy}). @end table In Zukunft könnten weitere URI-Schemata unterstützt werden. @c XXX: Remove this note when the protocol incurs fewer round trips @c and when (guix derivations) no longer relies on file system access. @quotation Anmerkung Die Fähigkeit, sich mit entfernten Erstellungs-Daemons zu verbinden, sehen wir als experimentell an, Stand @value{VERSION}. Bitte diskutieren Sie mit uns jegliche Probleme oder Vorschläge, die Sie haben könnten (siehe @ref{Mitwirken}). @end quotation @end defvr @deffn {Scheme-Prozedur} open-connection [@var{Uri}] [#:reserve-space? #t] Sich mit dem Daemon über den Unix-Socket an @var{Uri} verbinden (einer Zeichenkette). Wenn @var{reserve-space?} wahr ist, lässt ihn das etwas zusätzlichen Speicher im Dateisystem reservieren, damit der Müllsammler auch dann noch funktioniert, wenn die Platte zu voll wird. Liefert ein Server-Objekt. @var{Uri} nimmt standardmäßig den Wert von @var{%default-socket-path} an, was dem bei der Installation mit dem Aufruf von @command{configure} ausgewählten Vorgabeort entspricht, gemäß den Befehlszeilenoptionen, mit denen @command{configure} aufgerufen wurde. @end deffn @deffn {Scheme-Prozedur} close-connection @var{Server} Die Verbindung zum @var{Server} trennen. @end deffn @defvr {Scheme-Variable} current-build-output-port Diese Variable ist an einen SRFI-39-Parameter gebunden, der auf den Scheme-Port verweist, an den vom Daemon empfangene Erstellungsprotokolle und Fehlerprotokolle geschrieben werden sollen. @end defvr Prozeduren, die entfernte Prozeduraufrufe durchführen, nehmen immer ein Server-Objekt als ihr erstes Argument. @deffn {Scheme-Prozedur} valid-path? @var{Server} @var{Pfad} @cindex ungültige Store-Objekte Liefert @code{#t}, wenn der @var{Pfad} ein gültiges Store-Objekt benennt, und sonst @code{#f} (ein ungültiges Objekt kann auf der Platte gespeichert sein, tatsächlich aber ungültig sein, zum Beispiel weil es das Ergebnis einer abgebrochenen oder fehlgeschlagenen Erstellung ist). Ein @code{&store-protocol-error}-Fehlerzustand wird ausgelöst, wenn der @var{Pfad} nicht mit dem Store-Verzeichnis als Präfix beginnt (@file{/gnu/store}). @end deffn @deffn {Scheme-Prozedur} add-text-to-store @var{Server} @var{Name} @var{Text} [@var{Referenzen}] Den @var{Text} im Store in einer Datei namens @var{Name} ablegen und ihren Store-Pfad zurückliefern. @var{Referenzen} ist die Liste der Store-Pfade, die der Store-Pfad dann referenzieren soll. @end deffn @deffn {Scheme-Prozedur} build-derivations @var{Server} @var{Ableitungen} Die @var{Ableitungen} erstellen (eine Liste von @code{}-Objekten oder von Pfaden zu Ableitungen) und terminieren, sobald der Worker-Prozess mit dem Erstellen fertig ist. Liefert @code{#t} bei erfolgreicher Erstellung. @end deffn Es sei erwähnt, dass im Modul @code{(guix monads)} eine Monade sowie monadische Versionen obiger Prozeduren angeboten werden, damit an Code, der auf den Store zugreift, bequemer gearbeitet werden kann (siehe @ref{Die Store-Monade}). @c FIXME @i{Dieser Abschnitt ist im Moment noch unvollständig.} @node Ableitungen @section Ableitungen @cindex Ableitungen Systemnahe Erstellungsaktionen sowie die Umgebung, in der selbige durchzuführen sind, werden durch @dfn{Ableitungen} dargestellt. Eine Ableitung enthält folgende Informationen: @itemize @item Die Ausgaben, die die Ableitung hat. Ableitungen erzeugen mindestens eine Datei bzw. ein Verzeichnis im Store, können aber auch mehrere erzeugen. @item @cindex Erstellungszeitabhängigkeiten @cindex Abhängigkeiten zur Erstellungszeit Die Eingaben der Ableitung, also Abhängigkeiten zur Zeit ihrer Erstellung, die entweder andere Ableitungen oder einfache Dateien im Store sind (wie Patches, Erstellungsskripts usw.). @item Das System, wofür mit der Ableitung erstellt wird, also ihr Ziel — z.B.@: @code{x86_64-linux}. @item Der Dateiname eines Erstellungsskripts im Store, zusammen mit den Argumenten, mit denen es aufgerufen werden soll. @item Eine Liste zu definierender Umgebungsvariabler. @end itemize @cindex Ableitungspfad Ableitungen ermöglichen es den Clients des Daemons, diesem Erstellungsaktionen für den Store mitzuteilen. Es gibt davon zwei Arten, sowohl Darstellungen im Arbeitsspeicher jeweils für Client und Daemon, als auch Dateien im Store, deren Namen auf @code{.drv} enden — diese Dateien werden als @dfn{Ableitungspfade} bezeichnet. Ableitungspfade können an die Prozedur @code{build-derivations} übergeben werden, damit die darin niedergeschriebenen Erstellungsaktionen durchgeführt werden (siehe @ref{Der Store}). @cindex Ableitungen mit fester Ausgabe Operationen wie das Herunterladen von Dateien und Checkouts von unter Versionskontrolle stehenden Quelldateien, bei denen der Hash des Inhalts im Voraus bekannt ist, werden als @dfn{Ableitungen mit fester Ausgabe} modelliert. Anders als reguläre Ableitungen sind die Ausgaben von Ableitungen mit fester Ausgabe unabhängig von ihren Eingaben — z.B.@: liefert das Herunterladen desselben Quellcodes dasselbe Ergebnis unabhängig davon, mit welcher Methode und welchen Werkzeugen er heruntergeladen wurde. @cindex references @cindex Laufzeitabhängigkeiten @cindex Abhängigkeiten, zur Laufzeit Den Ausgaben von Ableitungen — d.h.@: Erstellungergebnissen — ist eine Liste von @dfn{Referenzen} zugeordnet, die auch der entfernte Prozeduraufruf @code{references} oder der Befehl @command{guix gc --references} liefert (siehe @ref{Aufruf von guix gc}). Referenzen sind die Menge der Laufzeitabhängigkeiten von Erstellungsergebnissen. Referenzen sind eine Teilmenge der Eingaben von Ableitungen; die Teilmenge wird automatisch ermittelt, indem der Erstellungsdaemon alle Dateien unter den Ausgaben nach Referenzen durchsucht. Das Modul @code{(guix derivations)} stellt eine Repräsentation von Ableitungen als Scheme-Objekte zur Verfügung, zusammen mit Prozeduren, um Ableitungen zu erzeugen und zu manipulieren. Die am wenigsten abstrahierte Methode, eine Ableitung zu erzeugen, ist mit der Prozedur @code{derivation}: @deffn {Scheme-Prozedur} derivation @var{Store} @var{Name} @var{Ersteller} @ @var{Argumente} [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @ [#:recursive? #f] [#:inputs '()] [#:env-vars '()] @ [#:system (%current-system)] [#:references-graphs #f] @ [#:allowed-references #f] [#:disallowed-references #f] @ [#:leaked-env-vars #f] [#:local-build? #f] @ [#:substitutable? #t] [#:properties '()] Eine Ableitungen mit den @var{Argumente}n erstellen und das resultierende @code{}-Objekt liefern. Wurden @var{hash} und @var{hash-algo} angegeben, wird eine @dfn{Ableitung mit fester Ausgabe} erzeugt — d.h.@: eine, deren Ausgabe schon im Voraus bekannt ist, wie z.B.@: beim Herunterladen einer Datei. Wenn des Weiteren auch @var{recursive?} wahr ist, darf die Ableitung mit fester Ausgabe eine ausführbare Datei oder ein Verzeichnis sein und @var{hash} muss die Prüfsumme eines Archivs mit dieser Ausgabe sein. Ist @var{references-graphs} wahr, dann muss es eine Liste von Paaren aus je einem Dateinamen und einem Store-Pfad sein. In diesem Fall wird der Referenzengraph jedes Store-Pfads in einer Datei mit dem angegebenen Namen in der Erstellungsumgebung zugänglich gemacht, in einem einfachen Text-Format. Ist @var{allowed-references} ein wahr, muss es eine Liste von Store-Objekten oder Ausgaben sein, die die Ausgabe der Ableitung referenzieren darf. Ebenso muss @var{disallowed-references}, wenn es auf wahr gesetzt ist, eine Liste von Dingen bezeichnen, die die Ausgaben @emph{nicht} referenzieren dürfen. Ist @var{leaked-env-vars} wahr, muss es eine Liste von Zeichenketten sein, die Umgebungsvariable benennen, die aus der Umgebung des Daemons in die Erstellungsumgebung überlaufen — ein »Leck«, englisch »leak«. Dies kann nur in Ableitungen mit fester Ausgabe benutzt werden, also wenn @var{hash} wahr ist. So ein Leck kann zum Beispiel benutzt werden, um Variable wie @code{http_proxy} an Ableitungen zu übergeben, die darüber Dateien herunterladen. Ist @var{local-build?} wahr, wird die Ableitung als schlechter Kandidat für das Auslagern deklariert, der besser lokal erstellt werden sollte (siehe @ref{Auslagern des Daemons einrichten}). Dies betrifft kleine Ableitungen, wo das Übertragen der Daten aufwendiger als ihre Erstellung ist. Ist @var{substitutable?} falsch, wird deklariert, dass für die Ausgabe der Ableitung keine Substitute benutzt werden sollen (siehe @ref{Substitute}). Das ist nützlich, wenn Pakete erstellt werden, die Details über den Prozessorbefehlssatz des Wirtssystems auslesen. @var{properties} muss eine assoziative Liste enthalten, die »Eigenschaften« der Ableitungen beschreibt. Sie wird genau so, wie sie ist, in der Ableitung gespeichert. @end deffn @noindent Hier ist ein Beispiel mit einem Shell-Skript, das als Ersteller benutzt wird. Es wird angenommen, dass @var{Store} eine offene Verbindung zum Daemon ist und @var{bash} auf eine ausführbare Bash im Store verweist: @lisp (use-modules (guix utils) (guix store) (guix derivations)) (let ((builder ; das Ersteller-Bash-Skript in den Store einfügen (add-text-to-store store "my-builder.sh" "echo Hallo Welt > $out\n" '()))) (derivation store "foo" bash `("-e" ,builder) #:inputs `((,bash) (,builder)) #:env-vars '(("HOME" . "/homeless")))) @result{} # /gnu/store/@dots{}-foo> @end lisp Wie man sehen kann, ist es umständlich, diese grundlegende Methode direkt zu benutzen. Natürlich ist es besser, Erstellungsskripts in Scheme zu schreiben! Am besten schreibt man den Erstellungscode als »G-Ausdruck« und übergibt ihn an @code{gexp->derivation}. Mehr Informationen finden Sie im Abschnitt @ref{G-Ausdrücke}. Doch es gab einmal eine Zeit, zu der @code{gexp->derivation} noch nicht existiert hatte und wo das Zusammenstellen von Ableitungen mit Scheme-Erstellungscode noch mit @code{build-expression->derivation} bewerkstelligt wurde, was im Folgenden beschrieben wird. Diese Prozedur gilt als veraltet und man sollte nunmehr die viel schönere Prozedur @code{gexp->derivation} benutzen. @deffn {Scheme-Prozedur} build-expression->derivation @var{Store} @ @var{Name} @var{Ausdruck} @ [#:system (%current-system)] [#:inputs '()] @ [#:outputs '("out")] [#:hash #f] [#:hash-algo #f] @ [#:recursive? #f] [#:env-vars '()] [#:modules '()] @ [#:references-graphs #f] [#:allowed-references #f] @ [#:disallowed-references #f] @ [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f] Liefert eine Ableitung, die den Scheme-Ausdruck @var{Ausdruck} als Ersteller einer Ableitung namens @var{Name} ausführt. @var{inputs} muss die Liste der Eingaben enthalten, jeweils als Tupel @code{(Name Ableitungspfad Unterableitung)}; wird keine @var{Unterableitung} angegeben, wird @code{"out"} angenommen. @var{Module} ist eine Liste der Namen von Guile-Modulen im momentanen Suchpfad, die in den Store kopiert, kompiliert und zur Verfügung gestellt werden, wenn der @var{Ausdruck} ausgeführt wird — z.B.@: @code{((guix build utils) (guix build gnu-build-system))}. Der @var{Ausdruck} wird in einer Umgebung ausgewertet, in der @code{%outputs} an eine Liste von Ausgabe-/Pfad-Paaren gebunden wurde und in der @code{%build-inputs} an eine Liste von Zeichenkette-/Ausgabepfad-Paaren gebunden wurde, die aus den @var{inputs}-Eingaben konstruiert worden ist. Optional kann in @var{env-vars} eine Liste von Paaren aus Zeichenketten stehen, die Name und Wert von für den Ersteller sichtbaren Umgebungsvariablen angeben. Der Ersteller terminiert, indem er @code{exit} mit dem Ergebnis des @var{Ausdruck}s aufruft; wenn also der @var{Ausdruck} den Wert @code{#f} liefert, wird angenommen, dass die Erstellung fehlgeschlagen ist. @var{Ausdruck} wird mit einer Ableitung @var{guile-for-build} erstellt. Wird kein @var{guile-for-build} angegeben oder steht es auf @code{#f}, wird stattdessen der Wert der Fluiden @code{%guile-for-build} benutzt. Siehe die Erklärungen zur Prozedur @code{derivation} für die Bedeutung von @var{references-graphs}, @var{allowed-references}, @var{disallowed-references}, @var{local-build?} und @var{substitutable?}. @end deffn @noindent Hier ist ein Beispiel einer Ableitung mit nur einer Ausgabe, die ein Verzeichnis erzeugt, in dem eine einzelne Datei enthalten ist: @lisp (let ((builder '(let ((out (assoc-ref %outputs "out"))) (mkdir out) ; das Verzeichnis ; /gnu/store/@dots{}-goo erstellen (call-with-output-file (string-append out "/test") (lambda (p) (display '(Hallo Guix) p)))))) (build-expression->derivation store "goo" builder)) @result{} # @dots{}> @end lisp @node Die Store-Monade @section Die Store-Monade @cindex Monade Die auf dem Store arbeitenden Prozeduren, die in den vorigen Abschnitten beschrieben wurden, nehmen alle eine offene Verbindung zum Erstellungs-Daemon als ihr erstes Argument entgegen. Obwohl das ihnen zu Grunde liegende Modell funktional ist, weisen sie doch alle Nebenwirkungen auf oder hängen vom momentanen Zustand des Stores ab. Ersteres ist umständlich, weil die Verbindung zum Erstellungs-Daemon zwischen all diesen Funktionen durchgereicht werden muss, so dass eine Komposition mit Funktionen ohne diesen Parameter unmöglich wird. Letzteres kann problematisch sein, weil Operationen auf dem Store Nebenwirkungen und/oder Abhängigkeiten von externem Zustand haben und ihre Ausführungsreihenfolge deswegen eine Rolle spielt. @cindex monadische Werte @cindex monadische Funktionen Hier kommt das Modul @code{(guix monads)} ins Spiel. Im Rahmen dieses Moduls können @dfn{Monaden} benutzt werden und dazu gehört insbesondere eine für unsere Zwecke sehr nützliche Monade, die @dfn{Store-Monade}. Monaden sind ein Konstrukt, mit dem zwei Dinge möglich sind: eine Assoziation von Werten mit einem »Kontext« (in unserem Fall ist das die Verbindung zum Store) und das Festlegen einer Reihenfolge für Berechnungen (hiermit sind auch Zugriffe auf den Store gemeint). Werte in einer Monade — solche, die mit weiterem Kontext assoziiert sind — werden @dfn{monadische Werte} genannt; Prozeduren, die solche Werte liefern, heißen @dfn{monadische Prozeduren}. Betrachten Sie folgende »normale« Prozedur: @example (define (sh-symlink store) ;; Eine Ableitung liefern, die mit der ausführbaren Datei »bash« ;; symbolisch verknüpft. (let* ((drv (package-derivation store bash)) (out (derivation->output-path drv)) (sh (string-append out "/bin/bash"))) (build-expression->derivation store "sh" `(symlink ,sh %output)))) @end example Unter Verwendung von @code{(guix monads)} und @code{(guix gexp)} lässt sie sich als monadische Funktion aufschreiben: @example (define (sh-symlink) ;; Ebenso, liefert aber einen monadischen Wert. (mlet %store-monad ((drv (package->derivation bash))) (gexp->derivation "sh" #~(symlink (string-append #$drv "/bin/bash") #$output)))) @end example An der zweiten Version lassen sich mehrere Dinge beobachten: Der Parameter @code{Store} ist jetzt implizit geworden und wurde in die Aufrufe der monadischen Prozeduren @code{package->derivation} und @code{gexp->derivation} »eingefädelt« und der von @code{package->derivation} gelieferte monadische Wert wurde mit @code{mlet} statt einem einfachen @code{let} @dfn{gebunden}. Wie sich herausstellt, muss man den Aufruf von @code{package->derivation} nicht einmal aufschreiben, weil er implizit geschieht, wie wir später sehen werden (siehe @ref{G-Ausdrücke}): @example (define (sh-symlink) (gexp->derivation "sh" #~(symlink (string-append #$bash "/bin/bash") #$output))) @end example @c See @c @c for the funny quote. Die monadische @code{sh-symlink} einfach aufzurufen, bewirkt nichts. Wie jemand einst sagte: »Mit einer Monade geht man um, wie mit Gefangenen, gegen die man keine Beweise hat: Man muss sie laufen lassen.« Um also aus der Monade auszubrechen und die gewünschte Wirkung zu erzielen, muss man @code{run-with-store} benutzen: @example (run-with-store (open-connection) (sh-symlink)) @result{} /gnu/store/...-sh-symlink @end example Erwähnenswert ist, dass das Modul @code{(guix monad-repl)} die REPL von Guile um neue »Meta-Befehle« erweitert, mit denen es leichter ist, mit monadischen Prozeduren umzugehen: @code{run-in-store} und @code{enter-store-monad}. Mit Ersterer wird ein einzelner monadischer Wert durch den Store »laufen gelassen«: @example scheme@@(guile-user)> ,run-in-store (package->derivation hello) $1 = # @dots{}> @end example Mit Letzterer wird rekursiv eine weitere REPL betreten, in der alle Rückgabewerte automatisch durch den Store laufen gelassen werden: @example scheme@@(guile-user)> ,enter-store-monad store-monad@@(guile-user) [1]> (package->derivation hello) $2 = # @dots{}> store-monad@@(guile-user) [1]> (text-file "foo" "Hallo!") $3 = "/gnu/store/@dots{}-foo" store-monad@@(guile-user) [1]> ,q scheme@@(guile-user)> @end example @noindent Beachten Sie, dass in einer @code{store-monad}-REPL keine nicht-monadischen Werte zurückgeliefert werden können. Die wichtigsten syntaktischen Formen, um mit Monaden im Allgemeinen umzugehen, werden im Modul @code{(guix monads)} bereitgestellt und sind im Folgenden beschrieben. @deffn {Scheme-Syntax} with-monad @var{Monade} @var{Rumpf} ... Alle @code{>>=}- oder @code{return}-Formen im @var{Rumpf} in der @var{Monade} auswerten. @end deffn @deffn {Scheme-Syntax} return @var{Wert} Einen monadischen Wert liefern, der den übergebenen @var{Wert} kapselt. @end deffn @deffn {Scheme-Syntax} >>= @var{mWert} @var{mProz} ... Den monadischen Wert @var{mWert} @dfn{binden}, wobei sein »Inhalt« an die monadischen Prozeduren @var{mProz}@dots{} übergeben wird@footnote{Diese Operation wird gemeinhin »bind« genannt, aber mit diesem Begriff wird in Guile eine völlig andere Prozedur bezeichnet, die nichts damit zu tun hat. Also benutzen wir dieses etwas kryptische Symbol als Erbe der Haskell-Programmiersprache.}. Es kann eine einzelne @var{mProz} oder mehrere davon geben, wie in diesem Beispiel: @example (run-with-state (with-monad %state-monad (>>= (return 1) (lambda (x) (return (+ 1 x))) (lambda (x) (return (* 2 x))))) 'irgendein-Zustand) @result{} 4 @result{} irgendein-Zustand @end example @end deffn @deffn {Scheme-Syntax} mlet @var{Monade} ((@var{Variable} @var{mWert}) ...) @ @var{Rumpf} ... @deffnx {Scheme-Syntax} mlet* @var{Monade} ((@var{Variable} @var{mWert}) ...) @ @var{Rumpf} ... Die @var{Variable}n an die monadischen Werte @var{mWert} im @var{Rumpf} binden, der eine Folge von Ausdrücken ist. Wie beim bind-Operator kann man es sich vorstellen als »Auspacken« des rohen, nicht-monadischen Werts, der im @var{mWert} steckt, wobei anschließend dieser rohe, nicht-monadische Wert im Sichtbarkeitsbereich des @var{Rumpf}s von der @var{Variable}n bezeichnet wird. Die Form (@var{Variable} -> @var{Wert}) bindet die @var{Variable} an den »normalen« @var{Wert}, wie es @code{let} tun würde. Die Bindungsoperation geschieht in der Reihenfolge von links nach rechts. Der letzte Ausdruck des @var{Rumpfs} muss ein monadischer Ausdruck sein und dessen Ergebnis wird das Ergebnis von @code{mlet} oder @code{mlet*} werden, wenn es durch die @var{Monad} laufen gelassen wurde. @code{mlet*} verhält sich gegenüber @code{mlet} wie @code{let*} gegenüber @code{let} (siehe @ref{Local Bindings,,, guile, GNU Guile Reference Manual}). @end deffn @deffn {Scheme-System} mbegin @var{Monade} @var{mAusdruck} ... Der Reihe nach den @var{mAusdruck} und die nachfolgenden monadischen Ausdrücke binden und als Ergebnis das des letzten Ausdrucks liefern. Jeder Ausdruck in der Abfolge muss ein monadischer Ausdruck sein. Dies verhält sich ähnlich wie @code{mlet}, außer dass die Rückgabewerte der monadischen Prozeduren ignoriert werden. In diesem Sinn verhält es sich analog zu @code{begin}, nur auf monadischen Ausdrücken. @end deffn @deffn {Scheme-System} mwhen @var{Bedingung} @var{mAusdr0} @var{mAusdr*} ... Wenn die @var{Bedingung} wahr ist, wird die Folge monadischer Ausdrücke @var{mAusdr0}..@var{mAusdr*} wie bei @code{mbegin} ausgewertet. Wenn die @var{Bedingung} falsch ist, wird @code{*unspecified*} in der momentanen Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer Ausdruck sein. @end deffn @deffn {Scheme-System} munless @var{Bedingung} @var{mAusdr0} @var{mAusdr*} ... Wenn die @var{Bedingung} falsch ist, wird die Folge monadischer Ausdrücke @var{mAusdr0}..@var{mAusdr*} wie bei @code{mbegin} ausgewertet. Wenn die @var{Bedingung} wahr ist, wird @code{*unspecified*} in der momentanen Monade zurückgeliefert. Jeder Ausdruck in der Folge muss ein monadischer Ausdruck sein. @end deffn @cindex Zustandsmonade Das Modul @code{(guix monads)} macht die @dfn{Zustandsmonade} (englisch »state monad«) verfügbar, mit der ein zusätzlicher Wert — der Zustand — durch die monadischen Prozeduraufrufe @emph{gefädelt} werden kann. @defvr {Scheme-Variable} %state-monad Die Zustandsmonade. Prozeduren in der Zustandsmonade können auf den gefädelten Zustand zugreifen und ihn verändern. Betrachten Sie das folgende Beispiel. Die Prozedur @code{Quadrat} liefert einen Wert in der Zustandsmonade zurück. Sie liefert das Quadrat ihres Arguments, aber sie inkrementiert auch den momentanen Zustandswert: @example (define (Quadrat x) (mlet %state-monad ((Anzahl (current-state))) (mbegin %state-monad (set-current-state (+ 1 Anzahl)) (return (* x x))))) (run-with-state (sequence %state-monad (map Quadrat (iota 3))) 0) @result{} (0 1 4) @result{} 3 @end example Wird das »durch« die Zustandsmonade @var{%state-monad} laufen gelassen, erhalten wir jenen zusätzlichen Zustandswert, der der Anzahl der Aufrufe von @code{Quadrat} entspricht. @end defvr @deffn {Monadische Prozedur} current-state Liefert den momentanen Zustand als einen monadischen Wert. @end deffn @deffn {Monadische Prozedur} set-current-state @var{Wert} Setzt den momentanen Zustand auf @var{Wert} und liefert den vorherigen Zustand als einen monadischen Wert. @end deffn @deffn {Monadische Prozedur} state-push @var{Wert} Hängt den @var{Wert} vorne an den momentanen Zustand an, der eine Liste sein muss. Liefert den vorherigen Zustand als monadischen Wert. @end deffn @deffn {Monadische Prozedur} state-pop Entfernt einen Wert vorne vom momentanen Zustand und liefert ihn als monadischen Wert zurück. Dabei wird angenommen, dass es sich beim Zustand um eine Liste handelt. @end deffn @deffn {Scheme-Prozedur} run-with-state @var{mWert} [@var{Zustand}] Den monadischen Wert @var{mWert} mit @var{Zustand} als initialem Zustand laufen lassen. Dies liefert zwei Werte: den Ergebniswert und den Ergebniszustand. @end deffn Die zentrale Schnittstelle zur Store-Monade, wie sie vom Modul @code{(guix store)} angeboten wird, ist die Folgende: @defvr {Scheme-Variable} %store-monad Die Store-Monade — ein anderer Name für @var{%state-monad}. Werte in der Store-Monade kapseln Zugriffe auf den Store. Sobald seine Wirkung gebraucht wird, muss ein Wert der Store-Monade »ausgewertet« werden, indem er an die Prozedur @code{run-with-store} übergeben wird (siehe unten). @end defvr @deffn {Scheme-Prozedur} run-with-store @var{Store} @var{mWert} [#:guile-for-build] [#:system (%current-system)] Den @var{mWert}, einen monadischen Wert in der Store-Monade, in der offenen Verbindung @var{Store} laufen lassen. @end deffn @deffn {Monadische Prozedur} text-file @var{Name} @var{Text} [@var{Referenzen}] Als monadischen Wert den absoluten Dateinamen im Store für eine Datei liefern, deren Inhalt der der Zeichenkette @var{Text} ist. @var{Referenzen} ist dabei eine Liste von Store-Objekten, die die Ergebnis-Textdatei referenzieren wird; der Vorgabewert ist die leere Liste. @end deffn @deffn {Monadische Prozedur} binary-file @var{Name} @var{Daten} [@var{Referenzen}] Den absoluten Dateinamen im Store als monadischen Wert für eine Datei liefern, deren Inhalt der des Byte-Vektors @var{Daten} ist. @var{Referenzen} ist dabei eine Liste von Store-Objekten, die die Ergebnis-Binärdatei referenzieren wird; der Vorgabewert ist die leere Liste. @end deffn @deffn {Monadische Prozedur} interned-file @var{Datei} [@var{Name}] @ [#:recursive? #t] [#:select? (const #t)] Liefert den Namen der @var{Datei}, nachdem sie in den Store interniert wurde. Dabei wird der @var{Name} als ihr Store-Name verwendet, oder, wenn kein @var{Name} angegeben wurde, der Basisname der @var{Datei}. Ist @var{recursive?} wahr, werden in der @var{Datei} enthaltene Dateien rekursiv hinzugefügt; ist die @var{Datei} eine flache Datei und @var{recursive?} ist wahr, wird ihr Inhalt in den Store eingelagert und ihre Berechtigungs-Bits übernommen. Steht @var{recursive?} auf wahr, wird @code{(@var{select?} @var{Datei} @var{Stat})} für jeden Verzeichniseintrag aufgerufen, wobei @var{Datei} der absolute Dateiname und @var{Stat} das Ergebnis von @code{lstat} ist, außer auf den Einträgen, wo @var{select?} keinen wahren Wert liefert. Folgendes Beispiel fügt eine Datei unter zwei verschiedenen Namen in den Store ein: @example (run-with-store (open-connection) (mlet %store-monad ((a (interned-file "README")) (b (interned-file "README" "LEGU-MIN"))) (return (list a b)))) @result{} ("/gnu/store/rwm@dots{}-README" "/gnu/store/44i@dots{}-LEGU-MIN") @end example @end deffn Das Modul @code{(guix packages)} exportiert die folgenden paketbezogenen monadischen Prozeduren: @deffn {Monadische Prozedur} package-file @var{Paket} [@var{Datei}] @ [#:system (%current-system)] [#:target #f] @ [#:output "out"] Liefert als monadischen Wert den absoluten Dateinamen der @var{Datei} innerhalb des Ausgabeverzeichnisses @var{output} des @var{Paket}s. Wird keine @var{Datei} angegeben, wird der Name des Ausgabeverzeichnisses @var{output} für das @var{Paket} zurückgeliefert. Ist @var{target} wahr, wird sein Wert als das Zielsystem bezeichnendes Tripel zum Cross-Kompilieren benutzt. @end deffn @deffn {Monadische Prozedur} package->derivation @var{Paket} [@var{System}] @deffnx {Monadische Prozedur} package->cross-derivation @var{Paket} @ @var{Ziel} [@var{System}] Monadische Version von @code{package-derivation} und @code{package-cross-derivation} (siehe @ref{Pakete definieren}). @end deffn @node G-Ausdrücke @section G-Ausdrücke @cindex G-Ausdruck @cindex Erstellungscode maskieren Es gibt also »Ableitungen«, die eine Abfolge von Erstellungsaktionen repräsentieren, die durchgeführt werden müssen, um ein Objekt im Store zu erzeugen (siehe @ref{Ableitungen}). Diese Erstellungsaktionen werden durchgeführt, nachdem der Daemon gebeten wurde, die Ableitungen tatsächlich zu erstellen; dann führt der Daemon sie in einer isolierten Umgebung (einem sogenannten Container) aus (siehe @ref{Aufruf des guix-daemon}). @cindex Schichten von Code Wenig überraschend ist, dass wir diese Erstellungsaktionen gerne in Scheme schreiben würden. Wenn wir das tun, bekommen wir zwei verschiedene @dfn{Schichten} von Scheme-Code@footnote{Der Begriff @dfn{Schicht}, englisch Stratum, wurde in diesem Kontext von Manuel Serrano et al.@: in ihrer Arbeit an Hop geprägt. Oleg Kiselyov, der aufschlussreiche @url{http://okmij.org/ftp/meta-programming/#meta-scheme, Essays und Code zu diesem Thema} geschrieben hat, nennt diese Art der Code-Generierung @dfn{Staging}, deutsch etwa Inszenierung bzw.@: Aufführung.}: den »wirtsseitigen Code« (»host code«) — also Code, der Pakete definiert, mit dem Daemon kommuniziert etc.@: — und den »erstellungsseitigen Code« (»build code«) — also Code, der die Erstellungsaktionen auch wirklich umsetzt, indem Dateien erstellt werden, @command{make} aufgerufen wird etc. Um eine Ableitung und ihre Erstellungsaktionen zu beschreiben, muss man normalerweise erstellungsseitigen Code im wirtsseitigen Code einbetten. Das bedeutet, man behandelt den erstellungsseitigen Code als Daten, was wegen der Homoikonizität von Scheme — dass Code genauso als Daten repräsentiert werden kann — sehr praktisch ist. Doch brauchen wir hier mehr als nur den normalen Quasimaskierungsmechanismus mit @code{quasiquote} in Scheme, wenn wir Erstellungsausdrücke konstruieren möchten. Das Modul @code{(guix gexp)} implementiert @dfn{G-Ausdrücke}, eine Form von S-Ausdrücken, die zu Erstellungsausdrücken angepasst wurden. G-Ausdrücke (englisch »G-expressions«, kurz @dfn{Gexps}) setzen sich grundlegend aus drei syntaktischen Formen zusammen: @code{gexp}, @code{ungexp} und @code{ungexp-splicing} (alternativ einfach: @code{#~}, @code{#$} und @code{#$@@}), die jeweils mit @code{quasiquote}, @code{unquote} und @code{unquote-splicing} vergleichbar sind (siehe @ref{Expression Syntax, @code{quasiquote},, guile, GNU Guile Reference Manual}). Es gibt aber auch erhebliche Unterschiede: @itemize @item G-Ausdrücke sind dafür gedacht, in eine Datei geschrieben zu werden, wo sie von anderen Prozessen ausgeführt oder manipuliert werden können. @item Wenn ein abstraktes Objekt wie ein Paket oder eine Ableitung innerhalb eines G-Ausdrücks demaskiert wird, ist das Ergebnis davon dasselbe, wie wenn dessen Ausgabedateiname genannt worden wäre. @item G-Ausdrücke tragen Informationen über die Pakete oder Ableitungen mit sich, auf die sie sich beziehen, und diese Abhängigkeiten werden automatisch zu den sie benutzenden Erstellungsprozessen als Eingaben hinzugefügt. @end itemize @cindex Herunterbrechen, von abstrakten Objekten in G-Ausdrücken Dieser Mechanismus ist nicht auf Pakete und Ableitung beschränkt: Es können @dfn{Compiler} definiert werden, die weitere abstrakte, hochsprachliche Objekte auf Ableitungen oder Dateien im Store »herunterbrechen«, womit diese Objekte dann auch in G-Ausdrücken eingefügt werden können. Zum Beispiel sind »dateiartige Objekte« ein nützlicher Typ solcher abstrakter Objekte. Mit ihnen können Dateien leicht in den Store eingefügt und von Ableitungen und anderem referenziert werden (siehe unten @code{local-file} und @code{plain-file}). Zur Veranschaulichung dieser Idee soll uns dieses Beispiel eines G-Ausdrucks dienen: @example (define build-exp #~(begin (mkdir #$output) (chdir #$output) (symlink (string-append #$coreutils "/bin/ls") "list-files"))) @end example Indem wir diesen G-Ausdruck an @code{gexp->derivation} übergeben, bekommen wir eine Ableitung, die ein Verzeichnis mit genau einer symbolischen Verknüpfung auf @file{/gnu/store/@dots{}-coreutils-8.22/bin/ls} erstellt: @example (gexp->derivation "das-ding" build-exp) @end example Wie man es erwarten würde, wird die Zeichenkette @code{"/gnu/store/@dots{}-coreutils-8.22"} anstelle der Referenzen auf das Paket @var{coreutils} im eigentlichen Erstellungscode eingefügt und @var{coreutils} automatisch zu einer Eingabe der Ableitung gemacht. Genauso wird auch @code{#$output} (was äquivalent zur Schreibweise @code{(ungexp output)} ist) ersetzt durch eine Zeichenkette mit dem Namen der Ausgabe der Ableitung. @cindex Cross-Kompilieren Im Kontext der Cross-Kompilierung bietet es sich an, zwischen Referenzen auf die @emph{native} Erstellung eines Pakets — also der, die auf dem Wirtssystem ausgeführt werden kann — und Referenzen auf Cross-Erstellungen eines Pakets zu unterscheiden. Hierfür spielt @code{#+} dieselbe Rolle wie @code{#$}, steht aber für eine Referenz auf eine native Paketerstellung. @example (gexp->derivation "vi" #~(begin (mkdir #$output) (system* (string-append #+coreutils "/bin/ln") "-s" (string-append #$emacs "/bin/emacs") (string-append #$output "/bin/vi"))) #:target "mips64el-linux-gnu") @end example @noindent Im obigen Beispiel wird die native Erstellung der @var{coreutils} benutzt, damit @command{ln} tatsächlich auf dem Wirtssystem ausgeführt werden kann, aber danach die cross-kompilierte Erstellung von @var{emacs} referenziert. @cindex importierte Module, in G-Ausdrücken @findex with-imported-modules Eine weitere Funktionalität von G-Ausdrücken stellen @dfn{importierte Module} dar. Manchmal will man bestimmte Guile-Module von der »wirtsseitigen Umgebung« im G-Ausdruck benutzen können, deswegen sollten diese Module in die »erstellungsseitige Umgebung« importiert werden. Die @code{with-imported-modules}-Form macht das möglich: @example (let ((build (with-imported-modules '((guix build utils)) #~(begin (use-modules (guix build utils)) (mkdir-p (string-append #$output "/bin")))))) (gexp->derivation "leeres-Verzeichnis" #~(begin #$build (display "Erfolg!\n") #t))) @end example @noindent In diesem Beispiel wird das Modul @code{(guix build utils)} automatisch in die isolierte Erstellungsumgebung unseres G-Ausdrucks geholt, so dass @code{(use-modules (guix build utils))} wie erwartet funktioniert. @cindex Modulabschluss @findex source-module-closure Normalerweise möchten Sie, dass der @emph{Abschluss} eines Moduls importiert wird — also das Modul und alle Module, von denen es abhängt — statt nur das Modul selbst. Ansonsten scheitern Versuche, das Modul zu benutzen, weil seine Modulabhängigkeiten fehlen. Die Prozedur @code{source-module-closure} berechnet den Abschluss eines Moduls, indem es den Kopf seiner Quelldatei analysiert, deswegen schafft die Prozedur hier Abhilfe: @example (use-modules (guix modules)) ;»source-module-closure« verfügbar machen (with-imported-modules (source-module-closure '((guix build utils) (gnu build vm))) (gexp->derivation "etwas-mit-vms" #~(begin (use-modules (guix build utils) (gnu build vm)) @dots{}))) @end example @cindex Erweiterungen, für G-Ausdrücke @findex with-extensions Auf die gleiche Art können Sie auch vorgehen, wenn Sie nicht bloß reine Scheme-Module importieren möchten, sondern auch »Erweiterungen« wie Guile-Anbindungen von C-Bibliotheken oder andere »vollumfängliche« Pakete. Sagen wir, Sie bräuchten das Paket @code{guile-json} auf der Erstellungsseite, dann könnten Sie es hiermit bekommen: @example (use-modules (gnu packages guile)) ;für »guile-json« (with-extensions (list guile-json) (gexp->derivation "etwas-mit-json" #~(begin (use-modules (json)) @dots{}))) @end example Die syntaktische Form, in der G-Ausdrücke konstruiert werden, ist im Folgenden zusammengefasst. @deffn {Scheme-Syntax} #~@var{Ausdruck} @deffnx {Scheme-Syntax} (gexp @var{Ausdruck}) Liefert einen G-Ausdruck, der den @var{Ausdruck} enthält. Der @var{Ausdruck} kann eine oder mehrere der folgenden Formen enthalten: @table @code @item #$@var{Objekt} @itemx (ungexp @var{Objekt}) Eine Referenz auf das @var{Objekt} einführen. Das @var{Objekt} kann einen der unterstützten Typen haben, zum Beispiel ein Paket oder eine Ableitung, so dass die @code{ungexp}-Form durch deren Ausgabedateiname ersetzt wird — z.B.@: @code{"/gnu/store/@dots{}-coreutils-8.22}. Wenn das @var{Objekt} eine Liste ist, wird diese durchlaufen und alle unterstützten Objekte darin auf diese Weise ersetzt. Wenn das @var{Objekt} ein anderer G-Ausdruck ist, wird sein Inhalt eingefügt und seine Abhängigkeiten zu denen des äußeren G-Ausdrucks hinzugefügt. Wenn das @var{Objekt} eine andere Art von Objekt ist, wird es so wie es ist eingefügt. @item #$@var{Objekt}:@var{Ausgabe} @itemx (ungexp @var{Objekt} @var{Ausgabe}) Dies verhält sich wie die Form oben, bezieht sich aber ausdrücklich auf die angegebene @var{Ausgabe} des @var{Objekt}s — dies ist nützlich, wenn das @var{Objekt} mehrere Ausgaben generiert (siehe @ref{Pakete mit mehreren Ausgaben.}). @item #+@var{Objekt} @itemx #+@var{Objekt}:@var{Ausgabe} @itemx (ungexp-native @var{Objekt}) @itemx (ungexp-native @var{Objekt} @var{Ausgabe}) Das Gleiche wie @code{ungexp}, jedoch wird im Kontext einer Cross-Kompilierung eine Referenz auf die @emph{native} Erstellung des @var{Objekt}s eingefügt. @item #$output[:@var{Ausgabe}] @itemx (ungexp output [@var{Ausgabe}]) Fügt eine Referenz auf die angegebene @var{Ausgabe} dieser Ableitung ein, oder auf die Hauptausgabe, wenn keine @var{Ausgabe} angegeben wurde. Dies ist nur bei G-Ausdrücken sinnvoll, die an @code{gexp->derivation} übergeben werden. @item #$@@@var{Liste} @itemx (ungexp-splicing @var{Liste}) Das Gleiche wie oben, jedoch wird nur der Inhalt der @var{Liste} in die äußere Liste eingespleißt. @item #+@@@var{Liste} @itemx (ungexp-native-splicing @var{Liste}) Das Gleiche, aber referenziert werden native Erstellungen der Objekte in der @var{Liste}. @end table G-Ausdrücke, die mit @code{gexp} oder @code{#~} erzeugt wurden, sind zur Laufzeit Objekte vom Typ @code{gexp?} (siehe unten). @end deffn @deffn {Scheme-Syntax} with-imported-modules @var{Module} @var{Rumpf}@dots{} Markiert die in @var{Rumpf}@dots{} definierten G-Ausdrücke, dass sie in ihrer Ausführungsumgebung die angegebenen @var{Module} brauchen. Jedes Objekt unter den @var{Module}n kann der Name eines Moduls wie @code{(guix build utils)} sein, oder es kann nacheinander ein Modulname, ein Pfeil und ein dateiartiges Objekt sein: @example `((guix build utils) (guix gcrypt) ((guix config) => ,(scheme-file "config.scm" #~(define-module @dots{})))) @end example @noindent Im Beispiel oben werden die ersten beiden Module vom Suchpfad genommen und das letzte aus dem angegebenen dateiartigen Objekt erzeugt. Diese Form hat einen @emph{lexikalischen} Sichtbarkeitsbereich: Sie wirkt sich auf die direkt in @var{Rumpf}@dots{} definierten G-Ausdrücke aus, aber nicht auf jene, die, sagen wir, in aus @var{Rumpf}@dots{} heraus aufgerufenen Prozeduren definiert wurden. @end deffn @deffn {Scheme-Syntax} with-extensions @var{Erweiterungen} @var{Rumpf}@dots{} Markiert die in @var{Rumpf}@dots{} definierten G-Ausdrücke, dass sie @var{Erweiterungen} in ihrer Erstellungs- und Ausführungsumgebung benötigen. @var{Erweiterungen} sind typischerweise eine Liste von Paketobjekten wie zum Beispiel die im Modul @code{(gnu packages guile)} definierten. Konkret werden die unter den @var{Erweiterungen} aufgeführten Pakete zum Ladepfad hinzugefügt, während die in @var{Rumpf}@dots{} aufgeführten importierten Module kompiliert werden und sie werden auch zum Ladepfad des von @var{Rumpf}@dots{} gelieferten G-Ausdrucks hinzugefügt. @end deffn @deffn {Scheme-Prozedur} gexp? @var{Objekt} Liefert @code{#t}, wenn das @var{Objekt} ein G-Ausdruck ist. @end deffn G-Ausdrücke sind dazu gedacht, auf die Platte geschrieben zu werden, entweder als Code, der eine Ableitung erstellt, oder als einfache Dateien im Store. Die monadischen Prozeduren unten ermöglichen Ihnen das (siehe @ref{Die Store-Monade}, wenn Sie mehr Informationen über Monaden suchen). @deffn {Monadische Prozedur} gexp->derivation @var{Name} @var{Ausdruck} @ [#:system (%current-system)] [#:target #f] [#:graft? #t] @ [#:hash #f] [#:hash-algo #f] @ [#:recursive? #f] [#:env-vars '()] [#:modules '()] @ [#:module-path @var{%load-path}] @ [#:effective-version "2.2"] @ [#:references-graphs #f] [#:allowed-references #f] @ [#:disallowed-references #f] @ [#:leaked-env-vars #f] @ [#:script-name (string-append @var{Name} "-builder")] @ [#:deprecation-warnings #f] @ [#:local-build? #f] [#:substitutable? #t] @ [#:properties '()] [#:guile-for-build #f] Liefert eine Ableitung unter dem @var{Name}n, die jeden @var{Ausdruck} (ein G-Ausdruck) mit @var{guile-for-build} (eine Ableitung) für das @var{System} erstellt; der @var{Ausdruck} wird dabei in einer Datei namens @var{script-name} gespeichert. Wenn »@var{target}« wahr ist, wird es beim Cross-Kompilieren als Zieltripel für mit @var{Ausdruck} bezeichnete Pakete benutzt. @var{modules} gilt als veraltet; stattdessen sollte @code{with-imported-modules} benutzt werden. Die Bedeutung ist, dass die @var{Module} im Ausführungskontext des @var{Ausdruck}s verfügbar gemacht werden; @var{modules} ist dabei eine Liste von Namen von Guile-Modulen, die im Modulpfad @var{module-path} gesucht werden, um sie in den Store zu kopieren, zu kompilieren und im Ladepfad während der Ausführung des @var{Ausdruck}s verfügbar zu machen — z.B.@: @code{((guix build utils) (guix build gnu-build-system))}. @var{effective-version} bestimmt, unter welcher Zeichenkette die Erweiterungen des @var{Ausdruck}s zum Suchpfad hinzugefügt werden (siehe @code{with-extensions}) — z.B.@: @code{"2.2"}. @var{graft?} bestimmt, ob vom @var{Ausdruck} benannte Pakete veredelt werden sollen, falls Veredelungen zur Verfügung stehen. Ist @var{references-graphs} wahr, muss es eine Liste von Tupeln in einer der folgenden Formen sein: @example (@var{Dateiname} @var{Paket}) (@var{Dateiname} @var{Paket} @var{Ausgabe}) (@var{Dateiname} @var{Ableitung}) (@var{Dateiname} @var{Ableitung} @var{Ausgabe}) (@var{Dateiname} @var{Store-Objekt}) @end example Bei jedem Element von @var{references-graphs} wird das rechts Stehende automatisch zu einer Eingabe des Erstellungsprozesses vom @var{Ausdruck} gemacht. In der Erstellungsumgebung enthält das, was mit @var{Dateiname} bezeichnet wird, den Referenzgraphen des entsprechenden Objekts in einem einfachen Textformat. @var{allowed-references} muss entweder @code{#f} oder eine Liste von Ausgabenamen und Paketen sein. Eine solche Liste benennt Store-Objekte, die das Ergebnis referenzieren darf. Jede Referenz auf ein nicht dort aufgeführtes Store-Objekt löst einen Erstellungsfehler aus. Genauso funktioniert @var{disallowed-references}, was eine Liste von Objekten sein kann, die von den Ausgaben nicht referenziert werden dürfen. @var{deprecation-warnings} bestimmt, ob beim Kompilieren von Modulen Warnungen angezeigt werden sollen, wenn auf als veraltet markierten Code zugegriffen wird (»deprecation warnings«). @var{deprecation-warnings} kann @code{#f}, @code{#t} oder @code{'detailed} (detailliert) sein. Die anderen Argumente verhalten sich wie bei @code{derivation} (siehe @ref{Ableitungen}). @end deffn @cindex dateiartige Objekte Die im Folgenden erklärten Prozeduren @code{local-file}, @code{plain-file}, @code{computed-file}, @code{program-file} und @code{scheme-file} liefern @dfn{dateiartige Objekte}. Das bedeutet, dass diese Objekte, wenn sie in einem G-Ausdruck demaskiert werden, zu einer Datei im Store führen. Betrachten Sie zum Beispiel diesen G-Ausdruck: @example #~(system* #$(file-append glibc "/sbin/nscd") "-f" #$(local-file "/tmp/my-nscd.conf")) @end example Der Effekt hiervon ist, dass @file{/tmp/my-nscd.conf} »interniert« wird, indem es in den Store kopiert wird. Sobald er umgeschrieben wurde, zum Beispiel über @code{gexp->derivation}, referenziert der G-Ausdruck diese Kopie im @file{/gnu/store}. Die Datei in @file{/tmp} zu bearbeiten oder zu löschen, hat dann keinen Effekt mehr darauf, was der G-Ausdruck tut. @code{plain-file} kann in ähnlicher Weise benutzt werden, es unterscheidet sich aber darin, dass dort der Prozedur der Inhalt der Datei als eine Zeichenkette übergeben wird. @deffn {Scheme-Prozedur} local-file @var{Datei} [@var{Name}] @ [#:recursive? #f] [#:select? (const #t)] Liefert ein Objekt, dass die lokale Datei @var{Datei} repräsentiert und sie zum Store hinzufügen lässt; dieses Objekt kann in einem G-Ausdruck benutzt werden. Wurde für die @var{Datei} ein relativer Dateiname angegeben, wird sie relativ zur Quelldatei gesucht, in der diese Form steht. Die @var{Datei} wird unter dem angegebenen @var{Name}n im Store abgelegt — als Vorgabe wird dabei der Basisname der @var{Datei} genommen. Ist @var{recursive?} wahr, werden in der @var{Datei} enthaltene Dateien rekursiv hinzugefügt; ist die @var{Datei} eine flache Datei und @var{recursive?} ist wahr, wird ihr Inhalt in den Store eingelagert und ihre Berechtigungs-Bits übernommen. Steht @var{recursive?} auf wahr, wird @code{(@var{select?} @var{Datei} @var{Stat})} für jeden Verzeichniseintrag aufgerufen, wobei @var{Datei} der absolute Dateiname und @var{Stat} das Ergebnis von @code{lstat} ist, außer auf den Einträgen, wo @var{select?} keinen wahren Wert liefert. Dies ist das deklarative Gegenstück zur monadischen Prozedur @code{interned-file} (siehe @ref{Die Store-Monade, @code{interned-file}}). @end deffn @deffn {Scheme-Prozedur} plain-file @var{Name} @var{Inhalt} Liefert ein Objekt, das eine Textdatei mit dem angegebenen @var{Name}n repräsentiert, die den angegebenen @var{Inhalt} hat (eine Zeichenkette oder ein Bytevektor), welche zum Store hinzugefügt werden soll. Dies ist das deklarative Gegenstück zu @code{text-file}. @end deffn @deffn {Scheme-Prozedur} computed-file @var{Name} @var{G-Ausdruck} @ [#:options '(#:local-build? #t)] Liefert ein Objekt, das das Store-Objekt mit dem @var{Name}n repräsentiert, eine Datei oder ein Verzeichnis, das vom @var{G-Ausdruck} berechnet wurde. @var{options} ist eine Liste zusätzlicher Argumente, die an @code{gexp->derivation} übergeben werden. Dies ist das deklarative Gegenstück zu @code{gexp->derivation}. @end deffn @deffn {Monadische Prozedur} gexp->script @var{Name} @var{Ausdruck} @ [#:guile (default-guile)] [#:module-path %load-path] Liefert ein ausführbares Skript namens @var{Name}, das den @var{Ausdruck} mit dem angegebenen @var{guile} ausführt, wobei vom @var{Ausdruck} importierte Module in seinem Suchpfad stehen. Die Module des @var{Ausdruck}s werden dazu im Modulpfad @var{module-path} gesucht. Folgendes Beispiel erstellt ein Skript, das einfach nur den Befehl @command{ls} ausführt: @example (use-modules (guix gexp) (gnu packages base)) (gexp->script "list-files" #~(execl #$(file-append coreutils "/bin/ls") "ls")) @end example Lässt man es durch den Store »laufen« (siehe @ref{Die Store-Monade, @code{run-with-store}}), erhalten wir eine Ableitung, die eine ausführbare Datei @file{/gnu/store/@dots{}-list-files} generiert, ungefähr so: @example #!/gnu/store/@dots{}-guile-2.0.11/bin/guile -ds !# (execl "/gnu/store/@dots{}-coreutils-8.22"/bin/ls" "ls") @end example @end deffn @deffn {Scheme-Prozedur} program-file @var{Name} @var{G-Ausdruck} @ [#:guile #f] [#:module-path %load-path] Liefert ein Objekt, das eine ausführbare Store-Datei @var{Name} repräsentiert, die den @var{G-Ausdruck} ausführt. @var{guile} ist das zu verwendende Guile-Paket, mit dem das Skript ausgeführt werden kann. Importierte Module des @var{G-Ausdruck}s werden im Modulpfad @var{module-path} gesucht. Dies ist das deklarative Gegenstück zu @code{gexp->script}. @end deffn @deffn {Monadische Prozedur} gexp->file @var{Name} @var{G-Ausdruck} @ [#:set-load-path? #t] [#:module-path %load-path] @ [#:splice? #f] @ [#:guile (default-guile)] Liefert eine Ableitung, die eine Datei @var{Name} erstellen wird, deren Inhalt der @var{G-Ausdruck} ist. Ist @var{splice?} wahr, dann wird @var{G-Ausdruck} stattdessen als eine Liste von mehreren G-Ausdrücken behandelt, die alle in die resultierende Datei gespleißt werden. Ist @var{set-load-path?} wahr, wird in die resultierende Datei Code hinzugefügt, der den Ladepfad @code{%load-path} und den Ladepfad für kompilierte Dateien @code{%load-compiled-path} festlegt, die für die importierten Module des @var{G-Ausdruck}s nötig sind. Die Module des @var{G-Ausdruck}s werden im Modulpfad @var{module-path} gesucht. Die resultierende Datei referenziert alle Abhängigkeiten des @var{G-Ausdruck}s oder eine Teilmenge davon. @end deffn @deffn {Scheme-Prozedur} scheme-file @var{Name} @var{G-Ausdruck} [#:splice? #f] Liefert ein Objekt, das die Scheme-Datei @var{Name} mit dem @var{G-Ausdruck} als Inhalt repräsentiert. Dies ist das deklarative Gegenstück zu @code{gexp->file}. @end deffn @deffn {Monadische Prozedur} text-file* @var{Name} @var{Text} @dots{} Liefert eine Ableitung als monadischen Wert, welche eine Textdatei erstellt, in der der gesamte @var{Text} enthalten ist. @var{Text} kann eine Folge nicht nur von Zeichenketten, sondern auch Objekten beliebigen Typs sein, die in einem G-Ausdruck benutzt werden können, also Paketen, Ableitungen, Objekte lokaler Dateien und so weiter. Die resultierende Store-Datei referenziert alle davon. Diese Variante sollte gegenüber @code{text-file} bevorzugt verwendet werden, wann immer die zu erstellende Datei Objekte im Store referenzieren wird. Typischerweise ist das der Fall, wenn eine Konfigurationsdatei erstellt wird, die Namen von Store-Dateien enthält, so wie hier: @example (define (profile.sh) ;; Liefert den Namen eines Shell-Skripts im Store, ;; welcher die Umgebungsvariable »PATH« initialisiert. (text-file* "profile.sh" "export PATH=" coreutils "/bin:" grep "/bin:" sed "/bin\n")) @end example In diesem Beispiel wird die resultierende Datei @file{/gnu/store/@dots{}-profile.sh} sowohl @var{coreutils}, @var{grep} als auch @var{sed} referenzieren, so dass der Müllsammler diese nicht löscht, während die resultierende Datei noch lebendig ist. @end deffn @deffn {Scheme-Prozedur} mixed-text-file @var{Name} @var{Text} @dots{} Liefert ein Objekt, was die Store-Datei @var{Name} repräsentiert, die @var{Text} enthält. @var{Text} ist dabei eine Folge von Zeichenketten und dateiartigen Objekten wie zum Beispiel: @example (mixed-text-file "profile" "export PATH=" coreutils "/bin:" grep "/bin") @end example Dies ist das deklarative Gegenstück zu @code{text-file*}. @end deffn @deffn {Scheme-Prozedur} file-union @var{Name} @var{Dateien} Liefert ein @code{}, das ein Verzeichnis mit allen @var{Dateien} enthält. Jedes Objekt in @var{Dateien} muss eine zweielementige Liste sein, deren erstes Element der im neuen Verzeichnis zu benutzende Dateiname ist und deren zweites Element ein G-Ausdruck ist, der die Zieldatei benennt. Hier ist ein Beispiel: @example (file-union "etc" `(("hosts" ,(plain-file "hosts" "127.0.0.1 localhost")) ("bashrc" ,(plain-file "bashrc" "alias ls='ls --color=auto'")))) @end example Dies liefert ein Verzeichnis @code{etc}, das zwei Dateien enthält. @end deffn @deffn {Scheme-Prozedur} directory-union @var{Name} @var{Dinge} Liefert ein Verzeichnis, was die Vereinigung (englisch »Union«) der @var{Dinge} darstellt, wobei @var{Dinge} eine Liste dateiartiger Objekte sein muss, die Verzeichnisse bezeichnen. Zum Beispiel: @example (directory-union "guile+emacs" (list guile emacs)) @end example Das liefert ein Verzeichnis, welches die Vereinigung der Pakete @code{guile} und @code{emacs} ist. @end deffn @deffn {Scheme-Prozedur} file-append @var{Objekt} @var{Suffix} @dots{} Liefert ein dateiartiges Objekt, das zur Aneinanderreihung von @var{Objekt} und @var{Suffix} umgeschrieben wird, wobei das @var{Objekt} ein herunterbrechbares Objekt und jedes @var{Suffix} eine Zeichenkette sein muss. Betrachten Sie zum Beispiel diesen G-Ausdruck: @example (gexp->script "uname-ausfuehren" #~(system* #$(file-append coreutils "/bin/uname"))) @end example Denselben Effekt könnte man erreichen mit: @example (gexp->script "uname-ausfuehren" #~(system* (string-append #$coreutils "/bin/uname"))) @end example Es gibt jedoch einen Unterschied, nämlich enthält das resultierende Skript bei @code{file-append} tatsächlich den absoluten Dateinamen als Zeichenkette, während im anderen Fall das resultierende Skript einen Ausdruck @code{(string-append @dots{})} enthält, der den Dateinamen erst @emph{zur Laufzeit} zusammensetzt. @end deffn Natürlich gibt es zusätzlich zu in »wirtsseitigem« Code eingebetteten G-Ausdrücken auch Module mit »erstellungsseitig« nutzbaren Werkzeugen. Um klarzustellen, dass sie dafür gedacht sind, in der Erstellungsschicht benutzt zu werden, bleiben diese Module im Namensraum @code{(guix build @dots{})}. @cindex Herunterbrechen, von abstrakten Objekten in G-Ausdrücken Intern werden hochsprachliche, abstrakte Objekte mit ihrem Compiler entweder zu Ableitungen oder zu Store-Objekten @dfn{heruntergebrochen}. Wird zum Beispiel ein Paket heruntergebrochen, bekommt man eine Ableitung, während ein @code{plain-file} zu einem Store-Objekt heruntergebrochen wird. Das wird mit der monadischen Prozedur @code{lower-object} bewerkstelligt. @deffn {Monadische Prozedur} lower-object @var{Objekt} [@var{System}] @ [#:target #f] Liefert die Ableitung oder das Store-Objekt, das dem @var{Objekt} für @var{System} als Wert in der Store-Monade @var{%store-monad} entspricht, cross-kompiliert für das Zieltripel @var{target}, wenn @var{target} wahr ist. Das @var{Objekt} muss ein Objekt sein, für das es einen mit ihm assoziierten G-Ausdruck-Compiler gibt, wie zum Beispiel ein @code{}. @end deffn @node Aufruf von guix repl @section @command{guix repl} aufrufen @cindex REPL (Lese-Auswerten-Schreiben-Schleife) Der Befehl @command{guix repl} startet eine Guile-REPL (@dfn{Read-Eval-Print Loop}, kurz REPL, deutsch Lese-Auswerten-Schreiben-Schleife) zur interaktiven Programmierung (siehe @ref{Using Guile Interactively,,, guile, GNU Guile Reference Manual}). Im Vergleich dazu, einfach den Befehl @command{guile} aufzurufen, garantiert @command{guix repl}, dass alle Guix-Module und deren Abhängigkeiten im Suchpfad verfügbar sind. Sie können die REPL so benutzen: @example $ guix repl scheme@@(guile-user)> ,use (gnu packages base) scheme@@(guile-user)> coreutils $1 = # @end example @cindex Untergeordnete @command{guix repl} implementiert zusätzlich ein einfaches maschinenlesbares Protokoll für die REPL, das von @code{(guix inferior)} benutzt wird, um mit @dfn{Untergeordneten} zu interagieren, also mit getrennten Prozessen einer womöglich anderen Version von Guix. Folgende @var{Optionen} gibt es: @table @code @item --type=@var{Typ} @itemx -t @var{Typ} Startet eine REPL des angegebenen @var{Typ}s, der einer der Folgenden sein darf: @table @code @item guile Die Voreinstellung, mit der eine normale, voll funktionsfähige Guile-REPL gestartet wird. @item machine Startet eine REPL, die ein maschinenlesbares Protokoll benutzt. Dieses Protokoll wird vom Modul @code{(guix inferior)} gesprochen. @end table @item --listen=@var{Endpunkt} Der Vorgabe nach würde @command{guix repl} von der Standardeingabe lesen und auf die Standardausgabe schreiben. Wird diese Befehlszeilenoption angegeben, lauscht die REPL stattdessen auf dem @var{Endpunkt} auf Verbindungen. Hier sind Beispiele gültiger Befehlszeilenoptionen: @table @code @item --listen=tcp:37146 Verbindungen mit dem »localhost« auf Port 37146 akzeptieren. @item --listen=unix:/tmp/socket Verbindungen zum Unix-Socket @file{/tmp/socket} akzeptieren. @end table @end table @c ********************************************************************* @node Zubehör @chapter Zubehör Dieser Abschnitt beschreibt die Befehlszeilenwerkzeuge von Guix. Manche davon richten sich hauptsächlich an Entwickler und solche Nutzer, die neue Paketdefinitionen schreiben, andere sind auch für ein breiteres Publikum nützlich. Sie ergänzen die Scheme-Programmierschnittstelle um bequeme Befehle. @menu * Aufruf von guix build:: Pakete aus der Befehlszeile heraus erstellen. * Aufruf von guix edit:: Paketdefinitionen bearbeiten. * Aufruf von guix download:: Herunterladen einer Datei und Ausgabe ihres Hashes. * Aufruf von guix hash:: Den kryptografischen Hash einer Datei berechnen. * Aufruf von guix import:: Paketdefinitionen importieren. * Aufruf von guix refresh:: Paketdefinitionen aktualisieren. * Aufruf von guix lint:: Fehler in Paketdefinitionen finden. * Aufruf von guix size:: Plattenplatzverbrauch profilieren. * Aufruf von guix graph:: Den Paketgraphen visualisieren. * Aufruf von guix publish:: Substitute teilen. * Aufruf von guix challenge:: Die Substitut-Server anfechten. * Aufruf von guix copy:: Mit einem entfernten Store Dateien austauschen. * Aufruf von guix container:: Prozesse isolieren. * Aufruf von guix weather:: Die Verfügbarkeit von Substituten einschätzen. * Aufruf von guix processes:: Auflisten der Client-Prozesse @end menu @node Aufruf von guix build @section Aufruf von @command{guix build} @cindex Paketerstellung @cindex @command{guix build} Der Befehl @command{guix build} lässt Pakete oder Ableitungen samt ihrer Abhängigkeiten erstellen und gibt die resultierenden Pfade im Store aus. Beachten Sie, dass das Nutzerprofil dadurch nicht modifiziert wird — eine solche Installation bewirkt der Befehl @command{guix package} (siehe @ref{Aufruf von guix package}). @command{guix build} wird also hauptsächlich von Entwicklern der Distribution benutzt. Die allgemeine Syntax lautet: @example guix build @var{Optionen} @var{Paket-oder-Ableitung}@dots{} @end example Zum Beispiel wird mit folgendem Befehl die neueste Version von Emacs und von Guile erstellt, das zugehörige Erstellungsprotokoll angezeigt und letztendlich werden die resultierenden Verzeichnisse ausgegeben: @example guix build emacs guile @end example Folgender Befehl erstellt alle Pakete, die zur Verfügung stehen: @example guix build --quiet --keep-going \ `guix package -A | cut -f1,2 --output-delimiter=@@` @end example Als @var{Paket-oder-Ableitung} muss entweder der Name eines in der Software-Distribution zu findenden Pakets, wie etwa @code{coreutils} oder @code{coreutils@@8.20}, oder eine Ableitung wie @file{/gnu/store/@dots{}-coreutils-8.19.drv} sein. Im ersten Fall wird nach einem Paket mit entsprechendem Namen (und optional der entsprechenden Version) in den Modulen der GNU-Distribution gesucht (siehe @ref{Paketmodule}). Alternativ kann die Befehlszeilenoption @code{--expression} benutzt werden, um einen Scheme-Ausdruck anzugeben, der zu einem Paket ausgewertet wird; dies ist nützlich, wenn zwischen mehreren gleichnamigen Paketen oder Paket-Varianten unterschieden werden muss. Null oder mehr @var{Optionen} können angegeben werden. Zur Verfügung stehen die in den folgenden Unterabschnitten beschriebenen Befehlszeilenoptionen. @menu * Gemeinsame Erstellungsoptionen:: Erstellungsoptionen für die meisten Befehle. * Paketumwandlungsoptionen:: Varianten von Paketen erzeugen. * Zusätzliche Erstellungsoptionen:: Optionen spezifisch für »guix build«. * Fehlschläge beim Erstellen untersuchen:: Praxiserfahrung bei der Paketerstellung. @end menu @node Gemeinsame Erstellungsoptionen @subsection Gemeinsame Erstellungsoptionen Einige dieser Befehlszeilenoptionen zur Steuerung des Erstellungsprozess haben @command{guix build} und andere Befehle, mit denen Erstellungen ausgelöst werden können, wie @command{guix package} oder @command{guix archive}, gemeinsam. Das sind folgende: @table @code @item --load-path=@var{Verzeichnis} @itemx -L @var{Verzeichnis} Das @var{Verzeichnis} vorne an den Suchpfad für Paketmodule anfügen (siehe @ref{Paketmodule}). Damit können Nutzer dafür sorgen, dass ihre eigenen selbstdefinierten Pakete für die Befehlszeilenwerkzeuge sichtbar sind. @item --keep-failed @itemx -K Den Verzeichnisbaum, in dem fehlgeschlagene Erstellungen durchgeführt wurden, behalten. Wenn also eine Erstellung fehlschlägt, bleibt ihr Erstellungsbaum in @file{/tmp} erhalten. Der Name dieses Unterverzeichnisses wird am Ende dem Erstellungsprotokolls ausgegeben. Dies hilft bei der Suche nach Fehlern in Erstellungen. Der Abschnitt @ref{Fehlschläge beim Erstellen untersuchen} zeigt Ihnen Hinweise und Tricks, wie Erstellungsfehler untersucht werden können. Diese Option hat keine Auswirkungen, wenn eine Verbindung zu einem entfernten Daemon über eine @code{guix://}-URI verwendet wurde (siehe @ref{Der Store, the @code{GUIX_DAEMON_SOCKET} variable}). @item --keep-going @itemx -k Weitermachen, auch wenn ein Teil der Erstellungen fehlschlägt. Das bedeutet, dass der Befehl erst terminiert, wenn alle Erstellungen erfolgreich oder mit Fehler durchgeführt wurden. Das normale Verhalten ist, abzubrechen, sobald eine der angegebenen Ableitungen fehlschlägt. @item --dry-run @itemx -n Die Ableitungen nicht erstellen. @anchor{fallback-option} @item --fallback Wenn das Substituieren vorerstellter Binärdateien fehlschlägt, diese als »Fallback« lokal selbst erstellen (siehe @ref{Fehler bei der Substitution}). @item --substitute-urls=@var{URLs} @anchor{client-substitute-urls} Die @var{urls} als durch Leerraumzeichen getrennte Liste von Quell-URLs für Substitute anstelle der vorgegebenen URL-Liste für den @command{guix-daemon} verwenden (siehe @ref{daemon-substitute-urls,, @command{guix-daemon} URLs}). Das heißt, die Substitute dürfen von den @var{urls} heruntergeladen werden, sofern sie mit einem durch den Systemadministrator autorisierten Schlüssel signiert worden sind (siehe @ref{Substitute}). Wenn als @var{urls} eine leere Zeichenkette angegeben wurde, verhält es sich, als wären Substitute abgeschaltet. @item --no-substitutes Benutze keine Substitute für Erstellungsergebnisse. Das heißt, dass alle Objekte lokal erstellt werden müssen, und kein Herunterladen von vorab erstellten Binärdateien erlaubt ist (siehe @ref{Substitute}). @item --no-grafts Pakete nicht »veredeln« (engl. »graft«). Praktisch heißt das, dass als Veredelungen verfügbare Paketaktualisierungen nicht angewandt werden. Der Abschnitt @ref{Sicherheitsaktualisierungen} hat weitere Informationen zu Veredelungen. @item --rounds=@var{n} Jede Ableitung @var{n}-mal nacheinander erstellen und einen Fehler melden, wenn die aufeinanderfolgenden Erstellungsergebnisse nicht Bit für Bit identisch sind. Das ist eine nützliche Methode, um nicht-deterministische Erstellungsprozesse zu erkennen. Nicht-deterministische Erstellungsprozesse sind ein Problem, weil Nutzer dadurch praktisch nicht @emph{verifizieren} können, ob von Drittanbietern bereitgestellte Binärdateien echt sind. Der Abschnitt @ref{Aufruf von guix challenge} erklärt dies genauer. Beachten Sie, dass die sich unterscheidenden Erstellungsergebnisse nicht erhalten bleiben, so dass Sie eventuelle Fehler manuell untersuchen müssen, z.B.@: indem Sie eines oder mehrere der Erstellungsergebnisse @code{guix archive --export} auslagern (siehe @ref{Aufruf von guix archive}), dann neu erstellen und letztlich die beiden Erstellungsergebnisse vergleichen. @item --no-build-hook Nicht versuchen, Erstellungen über den »Build-Hook« des Daemons auszulagern (siehe @ref{Auslagern des Daemons einrichten}). Somit wird lokal erstellt, statt Erstellungen auf entfernte Maschinen auszulagern. @item --max-silent-time=@var{Sekunden} Wenn der Erstellungs- oder Substitutionsprozess länger als @var{Sekunden}-lang keine Ausgabe erzeugt, wird er abgebrochen und ein Fehler beim Erstellen gemeldet. Standardmäßig wird die Einstellung für den Daemon benutzt (siehe @ref{Aufruf des guix-daemon, @code{--max-silent-time}}). @item --timeout=@var{Sekunden} Entsprechend wird hier der Erstellungs- oder Substitutionsprozess abgebrochen und als Fehlschlag gemeldet, wenn er mehr als @var{Sekunden}-lang dauert. Standardmäßig wird die Einstellung für den Daemon benutzt (siehe @ref{Aufruf des guix-daemon, @code{--timeout}}). @c Note: This option is actually not part of %standard-build-options but @c most programs honor it. @cindex Ausführlichkeit der Befehlszeilenwerkzeuge @cindex Erstellungsprotokolle, Ausführlichkeit @item -v @var{Stufe} @itemx --verbosity=@var{Stufe} Die angegebene Ausführlichkeitsstufe verwenden. Als @var{Stufe} muss eine ganze Zahl angegeben werden. Wird 0 gewählt, wird keine Ausgabe zur Fehlersuche angezeigt, 1 bedeutet eine knappe Ausgabe und 2 lässt alle Erstellungsprotokollausgaben auf die Standardfehlerausgabe schreiben. @item --cores=@var{n} @itemx -c @var{n} Die Nutzung von bis zu @var{n} Prozessorkernen für die Erstellungen gestatten. Der besondere Wert @code{0} bedeutet, dass so viele wie möglich benutzt werden. @item --max-jobs=@var{n} @itemx -M @var{n} Höchstens @var{n} gleichzeitige Erstellungsaufträge erlauben. Im Abschnitt @ref{Aufruf des guix-daemon, @code{--max-jobs}} finden Sie Details zu dieser Option und der äquivalenten Option des @command{guix-daemon}. @item --debug=@var{Stufe} Ein Protokoll zur Fehlersuche ausgeben, das vom Erstellungsdaemon kommt. Als @var{Stufe} muss eine ganze Zahl zwischen 0 und 5 angegeben werden; höhere Zahlen stehen für ausführlichere Ausgaben. Stufe 4 oder höher zu wählen, kann bei der Suche nach Fehlern, wie der Erstellungs-Daemon eingerichtet ist, helfen. @end table Intern ist @command{guix build} im Kern eine Schnittstelle zur Prozedur @code{package-derivation} aus dem Modul @code{(guix packages)} und zu der Prozedur @code{build-derivations} des Moduls @code{(guix derivations)}. Neben auf der Befehlszeile übergebenen Optionen beachten @command{guix build} und andere @command{guix}-Befehle, die Erstellungen durchführen lassen, die Umgebungsvariable @code{GUIX_BUILD_OPTIONS}. @defvr {Umgebungsvariable} GUIX_BUILD_OPTIONS Nutzer können diese Variable auf eine Liste von Befehlszeilenoptionen definieren, die automatisch von @command{guix build} und anderen @command{guix}-Befehlen, die Erstellungen durchführen lassen, benutzt wird, wie in folgendem Beispiel: @example $ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar" @end example Diese Befehlszeilenoptionen werden unabhängig von den auf der Befehlszeile übergebenen Befehlszeilenoptionen grammatikalisch analysiert und das Ergebnis an die bereits analysierten auf der Befehlszeile übergebenen Befehlszeilenoptionen angehängt. @end defvr @node Paketumwandlungsoptionen @subsection Paketumwandlungsoptionen @cindex Paketvarianten Eine weitere Gruppe von Befehlszeilenoptionen, die @command{guix build} und auch @command{guix package} unterstützen, sind @dfn{Paketumwandlungsoptionen}. Diese Optionen ermöglichen es, @dfn{Paketvarianten} zu definieren — zum Beispiel können Pakete aus einem anderen Quellcode als normalerweise erstellt werden. Damit ist es leicht, angepasste Pakete schnell zu erstellen, ohne die vollständigen Definitionen von Paketvarianten einzutippen (siehe @ref{Pakete definieren}). @table @code @item --with-source=@var{Quelle} @itemx --with-source=@var{Paket}=@var{Quelle} @itemx --with-source=@var{Paket}@@@var{Version}=@var{Quelle} Den Paketquellcode für das @var{Paket} von der angegebenen @var{Quelle} holen und die @var{Version} als seine Versionsnummer verwenden. Die @var{Quelle} muss ein Dateiname oder eine URL sein wie bei @command{guix download} (siehe @ref{Aufruf von guix download}). Wird kein @var{Paket} angegeben, wird als Paketname derjenige auf der Befehlszeile angegebene Paketname angenommen, der zur Basis am Ende der @var{Quelle} passt — wenn z.B.@: als @var{Quelle} die Datei @code{/src/guile-2.0.10.tar.gz} angegeben wurde, entspricht das dem @code{guile}-Paket. Ebenso wird, wenn keine @var{Version} angegeben wurde, die Version als Zeichenkette aus der @var{Quelle} abgeleitet; im vorherigen Beispiel wäre sie @code{2.0.10}. Mit dieser Option können Nutzer versuchen, eine andere Version ihres Pakets auszuprobieren, als die in der Distribution enthaltene Version. Folgendes Beispiel lädt @file{ed-1.7.tar.gz} von einem GNU-Spiegelserver herunter und benutzt es als Quelle für das @code{ed}-Paket: @example guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz @end example Für Entwickler wird es einem durch @code{--with-source} leicht gemacht, »Release Candidates«, also Vorabversionen, zu testen: @example guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz @end example @dots{} oder ein Checkout eines versionskontrollierten Repositorys in einer isolierten Umgebung zu erstellen: @example $ git clone git://git.sv.gnu.org/guix.git $ guix build guix --with-source=guix@@1.0=./guix @end example @item --with-input=@var{Paket}=@var{Ersatz} Abhängigkeiten vom @var{Paket} durch eine Abhängigkeit vom @var{Ersatz}-Paket ersetzen. Als @var{Paket} muss ein Paketname angegeben werden und als @var{Ersatz} eine Paketspezifikation wie @code{guile} oder @code{guile@@1.8}. Mit folgendem Befehl wird zum Beispiel Guix erstellt, aber statt der aktuellen stabilen Guile-Version hängt es von der alten Guile-Version @code{guile@@2.0} ab: @example guix build --with-input=guile=guile@@2.0 guix @end example Die Ersetzung ist rekursiv und umfassend. In diesem Beispiel würde nicht nur @code{guix}, sondern auch seine Abhängigkeit @code{guile-json} (was auch von @code{guile} abhängt) für @code{guile@@2.0} neu erstellt. Implementiert wird das alles mit der Scheme-Prozedur @code{package-input-rewriting} (siehe @ref{Pakete definieren, @code{package-input-rewriting}}). @item --with-graft=@var{Paket}=@var{Ersatz} Dies verhält sich ähnlich wie mit @code{--with-input}, aber mit dem wichtigen Unterschied, dass nicht die gesamte Abhängigkeitskette neu erstellt wird, sondern das @var{Ersatz}-Paket erstellt und die ursprünglichen Binärdateien, die auf das @var{Paket} verwiesen haben, damit @dfn{veredelt} werden. Im Abschnitt @ref{Sicherheitsaktualisierungen} finden Sie weitere Informationen über Veredelungen. Zum Beispiel veredelt folgender Befehl Wget und alle Abhängigkeiten davon mit der Version 3.5.4 von GnuTLS, indem Verweise auf die ursprünglich verwendete GnuTLS-Version ersetzt werden: @example guix build --with-graft=gnutls=gnutls@@3.5.4 wget @end example Das hat den Vorteil, dass es viel schneller geht, als alles neu zu erstellen. Die Sache hat aber einen Haken: Veredelung funktioniert nur, wenn das @var{Paket} und sein @var{Ersatz} miteinander streng kompatibel sind — zum Beispiel muss, wenn diese eine Programmbibliothek zur Verfügung stellen, deren Binärschnittstelle (»Application Binary Interface«, kurz ABI) kompatibel sein. Wenn das @var{Ersatz}-Paket auf irgendeine Art inkompatibel mit dem @var{Paket} ist, könnte das Ergebnispaket unbrauchbar sein. Vorsicht ist also geboten! @item --with-git-url=@var{Paket}=@var{URL} @cindex Git, den neuesten Commit benutzen @cindex latest commit, building Build @var{package} from the latest commit of the @code{master} branch of the Git repository at @var{url}. Git sub-modules of the repository are fetched, recursively. For example, the following command builds the NumPy Python library against the latest commit of the master branch of Python itself: @example guix build python-numpy \ --with-git-url=python=https://github.com/python/cpython @end example This option can also be combined with @code{--with-branch} or @code{--with-commit} (see below). @cindex continuous integration Obviously, since it uses the latest commit of the given branch, the result of such a command varies over time. Nevertheless it is a convenient way to rebuild entire software stacks against the latest commit of one or more packages. This is particularly useful in the context of continuous integration (CI). Checkouts are kept in a cache under @file{~/.cache/guix/checkouts} to speed up consecutive accesses to the same repository. You may want to clean it up once in a while to save disk space. @item --with-branch=@var{Paket}=@var{Branch} Build @var{package} from the latest commit of @var{branch}. If the @code{source} field of @var{package} is an origin with the @code{git-fetch} method (@pxref{»origin«-Referenz}) or a @code{git-checkout} object, the repository URL is taken from that @code{source}. Otherwise you have to use @code{--with-git-url} to specify the URL of the Git repository. For instance, the following command builds @code{guile-sqlite3} from the latest commit of its @code{master} branch, and then builds @code{guix} (which depends on it) and @code{cuirass} (which depends on @code{guix}) against this specific @code{guile-sqlite3} build: @example guix build --with-branch=guile-sqlite3=master cuirass @end example @item --with-commit=@var{Paket}=@var{Commit} This is similar to @code{--with-branch}, except that it builds from @var{commit} rather than the tip of a branch. @var{commit} must be a valid Git commit SHA1 identifier. @end table @node Zusätzliche Erstellungsoptionen @subsection Zusätzliche Erstellungsoptionen Die unten aufgeführten Befehlszeilenoptionen funktionieren nur mit @command{guix build}. @table @code @item --quiet @itemx -q Schweigend erstellen, ohne das Erstellungsprotokoll anzuzeigen — dies ist äquivalent zu @code{--verbosity=0}. Nach Abschluss der Erstellung ist das Protokoll in @file{/var} (oder einem entsprechenden Ort) einsehbar und kann jederzeit mit der Befehlszeilenoption @option{--log-file} gefunden werden. @item --file=@var{Datei} @itemx -f @var{Datei} Das Paket, die Ableitung oder das dateiähnliche Objekt erstellen, zu dem der Code in der @var{Datei} ausgewertet wird (siehe @ref{G-Ausdrücke, file-like objects}). Zum Beispiel könnte in der @var{Datei} so eine Paketdefinition stehen (siehe @ref{Pakete definieren}): @example @verbatiminclude package-hello.scm @end example @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Das Paket oder die Ableitung erstellen, zu der der @var{Ausdruck} ausgewertet wird. Zum Beispiel kann der @var{Ausdruck} @code{(@@ (gnu packages guile) guile-1.8)} sein, was diese bestimmte Variante der Version 1.8 von Guile eindeutig bezeichnet. Alternativ kann der @var{Ausdruck} ein G-Ausdruck sein. In diesem Fall wird er als Erstellungsprogramm an @code{gexp->derivation} übergeben (siehe @ref{G-Ausdrücke}). Zudem kann der @var{Ausdruck} eine monadische Prozedur mit null Argumenten bezeichnen (siehe @ref{Die Store-Monade}). Die Prozedur muss eine Ableitung als monadischen Wert zurückliefern, die dann durch @code{run-with-store} laufen gelassen wird. @item --source @itemx -S Die Quellcode-Ableitung der Pakete statt die Pakete selbst erstellen. Zum Beispiel liefert @code{guix build -S gcc} etwas in der Art von @file{/gnu/store/@dots{}-gcc-4.7.2.tar.bz2}, also den Tarball mit dem GCC-Quellcode. Der gelieferte Quell-Tarball ist das Ergebnis davon, alle Patches und Code-Schnipsel aufzuspielen, die im @code{origin}-Objekt des Pakets festgelegt wurden (siehe @ref{Pakete definieren}). @item --sources Den Quellcode für @var{Paket-oder-Ableitung} und alle Abhängigkeiten davon rekursiv herunterladen und zurückliefern. Dies ist eine praktische Methode, eine lokale Kopie des gesamten Quellcodes zu beziehen, der nötig ist, um die Pakete zu erstellen, damit Sie diese später auch ohne Netzwerkzugang erstellen lassen können. Es handelt sich um eine Erweiterung der Befehlszeilenoption @code{--source}, die jeden der folgenden Argumentwerte akzeptiert: @table @code @item package Mit diesem Wert verhält sich die Befehlszeilenoption @code{--sources} auf genau die gleiche Weise wie die Befehlszeilenoption @code{--source}. @item all Erstellt die Quellcode-Ableitungen aller Pakete einschließlich allen Quellcodes, der als Teil der Eingaben im @code{inputs}-Feld aufgelistet ist. Dies ist der vorgegebene Wert, wenn sonst keiner angegeben wird. @example $ guix build --sources tzdata Folgende Ableitungen werden erstellt: /gnu/store/@dots{}-tzdata2015b.tar.gz.drv /gnu/store/@dots{}-tzcode2015b.tar.gz.drv @end example @item transitive Die Quellcode-Ableitungen aller Pakete sowie aller transitiven Eingaben der Pakete erstellen. Damit kann z.B.@: Paket-Quellcode vorab heruntergeladen und später offline erstellt werden. @example $ guix build --sources=transitive tzdata Folgende Ableitungen werden erstellt: /gnu/store/@dots{}-tzcode2015b.tar.gz.drv /gnu/store/@dots{}-findutils-4.4.2.tar.xz.drv /gnu/store/@dots{}-grep-2.21.tar.xz.drv /gnu/store/@dots{}-coreutils-8.23.tar.xz.drv /gnu/store/@dots{}-make-4.1.tar.xz.drv /gnu/store/@dots{}-bash-4.3.tar.xz.drv @dots{} @end example @end table @item --system=@var{System} @itemx -s @var{System} Versuchen, für die angegebene Art von @var{System} geeignete Binärdateien zu erstellen — z.B.@: @code{i686-linux} — statt für die Art von System, das die Erstellung durchführt. @quotation Anmerkung Die Befehlszeilenoption @code{--system} dient der @emph{nativen} Kompilierung (nicht zu verwechseln mit Cross-Kompilierung). Siehe @code{--target} unten für Informationen zur Cross-Kompilierung. @end quotation Ein Beispiel sind Linux-basierte Systeme, die verschiedene Persönlichkeiten emulieren können. Zum Beispiel können Sie @code{--system=i686-linux} auf einem @code{x86_64-linux}-System oder @code{--system=armhf-linux} auf einem @code{aarch64-linux}-System angeben, um Pakete in einer vollständigen 32-Bit-Umgebung zu erstellen. @quotation Anmerkung Das Erstellen für ein @code{armhf-linux}-System ist ungeprüft auf allen @code{aarch64-linux}-Maschinen aktiviert, obwohl bestimmte aarch64-Chipsätze diese Funktionalität nicht unterstützen, darunter auch ThunderX. @end quotation Ebenso können Sie, wenn transparente Emulation mit QEMU und @code{binfmt_misc} aktiviert sind (siehe @ref{Virtualisierungsdienste, @code{qemu-binfmt-service-type}}), für jedes System Erstellungen durchführen, für das ein QEMU-@code{binfmt_misc}-Handler installiert ist. Erstellungen für ein anderes System, das nicht dem System der Maschine, die Sie benutzen, entspricht, können auch auf eine entfernte Maschine mit der richtigen Architektur ausgelagert werden. Siehe @ref{Auslagern des Daemons einrichten} für mehr Informationen über das Auslagern. @item --target=@var{Tripel} @cindex Cross-Kompilieren Lässt für das angegebene @var{Tripel} cross-erstellen, dieses muss ein gültiges GNU-Tripel wie z.B.@: @code{"mips64el-linux-gnu"} sein (siehe @ref{Specifying target triplets, GNU configuration triplets,, autoconf, Autoconf}). @anchor{build-check} @item --check @cindex Determinismus, Überprüfung @cindex Reproduzierbarkeit, Überprüfung @var{Paket-oder-Ableitung} erneut erstellen, wenn diese bereits im Store verfügbar ist, und einen Fehler melden, wenn die Erstellungsergebnisse nicht Bit für Bit identisch sind. Mit diesem Mechanismus können Sie überprüfen, ob zuvor installierte Substitute unverfälscht sind (siehe @ref{Substitute}) oder auch ob das Erstellungsergebnis eines Pakets deterministisch ist. Siehe @ref{Aufruf von guix challenge} für mehr Hintergrundinformationen und Werkzeuge. Wenn dies zusammen mit @option{--keep-failed} benutzt wird, bleiben die sich unterscheidenden Ausgaben im Store unter dem Namen @file{/gnu/store/@dots{}-check}. Dadurch können Unterschiede zwischen den beiden Ergebnissen leicht erkannt werden. @item --repair @cindex Reparieren von Store-Objekten @cindex Datenbeschädigung, Behebung Versuchen, die angegebenen Store-Objekte zu reparieren, wenn sie beschädigt sind, indem sie neu heruntergeladen oder neu erstellt werden. Diese Operation ist nicht atomar und nur der Administratornutzer @code{root} kann sie verwenden. @item --derivations @itemx -d Liefert die Ableitungspfade und @emph{nicht} die Ausgabepfade für die angegebenen Pakete. @item --root=@var{Datei} @itemx -r @var{Datei} @cindex GC-Wurzeln, Hinzufügen @cindex Müllsammlerwurzeln, Hinzufügen Die @var{Datei} zu einer symbolischen Verknüpfung auf das Ergebnis machen und als Müllsammlerwurzel registrieren. Dadurch wird das Ergebnis dieses Aufrufs von @command{guix build} vor dem Müllsammler geschützt, bis die @var{Datei} gelöscht wird. Wird diese Befehlszeilenoption @emph{nicht} angegeben, können Erstellungsergebnisse vom Müllsammler geholt werden, sobald die Erstellung abgeschlossen ist. Siehe @ref{Aufruf von guix gc} für mehr Informationen zu Müllsammlerwurzeln. @item --log-file @cindex Erstellungsprotokolle, Zugriff Liefert die Dateinamen oder URLs der Erstellungsprotokolle für das angegebene @var{Paket-oder-Ableitung} oder meldet einen Fehler, falls Protokolldateien fehlen. Dies funktioniert, egal wie die Pakete oder Ableitungen angegeben werden. Zum Beispiel sind folgende Aufrufe alle äquivalent: @example guix build --log-file `guix build -d guile` guix build --log-file `guix build guile` guix build --log-file guile guix build --log-file -e '(@@ (gnu packages guile) guile-2.0)' @end example Wenn ein Protokoll lokal nicht verfügbar ist und sofern @code{--no-substitutes} nicht übergeben wurde, sucht der Befehl nach einem entsprechenden Protokoll auf einem der Substitutserver (die mit @code{--substitute-urls} angegeben werden können). Stellen Sie sich zum Beispiel vor, sie wollten das Erstellungsprotokoll von GDB auf einem MIPS-System sehen, benutzen aber selbst eine @code{x86_64}-Maschine: @example $ guix build --log-file gdb -s mips64el-linux https://@value{SUBSTITUTE-SERVER}/log/@dots{}-gdb-7.10 @end example So haben Sie umsonst Zugriff auf eine riesige Bibliothek von Erstellungsprotokollen! @end table @node Fehlschläge beim Erstellen untersuchen @subsection Fehlschläge beim Erstellen untersuchen @cindex Erstellungsfehler, Fehlersuche Wenn Sie ein neues Paket definieren (siehe @ref{Pakete definieren}), werden Sie sich vermutlich einige Zeit mit der Fehlersuche beschäftigen und die Erstellung so lange anpassen, bis sie funktioniert. Dazu müssen Sie die Erstellungsbefehle selbst in einer Umgebung benutzen, die der, die der Erstellungsdaemon aufbaut, so ähnlich wie möglich ist. Das Erste, was Sie dafür tun müssen, ist die Befehlszeilenoption @option{--keep-failed} oder @option{-K} von @command{guix build} einzusetzen, wodurch Verzeichnisbäume fehlgeschlagener Erstellungen in @file{/tmp} oder dem von Ihnen als @code{TMPDIR} ausgewiesenen Verzeichnis erhalten und nicht gelöscht werden (siehe @ref{Aufruf von guix build, @code{--keep-failed}}). Im Anschluss können Sie mit @command{cd} in die Verzeichnisse dieses fehlgeschlagenen Erstellungsbaums wechseln und mit @command{source} dessen @file{environment-variables}-Datei laden, die alle Umgebungsvariablendefinitionen enthält, die zum Zeitpunkt des Fehlschlags der Erstellung galten. Sagen wir, Sie suchen Fehler in einem Paket @code{foo}, dann würde eine typische Sitzung so aussehen: @example $ guix build foo -K @dots{} @i{build fails} $ cd /tmp/guix-build-foo.drv-0 $ source ./environment-variables $ cd foo-1.2 @end example Nun können Sie Befehle (fast) so aufrufen, als wären Sie der Daemon, und Fehlerursachen in Ihrem Erstellungsprozess ermitteln. Manchmal passiert es, dass zum Beispiel die Tests eines Pakets erfolgreich sind, wenn Sie sie manuell aufrufen, aber scheitern, wenn der Daemon sie ausführt. Das kann passieren, weil der Daemon Erstellungen in isolierten Umgebungen (»Containern«) durchführt, wo, anders als in der obigen Umgebung, kein Netzwerkzugang möglich ist, @file{/bin/sh} nicht exisiert usw.@: (siehe @ref{Einrichten der Erstellungsumgebung}). In solchen Fällen müssen Sie den Erstellungsprozess womöglich aus einer zu der des Daemons ähnlichen isolierten Umgebung heraus ausprobieren: @example $ guix build -K foo @dots{} $ cd /tmp/guix-build-foo.drv-0 $ guix environment --no-grafts -C foo --ad-hoc strace gdb [env]# source ./environment-variables [env]# cd foo-1.2 @end example Hierbei erzeugt @command{guix environment -C} eine isolierte Umgebung und öffnet darin eine Shell (siehe @ref{Aufruf von guix environment}). Der Teil mit @command{--ad-hoc strace gdb} fügt die Befehle @command{strace} und @command{gdb} zur isolierten Umgebung hinzu, die Sie gut gebrauchen könnten, während Sie Fehler suchen. Wegen der Befehlszeilenoption @option{--no-grafts} bekommen Sie haargenau dieselbe Umgebung ohne veredelte Pakete (siehe @ref{Sicherheitsaktualisierungen} für mehr Informationen zu Veredelungen). Um der isolierten Umgebung des Erstellungsdaemons noch näher zu kommen, können wir @file{/bin/sh} entfernen: @example [env]# rm /bin/sh @end example (Keine Sorge, das ist harmlos: All dies passiert nur in der zuvor von @command{guix environment} erzeugten Wegwerf-Umgebung.) Der Befehl @command{strace} befindet sich wahrscheinlich nicht in Ihrem Suchpfad, aber wir können ihn so benutzen: @example [env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check @end example Auf diese Weise haben Sie nicht nur die Umgebungsvariablen, die der Daemon benutzt, nachgebildet, sondern lassen auch den Erstellungsprozess in einer isolierten Umgebung ähnlich der des Daemons laufen. @node Aufruf von guix edit @section @command{guix edit} aufrufen @cindex @command{guix edit} @cindex Paketdefinition, Bearbeiten So viele Pakete, so viele Quelldateien! Der Befehl @command{guix edit} erleichtert das Leben von sowohl Nutzern als auch Paketentwicklern, indem er Ihren Editor anweist, die Quelldatei mit der Definition des jeweiligen Pakets zu bearbeiten. Zum Beispiel startet dies: @example guix edit gcc@@4.9 vim @end example @noindent das mit der Umgebungsvariablen @code{VISUAL} ode @code{EDITOR} angegebene Programm und lässt es das Rezept von GCC@tie{}4.9.3 und von Vim anzeigen. Wenn Sie ein Git-Checkout von Guix benutzen (siehe @ref{Erstellung aus dem Git}) oder Ihre eigenen Pakete im @code{GUIX_PACKAGE_PATH} erstellt haben (siehe @ref{Paketmodule}), werden Sie damit die Paketrezepte auch bearbeiten können. Andernfalls werden Sie zumindest in die Lage versetzt, die nur lesbaren Rezepte für sich im Moment im Store befindliche Pakete zu untersuchen. @node Aufruf von guix download @section @command{guix download} aufrufen @cindex @command{guix download} @cindex Paketquellcode herunterladen Wenn Entwickler einer Paketdefinition selbige schreiben, müssen diese normalerweise einen Quellcode-Tarball herunterladen, seinen SHA256-Hash als Prüfsumme berechnen und diese in der Paketdefinition eintragen (siehe @ref{Pakete definieren}). Das Werkzeug @command{guix download} hilft bei dieser Aufgabe: Damit wird eine Datei von der angegebenen URI heruntergeladen, in den Store eingelagert und sowohl ihr Dateiname im Store als auch ihr SHA256-Hash als Prüfsumme angezeigt. Dadurch, dass die heruntergeladene Datei in den Store eingefügt wird, wird Bandbreite gespart: Wenn der Entwickler schließlich versucht, das neu definierte Paket mit @command{guix build} zu erstellen, muss der Quell-Tarball nicht erneut heruntergeladen werden, weil er sich bereits im Store befindet. Es ist auch eine bequeme Methode, Dateien temporär aufzubewahren, die letztlich irgendwann gelöscht werden (siehe @ref{Aufruf von guix gc}). Der Befehl @command{guix download} unterstützt dieselben URIs, die in Paketdefinitionen verwendet werden. Insbesondere unterstützt er @code{mirror://}-URIs. @code{https}-URIs (HTTP über TLS) werden unterstützt, @emph{vorausgesetzt} die Guile-Anbindungen für GnuTLS sind in der Umgebung des Benutzers verfügbar; wenn nicht, wird ein Fehler gemeldet. Siehe @ref{Guile Preparations, how to install the GnuTLS bindings for Guile,, gnutls-guile, GnuTLS-Guile}, hat mehr Informationen. Mit @command{guix download} werden HTTPS-Serverzertifikate verifiziert, indem die Zertifikate der X.509-Autoritäten in das durch die Umgebungsvariable @code{SSL_CERT_DIR} bezeichnete Verzeichnis heruntergeladen werden (siehe @ref{X.509-Zertifikate}), außer @option{--no-check-certificate} wird benutzt. Folgende Befehlszeilenoptionen stehen zur Verfügung: @table @code @item --format=@var{Format} @itemx -f @var{Format} Die Hash-Prüfsumme im angegebenen @var{Format} ausgeben. Für weitere Informationen, was gültige Werte für das @var{Format} sind, siehe @ref{Aufruf von guix hash}. @item --no-check-certificate X.509-Zertifikate von HTTPS-Servern @emph{nicht} validieren. Wenn Sie diese Befehlszeilenoption benutzen, haben Sie @emph{keinerlei Garantie}, dass Sie tatsächlich mit dem authentischen Server, der für die angegebene URL verantwortlich ist, kommunizieren. Das macht Sie anfällig gegen sogenannte »Man-in-the-Middle«-Angriffe. @item --output=@var{Datei} @itemx -o @var{Datei} Die heruntergeladene Datei @emph{nicht} in den Store, sondern in die angegebene @var{Datei} abspeichern. @end table @node Aufruf von guix hash @section @command{guix hash} aufrufen @cindex @command{guix hash} Der Befehl @command{guix hash} berechnet den SHA256-Hash einer Datei. Er ist primär ein Werkzeug, dass es bequemer macht, etwas zur Distribution beizusteuern: Damit wird die kryptografische Hash-Prüfsumme berechnet, die bei der Definition eines Pakets benutzt werden kann (siehe @ref{Pakete definieren}). Die allgemeine Syntax lautet: @example guix hash @var{Option} @var{Datei} @end example Wird als @var{Datei} ein Bindestrich @code{-} angegeben, berechnet @command{guix hash} den Hash der von der Standardeingabe gelesenen Daten. @command{guix hash} unterstützt die folgenden Optionen: @table @code @item --format=@var{Format} @itemx -f @var{Format} Gibt die Prüfsumme im angegebenen @var{Format} aus. Unterstützte Formate: @code{nix-base32}, @code{base32}, @code{base16} (@code{hex} und @code{hexadecimal} können auch benutzt werden). Wird keine Befehlszeilenoption @option{--format} angegeben, wird @command{guix hash} die Prüfsumme im @code{nix-base32}-Format ausgeben. Diese Darstellung wird bei der Definition von Paketen benutzt. @item --recursive @itemx -r Die Prüfsumme der @var{Datei} rekursiv berechnen. @c FIXME: Replace xref above with xref to an ``Archive'' section when @c it exists. In diesem Fall wird die Prüfsumme eines Archivs berechnet, das die @var{Datei} enthält, und auch ihre Kinder, wenn es sich um ein Verzeichnis handelt. Einige der Metadaten der @var{Datei} sind Teil dieses Archivs. Zum Beispiel unterscheidet sich die berechnete Prüfsumme, wenn die @var{Datei} eine reguläre Datei ist, je nachdem, ob die @var{Datei} ausführbar ist oder nicht. Metadaten wie der Zeitstempel haben keinen Einfluss auf die Prüfsumme (siehe @ref{Aufruf von guix archive}). @item --exclude-vcs @itemx -x Wenn dies zusammen mit der Befehlszeilenoption @option{--recursive} angegeben wird, werden Verzeichnisse zur Versionskontrolle (@file{.bzr}, @file{.git}, @file{.hg}, etc.)@: vom Archiv ausgenommen. @vindex git-fetch Zum Beispiel würden Sie auf diese Art die Prüfsumme eines Git-Checkouts berechnen, was nützlich ist, wenn Sie die Prüfsumme für die Methode @code{git-fetch} benutzen (siehe @ref{»origin«-Referenz}): @example $ git clone http://example.org/foo.git $ cd foo $ guix hash -rx . @end example @end table @node Aufruf von guix import @section @command{guix import} aufrufen @cindex Pakete importieren @cindex Paketimport @cindex Pakete an Guix anpassen @cindex @command{guix import} aufrufen Der Befehl @command{guix import} ist für Leute hilfreich, die ein Paket gerne mit so wenig Arbeit wie möglich zur Distribution hinzufügen würden — ein legitimer Anspruch. Der Befehl kennt ein paar Sammlungen, aus denen mit ihm Paketmetadaten »importiert« werden können. Das Ergebnis ist eine Paketdefinition oder eine Vorlage dafür in dem uns bekannten Format (siehe @ref{Pakete definieren}). Die allgemeine Syntax lautet: @example guix import @var{Importer} @var{Optionen}@dots{} @end example Der @var{Importer} gibt die Quelle an, aus der Paketmetadaten importiert werden, und die @var{Optionen} geben eine Paketbezeichnung und andere vom @var{Importer} abhängige Daten an. Derzeit sind folgende »Importer« verfügbar: @table @code @item gnu Metadaten für das angegebene GNU-Paket importieren. Damit wird eine Vorlage für die neueste Version dieses GNU-Pakets zur Verfügung gestellt, einschließlich der Prüfsumme seines Quellcode-Tarballs, seiner kanonischen Zusammenfassung und seiner Beschreibung. Zusätzliche Informationen wie Paketabhängigkeiten und seine Lizenz müssen noch manuell ermittelt werden. Zum Beispiel liefert der folgende Befehl eine Paketdefinition für GNU@tie{}Hello: @example guix import gnu hello @end example Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung: @table @code @item --key-download=@var{Richtlinie} Die Richtlinie zum Umgang mit fehlenden OpenPGP-Schlüsseln beim Verifizieren der Paketsignatur (auch »Beglaubigung« genannt) festlegen, wie bei @code{guix refresh}. Siehe @ref{Aufruf von guix refresh, @code{--key-download}}. @end table @item pypi @cindex pypi Metadaten aus dem @uref{https://pypi.python.org/, Python Package Index} importieren. Informationen stammen aus der JSON-formatierten Beschreibung, die unter @code{pypi.python.org} verfügbar ist, und enthalten meistens alle relevanten Informationen einschließlich der Abhängigkeiten des Pakets. Für maximale Effizienz wird empfohlen, das Hilfsprogramm @command{unzip} zu installieren, damit der Importer »Python Wheels« entpacken und daraus Daten beziehen kann. Der folgende Befehl importiert Metadaten für das Python-Paket namens @code{itsdangerous}: @example guix import pypi itsdangerous @end example @table @code @item --recursive @itemx -r Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt. @end table @item gem @cindex gem Metadaten von @uref{https://rubygems.org/, RubyGems} importieren. Informationen kommen aus der JSON-formatierten Beschreibung, die auf @code{rubygems.org} verfügbar ist, und enthält die relevantesten Informationen einschließlich der Laufzeitabhängigkeiten. Dies hat aber auch Schattenseiten — die Metadaten unterscheiden nicht zwischen Zusammenfassungen und Beschreibungen, daher wird dieselbe Zeichenkette für beides eingesetzt. Zudem fehlen Informationen zu nicht in Ruby geschriebenen Abhängigkeiten, die benötigt werden, um native Erweiterungen zu in Ruby geschriebenem Code zu erstellen. Diese herauszufinden bleibt dem Paketentwickler überlassen. Der folgende Befehl importiert Metadaten aus dem Ruby-Paket @code{rails}. @example guix import gem rails @end example @table @code @item --recursive @itemx -r Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt. @end table @item cpan @cindex CPAN Importiert Metadaten von @uref{https://www.metacpan.org/, MetaCPAN}. Informationen werden aus den JSON-formatierten Metadaten genommen, die über die @uref{https://fastapi.metacpan.org/, Programmierschnittstelle (»API«) von MetaCPAN} angeboten werden, und enthalten die relevantesten Informationen wie zum Beispiel Modulabhängigkeiten. Lizenzinformationen sollten genau nachgeprüft werden. Wenn Perl im Store verfügbar ist, wird das Werkzeug @code{corelist} benutzt, um Kernmodule in der Abhängigkeitsliste wegzulassen. Folgender Befehl importiert Metadaten für das Perl-Modul @code{Acme::Boolean}: @example guix import cpan Acme::Boolean @end example @item cran @cindex CRAN @cindex Bioconductor Metadaten aus dem @uref{https://cran.r-project.org/, CRAN} importieren, der zentralen Sammlung für die @uref{http://r-project.org, statistische und grafische Umgebung GNU@tie{}R}. Informationen werden aus der Datei namens @code{DESCRIPTION} des Pakets extrahiert. Der folgende Befehl importiert Metadaten für das @code{Cairo}-R-Paket: @example guix import cran Cairo @end example Wird zudem @code{--recursive} angegeben, wird der Importer den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für all die Pakete erzeugen, die noch nicht Teil von Guix sind. Wird @code{--archive=bioconductor} angegeben, werden Metadaten vom @uref{https://www.bioconductor.org/, Bioconductor} importiert, einer Sammlung von R-Paketen zur Analyse und zum Verständnis von großen Mengen genetischer Daten in der Bioinformatik. Informationen werden aus der @code{DESCRIPTION}-Datei im Paket extrahiert, das auf der Weboberfläche des Bioconductor-SVN-Repositorys veröffentlicht wurde. Der folgende Befehl importiert Metadaten für das R-Paket @code{GenomicRanges}: @example guix import cran --archive=bioconductor GenomicRanges @end example @item texlive @cindex TeX Live @cindex CTAN Metadaten aus @uref{http://www.ctan.org/, CTAN}, dem umfassenden TeX-Archivnetzwerk, herunterladen, was für TeX-Pakete benutzt wird, die Teil der @uref{https://www.tug.org/texlive/, TeX-Live-Distribution} sind. Informationen über das Paket werden über die von CTAN angebotene XML-Programmierschnittstelle bezogen, wohingegen der Quellcode aus dem SVN-Repository des TeX-Live-Projekts heruntergeladen wird. Das wird so gemacht, weil CTAN keine versionierten Archive vorhält. Der folgende Befehl importiert Metadaten für das TeX-Paket @code{fontspec}: @example guix import texlive fontspec @end example Wenn @code{--archive=VERZEICHNIS} angegeben wird, wird der Quellcode @emph{nicht} aus dem Unterverzeichnis @file{latex} des @file{texmf-dist/source}-Baums im SVN-Repository von TeX Live heruntergeladen, sondern aus dem angegebenen Schwesterverzeichnis im selben Wurzelverzeichnis. Der folgende Befehl importiert Metadaten für das Paket @code{ifxetex} aus CTAN und lädt die Quelldateien aus dem Verzeichnis @file{texmf/source/generic}: @example guix import texlive --archive=generic ifxetex @end example @item json @cindex JSON, Import Paketmetadaten aus einer lokalen JSON-Datei importieren. Betrachten Sie folgende Beispiel-Paketdefinition im JSON-Format: @example @{ "name": "hello", "version": "2.10", "source": "mirror://gnu/hello/hello-2.10.tar.gz", "build-system": "gnu", "home-page": "https://www.gnu.org/software/hello/", "synopsis": "Hello, GNU world: An example GNU package", "description": "GNU Hello prints a greeting.", "license": "GPL-3.0+", "native-inputs": ["gcc@@6"] @} @end example Die Felder sind genauso benannt wie bei einem @code{}-Verbundstyp (siehe @ref{Pakete definieren}). Referenzen zu anderen Paketen stehen darin als JSON-Liste von mit Anführungszeichen quotierten Zeichenketten wie @code{guile} oder @code{guile@@2.0}. Der Importer unterstützt auch eine ausdrücklichere Definition der Quelldateien mit den üblichen Feldern eines @code{}-Verbunds: @example @{ @dots{} "source": @{ "method": "url-fetch", "uri": "mirror://gnu/hello/hello-2.10.tar.gz", "sha256": @{ "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i" @} @} @dots{} @} @end example Der folgende Befehl liest Metadaten aus der JSON-Datei @code{hello.json} und gibt einen Paketausdruck aus: @example guix import json hello.json @end example @item nix Metadaten aus einer lokalen Kopie des Quellcodes der @uref{http://nixos.org/nixpkgs/, Nixpkgs-Distribution} importieren@footnote{Dazu wird der Befehl @command{nix-instantiate} von @uref{http://nixos.org/nix/, Nix} verwendet.}. Paketdefinitionen in Nixpkgs werden typischerweise in einer Mischung aus der Sprache von Nix und aus Bash-Code geschrieben. Dieser Befehl wird nur die abstrakte Paketstruktur, die in der Nix-Sprache geschrieben ist, importieren. Dazu gehören normalerweise alle grundlegenden Felder einer Paketdefinition. Beim Importieren eines GNU-Pakets werden Zusammenfassung und Beschreibung stattdessen durch deren kanonische Variante bei GNU ersetzt. Normalerweise würden Sie zunächst dies ausführen: @example export NIX_REMOTE=daemon @end example @noindent damit @command{nix-instantiate} nicht versucht, die Nix-Datenbank zu öffnen. Zum Beispiel importiert der Befehl unten die Paketdefinition von LibreOffice (genauer gesagt importiert er die Definition des an das Attribut @code{libreoffice} auf oberster Ebene gebundenen Pakets): @example guix import nix ~/path/to/nixpkgs libreoffice @end example @item hackage @cindex hackage Metadaten aus @uref{https://hackage.haskell.org/, Hackage}, dem zentralen Paketarchiv der Haskell-Gemeinde, importieren. Informationen werden aus Cabal-Dateien ausgelesen. Darin sind alle relevanten Informationen einschließlich der Paketabhängigkeiten enthalten. Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung: @table @code @item --stdin @itemx -s Eine Cabal-Datei von der Standardeingabe lesen. @item --no-test-dependencies @itemx -t Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden. @item --cabal-environment=@var{Aliste} @itemx -e @var{Aliste} @var{Aliste} muss eine assoziative Liste der Scheme-Programmiersprache sein, die die Umgebung definiert, in der bedingte Ausdrücke von Cabal ausgewertet werden. Dabei werden folgende Schlüssel akzeptiert: @code{os}, @code{arch}, @code{impl} und eine Zeichenkette, die dem Namen einer Option (einer »Flag«) entspricht. Der mit einer »Flag« assoziierte Wert muss entweder das Symbol @code{true} oder @code{false} sein. Der anderen Schlüsseln zugeordnete Wert muss mit der Definition des Cabal-Dateiformats konform sein. Der vorgegebene Wert zu den Schlüsseln @code{os}, @code{arch} and @code{impl} ist jeweils @samp{linux}, @samp{x86_64} bzw. @samp{ghc}. @item --recursive @itemx -r Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt. @end table Der folgende Befehl importiert Metadaten für die neuste Version des Haskell-@code{HTTP}-Pakets, ohne Testabhängigkeiten zu übernehmen und bei Übergabe von @code{false} als Wert der Flag @samp{network-uri}: @example guix import hackage -t -e "'((\"network-uri\" . false))" HTTP @end example Eine ganz bestimmte Paketversion kann optional ausgewählt werden, indem man nach dem Paketnamen anschließend ein At-Zeichen und eine Versionsnummer angibt wie in folgendem Beispiel: @example guix import hackage mtl@@2.1.3.1 @end example @item stackage @cindex stackage Der @code{stackage}-Importer ist ein Wrapper um den @code{hackage}-Importer. Er nimmt einen Paketnamen und schaut dafür die Paketversion nach, die Teil einer @uref{https://www.stackage.org, Stackage}-Veröffentlichung mit Langzeitunterstützung (englisch »Long-Term Support«, kurz LTS) ist, deren Metadaten er dann mit dem @code{hackage}-Importer bezieht. Beachten Sie, dass es Ihre Aufgabe ist, eine LTS-Veröffentlichung auszuwählen, die mit dem von Guix benutzten GHC-Compiler kompatibel ist. Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung: @table @code @item --no-test-dependencies @itemx -t Keine Abhängigkeiten übernehmen, die nur von Testkatalogen benötigt werden. @item --lts-version=@var{Version} @itemx -l @var{Version} @var{Version} ist die gewünschte Version der LTS-Veröffentlichung. Wird keine angegeben, wird die neueste benutzt. @item --recursive @itemx -r Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt. @end table Der folgende Befehl importiert Metadaten für dasjenige @code{HTTP}-Haskell-Paket, das in der LTS-Stackage-Veröffentlichung mit Version 7.18 vorkommt: @example guix import stackage --lts-version=7.18 HTTP @end example @item elpa @cindex elpa Metadaten aus der Paketsammlung »Emacs Lisp Package Archive« (ELPA) importieren (siehe @ref{Packages,,, emacs, The GNU Emacs Manual}). Speziell für diesen Importer stehen noch folgende Befehlszeilenoptionen zur Verfügung: @table @code @item --archive=@var{Repo} @itemx -a @var{Repo} Mit @var{Repo} wird die Archiv-Sammlung (ein »Repository«) bezeichnet, von dem die Informationen bezogen werden sollen. Derzeit sind die unterstützten Repositorys und ihre Bezeichnungen folgende: @itemize - @item @uref{http://elpa.gnu.org/packages, GNU}, bezeichnet mit @code{gnu}. Dies ist die Vorgabe. Pakete aus @code{elpa.gnu.org} wurden mit einem der Schlüssel im GnuPG-Schlüsselbund in @file{share/emacs/25.1/etc/package-keyring.gpg} (oder einem ähnlichen Pfad) des @code{emacs}-Pakets signiert (siehe @ref{Package Installation, ELPA package signatures,, emacs, The GNU Emacs Manual}). @item @uref{http://stable.melpa.org/packages, MELPA-Stable}, bezeichnet mit @code{melpa-stable}. @item @uref{http://melpa.org/packages, MELPA}, bezeichnet mit @code{melpa}. @end itemize @item --recursive @itemx -r Den Abhängigkeitsgraphen des angegebenen Pakets beim Anbieter rekursiv durchlaufen und Paketausdrücke für alle solchen Pakete erzeugen, die es in Guix noch nicht gibt. @end table @item crate @cindex crate Metadaten aus der Paketsammlung crates.io für Rust importieren @uref{https://crates.io, crates.io}. @item opam @cindex OPAM @cindex OCaml Metadaten aus der Paketsammlung @uref{https://opam.ocaml.org/, OPAM} der OCaml-Gemeinde importieren. @end table @command{guix import} verfügt über eine modulare Code-Struktur. Mehr Importer für andere Paketformate zu haben, wäre nützlich, und Ihre Hilfe ist hierbei gerne gesehen (siehe @ref{Mitwirken}). @node Aufruf von guix refresh @section @command{guix refresh} aufrufen @cindex @command{guix refresh} Die Zielgruppe des Befehls @command{guix refresh} zum Auffrischen von Paketen sind in erster Linie Entwickler der GNU-Software-Distribution. Nach Vorgabe werden damit alle Pakete in der Distribution gemeldet, die nicht der neuesten Version des Anbieters entsprechen, indem Sie dies ausführen: @example $ guix refresh gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1 gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0 @end example Alternativ können die zu betrachtenden Pakete dabei angegeben werden, was zur Ausgabe einer Warnung führt, wenn es für Pakete kein Aktualisierungsprogramm gibt: @example $ guix refresh coreutils guile guile-ssh gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13 @end example @command{guix refresh} durchsucht die Paketsammlung beim Anbieter jedes Pakets und bestimmt, was die höchste Versionsnummer ist, zu der es dort eine Veröffentlichung gibt. Zum Befehl gehören Aktualisierungsprogramme, mit denen bestimmte Typen von Paketen automatisch aktualisiert werden können: GNU-Pakete, ELPA-Pakete usw.@: — siehe die Dokumentation von @option{--type} unten. Es gibt jedoch auch viele Pakete, für die noch keine Methode enthalten ist, um das Vorhandensein einer neuen Veröffentlichung zu prüfen. Der Mechanismus ist aber erweiterbar, also können Sie gerne mit uns in Kontakt treten, wenn Sie eine neue Methode hinzufügen möchten! @table @code @item --recursive Consider the packages specified, and all the packages upon which they depend. @example $ guix refresh --recursive coreutils gnu/packages/acl.scm:35:2: warning: no updater for acl gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4 gnu/packages/xml.scm:68:2: warning: no updater for expat gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp @dots{} @end example @end table Manchmal unterscheidet sich der vom Anbieter benutzte Name von dem Paketnamen, der in Guix verwendet wird, so dass @command{guix refresh} etwas Unterstützung braucht. Die meisten Aktualisierungsprogramme folgen der Eigenschaft @code{upstream-name} in Paketdefinitionen, die diese Unterstützung bieten kann. @example (define-public network-manager (package (name "network-manager") ;; @dots{} (properties '((upstream-name . "NetworkManager"))))) @end example Wenn @code{--update} übergeben wird, werden die Quelldateien der Distribution verändert, so dass für diese Paketrezepte die aktuelle Version und die aktuelle Hash-Prüfsumme des Quellcode-Tarballs eingetragen wird (siehe @ref{Pakete definieren}). Dazu werden der neueste Quellcode-Tarball jedes Pakets sowie die jeweils zugehörige OpenPGP-Signatur heruntergeladen; mit Letzterer wird der heruntergeladene Tarball gegen seine Signatur mit @command{gpg} authentifiziert und schließlich dessen Hash berechnet. Wenn der öffentliche Schlüssel, mit dem der Tarball signiert wurde, im Schlüsselbund des Benutzers fehlt, wird versucht, ihn automatisch von einem Schlüssel-Server zu holen; wenn das klappt, wird der Schlüssel zum Schlüsselbund des Benutzers hinzugefügt, ansonsten meldet @command{guix refresh} einen Fehler. Die folgenden Befehlszeilenoptionen werden unterstützt: @table @code @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird. Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in diesem Beispiel: @example guix refresh -l -e '(@@@@ (gnu packages commencement) glibc-final)' @end example Dieser Befehls listet auf, was alles von der »endgültigen« Erstellung von libc abhängt (praktisch alle Pakete). @item --update @itemx -u Die Quelldateien der Distribution (die Paketrezepte) werden direkt »in place« verändert. Normalerweise führen Sie dies aus einem Checkout des Guix-Quellbaums heraus aus (siehe @ref{Guix vor der Installation ausführen}): @example $ ./pre-inst-env guix refresh -s non-core -u @end example Siehe @ref{Pakete definieren} für mehr Informationen zu Paketdefinitionen. @item --select=[@var{Teilmenge}] @itemx -s @var{Teilmenge} Wählt alle Pakete aus der @var{Teilmenge} aus, die entweder @code{core} oder @code{non-core} sein muss. Die @code{core}-Teilmenge bezieht sich auf alle Pakete, die den Kern der Distribution ausmachen, d.h.@: Pakete, aus denen heraus »alles andere« erstellt wird. Dazu gehören GCC, libc, Binutils, Bash und so weiter. In der Regel ist die Folge einer Änderung an einem dieser Pakete in der Distribution, dass alle anderen neu erstellt werden müssen. Daher sind solche Änderungen unangenehm für Nutzer, weil sie einiges an Erstellungszeit oder Bandbreite investieren müssen, um die Aktualisierung abzuschließen. Die @code{non-core}-Teilmenge bezieht sich auf die übrigen Pakete. Sie wird typischerweise dann benutzt, wenn eine Aktualisierung der Kernpakete zu viele Umstände machen würde. @item --manifest=@var{Datei} @itemx -m @var{Datei} Wählt alle Pakete im in der @var{Datei} stehenden Manifest aus. Das ist nützlich, um zu überprüfen, welche Pakete aus dem Manifest des Nutzers aktualisiert werden können. @item --type=@var{Aktualisierungsprogramm} @itemx -t @var{Aktualisierungsprogramm} Nur solche Pakete auswählen, die vom angegebenen @var{Aktualisierungsprogramm} behandelt werden. Es darf auch eine kommagetrennte Liste mehrerer Aktualisierungsprogramme angegeben werden. Zur Zeit kann als @var{Aktualisierungsprogramm} eines der folgenden angegeben werden: @table @code @item gnu Aktualisierungsprogramm für GNU-Pakete, @item gnome Aktualisierungsprogramm für GNOME-Pakete, @item kde Aktualisierungsprogramm für KDE-Pakete, @item xorg Aktualisierungsprogramm für X.org-Pakete, @item kernel.org Aktualisierungsprogramm auf kernel.org angebotener Pakete, @item elpa Aktualisierungsprogramm für @uref{http://elpa.gnu.org/, ELPA-Pakete}, @item cran Aktualisierungsprogramm für @uref{https://cran.r-project.org/, CRAN-Pakete}, @item bioconductor Aktualisierungsprogramm für R-Pakete vom @uref{https://www.bioconductor.org/, Bioconductor}, @item cpan Aktualisierungsprogramm für @uref{http://www.cpan.org/, CPAN-Pakete}, @item pypi Aktualisierungsprogramm für @uref{https://pypi.python.org, PyPI-Pakete}, @item gem Aktualisierungsprogramm für @uref{https://rubygems.org, RubyGems-Pakete}. @item github Aktualisierungsprogramm für @uref{https://github.com, GitHub-Pakete}. @item hackage Aktualisierungsprogramm für @uref{https://hackage.haskell.org, Hackage-Pakete}. @item stackage Aktualisierungsprogramm für @uref{https://www.stackage.org, Stackage-Pakete}. @item crate Aktualisierungsprogramm für @uref{https://crates.io, Crates-Pakete}. @item launchpad Aktualisierungsprogramm für @uref{https://launchpad.net, Launchpad}. @end table Zum Beispiel prüft folgender Befehl nur auf mögliche Aktualisierungen von auf @code{elpa.gnu.org} angebotenen Emacs-Paketen und von CRAN-Paketen: @example $ guix refresh --type=elpa,cran gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0 gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9 @end example @end table An @command{guix refresh} können auch ein oder mehrere Paketnamen übergeben werden wie in diesem Beispiel: @example $ ./pre-inst-env guix refresh -u emacs idutils gcc@@4.8 @end example @noindent Der Befehl oben aktualisiert speziell das @code{emacs}- und das @code{idutils}-Paket. Eine Befehlszeilenoption @code{--select} hätte dann keine Wirkung. Wenn Sie sich fragen, ob ein Paket aktualisiert werden sollte oder nicht, kann es helfen, sich anzuschauen, welche Pakete von der Aktualisierung betroffen wären und auf Kompatibilität hin geprüft werden sollten. Dazu kann die folgende Befehlszeilenoption zusammen mit einem oder mehreren Paketnamen an @command{guix refresh} übergeben werden: @table @code @item --list-updaters @itemx -L Eine Liste verfügbarer Aktualisierungsprogramme anzeigen und terminieren (siehe @option{--type} oben). Für jedes Aktualisierungsprogramm den Anteil der davon betroffenen Pakete anzeigen; zum Schluss wird der Gesamtanteil von irgendeinem Aktualisierungsprogramm betroffener Pakete angezeigt. @item --list-dependent @itemx -l Auflisten, welche abhängigen Pakete auf oberster Ebene neu erstellt werden müssten, wenn eines oder mehrere Pakete aktualisiert würden. Siehe @ref{Aufruf von guix graph, den @code{reverse-package}-Typ von @command{guix graph}} für Informationen dazu, wie Sie die Liste der Abhängigen eines Pakets visualisieren können. @end table Bedenken Sie, dass die Befehlszeilenoption @code{--list-dependent} das Ausmaß der nach einer Aktualisierungen benötigten Neuerstellungen nur @emph{annähert}. Es könnten auch unter Umständen mehr Neuerstellungen anfallen. @example $ guix refresh --list-dependent flex Building the following 120 packages would ensure 213 dependent packages are rebuilt: hop@@2.4.0 geiser@@0.4 notmuch@@0.18 mu@@0.9.9.5 cflow@@1.4 idutils@@4.6 @dots{} @end example Der oben stehende Befehl gibt einen Satz von Paketen aus, die Sie erstellen wollen könnten, um die Kompatibilität einer Aktualisierung des @code{flex}-Pakets beurteilen zu können. @table @code @item --list-transitive Die Pakete auflisten, von denen eines oder mehrere Pakete abhängen. @example $ guix refresh --list-transitive flex flex@@2.6.4 depends on the following 25 packages: perl@@5.28.0 help2man@@1.47.6 bison@@3.0.5 indent@@2.2.10 tar@@1.30 gzip@@1.9 bzip2@@1.0.6 xz@@5.2.4 file@@5.33 @dots{} @end example @end table Der oben stehende Befehl gibt einen Satz von Paketen aus, die, wenn sie geändert würden, eine Neuerstellung des @code{flex}-Pakets auslösen würden. Mit den folgenden Befehlszeilenoptionen können Sie das Verhalten von GnuPG anpassen: @table @code @item --gpg=@var{Befehl} Den @var{Befehl} als GnuPG-2.x-Befehl einsetzen. Der @var{Befehl} wird im @code{$PATH} gesucht. @item --keyring=@var{Datei} Die @var{Datei} als Schlüsselbund mit Anbieterschlüsseln verwenden. Die @var{Datei} muss im @dfn{Keybox-Format} vorliegen. Keybox-Dateien haben normalerweise einen Namen, der auf @file{.kbx} endet. Sie können mit Hilfe von GNU@tie{}Privacy Guard (GPG) bearbeitet werden (siehe @ref{kbxutil, @command{kbxutil},, gnupg, Using the GNU Privacy Guard} für Informationen über ein Werkzeug zum Bearbeiten von Keybox-Dateien). Wenn diese Befehlszeilenoption nicht angegeben wird, benutzt @command{guix refresh} die Keybox-Datei @file{~/.config/guix/upstream/trustedkeys.kbx} als Schlüsselbund für Signierschlüssel von Anbietern. OpenPGP-Signaturen werden mit Schlüsseln aus diesem Schlüsselbund überprüft; fehlende Schlüssel werden auch in diesen Schlüsselbund heruntergeladen (siehe @option{--key-download} unten). Sie können Schlüssel aus Ihrem normalerweise benutzten GPG-Schlüsselbund in eine Keybox-Datei exportieren, indem Sie Befehle wie diesen benutzen: @example gpg --export rms@@gnu.org | kbxutil --import-openpgp >> mykeyring.kbx @end example Ebenso können Sie wie folgt Schlüssel in eine bestimmte Keybox-Datei herunterladen: @example gpg --no-default-keyring --keyring mykeyring.kbx \ --recv-keys @value{OPENPGP-SIGNING-KEY-ID} @end example Siehe @ref{GPG Configuration Options, @option{--keyring},, gnupg, Using the GNU Privacy Guard} für mehr Informationen zur Befehlszeilenoption @option{--keyring} von GPG. @item --key-download=@var{Richtlinie} Fehlende OpenPGP-Schlüssel gemäß dieser @var{Richtlinie} behandeln, für die eine der Folgenden angegeben werden kann: @table @code @item always Immer fehlende OpenPGP-Schlüssel herunterladen und zum GnuPG-Schlüsselbund des Nutzers hinzufügen. @item never Niemals fehlende OpenPGP-Schlüssel herunterladen, sondern einfach abbrechen. @item interactive Ist ein Paket mit einem unbekannten OpenPGP-Schlüssel signiert, wird der Nutzer gefragt, ob der Schlüssel heruntergeladen werden soll oder nicht. Dies entspricht dem vorgegebenen Verhalten. @end table @item --key-server=@var{Host} Den mit @var{Host} bezeichneten Rechner als Schlüsselserver für OpenPGP benutzen, wenn ein öffentlicher Schlüssel importiert wird. @end table Das @code{github}-Aktualisierungsprogramm benutzt die @uref{https://developer.github.com/v3/, GitHub-Programmierschnittstelle} (die »Github-API«), um Informationen über neue Veröffentlichungen einzuholen. Geschieht dies oft, z.B.@: beim Auffrischen aller Pakete, so wird GitHub irgendwann aufhören, weitere API-Anfragen zu beantworten. Normalerweise sind 60 API-Anfragen pro Stunde erlaubt, für eine vollständige Auffrischung aller GitHub-Pakete in Guix werden aber mehr benötigt. Wenn Sie sich bei GitHub mit Ihrem eigenen API-Token authentisieren, gelten weniger einschränkende Grenzwerte. Um einen API-Token zu benutzen, setzen Sie die Umgebungsvariable @code{GUIX_GITHUB_TOKEN} auf einen von @uref{https://github.com/settings/tokens} oder anderweitig bezogenen API-Token. @node Aufruf von guix lint @section @command{guix lint} aufrufen @cindex @command{guix lint} @cindex Pakete, auf Fehler prüfen Den Befehl @command{guix lint} gibt es, um Paketentwicklern beim Vermeiden häufiger Fehler und bei der Einhaltung eines konsistenten Code-Stils zu helfen. Er führt eine Reihe von Prüfungen auf einer angegebenen Menge von Paketen durch, um in deren Definition häufige Fehler aufzuspüren. Zu den verfügbaren @dfn{Prüfern} gehören (siehe @code{--list-checkers} für eine vollständige Liste): @table @code @item synopsis @itemx description Überprüfen, ob bestimmte typografische und stilistische Regeln in Paketbeschreibungen und -zusammenfassungen eingehalten wurden. @item inputs-should-be-native Eingaben identifizieren, die wahrscheinlich native Eingaben sein sollten. @item source @itemx home-page @itemx mirror-url @itemx github-url @itemx source-file-name Die URLs für die Felder @code{home-page} und @code{source} anrufen und nicht erreichbare URLs melden. Wenn passend, wird eine @code{mirror://}-URL vorgeschlagen. Wenn die Quell-URL auf eine GitHub-URL weiterleitet, wird eine Empfehlung ausgegeben, direkt letztere zu verwenden. Es wird geprüft, dass der Quell-Dateiname aussagekräftig ist, dass er also z.B.@: nicht nur aus einer Versionsnummer besteht oder als »git-checkout« angegeben wurde, ohne dass ein @code{Dateiname} deklariert wurde (siehe @ref{»origin«-Referenz}). @item source-unstable-tarball Parse the @code{source} URL to determine if a tarball from GitHub is autogenerated or if it is a release tarball. Unfortunately GitHub's autogenerated tarballs are sometimes regenerated. @item cve @cindex Sicherheitslücken @cindex CVE, Common Vulnerabilities and Exposures Bekannte Sicherheitslücken melden, die in den Datenbanken der »Common Vulnerabilities and Exposures« (CVE) aus diesem und dem letzten Jahr vorkommen, @uref{https://nvd.nist.gov/download.cfm#CVE_FEED, wie sie von der US-amerikanischen NIST veröffentlicht werden}. Um Informationen über eine bestimmte Sicherheitslücke angezeigt zu bekommen, besuchen Sie Webseiten wie: @itemize @item @indicateurl{https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD} @item @indicateurl{https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD} @end itemize @noindent wobei Sie statt @code{CVE-YYYY-ABCD} die CVE-Kennnummer angeben — z.B.@: @code{CVE-2015-7554}. Paketentwickler können in ihren Paketrezepten den Namen und die Version des Pakets in der @uref{https://nvd.nist.gov/cpe.cfm,Common Platform Enumeration (CPE)} angeben, falls sich diese von dem in Guix benutzten Namen und der Version unterscheiden, zum Beispiel so: @example (package (name "grub") ;; @dots{} ;; CPE bezeichnet das Paket als "grub2". (properties '((cpe-name . "grub2") (cpe-version . "2.3"))) @end example @c See . Manche Einträge in der CVE-Datenbank geben die Version des Pakets nicht an, auf das sie sich beziehen, und würden daher bis in alle Ewigkeit Warnungen auslösen. Paketentwickler, die CVE-Warnmeldungen gefunden und geprüft haben, dass diese ignoriert werden können, können sie wie in diesem Beispiel deklarieren: @example (package (name "t1lib") ;; @dots{} ;; Diese CVEs treffen nicht mehr zu und können bedenkenlos ignoriert ;; werden. (properties `((lint-hidden-cve . ("CVE-2011-0433" "CVE-2011-1553" "CVE-2011-1554" "CVE-2011-5244"))))) @end example @item Formatierung Offensichtliche Fehler bei der Formatierung von Quellcode melden, z.B.@: Leerraum-Zeichen am Zeilenende oder Nutzung von Tabulatorzeichen. @end table Die allgemeine Syntax lautet: @example guix lint @var{Optionen} @var{Pakete}@dots{} @end example Wird kein Paket auf der Befehlszeile angegeben, dann werden alle Pakete geprüft, die es gibt. Als @var{Optionen} können null oder mehr der folgenden Befehlszeilenoptionen übergeben werden: @table @code @item --list-checkers @itemx -l Alle verfügbaren Prüfer für die Pakete auflisten und beschreiben. @item --checkers @itemx -c Nur die Prüfer aktivieren, die hiernach in einer kommagetrennten Liste aus von @code{--list-checkers} aufgeführten Prüfern vorkommen. @end table @node Aufruf von guix size @section @command{guix size} aufrufen @cindex Größe @cindex Paketgröße @cindex Abschluss @cindex @command{guix size} Der Befehl @command{guix size} hilft Paketentwicklern dabei, den Plattenplatzverbrauch von Paketen zu profilieren. Es ist leicht, die Auswirkungen zu unterschätzen, die das Hinzufügen zusätzlicher Abhängigkeiten zu einem Paket hat oder die das Verwenden einer einzelnen Ausgabe für ein leicht aufteilbares Paket ausmacht (siehe @ref{Pakete mit mehreren Ausgaben.}). Das sind typische Probleme, auf die @command{guix size} aufmerksam machen kann. Dem Befehl können eine oder mehrere Paketspezifikationen wie @code{gcc@@4.8} oder @code{guile:debug} übergeben werden, oder ein Dateiname im Store. Betrachten Sie dieses Beispiel: @example $ guix size coreutils Store-Objekt Gesamt Selbst /gnu/store/@dots{}-gcc-5.5.0-lib 60.4 30.1 38.1% /gnu/store/@dots{}-glibc-2.27 30.3 28.8 36.6% /gnu/store/@dots{}-coreutils-8.28 78.9 15.0 19.0% /gnu/store/@dots{}-gmp-6.1.2 63.1 2.7 3.4% /gnu/store/@dots{}-bash-static-4.4.12 1.5 1.5 1.9% /gnu/store/@dots{}-acl-2.2.52 61.1 0.4 0.5% /gnu/store/@dots{}-attr-2.4.47 60.6 0.2 0.3% /gnu/store/@dots{}-libcap-2.25 60.5 0.2 0.2% Gesamt: 78.9 MiB @end example @cindex Abschluss Die hier aufgelisteten Store-Objekte bilden den @dfn{transitiven Abschluss} der Coreutils — d.h.@: die Coreutils und all ihre Abhängigkeiten und deren Abhängigkeiten, rekursiv —, wie sie hiervon angezeigt würden: dag.pdf @end example Die Ausgabe sieht so aus: @image{images/coreutils-graph,2in,,Abhängigkeitsgraph der GNU Coreutils} Ein netter, kleiner Graph, oder? Aber es gibt mehr als eine Art von Graph! Der Graph oben ist kurz und knapp: Es ist der Graph der Paketobjekte, ohne implizite Eingaben wie GCC, libc, grep und so weiter. Oft möchte man einen knappen Graphen sehen, aber manchmal will man auch mehr Details sehen. @command{guix graph} unterstützt mehrere Typen von Graphen; Sie können den Detailgrad auswählen. @table @code @item package Der vorgegebene Typ aus dem Beispiel oben. Er zeigt den DAG der Paketobjekte ohne implizite Abhängigkeiten. Er ist knapp, filtert aber viele Details heraus. @item reverse-package Dies zeigt den @emph{umgekehrten} DAG der Pakete. Zum Beispiel: @example guix graph --type=reverse-package ocaml @end example ...@: yields the graph of packages that @emph{explicitly} depend on OCaml (if you are also interested in cases where OCaml is an implicit dependency, see @code{reverse-bag} below.) Beachten Sie, dass für Kernpakete damit gigantische Graphen entstehen können. Wenn Sie nur die Anzahl der Pakete wissen wollen, die von einem gegebenen Paket abhängen, benutzen Sie @command{guix refresh --list-dependent} (siehe @ref{Aufruf von guix refresh, @option{--list-dependent}}). @item bag-emerged Dies ist der Paket-DAG @emph{einschließlich} impliziter Eingaben. Zum Beispiel liefert der folgende Befehl: @example guix graph --type=bag-emerged coreutils | dot -Tpdf > dag.pdf @end example …@: diesen größeren Graphen: @image{images/coreutils-bag-graph,,5in,Detaillierter Abhängigkeitsgraph der GNU Coreutils} Am unteren Rand des Graphen sehen wir alle impliziten Eingaben des @var{gnu-build-system} (siehe @ref{Erstellungssysteme, @code{gnu-build-system}}). Beachten Sie dabei aber, dass auch hier die Abhängigkeiten dieser impliziten Eingaben — d.h.@: die @dfn{Bootstrap-Abhängigkeiten} (siehe @ref{Bootstrapping}) — nicht gezeigt werden, damit der Graph knapper bleibt. @item bag Ähnlich wie @code{bag-emerged}, aber diesmal mit allen Bootstrap-Abhängigkeiten. @item bag-with-origins Ähnlich wie @code{bag}, aber auch mit den Ursprüngen und deren Abhängigkeiten. @item reverse-bag This shows the @emph{reverse} DAG of packages. Unlike @code{reverse-package}, it also takes implicit dependencies into account. For example: @example guix graph -t reverse-bag dune @end example @noindent ...@: yields the graph of all packages that depend on Dune, directly or indirectly. Since Dune is an @emph{implicit} dependency of many packages @i{via} @code{dune-build-system}, this shows a large number of packages, whereas @code{reverse-package} would show very few if any. @item Ableitung Diese Darstellung ist am detailliertesten: Sie zeigt den DAG der Ableitungen (siehe @ref{Ableitungen}) und der einfachen Store-Objekte. Verglichen mit obiger Darstellung sieht man viele zusätzliche Knoten einschließlich Erstellungs-Skripts, Patches, Guile-Module usw. Für diesen Typ Graph kann auch der Name einer @file{.drv}-Datei anstelle eines Paketnamens angegeben werden, etwa so: @example guix graph -t derivation `guix system build -d my-config.scm` @end example @item module Dies ist der Graph der @dfn{Paketmodule} (siehe @ref{Paketmodule}). Zum Beispiel zeigt der folgende Befehl den Graph für das Paketmodul an, das das @code{guile}-Paket definiert: @example guix graph -t module guile | dot -Tpdf > modul-graph.pdf @end example @end table Alle oben genannten Typen entsprechen @emph{Abhängigkeiten zur Erstellungszeit}. Der folgende Graphtyp repräsentiert die @emph{Abhängigkeiten zur Laufzeit}: @table @code @item references Dies ist der Graph der @dfn{Referenzen} einer Paketausgabe, wie @command{guix gc --references} sie liefert (siehe @ref{Aufruf von guix gc}). Wenn die angegebene Paketausgabe im Store nicht verfügbar ist, versucht @command{guix graph}, die Abhängigkeitsinformationen aus Substituten zu holen. Hierbei können Sie auch einen Store-Dateinamen statt eines Paketnamens angeben. Zum Beispiel generiert der Befehl unten den Referenzgraphen Ihres Profils (der sehr groß werden kann!): @example guix graph -t references `readlink -f ~/.guix-profile` @end example @item referrers Dies ist der Graph der ein Store-Objekt @dfn{referenzierenden} Objekte, wie @command{guix gc --referrers} sie liefern würde (siehe @ref{Aufruf von guix gc}). Er basiert ausschließlich auf lokalen Informationen aus Ihrem Store. Nehmen wir zum Beispiel an, dass das aktuelle Inkscape in 10 Profilen verfügbar ist, dann wird @command{guix graph -t referrers inkscape} einen Graph zeigen, der bei Inkscape gewurzelt ist und Kanten zu diesen 10 Profilen hat. Ein solcher Graph kann dabei helfen, herauszufinden, weshalb ein Store-Objekt nicht vom Müllsammler abgeholt werden kann. @end table Folgendes sind die verfügbaren Befehlszeilenoptionen: @table @option @item --type=@var{Typ} @itemx -t @var{Typ} Eine Graph-Ausgabe dieses @var{Typ}s generieren. Dieser @var{Typ} muss einer der oben genannten Werte sein. @item --list-types Die unterstützten Graph-Typen auflisten. @item --backend=@var{Backend} @itemx -b @var{Backend} Einen Graph mit Hilfe des ausgewählten @var{Backend}s generieren. @item --list-backends Die unterstützten Graph-Backends auflisten. Derzeit sind die verfügbaren Backends Graphviz und d3.js. @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Als Paket benutzen, wozu der @var{Ausdruck} ausgewertet wird. Dies ist nützlich, um genau ein bestimmtes Paket zu referenzieren, wie in diesem Beispiel: @example guix graph -e '(@@@@ (gnu packages commencement) gnu-make-final)' @end example @item --system=@var{System} @itemx -s @var{System} Den Graphen für das @var{System} anzeigen — z.B.@: @code{i686-linux}. Der Abhängigkeitsgraph ist größtenteils von der Systemarchitektur unabhängig, aber ein paar architekturabhängige Teile können Ihnen mit dieser Befehlszeilenoption visualisiert werden. @end table @node Aufruf von guix publish @section @command{guix publish} aufrufen @cindex @command{guix publish} Der Zweck von @command{guix publish} ist, es Nutzern zu ermöglichen, ihren Store auf einfache Weise mit anderen zu teilen, die ihn dann als Substitutserver einsetzen können (siehe @ref{Substitute}). Wenn @command{guix publish} ausgeführt wird, wird dadurch ein HTTP-Server gestartet, so dass jeder mit Netzwerkzugang davon Substitute beziehen kann. Das bedeutet, dass jede Maschine, auf der Guix läuft, auch als Build-Farm fungieren kann, weil die HTTP-Schnittstelle mit Hydra, der Software, mit der die offizielle Build-Farm @code{@value{SUBSTITUTE-SERVER}} betrieben wird, kompatibel ist. Um Sicherheit zu gewährleisten, wird jedes Substitut signiert, so dass Empfänger dessen Authentizität und Integrität nachprüfen können (siehe @ref{Substitute}). Weil @command{guix publish} den Signierschlüssel des Systems benutzt, der nur vom Systemadministrator gelesen werden kann, muss es als der Administratornutzer »root« gestartet werden. Mit der Befehlszeilenoption @code{--user} werden Administratorrechte bald nach dem Start wieder abgelegt. Das Schlüsselpaar zum Signieren muss erzeugt werden, bevor @command{guix publish} gestartet wird. Dazu können Sie @command{guix archive --generate-key} ausführen (siehe @ref{Aufruf von guix archive}). Die allgemeine Syntax lautet: @example guix publish @var{Optionen}@dots{} @end example Wird @command{guix publish} ohne weitere Argumente ausgeführt, wird damit ein HTTP-Server gestartet, der auf Port 8080 lauscht: @example guix publish @end example Sobald ein Server zum Veröffentlichen autorisiert wurde (siehe @ref{Aufruf von guix archive}), kann der Daemon davon Substitute herunterladen: @example guix-daemon --substitute-urls=http://example.org:8080 @end example Nach den Voreinstellungen komprimiert @command{guix publish} Archive erst dann, wenn sie angefragt werden. Dieser »dynamische« Modus bietet sich an, weil so nichts weiter eingerichtet werden muss und er direkt verfügbar ist. Wenn Sie allerdings viele Clients bedienen wollen, empfehlen wir, dass Sie die Befehlszeilenoption @option{--cache} benutzen, die das Zwischenspeichern der komprimierten Archive aktiviert, bevor diese an die Clients geschickt werden — siehe unten für Details. Mit dem Befehl @command{guix weather} haben Sie eine praktische Methode zur Hand, zu überprüfen, was so ein Server anbietet (siehe @ref{Aufruf von guix weather}). Als Bonus dient @command{guix publish} auch als inhaltsadressierbarer Spiegelserver für Quelldateien, die in @code{origin}-Verbundsobjekten eingetragen sind (siehe @ref{»origin«-Referenz}). Wenn wir zum Beispiel annehmen, dass @command{guix publish} auf @code{example.org} läuft, liefert folgende URL die rohe @file{hello-2.10.tar.gz}-Datei mit dem angegebenen SHA256-Hash als ihre Prüfsumme (dargestellt im @code{nix-base32}-Format, siehe @ref{Aufruf von guix hash}): @example http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1@dots{}ndq1i @end example Offensichtlich funktionieren diese URLs nur mit solchen Dateien, die auch im Store vorliegen; in anderen Fällen werden sie 404 (»Nicht gefunden«) zurückliefern. @cindex Erstellungsprotokolle, Veröffentlichen Erstellungsprotokolle sind unter @code{/log}-URLs abrufbar: @example http://example.org/log/gwspk@dots{}-guile-2.2.3 @end example @noindent Ist der @command{guix-daemon} so eingestellt, dass er Erstellungsprotokolle komprimiert abspeichert, wie es voreingestellt ist (siehe @ref{Aufruf des guix-daemon}), liefern @code{/log}-URLs das unveränderte komprimierte Protokoll, mit einer entsprechenden @code{Content-Type}- und/oder @code{Content-Encoding}-Kopfzeile. Wir empfehlen dabei, dass Sie den @command{guix-daemon} mit @code{--log-compression=gzip} ausführen, weil Web-Browser dieses Format automatisch dekomprimieren können, was bei bzip2-Kompression nicht der Fall ist. Folgende Befehlszeilenoptionen stehen zur Verfügung: @table @code @item --port=@var{Port} @itemx -p @var{Port} Auf HTTP-Anfragen auf diesem @var{Port} lauschen. @item --listen=@var{Host} Auf der Netzwerkschnittstelle für den angegebenen @var{Host}, also der angegebenen Rechneradresse, lauschen. Vorgegeben ist, Verbindungen mit jeder Schnittstelle zu akzeptieren. @item --user=@var{Benutzer} @itemx -u @var{Benutzer} So früh wie möglich alle über die Berechtigungen des @var{Benutzer}s hinausgehenden Berechtigungen ablegen — d.h.@: sobald der Server-Socket geöffnet und der Signierschlüssel gelesen wurde. @item --compression[=@var{Stufe}] @itemx -C [@var{Stufe}] Daten auf der angegebenen Kompressions-@var{Stufe} komprimieren. Wird als @var{Stufe} null angegeben, wird Kompression deaktiviert. Der Bereich von 1 bis 9 entspricht unterschiedlichen gzip-Kompressionsstufen: 1 ist am schnellsten, während 9 am besten komprimiert (aber den Prozessor mehr auslastet). Der Vorgabewert ist 3. Wenn @option{--cache} nicht übergeben wird, werden Daten dynamisch immer erst dann komprimiert, wenn sie abgeschickt werden; komprimierte Datenströme landen in keinem Zwischenspeicher. Um also die Auslastung der Maschine, auf der @command{guix publish} läuft, zu reduzieren, kann es eine gute Idee sein, eine niedrige Kompressionsstufe zu wählen, @command{guix publish} einen Proxy mit Zwischenspeicher (einen »Caching Proxy«) voranzuschalten, oder @option{--cache} zu benutzen. @option{--cache} zu benutzen, hat den Vorteil, dass @command{guix publish} damit eine @code{Content-Length}-HTTP-Kopfzeile seinen Antworten beifügen kann. @item --cache=@var{Verzeichnis} @itemx -c @var{Verzeichnis} Archive und Metadaten (@code{.narinfo}-URLs) in das @var{Verzeichnis} zwischenspeichern und nur solche Archive versenden, die im Zwischenspeicher vorliegen. Wird diese Befehlszeilenoption weggelassen, dann werden Archive und Metadaten »dynamisch« erst auf eine Anfrage hin erzeugt. Dadurch kann die verfügbare Bandbreite reduziert werden, besonders wenn Kompression aktiviert ist, weil die Operation dann durch die Prozessorleistung beschränkt sein kann. Noch ein Nachteil des voreingestellten Modus ist, dass die Länge der Archive nicht im Voraus bekannt ist, @command{guix publish} also keine @code{Content-Length}-HTTP-Kopfzeile an seine Antworten anfügt, wodurch Clients nicht wissen können, welche Datenmenge noch heruntergeladen werden muss. Im Gegensatz dazu liefert, wenn @option{--cache} benutzt wird, die erste Anfrage nach einem Store-Objekt (über dessen @code{.narinfo}-URL) den Fehlercode 404, und im Hintergrund wird ein Prozess gestartet, der das Archiv in den Zwischenspeicher einlagert (auf Englisch sagen wir »@dfn{bake} the archive«), d.h.@: seine @code{.narinfo} wird berechnet und das Archiv, falls nötig, komprimiert. Sobald das Archiv im @var{Verzeichnis} zwischengespeichert wurde, werden nachfolgende Anfragen erfolgreich sein und direkt aus dem Zwischenspeicher bedient, der garantiert, dass Clients optimale Bandbreite genießen. Der Prozess zum Einlagern wird durch Worker-Threads umgesetzt. Der Vorgabe entsprechend wird dazu pro Prozessorkern ein Thread erzeugt, aber dieses Verhalten kann angepasst werden. Siehe @option{--workers} weiter unten. Wird @option{--ttl} verwendet, werden zwischengespeicherte Einträge automatisch gelöscht, sobald die dabei angegebene Zeit abgelaufen ist. @item --workers=@var{N} Wird @option{--cache} benutzt, wird die Reservierung von @var{N} Worker-Threads angefragt, um Archive einzulagern. @item --ttl=@var{ttl} @code{Cache-Control}-HTTP-Kopfzeilen erzeugen, die eine Time-to-live (TTL) von @var{ttl} signalisieren. Für @var{ttl} muss eine Dauer (mit dem Anfangsbuchstaben der Maßeinheit der Dauer im Englischen) angegeben werden: @code{5d} bedeutet 5 Tage, @code{1m} bedeutet 1 Monat und so weiter. Das ermöglicht es Guix, Substitutinformationen @var{ttl} lang zwischenzuspeichern. Beachten Sie allerdings, dass @code{guix publish} selbst @emph{nicht} garantiert, dass die davon angebotenen Store-Objekte so lange verfügbar bleiben, wie es die @var{ttl} vorsieht. Des Weiteren können bei Nutzung von @option{--cache} die zwischengespeicherten Einträge gelöscht werden, wenn auf sie @var{ttl} lang nicht zugegriffen wurde und kein ihnen entsprechendes Objekt mehr im Store existiert. @item --nar-path=@var{Pfad} Den @var{Pfad} als Präfix für die URLs von »nar«-Dateien benutzen (siehe @ref{Aufruf von guix archive, normalized archives}). Vorgegeben ist, dass Nars unter einer URL mit @code{/nar/gzip/@dots{}-coreutils-8.25} angeboten werden. Mit dieser Befehlszeilenoption können Sie den @code{/nar}-Teil durch den angegebenen @var{Pfad} ersetzen. @item --public-key=@var{Datei} @itemx --private-key=@var{Datei} Die angegebenen @var{Datei}en als das Paar aus öffentlichem und privatem Schlüssel zum Signieren veröffentlichter Store-Objekte benutzen. Die Dateien müssen demselben Schlüsselpaar entsprechen (der private Schlüssel wird zum Signieren benutzt, der öffentliche Schlüssel wird lediglich in den Metadaten der Signatur aufgeführt). Die Dateien müssen Schlüssel im kanonischen (»canonical«) S-Ausdruck-Format enthalten, wie es von @command{guix archive --generate-key} erzeugt wird (siehe @ref{Aufruf von guix archive}). Vorgegeben ist, dass @file{/etc/guix/signing-key.pub} und @file{/etc/guix/signing-key.sec} benutzt werden. @item --repl[=@var{Port}] @itemx -r [@var{Port}] Einen Guile-REPL-Server (siehe @ref{REPL Servers,,, guile, GNU Guile Reference Manual}) auf diesem @var{Port} starten (37146 ist voreingestellt). Dies kann zur Fehlersuche auf einem laufenden »@command{guix publish}«-Server benutzt werden. @end table @command{guix publish} auf einem »Guix System«-System zu aktivieren ist ein Einzeiler: Instanziieren Sie einfach einen @code{guix-publish-service-type}-Dienst im @code{services}-Feld Ihres @code{operating-system}-Objekts zur Betriebssystemdeklaration (siehe @ref{guix-publish-service-type, @code{guix-publish-service-type}}). Falls Sie Guix aber auf einer »Fremddistribution« laufen lassen, folgen Sie folgenden Anweisungen: @itemize @item Wenn Ihre Wirtsdistribution systemd als »init«-System benutzt: @example # ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service \ /etc/systemd/system/ # systemctl start guix-publish && systemctl enable guix-publish @end example @item Wenn Ihre Wirts-Distribution als »init«-System Upstart verwendet: @example # ln -s ~root/.guix-profile/lib/upstart/system/guix-publish.conf /etc/init/ # start guix-publish @end example @item Verfahren Sie andernfalls auf die gleiche Art für das »init«-System, das Ihre Distribution verwendet. @end itemize @node Aufruf von guix challenge @section @command{guix challenge} aufrufen @cindex Reproduzierbare Erstellungen @cindex verifizierbare Erstellungen @cindex @command{guix challenge} @cindex Anfechten Entsprechen die von diesem Server gelieferten Binärdateien tatsächlich dem Quellcode, aus dem sie angeblich erzeugt wurden? Ist ein Paketerstellungsprozess deterministisch? Diese Fragen versucht @command{guix challenge} zu beantworten. Die erste Frage ist offensichtlich wichtig: Bevor man einen Substitutserver benutzt (siehe @ref{Substitute}), @emph{verifiziert} man besser, dass er die richtigen Binärdateien liefert, d.h.@: man @emph{fechtet sie an}. Die letzte Frage macht die erste möglich: Wenn Paketerstellungen deterministisch sind, müssten voneinander unabhängige Erstellungen genau dasselbe Ergebnis liefern, Bit für Bit; wenn ein Server mit einer anderen Binärdatei als der lokal erstellten Binärdatei antwortet, ist diese entweder beschädigt oder bösartig. Wir wissen, dass die in @file{/gnu/store}-Dateinamen auftauchende Hash-Prüfsumme der Hash aller Eingaben des Prozesses ist, mit dem die Datei oder das Verzeichnis erstellt wurde — Compiler, Bibliotheken, Erstellungsskripts und so weiter (siehe @ref{Einführung}). Wenn wir von deterministischen Erstellungen ausgehen, sollte ein Store-Dateiname also auf genau eine Erstellungsausgabe abgebildet werden. Mit @command{guix challenge} prüft man, ob es tatsächlich eine eindeutige Abbildung gibt, indem die Erstellungsausgaben mehrerer unabhängiger Erstellungen jedes angegebenen Store-Objekts verglichen werden. Die Ausgabe des Befehls sieht so aus: @smallexample $ guix challenge --substitute-urls="https://@value{SUBSTITUTE-SERVER} https://guix.example.org" Liste der Substitute von »https://@value{SUBSTITUTE-SERVER}« wird aktualisiert … 100.0% Liste der Substitute von »https://guix.example.org« wird aktualisiert … 100.0% Inhalt von /gnu/store/@dots{}-openssl-1.0.2d verschieden: lokale Prüfsumme: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q https://guix.example.org/nar/@dots{}-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim Inhalt von /gnu/store/@dots{}-git-2.5.0 verschieden: lokale Prüfsumme: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f https://guix.example.org/nar/@dots{}-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73 Inhalt von /gnu/store/@dots{}-pius-2.1.1 verschieden: lokale Prüfsumme: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax https://guix.example.org/nar/@dots{}-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs @dots{} 6,406 Store-Objekte wurden analysiert: — 4,749 (74.1%) waren identisch — 525 (8.2%) unterscheiden sich — 1,132 (17.7%) blieben ergebnislos @end smallexample @noindent In diesem Beispiel wird mit @command{guix challenge} zuerst die Menge lokal erstellter Ableitungen im Store ermittelt — im Gegensatz zu von einem Substitserver heruntergeladenen Store-Objekten — und dann werden alle Substitutserver angefragt. Diejenigen Store-Objekte, bei denen der Server ein anderes Ergebnis berechnet hat als die lokale Erstellung, werden gemeldet. @cindex Nichtdeterminismus, in Paketerstellungen Nehmen wir zum Beispiel an, @code{guix.example.org} gibt uns immer eine verschiedene Antwort, aber @code{@value{SUBSTITUTE-SERVER}} stimmt mit lokalen Erstellungen überein, @emph{außer} im Fall von Git. Das könnte ein Hinweis sein, dass der Erstellungsprozess von Git nichtdeterministisch ist; das bedeutet, seine Ausgabe variiert abhängig von verschiedenen Umständen, die Guix nicht vollends kontrollieren kann, obwohl es Pakete in isolierten Umgebungen erstellt (siehe @ref{Funktionalitäten}). Zu den häufigsten Quellen von Nichtdeterminismus gehören das Einsetzen von Zeitstempeln innerhalb der Erstellungsgebnisse, das Einsetzen von Zufallszahlen und von Auflistungen eines Verzeichnisinhalts sortiert nach der Inode-Nummer. Siehe @uref{https://reproducible-builds.org/docs/} für mehr Informationen. Um herauszufinden, was mit dieser Git-Binärdatei nicht stimmt, können wir so etwas machen (siehe @ref{Aufruf von guix archive}): @example $ wget -q -O - https://@value{SUBSTITUTE-SERVER}/nar/@dots{}-git-2.5.0 \ | guix archive -x /tmp/git $ diff -ur --no-dereference /gnu/store/@dots{}-git.2.5.0 /tmp/git @end example Dieser Befehl zeigt die Unterschiede zwischen den Dateien, die sich aus der lokalen Erstellung ergeben, und den Dateien, die sich aus der Erstellung auf @code{@value{SUBSTITUTE-SERVER}} ergeben (siehe @ref{Overview, Comparing and Merging Files,, diffutils, Comparing and Merging Files}). Der Befehl @command{diff} funktioniert großartig für Textdateien. Wenn sich Binärdateien unterscheiden, ist @uref{https://diffoscope.org/, Diffoscope} die bessere Wahl: Es ist ein hilfreiches Werkzeug, das Unterschiede in allen Arten von Dateien visualisiert. Sobald Sie mit dieser Arbeit fertig sind, können Sie erkennen, ob die Unterschiede aufgrund eines nichtdeterministischen Erstellungsprozesses oder wegen einem bösartigen Server zustande kommen. Wir geben uns Mühe, Quellen von Nichtdeterminismus in Paketen zu entfernen, damit Substitute leichter verifiziert werden können, aber natürlich ist an diesem Prozess nicht nur Guix, sondern ein großer Teil der Freie-Software-Gemeinschaft beteiligt. In der Zwischenzeit ist @command{guix challenge} eines der Werkzeuge, die das Problem anzugehen helfen. Wenn Sie ein Paket für Guix schreiben, ermutigen wir Sie, zu überprüfen, ob @code{@value{SUBSTITUTE-SERVER}} und andere Substitutserver dasselbe Erstellungsergebnis bekommen, das Sie bekommen haben. Das geht so: @example $ guix challenge @var{Paket} @end example @noindent Dabei wird mit @var{Paket} eine Paketspezifikation wie @code{guile@@2.0} oder @code{glibc:debug} bezeichnet. Die allgemeine Syntax lautet: @example guix challenge @var{Optionen} [@var{Pakete}@dots{}] @end example Wird ein Unterschied zwischen der Hash-Prüfsumme des lokal erstellten Objekts und dem vom Server gelieferten Substitut festgestellt, oder zwischen den Substituten von unterschiedlichen Servern, dann wird der Befehl dies wie im obigen Beispiel anzeigen und mit dem Exit-Code 2 terminieren (andere Exit-Codes außer null stehen für andere Arten von Fehlern). Die eine, wichtige Befehlszeilenoption ist: @table @code @item --substitute-urls=@var{URLs} Die @var{URLs} als durch Leerraumzeichen getrennte Liste von Substitut-Quell-URLs benutzen. mit denen verglichen wird. @item --verbose @itemx -v Details auch zu Übereinstimmungen (deren Inhalt identisch ist) ausgeben, zusätzlich zu Informationen über Unterschiede. @end table @node Aufruf von guix copy @section @command{guix copy} aufrufen @cindex Kopieren, von Store-Objekten, über SSH @cindex SSH, Kopieren von Store-Objekten @cindex Store-Objekte zwischen Maschinen teilen @cindex Übertragen von Store-Objekten zwischen Maschinen Der Befehl @command{guix copy} kopiert Objekte aus dem Store einer Maschine in den Store einer anderen Maschine mittels einer Secure-Shell-Verbindung (kurz SSH-Verbindung)@footnote{Dieser Befehl steht nur dann zur Verfügung, wenn Guile-SSH gefunden werden kann. Siehe @ref{Voraussetzungen} für Details.}. Zum Beispiel kopiert der folgende Befehl das Paket @code{coreutils}, das Profil des Benutzers und all deren Abhängigkeiten auf den anderen @var{Rechner}, dazu meldet sich Guix als @var{Benutzer} an: @example guix copy --to=@var{Benutzer}@@@var{Rechner} \ coreutils `readlink -f ~/.guix-profile` @end example Wenn manche der zu kopierenden Objekte schon auf dem anderen @var{Rechner} vorliegen, werden sie tatsächlich @emph{nicht} übertragen. Der folgende Befehl bezieht @code{libreoffice} und @code{gimp} von dem @var{Rechner}, vorausgesetzt sie sind dort verfügbar: @example guix copy --from=@var{host} libreoffice gimp @end example Die SSH-Verbindung wird mit dem Guile-SSH-Client hergestellt, der mit OpenSSH kompatibel ist: Er berücksichtigt @file{~/.ssh/known_hosts} und @file{~/.ssh/config} und verwendet den SSH-Agenten zur Authentifizierung. Der Schlüssel, mit dem gesendete Objekte signiert sind, muss von der entfernten Maschine akzeptiert werden. Ebenso muss der Schlüssel, mit dem die Objekte signiert sind, die Sie von der entfernten Maschine empfangen, in Ihrer Datei @file{/etc/guix/acl} eingetragen sein, damit Ihr Daemon sie akzeptiert. Siehe @ref{Aufruf von guix archive} für mehr Informationen über die Authentifizierung von Store-Objekten. Die allgemeine Syntax lautet: @example guix copy [--to=@var{Spezifikation}|--from=@var{Spezifikation}] @var{Objekte}@dots{} @end example Sie müssen immer eine der folgenden Befehlszeilenoptionen angeben: @table @code @item --to=@var{Spezifikation} @itemx --from=@var{Spezifikation} Gibt den Rechner (den »Host«) an, an den oder von dem gesendet bzw. empfangen wird. Die @var{Spezifikation} muss eine SSH-Spezifikation sein wie @code{example.org}, @code{charlie@@example.org} oder @code{charlie@@example.org:2222}. @end table Die @var{Objekte} können entweder Paketnamen wie @code{gimp} oder Store-Objekte wie @file{/gnu/store/@dots{}-idutils-4.6} sein. Wenn ein zu sendendes Paket mit Namen angegeben wird, wird es erst erstellt, falls es nicht im Store vorliegt, außer @option{--dry-run} wurde angegeben wurde. Alle gemeinsamen Erstellungsoptionen werden unterstützt (siehe @ref{Gemeinsame Erstellungsoptionen}). @node Aufruf von guix container @section @command{guix container} aufrufen @cindex container @cindex @command{guix container} @quotation Anmerkung Dieses Werkzeug ist noch experimentell, Stand Version @value{VERSION}. Die Schnittstelle wird sich in Zukunft grundlegend verändern. @end quotation Der Zweck von @command{guix container} ist, in einer isolierten Umgebung (gemeinhin als »Container« bezeichnet) laufende Prozesse zu manipulieren, die typischerweise durch die Befehle @command{guix environment} (siehe @ref{Aufruf von guix environment}) und @command{guix system container} (siehe @ref{Aufruf von guix system}) erzeugt werden. Die allgemeine Syntax lautet: @example guix container @var{Aktion} @var{Optionen}@dots{} @end example Mit @var{Aktion} wird die Operation angegeben, die in der isolierten Umgebung durchgeführt werden soll, und mit @var{Optionen} werden die kontextabhängigen Argumente an die Aktion angegeben. Folgende Aktionen sind verfügbar: @table @code @item exec Führt einen Befehl im Kontext der laufenden isolierten Umgebung aus. Die Syntax ist: @example guix container exec @var{PID} @var{Programm} @var{Argumente}@dots{} @end example @var{PID} gibt die Prozess-ID der laufenden isolierten Umgebung an. Als @var{Programm} muss eine ausführbare Datei im Wurzeldateisystem der isolierten Umgebung angegeben werden. Die @var{Argumente} sind die zusätzlichen Befehlszeilenoptionen, die an das @var{Programm} übergeben werden. Der folgende Befehl startet eine interaktive Anmelde-Shell innerhalb einer isolierten Guix-Systemumgebung, gestartet durch @command{guix system container}, dessen Prozess-ID 9001 ist: @example guix container exec 9001 /run/current-system/profile/bin/bash --login @end example Beachten Sie, dass die @var{PID} nicht der Elternprozess der isolierten Umgebung sein darf, sondern PID 1 in der isolierten Umgebung oder einer seiner Kindprozesse sein muss. @end table @node Aufruf von guix weather @section @command{guix weather} aufrufen Manchmal werden Sie schlecht gelaunt sein, weil es zu wenige Substitute gibt und die Pakete bei Ihnen selbst erstellt werden müssen (siehe @ref{Substitute}). Der Befehl @command{guix weather} zeigt einen Bericht über die Verfügbarkeit von Substituten auf den angegebenen Servern an, damit Sie sich eine Vorstellung davon machen können, wie es heute um Ihre Laune bestellt sein wird. Manchmal bekommt man als Nutzer so hilfreiche Informationen, aber in erster Linie nützt der Befehl den Leuten, die @command{guix publish} benutzen (siehe @ref{Aufruf von guix publish}). @cindex Statistik, für Substitute @cindex Verfügbarkeit von Substituten @cindex Substitutverfügbarkeit @cindex Wetter, Substitutverfügbarkeit Hier ist ein Beispiel für einen Aufruf davon: @example $ guix weather --substitute-urls=https://guix.example.org 5.872 Paketableitungen für x86_64-linux berechnen … Nach 6.128 Store-Objekten von https://guix.example.org suchen … updating list of substitutes from 'https://guix.example.org'... 100.0% https://guix.example.org 43,4% Substitute verfügbar (2.658 von 6.128) 7.032,5 MiB an Nars (komprimiert) 19.824,2 MiB auf der Platte (unkomprimiert) 0,030 Sekunden pro Anfrage (182,9 Sekunden insgesamt) 33,5 Anfragen pro Sekunde 9,8% (342 von 3.470) der fehlenden Objekte sind in der Warteschlange Mindestens 867 Erstellungen in der Warteschlange x86_64-linux: 518 (59,7%) i686-linux: 221 (25,5%) aarch64-linux: 128 (14,8%) Erstellungsgeschwindigkeit: 23,41 Erstellungen pro Stunde x86_64-linux: 11,16 Erstellungen pro Stunde i686-linux: 6,03 Erstellungen pro Stunde aarch64-linux: 6,41 Erstellungen pro Stunde @end example @cindex Kontinuierliche Integration, Statistik Wie Sie sehen können, wird der Anteil unter allen Paketen angezeigt, für die auf dem Server Substitute verfügbar sind — unabhängig davon, ob Substitute aktiviert sind, und unabhängig davon, ob der signierende Schlüssel des Servers autorisiert ist. Es wird auch über die Größe der komprimierten Archive (die »Nars«) berichtet, die vom Server angeboten werden, sowie über die Größe, die die zugehörigen Store-Objekte im Store belegen würden (unter der Annahme, dass Deduplizierung abgeschaltet ist) und über den Durchsatz des Servers. Der zweite Teil sind Statistiken zur Kontinuierlichen Integration (englisch »Continuous Integration«, kurz CI), wenn der Server dies unterstützt. Des Weiteren kann @command{guix weather}, wenn es mit der Befehlszeilenoption @option{--coverage} aufgerufen wird, »wichtige« Paketsubstitute, die auf dem Server fehlen, auflisten (siehe unten). Dazu werden mit @command{guix weather} Anfragen über HTTP(S) zu Metadaten (@dfn{Narinfos}) für alle relevanten Store-Objekte gestellt. Wie @command{guix challenge} werden die Signaturen auf den Substituten ignoriert, was harmlos ist, weil der Befehl nur Statistiken sammelt und keine Substitute installieren kann. Neben anderen Dingen ist es möglich, bestimmte Systemtypen und bestimmte Paketmengen anzufragen. Die verfügbaren Befehlszeilenoptionen sind folgende: @table @code @item --substitute-urls=@var{URLs} @var{URLs} ist eine leerzeichengetrennte Liste anzufragender Substitutserver-URLs. Wird diese Befehlszeilenoption weggelassen, wird die vorgegebene Menge an Substitutservern angefragt. @item --system=@var{System} @itemx -s @var{System} Substitute für das @var{System} anfragen — z.B.@: für @code{aarch64-linux}. Diese Befehlszeilenoption kann mehrmals angegeben werden, wodurch @command{guix weather} die Substitute für mehrere Systemtypen anfragt. @item --manifest=@var{Datei} Anstatt die Substitute für alle Pakete anzufragen, werden nur die in der @var{Datei} angegebenen Pakete erfragt. Die @var{Datei} muss ein @dfn{Manifest} enthalten, wie bei der Befehlszeilenoption @code{-m} von @command{guix package} (siehe @ref{Aufruf von guix package}). @item --coverage[=@var{Anzahl}] @itemx -c [@var{Anzahl}] Einen Bericht über die Substitutabdeckung für Pakete ausgeben, d.h.@: Pakete mit mindestens @var{Anzahl}-vielen Abhängigen (voreingestellt mindestens null) anzeigen, für die keine Substitute verfügbar sind. Die abhängigen Pakete werden selbst nicht aufgeführt: Wenn @var{b} von @var{a} abhängt und Substitute für @var{a} fehlen, wird nur @var{a} aufgeführt, obwohl dann in der Regel auch die Substitute für @var{b} fehlen. Das Ergebnis sieht so aus: @example $ guix weather --substitute-urls=https://ci.guix.de.info -c 10 8.983 Paketableitungen für x86_64-linux berechnen … Nach 9.343 Store-Objekten von https://ci.guix.de.info suchen … Liste der Substitute von »https://ci.guix.de.info« wird aktualisiert … 100.0% https://ci.guix.de.info 64.7% Substitute verfügbar (6.047 von 9.343) @dots{} 2502 Pakete fehlen auf »https://ci.guix.de.info« für »x86_64-linux«, darunter sind: 58 kcoreaddons@@5.49.0 /gnu/store/@dots{}-kcoreaddons-5.49.0 46 qgpgme@@1.11.1 /gnu/store/@dots{}-qgpgme-1.11.1 37 perl-http-cookiejar@@0.008 /gnu/store/@dots{}-perl-http-cookiejar-0.008 @dots{} @end example What this example shows is that @code{kcoreaddons} and presumably the 58 packages that depend on it have no substitutes at @code{ci.guix.de.info}; likewise for @code{qgpgme} and the 46 packages that depend on it. If you are a Guix developer, or if you are taking care of this build farm, you'll probably want to have a closer look at these packages: they may simply fail to build. @end table @node Aufruf von guix processes @section @command{guix processes} aufrufen Der Befehl @command{guix processes} kann sich für Entwickler und Systemadministratoren als nützlich erweisen, besonders auf Maschinen mit mehreren Nutzern und auf Build-Farms. Damit werden die aktuellen Sitzungen (also Verbindungen zum Daemon) sowie Informationen über die beteiligten Prozesse aufgelistet@footnote{Entfernte Sitzungen, wenn @command{guix-daemon} mit @option{--listen} unter Angabe eines TCP-Endpunkts gestartet wurde, werden @emph{nicht} aufgelistet.}. Hier ist ein Beispiel für die davon gelieferten Informationen: @example $ sudo guix processes SessionPID: 19002 ClientPID: 19090 ClientCommand: guix environment --ad-hoc python SessionPID: 19402 ClientPID: 19367 ClientCommand: guix publish -u guix-publish -p 3000 -C 9 @dots{} SessionPID: 19444 ClientPID: 19419 ClientCommand: cuirass --cache-directory /var/cache/cuirass @dots{} LockHeld: /gnu/store/@dots{}-perl-ipc-cmd-0.96.lock LockHeld: /gnu/store/@dots{}-python-six-bootstrap-1.11.0.lock LockHeld: /gnu/store/@dots{}-libjpeg-turbo-2.0.0.lock ChildProcess: 20495: guix offload x86_64-linux 7200 1 28800 ChildProcess: 27733: guix offload x86_64-linux 7200 1 28800 ChildProcess: 27793: guix offload x86_64-linux 7200 1 28800 @end example In diesem Beispiel sehen wir, dass @command{guix-daemon} drei Clients hat: @command{guix environment}, @command{guix publish} und das Werkzeug Cuirass zur Kontinuierlichen Integration. Deren Prozesskennung (PID) ist jeweils im @code{ClientPID}-Feld zu sehen. Das Feld @code{SessionPID} zeigt die PID des @command{guix-daemon}-Unterprozesses dieser bestimmten Sitzung. Das Feld @code{LockHeld} zeigt an, welche Store-Objekte derzeit durch die Sitzung gesperrt sind, d.h.@: welche Store-Objekte zur Zeit erstellt oder substituiert werden (das @code{LockHeld}-Feld wird nicht angezeigt, wenn @command{guix processes} nicht als Administratornutzer root ausgeführt wird). Letztlich sehen wir am @code{ChildProcess}-Feld oben, dass diese drei Erstellungen hier ausgelagert (englisch »offloaded«) werden (siehe @ref{Auslagern des Daemons einrichten}). Die Ausgabe ist im Recutils-Format, damit wir den praktischen @command{recsel}-Befehl benutzen können, um uns interessierende Sitzungen auszuwählen (siehe @ref{Selection Expressions,,, recutils, GNU recutils manual}). Zum Beispiel zeigt dieser Befehl die Befehlszeile und PID des Clients an, der die Erstellung des Perl-Pakets ausgelöst hat: @example $ sudo guix processes | \ recsel -p ClientPID,ClientCommand -e 'LockHeld ~ "perl"' ClientPID: 19419 ClientCommand: cuirass --cache-directory /var/cache/cuirass @dots{} @end example @node Systemkonfiguration @chapter Systemkonfiguration @cindex Systemkonfiguration Die »Guix System«-Distribution unterstützt einen Mechanismus zur konsistenten Konfiguration des gesamten Systems. Damit meinen wir, dass alle Aspekte der globalen Systemkonfiguration an einem Ort stehen, d.h.@: die zur Verfügung gestellten Systemdienste, die Zeitzone und Einstellungen zur Locale (also die Anpassung an regionale Gepflogenheiten und Sprachen) sowie Benutzerkonten. Sie alle werden an derselben Stelle deklariert. So eine @dfn{Systemkonfiguration} kann @dfn{instanziiert}, also umgesetzt, werden. @c Yes, we're talking of Puppet, Chef, & co. here. ↑ Einer der Vorteile, die ganze Systemkonfiguration unter die Kontrolle von Guix zu stellen, ist, dass so transaktionelle Systemaktualisierungen möglich werden und dass diese rückgängig gemacht werden können, wenn das aktualisierte System nicht richtig funktioniert (siehe @ref{Funktionalitäten}). Ein anderer Vorteil ist, dass dieselbe Systemkonfiguration leicht auf einer anderen Maschine oder zu einem späteren Zeitpunkt benutzt werden kann, ohne dazu eine weitere Schicht administrativer Werkzeuge über den systemeigenen Werkzeugen einsetzen zu müssen. In diesem Abschnitt wird dieser Mechanismus beschrieben. Zunächst betrachten wir ihn aus der Perspektive eines Administrators. Dabei wird erklärt, wie das System konfiguriert und instanziiert werden kann. Dann folgt eine Demonstration, wie der Mechanismus erweitert werden kann, etwa um neue Systemdienste zu unterstützen. @menu * Das Konfigurationssystem nutzen:: Ihr GNU-System anpassen. * »operating-system«-Referenz:: Details der Betriebssystem-Deklarationen. * Dateisysteme:: Die Dateisystemeinbindungen konfigurieren. * Zugeordnete Geräte:: Näheres zu blockorientierten Speichermedien. * Benutzerkonten:: Benutzerkonten festlegen. * Tastaturbelegung:: Wie das System Tastendrücke interpretiert. * Locales:: Sprache und kulturelle Konventionen. * Dienste:: Systemdienste festlegen. * Setuid-Programme:: Mit Administratorrechten startende Programme. * X.509-Zertifikate:: HTTPS-Server authentifizieren. * Name Service Switch:: Den Name Service Switch von libc konfigurieren. * Initiale RAM-Disk:: Linux-libre hochfahren. * Bootloader-Konfiguration:: Den Bootloader konfigurieren. * Aufruf von guix system:: Instanziierung einer Systemkonfiguration. * Guix in einer VM starten:: Wie man »Guix System« in einer virtuellen Maschine startet. * Dienste definieren:: Neue Dienstdefinitionen hinzufügen. @end menu @node Das Konfigurationssystem nutzen @section Das Konfigurationssystem nutzen Das Betriebssystem können Sie konfigurieren, indem Sie eine @code{operating-system}-Deklaration in einer Datei speichern, die Sie dann dem Befehl @command{guix system} übergeben (siehe @ref{Aufruf von guix system}). Eine einfache Konfiguration mit den vorgegebenen Systemdiensten und dem vorgegebenen Linux-Libre als Kernel und mit einer initialen RAM-Disk und einem Bootloader, sieht so aus: @findex operating-system @lisp @include os-config-bare-bones.texi @end lisp Dieses Beispiel sollte selbsterklärend sein. Manche der Felder oben, wie etwa @code{host-name} und @code{bootloader}, müssen angegeben werden. Andere sind optional, wie etwa @code{packages} und @code{services}, sind optional; werden sie nicht angegeben, nehmen sie einen Vorgabewert an. Im Folgenden werden die Effekte von einigen der wichtigsten Feldern erläutert (siehe @ref{»operating-system«-Referenz} für Details zu allen verfügbaren Feldern), dann wird beschrieben, wie man das Betriebssystem mit @command{guix system} @dfn{instanziieren} kann. @unnumberedsubsec Bootloader @cindex Legacy-Boot, auf Intel-Maschinen @cindex BIOS-Boot, auf Intel-Maschinen @cindex UEFI-Boot @cindex EFI-Boot Das @code{bootloader}-Feld beschreibt, mit welcher Methode Ihr System »gebootet« werden soll. Maschinen, die auf Intel-Prozessoren basieren, können im alten »Legacy«-BIOS-Modus gebootet werden, wie es im obigen Beispiel der Fall wäre. Neuere Maschinen benutzen stattdessen das @dfn{Unified Extensible Firmware Interface} (UEFI) zum Booten. In diesem Fall sollte das @code{bootloader}-Feld in etwa so aussehen: @example (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi")) @end example Siehe den Abschnitt @ref{Bootloader-Konfiguration} für weitere Informationen zu den verfügbaren Konfigurationsoptionen. @unnumberedsubsec global sichtbare Pakete @vindex %base-packages Im Feld @code{packages} werden Pakete aufgeführt, die auf dem System für alle Benutzerkonten global sichtbar sein sollen, d.h.@: in der @code{PATH}-Umgebungsvariablen jedes Nutzers, zusätzlich zu den nutzereigenen Profilen (siehe @ref{Aufruf von guix package}). Die Variable @var{%base-packages} bietet alle Werkzeuge, die man für grundlegende Nutzer- und Administratortätigkeiten erwarten würde, einschließlich der GNU Core Utilities, der GNU Networking Utilities, des leichtgewichtigen Texteditors GNU Zile, @command{find}, @command{grep} und so weiter. Obiges Beispiel fügt zu diesen noch das Programm GNU@tie{}Screen hinzu, welches aus dem Modul @code{(gnu packages screen)} genommen wird (siehe @ref{Paketmodule}). Die Syntax @code{(list package output)} kann benutzt werden, um eine bestimmte Ausgabe eines Pakets auszuwählen: @lisp (use-modules (gnu packages)) (use-modules (gnu packages dns)) (operating-system ;; ... (packages (cons (list bind "utils") %base-packages))) @end lisp @findex specification->package Sich auf Pakete anhand ihres Variablennamens zu beziehen, wie oben bei @code{bind}, hat den Vorteil, dass der Name eindeutig ist; Tippfehler werden direkt als »unbound variables« gemeldet. Der Nachteil ist, dass man wissen muss, in welchem Modul ein Paket definiert wird, um die Zeile mit @code{use-package-modules} entsprechend zu ergänzen. Um dies zu vermeiden, kann man auch die Prozedur @code{specification->package} aus dem Modul @code{(gnu packages)} aufrufen, welche das einem angegebenen Namen oder Name-Versions-Paar zu Grunde liegende Paket liefert: @lisp (use-modules (gnu packages)) (operating-system ;; ... (packages (append (map specification->package '("tcpdump" "htop" "gnupg@@2.0")) %base-packages))) @end lisp @unnumberedsubsec Systemdienste @cindex services @vindex %base-services Das Feld @code{services} listet @dfn{Systemdienste} auf, die zur Verfügung stehen sollen, wenn das System startet (siehe @ref{Dienste}). Die @code{operating-system}-Deklaration oben legt fest, dass wir neben den grundlegenden Basis-Diensten auch wollen, dass der OpenSSH-Secure-Shell-Daemon auf Port 2222 lauscht (siehe @ref{Netzwerkdienste, @code{openssh-service-type}}). Intern sorgt der @code{openssh-service-type} dafür, dass @code{sshd} mit den richtigen Befehlszeilenoptionen aufgerufen wird, je nach Systemkonfiguration werden auch für dessen Betrieb nötige Konfigurationsdateien erstellt (siehe @ref{Dienste definieren}). @cindex Anpassung, von Diensten @findex modify-services Gelegentlich werden Sie die Basis-Dienste nicht einfach so, wie sie sind, benutzen, sondern anpassen wollen. Benutzen Sie @code{modify-services} (siehe @ref{Service-Referenz, @code{modify-services}}), um die Liste der Basis-Dienste zu modifizieren. Wenn Sie zum Beispiel @code{guix-daemon} und Mingetty (das Programm, womit Sie sich auf der Konsole anmelden) in der @var{%base-services}-Liste modifizieren möchten (siehe @ref{Basisdienste, @code{%base-services}}), schreiben Sie das Folgende in Ihre Betriebssystemdeklaration: @lisp (define %my-services ;; Meine ganz eigene Liste von Diensten. (modify-services %base-services (guix-service-type config => (guix-configuration (inherit config) (use-substitutes? #f) (extra-options '("--gc-keep-derivations")))) (mingetty-service-type config => (mingetty-configuration (inherit config))))) (operating-system ;; @dots{} (services %my-services)) @end lisp Dadurch ändert sich die Konfiguration — d.h.@: die Dienst-Parameter — der @code{guix-service-type}-Instanz und die aller @code{mingetty-service-type}-Instanzen in der @var{%base-services}-Liste. Das funktioniert so: Zunächst arrangieren wir, dass die ursprüngliche Konfiguration an den Bezeichner @code{config} im @var{Rumpf} gebunden wird, dann schreiben wir den @var{Rumpf}, damit er zur gewünschten Konfiguration ausgewertet wird. Beachten Sie insbesondere, wie wir mit @code{inherit} eine neue Konfiguration erzeugen, die dieselben Werte wie die alte Konfiguration hat, aber mit ein paar Modifikationen. @cindex verschlüsselte Partition Die Konfiguration für typische »Schreibtisch«-Nutzung zum Arbeiten, mit einer verschlüsselten Partition für das Wurzeldateisystem, einem X11-Display-Server, GNOME und Xfce (Benutzer können im Anmeldebildschirm auswählen, welche dieser Arbeitsumgebungen sie möchten, indem sie die Taste @kbd{F1} drücken), Netzwerkverwaltung, Verwaltungswerkzeugen für den Energieverbrauch, und Weiteres, würde so aussehen: @lisp @include os-config-desktop.texi @end lisp Ein grafisches System mit einer Auswahl an leichtgewichtigen Fenster-Managern statt voll ausgestatteten Arbeitsumgebungen würde so aussehen: @lisp @include os-config-lightweight-desktop.texi @end lisp Dieses Beispiel bezieht sich auf das Dateisystem hinter @file{/boot/efi} über dessen UUID, @code{1234-ABCD}. Schreiben Sie statt dieser UUID die richtige UUID für Ihr System, wie sie der Befehl @command{blkid} liefert. Im Abschnitt @ref{Desktop-Dienste} finden Sie eine genaue Liste der unter @var{%desktop-services} angebotenen Dienste. Der Abschnitt @ref{X.509-Zertifikate} hat Hintergrundinformationen über das @code{nss-certs}-Paket, das hier benutzt wird. Beachten Sie, dass @var{%desktop-services} nur eine Liste von die Dienste repräsentierenden service-Objekten ist. Wenn Sie Dienste daraus entfernen möchten, können Sie dazu die Prozeduren zum Filtern von Listen benutzen (siehe @ref{SRFI-1 Filtering and Partitioning,,, guile, GNU Guile Reference Manual}). Beispielsweise liefert der folgende Ausdruck eine Liste mit allen Diensten von @var{%desktop-services} außer dem Avahi-Dienst. @example (remove (lambda (service) (eq? (service-kind service) avahi-service-type)) %desktop-services) @end example @unnumberedsubsec Das System instanziieren Angenommen, Sie haben die @code{operating-system}-Deklaration in einer Datei @file{my-system-config.scm} gespeichert, dann instanziiert der Befehl @command{guix system reconfigure my-system-config.scm} diese Konfiguration und macht sie zum voreingestellten GRUB-Boot-Eintrag (siehe @ref{Aufruf von guix system}). Der normale Weg, die Systemkonfiguration nachträglich zu ändern, ist, die Datei zu aktualisieren und @command{guix system reconfigure} erneut auszuführen. Man sollte nie die Dateien in @file{/etc} bearbeiten oder den Systemzustand mit Befehlen wie @command{useradd} oder @command{grub-install} verändern. Tatsächlich müssen Sie das ausdrücklich vermeiden, sonst verfällt nicht nur Ihre Garantie, sondern Sie können Ihr System auch nicht mehr auf eine alte Version des Systems zurücksetzen, falls das jemals notwendig wird. @cindex Zurücksetzen, des Betriebssystems Zurücksetzen bezieht sich hierbei darauf, dass jedes Mal, wenn Sie @command{guix system reconfigure} ausführen, eine neue @dfn{Generation} des Systems erzeugt wird — ohne vorherige Generationen zu verändern. Alte Systemgenerationen bekommen einen Eintrag im Boot-Menü des Bootloaders, womit Sie alte Generationen beim Starten des Rechners auswählen können, wenn mit der neuesten Generation etwas nicht stimmt. Eine beruhigende Vorstellung, oder? Der Befehl @command{guix system list-generations} führt die auf der Platte verfügbaren Systemgenerationen auf. Es ist auch möglich, das System mit den Befehlen @command{guix system roll-back} und @command{guix system switch-generation} zurückzusetzen. Obwohl der Befehl @command{guix system reconfigure} vorherige Generationen nicht verändern wird, müssen Sie Acht geben, dass wenn die momentan aktuelle Generation nicht die neueste ist (z.B.@: nach einem Aufruf von @command{guix system roll-back}), weil @command{guix system reconfigure} alle neueren Generationen überschreibt (siehe @ref{Aufruf von guix system}). @unnumberedsubsec Die Programmierschnittstelle Auf der Ebene von Scheme wird der Großteil der @code{operating-system}-Deklaration mit der folgenden monadischen Prozedur instanziiert (siehe @ref{Die Store-Monade}): @deffn {Monadische Prozedur} operating-system-derivation os Liefert eine Ableitung, mit der ein @code{operating-system}-Objekt @var{os} erstellt wird (siehe @ref{Ableitungen}). Die Ausgabe der Ableitung ist ein einzelnes Verzeichnis mit Verweisen auf alle Pakete, Konfigurationsdateien und andere unterstützenden Dateien, die nötig sind, um @var{os} zu instanziieren. @end deffn Diese Prozedur wird vom Modul @code{(gnu system)} angeboten. Zusammen mit @code{(gnu services)} (siehe @ref{Dienste}) deckt dieses Modul den Kern von »Guix System« ab. Schauen Sie es sich mal an! @node »operating-system«-Referenz @section @code{operating-system}-Referenz Dieser Abschnitt fasst alle Optionen zusammen, die für @code{operating-system}-Deklarationen zur Verfügung stehen (siehe @ref{Das Konfigurationssystem nutzen}). @deftp {Datentyp} operating-system Der die Betriebssystemkonfiguration repräsentierende Datentyp. Damit meinen wir die globale Konfiguration des Systems und nicht die, die sich nur auf einzelne Nutzer bezieht (siehe @ref{Das Konfigurationssystem nutzen}). @table @asis @item @code{kernel} (Vorgabe: @var{linux-libre}) Das Paket für den zu nutzenden Betriebssystem-Kernel als »package«-Objekt@footnote{Derzeit wird nur der Kernel Linux-libre unterstützt. In der Zukunft wird man auch GNU@tie{}Hurd benutzen können.}. @item @code{kernel-arguments} (Vorgabe: @code{'()}) Eine Liste aus Zeichenketten oder G-Ausdrücken, die für zusätzliche Argumente an den Kernel stehen, die ihm auf seiner Befehlszeile übergeben werden — wie z.B.@: @code{("console=ttyS0")}. @item @code{bootloader} Das Konfigurationsobjekt für den Bootloader, mit dem das System gestartet wird. Siehe @ref{Bootloader-Konfiguration}. @item @code{label} This is the label (a string) as it appears in the bootloader's menu entry. The default label includes the kernel name and version. @item @code{keyboard-layout} (Vorgabe: @code{#f}) Dieses Feld gibt an, welche Tastaturbelegung auf der Konsole benutzt werden soll. Es kann entweder auf @code{#f} gesetzt sein, damit die voreingestellte Tastaturbelegung benutzt wird (in der Regel ist diese »US English«), oder ein @code{}-Verbundsobjekt sein. Diese Tastaturbelegung wird benutzt, sobald der Kernel gebootet wurde. Diese Tastaturbelegung wird zum Beispiel auch verwendet, wenn Sie eine Passphrase eintippen, falls sich Ihr Wurzeldateisystem auf einem mit @code{luks-device-mapping} zugeordneten Gerät befindet (siehe @ref{Zugeordnete Geräte}). @quotation Anmerkung Damit wird @emph{nicht} angegeben, welche Tastaturbelegung der Bootloader benutzt, und auch nicht, welche der grafische Display-Server verwendet. Siehe @ref{Bootloader-Konfiguration} für Informationen darüber, wie Sie die Tastaturbelegung des Bootloaders angeben können. Siehe @ref{X Window} für Informationen darüber, wie Sie die Tastaturbelegung angeben können, die das X-Fenstersystem verwendet. @end quotation @item @code{initrd-modules} (Vorgabe: @code{%base-initrd-modules}) @cindex initrd @cindex initiale RAM-Disk Die Liste der Linux-Kernel-Module, die in der initialen RAM-Disk zur Verfügung stehen sollen. Siehe @ref{Initiale RAM-Disk}. @item @code{initrd} (Vorgabe: @code{base-initrd}) Eine Prozedur, die eine initiale RAM-Disk für den Linux-Kernel liefert. Dieses Feld gibt es, damit auch sehr systemnahe Anpassungen vorgenommen werden können, aber für die normale Nutzung sollte man es kaum brauchen. Siehe @ref{Initiale RAM-Disk}. @item @code{firmware} (Vorgabe: @var{%base-firmware}) @cindex Firmware Eine Liste der Firmware-Pakete, die vom Betriebssystem-Kernel geladen werden können. Vorgegeben ist, dass für Atheros- und Broadcom-basierte WLAN-Geräte nötige Firmware geladen werden kann (genauer jeweils die Linux-libre-Module @code{ath9k} und @code{b43-open}). Siehe den Abschnitt @ref{Hardware-Überlegungen} für mehr Informationen zu unterstützter Hardware. @item @code{host-name} Der Hostname @item @code{hosts-file} @cindex hosts-Datei Ein dateiartiges Objekt (siehe @ref{G-Ausdrücke, file-like objects}), das für @file{/etc/hosts} benutzt werden soll (siehe @ref{Host Names,,, libc, The GNU C Library Reference Manual}). Der Vorgabewert ist eine Datei mit Einträgen für @code{localhost} und @var{host-name}. @item @code{mapped-devices} (Vorgabe: @code{'()}) Eine Liste zugeordneter Geräte (»mapped devices«). Siehe @ref{Zugeordnete Geräte}. @item @code{file-systems} Eine Liste von Dateisystemen. Siehe @ref{Dateisysteme}. @item @code{swap-devices} (Vorgabe: @code{'()}) @cindex Swap-Geräte Eine Liste von Zeichenketten, die Geräte identifizieren oder als »Swap-Speicher« genutzte Dateien identifizieren (siehe @ref{Memory Concepts,,, libc, The GNU C Library Reference Manual}). Beispiele wären etwa @code{'("/dev/sda3")} oder @code{'("/swapdatei")}. Es ist möglich, eine Swap-Datei auf dem Dateisystem eines zugeordneten Geräts anzugeben, sofern auch die Gerätezuordnung und das Dateisystem mit angegeben werden. Siehe @ref{Zugeordnete Geräte} und @ref{Dateisysteme}. @item @code{users} (Vorgabe: @code{%base-user-accounts}) @itemx @code{groups} (Vorgabe: @var{%base-groups}) Liste der Benutzerkonten und Benutzergruppen. Siehe @ref{Benutzerkonten}. Wenn in der @code{users}-Liste kein Benutzerkonto mit der UID-Kennung@tie{}0 aufgeführt wird, wird automatisch für den Administrator ein »root«-Benutzerkonto mit UID-Kennung@tie{}0 hinzugefügt. @item @code{skeletons} (Vorgabe: @code{(default-skeletons)}) Eine Liste von Tupeln aus je einem Ziel-Dateinamen und einem dateiähnlichen Objekt (siehe @ref{G-Ausdrücke, file-like objects}). Diese Objekte werden als Skeleton-Dateien im Persönlichen Verzeichnis (»Home«-Verzeichnis) jedes neuen Benutzerkontos angelegt. Ein gültiger Wert könnte zum Beispiel so aussehen: @example `((".bashrc" ,(plain-file "bashrc" "echo Hallo\n")) (".guile" ,(plain-file "guile" "(use-modules (ice-9 readline)) (activate-readline)"))) @end example @item @code{issue} (Vorgabe: @var{%default-issue}) Eine Zeichenkette, die als Inhalt der Datei @file{/etc/issue} verwendet werden soll, der jedes Mal angezeigt wird, wenn sich ein Nutzer auf einer Textkonsole anmeldet. @item @code{packages} (Vorgabe: @var{%base-packages}) Die Menge der Pakete, die ins globale Profil installiert werden sollen, welches unter @file{/run/current-system/profile} zu finden ist. Die vorgegebene Paketmenge umfasst zum Kern des Systems gehörende Werkzeuge (»core utilities«). Es ist empfehlenswert, nicht zum Kern gehörende Werkzeuge (»non-core«) stattdessen in Nutzerprofile zu installieren (siehe @ref{Aufruf von guix package}). @item @code{timezone} Eine Zeichenkette, die die Zeitzone bezeichnet, wie z.B.@: @code{"Europe/Berlin"}. Mit dem Befehl @command{tzselect} können Sie herausfinden, welche Zeichenkette der Zeitzone Ihrer Region entspricht. Wenn Sie eine ungültige Zeichenkette angeben, schlägt @command{guix system} fehl. @item @code{locale} (Vorgabe: @code{"en_US.utf8"}) Der Name der als Voreinstellung zu verwendenden Locale (siehe @ref{Locale Names,,, libc, The GNU C Library Reference Manual}). Siehe @ref{Locales} für weitere Informationen. @item @code{locale-definitions} (Vorgabe: @var{%default-locale-definitions}) Die Liste der Locale-Definitionen, die kompiliert werden sollen und dann im laufenden System benutzt werden können. Siehe @ref{Locales}. @item @code{locale-libcs} (Vorgabe: @code{(list @var{glibc})}) Die Liste der GNU-libc-Pakete, deren Locale-Daten und -Werkzeuge zum Erzeugen der Locale-Definitionen verwendet werden sollen. Siehe @ref{Locales} für eine Erläuterung der Kompatibilitätsauswirkungen, deretwegen man diese Option benutzen wollen könnte. @item @code{name-service-switch} (Vorgabe: @var{%default-nss}) Die Konfiguration des Name Service Switch (NSS) der libc — ein @code{}-Objekt. Siehe @ref{Name Service Switch} für Details. @item @code{services} (Vorgabe: @var{%base-services}) Eine Liste von »service«-Objekten, die die Systemdienste repräsentieren. Siehe @ref{Dienste}. @cindex essenzielle Dienste @item @code{essential-services} (Vorgabe: …) The list of ``essential services''---i.e., things like instances of @code{system-service-type} and @code{host-name-service-type} (@pxref{Service-Referenz}), which are derived from the operating system definition itself. As a user you should @emph{never} need to touch this field. @item @code{pam-services} (Vorgabe: @code{(base-pam-services)}) @cindex PAM @cindex Pluggable Authentication Modules @c FIXME: Add xref to PAM services section. Dienste für @dfn{Pluggable Authentication Modules} (PAM) von Linux. @item @code{setuid-programs} (Vorgabe: @var{%setuid-programs}) Eine Liste von Zeichenketten liefernden G-Ausdrücken, die setuid-Programme bezeichnen. Siehe @ref{Setuid-Programme}. @item @code{sudoers-file} (Vorgabe: @var{%sudoers-specification}) @cindex sudoers-Datei Der Inhalt der Datei @file{/etc/sudoers} als ein dateiähnliches Objekt (siehe @ref{G-Ausdrücke, @code{local-file} und @code{plain-file}}). Diese Datei gibt an, welche Nutzer den Befehl @command{sudo} benutzen dürfen, was sie damit tun und welche Berechtigungen sie so erhalten können. Die Vorgabe ist, dass nur der Administratornutzer @code{root} und Mitglieder der Benutzergruppe @code{wheel} den @code{sudo}-Befehl verwenden dürfen. @end table @deffn {Scheme Syntax} this-operating-system When used in the @emph{lexical scope} of an operating system field definition, this identifier resolves to the operating system being defined. The example below shows how to refer to the operating system being defined in the definition of the @code{label} field: @example (use-modules (gnu) (guix)) (operating-system ;; ... (label (package-full-name (operating-system-kernel this-operating-system)))) @end example It is an error to refer to @code{this-operating-system} outside an operating system definition. @end deffn @end deftp @node Dateisysteme @section Dateisysteme Die Liste der Dateisysteme, die eingebunden werden sollen, steht im @code{file-systems}-Feld der Betriebssystemdeklaration (siehe @ref{Das Konfigurationssystem nutzen}). Jedes Dateisystem wird mit der @code{file-system}-Form deklariert, etwa so: @example (file-system (mount-point "/home") (device "/dev/sda3") (type "ext4")) @end example Wie immer müssen manche Felder angegeben werden — die, die im Beispiel oben stehen —, während andere optional sind. Die Felder werden nun beschrieben. @deftp {Datentyp} file-system Objekte dieses Typs repräsentieren einzubindende Dateisysteme. Sie weisen folgende Komponenten auf: @table @asis @item @code{type} Eine Zeichenkette, die den Typ des Dateisystems spezifiziert, z.B.@: @code{"ext4"}. @item @code{mount-point} Der Einhängepunkt, d.h.@: der Pfad, an dem das Dateisystem eingebunden werden soll. @item @code{device} Hiermit wird die »Quelle« des Dateisystems bezeichnet. Sie kann eines von drei Dingen sein: die Bezeichnung (»Labels«) eines Dateisystems, die UUID-Kennung des Dateisystems oder der Name eines @file{/dev}-Knotens. Mit Bezeichnungen und UUIDs kann man Dateisysteme benennen, ohne den Gerätenamen festzuschreiben@footnote{Beachten Sie: Obwohl es verführerisch ist, mit @file{/dev/disk/by-uuid} und ähnlichen Gerätenamen dasselbe Resultat bekommen zu wollen, raten wir davon ab: Diese speziellen Gerätenamen werden erst vom udev-Daemon erzeugt und sind, wenn die Geräte eingebunden werden, vielleicht noch nicht verfügbar.}. @findex file-system-label Dateisystem-Bezeichnungen (»Labels«) werden mit der Prozedur @code{file-system-label} erzeugt und UUID-Kennungen werden mit @code{uuid} erzeugt, während Knoten in @file{/dev} mit ihrem Pfad als einfache Zeichenketten aufgeführt werden. Hier ist ein Beispiel, wie wir ein Dateisystem anhand seiner Bezeichnung aufführen, wie sie vom Befehl @command{e2label} angezeigt wird: @example (file-system (mount-point "/home") (type "ext4") (device (file-system-label "my-home"))) @end example @findex uuid UUID-Kennungen werden mit der @code{uuid}-Form von ihrer Darstellung als Zeichenkette (wie sie vom Befehl @command{tune2fs -l} angezeigt wird) konvertiert@footnote{Die @code{uuid}-Form nimmt 16-Byte-UUIDs entgegen, wie sie in @uref{https://tools.ietf.org/html/rfc4122, RFC@tie{}4122} definiert sind. Diese Form der UUID wird unter anderem von der ext2-Familie von Dateisystemen verwendet, sie unterscheidet sich jedoch zum Beispiel von den »UUID« genannten Kennungen, wie man sie bei FAT-Dateisystemen findet.} wie hier: @example (file-system (mount-point "/home") (type "ext4") (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb"))) @end example Wenn die Quelle eines Dateisystems ein zugeordnetes Gerät (siehe @ref{Zugeordnete Geräte}) ist, @emph{muss} sich das @code{device}-Feld auf den zugeordneten Gerätenamen beziehen — z.B.@: @file{"/dev/mapper/root-partition"}. Das ist nötig, damit das System weiß, dass das Einbinden des Dateisystems davon abhängt, die entsprechende Gerätezuordnung hergestellt zu haben. @item @code{flags} (Vorgabe: @code{'()}) Eine Liste von Symbolen, die Einbinde-Flags (»mount flags«) bezeichnen. Erkannt werden unter anderem @code{read-only}, @code{bind-mount}, @code{no-dev} (Zugang zu besonderen Dateien verweigern), @code{no-suid} (setuid- und setgid-Bits ignorieren) und @code{no-exec} (Programmausführungen verweigern). @item @code{options} (Vorgabe: @code{#f}) Entweder @code{#f} oder eine Zeichenkette mit Einbinde-Optionen (»mount options«). @item @code{mount?} (Vorgabe: @code{#t}) Dieser Wert zeigt an, ob das Dateisystem automatisch eingebunden werden soll, wenn das System gestartet wird. Ist der Wert @code{#f}, dann erhält das Dateisystem nur einen Eintrag in der Datei @file{/etc/fstab} (welche vom @command{mount}-Befehl zum Einbinden gelesen wird), es wird aber nicht automatisch eingebunden. @item @code{needed-for-boot?} (Vorgabe: @code{#f}) Dieser boolesche Wert gibt an, ob das Dateisystem zum Hochfahren des Systems notwendig ist. In diesem Fall wird das Dateisystem eingebunden, wenn die initiale RAM-Disk (initrd) geladen wird. Für zum Beispiel das Wurzeldateisystem ist dies ohnehin immer der Fall. @item @code{check?} (Vorgabe: @code{#t}) Dieser boolesche Wert sagt aus, ob das Dateisystem vor dem Einbinden auf Fehler hin geprüft werden soll. @item @code{create-mount-point?} (Vorgabe: @code{#f}) Steht dies auf wahr, wird der Einhängepunkt vor dem Einbinden erstellt, wenn er noch nicht existiert. @item @code{dependencies} (Vorgabe: @code{'()}) Dies ist eine Liste von @code{}- oder @code{}-Objekten, die Dateisysteme repräsentieren, die vor diesem Dateisystem eingebunden oder zugeordnet werden müssen (und nach diesem ausgehängt oder geschlossen werden müssen). Betrachten Sie zum Beispiel eine Hierarchie von Einbindungen: @file{/sys/fs/cgroup} ist eine Abhängigkeit von @file{/sys/fs/cgroup/cpu} und @file{/sys/fs/cgroup/memory}. Ein weiteres Beispiel ist ein Dateisystem, was von einem zugeordneten Gerät abhängt, zum Beispiel zur Verschlüsselung einer Partition (siehe @ref{Zugeordnete Geräte}). @end table @end deftp Das Modul @code{(gnu system file-systems)} exportiert die folgenden nützlichen Variablen. @defvr {Scheme-Variable} %base-file-systems Hiermit werden essenzielle Dateisysteme bezeichnet, die für normale Systeme unverzichtbar sind, wie zum Beispiel @var{%pseudo-terminal-file-system} und @var{%immutable-store} (siehe unten). Betriebssystemdeklaration sollten auf jeden Fall mindestens diese enthalten. @end defvr @defvr {Scheme-Variable} %pseudo-terminal-file-system Das als @file{/dev/pts} einzubindende Dateisystem. Es unterstützt über @code{openpty} und ähnliche Funktionen erstellte @dfn{Pseudo-Terminals} (siehe @ref{Pseudo-Terminals,,, libc, The GNU C Library Reference Manual}). Pseudo-Terminals werden von Terminal-Emulatoren wie @command{xterm} benutzt. @end defvr @defvr {Scheme-Variable} %shared-memory-file-system Dieses Dateisystem wird als @file{/dev/shm} eingebunden, um Speicher zwischen Prozessen teilen zu können (siehe @ref{Memory-mapped I/O, @code{shm_open},, libc, The GNU C Library Reference Manual}). @end defvr @defvr {Scheme-Variable} %immutable-store Dieses Dateisystem vollzieht einen »bind mount« des @file{/gnu/store}, um ihn für alle Nutzer einschließlich des Administratornutzers @code{root} nur lesbar zu machen, d.h.@: Schreibrechte zu entziehen. Dadurch kann als @code{root} ausgeführte Software, oder der Systemadministrator, nicht aus Versehen den Store modifizieren. Der Daemon kann weiterhin in den Store schreiben, indem er ihn selbst mit Schreibrechten in seinem eigenen »Namensraum« einbindet. @end defvr @defvr {Scheme-Variable} %binary-format-file-system Das @code{binfmt_misc}-Dateisystem, durch das beliebige Dateitypen als ausführbare Dateien auf der Anwendungsebene (dem User Space) zugänglich gemacht werden können. Es setzt voraus, dass das Kernel-Modul @code{binfmt.ko} geladen wurde. @end defvr @defvr {Scheme-Variable} %fuse-control-file-system Das @code{fusectl}-Dateisystem, womit »unprivilegierte« Nutzer ohne besondere Berechtigungen im User Space FUSE-Dateisysteme einbinden und aushängen können. Dazu muss das Kernel-Modul @code{fuse.ko} geladen sein. @end defvr @node Zugeordnete Geräte @section Zugeordnete Geräte @cindex Gerätezuordnung @cindex zugeordnete Geräte Der Linux-Kernel unterstützt das Konzept der @dfn{Gerätezuordnung}: Ein blockorientiertes Gerät wie eine Festplattenpartition kann einem neuen Gerät @dfn{zugeordnet} werden, gewöhnlich unter @code{/dev/mapper/}, wobei das neue Gerät durchlaufende Daten zusätzlicher Verarbeitung unterzogen werden@footnote{Beachten Sie, dass mit GNU@tie{}Hurd kein Unterschied zwischen dem Konzept eines »zugeordneten Geräts« und dem eines Dateisystems besteht: Dort werden bei beiden Ein- und Ausgabeoperationen auf eine Datei in Operationen auf dessen Hintergrundspeicher @emph{übersetzt}. Hurd implementiert zugeordnete Geräte genau wie Dateisysteme mit dem generischen @dfn{Übersetzer}-Mechanismus (siehe @ref{Translators,,, hurd, The GNU Hurd Reference Manual}).}. Ein typisches Beispiel ist eine Gerätezuordnung zur Verschlüsselung: Jeder Schreibzugriff auf das zugeordnete Gerät wird transparent verschlüsselt und jeder Lesezugriff ebenso entschlüsselt. Guix erweitert dieses Konzept, indem es darunter jedes Gerät und jede Menge von Geräten versteht, die auf irgendeine Weise @dfn{umgewandelt} wird, um ein neues Gerät zu bilden; zum Beispiel entstehen auch RAID-Geräte aus einem @dfn{Verbund} mehrerer anderer Geräte, wie etwa Festplatten oder Partition zu einem einzelnen Gerät, das sich wie eine Partition verhält. Ein weiteres Beispiel, das noch nicht in Guix implementiert wurde, sind »LVM logical volumes«. Zugeordnete Geräte werden mittels einer @code{mapped-device}-Form deklariert, die wie folgt definiert ist; Beispiele folgen weiter unten. @deftp {Datentyp} mapped-device Objekte dieses Typs repräsentieren Gerätezuordnungen, die gemacht werden, wenn das System hochfährt. @table @code @item source Es handelt sich entweder um eine Zeichenkette, die den Namen eines zuzuordnenden blockorientierten Geräts angibt, wie @code{"/dev/sda3"}, oder um eine Liste solcher Zeichenketten, sofern mehrere Geräts zu einem neuen Gerät verbunden werden. @item target Diese Zeichenkette gibt den Namen des neuen zugeordneten Geräts an. Bei Kernel-Zuordnern, wie verschlüsselten Geräten vom Typ @code{luks-device-mapping}, wird durch Angabe von @code{"my-partition"} ein Gerät @code{"/dev/mapper/my-partition"} erzeugt. Bei RAID-Geräten vom Typ @code{raid-device-mapping} muss der Gerätename als voller Pfad wie zum Beispiel @code{"/dev/md0"} angegeben werden. @item type Dies muss ein @code{mapped-device-kind}-Objekt sein, das angibt, wie die Quelle @var{source} dem Ziel @var{target} zugeordnet wird. @end table @end deftp @defvr {Scheme-Variable} luks-device-mapping Hiermit wird ein blockorientiertes Gerät mit LUKS verschlüsselt, mit Hilfe des Befehls @command{cryptsetup} aus dem gleichnamigen Paket. Dazu wird das Linux-Kernel-Modul @code{dm-crypt} vorausgesetzt. @end defvr @defvr {Scheme-Variable} raid-device-mapping Dies definiert ein RAID-Gerät, das mit dem Befehl @code{mdadm} aus dem gleichnamigen Paket als Verbund zusammengestellt wird. Es setzt voraus, dass das Linux-Kernel-Modul für das entsprechende RAID-Level geladen ist, z.B.@: @code{raid456} für RAID-4, RAID-5 oder RAID-6, oder @code{raid10} für RAID-10. @end defvr @cindex Laufwerksverschlüsselung @cindex LUKS Das folgende Beispiel gibt eine Zuordnung von @file{/dev/sda3} auf @file{/dev/mapper/home} mit LUKS an — dem @url{https://gitlab.com/cryptsetup/cryptsetup,Linux Unified Key Setup}, einem Standardmechanismus zur Plattenverschlüsselung. Das Gerät @file{/dev/mapper/home} kann dann als @code{device} einer @code{file-system}-Deklaration benutzt werden (siehe @ref{Dateisysteme}). @example (mapped-device (source "/dev/sda3") (target "home") (type luks-device-mapping)) @end example Um nicht davon abhängig zu sein, wie Ihre Geräte nummeriert werden, können Sie auch die LUKS-UUID (@dfn{unique identifier}, d.h.@: den eindeutigen Bezeichner) des Quellgeräts auf der Befehlszeile ermitteln: @example cryptsetup luksUUID /dev/sda3 @end example und wie folgt benutzen: @example (mapped-device (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44")) (target "home") (type luks-device-mapping)) @end example @cindex Swap-Verschlüsselung Es ist auch wünschenswert, Swap-Speicher zu verschlüsseln, da in den Swap-Speicher sensible Daten ausgelagert werden können. Eine Möglichkeit ist, eine Swap-Datei auf einem mit LUKS-Verschlüsselung zugeordneten Dateisystem zu verwenden. Dann wird die Swap-Datei verschlüsselt, weil das ganze Gerät verschlüsselt wird. Ein Beispiel finden Sie im Abschnitt @ref{Vor der Installation,,Disk Partitioning}. Ein RAID-Gerät als Verbund der Partitionen @file{/dev/sda1} und @file{/dev/sdb1} kann wie folgt deklariert werden: @example (mapped-device (source (list "/dev/sda1" "/dev/sdb1")) (target "/dev/md0") (type raid-device-mapping)) @end example Das Gerät @file{/dev/md0} kann als @code{device} in einer @code{file-system}-Deklaration dienen (siehe @ref{Dateisysteme}). Beachten Sie, dass das RAID-Level dabei nicht angegeben werden muss; es wird während der initialen Erstellung und Formatierung des RAID-Geräts festgelegt und später automatisch bestimmt. @node Benutzerkonten @section Benutzerkonten @cindex Benutzer @cindex Konten @cindex Benutzerkonten Benutzerkonten und Gruppen werden allein durch die @code{operating-system}-Deklaration des Betriebssystems verwaltet. Sie werden mit den @code{user-account}- und @code{user-group}-Formen angegeben: @example (user-account (name "alice") (group "users") (supplementary-groups '("wheel" ;zur sudo-Nutzung usw. berechtigen "audio" ;Soundkarte "video" ;Videogeräte wie Webcams "cdrom")) ;die gute alte CD-ROM (comment "Bobs Schwester") (home-directory "/home/alice")) @end example Beim Hochfahren oder nach Abschluss von @command{guix system reconfigure} stellt das System sicher, dass nur die in der @code{operating-system}-Deklaration angegebenen Benutzerkonten und Gruppen existieren, mit genau den angegebenen Eigenschaften. Daher gehen durch direkten Aufruf von Befehlen wie @command{useradd} erwirkte Erstellungen oder Modifikationen von Konten oder Gruppen verloren, sobald rekonfiguriert oder neugestartet wird. So wird sichergestellt, dass das System genau so funktioniert, wie es deklariert wurde. @deftp {Datentyp} user-account Objekte dieses Typs repräsentieren Benutzerkonten. Darin können folgende Komponenten aufgeführt werden: @table @asis @item @code{name} Der Name des Benutzerkontos. @item @code{group} @cindex Gruppen Dies ist der Name (als Zeichenkette) oder die Bezeichnung (als Zahl) der Benutzergruppe, zu der dieses Konto gehört. @item @code{supplementary-groups} (Vorgabe: @code{'()}) Dies kann optional als Liste von Gruppennamen angegeben werden, zu denen dieses Konto auch gehört. @item @code{uid} (Vorgabe: @code{#f}) Dies ist entweder der Benutzeridentifikator dieses Kontos (seine »User ID«) als Zahl oder @code{#f}. Bei Letzterem wird vom System automatisch eine Zahl gewählt, wenn das Benutzerkonto erstellt wird. @item @code{comment} (Vorgabe: @code{""}) Ein Kommentar zu dem Konto, wie etwa der vollständige Name des Kontoinhabers. @item @code{home-directory} Der Name des Persönlichen Verzeichnisses (»Home«-Verzeichnis) für dieses Konto. @item @code{create-home-directory?} (Vorgabe: @code{#t}) Zeigt an, ob das Persönliche Verzeichnis für das Konto automatisch erstellt werden soll, falls es noch nicht existiert. @item @code{shell} (Vorgabe: Bash) Ein G-Ausdruck, der den Dateinamen des Programms angibt, das dem Benutzer als Shell dienen soll (siehe @ref{G-Ausdrücke}). @item @code{system?} (Vorgabe: @code{#f}) Dieser boolesche Wert zeigt an, ob das Konto ein »System«-Benutzerkonto ist. Systemkonten werden manchmal anders behandelt, zum Beispiel werden sie auf grafischen Anmeldebildschirmen nicht aufgeführt. @anchor{user-account-password} @cindex Passwort, für Benutzerkonten @item @code{password} (Vorgabe: @code{#f}) Normalerweise lassen Sie dieses Feld auf @code{#f} und initialisieren Benutzerpasswörter als @code{root} mit dem @command{passwd}-Befehl. Die Benutzer lässt man ihr eigenes Passwort dann mit @command{passwd} ändern. Mit @command{passwd} festgelegte Passwörter bleiben natürlich beim Neustarten und beim Rekonfigurieren erhalten. Wenn Sie aber @emph{doch} ein anfängliches Passwort für ein Konto voreinstellen möchten, muss dieses Feld hier das verschlüsselte Passwort als Zeichenkette enthalten. Sie können dazu die Prozedur @code{crypt} benutzen. @example (user-account (name "charlie") (group "users") ;; Specify a SHA-512-hashed initial password. (password (crypt "InitialPassword!" "$6$abc"))) @end example @quotation Anmerkung The hash of this initial password will be available in a file in @file{/gnu/store}, readable by all the users, so this method must be used with care. @end quotation Siehe @ref{Passphrase Storage,,, libc, The GNU C Library Reference Manual} für weitere Informationen über Passwortverschlüsselung und @ref{Encryption,,, guile, GNU Guile Reference Manual} für Informationen über die Prozedur @code{crypt} in Guile. @end table @end deftp @cindex Gruppen Benutzergruppen-Deklarationen sind noch einfacher aufgebaut: @example (user-group (name "students")) @end example @deftp {Datentyp} user-group Dieser Typ gibt, nun ja, eine Benutzergruppe an. Es gibt darin nur ein paar Felder: @table @asis @item @code{name} Der Name der Gruppe. @item @code{id} (Vorgabe: @code{#f}) Der Gruppenbezeichner (eine Zahl). Wird er als @code{#f} angegeben, wird automatisch eine neue Zahl reserviert, wenn die Gruppe erstellt wird. @item @code{system?} (Vorgabe: @code{#f}) Dieser boolesche Wert gibt an, ob es sich um eine »System«-Gruppe handelt. Systemgruppen sind solche mit einer kleinen Zahl als Bezeichner. @item @code{password} (Vorgabe: @code{#f}) Wie, Benutzergruppen können ein Passwort haben? Nun ja, anscheinend schon. Wenn es nicht auf @code{#f} steht, gibt dieses Feld das Passwort der Gruppe an. @end table @end deftp Um Ihnen das Leben zu erleichtern, gibt es eine Variable, worin alle grundlegenden Benutzergruppen aufgeführt sind, die man erwarten könnte: @defvr {Scheme-Variable} %base-groups Die Liste von Basis-Benutzergruppen, von denen Benutzer und/oder Pakete erwarten könnten, dass sie auf dem System existieren. Dazu gehören Gruppen wie »root«, »wheel« und »users«, sowie Gruppen, um den Zugriff auf bestimmte Geräte einzuschränken, wie »audio«, »disk« und »cdrom«. @end defvr @defvr {Scheme-Variable} %base-user-accounts Diese Liste enthält Basis-Systembenutzerkonten, von denen Programme erwarten können, dass sie auf einem GNU/Linux-System existieren, wie das Konto »nobody«. Beachten Sie, dass das Konto »root« für den Administratornutzer nicht dazugehört. Es ist ein Sonderfall und wird automatisch erzeugt, egal ob es spezifiziert wurde oder nicht. @end defvr @node Tastaturbelegung @section Tastaturbelegung @cindex Tastaturbelegung @cindex Keymap To specify what each key of your keyboard does, you need to tell the operating system what @dfn{keyboard layout} you want to use. The default, when nothing is specified, is the US English QWERTY layout for 105-key PC keyboards. However, German speakers will usually prefer the German QWERTZ layout, French speakers will want the AZERTY layout, and so on; hackers might prefer Dvorak or bépo, and they might even want to further customize the effect of some of the keys. This section explains how to get that done. @cindex Tastaturbelegung, Definition There are three components that will want to know about your keyboard layout: @itemize @item The @emph{bootloader} may want to know what keyboard layout you want to use (@pxref{Bootloader-Konfiguration, @code{keyboard-layout}}). This is useful if you want, for instance, to make sure that you can type the passphrase of your encrypted root partition using the right layout. @item The @emph{operating system kernel}, Linux, will need that so that the console is properly configured (@pxref{»operating-system«-Referenz, @code{keyboard-layout}}). @item The @emph{graphical display server}, usually Xorg, also has its own idea of the keyboard layout (@pxref{X Window, @code{keyboard-layout}}). @end itemize Guix allows you to configure all three separately but, fortunately, it allows you to share the same keyboard layout for all three components. @cindex XKB, Tastaturbelegungen Keyboard layouts are represented by records created by the @code{keyboard-layout} procedure of @code{(gnu system keyboard)}. Following the X Keyboard extension (XKB), each layout has four attributes: a name (often a language code such as ``fi'' for Finnish or ``jp'' for Japanese), an optional variant name, an optional keyboard model name, and a possibly empty list of additional options. In most cases the layout name is all you care about. Here are a few example: @example ;; The German QWERTZ layout. Here we assume a standard ;; "pc105" keyboard model. (keyboard-layout "de") ;; The bépo variant of the French layout. (keyboard-layout "fr" "bepo") ;; The Catalan layout. (keyboard-layout "es" "cat") ;; The Latin American Spanish layout. In addition, the ;; "Caps Lock" key is used as an additional "Ctrl" key, ;; and the "Menu" key is used as a "Compose" key to enter ;; accented letters. (keyboard-layout "latam" #:options '("ctrl:nocaps" "compose:menu")) ;; The Russian layout for a ThinkPad keyboard. (keyboard-layout "ru" #:model "thinkpad") ;; The "US international" layout, which is the US layout plus ;; dead keys to enter accented characters. This is for an ;; Apple MacBook keyboard. (keyboard-layout "us" "intl" #:model "macbook78") @end example See the @file{share/X11/xkb} directory of the @code{xkeyboard-config} package for a complete list of supported layouts, variants, and models. @cindex Tastaturbelegung, Konfiguration Let's say you want your system to use the Turkish keyboard layout throughout your system---bootloader, console, and Xorg. Here's what your system configuration would look like: @findex set-xorg-configuration @lisp ;; Using the Turkish layout for the bootloader, the console, ;; and for Xorg. (operating-system ;; ... (keyboard-layout (keyboard-layout "tr")) ;for the console (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi") (keyboard-layout keyboard-layout))) ;for GRUB (services (cons (set-xorg-configuration (xorg-configuration ;for Xorg (keyboard-layout keyboard-layout))) %desktop-services))) @end lisp In the example above, for GRUB and for Xorg, we just refer to the @code{keyboard-layout} field defined above, but we could just as well refer to a different layout. The @code{set-xorg-configuration} procedure communicates the desired Xorg configuration to the graphical log-in manager, by default GDM. We've discussed how to specify the @emph{default} keyboard layout of your system when it starts, but you can also adjust it at run time: @itemize @item If you're using GNOME, its settings panel has a ``Region & Language'' entry where you can select one or more keyboard layouts. @item Under Xorg, the @command{setxkbmap} command (from the same-named package) allows you to change the current layout. For example, this is how you would change the layout to US Dvorak: @example setxkbmap us dvorak @end example @item The @code{loadkeys} command changes the keyboard layout in effect in the Linux console. However, note that @code{loadkeys} does @emph{not} use the XKB keyboard layout categorization described above. The command below loads the French bépo layout: @example loadkeys fr-bepo @end example @end itemize @node Locales @section Locales @cindex Locale Eine @dfn{Locale} legt die kulturellen Konventionen einer bestimmten Sprache und Region auf der Welt fest (siehe @ref{Locales,,, libc, The GNU C Library Reference Manual}). Jede Locale hat einen Namen, der typischerweise von der Form @code{@var{Sprache}_@var{Gebiet}.@var{Kodierung}} — z.B.@: benennt @code{fr_LU.utf8} die Locale für französische Sprache mit den kulturellen Konventionen aus Luxemburg unter Verwendung der UTF-8-Kodierung. @cindex Locale-Definition Normalerweise werden Sie eine standardmäßig zu verwendende Locale für die Maschine vorgeben wollen, indem Sie das @code{locale}-Feld der @code{operating-system}-Deklaration verwenden (siehe @ref{»operating-system«-Referenz, @code{locale}}). Die ausgewählte Locale wird automatisch zu den dem System bekannten @dfn{Locale-Definitionen} hinzugefügt, falls nötig, und ihre Kodierung wird aus dem Namen hergeleitet — z.B.@: wird angenommen, dass @code{bo_CN.utf8} als Kodierung @code{UTF-8} verwendet. Zusätzliche Locale-Definitionen können im Feld @code{locale-definitions} vom @code{operating-system} festgelegt werden — das ist zum Beispiel dann nützlich, wenn die Kodierung nicht aus dem Locale-Namen hergeleitet werden konnte. Die vorgegebene Menge an Locale-Definitionen enthält manche weit verbreiteten Locales, aber um Platz zu sparen, nicht alle verfügbaren Locales. Um zum Beispiel die nordfriesische Locale für Deutschland hinzuzufügen, könnte der Wert des Feldes wie folgt aussehen: @example (cons (locale-definition (name "fy_DE.utf8") (source "fy_DE")) %default-locale-definitions) @end example Um Platz zu sparen, könnte man auch wollen, dass @code{locale-definitions} nur die tatsächlich benutzen Locales aufführt, wie etwa: @example (list (locale-definition (name "ja_JP.eucjp") (source "ja_JP") (charset "EUC-JP"))) @end example @vindex LOCPATH Die kompilierten Locale-Definitionen sind unter @file{/run/current-system/locale/X.Y} verfügbar, wobei @code{X.Y} die Version von libc bezeichnet. Dies entspricht dem Pfad, an dem eine von Guix ausgelieferte GNU@tie{}libc standardmäßig nach Locale-Daten sucht. Er kann überschrieben werden durch die Umgebungsvariable @code{LOCPATH} (siehe @ref{locales-and-locpath, @code{LOCPATH} und Locale-Pakete}). Die @code{locale-definition}-Form wird vom Modul @code{(gnu system locale)} zur Verfügung gestellt. Details folgen unten. @deftp {Datentyp} locale-definition Dies ist der Datentyp einer Locale-Definition. @table @asis @item @code{name} Der Name der Locale. Siehe @ref{Locale Names,,, libc, The GNU C Library Reference Manual} für mehr Informationen zu Locale-Namen. @item @code{source} Der Name der Quelle der Locale. Typischerweise ist das der Teil @code{@var{Sprache}_@var{Gebiet}} des Locale-Namens. @item @code{charset} (Vorgabe: @code{"UTF-8"}) Der »Zeichensatz« oder das »Code set«, d.h.@: die Kodierung dieser Locale, @uref{http://www.iana.org/assignments/character-sets, wie die IANA sie definiert}. @end table @end deftp @defvr {Scheme-Variable} %default-locale-definitions Eine Liste häufig benutzter UTF-8-Locales, die als Vorgabewert des @code{locale-definitions}-Feldes in @code{operating-system}-Deklarationen benutzt wird. @cindex Locale-Name @cindex Normalisiertes Codeset in Locale-Namen Diese Locale-Definitionen benutzen das @dfn{normalisierte Codeset} für den Teil des Namens, der nach dem Punkt steht (siehe @ref{Using gettextized software, normalized codeset,, libc, The GNU C Library Reference Manual}). Zum Beispiel ist @code{uk_UA.utf8} enthalten, dagegen ist etwa @code{uk_UA.UTF-8} darin @emph{nicht} enthalten. @end defvr @subsection Kompatibilität der Locale-Daten @cindex Inkompatibilität, von Locale-Daten @code{operating-system}-Deklarationen verfügen über ein @code{locale-libcs}-Feld, um die GNU@tie{}libc-Pakete anzugeben, die zum Kompilieren von Locale-Deklarationen verwendet werden sollen (siehe @ref{»operating-system«-Referenz}). »Was interessiert mich das?«, könnten Sie fragen. Naja, leider ist das binäre Format der Locale-Daten von einer libc-Version auf die nächste manchmal nicht miteinander kompatibel. @c See @c and . Zum Beispiel kann ein mit der libc-Version 2.21 gebundenes Programm keine mit libc 2.22 erzeugten Locale-Daten lesen; schlimmer noch, das Programm @emph{terminiert} statt einfach die inkompatiblen Locale-Daten zu ignorieren@footnote{Versionen 2.23 von GNU@tie{}libc und neuere werden inkompatible Locale-Daten nur mehr überspringen, was schon einmal eine Verbesserung ist.}. Ähnlich kann ein gegen libc 2.22 gebundenes Programm die meisten, aber nicht alle, Locale-Daten von libc 2.21 lesen (Daten zu @code{LC_COLLATE} sind aber zum Beispiel inkompatibel); somit schlagen Aufrufe von @code{setlocale} vielleicht fehl, aber das Programm läuft weiter. Das »Problem« mit Guix ist, dass Nutzer viel Freiheit genießen: Sie können wählen, ob und wann sie die Software in ihren Profilen aktualisieren und benutzen vielleicht eine andere libc-Version als sie der Systemadministrator benutzt hat, um die systemweiten Locale-Daten zu erstellen. Glücklicherweise können »unprivilegierte« Nutzer ohne zusätzliche Berechtigungen dann zumindest ihre eigenen Locale-Daten installieren und @var{GUIX_LOCPATH} entsprechend definieren (siehe @ref{locales-and-locpath, @code{GUIX_LOCPATH} und Locale-Pakete}). Trotzdem ist es am besten, wenn die systemweiten Locale-Daten unter @file{/run/current-system/locale} für alle libc-Versionen erstellt werden, die auf dem System noch benutzt werden, damit alle Programme auf sie zugreifen können — was auf einem Mehrbenutzersystem ganz besonders wichtig ist. Dazu kann der Administrator des Systems mehrere libc-Pakete im @code{locale-libcs}-Feld vom @code{operating-system} angeben: @example (use-package-modules base) (operating-system ;; @dots{} (locale-libcs (list glibc-2.21 (canonical-package glibc)))) @end example Mit diesem Beispiel ergäbe sich ein System, was Locale-Definitionen sowohl für libc 2.21 als auch die aktuelle Version von libc in @file{/run/current-system/locale} hat. @node Dienste @section Dienste @cindex Systemdienste Ein wichtiger Bestandteil des Schreibens einer @code{operating-system}-Deklaration ist das Auflisten der @dfn{Systemdienste} und ihrer Konfiguration (siehe @ref{Das Konfigurationssystem nutzen}). Systemdienste sind typischerweise im Hintergrund laufende Daemon-Programme, die beim Hochfahren des Systems gestartet werden, oder andere Aktionen, die zu dieser Zeit durchgeführt werden müssen — wie das Konfigurieren des Netzwerkzugangs. Guix hat eine weit gefasste Definition, was ein »Dienst« ist (siehe @ref{Dienstkompositionen}), aber viele Dienste sind solche, die von GNU@tie{}Shepherd verwaltet werden (siehe @ref{Shepherd-Dienste}). Auf einem laufenden System kann der @command{herd}-Befehl benutzt werden, um verfügbare Dienste aufzulisten, ihren Status anzuzeigen, sie zu starten und zu stoppen oder andere angebotene Operationen durchzuführen (siehe @ref{Jump Start,,, shepherd, The GNU Shepherd Manual}). Zum Beispiel: @example # herd status @end example Dieser Befehl, durchgeführt als @code{root}, listet die momentan definierten Dienste auf. Der Befehl @command{herd doc} fasst kurz zusammen, was ein gegebener Dienst ist und welche Aktionen mit ihm assoziiert sind: @example # herd doc nscd Run libc's name service cache daemon (nscd). # herd doc nscd action invalidate invalidate: Invalidate the given cache--e.g., 'hosts' for host name lookups. @end example Die Unterbefehle @command{start}, @command{stop} und @command{restart} haben die Wirkung, die man erwarten würde. Zum Beispiel kann mit folgenden Befehlen der nscd-Dienst angehalten und der Xorg-Display-Server neu gestartet werden: @example # herd stop nscd Service nscd has been stopped. # herd restart xorg-server Service xorg-server has been stopped. Service xorg-server has been started. @end example Die folgenden Abschnitte dokumentieren die verfügbaren Dienste, die in einer @code{operating-system}-Deklaration benutzt werden können, angefangen mit den Diensten im Kern des Systems (»core services«) @menu * Basisdienste:: Essenzielle Systemdienste. * Geplante Auftragsausführung:: Der mcron-Dienst. * Log-Rotation:: Der rottlog-Dienst. * Netzwerkdienste:: Netzwerkeinrichtung, SSH-Daemon etc. * X Window:: Grafische Anzeige. * Druckdienste:: Unterstützung für lokale und entfernte Drucker. * Desktop-Dienste:: D-Bus- und Desktop-Dienste. * Tondienste:: Dienste für ALSA und Pulseaudio. * Datenbankdienste:: SQL-Datenbanken, Schlüssel-Wert-Speicher etc. * Mail-Dienste:: IMAP, POP3, SMTP und so weiter. * Kurznachrichtendienste:: Dienste für Kurznachrichten. * Telefondienste:: Telefoniedienste. * Überwachungsdienste:: Dienste zur Systemüberwachung. * Kerberos-Dienste:: Kerberos-Dienste. * LDAP-Dienste:: LDAP-Dienste. * Web-Dienste:: Web-Server. * Zertifikatsdienste:: TLS-Zertifikate via Let’s Encrypt. * DNS-Dienste:: DNS-Daemons. * VPN-Dienste:: VPN-Daemons. * Network File System:: Dienste mit Bezug zum Netzwerkdateisystem. * Kontinuierliche Integration:: Der Cuirass-Dienst. * Dienste zur Stromverbrauchsverwaltung:: Den Akku schonen. * Audio-Dienste:: Der MPD. * Virtualisierungsdienste:: Dienste für virtuelle Maschinen. * Versionskontrolldienste:: Entfernten Zugang zu Git-Repositorys bieten. * Spieldienste:: Spielserver. * Verschiedene Dienste:: Andere Dienste. @end menu @node Basisdienste @subsection Basisdienste Das Modul @code{(gnu services base)} stellt Definitionen für Basis-Dienste zur Verfügung, von denen man erwartet, dass das System sie anbietet. Im Folgenden sind die von diesem Modul exportierten Dienste aufgeführt. @defvr {Scheme-Variable} %base-services Diese Variable enthält eine Liste von Basis-Diensten, die man auf einem System vorzufinden erwartet (siehe @ref{Diensttypen und Dienste} für weitere Informationen zu Dienstobjekten): ein Anmeldungsdienst (mingetty) auf jeder Konsole (jedem »tty«), syslogd, den Name Service Cache Daemon (nscd) von libc, die udev-Geräteverwaltung und weitere. Dies ist der Vorgabewert für das @code{services}-Feld für die Dienste von @code{operating-system}-Deklarationen. Normalerweise werden Sie, wenn Sie ein Betriebssystem anpassen, Dienste an die @var{%base-services}-Liste anhängen, wie hier gezeigt: @example (append (list (service avahi-service-type) (service openssh-service-type)) %base-services) @end example @end defvr @defvr {Scheme-Variable} special-files-service-type Dieser Dienst richtet »besondere Dateien« wie @file{/bin/sh} ein; eine Instanz des Dienstes ist Teil der @code{%base-services}. Der mit @code{special-files-service-type}-Diensten assoziierte Wert muss eine Liste von Tupeln sein, deren erstes Element eine »besondere Datei« und deren zweites Element deren Zielpfad ist. Der Vorgabewert ist: @cindex @file{/bin/sh} @cindex @file{sh}, in @file{/bin} @example `(("/bin/sh" ,(file-append @var{bash} "/bin/sh"))) @end example @cindex @file{/usr/bin/env} @cindex @file{env}, in @file{/usr/bin} Wenn Sie zum Beispiel auch @code{/usr/bin/env} zu Ihrem System hinzufügen möchten, können Sie den Wert ändern auf: @example `(("/bin/sh" ,(file-append @var{bash} "/bin/sh")) ("/usr/bin/env" ,(file-append @var{coreutils} "/bin/env"))) @end example Da dieser Dienst Teil der @code{%base-services} ist, können Sie @code{modify-services} benutzen, um die Liste besonderer Dateien abzuändern (siehe @ref{Service-Referenz, @code{modify-services}}). Die leichte Alternative, um eine besondere Datei hinzuzufügen, ist über die Prozedur @code{extra-special-file} (siehe unten). @end defvr @deffn {Scheme-Prozedur} extra-special-file @var{Datei} @var{Ziel} Das @var{Ziel} als »besondere Datei« @var{Datei} verwenden. Beispielsweise können Sie die folgenden Zeilen in das @code{services}-Feld Ihrer Betriebssystemdeklaration einfügen für eine symbolische Verknüpfung @file{/usr/bin/env}: @example (extra-special-file "/usr/bin/env" (file-append coreutils "/bin/env")) @end example @end deffn @deffn {Scheme-Prozedur} host-name-service @var{Name} Liefert einen Dienst, der den Rechnernamen (den »Host«-Namen des Rechners) als @var{Name} festlegt. @end deffn @deffn {Scheme-Prozedur} login-service @var{Konfiguration} Liefert einen Dienst, der die Benutzeranmeldung möglich macht. Dazu verwendet er die angegebene @var{Konfiguration}, ein @code{}-Objekt, das unter anderem die beim Anmelden angezeigte Mitteilung des Tages (englisch »Message of the Day«) festlegt. @end deffn @deftp {Datentyp} login-configuration Dies ist der Datentyp, der die Anmeldekonfiguration repräsentiert. @table @asis @item @code{motd} @cindex Message of the Day Ein dateiartiges Objekt, das die »Message of the Day« enthält. @item @code{allow-empty-passwords?} (Vorgabe: @code{#t}) Leere Passwörter standardmäßig zulassen, damit sich neue Anwender anmelden können, direkt nachdem das Benutzerkonto »root« für den Administrator angelegt wurde. @end table @end deftp @deffn {Scheme-Prozedur} mingetty-service @var{Konfiguration} Liefert einen Dienst, der mingetty nach den Vorgaben der @var{Konfiguration} ausführt, einem @code{}-Objekt, das unter anderem die Konsole (das »tty«) festlegt, auf der mingetty laufen soll. @end deffn @deftp {Datentyp} mingetty-configuration Dieser Datentyp repräsentiert die Konfiguration von Mingetty, der vorgegebenen Implementierung zur Anmeldung auf einer virtuellen Konsole. @table @asis @item @code{tty} Der Name der Konsole, auf der diese Mingetty-Instanz läuft — z.B.@: @code{"tty1"}. @item @code{auto-login} (Vorgabe: @code{#f}) Steht dieses Feld auf wahr, muss es eine Zeichenkette sein, die den Benutzernamen angibt, als der man vom System automatisch angemeldet wird. Ist es @code{#f}, so muss zur Anmeldung ein Benutzername und ein Passwort eingegeben werden. @item @code{login-program} (Vorgabe: @code{#f}) Dies muss entweder @code{#f} sein, dann wird das voreingestellte Anmeldeprogramm benutzt (@command{login} aus dem Shadow-Werkzeugsatz) oder der Name des Anmeldeprogramms als G-Ausdruck. @item @code{login-pause?} (Vorgabe: @code{#f}) Ist es auf @code{#t} gesetzt, sorgt es in Verbindung mit @var{auto-login} dafür, dass der Benutzer eine Taste drücken muss, ehe eine Anmelde-Shell gestartet wird. @item @code{mingetty} (Vorgabe: @var{mingetty}) Welches Mingetty-Paket benutzt werden soll. @end table @end deftp @deffn {Scheme-Prozedur} agetty-service @var{Konfiguration} Liefert einen Dienst, um agetty entsprechend der @var{Konfiguration} auszuführen, welche ein @code{}-Objekt sein muss, das unter anderem festlegt, auf welchem tty es laufen soll. @end deffn @deftp {Datentyp} agetty-configuration Dies ist der Datentyp, der die Konfiguration von agetty repräsentiert, was Anmeldungen auf einer virtuellen oder seriellen Konsole implementiert. Siehe die Handbuchseite @code{agetty(8)} für mehr Informationen. @table @asis @item @code{tty} Der Name der Konsole, auf der diese Instanz von agetty läuft, als Zeichenkette — z.B.@: @code{"ttyS0"}. Dieses Argument ist optional, sein Vorgabewert ist eine vernünftige Wahl unter den seriellen Schnittstellen, auf deren Benutzung der Linux-Kernel eingestellt ist. Hierzu wird, wenn in der Kernel-Befehlszeile ein Wert für eine Option namens @code{agetty.tty} festgelegt wurde, der Gerätename daraus für agetty extrahiert und benutzt. Andernfalls wird agetty, falls auf der Kernel-Befehlszeile eine Option @code{console} mit einem tty vorkommt, den daraus extrahierten Gerätenamen der seriellen Schnittstelle benutzen. In beiden Fällen wird agetty nichts an den anderen Einstellungen für serielle Geräte verändern (Baud-Rate etc.), in der Hoffnung, dass Linux sie auf die korrekten Werte festgelegt hat. @item @code{baud-rate} (Vorgabe: @code{#f}) Eine Zeichenkette, die aus einer kommagetrennten Liste von einer oder mehreren Baud-Raten besteht, absteigend sortiert. @item @code{term} (Vorgabe: @code{#f}) Eine Zeichenkette, die den Wert enthält, der für die Umgebungsvariable @code{TERM} benutzt werden soll. @item @code{eight-bits?} (Vorgabe: @code{#f}) Steht dies auf @code{#t}, wird angenommen, dass das tty 8-Bit-korrekt ist, so dass die Paritätserkennung abgeschaltet wird. @item @code{auto-login} (Vorgabe: @code{#f}) Wird hier ein Anmeldename als eine Zeichenkette übergeben, wird der angegebene Nutzer automatisch angemeldet, ohne nach einem Anmeldenamen oder Passwort zu fragen. @item @code{no-reset?} (Vorgabe: @code{#f}) Steht dies auf @code{#t}, werden die Cflags des Terminals (d.h.@: dessen Steuermodi) nicht zurückgesetzt. @item @code{host} (Vorgabe: @code{#f}) Dies akzeptiert eine Zeichenkette mit dem einzutragenden Anmeldungs-Rechnernamen "login_host", der in die Datei @file{/var/run/utmpx} geschrieben wird. @item @code{remote?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird in Verbindung mit @var{host} eine Befehlszeilenoption @code{-r} für einen falschen Rechnernamen (»Fakehost«) in der Befehlszeile des mit @var{login-program} angegebenen Anmeldeprogramms übergeben. @item @code{flow-control?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird Hardware-Flusssteuerung (RTS/CTS) aktiviert. @item @code{no-issue?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird der Inhalt der Datei @file{/etc/issue} @emph{nicht} angezeigt, bevor die Anmeldeaufforderung zu sehen ist. @item @code{init-string} (Vorgabe: @code{#f}) Dies akzeptiert eine Zeichenkette, die zum tty oder zum Modem zuerst vor allem anderen gesendet wird. Es kann benutzt werden, um ein Modem zu initialisieren. @item @code{no-clear?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird agetty den Bildschirm @emph{nicht} löschen, bevor es die Anmeldeaufforderung anzeigt. @item @code{login-program} (Vorgabe: (file-append shadow "/bin/login")) Hier muss entweder ein G-Ausdruck mit dem Namen eines Anmeldeprogramms übergeben werden, oder dieses Feld wird nicht gesetzt, so dass als Vorgabewert das Programm @command{login} aus dem Shadow-Werkzeugsatz verwendet wird. @item @code{local-line} (Vorgabe: @code{#f}) Steuert den Leitungsschalter CLOCAL. Hierfür wird eines von drei Symbolen als Argument akzeptiert, @code{'auto}, @code{'always} oder @code{'never}. Für @code{#f} wählt agetty als Vorgabewert @code{'auto}. @item @code{extract-baud?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, so wird agetty angewiesen, die Baud-Rate aus den Statusmeldungen mancher Arten von Modem abzulesen. @item @code{skip-login?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird der Benutzer nicht aufgefordert, einen Anmeldenamen einzugeben. Dies kann zusammen mit dem @var{login-program}-Feld benutzt werden, um nicht standardkonforme Anmeldesysteme zu benutzen. @item @code{no-newline?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird @emph{kein} Zeilenumbruch ausgegeben, bevor die Datei @file{/etc/issue} ausgegeben wird. @c Is this dangerous only when used with login-program, or always? @item @code{login-options} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine Zeichenkette mit den Befehlszeilenoptionen für das Anmeldeprogramm. Beachten Sie, dass bei einem selbst gewählten @var{login-program} ein böswilliger Nutzer versuchen könnte, als Anmeldenamen etwas mit eingebetteten Befehlszeilenoptionen anzugeben, die vom Anmeldeprogramm interpretiert werden könnten. @item @code{login-pause} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird auf das Drücken einer beliebigen Taste gewartet, bevor die Anmeldeaufforderung angezeigt wird. Hiermit kann in Verbindung mit @var{auto-login} weniger Speicher verbraucht werden, indem man Shells erst erzeugt, wenn sie benötigt werden. @item @code{chroot} (Vorgabe: @code{#f}) Wechselt die Wurzel des Dateisystems auf das angegebene Verzeichnis. Dieses Feld akzeptiert einen Verzeichnispfad als Zeichenkette. @item @code{hangup?} (Vorgabe: @code{#f}) Mit dem Linux-Systemaufruf @code{vhangup} auf dem angegebenen Terminal virtuell auflegen. @item @code{keep-baud?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird versucht, die bestehende Baud-Rate beizubehalten. Die Baud-Raten aus dem Feld @var{baud-rate} werden benutzt, wenn agetty ein @key{BREAK}-Zeichen empfängt. @item @code{timeout} (Vorgabe: @code{#f}) Ist dies auf einen ganzzahligen Wert gesetzt, wird terminiert, falls kein Benutzername innerhalb von @var{timeout} Sekunden eingelesen werden konnte. @item @code{detect-case?} (Vorgabe: @code{#f}) Ist dies auf @code{#t} gesetzt, wird Unterstützung für die Erkennung von Terminals aktiviert, die nur Großschreibung beherrschen. Mit dieser Einstellung wird, wenn ein Anmeldename nur aus Großbuchstaben besteht, dieser als Anzeichen dafür aufgefasst, dass das Terminal nur Großbuchstaben beherrscht, und einige Umwandlungen von Groß- in Kleinbuchstaben aktiviert. Beachten Sie, dass dabei @emph{keine} Unicode-Zeichen unterstützt werden. @item @code{wait-cr?} (Vorgabe: @code{#f}) Wenn dies auf @code{#t} gesetzt ist, wird gewartet, bis der Benutzer oder das Modem einen Wagenrücklauf (»Carriage Return«) oder einen Zeilenvorschub (»Linefeed«) absendet, ehe @file{/etc/issue} oder eine Anmeldeaufforderung angezeigt wird. Dies wird typischerweise zusammen mit dem Feld @var{init-string} benutzt. @item @code{no-hints?} (Vorgabe: @code{#f}) Ist es auf @code{#t} gesetzt, werden @emph{keine} Hinweise zu den Feststelltasten Num-Taste, Umschaltsperre (»Caps Lock«) und Rollen-Taste (»Scroll Lock«) angezeigt. @item @code{no-hostname?} (Vorgabe: @code{#f}) Das vorgegebene Verhalten ist, den Rechnernamen auszugeben. Ist dieses Feld auf @code{#t} gesetzt, wird überhaupt kein Rechnername angezeigt. @item @code{long-hostname?} (Vorgabe: @code{#f}) Das vorgegebene Verhalten ist, den Rechnernamen nur bis zu seinem ersten Punkt anzuzeigen. Ist dieses Feld auf @code{#t} gesetzt, wird der vollständige Rechnername (der »Fully Qualified Hostname«), wie ihn @code{gethostname} oder @code{getaddrinfo} liefern, angezeigt. @item @code{erase-characters} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine Zeichenkette aus Zeichen, die auch als Rücktaste (zum Löschen) interpretiert werden sollen, wenn der Benutzer seinen Anmeldenamen eintippt. @item @code{kill-characters} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine Zeichenkette aus Zeichen, deren Eingabe als »ignoriere alle vorherigen Zeichen« interpretiert werden soll (auch »kill«-Zeichen genannt), wenn der Benutzer seinen Anmeldenamen eintippt. @item @code{chdir} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine Zeichenkette, die einen Verzeichnispfad angibt, zu dem vor der Anmeldung gewechselt wird. @item @code{delay} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine ganze Zahl mit der Anzahl Sekunden, die gewartet werden soll, bis ein tty geöffnet und die Anmeldeaufforderung angezeigt wird. @item @code{nice} (Vorgabe: @code{#f}) Dieses Feld akzeptiert eine ganze Zahl mit dem »nice«-Wert, mit dem das Anmeldeprogramm ausgeführt werden soll. @item @code{extra-options} (Vorgabe: @code{'()}) Dieses Feld ist ein »Notausstieg«, mit dem Nutzer beliebige Befehlszeilenoptionen direkt an @command{agetty} übergeben können. Diese müssen hier als eine Liste von Zeichenketten angegeben werden. @end table @end deftp @deffn {Scheme-Prozedur} kmscon-service-type @var{Konfiguration} Liefert einen Dienst, um @uref{https://www.freedesktop.org/wiki/Software/kmscon,kmscon} entsprechend der @var{Konfiguration} auszuführen. Diese ist ein @code{}-Objekt, das unter anderem angibt, auf welchem tty es ausgeführt werden soll. @end deffn @deftp {Datentyp} kmscon-configuration Dieser Datentyp repräsentiert die Konfiguration von Kmscon, die das Anmelden auf virtuellen Konsolen ermöglicht. @table @asis @item @code{virtual-terminal} Der Name der Konsole, auf der diese Kmscon läuft — z.B.@: @code{"tty1"}. @item @code{login-program} (Vorgabe: @code{#~(string-append #$shadow "/bin/login")}) Ein G-Ausdruck, der den Namen des Anmeldeprogramms angibt. Als Vorgabe wird das Anmeldeprogramm @command{login} aus dem Shadow-Werkzeugsatz verwendet. @item @code{login-arguments} (Vorgabe: @code{'("-p")}) Eine Liste der Argumente, die an @command{login} übergeben werden sollen. @item @code{auto-login} (Vorgabe: @code{#f}) Wird hier ein Anmeldename als eine Zeichenkette übergeben, wird der angegebene Nutzer automatisch angemeldet, ohne nach einem Anmeldenamen oder Passwort zu fragen. @item @code{hardware-acceleration?} (Vorgabe: #f) Ob Hardware-Beschleunigung verwendet werden soll. @item @code{kmscon} (Vorgabe: @var{kmscon}) Das Kmscon-Paket, das benutzt werden soll. @end table @end deftp @cindex Name Service Cache Daemon @cindex nscd @deffn {Scheme-Prozedur} nscd-service [@var{Konfiguration}] [#:glibc glibc] @ [#:name-services '()] Liefert einen Dienst, der den Name Service Cache Daemon (nscd) von libc mit der angegebenen @var{Konfiguration} ausführt — diese muss ein @code{}-Objekt sein. Siehe @ref{Name Service Switch} für ein Beispiel. Der Einfachheit halber bietet der Shepherd-Dienst für nscd die folgenden Aktionen an: @table @code @item invalidate @cindex Zwischenspeicher ungültig machen, nscd @cindex nscd, Ungültigmachen des Zwischenspeichers Dies macht den angegebenen Zwischenspeicher ungültig. Wenn Sie zum Beispiel: @example herd invalidate nscd hosts @end example @noindent ausführen, wird der Zwischenspeicher für die Auflösung von Rechnernamen (von »Host«-Namen) des nscd ungültig. @item statistics Wenn Sie @command{herd statistics nscd} ausführen, werden Ihnen Informationen angezeigt, welche Ihnen Informationen über den nscd-Zustand und die Zwischenspeicher angezeigt. @end table @end deffn @defvr {Scheme-Variable} %nscd-default-configuration Dies ist der vorgegebene Wert für die @code{} (siehe unten), die @code{nscd-service} benutzt. Die Konfiguration benutzt die Zwischenspeicher, die in @var{%nscd-default-caches} definiert sind; siehe unten. @end defvr @deftp {Datentyp} nscd-configuration Dieser Datentyp repräsentiert die Konfiguration des Name Service Caching Daemon (kurz »nscd«). @table @asis @item @code{name-services} (Vorgabe: @code{'()}) Liste von Paketen, die @dfn{Namensdienste} bezeichnen, die für den nscd sichtbar sein müssen, z.B.@: @code{(list @var{nss-mdns})}. @item @code{glibc} (Vorgabe: @var{glibc}) Ein Paket-Objekt, das die GNU-C-Bibliothek angibt, woraus der @command{nscd}-Befehl genommen werden soll. @item @code{log-file} (Vorgabe: @code{"/var/log/nscd.log"}) Name der nscd-Protokolldatei. Hierhin werden Ausgaben zur Fehlersuche geschrieben, falls @code{debug-level} echt positiv ist. @item @code{debug-level} (Vorgabe: @code{0}) Eine ganze Zahl, die den Detailgrad der Ausgabe zur Fehlersuche angibt. Größere Zahlen bewirken eine ausführlichere Ausgabe. @item @code{caches} (Vorgabe: @var{%nscd-default-caches}) Liste der @code{}-Objekte, die repräsentieren, was alles zwischengespeichert werden soll; siehe unten. @end table @end deftp @deftp {Datentyp} nscd-cache Ein Datentyp, der eine Zwischenspeicher-Datenbank von nscd mitsamt ihren Parametern definiert. @table @asis @item @code{Datenbank} Dies ist ein Symbol, was den Namen der Datenbank repräsentiert, die zwischengespeichert werden soll. Gültige Werte sind @code{passwd}, @code{group}, @code{hosts} und @code{services}, womit jeweils die entsprechende NSS-Datenbank bezeichnet wird (siehe @ref{NSS Basics,,, libc, The GNU C Library Reference Manual}). @item @code{positive-time-to-live} @itemx @code{negative-time-to-live} (Vorgabe: @code{20}) Eine Zahl, die für die Anzahl an Sekunden steht, die ein erfolgreiches (positives) oder erfolgloses (negatives) Nachschlageresultat im Zwischenspeicher verbleibt. @item @code{check-files?} (Vorgabe: @code{#t}) Ob auf Änderungen an den der @var{database} entsprechenden Dateien reagiert werden soll. Wenn @var{database} zum Beispiel @code{hosts} ist, wird, wenn dieses Feld gesetzt ist, nscd Änderungen an @file{/etc/hosts} beobachten und berücksichtigen. @item @code{persistent?} (Vorgabe: @code{#t}) Ob der Zwischenspeicher dauerhaft auf der Platte gespeichert werden soll. @item @code{shared?} (Vorgabe: @code{#t}) Ob der Zwischenspeicher zwischen den Nutzern geteilt werden soll. @item @code{max-database-size} (Vorgabe: 32@tie{}MiB) Die Maximalgröße des Datenbank-Zwischenspeichers in Bytes. @c XXX: 'suggested-size' and 'auto-propagate?' seem to be expert @c settings, so leave them out. @end table @end deftp @defvr {Scheme-Variable} %nscd-default-caches Liste von @code{}-Objekten, die von der vorgegebenen @code{nscd-configuration} benutzt werden (siehe oben). Damit wird dauerhaftes und aggressives Zwischenspeichern beim Nachschlagen von Dienst- und Rechnernamen (»Host«-Namen) aktiviert. Letzteres verbessert die Leistungsfähigkeit beim Nachschlagen von Rechnernamen, sorgt für mehr Widerstandsfähigkeit gegenüber unverlässlichen Namens-Servern und bietet außerdem einen besseren Schutz der Privatsphäre — oftmals befindet sich das Ergebnis einer Anfrage nach einem Rechnernamen bereits im lokalen Zwischenspeicher und externe Namens-Server müssen nicht miteinbezogen werden. @end defvr @anchor{syslog-configuration-type} @cindex syslog @cindex Protokollierung @deftp {Datentyp} syslog-configuration Dieser Datentyp repräsentiert die Konfiguration des syslog-Daemons. @table @asis @item @code{syslogd} (Vorgabe: @code{#~(string-append #$inetutils "/libexec/syslogd")}) Welcher Syslog-Daemon benutzt werden soll. @item @code{config-file} (Vorgabe: @code{%default-syslog.conf}) Die zu benutzende syslog-Konfigurationsdatei. @end table @end deftp @anchor{syslog-service} @cindex syslog @deffn {Scheme-Prozedur} syslog-service @var{Konfiguration} Liefert einen Dienst, der einen syslog-Daemon entsprechend der @var{Konfiguration} ausführt. Siehe @ref{syslogd invocation,,, inetutils, GNU Inetutils} für weitere Informationen über die Syntax der Konfiguration. @end deffn @defvr {Scheme-Variable} guix-service-type Dies ist der Typ für den Dienst, der den Erstellungs-Daemon @command{guix-daemon} ausführt (siehe @ref{Aufruf des guix-daemon}). Als Wert muss ein @code{guix-configuration}-Verbundsobjekt verwendet werden, wie unten beschrieben. @end defvr @anchor{guix-configuration-type} @deftp {Datentyp} guix-configuration Dieser Datentyp repräsentiert die Konfiguration des Erstellungs-Daemons von Guix. Siehe @ref{Aufruf des guix-daemon} für weitere Informationen. @table @asis @item @code{guix} (Vorgabe: @var{guix}) Das zu verwendende Guix-Paket. @item @code{build-group} (Vorgabe: @code{"guixbuild"}) Der Name der Gruppe, zu der die Erstellungs-Benutzerkonten gehören. @item @code{build-accounts} (Vorgabe: @code{10}) Die Anzahl zu erzeugender Erstellungs-Benutzerkonten. @item @code{authorize-key?} (Vorgabe: @code{#t}) @cindex Substitute, deren Autorisierung Ob die unter @code{authorized-keys} aufgelisteten Substitutschlüssel autorisiert werden sollen — vorgegeben ist, den von @code{@value{SUBSTITUTE-SERVER}} zu autorisieren (siehe @ref{Substitute}). @vindex %default-authorized-guix-keys @item @code{authorized-keys} (Vorgabe: @var{%default-authorized-guix-keys}) Die Liste der Dateien mit autorisierten Schlüsseln, d.h.@: eine Liste von Zeichenketten als G-Ausdrücke (siehe @ref{Aufruf von guix archive}). Der vorgegebene Inhalt ist der Schlüssel von @code{@value{SUBSTITUTE-SERVER}} (siehe @ref{Substitute}). @item @code{use-substitutes?} (Vorgabe: @code{#t}) Ob Substitute benutzt werden sollen. @item @code{substitute-urls} (Vorgabe: @var{%default-substitute-urls}) Die Liste der URLs, auf denen nach Substituten gesucht wird, wenn nicht anders angegeben. @item @code{max-silent-time} (Vorgabe: @code{0}) @itemx @code{timeout} (Vorgabe: @code{0}) Die Anzahl an Sekunden, die jeweils nichts in die Ausgabe geschrieben werden darf bzw. die es insgesamt dauern darf, bis ein Erstellungsprozess abgebrochen wird. Beim Wert null wird nie abgebrochen. @item @code{log-compression} (Vorgabe: @code{'bzip2}) Die für Erstellungsprotokolle zu benutzende Kompressionsmethode — entweder @code{gzip}, @code{bzip2} oder @code{none}. @item @code{extra-options} (Vorgabe: @code{'()}) Eine Liste zusätzlicher Befehlszeilenoptionen zu @command{guix-daemon}. @item @code{log-file} (Vorgabe: @code{"/var/log/guix-daemon.log"}) Die Datei, in die die Standardausgabe und die Standardfehlerausgabe von @command{guix-daemon} geschrieben werden. @item @code{http-proxy} (Vorgabe: @code{#f}) Der für das Herunterladen von Ableitungen mit fester Ausgabe und von Substituten zu verwendende HTTP-Proxy. @item @code{tmpdir} (Vorgabe: @code{#f}) Ein Verzeichnispfad, der angibt, wo @command{guix-daemon} seine Erstellungen durchführt. @end table @end deftp @deffn {Scheme-Prozedur} udev-service [#:udev @var{eudev} #:rules @code{'()}] Führt @var{udev} aus, was zur Laufzeit Gerätedateien ins Verzeichnis @file{/dev} einfügt. udev-Regeln können über die @var{rules}-Variable als eine Liste von Dateien übergeben werden. Die Prozeduren @var{udev-rule} und @var{file->udev-rule} aus @code{(gnu services base)} vereinfachen die Erstellung einer solchen Regeldatei. @end deffn @deffn {Scheme-Prozedur} udev-rule [@var{Dateiname} @var{Inhalt}] Liefert eine udev-Regeldatei mit dem angegebenen @var{Dateiname}n, in der die vom Literal @var{Inhalt} definierten Regeln stehen. Im folgenden Beispiel wird eine Regel für ein USB-Gerät definiert und in der Datei @file{90-usb-ding.rules} gespeichert. Mit der Regel wird ein Skript ausgeführt, sobald ein USB-Gerät mit der angegebenen Produktkennung erkannt wird. @example (define %beispiel-udev-rule (udev-rule "90-usb-ding.rules" (string-append "ACTION==\"add\", SUBSYSTEM==\"usb\", " "ATTR@{product@}==\"Beispiel\", " "RUN+=\"/pfad/zum/skript\""))) @end example The @command{herd rules udev} command, as root, returns the name of the directory containing all the active udev rules. @end deffn Hier zeigen wir, wie man den vorgegebenen @var{udev-service} um sie erweitern kann. @example (operating-system ;; @dots{} (services (modify-services %desktop-services (udev-service-type config => (udev-configuration (inherit config) (rules (append (udev-configuration-rules config) (list %beispiel-udev-rule)))))))) @end example @deffn {Scheme-Prozedur} file->udev-rule [@var{Dateiname} @var{Datei}] Liefert eine udev-Datei mit dem angegebenen @var{Dateiname}n, in der alle in der @var{Datei}, einem dateiartigen Objekt, definierten Regeln stehen. Folgendes Beispiel stellt dar, wie wir eine bestehende Regeldatei verwenden können. @example (use-modules (guix download) ;für url-fetch (guix packages) ;für origin ;; @dots{}) (define %android-udev-rules (file->udev-rule "51-android-udev.rules" (let ((version "20170910")) (origin (method url-fetch) (uri (string-append "https://raw.githubusercontent.com/M0Rf30/" "android-udev-rules/" version "/51-android.rules")) (sha256 (base32 "0lmmagpyb6xsq6zcr2w1cyx9qmjqmajkvrdbhjx32gqf1d9is003")))))) @end example @end deffn Zusätzlich können Guix-Paketdefinitionen unter den @var{rules} aufgeführt werden, um die udev-Regeln um diejenigen Definitionen zu ergänzen, die im Unterverzeichnis @file{lib/udev/rules.d} des jeweiligen Pakets aufgeführt sind. Statt des bisherigen Beispiels zu @var{file->udev-rule} hätten wir also auch das Paket @var{android-udev-rules} benutzen können, das in Guix im Modul @code{(gnu packages android)} vorhanden ist. Das folgende Beispiel zeit, wie dieses Paket @var{android-udev-rules} benutzt werden kann, damit das »Android-Tool« @command{adb} Geräte erkennen kann, ohne dafür Administratorrechte vorauszusetzen. Man sieht hier auch, wie die Benutzergruppe @code{adbusers} erstellt werden kann, die existieren muss, damit die im Paket @var{android-udev-rules} definierten Regeln richtig funktionieren. Um so eine Benutzergruppe zu erzeugen, müssen wir sie sowohl unter den @var{supplementary-groups} unserer @var{user-account}-Deklaration aufführen, als auch sie im @var{groups}-Feld des @var{operating-system}-Verbundsobjekts aufführen. @example (use-modules (gnu packages android) ;für android-udev-rules (gnu system shadow) ;für user-group ;; @dots{}) (operating-system ;; @dots{} (users (cons (user-acount ;; @dots{} (supplementary-groups '("adbusers" ;für adb "wheel" "netdev" "audio" "video")) ;; @dots{}))) (groups (cons (user-group (system? #t) (name "adbusers")) %base-groups)) ;; @dots{} (services (modify-services %desktop-services (udev-service-type config => (udev-configuration (inherit config) (rules (cons android-udev-rules (udev-configuration-rules config)))))))) @end example @defvr {Scheme-Variable} urandom-seed-service-type Etwas Entropie in der Datei @var{%random-seed-file} aufsparen, die als Startwert (als sogenannter »Seed«) für @file{/dev/urandom} dienen kann, nachdem das System neu gestartet wurde. Es wird auch versucht, @file{/dev/urandom} beim Hochfahren mit Werten aus @file{/dev/hwrng} zu starten, falls @file{/dev/hwrng} existiert und lesbar ist. @end defvr @defvr {Scheme-Variable} %random-seed-file Der Name der Datei, in der einige zufällige Bytes vom @var{urandom-seed-service} abgespeichert werden, um sie nach einem Neustart von dort als Startwert für @file{/dev/urandom} auslesen zu können. Als Vorgabe wird @file{/var/lib/random-seed} verwendet. @end defvr @cindex Maus @cindex gpm @defvr {Scheme-Variable} gpm-service-type Dieser Typ wird für den Dienst verwendet, der GPM ausführt, den @dfn{General-Purpose Mouse Daemon}, welcher zur Linux-Konsole Mausunterstützung hinzufügt. GPM ermöglicht es seinen Benutzern, auch in der Konsole die Maus zu benutzen und damit etwa Text auszuwählen, zu kopieren und einzufügen. Der Wert für Dienste dieses Typs muss eine @code{gpm-configuration} sein (siehe unten). Dieser Dienst gehört @emph{nicht} zu den @var{%base-services}. @end defvr @deftp {Datentyp} gpm-configuration Repräsentiert die Konfiguration von GPM. @table @asis @item @code{options} (Vorgabe: @code{%default-gpm-options}) Befehlszeilenoptionen, die an @command{gpm} übergeben werden. Die vorgegebenen Optionen weisen @command{gpm} an, auf Maus-Ereignisse auf der Datei @file{/dev/input/mice} zu lauschen. Siehe @ref{Command Line,,, gpm, gpm manual} für weitere Informationen. @item @code{gpm} (Vorgabe: @code{gpm}) Das GPM-Paket, was benutzt werden soll. @end table @end deftp @anchor{guix-publish-service-type} @deffn {Scheme-Variable} guix-publish-service-type Dies ist der Diensttyp für @command{guix publish} (siehe @ref{Aufruf von guix publish}). Sein Wert muss ein @code{guix-publish-configuration}-Objekt sein, wie im Folgenden beschrieben. Hierbei wird angenommen, dass @file{/etc/guix} bereits ein mit @command{guix archive --generate-key} erzeugtes Schlüsselpaar zum Signieren enthält (siehe @ref{Aufruf von guix archive}). Falls nicht, wird der Dienst beim Starten fehlschlagen. @end deffn @deftp {Datentyp} guix-publish-configuration Der Datentyp, der die Konfiguration des »@code{guix publish}«-Dienstes repräsentiert. @table @asis @item @code{guix} (Vorgabe: @code{guix}) Das zu verwendende Guix-Paket. @item @code{port} (Vorgabe: @code{80}) Der TCP-Port, auf dem auf Verbindungen gelauscht werden soll. @item @code{host} (Vorgabe: @code{"localhost"}) Unter welcher Rechneradresse (welchem »Host«, also welcher Netzwerkschnittstelle) auf Verbindungen gelauscht wird. Benutzen Sie @code{"0.0.0.0"}, wenn auf allen verfügbaren Netzwerkschnittstellen gelauscht werden soll. @item @code{compression-level} (Vorgabe: @code{3}) Die gzip-Kompressionsstufe, mit der Substitute komprimiert werden sollen. Benutzen Sie @code{0}, um Kompression völlig abzuschalten, und @code{9} für das höchste Kompressionsverhältnis, zu Lasten von zusätzlicher Prozessorauslastung. @item @code{nar-path} (Vorgabe: @code{"nar"}) Der URL-Pfad, unter dem »Nars« zum Herunterladen angeboten werden. Siehe @ref{Aufruf von guix publish, @code{--nar-path}} für Details. @item @code{cache} (Vorgabe: @code{#f}) Wenn dies @code{#f} ist, werden Archive nicht zwischengespeichert, sondern erst bei einer Anfrage erzeugt. Andernfalls sollte dies der Name eines Verzeichnisses sein — z.B.@: @code{"/var/cache/guix/publish"} —, in das @command{guix publish} fertige Archive und Metadaten zwischenspeichern soll. Siehe @ref{Aufruf von guix publish, @option{--cache}} für weitere Informationen über die jeweiligen Vor- und Nachteile. @item @code{workers} (Vorgabe: @code{#f}) Ist dies eine ganze Zahl, gibt es die Anzahl der Worker-Threads an, die zum Zwischenspeichern benutzt werden; ist es @code{#f}, werden so viele benutzt, wie es Prozessoren gibt. Siehe @ref{Aufruf von guix publish, @option{--workers}} für mehr Informationen. @item @code{ttl} (Vorgabe: @code{#f}) Wenn dies eine ganze Zahl ist, bezeichnet sie die @dfn{Time-to-live} als die Anzahl der Sekunden, die heruntergeladene veröffentlichte Archive zwischengespeichert werden dürfen. Siehe @ref{Aufruf von guix publish, @option{--ttl}} für mehr Informationen. @end table @end deftp @anchor{rngd-service} @deffn {Scheme-Prozedur} rngd-service [#:rng-tools @var{rng-tools}] @ [#:device "/dev/hwrng"] Liefert einen Dienst, der das @command{rngd}-Programm aus den @var{rng-tools} benutzt, um das mit @var{device} bezeichnete Gerät zum Entropie-Pool des Kernels hinzuzufügen. Dieser Dienst wird fehlschlagen, falls das mit @var{device} bezeichnete Gerät nicht existiert. @end deffn @anchor{pam-limits-service} @cindex Sitzungs-Limits @cindex ulimit @cindex Priorität @cindex Echtzeit @cindex jackd @deffn {Scheme-Prozedur} pam-limits-service [#:limits @code{'()}] Liefert einen Dienst, der eine Konfigurationsdatei für das @uref{http://linux-pam.org/Linux-PAM-html/sag-pam_limits.html, @code{pam_limits}-Modul} installiert. Diese Prozedur nimmt optional eine Liste von @code{pam-limits-entry}-Werten entgegen, die benutzt werden können, um @code{ulimit}-Limits und nice-Prioritäten für Benutzersitzungen festzulegen. Die folgenden Limit-Definitionen setzen zwei harte und weiche Limits für alle Anmeldesitzungen für Benutzer in der @code{realtime}-Gruppe. @example (pam-limits-service (list (pam-limits-entry "@@realtime" 'both 'rtprio 99) (pam-limits-entry "@@realtime" 'both 'memlock 'unlimited))) @end example Der erste Eintrag erhöht die maximale Echtzeit-Priorität für unprivilegierte Prozesse ohne zusätzliche Berechtigungen; der zweite Eintrag hebt jegliche Einschränkungen des maximalen Adressbereichs auf, der im Speicher reserviert werden darf. Diese Einstellungen werden in dieser Form oft für Echtzeit-Audio-Systeme verwendet. @end deffn @node Geplante Auftragsausführung @subsection Geplante Auftragsausführung @cindex cron @cindex mcron @cindex Planen von Aufträgen Das Modul @code{(gnu services mcron)} enthält eine Schnittstelle zu GNU@tie{}mcron, einem Daemon, der gemäß einem vorher festgelegten Zeitplan Aufträge (sogenannte »Jobs«) ausführt (siehe @ref{Top,,, mcron, GNU@tie{}mcron}). GNU@tie{}mcron ist ähnlich zum traditionellen @command{cron}-Daemon aus Unix; der größte Unterschied ist, dass mcron in Guile Scheme implementiert ist, wodurch einem viel Flexibilität bei der Spezifikation von Aufträgen und ihren Aktionen offen steht. Das folgende Beispiel definiert ein Betriebssystem, das täglich die Befehle @command{updatedb} (siehe @ref{Invoking updatedb,,, find, Finding Files}) und @command{guix gc} (siehe @ref{Aufruf von guix gc}) ausführt sowie den Befehl @command{mkid} im Namen eines »unprivilegierten« Nutzers ohne besondere Berechtigungen laufen lässt (siehe @ref{mkid invocation,,, idutils, ID Database Utilities}). Zum Anlegen von Auftragsdefinitionen benutzt es G-Ausdrücke, die dann an mcron übergeben werden (siehe @ref{G-Ausdrücke}). @lisp (use-modules (guix) (gnu) (gnu services mcron)) (use-package-modules base idutils) (define updatedb-job ;; 'updatedb' jeden Tag um 3 Uhr morgens ausführen. Hier schreiben wir ;; die vom Auftrag durchzuführende Aktion als eine Scheme-Prozedur. #~(job '(next-hour '(3)) (lambda () (execl (string-append #$findutils "/bin/updatedb") "updatedb" "--prunepaths=/tmp /var/tmp /gnu/store")))) (define garbage-collector-job ;; Jeden Tag 5 Minuten nach Mitternacht Müll sammeln gehen. ;; Die Aktions des Auftrags ist ein Shell-Befehl. #~(job "5 0 * * *" ;Vixie-cron-Syntax "guix gc -F 1G")) (define idutils-job ;; Die Index-Datenbank des Benutzers "charlie" um 12:15 Uhr und ;; 19:15 Uhr aktualisieren. Dies wird aus seinem Persönlichen ;; Ordner heraus ausgeführt. #~(job '(next-minute-from (next-hour '(12 19)) '(15)) (string-append #$idutils "/bin/mkid src") #:user "charlie")) (operating-system ;; @dots{} (services (cons (service mcron-service-type (mcron-configuration (jobs (list garbage-collector-job updatedb-job idutils-job)))) %base-services))) @end lisp Siehe @ref{Guile Syntax, mcron job specifications,, mcron, GNU@tie{}mcron} für weitere Informationen zu mcron-Auftragsspezifikationen. Nun folgt die Referenz des mcron-Dienstes. On a running system, you can use the @code{schedule} action of the service to visualize the mcron jobs that will be executed next: @example # herd schedule mcron @end example @noindent The example above lists the next five tasks that will be executed, but you can also specify the number of tasks to display: @example # herd schedule mcron 10 @end example @defvr {Scheme Variable} mcron-service-type This is the type of the @code{mcron} service, whose value is an @code{mcron-configuration} object. This service type can be the target of a service extension that provides it additional job specifications (@pxref{Dienstkompositionen}). In other words, it is possible to define services that provide additional mcron jobs to run. @end defvr @deftp {Data Type} mcron-configuration Data type representing the configuration of mcron. @table @asis @item @code{mcron} (default: @var{mcron}) The mcron package to use. @item @code{jobs} This is a list of gexps (@pxref{G-Ausdrücke}), where each gexp corresponds to an mcron job specification (@pxref{Syntax, mcron job specifications,, mcron, GNU@tie{}mcron}). @end table @end deftp @node Log-Rotation @subsection Log-Rotation @cindex rottlog @cindex log rotation @cindex Protokollierung Log files such as those found in @file{/var/log} tend to grow endlessly, so it's a good idea to @dfn{rotate} them once in a while---i.e., archive their contents in separate files, possibly compressed. The @code{(gnu services admin)} module provides an interface to GNU@tie{}Rot[t]log, a log rotation tool (@pxref{Top,,, rottlog, GNU Rot[t]log Manual}). The example below defines an operating system that provides log rotation with the default settings, for commonly encountered log files. @lisp (use-modules (guix) (gnu)) (use-service-modules admin mcron) (use-package-modules base idutils) (operating-system ;; @dots{} (services (cons (service rottlog-service-type) %base-services))) @end lisp @defvr {Scheme Variable} rottlog-service-type This is the type of the Rottlog service, whose value is a @code{rottlog-configuration} object. Other services can extend this one with new @code{log-rotation} objects (see below), thereby augmenting the set of files to be rotated. This service type can define mcron jobs (@pxref{Geplante Auftragsausführung}) to run the rottlog service. @end defvr @deftp {Data Type} rottlog-configuration Data type representing the configuration of rottlog. @table @asis @item @code{rottlog} (default: @code{rottlog}) The Rottlog package to use. @item @code{rc-file} (default: @code{(file-append rottlog "/etc/rc")}) The Rottlog configuration file to use (@pxref{Mandatory RC Variables,,, rottlog, GNU Rot[t]log Manual}). @item @code{rotations} (default: @code{%default-rotations}) A list of @code{log-rotation} objects as defined below. @item @code{jobs} This is a list of gexps where each gexp corresponds to an mcron job specification (@pxref{Geplante Auftragsausführung}). @end table @end deftp @deftp {Data Type} log-rotation Data type representing the rotation of a group of log files. Taking an example from the Rottlog manual (@pxref{Period Related File Examples,,, rottlog, GNU Rot[t]log Manual}), a log rotation might be defined like this: @example (log-rotation (frequency 'daily) (files '("/var/log/apache/*")) (options '("storedir apache-archives" "rotate 6" "notifempty" "nocompress"))) @end example The list of fields is as follows: @table @asis @item @code{frequency} (default: @code{'weekly}) The log rotation frequency, a symbol. @item @code{files} The list of files or file glob patterns to rotate. @item @code{options} (default: @code{'()}) The list of rottlog options for this rotation (@pxref{Configuration parameters,,, rottlog, GNU Rot[t]lg Manual}). @item @code{post-rotate} (default: @code{#f}) Either @code{#f} or a gexp to execute once the rotation has completed. @end table @end deftp @defvr {Scheme Variable} %default-rotations Specifies weekly rotation of @var{%rotated-files} and a couple of other files. @end defvr @defvr {Scheme Variable} %rotated-files The list of syslog-controlled files to be rotated. By default it is: @code{'("/var/log/messages" "/var/log/secure")}. @end defvr @node Netzwerkdienste @subsection Netzwerkdienste The @code{(gnu services networking)} module provides services to configure the network interface. @cindex DHCP, networking service @defvr {Scheme Variable} dhcp-client-service-type This is the type of services that run @var{dhcp}, a Dynamic Host Configuration Protocol (DHCP) client, on all the non-loopback network interfaces. Its value is the DHCP client package to use, @code{isc-dhcp} by default. @end defvr @deffn {Scheme Procedure} dhcpd-service-type This type defines a service that runs a DHCP daemon. To create a service of this type, you must supply a @code{}. For example: @example (service dhcpd-service-type (dhcpd-configuration (config-file (local-file "my-dhcpd.conf")) (interfaces '("enp0s25")))) @end example @end deffn @deftp {Data Type} dhcpd-configuration @table @asis @item @code{package} (default: @code{isc-dhcp}) The package that provides the DHCP daemon. This package is expected to provide the daemon at @file{sbin/dhcpd} relative to its output directory. The default package is the @uref{http://www.isc.org/products/DHCP, ISC's DHCP server}. @item @code{config-file} (default: @code{#f}) The configuration file to use. This is required. It will be passed to @code{dhcpd} via its @code{-cf} option. This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}). See @code{man dhcpd.conf} for details on the configuration file syntax. @item @code{version} (default: @code{"4"}) The DHCP version to use. The ISC DHCP server supports the values ``4'', ``6'', and ``4o6''. These correspond to the @code{dhcpd} program options @code{-4}, @code{-6}, and @code{-4o6}. See @code{man dhcpd} for details. @item @code{run-directory} (default: @code{"/run/dhcpd"}) The run directory to use. At service activation time, this directory will be created if it does not exist. @item @code{pid-file} (default: @code{"/run/dhcpd/dhcpd.pid"}) The PID file to use. This corresponds to the @code{-pf} option of @code{dhcpd}. See @code{man dhcpd} for details. @item @code{interfaces} (default: @code{'()}) The names of the network interfaces on which dhcpd should listen for broadcasts. If this list is not empty, then its elements (which must be strings) will be appended to the @code{dhcpd} invocation when starting the daemon. It may not be necessary to explicitly specify any interfaces here; see @code{man dhcpd} for details. @end table @end deftp @defvr {Scheme Variable} static-networking-service-type @c TODO Document data structures. This is the type for statically-configured network interfaces. @end defvr @deffn {Scheme Procedure} static-networking-service @var{interface} @var{ip} @ [#:netmask #f] [#:gateway #f] [#:name-servers @code{'()}] @ [#:requirement @code{'(udev)}] Return a service that starts @var{interface} with address @var{ip}. If @var{netmask} is true, use it as the network mask. If @var{gateway} is true, it must be a string specifying the default network gateway. @var{requirement} can be used to declare a dependency on another service before configuring the interface. This procedure can be called several times, one for each network interface of interest. Behind the scenes what it does is extend @code{static-networking-service-type} with additional network interfaces to handle. Zum Beispiel: @example (static-networking-service "eno1" "192.168.1.82" #:gateway "192.168.1.2" #:name-servers '("192.168.1.2")) @end example @end deffn @cindex wicd @cindex WLAN @cindex WiFi @cindex network management @deffn {Scheme Procedure} wicd-service [#:wicd @var{wicd}] Return a service that runs @url{https://launchpad.net/wicd,Wicd}, a network management daemon that aims to simplify wired and wireless networking. This service adds the @var{wicd} package to the global profile, providing several commands to interact with the daemon and configure networking: @command{wicd-client}, a graphical user interface, and the @command{wicd-cli} and @command{wicd-curses} user interfaces. @end deffn @cindex ModemManager @defvr {Scheme Variable} modem-manager-service-type This is the service type for the @uref{https://wiki.gnome.org/Projects/ModemManager, ModemManager} service. The value for this service type is a @code{modem-manager-configuration} record. This service is part of @code{%desktop-services} (@pxref{Desktop-Dienste}). @end defvr @deftp {Data Type} modem-manager-configuration Repräsentiert die Konfiguration vom ModemManager. @table @asis @item @code{modem-manager} (Vorgabe: @code{modem-manager}) Das ModemManager-Paket, was benutzt werden soll. @end table @end deftp @cindex NetworkManager @defvr {Scheme Variable} network-manager-service-type This is the service type for the @uref{https://wiki.gnome.org/Projects/NetworkManager, NetworkManager} service. The value for this service type is a @code{network-manager-configuration} record. This service is part of @code{%desktop-services} (@pxref{Desktop-Dienste}). @end defvr @deftp {Data Type} network-manager-configuration Data type representing the configuration of NetworkManager. @table @asis @item @code{network-manager} (default: @code{network-manager}) The NetworkManager package to use. @item @code{dns} (default: @code{"default"}) Processing mode for DNS, which affects how NetworkManager uses the @code{resolv.conf} configuration file. @table @samp @item default NetworkManager will update @code{resolv.conf} to reflect the nameservers provided by currently active connections. @item dnsmasq NetworkManager will run @code{dnsmasq} as a local caching nameserver, using a "split DNS" configuration if you are connected to a VPN, and then update @code{resolv.conf} to point to the local nameserver. @item none NetworkManager will not modify @code{resolv.conf}. @end table @item @code{vpn-plugins} (default: @code{'()}) This is the list of available plugins for virtual private networks (VPNs). An example of this is the @code{network-manager-openvpn} package, which allows NetworkManager to manage VPNs @i{via} OpenVPN. @end table @end deftp @cindex Connman @deffn {Scheme Variable} connman-service-type This is the service type to run @url{https://01.org/connman,Connman}, a network connection manager. Its value must be an @code{connman-configuration} record as in this example: @example (service connman-service-type (connman-configuration (disable-vpn? #t))) @end example See below for details about @code{connman-configuration}. @end deffn @deftp {Data Type} connman-configuration Data Type representing the configuration of connman. @table @asis @item @code{connman} (default: @var{connman}) The connman package to use. @item @code{disable-vpn?} (default: @code{#f}) When true, disable connman's vpn plugin. @end table @end deftp @cindex WPA Supplicant @defvr {Scheme Variable} wpa-supplicant-service-type This is the service type to run @url{https://w1.fi/wpa_supplicant/,WPA supplicant}, an authentication daemon required to authenticate against encrypted WiFi or ethernet networks. @end defvr @deftp {Data Type} wpa-supplicant-configuration Repräsentiert die Konfiguration des WPA-Supplikanten. Sie hat folgende Parameter: @table @asis @item @code{wpa-supplicant} (Vorgabe: @code{wpa-supplicant}) Das WPA-Supplicant-Paket, was benutzt werden soll. @item @code{dbus?} (Vorgabe: @code{#t}) Whether to listen for requests on D-Bus. @item @code{pid-file} (Vorgabe: @code{"/var/run/wpa_supplicant.pid"}) Wo die PID-Datei abgelegt wird. @item @code{interface} (Vorgabe: @code{#f}) If this is set, it must specify the name of a network interface that WPA supplicant will control. @item @code{config-file} (default: @code{#f}) Optionale Konfigurationsdatei. @item @code{extra-options} (Vorgabe: @code{'()}) List of additional command-line arguments to pass to the daemon. @end table @end deftp @cindex iptables @defvr {Scheme Variable} iptables-service-type This is the service type to set up an iptables configuration. iptables is a packet filtering framework supported by the Linux kernel. This service supports configuring iptables for both IPv4 and IPv6. A simple example configuration rejecting all incoming connections except those to the ssh port 22 is shown below. @lisp (service iptables-service-type (iptables-configuration (ipv4-rules (plain-file "iptables.rules" "*filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -p tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-port-unreachable COMMIT ")) (ipv6-rules (plain-file "ip6tables.rules" "*filter :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -p tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-port-unreachable COMMIT ")))) @end lisp @end defvr @deftp {Datentyp} iptables-configuration Repräsentiert die iptables-Konfiguration. @table @asis @item @code{iptables} (Vorgabe: @code{iptables}) The iptables package that provides @code{iptables-restore} and @code{ip6tables-restore}. @item @code{ipv4-rules} (Vorgabe: @code{%iptables-accept-all-rules}) The iptables rules to use. It will be passed to @code{iptables-restore}. This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}). @item @code{ipv6-rules} (Vorgabe: @code{%iptables-accept-all-rules}) The ip6tables rules to use. It will be passed to @code{ip6tables-restore}. This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}). @end table @end deftp @cindex NTP (Network Time Protocol), Dienst @cindex real time clock @defvr {Scheme Variable} ntp-service-type This is the type of the service running the @uref{http://www.ntp.org, Network Time Protocol (NTP)} daemon, @command{ntpd}. The daemon will keep the system clock synchronized with that of the specified NTP servers. The value of this service is an @code{ntpd-configuration} object, as described below. @end defvr @deftp {Datentyp} ntp-configuration Der Datentyp für die Dienstkonfiguration des NTP-Dienstes. @table @asis @item @code{servers} (Vorgabe: @code{%ntp-servers}) This is the list of servers (host names) with which @command{ntpd} will be synchronized. @item @code{allow-large-adjustment?} (default: @code{#f}) This determines whether @command{ntpd} is allowed to make an initial adjustment of more than 1,000 seconds. @item @code{ntp} (Vorgabe: @code{ntp}) Das NTP-Paket, was benutzt werden soll. @end table @end deftp @defvr {Scheme Variable} %ntp-servers List of host names used as the default NTP servers. These are servers of the @uref{https://www.ntppool.org/en/, NTP Pool Project}. @end defvr @cindex OpenNTPD @deffn {Scheme Procedure} openntpd-service-type Run the @command{ntpd}, the Network Time Protocol (NTP) daemon, as implemented by @uref{http://www.openntpd.org, OpenNTPD}. The daemon will keep the system clock synchronized with that of the given servers. @example (service openntpd-service-type (openntpd-configuration (listen-on '("127.0.0.1" "::1")) (sensor '("udcf0 correction 70000")) (constraint-from '("www.gnu.org")) (constraints-from '("https://www.google.com/")) (allow-large-adjustment? #t))) @end example @end deffn @deftp {Data Type} openntpd-configuration @table @asis @item @code{openntpd} (default: @code{(file-append openntpd "/sbin/ntpd")}) The openntpd executable to use. @item @code{listen-on} (default: @code{'("127.0.0.1" "::1")}) A list of local IP addresses or hostnames the ntpd daemon should listen on. @item @code{query-from} (default: @code{'()}) A list of local IP address the ntpd daemon should use for outgoing queries. @item @code{sensor} (default: @code{'()}) Specify a list of timedelta sensor devices ntpd should use. @code{ntpd} will listen to each sensor that acutally exists and ignore non-existant ones. See @uref{https://man.openbsd.org/ntpd.conf, upstream documentation} for more information. @item @code{server} (default: @var{%ntp-servers}) Specify a list of IP addresses or hostnames of NTP servers to synchronize to. @item @code{servers} (default: @code{'()}) Specify a list of IP addresses or hostnames of NTP pools to synchronize to. @item @code{constraint-from} (default: @code{'()}) @code{ntpd} can be configured to query the ‘Date’ from trusted HTTPS servers via TLS. This time information is not used for precision but acts as an authenticated constraint, thereby reducing the impact of unauthenticated NTP man-in-the-middle attacks. Specify a list of URLs, IP addresses or hostnames of HTTPS servers to provide a constraint. @item @code{constraints-from} (default: @code{'()}) As with constraint from, specify a list of URLs, IP addresses or hostnames of HTTPS servers to provide a constraint. Should the hostname resolve to multiple IP addresses, @code{ntpd} will calculate a median constraint from all of them. @item @code{allow-large-adjustment?} (default: @code{#f}) Determines if @code{ntpd} is allowed to make an initial adjustment of more than 180 seconds. @end table @end deftp @cindex inetd @deffn {Scheme variable} inetd-service-type This service runs the @command{inetd} (@pxref{inetd invocation,,, inetutils, GNU Inetutils}) daemon. @command{inetd} listens for connections on internet sockets, and lazily starts the specified server program when a connection is made on one of these sockets. The value of this service is an @code{inetd-configuration} object. The following example configures the @command{inetd} daemon to provide the built-in @command{echo} service, as well as an smtp service which forwards smtp traffic over ssh to a server @code{smtp-server} behind a gateway @code{hostname}: @example (service inetd-service-type (inetd-configuration (entries (list (inetd-entry (name "echo") (socket-type 'stream) (protocol "tcp") (wait? #f) (user "root")) (inetd-entry (node "127.0.0.1") (name "smtp") (socket-type 'stream) (protocol "tcp") (wait? #f) (user "root") (program (file-append openssh "/bin/ssh")) (arguments '("ssh" "-qT" "-i" "/path/to/ssh_key" "-W" "smtp-server:25" "user@@hostname"))))) @end example See below for more details about @code{inetd-configuration}. @end deffn @deftp {Data Type} inetd-configuration Data type representing the configuration of @command{inetd}. @table @asis @item @code{program} (default: @code{(file-append inetutils "/libexec/inetd")}) The @command{inetd} executable to use. @item @code{entries} (default: @code{'()}) A list of @command{inetd} service entries. Each entry should be created by the @code{inetd-entry} constructor. @end table @end deftp @deftp {Data Type} inetd-entry Data type representing an entry in the @command{inetd} configuration. Each entry corresponds to a socket where @command{inetd} will listen for requests. @table @asis @item @code{node} (Vorgabe: @code{#f}) Optional string, a comma-separated list of local addresses @command{inetd} should use when listening for this service. @xref{Configuration file,,, inetutils, GNU Inetutils} for a complete description of all options. @item @code{name} A string, the name must correspond to an entry in @code{/etc/services}. @item @code{socket-type} One of @code{'stream}, @code{'dgram}, @code{'raw}, @code{'rdm} or @code{'seqpacket}. @item @code{protocol} A string, must correspond to an entry in @code{/etc/protocols}. @item @code{wait?} (Vorgabe: @code{#t}) Whether @command{inetd} should wait for the server to exit before listening to new service requests. @item @code{user} A string containing the user (and, optionally, group) name of the user as whom the server should run. The group name can be specified in a suffix, separated by a colon or period, i.e.@: @code{"user"}, @code{"user:group"} or @code{"user.group"}. @item @code{program} (default: @code{"internal"}) The server program which will serve the requests, or @code{"internal"} if @command{inetd} should use a built-in service. @item @code{arguments} (Vorgabe: @code{'()}) A list strings or file-like objects, which are the server program's arguments, starting with the zeroth argument, i.e.@: the name of the program itself. For @command{inetd}'s internal services, this entry must be @code{'()} or @code{'("internal")}. @end table @xref{Configuration file,,, inetutils, GNU Inetutils} for a more detailed discussion of each configuration field. @end deftp @cindex Tor @defvr {Scheme Variable} tor-service-type This is the type for a service that runs the @uref{https://torproject.org, Tor} anonymous networking daemon. The service is configured using a @code{} record. By default, the Tor daemon runs as the @code{tor} unprivileged user, which is a member of the @code{tor} group. @end defvr @deftp {Datentyp} tor-configuration @table @asis @item @code{tor} (Vorgabe: @code{tor}) The package that provides the Tor daemon. This package is expected to provide the daemon at @file{bin/tor} relative to its output directory. The default package is the @uref{https://www.torproject.org, Tor Project's} implementation. @item @code{config-file} (Vorgabe: @code{(plain-file "empty" "")}) The configuration file to use. It will be appended to a default configuration file, and the final configuration file will be passed to @code{tor} via its @code{-f} option. This may be any ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}). See @code{man tor} for details on the configuration file syntax. @item @code{hidden-services} (Vorgabe: @code{'()}) The list of @code{} records to use. For any hidden service you include in this list, appropriate configuration to enable the hidden service will be automatically added to the default configuration file. You may conveniently create @code{} records using the @code{tor-hidden-service} procedure described below. @item @code{socks-socket-type} (Vorgabe: @code{'tcp}) The default socket type that Tor should use for its SOCKS socket. This must be either @code{'tcp} or @code{'unix}. If it is @code{'tcp}, then by default Tor will listen on TCP port 9050 on the loopback interface (i.e., localhost). If it is @code{'unix}, then Tor will listen on the UNIX domain socket @file{/var/run/tor/socks-sock}, which will be made writable by members of the @code{tor} group. If you want to customize the SOCKS socket in more detail, leave @code{socks-socket-type} at its default value of @code{'tcp} and use @code{config-file} to override the default by providing your own @code{SocksPort} option. @end table @end deftp @cindex hidden service @deffn {Scheme Procedure} tor-hidden-service @var{name} @var{mapping} Define a new Tor @dfn{hidden service} called @var{name} and implementing @var{mapping}. @var{mapping} is a list of port/host tuples, such as: @example '((22 "127.0.0.1:22") (80 "127.0.0.1:8080")) @end example In this example, port 22 of the hidden service is mapped to local port 22, and port 80 is mapped to local port 8080. This creates a @file{/var/lib/tor/hidden-services/@var{name}} directory, where the @file{hostname} file contains the @code{.onion} host name for the hidden service. See @uref{https://www.torproject.org/docs/tor-hidden-service.html.en, the Tor project's documentation} for more information. @end deffn The @code{(gnu services rsync)} module provides the following services: You might want an rsync daemon if you have files that you want available so anyone (or just yourself) can download existing files or upload new files. @deffn {Scheme Variable} rsync-service-type This is the type for the @uref{https://rsync.samba.org, rsync} rsync daemon, @command{rsync-configuration} record as in this example: @example (service rsync-service-type) @end example See below for details about @code{rsync-configuration}. @end deffn @deftp {Data Type} rsync-configuration Data type representing the configuration for @code{rsync-service}. @table @asis @item @code{package} (default: @var{rsync}) @code{rsync} package to use. @item @code{port-number} (default: @code{873}) TCP port on which @command{rsync} listens for incoming connections. If port is less than @code{1024} @command{rsync} needs to be started as the @code{root} user and group. @item @code{pid-file} (default: @code{"/var/run/rsyncd/rsyncd.pid"}) Name of the file where @command{rsync} writes its PID. @item @code{lock-file} (default: @code{"/var/run/rsyncd/rsyncd.lock"}) Name of the file where @command{rsync} writes its lock file. @item @code{log-file} (default: @code{"/var/log/rsyncd.log"}) Name of the file where @command{rsync} writes its log file. @item @code{use-chroot?} (default: @var{#t}) Whether to use chroot for @command{rsync} shared directory. @item @code{share-path} (default: @file{/srv/rsync}) Location of the @command{rsync} shared directory. @item @code{share-comment} (default: @code{"Rsync share"}) Comment of the @command{rsync} shared directory. @item @code{read-only?} (default: @var{#f}) Read-write permissions to shared directory. @item @code{timeout} (default: @code{300}) I/O timeout in seconds. @item @code{user} (default: @var{"root"}) Owner of the @code{rsync} process. @item @code{group} (default: @var{"root"}) Group of the @code{rsync} process. @item @code{uid} (default: @var{"rsyncd"}) User name or user ID that file transfers to and from that module should take place as when the daemon was run as @code{root}. @item @code{gid} (default: @var{"rsyncd"}) Group name or group ID that will be used when accessing the module. @end table @end deftp Furthermore, @code{(gnu services ssh)} provides the following services. @cindex SSH @cindex SSH server @deffn {Scheme Procedure} lsh-service [#:host-key "/etc/lsh/host-key"] @ [#:daemonic? #t] [#:interfaces '()] [#:port-number 22] @ [#:allow-empty-passwords? #f] [#:root-login? #f] @ [#:syslog-output? #t] [#:x11-forwarding? #t] @ [#:tcp/ip-forwarding? #t] [#:password-authentication? #t] @ [#:public-key-authentication? #t] [#:initialize? #t] Run the @command{lshd} program from @var{lsh} to listen on port @var{port-number}. @var{host-key} must designate a file containing the host key, and readable only by root. When @var{daemonic?} is true, @command{lshd} will detach from the controlling terminal and log its output to syslogd, unless one sets @var{syslog-output?} to false. Obviously, it also makes lsh-service depend on existence of syslogd service. When @var{pid-file?} is true, @command{lshd} writes its PID to the file called @var{pid-file}. When @var{initialize?} is true, automatically create the seed and host key upon service activation if they do not exist yet. This may take long and require interaction. When @var{initialize?} is false, it is up to the user to initialize the randomness generator (@pxref{lsh-make-seed,,, lsh, LSH Manual}), and to create a key pair with the private key stored in file @var{host-key} (@pxref{lshd basics,,, lsh, LSH Manual}). When @var{interfaces} is empty, lshd listens for connections on all the network interfaces; otherwise, @var{interfaces} must be a list of host names or addresses. @var{allow-empty-passwords?} specifies whether to accept log-ins with empty passwords, and @var{root-login?} specifies whether to accept log-ins as root. The other options should be self-descriptive. @end deffn @cindex SSH @cindex SSH server @deffn {Scheme Variable} openssh-service-type This is the type for the @uref{http://www.openssh.org, OpenSSH} secure shell daemon, @command{sshd}. Its value must be an @code{openssh-configuration} record as in this example: @example (service openssh-service-type (openssh-configuration (x11-forwarding? #t) (permit-root-login 'without-password) (authorized-keys `(("alice" ,(local-file "alice.pub")) ("bob" ,(local-file "bob.pub")))))) @end example See below for details about @code{openssh-configuration}. This service can be extended with extra authorized keys, as in this example: @example (service-extension openssh-service-type (const `(("charlie" ,(local-file "charlie.pub"))))) @end example @end deffn @deftp {Data Type} openssh-configuration This is the configuration record for OpenSSH's @command{sshd}. @table @asis @item @code{pid-file} (default: @code{"/var/run/sshd.pid"}) Name of the file where @command{sshd} writes its PID. @item @code{port-number} (default: @code{22}) TCP port on which @command{sshd} listens for incoming connections. @item @code{permit-root-login} (default: @code{#f}) This field determines whether and when to allow logins as root. If @code{#f}, root logins are disallowed; if @code{#t}, they are allowed. If it's the symbol @code{'without-password}, then root logins are permitted but not with password-based authentication. @item @code{allow-empty-passwords?} (default: @code{#f}) When true, users with empty passwords may log in. When false, they may not. @item @code{password-authentication?} (default: @code{#t}) When true, users may log in with their password. When false, they have other authentication methods. @item @code{public-key-authentication?} (default: @code{#t}) When true, users may log in using public key authentication. When false, users have to use other authentication method. Authorized public keys are stored in @file{~/.ssh/authorized_keys}. This is used only by protocol version 2. @item @code{x11-forwarding?} (default: @code{#f}) When true, forwarding of X11 graphical client connections is enabled---in other words, @command{ssh} options @option{-X} and @option{-Y} will work. @item @code{allow-agent-forwarding?} (Vorgabe: @code{#t}) Whether to allow agent forwarding. @item @code{allow-tcp-forwarding?} (Vorgabe: @code{#t}) Whether to allow TCP forwarding. @item @code{gateway-ports?} (Vorgabe: @code{#f}) Whether to allow gateway ports. @item @code{challenge-response-authentication?} (default: @code{#f}) Specifies whether challenge response authentication is allowed (e.g.@: via PAM). @item @code{use-pam?} (default: @code{#t}) Enables the Pluggable Authentication Module interface. If set to @code{#t}, this will enable PAM authentication using @code{challenge-response-authentication?} and @code{password-authentication?}, in addition to PAM account and session module processing for all authentication types. Because PAM challenge response authentication usually serves an equivalent role to password authentication, you should disable either @code{challenge-response-authentication?} or @code{password-authentication?}. @item @code{print-last-log?} (default: @code{#t}) Specifies whether @command{sshd} should print the date and time of the last user login when a user logs in interactively. @item @code{subsystems} (default: @code{'(("sftp" "internal-sftp"))}) Configures external subsystems (e.g.@: file transfer daemon). This is a list of two-element lists, each of which containing the subsystem name and a command (with optional arguments) to execute upon subsystem request. The command @command{internal-sftp} implements an in-process SFTP server. Alternately, one can specify the @command{sftp-server} command: @example (service openssh-service-type (openssh-configuration (subsystems `(("sftp" ,(file-append openssh "/libexec/sftp-server")))))) @end example @item @code{accepted-environment} (default: @code{'()}) List of strings describing which environment variables may be exported. Each string gets on its own line. See the @code{AcceptEnv} option in @code{man sshd_config}. This example allows ssh-clients to export the @code{COLORTERM} variable. It is set by terminal emulators, which support colors. You can use it in your shell's ressource file to enable colors for the prompt and commands if this variable is set. @example (service openssh-service-type (openssh-configuration (accepted-environment '("COLORTERM")))) @end example @item @code{authorized-keys} (default: @code{'()}) @cindex authorized keys, SSH @cindex SSH authorized keys This is the list of authorized keys. Each element of the list is a user name followed by one or more file-like objects that represent SSH public keys. For example: @example (openssh-configuration (authorized-keys `(("rekado" ,(local-file "rekado.pub")) ("chris" ,(local-file "chris.pub")) ("root" ,(local-file "rekado.pub") ,(local-file "chris.pub"))))) @end example @noindent registers the specified public keys for user accounts @code{rekado}, @code{chris}, and @code{root}. Additional authorized keys can be specified @i{via} @code{service-extension}. Note that this does @emph{not} interfere with the use of @file{~/.ssh/authorized_keys}. @item @code{log-level} (Vorgabe: @code{'info}) This is a symbol specifying the logging level: @code{quiet}, @code{fatal}, @code{error}, @code{info}, @code{verbose}, @code{debug}, etc. See the man page for @file{sshd_config} for the full list of level names. @item @code{extra-content} (Vorgabe: @code{""}) This field can be used to append arbitrary text to the configuration file. It is especially useful for elaborate configurations that cannot be expressed otherwise. This configuration, for example, would generally disable root logins, but permit them from one specific IP address: @example (openssh-configuration (extra-content "\ Match Address 192.168.0.1 PermitRootLogin yes")) @end example @end table @end deftp @deffn {Scheme Procedure} dropbear-service [@var{config}] Run the @uref{https://matt.ucc.asn.au/dropbear/dropbear.html,Dropbear SSH daemon} with the given @var{config}, a @code{} object. For example, to specify a Dropbear service listening on port 1234, add this call to the operating system's @code{services} field: @example (dropbear-service (dropbear-configuration (port-number 1234))) @end example @end deffn @deftp {Data Type} dropbear-configuration This data type represents the configuration of a Dropbear SSH daemon. @table @asis @item @code{dropbear} (default: @var{dropbear}) The Dropbear package to use. @item @code{port-number} (default: 22) The TCP port where the daemon waits for incoming connections. @item @code{syslog-output?} (default: @code{#t}) Whether to enable syslog output. @item @code{pid-file} (default: @code{"/var/run/dropbear.pid"}) File name of the daemon's PID file. @item @code{root-login?} (default: @code{#f}) Whether to allow @code{root} logins. @item @code{allow-empty-passwords?} (default: @code{#f}) Whether to allow empty passwords. @item @code{password-authentication?} (default: @code{#t}) Whether to enable password-based authentication. @end table @end deftp @defvr {Scheme Variable} %facebook-host-aliases This variable contains a string for use in @file{/etc/hosts} (@pxref{Host Names,,, libc, The GNU C Library Reference Manual}). Each line contains a entry that maps a known server name of the Facebook on-line service---e.g., @code{www.facebook.com}---to the local host---@code{127.0.0.1} or its IPv6 equivalent, @code{::1}. This variable is typically used in the @code{hosts-file} field of an @code{operating-system} declaration (@pxref{»operating-system«-Referenz, @file{/etc/hosts}}): @example (use-modules (gnu) (guix)) (operating-system (host-name "mymachine") ;; ... (hosts-file ;; Create a /etc/hosts file with aliases for "localhost" ;; and "mymachine", as well as for Facebook servers. (plain-file "hosts" (string-append (local-host-aliases host-name) %facebook-host-aliases)))) @end example This mechanism can prevent programs running locally, such as Web browsers, from accessing Facebook. @end defvr The @code{(gnu services avahi)} provides the following definition. @defvr {Scheme-Variable} avahi-service-type This is the service that runs @command{avahi-daemon}, a system-wide mDNS/DNS-SD responder that allows for service discovery and ``zero-configuration'' host name lookups (see @uref{http://avahi.org/}). Its value must be a @code{zero-configuration} record---see below. This service extends the name service cache daemon (nscd) so that it can resolve @code{.local} host names using @uref{http://0pointer.de/lennart/projects/nss-mdns/, nss-mdns}. @xref{Name Service Switch}, for information on host name resolution. Additionally, add the @var{avahi} package to the system profile so that commands such as @command{avahi-browse} are directly usable. @end defvr @deftp {Datentyp} avahi-configuration Dieser Datentyp repräsentiert die Konfiguration von Avahi. @table @asis @item @code{host-name} (Vorgabe: @code{#f}) If different from @code{#f}, use that as the host name to publish for this machine; otherwise, use the machine's actual host name. @item @code{publish?} (Vorgabe: @code{#t}) When true, allow host names and services to be published (broadcast) over the network. @item @code{publish-workstation?} (Vorgabe: @code{#t}) When true, @command{avahi-daemon} publishes the machine's host name and IP address via mDNS on the local network. To view the host names published on your local network, you can run: @example avahi-browse _workstation._tcp @end example @item @code{wide-area?} (Vorgabe: @code{#f}) When true, DNS-SD over unicast DNS is enabled. @item @code{ipv4?} (Vorgabe: @code{#t}) @itemx @code{ipv6?} (Vorgabe: @code{#t}) These fields determine whether to use IPv4/IPv6 sockets. @item @code{domains-to-browse} (Vorgabe: @code{'()}) This is a list of domains to browse. @end table @end deftp @deffn {Scheme Variable} openvswitch-service-type This is the type of the @uref{http://www.openvswitch.org, Open vSwitch} service, whose value should be an @code{openvswitch-configuration} object. @end deffn @deftp {Data Type} openvswitch-configuration Data type representing the configuration of Open vSwitch, a multilayer virtual switch which is designed to enable massive network automation through programmatic extension. @table @asis @item @code{package} (default: @var{openvswitch}) Package object of the Open vSwitch. @end table @end deftp @node X Window @subsection X Window @cindex X11 @cindex X Window System @cindex login manager Support for the X Window graphical display system---specifically Xorg---is provided by the @code{(gnu services xorg)} module. Note that there is no @code{xorg-service} procedure. Instead, the X server is started by the @dfn{login manager}, by default the GNOME Display Manager (GDM). @cindex GDM @cindex GNOME, login manager GDM of course allows users to log in into window managers and desktop environments other than GNOME; for those using GNOME, GDM is required for features such as automatic screen locking. @cindex window manager To use X11, you must install at least one @dfn{window manager}---for example the @code{windowmaker} or @code{openbox} packages---preferably by adding it to the @code{packages} field of your operating system definition (@pxref{»operating-system«-Referenz, system-wide packages}). @defvr {Scheme-Variable} gdm-service-type This is the type for the @uref{https://wiki.gnome.org/Projects/GDM/, GNOME Desktop Manager} (GDM), a program that manages graphical display servers and handles graphical user logins. Its value must be a @code{gdm-configuration} (see below.) @cindex session types (X11) @cindex X11 session types GDM looks for @dfn{session types} described by the @file{.desktop} files in @file{/run/current-system/profile/share/xsessions} and allows users to choose a session from the log-in screen. Packages such as @code{gnome}, @code{xfce}, and @code{i3} provide @file{.desktop} files; adding them to the system-wide set of packages automatically makes them available at the log-in screen. In addition, @file{~/.xsession} files are honored. When available, @file{~/.xsession} must be an executable that starts a window manager and/or other X clients. @end defvr @deftp {Datentyp} gdm-configuration @table @asis @item @code{auto-login?} (default: @code{#f}) @itemx @code{default-user} (Vorgabe: @code{#f}) When @code{auto-login?} is false, GDM presents a log-in screen. When @code{auto-login?} is true, GDM logs in directly as @code{default-user}. @item @code{gnome-shell-assets} (Vorgabe: …) List of GNOME Shell assets needed by GDM: icon theme, fonts, etc. @item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)}) Xorg-Server für grafische Oberflächen konfigurieren. @item @code{xsession} (Vorgabe: @code{(xinitrc)}) Script to run before starting a X session. @item @code{dbus-daemon} (Vorgabe: @code{dbus-daemon-wrapper}) File name of the @code{dbus-daemon} executable. @item @code{gdm} (Vorgabe: @code{gdm}) Das GDM-Paket, was benutzt werden soll. @end table @end deftp @defvr {Scheme Variable} slim-service-type This is the type for the SLiM graphical login manager for X11. Like GDM, SLiM looks for session types described by @file{.desktop} files and allows users to choose a session from the log-in screen using @kbd{F1}. It also honors @file{~/.xsession} files. @end defvr @deftp {Data Type} slim-configuration Data type representing the configuration of @code{slim-service-type}. @table @asis @item @code{allow-empty-passwords?} (Vorgabe: @code{#t}) Whether to allow logins with empty passwords. @item @code{auto-login?} (default: @code{#f}) @itemx @code{default-user} (default: @code{""}) When @code{auto-login?} is false, SLiM presents a log-in screen. When @code{auto-login?} is true, SLiM logs in directly as @code{default-user}. @item @code{theme} (default: @code{%default-slim-theme}) @itemx @code{theme-name} (default: @code{%default-slim-theme-name}) The graphical theme to use and its name. @item @code{auto-login-session} (default: @code{#f}) If true, this must be the name of the executable to start as the default session---e.g., @code{(file-append windowmaker "/bin/windowmaker")}. If false, a session described by one of the available @file{.desktop} files in @code{/run/current-system/profile} and @code{~/.guix-profile} will be used. @quotation Anmerkung You must install at least one window manager in the system profile or in your user profile. Failing to do that, if @code{auto-login-session} is false, you will be unable to log in. @end quotation @item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)}) Xorg-Server für grafische Oberflächen konfigurieren. @item @code{xauth} (default: @code{xauth}) The XAuth package to use. @item @code{shepherd} (default: @code{shepherd}) The Shepherd package used when invoking @command{halt} and @command{reboot}. @item @code{sessreg} (default: @code{sessreg}) The sessreg package used in order to register the session. @item @code{slim} (default: @code{slim}) The SLiM package to use. @end table @end deftp @defvr {Scheme Variable} %default-theme @defvrx {Scheme Variable} %default-theme-name The default SLiM theme and its name. @end defvr @deftp {Data Type} sddm-configuration This is the data type representing the sddm service configuration. @table @asis @item @code{display-server} (default: "x11") Select display server to use for the greeter. Valid values are "x11" or "wayland". @item @code{numlock} (default: "on") Valid values are "on", "off" or "none". @item @code{halt-command} (default @code{#~(string-apppend #$shepherd "/sbin/halt")}) Command to run when halting. @item @code{reboot-command} (default @code{#~(string-append #$shepherd "/sbin/reboot")}) Command to run when rebooting. @item @code{theme} (default "maldives") Theme to use. Default themes provided by SDDM are "elarun" or "maldives". @item @code{themes-directory} (default "/run/current-system/profile/share/sddm/themes") Directory to look for themes. @item @code{faces-directory} (default "/run/current-system/profile/share/sddm/faces") Directory to look for faces. @item @code{default-path} (default "/run/current-system/profile/bin") Default PATH to use. @item @code{minimum-uid} (default 1000) Minimum UID to display in SDDM. @item @code{maximum-uid} (default 2000) Maximum UID to display in SDDM @item @code{remember-last-user?} (default #t) Remember last user. @item @code{remember-last-session?} (default #t) Remember last session. @item @code{hide-users} (default "") Usernames to hide from SDDM greeter. @item @code{hide-shells} (default @code{#~(string-append #$shadow "/sbin/nologin")}) Users with shells listed will be hidden from the SDDM greeter. @item @code{session-command} (default @code{#~(string-append #$sddm "/share/sddm/scripts/wayland-session")}) Script to run before starting a wayland session. @item @code{sessions-directory} (default "/run/current-system/profile/share/wayland-sessions") Directory to look for desktop files starting wayland sessions. @item @code{xorg-configuration} (Vorgabe: @code{(xorg-configuration)}) Xorg-Server für grafische Oberflächen konfigurieren. @item @code{xauth-path} (default @code{#~(string-append #$xauth "/bin/xauth")}) Path to xauth. @item @code{xephyr-path} (default @code{#~(string-append #$xorg-server "/bin/Xephyr")}) Path to Xephyr. @item @code{xdisplay-start} (default @code{#~(string-append #$sddm "/share/sddm/scripts/Xsetup")}) Script to run after starting xorg-server. @item @code{xdisplay-stop} (default @code{#~(string-append #$sddm "/share/sddm/scripts/Xstop")}) Script to run before stopping xorg-server. @item @code{xsession-command} (Vorgabe: @code{xinitrc}) Script to run before starting a X session. @item @code{xsessions-directory} (default: "/run/current-system/profile/share/xsessions") Directory to look for desktop files starting X sessions. @item @code{minimum-vt} (default: 7) Minimum VT to use. @item @code{auto-login-user} (default "") User to use for auto-login. @item @code{auto-login-session} (default "") Desktop file to use for auto-login. @item @code{relogin?} (default #f) Relogin after logout. @end table @end deftp @cindex login manager @cindex X11 login @deffn {Scheme Procedure} sddm-service config Return a service that spawns the SDDM graphical login manager for config of type @code{}. @example (sddm-service (sddm-configuration (auto-login-user "Alice") (auto-login-session "xfce.desktop"))) @end example @end deffn @cindex Xorg, Konfiguration @deftp {Datentyp} xorg-configuration This data type represents the configuration of the Xorg graphical display server. Note that there is not Xorg service; instead, the X server is started by a ``display manager'' such as GDM, SDDM, and SLiM. Thus, the configuration of these display managers aggregates an @code{xorg-configuration} record. @table @asis @item @code{modules} (Vorgabe: @code{%default-xorg-modules}) This is a list of @dfn{module packages} loaded by the Xorg server---e.g., @code{xf86-video-vesa}, @code{xf86-input-keyboard}, and so on. @item @code{fonts} (Vorgabe: @code{%default-xorg-fonts}) This is a list of font directories to add to the server's @dfn{font path}. @item @code{drivers} (Vorgabe: @code{'()}) This must be either the empty list, in which case Xorg chooses a graphics driver automatically, or a list of driver names that will be tried in this order---e.g., @code{("modesetting" "vesa")}. @item @code{resolutions} (Vorgabe: @code{'()}) When @code{resolutions} is the empty list, Xorg chooses an appropriate screen resolution. Otherwise, it must be a list of resolutions---e.g., @code{((1024 768) (640 480))}. @cindex Tastaturbelegung, für Xorg @cindex keymap, for Xorg @item @code{keyboard-layout} (Vorgabe: @code{#f}) If this is @code{#f}, Xorg uses the default keyboard layout---usually US English (``qwerty'') for a 105-key PC keyboard. Otherwise this must be a @code{keyboard-layout} object specifying the keyboard layout in use when Xorg is running. @xref{Tastaturbelegung}, for more information on how to specify the keyboard layout. @item @code{extra-config} (Vorgabe: @code{'()}) This is a list of strings or objects appended to the configuration file. It is used to pass extra text to be added verbatim to the configuration file. @item @code{server} (Vorgabe: @code{xorg-server}) This is the package providing the Xorg server. @item @code{server-arguments} (Vorgabe: @code{%default-xorg-server-arguments}) This is the list of command-line arguments to pass to the X server. The default is @code{-nolisten tcp}. @end table @end deftp @deffn {Scheme-Prozedur} set-xorg-configuration @var{Konfiguration} @ [@var{login-manager-service-type}] Tell the log-in manager (of type @var{login-manager-service-type}) to use @var{config}, an record. Since the Xorg configuration is embedded in the log-in manager's configuration---e.g., @code{gdm-configuration}---this procedure provides a shorthand to set the Xorg configuration. @end deffn @deffn {Scheme-Prozedur} xorg-start-command [@var{Konfiguration}] Return a @code{startx} script in which the modules, fonts, etc. specified in @var{config}, are available. The result should be used in place of @code{startx}. Usually the X server is started by a login manager. @end deffn @deffn {Scheme Procedure} screen-locker-service @var{package} [@var{program}] Add @var{package}, a package for a screen locker or screen saver whose command is @var{program}, to the set of setuid programs and add a PAM entry for it. For example: @lisp (screen-locker-service xlockmore "xlock") @end lisp makes the good ol' XlockMore usable. @end deffn @node Druckdienste @subsection Druckdienste @cindex printer support with CUPS Das Modul @code{(gnu services cups)} stellt eine Guix-Dienstdefinition für den CUPS-Druckdienst zur Verfügung. Wenn Sie Druckerunterstützung zu einem Guix-System hinzufügen möchten, dann fügen Sie einen @code{cups-service}-Dienst in die Betriebssystemdefinition ein. @deffn {Scheme Variable} cups-service-type The service type for the CUPS print server. Its value should be a valid CUPS configuration (see below). To use the default settings, simply write: @example (service cups-service-type) @end example @end deffn The CUPS configuration controls the basic things about your CUPS installation: what interfaces it listens on, what to do if a print job fails, how much logging to do, and so on. To actually add a printer, you have to visit the @url{http://localhost:631} URL, or use a tool such as GNOME's printer configuration services. By default, configuring a CUPS service will generate a self-signed certificate if needed, for secure connections to the print server. Suppose you want to enable the Web interface of CUPS and also add support for Epson printers @i{via} the @code{escpr} package and for HP printers @i{via} the @code{hplip-minimal} package. You can do that directly, like this (you need to use the @code{(gnu packages cups)} module): @example (service cups-service-type (cups-configuration (web-interface? #t) (extensions (list cups-filters escpr hplip-minimal)))) @end example Note: If you wish to use the Qt5 based GUI which comes with the hplip package then it is suggested that you install the @code{hplip} package, either in your OS configuration file or as your user. The available configuration parameters follow. Each parameter definition is preceded by its type; for example, @samp{string-list foo} indicates that the @code{foo} parameter should be specified as a list of strings. There is also a way to specify the configuration as a string, if you have an old @code{cupsd.conf} file that you want to port over from some other system; see the end for more details. @c The following documentation was initially generated by @c (generate-documentation) in (gnu services cups). Manually maintained @c documentation is better, so we shouldn't hesitate to edit below as @c needed. However if the change you want to make to this documentation @c can be done in an automated way, it's probably easier to change @c (generate-documentation) than to make it below and have to deal with @c the churn as CUPS updates. Available @code{cups-configuration} fields are: @deftypevr {@code{cups-configuration} parameter} package cups The CUPS package. @end deftypevr @deftypevr {@code{cups-configuration} parameter} package-list extensions Drivers and other extensions to the CUPS package. @end deftypevr @deftypevr {@code{cups-configuration} parameter} files-configuration files-configuration Configuration of where to write logs, what directories to use for print spools, and related privileged configuration parameters. Available @code{files-configuration} fields are: @deftypevr {@code{files-configuration} parameter} log-location access-log Defines the access log filename. Specifying a blank filename disables access log generation. The value @code{stderr} causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background. The value @code{syslog} causes log entries to be sent to the system log daemon. The server name may be included in filenames using the string @code{%s}, as in @code{/var/log/cups/%s-access_log}. Defaults to @samp{"/var/log/cups/access_log"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} file-name cache-dir Where CUPS should cache data. Defaults to @samp{"/var/cache/cups"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string config-file-perm Specifies the permissions for all configuration files that the scheduler writes. Note that the permissions for the printers.conf file are currently masked to only allow access from the scheduler user (typically root). This is done because printer device URIs sometimes contain sensitive authentication information that should not be generally known on the system. There is no way to disable this security feature. Defaults to @samp{"0640"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} log-location error-log Defines the error log filename. Specifying a blank filename disables access log generation. The value @code{stderr} causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background. The value @code{syslog} causes log entries to be sent to the system log daemon. The server name may be included in filenames using the string @code{%s}, as in @code{/var/log/cups/%s-error_log}. Defaults to @samp{"/var/log/cups/error_log"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string fatal-errors Specifies which errors are fatal, causing the scheduler to exit. The kind strings are: @table @code @item none No errors are fatal. @item all All of the errors below are fatal. @item browse Browsing initialization errors are fatal, for example failed connections to the DNS-SD daemon. @item config Configuration file syntax errors are fatal. @item listen Listen or Port errors are fatal, except for IPv6 failures on the loopback or @code{any} addresses. @item log Log file creation or write errors are fatal. @item permissions Bad startup file permissions are fatal, for example shared TLS certificate and key files with world-read permissions. @end table Defaults to @samp{"all -browse"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} boolean file-device? Specifies whether the file pseudo-device can be used for new printer queues. The URI @uref{file:///dev/null} is always allowed. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string group Specifies the group name or ID that will be used when executing external programs. Defaults to @samp{"lp"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string log-file-perm Specifies the permissions for all log files that the scheduler writes. Defaults to @samp{"0644"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} log-location page-log Defines the page log filename. Specifying a blank filename disables access log generation. The value @code{stderr} causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background. The value @code{syslog} causes log entries to be sent to the system log daemon. The server name may be included in filenames using the string @code{%s}, as in @code{/var/log/cups/%s-page_log}. Defaults to @samp{"/var/log/cups/page_log"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string remote-root Specifies the username that is associated with unauthenticated accesses by clients claiming to be the root user. The default is @code{remroot}. Defaults to @samp{"remroot"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} file-name request-root Specifies the directory that contains print jobs and other HTTP request data. Defaults to @samp{"/var/spool/cups"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} sandboxing sandboxing Specifies the level of security sandboxing that is applied to print filters, backends, and other child processes of the scheduler; either @code{relaxed} or @code{strict}. This directive is currently only used/supported on macOS. Defaults to @samp{strict}. @end deftypevr @deftypevr {@code{files-configuration} parameter} file-name server-keychain Specifies the location of TLS certificates and private keys. CUPS will look for public and private keys in this directory: a @code{.crt} files for PEM-encoded certificates and corresponding @code{.key} files for PEM-encoded private keys. Defaults to @samp{"/etc/cups/ssl"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} file-name server-root Specifies the directory containing the server configuration files. Defaults to @samp{"/etc/cups"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} boolean sync-on-close? Specifies whether the scheduler calls fsync(2) after writing configuration or state files. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{files-configuration} parameter} space-separated-string-list system-group Specifies the group(s) to use for @code{@@SYSTEM} group authentication. @end deftypevr @deftypevr {@code{files-configuration} parameter} file-name temp-dir Specifies the directory where temporary files are stored. Defaults to @samp{"/var/spool/cups/tmp"}. @end deftypevr @deftypevr {@code{files-configuration} parameter} string user Specifies the user name or ID that is used when running external programs. Defaults to @samp{"lp"}. @end deftypevr @end deftypevr @deftypevr {@code{cups-configuration} parameter} access-log-level access-log-level Specifies the logging level for the AccessLog file. The @code{config} level logs when printers and classes are added, deleted, or modified and when configuration files are accessed or updated. The @code{actions} level logs when print jobs are submitted, held, released, modified, or canceled, and any of the conditions for @code{config}. The @code{all} level logs all requests. Defaults to @samp{actions}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean auto-purge-jobs? Specifies whether to purge job history data automatically when it is no longer required for quotas. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} browse-local-protocols browse-local-protocols Specifies which protocols to use for local printer sharing. Defaults to @samp{dnssd}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean browse-web-if? Specifies whether the CUPS web interface is advertised. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean browsing? Specifies whether shared printers are advertised. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string classification Specifies the security classification of the server. Any valid banner name can be used, including "classified", "confidential", "secret", "topsecret", and "unclassified", or the banner can be omitted to disable secure printing functions. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean classify-override? Specifies whether users may override the classification (cover page) of individual print jobs using the @code{job-sheets} option. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} default-auth-type default-auth-type Specifies the default type of authentication to use. Defaults to @samp{Basic}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} default-encryption default-encryption Specifies whether encryption will be used for authenticated requests. Defaults to @samp{Required}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string default-language Specifies the default language to use for text and web content. Defaults to @samp{"en"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string default-paper-size Specifies the default paper size for new print queues. @samp{"Auto"} uses a locale-specific default, while @samp{"None"} specifies there is no default paper size. Specific size names are typically @samp{"Letter"} or @samp{"A4"}. Defaults to @samp{"Auto"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string default-policy Specifies the default access policy to use. Defaults to @samp{"default"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean default-shared? Specifies whether local printers are shared by default. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer dirty-clean-interval Specifies the delay for updating of configuration and state files, in seconds. A value of 0 causes the update to happen as soon as possible, typically within a few milliseconds. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} error-policy error-policy Specifies what to do when an error occurs. Possible values are @code{abort-job}, which will discard the failed print job; @code{retry-job}, which will retry the job at a later time; @code{retry-this-job}, which retries the failed job immediately; and @code{stop-printer}, which stops the printer. Defaults to @samp{stop-printer}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer filter-limit Specifies the maximum cost of filters that are run concurrently, which can be used to minimize disk, memory, and CPU resource problems. A limit of 0 disables filter limiting. An average print to a non-PostScript printer needs a filter limit of about 200. A PostScript printer needs about half that (100). Setting the limit below these thresholds will effectively limit the scheduler to printing a single job at any time. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer filter-nice Specifies the scheduling priority of filters that are run to print a job. The nice value ranges from 0, the highest priority, to 19, the lowest priority. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} host-name-lookups host-name-lookups Specifies whether to do reverse lookups on connecting clients. The @code{double} setting causes @code{cupsd} to verify that the hostname resolved from the address matches one of the addresses returned for that hostname. Double lookups also prevent clients with unregistered addresses from connecting to your server. Only set this option to @code{#t} or @code{double} if absolutely required. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer job-kill-delay Specifies the number of seconds to wait before killing the filters and backend associated with a canceled or held job. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer job-retry-interval Specifies the interval between retries of jobs in seconds. This is typically used for fax queues but can also be used with normal print queues whose error policy is @code{retry-job} or @code{retry-current-job}. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer job-retry-limit Specifies the number of retries that are done for jobs. This is typically used for fax queues but can also be used with normal print queues whose error policy is @code{retry-job} or @code{retry-current-job}. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean keep-alive? Specifies whether to support HTTP keep-alive connections. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer keep-alive-timeout Specifies how long an idle client connection remains open, in seconds. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer limit-request-body Specifies the maximum size of print files, IPP requests, and HTML form data. A limit of 0 disables the limit check. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} multiline-string-list listen Listens on the specified interfaces for connections. Valid values are of the form @var{address}:@var{port}, where @var{address} is either an IPv6 address enclosed in brackets, an IPv4 address, or @code{*} to indicate all addresses. Values can also be file names of local UNIX domain sockets. The Listen directive is similar to the Port directive but allows you to restrict access to specific interfaces or networks. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer listen-back-log Specifies the number of pending connections that will be allowed. This normally only affects very busy servers that have reached the MaxClients limit, but can also be triggered by large numbers of simultaneous connections. When the limit is reached, the operating system will refuse additional connections until the scheduler can accept the pending ones. Defaults to @samp{128}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} location-access-control-list location-access-controls Specifies a set of additional access controls. Available @code{location-access-controls} fields are: @deftypevr {@code{location-access-controls} parameter} file-name path Specifies the URI path to which the access control applies. @end deftypevr @deftypevr {@code{location-access-controls} parameter} access-control-list access-controls Access controls for all access to this path, in the same format as the @code{access-controls} of @code{operation-access-control}. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{location-access-controls} parameter} method-access-control-list method-access-controls Access controls for method-specific access to this path. Defaults to @samp{()}. Available @code{method-access-controls} fields are: @deftypevr {@code{method-access-controls} parameter} boolean reverse? If @code{#t}, apply access controls to all methods except the listed methods. Otherwise apply to only the listed methods. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{method-access-controls} parameter} method-list methods Methods to which this access control applies. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{method-access-controls} parameter} access-control-list access-controls Access control directives, as a list of strings. Each string should be one directive, such as "Order allow,deny". Defaults to @samp{()}. @end deftypevr @end deftypevr @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer log-debug-history Specifies the number of debugging messages that are retained for logging if an error occurs in a print job. Debug messages are logged regardless of the LogLevel setting. Defaults to @samp{100}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} log-level log-level Specifies the level of logging for the ErrorLog file. The value @code{none} stops all logging while @code{debug2} logs everything. Defaults to @samp{info}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} log-time-format log-time-format Specifies the format of the date and time in the log files. The value @code{standard} logs whole seconds while @code{usecs} logs microseconds. Defaults to @samp{standard}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-clients Specifies the maximum number of simultaneous clients that are allowed by the scheduler. Defaults to @samp{100}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-clients-per-host Specifies the maximum number of simultaneous clients that are allowed from a single address. Defaults to @samp{100}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-copies Specifies the maximum number of copies that a user can print of each job. Defaults to @samp{9999}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-hold-time Specifies the maximum time a job may remain in the @code{indefinite} hold state before it is canceled. A value of 0 disables cancellation of held jobs. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs Specifies the maximum number of simultaneous jobs that are allowed. Set to 0 to allow an unlimited number of jobs. Defaults to @samp{500}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs-per-printer Specifies the maximum number of simultaneous jobs that are allowed per printer. A value of 0 allows up to MaxJobs jobs per printer. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-jobs-per-user Specifies the maximum number of simultaneous jobs that are allowed per user. A value of 0 allows up to MaxJobs jobs per user. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-job-time Specifies the maximum time a job may take to print before it is canceled, in seconds. Set to 0 to disable cancellation of "stuck" jobs. Defaults to @samp{10800}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer max-log-size Specifies the maximum size of the log files before they are rotated, in bytes. The value 0 disables log rotation. Defaults to @samp{1048576}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer multiple-operation-timeout Specifies the maximum amount of time to allow between files in a multiple file print job, in seconds. Defaults to @samp{300}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string page-log-format Specifies the format of PageLog lines. Sequences beginning with percent (@samp{%}) characters are replaced with the corresponding information, while all other characters are copied literally. The following percent sequences are recognized: @table @samp @item %% insert a single percent character @item %@{name@} insert the value of the specified IPP attribute @item %C insert the number of copies for the current page @item %P insert the current page number @item %T insert the current date and time in common log format @item %j insert the job ID @item %p insert the printer name @item %u insert the username @end table A value of the empty string disables page logging. The string @code{%p %u %j %T %P %C %@{job-billing@} %@{job-originating-host-name@} %@{job-name@} %@{media@} %@{sides@}} creates a page log with the standard items. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} environment-variables environment-variables Passes the specified environment variable(s) to child processes; a list of strings. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} policy-configuration-list policies Specifies named access control policies. Available @code{policy-configuration} fields are: @deftypevr {@code{policy-configuration} parameter} string name Name of the policy. @end deftypevr @deftypevr {@code{policy-configuration} parameter} string job-private-access Specifies an access list for a job's private values. @code{@@ACL} maps to the printer's requesting-user-name-allowed or requesting-user-name-denied values. @code{@@OWNER} maps to the job's owner. @code{@@SYSTEM} maps to the groups listed for the @code{system-group} field of the @code{files-config} configuration, which is reified into the @code{cups-files.conf(5)} file. Other possible elements of the access list include specific user names, and @code{@@@var{group}} to indicate members of a specific group. The access list may also be simply @code{all} or @code{default}. Defaults to @samp{"@@OWNER @@SYSTEM"}. @end deftypevr @deftypevr {@code{policy-configuration} parameter} string job-private-values Specifies the list of job values to make private, or @code{all}, @code{default}, or @code{none}. Defaults to @samp{"job-name job-originating-host-name job-originating-user-name phone"}. @end deftypevr @deftypevr {@code{policy-configuration} parameter} string subscription-private-access Specifies an access list for a subscription's private values. @code{@@ACL} maps to the printer's requesting-user-name-allowed or requesting-user-name-denied values. @code{@@OWNER} maps to the job's owner. @code{@@SYSTEM} maps to the groups listed for the @code{system-group} field of the @code{files-config} configuration, which is reified into the @code{cups-files.conf(5)} file. Other possible elements of the access list include specific user names, and @code{@@@var{group}} to indicate members of a specific group. The access list may also be simply @code{all} or @code{default}. Defaults to @samp{"@@OWNER @@SYSTEM"}. @end deftypevr @deftypevr {@code{policy-configuration} parameter} string subscription-private-values Specifies the list of job values to make private, or @code{all}, @code{default}, or @code{none}. Defaults to @samp{"notify-events notify-pull-method notify-recipient-uri notify-subscriber-user-name notify-user-data"}. @end deftypevr @deftypevr {@code{policy-configuration} parameter} operation-access-control-list access-controls Access control by IPP operation. Defaults to @samp{()}. @end deftypevr @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean-or-non-negative-integer preserve-job-files Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. Otherwise a boolean value applies indefinitely. Defaults to @samp{86400}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean-or-non-negative-integer preserve-job-history Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If @code{#t}, the job history is preserved until the MaxJobs limit is reached. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer reload-timeout Specifies the amount of time to wait for job completion before restarting the scheduler. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string rip-cache Specifies the maximum amount of memory to use when converting documents into bitmaps for a printer. Defaults to @samp{"128m"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string server-admin Specifies the email address of the server administrator. Defaults to @samp{"root@@localhost.localdomain"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} host-name-list-or-* server-alias The ServerAlias directive is used for HTTP Host header validation when clients connect to the scheduler from external interfaces. Using the special name @code{*} can expose your system to known browser-based DNS rebinding attacks, even when accessing sites through a firewall. If the auto-discovery of alternate names does not work, we recommend listing each alternate name with a ServerAlias directive instead of using @code{*}. Defaults to @samp{*}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string server-name Specifies the fully-qualified host name of the server. Defaults to @samp{"localhost"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} server-tokens server-tokens Specifies what information is included in the Server header of HTTP responses. @code{None} disables the Server header. @code{ProductOnly} reports @code{CUPS}. @code{Major} reports @code{CUPS 2}. @code{Minor} reports @code{CUPS 2.0}. @code{Minimal} reports @code{CUPS 2.0.0}. @code{OS} reports @code{CUPS 2.0.0 (@var{uname})} where @var{uname} is the output of the @code{uname} command. @code{Full} reports @code{CUPS 2.0.0 (@var{uname}) IPP/2.0}. Defaults to @samp{Minimal}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} string set-env Set the specified environment variable to be passed to child processes. Defaults to @samp{"variable value"}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} multiline-string-list ssl-listen Listens on the specified interfaces for encrypted connections. Valid values are of the form @var{address}:@var{port}, where @var{address} is either an IPv6 address enclosed in brackets, an IPv4 address, or @code{*} to indicate all addresses. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} ssl-options ssl-options Sets encryption options. By default, CUPS only supports encryption using TLS v1.0 or higher using known secure cipher suites. The @code{AllowRC4} option enables the 128-bit RC4 cipher suites, which are required for some older clients that do not implement newer ones. The @code{AllowSSL3} option enables SSL v3.0, which is required for some older clients that do not support TLS v1.0. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean strict-conformance? Specifies whether the scheduler requires clients to strictly adhere to the IPP specifications. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} non-negative-integer timeout Specifies the HTTP request timeout, in seconds. Defaults to @samp{300}. @end deftypevr @deftypevr {@code{cups-configuration} parameter} boolean web-interface? Specifies whether the web interface is enabled. Defaults to @samp{#f}. @end deftypevr At this point you're probably thinking ``oh dear, Guix manual, I like you but you can stop already with the configuration options''. Indeed. However, one more point: it could be that you have an existing @code{cupsd.conf} that you want to use. In that case, you can pass an @code{opaque-cups-configuration} as the configuration of a @code{cups-service-type}. Available @code{opaque-cups-configuration} fields are: @deftypevr {@code{opaque-cups-configuration} parameter} package cups The CUPS package. @end deftypevr @deftypevr {@code{opaque-cups-configuration} parameter} string cupsd.conf The contents of the @code{cupsd.conf}, as a string. @end deftypevr @deftypevr {@code{opaque-cups-configuration} parameter} string cups-files.conf The contents of the @code{cups-files.conf} file, as a string. @end deftypevr For example, if your @code{cupsd.conf} and @code{cups-files.conf} are in strings of the same name, you could instantiate a CUPS service like this: @example (service cups-service-type (opaque-cups-configuration (cupsd.conf cupsd.conf) (cups-files.conf cups-files.conf))) @end example @node Desktop-Dienste @subsection Desktop-Dienste The @code{(gnu services desktop)} module provides services that are usually useful in the context of a ``desktop'' setup---that is, on a machine running a graphical display server, possibly with graphical user interfaces, etc. It also defines services that provide specific desktop environments like GNOME, Xfce or MATE. To simplify things, the module defines a variable containing the set of services that users typically expect on a machine with a graphical environment and networking: @defvr {Scheme Variable} %desktop-services This is a list of services that builds upon @var{%base-services} and adds or adjusts services for a typical ``desktop'' setup. In particular, it adds a graphical login manager (@pxref{X Window, @code{gdm-service-type}}), screen lockers, a network management tool (@pxref{Netzwerkdienste, @code{network-manager-service-type}}), energy and color management services, the @code{elogind} login and seat manager, the Polkit privilege service, the GeoClue location service, the AccountsService daemon that allows authorized users change system passwords, an NTP client (@pxref{Netzwerkdienste}), the Avahi daemon, and has the name service switch service configured to be able to use @code{nss-mdns} (@pxref{Name Service Switch, mDNS}). @end defvr The @var{%desktop-services} variable can be used as the @code{services} field of an @code{operating-system} declaration (@pxref{»operating-system«-Referenz, @code{services}}). Additionally, the @code{gnome-desktop-service-type}, @code{xfce-desktop-service}, @code{mate-desktop-service-type} and @code{enlightenment-desktop-service-type} procedures can add GNOME, Xfce, MATE and/or Enlightenment to a system. To ``add GNOME'' means that system-level services like the backlight adjustment helpers and the power management utilities are added to the system, extending @code{polkit} and @code{dbus} appropriately, allowing GNOME to operate with elevated privileges on a limited number of special-purpose system interfaces. Additionally, adding a service made by @code{gnome-desktop-service-type} adds the GNOME metapackage to the system profile. Likewise, adding the Xfce service not only adds the @code{xfce} metapackage to the system profile, but it also gives the Thunar file manager the ability to open a ``root-mode'' file management window, if the user authenticates using the administrator's password via the standard polkit graphical interface. To ``add MATE'' means that @code{polkit} and @code{dbus} are extended appropriately, allowing MATE to operate with elevated privileges on a limited number of special-purpose system interfaces. Additionally, adding a service of type @code{mate-desktop-service-type} adds the MATE metapackage to the system profile. ``Adding Enlightenment'' means that @code{dbus} is extended appropriately, and several of Enlightenment's binaries are set as setuid, allowing Enlightenment's screen locker and other functionality to work as expetected. The desktop environments in Guix use the Xorg display server by default. If you'd like to use the newer display server protocol called Wayland, you need to use the @code{sddm-service} instead of GDM as the graphical login manager. You should then select the ``GNOME (Wayland)'' session in SDDM. Alternatively you can also try starting GNOME on Wayland manually from a TTY with the command ``XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session``. Currently only GNOME has support for Wayland. @defvr {Scheme-Variable} gnome-desktop-service-type Dies ist der Typ des Dienstes, der die @uref{https://www.gnome.org, GNOME}-Arbeitsumgebung bereitstellt. Sein Wert ist ein @code{gnome-desktop-configuration}-Objekt (siehe unten). This service adds the @code{gnome} package to the system profile, and extends polkit with the actions from @code{gnome-settings-daemon}. @end defvr @deftp {Datentyp} gnome-desktop-configuration Configuration record for the GNOME desktop environment. @table @asis @item @code{gnome} (Vorgabe: @code{gnome}) Welches GNOME-Paket benutzt werden soll. @end table @end deftp @defvr {Scheme-Variable} xfce-desktop-service-type Der Typ des Dienstes, um die @uref{Xfce, https://xfce.org/}-Arbeitsumgebung auszuführen. Sein Wert ist ein @code{xfce-desktop-configuration}-Objekt (siehe unten). This service that adds the @code{xfce} package to the system profile, and extends polkit with the ability for @code{thunar} to manipulate the file system as root from within a user session, after the user has authenticated with the administrator's password. @end defvr @deftp {Datentyp} xfce-desktop-configuration Verbundstyp für Einstellungen zur Xfce-Arbeitsumgebung. @table @asis @item @code{xfce} (Vorgabe: @code{xfce}) Das Xfce-Paket, was benutzt werden soll. @end table @end deftp @deffn {Scheme-Variable} mate-desktop-service-type Dies ist der Typ des Dienstes, um die @uref{https://mate-desktop.org/, MATE-Arbeitsumgebung} auszuführen. Sein Wert ist ein @code{mate-desktop-configuration}-Objekt (siehe unten). This service adds the @code{mate} package to the system profile, and extends polkit with the actions from @code{mate-settings-daemon}. @end deffn @deftp {Datentyp} mate-desktop-configuration Verbundstyp für die Einstellungen der MATE-Arbeitsumgebung. @table @asis @item @code{mate} (Vorgabe: @code{mate}) Das MATE-Paket, was benutzt werden soll. @end table @end deftp @deffn {Scheme-Variable} enlightenment-desktop-service-type Return a service that adds the @code{enlightenment} package to the system profile, and extends dbus with actions from @code{efl}. @end deffn @deftp {Data Type} enlightenment-desktop-service-configuration @table @asis @item @code{enlightenment} (Vorgabe: @code{enlightenment}) Das Enlightenment-Paket, was benutzt werden soll. @end table @end deftp Because the GNOME, Xfce and MATE desktop services pull in so many packages, the default @code{%desktop-services} variable doesn't include any of them by default. To add GNOME, Xfce or MATE, just @code{cons} them onto @code{%desktop-services} in the @code{services} field of your @code{operating-system}: @example (use-modules (gnu)) (use-service-modules desktop) (operating-system ... ;; cons* adds items to the list given as its last argument. (services (cons* (service gnome-desktop-service-type) (service xfce-desktop-service) %desktop-services)) ...) @end example These desktop environments will then be available as options in the graphical login window. The actual service definitions included in @code{%desktop-services} and provided by @code{(gnu services dbus)} and @code{(gnu services desktop)} are described below. @deffn {Scheme Procedure} dbus-service [#:dbus @var{dbus}] [#:services '()] Return a service that runs the ``system bus'', using @var{dbus}, with support for @var{services}. @uref{http://dbus.freedesktop.org/, D-Bus} is an inter-process communication facility. Its system bus is used to allow system services to communicate and to be notified of system-wide events. @var{services} must be a list of packages that provide an @file{etc/dbus-1/system.d} directory containing additional D-Bus configuration and policy files. For example, to allow avahi-daemon to use the system bus, @var{services} must be equal to @code{(list avahi)}. @end deffn @deffn {Scheme Procedure} elogind-service [#:config @var{config}] Return a service that runs the @code{elogind} login and seat management daemon. @uref{https://github.com/elogind/elogind, Elogind} exposes a D-Bus interface that can be used to know which users are logged in, know what kind of sessions they have open, suspend the system, inhibit system suspend, reboot the system, and other tasks. Elogind handles most system-level power events for a computer, for example suspending the system when a lid is closed, or shutting it down when the power button is pressed. The @var{config} keyword argument specifies the configuration for elogind, and should be the result of an @code{(elogind-configuration (@var{parameter} @var{value})...)} invocation. Available parameters and their default values are: @table @code @item kill-user-processes? @code{#f} @item kill-only-users @code{()} @item kill-exclude-users @code{("root")} @item inhibit-delay-max-seconds @code{5} @item handle-power-key @code{poweroff} @item handle-suspend-key @code{suspend} @item handle-hibernate-key @code{hibernate} @item handle-lid-switch @code{suspend} @item handle-lid-switch-docked @code{ignore} @item power-key-ignore-inhibited? @code{#f} @item suspend-key-ignore-inhibited? @code{#f} @item hibernate-key-ignore-inhibited? @code{#f} @item lid-switch-ignore-inhibited? @code{#t} @item holdoff-timeout-seconds @code{30} @item idle-action @code{ignore} @item idle-action-seconds @code{(* 30 60)} @item runtime-directory-size-percent @code{10} @item runtime-directory-size @code{#f} @item remove-ipc? @code{#t} @item suspend-state @code{("mem" "standby" "freeze")} @item suspend-mode @code{()} @item hibernate-state @code{("disk")} @item hibernate-mode @code{("platform" "shutdown")} @item hybrid-sleep-state @code{("disk")} @item hybrid-sleep-mode @code{("suspend" "platform" "shutdown")} @end table @end deffn @deffn {Scheme Procedure} accountsservice-service @ [#:accountsservice @var{accountsservice}] Return a service that runs AccountsService, a system service that can list available accounts, change their passwords, and so on. AccountsService integrates with PolicyKit to enable unprivileged users to acquire the capability to modify their system configuration. @uref{https://www.freedesktop.org/wiki/Software/AccountsService/, the accountsservice web site} for more information. The @var{accountsservice} keyword argument is the @code{accountsservice} package to expose as a service. @end deffn @deffn {Scheme Procedure} polkit-service @ [#:polkit @var{polkit}] Return a service that runs the @uref{http://www.freedesktop.org/wiki/Software/polkit/, Polkit privilege management service}, which allows system administrators to grant access to privileged operations in a structured way. By querying the Polkit service, a privileged system component can know when it should grant additional capabilities to ordinary users. For example, an ordinary user can be granted the capability to suspend the system if the user is logged in locally. @end deffn @defvr {Scheme-Variable} upower-service-type Service that runs @uref{http://upower.freedesktop.org/, @command{upowerd}}, a system-wide monitor for power consumption and battery levels, with the given configuration settings. It implements the @code{org.freedesktop.UPower} D-Bus interface, and is notably used by GNOME. @end defvr @deftp {Datentyp} upower-configuration Repräsentiert die Konfiguration von UPower. @table @asis @item @code{upower} (Vorgabe: @var{upower}) Package to use for @code{upower}. @item @code{watts-up-pro?} (Vorgabe: @code{#f}) Enable the Watts Up Pro device. @item @code{poll-batteries?} (Vorgabe: @code{#t}) Enable polling the kernel for battery level changes. @item @code{ignore-lid?} (Vorgabe: @code{#f}) Ignore the lid state, this can be useful if it's incorrect on a device. @item @code{use-percentage-for-policy?} (Vorgabe: @code{#f}) Whether battery percentage based policy should be used. The default is to use the time left, change to @code{#t} to use the percentage. @item @code{percentage-low} (Vorgabe: @code{10}) When @code{use-percentage-for-policy?} is @code{#t}, this sets the percentage at which the battery is considered low. @item @code{percentage-critical} (Vorgabe: @code{3}) When @code{use-percentage-for-policy?} is @code{#t}, this sets the percentage at which the battery is considered critical. @item @code{percentage-action} (Vorgabe: @code{2}) When @code{use-percentage-for-policy?} is @code{#t}, this sets the percentage at which action will be taken. @item @code{time-low} (Vorgabe: @code{1200}) When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining in seconds at which the battery is considered low. @item @code{time-critical} (Vorgabe: @code{300}) When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining in seconds at which the battery is considered critical. @item @code{time-action} (Vorgabe: @code{120}) When @code{use-time-for-policy?} is @code{#f}, this sets the time remaining in seconds at which action will be taken. @item @code{critical-power-action} (Vorgabe: @code{'hybrid-sleep}) The action taken when @code{percentage-action} or @code{time-action} is reached (depending on the configuration of @code{use-percentage-for-policy?}). Possible values are: @itemize @bullet @item @code{'power-off} @item @code{'hibernate} @item @code{'hybrid-sleep}. @end itemize @end table @end deftp @deffn {Scheme Procedure} udisks-service [#:udisks @var{udisks}] Return a service for @uref{http://udisks.freedesktop.org/docs/latest/, UDisks}, a @dfn{disk management} daemon that provides user interfaces with notifications and ways to mount/unmount disks. Programs that talk to UDisks include the @command{udisksctl} command, part of UDisks, and GNOME Disks. @end deffn @deffn {Scheme Procedure} colord-service [#:colord @var{colord}] Return a service that runs @command{colord}, a system service with a D-Bus interface to manage the color profiles of input and output devices such as screens and scanners. It is notably used by the GNOME Color Manager graphical tool. See @uref{http://www.freedesktop.org/software/colord/, the colord web site} for more information. @end deffn @deffn {Scheme Procedure} geoclue-application name [#:allowed? #t] [#:system? #f] [#:users '()] Return a configuration allowing an application to access GeoClue location data. @var{name} is the Desktop ID of the application, without the @code{.desktop} part. If @var{allowed?} is true, the application will have access to location information by default. The boolean @var{system?} value indicates whether an application is a system component or not. Finally @var{users} is a list of UIDs of all users for which this application is allowed location info access. An empty users list means that all users are allowed. @end deffn @defvr {Scheme Variable} %standard-geoclue-applications The standard list of well-known GeoClue application configurations, granting authority to the GNOME date-and-time utility to ask for the current location in order to set the time zone, and allowing the IceCat and Epiphany web browsers to request location information. IceCat and Epiphany both query the user before allowing a web page to know the user's location. @end defvr @deffn {Scheme Procedure} geoclue-service [#:colord @var{colord}] @ [#:whitelist '()] @ [#:wifi-geolocation-url "https://location.services.mozilla.com/v1/geolocate?key=geoclue"] @ [#:submit-data? #f] [#:wifi-submission-url "https://location.services.mozilla.com/v1/submit?key=geoclue"] @ [#:submission-nick "geoclue"] @ [#:applications %standard-geoclue-applications] Return a service that runs the GeoClue location service. This service provides a D-Bus interface to allow applications to request access to a user's physical location, and optionally to add information to online location databases. See @uref{https://wiki.freedesktop.org/www/Software/GeoClue/, the GeoClue web site} for more information. @end deffn @deffn {Scheme Procedure} bluetooth-service [#:bluez @var{bluez}] @ [@w{#:auto-enable? #f}] Return a service that runs the @command{bluetoothd} daemon, which manages all the Bluetooth devices and provides a number of D-Bus interfaces. When AUTO-ENABLE? is true, the bluetooth controller is powered automatically at boot, which can be useful when using a bluetooth keyboard or mouse. Users need to be in the @code{lp} group to access the D-Bus service. @end deffn @node Tondienste @subsection Tondienste @cindex sound support @cindex ALSA @cindex PulseAudio, sound support The @code{(gnu services sound)} module provides a service to configure the Advanced Linux Sound Architecture (ALSA) system, which makes PulseAudio the preferred ALSA output driver. @deffn {Scheme Variable} alsa-service-type This is the type for the @uref{https://alsa-project.org/, Advanced Linux Sound Architecture} (ALSA) system, which generates the @file{/etc/asound.conf} configuration file. The value for this type is a @command{alsa-configuration} record as in this example: @example (service alsa-service-type) @end example See below for details about @code{alsa-configuration}. @end deffn @deftp {Datentyp} alsa-configuration Repräsentiert die Konfiguration für den Dienst @code{alsa-service}. @table @asis @item @code{alsa-plugins} (Vorgabe: @var{alsa-plugins}) @code{alsa-plugins}-Paket, was benutzt werden soll. @item @code{pulseaudio?} (Vorgabe: @var{#t}) Whether ALSA applications should transparently be made to use the @uref{http://www.pulseaudio.org/, PulseAudio} sound server. Using PulseAudio allows you to run several sound-producing applications at the same time and to individual control them @i{via} @command{pavucontrol}, among other things. @item @code{extra-options} (Vorgabe: @var{""}) String to append to the @file{/etc/asound.conf} file. @end table @end deftp Individual users who want to override the system configuration of ALSA can do it with the @file{~/.asoundrc} file: @example # In guix, we have to specify the absolute path for plugins. pcm_type.jack @{ lib "/home/alice/.guix-profile/lib/alsa-lib/libasound_module_pcm_jack.so" @} # Routing ALSA to jack: # . pcm.rawjack @{ type jack playback_ports @{ 0 system:playback_1 1 system:playback_2 @} capture_ports @{ 0 system:capture_1 1 system:capture_2 @} @} pcm.!default @{ type plug slave @{ pcm "rawjack" @} @} @end example See @uref{https://www.alsa-project.org/main/index.php/Asoundrc} for the details. @node Datenbankdienste @subsection Datenbankdienste @cindex Datenbank @cindex SQL The @code{(gnu services databases)} module provides the following services. @deffn {Scheme Procedure} postgresql-service [#:postgresql postgresql] @ [#:config-file] [#:data-directory ``/var/lib/postgresql/data''] @ [#:port 5432] [#:locale ``en_US.utf8''] [#:extension-packages '()] Return a service that runs @var{postgresql}, the PostgreSQL database server. The PostgreSQL daemon loads its runtime configuration from @var{config-file}, creates a database cluster with @var{locale} as the default locale, stored in @var{data-directory}. It then listens on @var{port}. @cindex postgresql extension-packages Additional extensions are loaded from packages listed in @var{extension-packages}. Extensions are available at runtime. For instance, to create a geographic database using the @code{postgis} extension, a user can configure the postgresql-service as in this example: @cindex postgis @example (use-package-modules databases geo) (operating-system … ;; postgresql wird benötigt, um »psql« auszuführen, aber postgis ist ;; für den Betrieb nicht unbedingt notwendig. (packages (cons* postgresql %base-packages)) (services (cons* (postgresql-service #:extension-packages (list postgis)) %base-services))) @end example Then the extension becomes visible and you can initialise an empty geographic database in this way: @example psql -U postgres > create database postgistest; > \connect postgistest; > create extension postgis; > create extension postgis_topology; @end example There is no need to add this field for contrib extensions such as hstore or dblink as they are already loadable by postgresql. This field is only required to add extensions provided by other packages. @end deffn @deffn {Scheme Procedure} mysql-service [#:config (mysql-configuration)] Return a service that runs @command{mysqld}, the MySQL or MariaDB database server. The optional @var{config} argument specifies the configuration for @command{mysqld}, which should be a @code{} object. @end deffn @deftp {Data Type} mysql-configuration Data type representing the configuration of @var{mysql-service}. @table @asis @item @code{mysql} (default: @var{mariadb}) Package object of the MySQL database server, can be either @var{mariadb} or @var{mysql}. For MySQL, a temporary root password will be displayed at activation time. For MariaDB, the root password is empty. @item @code{port} (default: @code{3306}) TCP port on which the database server listens for incoming connections. @end table @end deftp @defvr {Scheme Variable} memcached-service-type This is the service type for the @uref{https://memcached.org/, Memcached} service, which provides a distributed in memory cache. The value for the service type is a @code{memcached-configuration} object. @end defvr @example (service memcached-service-type) @end example @deftp {Data Type} memcached-configuration Data type representing the configuration of memcached. @table @asis @item @code{memcached} (default: @code{memcached}) The Memcached package to use. @item @code{interfaces} (default: @code{'("0.0.0.0")}) Network interfaces on which to listen. @item @code{tcp-port} (default: @code{11211}) Port on which to accept connections on, @item @code{udp-port} (default: @code{11211}) Port on which to accept UDP connections on, a value of 0 will disable listening on a UDP socket. @item @code{additional-options} (default: @code{'()}) Additional command line options to pass to @code{memcached}. @end table @end deftp @defvr {Scheme Variable} mongodb-service-type This is the service type for @uref{https://www.mongodb.com/, MongoDB}. The value for the service type is a @code{mongodb-configuration} object. @end defvr @example (service mongodb-service-type) @end example @deftp {Data Type} mongodb-configuration Data type representing the configuration of mongodb. @table @asis @item @code{mongodb} (default: @code{mongodb}) The MongoDB package to use. @item @code{config-file} (default: @code{%default-mongodb-configuration-file}) The configuration file for MongoDB. @item @code{data-directory} (default: @code{"/var/lib/mongodb"}) This value is used to create the directory, so that it exists and is owned by the mongodb user. It should match the data-directory which MongoDB is configured to use through the configuration file. @end table @end deftp @defvr {Scheme Variable} redis-service-type This is the service type for the @uref{https://redis.io/, Redis} key/value store, whose value is a @code{redis-configuration} object. @end defvr @deftp {Data Type} redis-configuration Data type representing the configuration of redis. @table @asis @item @code{redis} (default: @code{redis}) The Redis package to use. @item @code{bind} (default: @code{"127.0.0.1"}) Network interface on which to listen. @item @code{port} (default: @code{6379}) Port on which to accept connections on, a value of 0 will disable listening on a TCP socket. @item @code{working-directory} (default: @code{"/var/lib/redis"}) Directory in which to store the database and related files. @end table @end deftp @node Mail-Dienste @subsection Mail-Dienste @cindex mail @cindex email The @code{(gnu services mail)} module provides Guix service definitions for email services: IMAP, POP3, and LMTP servers, as well as mail transport agents (MTAs). Lots of acronyms! These services are detailed in the subsections below. @subsubheading Dovecot Service @deffn {Scheme Procedure} dovecot-service [#:config (dovecot-configuration)] Return a service that runs the Dovecot IMAP/POP3/LMTP mail server. @end deffn By default, Dovecot does not need much configuration; the default configuration object created by @code{(dovecot-configuration)} will suffice if your mail is delivered to @code{~/Maildir}. A self-signed certificate will be generated for TLS-protected connections, though Dovecot will also listen on cleartext ports by default. There are a number of options, though, which mail administrators might need to change, and as is the case with other services, Guix allows the system administrator to specify these parameters via a uniform Scheme interface. For example, to specify that mail is located at @code{maildir~/.mail}, one would instantiate the Dovecot service like this: @example (dovecot-service #:config (dovecot-configuration (mail-location "maildir:~/.mail"))) @end example The available configuration parameters follow. Each parameter definition is preceded by its type; for example, @samp{string-list foo} indicates that the @code{foo} parameter should be specified as a list of strings. There is also a way to specify the configuration as a string, if you have an old @code{dovecot.conf} file that you want to port over from some other system; see the end for more details. @c The following documentation was initially generated by @c (generate-documentation) in (gnu services mail). Manually maintained @c documentation is better, so we shouldn't hesitate to edit below as @c needed. However if the change you want to make to this documentation @c can be done in an automated way, it's probably easier to change @c (generate-documentation) than to make it below and have to deal with @c the churn as dovecot updates. Available @code{dovecot-configuration} fields are: @deftypevr {@code{dovecot-configuration} parameter} package dovecot The dovecot package. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} comma-separated-string-list listen A list of IPs or hosts where to listen for connections. @samp{*} listens on all IPv4 interfaces, @samp{::} listens on all IPv6 interfaces. If you want to specify non-default ports or anything more complex, customize the address and port fields of the @samp{inet-listener} of the specific services you are interested in. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} protocol-configuration-list protocols List of protocols we want to serve. Available protocols include @samp{imap}, @samp{pop3}, and @samp{lmtp}. Available @code{protocol-configuration} fields are: @deftypevr {@code{protocol-configuration} parameter} string name The name of the protocol. @end deftypevr @deftypevr {@code{protocol-configuration} parameter} string auth-socket-path UNIX socket path to the master authentication server to find users. This is used by imap (for shared users) and lda. It defaults to @samp{"/var/run/dovecot/auth-userdb"}. @end deftypevr @deftypevr {@code{protocol-configuration} parameter} space-separated-string-list mail-plugins Space separated list of plugins to load. @end deftypevr @deftypevr {@code{protocol-configuration} parameter} non-negative-integer mail-max-userip-connections Maximum number of IMAP connections allowed for a user from each IP address. NOTE: The username is compared case-sensitively. Defaults to @samp{10}. @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} service-configuration-list services List of services to enable. Available services include @samp{imap}, @samp{imap-login}, @samp{pop3}, @samp{pop3-login}, @samp{auth}, and @samp{lmtp}. Available @code{service-configuration} fields are: @deftypevr {@code{service-configuration} parameter} string kind The service kind. Valid values include @code{director}, @code{imap-login}, @code{pop3-login}, @code{lmtp}, @code{imap}, @code{pop3}, @code{auth}, @code{auth-worker}, @code{dict}, @code{tcpwrap}, @code{quota-warning}, or anything else. @end deftypevr @deftypevr {@code{service-configuration} parameter} listener-configuration-list listeners Listeners for the service. A listener is either a @code{unix-listener-configuration}, a @code{fifo-listener-configuration}, or an @code{inet-listener-configuration}. Defaults to @samp{()}. Available @code{unix-listener-configuration} fields are: @deftypevr {@code{unix-listener-configuration} parameter} string path Path to the file, relative to @code{base-dir} field. This is also used as the section name. @end deftypevr @deftypevr {@code{unix-listener-configuration} parameter} string mode The access mode for the socket. Defaults to @samp{"0600"}. @end deftypevr @deftypevr {@code{unix-listener-configuration} parameter} string user The user to own the socket. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{unix-listener-configuration} parameter} string group The group to own the socket. Defaults to @samp{""}. @end deftypevr Available @code{fifo-listener-configuration} fields are: @deftypevr {@code{fifo-listener-configuration} parameter} string path Path to the file, relative to @code{base-dir} field. This is also used as the section name. @end deftypevr @deftypevr {@code{fifo-listener-configuration} parameter} string mode The access mode for the socket. Defaults to @samp{"0600"}. @end deftypevr @deftypevr {@code{fifo-listener-configuration} parameter} string user The user to own the socket. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{fifo-listener-configuration} parameter} string group The group to own the socket. Defaults to @samp{""}. @end deftypevr Available @code{inet-listener-configuration} fields are: @deftypevr {@code{inet-listener-configuration} parameter} string protocol The protocol to listen for. @end deftypevr @deftypevr {@code{inet-listener-configuration} parameter} string address The address on which to listen, or empty for all addresses. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{inet-listener-configuration} parameter} non-negative-integer port The port on which to listen. @end deftypevr @deftypevr {@code{inet-listener-configuration} parameter} boolean ssl? Whether to use SSL for this service; @samp{yes}, @samp{no}, or @samp{required}. Defaults to @samp{#t}. @end deftypevr @end deftypevr @deftypevr {@code{service-configuration} parameter} non-negative-integer client-limit Maximum number of simultaneous client connections per process. Once this number of connections is received, the next incoming connection will prompt Dovecot to spawn another process. If set to 0, @code{default-client-limit} is used instead. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{service-configuration} parameter} non-negative-integer service-count Number of connections to handle before starting a new process. Typically the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0 is faster. . Defaults to @samp{1}. @end deftypevr @deftypevr {@code{service-configuration} parameter} non-negative-integer process-limit Maximum number of processes that can exist for this service. If set to 0, @code{default-process-limit} is used instead. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{service-configuration} parameter} non-negative-integer process-min-avail Number of processes to always keep waiting for more connections. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{service-configuration} parameter} non-negative-integer vsz-limit If you set @samp{service-count 0}, you probably need to grow this. Defaults to @samp{256000000}. @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} dict-configuration dict Dict configuration, as created by the @code{dict-configuration} constructor. Available @code{dict-configuration} fields are: @deftypevr {@code{dict-configuration} parameter} free-form-fields entries A list of key-value pairs that this dict should hold. Defaults to @samp{()}. @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} passdb-configuration-list passdbs A list of passdb configurations, each one created by the @code{passdb-configuration} constructor. Available @code{passdb-configuration} fields are: @deftypevr {@code{passdb-configuration} parameter} string driver The driver that the passdb should use. Valid values include @samp{pam}, @samp{passwd}, @samp{shadow}, @samp{bsdauth}, and @samp{static}. Defaults to @samp{"pam"}. @end deftypevr @deftypevr {@code{passdb-configuration} parameter} space-separated-string-list args Space separated list of arguments to the passdb driver. Defaults to @samp{""}. @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} userdb-configuration-list userdbs List of userdb configurations, each one created by the @code{userdb-configuration} constructor. Available @code{userdb-configuration} fields are: @deftypevr {@code{userdb-configuration} parameter} string driver The driver that the userdb should use. Valid values include @samp{passwd} and @samp{static}. Defaults to @samp{"passwd"}. @end deftypevr @deftypevr {@code{userdb-configuration} parameter} space-separated-string-list args Space separated list of arguments to the userdb driver. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{userdb-configuration} parameter} free-form-args override-fields Override fields from passwd. Defaults to @samp{()}. @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} plugin-configuration plugin-configuration Plug-in configuration, created by the @code{plugin-configuration} constructor. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} list-of-namespace-configuration namespaces List of namespaces. Each item in the list is created by the @code{namespace-configuration} constructor. Available @code{namespace-configuration} fields are: @deftypevr {@code{namespace-configuration} parameter} string name Name for this namespace. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} string type Namespace type: @samp{private}, @samp{shared} or @samp{public}. Defaults to @samp{"private"}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} string separator Hierarchy separator to use. You should use the same separator for all namespaces or some clients get confused. @samp{/} is usually a good one. The default however depends on the underlying mail storage format. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} string prefix Prefix required to access this namespace. This needs to be different for all namespaces. For example @samp{Public/}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} string location Physical location of the mailbox. This is in the same format as mail_location, which is also the default for it. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} boolean inbox? There can be only one INBOX, and this setting defines which namespace has it. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} boolean hidden? If namespace is hidden, it's not advertised to clients via NAMESPACE extension. You'll most likely also want to set @samp{list? #f}. This is mostly useful when converting from another server with different namespaces which you want to deprecate but still keep working. For example you can create hidden namespaces with prefixes @samp{~/mail/}, @samp{~%u/mail/} and @samp{mail/}. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} boolean list? Show the mailboxes under this namespace with the LIST command. This makes the namespace visible for clients that do not support the NAMESPACE extension. The special @code{children} value lists child mailboxes, but hides the namespace prefix. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} boolean subscriptions? Namespace handles its own subscriptions. If set to @code{#f}, the parent namespace handles them. The empty prefix should always have this as @code{#t}). Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{namespace-configuration} parameter} mailbox-configuration-list mailboxes List of predefined mailboxes in this namespace. Defaults to @samp{()}. Available @code{mailbox-configuration} fields are: @deftypevr {@code{mailbox-configuration} parameter} string name Name for this mailbox. @end deftypevr @deftypevr {@code{mailbox-configuration} parameter} string auto @samp{create} will automatically create this mailbox. @samp{subscribe} will both create and subscribe to the mailbox. Defaults to @samp{"no"}. @end deftypevr @deftypevr {@code{mailbox-configuration} parameter} space-separated-string-list special-use List of IMAP @code{SPECIAL-USE} attributes as specified by RFC 6154. Valid values are @code{\All}, @code{\Archive}, @code{\Drafts}, @code{\Flagged}, @code{\Junk}, @code{\Sent}, and @code{\Trash}. Defaults to @samp{()}. @end deftypevr @end deftypevr @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} file-name base-dir Base directory where to store runtime data. Defaults to @samp{"/var/run/dovecot/"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string login-greeting Greeting message for clients. Defaults to @samp{"Dovecot ready."}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-trusted-networks List of trusted network ranges. Connections from these IPs are allowed to override their IP addresses and ports (for logging and for authentication checks). @samp{disable-plaintext-auth} is also ignored for these networks. Typically you would specify your IMAP proxy servers here. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-access-sockets List of login access check sockets (e.g.@: tcpwrap). Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean verbose-proctitle? Show more verbose process titles (in ps). Currently shows user name and IP address. Useful for seeing who is actually using the IMAP processes (e.g.@: shared mailboxes or if the same uid is used for multiple accounts). Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean shutdown-clients? Should all processes be killed when Dovecot master process shuts down. Setting this to @code{#f} means that Dovecot can be upgraded without forcing existing client connections to close (although that could also be a problem if the upgrade is e.g.@: due to a security fix). Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer doveadm-worker-count If non-zero, run mail commands via this many connections to doveadm server, instead of running them directly in the same process. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string doveadm-socket-path UNIX socket or host:port used for connecting to doveadm server. Defaults to @samp{"doveadm-server"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list import-environment List of environment variables that are preserved on Dovecot startup and passed down to all of its child processes. You can also give key=value pairs to always set specific settings. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean disable-plaintext-auth? Disable LOGIN command and all other plaintext authentications unless SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP matches the local IP (i.e.@: you're connecting from the same computer), the connection is considered secure and plaintext authentication is allowed. See also ssl=required setting. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-cache-size Authentication cache size (e.g.@: @samp{#e10e6}). 0 means it's disabled. Note that bsdauth, PAM and vpopmail require @samp{cache-key} to be set for caching to be used. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-cache-ttl Time to live for cached data. After TTL expires the cached record is no longer used, *except* if the main database lookup returns internal failure. We also try to handle password changes automatically: If user's previous authentication was successful, but this one wasn't, the cache isn't used. For now this works only with plaintext authentication. Defaults to @samp{"1 hour"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-cache-negative-ttl TTL for negative hits (user not found, password mismatch). 0 disables caching them completely. Defaults to @samp{"1 hour"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-realms List of realms for SASL authentication mechanisms that need them. You can leave it empty if you don't want to support multiple realms. Many clients simply use the first one listed here, so keep the default realm first. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-default-realm Default realm/domain to use if none was specified. This is used for both SASL realms and appending @@domain to username in plaintext logins. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-username-chars List of allowed characters in username. If the user-given username contains a character not listed in here, the login automatically fails. This is just an extra check to make sure user can't exploit any potential quote escaping vulnerabilities with SQL/LDAP databases. If you want to allow all characters, set this value to empty. Defaults to @samp{"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@@"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-username-translation Username character translations before it's looked up from databases. The value contains series of from -> to characters. For example @samp{#@@/@@} means that @samp{#} and @samp{/} characters are translated to @samp{@@}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-username-format Username formatting before it's looked up from databases. You can use the standard variables here, e.g.@: %Lu would lowercase the username, %n would drop away the domain if it was given, or @samp{%n-AT-%d} would change the @samp{@@} into @samp{-AT-}. This translation is done after @samp{auth-username-translation} changes. Defaults to @samp{"%Lu"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-master-user-separator If you want to allow master users to log in by specifying the master username within the normal username string (i.e.@: not using SASL mechanism's support for it), you can specify the separator character here. The format is then . UW-IMAP uses @samp{*} as the separator, so that could be a good choice. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-anonymous-username Username to use for users logging in with ANONYMOUS SASL mechanism. Defaults to @samp{"anonymous"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer auth-worker-max-count Maximum number of dovecot-auth worker processes. They're used to execute blocking passdb and userdb queries (e.g.@: MySQL and PAM). They're automatically created and destroyed as needed. Defaults to @samp{30}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-gssapi-hostname Host name to use in GSSAPI principal names. The default is to use the name returned by gethostname(). Use @samp{$ALL} (with quotes) to allow all keytab entries. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-krb5-keytab Kerberos keytab to use for the GSSAPI mechanism. Will use the system default (usually @file{/etc/krb5.keytab}) if not specified. You may need to change the auth service to run as root to be able to read this file. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-use-winbind? Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon and @samp{ntlm-auth} helper. . Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} file-name auth-winbind-helper-path Path for Samba's @samp{ntlm-auth} helper binary. Defaults to @samp{"/usr/bin/ntlm_auth"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string auth-failure-delay Time to delay before replying to failed authentications. Defaults to @samp{"2 secs"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-require-client-cert? Require a valid SSL client certificate or the authentication fails. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-ssl-username-from-cert? Take the username from client's SSL certificate, using @code{X509_NAME_get_text_by_NID()} which returns the subject's DN's CommonName. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list auth-mechanisms List of wanted authentication mechanisms. Supported mechanisms are: @samp{plain}, @samp{login}, @samp{digest-md5}, @samp{cram-md5}, @samp{ntlm}, @samp{rpa}, @samp{apop}, @samp{anonymous}, @samp{gssapi}, @samp{otp}, @samp{skey}, and @samp{gss-spnego}. NOTE: See also @samp{disable-plaintext-auth} setting. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-servers List of IPs or hostnames to all director servers, including ourself. Ports can be specified as ip:port. The default port is the same as what director service's @samp{inet-listener} is using. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list director-mail-servers List of IPs or hostnames to all backend mail servers. Ranges are allowed too, like 10.0.0.10-10.0.0.30. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string director-user-expire How long to redirect users to a specific server after it no longer has any connections. Defaults to @samp{"15 min"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string director-username-hash How the username is translated before being hashed. Useful values include %Ln if user can log in with or without @@domain, %Ld if mailboxes are shared within domain. Defaults to @samp{"%Lu"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string log-path Log file to use for error messages. @samp{syslog} logs to syslog, @samp{/dev/stderr} logs to stderr. Defaults to @samp{"syslog"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string info-log-path Log file to use for informational messages. Defaults to @samp{log-path}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string debug-log-path Log file to use for debug messages. Defaults to @samp{info-log-path}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string syslog-facility Syslog facility to use if you're logging to syslog. Usually if you don't want to use @samp{mail}, you'll use local0..local7. Also other standard facilities are supported. Defaults to @samp{"mail"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose? Log unsuccessful authentication attempts and the reasons why they failed. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-verbose-passwords? In case of password mismatches, log the attempted password. Valid values are no, plain and sha1. sha1 can be useful for detecting brute force password attempts vs. user simply trying the same password over and over again. You can also truncate the value to n chars by appending ":n" (e.g.@: sha1:6). Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug? Even more verbose logging for debugging purposes. Shows for example SQL queries. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean auth-debug-passwords? In case of password mismatches, log the passwords and used scheme so the problem can be debugged. Enabling this also enables @samp{auth-debug}. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mail-debug? Enable mail process debugging. This can help you figure out why Dovecot isn't finding your mails. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean verbose-ssl? Show protocol level SSL errors. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string log-timestamp Prefix for each line written to log file. % codes are in strftime(3) format. Defaults to @samp{"\"%b %d %H:%M:%S \""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list login-log-format-elements List of elements we want to log. The elements which have a non-empty variable value are joined together to form a comma-separated string. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string login-log-format Login log format. %s contains @samp{login-log-format-elements} string, %$ contains the data we want to log. Defaults to @samp{"%$: %s"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-log-prefix Log prefix for mail processes. See doc/wiki/Variables.txt for list of possible variables you can use. Defaults to @samp{"\"%s(%u)<%@{pid@}><%@{session@}>: \""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string deliver-log-format Format to use for logging mail deliveries. You can use variables: @table @code @item %$ Delivery status message (e.g.@: @samp{saved to INBOX}) @item %m Message-ID @item %s Subject @item %f From address @item %p Physical size @item %w Virtual size. @end table Defaults to @samp{"msgid=%m: %$"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-location Location for users' mailboxes. The default is empty, which means that Dovecot tries to find the mailboxes automatically. This won't work if the user doesn't yet have any mail, so you should explicitly tell Dovecot the full location. If you're using mbox, giving a path to the INBOX file (e.g.@: /var/mail/%u) isn't enough. You'll also need to tell Dovecot where the other mailboxes are kept. This is called the "root mail directory", and it must be the first path given in the @samp{mail-location} setting. There are a few special variables you can use, eg.: @table @samp @item %u username @item %n user part in user@@domain, same as %u if there's no domain @item %d domain part in user@@domain, empty if there's no domain @item %h home director @end table See doc/wiki/Variables.txt for full list. Some examples: @table @samp @item maildir:~/Maildir @item mbox:~/mail:INBOX=/var/mail/%u @item mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/% @end table Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-uid System user and group used to access mails. If you use multiple, userdb can override these by returning uid or gid fields. You can use either numbers or names. . Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-gid Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-privileged-group Group to enable temporarily for privileged operations. Currently this is used only with INBOX when either its initial creation or dotlocking fails. Typically this is set to "mail" to give access to /var/mail. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-access-groups Grant access to these supplementary groups for mail processes. Typically these are used to set up access to shared mailboxes. Note that it may be dangerous to set these if users can create symlinks (e.g.@: if "mail" group is set here, ln -s /var/mail ~/mail/var could allow a user to delete others' mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mail-full-filesystem-access? Allow full file system access to clients. There's no access checks other than what the operating system does for the active UID/GID. It works with both maildir and mboxes, allowing you to prefix mailboxes names with e.g.@: /path/ or ~user/. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mmap-disable? Don't use mmap() at all. This is required if you store indexes to shared file systems (NFS or clustered file system). Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean dotlock-use-excl? Rely on @samp{O_EXCL} to work when creating dotlock files. NFS supports @samp{O_EXCL} since version 3, so this should be safe to use nowadays by default. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-fsync When to use fsync() or fdatasync() calls: @table @code @item optimized Whenever necessary to avoid losing important data @item always Useful with e.g.@: NFS when write()s are delayed @item never Never use it (best performance, but crashes can lose data). @end table Defaults to @samp{"optimized"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-storage? Mail storage exists in NFS. Set this to yes to make Dovecot flush NFS caches whenever needed. If you're using only a single mail server this isn't needed. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mail-nfs-index? Mail index files also exist in NFS. Setting this to yes requires @samp{mmap-disable? #t} and @samp{fsync-disable? #f}. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string lock-method Locking method for index files. Alternatives are fcntl, flock and dotlock. Dotlocking uses some tricks which may create more disk I/O than other locking methods. NFS users: flock doesn't work, remember to change @samp{mmap-disable}. Defaults to @samp{"fcntl"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} file-name mail-temp-dir Directory in which LDA/LMTP temporarily stores incoming mails >128 kB. Defaults to @samp{"/tmp"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-uid Valid UID range for users. This is mostly to make sure that users can't log in as daemons or other system users. Note that denying root logins is hardcoded to dovecot binary and can't be done even if @samp{first-valid-uid} is set to 0. Defaults to @samp{500}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-uid Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer first-valid-gid Valid GID range for users. Users having non-valid GID as primary group ID aren't allowed to log in. If user belongs to supplementary groups with non-valid GIDs, those groups are not set. Defaults to @samp{1}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer last-valid-gid Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-max-keyword-length Maximum allowed length for mail keyword name. It's only forced when trying to create new keywords. Defaults to @samp{50}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} colon-separated-file-name-list valid-chroot-dirs List of directories under which chrooting is allowed for mail processes (i.e.@: /var/mail will allow chrooting to /var/mail/foo/bar too). This setting doesn't affect @samp{login-chroot} @samp{mail-chroot} or auth chroot settings. If this setting is empty, "/./" in home dirs are ignored. WARNING: Never add directories here which local users can modify, that may lead to root exploit. Usually this should be done only if you don't allow shell access for users. . Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-chroot Default chroot directory for mail processes. This can be overridden for specific users in user database by giving /./ in user's home directory (e.g.@: /home/./user chroots into /home). Note that usually there is no real need to do chrooting, Dovecot doesn't allow users to access files outside their mail directory anyway. If your home directories are prefixed with the chroot directory, append "/."@: to @samp{mail-chroot}. . Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} file-name auth-socket-path UNIX socket path to master authentication server to find users. This is used by imap (for shared users) and lda. Defaults to @samp{"/var/run/dovecot/auth-userdb"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} file-name mail-plugin-dir Directory where to look up mail plugins. Defaults to @samp{"/usr/lib/dovecot"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mail-plugins List of plugins to load for all services. Plugins specific to IMAP, LDA, etc.@: are added to this list in their own .conf files. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-cache-min-mail-count The minimum number of mails in a mailbox before updates are done to cache file. This allows optimizing Dovecot's behavior to do less disk writes at the cost of more disk reads. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mailbox-idle-check-interval When IDLE command is running, mailbox is checked once in a while to see if there are any new mails or other changes. This setting defines the minimum time to wait between those checks. Dovecot can also use dnotify, inotify and kqueue to find out immediately when changes occur. Defaults to @samp{"30 secs"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mail-save-crlf? Save mails with CR+LF instead of plain LF. This makes sending those mails take less CPU, especially with sendfile() syscall with Linux and FreeBSD. But it also creates a bit more disk I/O which may just make it slower. Also note that if other software reads the mboxes/maildirs, they may handle the extra CRs wrong and cause problems. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean maildir-stat-dirs? By default LIST command returns all entries in maildir beginning with a dot. Enabling this option makes Dovecot return only entries which are directories. This is done by stat()ing each entry, so it causes more disk I/O. (For systems setting struct @samp{dirent->d_type} this check is free and it's done always regardless of this setting). Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean maildir-copy-with-hardlinks? When copying a message, do it with hard links whenever possible. This makes the performance much better, and it's unlikely to have any side effects. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean maildir-very-dirty-syncs? Assume Dovecot is the only MUA accessing Maildir: Scan cur/ directory only when its mtime changes unexpectedly or when we can't find the mail otherwise. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-read-locks Which locking methods to use for locking mbox. There are four available: @table @code @item dotlock Create .lock file. This is the oldest and most NFS-safe solution. If you want to use /var/mail/ like directory, the users will need write access to that directory. @item dotlock-try Same as dotlock, but if it fails because of permissions or because there isn't enough disk space, just skip it. @item fcntl Use this if possible. Works with NFS too if lockd is used. @item flock May not exist in all systems. Doesn't work with NFS. @item lockf May not exist in all systems. Doesn't work with NFS. @end table You can use multiple locking methods; if you do the order they're declared in is important to avoid deadlocks if other MTAs/MUAs are using multiple locking methods as well. Some operating systems don't allow using some of them simultaneously. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list mbox-write-locks @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mbox-lock-timeout Maximum time to wait for lock (all of them) before aborting. Defaults to @samp{"5 mins"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mbox-dotlock-change-timeout If dotlock exists but the mailbox isn't modified in any way, override the lock file after this much time. Defaults to @samp{"2 mins"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mbox-dirty-syncs? When mbox changes unexpectedly we have to fully read it to find out what changed. If the mbox is large this can take a long time. Since the change is usually just a newly appended mail, it'd be faster to simply read the new mails. If this setting is enabled, Dovecot does this but still safely fallbacks to re-reading the whole mbox file whenever something in mbox isn't how it's expected to be. The only real downside to this setting is that if some other MUA changes message flags, Dovecot doesn't notice it immediately. Note that a full sync is done with SELECT, EXAMINE, EXPUNGE and CHECK commands. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mbox-very-dirty-syncs? Like @samp{mbox-dirty-syncs}, but don't do full syncs even with SELECT, EXAMINE, EXPUNGE or CHECK commands. If this is set, @samp{mbox-dirty-syncs} is ignored. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mbox-lazy-writes? Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK commands and when closing the mailbox). This is especially useful for POP3 where clients often delete all mails. The downside is that our changes aren't immediately visible to other MUAs. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mbox-min-index-size If mbox size is smaller than this (e.g.@: 100k), don't write index files. If an index file already exists it's still read, just not updated. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mdbox-rotate-size Maximum dbox file size until it's rotated. Defaults to @samp{10000000}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mdbox-rotate-interval Maximum dbox file age until it's rotated. Typically in days. Day begins from midnight, so 1d = today, 2d = yesterday, etc. 0 = check disabled. Defaults to @samp{"1d"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean mdbox-preallocate-space? When creating new mdbox files, immediately preallocate their size to @samp{mdbox-rotate-size}. This setting currently works only in Linux with some file systems (ext4, xfs). Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-dir sdbox and mdbox support saving mail attachments to external files, which also allows single instance storage for them. Other backends don't support this for now. WARNING: This feature hasn't been tested much yet. Use at your own risk. Directory root where to store mail attachments. Disabled, if empty. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer mail-attachment-min-size Attachments smaller than this aren't saved externally. It's also possible to write a plugin to disable saving specific attachments externally. Defaults to @samp{128000}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-fs File system backend to use for saving attachments: @table @code @item posix No SiS done by Dovecot (but this might help FS's own deduplication) @item sis posix SiS with immediate byte-by-byte comparison during saving @item sis-queue posix SiS with delayed comparison and deduplication. @end table Defaults to @samp{"sis posix"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string mail-attachment-hash Hash format to use in attachment filenames. You can add any text and variables: @code{%@{md4@}}, @code{%@{md5@}}, @code{%@{sha1@}}, @code{%@{sha256@}}, @code{%@{sha512@}}, @code{%@{size@}}. Variables can be truncated, e.g.@: @code{%@{sha256:80@}} returns only first 80 bits. Defaults to @samp{"%@{sha1@}"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-process-limit Defaults to @samp{100}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-client-limit Defaults to @samp{1000}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer default-vsz-limit Default VSZ (virtual memory size) limit for service processes. This is mainly intended to catch and kill processes that leak memory before they eat up everything. Defaults to @samp{256000000}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string default-login-user Login user is internally used by login processes. This is the most untrusted user in Dovecot system. It shouldn't have access to anything at all. Defaults to @samp{"dovenull"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string default-internal-user Internal user is used by unprivileged processes. It should be separate from login user, so that login processes can't disturb other processes. Defaults to @samp{"dovecot"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string ssl? SSL/TLS support: yes, no, required. . Defaults to @samp{"required"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string ssl-cert PEM encoded X.509 SSL/TLS certificate (public key). Defaults to @samp{" was automatically rejected:%n%r"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string recipient-delimiter Delimiter character between local-part and detail in email address. Defaults to @samp{"+"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string lda-original-recipient-header Header where the original recipient address (SMTP's RCPT TO: address) is taken from if not available elsewhere. With dovecot-lda -a parameter overrides this. A commonly used header for this is X-Original-To. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autocreate? Should saving a mail to a nonexistent mailbox automatically create it?. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} boolean lda-mailbox-autosubscribe? Should automatically created mailboxes be also automatically subscribed?. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} non-negative-integer imap-max-line-length Maximum IMAP command line length. Some clients generate very long command lines with huge mailboxes, so you may need to raise this if you get "Too long argument" or "IMAP command line too large" errors often. Defaults to @samp{64000}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string imap-logout-format IMAP logout format string: @table @code @item %i total number of bytes read from client @item %o total number of bytes sent to client. @end table See @file{doc/wiki/Variables.txt} for a list of all the variables you can use. Defaults to @samp{"in=%i out=%o deleted=%@{deleted@} expunged=%@{expunged@} trashed=%@{trashed@} hdr_count=%@{fetch_hdr_count@} hdr_bytes=%@{fetch_hdr_bytes@} body_count=%@{fetch_body_count@} body_bytes=%@{fetch_body_bytes@}"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string imap-capability Override the IMAP CAPABILITY response. If the value begins with '+', add the given capabilities on top of the defaults (e.g.@: +XFOO XBAR). Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string imap-idle-notify-interval How long to wait between "OK Still here" notifications when client is IDLEing. Defaults to @samp{"2 mins"}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string imap-id-send ID field names and values to send to clients. Using * as the value makes Dovecot use the default value. The following fields have default values currently: name, version, os, os-version, support-url, support-email. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} string imap-id-log ID fields sent by client to log. * means everything. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{dovecot-configuration} parameter} space-separated-string-list imap-client-workarounds Workarounds for various client bugs: @table @code @item delay-newmail Send EXISTS/RECENT new mail notifications only when replying to NOOP and CHECK commands. Some clients ignore them otherwise, for example OSX Mail (' before setting it here, to get a feel for which cipher suites you will get. After setting this option, it is recommend that you inspect your Murmur log to ensure that Murmur is using the cipher suites that you expected it to. Note: Changing this option may impact the backwards compatibility of your Murmur server, and can remove the ability for older Mumble clients to be able to connect to it. @item @code{public-registration} (default: @code{#f}) Must be a @code{} record or @code{#f}. You can optionally register your server in the public server list that the @code{mumble} client shows on startup. You cannot register your server if you have set a @code{server-password}, or set @code{allow-ping} to @code{#f}. It might take a few hours until it shows up in the public list. @item @code{file} (default: @code{#f}) Optional alternative override for this configuration. @end table @end deftp @deftp {Data Type} murmur-public-registration-configuration Configuration for public registration of a murmur service. @table @asis @item @code{name} This is a display name for your server. Not to be confused with the hostname. @item @code{password} A password to identify your registration. Subsequent updates will need the same password. Don't lose your password. @item @code{url} This should be a @code{http://} or @code{https://} link to your web site. @item @code{hostname} (default: @code{#f}) By default your server will be listed by its IP address. If it is set your server will be linked by this host name instead. @end table @end deftp @node Überwachungsdienste @subsection Überwachungsdienste @subsubheading Tailon Service @uref{https://tailon.readthedocs.io/, Tailon} is a web application for viewing and searching log files. The following example will configure the service with default values. By default, Tailon can be accessed on port 8080 (@code{http://localhost:8080}). @example (service tailon-service-type) @end example The following example customises more of the Tailon configuration, adding @command{sed} to the list of allowed commands. @example (service tailon-service-type (tailon-configuration (config-file (tailon-configuration-file (allowed-commands '("tail" "grep" "awk" "sed")))))) @end example @deftp {Data Type} tailon-configuration Data type representing the configuration of Tailon. This type has the following parameters: @table @asis @item @code{config-file} (default: @code{(tailon-configuration-file)}) The configuration file to use for Tailon. This can be set to a @dfn{tailon-configuration-file} record value, or any gexp (@pxref{G-Ausdrücke}). For example, to instead use a local file, the @code{local-file} function can be used: @example (service tailon-service-type (tailon-configuration (config-file (local-file "./my-tailon.conf")))) @end example @item @code{package} (default: @code{tailon}) The tailon package to use. @end table @end deftp @deftp {Data Type} tailon-configuration-file Data type representing the configuration options for Tailon. This type has the following parameters: @table @asis @item @code{files} (default: @code{(list "/var/log")}) List of files to display. The list can include strings for a single file or directory, or a list, where the first item is the name of a subsection, and the remaining items are the files or directories in that subsection. @item @code{bind} (default: @code{"localhost:8080"}) Address and port to which Tailon should bind on. @item @code{relative-root} (default: @code{#f}) URL path to use for Tailon, set to @code{#f} to not use a path. @item @code{allow-transfers?} (default: @code{#t}) Allow downloading the log files in the web interface. @item @code{follow-names?} (default: @code{#t}) Allow tailing of not-yet existent files. @item @code{tail-lines} (default: @code{200}) Number of lines to read initially from each file. @item @code{allowed-commands} (default: @code{(list "tail" "grep" "awk")}) Commands to allow running. By default, @code{sed} is disabled. @item @code{debug?} (default: @code{#f}) Set @code{debug?} to @code{#t} to show debug messages. @item @code{wrap-lines} (default: @code{#t}) Initial line wrapping state in the web interface. Set to @code{#t} to initially wrap lines (the default), or to @code{#f} to initially not wrap lines. @item @code{http-auth} (default: @code{#f}) HTTP authentication type to use. Set to @code{#f} to disable authentication (the default). Supported values are @code{"digest"} or @code{"basic"}. @item @code{users} (default: @code{#f}) If HTTP authentication is enabled (see @code{http-auth}), access will be restricted to the credentials provided here. To configure users, use a list of pairs, where the first element of the pair is the username, and the 2nd element of the pair is the password. @example (tailon-configuration-file (http-auth "basic") (users '(("user1" . "password1") ("user2" . "password2")))) @end example @end table @end deftp @subsubheading Darkstat Service @cindex darkstat Darkstat is a packet sniffer that captures network traffic, calculates statistics about usage, and serves reports over HTTP. @defvar {Scheme Variable} darkstat-service-type This is the service type for the @uref{https://unix4lyfe.org/darkstat/, darkstat} service, its value must be a @code{darkstat-configuration} record as in this example: @example (service darkstat-service-type (darkstat-configuration (interface "eno1"))) @end example @end defvar @deftp {Data Type} darkstat-configuration Data type representing the configuration of @command{darkstat}. @table @asis @item @code{package} (default: @code{darkstat}) The darkstat package to use. @item @code{interface} Capture traffic on the specified network interface. @item @code{port} (default: @code{"667"}) Bind the web interface to the specified port. @item @code{bind-address} (default: @code{"127.0.0.1"}) Bind the web interface to the specified address. @item @code{base} (default: @code{"/"}) Specify the path of the base URL. This can be useful if @command{darkstat} is accessed via a reverse proxy. @end table @end deftp @subsubheading Prometheus Node Exporter Service @cindex prometheus-node-exporter The Prometheus ``node exporter'' makes hardware and operating system statistics provided by the Linux kernel available for the Prometheus monitoring system. This service should be deployed on all physical nodes and virtual machines, where monitoring these statistics is desirable. @defvar {Scheme variable} prometheus-node-exporter-service-type This is the service type for the @uref{https://github.com/prometheus/node_exporter/, prometheus-node-exporter} service, its value must be a @code{prometheus-node-exporter-configuration} record as in this example: @example (service prometheus-node-exporter-service-type (prometheus-node-exporter-configuration (web-listen-address ":9100"))) @end example @end defvar @deftp {Data Type} prometheus-node-exporter-configuration Repräsentiert die Konfiguration von @command{node_exporter}. @table @asis @item @code{package} (Vorgabe: @code{go-github-com-prometheus-node-exporter}) Das Paket für den prometheus-node-exporter, was benutzt werden soll. @item @code{web-listen-address} (Vorgabe: @code{":9100"}) Bind the web interface to the specified address. @end table @end deftp @subsubheading Zabbix-Server @cindex zabbix zabbix-server Zabbix provides monitoring metrics, among others network utilization, CPU load and disk space consumption: @itemize @item High performance, high capacity (able to monitor hundreds of thousands of devices). @item Auto-discovery of servers and network devices and interfaces. @item Low-level discovery, allows to automatically start monitoring new items, file systems or network interfaces among others. @item Distributed monitoring with centralized web administration. @item Native high performance agents. @item SLA, and ITIL KPI metrics on reporting. @item High-level (business) view of monitored resources through user-defined visual console screens and dashboards. @item Remote command execution through Zabbix proxies. @end itemize @c %start of fragment Available @code{zabbix-server-configuration} fields are: @deftypevr {@code{zabbix-server-configuration} parameter} package zabbix-server Das zabbix-server-Paket. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string user User who will run the Zabbix server. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} group group Group who will run the Zabbix server. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string db-host Rechnername der Datenbank. Defaults to @samp{"127.0.0.1"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string db-name Datenbankname. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string db-user Benutzerkonto der Datenbank. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string db-password Database password. Please, use @code{include-files} with @code{DBPassword=SECRET} inside a specified file instead. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} number db-port Datenbank-Portnummer. Defaults to @samp{5432}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string log-type Specifies where log messages are written to: @itemize @bullet @item @code{system} - syslog. @item @code{file} - file specified with @code{log-file} parameter. @item @code{console} - standard output. @end itemize Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string log-file Log file name for @code{log-type} @code{file} parameter. Defaults to @samp{"/var/log/zabbix/server.log"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string pid-file Name der PID-Datei. Defaults to @samp{"/var/run/zabbix/zabbix_server.pid"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string ssl-ca-location The location of certificate authority (CA) files for SSL server certificate verification. Defaults to @samp{"/etc/ssl/certs/ca-certificates.crt"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string ssl-cert-location Location of SSL client certificates. Defaults to @samp{"/etc/ssl/certs"}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} string extra-options Extra options will be appended to Zabbix server configuration file. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-server-configuration} parameter} include-files include-files You may include individual files or all files in a directory in the configuration file. Defaults to @samp{()}. @end deftypevr @c %end of fragment @subsubheading Zabbix agent @cindex zabbix zabbix-agent Zabbix agent gathers information for Zabbix server. @c %start of fragment Available @code{zabbix-agent-configuration} fields are: @deftypevr {@code{zabbix-agent-configuration} parameter} package zabbix-agent Das zabbix-agent-Paket. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string user User who will run the Zabbix agent. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} group group Group who will run the Zabbix agent. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string hostname Unique, case sensitive hostname which is required for active checks and must match hostname as configured on the server. Defaults to @samp{"Zabbix server"}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string log-type Specifies where log messages are written to: @itemize @bullet @item @code{system} - syslog. @item @code{file} - file specified with @code{log-file} parameter. @item @code{console} - standard output. @end itemize Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string log-file Log file name for @code{log-type} @code{file} parameter. Defaults to @samp{"/var/log/zabbix/agent.log"}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string pid-file Name der PID-Datei. Defaults to @samp{"/var/run/zabbix/zabbix_agent.pid"}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} list server List of IP addresses, optionally in CIDR notation, or hostnames of Zabbix servers and Zabbix proxies. Incoming connections will be accepted only from the hosts listed here. Defaults to @samp{("127.0.0.1")}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} list server-active List of IP:port (or hostname:port) pairs of Zabbix servers and Zabbix proxies for active checks. If port is not specified, default port is used. If this parameter is not specified, active checks are disabled. Defaults to @samp{("127.0.0.1")}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} string extra-options Extra options will be appended to Zabbix server configuration file. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-agent-configuration} parameter} include-files include-files You may include individual files or all files in a directory in the configuration file. Defaults to @samp{()}. @end deftypevr @c %end of fragment @subsubheading Zabbix front-end @cindex zabbix zabbix-front-end This service provides a WEB interface to Zabbix server. @c %start of fragment Available @code{zabbix-front-end-configuration} fields are: @deftypevr {@code{zabbix-front-end-configuration} parameter} nginx-server-configuration-list nginx NGINX configuration. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-host Rechnername der Datenbank. Defaults to @samp{"localhost"}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} number db-port Datenbank-Portnummer. Defaults to @samp{5432}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-name Datenbankname. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-user Benutzerkonto der Datenbank. Defaults to @samp{"zabbix"}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-password Database password. Please, use @code{db-secret-file} instead. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string db-secret-file Secret file which will be appended to @file{zabbix.conf.php} file. This file contains credentials for use by Zabbix front-end. You are expected to create it manually. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} string zabbix-host Zabbix server hostname. Defaults to @samp{"localhost"}. @end deftypevr @deftypevr {@code{zabbix-front-end-configuration} parameter} number zabbix-port Zabbix server port. Defaults to @samp{10051}. @end deftypevr @c %end of fragment @node Kerberos-Dienste @subsection Kerberos-Dienste @cindex Kerberos The @code{(gnu services kerberos)} module provides services relating to the authentication protocol @dfn{Kerberos}. @subsubheading Krb5 Service Programs using a Kerberos client library normally expect a configuration file in @file{/etc/krb5.conf}. This service generates such a file from a definition provided in the operating system declaration. It does not cause any daemon to be started. No ``keytab'' files are provided by this service---you must explicitly create them. This service is known to work with the MIT client library, @code{mit-krb5}. Other implementations have not been tested. @defvr {Scheme Variable} krb5-service-type A service type for Kerberos 5 clients. @end defvr @noindent Here is an example of its use: @lisp (service krb5-service-type (krb5-configuration (default-realm "EXAMPLE.COM") (allow-weak-crypto? #t) (realms (list (krb5-realm (name "EXAMPLE.COM") (admin-server "groucho.example.com") (kdc "karl.example.com")) (krb5-realm (name "ARGRX.EDU") (admin-server "kerb-admin.argrx.edu") (kdc "keys.argrx.edu")))))) @end lisp @noindent This example provides a Kerberos@tie{}5 client configuration which: @itemize @item Recognizes two realms, @i{viz:} ``EXAMPLE.COM'' and ``ARGRX.EDU'', both of which have distinct administration servers and key distribution centers; @item Will default to the realm ``EXAMPLE.COM'' if the realm is not explicitly specified by clients; @item Accepts services which only support encryption types known to be weak. @end itemize The @code{krb5-realm} and @code{krb5-configuration} types have many fields. Only the most commonly used ones are described here. For a full list, and more detailed explanation of each, see the MIT @uref{http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html,,krb5.conf} documentation. @deftp {Data Type} krb5-realm @cindex realm, kerberos @table @asis @item @code{name} This field is a string identifying the name of the realm. A common convention is to use the fully qualified DNS name of your organization, converted to upper case. @item @code{admin-server} This field is a string identifying the host where the administration server is running. @item @code{kdc} This field is a string identifying the key distribution center for the realm. @end table @end deftp @deftp {Data Type} krb5-configuration @table @asis @item @code{allow-weak-crypto?} (default: @code{#f}) If this flag is @code{#t} then services which only offer encryption algorithms known to be weak will be accepted. @item @code{default-realm} (default: @code{#f}) This field should be a string identifying the default Kerberos realm for the client. You should set this field to the name of your Kerberos realm. If this value is @code{#f} then a realm must be specified with every Kerberos principal when invoking programs such as @command{kinit}. @item @code{realms} This should be a non-empty list of @code{krb5-realm} objects, which clients may access. Normally, one of them will have a @code{name} field matching the @code{default-realm} field. @end table @end deftp @subsubheading PAM krb5 Service @cindex pam-krb5 The @code{pam-krb5} service allows for login authentication and password management via Kerberos. You will need this service if you want PAM enabled applications to authenticate users using Kerberos. @defvr {Scheme Variable} pam-krb5-service-type A service type for the Kerberos 5 PAM module. @end defvr @deftp {Data Type} pam-krb5-configuration Data type representing the configuration of the Kerberos 5 PAM module This type has the following parameters: @table @asis @item @code{pam-krb5} (default: @code{pam-krb5}) The pam-krb5 package to use. @item @code{minimum-uid} (default: @code{1000}) The smallest user ID for which Kerberos authentications should be attempted. Local accounts with lower values will silently fail to authenticate. @end table @end deftp @node LDAP-Dienste @subsection LDAP-Dienste @cindex LDAP @cindex nslcd, LDAP service The @code{(gnu services authentication)} module provides the @code{nslcd-service-type}, which can be used to authenticate against an LDAP server. In addition to configuring the service itself, you may want to add @code{ldap} as a name service to the Name Service Switch. @xref{Name Service Switch} for detailed information. Here is a simple operating system declaration with a default configuration of the @code{nslcd-service-type} and a Name Service Switch configuration that consults the @code{ldap} name service last: @example (use-service-modules authentication) (use-modules (gnu system nss)) ... (operating-system ... (services (cons* (service nslcd-service-type) (service dhcp-client-service-type) %base-services)) (name-service-switch (let ((services (list (name-service (name "db")) (name-service (name "files")) (name-service (name "ldap"))))) (name-service-switch (inherit %mdns-host-lookup-nss) (password services) (shadow services) (group services) (netgroup services) (gshadow services))))) @end example @c %start of generated documentation for nslcd-configuration Available @code{nslcd-configuration} fields are: @deftypevr {@code{nslcd-configuration} parameter} package nss-pam-ldapd Das @code{nss-pam-ldapd}-Paket, was benutzt werden soll. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number threads The number of threads to start that can handle requests and perform LDAP queries. Each thread opens a separate connection to the LDAP server. The default is to start 5 threads. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} string uid This specifies the user id with which the daemon should be run. Defaults to @samp{"nslcd"}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} string gid This specifies the group id with which the daemon should be run. Defaults to @samp{"nslcd"}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} log-option log This option controls the way logging is done via a list containing SCHEME and LEVEL. The SCHEME argument may either be the symbols "none" or "syslog", or an absolute file name. The LEVEL argument is optional and specifies the log level. The log level may be one of the following symbols: "crit", "error", "warning", "notice", "info" or "debug". All messages with the specified log level or higher are logged. Defaults to @samp{("/var/log/nslcd" info)}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} list uri The list of LDAP server URIs. Normally, only the first server will be used with the following servers as fall-back. Defaults to @samp{("ldap://localhost:389/")}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string ldap-version The version of the LDAP protocol to use. The default is to use the maximum version supported by the LDAP library. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string binddn Specifies the distinguished name with which to bind to the directory server for lookups. The default is to bind anonymously. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string bindpw Specifies the credentials with which to bind. This option is only applicable when used with binddn. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string rootpwmoddn Specifies the distinguished name to use when the root user tries to modify a user's password using the PAM module. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string rootpwmodpw Specifies the credentials with which to bind if the root user tries to change a user's password. This option is only applicable when used with rootpwmoddn Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-mech Specifies the SASL mechanism to be used when performing SASL authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-realm Specifies the SASL realm to be used when performing SASL authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-authcid Specifies the authentication identity to be used when performing SASL authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string sasl-authzid Specifies the authorization identity to be used when performing SASL authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean sasl-canonicalize? Determines whether the LDAP server host name should be canonicalised. If this is enabled the LDAP library will do a reverse host name lookup. By default, it is left up to the LDAP library whether this check is performed or not. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string krb5-ccname Set the name for the GSS-API Kerberos credentials cache. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} string base Basis für die Verzeichnissuche. Vorgegeben ist @samp{"dc=example,dc=com"}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} scope-option scope Specifies the search scope (subtree, onelevel, base or children). The default scope is subtree; base scope is almost never useful for name service lookups; children scope is not supported on all servers. Defaults to @samp{(subtree)}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-deref-option deref Specifies the policy for dereferencing aliases. The default policy is to never dereference aliases. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean referrals Specifies whether automatic referral chasing should be enabled. The default behaviour is to chase referrals. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} list-of-map-entries maps This option allows for custom attributes to be looked up instead of the default RFC 2307 attributes. It is a list of maps, each consisting of the name of a map, the RFC 2307 attribute to match and the query expression for the attribute as it is available in the directory. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} list-of-filter-entries filters A list of filters consisting of the name of a map to which the filter applies and an LDAP search filter expression. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number bind-timelimit Specifies the time limit in seconds to use when connecting to the directory server. The default value is 10 seconds. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number timelimit Specifies the time limit (in seconds) to wait for a response from the LDAP server. A value of zero, which is the default, is to wait indefinitely for searches to be completed. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number idle-timelimit Specifies the period if inactivity (in seconds) after which the con‐ nection to the LDAP server will be closed. The default is not to time out connections. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number reconnect-sleeptime Specifies the number of seconds to sleep when connecting to all LDAP servers fails. By default one second is waited between the first failure and the first retry. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number reconnect-retrytime Specifies the time after which the LDAP server is considered to be permanently unavailable. Once this time is reached retries will be done only once per this time period. The default value is 10 seconds. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-ssl-option ssl Specifies whether to use SSL/TLS or not (the default is not to). If 'start-tls is specified then StartTLS is used rather than raw LDAP over SSL. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-tls-reqcert-option tls-reqcert Specifies what checks to perform on a server-supplied certificate. The meaning of the values is described in the ldap.conf(5) manual page. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cacertdir Specifies the directory containing X.509 certificates for peer authen‐ tication. This parameter is ignored when using GnuTLS. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cacertfile Specifies the path to the X.509 certificate for peer authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-randfile Specifies the path to an entropy source. This parameter is ignored when using GnuTLS. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-ciphers Specifies the ciphers to use for TLS as a string. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-cert Specifies the path to the file containing the local certificate for client TLS authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string tls-key Specifies the path to the file containing the private key for client TLS authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number pagesize Set this to a number greater than 0 to request paged results from the LDAP server in accordance with RFC2696. The default (0) is to not request paged results. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-ignore-users-option nss-initgroups-ignoreusers This option prevents group membership lookups through LDAP for the specified users. Alternatively, the value 'all-local may be used. With that value nslcd builds a full list of non-LDAP users on startup. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-min-uid This option ensures that LDAP users with a numeric user id lower than the specified value are ignored. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-uid-offset This option specifies an offset that is added to all LDAP numeric user ids. This can be used to avoid user id collisions with local users. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-number nss-gid-offset This option specifies an offset that is added to all LDAP numeric group ids. This can be used to avoid user id collisions with local groups. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-nested-groups If this option is set, the member attribute of a group may point to another group. Members of nested groups are also returned in the higher level group and parent groups are returned when finding groups for a specific user. The default is not to perform extra searches for nested groups. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-getgrent-skipmembers If this option is set, the group member list is not retrieved when looking up groups. Lookups for finding which groups a user belongs to will remain functional so the user will likely still get the correct groups assigned on login. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean nss-disable-enumeration If this option is set, functions which cause all user/group entries to be loaded from the directory will not succeed in doing so. This can dramatically reduce LDAP server load in situations where there are a great number of users and/or groups. This option is not recommended for most configurations. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string validnames This option can be used to specify how user and group names are verified within the system. This pattern is used to check all user and group names that are requested and returned from LDAP. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean ignorecase This specifies whether or not to perform searches using case-insensitive matching. Enabling this could open up the system to authorization bypass vulnerabilities and introduce nscd cache poisoning vulnerabilities which allow denial of service. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-boolean pam-authc-ppolicy This option specifies whether password policy controls are requested and handled from the LDAP server when performing user authentication. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-authc-search By default nslcd performs an LDAP search with the user's credentials after BIND (authentication) to ensure that the BIND operation was successful. The default search is a simple check to see if the user's DN exists. A search filter can be specified that will be used instead. It should return at least one entry. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-authz-search This option allows flexible fine tuning of the authorisation check that should be performed. The search filter specified is executed and if any entries match, access is granted, otherwise access is denied. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} maybe-string pam-password-prohibit-message If this option is set password modification using pam_ldap will be denied and the specified message will be presented to the user instead. The message can be used to direct the user to an alternative means of changing their password. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{nslcd-configuration} parameter} list pam-services List of pam service names for which LDAP authentication should suffice. Defaults to @samp{()}. @end deftypevr @c %end of generated documentation for nslcd-configuration @node Web-Dienste @subsection Web-Dienste @cindex Web @cindex WWW @cindex HTTP Das Modul @code{(gnu services web)} stellt den Apache-HTTP-Server, den nginx-Webserver und auch einen fastcgi-Wrapperdienst bereit. @subsubheading Apache-HTTP-Server @deffn {Scheme-Variable} httpd-service-type Diensttyp für den @uref{https://httpd.apache.org/,Apache-HTTP-Server} (@dfn{httpd}). Der Wert dieses Diensttyps ist ein @code{httpd-configuration}-Verbund. Es folgt ein einfaches Beispiel der Konfiguration. @example (service httpd-service-type (httpd-configuration (config (httpd-config-file (server-name "www.example.com") (document-root "/srv/http/www.example.com"))))) @end example Andere Dienste können den @code{httpd-service-type} auch erweitern, um etwas zur Konfiguration hinzuzufügen. @example (simple-service 'my-extra-server httpd-service-type (list (httpd-virtualhost "*:80" (list (string-append "ServerName "www.example.com DocumentRoot \"/srv/http/www.example.com\""))))) @end example @end deffn Nun folgt eine Beschreibung der Verbundstypen @code{httpd-configuration}, @code{httpd-module}, @code{httpd-config-file} und @code{httpd-virtualhost}. @deffn {Datentyp} httpd-configuration Dieser Datentyp repräsentiert die Konfiguration des httpd-Dienstes. @table @asis @item @code{package} (Vorgabe: @code{httpd}) Das zu benutzende httpd-Paket. @item @code{pid-file} (Vorgabe: @code{"/var/run/httpd"}) Die vom Shepherd-Dienst benutzte PID-Datei. @item @code{config} (Vorgabe: @code{(httpd-config-file)}) Die vom httpd-Dienst zu benutzende Konfigurationsdatei. Vorgegeben ist ein @code{httpd-config-file}-Verbundsobjekt, aber als Wert kann auch ein anderer G-Ausdruck benutzt werden, der eine Datei erzeugt, zum Beispiel ein @code{plain-file}. Es kann auch eine Datei außerhalb des Stores mit einer Zeichenkette angegeben werden. @end table @end deffn @deffn {Datentyp} httpd-module Dieser Datentyp steht für ein Modul des httpd-Dienstes. @table @asis @item @code{name} Der Name des Moduls. @item @code{file} Die Datei, in der das Modul steht. Sie kann relativ zum benutzten httpd-Paket oder als absoluter Pfad einer Datei oder als ein G-Ausdruck für eine Datei im Store angegeben werden, zum Beispiel @code{(file-append mod-wsgi "/modules/mod_wsgi.so")}. @end table @end deffn @defvr {Scheme-Variable} %default-httpd-modules Eine vorgegebene Liste von @code{httpd-module}-Objekten. @end defvr @deffn {Datentyp} httpd-config-file Dieser Datentyp repräsentiert eine Konfigurationsdatei für den httpd-Dienst. @table @asis @item @code{modules} (Vorgabe: @code{%default-httpd-modules}) Welche Module geladen werden sollen. Zusätzliche Module können hier eingetragen werden oder durch eine zusätzliche Konfigurationsangabe geladen werden. Um zum Beispiel Anfragen nach PHP-Dateien zu behandeln, können Sie das Modul @code{mod_proxy_fcgi} von Apache zusammen mit @code{php-fpm-service-type} benutzen: @example (service httpd-service-type (httpd-configuration (config (httpd-config-file (modules (cons* (httpd-module (name "proxy_module") (file "modules/mod_proxy.so")) (httpd-module (name "proxy_fcgi_module") (file "modules/mod_proxy_fcgi.so")) %default-httpd-modules)) (extra-config (list "\ SetHandler \"proxy:unix:/var/run/php-fpm.sock|fcgi://localhost/\" ")))))) (service php-fpm-service-type (php-fpm-configuration (socket "/var/run/php-fpm.sock") (socket-group "httpd"))) @end example @item @code{server-root} (Vorgabe: @code{httpd}) Die @code{ServerRoot} in der Konfigurationsdatei, vorgegeben ist das httpd-Paket. Direktiven wie @code{Include} und @code{LoadModule} werden relativ zur ServerRoot interpretiert. @item @code{server-name} (Vorgabe: @code{#f}) Der @code{ServerName} in der Konfigurationsdatei, mit dem das Anfrageschema (Request Scheme), der Rechnername (Hostname) und Port angegeben wird, mit denen sich der Server identifiziert. Es muss nicht als Teil der Server-Konfiguration festgelegt werden, sondern kann auch in virtuellen Rechnern (Virtual Hosts) festgelegt werden. Vorgegeben ist @code{#f}, wodurch kein @code{ServerName} festgelegt wird. @item @code{document-root} (Vorgabe: @code{"/srv/http"}) Das @code{DocumentRoot}-Verzeichnis, in dem sich die Dateien befinden, die man vom Server abrufen kann. @item @code{listen} (Vorgabe: @code{'("80")}) Die Liste der Werte für die @code{Listen}-Direktive in der Konfigurationsdatei. Als Wert sollte eine Liste von Zeichenketten angegeben werden, die jeweils die Portnummer, auf der gelauscht wird, und optional auch die zu benutzende IP-Adresse und das Protokoll angeben. @item @code{pid-file} (Vorgabe: @code{"/var/run/httpd"}) Hiermit wird die PID-Datei als @code{PidFile}-Direktive angegeben. Der Wert sollte mit der @code{pid-file}-Datei in der @code{httpd-configuration} übereinstimmen, damit der Shepherd-Dienst richtig konfiguriert ist. @item @code{error-log} (Vorgabe: @code{"/var/log/httpd/error_log"}) Der Ort, an den der Server mit der @code{ErrorLog}-Direktive Fehlerprotokolle schreibt. @item @code{user} (Vorgabe: @code{"httpd"}) Der Benutzer, als der der Server durch die @code{User}-Direktive Anfragen beantwortet. @item @code{group} (Vorgabe: @code{"httpd"}) Die Gruppe, mit der der Server durch die @code{Group}-Direktive Anfragen beantwortet. @item @code{extra-config} (Vorgabe: @code{(list "TypesConfig etc/httpd/mime.types")}) Eine flache Liste von Zeichenketten und G-Ausdrücken, die am Ende der Konfigurationsdatei hinzugefügt werden. Alle Werte, mit denen dieser Dienst erweitert wird, werden an die Liste angehängt. @end table @end deffn @deffn {Datentyp} httpd-virtualhost Dieser Datentyp repräsentiert einen Konfigurationsblock für einen virtuellen Rechner (Virtual Host) des httpd-Dienstes. Sie sollten zur zusätzlichen Konfiguration extra-config des httpd-Dienstes hinzugefügt werden. @example (simple-service 'my-extra-server httpd-service-type (list (httpd-virtualhost "*:80" (list (string-append "ServerName "www.example.com DocumentRoot \"/srv/http/www.example.com\""))))) @end example @table @asis @item @code{addresses-and-ports} Adressen und Ports für die @code{VirtualHost}-Direktive. @item @code{contents} Der Inhalt der @code{VirtualHost}-Direktive. Er sollte als Liste von Zeichenketten und G-Ausdrücken angegeben werden. @end table @end deffn @subsubheading NGINX @deffn {Scheme-Variable} nginx-service-type Diensttyp für den @uref{https://nginx.org/,NGinx}-Webserver. Der Wert des Dienstes ist ein @code{}-Verbundsobjekt. Es folgt ein einfaches Beispiel der Konfiguration. @example (service nginx-service-type (nginx-configuration (server-blocks (list (nginx-server-configuration (server-name '("www.example.com")) (root "/srv/http/www.example.com")))))) @end example Außer durch direktes Hinzufügen von Server-Blöcken zur Dienstkonfiguration kann der Dienst auch durch andere Dienste erweitert werden, um Server-Blöcke hinzuzufügen, wie man im folgenden Beispiel sieht: @example (simple-service 'my-extra-server nginx-service-type (list (nginx-server-configuration (root "/srv/http/extra-website") (try-files (list "$uri" "$uri/index.html"))))) @end example @end deffn Beim Starten hat @command{nginx} seine Konfigurationsdatei noch nicht gelesen und benutzt eine vorgegebene Datei, um Fehlermeldungen zu protokollieren. Wenn er seine Konfigurationsdatei nicht laden kann, landen Fehlermeldungen also dort. Nachdem die Konfigurationsdatei geladen ist, werden Fehlerprotokolle nach Voreinstellung in die Datei geschrieben, die in der Konfiguration angegeben ist. In unserem Fall können Sie Fehlermeldungen beim Starten in @file{/var/run/nginx/logs/error.log} finden und nachdem die Konfiguration eingelesen wurde, finden Sie sie in @file{/var/log/nginx/error.log}. Letzterer Ort kann mit der Konfigurationsoption @var{log-directory} geändert werden. @deffn {Datentyp} nginx-configuration Dieser Datentyp repräsentiert die Konfiguration von NGinx. Ein Teil der Konfiguration kann hierüber und über die anderen zu Ihrer Verfügung stehenden Verbundstypen geschehen, alternativ können Sie eine Konfigurationsdatei mitgeben. @table @asis @item @code{nginx} (Vorgabe: @code{nginx}) Das zu benutzende nginx-Paket. @item @code{log-directory} (Vorgabe: @code{"/var/log/nginx"}) In welches Verzeichnis NGinx Protokolldateien schreiben wird. @item @code{run-directory} (Vorgabe: @code{"/var/run/nginx"}) In welchem Verzeichnis NGinx eine PID-Datei anlegen und temporäre Dateien ablegen wird. @item @code{server-blocks} (Vorgabe: @code{'()}) Eine Liste von @dfn{Server-Blöcken}, die in der erzeugten Konfigurationsdatei stehen sollen. Die Elemente davon sollten den Typ @code{} haben. Im folgenden Beispiel wäre NGinx so eingerichtet, dass Anfragen an @code{www.example.com} mit Dateien aus dem Verzeichnis @code{/srv/http/www.example.com} beantwortet werden, ohne HTTPS zu benutzen. @example (service nginx-service-type (nginx-configuration (server-blocks (list (nginx-server-configuration (server-name '("www.example.com")) (root "/srv/http/www.example.com")))))) @end example @item @code{upstream-blocks} (Vorgabe: @code{'()}) Eine Liste von @dfn{Upstream-Blöcken}, die in der erzeugten Konfigurationsdatei stehen sollen. Ihre Elemente sollten den Typ @code{} haben. Upstreams als @code{upstream-blocks} zu konfigurieren, kann hilfreich sein, wenn es mit @code{locations} in @code{} verbunden wird. Das folgende Beispiel erzeugt eine Server-Konfiguration mit einer Location-Konfiguration, bei der Anfragen als Proxy entsprechend einer Upstream-Konfiguration weitergeleitet werden, wodurch zwei Server diese beantworten können. @example (service nginx-service-type (nginx-configuration (server-blocks (list (nginx-server-configuration (server-name '("www.example.com")) (root "/srv/http/www.example.com") (locations (list (nginx-location-configuration (uri "/path1") (body '("proxy_pass http://server-proxy;")))))))) (upstream-blocks (list (nginx-upstream-configuration (name "server-proxy") (servers (list "server1.example.com" "server2.example.com"))))))) @end example @item @code{file} (default: @code{#f}) Wenn eine Konfigurationsdatei als @var{file} angegeben wird, dann wird diese benutzt und @emph{keine} Konfigurationsdatei anhand der angegebenen @code{log-directory}, @code{run-directory}, @code{server-blocks} und @code{upstream-blocks} erzeugt. Trotzdem sollten diese Argumente bei einer richtigen Konfiguration mit denen in der Datei @var{file} übereinstimmen, damit die Verzeichnisse bei Aktivierung des Dienstes erzeugt werden. Das kann nützlich sein, wenn Sie schon eine bestehende Konfigurationsdatei haben oder das, was Sie brauchen, nicht mit anderen Teilen eines nginx-configuration-Verbundsobjekts umgesetzt werden kann. @item @code{server-names-hash-bucket-size} (Vorgabe: @code{#f}) Größe der Behälter (englisch »Buckets«) für die Hashtabelle der Servernamen; vorgegeben ist @code{#f}, wodurch die Größe der Cache-Lines des Prozessors verwendet wird. @item @code{server-names-hash-bucket-max-size} (Vorgabe: @code{#f}) Maximale Behältergröße für die Hashtabelle der Servernamen. @item @code{extra-content} (Vorgabe: @code{""}) Zusätzlicher Inhalt des @code{http}-Blocks. Er sollte eine Zeichenkette oder ein zeichenkettenwertiger G-Ausdruck. @end table @end deffn @deftp {Datentyp} nginx-server-configuration Der Datentyp, der die Konfiguration eines nginx-Serverblocks repräsentiert. Dieser Typ hat die folgenden Parameter: @table @asis @item @code{listen} (Vorgabe: @code{'("80" "443 ssl")}) Jede @code{listen}-Direktive legt Adresse und Port für eine IP fest oder gibt einen Unix-Socket an, auf dem der Server Anfragen beantwortet. Es können entweder sowohl Adresse als auch Port oder nur die Adresse oder nur der Port angegeben werden. Als Adresse kann auch ein Rechnername (»Hostname«) angegeben werden, zum Beispiel: @example '("127.0.0.1:8000" "127.0.0.1" "8000" "*:8000" "localhost:8000") @end example @item @code{server-name} (Vorgabe: @code{(list 'default)}) Eine Liste von Servernamen, die dieser Server repräsentiert. @code{'default} repräsentiert den voreingestellten Server, der für Verbindungen verwendet wird, die zu keinem anderen Server passen. @item @code{root} (Vorgabe: @code{"/srv/http"}) Wurzelverzeichnis der Webpräsenz, die über nginx abgerufen werden kann. @item @code{locations} (Vorgabe: @code{'()}) Eine Liste von @dfn{nginx-location-configuration}- oder @dfn{nginx-named-location-configuration}-Verbundsobjekten, die innerhalb des Serverblocks benutzt werden. @item @code{index} (Vorgabe: @code{(list "index.html")}) Index-Dateien, mit denen Anfragen nach einem Verzeichnis beantwortet werden. Wenn @emph{keine} davon gefunden wird, antwortet Nginx mit der Liste der Dateien im Verzeichnis. @item @code{try-files} (Vorgabe: @code{'()}) Eine Liste der Dateien, bei denen in der angegebenen Reihenfolge geprüft wird, ob sie existieren. @code{nginx} beantwortet die Anfrage mit der ersten Datei, die es findet. @item @code{ssl-certificate} (Vorgabe: @code{#f}) Wo das Zertifikat für sichere Verbindungen gespeichert ist. Sie sollten es auf @code{#f} setzen, wenn Sie kein Zertifikat haben oder kein HTTPS benutzen möchten. @item @code{ssl-certificate-key} (Vorgabe: @code{#f}) Wo der private Schlüssel für sichere Verbindungen gespeichert ist. Sie sollten ihn auf @code{#f} setzen, wenn Sie keinen Schlüssel haben oder kein HTTPS benutzen möchten. @item @code{server-tokens?} (Vorgabe: @code{#f}) Ob der Server Informationen über seine Konfiguration bei Antworten beilegen soll. @item @code{raw-content} (Vorgabe: @code{'()}) Eine Liste von Zeilen, die unverändert in den Serverblock eingefügt werden. @end table @end deftp @deftp {Datentyp} nginx-upstream-configuration Der Datentyp, der die Konfiguration eines nginx-@code{upstream}-Blocks repräsentiert. Dieser Typ hat folgende Parameter: @table @asis @item @code{name} Der Name dieser Servergruppe. @item @code{servers} Gibt die Adressen der Server in der Gruppe an. Die Adresse kann als IP-Adresse (z.B.@: @samp{127.0.0.1}), Domänenname (z.B.@: @samp{backend1.example.com}) oder als Pfad eines Unix-Sockets mit dem vorangestellten Präfix @samp{unix:} angegeben werden. Wenn Adressen eine IP-Adresse oder einen Domänennamen benutzen, ist der voreingestellte Port 80, aber ein abweichender Port kann auch explizit angegeben werden. @end table @end deftp @deftp {Datentyp} nginx-location-configuration Der Datentyp, der die Konfiguration eines nginx-@code{location}-Blocks angibt. Der Typ hat die folgenden Parameter: @table @asis @item @code{uri} Die URI, die auf diesen Block passt. @anchor{nginx-location-configuration body} @item @code{body} Der Rumpf des location-Blocks, der als eine Liste von Zeichenketten angegeben werden muss. Er kann viele Konfigurationsdirektiven enthalten, zum Beispiel können Anfragen an eine Upstream-Servergruppe weitergeleitet werden, die mit einem @code{nginx-upstream-configuration}-Block angegeben wurde, indem diese Direktive im Rumpf angegeben wird: @samp{(list "proxy_pass http://upstream-name;")}. @end table @end deftp @deftp {Datentyp} nginx-named-location-configuration Der Datentyp repräsentiert die Konfiguration eines mit Namen versehenen nginx-location-Blocks (»Named Location Block«). Ein mit Namen versehener location-Block wird zur Umleitung von Anfragen benutzt und nicht für die normale Anfrageverarbeitung. Dieser Typ hat die folgenden Parameter: @table @asis @item @code{name} Der Name, mit dem dieser location-Block identifiziert wird. @item @code{body} Siehe @ref{nginx-location-configuration body}, weil der Rumpf (»Body«) eines mit Namen versehenen location-Blocks wie ein @code{nginx-location-configuration body} benutzt werden kann. Eine Einschränkung ist, dass der Rumpf eines mit Namen versehenen location-Blocks keine location-Blöcke enthalten kann. @end table @end deftp @subsubheading Varnish Cache @cindex Varnish Varnish is a fast cache server that sits in between web applications and end users. It proxies requests from clients and caches the accessed URLs such that multiple requests for the same resource only creates one request to the back-end. @defvr {Scheme Variable} varnish-service-type Service type for the Varnish daemon. @end defvr @deftp {Data Type} varnish-configuration Data type representing the @code{varnish} service configuration. This type has the following parameters: @table @asis @item @code{package} (Vorgabe: @code{varnish}) Das Varnish-Paket, was benutzt werden soll. @item @code{name} (Vorgabe: @code{"default"}) A name for this Varnish instance. Varnish will create a directory in @file{/var/varnish/} with this name and keep temporary files there. If the name starts with a forward slash, it is interpreted as an absolute directory name. Pass the @code{-n} argument to other Varnish programs to connect to the named instance, e.g.@: @command{varnishncsa -n default}. @item @code{backend} (Vorgabe: @code{"localhost:8080"}) The backend to use. This option has no effect if @code{vcl} is set. @item @code{vcl} (Vorgabe: #f) The @dfn{VCL} (Varnish Configuration Language) program to run. If this is @code{#f}, Varnish will proxy @code{backend} using the default configuration. Otherwise this must be a file-like object with valid VCL syntax. @c Varnish does not support HTTPS, so keep this URL to avoid confusion. For example, to mirror @url{http://www.gnu.org,www.gnu.org} with VCL you can do something along these lines: @example (define %gnu-mirror (plain-file "gnu.vcl" "vcl 4.1; backend gnu @{ .host = "www.gnu.org"; @}")) (operating-system ... (services (cons (service varnish-service-type (varnish-configuration (listen '(":80")) (vcl %gnu-mirror))) %base-services))) @end example The configuration of an already running Varnish instance can be inspected and changed using the @command{varnishadm} program. Consult the @url{https://varnish-cache.org/docs/,Varnish User Guide} and @url{https://book.varnish-software.com/4.0/,Varnish Book} for comprehensive documentation on Varnish and its configuration language. @item @code{listen} (Vorgabe: @code{'("localhost:80")}) List of addresses Varnish will listen on. @item @code{storage} (Vorgabe: @code{'("malloc,128m")}) List of storage backends that will be available in VCL. @item @code{parameters} (Vorgabe: @code{'()}) List of run-time parameters in the form @code{'(("parameter" . "value"))}. @item @code{extra-options} (Vorgabe: @code{'()}) Additional arguments to pass to the @command{varnishd} process. @end table @end deftp @subsubheading FastCGI @cindex fastcgi @cindex fcgiwrap FastCGI is an interface between the front-end and the back-end of a web service. It is a somewhat legacy facility; new web services should generally just talk HTTP between the front-end and the back-end. However there are a number of back-end services such as PHP or the optimized HTTP Git repository access that use FastCGI, so we have support for it in Guix. To use FastCGI, you configure the front-end web server (e.g., nginx) to dispatch some subset of its requests to the fastcgi backend, which listens on a local TCP or UNIX socket. There is an intermediary @code{fcgiwrap} program that sits between the actual backend process and the web server. The front-end indicates which backend program to run, passing that information to the @code{fcgiwrap} process. @defvr {Scheme Variable} fcgiwrap-service-type A service type for the @code{fcgiwrap} FastCGI proxy. @end defvr @deftp {Data Type} fcgiwrap-configuration Der Datentyp, der die Konfiguration des @code{fcgiwrap}-Dienstes repräsentiert. Dieser Typ hat die folgenden Parameter: @table @asis @item @code{package} (default: @code{fcgiwrap}) The fcgiwrap package to use. @item @code{socket} (default: @code{tcp:127.0.0.1:9000}) The socket on which the @code{fcgiwrap} process should listen, as a string. Valid @var{socket} values include @code{unix:@var{/path/to/unix/socket}}, @code{tcp:@var{dot.ted.qu.ad}:@var{port}} and @code{tcp6:[@var{ipv6_addr}]:port}. @item @code{user} (default: @code{fcgiwrap}) @itemx @code{group} (default: @code{fcgiwrap}) The user and group names, as strings, under which to run the @code{fcgiwrap} process. The @code{fastcgi} service will ensure that if the user asks for the specific user or group names @code{fcgiwrap} that the corresponding user and/or group is present on the system. It is possible to configure a FastCGI-backed web service to pass HTTP authentication information from the front-end to the back-end, and to allow @code{fcgiwrap} to run the back-end process as a corresponding local user. To enable this capability on the back-end., run @code{fcgiwrap} as the @code{root} user and group. Note that this capability also has to be configured on the front-end as well. @end table @end deftp @cindex php-fpm PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for sites of any size. These features include: @itemize @bullet @item Adaptive process spawning @item Basic statistics (similar to Apache's mod_status) @item Advanced process management with graceful stop/start @item Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode) @item Stdout & stderr logging @item Emergency restart in case of accidental opcode cache destruction @item Accelerated upload support @item Support for a "slowlog" @item Enhancements to FastCGI, such as fastcgi_finish_request() - a special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing, etc.) @end itemize ...@: and much more. @defvr {Scheme Variable} php-fpm-service-type A Service type for @code{php-fpm}. @end defvr @deftp {Data Type} php-fpm-configuration Data Type for php-fpm service configuration. @table @asis @item @code{php} (default: @code{php}) The php package to use. @item @code{socket} (default: @code{(string-append "/var/run/php" (version-major (package-version php)) "-fpm.sock")}) The address on which to accept FastCGI requests. Valid syntaxes are: @table @asis @item @code{"ip.add.re.ss:port"} Listen on a TCP socket to a specific address on a specific port. @item @code{"port"} Listen on a TCP socket to all addresses on a specific port. @item @code{"/path/to/unix/socket"} Listen on a unix socket. @end table @item @code{user} (default: @code{php-fpm}) User who will own the php worker processes. @item @code{group} (default: @code{php-fpm}) Group of the worker processes. @item @code{socket-user} (default: @code{php-fpm}) User who can speak to the php-fpm socket. @item @code{socket-group} (default: @code{php-fpm}) Group that can speak to the php-fpm socket. @item @code{pid-file} (default: @code{(string-append "/var/run/php" (version-major (package-version php)) "-fpm.pid")}) The process id of the php-fpm process is written to this file once the service has started. @item @code{log-file} (default: @code{(string-append "/var/log/php" (version-major (package-version php)) "-fpm.log")}) Log for the php-fpm master process. @item @code{process-manager} (default: @code{(php-fpm-dynamic-process-manager-configuration)}) Detailed settings for the php-fpm process manager. Must be either: @table @asis @item @code{} @item @code{} @item @code{} @end table @item @code{display-errors} (default @code{#f}) Determines whether php errors and warning should be sent to clients and displayed in their browsers. This is useful for local php development, but a security risk for public sites, as error messages can reveal passwords and personal data. @item @code{timezone} (Vorgabe: @code{#f}) Specifies @code{php_admin_value[date.timezone]} parameter. @item @code{workers-logfile} (default @code{(string-append "/var/log/php" (version-major (package-version php)) "-fpm.www.log")}) This file will log the @code{stderr} outputs of php worker processes. Can be set to @code{#f} to disable logging. @item @code{file} (default @code{#f}) An optional override of the whole configuration. You can use the @code{mixed-text-file} function or an absolute filepath for it. @end table @end deftp @deftp {Data type} php-fpm-dynamic-process-manager-configuration Data Type for the @code{dynamic} php-fpm process manager. With the @code{dynamic} process manager, spare worker processes are kept around based on it's configured limits. @table @asis @item @code{max-children} (default: @code{5}) Maximum of worker processes. @item @code{start-servers} (default: @code{2}) How many worker processes should be started on start-up. @item @code{min-spare-servers} (default: @code{1}) How many spare worker processes should be kept around at minimum. @item @code{max-spare-servers} (default: @code{3}) How many spare worker processes should be kept around at maximum. @end table @end deftp @deftp {Data type} php-fpm-static-process-manager-configuration Data Type for the @code{static} php-fpm process manager. With the @code{static} process manager, an unchanging number of worker processes are created. @table @asis @item @code{max-children} (default: @code{5}) Maximum of worker processes. @end table @end deftp @deftp {Data type} php-fpm-on-demand-process-manager-configuration Data Type for the @code{on-demand} php-fpm process manager. With the @code{on-demand} process manager, worker processes are only created as requests arrive. @table @asis @item @code{max-children} (default: @code{5}) Maximum of worker processes. @item @code{process-idle-timeout} (default: @code{10}) The time in seconds after which a process with no requests is killed. @end table @end deftp @deffn {Scheme Procedure} nginx-php-fpm-location @ [#:nginx-package nginx] @ [socket (string-append "/var/run/php" @ (version-major (package-version php)) @ "-fpm.sock")] A helper function to quickly add php to an @code{nginx-server-configuration}. @end deffn A simple services setup for nginx with php can look like this: @example (services (cons* (service dhcp-client-service-type) (service php-fpm-service-type) (service nginx-service-type (nginx-server-configuration (server-name '("example.com")) (root "/srv/http/") (locations (list (nginx-php-location))) (listen '("80")) (ssl-certificate #f) (ssl-certificate-key #f))) %base-services)) @end example @cindex cat-avatar-generator The cat avatar generator is a simple service to demonstrate the use of php-fpm in @code{Nginx}. It is used to generate cat avatar from a seed, for instance the hash of a user's email address. @deffn {Scheme-Prozedur} cat-avatar-generator-service @ [#:cache-dir "/var/cache/cat-avatar-generator"] @ [#:package cat-avatar-generator] @ [#:configuration (nginx-server-configuration)] Returns an nginx-server-configuration that inherits @code{configuration}. It extends the nginx configuration to add a server block that serves @code{package}, a version of cat-avatar-generator. During execution, cat-avatar-generator will be able to use @code{cache-dir} as its cache directory. @end deffn A simple setup for cat-avatar-generator can look like this: @example (services (cons* (cat-avatar-generator-service #:configuration (nginx-server-configuration (server-name '("example.com")))) ... %base-services)) @end example @subsubheading Hpcguix-web @cindex hpcguix-web The @uref{hpcguix-web, https://github.com/UMCUGenetics/hpcguix-web/} program is a customizable web interface to browse Guix packages, initially designed for users of high-performance computing (HPC) clusters. @defvr {Scheme Variable} hpcguix-web-service-type The service type for @code{hpcguix-web}. @end defvr @deftp {Data Type} hpcguix-web-configuration Data type for the hpcguix-web service configuration. @table @asis @item @code{specs} A gexp (@pxref{G-Ausdrücke}) specifying the hpcguix-web service configuration. The main items available in this spec are: @table @asis @item @code{title-prefix} (Vorgabe: @code{"hpcguix | "}) Das Präfix der Webseitentitel. @item @code{guix-command} (Vorgabe: @code{"guix"}) Der @command{guix}-Befehl. @item @code{package-filter-proc} (Vorgabe: @code{(const #t)}) Eine Prozedur, die festlegt, wie anzuzeigende Pakete gefiltert werden. @item @code{package-page-extension-proc} (Vorgabe: @code{(const '())}) Extension package for @code{hpcguix-web}. @item @code{menu} (Vorgabe: @code{'()}) Additional entry in page @code{menu}. @item @code{channels} (Vorgabe: @code{%default-channels}) List of channels from which the package list is built (@pxref{Kanäle}). @item @code{package-list-expiration} (Vorgabe: @code{(* 12 3600)}) The expiration time, in seconds, after which the package list is rebuilt from the latest instances of the given channels. @end table See the hpcguix-web repository for a @uref{https://github.com/UMCUGenetics/hpcguix-web/blob/master/hpcweb-configuration.scm, complete example}. @item @code{package} (Vorgabe: @code{hpcguix-web}) Das hpcguix-web-Paket, was benutzt werden soll. @end table @end deftp A typical hpcguix-web service declaration looks like this: @example (service hpcguix-web-service-type (hpcguix-web-configuration (specs #~(define site-config (hpcweb-configuration (title-prefix "Guix-HPC - ") (menu '(("/about" "ABOUT")))))))) @end example @quotation Anmerkung The hpcguix-web service periodically updates the package list it publishes by pulling channels from Git. To that end, it needs to access X.509 certificates so that it can authenticate Git servers when communicating over HTTPS, and it assumes that @file{/etc/ssl/certs} contains those certificates. Thus, make sure to add @code{nss-certs} or another certificate package to the @code{packages} field of your configuration. @ref{X.509-Zertifikate}, for more information on X.509 certificates. @end quotation @node Zertifikatsdienste @subsection Zertifikatsdienste @cindex Web @cindex HTTP, HTTPS @cindex Let's Encrypt @cindex TLS certificates The @code{(gnu services certbot)} module provides a service to automatically obtain a valid TLS certificate from the Let's Encrypt certificate authority. These certificates can then be used to serve content securely over HTTPS or other TLS-based protocols, with the knowledge that the client will be able to verify the server's authenticity. @url{https://letsencrypt.org/, Let's Encrypt} provides the @code{certbot} tool to automate the certification process. This tool first securely generates a key on the server. It then makes a request to the Let's Encrypt certificate authority (CA) to sign the key. The CA checks that the request originates from the host in question by using a challenge-response protocol, requiring the server to provide its response over HTTP. If that protocol completes successfully, the CA signs the key, resulting in a certificate. That certificate is valid for a limited period of time, and therefore to continue to provide TLS services, the server needs to periodically ask the CA to renew its signature. The certbot service automates this process: the initial key generation, the initial certification request to the Let's Encrypt service, the web server challenge/response integration, writing the certificate to disk, the automated periodic renewals, and the deployment tasks associated with the renewal (e.g.@: reloading services, copying keys with different permissions). Certbot is run twice a day, at a random minute within the hour. It won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your service a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason. By using this service, you agree to the ACME Subscriber Agreement, which can be found there: @url{https://acme-v01.api.letsencrypt.org/directory}. @defvr {Scheme Variable} certbot-service-type A service type for the @code{certbot} Let's Encrypt client. Its value must be a @code{certbot-configuration} record as in this example: @example (define %nginx-deploy-hook (program-file "nginx-deploy-hook" #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read))) (kill pid SIGHUP)))) (service certbot-service-type (certbot-configuration (email "foo@@example.net") (certificates (list (certificate-configuration (domains '("example.net" "www.example.net")) (deploy-hook %nginx-deploy-hook)) (certificate-configuration (domains '("bar.example.net"))))))) @end example See below for details about @code{certbot-configuration}. @end defvr @deftp {Data Type} certbot-configuration Data type representing the configuration of the @code{certbot} service. This type has the following parameters: @table @asis @item @code{package} (default: @code{certbot}) The certbot package to use. @item @code{webroot} (default: @code{/var/www}) The directory from which to serve the Let's Encrypt challenge/response files. @item @code{certificates} (default: @code{()}) A list of @code{certificates-configuration}s for which to generate certificates and request signatures. Each certificate has a @code{name} and several @code{domains}. @item @code{email} Mandatory email used for registration, recovery contact, and important account notifications. @item @code{rsa-key-size} (default: @code{2048}) Size of the RSA key. @item @code{default-location} (default: @i{see below}) The default @code{nginx-location-configuration}. Because @code{certbot} needs to be able to serve challenges and responses, it needs to be able to run a web server. It does so by extending the @code{nginx} web service with an @code{nginx-server-configuration} listening on the @var{domains} on port 80, and which has a @code{nginx-location-configuration} for the @code{/.well-known/} URI path subspace used by Let's Encrypt. @xref{Web-Dienste}, for more on these nginx configuration data types. Requests to other URL paths will be matched by the @code{default-location}, which if present is added to all @code{nginx-server-configuration}s. By default, the @code{default-location} will issue a redirect from @code{http://@var{domain}/...} to @code{https://@var{domain}/...}, leaving you to define what to serve on your site via @code{https}. Pass @code{#f} to not issue a default location. @end table @end deftp @deftp {Data Type} certificate-configuration Data type representing the configuration of a certificate. This type has the following parameters: @table @asis @item @code{name} (default: @i{see below}) This name is used by Certbot for housekeeping and in file paths; it doesn't affect the content of the certificate itself. To see certificate names, run @code{certbot certificates}. Its default is the first provided domain. @item @code{domains} (default: @code{()}) The first domain provided will be the subject CN of the certificate, and all domains will be Subject Alternative Names on the certificate. @item @code{deploy-hook} (default: @code{#f}) Command to be run in a shell once for each successfully issued certificate. For this command, the shell variable @code{$RENEWED_LINEAGE} will point to the config live subdirectory (for example, @samp{"/etc/letsencrypt/live/example.com"}) containing the new certificates and keys; the shell variable @code{$RENEWED_DOMAINS} will contain a space-delimited list of renewed certificate domains (for example, @samp{"example.com www.example.com"}. @end table @end deftp For each @code{certificate-configuration}, the certificate is saved to @code{/etc/letsencrypt/live/@var{name}/fullchain.pem} and the key is saved to @code{/etc/letsencrypt/live/@var{name}/privkey.pem}. @node DNS-Dienste @subsection DNS-Dienste @cindex DNS (domain name system) @cindex domain name system (DNS) The @code{(gnu services dns)} module provides services related to the @dfn{domain name system} (DNS). It provides a server service for hosting an @emph{authoritative} DNS server for multiple zones, slave or master. This service uses @uref{https://www.knot-dns.cz/, Knot DNS}. And also a caching and forwarding DNS server for the LAN, which uses @uref{http://www.thekelleys.org.uk/dnsmasq/doc.html, dnsmasq}. @subsubheading Knot-Dienst An example configuration of an authoritative server for two zones, one master and one slave, is: @lisp (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))) @end lisp @deffn {Scheme Variable} knot-service-type This is the type for the Knot DNS server. Knot DNS is an authoritative DNS server, meaning that it can serve multiple zones, that is to say domain names you would buy from a registrar. This server is not a resolver, meaning that it can only resolve names for which it is authoritative. This server can be configured to serve zones as a master server or a slave server as a per-zone basis. Slave zones will get their data from masters, and will serve it as an authoritative server. From the point of view of a resolver, there is no difference between master and slave. The following data types are used to configure the Knot DNS server: @end deffn @deftp {Data Type} knot-key-configuration Data type representing a key. This type has the following parameters: @table @asis @item @code{id} (default: @code{""}) An identifier for other configuration fields to refer to this key. IDs must be unique and must not be empty. @item @code{algorithm} (default: @code{#f}) The algorithm to use. Choose between @code{#f}, @code{'hmac-md5}, @code{'hmac-sha1}, @code{'hmac-sha224}, @code{'hmac-sha256}, @code{'hmac-sha384} and @code{'hmac-sha512}. @item @code{secret} (default: @code{""}) The secret key itself. @end table @end deftp @deftp {Data Type} knot-acl-configuration Data type representing an Access Control List (ACL) configuration. This type has the following parameters: @table @asis @item @code{id} (default: @code{""}) An identifier for ether configuration fields to refer to this key. IDs must be unique and must not be empty. @item @code{address} (default: @code{'()}) An ordered list of IP addresses, network subnets, or network ranges represented with strings. The query must match one of them. Empty value means that address match is not required. @item @code{key} (default: @code{'()}) An ordered list of references to keys represented with strings. The string must match a key ID defined in a @code{knot-key-configuration}. No key means that a key is not require to match that ACL. @item @code{action} (default: @code{'()}) An ordered list of actions that are permitted or forbidden by this ACL. Possible values are lists of zero or more elements from @code{'transfer}, @code{'notify} and @code{'update}. @item @code{deny?} (default: @code{#f}) When true, the ACL defines restrictions. Listed actions are forbidden. When false, listed actions are allowed. @end table @end deftp @deftp {Data Type} zone-entry Data type represnting a record entry in a zone file. This type has the following parameters: @table @asis @item @code{name} (default: @code{"@@"}) The name of the record. @code{"@@"} refers to the origin of the zone. Names are relative to the origin of the zone. For example, in the @code{example.org} zone, @code{"ns.example.org"} actually refers to @code{ns.example.org.example.org}. Names ending with a dot are absolute, which means that @code{"ns.example.org."} refers to @code{ns.example.org}. @item @code{ttl} (default: @code{""}) The Time-To-Live (TTL) of this record. If not set, the default TTL is used. @item @code{class} (default: @code{"IN"}) The class of the record. Knot currently supports only @code{"IN"} and partially @code{"CH"}. @item @code{type} (default: @code{"A"}) The type of the record. Common types include A (IPv4 address), AAAA (IPv6 address), NS (Name Server) and MX (Mail eXchange). Many other types are defined. @item @code{data} (default: @code{""}) The data contained in the record. For instance an IP address associated with an A record, or a domain name associated with an NS record. Remember that domain names are relative to the origin unless they end with a dot. @end table @end deftp @deftp {Data Type} zone-file Data type representing the content of a zone file. This type has the following parameters: @table @asis @item @code{entries} (default: @code{'()}) The list of entries. The SOA record is taken care of, so you don't need to put it in the list of entries. This list should probably contain an entry for your primary authoritative DNS server. Other than using a list of entries directly, you can use @code{define-zone-entries} to define a object containing the list of entries more easily, that you can later pass to the @code{entries} field of the @code{zone-file}. @item @code{origin} (default: @code{""}) The name of your zone. This parameter cannot be empty. @item @code{ns} (default: @code{"ns"}) The domain of your primary authoritative DNS server. The name is relative to the origin, unless it ends with a dot. It is mandatory that this primary DNS server corresponds to an NS record in the zone and that it is associated to an IP address in the list of entries. @item @code{mail} (default: @code{"hostmaster"}) An email address people can contact you at, as the owner of the zone. This is translated as @code{@@}. @item @code{serial} (default: @code{1}) The serial number of the zone. As this is used to keep track of changes by both slaves and resolvers, it is mandatory that it @emph{never} decreases. Always increment it when you make a change in your zone. @item @code{refresh} (default: @code{(* 2 24 3600)}) The frequency at which slaves will do a zone transfer. This value is a number of seconds. It can be computed by multiplications or with @code{(string->duration)}. @item @code{retry} (default: @code{(* 15 60)}) The period after which a slave will retry to contact its master when it fails to do so a first time. @item @code{expiry} (default: @code{(* 14 24 3600)}) Default TTL of records. Existing records are considered correct for at most this amount of time. After this period, resolvers will invalidate their cache and check again that it still exists. @item @code{nx} (default: @code{3600}) Default TTL of inexistant records. This delay is usually short because you want your new domains to reach everyone quickly. @end table @end deftp @deftp {Data Type} knot-remote-configuration Data type representing a remote configuration. This type has the following parameters: @table @asis @item @code{id} (default: @code{""}) An identifier for other configuration fields to refer to this remote. IDs must be unique and must not be empty. @item @code{address} (default: @code{'()}) An ordered list of destination IP addresses. Addresses are tried in sequence. An optional port can be given with the @@ separator. For instance: @code{(list "1.2.3.4" "2.3.4.5@@53")}. Default port is 53. @item @code{via} (default: @code{'()}) An ordered list of source IP addresses. An empty list will have Knot choose an appropriate source IP. An optional port can be given with the @@ separator. The default is to choose at random. @item @code{key} (default: @code{#f}) A reference to a key, that is a string containing the identifier of a key defined in a @code{knot-key-configuration} field. @end table @end deftp @deftp {Data Type} knot-keystore-configuration Data type representing a keystore to hold dnssec keys. This type has the following parameters: @table @asis @item @code{id} (default: @code{""}) The id of the keystore. It must not be empty. @item @code{backend} (default: @code{'pem}) The backend to store the keys in. Can be @code{'pem} or @code{'pkcs11}. @item @code{config} (default: @code{"/var/lib/knot/keys/keys"}) The configuration string of the backend. An example for the PKCS#11 is: @code{"pkcs11:token=knot;pin-value=1234 /gnu/store/.../lib/pkcs11/libsofthsm2.so"}. For the pem backend, the string reprensents a path in the file system. @end table @end deftp @deftp {Data Type} knot-policy-configuration Data type representing a dnssec policy. Knot DNS is able to automatically sign your zones. It can either generate and manage your keys automatically or use keys that you generate. Dnssec is usually implemented using two keys: a Key Signing Key (KSK) that is used to sign the second, and a Zone Signing Key (ZSK) that is used to sign the zone. In order to be trusted, the KSK needs to be present in the parent zone (usually a top-level domain). If your registrar supports dnssec, you will have to send them your KSK's hash so they can add a DS record in their zone. This is not automated and need to be done each time you change your KSK. The policy also defines the lifetime of keys. Usually, ZSK can be changed easily and use weaker cryptographic functions (they use lower parameters) in order to sign records quickly, so they are changed often. The KSK however requires manual interaction with the registrar, so they are changed less often and use stronger parameters because they sign only one record. This type has the following parameters: @table @asis @item @code{id} (default: @code{""}) The id of the policy. It must not be empty. @item @code{keystore} (default: @code{"default"}) A reference to a keystore, that is a string containing the identifier of a keystore defined in a @code{knot-keystore-configuration} field. The @code{"default"} identifier means the default keystore (a kasp database that was setup by this service). @item @code{manual?} (default: @code{#f}) Whether the key management is manual or automatic. @item @code{single-type-signing?} (default: @code{#f}) When @code{#t}, use the Single-Type Signing Scheme. @item @code{algorithm} (default: @code{"ecdsap256sha256"}) An algorithm of signing keys and issued signatures. @item @code{ksk-size} (default: @code{256}) The length of the KSK. Note that this value is correct for the default algorithm, but would be unsecure for other algorithms. @item @code{zsk-size} (default: @code{256}) The length of the ZSK. Note that this value is correct for the default algorithm, but would be unsecure for other algorithms. @item @code{dnskey-ttl} (default: @code{'default}) The TTL value for DNSKEY records added into zone apex. The special @code{'default} value means same as the zone SOA TTL. @item @code{zsk-lifetime} (default: @code{(* 30 24 3600)}) The period between ZSK publication and the next rollover initiation. @item @code{propagation-delay} (default: @code{(* 24 3600)}) An extra delay added for each key rollover step. This value should be high enough to cover propagation of data from the master server to all slaves. @item @code{rrsig-lifetime} (default: @code{(* 14 24 3600)}) A validity period of newly issued signatures. @item @code{rrsig-refresh} (default: @code{(* 7 24 3600)}) A period how long before a signature expiration the signature will be refreshed. @item @code{nsec3?} (default: @code{#f}) When @code{#t}, NSEC3 will be used instead of NSEC. @item @code{nsec3-iterations} (default: @code{5}) The number of additional times the hashing is performed. @item @code{nsec3-salt-length} (default: @code{8}) The length of a salt field in octets, which is appended to the original owner name before hashing. @item @code{nsec3-salt-lifetime} (default: @code{(* 30 24 3600)}) The validity period of newly issued salt field. @end table @end deftp @deftp {Data Type} knot-zone-configuration Data type representing a zone served by Knot. This type has the following parameters: @table @asis @item @code{domain} (default: @code{""}) The domain served by this configuration. It must not be empty. @item @code{file} (default: @code{""}) The file where this zone is saved. This parameter is ignored by master zones. Empty means default location that depends on the domain name. @item @code{zone} (default: @code{(zone-file)}) The content of the zone file. This parameter is ignored by slave zones. It must contain a zone-file record. @item @code{master} (default: @code{'()}) A list of master remotes. When empty, this zone is a master. When set, this zone is a slave. This is a list of remotes identifiers. @item @code{ddns-master} (default: @code{#f}) The main master. When empty, it defaults to the first master in the list of masters. @item @code{notify} (default: @code{'()}) A list of slave remote identifiers. @item @code{acl} (default: @code{'()}) A list of acl identifiers. @item @code{semantic-checks?} (default: @code{#f}) When set, this adds more semantic checks to the zone. @item @code{disable-any?} (default: @code{#f}) When set, this forbids queries of the ANY type. @item @code{zonefile-sync} (default: @code{0}) The delay between a modification in memory and on disk. 0 means immediate synchronization. @item @code{serial-policy} (default: @code{'increment}) A policy between @code{'increment} and @code{'unixtime}. @end table @end deftp @deftp {Data Type} knot-configuration Data type representing the Knot configuration. This type has the following parameters: @table @asis @item @code{knot} (default: @code{knot}) The Knot package. @item @code{run-directory} (default: @code{"/var/run/knot"}) The run directory. This directory will be used for pid file and sockets. @item @code{listen-v4} (default: @code{"0.0.0.0"}) An ip address on which to listen. @item @code{listen-v6} (default: @code{"::"}) An ip address on which to listen. @item @code{listen-port} (default: @code{53}) A port on which to listen. @item @code{keys} (default: @code{'()}) The list of knot-key-configuration used by this configuration. @item @code{acls} (default: @code{'()}) The list of knot-acl-configuration used by this configuration. @item @code{remotes} (default: @code{'()}) The list of knot-remote-configuration used by this configuration. @item @code{zones} (default: @code{'()}) The list of knot-zone-configuration used by this configuration. @end table @end deftp @subsubheading Dnsmasq-Dienst @deffn {Scheme Variable} dnsmasq-service-type This is the type of the dnsmasq service, whose value should be an @code{dnsmasq-configuration} object as in this example: @example (service dnsmasq-service-type (dnsmasq-configuration (no-resolv? #t) (servers '("192.168.1.1")))) @end example @end deffn @deftp {Datentyp} dnsmasq-configuration Repräsentiert die dnsmasq-Konfiguration. @table @asis @item @code{package} (Vorgabe: @var{dnsmasq}) Package object of the dnsmasq server. @item @code{no-hosts?} (Vorgabe: @code{#f}) When true, don't read the hostnames in /etc/hosts. @item @code{port} (Vorgabe: @code{53}) The port to listen on. Setting this to zero completely disables DNS responses, leaving only DHCP and/or TFTP functions. @item @code{local-service?} (Vorgabe: @code{#t}) Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server. @item @code{listen-addresses} (Vorgabe: @code{'()}) Listen on the given IP addresses. @item @code{resolv-file} (Vorgabe: @code{"/etc/resolv.conf"}) The file to read the IP address of the upstream nameservers from. @item @code{no-resolv?} (Vorgabe: @code{#f}) When true, don't read @var{resolv-file}. @item @code{servers} (default: @code{'()}) Specify IP address of upstream servers directly. @item @code{cache-size} (Vorgabe: @code{150}) Set the size of dnsmasq's cache. Setting the cache size to zero disables caching. @item @code{negative-cache?} (Vorgabe: @code{#t}) When false, disable negative caching. @end table @end deftp @subsubheading ddclient-Dienst @cindex ddclient The ddclient service described below runs the ddclient daemon, which takes care of automatically updating DNS entries for service providers such as @uref{https://dyn.com/dns/, Dyn}. The following example show instantiates the service with its default configuration: @example (service ddclient-service-type) @end example Note that ddclient needs to access credentials that are stored in a @dfn{secret file}, by default @file{/etc/ddclient/secrets} (see @code{secret-file} below.) You are expected to create this file manually, in an ``out-of-band'' fashion (you @emph{could} make this file part of the service configuration, for instance by using @code{plain-file}, but it will be world-readable @i{via} @file{/gnu/store}.) See the examples in the @file{share/ddclient} directory of the @code{ddclient} package. @c %start of fragment Available @code{ddclient-configuration} fields are: @deftypevr {@code{ddclient-configuration} parameter} package ddclient Das ddclient-Paket. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} integer daemon The period after which ddclient will retry to check IP and domain name. Defaults to @samp{300}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} boolean syslog Use syslog for the output. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string mail Mail to user. Defaults to @samp{"root"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string mail-failure Den Nutzer per Mail bei fehlgeschlagenen Aktualisierungen benachrichtigen. Defaults to @samp{"root"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string pid PID-Datei für den ddclient. Defaults to @samp{"/var/run/ddclient/ddclient.pid"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} boolean ssl Enable SSL support. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string user Specifies the user name or ID that is used when running ddclient program. Defaults to @samp{"ddclient"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string group Group of the user who will run the ddclient program. Defaults to @samp{"ddclient"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} string secret-file Secret file which will be appended to @file{ddclient.conf} file. This file contains credentials for use by ddclient. You are expected to create it manually. Defaults to @samp{"/etc/ddclient/secrets.conf"}. @end deftypevr @deftypevr {@code{ddclient-configuration} parameter} list extra-options Extra options will be appended to @file{ddclient.conf} file. Defaults to @samp{()}. @end deftypevr @c %end of fragment @node VPN-Dienste @subsection VPN-Dienste @cindex VPN (virtual private network) @cindex virtual private network (VPN) The @code{(gnu services vpn)} module provides services related to @dfn{virtual private networks} (VPNs). It provides a @emph{client} service for your machine to connect to a VPN, and a @emph{servire} service for your machine to host a VPN. Both services use @uref{https://openvpn.net/, OpenVPN}. @deffn {Scheme Procedure} openvpn-client-service @ [#:config (openvpn-client-configuration)] Return a service that runs @command{openvpn}, a VPN daemon, as a client. @end deffn @deffn {Scheme Procedure} openvpn-server-service @ [#:config (openvpn-server-configuration)] Return a service that runs @command{openvpn}, a VPN daemon, as a server. Both can be run simultaneously. @end deffn @c %automatically generated documentation Available @code{openvpn-client-configuration} fields are: @deftypevr {@code{openvpn-client-configuration} parameter} package openvpn The OpenVPN package. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} string pid-file The OpenVPN pid file. Defaults to @samp{"/var/run/openvpn/openvpn.pid"}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} proto proto The protocol (UDP or TCP) used to open a channel between clients and servers. Defaults to @samp{udp}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} dev dev The device type used to represent the VPN connection. Defaults to @samp{tun}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} string ca The certificate authority to check connections against. Defaults to @samp{"/etc/openvpn/ca.crt"}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} string cert The certificate of the machine the daemon is running on. It should be signed by the authority given in @code{ca}. Defaults to @samp{"/etc/openvpn/client.crt"}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} string key The key of the machine the daemon is running on. It must be the key whose certificate is @code{cert}. Defaults to @samp{"/etc/openvpn/client.key"}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} boolean comp-lzo? Whether to use the lzo compression algorithm. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-key? Don't re-read key files across SIGUSR1 or --ping-restart. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} boolean persist-tun? Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} number verbosity Verbosity level. Defaults to @samp{3}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} tls-auth-client tls-auth Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} key-usage verify-key-usage? Whether to check the server certificate has server usage extension. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} bind bind? Bind to a specific local port number. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} resolv-retry resolv-retry? Retry resolving server address. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-client-configuration} parameter} openvpn-remote-list remote A list of remote servers to connect to. Defaults to @samp{()}. Available @code{openvpn-remote-configuration} fields are: @deftypevr {@code{openvpn-remote-configuration} parameter} string name Server name. Defaults to @samp{"my-server"}. @end deftypevr @deftypevr {@code{openvpn-remote-configuration} parameter} number port Port number the server listens to. Defaults to @samp{1194}. @end deftypevr @end deftypevr @c %end of automatic openvpn-client documentation @c %automatically generated documentation Available @code{openvpn-server-configuration} fields are: @deftypevr {@code{openvpn-server-configuration} parameter} package openvpn The OpenVPN package. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string pid-file The OpenVPN pid file. Defaults to @samp{"/var/run/openvpn/openvpn.pid"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} proto proto The protocol (UDP or TCP) used to open a channel between clients and servers. Defaults to @samp{udp}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} dev dev The device type used to represent the VPN connection. Defaults to @samp{tun}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string ca The certificate authority to check connections against. Defaults to @samp{"/etc/openvpn/ca.crt"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string cert The certificate of the machine the daemon is running on. It should be signed by the authority given in @code{ca}. Defaults to @samp{"/etc/openvpn/client.crt"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string key The key of the machine the daemon is running on. It must be the key whose certificate is @code{cert}. Defaults to @samp{"/etc/openvpn/client.key"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} boolean comp-lzo? Whether to use the lzo compression algorithm. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-key? Don't re-read key files across SIGUSR1 or --ping-restart. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} boolean persist-tun? Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} number verbosity Verbosity level. Defaults to @samp{3}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} tls-auth-server tls-auth Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} number port Specifies the port number on which the server listens. Defaults to @samp{1194}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} ip-mask server An ip and mask specifying the subnet inside the virtual network. Defaults to @samp{"10.8.0.0 255.255.255.0"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} cidr6 server-ipv6 A CIDR notation specifying the IPv6 subnet inside the virtual network. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string dh The Diffie-Hellman parameters file. Defaults to @samp{"/etc/openvpn/dh2048.pem"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string ifconfig-pool-persist The file that records client IPs. Defaults to @samp{"/etc/openvpn/ipp.txt"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} gateway redirect-gateway? When true, the server will act as a gateway for its clients. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} boolean client-to-client? When true, clients are allowed to talk to each other inside the VPN. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} keepalive keepalive Causes ping-like messages to be sent back and forth over the link so that each side knows when the other side has gone down. @code{keepalive} requires a pair. The first element is the period of the ping sending, and the second element is the timeout before considering the other side down. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} number max-clients The maximum number of clients. Defaults to @samp{100}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} string status The status file. This file shows a small report on current connection. It is truncated and rewritten every minute. Defaults to @samp{"/var/run/openvpn/status"}. @end deftypevr @deftypevr {@code{openvpn-server-configuration} parameter} openvpn-ccd-list client-config-dir The list of configuration for some clients. Defaults to @samp{()}. Available @code{openvpn-ccd-configuration} fields are: @deftypevr {@code{openvpn-ccd-configuration} parameter} string name Client name. Defaults to @samp{"client"}. @end deftypevr @deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask iroute Client own network Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{openvpn-ccd-configuration} parameter} ip-mask ifconfig-push Client VPN IP. Defaults to @samp{#f}. @end deftypevr @end deftypevr @c %end of automatic openvpn-server documentation @node Network File System @subsection Network File System @cindex NFS The @code{(gnu services nfs)} module provides the following services, which are most commonly used in relation to mounting or exporting directory trees as @dfn{network file systems} (NFS). @subsubheading RPC Bind Service @cindex rpcbind The RPC Bind service provides a facility to map program numbers into universal addresses. Many NFS related services use this facility. Hence it is automatically started when a dependent service starts. @defvr {Scheme Variable} rpcbind-service-type A service type for the RPC portmapper daemon. @end defvr @deftp {Data Type} rpcbind-configuration Data type representing the configuration of the RPC Bind Service. This type has the following parameters: @table @asis @item @code{rpcbind} (default: @code{rpcbind}) The rpcbind package to use. @item @code{warm-start?} (default: @code{#t}) If this parameter is @code{#t}, then the daemon will read a state file on startup thus reloading state information saved by a previous instance. @end table @end deftp @subsubheading Pipefs Pseudo File System @cindex pipefs @cindex rpc_pipefs The pipefs file system is used to transfer NFS related data between the kernel and user space programs. @defvr {Scheme Variable} pipefs-service-type A service type for the pipefs pseudo file system. @end defvr @deftp {Data Type} pipefs-configuration Data type representing the configuration of the pipefs pseudo file system service. This type has the following parameters: @table @asis @item @code{mount-point} (default: @code{"/var/lib/nfs/rpc_pipefs"}) The directory to which the file system is to be attached. @end table @end deftp @subsubheading GSS Daemon Service @cindex GSSD @cindex GSS @cindex global security system The @dfn{global security system} (GSS) daemon provides strong security for RPC based protocols. Before exchanging RPC requests an RPC client must establish a security context. Typically this is done using the Kerberos command @command{kinit} or automatically at login time using PAM services (@pxref{Kerberos-Dienste}). @defvr {Scheme Variable} gss-service-type A service type for the Global Security System (GSS) daemon. @end defvr @deftp {Data Type} gss-configuration Data type representing the configuration of the GSS daemon service. This type has the following parameters: @table @asis @item @code{nfs-utils} (default: @code{nfs-utils}) The package in which the @command{rpc.gssd} command is to be found. @item @code{pipefs-directory} (default: @code{"/var/lib/nfs/rpc_pipefs"}) The directory where the pipefs file system is mounted. @end table @end deftp @subsubheading IDMAP Daemon Service @cindex idmapd @cindex name mapper The idmap daemon service provides mapping between user IDs and user names. Typically it is required in order to access file systems mounted via NFSv4. @defvr {Scheme Variable} idmap-service-type A service type for the Identity Mapper (IDMAP) daemon. @end defvr @deftp {Data Type} idmap-configuration Data type representing the configuration of the IDMAP daemon service. This type has the following parameters: @table @asis @item @code{nfs-utils} (default: @code{nfs-utils}) The package in which the @command{rpc.idmapd} command is to be found. @item @code{pipefs-directory} (default: @code{"/var/lib/nfs/rpc_pipefs"}) The directory where the pipefs file system is mounted. @item @code{domain} (default: @code{#f}) The local NFSv4 domain name. This must be a string or @code{#f}. If it is @code{#f} then the daemon will use the host's fully qualified domain name. @end table @end deftp @node Kontinuierliche Integration @subsection Kontinuierliche Integration @cindex continuous integration @uref{https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git, Cuirass} is a continuous integration tool for Guix. It can be used both for development and for providing substitutes to others (@pxref{Substitute}). The @code{(gnu services cuirass)} module provides the following service. @defvr {Scheme Procedure} cuirass-service-type The type of the Cuirass service. Its value must be a @code{cuirass-configuration} object, as described below. @end defvr To add build jobs, you have to set the @code{specifications} field of the configuration. Here is an example of a service that polls the Guix repository and builds the packages from a manifest. Some of the packages are defined in the @code{"custom-packages"} input, which is the equivalent of @code{GUIX_PACKAGE_PATH}. @example (define %cuirass-specs #~(list '((#:name . "my-manifest") (#:load-path-inputs . ("guix")) (#:package-path-inputs . ("custom-packages")) (#:proc-input . "guix") (#:proc-file . "build-aux/cuirass/gnu-system.scm") (#:proc . cuirass-jobs) (#:proc-args . ((subset . "manifests") (systems . ("x86_64-linux")) (manifests . (("config" . "guix/manifest.scm"))))) (#:inputs . (((#:name . "guix") (#:url . "git://git.savannah.gnu.org/guix.git") (#:load-path . ".") (#:branch . "master") (#:no-compile? . #t)) ((#:name . "config") (#:url . "git://git.example.org/config.git") (#:load-path . ".") (#:branch . "master") (#:no-compile? . #t)) ((#:name . "custom-packages") (#:url . "git://git.example.org/custom-packages.git") (#:load-path . ".") (#:branch . "master") (#:no-compile? . #t))))))) (service cuirass-service-type (cuirass-configuration (specifications %cuirass-specs))) @end example While information related to build jobs is located directly in the specifications, global settings for the @command{cuirass} process are accessible in other @code{cuirass-configuration} fields. @deftp {Data Type} cuirass-configuration Data type representing the configuration of Cuirass. @table @asis @item @code{log-file} (default: @code{"/var/log/cuirass.log"}) Location of the log file. @item @code{cache-directory} (default: @code{"/var/cache/cuirass"}) Location of the repository cache. @item @code{user} (default: @code{"cuirass"}) Owner of the @code{cuirass} process. @item @code{group} (default: @code{"cuirass"}) Owner's group of the @code{cuirass} process. @item @code{interval} (default: @code{60}) Number of seconds between the poll of the repositories followed by the Cuirass jobs. @item @code{database} (Vorgabe: @code{"/var/lib/cuirass/cuirass.db"}) Location of sqlite database which contains the build results and previously added specifications. @item @code{ttl} (Vorgabe: @code{(* 30 24 3600)}) Specifies the time-to-live (TTL) in seconds of garbage collector roots that are registered for build results. This means that build results are protected from garbage collection for at least @var{ttl} seconds. @item @code{port} (default: @code{8081}) Port number used by the HTTP server. @item --listen=@var{Host} Listen on the network interface for @var{host}. The default is to accept connections from localhost. @item @code{specifications} (default: @code{#~'()}) A gexp (@pxref{G-Ausdrücke}) that evaluates to a list of specifications, where a specification is an association list (@pxref{Associations Lists,,, guile, GNU Guile Reference Manual}) whose keys are keywords (@code{#:keyword-example}) as shown in the example above. @item @code{use-substitutes?} (default: @code{#f}) This allows using substitutes to avoid building every dependencies of a job from source. @item @code{one-shot?} (default: @code{#f}) Only evaluate specifications and build derivations once. @item @code{fallback?} (default: @code{#f}) When substituting a pre-built binary fails, fall back to building packages locally. @item @code{cuirass} (default: @code{cuirass}) The Cuirass package to use. @end table @end deftp @node Dienste zur Stromverbrauchsverwaltung @subsection Dienste zur Stromverbrauchsverwaltung @cindex tlp @cindex power management with TLP @subsubheading TLP-Daemon The @code{(gnu services pm)} module provides a Guix service definition for the Linux power management tool TLP. TLP enables various powersaving modes in userspace and kernel. Contrary to @code{upower-service}, it is not a passive, monitoring tool, as it will apply custom settings each time a new power source is detected. More information can be found at @uref{http://linrunner.de/en/tlp/tlp.html, TLP home page}. @deffn {Scheme Variable} tlp-service-type The service type for the TLP tool. Its value should be a valid TLP configuration (see below). To use the default settings, simply write: @example (service tlp-service-type) @end example @end deffn By default TLP does not need much configuration but most TLP parameters can be tweaked using @code{tlp-configuration}. Each parameter definition is preceded by its type; for example, @samp{boolean foo} indicates that the @code{foo} parameter should be specified as a boolean. Types starting with @code{maybe-} denote parameters that won't show up in TLP config file when their value is @code{'disabled}. @c The following documentation was initially generated by @c (generate-tlp-documentation) in (gnu services pm). Manually maintained @c documentation is better, so we shouldn't hesitate to edit below as @c needed. However if the change you want to make to this documentation @c can be done in an automated way, it's probably easier to change @c (generate-documentation) than to make it below and have to deal with @c the churn as TLP updates. Available @code{tlp-configuration} fields are: @deftypevr {@code{tlp-configuration} parameter} package tlp The TLP package. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean tlp-enable? Set to true if you wish to enable TLP. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string tlp-default-mode Default mode when no power supply can be detected. Alternatives are AC and BAT. Defaults to @samp{"AC"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer disk-idle-secs-on-ac Number of seconds Linux kernel has to wait after the disk goes idle, before syncing on AC. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer disk-idle-secs-on-bat Same as @code{disk-idle-ac} but on BAT mode. Defaults to @samp{2}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer max-lost-work-secs-on-ac Dirty pages flushing periodicity, expressed in seconds. Defaults to @samp{15}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer max-lost-work-secs-on-bat Same as @code{max-lost-work-secs-on-ac} but on BAT mode. Defaults to @samp{60}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list cpu-scaling-governor-on-ac CPU frequency scaling governor on AC mode. With intel_pstate driver, alternatives are powersave and performance. With acpi-cpufreq driver, alternatives are ondemand, powersave, performance and conservative. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list cpu-scaling-governor-on-bat Same as @code{cpu-scaling-governor-on-ac} but on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-min-freq-on-ac Set the min available frequency for the scaling governor on AC. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-max-freq-on-ac Set the max available frequency for the scaling governor on AC. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-min-freq-on-bat Set the min available frequency for the scaling governor on BAT. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-scaling-max-freq-on-bat Set the max available frequency for the scaling governor on BAT. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-min-perf-on-ac Limit the min P-state to control the power dissipation of the CPU, in AC mode. Values are stated as a percentage of the available performance. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-max-perf-on-ac Limit the max P-state to control the power dissipation of the CPU, in AC mode. Values are stated as a percentage of the available performance. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-min-perf-on-bat Same as @code{cpu-min-perf-on-ac} on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-non-negative-integer cpu-max-perf-on-bat Same as @code{cpu-max-perf-on-ac} on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-boolean cpu-boost-on-ac? Enable CPU turbo boost feature on AC mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-boolean cpu-boost-on-bat? Same as @code{cpu-boost-on-ac?} on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean sched-powersave-on-ac? Allow Linux kernel to minimize the number of CPU cores/hyper-threads used under light load conditions. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean sched-powersave-on-bat? Same as @code{sched-powersave-on-ac?} but on BAT mode. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean nmi-watchdog? Enable Linux kernel NMI watchdog. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-string phc-controls For Linux kernels with PHC patch applied, change CPU voltages. An example value would be @samp{"F:V F:V F:V F:V"}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string energy-perf-policy-on-ac Set CPU performance versus energy saving policy on AC. Alternatives are performance, normal, powersave. Defaults to @samp{"performance"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string energy-perf-policy-on-bat Same as @code{energy-perf-policy-ac} but on BAT mode. Defaults to @samp{"powersave"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disks-devices Hard disk devices. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disk-apm-level-on-ac Hard disk advanced power management level. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} space-separated-string-list disk-apm-level-on-bat Same as @code{disk-apm-bat} but on BAT mode. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-spindown-timeout-on-ac Hard disk spin down timeout. One value has to be specified for each declared hard disk. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-spindown-timeout-on-bat Same as @code{disk-spindown-timeout-on-ac} but on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list disk-iosched Select IO scheduler for disk devices. One value has to be specified for each declared hard disk. Example alternatives are cfq, deadline and noop. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string sata-linkpwr-on-ac SATA aggressive link power management (ALPM) level. Alternatives are min_power, medium_power, max_performance. Defaults to @samp{"max_performance"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string sata-linkpwr-on-bat Same as @code{sata-linkpwr-ac} but on BAT mode. Defaults to @samp{"min_power"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-string sata-linkpwr-blacklist Exclude specified SATA host devices for link power management. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-on-off-boolean ahci-runtime-pm-on-ac? Enable Runtime Power Management for AHCI controller and disks on AC mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-on-off-boolean ahci-runtime-pm-on-bat? Same as @code{ahci-runtime-pm-on-ac} on BAT mode. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer ahci-runtime-pm-timeout Seconds of inactivity before disk is suspended. Defaults to @samp{15}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string pcie-aspm-on-ac PCI Express Active State Power Management level. Alternatives are default, performance, powersave. Defaults to @samp{"performance"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string pcie-aspm-on-bat Same as @code{pcie-aspm-ac} but on BAT mode. Defaults to @samp{"powersave"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-power-profile-on-ac Radeon graphics clock speed level. Alternatives are low, mid, high, auto, default. Defaults to @samp{"high"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-power-profile-on-bat Same as @code{radeon-power-ac} but on BAT mode. Defaults to @samp{"low"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-state-on-ac Radeon dynamic power management method (DPM). Alternatives are battery, performance. Defaults to @samp{"performance"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-state-on-bat Same as @code{radeon-dpm-state-ac} but on BAT mode. Defaults to @samp{"battery"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-perf-level-on-ac Radeon DPM performance level. Alternatives are auto, low, high. Defaults to @samp{"auto"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string radeon-dpm-perf-level-on-bat Same as @code{radeon-dpm-perf-ac} but on BAT mode. Defaults to @samp{"auto"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} on-off-boolean wifi-pwr-on-ac? Wifi power saving mode. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} on-off-boolean wifi-pwr-on-bat? Same as @code{wifi-power-ac?} but on BAT mode. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} y-n-boolean wol-disable? Disable wake on LAN. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer sound-power-save-on-ac Timeout duration in seconds before activating audio power saving on Intel HDA and AC97 devices. A value of 0 disables power saving. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} non-negative-integer sound-power-save-on-bat Same as @code{sound-powersave-ac} but on BAT mode. Defaults to @samp{1}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} y-n-boolean sound-power-save-controller? Disable controller in powersaving mode on Intel HDA devices. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean bay-poweroff-on-bat? Enable optical drive in UltraBay/MediaBay on BAT mode. Drive can be powered on again by releasing (and reinserting) the eject lever or by pressing the disc eject button on newer models. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string bay-device Name of the optical drive device to power off. Defaults to @samp{"sr0"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string runtime-pm-on-ac Runtime Power Management for PCI(e) bus devices. Alternatives are on and auto. Defaults to @samp{"on"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} string runtime-pm-on-bat Same as @code{runtime-pm-ac} but on BAT mode. Defaults to @samp{"auto"}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean runtime-pm-all? Runtime Power Management for all PCI(e) bus devices, except blacklisted ones. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-space-separated-string-list runtime-pm-blacklist Exclude specified PCI(e) device addresses from Runtime Power Management. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} space-separated-string-list runtime-pm-driver-blacklist Exclude PCI(e) devices assigned to the specified drivers from Runtime Power Management. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean usb-autosuspend? Enable USB autosuspend feature. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-string usb-blacklist Exclude specified devices from USB autosuspend. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean usb-blacklist-wwan? Exclude WWAN devices from USB autosuspend. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-string usb-whitelist Include specified devices into USB autosuspend, even if they are already excluded by the driver or via @code{usb-blacklist-wwan?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} maybe-boolean usb-autosuspend-disable-on-shutdown? Enable USB autosuspend before shutdown. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{tlp-configuration} parameter} boolean restore-device-state-on-startup? Restore radio device state (bluetooth, wifi, wwan) from previous shutdown on system startup. Defaults to @samp{#f}. @end deftypevr @cindex thermald @cindex CPU frequency scaling with thermald @subsubheading Thermald-Daemon The @code{(gnu services pm)} module provides an interface to thermald, a CPU frequency scaling service which helps prevent overheating. @defvr {Scheme Variable} thermald-service-type This is the service type for @uref{https://01.org/linux-thermal-daemon/, thermald}, the Linux Thermal Daemon, which is responsible for controlling the thermal state of processors and preventing overheating. @end defvr @deftp {Data Type} thermald-configuration Data type representing the configuration of @code{thermald-service-type}. @table @asis @item @code{ignore-cpuid-check?} (default: @code{#f}) Ignore cpuid check for supported CPU models. @item @code{thermald} (default: @var{thermald}) Package object of thermald. @end table @end deftp @node Audio-Dienste @subsection Audio-Dienste The @code{(gnu services audio)} module provides a service to start MPD (the Music Player Daemon). @cindex mpd @subsubheading Music Player Daemon The Music Player Daemon (MPD) is a service that can play music while being controlled from the local machine or over the network by a variety of clients. The following example shows how one might run @code{mpd} as user @code{"bob"} on port @code{6666}. It uses pulseaudio for output. @example (service mpd-service-type (mpd-configuration (user "bob") (port "6666"))) @end example @defvr {Scheme Variable} mpd-service-type The service type for @command{mpd} @end defvr @deftp {Data Type} mpd-configuration Data type representing the configuration of @command{mpd}. @table @asis @item @code{user} (default: @code{"mpd"}) The user to run mpd as. @item @code{music-dir} (default: @code{"~/Music"}) The directory to scan for music files. @item @code{playlist-dir} (default: @code{"~/.mpd/playlists"}) The directory to store playlists. @item @code{db-file} (Vorgabe: @code{"~/.mpd/tag_cache"}) Der Ort, an dem die Musikdatenbank gespeichert wird. @item @code{state-file} (Vorgabe: @code{"~/.mpd/state"}) The location of the file that stores current MPD's state. @item @code{sticker-file} (Vorgabe: @code{"~/.mpd/sticker.sql"}) Der Ort, an dem die Sticker-Datenbank gespeichert wird. @item @code{port} (default: @code{"6600"}) The port to run mpd on. @item @code{address} (default: @code{"any"}) The address that mpd will bind to. To use a Unix domain socket, an absolute path can be specified here. @end table @end deftp @node Virtualisierungsdienste @subsection Virtualization services The @code{(gnu services virtualization)} module provides services for the libvirt and virtlog daemons, as well as other virtualization-related services. @subsubheading Libvirt daemon @code{libvirtd} is the server side daemon component of the libvirt virtualization management system. This daemon runs on host servers and performs required management tasks for virtualized guests. @deffn {Scheme Variable} libvirt-service-type This is the type of the @uref{https://libvirt.org, libvirt daemon}. Its value must be a @code{libvirt-configuration}. @example (service libvirt-service-type (libvirt-configuration (unix-sock-group "libvirt") (tls-port "16555"))) @end example @end deffn @c Auto-generated with (generate-libvirt-documentation) Available @code{libvirt-configuration} fields are: @deftypevr {@code{libvirt-configuration} parameter} package libvirt Libvirt package. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean listen-tls? Flag listening for secure TLS connections on the public TCP/IP port. must set @code{listen} for this to have any effect. It is necessary to setup a CA and issue server certificates before using this capability. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean listen-tcp? Listen for unencrypted TCP connections on the public TCP/IP port. must set @code{listen} for this to have any effect. Using the TCP socket requires SASL authentication by default. Only SASL mechanisms which support data encryption are allowed. This is DIGEST_MD5 and GSSAPI (Kerberos5) Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string tls-port Port for accepting secure TLS connections This can be a port number, or service name Defaults to @samp{"16514"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string tcp-port Port for accepting insecure TCP connections This can be a port number, or service name Defaults to @samp{"16509"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string listen-addr IP address or hostname used for client connections. Defaults to @samp{"0.0.0.0"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean mdns-adv? Flag toggling mDNS advertisement of the libvirt service. Alternatively can disable for all services on a host by stopping the Avahi daemon. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string mdns-name Default mDNS advertisement name. This must be unique on the immediate broadcast network. Defaults to @samp{"Virtualization Host "}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string unix-sock-group UNIX domain socket group ownership. This can be used to allow a 'trusted' set of users access to management capabilities without becoming root. Defaults to @samp{"root"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string unix-sock-ro-perms UNIX socket permissions for the R/O socket. This is used for monitoring VM status only. Defaults to @samp{"0777"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string unix-sock-rw-perms UNIX socket permissions for the R/W socket. Default allows only root. If PolicyKit is enabled on the socket, the default will change to allow everyone (eg, 0777) Defaults to @samp{"0770"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string unix-sock-admin-perms UNIX socket permissions for the admin socket. Default allows only owner (root), do not change it unless you are sure to whom you are exposing the access to. Defaults to @samp{"0777"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string unix-sock-dir The directory in which sockets will be found/created. Defaults to @samp{"/var/run/libvirt"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string auth-unix-ro Authentication scheme for UNIX read-only sockets. By default socket permissions allow anyone to connect Defaults to @samp{"polkit"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string auth-unix-rw Authentication scheme for UNIX read-write sockets. By default socket permissions only allow root. If PolicyKit support was compiled into libvirt, the default will be to use 'polkit' auth. Defaults to @samp{"polkit"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string auth-tcp Authentication scheme for TCP sockets. If you don't enable SASL, then all TCP traffic is cleartext. Don't do this outside of a dev/test scenario. Defaults to @samp{"sasl"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string auth-tls Authentication scheme for TLS sockets. TLS sockets already have encryption provided by the TLS layer, and limited authentication is done by certificates. It is possible to make use of any SASL authentication mechanism as well, by using 'sasl' for this option Defaults to @samp{"none"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} optional-list access-drivers API access control scheme. By default an authenticated user is allowed access to all APIs. Access drivers can place restrictions on this. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string key-file Server key file path. If set to an empty string, then no private key is loaded. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string cert-file Server key file path. If set to an empty string, then no certificate is loaded. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string ca-file Server key file path. If set to an empty string, then no CA certificate is loaded. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string crl-file Certificate revocation list path. If set to an empty string, then no CRL is loaded. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean tls-no-sanity-cert Disable verification of our own server certificates. When libvirtd starts it performs some sanity checks against its own certificates. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean tls-no-verify-cert Disable verification of client certificates. Client certificate verification is the primary authentication mechanism. Any client which does not present a certificate signed by the CA will be rejected. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} optional-list tls-allowed-dn-list Whitelist of allowed x509 Distinguished Name. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} optional-list sasl-allowed-usernames Whitelist of allowed SASL usernames. The format for username depends on the SASL authentication mechanism. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string tls-priority Override the compile time default TLS priority string. The default is usually "NORMAL" unless overridden at build time. Only set this is it is desired for libvirt to deviate from the global default settings. Defaults to @samp{"NORMAL"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-clients Maximum number of concurrent client connections to allow over all sockets combined. Defaults to @samp{5000}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-queued-clients Maximum length of queue of connections waiting to be accepted by the daemon. Note, that some protocols supporting retransmission may obey this so that a later reattempt at connection succeeds. Defaults to @samp{1000}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-anonymous-clients Maximum length of queue of accepted but not yet authenticated clients. Set this to zero to turn this feature off Defaults to @samp{20}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer min-workers Number of workers to start up initially. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-workers Maximum number of worker threads. If the number of active clients exceeds @code{min-workers}, then more threads are spawned, up to max_workers limit. Typically you'd want max_workers to equal maximum number of clients allowed. Defaults to @samp{20}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer prio-workers Number of priority workers. If all workers from above pool are stuck, some calls marked as high priority (notably domainDestroy) can be executed in this pool. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-requests Total global limit on concurrent RPC calls. Defaults to @samp{20}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer max-client-requests Limit on concurrent requests from a single client connection. To avoid one client monopolizing the server this should be a small fraction of the global max_requests and max_workers parameter. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-min-workers Same as @code{min-workers} but for the admin interface. Defaults to @samp{1}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-max-workers Same as @code{max-workers} but for the admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-max-clients Same as @code{max-clients} but for the admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-max-queued-clients Same as @code{max-queued-clients} but for the admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-max-client-requests Same as @code{max-client-requests} but for the admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer log-level Logging level. 4 errors, 3 warnings, 2 information, 1 debug. Defaults to @samp{3}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string log-filters Logging filters. A filter allows to select a different logging level for a given category of logs The format for a filter is one of: @itemize @bullet @item x:name @item x:+name @end itemize where @code{name} is a string which is matched against the category given in the @code{VIR_LOG_INIT()} at the top of each libvirt source file, e.g., "remote", "qemu", or "util.json" (the name in the filter can be a substring of the full category name, in order to match multiple similar categories), the optional "+" prefix tells libvirt to log stack trace for each message matching name, and @code{x} is the minimal level where matching messages should be logged: @itemize @bullet @item 1: DEBUG @item 2: INFO @item 3: WARNING @item 4: ERROR @end itemize Multiple filters can be defined in a single filters statement, they just need to be separated by spaces. Defaults to @samp{"3:remote 4:event"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string log-outputs Logging outputs. An output is one of the places to save logging information The format for an output can be: @table @code @item x:stderr output goes to stderr @item x:syslog:name use syslog for the output and use the given name as the ident @item x:file:file_path output to a file, with the given filepath @item x:journald output to journald logging system @end table In all case the x prefix is the minimal level, acting as a filter @itemize @bullet @item 1: DEBUG @item 2: INFO @item 3: WARNING @item 4: ERROR @end itemize Multiple outputs can be defined, they just need to be separated by spaces. Defaults to @samp{"3:stderr"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer audit-level Allows usage of the auditing subsystem to be altered @itemize @bullet @item 0: disable all auditing @item 1: enable auditing, only if enabled on host @item 2: enable auditing, and exit if disabled on host. @end itemize Defaults to @samp{1}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} boolean audit-logging Send audit messages via libvirt logging infrastructure. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} optional-string host-uuid Host UUID. UUID must not have all digits be the same. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} string host-uuid-source Source to read host UUID. @itemize @bullet @item @code{smbios}: fetch the UUID from @code{dmidecode -s system-uuid} @item @code{machine-id}: fetch the UUID from @code{/etc/machine-id} @end itemize If @code{dmidecode} does not provide a valid UUID a temporary UUID will be generated. Defaults to @samp{"smbios"}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer keepalive-interval A keepalive message is sent to a client after @code{keepalive_interval} seconds of inactivity to check if the client is still responding. If set to -1, libvirtd will never send keepalive requests; however clients can still send them and the daemon will send responses. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer keepalive-count Maximum number of keepalive messages that are allowed to be sent to the client without getting any response before the connection is considered broken. In other words, the connection is automatically closed approximately after @code{keepalive_interval * (keepalive_count + 1)} seconds since the last message received from the client. When @code{keepalive-count} is set to 0, connections will be automatically closed after @code{keepalive-interval} seconds of inactivity without sending any keepalive messages. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-keepalive-interval Same as above but for admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer admin-keepalive-count Same as above but for admin interface. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{libvirt-configuration} parameter} integer ovs-timeout Timeout for Open vSwitch calls. The @code{ovs-vsctl} utility is used for the configuration and its timeout option is set by default to 5 seconds to avoid potential infinite waits blocking libvirt. Defaults to @samp{5}. @end deftypevr @c %end of autogenerated docs @subsubheading Virtlog daemon The virtlogd service is a server side daemon component of libvirt that is used to manage logs from virtual machine consoles. This daemon is not used directly by libvirt client applications, rather it is called on their behalf by @code{libvirtd}. By maintaining the logs in a standalone daemon, the main @code{libvirtd} daemon can be restarted without risk of losing logs. The @code{virtlogd} daemon has the ability to re-exec() itself upon receiving @code{SIGUSR1}, to allow live upgrades without downtime. @deffn {Scheme Variable} virtlog-service-type This is the type of the virtlog daemon. Its value must be a @code{virtlog-configuration}. @example (service virtlog-service-type (virtlog-configuration (max-clients 1000))) @end example @end deffn @deftypevr {@code{virtlog-configuration} parameter} integer log-level Logging level. 4 errors, 3 warnings, 2 information, 1 debug. Defaults to @samp{3}. @end deftypevr @deftypevr {@code{virtlog-configuration} parameter} string log-filters Logging filters. A filter allows to select a different logging level for a given category of logs The format for a filter is one of: @itemize @bullet @item x:name @item x:+name @end itemize where @code{name} is a string which is matched against the category given in the @code{VIR_LOG_INIT()} at the top of each libvirt source file, e.g., "remote", "qemu", or "util.json" (the name in the filter can be a substring of the full category name, in order to match multiple similar categories), the optional "+" prefix tells libvirt to log stack trace for each message matching name, and @code{x} is the minimal level where matching messages should be logged: @itemize @bullet @item 1: DEBUG @item 2: INFO @item 3: WARNING @item 4: ERROR @end itemize Multiple filters can be defined in a single filters statement, they just need to be separated by spaces. Defaults to @samp{"3:remote 4:event"}. @end deftypevr @deftypevr {@code{virtlog-configuration} parameter} string log-outputs Logging outputs. An output is one of the places to save logging information The format for an output can be: @table @code @item x:stderr output goes to stderr @item x:syslog:name use syslog for the output and use the given name as the ident @item x:file:file_path output to a file, with the given filepath @item x:journald output to journald logging system @end table In all case the x prefix is the minimal level, acting as a filter @itemize @bullet @item 1: DEBUG @item 2: INFO @item 3: WARNING @item 4: ERROR @end itemize Multiple outputs can be defined, they just need to be separated by spaces. Defaults to @samp{"3:stderr"}. @end deftypevr @deftypevr {@code{virtlog-configuration} parameter} integer max-clients Maximum number of concurrent client connections to allow over all sockets combined. Defaults to @samp{1024}. @end deftypevr @deftypevr {@code{virtlog-configuration} parameter} integer max-size Maximum file size before rolling over. Defaults to @samp{2MB} @end deftypevr @deftypevr {@code{virtlog-configuration} parameter} integer max-backups Maximum number of backup files to keep. Defaults to @samp{3} @end deftypevr @subsubheading Transparent Emulation with QEMU @cindex emulation @cindex @code{binfmt_misc} @code{qemu-binfmt-service-type} provides support for transparent emulation of program binaries built for different architectures---e.g., it allows you to transparently execute an ARMv7 program on an x86_64 machine. It achieves this by combining the @uref{https://www.qemu.org, QEMU} emulator and the @code{binfmt_misc} feature of the kernel Linux. @defvr {Scheme Variable} qemu-binfmt-service-type This is the type of the QEMU/binfmt service for transparent emulation. Its value must be a @code{qemu-binfmt-configuration} object, which specifies the QEMU package to use as well as the architecture we want to emulated: @example (service qemu-binfmt-service-type (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el")))) @end example In this example, we enable transparent emulation for the ARM and aarch64 platforms. Running @code{herd stop qemu-binfmt} turns it off, and running @code{herd start qemu-binfmt} turns it back on (@pxref{Invoking herd, the @command{herd} command,, shepherd, The GNU Shepherd Manual}). @end defvr @deftp {Data Type} qemu-binfmt-configuration This is the configuration for the @code{qemu-binfmt} service. @table @asis @item @code{platforms} (default: @code{'()}) The list of emulated QEMU platforms. Each item must be a @dfn{platform object} as returned by @code{lookup-qemu-platforms} (see below). @item @code{guix-support?} (default: @code{#f}) When it is true, QEMU and all its dependencies are added to the build environment of @command{guix-daemon} (@pxref{Aufruf des guix-daemon, @code{--chroot-directory} option}). This allows the @code{binfmt_misc} handlers to be used within the build environment, which in turn means that you can transparently build programs for another architecture. For example, let's suppose you're on an x86_64 machine and you have this service: @example (service qemu-binfmt-service-type (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm")) (guix-support? #t))) @end example You can run: @example guix build -s armhf-linux inkscape @end example @noindent and it will build Inkscape for ARMv7 @emph{as if it were a native build}, transparently using QEMU to emulate the ARMv7 CPU. Pretty handy if you'd like to test a package build for an architecture you don't have access to! @item @code{qemu} (default: @code{qemu}) The QEMU package to use. @end table @end deftp @deffn {Scheme Procedure} lookup-qemu-platforms @var{platforms}@dots{} Return the list of QEMU platform objects corresponding to @var{platforms}@dots{}. @var{platforms} must be a list of strings corresponding to platform names, such as @code{"arm"}, @code{"sparc"}, @code{"mips64el"}, and so on. @end deffn @deffn {Scheme Procedure} qemu-platform? @var{obj} Return true if @var{obj} is a platform object. @end deffn @deffn {Scheme Procedure} qemu-platform-name @var{platform} Return the name of @var{platform}---a string such as @code{"arm"}. @end deffn @node Versionskontrolldienste @subsection Versionskontrolldienste The @code{(gnu services version-control)} module provides a service to allow remote access to local Git repositories. There are three options: the @code{git-daemon-service}, which provides access to repositories via the @code{git://} unsecured TCP-based protocol, extending the @code{nginx} web server to proxy some requests to @code{git-http-backend}, or providing a web interface with @code{cgit-service-type}. @deffn {Scheme Procedure} git-daemon-service [#:config (git-daemon-configuration)] Return a service that runs @command{git daemon}, a simple TCP server to expose repositories over the Git protocol for anonymous access. The optional @var{config} argument should be a @code{} object, by default it allows read-only access to exported@footnote{By creating the magic file "git-daemon-export-ok" in the repository directory.} repositories under @file{/srv/git}. @end deffn @deftp {Data Type} git-daemon-configuration Data type representing the configuration for @code{git-daemon-service}. @table @asis @item @code{package} (default: @var{git}) Package object of the Git distributed version control system. @item @code{export-all?} (default: @var{#f}) Whether to allow access for all Git repositories, even if they do not have the @file{git-daemon-export-ok} file. @item @code{base-path} (default: @file{/srv/git}) Whether to remap all the path requests as relative to the given path. If you run git daemon with @var{(base-path "/srv/git")} on example.com, then if you later try to pull @code{git://example.com/hello.git}, git daemon will interpret the path as @code{/srv/git/hello.git}. @item @code{user-path} (default: @var{#f}) Whether to allow @code{~user} notation to be used in requests. When specified with empty string, requests to @code{git://host/~alice/foo} is taken as a request to access @code{foo} repository in the home directory of user @code{alice}. If @var{(user-path "path")} is specified, the same request is taken as a request to access @code{path/foo} repository in the home directory of user @code{alice}. @item @code{listen} (default: @var{'()}) Whether to listen on specific IP addresses or hostnames, defaults to all. @item @code{port} (default: @var{#f}) Whether to listen on an alternative port, which defaults to 9418. @item @code{whitelist} (default: @var{'()}) If not empty, only allow access to this list of directories. @item @code{extra-options} (default: @var{'()}) Extra options will be passed to @code{git daemon}, please run @command{man git-daemon} for more information. @end table @end deftp The @code{git://} protocol lacks authentication. When you pull from a repository fetched via @code{git://}, you don't know that the data you receive was modified is really coming from the specified host, and you have your connection is subject to eavesdropping. It's better to use an authenticated and encrypted transport, such as @code{https}. Although Git allows you to serve repositories using unsophisticated file-based web servers, there is a faster protocol implemented by the @code{git-http-backend} program. This program is the back-end of a proper Git web service. It is designed to sit behind a FastCGI proxy. @xref{Web-Dienste}, for more on running the necessary @code{fcgiwrap} daemon. Guix has a separate configuration data type for serving Git repositories over HTTP. @deftp {Data Type} git-http-configuration Data type representing the configuration for @code{git-http-service}. @table @asis @item @code{package} (default: @var{git}) Package object of the Git distributed version control system. @item @code{git-root} (default: @file{/srv/git}) Directory containing the Git repositories to expose to the world. @item @code{export-all?} (default: @var{#f}) Whether to expose access for all Git repositories in @var{git-root}, even if they do not have the @file{git-daemon-export-ok} file. @item @code{uri-path} (default: @file{/git/}) Path prefix for Git access. With the default @code{/git/} prefix, this will map @code{http://@var{server}/git/@var{repo}.git} to @code{/srv/git/@var{repo}.git}. Requests whose URI paths do not begin with this prefix are not passed on to this Git instance. @item @code{fcgiwrap-socket} (default: @code{127.0.0.1:9000}) The socket on which the @code{fcgiwrap} daemon is listening. @xref{Web-Dienste}. @end table @end deftp There is no @code{git-http-service-type}, currently; instead you can create an @code{nginx-location-configuration} from a @code{git-http-configuration} and then add that location to a web server. @deffn {Scheme Procedure} git-http-nginx-location-configuration @ [config=(git-http-configuration)] Compute an @code{nginx-location-configuration} that corresponds to the given Git http configuration. An example nginx service definition to serve the default @file{/srv/git} over HTTPS might be: @example (service nginx-service-type (nginx-configuration (server-blocks (list (nginx-server-configuration (listen '("443 ssl")) (server-name "git.my-host.org") (ssl-certificate "/etc/letsencrypt/live/git.my-host.org/fullchain.pem") (ssl-certificate-key "/etc/letsencrypt/live/git.my-host.org/privkey.pem") (locations (list (git-http-nginx-location-configuration (git-http-configuration (uri-path "/")))))))))) @end example This example assumes that you are using Let's Encrypt to get your TLS certificate. @xref{Zertifikatsdienste}. The default @code{certbot} service will redirect all HTTP traffic on @code{git.my-host.org} to HTTPS. You will also need to add an @code{fcgiwrap} proxy to your system services. @xref{Web-Dienste}. @end deffn @subsubheading Cgit Service @cindex Cgit service @cindex Git, web interface @uref{https://git.zx2c4.com/cgit/, Cgit} is a web frontend for Git repositories written in C. The following example will configure the service with default values. By default, Cgit can be accessed on port 80 (@code{http://localhost:80}). @example (service cgit-service-type) @end example The @code{file-object} type designates either a file-like object (@pxref{G-Ausdrücke, file-like objects}) or a string. @c %start of fragment Available @code{cgit-configuration} fields are: @deftypevr {@code{cgit-configuration} parameter} package package The CGIT package. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} nginx-server-configuration-list nginx NGINX configuration. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object about-filter Specifies a command which will be invoked to format the content of about pages (both top-level and for each repository). Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string agefile Specifies a path, relative to each repository path, which can be used to specify the date and time of the youngest commit in the repository. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object auth-filter Specifies a command that will be invoked for authenticating repository access. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string branch-sort Flag which, when set to @samp{age}, enables date ordering in the branch ref list, and when set @samp{name} enables ordering by branch name. Defaults to @samp{"name"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string cache-root Path used to store the cgit cache entries. Defaults to @samp{"/var/cache/cgit"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-static-ttl Number which specifies the time-to-live, in minutes, for the cached version of repository pages accessed with a fixed SHA1. Defaults to @samp{-1}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-dynamic-ttl Number which specifies the time-to-live, in minutes, for the cached version of repository pages accessed without a fixed SHA1. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-repo-ttl Number which specifies the time-to-live, in minutes, for the cached version of the repository summary page. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-root-ttl Number which specifies the time-to-live, in minutes, for the cached version of the repository index page. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-scanrc-ttl Number which specifies the time-to-live, in minutes, for the result of scanning a path for Git repositories. Defaults to @samp{15}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-about-ttl Number which specifies the time-to-live, in minutes, for the cached version of the repository about page. Defaults to @samp{15}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-snapshot-ttl Number which specifies the time-to-live, in minutes, for the cached version of snapshots. Defaults to @samp{5}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer cache-size The maximum number of entries in the cgit cache. When set to @samp{0}, caching is disabled. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean case-sensitive-sort? Sort items in the repo list case sensitively. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} list clone-prefix List of common prefixes which, when combined with a repository URL, generates valid clone URLs for the repository. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} list clone-url List of @code{clone-url} templates. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object commit-filter Command which will be invoked to format commit messages. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string commit-sort Flag which, when set to @samp{date}, enables strict date ordering in the commit log, and when set to @samp{topo} enables strict topological ordering. Defaults to @samp{"git log"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object css URL which specifies the css document to include in all cgit pages. Defaults to @samp{"/share/cgit/cgit.css"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object email-filter Specifies a command which will be invoked to format names and email address of committers, authors, and taggers, as represented in various places throughout the cgit interface. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean embedded? Flag which, when set to @samp{#t}, will make cgit generate a HTML fragment suitable for embedding in other HTML pages. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-commit-graph? Flag which, when set to @samp{#t}, will make cgit print an ASCII-art commit history graph to the left of the commit messages in the repository log page. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-filter-overrides? Flag which, when set to @samp{#t}, allows all filter settings to be overridden in repository-specific cgitrc files. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-follow-links? Flag which, when set to @samp{#t}, allows users to follow a file in the log view. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-http-clone? If set to @samp{#t}, cgit will act as an dumb HTTP endpoint for Git clones. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-index-links? Flag which, when set to @samp{#t}, will make cgit generate extra links "summary", "commit", "tree" for each repo in the repository index. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-index-owner? Flag which, when set to @samp{#t}, will make cgit display the owner of each repo in the repository index. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-log-filecount? Flag which, when set to @samp{#t}, will make cgit print the number of modified files for each commit on the repository log page. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-log-linecount? Flag which, when set to @samp{#t}, will make cgit print the number of added and removed lines for each commit on the repository log page. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-remote-branches? Flag which, when set to @code{#t}, will make cgit display remote branches in the summary and refs views. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-subject-links? Flag which, when set to @code{1}, will make cgit use the subject of the parent commit as link text when generating links to parent commits in commit view. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-html-serving? Flag which, when set to @samp{#t}, will make cgit use the subject of the parent commit as link text when generating links to parent commits in commit view. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-tree-linenumbers? Flag which, when set to @samp{#t}, will make cgit generate linenumber links for plaintext blobs printed in the tree view. Defaults to @samp{#t}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean enable-git-config? Flag which, when set to @samp{#f}, will allow cgit to use Git config to set any repo specific settings. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object favicon URL used as link to a shortcut icon for cgit. Defaults to @samp{"/favicon.ico"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string footer The content of the file specified with this option will be included verbatim at the bottom of all pages (i.e.@: it replaces the standard "generated by..."@: message). Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string head-include The content of the file specified with this option will be included verbatim in the HTML HEAD section on all pages. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string header The content of the file specified with this option will be included verbatim at the top of all pages. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object include Name of a configfile to include before the rest of the current config- file is parsed. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string index-header The content of the file specified with this option will be included verbatim above the repository index. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string index-info The content of the file specified with this option will be included verbatim below the heading on the repository index page. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean local-time? Flag which, if set to @samp{#t}, makes cgit print commit and tag times in the servers timezone. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object logo URL which specifies the source of an image which will be used as a logo on all cgit pages. Defaults to @samp{"/share/cgit/cgit.png"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string logo-link URL loaded when clicking on the cgit logo image. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object owner-filter Command which will be invoked to format the Owner column of the main page. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-atom-items Number of items to display in atom feeds view. Defaults to @samp{10}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-commit-count Number of entries to list per page in "log" view. Defaults to @samp{50}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-message-length Number of commit message characters to display in "log" view. Defaults to @samp{80}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-repo-count Specifies the number of entries to list per page on the repository index page. Defaults to @samp{50}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-repodesc-length Specifies the maximum number of repo description characters to display on the repository index page. Defaults to @samp{80}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer max-blob-size Specifies the maximum size of a blob to display HTML for in KBytes. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string max-stats Maximum statistics period. Valid values are @samp{week},@samp{month}, @samp{quarter} and @samp{year}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} mimetype-alist mimetype Mimetype for the specified filename extension. Defaults to @samp{((gif "image/gif") (html "text/html") (jpg "image/jpeg") (jpeg "image/jpeg") (pdf "application/pdf") (png "image/png") (svg "image/svg+xml"))}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object mimetype-file Specifies the file to use for automatic mimetype lookup. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string module-link Text which will be used as the formatstring for a hyperlink when a submodule is printed in a directory listing. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean nocache? If set to the value @samp{#t} caching will be disabled. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean noplainemail? If set to @samp{#t} showing full author email addresses will be disabled. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean noheader? Flag which, when set to @samp{#t}, will make cgit omit the standard header on all pages. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} project-list project-list A list of subdirectories inside of @code{repository-directory}, relative to it, that should loaded as Git repositories. An empty list means that all subdirectories will be loaded. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object readme Text which will be used as default value for @code{cgit-repo-readme}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean remove-suffix? If set to @code{#t} and @code{repository-directory} is enabled, if any repositories are found with a suffix of @code{.git}, this suffix will be removed for the URL and name. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer renamelimit Maximum number of files to consider when detecting renames. Defaults to @samp{-1}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string repository-sort The way in which repositories in each section are sorted. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} robots-list robots Text used as content for the @code{robots} meta-tag. Defaults to @samp{("noindex" "nofollow")}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string root-desc Text printed below the heading on the repository index page. Defaults to @samp{"a fast webinterface for the git dscm"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string root-readme The content of the file specified with this option will be included verbatim below thef "about" link on the repository index page. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string root-title Text printed as heading on the repository index page. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean scan-hidden-path If set to @samp{#t} and repository-directory is enabled, repository-directory will recurse into directories whose name starts with a period. Otherwise, repository-directory will stay away from such directories, considered as "hidden". Note that this does not apply to the ".git" directory in non-bare repos. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} list snapshots Text which specifies the default set of snapshot formats that cgit generates links for. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} repository-directory repository-directory Name of the directory to scan for repositories (represents @code{scan-path}). Defaults to @samp{"/srv/git"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string section The name of the current repository section - all repositories defined after this option will inherit the current section name. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string section-sort Flag which, when set to @samp{1}, will sort the sections on the repository listing by name. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer section-from-path A number which, if defined prior to repository-directory, specifies how many path elements from each repo path to use as a default section name. Defaults to @samp{0}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} boolean side-by-side-diffs? If set to @samp{#t} shows side-by-side diffs instead of unidiffs per default. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} file-object source-filter Specifies a command which will be invoked to format plaintext blobs in the tree view. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer summary-branches Specifies the number of branches to display in the repository "summary" view. Defaults to @samp{10}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer summary-log Specifies the number of log entries to display in the repository "summary" view. Defaults to @samp{10}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} integer summary-tags Specifies the number of tags to display in the repository "summary" view. Defaults to @samp{10}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string strict-export Filename which, if specified, needs to be present within the repository for cgit to allow access to that repository. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} string virtual-root URL which, if specified, will be used as root for all cgit links. Defaults to @samp{"/"}. @end deftypevr @deftypevr {@code{cgit-configuration} parameter} repository-cgit-configuration-list repositories A list of @dfn{cgit-repo} records to use with config. Defaults to @samp{()}. Available @code{repository-cgit-configuration} fields are: @deftypevr {@code{repository-cgit-configuration} parameter} repo-list snapshots A mask of snapshot formats for this repo that cgit generates links for, restricted by the global @code{snapshots} setting. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object source-filter Override the default @code{source-filter}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string url The relative URL used to access the repository. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object about-filter Override the default @code{about-filter}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string branch-sort Flag which, when set to @samp{age}, enables date ordering in the branch ref list, and when set to @samp{name} enables ordering by branch name. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-list clone-url A list of URLs which can be used to clone repo. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object commit-filter Override the default @code{commit-filter}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string commit-sort Flag which, when set to @samp{date}, enables strict date ordering in the commit log, and when set to @samp{topo} enables strict topological ordering. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string defbranch The name of the default branch for this repository. If no such branch exists in the repository, the first branch name (when sorted) is used as default instead. By default branch pointed to by HEAD, or "master" if there is no suitable HEAD. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string desc The value to show as repository description. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string homepage The value to show as repository homepage. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object email-filter Override the default @code{email-filter}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-commit-graph? A flag which can be used to disable the global setting @code{enable-commit-graph?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-log-filecount? A flag which can be used to disable the global setting @code{enable-log-filecount?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-log-linecount? A flag which can be used to disable the global setting @code{enable-log-linecount?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-remote-branches? Flag which, when set to @code{#t}, will make cgit display remote branches in the summary and refs views. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-subject-links? A flag which can be used to override the global setting @code{enable-subject-links?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} maybe-repo-boolean enable-html-serving? A flag which can be used to override the global setting @code{enable-html-serving?}. Der Vorgabewert ist @samp{disabled} (d.h.@: deaktiviert). @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-boolean hide? Flag which, when set to @code{#t}, hides the repository from the repository index. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-boolean ignore? Flag which, when set to @samp{#t}, ignores the repository. Defaults to @samp{#f}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object logo URL which specifies the source of an image which will be used as a logo on this repo’s pages. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string logo-link URL loaded when clicking on the cgit logo image. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-file-object owner-filter Override the default @code{owner-filter}. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string module-link Text which will be used as the formatstring for a hyperlink when a submodule is printed in a directory listing. The arguments for the formatstring are the path and SHA1 of the submodule commit. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} module-link-path module-link-path Text which will be used as the formatstring for a hyperlink when a submodule with the specified subdirectory path is printed in a directory listing. Defaults to @samp{()}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string max-stats Override the default maximum statistics period. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string name The value to show as repository name. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string owner A value used to identify the owner of the repository. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string path An absolute path to the repository directory. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string readme A path (relative to repo) which specifies a file to include verbatim as the "About" page for this repo. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-string section The name of the current repository section - all repositories defined after this option will inherit the current section name. Defaults to @samp{""}. @end deftypevr @deftypevr {@code{repository-cgit-configuration} parameter} repo-list extra-options Extra options will be appended to cgitrc file. Defaults to @samp{()}. @end deftypevr @end deftypevr @deftypevr {@code{cgit-configuration} parameter} list extra-options Extra options will be appended to cgitrc file. Defaults to @samp{()}. @end deftypevr @c %end of fragment However, it could be that you just want to get a @code{cgitrc} up and running. In that case, you can pass an @code{opaque-cgit-configuration} as a record to @code{cgit-service-type}. As its name indicates, an opaque configuration does not have easy reflective capabilities. Available @code{opaque-cgit-configuration} fields are: @deftypevr {@code{opaque-cgit-configuration} parameter} package cgit The cgit package. @end deftypevr @deftypevr {@code{opaque-cgit-configuration} parameter} string string The contents of the @code{cgitrc}, as a string. @end deftypevr For example, if your @code{cgitrc} is just the empty string, you could instantiate a cgit service like this: @example (service cgit-service-type (opaque-cgit-configuration (cgitrc ""))) @end example @subsubheading Gitolite-Dienst @cindex Gitolite-Dienst @cindex Git, hosting @uref{http://gitolite.com/gitolite/, Gitolite} is a tool for hosting Git repositories on a central server. Gitolite can handle multiple repositories and users, and supports flexible configuration of the permissions for the users on the repositories. The following example will configure Gitolite using the default @code{git} user, and the provided SSH public key. @example (service gitolite-service-type (gitolite-configuration (admin-pubkey (plain-file "yourname.pub" "ssh-rsa AAAA... guix@@example.com")))) @end example Gitolite is configured through a special admin repository which you can clone, for example, if you setup Gitolite on @code{example.com}, you would run the following command to clone the admin repository. @example git clone git@@example.com:gitolite-admin @end example When the Gitolite service is activated, the provided @code{admin-pubkey} will be inserted in to the @file{keydir} directory in the gitolite-admin repository. If this results in a change in the repository, it will be committed using the message ``gitolite setup by GNU Guix''. @deftp {Datentyp} gitolite-configuration Repräsentiert die Konfiguration vom @code{gitolite-service-type}. @table @asis @item @code{package} (Vorgabe: @var{gitolite}) Welches Gitolite-Paket benutzt werden soll. @item @code{user} (Vorgabe: @var{git}) User to use for Gitolite. This will be user that you use when accessing Gitolite over SSH. @item @code{group} (Vorgabe: @var{git}) Group to use for Gitolite. @item @code{home-directory} (Vorgabe: @var{"/var/lib/gitolite"}) Directory in which to store the Gitolite configuration and repositories. @item @code{rc-file} (Vorgabe: @var{(gitolite-rc-file)}) A ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}), representing the configuration for Gitolite. @item @code{admin-pubkey} (Vorgabe: @var{#f}) A ``file-like'' object (@pxref{G-Ausdrücke, file-like objects}) used to setup Gitolite. This will be inserted in to the @file{keydir} directory within the gitolite-admin repository. To specify the SSH key as a string, use the @code{plain-file} function. @example (plain-file "yourname.pub" "ssh-rsa AAAA... guix@@example.com") @end example @end table @end deftp @deftp {Datentyp} gitolite-rc-file Repräsentiert die Gitolie-RC-Datei. @table @asis @item @code{umask} (Vorgabe: @code{#o0077}) This controls the permissions Gitolite sets on the repositories and their contents. A value like @code{#o0027} will give read access to the group used by Gitolite (by default: @code{git}). This is necessary when using Gitolite with software like cgit or gitweb. @item @code{git-config-keys} (Vorgabe: @code{""}) Gitolite allows you to set git config values using the "config" keyword. This setting allows control over the config keys to accept. @item @code{roles} (Vorgabe: @code{'(("READERS" . 1) ("WRITERS" . ))}) Set the role names allowed to be used by users running the perms command. @item @code{enable} (default: @code{'("help" "desc" "info" "perms" "writable" "ssh-authkeys" "git-config" "daemon" "gitweb")}) This setting controls the commands and features to enable within Gitolite. @end table @end deftp @node Spieldienste @subsection Spieldienste @subsubheading The Battle for Wesnoth Service @cindex wesnothd @uref{https://wesnoth.org, The Battle for Wesnoth} is a fantasy, turn based tactical strategy game, with several single player campaigns, and multiplayer games (both networked and local). @defvar {Scheme Variable} wesnothd-service-type Service type for the wesnothd service. Its value must be a @code{wesnothd-configuration} object. To run wesnothd in the default configuration, instantiate it as: @example (service wesnothd-service-type) @end example @end defvar @deftp {Data Type} wesnothd-configuration Data type representing the configuration of @command{wesnothd}. @table @asis @item @code{package} (default: @code{wesnoth-server}) The wesnoth server package to use. @item @code{port} (default: @code{15000}) The port to bind the server to. @end table @end deftp @node Verschiedene Dienste @subsection Verschiedene Dienste @cindex fingerprint @subsubheading Fingerabdrucklese-Dienst The @code{(gnu services authentication)} module provides a DBus service to read and identify fingerprints via a fingerprint sensor. @defvr {Scheme Variable} fprintd-service-type The service type for @command{fprintd}, which provides the fingerprint reading capability. @example (service fprintd-service-type) @end example @end defvr @cindex sysctl @subsubheading System Control Service The @code{(gnu services sysctl)} provides a service to configure kernel parameters at boot. @defvr {Scheme Variable} sysctl-service-type The service type for @command{sysctl}, which modifies kernel parameters under @file{/proc/sys/}. To enable IPv4 forwarding, it can be instantiated as: @example (service sysctl-service-type (sysctl-configuration (settings '(("net.ipv4.ip_forward" . "1"))))) @end example @end defvr @deftp {Data Type} sysctl-configuration The data type representing the configuration of @command{sysctl}. @table @asis @item @code{sysctl} (default: @code{(file-append procps "/sbin/sysctl"}) The @command{sysctl} executable to use. @item @code{settings} (default: @code{'()}) An association list specifies kernel parameters and their values. @end table @end deftp @cindex pcscd @subsubheading PC/SC Smart Card Daemon Service The @code{(gnu services security-token)} module provides the following service to run @command{pcscd}, the PC/SC Smart Card Daemon. @command{pcscd} is the daemon program for pcsc-lite and the MuscleCard framework. It is a resource manager that coordinates communications with smart card readers, smart cards and cryptographic tokens that are connected to the system. @defvr {Scheme Variable} pcscd-service-type Service type for the @command{pcscd} service. Its value must be a @code{pcscd-configuration} object. To run pcscd in the default configuration, instantiate it as: @example (service pcscd-service-type) @end example @end defvr @deftp {Datentyp} pcscd-configuration Repräsentiert die Konfiguration von @command{pcscd}. @table @asis @item @code{pcsc-lite} (Vorgabe: @code{pcsc-lite}) The pcsc-lite package that provides pcscd. @item @code{usb-drivers} (Vorgabe: @code{(list ccid)}) List of packages that provide USB drivers to pcscd. Drivers are expected to be under @file{pcsc/drivers} in the store directory of the package. @end table @end deftp @cindex lirc @subsubheading Lirc Service The @code{(gnu services lirc)} module provides the following service. @deffn {Scheme Procedure} lirc-service [#:lirc lirc] @ [#:device #f] [#:driver #f] [#:config-file #f] @ [#:extra-options '()] Return a service that runs @url{http://www.lirc.org,LIRC}, a daemon that decodes infrared signals from remote controls. Optionally, @var{device}, @var{driver} and @var{config-file} (configuration file name) may be specified. See @command{lircd} manual for details. Finally, @var{extra-options} is a list of additional command-line options passed to @command{lircd}. @end deffn @cindex spice @subsubheading Spice Service The @code{(gnu services spice)} module provides the following service. @deffn {Scheme Procedure} spice-vdagent-service [#:spice-vdagent] Returns a service that runs @url{http://www.spice-space.org,VDAGENT}, a daemon that enables sharing the clipboard with a vm and setting the guest display resolution when the graphical console window resizes. @end deffn @cindex inputattach @subsubheading inputattach-Dienst @cindex tablet input, for Xorg @cindex touchscreen input, for Xorg The @uref{https://linuxwacom.github.io/, inputattach} service allows you to use input devices such as Wacom tablets, touchscreens, or joysticks with the Xorg display server. @deffn {Scheme-Variable} inputattach-service-type Type of a service that runs @command{inputattach} on a device and dispatches events from it. @end deffn @deftp {Datentyp} inputattach-configuration @table @asis @item @code{device-type} (Vorgabe: @code{"wacom"}) The type of device to connect to. Run @command{inputattach --help}, from the @code{inputattach} package, to see the list of supported device types. @item @code{device} (Vorgabe: @code{"/dev/ttyS0"}) The device file to connect to the device. @item @code{log-file} (Vorgabe: @code{#f}) If true, this must be the name of a file to log messages to. @end table @end deftp @subsection Dictionary Services @cindex dictionary The @code{(gnu services dict)} module provides the following service: @deffn {Scheme Procedure} dicod-service [#:config (dicod-configuration)] Return a service that runs the @command{dicod} daemon, an implementation of DICT server (@pxref{Dicod,,, dico, GNU Dico Manual}). The optional @var{config} argument specifies the configuration for @command{dicod}, which should be a @code{} object, by default it serves the GNU Collaborative International Dictonary of English. You can add @command{open localhost} to your @file{~/.dico} file to make @code{localhost} the default server for @command{dico} client (@pxref{Initialization File,,, dico, GNU Dico Manual}). @end deffn @deftp {Data Type} dicod-configuration Data type representing the configuration of dicod. @table @asis @item @code{dico} (default: @var{dico}) Package object of the GNU Dico dictionary server. @item @code{interfaces} (default: @var{'("localhost")}) This is the list of IP addresses and ports and possibly socket file names to listen to (@pxref{Server Settings, @code{listen} directive,, dico, GNU Dico Manual}). @item @code{handlers} (default: @var{'()}) List of @code{} objects denoting handlers (module instances). @item @code{databases} (default: @var{(list %dicod-database:gcide)}) List of @code{} objects denoting dictionaries to be served. @end table @end deftp @deftp {Data Type} dicod-handler Data type representing a dictionary handler (module instance). @table @asis @item @code{name} Name of the handler (module instance). @item @code{module} (default: @var{#f}) Name of the dicod module of the handler (instance). If it is @code{#f}, the module has the same name as the handler. (@pxref{Module,,, dico, GNU Dico Manual}). @item @code{options} List of strings or gexps representing the arguments for the module handler @end table @end deftp @deftp {Data Type} dicod-database Data type representing a dictionary database. @table @asis @item @code{name} Name of the database, will be used in DICT commands. @item @code{handler} Name of the dicod handler (module instance) used by this database (@pxref{Handlers,,, dico, GNU Dico Manual}). @item @code{complex?} (default: @var{#f}) Whether the database configuration complex. The complex configuration will need a corresponding @code{} object, otherwise not. @item @code{options} List of strings or gexps representing the arguments for the database (@pxref{Databases,,, dico, GNU Dico Manual}). @end table @end deftp @defvr {Scheme Variable} %dicod-database:gcide A @code{} object serving the GNU Collaborative International Dictionary of English using the @code{gcide} package. @end defvr The following is an example @code{dicod-service} configuration. @example (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)))) @end example @cindex Docker @subsubheading Docker-Dienst Das Modul @code{(gnu services docker)} stellt den folgenden Dienst zur Verfügung. @defvr {Scheme-Variable} docker-service-type This is the type of the service that runs @url{http://www.docker.com,Docker}, a daemon that can execute application bundles (sometimes referred to as ``containers'') in isolated environments. @end defvr @deftp {Datentyp} docker-configuration Dies ist der Datentyp, der die Konfiguration von Docker und Containerd repräsentiert. @table @asis @item @code{package} (Vorgabe: @code{docker}) Das Docker-Paket, was benutzt werden soll. @item @code{containerd} (Vorgabe: @var{containerd}) Das Containerd-Paket, was benutzt werden soll. @end table @end deftp @node Setuid-Programme @section Setuid-Programme @cindex 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 @command{passwd}, womit Nutzer ihr Passwort ändern können, wozu das Programm auf die Dateien @file{/etc/passwd} und @file{/etc/shadow} zugreifen muss — was normalerweise nur der »root«-Nutzer darf, aus offensichtlichen Gründen der Informationssicherheit. Deswegen sind diese ausführbaren Programmdateien @dfn{setuid-root}, d.h.@: sie laufen immer mit den Administratorrechten des root-Nutzers, egal wer sie startet (siehe @ref{How Change Persona,,, libc, The GNU C Library Reference Manual} für mehr Informationen über den setuid-Mechanismus). Der Store selbst kann @emph{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 @ref{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 @emph{deklarieren}, welche Programme mit setuid-root gestartet werden. Das Feld @code{setuid-programs} einer @code{operating-system}-Deklaration enthält eine Liste von G-Ausdrücken, die die Namen der Programme angeben, die setuid-root sein sollen (siehe @ref{Das Konfigurationssystem nutzen}). Zum Beispiel kann das Programm @command{passwd}, was Teil des Shadow-Pakets ist, durch diesen G-Ausdruck bezeichnet werden (siehe @ref{G-Ausdrücke}): @example #~(string-append #$shadow "/bin/passwd") @end example Eine vorgegebene Menge von setuid-Programmen wird durch die Variable @code{%setuid-programs} aus dem Modul @code{(gnu system)} definiert. @defvr {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 @command{passwd}, @command{ping}, @command{su} und @command{sudo}. @end defvr Intern erzeugt Guix die eigentlichen setuid-Programme im Verzeichnis @file{/run/setuid-programs}, wenn das System aktiviert wird. Die Dateien in diesem Verzeichnis verweisen auf die »echten« Binärdateien im Store. @node X.509-Zertifikate @section X.509-Zertifikate @cindex HTTPS, Zertifikate @cindex X.509-Zertifikate @cindex TLS Über HTTPS verfügbare Webserver (also HTTP mit gesicherter Transportschicht, englisch »Transport-Layer Security«, kurz TLS) senden Client-Programmen ein @dfn{X.509-Zertifikat}, mit dem der Client den Server dann @emph{authentifizieren} kann. Dazu verifiziert der Client, dass das Zertifikat des Servers von einer sogenannten Zertifizierungsstelle signiert wurde (englisch @dfn{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@tie{}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 — @command{wget}, @command{git}, @command{w3m} etc.@: — muss allerdings erst mitgeteilt werden, wo die CA-Zertifikate installiert sind. @cindex @code{nss-certs} In Guix müssen Sie dazu ein Paket, das Zertifikate enthält, in das @code{packages}-Feld der @code{operating-system}-Deklaration des Betriebssystems hinzufügen (siehe @ref{»operating-system«-Referenz}). Guix liefert ein solches Paket mit, @code{nss-certs}, was als Teil von Mozillas »Network Security Services« angeboten wird. Beachten Sie, dass es @emph{nicht} zu den @var{%base-packages} gehört, Sie es also ausdrücklich hinzufügen müssen. Das Verzeichnis @file{/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 @code{SSL_CERT_DIR} und @code{SSL_CERT_FILE}, manche Anwendungen benutzen stattdessen aber ihre eigenen Umgebungsvariablen. Das Versionskontrollsystem Git liest den Ort zum Beispiel aus der Umgebungsvariablen @code{GIT_SSL_CAINFO} aus. Sie würden typischerweise also so etwas ausführen: @example $ guix package -i 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" @end example Ein weiteres Beispiel ist R, was voraussetzt, dass die Umgebungsvariable @code{CURL_CA_BUNDLE} auf ein Zertifikatsbündel verweist, weshalb Sie etwas wie hier ausführen müssten: @example $ guix package -i nss-certs $ export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" @end example Für andere Anwendungen möchten Sie die Namen der benötigten Umgebungsvariablen vielleicht in deren Dokumentation nachschlagen. @node Name Service Switch @section Name Service Switch @cindex Name Service Switch @cindex NSS Das Modul @code{(gnu system nss)} enthält Anbindungen für die Konfiguration des @dfn{Name Service Switch} (NSS) der libc (siehe @ref{NSS Configuration File,,, libc, The GNU C Library Reference Manual}). 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 @ref{Name Service Switch, System Databases and Name Service Switch,, libc, The GNU C Library Reference Manual}). 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 @code{name-service-switch} von @code{operating-system}-Deklarationen angegeben (siehe @ref{»operating-system«-Referenz, @code{name-service-switch}}). @cindex nss-mdns @cindex .local, Rechnernamensauflösung Zum Beispiel konfigurieren die folgenden Deklarationen den NSS so, dass er das @uref{http://0pointer.de/lennart/projects/nss-mdns/, @code{nss-mdns}-Backend} benutzt, wodurch er auf @code{.local} endende Rechnernamen über Multicast-DNS (mDNS) auflöst: @example (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"))))) @end example Keine Sorge: Die Variable @code{%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 @code{.local}-Rechner ist. Beachten Sie dabei, dass es zusätzlich zum Festlegen des @code{name-service-switch} in der @code{operating-system}-Deklaration auch erforderlich ist, den @code{avahi-service-type} zu benutzen (siehe @ref{Netzwerkdienste, @code{avahi-service-type}}). Es genügt auch, wenn Sie die @var{%desktop-services} benutzen, weil er darin enthalten ist (siehe @ref{Desktop-Dienste}). Dadurch wird @code{nss-mdns} für den Name Service Cache Daemon nutzbar (siehe @ref{Basisdienste, @code{nscd-service}}). Um sich eine lange Konfiguration zu ersparen, können Sie auch einfach die folgenden Variablen für typische NSS-Konfigurationen benutzen. @defvr {Scheme-Variable} %default-nss Die vorgegebene Konfiguration des Name Service Switch als ein @code{name-service-switch}-Objekt. @end defvr @defvr {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 @code{.local} endende Rechnernamen. @end defvr 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 @ref{NSS Configuration File,,, libc, The GNU C Library Reference Manual}). 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 @command{guix system} aufrufen. @deftp {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. @table @code @item aliases @itemx ethers @itemx group @itemx gshadow @itemx hosts @itemx initgroups @itemx netgroup @itemx networks @itemx password @itemx public-key @itemx rpc @itemx services @itemx shadow Das sind die Systemdatenbanken, um die sich NSS kümmern kann. Jedes dieser Felder muss eine Liste aus @code{}-Objekten sein (siehe unten). @end table @end deftp @deftp {Datentyp} name-service Der einen eigentlichen Namensdienst repräsentierende Datentyp zusammen mit der zugehörigen Auflösungsaktion. @table @code @item name Eine Zeichenkette, die den Namensdienst bezeichnet (siehe @ref{Services in the NSS configuration,,, libc, The GNU C Library Reference Manual}). Beachten Sie, dass hier aufgeführte Namensdienste für den nscd sichtbar sein müssen. Dazu übergeben Sie im Argument @code{#:name-services} des @code{nscd-service} die Liste der Pakete, die die entsprechenden Namensdienste anbieten (siehe @ref{Basisdienste, @code{nscd-service}}). @item reaction Eine mit Hilfe des Makros @code{lookup-specification} angegebene Aktion (siehe @ref{Actions in the NSS configuration,,, libc, The GNU C Library Reference Manual}). Zum Beispiel: @example (lookup-specification (unavailable => continue) (success => return)) @end example @end table @end deftp @node Initiale RAM-Disk @section Initiale RAM-Disk @cindex initrd @cindex initiale RAM-Disk Um ihn zu initialisieren (zu »bootstrappen«), wird für den Kernel Linux-Libre eine @dfn{initiale RAM-Disk} angegeben (kurz @dfn{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 @code{initrd-modules} einer @code{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 @code{initrd-modules} in dem meisten Fällen genügen. Wenn Sie aber zum Beispiel das Kernel-Modul @code{megaraid_sas} zusätzlich zu den vorgegebenen Modulen brauchen, um auf Ihr Wurzeldateisystem zugreifen zu können, würden Sie das so schreiben: @example (operating-system ;; @dots{} (initrd-modules (cons "megaraid_sas" %base-initrd-modules))) @end example @defvr {Scheme-Variable} %base-initrd-modules Der Vorgabewert für die Liste der Kernel-Module, die in der initrd enthalten sein sollen. @end defvr Wenn Sie noch systemnähere Anpassungen durchführen wollen, können Sie im Feld @code{initrd} einer @code{operating-system}-Deklaration angeben, was für eine Art von initrd Sie benutzen möchten. Das Modul @code{(gnu system linux-initrd)} enthält drei Arten, eine initrd zu erstellen: die abstrakte Prozedur @code{base-initrd} und die systemnahen Prozeduren @code{raw-initrd} und @code{expression->initrd}. Mit der Prozedur @code{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 @code{initrd}-Feld auf diese Art definieren: @example (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))) @end example Die Prozedur @code{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 @code{base-initrd} baut auf der Prozedur @code{raw-initrd} auf. Anders als @code{base-initrd} hat @code{raw-initrd} keinerlei Zusatzfunktionalitäten: Es wird kein Versuch unternommen, für die initrd notwendige Kernel-Module und Pakete automatisch hinzuzunehmen. @code{raw-initrd} kann zum Beispiel benutzt werden, wenn ein Nutzer eine eigene Konfiguration des Linux-Kernels verwendet und die Standard-Kernel-Module, die mit @code{base-initrd} hinzugenommen würden, nicht verfügbar sind. Die initiale RAM-Disk, wie sie von @code{base-initrd} oder @code{raw-initrd} erzeugt wird, richtet sich nach verschiedenen Optionen, die auf der Kernel-Befehlszeile übergeben werden (also über GRUBs @code{linux}-Befehl oder die @code{-append}-Befehlszeilenoption von QEMU). Erwähnt werden sollten: @table @code @item --load=@var{boot} Die initiale RAM-Disk eine Datei @var{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@tie{}Shepherd startet, das Initialisierungssystem (»init«-System) von Guix System. @item --root=@var{Wurzel} Das mit @var{Wurzel} bezeichnete Dateisystem als Wurzeldateisystem einbinden. @var{Wurzel} kann ein Geratename wie @code{/dev/sda1}, eine Dateisystembezeichnung (d.h.@: ein Dateisystem-»Label«) oder eine Dateisystem-UUID sein. @item --system=@var{System} @file{/run/booted-system} und @file{/run/current-system} auf das @var{System} zeigen lassen. @item modprobe.blacklist=@var{Module}@dots{} @cindex Kernel-Module, Sperrliste @cindex Sperrliste, von Kernel-Modulen Die initiale RAM-Disk sowie den Befehl @command{modprobe} (aus dem kmod-Paket) anweisen, das Laden der angegebenen @var{Module} zu verweigern. Als @var{Module} muss eine kommagetrennte Liste von Kernel-Modul-Namen angegeben werden — z.B.@: @code{usbkbd,9pnet}. @item --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 @dfn{boot-to-Guile}. Der Schemer in Ihnen wird das lieben. Siehe @ref{Using Guile Interactively,,, guile, GNU Guile Reference Manual} für mehr Informationen über die REPL von Guile. @end table Jetzt wo Sie wissen, was für Funktionalitäten eine durch @code{base-initrd} und @code{raw-initrd} erzeugte initiale RAM-Disk so haben kann, möchten Sie vielleicht auch wissen, wie man Sie benutzt und weiter anpasst: @cindex initrd @cindex initiale RAM-Disk @deffn {Scheme-Prozedur} raw-initrd @var{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. @var{Dateisysteme} bezeichnet eine Liste von durch die initrd einzubindenden Dateisystemen, unter Umständen zusätzlich zum auf der Kernel-Befehlszeile mit @code{--root} angegebenen Wurzeldateisystem. @var{linux-modules} ist eine Liste von Kernel-Modulen, die zur Boot-Zeit geladen werden sollen. @var{mapped-devices} ist eine Liste von Gerätezuordnungen, die hergestellt sein müssen, bevor die unter @var{file-systems} aufgeführten Dateisysteme eingebunden werden (siehe @ref{Zugeordnete Geräte}). @var{helper-packages} ist eine Liste von Paketen, die in die initrd kopiert werden. Darunter kann @code{e2fsck/static} oder andere Pakete aufgeführt werden, mit denen durch die initrd das Wurzeldateisystem auf Fehler hin geprüft werden kann. When true, @var{keyboard-layout} is a @code{} record denoting the desired console keyboard layout. This is done before @var{mapped-devices} are set up and before @var{file-systems} are mounted such that, should the user need to enter a passphrase or use the REPL, this happens using the intended keyboard layout. Wenn @var{qemu-networking?} wahr ist, wird eine Netzwerkverbindung mit den Standard-QEMU-Parametern hergestellt. Wenn @var{virtio?} wahr ist, werden zusätzliche Kernel-Module geladen, damit die initrd als ein QEMU-Gast paravirtualisierte Ein-/Ausgabetreiber benutzen kann. Wenn @var{volatile-root?} wahr ist, ist Schreiben auf das Wurzeldateisystem möglich, aber Änderungen daran bleiben nicht erhalten. @end deffn @deffn {Scheme-Prozedur} base-initrd @var{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 @var{linux}. Die @var{file-systems} sind eine Liste von durch die initrd einzubindenden Dateisystemen, unter Umständen zusätzlich zum Wurzeldateisystem, das auf der Kernel-Befehlszeile mit @code{--root} angegeben wurde. Die @var{mapped-devices} sind eine Liste von Gerätezuordnungen, die hergestellt sein müssen, bevor die @var{file-systems} eingebunden werden. When true, @var{keyboard-layout} is a @code{} record denoting the desired console keyboard layout. This is done before @var{mapped-devices} are set up and before @var{file-systems} are mounted such that, should the user need to enter a passphrase or use the REPL, this happens using the intended keyboard layout. @var{qemu-networking?} und @var{volatile-root?} verhalten sich wie bei @code{raw-initrd}. In die initrd werden automatisch alle Kernel-Module eingefügt, die für die unter @var{file-systems} angegebenen Dateisysteme und die angegebenen Optionen nötig sind. Zusätzliche Kernel-Module können unter den @var{linux-modules} aufgeführt werden. Diese werden zur initrd hinzugefügt und zur Boot-Zeit in der Reihenfolge geladen, in der sie angegeben wurden. @end deffn 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 @code{expression->initrd} erstellt eine solche initrd für ein an sie übergebenes Programm. @deffn {Scheme-Prozedur} expression->initrd @var{G-Ausdruck} @ [#:guile %guile-static-stripped] [#:name "guile-initrd"] Liefert eine Linux-initrd (d.h.@: ein gzip-komprimiertes cpio-Archiv) als dateiartiges Objekt, in dem @var{guile} enthalten ist, womit der @var{G-Ausdruck} nach dem Booten ausgewertet wird. Alle vom @var{G-Ausdruck} referenzierten Ableitungen werden automatisch in die initrd kopiert. @end deffn @node Bootloader-Konfiguration @section Bootloader-Konfiguration @cindex bootloader @cindex Bootloader Das Betriebssystem unterstützt mehrere Bootloader. Der gewünschte Bootloader wird mit der @code{bootloader-configuration}-Deklaration konfiguriert. Alle Felder dieser Struktur sind für alle Bootloader gleich außer dem einen Feld @code{bootloader}, das angibt, welcher Bootloader konfiguriert und installiert werden soll. Manche der Bootloader setzen nicht alle Felder einer @code{bootloader-configuration} um. Zum Beispiel ignoriert der extlinux-Bootloader das @code{theme}-Feld, weil er keine eigenen Themen unterstützt. @deftp {Datentyp} bootloader-configuration Der Typ der Deklaration einer Bootloader-Konfiguration. @table @asis @item @code{bootloader} @cindex EFI, Bootloader @cindex UEFI, Bootloader @cindex BIOS, Bootloader Der zu benutzende Bootloader als ein @code{bootloader}-Objekt. Zur Zeit werden @code{grub-bootloader}, @code{grub-efi-bootloader}, @code{extlinux-bootloader} und @code{u-boot-bootloader} unterstützt. @vindex grub-efi-bootloader @code{grub-efi-bootloader} macht es möglich, auf modernen Systemen mit @dfn{Unified Extensible Firmware Interface} (UEFI) zu booten. Sie sollten das hier benutzen, wenn im Installationsabbild ein Verzeichnis @file{/sys/firmware/efi} vorhanden ist, wenn Sie davon auf Ihrem System booten. @vindex grub-bootloader Mit @code{grub-bootloader} können Sie vor allem auf Intel-basierten Maschinen im alten »Legacy«-BIOS-Modus booten. @cindex ARM, Bootloader @cindex AArch64, Bootloader Verfügbare Bootloader werden in den Modulen @code{(gnu bootloader @dots{})} beschrieben. Insbesondere enthält @code{(gnu bootloader u-boot)} Definitionen für eine Vielzahl von ARM- und AArch64-Systemen, die den @uref{http://www.denx.de/wiki/U-Boot/, U-Boot-Bootloader} benutzen. @item @code{target} Eine Zeichenkette, die angibt, auf welches Ziel der Bootloader installiert werden soll. Was das bedeutet, hängt vom jeweiligen Bootloader ab. Für @code{grub-bootloader} sollte hier zum Beispiel ein Gerätename angegeben werden, der vom @command{installer}-Befehl des Bootloaders verstanden wird, etwa @code{/dev/sda} oder @code{(hd0)} (siehe @ref{Invoking grub-install,,, grub, GNU GRUB Manual}). Für @code{grub-efi-bootloader} sollte der Einhängepunkt des EFI-Dateisystems angegeben werden, in der Regel @file{/boot/efi}. @item @code{menu-entries} (Vorgabe: @code{()}) Eine möglicherweise leere Liste von @code{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. @item @code{default-entry} (Vorgabe: @code{0}) Die Position des standardmäßig ausgewählten Bootmenü-Eintrags. An Position 0 steht der Eintrag der aktuellen Systemgeneration. @item @code{timeout} (Vorgabe: @code{5}) Wieviele 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. @cindex Tastaturbelegung, beim Bootloader @item @code{keyboard-layout} (Vorgabe: @code{#f}) Wenn dies auf @code{#f} gesetzt ist, verwendet das Menü des Bootloaders (falls vorhanden) die Vorgabe-Tastaturbelegung, normalerweise US@tie{}English (»qwerty«). Andernfalls muss es ein @code{keyboard-layout}-Objekt sein (siehe @ref{Tastaturbelegung}). @quotation Anmerkung Dieses Feld wird derzeit von Bootloadern außer @code{grub} und @code{grub-efi} ignoriert. @end quotation @item @code{theme} (Vorgabe: @var{#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. @item @code{terminal-outputs} (Vorgabe: @code{'gfxterm}) Die Ausgabeterminals, die für das Boot-Menü des Bootloaders benutzt werden, als eine Liste von Symbolen. GRUB akzeptiert hier diese Werte: @code{console}, @code{serial}, @code{serial_@{0–3@}}, @code{gfxterm}, @code{vga_text}, @code{mda_text}, @code{morse} und @code{pkmodem}. Dieses Feld entspricht der GRUB-Variablen @code{GRUB_TERMINAL_OUTPUT} (siehe @ref{Simple configuration,,, grub,GNU GRUB manual}). @item @code{terminal-inputs} (Vorgabe: @code{'()}) 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: @code{console}, @code{serial}, @code{serial_@{0-3@}}, @code{at_keyboard} und @code{usb_keyboard}. Dieses Feld entspricht der GRUB-Variablen @code{GRUB_TERMINAL_INPUT} (siehe @ref{Simple configuration,,, grub,GNU GRUB manual}). @item @code{serial-unit} (Vorgabe: @code{#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 @ref{Serial terminal,,, grub,GNU GRUB manual}). @item @code{serial-speed} (Vorgabe: @code{#f}) Die Geschwindigkeit der seriellen Schnittstelle als eine ganze Zahl. GRUB bestimmt den Wert standardmäßig zur Laufzeit; derzeit wählt GRUB 9600@tie{}bps (siehe @ref{Serial terminal,,, grub,GNU GRUB manual}). @end table @end deftp @cindex Dual-Boot @cindex Bootmenü Sollten Sie zusätzliche Bootmenü-Einträge über das oben beschriebene @code{menu-entries}-Feld hinzufügen möchten, müssen Sie diese mit der @code{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: @example (menu-entry (label "Die _andere_ Distribution") (linux "/boot/old/vmlinux-2.6.32") (linux-arguments '("root=/dev/sda2")) (initrd "/boot/old/initrd")) @end example Details finden Sie unten. @deftp {Datentyp} menu-entry Der Typ eines Eintrags im Bootloadermenü. @table @asis @item @code{label} Die Beschriftung, die im Menü gezeigt werden soll — z.B.@: @code{"GNU"}. @item @code{linux} Das Linux-Kernel-Abbild, was gebootet werden soll, zum Beispiel: @example (file-append linux-libre "/bzImage") @end example Für GRUB kann hier auch ein Gerät ausdrücklich zum Dateipfad angegeben werden, unter Verwendung von GRUBs Konventionen zur Gerätebenennung (siehe @ref{Naming convention,,, grub, GNU GRUB manual}), zum Beispiel: @example "(hd0,msdos1)/boot/vmlinuz" @end example Wenn das Gerät auf diese Weise ausdrücklich angegeben wird, wird das @code{device}-Feld gänzlich ignoriert. @item @code{linux-arguments} (Vorgabe: @code{()}) Die Liste zusätzlicher Linux-Kernel-Befehlszeilenargumente — z.B.@: @code{("console=ttyS0")}. @item @code{initrd} Ein G-Ausdruck oder eine Zeichenkette, die den Dateinamen der initialen RAM-Disk angibt, die benutzt werden soll (siehe @ref{G-Ausdrücke}). @item @code{device} (Vorgabe: @code{#f}) Das Gerät, auf dem Kernel und initrd zu finden sind — d.h.@: bei GRUB die Wurzel (@dfn{root}) dieses Menüeintrags (siehe @ref{root,,, grub, GNU GRUB manual}). Dies kann eine Dateisystembezeichnung (als Zeichenkette), eine Dateisystem-UUID (als Bytevektor, siehe @ref{Dateisysteme}) oder @code{#f} sein, im letzten Fall wird der Bootloader auf dem Gerät suchen, das die vom @code{linux}-Feld benannte Datei enthält (siehe @ref{search,,, grub, GNU GRUB manual}). Ein vom Betriebssystem vergebener Gerätename wie @file{/dev/sda1} ist aber @emph{nicht} erlaubt. @end table @end deftp @c FIXME: Write documentation once it's stable. For now only GRUB has theme support. GRUB themes are created using the @code{grub-theme} form, which is not documented yet. @defvr {Scheme Variable} %default-theme Das vorgegebene GRUB-Thema, das vom Betriebssystem benutzt wird, wenn kein @code{theme}-Feld im @code{bootloader-configuration}-Verbundsobjekt angegeben wurde. Es wird von einem feschen Hintergrundbild begleitet, das die Logos von GNU und Guix zeigt. @end defvr @node Aufruf von guix system @section @code{guix system} aufrufen Sobald Sie eine Betriebssystemdeklaration geschrieben haben, wie wir sie in den vorangehenden Abschnitten gesehen haben, kann diese @dfn{instanziiert} werden, indem Sie den Befehl @command{guix system} aufrufen. Zusammengefasst: @example guix system @var{Optionen}@dots{} @var{Aktion} @var{Datei} @end example @var{Datei} muss der Name einer Datei sein, in der eine Betriebssystemdeklaration als @code{operating-system}-Objekt steht. @var{Aktion} gibt an, wie das Betriebssystem instanziiert wird. Derzeit werden folgende Werte dafür unterstützt: @table @code @item search Verfügbare Diensttypendefinitionen anzeigen, die zum angegebenen regulären Ausdruck passen, sortiert nach Relevanz: @example $ guix system search console font name: console-fonts location: gnu/services/base.scm:729: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 like: + + '(("tty1" . "LatGrkCyr-8x16")) relevance: 20 name: mingetty location: gnu/services/base.scm:1048:2 extends: shepherd-root description: Provide console login using the `mingetty' program. relevance: 2 name: login location: gnu/services/base.scm:775:2 extends: pam description: Provide a console log-in service as specified by its + configuration value, a `login-configuration' object. relevance: 2 @dots{} @end example Wie auch bei @command{guix package --search} wird das Ergebnis im @code{recutils}-Format geliefert, so dass es leicht ist, die Ausgabe zu filtern (siehe @ref{Top, GNU recutils databases,, recutils, GNU recutils manual}). @item reconfigure Das in der @var{Datei} beschriebene Betriebssystem erstellen, aktivieren und zu ihm wechseln@footnote{Diese Aktion (und die dazu ähnlichen Aktionen @code{switch-generation} und @code{roll-back}) sind nur auf Systemen nutzbar, auf denen »Guix System« bereits läuft.}. Dieser Befehl setzt die in der @var{Datei} festgelegte Konfiguration vollständig um: Benutzerkonten, Systemdienste, die Liste globaler Pakete, setuid-Programme und so weiter. Der Befehl startet die in der @var{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 @code{herd stop X} oder @code{herd restart X}). Dieser Befehl erzeugt eine neue Generation, deren Nummer (wie @command{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 @command{guix package} (siehe @ref{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 @option{--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. @quotation Anmerkung @c The paragraph below refers to the problem discussed at @c . Es ist sehr zu empfehlen, @command{guix pull} einmal auszuführen, bevor Sie @command{guix system reconfigure} zum ersten Mal aufrufen (siehe @ref{Aufruf von guix pull}). Wenn Sie das nicht tun, könnten Sie nach dem Abschluss von @command{reconfigure} eine ältere Version von Guix vorfinden, als Sie vorher hatten. @end quotation @item switch-generation @cindex Generationen 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 @emph{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: @example guix system switch-generation 7 @end example Die Zielgeneration kann auch relativ zur aktuellen Generation angegeben werden, in der Form @code{+N} oder @code{-N}, wobei @code{+3} zum Beispiel »3 Generationen weiter als die aktuelle Generation« bedeuten würde und @code{-1} »1 Generation vor der aktuellen Generation« hieße. Wenn Sie einen negativen Wert wie @code{-1} angeben, müssen Sie @code{--} der Befehlszeilenoption voranstellen, damit die negative Zahl nicht selbst als Befehlszeilenoption aufgefasst wird. Zum Beispiel: @example guix system switch-generation -- -1 @end example Zur Zeit bewirkt ein Aufruf dieser Aktion @emph{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 @command{reconfigure}, also etwa Dienste aktivieren und deaktivieren. Diese Aktion schlägt fehl, wenn die angegebene Generation nicht existiert. @item roll-back @cindex rücksetzen Zur vorhergehenden Systemgeneration wechseln. Wenn das System das nächste Mal hochgefahren wird, wird es die vorhergehende Systemgeneration benutzen. Dies ist die Umkehrung von @command{reconfigure} und tut genau dasselbe, wie @command{switch-generation} mit dem Argument @code{-1} aufzurufen. Wie auch bei @command{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. @item delete-generations @cindex Löschen von Systemgenerationen @cindex Platz sparen Systemgenerationen löschen, wodurch diese zu Kandidaten für den Müllsammler werden (siehe @ref{Aufruf von guix gc} für Informationen, wie Sie den »Müllsammler« laufen lassen). Es funktioniert auf die gleiche Weise wie @command{guix package --delete-generations} (siehe @ref{Aufruf von guix package, @code{--delete-generations}}). Wenn keine Argumente angegeben werden, werden alle Systemgenerationen außer der aktuellen gelöscht: @example guix system delete-generations @end example 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: @example guix system delete-generations 2m @end example 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. @item 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. @item init In das angegebene Verzeichnis alle Dateien einfügen, um das in der @var{Datei} angegebene Betriebssystem starten zu können. Dies ist nützlich bei erstmaligen Installationen von »Guix System«. Zum Beispiel: @example guix system init my-os-config.scm /mnt @end example Hiermit werden alle Store-Objekte nach @file{/mnt} kopiert, die von der in @file{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 @file{/etc}, @file{/var} und @file{/run} und die Datei @file{/bin/sh}. Dieser Befehl installiert auch den Bootloader auf dem in @file{my-os-config} angegebenen Ziel, außer die Befehlszeilenoption @option{--no-bootloader} wurde übergeben. @item vm @cindex virtuelle Maschine @cindex VM @anchor{guix system vm} Eine virtuelle Maschine (VM) erstellen, die das in der @var{Datei} deklarierte Betriebssystem enthält, und ein Skript liefern, das diese virtuelle Maschine startet. @quotation Anmerkung Die Aktion @code{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 @file{/dev/kvm} muss dann existieren und dem Benutzer und den Erstellungsbenutzern des Daemons müssen Berechtigungen zum Lesen und Schreiben darauf gegeben werden (siehe @ref{Einrichten der Erstellungsumgebung}). @end quotation 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@tie{}GiB an RAM für die emulierte Maschine angefragt: @example $ /gnu/store/@dots{}-run-vm.sh -m 1024 -net user @end example Die virtuelle Maschine verwendet denselben Store wie das Wirtssystem. Mit den Befehlszeilenoptionen @code{--share} und @code{--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 @file{/austausch} aber mit Lese- und Schreibzugriff dem Verzeichnis @file{$HOME/tmp} auf dem Wirtssystem zugeordnet wurde: @example guix system vm my-config.scm \ --expose=$HOME --share=$HOME/tmp=/austausch @end example 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 @code{--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 @code{--image-size} kann die Größe des Disk-Images angegeben werden. @cindex System-Disk-Images, Erstellung in verschiedenen Formaten @cindex Erzeugen von System-Disk-Images in verschiedenen Formaten @item vm-image @itemx disk-image @itemx 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 @var{Datei} deklarierte Betriebssystem liefern. Das vorgegebene Verhalten von @command{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 @option{--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 @option{--image-size} im Fall von @code{docker-image} ignoriert. Sie können den Dateisystemtyp für das Wurzeldateisystem mit der Befehlszeilenoption @option{--file-system-type} festlegen. Vorgegeben ist, @code{ext4} zu verwenden. Wenn Sie ein @code{vm-image} anfordern, ist das gelieferte Disk-Image im qcow2-Format, was vom QEMU-Emulator effizient benutzt werden kann. Im Abschnitt @ref{Guix in einer VM starten} finden Sie mehr Informationen, wie Sie das Disk-Image in einer virtuellen Maschine laufen lassen. Wenn Sie ein @code{disk-image} anfordern, wird ein rohes Disk-Image hergestellt; es kann zum Beispiel auf einen USB-Stick kopiert werden. Angenommen @code{/dev/sdc} ist das dem USB-Stick entsprechende Gerät, dann kann das Disk-Image mit dem folgenden Befehls darauf kopiert werden: @example # dd if=$(guix system disk-image my-os.scm) of=/dev/sdc @end example Wenn Sie ein @code{docker-image} anfordern, wird ein Abbild für Docker hergestellt. Guix erstellt das Abbild von Grund auf und @emph{nicht} aus einem vorerstellten Docker-Basisabbild heraus, daher enthält es @emph{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: @example image_id="$(docker load < guix-system-docker-image.tar.gz)" docker run -e GUIX_NEW_SYSTEM=/var/guix/profiles/system \\ --entrypoint /var/guix/profiles/system/profile/bin/guile \\ $image_id /var/guix/profiles/system/boot @end example 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. 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 @code{docker run} die Befehlszeilenoption @option{--privileged} übergeben. @item container Liefert ein Skript, um das in der @var{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. Zur Zeit 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 @code{vm} (siehe @ref{guix system vm}) können zusätzlich weitere Dateisysteme zwischen Wirt und Container geteilt werden, indem man die Befehlszeilenoptionen @option{--share} und @option{--expose} verwendet: @example guix system container my-config.scm \ --expose=$HOME --share=$HOME/tmp=/austausch @end example @quotation Anmerkung Diese Befehlszeilenoption funktioniert nur mit Linux-libre 3.19 oder neuer. @end quotation @end table Unter den @var{Optionen} können beliebige gemeinsame Erstellungsoptionen aufgeführt werden (siehe @ref{Gemeinsame Erstellungsoptionen}). Des Weiteren kann als @var{Optionen} Folgendes angegeben werden: @table @option @item --expression=@var{Ausdruck} @itemx -e @var{Ausdruck} Als Konfiguration des Betriebssystems das »operating-system« betrachten, zu dem der @var{Ausdruck} ausgewertet wird. Dies ist eine Alternative dazu, die Konfiguration in einer Datei festzulegen. Hiermit wird auch das Installationsabbild des Guix-Systems erstellt, siehe @ref{Ein Abbild zur Installation erstellen}). @item --system=@var{System} @itemx -s @var{System} Versuche, für das angegebene @var{System} statt für denselben Systemtyp wie auf dem Wirtssystem zu erstellen. Dies funktioniert wie bei @command{guix build} (siehe @ref{Aufruf von guix build}). @item --derivation @itemx -d Liefert den Namen der Ableitungsdatei für das angegebene Betriebssystem, ohne dazu etwas zu erstellen. @item --file-system-type=@var{Typ} @itemx -t @var{Typ} Für die Aktion @code{disk-image} wird hiermit ein Dateisystem des angegebenen @var{Typ}s im Abbild bzw. Disk-Image erzeugt. Wird diese Befehlszeilenoption nicht angegeben, so benutzt @command{guix system} als Dateisystemtyp @code{ext4}. @cindex ISO-9660-Format @cindex CD-Abbild-Format @cindex DVD-Abbild-Format @code{--file-system-type=iso9660} erzeugt ein Abbild im Format ISO-9660, was für das Brennen auf CDs und DVDs geeignet ist. @item --image-size=@var{Größe} Für die Aktionen @code{vm-image} und @code{disk-image} wird hiermit festgelegt, dass ein Abbild der angegebenen @var{Größe} erstellt werden soll. Die @var{Größe} kann als Zahl die Anzahl Bytes angeben oder mit einer Einheit als Suffix versehen werden (siehe @ref{Block size, size specifications,, coreutils, GNU Coreutils}). Wird keine solche Befehlszeilenoption angegeben, berechnet @command{guix system} eine Schätzung der Abbildgröße anhand der Größe des in der @var{Datei} deklarierten Systems. @item --root=@var{Datei} @itemx -r @var{Datei} Die @var{Datei} zu einer symbolischen Verknüpfung auf das Ergebnis machen und als Müllsammlerwurzel registrieren. @item --skip-checks Die Konfiguration @emph{nicht} vor der Installation zur Sicherheit auf Fehler prüfen. Das vorgegebene Verhalten von @command{guix system init} und @command{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 @code{operating-system}-Deklaration erwähnten Dateisysteme tatsächlich existieren (siehe @ref{Dateisysteme}) und dass alle Linux-Kernelmodule, die beim Booten benötigt werden könnten, auch im @code{initrd-modules}-Feld aufgeführt sind (siehe @ref{Initiale RAM-Disk}). Mit dieser Befehlszeilenoption werden diese Tests allesamt übersprungen. @cindex on-error @cindex on-error-Strategie @cindex Fehlerstrategie @item --on-error=@var{Strategie} Beim Auftreten eines Fehlers beim Einlesen der @var{Datei} die angegebene @var{Strategie} verfolgen. Als @var{Strategie} dient eine der Folgenden: @table @code @item nothing-special Nichts besonderes; der Fehler wird kurz gemeldet und der Vorgang abgebrochen. Dies ist die vorgegebene Strategie. @item backtrace Ebenso, aber zusätzlich wird eine Rückverfolgung des Fehlers (ein »Backtrace«) angezeigt. @item 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 @code{,bt} eine Rückverfolgung (»Backtrace«) anzeigen lassen und mit @code{,locals} die Werte lokaler Variabler anzeigen lassen. Im Allgemeinen können Sie mit Befehlen den Zustand des Programms inspizieren. Siehe @ref{Debug Commands,,, guile, GNU Guile Reference Manual} für eine Liste verfügbarer Befehle zur Fehlersuche. @end table @end table 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: @table @code @item list-generations Eine für Menschen verständliche Zusammenfassung jeder auf der Platte verfügbaren Generation des Betriebssystems ausgeben. Dies ähnelt der Befehlszeilenoption @option{--list-generations} von @command{guix package} (siehe @ref{Aufruf von guix package}). Optional kann ein Muster angegeben werden, was dieselbe Syntax wie @command{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: @example $ guix system list-generations 10d @end example @end table Der Befehl @command{guix system} hat sogar noch mehr zu bieten! Mit folgenden Unterbefehlen wird Ihnen visualisiert, wie Ihre Systemdienste voneinander abhängen: @anchor{system-extension-graph} @table @code @item extension-graph Im Dot-/Graphviz-Format auf die Standardausgabe den @dfn{Diensterweiterungsgraphen} des in der @var{Datei} definierten Betriebssystems ausgeben (siehe @ref{Dienstkompositionen} für mehr Informationen zu Diensterweiterungen). Der Befehl: @example $ guix system extension-graph @var{file} | dot -Tpdf > services.pdf @end example erzeugt eine PDF-Datei, in der die Erweiterungsrelation unter Diensten angezeigt wird. @anchor{system-shepherd-graph} @item shepherd-graph Im Dot-/Graphviz-Format auf die Standardausgabe den @dfn{Abhängigkeitsgraphen} der Shepherd-Dienste des in der @var{Datei} definierten Betriebssystems ausgeben. Siehe @ref{Shepherd-Dienste} für mehr Informationen sowie einen Beispielgraphen. @end table @node Guix in einer VM starten @section Guix in einer virtuellen Maschine betreiben @cindex virtuelle Maschine Um Guix in einer virtuellen Maschine (VM) auszuführen, können Sie entweder das vorerstellte Guix-VM-Abbild benutzen, das auf @indicateurl{https://alpha.gnu.org/gnu/guix/guix-system-vm-image-@value{VERSION}.@var{System}.xz} angeboten wird, oder Ihr eigenes Abbild erstellen, indem Sie @command{guix system vm-image} benutzen (siehe @ref{Aufruf von guix system}). Das Abbild wird im qcow2-Format zurückgeliefert, das der @uref{http://qemu.org/, QEMU-Emulator} effizient benutzen kann. @cindex QEMU Wenn Sie Ihr eigenes Abbild erstellen haben lassen, müssen Sie es aus dem Store herauskopieren (siehe @ref{Der Store}) und sich darauf Schreibberechtigung geben, um die Kopie benutzen zu können. Wenn Sie QEMU aufrufen, müssen Sie einen Systememulator angeben, der für Ihre Hardware-Plattform passend ist. Hier ist ein minimaler QEMU-Aufruf, der das Ergebnis von @command{guix system vm-image} auf x86_64-Hardware bootet: @example $ qemu-system-x86_64 \ -net user -net nic,model=virtio \ -enable-kvm -m 256 /tmp/qemu-image @end example Die Bedeutung jeder dieser Befehlszeilenoptionen ist folgende: @table @code @item qemu-system-x86_64 Hiermit wird die zu emulierende Hardware-Plattform angegeben. Sie sollte zum Wirtsrechner passen. @item -net user Den als Nutzer ausgeführten Netzwerkstapel (»User-Mode Network Stack«) ohne besondere Berechtigungen benutzen. Mit dieser Art von Netzwerkanbindung kann das Gast-Betriebssystem eine Verbindung zum Wirt aufbauen, aber nicht andersherum. Es ist die einfachste Art, das Gast-Betriebssystem mit dem Internet zu verbinden. @item -net nic,model=virtio Sie müssen ein Modell einer zu emulierenden Netzwerkschnittstelle angeben. Wenn Sie keine Netzwerkkarte (englisch »Network Interface Card«, kurz NIC) erzeugen lassen, wird das Booten fehlschlagen. Falls Ihre Hardware-Plattform x86_64 ist, können Sie eine Liste verfügbarer NIC-Modelle einsehen, indem Sie @command{qemu-system-x86_64 -net nic,model=help} ausführen. @item -enable-kvm Wenn Ihr System über Erweiterungen zur Hardware-Virtualisierung verfügt, beschleunigt es die Dinge, wenn Sie die Virtualisierungsunterstützung »KVM« des Linux-Kernels benutzen lassen. @item -m 256 Die Menge an Arbeitsspeicher (RAM), die dem Gastbetriebssystem zur Verfügung stehen soll, in Mebibytes. Vorgegeben wären 128@tie{}MiB, was für einige Operationen zu wenig sein könnte. @item /tmp/qemu-image Der Dateiname des qcow2-Abbilds. @end table Das voreingestellte @command{run-vm.sh}-Skript, das durch einen Aufruf von @command{guix system vm} erzeugt wird, fügt keine Befehlszeilenoption @command{-net user} an. Um innerhalb der virtuellen Maschine Netzwerkzugang zu haben, fügen Sie den @code{(dhcp-client-service)} zu Ihrer Systemdefinition hinzu und starten Sie die VM mit @command{`guix system vm config.scm` -net user}. Erwähnt werden sollte der Nachteil, dass bei Verwendung von @command{-net user} zur Netzanbindung der @command{ping}-Befehl @emph{nicht} funktionieren wird, weil dieser das ICMP-Protokoll braucht. Sie werden also einen anderen Befehl benutzen müssen, um auszuprobieren, ob Sie mit dem Netzwerk verbunden sind, zum Beispiel @command{guix download}. @subsection Verbinden über SSH @cindex SSH @cindex SSH server Um SSH in der virtuellen Maschine zu aktivieren, müssen Sie einen SSH-Server wie den @code{(dropbear-service)} oder den @code{(lsh-service)} zu ihr hinzufügen. Der @code{(lsh-service}) kann derzeit nicht ohne Benutzerinteraktion starten, weil der Benutzer erst ein paar Zeichen eintippen muss, um den Zufallsgenerator zu initialisieren. Des Weiteren müssen Sie den SSH-Port für das Wirtssystem freigeben (standardmäßig hat er die Portnummer 22). Das geht zum Beispiel so: @example `guix system vm config.scm` -net user,hostfwd=tcp::10022-:22 @end example Um sich mit der virtuellen Maschine zu verbinden, benutzen Sie diesen Befehl: @example ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 @end example Mit @command{-p} wird @command{ssh} der Port mitgeteilt, über den eine Verbindung hergestellt werden soll. @command{-o UserKnownHostsFile=/dev/null} verhindert, dass @command{ssh} sich bei jeder Modifikation Ihrer @command{config.scm}-Datei beschwert, ein anderer bekannter Rechner sei erwartet worden, und @command{-o StrictHostKeyChecking=no} verhindert, dass Sie die Verbindung zu unbekannten Rechnern jedes Mal bestätigen müssen, wenn Sie sich verbinden. @subsection @command{virt-viewer} mit Spice benutzen Eine Alternative zur grafischen Schnittstelle des standardmäßigen @command{qemu} ist, sich mit Hilfe des @command{remote-viewer} aus dem Paket @command{virt-viewer} zu verbinden. Um eine Verbindung herzustellen, übergeben Sie die Befehlszeilenoption @command{-spice port=5930,disable-ticketing} an @command{qemu}. Siehe den vorherigen Abschnitt für weitere Informationen, wie Sie das übergeben. Spice macht es auch möglich, ein paar nette Hilfestellungen zu benutzen, zum Beispiel können Sie Ihren Zwischenspeicher zum Kopieren und Einfügen (Ihr »Clipboard«) mit Ihrer virtuellen Maschine teilen. Um das zu aktivieren, werden Sie die folgenden Befehlszeilennoptionen zusätzlich an @command{qemu} übergeben müssen: @example -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent, name=com.redhat.spice.0 @end example Sie werden auch den @ref{Verschiedene Dienste, Spice-Dienst} hinzufügen müssen. @node Dienste definieren @section Dienste definieren Der vorhergehende Abschnitt präsentiert die verfügbaren Dienste und wie man sie in einer @code{operating-system}-Deklaration kombiniert. Aber wie definieren wir solche Dienste eigentlich? Und was ist überhaupt ein Dienst? @menu * Dienstkompositionen:: Wie Dienste zusammengestellt werden. * Diensttypen und Dienste:: Typen und Dienste. * Service-Referenz:: Referenz zur Programmierschnittstelle. * Shepherd-Dienste:: Eine spezielle Art von Dienst. @end menu @node Dienstkompositionen @subsection Dienstkompositionen @cindex services @cindex Daemons Wir definieren hier einen @dfn{Dienst} (englisch »Service«) als, grob gesagt, etwas, das die Funktionalität des Betriebssystems erweitert. Oft ist ein Dienst ein Prozess — ein sogenannter @dfn{Daemon} —, der beim Hochfahren des Systems gestartet wird: ein Secure-Shell-Server, ein Web-Server, der Guix-Erstellungsdaemon usw. Manchmal ist ein Dienst ein Daemon, dessen Ausführung von einem anderen Daemon ausgelöst wird — zum Beispiel wird ein FTP-Server von @command{inetd} gestartet oder ein D-Bus-Dienst durch @command{dbus-daemon} aktiviert. Manchmal entspricht ein Dienst aber auch keinem Daemon. Zum Beispiel nimmt sich der Benutzerkonten-Dienst (»account service«) die Benutzerkonten und sorgt dafür, dass sie existieren, wenn das System läuft. Der »udev«-Dienst sammelt die Regeln zur Geräteverwaltung an und macht diese für den eudev-Daemon verfügbar. Der @file{/etc}-Dienst fügt Dateien in das Verzeichnis @file{/etc} des Systems ein. @cindex Diensterweiterungen Dienste des Guix-Systems werden durch @dfn{Erweiterungen} (»Extensions«) miteinander verbunden. Zum Beispiel @emph{erweitert} der Secure-Shell-Dienst den Shepherd — Shepherd ist das Initialisierungssystem (auch »init«-System genannt), was als PID@tie{}1 läuft —, indem es ihm die Befehlszeilen zum Starten und Stoppen des Secure-Shell-Daemons übergibt (siehe @ref{Netzwerkdienste, @code{openssh-service-type}}). Der UPower-Dienst erweitert den D-Bus-Dienst, indem es ihm seine @file{.service}-Spezifikation übergibt, und erweitert den udev-Dienst, indem es ihm Geräteverwaltungsregeln übergibt (siehe @ref{Desktop-Dienste, @code{upower-service}}). Der Guix-Daemon-Dienst erweitert den Shepherd, indem er ihm die Befehlszeilen zum Starten und Stoppen des Daemons übergibt, und er erweitert den Benutzerkontendienst (»account service«), indem er ihm eine Liste der benötigten Erstellungsbenutzerkonten übergibt (siehe @ref{Basisdienste}). Alles in allem bilden Dienste und ihre »Erweitert«-Relationen einen gerichteten azyklischen Graphen (englisch »Directed Acyclic Graph«, kurz DAG). Wenn wir Dienste als Kästen und Erweiterungen als Pfeile darstellen, könnte ein typisches System so etwas hier anbieten: @image{images/service-graph,,5in,Typischer Diensterweiterungsgraph} @cindex Systemdienst Ganz unten sehen wir den @dfn{Systemdienst}, der das Verzeichnis erzeugt, in dem alles zum Ausführen und Hochfahren enthalten ist, so wie es der Befehl @command{guix system build} liefert. Siehe @ref{Service-Referenz}, um mehr über die anderen hier gezeigten Diensttypen zu erfahren. Beim @ref{system-extension-graph, Befehl @command{guix system extension-graph}} finden Sie Informationen darüber, wie Sie diese Darstellung für eine Betriebssystemdefinition Ihrer Wahl generieren lassen. @cindex Diensttypen Technisch funktioniert es so, dass Entwickler @dfn{Diensttypen} definieren können, um diese Beziehungen auszudrücken. Im System kann es beliebig viele Dienste zu jedem Typ geben — zum Beispiel können auf einem System zwei Instanzen des GNU-Secure-Shell-Servers (lsh) laufen, mit zwei Instanzen des Diensttyps @code{lsh-service-type} mit je unterschiedlichen Parametern. Der folgende Abschnitt beschreibt die Programmierschnittstelle für Diensttypen und Dienste. @node Diensttypen und Dienste @subsection Diensttypen und Dienste Ein @dfn{Diensttyp} (»service type«) ist ein Knoten im oben beschriebenen ungerichteten azyklischen Graphen (DAG). Fangen wir an mit einem einfachen Beispiel: dem Diensttyp für den Guix-Erstellungsdaemon (siehe @ref{Aufruf des guix-daemon}): @example (define guix-service-type (service-type (name 'guix) (extensions (list (service-extension shepherd-root-service-type guix-shepherd-service) (service-extension account-service-type guix-accounts) (service-extension activation-service-type guix-activation))) (default-value (guix-configuration)))) @end example @noindent Damit sind drei Dinge definiert: @enumerate @item Ein Name, der nur dazu da ist, dass man leichter die Abläufe verstehen und Fehler suchen kann. @item Eine Liste von @dfn{Diensterweiterungen} (»service extensions«). Jede Erweiterung gibt den Ziel-Diensttyp an sowie eine Prozedur, die für gegebene Parameter für den Dienst eine Liste von Objekten zurückliefert, um den Dienst dieses Typs zu erweitern. Jeder Diensttyp benutzt mindestens eine Diensterweiterung. Die einzige Ausnahme ist der @dfn{boot service type}, der die Grundlage aller Dienste ist. @item Optional kann ein Vorgabewert für Instanzen dieses Typs angegeben werden. @end enumerate In this example, @code{guix-service-type} extends three services: @table @code @item shepherd-root-service-type The @code{guix-shepherd-service} procedure defines how the Shepherd service is extended. Namely, it returns a @code{} object that defines how @command{guix-daemon} is started and stopped (@pxref{Shepherd-Dienste}). @item account-service-type This extension for this service is computed by @code{guix-accounts}, which returns a list of @code{user-group} and @code{user-account} objects representing the build user accounts (@pxref{Aufruf des guix-daemon}). @item activation-service-type Here @code{guix-activation} is a procedure that returns a gexp, which is a code snippet to run at ``activation time''---e.g., when the service is booted. @end table Ein Dienst dieses Typs wird dann so instanziiert: @example (service guix-service-type (guix-configuration (build-accounts 5) (use-substitutes? #f))) @end example Das zweite Argument an die @code{service}-Form ist ein Wert, der die Parameter dieser bestimmten Dienstinstanz repräsentiert. Siehe @ref{guix-configuration-type, @code{guix-configuration}} für Informationen über den @code{guix-configuration}-Datentyp. Wird kein Wert angegeben, wird die Vorgabe verwendet, die im @code{guix-service-type} angegeben wurde: @example (service guix-service-type) @end example @code{guix-service-type} is quite simple because it extends other services but is not extensible itself. @c @subsubsubsection Extensible Service Types Der Diensttyp eines @emph{erweiterbaren} Dienstes sieht ungefähr so aus: @example (define udev-service-type (service-type (name 'udev) (extensions (list (service-extension shepherd-root-service-type udev-shepherd-service))) (compose concatenate) ;Liste der Regeln zusammenfügen (extend (lambda (config rules) ;Konfiguration und Regeln (match config (($ udev initial-rules) (udev-configuration (udev udev) ;zu benutzendes udev-Paket (rules (append initial-rules rules))))))))) @end example This is the service type for the @uref{https://wiki.gentoo.org/wiki/Project:Eudev, eudev device management daemon}. Compared to the previous example, in addition to an extension of @code{shepherd-root-service-type}, we see two new fields: @table @code @item compose Die Prozedur, um die Liste der jeweiligen Erweiterungen für den Dienst dieses Typs zu einem Objekt zusammenzustellen (zu »komponieren«, englisch @dfn{compose}). Dienste können den udev-Dienst erweitern, indem sie eine Liste von Regeln (»Rules«) an ihn übergeben; wir komponieren mehrere solche Erweiterungen, indem wir die Listen einfach zusammenfügen. @item extend Diese Prozedur definiert, wie der Wert des Dienstes um die Komposition mit Erweiterungen erweitert (»extended«) werden kann. Udev-Erweiterungen werden zu einer einzigen Liste von Regeln komponiert, aber der Wert des udev-Dienstes ist ein @code{}-Verbundsobjekt. Deshalb erweitern wir diesen Verbund, indem wir die Liste der von Erweiterungen beigetragenen Regeln an die im Verbund gespeicherte Liste der Regeln anhängen. @item description Diese Zeichenkette gibt einen Überblick über den Systemtyp. Die Zeichenkette darf mit Texinfo ausgezeichnet werden (siehe @ref{Overview,,, texinfo, GNU Texinfo}). Der Befehl @command{guix system search} durchsucht diese Zeichenketten und zeigt sie an (siehe @ref{Aufruf von guix system}). @end table There can be only one instance of an extensible service type such as @code{udev-service-type}. If there were more, the @code{service-extension} specifications would be ambiguous. Sind Sie noch da? Der nächste Abschnitt gibt Ihnen eine Referenz der Programmierschnittstelle für Dienste. @node Service-Referenz @subsection Service-Referenz Wir haben bereits einen Überblick über Diensttypen gesehen (siehe @ref{Diensttypen und Dienste}). Dieser Abschnitt hier stellt eine Referenz dar, wie Dienste und Diensttypen manipuliert werden können. Diese Schnittstelle wird vom Modul @code{(gnu services)} angeboten. @deffn {Scheme-Prozedur} service @var{Typ} [@var{Wert}] Liefert einen neuen Dienst des angegebenen @var{Typ}s. Der @var{Typ} muss als @code{}-Objekt angegeben werden (siehe unten). Als @var{Wert} kann ein beliebiges Objekt angegeben werden, das die Parameter dieser bestimmten Instanz dieses Dienstes repräsentiert. Wenn kein @var{Wert} angegeben wird, wird der vom @var{Typ} festgelegte Vorgabewert verwendet; verfügt der @var{Typ} über keinen Vorgabewert, dann wird ein Fehler gemeldet. Zum Beispiel bewirken Sie hiermit: @example (service openssh-service-type) @end example @noindent dasselbe wie mit: @example (service openssh-service-type (openssh-configuration)) @end example In beiden Fällen ist das Ergebnis eine Instanz von @code{openssh-service-type} mit der vorgegebenen Konfiguration. @end deffn @deffn {Scheme-Prozedur} service? @var{Objekt} Liefert wahr zurück, wenn das @var{Objekt} ein Dienst ist. @end deffn @deffn {Scheme-Prozedur} service-kind @var{Dienst} Liefert den Typ des @var{Dienst}es — d.h.@: ein @code{}-Objekt. @end deffn @deffn {Scheme-Prozedur} service-value @var{Dienst} Liefert den Wert, der mit dem @var{Dienst} assoziiert wurde. Er repräsentiert die Parameter des @var{Dienst}es. @end deffn Hier ist ein Beispiel, wie ein Dienst erzeugt und manipuliert werden kann: @example (define s (service nginx-service-type (nginx-configuration (nginx nginx) (log-directory log-Verzeichnis) (run-directory run-Verzeichnis) (file config-Datei)))) (service? s) @result{} #t (eq? (service-kind s) nginx-service-type) @result{} #t @end example The @code{modify-services} form provides a handy way to change the parameters of some of the services of a list such as @code{%base-services} (@pxref{Basisdienste, @code{%base-services}}). It evaluates to a list of services. Of course, you could always use standard list combinators such as @code{map} and @code{fold} to do that (@pxref{SRFI-1, List Library,, guile, GNU Guile Reference Manual}); @code{modify-services} simply provides a more concise form for this common pattern. @deffn {Scheme-Syntax} modify-services @var{Dienste} @ (@var{Typ} @var{Variable} => @var{Rumpf}) @dots{} Passt die von @var{Dienste} bezeichnete Dienst-Liste entsprechend den angegebenen Klauseln an. Jede Klausel hat die Form: @example (@var{Typ} @var{Variable} => @var{Rumpf}) @end example wobei @var{Typ} einen Diensttyp (»service type«) bezeichnet — wie zum Beispiel @code{guix-service-type} — und @var{Variable} ein Bezeichner ist, der im @var{Rumpf} an die Dienst-Parameter — z.B.@: eine @code{guix-configuration}-Instanz — des ursprünglichen Dienstes mit diesem @var{Typ} gebunden wird. Der @var{Rumpf} muss zu den neuen Dienst-Parametern ausgewertet werden, welche benutzt werden, um den neuen Dienst zu konfigurieren. Dieser neue Dienst wird das Original in der resultierenden Liste ersetzen. Weil die Dienstparameter eines Dienstes mit @code{define-record-type*} erzeugt werden, können Sie einen kurzen @var{Rumpf} schreiben, der zu den neuen Dienstparametern ausgewertet wird, indem Sie die Funktionalität namens @code{inherit} benutzen, die von @code{define-record-type*} bereitgestellt wird. Siehe @ref{Das Konfigurationssystem nutzen} für ein Anwendungsbeispiel. @end deffn Als Nächstes ist die Programmierschnittstelle für Diensttypen an der Reihe. Sie ist etwas, was Sie kennen werden wollen, wenn Sie neue Dienstdefinitionen schreiben, aber wenn Sie nur Ihre @code{operating-system}-Deklaration anpassen möchten, brauchen Sie diese Schnittstelle wahrscheinlich nicht. @deftp {Datentyp} service-type @cindex Diensttyp Die Repräsentation eines @dfn{Diensttypen} (siehe @ref{Diensttypen und Dienste}). @table @asis @item @code{name} Dieses Symbol wird nur verwendet, um die Abläufe im System anzuzeigen und die Fehlersuche zu erleichtern. @item @code{extensions} Eine nicht-leere Liste von @code{}-Objekten (siehe unten). @item @code{compose} (Vorgabe: @code{#f}) Wenn es auf @code{#f} gesetzt ist, dann definiert der Diensttyp Dienste, die nicht erweitert werden können — d.h.@: diese Dienste erhalten ihren Wert nicht von anderen Diensten. Andernfalls muss es eine Prozedur sein, die ein einziges Argument entgegennimmt. Die Prozedur wird durch @code{fold-services} aufgerufen und ihr wird die Liste von aus den Erweiterungen angesammelten Werten übergeben. Sie gibt daraufhin einen einzelnen Wert zurück. @item @code{extend} (Vorgabe: @code{#f}) Ist dies auf @code{#f} gesetzt, dann können Dienste dieses Typs nicht erweitert werden. Andernfalls muss es eine zwei Argumente nehmende Prozedur sein, die von @code{fold-services} mit dem anfänglichen Wert für den Dienst als erstes Argument und dem durch Anwendung von @code{compose} gelieferten Wert als zweites Argument aufgerufen wird. Als Ergebnis muss ein Wert geliefert werden, der einen zulässigen neuen Parameterwert für die Dienstinstanz darstellt. @end table Siehe den Abschnitt @ref{Diensttypen und Dienste} für Beispiele. @end deftp @deffn {Scheme-Prozedur} service-extension @var{Zieltyp} @ @var{Berechner} Liefert eine neue Erweiterung für den Dienst mit dem @var{Zieltyp}. Als @var{Berechner} muss eine Prozedur angegeben werden, die ein einzelnes Argument nimmt: @code{fold-services} ruft sie auf und übergibt an sie den Wert des erweiternden Dienstes, sie muss dafür einen zulässigen Wert für den @var{Zieltyp} liefern. @end deffn @deffn {Scheme-Prozedur} service-extension? @var{Objekt} Liefert wahr zurück, wenn das @var{Objekt} eine Diensterweiterung ist. @end deffn Manchmal wollen Sie vielleicht einfach nur einen bestehenden Dienst erweitern. Dazu müssten Sie einen neuen Diensttyp definieren und die Erweiterung definieren, für die Sie sich interessieren, was ganz schön wortreich werden kann. Mit der Prozedur @code{simple-service} können Sie es kürzer fassen. @deffn {Scheme-Prozedur} simple-service @var{Name} @var{Zieltyp} @var{Wert} Liefert einen Dienst, der den Dienst mit dem @var{Zieltyp} um den @var{Wert} erweitert. Dazu wird ein Diensttyp mit dem @var{Name}n für den einmaligen Gebrauch erzeugt, den der zurückgelieferte Dienst instanziiert. Zum Beispiel kann mcron (siehe @ref{Geplante Auftragsausführung}) so um einen zusätzlichen Auftrag erweitert werden: @example (simple-service 'my-mcron-job mcron-service-type #~(job '(next-hour (3)) "guix gc -F 2G")) @end example @end deffn Den Kern dieses abstrakten Modells für Dienste bildet die Prozedur @code{fold-services}, die für das »Kompilieren« einer Liste von Diensten hin zu einem einzelnen Verzeichnis verantwortlich ist, in welchem alles enthalten ist, was Sie zum Booten und Hochfahren des Systems brauchen — d.h.@: das Verzeichnis, das der Befehl @command{guix system build} anzeigt (siehe @ref{Aufruf von guix system}). Einfach ausgedrückt propagiert @code{fold-services} Diensterweiterungen durch den Dienstgraphen nach unten und aktualisiert dabei in jedem Knoten des Graphen dessen Parameter, bis nur noch der Wurzelknoten übrig bleibt. @deffn {Scheme-Prozedur} fold-services @var{Dienste} @ [#:target-type @var{system-service-type}] Faltet die @var{Dienste} wie die funktionale Prozedur @code{fold} zu einem einzigen zusammen, indem ihre Erweiterungen nach unten propagiert werden, bis eine Wurzel vom @var{target-type} als Diensttyp erreicht wird; dieser so angepasste Wurzeldienst wird zurückgeliefert. @end deffn Als Letztes definiert das Modul @code{(gnu services)} noch mehrere essenzielle Diensttypen, von denen manche im Folgenden aufgelistet sind: @defvr {Scheme-Variable} system-service-type Die Wurzel des Dienstgraphen. Davon wird das Systemverzeichnis erzeugt, wie es vom Befehl @command{guix system build} zurückgeliefert wird. @end defvr @defvr {Scheme-Variable} boot-service-type Der Typ des »Boot-Dienstes«, der das @dfn{Boot-Skript} erzeugt. Das Boot-Skript ist das, was beim Booten durch die initiale RAM-Disk ausgeführt wird. @end defvr @defvr {Scheme-Variable} etc-service-type Der Typ des @file{/etc}-Dienstes. Dieser Dienst wird benutzt, um im @file{/etc}-Verzeichnis Dateien zu platzieren. Er kann erweitert werden, indem man Name-/Datei-Tupel an ihn übergibt wie in diesem Beispiel: @example (list `("issue" ,(plain-file "issue" "Willkommen!\n"))) @end example Dieses Beispiel würde bewirken, dass eine Datei @file{/etc/issue} auf die angegebene Datei verweist. @end defvr @defvr {Scheme-Variable} setuid-program-service-type Der Typ des Dienstes für setuid-Programme, der eine Liste von ausführbaren Dateien ansammelt, die jeweils als G-Ausdrücke übergeben werden und dann zur Menge der setuid-gesetzten Programme auf dem System hinzugefügt werden (siehe @ref{Setuid-Programme}). @end defvr @defvr {Scheme-Variable} profile-service-type Der Typ des Dienstes zum Einfügen von Dateien ins @dfn{Systemprofil} — d.h.@: die Programme unter @file{/run/current-system/profile}. Andere Dienste können ihn erweitern, indem sie ihm Listen von ins Systemprofil zu installierenden Paketen übergeben. @end defvr @node Shepherd-Dienste @subsection Shepherd-Dienste @cindex Shepherd-Dienste @cindex PID 1 @cindex init-System Das Modul @code{(gnu services shepherd)} gibt eine Methode an, mit der Dienste definiert werden können, die von GNU@tie{}Shepherd verwaltet werden, was das Initialisierungssystem (das »init«-System) ist — es ist der erste Prozess, der gestartet wird, wenn das System gebootet wird, auch bekannt als PID@tie{}1 (siehe @ref{Einführung,,, shepherd, The GNU Shepherd Manual}). Dienste unter dem Shepherd können voneinander abhängen. Zum Beispiel kann es sein, dass der SSH-Daemon erst gestartet werden darf, nachdem der Syslog-Daemon gestartet wurde, welcher wiederum erst gestartet werden kann, sobald alle Dateisysteme eingebunden wurden. Das einfache Betriebssystem, dessen Definition wir zuvor gesehen haben (siehe @ref{Das Konfigurationssystem nutzen}), ergibt folgenden Dienstgraphen: @image{images/shepherd-graph,,5in,Typischer Shepherd-Dienstgraph} Sie können so einen Graphen tatsächlich für jedes Betriebssystem erzeugen lassen, indem Sie den Befehl @command{guix system shepherd-graph} benutzen (siehe @ref{system-shepherd-graph, @command{guix system shepherd-graph}}). The @code{%shepherd-root-service} is a service object representing PID@tie{}1, of type @code{shepherd-root-service-type}; it can be extended by passing it lists of @code{} objects. @deftp {Datentyp} shepherd-service Der Datentyp, der einen von Shepherd verwalteten Dienst repräsentiert. @table @asis @item @code{provision} Diese Liste von Symbolen gibt an, was vom Dienst angeboten wird. Das bedeutet, es sind die Namen, die an @command{herd start}, @command{herd status} und ähnliche Befehle übergeben werden können (siehe @ref{Invoking herd,,, shepherd, The GNU Shepherd Manual}). Siehe @ref{Slots of services, the @code{provides} slot,, shepherd, The GNU Shepherd Manual} für Details. @item @code{requirements} (Vorgabe: @code{'()}) Eine Liste von Symbolen, die angegeben, von welchen anderen Shepherd-Diensten dieser hier abhängt. @item @code{respawn?} (Vorgabe: @code{#t}) Ob der Dienst neu gestartet werden soll, nachdem er gestoppt wurde, zum Beispiel wenn der ihm zu Grunde liegende Prozess terminiert wird. @item @code{start} @itemx @code{stop} (Vorgabe: @code{#~(const #f)}) Die Felder @code{start} und @code{stop} beziehen sich auf Shepherds Funktionen zum Starten und Stoppen von Prozessen (siehe @ref{Service De- and Constructors,,, shepherd, The GNU Shepherd Manual}). Sie enthalten G-Ausdrücke, die in eine Shepherd-Konfigurationdatei umgeschrieben werden (siehe @ref{G-Ausdrücke}). @item @code{actions} (Vorgabe: @code{'()}) @cindex Aktionen, bei Shepherd-Diensten Dies ist eine Liste von @code{shepherd-action}-Objekten (siehe unten), die vom Dienst zusätzlich unterstützte @dfn{Aktionen} neben den Standardaktionen @code{start} und @code{stop} angeben. Hier aufgeführte Aktionen werden als @command{herd}-Unterbefehle verfügbar gemacht: @example herd @var{Aktion} @var{Dienst} [@var{Argumente}@dots{}] @end example @item @code{Dokumentation} Eine Zeichenkette zur Dokumentation, die angezeigt wird, wenn man dies ausführt: @example herd doc @var{Dienstname} @end example where @var{service-name} is one of the symbols in @code{provision} (@pxref{Invoking herd,,, shepherd, The GNU Shepherd Manual}). @item @code{modules} (default: @code{%default-modules}) Dies ist die Liste der Module, die in den Sichtbarkeitsbereich geladen sein müssen, wenn @code{start} und @code{stop} ausgewertet werden. @end table @end deftp @deftp {Datentyp} shepherd-action Dieser Datentyp definiert zusätzliche Aktionen, die ein Shepherd-Dienst implementiert (siehe oben). @table @code @item name Die Aktion bezeichnendes Symbol. @item Dokumentation Diese Zeichenkette ist die Dokumentation für die Aktion. Sie können sie sehen, wenn Sie dies ausführen: @example herd doc @var{Dienst} action @var{Aktion} @end example @item procedure Dies sollte ein G-Ausdruck sein, der zu einer mindestens ein Argument nehmenden Prozedur ausgewertet wird. Das Argument ist der »running«-Wert des Dienstes (siehe @ref{Slots of services,,, shepherd, The GNU Shepherd Manual}). @end table Das folgende Beispiel definiert eine Aktion namens @code{sag-hallo}, die den Benutzer freundlich begrüßt: @example (shepherd-action (name 'sag-hallo) (documentation "Sag Hallo!") (procedure #~(lambda (running . args) (format #t "Hallo, Freund! Argumente: ~s\n" args) #t))) @end example Wenn wir annehmen, dass wir die Aktion zum Dienst @code{beispiel} hinzufügen, können Sie Folgendes ausführen: @example # herd sag-hallo beispiel Hallo, Freund! Argumente: () # herd sag-hallo beispiel a b c Hallo, Freund! Argumente: ("a" "b" "c") @end example Wie Sie sehen können, ist das eine sehr ausgeklügelte Art, Hallo zu sagen. Siehe @ref{Service Convenience,,, shepherd, The GNU Shepherd Manual} für mehr Informationen zu Aktionen. @end deftp @defvr {Scheme-Variable} shepherd-root-service-type Der Diensttyp für den Shepherd-»Wurzeldienst« — also für PID@tie{}1. Dieser Diensttyp stellt das Ziel für Diensterweiterungen dar, die Shepherd-Dienste erzeugen sollen (siehe @ref{Diensttypen und Dienste} für ein Beispiel). Jede Erweiterung muss eine Liste von @code{}-Objekten übergeben. @end defvr @defvr {Scheme-Variable} %shepherd-root-service Dieser Dienst repräsentiert PID@tie{}1. @end defvr @node Dokumentation @chapter Dokumentation @cindex documentation, searching for @cindex searching for documentation @cindex Info, documentation format @cindex man pages @cindex manual pages In most cases packages installed with Guix come with documentation. There are two main documentation formats: ``Info'', a browseable hypertext format used for GNU software, and ``manual pages'' (or ``man pages''), the linear documentation format traditionally found on Unix. Info manuals are accessed with the @command{info} command or with Emacs, and man pages are accessed using @command{man}. You can look for documentation of software installed on your system by keyword. For example, the following command searches for information about ``TLS'' in Info manuals: @example $ info -k TLS "(emacs)Network Security" -- STARTTLS "(emacs)Network Security" -- TLS "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_flags "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_function @dots{} @end example @noindent The command below searches for the same keyword in man pages: @example $ man -k TLS SSL (7) - OpenSSL SSL/TLS library certtool (1) - GnuTLS certificate tool @dots {} @end example These searches are purely local to your computer so you have the guarantee that documentation you find corresponds to what you have actually installed, you can access it off-line, and your privacy is respected. Once you have these results, you can view the relevant documentation by running, say: @example $ info "(gnutls)Core TLS API" @end example @noindent or: @example $ man certtool @end example Info manuals contain sections and indices as well as hyperlinks like those found in Web pages. The @command{info} reader (@pxref{Top, Info reader,, info-stnd, Stand-alone GNU Info}) and its Emacs counterpart (@pxref{Misc Help,,, emacs, The GNU Emacs Manual}) provide intuitive key bindings to navigate manuals. @xref{Getting Started,,, info, Info: An Introduction}, for an introduction to Info navigation. @node Dateien zur Fehlersuche installieren @chapter Dateien zur Fehlersuche installieren @cindex debugging files Program binaries, as produced by the GCC compilers for instance, are typically written in the ELF format, with a section containing @dfn{debugging information}. Debugging information is what allows the debugger, GDB, to map binary code to source code; it is required to debug a compiled program in good conditions. The problem with debugging information is that is takes up a fair amount of disk space. For example, debugging information for the GNU C Library weighs in at more than 60 MiB. Thus, as a user, keeping all the debugging info of all the installed programs is usually not an option. Yet, space savings should not come at the cost of an impediment to debugging---especially in the GNU system, which should make it easier for users to exert their computing freedom (@pxref{GNU-Distribution}). Thankfully, the GNU Binary Utilities (Binutils) and GDB provide a mechanism that allows users to get the best of both worlds: debugging information can be stripped from the binaries and stored in separate files. GDB is then able to load debugging information from those files, when they are available (@pxref{Separate Debug Files,,, gdb, Debugging with GDB}). The GNU distribution takes advantage of this by storing debugging information in the @code{lib/debug} sub-directory of a separate package output unimaginatively called @code{debug} (@pxref{Pakete mit mehreren Ausgaben.}). Users can choose to install the @code{debug} output of a package when they need it. For instance, the following command installs the debugging information for the GNU C Library and for GNU Guile: @example guix package -i glibc:debug guile:debug @end example GDB must then be told to look for debug files in the user's profile, by setting the @code{debug-file-directory} variable (consider setting it from the @file{~/.gdbinit} file, @pxref{Startup,,, gdb, Debugging with GDB}): @example (gdb) set debug-file-directory ~/.guix-profile/lib/debug @end example From there on, GDB will pick up debugging information from the @code{.debug} files under @file{~/.guix-profile/lib/debug}. In addition, you will most likely want GDB to be able to show the source code being debugged. To do that, you will have to unpack the source code of the package of interest (obtained with @code{guix build --source}, @pxref{Aufruf von guix build}), and to point GDB to that source directory using the @code{directory} command (@pxref{Source Path, @code{directory},, gdb, Debugging with GDB}). @c XXX: keep me up-to-date The @code{debug} output mechanism in Guix is implemented by the @code{gnu-build-system} (@pxref{Erstellungssysteme}). Currently, it is opt-in---debugging information is available only for the packages with definitions explicitly declaring a @code{debug} output. This may be changed to opt-out in the future if our build farm servers can handle the load. To check whether a package has a @code{debug} output, use @command{guix package --list-available} (@pxref{Aufruf von guix package}). @node Sicherheitsaktualisierungen @chapter Sicherheitsaktualisierungen @cindex security updates @cindex Sicherheitslücken Occasionally, important security vulnerabilities are discovered in software packages and must be patched. Guix developers try hard to keep track of known vulnerabilities and to apply fixes as soon as possible in the @code{master} branch of Guix (we do not yet provide a ``stable'' branch containing only security updates.) The @command{guix lint} tool helps developers find out about vulnerable versions of software packages in the distribution: @smallexample $ guix lint -c cve gnu/packages/base.scm:652:2: glibc@@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547 gnu/packages/gcc.scm:334:2: gcc@@4.9.3: probably vulnerable to CVE-2015-5276 gnu/packages/image.scm:312:2: openjpeg@@2.1.0: probably vulnerable to CVE-2016-1923, CVE-2016-1924 @dots{} @end smallexample @xref{Aufruf von guix lint}, for more information. @quotation Anmerkung As of version @value{VERSION}, the feature described below is considered ``beta''. @end quotation Guix follows a functional package management discipline (@pxref{Einführung}), which implies that, when a package is changed, @emph{every package that depends on it} must be rebuilt. This can significantly slow down the deployment of fixes in core packages such as libc or Bash, since basically the whole distribution would need to be rebuilt. Using pre-built binaries helps (@pxref{Substitute}), but deployment may still take more time than desired. @cindex grafts To address this, Guix implements @dfn{grafts}, a mechanism that allows for fast deployment of critical updates without the costs associated with a whole-distribution rebuild. The idea is to rebuild only the package that needs to be patched, and then to ``graft'' it onto packages explicitly installed by the user and that were previously referring to the original package. The cost of grafting is typically very low, and order of magnitudes lower than a full rebuild of the dependency chain. @cindex replacements of packages, for grafts For instance, suppose a security update needs to be applied to Bash. Guix developers will provide a package definition for the ``fixed'' Bash, say @code{bash-fixed}, in the usual way (@pxref{Pakete definieren}). Then, the original package definition is augmented with a @code{replacement} field pointing to the package containing the bug fix: @example (define bash (package (name "bash") ;; @dots{} (replacement bash-fixed))) @end example From there on, any package depending directly or indirectly on Bash---as reported by @command{guix gc --requisites} (@pxref{Aufruf von guix gc})---that is installed is automatically ``rewritten'' to refer to @code{bash-fixed} instead of @code{bash}. This grafting process takes time proportional to the size of the package, usually less than a minute for an ``average'' package on a recent machine. Grafting is recursive: when an indirect dependency requires grafting, then grafting ``propagates'' up to the package that the user is installing. Currently, the length of the name and version of the graft and that of the package it replaces (@code{bash-fixed} and @code{bash} in the example above) must be equal. This restriction mostly comes from the fact that grafting works by patching files, including binary files, directly. Other restrictions may apply: for instance, when adding a graft to a package providing a shared library, the original shared library and its replacement must have the same @code{SONAME} and be binary-compatible. The @option{--no-grafts} command-line option allows you to forcefully avoid grafting (@pxref{Gemeinsame Erstellungsoptionen, @option{--no-grafts}}). Thus, the command: @example guix build bash --no-grafts @end example @noindent returns the store file name of the original Bash, whereas: @example guix build bash @end example @noindent returns the store file name of the ``fixed'', replacement Bash. This allows you to distinguish between the two variants of Bash. To verify which Bash your whole profile refers to, you can run (@pxref{Aufruf von guix gc}): @example guix gc -R `readlink -f ~/.guix-profile` | grep bash @end example @noindent @dots{} and compare the store file names that you get with those above. Likewise for a complete Guix system generation: @example guix gc -R `guix system build my-config.scm` | grep bash @end example Lastly, to check which Bash running processes are using, you can use the @command{lsof} command: @example lsof | grep /gnu/store/.*bash @end example @node Bootstrapping @chapter Bootstrapping @c Adapted from the ELS 2013 paper. @cindex bootstrapping Bootstrapping in our context refers to how the distribution gets built ``from nothing''. Remember that the build environment of a derivation contains nothing but its declared inputs (@pxref{Einführung}). So there's an obvious chicken-and-egg problem: how does the first package get built? How does the first compiler get compiled? Note that this is a question of interest only to the curious hacker, not to the regular user, so you can shamelessly skip this section if you consider yourself a ``regular user''. @cindex bootstrap binaries The GNU system is primarily made of C code, with libc at its core. The GNU build system itself assumes the availability of a Bourne shell and command-line tools provided by GNU Coreutils, Awk, Findutils, `sed', and `grep'. Furthermore, build programs---programs that run @code{./configure}, @code{make}, etc.---are written in Guile Scheme (@pxref{Ableitungen}). Consequently, to be able to build anything at all, from scratch, Guix relies on pre-built binaries of Guile, GCC, Binutils, libc, and the other packages mentioned above---the @dfn{bootstrap binaries}. These bootstrap binaries are ``taken for granted'', though we can also re-create them if needed (more on that later). @unnumberedsec Preparing to Use the Bootstrap Binaries @c As of Emacs 24.3, Info-mode displays the image, but since it's a @c large image, it's hard to scroll. Oh well. @image{images/bootstrap-graph,6in,,Dependency graph of the early bootstrap derivations} The figure above shows the very beginning of the dependency graph of the distribution, corresponding to the package definitions of the @code{(gnu packages bootstrap)} module. A similar figure can be generated with @command{guix graph} (@pxref{Aufruf von guix graph}), along the lines of: @example guix graph -t derivation \ -e '(@@@@ (gnu packages bootstrap) %bootstrap-gcc)' \ | dot -Tps > t.ps @end example At this level of detail, things are slightly complex. First, Guile itself consists of an ELF executable, along with many source and compiled Scheme files that are dynamically loaded when it runs. This gets stored in the @file{guile-2.0.7.tar.xz} tarball shown in this graph. This tarball is part of Guix's ``source'' distribution, and gets inserted into the store with @code{add-to-store} (@pxref{Der Store}). But how do we write a derivation that unpacks this tarball and adds it to the store? To solve this problem, the @code{guile-bootstrap-2.0.drv} derivation---the first one that gets built---uses @code{bash} as its builder, which runs @code{build-bootstrap-guile.sh}, which in turn calls @code{tar} to unpack the tarball. Thus, @file{bash}, @file{tar}, @file{xz}, and @file{mkdir} are statically-linked binaries, also part of the Guix source distribution, whose sole purpose is to allow the Guile tarball to be unpacked. Once @code{guile-bootstrap-2.0.drv} is built, we have a functioning Guile that can be used to run subsequent build programs. Its first task is to download tarballs containing the other pre-built binaries---this is what the @code{.tar.xz.drv} derivations do. Guix modules such as @code{ftp-client.scm} are used for this purpose. The @code{module-import.drv} derivations import those modules in a directory in the store, using the original layout. The @code{module-import-compiled.drv} derivations compile those modules, and write them in an output directory with the right layout. This corresponds to the @code{#:modules} argument of @code{build-expression->derivation} (@pxref{Ableitungen}). Finally, the various tarballs are unpacked by the derivations @code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv}, etc., at which point we have a working C tool chain. @unnumberedsec Building the Build Tools Bootstrapping is complete when we have a full tool chain that does not depend on the pre-built bootstrap tools discussed above. This no-dependency requirement is verified by checking whether the files of the final tool chain contain references to the @file{/gnu/store} directories of the bootstrap inputs. The process that leads to this ``final'' tool chain is described by the package definitions found in the @code{(gnu packages commencement)} module. The @command{guix graph} command allows us to ``zoom out'' compared to the graph above, by looking at the level of package objects instead of individual derivations---remember that a package may translate to several derivations, typically one derivation to download its source, one to build the Guile modules it needs, and one to actually build the package from source. The command: @example guix graph -t bag \ -e '(@@@@ (gnu packages commencement) glibc-final-with-bootstrap-bash)' | dot -Tps > t.ps @end example @noindent produces the dependency graph leading to the ``final'' C library@footnote{You may notice the @code{glibc-intermediate} label, suggesting that it is not @emph{quite} final, but as a good approximation, we will consider it final.}, depicted below. @image{images/bootstrap-packages,6in,,Dependency graph of the early packages} @c See . The first tool that gets built with the bootstrap binaries is GNU@tie{}Make---noted @code{make-boot0} above---which is a prerequisite for all the following packages. From there Findutils and Diffutils get built. Then come the first-stage Binutils and GCC, built as pseudo cross tools---i.e., with @code{--target} equal to @code{--host}. They are used to build libc. Thanks to this cross-build trick, this libc is guaranteed not to hold any reference to the initial tool chain. From there the final Binutils and GCC (not shown above) are built. GCC uses @code{ld} from the final Binutils, and links programs against the just-built libc. This tool chain is used to build the other packages used by Guix and by the GNU Build System: Guile, Bash, Coreutils, etc. And voilà! At this point we have the complete set of build tools that the GNU Build System expects. These are in the @code{%final-inputs} variable of the @code{(gnu packages commencement)} module, and are implicitly used by any package that uses @code{gnu-build-system} (@pxref{Erstellungssysteme, @code{gnu-build-system}}). @unnumberedsec Building the Bootstrap Binaries @cindex bootstrap binaries Because the final tool chain does not depend on the bootstrap binaries, those rarely need to be updated. Nevertheless, it is useful to have an automated way to produce them, should an update occur, and this is what the @code{(gnu packages make-bootstrap)} module provides. The following command builds the tarballs containing the bootstrap binaries (Guile, Binutils, GCC, libc, and a tarball containing a mixture of Coreutils and other basic command-line tools): @example guix build bootstrap-tarballs @end example The generated tarballs are those that should be referred to in the @code{(gnu packages bootstrap)} module mentioned at the beginning of this section. Still here? Then perhaps by now you've started to wonder: when do we reach a fixed point? That is an interesting question! The answer is unknown, but if you would like to investigate further (and have significant computational and storage resources to do so), then let us know. @unnumberedsec Reducing the Set of Bootstrap Binaries Our bootstrap binaries currently include GCC, Guile, etc. That's a lot of binary code! Why is that a problem? It's a problem because these big chunks of binary code are practically non-auditable, which makes it hard to establish what source code produced them. Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper @emph{Reflections on Trusting Trust}. This is mitigated by the fact that our bootstrap binaries were generated from an earlier Guix revision. Nevertheless it lacks the level of transparency that we get in the rest of the package dependency graph, where Guix always gives us a source-to-binary mapping. Thus, our goal is to reduce the set of bootstrap binaries to the bare minimum. The @uref{http://bootstrappable.org, Bootstrappable.org web site} lists on-going projects to do that. One of these is about replacing the bootstrap GCC with a sequence of assemblers, interpreters, and compilers of increasing complexity, which could be built from source starting from a simple and auditable assembler. Your help is welcome! @node Portierung @chapter Porting to a New Platform As discussed above, the GNU distribution is self-contained, and self-containment is achieved by relying on pre-built ``bootstrap binaries'' (@pxref{Bootstrapping}). These binaries are specific to an operating system kernel, CPU architecture, and application binary interface (ABI). Thus, to port the distribution to a platform that is not yet supported, one must build those bootstrap binaries, and update the @code{(gnu packages bootstrap)} module to use them on that platform. Fortunately, Guix can @emph{cross compile} those bootstrap binaries. When everything goes well, and assuming the GNU tool chain supports the target platform, this can be as simple as running a command like this one: @example guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs @end example For this to work, the @code{glibc-dynamic-linker} procedure in @code{(gnu packages bootstrap)} must be augmented to return the right file name for libc's dynamic linker on that platform; likewise, @code{system->linux-architecture} in @code{(gnu packages linux)} must be taught about the new platform. Once these are built, the @code{(gnu packages bootstrap)} module needs to be updated to refer to these binaries on the target platform. That is, the hashes and URLs of the bootstrap tarballs for the new platform must be added alongside those of the currently supported platforms. The bootstrap Guile tarball is treated specially: it is expected to be available locally, and @file{gnu/local.mk} has rules to download it for the supported architectures; a rule for the new platform must be added as well. In practice, there may be some complications. First, it may be that the extended GNU triplet that specifies an ABI (like the @code{eabi} suffix above) is not recognized by all the GNU tools. Typically, glibc recognizes some of these, whereas GCC uses an extra @code{--with-abi} configure flag (see @code{gcc.scm} for examples of how to handle this). Second, some of the required packages could fail to build for that platform. Lastly, the generated binaries could be broken for some reason. @c ********************************************************************* @include contributing.de.texi @c ********************************************************************* @node Danksagungen @chapter Danksagungen Guix baut auf dem @uref{http://nixos.org/nix/, Nix-Paketverwaltungsprogramm} auf, das von Eelco Dolstra entworfen und entwickelt wurde, mit Beiträgen von anderen Leuten (siehe die Datei @file{nix/AUTHORS} in Guix). Nix hat für die funktionale Paketverwaltung die Pionierarbeit geleistet und noch nie dagewesene Funktionalitäten vorangetrieben wie transaktionsbasierte Paketaktualisierungen und die Rücksetzbarkeit selbiger, eigene Paketprofile für jeden Nutzer und referenziell transparente Erstellungsprozesse. Ohne diese Arbeit gäbe es Guix nicht. Die Nix-basierten Software-Distributionen Nixpkgs und NixOS waren auch eine Inspiration für Guix. GNU@tie{}Guix ist selbst das Produkt kollektiver Arbeit mit Beiträgen durch eine Vielzahl von Leuten. Siehe die Datei @file{AUTHORS} in Guix für mehr Informationen, wer diese wunderbaren Menschen sind. In der Datei @file{THANKS} finden Sie eine Liste der Leute, die uns geholfen haben, indem Sie Fehler gemeldet, sich um unsere Infrastruktur gekümmert, künstlerische Arbeit und schön gestaltete Themen beigesteuert, Vorschläge gemacht und noch vieles mehr getan haben — vielen Dank! @c ********************************************************************* @node GNU-Lizenz für freie Dokumentation @appendix GNU-Lizenz für freie Dokumentation @cindex Lizenz, GNU-Lizenz für freie Dokumentation @include fdl-1.3.texi @c ********************************************************************* @node Konzeptverzeichnis @unnumbered Konzeptverzeichnis @printindex cp @node Programmierverzeichnis @unnumbered Programmierverzeichnis @syncodeindex tp fn @syncodeindex vr fn @printindex fn @bye @c Local Variables: @c ispell-local-dictionary: "american"; @c End: