\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-cookbook.de.info
@documentencoding UTF-8
@documentlanguage de
@frenchspacing on
@settitle GNU-Guix-Kochbuch
@c %**end of header

@c Onion service for ci.guix.gnu.org.
@set SUBSTITUTE-TOR-URL https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion

@copying
Copyright @copyright{} 2019, 2022 Ricardo Wurmus@* Copyright @copyright{}
2019 Efraim Flashner@* Copyright @copyright{} 2019 Pierre Neidhardt@*
Copyright @copyright{} 2020 Oleg Pykhalov@* Copyright @copyright{} 2020
Matthew Brooks@* Copyright @copyright{} 2020 Marcin Karpezo@* Copyright
@copyright{} 2020 Brice Waegeneire@* Copyright @copyright{} 2020 André
Batista@* Copyright @copyright{} 2020 Christine Lemmer-Webber@* Copyright
@copyright{} 2021 Joshua Branson@* Copyright @copyright{} 2022, 2023 Maxim
Cournoyer@* Copyright @copyright{} 2023-2025 Ludovic Courtès@* Copyright
@copyright{} 2023 Thomas Ieong@* Copyright @copyright{} 2024 Florian Pelz@*
Copyright @copyright{} 2025 45mg@* Copyright @copyright{} 2023 Marek
Felšöci@* Copyright @copyright{} 2023 Konrad Hinsen@* Copyright @copyright{}
2023 Philippe Swartvagher@*

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-Lizenz für freie Dokumentation“.
@end copying

@dircategory Systemadministration
@direntry
* Guix-Kochbuch: (guix-cookbook.de).  Anleitungen und Beispiele für GNU 
                                        Guix.
@end direntry

@titlepage
@title GNU-Guix-Kochbuch
@subtitle Anleitungen und Beispiele, wie man den funktionalen Paketmanager GNU Guix benutzt
@author Die Entwickler von GNU Guix

@page
@vskip 0pt plus 1filll

@insertcopying
@end titlepage

@contents

@c *********************************************************************
@node Top
@top GNU-Guix-Kochbuch

Dieses Dokument stellt Anleitungen und detaillierte Beispiele vor, wie man
GNU@tie{}Guix benutzt, ein Werkzeug zur funktionalen Paketverwaltung, das
für das GNU-System geschrieben wurde. Bitte lesen Sie Details zum System,
seinen Programmierschnittstellen und ähnlichen Konzepten im @ref{Top,,,
guix.de, Referenzhandbuch zu GNU Guix} nach.

@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-cookbook, GNU
Guix Cookbook}), in Vereinfachtem Chinesisch (siehe @ref{Top,,,
guix-cookbook.zh_CN, GNU Guix 烹饪书}), auf Französisch (siehe @ref{Top,,,
guix-cookbook.fr, Livre de recettes de GNU Guix}), auf Koreanisch (siehe
@ref{Top,,, guix-cookbook.ko, GNU Guix 쿡북}), auf Spanisch (siehe @ref{Top,,,
guix-cookbook.es, Libro de recetas de GNU Guix}), auf Italienisch (siehe
@ref{Top,,, guix-cookbook.it, Ricettario di GNU Guix}), auf Brasilianischem
Portugiesisch (siehe @ref{Top,,, guix-cookbook.pt_BR, Livro de receitas do
GNU Guix}), auf Russisch (siehe @ref{Top,,, guix-cookbook.ru, GNU Guix
Рецепты}), auf Slowakisch (siehe @ref{Top,,, guix-cookbook.sk, Receptár GNU
Guix}), Schwedisch (@pxref{Top,,, guix-cookbook.sv, Kokbok för GNU Guix})
und auf Tamil (@pxref{Top,,, guix-cookbook.ta, GNU Guix கையேடு})
verfügbar. Wenn Sie dieses Dokument in Ihre eigene Sprache übersetzen
möchten, dann sind Sie bei
@uref{https://translate.codeberg.org/projects/guix/documentation-cookbook,
Weblate} herzlich willkommen (siehe @ref{Guix übersetzen,,, guix.de,
Referenzhandbuch zu GNU Guix}).

@menu
* Anleitungen zu Scheme::    Lernen Sie Ihre neue Lieblingssprache kennen!
* Pakete schreiben::         Wie man eigene Pakete verfasst.
* Systemkonfiguration::      Das GNU-System anpassen.
* Container::                Isolierte Umgebungen und verschachtelte 
                               Systeme.
* Virtuelle Maschinen::      Bedienung und Konfiguration von VM.
* Fortgeschrittene Paketverwaltung::  Alle Macht den Nutzern!
* Software-Entwicklung::     Umgebungen, kontinuierliche Integration usw.
* Umgebungen verwalten::     Umgebungen festlegen.
* Reproduzierbare Wissenschaft::  Eine Grundlage für reproduzierbare 
                                    Wissenschaft.
* Auf einem Rechencluster installieren::  Hochleistungsrechnen mit Guix.
* Verwalten eines Guix System::  Wo die Systemverwaltung anders ist.

* Danksagungen::             Danke!
* GNU-Lizenz für freie Dokumentation::  Die Lizenz dieses Dokuments.
* Konzeptverzeichnis::       Konzepte.

@detailmenu
 --- Detaillierte Liste der Knoten ---



Anleitungen zu Scheme



* Ein Schnellkurs in Scheme::  Ein Schnellkurs in Scheme

Pakete schreiben



* Anleitung zum Paketeschreiben::  Eine Anleitung, wie Sie Pakete zu Guix 
                                     hinzufügen.
* Packaging Workflows::      Real life examples on working with specific 
                               build systems.

Anleitung zum Paketeschreiben



* Ein Hallo-Welt-Paket::     Ein Hallo-Welt-Paket
* Herangehensweisen::        Herangehensweisen
* Erweitertes Beispiel::     Erweitertes Beispiel
* Andere Erstellungssysteme::  Andere Erstellungssysteme
* Programmierbare und automatisierte Paketdefinition::  Programmierbare und 
                                                          automatisierte 
                                                          Paketdefinition
* Hilfe bekommen::           Hilfe bekommen
* Schlusswort::              Schlusswort
* Literaturverzeichnis::     Literaturverzeichnis

Herangehensweisen



* Lokale Datei::             Lokale Datei
* Kanäle::                   Kanäle
* Direkt am Checkout hacken::  Direkt am Checkout hacken

Programmierbare und automatisierte Paketdefinition



* Rekursive Importer::       Rekursive Importer
* Automatisch aktualisieren::  Automatisch aktualisieren
* Vererbung::                Vererbung

Packaging Workflows



* Packaging Rust Crates::    Packaging Rust Crates

Packaging Rust Crates



* Common Workflow for Rust Packaging::  Common Workflow for Rust Packaging
* Cargo Workspaces and Development Snapshots::  Cargo Workspaces and 
                                                  Development Snapshots
* Using Rust Libraries in Other Build Systems::  Using Rust Libraries in 
                                                   Other Build Systems

Systemkonfiguration



* Automatisch an virtueller Konsole anmelden::  Benutzer an einem bestimmten 
                                                  TTY automatisch anmelden.
* Den Kernel anpassen::      Einen eigenen Linux-Kernel auf Guix System 
                               erzeugen und benutzen.
* Die Image-Schnittstelle von Guix System::  Abbilder für bestimmte 
                                               Plattformen anpassen.
* Sicherheitsschlüssel verwenden::  Ihre Sicherheitsschlüssel mit Guix 
                                      System gebrauchen.
* Dynamisches DNS als mcron-Auftrag::  Mit diesem Auftrag bleibt Ihre 
                                         IP-Adresse bei DuckDNS aktuell.
* Verbinden mit Wireguard VPN::  Wie man sich mit einem Wireguard-VPN 
                                   verbindet.
* Fensterverwalter (Window Manager) anpassen::  Wie man einen 
                                                  Fensterverwalter auf Guix 
                                                  System anpassen kann.
* Guix auf einem Linode-Server nutzen::  Guix auf einem Linode-Server 
                                           nutzen.
* Guix auf einem Kimsufi-Server nutzen::  Guix auf einem Kimsufi-Server 
                                            nutzen.
* Bind-Mounts anlegen::      Bind-Mounts als Dateisystemdefinition 
                               einrichten.
* Substitute über Tor beziehen::  Den Guix-Daemon konfigurieren, damit er 
                                    Substitute über Tor lädt.
* NGINX mit Lua konfigurieren::  Den NGINX-Web-Server so einrichten, dass 
                                   Lua-Module geladen werden.
* Musik-Server mit Bluetooth-Audio::  Musikzentrale ohne Bildschirm mit 
                                        Bluetooth-Ausgabe.

Fensterverwalter (Window Manager) anpassen



* StumpWM::                  StumpWM
* Sitzungen sperren::        Sitzungen sperren

Sitzungen sperren



* Xorg::                     Xorg

Container



* Guix-Container::           Völlig isolierte Umgebungen.
* Container mit Guix System::  Ein System in Ihrem System.

Container mit Guix System



* Ein Datenbank-Container::  Ein Datenbank-Container
* Netzwerkverbindungen im Container::  Netzwerkverbindungen im Container

Virtuelle Maschinen



* Netzwerkbrücke für QEMU::  Netzwerkbrücke für QEMU
* Netzwerk-Routing anschalten in libvirt::  Netzwerk-Routing anschalten in 
                                              libvirt
* Eigenes NAT-basiertes Netzwerk in libvirt::  Eigenes NAT-basiertes 
                                                 Netzwerk in libvirt
* Literaturangaben: Literaturangaben zu VM.  Weiterführende Literatur zu 
                                               virtuellen Maschinen.

Fortgeschrittene Paketverwaltung



* Guix-Profile in der Praxis::  Strategien für mehrere Profile und 
                                  Manifeste.

Guix-Profile in der Praxis



* Grundlegende Einrichtung über Manifeste::  Grundlegende Einrichtung über 
                                               Manifeste
* Die nötigen Pakete::       Die nötigen Pakete
* Vorgabeprofil::            Vorgabeprofil
* Der Vorteil von Manifesten::  Der Vorteil von Manifesten
* Reproduzierbare Profile::  Reproduzierbare Profile

Software-Entwicklung



* Einstieg::                 Schritt 0: „guix shell“ benutzen.
* Erstellen mit Guix::       Schritt 1: Ihren Code kompilieren.
* Das Repository als Kanal::  Schritt 2: Ein Repo in einen Kanal verwandeln.
* Paketvarianten::           Bonus: Varianten definieren.
* Kontinuierliche Integration einrichten::  Schritt 3: Kontinuierliche 
                                              Integration.
* Erstellungs-Manifest::     Bonus: Manifest.
* Zusammenfassung::          Resümee.

Umgebungen verwalten



* Guix-Umgebung mit direnv::  Mit direnv Guix-Umgebungen einrichten.

Guix zur reproduzierbaren Wissenschaft heranziehen



* Setting Up the Environment::  Step 1: using `guix shell'.
* Recording the Environment::  Step 2: using `guix describe'.
* Ensuring Long-Term Source Code Archiving::  Step 3: Software Heritage.
* Referencing the Software Environment::  Step 4: SWHIDs.

Auf einem Rechencluster installieren



* Den Zentralrechner konfigurieren::  Auf diesem Rechner läuft der Daemon.
* Die Arbeitsrechner konfigurieren::  Die Client-Knoten.
* Netzwerkzugriff im Cluster::  Der Umgang mit eingeschränktem 
                                  Netzwerkzugriff.
* Speicherplatz im Cluster::  Mit dem Plattenplatz haushalten.
* Sicherheit im Cluster::    Sicherheit gewährleisten.

Verwalten eines Guix System



* Postgres für Cuirass aktualisieren::  Aktualisieren, wenn man noch das 
                                          vorgegebene Postgres hat.

@end detailmenu
@end menu

@c *********************************************************************
@node Anleitungen zu Scheme
@chapter Anleitungen zu Scheme

GNU@tie{}Guix ist in Scheme geschrieben, einer für alle Anwendungszwecke
geeigneten Programmiersprache, und viele Funktionalitäten von Guix können
programmatisch angesteuert und verändert werden. Sie können Scheme benutzen,
um Paketdefinitionen zu erzeugen, abzuändern, ganze Betriebssysteme
einzuspielen etc.

Wenn man die Grundzüge kennt, wie man in Scheme programmiert, bekommt man
Zugang zu vielen der fortgeschrittenen Funktionen von Guix@tie{}– und Sie
müssen dazu nicht einmal ein erfahrener Programmierer sein!

Legen wir los!

@menu
* Ein Schnellkurs in Scheme::  Ein Schnellkurs in Scheme
@end menu

@node Ein Schnellkurs in Scheme
@section Ein Schnellkurs in Scheme

@cindex Scheme, Schnellkurs

Die von Guix benutzte Scheme-Implementierung nennt sich Guile. Um mit der
Sprache herumspielen zu können, installieren Sie Guile mit @code{guix
install guile} und starten eine interaktive Programmierumgebung (englisch
@uref{https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop,
Read-Eval-Print-Loop}, kurz REPL), indem Sie @code{guile} auf der
Befehlszeile ausführen.

Alternativ können Sie auch den Befehl @code{guix shell -- guile} ausführen,
wenn Sie Guile lieber @emph{nicht} in Ihr Nutzerprofil installieren wollen.

In den folgenden Beispielen stehen die Zeilen dafür, was Sie auf der REPL
eintippen; wenn eine Zeile mit „@result{}“ beginnt, zeigt sie das Ergebnis
einer Auswertung, während Zeilen, die mit „@print{}“ beginnen, für eine
angezeigte Ausgabe stehen. Siehe @ref{Using Guile Interactively,,, guile,
das Referenzhandbuch zu GNU Guile} für mehr Details zur REPL.

@itemize
@item
Die Scheme-Syntax ist an sich ein Baum von Ausdrücken (Lisp-Programmierer
nennen sie @emph{symbolische Ausdrücke}, kurz @emph{S-Ausdrücke} bzw.@:
englisch @emph{s-expression}). Ein solcher Ausdruck kann ein Literal sein,
wie z.B.@: Zahlen oder Zeichenketten, oder er kann ein zusammengesetzter
Ausdruck sein, d.h.@: eine geklammerte Liste von zusammengesetzten und
literalen Ausdrücken. Dabei stehen @code{#true} und @code{#false} (abgekürzt
auch @code{#t} und @code{#f}) jeweils für die Booleschen Werte „wahr“ und
„falsch“.

Beispiele für gültige Ausdrücke

@lisp
"Hallo Welt!"
@result{} "Hallo Welt!"

17
@result{} 17

(display (string-append "Hallo " "Guix" "\n"))
@print{} Hallo Guix
@result{} #<unspecified>
@end lisp

@item
Das letzte Beispiel eben ist der Aufruf einer Funktion innerhalb eines
anderen Funktionsaufrufs. Wenn ein geklammerter Ausdruck ausgewertet wird,
ist der erste Term die Funktion und der Rest sind die Argumente, die an die
Funktion übergeben werden. Jede Funktion liefert ihren zuletzt ausgewerteten
Ausdruck als ihren Rückgabewert.

@item
Anonyme Funktionen@tie{}– bzw.@: Prozeduren, wie man in Scheme sagt@tie{}–
werden mit dem @code{lambda}-Term deklariert:

@lisp
(lambda (x) (* x x))
@result{} #<procedure 120e348 at <unknown port>:24:0 (x)>
@end lisp

Die obige Prozedur liefert das Quadrat ihres Arguments. Weil alles ein
Ausdruck ist, liefert der Ausdruck @code{lambda} eine anonyme Prozedur, die
wiederum auf ein Argument angewandt werden kann:

@lisp
((lambda (x) (* x x)) 3)
@result{} 9
@end lisp

Prozeduren sind normale Werte wie Zahlen, Zeichenketten, Boolesche Ausdrücke
und dererlei auch.

@item
Allem kann mit @code{define} ein globaler Name zugewiesen werden:

@lisp
(define a 3)
(define quadrat (lambda (x) (* x x)))
(quadrat a)
@result{} 9
@end lisp

@item
Prozeduren können auch kürzer mit der folgenden Syntax definiert werden:

@lisp
(define (quadrat x) (* x x))
@end lisp

@item
Eine Listenstruktur kann mit der @code{list}-Prozedur erzeugt werden:

@lisp
(list 2 a 5 7)
@result{} (2 3 5 7)
@end lisp

@item
Für die Erzeugung und Verarbeitung von Listen stehen im Modul @code{(srfi
srfi-1)} Standardprozeduren zur Verfügung (siehe @ref{SRFI-1,
Listenverarbeitung,, guile, Referenzhandbuch zu GNU Guile}). Hier ein kurzer
Überblick:

@lisp
(use-modules (srfi srfi-1))  ;Prozeduren zur Listenverarbeitung importieren

(append (list 1 2) (list 3 4))
@result{} (1 2 3 4)

(map (lambda (x) (* x x)) (list 1 2 3 4))
@result{} (1 4 9 16)

(delete 3 (list 1 2 3 4))        @result{} (1 2 4)
(filter odd? (list 1 2 3 4))     @result{} (1 3)
(remove even? (list 1 2 3 4))    @result{} (1 3)
(find number? (list "a" 42 "b")) @result{} 42
@end lisp

Beachten Sie, dass das erste Argument an @code{map}, @code{filter},
@code{remove} und @code{find} eine Prozedur ist!

@item
@cindex symbolischer Ausdruck (S-expression)
Mit dem @dfn{quote}-Zeichen wird das Auswerten eines geklammerten Ausdrucks
abgeschaltet (man spricht dann von einem symbolischen Ausdruck, engl.@:
„S-Expression“ bzw. „S-exp“): Der erste Term wird @emph{nicht} auf den
anderen Termen aufgerufen (siehe @ref{Expression Syntax, quote,, guile,
Referenzhandbuch zu GNU Guile}). Folglich liefert es quasi eine Liste von
Termen.

@lisp
'(display (string-append "Hallo " "Guix" "\n"))
@result{} (display (string-append "Hallo " "Guix" "\n"))

'(2 a 5 7)
@result{} (2 a 5 7)
@end lisp

@item
Mit einem @code{quasiquote}-Zeichen (@code{`}) wird die Auswertung eines
geklammerten Ausdrucks so lange abgeschaltet, bis ein @code{unquote} (ein
Komma) sie wieder aktiviert. Wir können damit genau steuern, was ausgewertet
wird und was nicht.

@lisp
`(2 a 5 7 (2 ,a 5 ,(+ a 4)))
@result{} (2 a 5 7 (2 3 5 7))
@end lisp

Beachten Sie, dass obiges Ergebnis eine Liste verschiedenartiger Elemente
ist: Zahlen, Symbole (in diesem Fall @code{a}) und als letztes Element
selbst wieder eine Liste.

@item
@cindex G-Ausdrücke, Syntax
@cindex Gexps, Syntax
@findex #~
@findex #$
@findex gexp
@findex ungexp
In Guix gibt es außerdem eine aufgeputschte Form von S-Ausdrücken: die
@dfn{G-Ausdrücke} oder „Gexps“, die ihre eigene Art von @code{quasiquote}
und @code{unquote} haben: @code{#~} (oder @code{gexp}) und @code{#$} (oder
@code{ungexp}). Mit Ihnen kennzeichnen Sie, welcher Code @emph{erst später
ausgeführt} werden soll („Code-Staging“).

G-Ausdrücke begegnen Ihnen etwa in manchen Paketdefinitionen, wo sie
eingesetzt werden, damit Code erst bei der Erstellung des Pakets
abläuft. Das sieht so aus:

@lisp
(use-modules (guix gexp)           ;für’s Schreiben von G-Ausdrücken
             (gnu packages base))  ;für 'coreutils'

;; Folgender G-Ausdruck enthält später ausgeführten Code.
#~(begin
    ;; 'ls' aufrufen aus dem Paket, das in der Variablen 'coreutils'
    ;; definiert ist.
    (system* #$(file-append coreutils "/bin/ls") "-l")

    ;; Das Ausgabeverzeichnis des aktuell definierten Pakets anlegen.
    (mkdir #$output))
@end lisp

Siehe @ref{G-Ausdrücke,,, guix.de, Referenzhandbuch zu GNU Guix} für Details
zu G-Ausdrücken.

@item
Mehrere Variable können in einer lokalen Umgebung mit Bezeichnern versehen
werden, indem Sie @code{let} benutzen (siehe @ref{Local Bindings,,, guile,
Referenzhandbuch zu GNU Guile}):

@lisp
(define x 10)
(let ((x 2)
      (y 3))
  (list x y))
@result{} (2 3)

x
@result{} 10

y
@error{} In procedure module-lookup: Unbound variable: y
@end lisp

Benutzen Sie @code{let*}, damit spätere Variablendeklarationen auf frühere
verweisen können.

@lisp
(let* ((x 2)
       (y (* x 3)))
  (list x y))
@result{} (2 6)
@end lisp

@item
Mit @dfn{Schlüsselwörtern} bestimmen wir normalerweise diejenigen Parameter
einer Prozedur, die einen Namen haben sollen. Ihnen wird @code{#:}
(Doppelkreuz und Doppelpunkt) vorangestellt, gefolgt von alphanumerischen
Zeichen: @code{#:etwa-so}. Siehe @ref{Keywords,,, guile, Referenzhandbuch zu
GNU Guile}.

@item
Das Prozentzeichen @code{%} wird in der Regel für globale Variable auf
Erstellungsebene benutzt, auf die nur lesend zugegriffen werden
soll. Beachten Sie, dass es sich dabei nur um eine Konvention handelt,
ähnlich wie @code{_} in C@. Scheme behandelt @code{%} genau wie jedes andere
Zeichen.

@item
Module werden mit Hilfe von @code{define-module} erzeugt (siehe
@ref{Creating Guile Modules,,, guile, Referenzhandbuch zu GNU Guile}). Zum
Beispiel definiert man mit

@lisp
(define-module (guix build-system ruby)
  #:use-module (guix store)
  #:export (ruby-build
            ruby-build-system))
@end lisp

das Modul @code{guix build-system ruby}, das sich unter dem Pfad
@file{guix/build-system/ruby.scm} innerhalb irgendeines Verzeichnisses im
Guile-Ladepfad befinden muss. Es hat eine Abhängigkeit auf das Modul
@code{(guix store)} und exportiert zwei seiner Variablen, @code{ruby-build}
und @code{ruby-build-system}.

Siehe @ref{Paketmodule,,, guix.de, Referenzhandbuch zu GNU Guix} für
Informationen zu Modulen, in denen Pakete definiert werden.
@end itemize

@quotation Vertiefung
Die Sprache Scheme wurde oft eingesetzt, um Programmieren beizubringen,
daher gibt es ein breites Angebot an Lehrmaterialien, die sie als
Transportmittel einsetzen. Hier sehen Sie eine Auswahl solcher Dokumente,
mit denen Sie mehr über Scheme erfahren können:

@itemize
@item
@uref{https://spritely.institute/news/ein-scheme-primer.html, @i{Ein
Scheme-Primer}}, von Christine Lemmer-Webber und dem Spritely Institute, auf
Deutsch übersetzt von Florian Pelz.

@item
@c There used to be a copy at mitpress.mit.edu but it vanished.
Eines der Referenzbücher zu Scheme ist das einflussreiche „Structure and
Interpretation of Computer Programs“, von Harold Abelson und Gerald Jay
Sussman, mit Julie Sussman. Eine deutsche Übersetzung „Struktur und
Interpretation von Computerprogrammen“ hat Susanne Daniels-Herold
verfasst. Vom englischen Original finden Sie eine
@uref{https://sarabander.github.io/sicp/, kostenlose Ausgabe online}. Viele
kennen es unter dem Akronym SICP.

Das Buch können Sie auch installieren und von Ihrem Rechner aus lesen:

@example
guix install book-sicp info-reader
info sicp
@end example

@end itemize

Sie finden noch mehr Bücher, Anleitungen und andere Ressourcen auf
@url{https://schemers.org/}.
@end quotation


@c *********************************************************************
@node Pakete schreiben
@chapter Pakete schreiben

@cindex Pakete schreiben

In diesem Kapitel bringen wir Ihnen bei, wie Sie Pakete zur mit GNU Guix
ausgelieferten Paketsammlung beitragen. Dazu gehört, Paketdefinitionen in
Guile Scheme zu schreiben, sie in Paketmodulen zu organisieren und sie zu
erstellen.

@menu
* Anleitung zum Paketeschreiben::  Eine Anleitung, wie Sie Pakete zu Guix 
                                     hinzufügen.
* Packaging Workflows::      Real life examples on working with specific 
                               build systems.
@end menu

@node Anleitung zum Paketeschreiben
@section Anleitung zum Paketeschreiben

GNU Guix zeichnet sich in erster Linie deswegen als das @emph{hackbare}
Paketverwaltungswerkzeug aus, weil es mit
@uref{https://www.gnu.org/software/guile/, GNU Guile} arbeitet, einer
mächtigen, hochsprachlichen Programmiersprache, die einen der Dialekte von
@uref{https://de.wikipedia.org/wiki/Scheme, Scheme} darstellt. Scheme
wiederum gehört zur @uref{https://de.wikipedia.org/wiki/Lisp, Lisp-Familie
von Programmiersprachen}.

Paketdefinitionen werden ebenso in Scheme geschrieben, wodurch Guix auf sehr
einzigartige Weise mächtiger wird als die meisten anderen
Paketverwaltungssysteme, die Shell-Skripte oder einfache Sprachen benutzen.

@itemize
@item
Sie können sich Funktionen, Strukturen, Makros und all die Ausdrucksstärke
von Scheme für Ihre Paketdefinitionen zu Nutze machen.

@item
Durch Vererbung können Sie ohne viel Aufwand ein Paket anpassen, indem Sie
von ihm erben lassen und nur das Nötige abändern.

@item
Stapelverarbeitung („batch mode“) wird möglich; die ganze Paketsammlung kann
analysiert, gefiltert und verarbeitet werden. Versuchen Sie, ein
Serversystem ohne Bildschirm („headless“) auch tatsächlich von allen
Grafikschnittstellen zu befreien? Das ist möglich. Möchten Sie alles von
Neuem aus seinem Quellcode erstellen, aber mit eingeschalteten besonderen
Compileroptimierungen? Übergeben Sie einfach das passende @code{#:make-flags
"..."}-Argument an die Paketliste. Es wäre nicht übertrieben, hier an die
@uref{https://wiki.gentoo.org/wiki/USE_flag, USE-Optionen von Gentoo} zu
denken, aber das hier übertrifft sie: Der Paketautor muss vorher gar nicht
darüber nachgedacht haben, der Nutzer kann sie selbst @emph{programmieren}!
@end itemize

Die folgende Anleitung erklärt alles Grundlegende über das Schreiben von
Paketen mit Guix. Dabei setzen wir kein großes Wissen über das Guix-System
oder die Lisp-Sprache voraus. Vom Leser wird nur erwartet, dass er mit der
Befehlszeile vertraut ist und über grundlegende Programmierkenntnisse
verfügt.

@menu
* Ein Hallo-Welt-Paket::     Ein Hallo-Welt-Paket
* Herangehensweisen::        Herangehensweisen
* Erweitertes Beispiel::     Erweitertes Beispiel
* Andere Erstellungssysteme::  Andere Erstellungssysteme
* Programmierbare und automatisierte Paketdefinition::  Programmierbare und 
                                                          automatisierte 
                                                          Paketdefinition
* Hilfe bekommen::           Hilfe bekommen
* Schlusswort::              Schlusswort
* Literaturverzeichnis::     Literaturverzeichnis
@end menu

@node Ein Hallo-Welt-Paket
@subsection Ein Hallo-Welt-Paket

Der Abschnitt „Pakete definieren“ im Handbuch führt in die Grundlagen des
Paketschreibens für Guix ein (siehe @ref{Pakete definieren,,, guix.de,
Referenzhandbuch zu GNU Guix}). Im folgenden Abschnitt werden wir diese
Grundlagen teilweise rekapitulieren.

GNU@tie{}Hello ist ein Projekt, das uns als Stellvertreter für „richtige“
Projekte und allgemeines Beispiel für das Schreiben von Paketen dient. Es
verwendet das GNU-Erstellungssystem (@code{./configure && make && make
install}). Guix stellt uns schon eine Paketdefinition zur Verfügung, die uns
einen perfekten Ausgangspunkt bietet. Sie können sich ihre Deklaration
anschauen, indem Sie @code{guix edit hello} von der Befehlszeile
ausführen. Schauen wir sie uns an:

@lisp
(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)
    (synopsis "Hello, GNU world: An example GNU package")
    (description
     "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))
@end lisp

Wie Sie sehen können, ist das meiste klar strukturiert. Aber sehen wir uns
die Felder zusammen an:

@table @samp
@item name
Der Name des Projekts. Wir halten uns an die Konventionen von Scheme und
bevorzugen deshalb Kleinschreibung ohne Unterstriche, sondern mit
Bindestrichen zwischen den Wörtern.

@item source
Dieses Feld enthält eine Beschreibung, was der Ursprung des Quellcodes
ist. Das @code{origin}-Verbundsobjekt enthält diese Felder:

@enumerate
@item Die Methode. Wir verwenden hier @code{url-fetch}, um über HTTP/FTP herunterzuladen,
    aber es gibt auch andere Methoden wie @code{git-fetch} für Git-Repositorys.
@item Die URI, welche bei @code{url-fetch} normalerweise eine Ortsangabe mit @code{https://} ist.
    In diesem Fall verweist die besondere URI ‚mirror://gnu‘ auf eine von
mehreren wohlbekannten Ortsangaben, von denen Guix jede durchprobieren kann,
um den Quellcode herunterzuladen, wenn es bei manchen davon nicht klappt.
@item Die @code{sha256}-Prüfsumme der angefragten Datei.
    Sie ist notwendig, damit sichergestellt werden kann, dass der Quellcode
nicht beschädigt ist. Beachten Sie, dass Guix mit Zeichenketten in
Base32-Kodierung arbeitet, weshalb wir die @code{base32}-Funktion aufrufen.
@end enumerate

@item build-system

Hier glänzt Schemes Fähigkeit zur Abstraktion: In diesem Fall abstrahiert
@code{gnu-build-system} die berühmten Schritte @code{./configure && make &&
make install}, die sonst in der Shell aufgerufen würden. Zu den anderen
Erstellungssystemen gehören das @code{trivial-build-system}, das nichts tut
und dem Paketautoren das Schreiben sämtlicher Erstellungsschritte
abverlangt, das @code{python-build-system}, das @code{emacs-build-system},
und viele mehr (siehe @ref{Erstellungssysteme,,, guix.de, Referenzhandbuch
zu GNU Guix}).

@item synopsis
Die Zusammenfassung. Sie sollte eine knappe Beschreibung sein, was das Paket
tut. Für viele Pakete findet sich auf der Homepage ein Einzeiler, der als
Zusammenfassung benutzt werden kann.

@item description
Genau wie bei der Zusammenfassung ist es in Ordnung, die Beschreibung des
Projekts für das Paket wiederzuverwenden. Beachten Sie, dass Guix dafür
Texinfo-Syntax verlangt.

@item home-page
Hier soll möglichst HTTPS benutzt werden.

@item license
Siehe die vollständige Liste verfügbarer Lizenzen in
@code{guix/licenses.scm} im Guix-Quellcode.
@end table

Es wird Zeit, unser erstes Paket zu schreiben! Aber noch nichts tolles, wir
bleiben bei einem Paket @code{my-hello} stelltvertretend für „richtige“
Software; es ist eine Kopie obiger Deklaration.

Genau wie beim Ritual, Neulinge in Programmiersprachen „Hallo Welt“
schreiben zu lassen, fangen wir mit der vielleicht „arbeitsintensivsten“
Herangehensweise ans Paketeschreiben an. Wir kümmern uns später darum, wie
man am besten an Paketen arbeitet; erst einmal nehmen wir den einfachsten
Weg.

Speichern Sie den folgenden Code in eine Datei @file{my-hello.scm}.

@lisp
(use-modules (guix packages)
             (guix download)
             (guix build-system gnu)
             (guix licenses))

(package
  (name "my-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)
  (synopsis "Hello, Guix world: An example custom Guix package")
  (description
   "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
  (home-page "https://www.gnu.org/software/hello/")
  (license gpl3+))
@end lisp

Wir erklären den zusätzlichen Code in Kürze.

Spielen Sie ruhig mit unterschiedlichen Werten für die verschiedenen Felder
herum. Wenn Sie den Quellort (die „source“) ändern, müssen Sie die Prüfsumme
aktualisieren. Tatsächlich weigert sich Guix, etwas zu erstellen, wenn die
angegebene Prüfsumme nicht zu der berechneten Prüfsumme des Quellcodes
passt. Um die richtige Prüfsumme für die Paketdeklaration zu finden, müssen
wir den Quellcode herunterladen, die SHA256-Summe davon berechnen und sie in
Base32 umwandeln.

Glücklicherweise kann Guix diese Aufgabe automatisieren; wir müssen
lediglich die URI übergeben.

@c TRANSLATORS: This is example shell output.
@example sh
$ guix download mirror://gnu/hello/hello-2.10.tar.gz

Starting download of /tmp/guix-file.JLYgL7
From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
following redirection to `https://mirror.ibcp.fr/pub/gnu/hello/hello-2.10.tar.gz'...
 …10.tar.gz  709KiB                                 2.5MiB/s 00:00 [##################] 100.0%
/gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
@end example

In diesem speziellen Fall sagt uns die Ausgabe, welcher Spiegelserver
ausgewählt wurde. Wenn das Ergebnis des obigen Befehls nicht dasselbe ist
wie im Codeschnipsel, dann aktualisieren Sie Ihre
@code{my-hello}-Deklaration entsprechend.

Beachten Sie, dass Tarball-Archive von GNU-Paketen mit einer
OpenPGP-Signatur ausgeliefert werden, deshalb sollten Sie mit Sicherheit die
Signatur dieses Tarballs mit „gpg“ überprüfen, um ihn zu authentifizieren,
bevor Sie weitermachen.

@c TRANSLATORS: This is example shell output.
@example sh
$ guix download mirror://gnu/hello/hello-2.10.tar.gz.sig

Starting download of /tmp/guix-file.03tFfb
From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz.sig...
following redirection to `https://ftp.igh.cnrs.fr/pub/gnu/hello/hello-2.10.tar.gz.sig'...
 ….tar.gz.sig  819B                                                                                                                       1.2MiB/s 00:00 [##################] 100.0%
/gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig
0q0v86n3y38z17rl146gdakw9xc4mcscpk8dscs412j22glrv9jf
$ gpg --verify /gnu/store/rzs8wba9ka7grrmgcpfyxvs58mly0sx6-hello-2.10.tar.gz.sig /gnu/store/hbdalsf5lpf01x4dcknwx6xbn6n5km6k-hello-2.10.tar.gz
gpg: Signatur vom So 16 Nov 2014 13:08:37 CET
gpg:                mittels RSA-Schlüssel A9553245FDE9B739
gpg: Korrekte Signatur von "Sami Kerola (https://www.iki.fi/kerolasa/) <kerolasa@@iki.fi>" [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck  = 8ED3 96E3 7E38 D471 A005  30D3 A955 3245 FDE9 B739
@end example

Sie können dann unbesorgt das hier ausführen:

@c TRANSLATORS: Do not translate this command
@example sh
$ guix package --install-from-file=my-hello.scm
@end example

Nun sollte @code{my-hello} in Ihrem Profil enthalten sein!

@c TRANSLATORS: Do not translate this command
@example sh
$ guix package --list-installed=my-hello
my-hello	2.10	out
/gnu/store/f1db2mfm8syb8qvc357c53slbvf1g9m9-my-hello-2.10
@end example

Wir sind so weit gekommen, wie es ohne Scheme-Kenntnisse möglich ist. Bevor
wir mit komplexeren Paketen weitermachen, ist jetzt der Zeitpunkt gekommen,
Ihr Wissen über Scheme zu entstauben. Siehe @ref{Ein Schnellkurs in Scheme}
für eine Auffrischung.

@node Herangehensweisen
@subsection Herangehensweisen

Im Rest dieses Kapitels setzen wir ein paar grundlegende
Scheme-Programmierkenntnisse voraus. Wir wollen uns nun verschiedene
mögliche Herangehensweisen anschauen, wie man an Guix-Paketen arbeiten kann.

Es gibt mehrere Arten, eine Umgebung zum Paketeschreiben aufzusetzen.

Unsere Empfehlung ist, dass Sie direkt am Checkout des Guix-Quellcodes
arbeiten, weil es dann für alle einfacher ist, zu Guix beizutragen.

Werfen wir aber zunächst einen Blick auf andere Möglichkeiten.

@menu
* Lokale Datei::             Lokale Datei
* Kanäle::                   Kanäle
* Direkt am Checkout hacken::  Direkt am Checkout hacken
@end menu

@node Lokale Datei
@subsubsection Lokale Datei

Diese Methode haben wir zuletzt für @samp{my-hello} benutzt. Jetzt nachdem
wir uns mit den Scheme-Grundlagen befasst haben, können wir uns den Code am
Anfang erklären. @code{guix package --help} sagt uns:

@example
  -f, --install-from-file=DATEI
                         das Paket installieren, zu dem der Code in der DATEI
                           ausgewertet wird
@end example

Daher @emph{muss} der letzte Ausdruck ein Paket liefern, was im vorherigen
Beispiel der Fall ist.

Der Ausdruck @code{use-modules} sagt aus, welche Module in der Datei
gebraucht werden. Module sind eine Sammlung aus Werten und Prozeduren. In
anderen Programmiersprachen werden sie oft „Bibliotheken“ oder „Pakete“
genannt.

@node Kanäle
@subsubsection Kanäle

@cindex Kanal
Guix und seine Paketsammlung können durch @dfn{Kanäle} (englisch: Channels)
erweitert werden. Ein Kanal ist ein Git-Repository, öffentlich oder nicht,
das @file{.scm}-Dateien enthält, die Pakete (siehe @ref{Pakete definieren,,,
guix.de, Referenzhandbuch zu GNU Guix}) oder Dienste (siehe @ref{Dienste
definieren,,, guix.de, Referenzhandbuch zu GNU Guix}) bereitstellen.

Wie würden Sie einen Kanal erstellen? Erstellen Sie zunächst ein
Verzeichnis, das Ihre @file{.scm}-Dateien enthalten wird, beispielsweise
@file{~/my-channel}:

@example
mkdir ~/my-channel
@end example

Angenommen, Sie möchten das Paket @samp{my-hello}, das wir zuvor gesehen
haben, hinzufügen; es bedarf zunächst einiger Anpassungen:

@lisp
(define-module (my-hello)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix build-system gnu)
  #:use-module (guix download))

(define-public my-hello
  (package
    (name "my-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)
    (synopsis "Hello, Guix world: An example custom Guix package")
    (description
     "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))
@end lisp

Beachten Sie, dass wir den Paketwert einer exportierten Variablen mit
@code{define-public} zugewiesen haben. Das bedeutet, das Paket wird einer
Variablen @code{my-hello} zugewiesen, damit darauf verwiesen werden
kann. Unter anderem kann es dadurch als Abhängigkeit anderer Pakete
verwendet werden.

Wenn Sie @code{guix package --install-from-file=my-hello.scm} auf der obigen
Datei aufrufen, geht es schief, weil der letzte Ausdruck,
@code{define-public}, kein Paket zurückliefert. Wenn Sie trotzdem
@code{define-public} für jene Herangehensweise verwenden möchten, stellen
Sie sicher, dass am Ende der Datei eine Auswertung von @code{my-hello}
steht:

@lisp
;; …
(define-public my-hello
  ;; …
  )

my-hello
@end lisp

Meistens tut man das aber nicht.

Wie machen Sie nun dieses Paket für @command{guix}-Befehle sichtbar, damit
Sie Ihre Pakete testen können? Sie müssen das Verzeichnis mit der
Befehlszeilenoption @option{-L} zum Suchpfad hinzufügen, wie in diesen
Beispielen:

@example
guix show -L ~/my-channel my-hello
guix build -L ~/my-channel my-hello
@end example

Der letzte Schritt besteht darin, @file{~/my-channel} in einen echten Kanal
zu verwandeln, so dass Ihre Paketsammlung nahtlos mit jedem
@command{guix}-Befehl zur Verfügung steht. Dazu müssen Sie es zunächst zu
einem Git-Repository machen:

@example
cd ~/my-channel
git init
git add my-hello.scm
git commit -m "Erster Commit meines Kanals."
@end example

Und das war’s, Sie haben einen Kanal! Von nun an können Sie diesen Kanal zu
Ihrer Kanalkonfiguration in @file{~/.config/guix/channels.scm} hinzufügen
(siehe @ref{Weitere Kanäle angeben,,, guix.de, Referenzhandbuch zu GNU
Guix}). Unter der Annahme, dass Sie Ihren Kanal vorerst lokal halten, würde
die @file{channels.scm} etwa so aussehen:

@lisp
(append (list (channel
                (name 'my-channel)
                (url (string-append "file://" (getenv "HOME")
                                    "/my-channel"))))
        %default-channels)
@end lisp

Wenn Sie das nächste Mal @command{guix pull} ausführen, wird Ihr Kanal
aufgenommen und die darin definierten Pakete stehen allen
@command{guix}-Befehlen zur Verfügung, auch wenn Sie @option{-L} nicht
übergeben. Der Befehl @command{guix describe} wird zeigen, dass Guix
tatsächlich sowohl den Kanal @code{my-channel} als auch den
@code{guix}-Kanal benutzt.

Siehe @ref{Einen Kanal erstellen,,, guix.de, Referenzhandbuch zu GNU Guix}
für Details.

@node Direkt am Checkout hacken
@subsubsection Direkt am Checkout hacken

Es wird empfohlen, direkt am Code des Guix-Projekts zu arbeiten, weil Ihre
Änderungen dann später mit weniger Schwierigkeiten bei uns eingereicht
werden können, damit Ihre harte Arbeit der Gemeinschaft nützt!

Anders als die meisten Software-Distributionen werden bei Guix sowohl
Werkzeuge (einschließlich des Paketverwaltungsprogramms) als auch die
Paketdefinitionen in einem Repository gespeichert. Der Grund für diese
Entscheidung war, dass Entwickler die Freiheit haben sollten, die
Programmierschnittstelle (API) zu ändern, ohne Inkompatibilitäten
einzuführen, indem alle Pakete gleichzeitig mit der API aktualisiert
werden. Dadurch wird die Entwicklung weniger träge.

Legen Sie ein Checkout des offiziellen @uref{https://git-scm.com/,
Git-Repositorys} an:

@example
$ git clone https://git.guix.gnu.org/guix.git
@end example

Im Rest dieses Artikels schreiben wir @samp{$GUIX_CHECKOUT}, wenn wir den
Ort meinen, an dem das Checkout gespeichert ist.


Folgen Sie den Anweisungen im Handbuch (siehe (@ref{Mitwirken,,, guix.de,
Referenzhandbuch zu GNU Guix}), um die nötige Umgebung für die Nutzung des
Repositorys herzustellen.

Sobald sie hergestellt wurde, sollten Sie die Paketdefinitionen aus der
Repository-Umgebung benutzen können.

Versuchen Sie sich ruhig daran, die Paketdefinitionen zu editieren, die Sie
in @samp{$GUIX_CHECKOUT/gnu/packages} finden.

Das Skript @samp{$GUIX_CHECKOUT/pre-inst-env} ermöglicht es Ihnen,
@samp{guix} auf der Paketsammlung des Repositorys aufzurufen (siehe
@ref{Guix vor der Installation ausführen,,, guix.de, Referenzhandbuch zu GNU
Guix}).

@itemize
@item
So suchen Sie Pakete, z.B.@: Ruby:

@example
  $ cd $GUIX_CHECKOUT
  $ ./pre-inst-env guix package --list-available=ruby
      ruby    1.8.7-p374      out     gnu/packages/ruby.scm:119:2
      ruby    2.1.6   out     gnu/packages/ruby.scm:91:2
      ruby    2.2.2   out     gnu/packages/ruby.scm:39:2
@end example

@item
Erstellen Sie ein Paket, z.B.@: Ruby in Version 2.1:

@example
  $ ./pre-inst-env guix build --keep-failed ruby@@2.1
  /gnu/store/c13v73jxmj2nir2xjqaz5259zywsa9zi-ruby-2.1.6
@end example

@item
Installieren Sie es in Ihr Profil:

@example
  $ ./pre-inst-env guix package --install ruby@@2.1
@end example

@item
Prüfen Sie auf häufige Fehler:

@example
  $ ./pre-inst-env guix lint ruby@@2.1
@end example
@end itemize

Guix ist bestrebt, einen hohen Standard an seine Pakete anzusetzen. Wenn Sie
Beiträge zum Guix-Projekt leisten,

@itemize
@item
schreiben Sie Ihren Code im Stil von Guix (siehe @ref{Programmierstil,,,
guix.de, Referenzhandbuch zu GNU Guix})
@item
und schauen Sie sich die Kontrollliste aus dem Handbuch (siehe
@ref{Einreichen von Patches,,, guix.de, Referenzhandbuch zu GNU Guix}) noch
einmal an.
@end itemize

Sobald Sie mit dem Ergebnis zufrieden sind, freuen wir uns, wenn Sie Ihren
Beitrag an uns schicken, damit wir ihn in Guix aufnehmen. Dieser Prozess
wird auch im Handbuch beschrieben (siehe @ref{Mitwirken,,, guix.de,
Referenzhandbuch zu GNU Guix})<.


Es handelt sich um eine gemeinschaftliche Arbeit, je mehr also mitmachen,
desto besser wird Guix!

@node Erweitertes Beispiel
@subsection Erweitertes Beispiel

Einfacher als obiges Hallo-Welt-Beispiel wird es nicht. Pakete können auch
komplexer als das sein und Guix eignet sich für fortgeschrittenere
Szenarien. Schauen wir uns ein anderes, umfangreicheres Paket an (leicht
modifiziert gegenüber Guix’ Quellcode):

@lisp
(define-module (gnu packages version-control)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix utils)
  #:use-module (guix packages)
  #:use-module (guix git-download)
  #:use-module (guix build-system cmake)
  #:use-module (gnu packages)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages ssh)
  #:use-module (gnu packages tls)
  #:use-module (gnu packages web))

(define-public my-libgit2
  (let ((commit "e98d0a37c93574d2c6107bf7f31140b548c6a7bf")
        (revision "1"))
    (package
      (name "my-libgit2")
      (version (git-version "0.26.6" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "https://github.com/libgit2/libgit2/")
                      (commit commit)))
                (file-name (git-file-name name version))
                (sha256
                 (base32
                  "17pjvprmdrx4h6bb1hhc98w9qi6ki7yl57f090n9kbhswxqfs7s3"))
                (patches (search-patches "libgit2-mtime-0.patch"))
                (modules '((guix build utils)))
                ;; Gebündelte Software entfernen wir.
                (snippet '(delete-file-recursively "deps"))))
      (build-system cmake-build-system)
      (outputs '("out" "debug"))
      (arguments
       `(#:tests? #true                         ;Testkatalog ausführen (wie ohnehin vorgegeben)
         #:configure-flags '("-DUSE_SHA1DC=ON") ;Kollisionserkennung für SHA-1 aktivieren
         #:phases
         (modify-phases %standard-phases
           (add-after 'unpack 'fix-hardcoded-paths
             (lambda _
               (substitute* "tests/repo/init.c"
                 (("#!/bin/sh") (string-append "#!" (which "sh"))))
               (substitute* "tests/clar/fs.h"
                 (("/bin/cp") (which "cp"))
                 (("/bin/rm") (which "rm")))))
           ;; Ausführliche Testausgaben einschalten.
           (replace 'check
             (lambda* (#:key tests? #:allow-other-keys)
               (when tests?
                 (invoke "./libgit2_clar" "-v" "-Q"))))
           (add-after 'unpack 'make-files-writable-for-tests
             (lambda _ (for-each make-file-writable (find-files ".")))))))
      (inputs
       (list libssh2 http-parser python-wrapper))
      (native-inputs
       (list pkg-config))
      (propagated-inputs
       ;; Weil diese zwei Bibliotheken unter 'Requires.private' in libgit2.pc stehen.
       (list openssl zlib))
      (home-page "https://libgit2.github.com/")
      (synopsis "Library providing Git core methods")
      (description
       "Libgit2 is a portable, pure C implementation of the Git core methods
provided as a re-entrant linkable library with a solid API, allowing you to
write native speed custom Git applications in any language with bindings.")
      ;; Wir schreiben als Kommentar, dass es eigentlich die GPL2 mit Ausnahmen ist:
      ;; GPLv2 with linking exception
      (license license:gpl2))))
@end lisp

(In solchen Fällen, wo Sie nur ein paar wenige Felder einer Paketdefinition
abändern wollen, wäre es wirklich besser, wenn Sie Vererbung einsetzen
würden, statt alles abzuschreiben. Siehe unten.)

Reden wir über diese Felder im Detail.

@subsubsection @code{git-fetch}-Methode

Anders als die @code{url-fetch}-Methode erwartet @code{git-fetch} eine
@code{git-reference}, welche ein Git-Repository und einen Commit
entgegennimmt. Der Commit kann eine beliebige Art von Git-Referenz sein,
z.B.@: ein Tag. Wenn die @code{version} also mit einem Tag versehen ist,
kann sie einfach benutzt werden. Manchmal ist dem Tag ein Präfix @code{v}
vorangestellt. In diesem Fall würden Sie @code{(commit (string-append "v"
version))} schreiben.

Um sicherzustellen, dass der Quellcode aus dem Git-Repository in einem
Verzeichnis mit nachvollziehbarem Namen landet, schreiben wir
@code{(file-name (git-file-name name version))}.

Mit der Prozedur @code{git-version} kann die Version beim Paketieren eines
bestimmten Commits eines Programms entsprechend den Richtlinien für Beiträge
zu Guix (@pxref{Versionsnummern,,, guix.de, Referenzhandbuch zu GNU Guix})
abgeleitet werden.

Sie fragen, woher man den darin angegebenen @code{sha256}-Hash bekommt?
Indem Sie @command{guix hash} auf einem Checkout des gewünschten Commits
aufrufen, ungefähr so:

@example
git clone https://github.com/libgit2/libgit2/
cd libgit2
git checkout v0.26.6
guix hash -rx .
@end example

@command{guix hash -rx} berechnet einen SHA256-Hash des gesamten
Verzeichnisses, abgesehen vom @file{.git}-Unterverzeichnis (siehe
@ref{Aufruf von guix hash,,, guix.de, Referenzhandbuch zu GNU Guix}).

In Zukunft wird @command{guix download} diese Schritte hoffentlich für Sie
erledigen können, genau wie es das für normales Herunterladen macht.

@subsubsection Schnipsel

„Snippets“, deutsch Schnipsel, sind mit z.B.@: @code{quote}-Zeichen
maskierte, also nicht ausgewertete, Stücke Scheme-Code, mit denen der
Quellcode gepatcht wird. Sie sind eine guixige Alternative zu traditionellen
@file{.patch}-Dateien. Wegen der Maskierung werden sie erst dann
ausgewertet, wenn sie an den Guix-Daemon zum Erstellen übergeben werden. Es
kann so viele Schnipsel geben wie nötig.

In Schnipseln könnten zusätzliche Guile-Module benötigt werden. Diese können
importiert werden, indem man sie im Feld @code{modules} angibt.

@subsubsection Eingaben

Es gibt 3 verschiedene Arten von Eingaben. Kurz gefasst:

@table @asis
@item native-inputs
Sie werden zum Erstellen gebraucht, aber @emph{nicht} zur Laufzeit@tie{}–
wenn Sie ein Paket als Substitut installieren, werden diese Eingaben
nirgendwo installiert.
@item inputs
Sie werden in den Store installiert, aber nicht in das Profil, und sie
stehen beim Erstellen zur Verfügung.
@item propagated-inputs
Sie werden sowohl in den Store als auch ins Profil installiert und sind auch
beim Erstellen verfügbar.
@end table

Siehe @ref{„package“-Referenz,,, guix.de, Referenzhandbuch zu GNU Guix} für
mehr Details.

Der Unterschied zwischen den verschiedenen Eingaben ist wichtig: Wenn eine
Abhängigkeit als @code{input} statt als @code{propagated-input} ausreicht,
dann sollte sie auch so eingeordnet werden, sonst „verschmutzt“ sie das
Profil des Benutzers ohne guten Grund.

Wenn eine Nutzerin beispielsweise ein grafisches Programm installiert, das
von einem Befehlszeilenwerkzeug abhängt, sie sich aber nur für den
grafischen Teil interessiert, dann sollten wir sie nicht zur Installation
des Befehlszeilenwerkzeugs in ihr Benutzerprofil zwingen. Um die
Abhängigkeit sollte sich das Paket kümmern, nicht seine Benutzerin. Mit
@emph{Inputs} können wir Abhängigkeiten verwenden, wo sie gebraucht werden,
ohne Nutzer zu belästigen, indem wir ausführbare Dateien (oder Bibliotheken)
in deren Profil installieren.

Das Gleiche gilt für @emph{native-inputs}: Wenn das Programm einmal
installiert ist, können Abhängigkeiten zur Erstellungszeit gefahrlos dem
Müllsammler anvertraut werden. Sie sind auch besser, wenn ein Substitut
verfügbar ist, so dass nur die @code{inputs} und @code{propagated-inputs}
heruntergeladen werden; @code{native-inputs} braucht niemand, der das Paket
aus einem Substitut heraus installiert.

@quotation Anmerkung
Vielleicht bemerken Sie hier und da Schnipsel, deren Paketeingaben recht
anders geschrieben wurden, etwa so:

@lisp
;; Der „alte Stil“ von Eingaben.
(inputs
 `(("libssh2" ,libssh2)
   ("http-parser" ,http-parser)
   ("python" ,python-wrapper)))
@end lisp

Früher hatte man Eingaben in diesem „alten Stil“ geschrieben, wo jede
Eingabe ausdrücklich mit einer Bezeichnung (als Zeichenkette) assoziiert
wurde. Er wird immer noch unterstützt, aber wir empfehlen, dass Sie
stattdessen im weiter oben gezeigten Stil schreiben. Siehe
@ref{„package“-Referenz,,, guix.de, Referenzhandbuch zu GNU Guix} für mehr
Informationen.
@end quotation

@subsubsection Ausgaben

Genau wie ein Paket mehrere Eingaben haben kann, kann es auch mehrere
Ausgaben haben.

Jede Ausgabe entspricht einem anderen Verzeichnis im Store.

Die Benutzerin kann sich entscheiden, welche Ausgabe sie installieren will;
so spart sie Platz auf dem Datenträger und verschmutzt ihr Benutzerprofil
nicht mit unerwünschten ausführbaren Dateien oder Bibliotheken.

Nach Ausgaben zu trennen ist optional. Wenn Sie kein @code{outputs}-Feld
schreiben, heißt die standardmäßige und einzige Ausgabe (also das ganze
Paket) schlicht @code{"out"}.

Typische Namen für getrennte Ausgaben sind @code{debug} und @code{doc}.

Es wird empfohlen, getrennte Ausgaben nur dann anzubieten, wenn Sie gezeigt
haben, dass es sich lohnt, d.h.@: wenn die Ausgabengröße signifikant ist
(vergleichen Sie sie mittels @code{guix size}) oder das Paket modular
aufgebaut ist.

@subsubsection Argumente ans Erstellungssystem

@code{arguments} ist eine Liste aus Schlüsselwort-Wert-Paaren (eine
„keyword-value list“), mit denen der Erstellungsprozess konfiguriert wird.

Das einfachste Argument @code{#:tests?} kann man benutzen, um den
Testkatalog bei der Erstellung des Pakets nicht zu prüfen. Das braucht man
meistens dann, wenn das Paket überhaupt keinen Testkatalog hat. Wir
empfehlen sehr, den Testkatalog zu benutzen, wenn es einen gibt.

Ein anderes häufiges Argument ist @code{:make-flags}, was eine Liste an den
@code{make}-Aufruf anzuhängender Befehlszeilenargumente festlegt, so wie Sie
sie auf der Befehlszeile angeben würden. Zum Beispiel werden die folgenden
@code{:make-flags}

@lisp
#:make-flags (list (string-append "prefix=" (assoc-ref %outputs "out"))
                   "CC=gcc")
@end lisp

übersetzt zu

@example
$ make CC=gcc prefix=/gnu/store/...-<out>
@end example

Dadurch wird als C-Compiler @code{gcc} verwendet und als
@code{prefix}-Variable (das Installationsverzeichnis in der Sprechweise von
Make) wird @code{(assoc-ref %outputs "out")} verwendet, also eine globale
Variable der Erstellungsschicht, die auf das Zielverzeichnis im Store
verweist (so etwas wie @file{/gnu/store/…-my-libgit2-20180408}).

Auf gleiche Art kann man auch die Befehlszeilenoptionen für configure
festlegen:

@lisp
#:configure-flags '("-DUSE_SHA1DC=ON")
@end lisp

Die Variable @code{%build-inputs} wird auch in diesem Sichtbarkeitsbereich
erzeugt. Es handelt sich um eine assoziative Liste, die von den Namen der
Eingaben auf ihre Verzeichnisse im Store abbildet.

Das @code{phases}-Schlüsselwort listet der Reihe nach die vom
Erstellungssystem durchgeführten Schritte auf. Zu den üblichen Phasen
gehören @code{unpack}, @code{configure}, @code{build}, @code{install} und
@code{check}. Um mehr über diese Phasen zu lernen, müssen Sie sich die
Definition des zugehörigen Erstellungssystems in
@samp{$GUIX_CHECKOUT/guix/build/gnu-build-system.scm} anschauen:

@lisp
(define %standard-phases
  ;; Standard build phases, as a list of symbol/procedure pairs.
  (let-syntax ((phases (syntax-rules ()
                         ((_ p ...) `((p . ,p) ...)))))
    (phases set-SOURCE-DATE-EPOCH set-paths install-locale unpack
            bootstrap
            patch-usr-bin-file
            patch-source-shebangs configure patch-generated-file-shebangs
            build check install
            patch-shebangs strip
            validate-runpath
            validate-documentation-location
            delete-info-dir-file
            patch-dot-desktop-files
            make-dynamic-linker-cache
            install-license-files
            reset-gzip-timestamps
            compress-documentation)))
@end lisp

Alternativ auf einer REPL:

@lisp
(add-to-load-path "/pfad/zum/guix/checkout")
,use (guix build gnu-build-system)
(map car %standard-phases)
@result{} (set-SOURCE-DATE-EPOCH set-paths install-locale unpack bootstrap patch-usr-bin-file patch-source-shebangs configure patch-generated-file-shebangs build check install patch-shebangs strip validate-runpath validate-documentation-location delete-info-dir-file patch-dot-desktop-files make-dynamic-linker-cache install-license-files reset-gzip-timestamps compress-documentation)
@end lisp

Wenn Sie mehr darüber wissen wollen, was in diesen Phasen passiert, schauen
Sie in den jeweiligen Prozeduren.

Beispielsweise sieht momentan, als dies hier geschrieben wurde, die
Definition von @code{unpack} für das GNU-Erstellungssystem so aus:

@lisp
(define* (unpack #:key source #:allow-other-keys)
  "Unpack SOURCE in the working directory, and change directory within the
source.  When SOURCE is a directory, copy it in a sub-directory of the current
working directory."
  (if (file-is-directory? source)
      (begin
        (mkdir "source")
        (chdir "source")

        ;; Preserve timestamps (set to the Epoch) on the copied tree so that
        ;; things work deterministically.
        (copy-recursively source "."
                          #:keep-mtime? #t)
        ;; Make the source checkout files writable, for convenience.
        (for-each (lambda (f)
                    (false-if-exception (make-file-writable f)))
                  (find-files ".")))
      (begin
        (cond
         ((string-suffix? ".zip" source)
          (invoke "unzip" source))
         ((tarball? source)
          (invoke "tar" "xvf" source))
         (else
          (let ((name (strip-store-file-name source))
                (command (compressor source)))
            (copy-file source name)
            (when command
              (invoke command "--decompress" name)))))
        ;; Attempt to change into child directory.
        (and=> (first-subdirectory ".") chdir))))
@end lisp

Beachten Sie den Aufruf von @code{chdir}: Damit wird das Arbeitsverzeichnis
zu demjenigen gewechselt, wohin die Quelldateien entpackt wurden. In jeder
Phase nach @code{unpack} dient also das Verzeichnis mit den Quelldateien als
Arbeitsverzeichnis. Deswegen können wir direkt mit den Quelldateien
arbeiten, zumindest solange keine spätere Phase das Arbeitsverzeichnis
woandershin wechselt.

Die Liste der @code{%standard-phases} des Erstellungssystems ändern wir mit
Hilfe des @code{modify-phases}-Makros über eine Liste von Änderungen. Sie
kann folgende Formen haben:

@itemize
@item
@code{(add-before @var{Phase} @var{neue-Phase} @var{Prozedur})}:
@var{Prozedur} unter dem Namen @var{neue-Phase} vor @var{Phase} ausführen.
@item
@code{(add-after @var{Phase} @var{neue-Phase} @var{Prozedur})}: Genauso,
aber danach.
@item
@code{(replace @var{Phase} @var{Prozedur})}.
@item
@code{(delete @var{Phase})}.
@end itemize

Die @var{Prozedur} unterstützt die Schlüsselwortargumente @code{inputs} und
@code{outputs}. Jede Eingabe (ob sie @emph{native}, @emph{propagated} oder
nichts davon ist) und jedes Ausgabeverzeichnis ist in diesen Variablen mit
dem jeweiligen Namen assoziiert. @code{(assoc-ref outputs "out")} ist also
das Store-Verzeichnis der Hauptausgabe des Pakets. Eine Phasenprozedur kann
so aussehen:

@lisp
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let ((bash-directory (assoc-ref inputs "bash"))
        (output-directory (assoc-ref outputs "out"))
        (doc-directory (assoc-ref outputs "doc")))
    ;; ... ))
@end lisp

Ihr Rückgabewert wird ignoriert.

@subsubsection Code-Staging

Aufmerksame Leser könnten die Syntax mit @code{quasiquote} und Komma im
Argumentefeld bemerkt haben. Tatsächlich sollte der Erstellungscode in der
Paketdeklaration @emph{nicht} auf Client-Seite ausgeführt werden, sondern
erst, wenn er an den Guix-Daemon übergeben worden ist. Der Mechanismus, über
den Code zwischen zwei laufenden Prozessen weitergegeben wird, nennen wir
@uref{https://arxiv.org/abs/1709.00833, Code-Staging}.

@subsubsection Hilfsfunktionen

Beim Anpassen der @code{phases} müssen wir oft Code schreiben, der analog zu
den äquivalenten Systemaufrufen funktioniert (@code{make}, @code{mkdir},
@code{cp}, etc.), welche in regulären „Unix-artigen“ Installationen oft
benutzt werden.

Manche, wie @code{chmod}, sind Teil von Guile. Siehe das @ref{,,, guile,
Referenzhandbuch zu Guile} für eine vollständige Liste.

Guix stellt zusätzliche Hilfsfunktionen zur Verfügung, die bei der
Paketverwaltung besonders praktisch sind.

Manche dieser Funktionalitäten finden Sie in
@samp{$GUIX_CHECKOUT/guix/guix/build/utils.scm}. Die meisten spiegeln das
Verhalten traditioneller Unix-Systembefehle wider:

@table @code
@item which
Das Gleiche wie der @samp{which}-Systembefehl.
@item find-files
Wie der @samp{find} Systembefehl.
@item mkdir-p
Wie @samp{mkdir -p}, das Elternverzeichnisse erzeugt, wenn nötig.
@item install-file
Ähnlich wie @samp{install} beim Installieren einer Datei in ein (nicht
unbedingt existierendes) Verzeichnis. Guile kennt @code{copy-file}, das wie
@samp{cp} funktioniert.
@item copy-recursively
Wie @samp{cp -r}.
@item delete-file-recursively
Wie @samp{rm -rf}.
@item invoke
Eine ausführbare Datei ausführen. Man sollte es benutzen und nicht
@code{system*}.
@item with-directory-excursion
Den Rumpf in einem anderen Arbeitsverzeichnis ausführen und danach wieder in
das vorherige Arbeitsverzeichnis wechseln.
@item substitute*
Eine „@command{sed}-artige“ Funktion.
@end table

Siehe @ref{Werkzeuge zur Erstellung,,, guix.de, Referenzhandbuch zu GNU
Guix} für mehr Informationen zu diesen Werkzeugen.

@subsubsection Modulpräfix

Die Lizenz in unserem letzten Beispiel braucht ein Präfix. Der Grund liegt
darin, wie das @code{license}-Modul importiert worden ist, nämlich
@code{#:use-module ((guix licenses)  #:prefix license:)}. Der
Importmechanismus von Guile-Modulen (siehe @ref{Using Guile Modules,,,
guile, Referenzhandbuch zu Guile}) gibt Benutzern die volle Kontrolle über
Namensräume. Man braucht sie, um Konflikte zu lösen, z.B.@ zwischen der
@samp{zlib}-Variablen aus @samp{licenses.scm} (dieser Wert repräsentiert
eine @emph{Softwarelizenz}) und der @samp{zlib}-Variablen aus
@samp{compression.scm} (ein Wert, der für ein @emph{Paket} steht).

@node Andere Erstellungssysteme
@subsection Andere Erstellungssysteme

Was wir bisher gesehen haben reicht für die meisten Pakete aus, die als
Erstellungssystem etwas anderes als @code{trivial-build-system}
verwenden. Letzteres automatisiert gar nichts und überlässt es Ihnen, alles
zur Erstellung manuell festzulegen. Das kann einen noch mehr beanspruchen
und wir beschreiben es hier zurzeit nicht, aber glücklicherweise braucht man
dieses System auch nur in seltenen Fällen.

Bei anderen Erstellungssystemen wie ASDF, Emacs, Perl, Ruby und vielen
anderen ist der Prozess sehr ähnlich zum GNU-Erstellungssystem abgesehen von
ein paar speziellen Argumenten.

Siehe @ref{Erstellungssysteme,,, guix.de, Referenzhandbuch zu GNU Guix}, für
mehr Informationen über Erstellungssysteme, oder den Quellcode in den
Verzeichnissen @samp{$GUIX_CHECKOUT/guix/build} und
@samp{$GUIX_CHECKOUT/guix/build-system}.

@node Programmierbare und automatisierte Paketdefinition
@subsection Programmierbare und automatisierte Paketdefinition

Wir können es nicht oft genug wiederholen: Eine Allzweck-Programmiersprache
zur Hand zu haben macht Dinge möglich, die traditionelle Paketverwaltung
weit übersteigen.

Wir können uns das anhand Guix’ großartiger Funktionalitäten klarmachen!

@menu
* Rekursive Importer::       Rekursive Importer
* Automatisch aktualisieren::  Automatisch aktualisieren
* Vererbung::                Vererbung
@end menu

@node Rekursive Importer
@subsubsection Rekursive Importer

Sie könnten feststellen, dass manche Erstellungssysteme gut genug sind und
nichts weiter zu tun bleibt, um ein Paket zu verfassen. Das Paketeschreiben
kann so monoton werden und man wird dessen bald überdrüssig. Eine
Daseinsberechtigung von Rechnern ist, Menschen bei solch langweiligen
Aufgaben zu ersetzen. Lasst uns also Guix die Sache erledigen: Wir lassen
uns die Paketdefinition eines R-Pakets mit den Informationen aus CRAN holen
(was zu anderen ausgegeben wird, haben wir im Folgenden weggelassen):

@example
$ guix import cran --recursive walrus

(define-public r-mc2d
    ; …
    (license gpl2+)))

(define-public r-jmvcore
    ; …
    (license gpl2+)))

(define-public r-wrs2
    ; …
    (license gpl3)))

(define-public r-walrus
  (package
    (name "r-walrus")
    (version "1.0.3")
    (source
      (origin
        (method url-fetch)
        (uri (cran-uri "walrus" version))
        (sha256
          (base32
            "1nk2glcvy4hyksl5ipq2mz8jy4fss90hx6cq98m3w96kzjni6jjj"))))
    (build-system r-build-system)
    (propagated-inputs
      (list r-ggplot2 r-jmvcore r-r6 r-wrs2))
    (home-page "https://github.com/jamovi/walrus")
    (synopsis "Robust Statistical Methods")
    (description
      "This package provides a toolbox of common robust statistical
tests, including robust descriptives, robust t-tests, and robust ANOVA.
It is also available as a module for 'jamovi' (see
<https://www.jamovi.org> for more information).  Walrus is based on the
WRS2 package by Patrick Mair, which is in turn based on the scripts and
work of Rand Wilcox.  These analyses are described in depth in the book
'Introduction to Robust Estimation & Hypothesis Testing'.")
    (license gpl3)))
@end example

Der rekursive Importer wird keine Pakete importieren, für die es in Guix
bereits eine Paketdefinition gibt, außer dem Paket, mit dem er anfängt.

Nicht für alle Anwendungen können auf diesem Weg Pakete erzeugt werden, nur
für jene, die auf ausgewählten Systemen aufbauen. Im Handbuch können Sie
Informationen über die vollständige Liste aller Importer bekommen (siehe
@ref{Aufruf von guix import,,, guix.de, Referenzhandbuch zu GNU Guix}).

@node Automatisch aktualisieren
@subsubsection Automatisch aktualisieren

Guix ist klug genug, um verfügbare Aktualisierungen auf bekannten Systemen
zu erkennen. Es kann über veraltete Paketdefinitionen Bericht erstatten,
wenn man dies eingibt:

@example
$ guix refresh hello
@end example

In den meisten Fällen muss man zur Aktualisierung auf eine neuere Version
wenig mehr tun, als die Versionsnummer und die Prüfsumme ändern. Auch das
kann mit Guix automatisiert werden:

@example
$ guix refresh hello --update
@end example

@node Vererbung
@subsubsection Vererbung

Wenn Sie anfangen, bestehende Paketdefinitionen anzuschauen, könnte es Ihnen
auffallen, dass viele von ihnen über ein @code{inherit}-Feld verfügen.

@lisp
(define-public adwaita-icon-theme
  (package (inherit gnome-icon-theme)
    (name "adwaita-icon-theme")
    (version "3.26.1")
    (source (origin
              (method url-fetch)
              (uri (string-append "mirror://gnome/sources/" name "/"
                                  (version-major+minor version) "/"
                                  name "-" version ".tar.xz"))
              (sha256
               (base32
                "17fpahgh5dyckgz7rwqvzgnhx53cx9kr2xw0szprc6bnqy977fi8"))))
    (native-inputs (list `(,gtk+ \"bin\")))))
@end lisp

Alle @emph{nicht} aufgeführten Felder werden vom Elternpaket geerbt. Das ist
ziemlich praktisch, um alternative Pakete zu erzeugen, zum Beispiel solche
mit geänderten Quellorten, Versionen oder Kompilierungsoptionen.

@node Hilfe bekommen
@subsection Hilfe bekommen

Leider ist es für manche Anwendungen schwierig, Pakete zu
schreiben. Manchmal brauchen sie einen Patch, um mit vom Standard
abweichenden Dateisystemhierarchien klarzukommen, wie sie der Store
erforderlich macht. Manchmal funktionieren die Tests nicht richtig. (Man
kann sie überspringen, aber man sollte nicht.) Ein andermal ist das sich
ergebende Paket nicht reproduzierbar.

Wenn Sie nicht weiterkommen, weil Sie nicht wissen, wie Sie ein Problem beim
Paketschreiben lösen können, dann zögern Sie nicht, die Gemeinde um Hilfe zu
bitten.

Siehe die @uref{https://guix.gnu.org/contact/, Homepage von Guix} für
Informationen, welche Mailing-Listen, IRC-Kanäle etc.@: bereitstehen.

@node Schlusswort
@subsection Schlusswort

Diese Anleitung hat einen Überblick über die fortgeschrittene
Paketverwaltung gegeben, die Guix vorweist. Zu diesem Zeitpunkt haben wir
diese Einführung größtenteils auf das @code{gnu-build-system} eingeschränkt,
was eine zentrale Abstraktionsschicht darstellt, auf der weitere
Abstraktionen aufbauen.

Wie geht es nun weiter? Als Nächstes müssten wir das Erstellungssystem in
seine Bestandteile zerlegen, um einen Einblick ganz ohne Abstraktionen zu
bekommen. Das bedeutet, wir müssten das @code{trivial-build-system}
analysieren. Dadurch sollte ein gründliches Verständnis des Prozesses
vermittelt werden, bevor wir höher entwickelte Paketierungstechniken und
Randfälle untersuchen.

Andere Funktionalitäten, die es wert sind, erkundet zu werden, sind Guix’
Funktionalitäten zum interaktiven Editieren und zur Fehlersuche, die die
REPL von Guile darbietet.

Diese eindrucksvollen Funktionalitäten sind völlig optional und können
warten; jetzt ist die Zeit für eine wohlverdiente Pause. Mit dem Wissen, in
das wir hier eingeführt haben, sollten Sie für das Paketieren vieler
Programme gut gerüstet sein. Sie können gleich anfangen und hoffentlich
bekommen wir bald Ihre Beiträge zu sehen!

@node Literaturverzeichnis
@subsection Literaturverzeichnis

@itemize
@item
Die @uref{https://guix.gnu.org/manual/de/html_node/Pakete-definieren.html,
Paketreferenz im Handbuch}

@item
@uref{https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org, Pjotr’s
Hacking-Leitfaden für GNU Guix}

@item
@uref{https://guix.gnu.org/guix-ghm-andreas-20130823.pdf,, „GNU Guix:
Package without a scheme!“} von Andreas Enge
@end itemize

@node Packaging Workflows
@section Packaging Workflows

The following sections provide real-life examples on working with specific
build systems, serving as extensions to the concise packaging guidelines
(@pxref{Packaging Guidelines,,, guix, GNU Guix Reference Manual}).

@menu
* Packaging Rust Crates::    Packaging Rust Crates
@end menu

@node Packaging Rust Crates
@subsection Packaging Rust Crates

In preparation, add the following packages to our environment:

@example
$ guix shell rust rust:cargo cargo-audit cargo-license
@end example

@menu
* Common Workflow for Rust Packaging::  Common Workflow for Rust Packaging
* Cargo Workspaces and Development Snapshots::  Cargo Workspaces and 
                                                  Development Snapshots
* Using Rust Libraries in Other Build Systems::  Using Rust Libraries in 
                                                   Other Build Systems
@end menu

@node Common Workflow for Rust Packaging
@subsubsection Common Workflow for Rust Packaging

In this example, we'll package @code{cargo-audit}, which is published on the
@uref{https://crates.io, crates.io} Rust package repository.  All its
dependencies are on crates.io as well.

@enumerate
@item
Since @code{cargo-audit} is available on crates.io, we can generate a
template via the crates.io importer (@pxref{Invoking guix import,,, guix,
GNU Guix Reference Manual}):

@example
$ guix import crate cargo-audit
@end example

After manual editing, we'll have the following definiton:

@lisp
(define-public cargo-audit
  (package
    (name "cargo-audit")
    (version "0.21.2")
    (source
     (origin
       (method url-fetch)
       (uri (crate-uri "cargo-audit" version))
       (file-name (string-append name "-" version ".tar.gz"))
       (sha256
        (base32 "1a00yqpckkw86zh2hg7ra82c5fx0ird5766dyynimbvqiwg2ps0n"))))
    (build-system cargo-build-system)
    (arguments (list #:install-source? #f))
    (inputs (cargo-inputs 'cargo-audit))
    (home-page "https://rustsec.org/")
    (synopsis "Audit Cargo.lock for crates with security vulnerabilities")
    (description
     "This package provides a Cargo subcommand, @@command@{cargo audit@}, to
audit @@file@{Cargo.lock@} for crates with security vulnerabilities.")
    (license (list license:asl2.0 license:expat))))
@end lisp

The identifier used to invoke @code{cargo-inputs}, in this case
@code{'cargo-audit}, must be unique, usually matching the variable name of
the package.

@item
Unpack package source and navigate to the unpacked directory, then run the
following commands:

@example
$ cargo generate-lockfile
$ cargo audit
$ cargo license
@end example

@command{cargo generate-lockfile} updates dependencies to compatible
versions.  Applying it to all Rust applications helps reduce a great number
of Rust libraries we need to check later.  Although sometimes libraries may
fail to follow the @uref{https://semver.org/, semantic versioning} scheme,
it's still acceptable.

@command{cargo audit} checks known vulnerabilities and @command{cargo
license} checks licenses, for all the dependencies.  We must have an
acceptable output of @command{cargo audit} and ensure all dependencies are
licensed with our supported licenses (@pxref{Defining Packages,,, guix, GNU
Guix Reference Manual}).

@item
Import dependencies from the generated lockfile:

@example
$ guix import --insert=gnu/packages/rust-crates.scm \
      crate --lockfile=/path/to/Cargo.lock cargo-audit

# Or use short options, in this case the shell processes file names
# before passing them to Guix, allowing tilde expansion, for example.
$ guix import -i gnu/packages/rust-crates.scm \
      crate -f /path/to/Cargo.lock cargo-audit
@end example

@code{cargo-audit} here must be consistent with the identifier used for
@code{cargo-inputs} invocation in the package definition.

At this stage, the package @code{cargo-audit} is buildable.

@item
Finally we'll unbundle the vendored dependencies.  The lockfile importer
inserts @code{TODO REVIEW:} comments for libraries with high probability of
bundled dependencies.  @code{cargo-build-system} also performs additional
check for binary files in its @code{check-for-pregenerated-files} phase,
which usually indicates bundling:

@example
$ ./pre-inst-env guix build cargo-audit
@dots{}
starting phase `check-for-pregenerated-files'
Searching for binary files...
./guix-vendor/rust-async-compression-0.4.21.tar.gz/tests/artifacts/dictionary-rust
./guix-vendor/rust-async-compression-0.4.21.tar.gz/tests/artifacts/dictionary-rust-other
./guix-vendor/rust-async-compression-0.4.21.tar.gz/tests/artifacts/lib.rs.zst
./guix-vendor/rust-async-compression-0.4.21.tar.gz/tests/artifacts/long-window-size-lib.rs.zst
./guix-vendor/rust-winapi-i686-pc-windows-gnu-0.4.0.tar.gz/lib/libwinapi_aclui.a
./guix-vendor/rust-winapi-i686-pc-windows-gnu-0.4.0.tar.gz/lib/libwinapi_activeds.a
./guix-vendor/rust-winapi-i686-pc-windows-gnu-0.4.0.tar.gz/lib/libwinapi_asycfilt.a
./guix-vendor/rust-winapi-i686-pc-windows-gnu-0.4.0.tar.gz/lib/libwinapi_amsi.a
@dots{}
@end example

Although Rust libraries are not publicly exported, we can still select them
via the Guix command-line interface via a Guile expression:

@example
$ guix build --expression='(@@@@ (gnu packages rust-crates) rust-ring-0.17.14)'
@end example

To unbundle most dependencies, a snippet is sufficient:

@lisp
(define rust-curl-sys-0.4.80+curl-8.12.1
  (crate-source "curl-sys" "0.4.80+curl-8.12.1"
                "0d7ppx4kq77hc5nyff6jydmfabpgd0i3ppjvn8x0q833mhpdzxsm"
                #:snippet '(delete-file-recursively "curl")))
@end lisp

@lisp
(define rust-bzip2-sys-0.1.13+1.0.8
  (crate-source "bzip2-sys" "0.1.13+1.0.8"
                "056c39pgjh4272bdslv445f5ry64xvb0f7nph3z7860ln8rzynr2"
                #:snippet
                '(begin
                   (delete-file-recursively "bzip2-1.0.8")
                   (delete-file "build.rs")
                   (with-output-to-file "build.rs"
                     (lambda _
                       (format #t "fn main() @{~@@
                        println!(\"cargo:rustc-link-lib=bz2\");~@@
                        @}~%"))))))
@end lisp

In a more complex case, where unbundling one dependency requires a build
process that involves other packages, we should make a full package in
@code{(gnu packages rust-sources)} first and reference it in the imported
definition.

For example, we have defined a @code{rust-ring-0.17} in @code{(gnu packages
rust-sources)}, then the imported definition in @code{(gnu packages
rust-crates)} should be modified to reference it.

@lisp
(define rust-ring-0.17.14 rust-ring-0.17)
@end lisp

When one dependency can be safely removed, modify it to @code{#f}.

@lisp
(define rust-openssl-src-300.4.2+3.4.1 #f)
@end lisp

To facilitate various tasks in the common workflow, several scripts are
provided in the @file{etc/teams/rust} directory of Guix source tree.
@end enumerate

@node Cargo Workspaces and Development Snapshots
@subsubsection Cargo Workspaces and Development Snapshots

In this example, we'll package @code{niri}, which depends on development
snapshots (also Cargo workspaces here).

As we can't ensure compatibility of a development snapshot, before executing
@command{cargo generate-lockfile}, we should modify @file{Cargo.toml} to pin
it to a known working revision.

To use our packaged development snapshots, it's also necessary to modify
@file{Cargo.toml} in a build phase, with a package-specific substitution
pattern.

@lisp
(define-public niri
  (package
   (name "niri")
   (version "25.02")
   (source (origin
             (method git-fetch)
             (uri (git-reference
                   (url "https://github.com/YaLTeR/niri")
                   (commit (string-append "v" version))))
             (file-name (git-file-name name version))
             (sha256
              (base32
               "0vzskaalcz6pcml687n54adjddzgf5r07gggc4fhfsa08h1wfd4r"))))
   (build-system cargo-build-system)
   (arguments
    (list #:install-source? #f
          #:phases
          #~(modify-phases %standard-phases
              (add-after 'unpack 'use-guix-vendored-dependencies
                (lambda _
                  (substitute* "Cargo.toml"
                    (("# version =.*")
                     "version = \"*\"")
                    (("git.*optional")
                     "version = \"*\", optional")
                    (("^git = .*")
                     "")))))))
   (native-inputs
    (list pkg-config))
   (inputs
    (cons* clang
           libdisplay-info
           libinput-minimal
           libseat
           libxkbcommon
           mesa
           pango
           pipewire
           wayland
           (cargo-inputs 'niri)))
   (home-page "https://github.com/YaLTeR/niri")
   (synopsis "Scrollable-tiling Wayland compositor")
   (description
    "Niri is a scrollable-tiling Wayland compositor which arranges windows in a
scrollable format.  It is considered stable for daily use and performs most
functions expected of a Wayland compositor.")
   (license license:gpl3+)))
@end lisp

@code{niri} has Cargo workspace dependencies.  When packaging a Cargo
workspace dependency, parameter @code{#:cargo-package-crates} is required.

@lisp
(define-public rust-pipewire-0.8.0.fd3d8f7
  (let ((commit "fd3d8f7861a29c2eeaa4c393402e013578bb36d9")
        (revision "0"))
    (package
      (name "rust-pipewire")
      (version (git-version "0.8.0" revision commit))
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://gitlab.freedesktop.org/pipewire/pipewire-rs.git")
               (commit commit)))
         (file-name (git-file-name name version))
         (sha256
          (base32 "1hzyhz7xg0mz8a5y9j6yil513p1m610q3j9pzf6q55vdh5mcn79v"))))
      (build-system cargo-build-system)
      (arguments
       (list #:skip-build? #t
             #:cargo-package-crates
             ''("libspa-sys" "libspa" "pipewire-sys" "pipewire")))
      (inputs (cargo-inputs 'rust-pipewire-0.8.0.fd3d8f7))
      (home-page "https://pipewire.org/")
      (synopsis "Rust bindings for PipeWire")
      (description "This package provides Rust bindings for PipeWire.")
      (license license:expat))))
@end lisp

Don't forget to modify all workspace members in @code{(gnu packages
rust-crates)}:

@lisp
(define rust-pipewire-0.8.0.fd3d8f7 package:rust-pipewire-0.8.0.fd3d8f7)
(define rust-pipewire-sys-0.8.0.fd3d8f7 package:rust-pipewire-0.8.0.fd3d8f7)
@dots{}
(define rust-libspa-0.8.0.fd3d8f7 package:rust-pipewire-0.8.0.fd3d8f7)
(define rust-libspa-sys-0.8.0.fd3d8f7 package:rust-pipewire-0.8.0.fd3d8f7)
@end lisp

@node Using Rust Libraries in Other Build Systems
@subsubsection Using Rust Libraries in Other Build Systems

In this example, we'll package @code{libchewing}, which combines two build
systems.

When building Rust packages in other build systems, we need to add
@code{rust}, and @code{rust:cargo} to @code{native-inputs}, import and use
modules from both build systems, and apply necessary build phases from
@code{cargo-build-system}.

For cross-compilation support, we'll also add @code{rust-sysroot} created
with @code{(make-rust-sysroot (%current-target-system))} to
@code{native-inputs}, and set @code{#:cargo-target} for
@code{cargo-build-system}'s build phases.

@lisp
(define-public libchewing
  (package
    (name "libchewing")
    (version "0.9.1")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             (url "https://github.com/chewing/libchewing")
             (commit (string-append "v" version))))
       (file-name (git-file-name name version))
       (sha256
        (base32 "0gh64wvrk5pn0fhmpvj1j99d5g7f7697rk96zbkc8l72yjr819z5"))))
    (build-system cmake-build-system)
    (arguments
     (list #:imported-modules
           (append %cmake-build-system-modules
                   %cargo-build-system-modules)
           #:modules
           '(((guix build cargo-build-system) #:prefix cargo:)
             (guix build cmake-build-system)
             (guix build utils))
           #:phases
           #~(modify-phases %standard-phases
               (add-after 'unpack 'prepare-cargo-build-system
                 (lambda args
                   (for-each
                    (lambda (phase)
                      (format #t "Running cargo phase: ~a~%" phase)
                      (apply (assoc-ref cargo:%standard-phases phase)
                             ;; For cross-compilation.
                             #:cargo-target #$(cargo-triplet)
                             args))
                    '(unpack-rust-crates
                      configure
                      check-for-pregenerated-files
                      patch-cargo-checksums)))))))
    (native-inputs
     (append
      (list rust `(,rust "cargo") )
      ;; For cross-compilation.
      (or (and=> (%current-target-system)
                 (compose list make-rust-sysroot))
          '())))
    (inputs
     (cons* corrosion ncurses sqlite (cargo-inputs 'libchewing)))
    (synopsis "Chinese phonetic input method")
    (description "Chewing is an intelligent phonetic (Zhuyin/Bopomofo) input
method, one of the most popular choices for Traditional Chinese users.")
    (home-page "https://chewing.im/")
    (license license:lgpl2.1+)))
@end lisp


@c *********************************************************************
@node Systemkonfiguration
@chapter Systemkonfiguration

Guix stellt eine flexible Sprache bereit, um Ihr „Guix System“ auf
deklarative Weise zu konfigurieren. Diese Flexibilität kann einen manchmal
überwältigen. Dieses Kapitel hat den Zweck, einige fortgeschrittene
Konfigurationskonzepte vorzuzeigen.

Siehe @ref{Systemkonfiguration,,, guix.de, Referenzhandbuch zu GNU Guix} für
eine vollständige Referenz.

@menu
* Automatisch an virtueller Konsole anmelden::  Benutzer an einem bestimmten 
                                                  TTY automatisch anmelden.
* Den Kernel anpassen::      Einen eigenen Linux-Kernel auf Guix System 
                               erzeugen und benutzen.
* Die Image-Schnittstelle von Guix System::  Abbilder für bestimmte 
                                               Plattformen anpassen.
* Sicherheitsschlüssel verwenden::  Ihre Sicherheitsschlüssel mit Guix 
                                      System gebrauchen.
* Dynamisches DNS als mcron-Auftrag::  Mit diesem Auftrag bleibt Ihre 
                                         IP-Adresse bei DuckDNS aktuell.
* Verbinden mit Wireguard VPN::  Wie man sich mit einem Wireguard-VPN 
                                   verbindet.
* Fensterverwalter (Window Manager) anpassen::  Wie man einen 
                                                  Fensterverwalter auf Guix 
                                                  System anpassen kann.
* Guix auf einem Linode-Server nutzen::  Guix auf einem Linode-Server 
                                           nutzen.
* Guix auf einem Kimsufi-Server nutzen::  Guix auf einem Kimsufi-Server 
                                            nutzen.
* Bind-Mounts anlegen::      Bind-Mounts als Dateisystemdefinition 
                               einrichten.
* Substitute über Tor beziehen::  Den Guix-Daemon konfigurieren, damit er 
                                    Substitute über Tor lädt.
* NGINX mit Lua konfigurieren::  Den NGINX-Web-Server so einrichten, dass 
                                   Lua-Module geladen werden.
* Musik-Server mit Bluetooth-Audio::  Musikzentrale ohne Bildschirm mit 
                                        Bluetooth-Ausgabe.
@end menu

@node Automatisch an virtueller Konsole anmelden
@section Automatisch an virtueller Konsole anmelden

Im Guix-Handbuch wird erklärt, wie man ein Benutzerkonto automatisch auf
@emph{allen} TTYs anmelden lassen kann (@pxref{auto-login to TTY,,, guix.de,
Referenzhandbuch zu GNU Guix}), aber vielleicht wäre es Ihnen lieber, ein
Benutzerkonto an genau einem TTY anzumelden und die anderen TTYs so zu
konfigurieren, dass entweder andere Benutzer oder gar niemand angemeldet
wird. Beachten Sie, dass man auf jedem TTY automatisch jemanden anmelden
kann, aber meistens will man @code{tty1} in Ruhe lassen, weil dorthin nach
Voreinstellung Warnungs- und Fehlerprotokolle ausgegeben werden.

Um eine Benutzerin auf einem einzelnen TTY automatisch anzumelden, schreibt
man:

@lisp
(define (auto-login-to-tty config tty user)
  (if (string=? tty (mingetty-configuration-tty config))
        (mingetty-configuration
         (inherit config)
         (auto-login user))
        config))

(define %my-services
  (modify-services %base-services
    ;; …
    (mingetty-service-type config =>
                           (auto-login-to-tty
                            config "tty3" "alice"))))

(operating-system
  ;; …
  (services %my-services))
@end lisp

Mit Hilfe von @code{compose} (siehe @ref{Higher-Order Functions,,, guile,
das Referenzhandbuch zu GNU Guile}) kann man etwas wie
@code{auto-login-to-tty} mehrfach angeben, um mehrere Nutzerkonten auf
verschiedenen TTYs anzumelden.

Zum Schluss aber noch eine Warnung. Wenn Sie jemanden auf einem TTY
automatisch anmelden lassen, kann jeder einfach Ihren Rechner anschalten und
dann Befehle in deren Namen ausführen. Haben Sie Ihr Wurzeldateisystem auf
einer verschlüsselten Partition, müsste man dafür erst einmal das Passwort
eingeben, wenn das System startet. Dann wäre automatisches Anmelden
vielleicht bequem.


@node Den Kernel anpassen
@section Den Kernel anpassen

Im Kern ist Guix eine quellcodebasierte Distribution mit Substituten (siehe
@ref{Substitute,,, guix.de, Referenzhandbuch zu GNU Guix}), daher ist das
Erstellen von Paketen aus ihrem Quellcode heraus genauso vorgesehen wie die
normale Installation und Aktualisierung von Paketen. Von diesem Standpunkt
ist es sinnvoll, zu versuchen, den Zeitaufwand für das Kompilieren von
Paketen zu senken, und kürzliche Neuerungen sowie Verbesserungen beim
Erstellen und Verteilen von Substituten bleiben ein Diskussionsthema
innerhalb von Guix.

Der Kernel braucht zwar keine übermäßigen Mengen an Arbeitsspeicher beim
Erstellen, jedoch jede Menge Zeit auf einer durchschnittlichen Maschine. Die
offizielle Konfiguration des Kernels umfasst, wie bei anderen
GNU/Linux-Distributionen auch, besser zu viel als zu wenig. Das ist der
eigentliche Grund, warum seine Erstellung so lange dauert, wenn man den
Kernel aus dem Quellcode heraus erstellt.

Man kann den Linux-Kernel jedoch auch als ganz normales Paket beschreiben,
das genau wie jedes andere Paket angepasst werden kann. Der Vorgang ist ein
klein wenig anders, aber das liegt hauptsächlich an der Art, wie die
Paketdefinition geschrieben ist.

Die @code{linux-libre}-Kernelpaketdefinition ist tatsächlich eine Prozedur,
die ein Paket liefert.

@lisp
(define* (make-linux-libre* version gnu-revision source supported-systems
                            #:key
                            (extra-version #f)
                            ;; Eine Funktion, die eine Architektur und eine
                            ;; Variante nimmt. Siehe kernel-config als Beispiel.
                            (configuration-file #f)
                            (defconfig "defconfig")
                            (extra-options (default-extra-linux-options version)))
  …)
@end lisp

Das momentane @code{linux-libre}-Paket zielt ab auf die 5.15.x-Serie und ist
wie folgt deklariert:

@lisp
(define-public linux-libre-5.15
  (make-linux-libre* linux-libre-5.15-version
                     linux-libre-5.15-gnu-revision
                     linux-libre-5.15-source
                     '("x86_64-linux" "i686-linux" "armhf-linux"
                       "aarch64-linux" "riscv64-linux")
                     #:configuration-file kernel-config))
@end lisp

Alle Schlüssel, denen kein Wert zugewiesen wird, erben ihren Vorgabewert von
der Definition von @code{make-linux-libre}. Wenn Sie die beiden Schnipsel
oben vergleichen, ist anzumerken, dass sich der Code-Kommentar in ersterem
auf @code{#:configuration-file} bezieht. Deswegen ist es nicht so leicht,
aus der Definition heraus eine eigene Kernel-Konfiguration anhand der
Definition zu schreiben, aber keine Sorge, es gibt andere Möglichkeiten, um
mit dem zu arbeiten, was uns gegeben wurde.

There are two ways to create a kernel with a custom kernel configuration.
The first is to provide a standard @file{defconfig} to
@code{customize-linux} procedure.  To produce such file you need to obtain
Linux source code, create a @file{.config} file (using @code{make
menuconfig} command, for example) or provide one you already have.  After
that you will need to run @code{make savedefconfig} command within the
kernel source tree---this will produce the @file{defconfig} file which we
will use to build a custom kernel.

Below is a sample kernel package.

@lisp
(define-public my-linux-libre
  (package
    (inherit (customize-linux
              #:linux linux-libre
              #:defconfig
              (local-file "defconfig")))
    (name "my-linux-libre")))
@end lisp

In the same directory as the file defining @code{my-linux-libre} is a file
named @file{defconfig}. This way you can provide kernel options you want to
have in the result kernel.

Die zweite Möglichkeit, einen eigenen Kernel zu erzeugen, ist, einen neuen
Wert an das @code{extra-options}-Schlüsselwort der
@code{make-linux-libre}-Prozedur zu übergeben. Das
@code{extra-options}-Schlüsselwort wird zusammen mit einer anderen, direkt
darunter definierten Funktion benutzt:

@lisp
(define (default-extra-linux-options version)
  `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
   ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #true)
   ;; In der initrd benötigte Module:
   ("CONFIG_NET_9P" . m)
   ("CONFIG_NET_9P_VIRTIO" . m)
   ("CONFIG_VIRTIO_BLK" . m)
   ("CONFIG_VIRTIO_NET" . m)
   ("CONFIG_VIRTIO_PCI" . m)
   ("CONFIG_VIRTIO_BALLOON" . m)
   ("CONFIG_VIRTIO_MMIO" . m)
   ("CONFIG_FUSE_FS" . m)
   ("CONFIG_CIFS" . m)
   ("CONFIG_9P_FS" . m)))

(define (config->string options)
  (string-join (map (match-lambda
                      ((option . 'm)
                       (string-append option "=m"))
                      ((option . #true)
                       (string-append option "=y"))
                      ((option . #false)
                       (string-append option "=n")))
                    options)
               "\n"))
@end lisp

Und im eigenen configure-Skript des „make-linux-libre“-Pakets:

@lisp
;; Anhängen an die Datei ist wirksam, egal ob die Option in der Datei
;; stand. Es zählt das letzte Vorkommen.
(let ((port (open-file ".config" "a"))
      (extra-configuration ,(config->string extra-options)))
  (display extra-configuration port)
  (close-port port))

(invoke "make" "oldconfig")
@end lisp

Indem wir also kein „configuration-file“ mitgeben, ist @file{.config}
anfangs leer und danach schreiben wir dort die Sammlung der gewünschten
Optionen („Flags“) hinein. Hier ist noch ein eigener Kernel:

@lisp
(define %macbook41-full-config
  (append %macbook41-config-options
          %file-systems
          %efi-support
          %emulation
          ((@@@@ (gnu packages linux) default-extra-linux-options) version)))

(define-public linux-libre-macbook41
  ;; XXX: Auf die interne 'make-linux-libre*'-Prozedur zugreifen, welche privat
  ;; ist und nicht exportiert, des Weiteren kann sie sich in Zukunft ändern.
  ((@@@@ (gnu packages linux) make-linux-libre*)
   (@@@@ (gnu packages linux) linux-libre-version)
   (@@@@ (gnu packages linux) linux-libre-gnu-revision)
   (@@@@ (gnu packages linux) linux-libre-source)
   '("x86_64-linux")
   #:extra-version "macbook41"
   #:extra-options %macbook41-config-options))
@end lisp

Im obigen Beispiel ist @code{%file-systems} eine Sammlung solcher „Flags“,
mit denen Unterstützung für verschiedene Dateisysteme aktiviert wird,
@code{%efi-support} aktiviert Unterstützung für EFI und @code{%emulation}
ermöglicht es einer x86_64-linux-Maschine, auch im 32-Bit-Modus zu
arbeiten. Die Prozedur @code{default-extra-linux-options} ist die oben
definierte, die hinzugefügt werden musste, um die vorgegebenen
Konfigurationsoptionen für das @code{extra-options}-Schlüsselwort zu
behalten.

All das klingt machbar, aber woher weiß man überhaupt, welche Module für ein
bestimmtes System nötig sind? Es gibt zwei hilfreiche Anlaufstellen, zum
einen das
@uref{https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel,
Gentoo-Handbuch}, zum anderen die
@uref{https://www.kernel.org/doc/html/latest/admin-guide/README.html?highlight=localmodconfig,
Dokumentation des Kernels selbst}. Aus der Kernel-Dokumentation erfahren
wir, dass @code{make localmodconfig} der Befehl sein könnte, den wir wollen.

Um @code{make localmodconfig} auch tatsächlich ausführen zu können, müssen
wir zunächst den Quellcode des Kernels holen und entpacken:

@example shell
tar xf $(guix build linux-libre --source)
@end example

Sobald wir im Verzeichnis mit dem Quellcode sind, führen Sie @code{touch
.config} aus, um mit einer ersten, leeren @file{.config}
anzufangen. @code{make localmodconfig} funktioniert so, dass angeschaut
wird, was bereits in Ihrer @file{.config} steht, und Ihnen mitgeteilt wird,
was Ihnen noch fehlt. Wenn die Datei leer bleibt, fehlt eben alles. Der
nächste Schritt ist, das hier auszuführen:

@example shell
guix shell -D linux-libre -- make localmodconfig
@end example

und uns die Ausgabe davon anzuschauen. Beachten Sie, dass die
@file{.config}-Datei noch immer leer ist. Die Ausgabe enthält im Allgemeinen
zwei Arten von Warnungen. Am Anfang der ersten steht „WARNING“ und in
unserem Fall können wir sie tatsächlich ignorieren. Bei der zweiten heißt
es:

@example shell
module pcspkr did not have configs CONFIG_INPUT_PCSPKR
@end example

Für jede solche Zeile kopieren Sie den @code{CONFIG_XXXX_XXXX}-Teil in die
@file{.config} im selben Verzeichnis und hängen @code{=m} an, damit es am
Ende so aussieht:

@example shell
CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m
@end example

Nachdem Sie alle Konfigurationsoptionen kopiert haben, führen Sie noch
einmal @code{make localmodconfig} aus, um sicherzugehen, dass es keine
Ausgaben mehr gibt, deren erstes Wort „module“ ist. Zusätzlich zu diesen
maschinenspezifischen Modulen gibt es noch ein paar mehr, die Sie auch
brauchen. @code{CONFIG_MODULES} brauchen Sie, damit Sie Module getrennt
erstellen und laden können und nicht alles im Kernel eingebaut sein
muss. Sie brauchen auch @code{CONFIG_BLK_DEV_SD}, um von Festplatten lesen
zu können. Möglicherweise gibt es auch sonst noch Module, die Sie brauchen
werden.

Die Absicht hinter dem hier Niedergeschriebenen ist @emph{nicht}, eine
Anleitung zum Konfigurieren eines eigenen Kernels zu sein. Wenn Sie also
vorhaben, den Kernel an Ihre ganz eigenen Bedürfnisse anzupassen, werden Sie
in anderen Anleitungen fündig.

Die zweite Möglichkeit, die Kernel-Konfiguration einzurichten, benutzt mehr
von Guix’ Funktionalitäten und sie ermöglicht es Ihnen, Gemeinsamkeiten von
Konfigurationen zwischen verschiedenen Kernels zu teilen. Zum Beispiel wird
eine Reihe von EFI-Konfigurationsoptionen von allen Maschinen, die EFI
benutzen, benötigt. Wahrscheinlich haben all diese Kernels eine Schnittmenge
zu unterstützender Dateisysteme. Indem Sie Variable benutzen, können Sie
leicht auf einen Schlag sehen, welche Funktionalitäten aktiviert sind, und
gleichzeitig sicherstellen, dass Ihnen nicht Funktionalitäten des einen
Kernels im anderen fehlen.

Was wir hierbei nicht erläutert haben, ist, wie Guix’ initrd und dessen
Anpassung funktioniert. Wahrscheinlich werden Sie auf einer Maschine mit
eigenem Kernel die initrd verändern müssen, weil sonst versucht wird,
bestimmte Module in die initrd einzubinden, die Sie gar nicht erstellen
haben lassen.

@node Die Image-Schnittstelle von Guix System
@section Die Image-Schnittstelle von Guix System

In der Vergangenheit drehte sich in Guix System alles um eine
@code{operating-system}-Struktur. So eine Struktur enthält vielerlei Felder
vom Bootloader und der Deklaration des Kernels bis hin zu den Diensten, die
installiert werden sollen.

Aber je nach Zielmaschine@tie{}– diese kann alles von einer normalen
@code{x86_64}-Maschine sein bis zu einem kleinen ARM-Einplatinenrechner wie
dem Pine64@tie{}–, können die für ein Abbild geltenden Einschränkungen sehr
unterschiedlich sein. Die Hardwarehersteller ordnen verschiedene
Abbildformate an mit unterschiedlich versetzten unterschiedlich großen
Partitionen.

Um für jede dieser Arten von Maschinen geeignete Abbilder zu erzeugen,
brauchen wir eine neue Abstraktion. Dieses Ziel verfolgen wir mit dem
@code{image}-Verbund. Ein Verbundsobjekt enthält alle nötigen Informationen,
um daraus ein eigenständiges Abbild auf die Zielmaschine zu bringen. Es ist
direkt startfähig von jeder solchen Zielmaschine.

@lisp
(define-record-type* <image>
  image make-image
  image?
  (name               image-name ;Symbol
                      (default #f))
  (format             image-format) ;Symbol
  (target             image-target
                      (default #f))
  (size               image-size  ;Größe in Bytes als ganze Zahl
                      (default 'guess)) ;Vorgabe: automatisch bestimmen
  (operating-system   image-operating-system  ;<operating-system>
                      (default #f))
  (partitions         image-partitions ;Liste von <partition>
                      (default '()))
  (compression?       image-compression? ;Boolescher Ausdruck
                      (default #t))
  (volatile-root?     image-volatile-root? ;Boolescher Ausdruck
                      (default #t))
  (substitutable?     image-substitutable? ;Boolescher Ausdruck
                      (default #t)))
@end lisp

In einem Verbundsobjekt davon steht auch das zu instanziierende
Betriebssystem (in @code{operating-system}). Im Feld @code{format} steht,
was der Abbildtyp („image type“) ist, zum Beispiel @code{efi-raw},
@code{qcow2} oder @code{iso9660}. In Zukunft könnten die Möglichkeiten auf
@code{docker} oder andere Abbildtypen erweitert werden.

Ein neues Verzeichnis im Guix-Quellbaum wurde Abbilddefinitionen
gewidmet. Zurzeit gibt es vier Dateien darin:

@itemize @bullet
@item @file{gnu/system/images/hurd.scm}
@item @file{gnu/system/images/pine64.scm}
@item @file{gnu/system/images/novena.scm}
@item @file{gnu/system/images/pinebook-pro.scm}
@end itemize

Schauen wir uns @file{pine64.scm} an. Es enthält die Variable
@code{pine64-barebones-os}, bei der es sich um eine minimale Definition
eines Betriebssystems handelt, die auf Platinen der Art @b{Pine A64 LTS}
ausgerichtet ist.

@lisp
(define pine64-barebones-os
  (operating-system
   (host-name "vignemale")
   (timezone "Europe/Paris")
   (locale "en_US.utf8")
   (bootloader (bootloader-configuration
                (bootloader u-boot-pine64-lts-bootloader)
                (targets '("/dev/vda"))))
   (initrd-modules '())
   (kernel linux-libre-arm64-generic)
   (file-systems (cons (file-system
                        (device (file-system-label "my-root"))
                        (mount-point "/")
                        (type "ext4"))
                       %base-file-systems))
   (services (cons (service agetty-service-type
                            (agetty-configuration
                             (extra-options '("-L")) ;kein Carrier Detect
                             (baud-rate "115200")
                             (term "vt100")
                             (tty "ttyS0")))
                   %base-services))))
@end lisp

Die Felder @code{kernel} und @code{bootloader} verweisen auf
platinenspezifische Pakete.

Direkt darunter wird auch die Variable @code{pine64-image-type} definiert.

@lisp
(define pine64-image-type
  (image-type
   (name 'pine64-raw)
   (constructor (cut image-with-os arm64-disk-image <>))))
@end lisp

Sie benutzt einen Verbundstyp, über den wir noch nicht gesprochen haben, den
@code{image-type}-Verbund. Er ist wie folgt definiert:

@lisp
(define-record-type* <image-type>
  image-type make-image-type
  image-type?
  (name           image-type-name) ;Symbol
  (constructor    image-type-constructor)) ;<operating-system> -> <image>
@end lisp

Der Hauptzweck dieses Verbunds ist, einer Prozedur, die ein
@code{operating-system} in ein @code{image}-Abbild umwandelt, einen Namen zu
geben. Um den Bedarf dafür nachzuvollziehen, schauen wir uns den Befehl an,
mit dem ein Abbild aus einer @code{operating-system}-Konfigurationsdatei
erzeugt wird:

@example
guix system image my-os.scm
@end example

Dieser Befehl erwartet eine @code{operating-system}-Konfiguration, doch wie
geben wir an, dass wir ein Abbild für einen Pine64-Rechner möchten? Wir
müssen zusätzliche Informationen mitgeben, nämlich den Abbildtyp,
@code{image-type}, indem wir die Befehlszeilenoption @code{--image-type}
oder @code{-t} übergeben, und zwar so:

@example
guix system image --image-type=pine64-raw my-os.scm
@end example

Der Parameter @code{image-type} verweist auf den oben definierten
@code{pine64-image-type}. Dadurch wird die Prozedur @code{(cut image-with-os
arm64-disk-image <>)} auf das in @code{my-os.scm} deklarierte
@code{operating-system} angewandt und macht es zu einem @code{image}-Abbild.

Es ergibt sich ein Abbild wie dieses:

@lisp
(image
 (format 'disk-image)
 (target "aarch64-linux-gnu")
 (operating-system my-os)
 (partitions
  (list (partition
         (inherit root-partition)
         (offset root-offset)))))
@end lisp

Das ist das Aggregat aus dem in @code{my-os.scm} definierten
@code{operating-system} und dem @code{arm64-disk-image}-Verbundsobjekt.

Aber genug vom Scheme-Wahnsinn. Was nützt die Image-Schnittstelle dem Nutzer
von Guix?

Sie können das ausführen:

@example
mathieu@@cervin:~$ guix system --list-image-types
Die verfügbaren Abbildtypen sind:

   - unmatched-raw
   - rock64-raw
   - pinebook-pro-raw
   - pine64-raw
   - novena-raw
   - hurd-raw
   - hurd-qcow2
   - qcow2
   - iso9660
   - uncompressed-iso9660
   - tarball
   - efi-raw
   - mbr-raw
   - docker
   - wsl2
   - raw-with-offset
   - efi32-raw
@end example

und indem Sie eine Betriebssystemkonfigurationsdatei mit einem auf
@code{pine64-barebones-os} aufbauenden @code{operating-system} schreiben,
können Sie Ihr Abbild nach Ihren Wünschen anpassen in einer Datei, sagen wir
@file{my-pine-os.scm}:

@lisp
(use-modules (gnu services linux)
             (gnu system images pine64))

(let ((base-os pine64-barebones-os))
  (operating-system
    (inherit base-os)
    (timezone "America/Indiana/Indianapolis")
    (services
     (cons
      (service earlyoom-service-type
               (earlyoom-configuration
                (prefer-regexp "icecat|chromium")))
      (operating-system-user-services base-os)))))
@end lisp

Führen Sie aus:

@example
guix system image --image-type=pine64-raw my-pine-os.scm
@end example

oder

@example
guix system image --image-type=hurd-raw my-hurd-os.scm
@end example

und Sie bekommen ein Abbild, das Sie direkt auf eine Festplatte kopieren und
starten können.

Ohne irgendetwas an @code{my-hurd-os.scm} zu ändern, bewirkt ein Aufruf

@example
guix system image --image-type=hurd-qcow2 my-hurd-os.scm
@end example

dass stattdessen ein Hurd-Abbild für QEMU erzeugt wird.

@node Sicherheitsschlüssel verwenden
@section Sicherheitsschlüssel verwenden
@cindex 2FA, Zwei-Faktor-Authentisierung
@cindex U2F, Universal 2nd Factor
@cindex Sicherheitsschlüssel, einrichten

Indem Sie Sicherheitsschlüssel einsetzen, können Sie sich besser
absichern. Diese stellen eine zweite Bestätigung Ihrer Identität dar, die
nicht leicht gestohlen oder kopiert werden kann, zumindest wenn der
Angreifer nur Fernzugriff ergattert hat. Sicherheitsschlüssel sind etwas,
was Sie haben, dagegen ist ein Geheimnis (eine Passphrase) etwas, was Sie
wissen. So sinkt das Risiko, dass sich jemand Fremdes als Sie ausgibt.

Mit der nachfolgenden Beispielkonfiguration wird vorgeführt, wie Sie mit
kleinstem Konfigurationsaufwand auf Ihrem Guix System einen
Yubico-Sicherheitsschlüssel einsetzen können. Wir hoffen, die Konfiguration
klappt auch bei anderen Sicherheitsschlüsseln, mit geringen Anpassungen.

@subsection Einrichten einer Zwei-Faktor-Authentisierung (2FA)

Dazu müssen Sie die udev-Regeln des Systems um auf Ihren
Sicherheitsschlüssel abgestimmte Regeln erweitern. Im Folgenden wird
gezeigt, wie Sie Ihre udev-Regeln um die Regeldatei
@file{lib/udev/rules.d/70-u2f.rules} aus dem @code{libfido2}-Paket im Modul
@code{(gnu packages security-token)} erweitern und Ihren Benutzer zur
zugehörigen Gruppe @samp{"plugdev"} hinzufügen:

@lisp
(use-package-modules … security-token …)
…
(operating-system
 …
 (users (cons* (user-account
               (name "ihr-benutzer")
               (group "users")
               (supplementary-groups
		'("wheel" "netdev" "audio" "video"
                  "plugdev"))           ;<- Systemgruppe hinzufügen
               (home-directory "/home/ihr-benutzer"))
              %base-user-accounts))
 …
 (services
  (cons*
   …
   (udev-rules-service 'fido2 libfido2 #:groups '("plugdev")))))
@end lisp

Rekonfigurieren Sie Ihr System. Danach melden Sie sich neu an zu einer
grafischen Sitzung, damit sich die neue Gruppe Ihres Benutzers auswirken
kann. Sie können jetzt prüfen, ob Ihr Sicherheitsschlüssel einsatzbereit
ist, indem Sie dies starten:

@example
guix shell ungoogled-chromium -- chromium chrome://settings/securityKeys
@end example

und nachsehen, ob Sie den Sicherheitsschlüssel mit dem Menüeintrag
„Sicherheitsschlüssel zurücksetzen“ neu machen können. Wenn es klappt,
gratulieren wir zu Ihrem nutzungsbereiten Sicherheitsschlüssel, mit dem Sie
nun ihn unterstützende Anwendungen für Zwei-Faktor-Authentisierung (2FA)
einrichten können.

@subsection Abschalten der OTP-Code-Erzeugung beim Yubikey
@cindex Yubikey-OTP deaktivieren
Wenn Sie einen Yubikey-Sicherheitsschlüssel verwenden und es Sie stört, dass
er unsinnige OTP-Codes erzeugt, wenn Sie ihn unabsichtlich anrühren (und Sie
damit am Ende den @samp{#guix}-Kanal zumüllen, während Sie mit Ihrem
Lieblings-IRC-Client an der Diskussion teilnehmen!), dann deaktivieren Sie
es einfach mit dem folgenden @command{ykman}-Befehl:

@example
guix shell python-yubikey-manager -- ykman config usb --force --disable OTP
@end example

Alternativ können Sie auch die Oberfläche mit dem @command{ykman-gui}-Befehl
aus dem Paket @code{yubikey-manager-qt} starten und entweder gleich die
ganze OTP-Anwendung für die USB-Schnittstelle abschalten oder, unter
@samp{Applications -> OTP}, die Konfiguration für Slot 1 löschen, die bei
der Yubico-OTP-Anwendung voreingestellt ist.

@subsection Yubikey verlangen, um eine KeePassXC-Datenbank zu entsperren
@cindex Yubikey, KeePassXC-Integration
Die Anwendung KeePassXC zur Verwaltung von Passwörtern kann mit Yubikeys
zusammenarbeiten, aber erst, wenn die udev-Regeln dafür auf Ihrem Guix
System vorliegen und nachdem Sie passende Einstellungen in der
Yubico-OTP-Anwendung zum Schlüssel vorgenommen haben.

Die erforderliche udev-Regeldatei liegt im Paket
@code{yubikey-personalization} und kann hiermit installiert werden:

@lisp
(use-package-modules … security-token …)
…
(operating-system
 …
 (services
  (cons*
   …
   (udev-rules-service 'yubikey yubikey-personalization))))
@end lisp

Sobald Sie Ihr System rekonfiguriert haben (und Ihren Yubikey neu verbunden
haben), sollten Sie anschließend die OTP-Challenge-Response-Anwendung für
Ihren Yubikey auf dessen Slot 2 einrichten, die von KeePassXC benutzt
wird. Das ist problemlos möglich mit dem grafischen Konfigurationsprogramm
Yubikey Manager, das Sie so aufrufen können:

@example
guix shell yubikey-manager-qt -- ykman-gui
@end example

Stellen Sie zunächst sicher, dass @samp{OTP} im Karteireiter
@samp{Interfaces} aktiviert ist. Begeben Sie sich dann zu @samp{Applications
-> OTP} und klicken Sie auf den Knopf @samp{Configure} im Abschnitt
@samp{Long Touch (Slot 2)}.  Wählen Sie @samp{Challenge-response} und geben
Sie einen geheimen Schlüssel entweder ein oder lassen Sie ihn
erzeugen. Anschließend klicken Sie auf den Knopf @samp{Finish}. Wenn Sie
noch einen zweiten Yubikey haben, den Sie als Ersatz einsetzen können
möchten, konfigurieren Sie ihn auf die gleiche Weise mit @emph{demselben}
geheimen Schlüssel.

Jetzt sollte Ihr Yubikey von KeePassXC erkannt werden. Er kann für eine
Datenbank hinzugefügt werden, indem Sie in KeePassXC im Menü @samp{Datenbank
-> Datenbank-Sicherheit...} öffnen und dort auf den Knopf @samp{Zusätzlichen
Schutz hinzufügen@tie{}...} klicken, dann auf @samp{Challenge-Response
hinzufügen} klicken und den Sicherheitsschlüssel aus der Auswahlliste wählen
und den @samp{OK}-Knopf anklicken, um die Einrichtung abzuschließen.

@node Dynamisches DNS als mcron-Auftrag
@section Dynamisches DNS als mcron-Auftrag

@cindex dynamisches DNS, DDNS
Wenn Sie von Ihrem Internetdienstanbieter nur dynamische IP-Adressen
bekommen, aber einen statischen Rechnernamen möchten, können Sie einen
Dienst für dynamisches @acronym{DNS, Domain Name System} einrichten (auch
bekannt unter der Bezeichnung @acronym{DDNS, Dynamic DNS}). Dieser ordnet
einem festen, „statischen“ Rechnernamen eine öffentliche, aber dynamische
(oft wechselnde) IP-Adresse zu. Es gibt davon mehrere Anbieter; im folgenden
mcron-Auftrag verwenden wir @url{https://duckdns.org, DuckDNS}. Er sollte
auch mit anderen Anbietern von dynamischem DNS funktionieren, die eine
ähnliche Schnittstelle zum Wechsel der IP-Adresse haben, etwa
@url{https://freedns.afraid.org/}, wenn Sie Kleinigkeiten anpassen.

So sieht der mcron-Auftrag dafür aus. Statt @var{DOMAIN} schreiben Sie Ihre
eigene Domain und den von DuckDNS der @var{DOMAIN} zugeordneten Token in die
Datei @file{/etc/duckdns/@var{DOMAIN}.token}.

@lisp
(define duckdns-job
  ;; IP der eigenen Domain alle 5 Minuten aktualisieren.
  #~(job '(next-minute (range 0 60 5))
	 #$(program-file
            "duckdns-update"
            (with-extensions (list guile-gnutls) ;nötig für (web client)
              #~(begin
                  (use-modules (ice-9 textual-ports)
                               (web client))
                  (let ((token (string-trim-both
                                (call-with-input-file "/etc/duckdns/@var{DOMAIN}.token"
                                  get-string-all)))
                        (query-template (string-append "https://www.duckdns.org/"
                                                       "update?domains=@var{DOMAIN}"
                                                       "&token=~a&ip=")))
                    (http-get (format #f query-template token))))))
         "duckdns-update"
         #:user "nobody"))
@end lisp

Der Auftrag muss in die Liste der mcron-Aufträge für Ihr System eingetragen
werden, etwa so:

@lisp
(operating-system
 (services
  (cons* (service mcron-service-type
           (mcron-configuration
             (jobs (list duckdns-job …))))
         …
         %base-services)))
@end lisp

@node Verbinden mit Wireguard VPN
@section Verbinden mit Wireguard VPN

Damit Sie sich mit einem Wireguard-VPN-Server verbinden können, müssen Sie
dafür sorgen, dass die dafür nötigen Kernel-Module in den Speicher
eingeladen werden und ein Paket bereitsteht, dass die unterstützenden
Netzwerkwerkzeuge dazu enthält (z.B.@: @code{wireguard-tools} oder
@code{network-manager}).

Hier ist ein Beispiel für eine Konfiguration für Linux-Libre < 5.6, wo sich
das Modul noch nicht im Kernel-Quellbaum befindet („out of tree“) und daher
von Hand geladen werden muss@tie{}– in nachfolgenden Kernelversionen ist das
Modul bereits eingebaut und @emph{keine} derartige Konfiguration ist nötig.

@lisp
(use-modules (gnu))
(use-service-modules desktop)
(use-package-modules vpn)

(operating-system
  ;; …
  (services (cons (simple-service 'wireguard-module
                                  kernel-module-loader-service-type
                                  '("wireguard"))
                  %desktop-services))
  (packages (cons wireguard-tools %base-packages))
  (kernel-loadable-modules (list wireguard-linux-compat)))
@end lisp

Nachdem Sie Ihr System rekonfiguriert haben, können Sie dann entweder die
Wireguard-Werkzeuge („Wireguard Tools“) oder NetworkManager benutzen, um
sich mit einem VPN-Server zu verbinden.

@subsection Die Wireguard Tools benutzen

Um Ihre Wireguard-Konfiguration zu testen, bietet es sich an,
@command{wg-quick} zu benutzen. Übergeben Sie einfach eine
Konfigurationsdatei @command{wg-quick up ./wg0.conf}. Sie können auch die
Konfigurationsdatei in @file{/etc/wireguard} platzieren und dann stattdessen
@command{wg-quick up wg0} ausführen.

@quotation Anmerkung
Seien Sie gewarnt, dass sein Autor diesen Befehl als ein schnell und
unsauber geschriebenes Bash-Skript bezeichnet hat.
@end quotation

@subsection NetworkManager benutzen

Dank der Unterstützung für Wireguard durch den NetworkManager können wir
über den Befehl @command{nmcli} eine Verbindung mit unserem VPN
herstellen. Bislang treffen wir in dieser Anleitung die Annahme, dass Sie
den Network-Manager-Dienst aus den @code{%desktop-services} benutzen. Wenn
Sie eine abweichende Konfiguration verwenden, müssen Sie unter Umständen
Ihre @code{services}-Liste abändern, damit ein
@code{network-manager-service-type} geladen wird, und Ihr Guix-System
rekonfigurieren.

Benutzen Sie den nmcli-Import-Befehl, um Ihre VPN-Konfiguration zu
importieren.

@example shell
# nmcli connection import type wireguard file wg0.conf
Verbindung »wg0« (edbee261-aa5a-42db-b032-6c7757c60fde) erfolgreich hinzugefügt.
@end example

Dadurch wird eine Konfigurationsdatei in
@file{/etc/NetworkManager/wg0.nmconnection} angelegt. Anschließend können
Sie sich mit dem Wireguard-Server verbinden:

@example shell
$ nmcli connection up wg0
Verbindung wurde erfolgreich aktiviert (aktiver D-Bus-Pfad: /org/freedesktop/NetworkManager/ActiveConnection/6)
@end example

Nach Voreinstellung wird sich NetworkManager automatisch beim Systemstart
verbinden. Um dieses Verhalten zu ändern, müssen Sie Ihre Konfiguration
bearbeiten:

@example shell
# nmcli connection modify wg0 connection.autoconnect no
@end example

Für Informationen speziell zu NetworkManager und Wireguard
@uref{https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-networkmanager/,siehe
diesen Blogeintrag von thaller}.

@node Fensterverwalter (Window Manager) anpassen
@section Fensterverwalter (Window Manager) anpassen
@cindex Fensterverwaltung (Window Manager, WM)

@menu
* StumpWM::                  StumpWM
* Sitzungen sperren::        Sitzungen sperren
@end menu

@node StumpWM
@subsection StumpWM
@cindex stumpwm

Sie können StumpWM mit einem Guix-System installieren, indem Sie die Pakete
@code{stumpwm} und optional auch @code{`(,stumpwm "lib")} in eine
Systemkonfigurationsdatei, z.B.@: @file{/etc/config.scm}, eintragen.

Eine Beispielkonfiguration kann so aussehen:

@lisp
(use-modules (gnu))
(use-package-modules wm)

(operating-system
  ;; …
  (packages (append (list sbcl stumpwm `(,stumpwm "lib"))
                    %base-packages)))
@end lisp

@cindex StumpWM-Schriftarten
Nach Voreinstellung benutzt StumpWM die Schriftarten von X11, die auf Ihrem
System klein oder verpixelt erscheinen mögen. Sie können das Problem
beheben, indem Sie das Lisp-Modul @code{sbcl-ttf-fonts} aus den Beiträgen zu
StumpWM („StumpWM Contrib“) als Systempaket installieren:

@lisp
(use-modules (gnu))
(use-package-modules fonts wm)

(operating-system
  ;; …
  (packages (append (list sbcl stumpwm `(,stumpwm "lib"))
                    sbcl-ttf-fonts font-dejavu %base-packages)))
@end lisp

Den folgenden Code fügen Sie in die Konfigurationsdatei von StumpWM
@file{~/.stumpwm.d/init.lisp} ein:

@lisp
(require :ttf-fonts)
(setf xft:*font-dirs* '("/run/current-system/profile/share/fonts/"))
(setf clx-truetype:+font-cache-filename+ (concat (getenv "HOME")
                                                 "/.fonts/font-cache.sexp"))
(xft:cache-fonts)
(set-font (make-instance 'xft:font :family "DejaVu Sans Mono"
                                   :subfamily "Book" :size 11))
@end lisp

@node Sitzungen sperren
@subsection Sitzungen sperren
@cindex Sitzungssperre

Abhängig von Ihrer Arbeitsumgebung ist das Sperren Ihres Bildschirms
vielleicht bereits eingebaut. Wenn nicht, müssen Sie es selbst
einrichten. Wenn Sie eine Arbeitsumgebung wie GNOME oder KDE benutzen, ist
Sperren normalerweise bereits möglich. Wenn Sie einen einfachen
Fensterverwalter („Window Manager“) wie StumpWM oder EXWM benutzen, müssen
Sie es vielleicht selbst einrichten.

@menu
* Xorg::                     Xorg
@end menu

@node Xorg
@subsubsection Xorg

Sofern Sie Xorg benutzen, können Sie mit dem Programm
@uref{https://www.mankier.com/1/xss-lock, xss-lock} den Bildschirm für Ihre
Sitzung sperren. xss-lock wird durch DPMS ausgelöst, was seit Xorg 1.8
automatisch aktiv ist, wenn zur Laufzeit des Kernels ACPI verfügbar ist.

Um xss-lock zu benutzen, können Sie es einfach ausführen und in den
Hintergrund versetzen, bevor Sie Ihren Fensterverwalter z.B.@: aus Ihrer
@file{~/.xsession} heraus starten:

@example
xss-lock -- slock &
exec stumpwm
@end example

In diesem Beispiel benutzt xss-lock das Programm @code{slock}, um die
eigentliche Sperrung des Bildschirms durchzuführen, wenn es den Zeitpunkt
dafür gekommen sieht, weil Sie z.B.@: Ihr Gerät in den Energiesparmodus
versetzen.

Damit slock aber überhaupt die Berechtigung dafür erteilt bekommt,
Bildschirme grafischer Sitzungen zu sperren, muss es als setuid-root
eingestellt sein, wodurch es Benutzer authentifizieren kann, außerdem
braucht es Einstellungen im PAM-Dienst. Um das bereitzustellen, tragen Sie
den folgenden Dienst in Ihre @file{config.scm} ein:

@lisp
(service screen-locker-service-type
         (screen-locker-configuration
          (name "slock")
          (program (file-append slock "/bin/slock"))))
@end lisp

Wenn Sie Ihren Bildschirm manuell sperren, z.B.@: indem Sie slock direkt
aufrufen, wenn Sie Ihren Bildschirm sperren wollen, ohne in den
Energiesparmodus zu wechseln, dann ist es eine gute Idee, das auch xss-lock
mitzuteilen, indem Sie @code{xset s activate} direkt vor slock ausführen.

@node Guix auf einem Linode-Server nutzen
@section Guix auf einem Linode-Server nutzen
@cindex linode, Linode

Um Guix auf einem durch @uref{https://www.linode.com, Linode}
bereitgestellten, „gehosteten“ Server zu benutzen, richten Sie zunächst
einen dort empfohlenen Debian-Server ein. Unsere Empfehlung ist, zum Wechsel
auf Guix mit der voreingestellten Distribution anzufangen. Erzeugen Sie Ihre
SSH-Schlüssel.

@example
ssh-keygen
@end example

Stellen Sie sicher, dass Ihr SSH-Schlüssel zur leichten Anmeldung auf dem
entfernten Server eingerichtet ist. Das können Sie leicht mit Linodes
grafischer Oberfläche zum Hinzufügen von SSH-Schlüsseln
bewerkstelligen. Gehen Sie dazu in Ihr Profil und klicken Sie auf die
Funktion zum Hinzufügen eines SSH-Schlüssels. Kopieren Sie dort hinein die
Ausgabe von:

@example
cat ~/.ssh/<benutzername>_rsa.pub
@end example

Fahren Sie den Linode-Knoten herunter.

Im Karteireiter für „Storage“ bei Linode verkleinern Sie das Laufwerk für
Debian. Empfohlen werden 30@tie{}GB freier Speicher. Klicken Sie
anschließend auf „Add a disk“ und tragen Sie Folgendes in das Formular ein:

@itemize @bullet
@item
Label: "Guix"

@item
Filesystem: ext4

@item
Wählen Sie als Größe den übrigen Speicherplatz.
@end itemize

Drücken Sie im Karteireiter „Configurations“ auf „Edit“. Unter „Block Device
Assignment“ klicken Sie auf „Add a Device“. Dort müsste @file{/dev/sdc}
stehen; wählen Sie das Laufwerk „Guix“. Speichern Sie die Änderungen.

Fügen Sie eine Konfiguration hinzu („Add a Configuration“) mit folgenden
Eigenschaften:
@itemize @bullet
@item
Label: Guix

@item
Kernel: GRUB 2 (Das steht ganz unten! Dieser Schritt ist @b{WICHTIG!})

@item
Block device assignment:

@item
@file{/dev/sda}: Guix

@item
@file{/dev/sdb}: swap

@item
Root device: @file{/dev/sda}

@item
Schalten Sie alle Dateisystem-/Boot-Helfer ab.
@end itemize

Starten Sie den Knoten jetzt wieder mit der Debian-Konfiguration. Sobald er
wieder läuft, verbinden Sie sich mittels SSH zu Ihrem Server über @code{ssh
root@@@var{<IP-Adresse-Ihres-Servers>}}. (Die IP-Adresse Ihres Servers
finden Sie in Linodes Übersichtsseite bei „Summary“.) Nun können Sie mit den
Schritten aus dem @ref{Aus Binärdatei installieren,,, guix.de,
Referenzhandbuch zu GNU Guix} weitermachen:

@example
sudo apt-get install gpg
wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 -qO - | gpg --import -
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh
guix pull
@end example

Nun wird es Zeit, eine Konfiguration für den Server anzulegen. Die
wichtigsten Informationen finden Sie hierunter. Speichern Sie die
Konfiguration als @file{guix-config.scm}.

@lisp
(use-modules (gnu)
             (guix modules))
(use-service-modules networking
                     ssh)
(use-package-modules admin
                     package-management
                     ssh
                     tls)

(operating-system
  (host-name "my-server")
  (timezone "America/New_York")
  (locale "en_US.UTF-8")
  ;; Dieser komisch aussehende Code wird eine grub.cfg
  ;; anlegen ohne den GRUB-Bootloader auf die
  ;; Platte zu installieren.
  (bootloader (bootloader-configuration
               (bootloader
                (bootloader
                 (inherit grub-bootloader)
                 (installer #~(const #true))))))
  (file-systems (cons (file-system
                        (device "/dev/sda")
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))


  (swap-devices (list "/dev/sdb"))


  (initrd-modules (cons "virtio_scsi"    ; Um die Platte zu finden
                        %base-initrd-modules))

  (users (cons (user-account
                (name "janedoe")
                (group "users")
                ;; Durch Hinzufügen zur "wheel"-Gruppe
                ;; wird das Konto zum Sudoer.
                (supplementary-groups '("wheel"))
                (home-directory "/home/janedoe"))
               %base-user-accounts))

  (packages (cons* openssh-sans-x
                   %base-packages))

  (services (cons*
             (service dhcp-client-service-type)
             (service openssh-service-type
                      (openssh-configuration
                       (openssh openssh-sans-x)
                       (password-authentication? #false)
                       (authorized-keys
                        `(("janedoe" ,(local-file "janedoe_rsa.pub"))
                          ("root" ,(local-file "janedoe_rsa.pub"))))))
             %base-services)))
@end lisp

Ersetzen Sie in der obigen Konfiguration aber folgende Felder:
@lisp
(host-name "my-server")       ; hier sollte Ihr Servername stehen
; Wenn Sie sich einen Linode-Server außerhalb der USA ausgesucht
; haben, finden Sie mit tzselect die richtige Zeitzonenangabe.
(timezone "America/New_York") ; Zeitzone ersetzen wenn nötig
(name "janedoe")              ; Ersetzen durch Ihren Benutzernamen
("janedoe" ,(local-file "janedoe_rsa.pub")) ; Ersetzen durch Ihren SSH-Schlüssel
("root" ,(local-file "janedoe_rsa.pub")) ; Ersetzen durch Ihren SSH-Schlüssel
@end lisp

Durch die letzte Zeile im obigen Beispiel können Sie sich als
Administratornutzer root auf dem Server anmelden und das anfängliche
Passwort für root festlegen (lesen Sie den Hinweis zur Anmeldung als root am
Ende dieses Rezepts). Nachdem das erledigt ist, können Sie die Zeile aus
Ihrer Konfiguration löschen und Ihr System rekonfigurieren, damit eine
Anmeldung als root nicht mehr möglich ist.

Kopieren Sie Ihren öffentlichen SSH-Schlüssel (z.B.@:
@file{~/.ssh/id_rsa.pub}) in die Datei
@file{@var{<Ihr-Benutzername>}_rsa.pub} und Ihre @file{guix-config.scm} ins
selbe Verzeichnis. Führen Sie dann diese Befehle in einem neuen Terminal
aus:

@example
sftp root@@<IP-Adresse-des-entfernten-Servers>
put /pfad/mit/dateien/<Benutzername>_rsa.pub .
put /pfad/mit/dateien/guix-config.scm .
@end example

Binden Sie mit Ihrem ersten Terminal das Guix-Laufwerk ein:

@example
mkdir /mnt/guix
mount /dev/sdc /mnt/guix
@end example

Aufgrund der Art und Weise, wie wir den Bootloader-Abschnitt von
@file{guix-config.scm} oben festgelegt haben, installieren wir GRUB nicht
vollständig. Stattdessen installieren wir nur unsere
GRUB-Konfigurationsdatei. Daher müssen wir ein bisschen von den anderen
GRUB-Einstellungen vom Debian-System kopieren:

@example
mkdir -p /mnt/guix/boot/grub
cp -r /boot/grub/* /mnt/guix/boot/grub/
@end example

Initialisieren Sie nun die Guix-Installation:

@example
guix system init guix-config.scm /mnt/guix
@end example

OK, fahren Sie Ihn jetzt herunter! Von der Linode-Konsole wählen Sie Booten
aus und wählen „Guix“.

Sobald es gestartet ist, sollten Sie sich über SSH anmelden können!
(Allerdings wird sich die Serverkonfiguration geändert haben.) Ihnen könnte
eine Fehlermeldung wie diese hier gezeigt werden:

@example
$ ssh root@@<server ip address>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:0B+wp33w57AnKQuHCvQP0+ZdKaqYrI/kyU7CfVbS7R4.
Please contact your system administrator.
Add correct host key in /home/joshua/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/joshua/.ssh/known_hosts:3
ECDSA host key for 198.58.98.76 has changed and you have requested strict checking.
Host key verification failed.
@end example

Löschen Sie entweder die ganze Datei @file{~/.ssh/known_hosts} oder nur die
ungültig gewordene Zeile, die mit der IP-Adresse Ihres Servers beginnt.

Denken Sie daran, Ihr Passwort und das Passwort des Administratornutzers
root festzulegen.

@example
ssh root@@<IP-Adresse-des-entfernten-Servers>
passwd  ; für das root-Passswort
passwd <benutzername> ; für das Passwort des normalen Benutzers
@end example

Es kann sein, dass die obigen Befehle noch nicht funktionieren. Wenn Sie
Probleme haben, sich aus der Ferne über SSH bei Ihrer Linode-Kiste
anzumelden, dann müssen Sie vielleicht Ihr anfängliches Passwort für root
und das normale Benutzerkonto festlegen, indem Sie auf die „Launch
Console“-Option in Ihrer Linode klicken. Wählen Sie „Glish“ statt
„Weblish“. Jetzt sollten Sie über SSH in Ihre Maschine ’reinkommen.

Hurra! Nun können Sie den Server herunterfahren, die Debian-Platte löschen
und Guix auf den gesamten verfügbaren Speicher erweitern. Herzlichen
Glückwunsch!

Übrigens, wenn Sie das Ergebnis jetzt als „Disk Image“ speichern, können Sie
neue Guix-Abbilder von da an leicht einrichten! Vielleicht müssen Sie die
Größe des Guix-Abbilds auf 6144MB verkleinern, um es als Abbild speichern zu
können. Danach können Sie es wieder auf die Maximalgröße vergrößern.

@node Guix auf einem Kimsufi-Server nutzen
@section Guix auf einem Kimsufi-Server nutzen
@cindex kimsufi, Kimsufi, OVH

Um Guix auf einem von @uref{https://www.kimsufi.com/, Kimsufi} gemieteten
Server einzusetzen, klicken Sie auf den Karteireiter zu Netboot und wählen
Sie dann rescue64-pro aus und starten Sie neu.

OVH wird Ihnen eine E-Mail mit den Anmeldedaten schicken, damit Sie sich
über SSH auf ein Debian-System verbinden können.

Folgen Sie nun den Anweisungen zur Installation von Guix aus einer
Binärdatei (siehe @ref{Aus Binärdatei installieren,,, guix.de,
Referenzhandbuch zu GNU Guix}):

@example
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
./guix-install.sh
guix pull
@end example

Partitionieren Sie nun die Laufwerke und formatieren Sie sie, aber erst
nachdem Sie das RAID-Array angehalten haben:

@example
mdadm --stop /dev/md127
mdadm --zero-superblock /dev/sda2 /dev/sdb2
@end example

Löschen Sie die Laufwerksinhalte und richten Sie die Partitionen ein; wir
erzeugen ein RAID-1-Array.

@example
wipefs -a /dev/sda
wipefs -a /dev/sdb

parted /dev/sda --align=opt -s -m -- mklabel gpt
parted /dev/sda --align=opt -s -m -- \
 mkpart bios_grub 1049kb 512MiB \
 set 1 bios_grub on
parted /dev/sda --align=opt -s -m -- \
 mkpart primary 512MiB -512MiB
 set 2 raid on
parted /dev/sda --align=opt -s -m -- mkpart primary linux-swap 512MiB 100%

parted /dev/sdb --align=opt -s -m -- mklabel gpt
parted /dev/sdb --align=opt -s -m -- \
     mkpart bios_grub 1049kb 512MiB \
     set 1 bios_grub on
parted /dev/sdb --align=opt -s -m -- \
     mkpart primary 512MiB -512MiB \
     set 2 raid on
parted /dev/sdb --align=opt -s -m -- mkpart primary linux-swap 512MiB 100%
@end example

Legen Sie das Array an:

@example
mdadm --create /dev/md127 --level=1 --raid-disks=2 \
  --metadata=0.90 /dev/sda2 /dev/sdb2
@end example

Legen Sie nun Dateisysteme auf diesen Partitionen an, angefangen mit der
Boot-Partition:

@example
mkfs.ext4  /dev/sda1
mkfs.ext4  /dev/sdb1
@end example

Dann die Wurzelpartition:

@example
mkfs.ext4 /dev/md127
@end example

Initialisieren Sie die Swap-Partitionen:

@example
mkswap /dev/sda3
swapon /dev/sda3
mkswap /dev/sdb3
swapon /dev/sdb3
@end example

Binden Sie das Guix-Laufwerk ein:

@example
mkdir /mnt/guix
mount /dev/md127 /mnt/guix
@end example

Der nächste Schritt ist, in eine Datei @file{os.scm} eine
Betriebssystemdeklaration zu schreiben, zum Beispiel:

@lisp
(use-modules (gnu) (guix))
(use-service-modules networking ssh vpn virtualization sysctl admin mcron)
(use-package-modules ssh tls tmux vpn virtualization)

(operating-system
  (host-name "kimsufi")

  (bootloader (bootloader-configuration
	       (bootloader grub-bootloader)
	       (targets (list "/dev/sda" "/dev/sdb"))
	       (terminal-outputs '(console))))

  ;; Wir brauchen ein Kernel-Modul für RAID-1 (d.h. "spiegeln").
  (initrd-modules (cons* "raid1"  %base-initrd-modules))

  (mapped-devices
   (list (mapped-device
          (source (list "/dev/sda2" "/dev/sdb2"))
          (target "/dev/md127")
          (type raid-device-mapping))))

  (swap-devices
   (list (swap-space
          (target "/dev/sda3"))
         (swap-space
          (target "/dev/sdb3"))))

  (issue
   ;; Voreingestellte Botschaft für /etc/issue.
   "\
Hier ist das GNU-System bei Kimsufi.  Willkommen.\n")

  (file-systems (cons* (file-system
		         (mount-point "/")
		         (device "/dev/md127")
		         (type "ext4")
		         (dependencies mapped-devices))
		       %base-file-systems))

  (users (cons (user-account
	        (name "guix")
	        (comment "guix")
	        (group "users")
	        (supplementary-groups '("wheel"))
	        (home-directory "/home/guix"))
	       %base-user-accounts))

  (sudoers-file
   (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
guix ALL=(ALL) NOPASSWD:ALL\n"))

  ;; Global installierte Pakete.
  (packages (cons* tmux gnutls wireguard-tools %base-packages))
  (services
   (cons*
    (service static-networking-service-type
	     (list (static-networking
		    (addresses (list (network-address
				      (device "enp3s0")
				      (value "@var{Server-IP-Adresse}/24"))))
		    (routes (list (network-route
				   (destination "default")
				   (gateway "@var{Server-Netzwerkzugang}"))))
		    (name-servers '("213.186.33.99")))))

    (service unattended-upgrade-service-type)

    (service openssh-service-type
	     (openssh-configuration
	      (openssh openssh-sans-x)
	      (permit-root-login #f)
	      (authorized-keys
	       `(("guix" ,(plain-file "@var{SSH-Name-des-Schlüssels.pub}"
                                      "@var{SSH-Inhalt-öffentl-Schlüssel}"))))))
    (modify-services %base-services
      (sysctl-service-type
       config =>
       (sysctl-configuration
	(settings (append '(("net.ipv6.conf.all.autoconf" . "0")
			    ("net.ipv6.conf.all.accept_ra" . "0"))
			  %default-sysctl-settings))))))))
@end lisp

Vergessen Sie nicht, anstelle der Variablen @var{Server-IP-Adresse},
@var{Server-Netzwerkzugang}, @var{SSH-Name-des-Schlüssels} und
@var{SSH-Inhalt-öffentl-Schlüssel} die für Sie zutreffenden Werte zu
schreiben.

Der Netzwerkzugang (Gateway) ist die letzte nutzbare IP in Ihrem Block. Wenn
Sie z.B.@: einen Server mit IP @samp{37.187.79.10} haben, dann ist sein
Gateway @samp{37.187.79.254}.

Übertragen Sie Ihre Datei mit Betriebssystemdeklaration @file{os.scm} auf
den Server mittels des Befehls @command{scp} oder @command{sftp}.

Bleibt nur noch, Guix mit @code{guix system init} zu installieren und neu zu
starten.

Aber das klappt nur, wenn wir vorher ein Chroot aufsetzen, weil die
Wurzelpartition des laufenden Rettungssystems („rescue“) auf einer
aufs-Partition eingebunden ist und, wenn Sie es versuchen, die Installation
von Guix beim GRUB-Schritt fehlschlägt mit der Meldung, der kanonische Pfad
von „aufs“ sei nicht ermittelbar.

Installieren Sie die Pakete, die im Chroot benutzt werden:

@example
guix install bash-static parted util-linux-with-udev coreutils guix
@end example

Dann legt folgender Befehl die Verzeichnisse für das Chroot an:

@example
cd /mnt && \
mkdir -p bin etc gnu/store root/.guix-profile/ root/.config/guix/current \
  var/guix proc sys dev
@end example

Kopieren Sie die resolv.conf des Wirtssystems in die Chroot:

@example
cp /etc/resolv.conf etc/
@end example

Binden Sie die blockorientierten Speichermedien, den Store, seine Datenbank
sowie die aktuelle Guix-Konfiguration ein:

@example
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev
mount --rbind /var/guix/ var/guix/
mount --rbind /gnu/store gnu/store/
mount --rbind /root/.config/ root/.config/
mount --rbind /root/.guix-profile/bin/ bin
mount --rbind /root/.guix-profile root/.guix-profile/
@end example

Betreten Sie ein Chroot in /mnt und installieren Sie das System:

@example
chroot /mnt/ /bin/bash

guix system init /root/os.scm /guix
@end example

Schlussendlich können Sie in der Web-Oberfläche von @samp{netboot} auf
@samp{boot to disk} wechseln und neu starten (auch das tun Sie über die
Web-Oberfläche).

Nach ein paar Minuten Wartezeit können Sie versuchen, Ihren Server mit SSH
zu betreten: @code{ssh guix@@@var{Server-IP-Adresse} -i
@var{Pfad-zu-Ihrem-SSH-Schlüssel}}

Sie sollten nun ein nutzbares Guix-System auf Kimsufi am Laufen haben; wir
gratulieren!

@node Bind-Mounts anlegen
@section Bind-Mounts anlegen

Um ein Dateisystem per „bind mount“ einzubinden, braucht man zunächst ein
paar Definitionen. Fügen Sie diese noch vor dem
@code{operating-system}-Abschnitt Ihrer Systemdefinition ein. In diesem
Beispiel binden wir ein Verzeichnis auf einem Magnetfestplattenlaufwerk an
@file{/tmp}, um die primäre SSD weniger abzunutzen, ohne dass wir extra eine
ganze Partition für @file{/tmp} erzeugen müssen.

Als Erstes sollten wir das Quelllaufwerk definieren, wo wir das Verzeichnis
für den Bind-Mount unterbringen. Dann kann der Bind-Mount es als
Abhängigkeit benutzen.

@lisp
(define quelllaufwerk ;; "quelllaufwerk" kann man nennen, wie man will
   (file-system
    (device (uuid "hier kommt die UUID hin"))
    (mount-point "/hier-der-pfad-zur-magnetfestplatte")
    (type "ext4"))) ;; Legen Sie den dazu passenden Typ fest.
@end lisp

Auch das Quellverzeichnis muss so definiert werden, dass Guix es nicht für
ein reguläres blockorientiertes Gerät hält, sondern es als Verzeichnis
erkennt.
@lisp
;; Dem "quellverzeichnis" kann man einen beliebigen gültigen Variablennamen geben.
(define (%quellverzeichnis) "/hier-der-pfad-zur-magnetfestplatte/tmp")
@end lisp

In der Definition des @code{file-systems}-Felds müssen wir die Einbindung
einfügen.

@lisp
(file-systems (cons*

                …<hier würden andere Laufwerke stehen>…

                ;; Muss dem Namen entsprechen, den Sie vorher ans Quelllaufwerk
                ;; vergeben haben.
                quelllaufwerk

                (file-system
                 ;; Geben Sie Acht, dass das "quellverzeichnis" so heißt wie in
                 ;; der Definition vorher.
                 (device (%quellverzeichnis))
                 (mount-point "/tmp")
                 ;; Wir binden ein Verzeichnis und keine Partition ein, daher
                 ;; muss dieser Typ "none" sein.
                 (type "none")
                 (flags '(bind-mount))
                 ;; Geben Sie Acht, dass "quelllaufwerk" dem Namen entspricht,
                 ;; den Sie der Variablen für das Laufwerk gegeben haben.
                 (dependencies (list quelllaufwerk))
                 )

                 …<hier würden andere Laufwerke stehen>…

                ))
@end lisp

@node Substitute über Tor beziehen
@section Substitute über Tor beziehen

Der Guix-Daemon kann einen HTTP-Proxy benutzen, wenn er Substitute
herunterlädt. Wir wollen ihn hier so konfigurieren, dass Substitute über Tor
bezogen werden.

@quotation Warnung
@emph{Nicht aller} Datenverkehr des Guix-Daemons wird dadurch über Tor
laufen! Nur HTTP und HTTPS durchläuft den Proxy, @emph{nicht} so ist es bei
FTP, dem Git-Protokokl, SSH etc.@:, diese laufen weiterhin durch’s
„Clearnet“. Die Konfiguration ist also @emph{nicht} narrensicher; ein Teil
Ihres Datenverkehrs wird gar nicht über Tor geleitet. Verwenden Sie sie nur
auf Ihr eigenes Risiko!

Beachten Sie außerdem, dass sich die hier beschriebene Prozedur nur auf
Paketsubstitute bezieht. Wenn Sie Ihre Guix-Distribution mit @command{guix
pull} aktualisieren, müssen Sie noch immer @command{torsocks} benutzen, wenn
Sie die Verbindung zu Guix’ Git-Repository über Tor leiten wollen.
@end quotation

Der Substitutserver von Guix ist als Onion-Dienst verfügbar, wenn Sie ihn
benutzen möchten, um Ihre Substitute über Tor zu laden, dann konfigurieren
Sie Ihr System wie folgt:

@lisp
(use-modules (gnu))
(use-service-module base networking)

(operating-system
  …
  (services
    (cons
      (service tor-service-type
              (tor-configuration
                (config-file (plain-file "tor-config"
                                         "HTTPTunnelPort 127.0.0.1:9250"))))
      (modify-services %base-services
        (guix-service-type
          config => (guix-configuration
                      (inherit config)
                      ;; Onion-Dienst von ci.guix.gnu.org
                      (substitute-urls "\
@value{SUBSTITUTE-TOR-URL}")
                      (http-proxy "http://localhost:9250")))))))
@end lisp

Dadurch wird ständig ein Tor-Prozess laufen, der einen HTTP-CONNECT-Tunnel
für die Nutzung durch den @command{guix-daemon} bereitstellt. Der Daemon
kann andere Protokolle als HTTP(S) benutzen, um entfernte Ressourcen
abzurufen, und Anfragen über solche Protokolle werden Tor @emph{nicht}
durchlaufen, weil wir hier nur einen HTTP-Tunnel festlegen. Beachten Sie,
dass wir für @code{substitutes-urls} HTTPS statt HTTP benutzen, sonst würde
es nicht funktionieren. Dabei handelt es sich um eine Einschränkung von Tors
Tunnel; vielleicht möchten Sie stattdessen @command{privoxy} benutzen, um
dieser Einschränkung nicht zu unterliegen.

Wenn Sie Substitute nicht immer, sondern nur manchmal über Tor beziehen
wollen, dann überspringen Sie das mit der @code{guix-configuration}. Führen
Sie einfach das hier aus, wenn Sie ein Substitut über den Tor-Tunnel laden
möchten:

@example
sudo herd set-http-proxy guix-daemon http://localhost:9250
guix build \
  --substitute-urls=@value{SUBSTITUTE-TOR-URL} @dots{}
@end example

@node NGINX mit Lua konfigurieren
@section NGINX mit Lua konfigurieren
@cindex nginx, lua, openresty, resty

NGINX lässt sich mit Lua-Skripts erweitern.

Guix stellt einen NGINX-Dienst bereit, mit dem das Lua-Modul und bestimmte
Lua-Pakete geladen werden können, so dass Anfragen beantwortet werden, indem
Lua-Skripte ausgewertet werden.

Folgendes Beispiel zeigt eine Systemdefinition mit Einstellungen, um das
Lua-Skript @file{index.lua} bei HTTP-Anfragen an den Endpunkt
@uref{http://localhost/hello} auszuwerten:

@example
local shell = require "resty.shell"

local stdin = ""
local timeout = 1000  -- ms
local max_size = 4096  -- byte

local ok, stdout, stderr, reason, status =
   shell.run([[/run/current-system/profile/bin/ls /tmp]], stdin, timeout, max_size)

ngx.say(stdout)
@end example

@lisp
(use-modules (gnu))
(use-service-modules #;… web)
(use-package-modules #;… lua)
(operating-system
  ;; …
  (services
   ;; …
   (service nginx-service-type
            (nginx-configuration
             (modules
              (list
               (file-append nginx-lua-module "/etc/nginx/modules/ngx_http_lua_module.so")))
             (lua-package-path (list lua-resty-core
                                     lua-resty-lrucache
                                     lua-resty-signal
                                     lua-tablepool
                                     lua-resty-shell))
             (lua-package-cpath (list lua-resty-signal))
             (server-blocks
              (list (nginx-server-configuration
                     (server-name '("localhost"))
                     (listen '("80"))
                     (root "/etc")
                     (locations (list
                                 (nginx-location-configuration
                                  (uri "/hello")
                                  (body (list #~(format #f "content_by_lua_file ~s;"
                                                        #$(local-file "index.lua"))))))))))))))
@end lisp

@node Musik-Server mit Bluetooth-Audio
@section Musik-Server mit Bluetooth-Audio
@cindex mpd
@cindex Musik-Server, ohne Oberfläche
@cindex Bluetooth, ALSA-Konfiguration

Bei MPD, dem Music Player Daemon, handelt es sich um eine vielseitige
Server-Anwendung, mit der Sie Musik spielen lassen. Client-Programme an
verschiedenen Maschinen im Netzwerk@tie{}– einem Mobiltelefon, Laptop oder
einer Desktop-Workstation@tie{}– können sich damit verbinden und die
Wiedergabe der Tondateien steuern, die Ihre eigene Musiksammung
enthalten. MPD dekodiert die Tondateien und spielt sie auf einer oder
mehreren Ausgaben ab.

MPD ist so voreingestellt, dass auf dem Standardtonausgabegerät abgespielt
wird. Im folgenden Beispiel legen wir eine interessantere Architektur fest:
einen Musik-Server, der ohne Bildschirm betrieben werden kann. Eine
grafische Oberfläche fehlt, ein Pulseaudio-Daemon ist auch nicht da und es
gibt keine lokale Tonausgabe. Stattdessen richten wir MPD für zwei Ausgaben
ein: zum einen ein Bluetooth-Lautsprecher, zum anderen ein Web-Server, der
Audio an Mediaplayer streamen kann.

Bluetooth einzurichten, ist oft eher frustrierend. Sie müssen Ihr
Bluetooth-Gerät koppeln und dabei beachten, dass zum Gerät automatisch eine
Verbindung aufgebaut sein soll, sobald es an ist. Das können Sie mit dem
Bluetooth-Systemdienst umsetzen, der von der Prozedur
@code{bluetooth-service} geliefert wird.

Rekonfigurieren Sie Ihr System mit mindestens den folgenden Diensten und
Paketen:

@lisp
(operating-system
  ;; …
  (packages (cons* bluez bluez-alsa
                   %base-packages))
  (services
   ;; …
   (dbus-service #:services (list bluez-alsa))
   (bluetooth-service #:auto-enable? #t)))
@end lisp

Starten Sie den @code{bluetooth}-Dienst und benutzen Sie dann
@command{bluetoothctl}, um einen Scan nach Bluetooth-Geräten
durchzuführen. Versuchen Sie, Ihren Bluetooth-Lautsprecher unter dem
schwedischen Büfett aus anderen Smart-Home-Gerätschaften Ihrer Nachbarn
auszumachen, und merken Sie sich dessen Device-ID in der angezeigten
Liste. Das einmal zu machen, genügt:

@example
$ bluetoothctl 
[NEW] Controller 00:11:22:33:95:7F BlueZ 5.40 [default]

[bluetooth]# power on
[bluetooth]# Changing power on succeeded

[bluetooth]# agent on
[bluetooth]# Agent registered

[bluetooth]# default-agent
[bluetooth]# Default agent request successful

[bluetooth]# scan on
[bluetooth]# Discovery started
[CHG] Controller 00:11:22:33:95:7F Discovering: yes
[NEW] Device AA:BB:CC:A4:AA:CD My Bluetooth Speaker
[NEW] Device 44:44:FF:2A:20:DC My Neighbor's TV
…

[bluetooth]# pair AA:BB:CC:A4:AA:CD
Attempting to pair with AA:BB:CC:A4:AA:CD
[CHG] Device AA:BB:CC:A4:AA:CD Connected: yes

[Mein Bluetooth-Lautsprecher]# [CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110b-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110c-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD UUIDs: 0000110e-0000-1000-8000-00xxxxxxxxxx
[CHG] Device AA:BB:CC:A4:AA:CD Paired: yes
Pairing successful

[CHG] Device AA:BB:CC:A4:AA:CD Connected: no

[bluetooth]# 
[bluetooth]# trust AA:BB:CC:A4:AA:CD
[bluetooth]# [CHG] Device AA:BB:CC:A4:AA:CD Trusted: yes
Changing AA:BB:CC:A4:AA:CD trust succeeded

[bluetooth]# 
[bluetooth]# connect AA:BB:CC:A4:AA:CD
Attempting to connect to AA:BB:CC:A4:AA:CD
[bluetooth]# [CHG] Device AA:BB:CC:A4:AA:CD RSSI: -63
[CHG] Device AA:BB:CC:A4:AA:CD Connected: yes
Connection successful

[My Bluetooth Speaker]# scan off
[CHG] Device AA:BB:CC:A4:AA:CD RSSI is nil
Discovery stopped
[CHG] Controller 00:11:22:33:95:7F Discovering: no
@end example

Wir gratulieren: Sie bekommen jetzt eine automatische Verbindung zu Ihrem
Bluetooth-Speaker!

Es wird Zeit, ALSA einzurichten. Dabei müssen Sie es anweisen, das
Bluetooth-Modul @emph{bluealsa} zu verwenden, so dass Sie ein ALSA-pcm-Gerät
definieren können, das Ihrem Bluetooth-Lautsprecher entspricht. Wenn Ihr
Server keine Bedienelemente haben soll, ist es einfacher, wenn Sie
@emph{bluealsa} mit einem festen Bluetooth-Gerät verbinden lassen, statt mit
Pulseaudio ein Umschalten der Streams einzurichten. ALSA einzurichten, geht
so: Wir schreiben eine passende @code{alsa-configuration} für den
@code{alsa-service-type}. In der Konfiguration deklarieren Sie den
@code{pcm}-Typ @code{bluealsa} aus dem Modul @code{bluealsa} des Pakets
@code{bluez-alsa}. Für diesen Typ definieren Sie dann ein @code{pcm}-Gerät
für Ihren Bluetooth-Lautsprecher.

Was bleibt, ist, MPD die Audiodaten an dieses ALSA-Gerät schicken zu
lassen. Zusätzlich fügen wir eine zweite MPD-Ausgabe hinzu, womit die
aktuell abgespielten Tondateien auch als Stream über einen Web-Server auf
Port 8080 dargeboten werden. Es ermöglicht, dass man mit anderen Geräten im
Netzwerk einen tauglichen Mediaplayer die Daten vom HTTP-Server, auf Port
8080, abspielen lässt, egal ob der Bluetooth-Lautsprecher läuft.

Es folgt ein Umriss, wie eine Betriebssystemdeklaration aussehen kann, die
die oben genannten Aufgaben erfüllen dürfte:

@lisp
(use-modules (gnu))
(use-service-modules audio dbus sound #;… etc)
(use-package-modules audio linux #;… etc)
(operating-system
  ;; …
  (packages (cons* bluez bluez-alsa
                   %base-packages))
  (services
   ;; …
   (service mpd-service-type
            (mpd-configuration
             (user "ihr-benutzername")
             (music-dir "/pfad/zu/ihrer/musik")
             (address "192.168.178.20")
             (outputs (list (mpd-output
                             (type "alsa")
                             (name "MPD")
                             (extra-options
                              ;; Der Name muss derselbe sein wie in der
                              ;; ALSA-Konfiguration unten.
                              '((device . "pcm.btspeaker"))))
                            (mpd-output
                             (type "httpd")
                             (name "streaming")
                             (enabled? #false)
                             (always-on? #true)
                             (tags? #true)
                             (mixer-type 'null)
                             (extra-options
                              '((encoder . "vorbis")
                                (port    . "8080")
                                (bind-to-address . "192.168.178.20")
                                (max-clients . "0") ;keine Begrenzung
                                (quality . "5.0")
                                (format  . "44100:16:1"))))))))
   (dbus-service #:services (list bluez-alsa))
   (bluetooth-service #:auto-enable? #t)
   (service alsa-service-type
            (alsa-configuration
             (pulseaudio? #false) ;brauchen wir nicht
             (extra-options
              #~(string-append "\
# Bluetooth-Audiogerätetyp \"bluealsa\" aus dem bluealsa-Modul deklarieren
pcm_type.bluealsa @{
    lib \""
#$(file-append bluez-alsa "/lib/alsa-lib/libasound_module_pcm_bluealsa.so") "\"
@}

# Control device type \"bluealsa\" aus demselben Modul deklarieren
ctl_type.bluealsa @{
    lib \""
#$(file-append bluez-alsa "/lib/alsa-lib/libasound_module_ctl_bluealsa.so") "\"
@}

# Das eigentliche Bluetooth-Audiogerät definieren.
pcm.btspeaker @{
    type bluealsa
    device \"AA:BB:CC:A4:AA:CD\" # Unique Device Identifier
    profile \"a2dp\"
@}

# Einen zugehörigen Controller definieren.
ctl.btspeaker @{
    type bluealsa
@}
"))))))
@end lisp

Genießen Sie nun, wie die Musik aus dem MPD-Client Ihrer Wahl erschallt,
oder einem Mediaplayer, der über HTTP streamen kann!


@c *********************************************************************
@node Container
@chapter Container

Durch den Linux-Kernel werden den Systemprozessen zahlreiche gemeinsame
Ressourcen zur Verfügung gestellt, etwa eine gemeinsame Sicht auf das
Dateisystem, auf andere Prozesse, Netzwerkgeräte, Benutzer- und
Gruppenidentitäten und noch mehr. Seit Linux 3.19 ist es möglich, dass
Benutzer einige dieser Ressourcen trennen und ausgewählten Prozessen (und
deren Kindprozessen) eine andere Sicht auf das System geben.

Wenn ein Prozess zum Beispiel einen getrennten @code{mount}-Namensraum
bekommt, hat er eine eigene Sicht auf das Dateisystem@tie{}– in seiner Welt
kann er nur Verzeichnisse sehen, die in seinen @code{mount}-Namensraum
eingebunden worden sind. Wenn ein Prozess über seinen eigenen
@code{proc}-Namensraum verfügt, scheint es, als sei er der einzige Prozess,
der auf dem System läuft, und seine Prozesskennung ist die PID 1.

Guix bringt diese Kernelfunktionen für völlig isolierte Umgebungen und sogar
Guix System in Containern zum Einsatz@tie{}– Container sind wie
leichtgewichtige virtuelle Maschinen, die denselben Kernel wie das
Wirtssystem benutzen. Daraus können Sie besonders dann Ihren Nutzen ziehen,
wenn Sie Guix auf einer Fremddistribution verwenden, denn so können Sie
ausschließen, dass die systemweit zugänglichen fremden Bibliotheken und
Konfigurationsdateien störenden Einfluss hätten.

@menu
* Guix-Container::           Völlig isolierte Umgebungen.
* Container mit Guix System::  Ein System in Ihrem System.
@end menu

@node Guix-Container
@section Guix-Container

Der einfachste Einstieg ist, @command{guix shell} mit der
Befehlszeilenoption @option{--container} aufzurufen. Siehe @ref{Aufruf von
guix shell,,, guix.de, Referenzhandbuch zu GNU Guix} für eine Referenz der
möglichen Optionen.

Folgende Befehle legen einen minimalen Shell-Prozess an, bei dem die meisten
Namensräume vom übrigen System getrennt sind. Das aktuelle
Arbeitsverzeichnis bleibt für den Prozess sichtbar, aber das restliche
Dateisystem ist unzugänglich. Diese äußerste Isolation kann sehr hilfreich
sein, wenn Sie jeglichen Einfluss durch Umgebungsvariable, global
installierte Bibliotheken oder Konfigurationsdateien ausschließen möchten.

@example
guix shell --container
@end example

Diese Umgebung ist kahl und leer. Sie haben in der brachen Umgebung nicht
einmal die GNU coreutils und müssen zu ihrer Erkundung mit den in die Shell
eingebauten Werkzeugen vorliebnehmen. Selbst das Verzeichnis
@file{/gnu/store} hat seine für gewöhnlich gigantischen Ausmaße verloren und
ist nur mehr ein Schatten seiner selbst.

@example sh
$ echo /gnu/store/*
/gnu/store/…-gcc-10.3.0-lib
/gnu/store/…-glibc-2.33
/gnu/store/…-bash-static-5.1.8
/gnu/store/…-ncurses-6.2.20210619
/gnu/store/…-bash-5.1.8
/gnu/store/…-profile
/gnu/store/…-readline-8.1.1
@end example

@cindex Container verlassen
In einer solchen Umgebung gibt es nichts für Sie zu tun außer die Umgebung
wieder zu verlassen. Das geht, indem Sie @key{^D} drücken oder
@command{exit} aufrufen, womit die eingeschränkte Shell-Umgebung ihr Ende
findet.

@cindex Verzeichnisse zugänglich machen, Container
@cindex geteilte Verzeichnisse, Container
@cindex Freigaben, Container
Sie können zusätzliche Verzeichnisse in der Container-Umgebung zugänglich
machen. Verwenden Sie dazu @option{--expose=VERZEICHNIS} für eine
Verzeichniseinbindung nur mit Lesezugriff innerhalb des Containers oder
verwenden Sie @option{--share=VERZEICHNIS} für Schreibzugriff. Mit einem
zusätzlichen Argument nach dem Verzeichnisnamen können Sie den Namen
festlegen, der dem Verzeichnis innerhalb des Containers zugeordnet
wird. Folgendes Beispiel zeigt, wie Sie das Verzeichnis @file{/etc} aus dem
Wirtssystem auf @file{/das/wirtssystem/etc} innerhalb eines Containers
abbilden, in dem die GNU coreutils installiert sind.

@example sh
$ guix shell --container --share=/etc=/das/wirtssystem/etc coreutils
$ ls /das/wirtssystem/etc
@end example

Gleichermaßen können Sie verhindern, dass das aktuelle Arbeitsverzeichnis
eine Zuordnung in den Container bekommt, indem Sie die Befehlszeilenoption
@option{--no-cwd} angeben. Es ist eine gute Idee, ein Verzeichnis anzulegen,
das innerhalb des Containers das Persönliche Verzeichnis (auch
„Home-Verzeichnis“) ist. Aus diesem heraus lassen Sie die Shell für den
Container starten.

@cindex Systembibliotheken verbergen, Container
@cindex inkompatible ABI beheben, Container
Auf einem fremden System ist es möglich, in einer Container-Umgebung
Software zu kompilieren, die mit den Bibliotheken des Systems oder mit
dessen Compiler-Toolchain inkompatibel ist. In der Forschung kommt es
häufiger vor, dass man in einer R-Sitzung Pakete installieren möchte. Ohne
Container ist es gut möglich, dass die Compiler-Toolchain des Fremdsystems
und dessen inkompatible Bibliotheken Vorrang haben und die Binärdateien
@emph{nicht} zusammenpassen und in R @emph{nicht} benutzt werden können. In
einer Container-Shell gibt es das Problem @emph{nicht}, denn die
Bibliotheken und Programme des äußeren Systems sind schlicht gar nicht da,
weil der @code{mount}-Namensraum getrennt ist.

Schauen wir uns ein umfassendes Manifest für eine komfortable
R-Entwicklungsumgebung an:

@lisp
(specifications->manifest
  (list "r-minimal"

        ;; grundlegende Pakete
        "bash-minimal"
        "glibc-locales"
        "nss-certs"

        ;; Befehlszeilenwerkzeuge, die man oft braucht, sonst
        ;; wäre der Container so gut wie leer.
        "coreutils"
        "grep"
        "which"
        "wget"
        "sed"

        ;; R-Programme für Markdown
        "pandoc"

        ;; Toolchain und häufige Bibliotheken für "install.packages"
        "gcc-toolchain@@10"
        "gfortran-toolchain"
        "gawk"
        "tar"
        "gzip"
        "unzip"
        "make"
        "cmake"
        "pkg-config"
        "cairo"
        "libxt"
        "openssl"
        "curl"
        "zlib"))
@end lisp

Nehmen wir dieses Manifest und richten uns eine Container-Umgebung ein, in
der wir R ausführen. Der Einfachheit halber wollen wir den
@code{net}-Namensraum teilen und bekommen Zugriff auf die
Netzwerkschnittstellen des Wirtssystems. Damit können wir R-Pakete auf
traditionelle Weise aus ihrem Quellcode erstellen, ohne uns um inkompatible
ABIs oder sonstige Inkompatibilitäten sorgen zu müssen.

@example sh
$ guix shell --container --network --manifest=manifest.scm -- R

R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
Copyright (C) 2022 The R Foundation for Statistical Computing
…
> e <- Sys.getenv("GUIX_ENVIRONMENT")
> Sys.setenv(GIT_SSL_CAINFO=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_FILE=paste0(e, "/etc/ssl/certs/ca-certificates.crt"))
> Sys.setenv(SSL_CERT_DIR=paste0(e, "/etc/ssl/certs"))
> install.packages("Cairo", lib=paste0(getwd()))
…
* installing *source* package 'Cairo' ...
…
* DONE (Cairo)

The downloaded source packages are in
	'/tmp/RtmpCuwdwM/downloaded_packages'
> library("Cairo", lib=getwd())
> # success!
@end example

Containerisierte Shells einzusetzen ist lustig, aber wenn man mehr will als
einen einzelnen interaktiven Prozess, werden sie ein bisschen
umständlich. Manche Aufgaben sind einfach leichter zu lösen, wenn Sie sie
auf einem ordentlichen Guix-System als festem Fundament aufbauen. Dann
bekämen Sie Zugriff auf das reichhaltige Angebot von Systemdiensten. Im
nächsten Abschnitt wird Ihnen gezeigt, wie Sie eine vollständige Instanz von
Guix System in einem Container starten können.


@node Container mit Guix System
@section Container mit Guix System

Guix System stellt eine breite Palette von ineinandergreifenden
Systemdiensten zur Verfügung, welche Sie deklarativ konfigurieren, um ein
verlässliches und zustandsloses GNU-System als Fundament für Ihre weiteren
Aufgaben zu haben. Selbst wenn Sie Guix auf einer Fremddistribution
verwenden, können Sie von diesem Aufbau profitieren, indem Sie so ein System
in einem Container starten. Dabei greifen wir auf die Kernel-Funktionalität
getrennter Namensräume zurück, die im vorigen Abschnitt genannt wurde. Durch
sie wird die erstellte Guix-System-Instanz vom Wirtssystem isoliert und nur
die Orte im Dateisystem freigegeben, die Sie ausdrücklich deklariert haben.

Der Unterschied zwischen einem Guix-System-Container und einem
Shell-Prozess, wie ihn @command{guix shell --container} anlegt, besteht in
mehreren wichtigen Einzelheiten. Während in einem Shell-Container der
containerisierte Prozess ein Bash-Shell-Prozess ist, wird in einem
Guix-System-Container Shepherd als PID 1 ausgeführt. In einem
Systemcontainer werden all die Systemdienste (siehe @ref{Dienste,,, guix.de,
Referenzhandbuch zu GNU Guix}) auf dieselbe Weise eingerichtet wie wenn Sie
Guix System in einer virtuellen Maschine oder auf echter Hardware
booten@tie{}– auch die Daemons, die durch GNU@tie{}Shepherd gestartet werden
(siehe @ref{Shepherd-Dienste,,, guix.de, Referenzhandbuch zu GNU Guix}) und
andere Arten, das System zu erweitern (siehe @ref{Dienstkompositionen,,,
guix.de, Referenzhandbuch zu GNU Guix}), sind die gleichen.

Dass ein Guix-System-Container eine Zunahme an Komplexität bedeute, lässt
sich leicht rechtfertigen, wenn Sie mit komplexeren Anwendungen zu tun haben
und deren höheren oder engeren Anforderungen an ihren
Ausführungskontext@tie{}– an Konfigurationsdateien, eigene Benutzerkonten,
Verzeichnisse für Zwischenspeicher oder Protokolldateien, etc. In Guix
System werden solche Anforderungen einer Software durch das Aufspielen von
Systemdiensten erfüllt.


@menu
* Ein Datenbank-Container::  Ein Datenbank-Container
* Netzwerkverbindungen im Container::  Netzwerkverbindungen im Container
@end menu

@node Ein Datenbank-Container
@subsection Ein Datenbank-Container

Ein geeignetes Beispiel wäre ein PostgreSQL-Datenbankserver. Die
Komplexität, ihn aufzusetzen, können Sie großenteils in einer verführerisch
kurzen Dienstdeklaration einfangen:

@lisp
(service postgresql-service-type
         (postgresql-configuration
          (postgresql postgresql-14)))
@end lisp

Eine vollumfängliche Betriebssystemdeklaration, die Sie für einen
Guix-System-Container verwenden könnten, sähe in etwa so aus:

@lisp
(use-modules (gnu))
(use-package-modules databases)
(use-service-modules databases)

(operating-system
  (host-name "container")
  (timezone "Europe/Berlin")
  (file-systems (cons (file-system
                        (device (file-system-label "ist-egal"))
                        (mount-point "/")
                        (type "ext4"))
                      %base-file-systems))
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)
               (targets '("/dev/sdX"))))
  (services
   (cons* (service postgresql-service-type
                   (postgresql-configuration
                    (postgresql postgresql-14)
                    (config-file
                     (postgresql-config-file
                      (log-destination "stderr")
                      (hba-file
                       (plain-file "pg_hba.conf"
                                   "\
local	all	all			trust
host	all	all	10.0.0.1/32 	trust"))
                      (extra-config
                       '(("listen_addresses" "*")
                         ("log_directory"    "/var/log/postgresql")))))))
          (service postgresql-role-service-type
                   (postgresql-role-configuration
                    (roles
                     (list (postgresql-role
                            (name "test")
                            (create-database? #t))))))
          %base-services)))
@end lisp

Mit @code{postgresql-role-service-type} definieren wir eine Rolle namens
„test“ und lassen eine zugehörige Datenbank erzeugen, so dass wir gleich mit
dem Testen anfangen können ohne weitere manuelle Schritte. Mit den
Einstellungen in @code{postgresql-config-file} wird einem Client mit der
IP-Adresse 10.0.0.1 die Berechtigung verliehen, eine Verbindung zur
Datenbank aufzubauen, ohne sich authentisieren zu müssen@tie{}– eigentlich
keine gute Idee bei Produktivsystemen, aber für dieses Beispiel geeignet.

Erstellen wir uns ein Skript, das eine Instanz dieses Guix-Systems als
Container anlegt. Nachdem Sie obige Betriebssystemdeklaration mit dem
@code{operating-system} in eine Datei @file{os.scm} speichern, entsteht das
Startprogramm für den Container durch einen Aufruf von @command{guix system
container} (siehe @ref{Aufruf von guix system,,, guix.de, Referenzhandbuch
zu GNU Guix}).

@example
$ guix system container os.scm
Folgende Ableitungen werden erstellt:
  /gnu/store/…-run-container.drv
  …
/gnu/store/…-run-container.drv wird erstellt …
/gnu/store/…-run-container
@end example

Jetzt, wo unser Startprogramm fertig ist, können wir es ausführen und ein
neues System mit einem laufenden PostgreSQL-Dienst entschlüpft. Anmerkung:
Aufgrund derzeit noch ungelöster Einschränkungen kann das Startprogramm nur
mit Administratorrechten ausgeführt werden, zum Beispiel mit @command{sudo}.

@example
$ sudo /gnu/store/…-run-container
System-Container läuft mit PID 5983
…
@end example

Versetzen Sie den Prozess in den Hintergrund, indem Sie @key{Strg-z} drücken
und danach @command{bg} eingeben. Achten Sie auf die ausgegebene
Prozesskennung (PID); wir brauchen sie später noch, um uns mit dem Container
zu verbinden. Wissen Sie was? Schauen wir uns doch gleich an, wie Sie eine
Verbindung zum Container herstellen. Dazu benutzen wir @command{nsenter},
ein Werkzeug, das im Paket @code{util-linux} zu finden ist:

@example
$ guix shell util-linux
$ sudo nsenter -a -t 5983
root@@container /# pgrep -a postgres
49 /gnu/store/…-postgresql-14.4/bin/postgres -D /var/lib/postgresql/data --config-file=/gnu/store/…-postgresql.conf -p 5432
51 postgres: checkpointer
52 postgres: background writer
53 postgres: walwriter
54 postgres: autovacuum launcher
55 postgres: stats collector
56 postgres: logical replication launcher
root@@container /# exit
@end example

Wie Sie sehen, läuft der PostgreSQL-Dienst im Container!


@node Netzwerkverbindungen im Container
@subsection Netzwerkverbindungen im Container
@cindex Container-Netzwerkverbindung

Was nützt ein Guix System mit laufendem PostgreSQL-Datenbankdienst in einem
Container, wenn es nur mit Prozessen reden kann, die ihren Ursprung in dem
Container haben? Viel besser wäre es doch, könnten wir die Datenbank über
das Netzwerk ansprechen.

Am einfachsten geht das mit einem Paar verbundener virtueller
Ethernet-Geräte (bekannt als @code{veth}). Wir schieben das eine Gerät
(@code{ceth-test}) in den @code{net}-Namensraum des Containers und lassen
das andere Ende (@code{veth-test}) der Verbindung auf dem Wirtssystem.

@example
pid=5983
ns="guix-test"
host="veth-test"
client="ceth-test"

# Anbringen des neuen net-Namensraums "guix-test" an der PID des Containers.
sudo ip netns attach $ns $pid

# Das Geräte-Paar erzeugen.
sudo ip link add $host type veth peer name $client

# Das Client-Gerät in den net-Namensraum des Containers verschieben.
sudo ip link set $client netns $ns
@end example

Anschließend konfigurieren wir die Wirtsseite:

@example
sudo ip link set $host up
sudo ip addr add 10.0.0.1/24 dev $host
@end example

… und dann konfigurieren wir die Clientseite:

@example
sudo ip netns exec $ns  ip link set lo up
sudo ip netns exec $ns  ip link set $client up
sudo ip netns exec $ns  ip addr add 10.0.0.2/24 dev $client
@end example

Zu diesem Zeitpunkt kann der Wirt den Container unter der IP-Adresse
10.0.0.2 erreichen und der Container kann seinerseits den Wirt auf
IP-Adresse 10.0.0.1 erreichen. Das war alles, um mit dem Datenbankdienst,
der im Container steckt, vom außen liegenden Wirtssystem aus reden zu
können.

@example
$ psql -h 10.0.0.2 -U test
psql (14.4)
Type "help" for help.

test=> CREATE TABLE hallo (wen TEXT NOT NULL);
CREATE TABLE
test=> INSERT INTO hallo (wen) VALUES ('Welt');
INSERT 0 1
test=> SELECT * FROM hallo;
  wen
-------
  Welt
(1 row)
@end example

Jetzt, wo wir mit der kurzen Demonstration fertig sind, geht es an’s
Aufräumen:

@example
sudo kill $pid
sudo ip netns del $ns
sudo ip link del $host
@end example

@c *********************************************************************
@node Virtuelle Maschinen
@chapter Virtuelle Maschinen

Mit Guix können Sie Disk-Images erzeugen (siehe @ref{Aufruf von guix
system,,, guix.de, Referenzhandbuch zu GNU Guix}), um sie in Software für
virtuelle Maschinen wie virt-manager, GNOME Boxes oder auch dem schlichten
QEMU einzusetzen, nur als Beispiel.

In diesem Kapitel wollen wir direkt nutzbare, praktische Beispiele
anschauen, wie man virtuelle Maschinen auf Guix System konfigurieren und
nutzen will.

@menu
* Netzwerkbrücke für QEMU::  Netzwerkbrücke für QEMU
* Netzwerk-Routing anschalten in libvirt::  Netzwerk-Routing anschalten in 
                                              libvirt
* Eigenes NAT-basiertes Netzwerk in libvirt::  Eigenes NAT-basiertes 
                                                 Netzwerk in libvirt
* Literaturangaben: Literaturangaben zu VM.  Weiterführende Literatur zu 
                                               virtuellen Maschinen.
@end menu

@node Netzwerkbrücke für QEMU
@section Netzwerkbrücke für QEMU
@cindex Netzwerkbrücke als Schnittstelle
@cindex Netzwerk, Bridge
@cindex QEMU, Netzwerk-Bridge

In der Voreinstellung wird der QEMU-Netzwerkstapel auf dem Wirtssystem als
normaler Nutzer ausgeführt („User-Mode Host Network Back-end“), was den
Vorteil hat, dass man nichts weiter konfigurieren muss. Unglücklicherweise
kann man damit @emph{nicht} alles machen. In diesem Modus bekommt die
Gast-@abbr{VM, virtuelle Maschine} Zugriff auf das Netzwerk auf dieselbe
Weise wie das Wirtssystem, aber vom Wirt aus kann man keine Verbindung zum
Gast zustande bringen. Außerdem können, weil in QEMU das User-Mode-Netzwerk
über ICMP läuft, @emph{keine} ICMP-basierten Netzwerkprogramme wie
@command{ping} funktionieren. Daher ist es oft ratsam, eine Netzwerkbrücke
zu konfigurieren, über die das Gastsystem vollständig am Netzwerk
teilhat. So kann man auf dem Gast auch einen Server betreiben.

@subsection Eine Netzwerkbrücken-Schnittstelle aufbauen

Es gibt viele Möglichkeiten, wie man eine Netzwerkbrücke herstellen
kann. Wenn die Betriebssystemdeklaration Ihres Systems auf einer der
Vorlagen für Desktop-Rechner basiert, läuft darauf NetworkManager. Mit
folgendem Befehl kann man NetworkManager über dessen befehlszeilenbasiertes
Programm @command{nmcli} („Command Line Interface“, CLI) anweisen, eine
Netzwerkbrücke aufzubauen:

@example sh
# nmcli con add type bridge con-name br0 ifname br0
@end example

Um diese Brücke zu Ihrem Netzwerk hinzuzufügen, müssen Sie Ihre
Netzwerkbrücke der Ethernet-Schnittstelle zuordnen, über die Sie sich mit
dem Netzwerk verbinden. Wenn Ihre Schnittstelle z.B.@: die Bezeichnung
@samp{enp2s0} hat, dann wird die Zuordnung mit folgendem Befehl hergestellt:

@example sh
# nmcli con add type bridge-slave ifname enp2s0 master br0
@end example

@quotation Wichtig
Zu einer Brücke können nur Ethernet-Schnittstellen hinzugefügt werden. Wenn
Sie ein Drahtlosnetzwerk benutzen, richten Sie wohl besser Routing für Ihr
Netzwerk ein, beschrieben in @ref{Netzwerk-Routing anschalten in libvirt}.
@end quotation

In der Voreinstellung ermöglicht es die Netzwerkbrücke den Gastsystemen,
ihre IP-Adressen mittels DHCP zu beziehen, wenn DHCP auf Ihrem lokalen
Netzwerk zur Verfügung gestellt wird. Weil das einfach ist, werden wir es
hier benutzen. Um Gastmaschinen im Netzwerk zu finden, können Sie die Gäste
so konfigurieren, dass diese ihre Rechnernamen über mDNS mitteilen.

@subsection Das QEMU-Bridge-Helper-Skript konfigurieren

Zu QEMU gehört ein Hilfsprogramm, mit dem eine Netzwerkbrücken-Schnittstelle
zur Verwendung durch „unprivilegierte“ Nutzer ohne besondere Berechtigungen
einfach eingerichtet wird (siehe @ref{Network options,,, QEMU,
QEMU-Dokumentation}. Das Programm muss setuid-root gesetzt sein, damit es
funktioniert. Dazu fügen Sie es zum @code{privileged-programs}-Feld Ihrer
Betriebssystemkonfiguration (auf dem Wirtssystem) hinzu, so wie hier:

@example lisp
(privileged-programs
 (cons (privileged-program
         (program (file-append qemu "/libexec/qemu-bridge-helper"))
         (setuid? #t))
       %default-privileged-programs))
@end example

Zudem muss in der Datei @file{/etc/qemu/bridge.conf} eine Erlaubnis für die
Netzwerkbrücken-Schnittstelle eingetragen werden, denn nach Voreinstellung
wird alles blockiert. Fügen Sie dazu folgenden Dienst zu Ihrer
@code{services}-Liste hinzu:

@example lisp
(extra-special-file "/etc/qemu/host.conf"
                    (plain-file "host.conf" "allow br0\n"))
@end example

@subsection QEMU mit den richtigen Befehlszeilenoptionen aufrufen

Wenn Sie QEMU aufrufen, müssen Sie die folgenden Optionen angeben, damit die
Netzwerkbrücke benutzt wird, nachdem Sie eine einzigartige MAC-Adresse für
den Gast vorgeben.

@quotation Wichtig
Nach Voreinstellung wird dieselbe MAC-Adresse für alle Gastsysteme benutzt,
wenn Sie keine angeben. Wenn sich die MAC-Adressen mehrerer virtueller
Maschinen aber nicht unterscheiden, kommt es zu Netzwerkfehlern, wenn Sie
die Netzwerkbrücke benutzen.
@end quotation

@example sh
$ qemu-system-x86_64 […] \
    -device virtio-net-pci,netdev=user0,mac=XX:XX:XX:XX:XX:XX \
    -netdev bridge,id=user0,br=br0 \
    […]
@end example

Um MAC-Adressen mit dem für QEMU registrierten Präfix zu erzeugen, können
Sie folgendes Code-Schnipsel eintippen:

@example sh
mac_address="52:54:00:$(dd if=/dev/urandom bs=512 count=1 2>/dev/null \
                           | md5sum \
                           | sed -E 's/^(..)(..)(..).*$/\1:\2:\3/')"
echo $mac_address
@end example

@subsection Durch Docker verursachte Netzwerkprobleme

Wenn Sie auf Ihrer Maschine Docker einsetzen, kann es zu
Verbindungsproblemen kommen, wenn Sie eine Netzwerkbrücke zu benutzen
versuchen. Der Grund ist, dass auch Docker Netzwerkbrücken mitbringt und
seine eigenen Netzwerkregeln einrichtet. Die Lösung liegt im Hinzufügen des
folgenden @code{iptables}-Schnipsels in Ihre Betriebssystemdeklaration:

@example lisp
(service iptables-service-type
             (iptables-configuration
              (ipv4-rules (plain-file "iptables.rules" "\
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i br0 -o br0 -j ACCEPT
COMMIT
"))
@end example

@node Netzwerk-Routing anschalten in libvirt
@section Netzwerk-Routing anschalten in libvirt
@cindex Virtuelle-Netzwerkbrücken-Schnittstelle
@cindex Netzwerk, virtuelle Netzwerkbrücke
@cindex libvirt, virtueller Netzwerkswitch

Wenn die Maschine, auf der Ihre virtuellen Maschinen laufen sollen, nur eine
drahtlose Verbindung ins Netzwerk hat, haben Sie keine Möglichkeit, eine
echte Netzwerkbrücke zu deren Anbindung einzurichten, wie wir sie im vorigen
Abschnitt beschrieben haben (siehe @ref{Netzwerkbrücke für QEMU}). Ihnen
bleibt die zweitbeste Option, ein @emph{virtueller Netzwerkswitch} mit
statischem Routing zu benutzen und eine mit libvirt betriebene virtuelle
Maschine so einzurichten, dass sie benutzt wird (zum Beispiel mit Hilfe der
grafischen Benutzeroberfläche @command{virt-manager}). Das ist ähnlich zu
dem voreingestellten Betriebsmodus von QEMU/libvirt, außer dass wir, statt
@abbr{NAT, Network Address Translation} zum Einsatz zu bringen, mit
statischen Routen die IP-Adresse der @abbr{VM, virtuellen Maschine} ins
@abbr{LAN, Local Area Network} aufnehmen. Damit wird eine beidseitige
Verbindung zu und von der virtuellen Maschine möglich, damit alle in Ihrem
Netzwerk Zugriff auf die auf der virtuellen Maschine angebotenen Dienste
bekommen.

@subsection Einen virtuellen Netzwerkswitch anlegen

Ein virtueller Netzwerk-Switch besteht aus einem virtuellen Netzwerkgerät,
das „virtuelle Brücke“ genannt wird, einem DHCP-Server (dnsmasq) und
Firewall-Regeln (iptables). Siehe den
@url{https://wiki.libvirt.org/VirtualNetworking.html, Artikel im
libvirt-Wiki zu virtuellen Netzwerken} für mehr Details zu den Betriebsmodi,
der Verwaltung und Implementierung virtueller Netzwerk-Switches.

Mit dem Befehl @command{virsh} aus dem Paket @code{libvirt} lässt sich der
virtuelle Switch sehr einfach anlegen. Zuerst müssen Sie wissen, welches
Netzwerk-Subnetz Ihr virtueller Switch haben soll. Wenn Ihrem LAN zu Hause
das @samp{192.168.1.0/24}-Netzwerk gehört, könnten Sie z.B.@:
@samp{192.168.2.0/24} vergeben. Legen Sie eine XML-Datei an z.B.@: als
@file{/tmp/virbr0.xml} mit folgendem Inhalt:

@example
<network>
  <name>virbr0</name>
  <bridge name="virbr0" />
  <forward mode="route"/>
  <ip address="192.168.2.0" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.2.1" end="192.168.2.254"/>
    </dhcp>
  </ip>
</network>
@end example

Damit legen Sie die Schnittstelle mit Hilfe des @command{virsh}-Befehls an,
welchen Sie als Administratorbenutzer @code{root} ausführen:

@example
virsh net-define /tmp/virbr0.xml
virsh net-autostart virbr0
virsh net-start virbr0
@end example

Die Schnittstelle @samp{virbr0} müsste jetzt zum Beispiel in der Ausgabe des
Befehls @samp{ip address} zu sehen sein. Sie wird automatisch gestartet,
sobald Ihre virtuelle Maschine mit libvirt gestartet wird.

@subsection Statische Routen für Ihre virtuelle Netzwerkbrücke einrichten

Wenn Sie Ihre virtuelle Maschine so eingerichtet haben, dass sie auf der neu
geschaffenen Schnittstelle @samp{virbr0} für die virtuelle Bridge läuft,
sollte sie von sich aus bereits eine IP wie @samp{192.168.2.15} über DHCP
beziehen und darüber von dem Wirts-Serverrechner aus erreichbar sein mit
@samp{ping 192.168.2.15} oder entsprechend. Zum Schluss fehlt noch eine
letzte Konfiguration, damit die VM auch das externe Netzwerk erreichen kann:
Sie müssen im für das Netzwerk zuständigen Router statische Routen
hinzufügen.

In diesem Beispiel gehen wir davon aus, dass das LAN-Netzwerk bei Ihnen den
Block @samp{192.168.1.0/24} bekommt und die Router-Einstellungswebseite
könnte z.B.@: unter @url{http://192.168.1.1} verfügbar sein. Wenn auf Ihrem
Router die Firmware von @url{https://librecmc.org/, libreCMC} läuft, würden
Sie nach @clicksequence{Netzwerk @click{} Statische Routen} navigieren (auf
die Seite @url{https://192.168.1.1/cgi-bin/luci/admin/network/routes}) und
dort einen neuen Eintrag für @samp{Statische IPv4-Routen} mit den folgenden
Informationen anlegen:

@table @samp
@item Schnittstelle
lan
@item Ziel
192.168.2.0
@item IPv4-Netzmaske
255.255.255.0
@item IPv4-Gateway
@var{Server-IP}
@item Routen-Typ
unicast
@end table

Dabei schreiben Sie statt @var{Server-IP} die IP-Adresse der Wirtsmaschine,
auf der die VM laufen. Diese sollte als statische Adresse eingerichtet sein.

Sobald Sie diese neue statische Route speichern und anwenden, sollten Sie
sich von und nach außen mit Ihrer VM verbinden können. Um zu überprüfen, ob
es funktioniert, führen Sie z.B.@: den Befehl @samp{ping gnu.org} aus.

@node Eigenes NAT-basiertes Netzwerk in libvirt
@section Eigenes NAT-basiertes Netzwerk in libvirt

As mentioned in the preceding section (@pxref{Netzwerk-Routing anschalten in libvirt}),
libvirt allows virtual networks to be defined via XML files and managed by
the @command{virsh} command.  The details of the creation and removal of
virtual network switches are handled by libvirt, so the user does not have
to deal with them.

However, libvirt's handling of virtual network switches can sometimes clash
with more complex networking setups.  In particular, the iptables rules
inserted by libvirt for switches operating in the NAT mode can clash with
existing iptables/nftables rules, leading to insecure or broken packet
filtering.

In such cases, the only solution is to manually set up a virtual network
switch.  This section will provide instructions on how to do so using Guix
System services.

@subsection Creating the virtual network bridge

The @code{static-networking-service-type} can be used to create a virtual
network bridge and assign an IP address to it:

@example lisp
(service static-networking-service-type
         (list (static-networking
                ;; The default provision is 'networking; if you're using any
                ;; other service with this provision, such as
                ;; `network-manager-service-type`, then you need to change the
                ;; default.
                (provision '(static-networking))
                (links
                 (list (network-link
                        (name "virbr0")
                        (type 'bridge)
                        (arguments '()))))
                (addresses
                 (list (network-address
                        (device "virbr0")
                        (value "192.168.10.1/24")))))))
@end example

@subsection Running dnsmasq for the virtual network bridge

The @code{dnsmasq-service-type} can be used to provide DNS and DHCP for
guests connected to this virtual network switch:

@example lisp
(service dnsmasq-service-type
         (dnsmasq-configuration
          ;; You can have multiple instances of `dnsmasq-service-type` as long
          ;; as each one has a different shepherd-provision.
          (shepherd-provision '(dnsmasq-virbr0))
          (extra-options (list
                          ;; Only bind to the virtual bridge. This
                          ;; avoids conflicts with other running
                          ;; dnsmasq instances.
                          "--except-interface=lo"
                          "--interface=virbr0"
                          "--bind-dynamic"
                          ;; IPv4 addresses to offer to VMs. This
                          ;; should match the chosen subnet.
                          "--dhcp-range=192.168.10.2,192.168.10.254"))))
@end example

@subsection Configuring NAT for the virtual network switch

If you intend to use the virtual network switch in NAT mode, you will need
to use nftables (or iptables) rules to set up IP masquerading.  The
following example shows how to use @code{nftables-service-type} to do this:

@example lisp
(service nftables-service-type
         (nftables-configuration
          (ruleset
           (plain-file "nftables.conf"
                       "\
table inet filter @{

  chain input @{
    type filter hook input priority filter; policy drop;
    # Add your existing packet filtering rules here...
    iifname virbr0 udp dport 67 counter accept comment \"allow dhcp on virbr0\"
    iifname virbr0 meta l4proto @{tcp, udp@} th dport 53 accept \\
        comment \"allow dns on virbr0\"
  @}

  chain forward @{
    type filter hook forward priority filter; policy drop;
    # Add your existing forwarding rules here...
    iifname virbr0 accept comment \"allow outbound traffic from virbr0\"
    oifname virbr0 ct state @{established, related @} accept \\
        comment \"allow established traffic to virbr0\"
  @}

@}

table inet nat @{
  chain postrouting @{
    type nat hook postrouting priority srcnat; policy accept;
    # Add your existing nat rules here...
    iifname virbr0 ip daddr @{ 224.0.0.0/24, 255.255.255.255/32 @} return \\
        comment \"don't masquerade to reserved address blocks\"
    iifname virbr0 oifname != virbr0 masquerade \\
        comment \"masquerade all outgoing traffic from VMs\"
  @}
@}
"))))
@end example

Ensure that you have IPv4 forwarding enabled (you can use
@code{sysctl-service-type} for this).

@node Literaturangaben zu VM
@section Literaturverzeichnis

@itemize
@item
@uref{https://jamielinux.com/docs/libvirt-networking-handbook/index.html,
The (unofficial) libvirt Networking Handbook}@* Note that this resource is
rather outdated at the time of writing (as of March 2025, it was last
updated in 2015).  Nevertheless, the authors of this chapter have found it
to be a valuable source of information.
@end itemize

@c *********************************************************************
@node Fortgeschrittene Paketverwaltung
@chapter Fortgeschrittene Paketverwaltung

Guix ist ein funktionales Paketverwaltungsprogramm, das weit mehr
Funktionalitäten als traditionelle Paketverwalter anbietet. Für nicht
Eingeweihte sind deren Anwendungsfälle nicht sofort ersichtlich. Dieses
Kapitel ist dazu da, manche fortgeschrittenen Paketverwaltungskonzepte zu
demonstrieren.

Siehe @ref{Paketverwaltung,,, guix.de, Referenzhandbuch zu GNU Guix} für
eine vollständige Referenz.

@menu
* Guix-Profile in der Praxis::  Strategien für mehrere Profile und 
                                  Manifeste.
@end menu

@node Guix-Profile in der Praxis
@section Guix-Profile in der Praxis

Guix gibt uns eine sehr nützliche Funktionalität, die Neuankömmlingen sehr
fremd sein dürfte: @dfn{Profile}. Mit ihnen kann man Paketinstallationen
zusammenfassen und jeder Benutzer desselben Systems kann so viele davon
anlegen, wie sie oder er möchte.

Ob Sie ein Entwickler sind oder nicht, Sie dürften feststellen, dass mehrere
Profile ein mächtiges Werkzeug sind, das Sie flexibler macht. Zwar ist es
ein gewisser Paradigmenwechsel verglichen mit @emph{traditioneller
Paketverwaltung}, doch sind sie sehr praktisch, sobald man im Umgang mit
ihnen den Dreh ’raushat.

@quotation Anmerkung
Die Anleitung in diesem Abschnitt setzt sich meinungsstark für die Nutzung
mehrerer Profile ein. Als sie geschrieben wurde, gab es @command{guix shell}
und dessen schnelles Zwischenspeichern der damit angelegten Profile noch
nicht (siehe @ref{Aufruf von guix shell,,, guix.de, Referenzhandbuch zu GNU
Guix}).

Oftmals dürfte es für Sie einfacher sein, mit @command{guix shell} die von
Ihnen benötigten Umgebungen dann aufzusetzen, wenn Sie sie brauchen, statt
dass Sie sich der Pflege eines dedizierten Profils annehmen müssen. Es ist
Ihre Entscheidung!
@end quotation

Wenn Ihnen Pythons @samp{virtualenv} vertraut ist, können Sie sich ein
Profil als eine Art universelles @samp{virtualenv} vorstellen, das jede Art
von Software enthalten kann und nicht nur Python-Software. Des Weiteren sind
Profile selbstversorgend: Sie schließen alle Laufzeitabhängigkeiten ein und
garantieren somit, dass alle Programme innerhalb eines Profils stets zu
jeder Zeit funktionieren werden.

Mehrere Profile bieten viele Vorteile:

@itemize
@item
Klare semantische Trennung der verschiedenen Pakete, die ein Nutzer für
verschiedene Kontexte braucht.

@item
Mehrere Profile können in der Umgebung verfügbar gemacht werden, entweder
beim Anmelden oder in einer eigenen Shell.

@item
Profile können bei Bedarf geladen werden. Zum Beispiel kann der Nutzer
mehrere Unter-Shells benutzen, von denen jede ein anderes Profil ausführt.

@item
Isolierung: Programme aus dem einen Profil werden keine Programme aus dem
anderen benutzen, und der Nutzer kann sogar verschiedene Versionen desselben
Programms in die zwei Profile installieren, ohne dass es zu Konflikten
kommt.

@item
Deduplizierung: Profile teilen sich Abhängigkeiten, wenn sie genau gleich
sind. Dadurch sind mehrere Profile speichereffizient.

@item
Reproduzierbar: Wenn man dafür deklarative Manifeste benutzt, kann ein
Profil allein durch den bei dessen Einrichtung aktiven Guix-Commit eindeutig
spezifiziert werden. Das bedeutet, dass man genau dasselbe Profil
@uref{https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my/,
jederzeit und überall einrichten kann} und man dafür nur die
Commit-Informationen braucht. Siehe den Abschnitt über @ref{Reproduzierbare Profile}.

@item
Leichtere Aktualisierung und Wartung: Mit mehreren Profilen ist es ein
Leichtes, eine Liste von Paketen zur Hand zu haben und Aktualisierungen
völlig reibungslos ablaufen zu lassen.
@end itemize

Konkret wären diese hier typische Profile:

@itemize
@item
Die Abhängigkeiten des Projekts, an dem Sie arbeiten.

@item
Die Bibliotheken Ihrer Lieblingsprogrammiersprache.

@item
Programme nur für Laptops (wie @samp{powertop}), für die Sie auf einem
„Desktop“-Rechner keine Verwendung haben.

@item
@TeX{}live (das kann wirklich praktisch sein, wenn Sie nur ein einziges
Paket für dieses eine Dokument installieren müssen, das Ihnen jemand in
einer E-Mail geschickt hat).

@item
Spiele.
@end itemize

Tauchen wir ein in deren Einrichtung!

@menu
* Grundlegende Einrichtung über Manifeste::  Grundlegende Einrichtung über 
                                               Manifeste
* Die nötigen Pakete::       Die nötigen Pakete
* Vorgabeprofil::            Vorgabeprofil
* Der Vorteil von Manifesten::  Der Vorteil von Manifesten
* Reproduzierbare Profile::  Reproduzierbare Profile
@end menu

@node Grundlegende Einrichtung über Manifeste
@subsection Grundlegende Einrichtung über Manifeste

Ein Guix-Profil kann über ein @dfn{Manifest} eingerichtet werden. Ein
Manifest ist ein in Scheme geschriebenes Codeschnipsel, mit dem die Pakete
spezifiziert werden, die Sie in Ihrem Profil haben möchten. Das sieht etwa
so aus:

@lisp
(specifications->manifest
  '("paket-1"
    ;; Version 1.3 von paket-2.
    "paket-2@@1.3"
    ;; Die "lib"-Ausgabe von paket-3.
    "paket-3:lib"
    ; …
    "paket-N"))
@end lisp

Siehe @ref{Manifeste verfassen,,, guix.de, Referenzhandbuch zu GNU Guix} für
mehr Informationen zur Syntax.

Wir können eine Manifestspezifikation für jedes Profil schreiben und es auf
diese Weise installieren:

@example
GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
mkdir -p "$GUIX_EXTRA_PROFILES"/my-project # wenn es noch nicht existiert
guix package --manifest=/pfad/zu/guix-my-project-manifest.scm \
 --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project
@end example

Hierbei haben wir eine beliebig benannte Variable @samp{GUIX_EXTRA_PROFILES}
eingerichtet, die auf das Verzeichnis verweist, wo wir unsere Profile für
den Rest dieses Artikels speichern wollen.

Wenn Sie all Ihre Profile in ein einzelnes Verzeichnis legen und jedes
Profil ein Unterverzeichnis darin bekommt, ist die Organisation etwas
verständlicher. Dadurch wird jedes Unterverzeichnis all die symbolischen
Verknüpfungen für genau ein Profil enthalten. Außerdem wird es von jeder
Programmiersprache aus einfach, eine „Schleife über die Profile“ zu
schreiben (z.B.@: in einem Shell-Skript), indem Sie es einfach die
Unterverzeichnisse von @samp{$GUIX_EXTRA_PROFILES} in einer Schleife
durchlaufen lassen.

Beachten Sie, dass man auch eine Schleife über die Ausgabe von

@example
guix package --list-profiles
@end example

schreiben kann, obwohl Sie dabei wahrscheinlich
@file{~/.config/guix/current} herausfiltern wollen würden.

Um bei der Anmeldung alle Profile zu aktivieren, fügen Sie dies in Ihre
@file{~/.bash_profile} ein (oder etwas Entsprechendes):

@example
for i in $GUIX_EXTRA_PROFILES/*; do
  profile=$i/$(basename "$i")
  if [ -f "$profile"/etc/profile ]; then
    GUIX_PROFILE="$profile"
    . "$GUIX_PROFILE"/etc/profile
  fi
  unset profile
done
@end example

Eine Anmerkung für Nutzer von „Guix System“: Obiger Code entspricht dem, wie
Ihr voreingestelltes Profil @file{~/.guix-profile} durch @file{/etc/profile}
aktiviert wird, was nach Vorgabe durch @file{~/.bashrc} geladen wird.

Selbstverständlich können Sie sich auch dafür entscheiden, nur eine
Teilmenge zu aktivieren:

@example
for i in "$GUIX_EXTRA_PROFILES"/my-project-1 "$GUIX_EXTRA_PROFILES"/my-project-2; do
  profile=$i/$(basename "$i")
  if [ -f "$profile"/etc/profile ]; then
    GUIX_PROFILE="$profile"
    . "$GUIX_PROFILE"/etc/profile
  fi
  unset profile
done
@end example

Wenn ein Profil abgeschaltet ist, lässt es sich mit Leichtigkeit für eine
bestimmte Shell aktivieren, ohne die restliche Benutzersitzung zu
„verschmutzen“:

@example
GUIX_PROFILE="pfad/zu/my-project" ; . "$GUIX_PROFILE"/etc/profile
@end example

Der Schlüssel dazu, wie man ein Profil aktiviert, ist dessen
@samp{etc/profile}-Datei mit @command{source} zu laden. Diese Datei enthält
einige Shell-Befehle, um die für das Aktivieren der Software im Profil
nötigen Umgebungsvariablen zu exportieren. Die Datei wird durch Guix
automatisch erzeugt, um mit @command{source} eingelesen zu werden. Sie
enthält dieselben Variablen, die Sie nach Ausführung dieses Befehls bekämen:

@example
guix package --search-paths=prefix --profile=$my_profile"
@end example

Siehe auch hier das @ref{Aufruf von guix package,,, guix.de,
Referenzhandbuch zu GNU Guix} für die Befehlszeilenoptionen.

Um ein Profil zu aktualisieren, installieren Sie das Manifest einfach
nochmal:

@example
guix package -m /pfad/zu/guix-my-project-manifest.scm \
 -p "$GUIX_EXTRA_PROFILES"/my-project/my-project
@end example

Um alle Profile zu aktualisieren, genügt es, sie in einer Schleife
durchlaufen zu lassen. Nehmen wir zum Beispiel an, Ihre
Manifestspezifikationen befinden sich in
@file{~/.guix-manifests/guix-$profile-manifest.scm}, wobei @samp{$profile}
der Name des Profils ist (z.B.@: „projekt1“), dann könnten Sie in der
Bourne-Shell Folgendes tun:

@example
for profile in "$GUIX_EXTRA_PROFILES"/*; do
  guix package --profile="$profile" \
   --manifest="$HOME/.guix-manifests/guix-$profile-manifest.scm"
done
@end example

Jedes Profil verfügt über seine eigenen Generationen:

@example
guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --list-generations
@end example

Sie können es auf jede Generation zurücksetzen:

@example
guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --switch-generations=17
@end example

Zu guter Letzt ist es möglich, zu einem Profil zu wechseln ohne die aktuelle
Umgebung zu erben, indem Sie es aus einer leeren Shell heraus aktivieren:

@example
env -i $(which bash) --login --noprofile --norc
. my-project/etc/profile
@end example

@node Die nötigen Pakete
@subsection Die nötigen Pakete

Das Aktivieren eines Profils bedeutet im Grunde, dass eine Menge
Umgebungsvariabler exportiert wird. Diese Rolle fällt der
@samp{etc/profile}-Datei innerhalb des Profils zu.

@emph{Anmerkung: Nur diejenigen Umgebungsvariablen der sie gebrauchenden Pakete
werden gesetzt.}

Zum Beispiel wird kein @samp{MANPATH} gesetzt sein, wenn keine Anwendung im
Profil diese „Man-Pages“ (Handbuchseiten) gebraucht. Wenn Sie also
transparenten Zugriff auf Handbuchseiten brauchen, nachdem das Profil
geladen wurde, dann gibt es zwei Möglichkeiten:

@itemize
@item
Entweder Sie exportieren die Variablen von Hand, z.B.
@example
export MANPATH=/path/to/profile$@{MANPATH:+:@}$MANPATH
@end example

@item
Oder Sie schreiben @samp{man-db} in das Profilmanifest hinein.
@end itemize

Das Gleiche gilt für @samp{INFOPATH} (Sie können @samp{info-reader}
installieren), @samp{PKG_CONFIG_PATH} (installieren Sie @samp{pkg-config}),
etc.

@node Vorgabeprofil
@subsection Vorgabeprofil

Was ist mit dem Standardprofil, das Guix in @file{~/.guix-profile}
aufbewahrt?

Sie können ihm die Rolle zuweisen, die Sie wollen. Normalerweise würden Sie
das Manifest derjenigen Pakete installieren, die Sie ständig benutzen
möchten.

Alternativ können Sie es ohne Manifest für Wegwerfpakete benutzen, die Sie
nur ein paar Tage lang benutzen wollen. Das macht es leicht,

@example
guix install paket-foo
guix upgrade paket-bar
@end example

auszuführen ohne den Pfad zu einem Profil festzulegen.

@node Der Vorteil von Manifesten
@subsection Der Vorteil von Manifesten

Mit Manifesten können Sie @dfn{deklarativ} angeben, welche Pakete Sie in
Ihrem Profil haben möchten (siehe @ref{Manifeste verfassen,,, guix.de,
Referenzhandbuch zu GNU Guix}). Sie sind eine bequeme Art, Ihre Paketlisten
zur Hand zu haben und diese z.B.@: über mehrere Maschinen hinweg in einem
Versionskontrollsystem zu synchronisieren.

Eine oft gehörte Beschwerde über Manifeste ist, dass es lange dauert, sie zu
installieren, wenn sie viele Pakete enthalten. Das ist besonders hinderlich,
wenn Sie nur ein einziges Paket in ein großes Manifest installieren möchten.

Das ist ein weiteres Argument dafür, mehrere Profile zu benutzen, denn es
stellt sich heraus, dass dieses Vorgehen perfekt für das Aufbrechen von
Manifesten in mehrere Mengen semantisch verbundener Pakete geeignet ist. Mit
mehreren, kleinen Profilen haben Sie mehr Flexibilität und
Benutzerfreundlichkeit.

Manifeste haben mehrere Vorteile. Insbesondere erleichtern sie die Wartung.

@itemize
@item
Wenn ein Profil aus einem Manifest heraus eingerichtet wird, ist das
Manifest selbst genug, um eine Liste der Pakete zur Verfügung zu haben und
das Profil später auf einem anderen System zu installieren. Bei
@i{ad-hoc}-Profilen müssten wir hingegen eine Manifestspezifikation von Hand
schreiben und uns um die Paketversionen derjenigen Pakete kümmern, die nicht
die vorgegebene Version verwenden.

@item
Bei @code{guix package --upgrade} wird immer versucht, die Pakete zu
aktualisieren, die propagierte Eingaben haben, selbst wenn es nichts zu tun
gibt. Mit Guix-Manifesten fällt dieses Problem weg.

@item
Wenn man nur Teile eines Profils aktualisiert, kann es zu Konflikten kommen
(weil die Abhängigkeiten zwischen aktualisierten und nicht aktualisierten
Paketen voneinander abweichen), und es kann mühsam sein, diese Konflikte von
Hand aufzulösen. Manifeste haben kein solches Problem, weil alle Pakete
immer gleichzeitig aktualisiert werden.

@item
Wie zuvor erwähnt, gewähren einem Manifeste reproduzierbare Profile, während
die imperativen @code{guix install}, @code{guix upgrade}, etc.@: das nicht
tun, weil sie jedes Mal ein anderes Profil ergeben, obwohl sie dieselben
Pakete enthalten. Siehe die @uref{https://issues.guix.gnu.org/issue/33285,
dieses Thema betreffende Diskussion}.

@item
Manifestspezifikationen können von anderen @samp{guix}-Befehlen benutzt
werden. Zum Beispiel können Sie @code{guix weather -m manifest.scm}
ausführen, um zu sehen, wie viele Substitute verfügbar sind, was Ihnen bei
der Entscheidung helfen kann, ob Sie heute schon eine Aktualisierung
durchführen oder lieber noch eine Weile warten möchten. Ein anderes
Beispiel: Sie können mit @code{guix pack -m manifest.scm} ein Bündel
erzeugen, das alle Pakete im Manifest enthält (mitsamt derer transitiven
Referenzen).

@item
Zuletzt haben Manifeste auch eine Repräsentation in Scheme, nämlich den
@samp{<manifest>}-Verbundstyp. Sie können in Scheme verarbeitet werden und
an die verschiedenen
@uref{https://de.wikipedia.org/wiki/Programmierschnittstelle,
Guix-Programmierschnittstellen (APIs)} übergeben werden.
@end itemize

Es ist wichtig, dass Sie verstehen, dass Manifeste zwar benutzt werden
können, um Profile zu deklarieren, sie aber nicht ganz dasselbe wie Profile
sind: Profile haben Nebenwirkungen. Sie setzen Pakete im Store fest, so dass
sie nicht vom Müllsammler geholt werden (siehe @ref{Aufruf von guix gc,,,
guix.de, Referenzhandbuch zu GNU Guix}) und stellen sicher, dass sie auch in
Zukunft jederzeit verfügbar sein werden. Wenn Sie den Befehl @command{guix
shell} verwenden, werden damit erzeugte kürzlich verwendete Profile
allerdings auch vor dem Müllsammler beschützt; Profile, die länger nicht
verwendet werden, können jedoch zusammen mit ihren referenzierten Paketen
von ihm gelöscht werden.

Wenn wir uns 100% sicher sein wollen, dass der Müllsammler ein bestimmtes
Profil nicht sammelt, müssen wir das Manifest in ein Profil installieren und
@code{GUIX_PROFILE=/das/profil; . "$GUIX_PROFILE"/etc/profile} aufrufen, wie
oben erklärt. Dadurch haben wir die Garantie, dass unsere Hacking-Umgebung
jederzeit zur Verfügung steht.

@emph{Sicherheitswarnung:} Obwohl es angenehm sein kann, alte Profile zu
behalten, sollten Sie daran denken, dass veraltete Pakete @emph{nicht} über
die neuesten Sicherheitsbehebungen verfügen.

@node Reproduzierbare Profile
@subsection Reproduzierbare Profile

Um ein Profil Bit für Bit nachzubilden, brauchen wir zweierlei
Informationen:

@itemize
@item
ein Manifest (siehe @ref{Manifeste verfassen,,, guix.de, Referenzhandbuch zu
GNU Guix}) und
@item
eine Kanalspezifikation für Guix (siehe @pxref{Guix nachbilden,,, guix.de,
Referenzhandbuch zu GNU Guix}).
@end itemize

Tatsächlich kann es vorkommen, dass ein Manifest allein nicht genug ist:
Verschiedene Versionen von Guix (oder andere Kanäle) können beim selben
Manifest zu verschiedenen Ausgaben führen.

Sie können sich die Guix-Kanalspezifikationen mit @samp{guix describe
--format=channels} ausgeben lassen (siehe @ref{Aufruf von guix describe,,,
guix.de, Referenzhandbuch zu GNU Guix}). Speichern Sie sie in eine Datei ab,
sagen wir @samp{channel-specs.scm}.

Auf einem anderen Rechner können Sie die Kanalspezifikationsdatei und das
Manifest benutzen, um genau dasselbe Profil zu reproduzieren:

@example
GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
GUIX_EXTRA=$HOME/.guix-extra

mkdir -p "$GUIX_EXTRA"/my-project
guix pull --channels=channel-specs.scm --profile="$GUIX_EXTRA/my-project/guix"

mkdir -p "$GUIX_EXTRA_PROFILES/my-project"
"$GUIX_EXTRA"/my-project/guix/bin/guix package \
 --manifest=/pfad/zu/guix-my-project-manifest.scm \
 --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project
@end example

Es kann nichts Schlimmes passieren, wenn Sie das Guix-Kanalprofil, das Sie
eben aus der Kanalspezifikation erstellt haben, löschen, denn das
Projektprofil hängt davon nicht ab.

@node Software-Entwicklung
@chapter Software-Entwicklung

@cindex Entwicklung, mit Guix
@cindex Software-Entwicklung, mit Guix
Guix ist ein hilfreiches Werkzeug für Entwickler; besonders @command{guix
shell} versorgt Sie mit einer eigenständigen Entwicklungsumgebung für Ihr
Paket, unabhängig von der oder den Sprachen, in denen es programmiert ist
(siehe @ref{Aufruf von guix shell,,, guix.de, Referenzhandbuch zu GNU
Guix}). Um Ihren Nutzen daraus zu ziehen, fertigen Sie als Erstes eine
Paketdefinition an, die entweder ins eigentliche Guix akzeptiert werden muss
oder die Teil eines Kanals oder gleich im Quellbaum Ihres Projekts sein muss
in einer Datei @file{guix.scm}. Letztere Option bietet sich an, weil
Entwickler dann nur das Repository des Projekts zu klonen brauchen und
@command{guix shell} ohne Argumente aufrufen können.

Zur Entwicklung gehört jedoch mehr. Wie richten Entwickler eine
kontinuierliche Integration ihres Codes in Guix-Erstellungsumgebungen ein?
Wie findet eine sofortige Auslieferung ihres Codes an abenteuerlustige
Nutzer statt? Dieses Kapitel erklärt, wie Entwickler wenige zusätzliche
Dateien ins Repository hinzufügen, um Guix-basierte Entwicklungsumgebungen,
kontinuierliche Integration und kontinuierliche Auslieferung
umzusetzen@tie{}– alles auf einmal@footnote{Dieses Kapitel ist eine
aufgearbeitete Fassung
@uref{https://guix.gnu.org/de/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/,
eines Blog-Eintrags}, der im Juni 2023 auf Guix’ Webauftritt veröffentlicht
wurde.}.

@menu
* Einstieg::                 Schritt 0: „guix shell“ benutzen.
* Erstellen mit Guix::       Schritt 1: Ihren Code kompilieren.
* Das Repository als Kanal::  Schritt 2: Ein Repo in einen Kanal verwandeln.
* Paketvarianten::           Bonus: Varianten definieren.
* Kontinuierliche Integration einrichten::  Schritt 3: Kontinuierliche 
                                              Integration.
* Erstellungs-Manifest::     Bonus: Manifest.
* Zusammenfassung::          Resümee.
@end menu

@node Einstieg
@section Einstieg

Wie lässt sich also ein Repository „guixifizieren“? Unser erster Schritt
ist, wie wir sehen konnten, eine Datei @file{guix.scm} im obersten
Verzeichnis des fraglichen Repositorys unterzubringen. Nehmen wir
@uref{https://www.gnu.org/software/guile,Guile} als Beispiel in diesem
Kapitel; es ist in Scheme (zum größten Teil) und in C geschrieben und ist
von anderer Software abhängig@tie{}– einer C-Compiler-Toolchain,
C-Bibliotheken, Autoconf und seinen Freunden, LaTeX und so weiter. Daraus
ergibt sich eine @file{guix.scm}, die ziemlich wie andere Paketdefinitionen
auch aussieht (siehe @ref{Pakete definieren,,, guix.de, Referenzhandbuch zu
GNU Guix}), nur fehlt das @code{define-public} am Anfang:

@lisp
;; Die ‚guix.scm‘-Datei für Guile, gedacht für ‚guix shell‘.

(use-modules (guix)
             (guix build-system gnu)
             ((guix licenses) #:prefix license:)
             (gnu packages autotools)
             (gnu packages base)
             (gnu packages bash)
             (gnu packages bdw-gc)
             (gnu packages compression)
             (gnu packages flex)
             (gnu packages gdb)
             (gnu packages gettext)
             (gnu packages gperf)
             (gnu packages libffi)
             (gnu packages libunistring)
             (gnu packages linux)
             (gnu packages pkg-config)
             (gnu packages readline)
             (gnu packages tex)
             (gnu packages texinfo)
             (gnu packages version-control))

(package
  (name "guile")
  (version "3.0.99-git")                          ;komische Versionsnummer
  (source #f)                                     ;keine Quelle
  (build-system gnu-build-system)
  (native-inputs
   (append (list autoconf
                 automake
                 libtool
                 gnu-gettext
                 flex
                 texinfo
                 texlive-base                 ;für "make pdf"
                 texlive-epsf
                 gperf
                 git
                 gdb
                 strace
                 readline
                 lzip
                 pkg-config)

           ;; Zum Cross-Kompilieren ist eine native Version desselben
           ;; Guiles notwendig.
           (if (%current-target-system)
               (list this-package)
               '())))
  (inputs
   (list libffi bash-minimal))
  (propagated-inputs
   (list libunistring libgc))

  (native-search-paths
   (list (search-path-specification
          (variable "GUILE_LOAD_PATH")
          (files '("share/guile/site/3.0")))
         (search-path-specification
          (variable "GUILE_LOAD_COMPILED_PATH")
          (files '("lib/guile/3.0/site-ccache")))))
  (synopsis "Scheme implementation intended especially for extensions")
  (description
   "Guile is the GNU Ubiquitous Intelligent Language for Extensions,
and it's actually a full-blown Scheme implementation!")
  (home-page "https://www.gnu.org/software/guile/")
  (license license:lgpl3+))
@end lisp

Das ist schon ein bisschen aufwendig, aber wenn jemand an Guile hacken will,
braucht sie bloß noch das hier aufzurufen:

@lisp
guix shell
@end lisp

Sie findet sich in einer Shell wieder, wo es alle Abhängigkeiten von Guile
gibt: die oben aufgeführten Abhängigkeiten und außerdem @emph{implizite
Abhängigkeiten} wie die GCC-Toolchain, GNU@tie{}Make, sed, grep und so
weiter. Siehe @ref{Aufruf von guix shell,,, guix.de, Referenzhandbuch zu GNU
Guix} für weitere Informationen zu @command{guix shell}.

@quotation Empfehlung des Hauses
Wir legen Ihnen nahe, Entwicklungsumgebungen mit diesem Befehl anzulegen:

@example
guix shell --container --link-profile
@end example

@noindent
… oder kurz:

@example
guix shell -CP
@end example

So erhält man eine Shell in einem isolierten Container und alle
Abhängigkeiten finden sich in @code{$HOME/.guix-profile}, was die Nutzung
von Zwischenspeichern wie @file{config.cache} (siehe @ref{Cache Files,,,
autoconf, Autoconf}) erleichtert und wodurch absolute Dateinamen, die in
erzeugten Dateien wie @code{Makefile}s und Ähnlichem festgehalten werden,
gültig bleiben. Die Tatsache, dass die Shell in einem Container läuft,
erlaubt Ihnen ein Gefühl der Sicherheit: Nichts außer dem aktuellen
Verzeichnis und Guiles Abhängigkeiten ist in dieser isolierten Umgebung
sichtbar; nichts vom System kann Ihre Arbeit störend beeinflussen.
@end quotation

@node Erstellen mit Guix
@section Stufe 1: Erstellen mit Guix

Jetzt, wo wir eine Paketdefinition vorliegen haben (siehe @ref{Einstieg}), können wir sie dann auch gleich benutzen, um Guile mit Guix zu
erstellen? Uns fehlt der Eintrag im @code{source}-Feld, das wir leer
gelassen haben, denn für @command{guix shell} spielen nur die @emph{inputs}
unseres Pakets eine Rolle@tie{}– um die Entwicklungsumgebung zu unserem
Paket aufzusetzen@tie{}–, aber das Paket selber wurde bisher nicht
gebraucht.

Wenn wir das Paket mit Guix erstellt bekommen möchten, müssen wir etwas ins
@code{source}-Feld eintragen, etwa so:

@lisp
(use-modules (guix)
             (guix git-download)  ;für ‚git-predicate‘
             …)

(define vcs-file?
  ;; Wahr zurückliefern, wenn die angegebene Datei unter
  ;; Versionskontrolle steht.
  (or (git-predicate (current-source-directory))
      (const #t)))                                ;es ist kein Git-Checkout

(package
  (name "guile")
  (version "3.0.99-git")                          ;komische Versionsnummer
  (source (local-file "." "guile-checkout"
                      #:recursive? #t
                      #:select? vcs-file?))
  …)
@end lisp

Dies sind unsere Änderungen verglichen mit dem vorherigen Abschnitt:

@enumerate
@item
Wir haben @code{(guix git-download)} zu unseren importierten Modulen
hinzugefügt, damit wir dessen Prozedur @code{git-predicate} benutzen können.
@item
Wir haben @code{vcs-file?} als Prozedur definiert, die wahr zurückgibt, wenn
ihr eine Datei übergeben wird, die unter Versionskontrolle steht. Es gehört
sich, den Fall abzufangen, wenn wir uns in keinem Git-Checkout befinden:
Dann wird immer wahr geliefert.
@item
Wir setzen @code{source} auf
@uref{https://guix.gnu.org/manual/devel/de/html_node/G_002dAusdrucke.html#index-local_002dfile,@code{local-file}}@tie{}–
einer rekursiven Kopie des aktuellen Verzeichnisses (@code{"."}),
eingeschränkt auf solche Dateien, die unter Versionskontrolle gestellt sind
(mit @code{#:select?}).
@end enumerate

Von da an erfüllt @file{guix.scm} einen zweiten Zweck: Wir können die
Software mit Guix erstellen. Der Vorteil der Erstellung mit Guix ist, dass
eine „saubere“ Erstellung durchgeführt wird@tie{}– Sie können sich sicher
sein, das Ergebnis der Erstellung beruht nicht auf Dateien in Ihrem
Quellbaum oder anderen Dingen in Ihrem System@tie{}– und auch, dass Sie
viele Möglichkeiten testen können. Als Erstes wäre da eine einfache native
Erstellung:

@example
guix build -f guix.scm
@end example

Aber auch für ein anderes System können Sie die Erstellung durchführen
(unter Umständen müssen Sie erst die Auslagerungsfunktion, siehe
@ref{Auslagern des Daemons einrichten,,, guix.de, Referenzhandbuch zu GNU
Guix}, oder transparente Emulation, siehe @ref{Virtualisierungsdienste,,,
guix.de, Referenzhandbuch zu GNU Guix}, einrichten):

@lisp
guix build -f guix.scm -s aarch64-linux -s riscv64-linux
@end lisp

@noindent
… oder Sie cross-kompilieren:

@lisp
guix build -f guix.scm --target=x86_64-w64-mingw32
@end lisp

Möglich sind auch @dfn{Paketumwandlungsoptionen}, womit Sie Varianten Ihres
Pakets testen können (siehe @ref{Paketumwandlungsoptionen,,, guix.de,
Referenzhandbuch zu GNU Guix}):

@example
# Wie sieht es aus, wenn wir mit Clang statt GCC erstellen?
guix build -f guix.scm \
  --with-c-toolchain=guile@@3.0.99-git=clang-toolchain

# Was ist mit wenig getesteten configure-Befehlszeilenoptionen?
guix build -f guix.scm \
  --with-configure-flag=guile@@3.0.99-git=--disable-networking
@end example

Praktisch!

@node Das Repository als Kanal
@section Stufe 2: Das Repository als Kanal

Jetzt haben wir ein Git-Repository mit (unter anderem) einer Paketdefinition
(siehe @ref{Erstellen mit Guix}). Wäre es nicht besser, wenn wir daraus
einen @dfn{Kanal} machen würden (siehe @ref{Kanäle,,, guix.de,
Referenzhandbuch zu GNU Guix})? Schließlich sind Kanäle entwickelt worden,
um Nutzer mit Paketdefinitionen zu versorgen, und genau das tun wir mit
@file{guix.scm}.

Tatsächlich sollten wir es zu einem Kanal machen, aber aufgepasst: Die
@code{.scm}-Datei(en) unseres Kanals gehören in ein gesondertes Verzeichnis,
damit @command{guix pull} nicht versucht, die falschen @code{.scm}-Dateien
zu laden, wenn jemand damit den Kanal herunterlädt@tie{}– und in Guile gibt
es viele @code{.scm}-Dateien! Wir fangen mit der Trennung an, behalten aber
auf oberster Ebene eine symbolische Verknüpfung @file{guix.scm} zur Nutzung
mit @command{guix shell}:

@lisp
mkdir -p .guix/modules
mv guix.scm .guix/modules/guile-package.scm
ln -s .guix/modules/guile-package.scm guix.scm
@end lisp

Damit es als Kanal verwendet werden kann, erweitern wir unsere
@file{guix.scm}-Datei zu einem @dfn{Paketmodul} (siehe @ref{Paketmodule,,,
guix.de, Referenzhandbuch zu GNU Guix}). Das geschieht, indem wir die
@code{use-modules}-Form am Anfang durch eine @code{define-module}-Form
ersetzen. Auch müssen wir dann eine Paketvariable @emph{exportieren}, mit
@code{define-public}, und dennoch am Ende der Datei den Paketwert
zurückliefern, damit @command{guix shell} und @command{guix build -f
guix.scm} weiterhin funktionieren. Das Endergebnis sieht so aus (ohne zu
wiederholen, was wir nicht verändern):

@lisp
(define-module (guile-package)
  #:use-module (guix)
  #:use-module (guix git-download)   ;für ‚git-predicate‘
  …)

(define vcs-file?
  ;; Wahr zurückliefern, wenn die angegebene Datei unter
  ;; Versionskontrolle steht.
  (or (git-predicate (dirname (dirname (current-source-directory))))
      (const #t)))                                ;es ist kein Git-Checkout

(define-public guile
  (package
    (name "guile")
    (version "3.0.99-git")                          ;komische Versionsnummer
    (source (local-file "../.." "guile-checkout"
                        #:recursive? #t
                        #:select? vcs-file?))
    …))

;; Das oben definierte Paketobjekt muss am Modulende zurückgeliefert werden.
guile
@end lisp

Zuletzt brauchen wir noch eine
@uref{https://guix.gnu.org/manual/devel/de/html_node/Paketmodule-in-einem-Unterverzeichnis.html,@code{.guix-channel}-Datei},
um Guix zu erklären, woher es die Paketmodule in unserem Repository bekommt:

@lisp
;; Mit dieser Datei kann man dieses Repo als Guix-Kanal eintragen.

(channel
  (version 0)
  (directory ".guix/modules"))  ;Paketmodule finden sich unter .guix/modules/
@end lisp

Zusammengefasst liegen diese Dateien jetzt im Repository:

@lisp
.
├── .guix-channel
├── guix.scm → .guix/modules/guile-package.scm
└── .guix
    └── modules
       └── guile-package.scm
@end lisp

Und das war alles: Wir haben einen Kanal erschaffen! (Noch besser wäre es,
auch
@uref{https://guix.gnu.org/en/manual/devel/de/html_node/Kanalautorisierungen-angeben.html,@emph{Kanalautorisierungen}}
zu unterstützen, damit Benutzer wissen, dass der heruntergeladene Code echt
ist. Wir ersparen Ihnen die Feinheiten hier, aber ziehen Sie es in
Betracht!) Nutzer können von diesem Kanal pullen, indem sie
@uref{https://guix.gnu.org/manual/devel/de/html_node/Weitere-Kanale-angeben.html,ihn
zu @code{~/.config/guix/channels.scm} hinzufügen}, etwa so:

@lisp
(append (list (channel
                (name 'guile)
                (url "https://git.savannah.gnu.org/git/guile.git")
                (branch "main")))
        %default-channels)
@end lisp

Nach einem Aufruf von @command{guix pull} sind die neuen Pakete zu sehen:

@example
$ guix describe
Generation 264  26. Mai 2023 16:00:35    (aktuell)
  guile 36fd2b4
    Repository-URL: https://git.savannah.gnu.org/git/guile.git
    Branch: main
    Commit: 36fd2b4920ae926c79b936c29e739e71a6dff2bc
  guix c5bc698
    Repository-URL: https://git.guix.gnu.org/guix.git
    Commit: c5bc698e8922d78ed85989985cc2ceb034de2f23
$ guix package -A ^guile$
guile   3.0.99-git      out,debug       guile-package.scm:51:4
guile   3.0.9           out,debug       gnu/packages/guile.scm:317:2
guile   2.2.7           out,debug       gnu/packages/guile.scm:258:2
guile   2.2.4           out,debug       gnu/packages/guile.scm:304:2
guile   2.0.14          out,debug       gnu/packages/guile.scm:148:2
guile   1.8.8           out             gnu/packages/guile.scm:77:2
$ guix build guile@@3.0.99-git
[…]
/gnu/store/axnzbl89yz7ld78bmx72vpqp802dwsar-guile-3.0.99-git-debug
/gnu/store/r34gsij7f0glg2fbakcmmk0zn4v62s5w-guile-3.0.99-git
@end example

Auf diesem Weg liefern Sie, als Entwickler, Ihre Software direkt in die
Hände der Nutzer! Es gibt keine Mittelsmänner, trotzdem bleiben Transparenz
und Provenienzverfolgung erhalten.

Auf dieser Grundlage kann außerdem jeder leicht Docker-Abbilder, Pakete als
Deb/RPM oder einen einfachen Tarball mit @command{guix pack} anfertigen
(siehe @ref{Aufruf von guix pack,,, guix.de, Referenzhandbuch zu GNU Guix}):

@example
# Sie wünschen ein Docker-Image mit unserem Guile-Snapshot?
guix pack -f docker -S /bin=bin guile@@3.0.99-git

# Und ein verschiebliches RPM?
guix pack -f rpm -R -S /bin=bin guile@@3.0.99-git
@end example

@node Paketvarianten
@section Bonus: Paketvarianten

Jetzt, wo wir es zu einem richtigen Kanal gebracht haben (siehe @ref{Das Repository als Kanal}), drängt sich die Frage auf, warum er nur ein Paket
enthält. Da geht mehr, denn wir können gleich mehrere @dfn{Paketvarianten}
(siehe @ref{Paketvarianten definieren,,, guix.de, Referenzhandbuch zu GNU
Guix}) in unserer Datei @file{guile-package.scm} festlegen, und zwar
Varianten, die wir Entwickler von Guile gerne testen würden@tie{}– wofür wir
oben noch Paketumwandlungsoptionen gebraucht haben. Wir können Sie auf diese
Weise eintragen:

@lisp
;; Dies ist die Datei ‚.guix/modules/guile-package.scm‘.

(define-module (guile-package)
  …)

(define-public guile
  …)

(define (package-with-configure-flags p flags)
  "Liefert P erweitert um die 'configure'-Optionen in FLAGS."
  (package/inherit p
    (arguments
     (substitute-keyword-arguments (package-arguments p)
       ((#:configure-flags original-flags #~(list))
        #~(append #$original-flags #$flags))))))

(define-public guile-without-threads
  (package
    (inherit (package-with-configure-flags guile
                                           #~(list "--without-threads")))
    (name "guile-without-threads")))

(define-public guile-without-networking
  (package
    (inherit (package-with-configure-flags guile
                                           #~(list "--disable-networking")))
    (name "guile-without-networking")))


;; Das oben definierte Paketobjekt muss am Modulende zurückgeliefert werden.
guile
@end lisp

Sobald wir den Kanal mit @command{guix pull} aktiviert haben, können wir
diese Varianten als normale Pakete erstellen. Es geht aber auch, einen
Befehl wie hier in einem Checkout von Guile auf oberster Ebene auszuführen:

@lisp
guix build -L $PWD/.guix/modules guile-without-threads
@end lisp

@node Kontinuierliche Integration einrichten
@section Stufe 3: Kontinuierliche Integration einrichten

@cindex kontinuierliche Integration (CI)
Mit dem oben definierten Kanal (siehe @ref{Das Repository als Kanal})
können wir erst recht etwas anstellen, sobald wir
@uref{https://de.wikipedia.org/wiki/Kontinuierliche_Integration,
@dfn{Kontinuierliche Integration}} (Continuous Integration, CI) eingerichtet
haben. Hier gibt es mehrere Wege zum Ziel.

Sie können ein dem Mainstream entsprechendes Werkzeug zur kontinuierlichen
Integration nehmen wie GitLab-CI. Dazu müssen Sie Aufgaben („Jobs“) in einem
Docker-Abbild oder einer virtuellen Maschine, auf der Guix installiert ist,
ausführen lassen. Wenn wir das für Guile vorhätten, legten wir eine Aufgabe
an, die einen Shell-Befehl wie diesen laufen lässt:

@lisp
guix build -L $PWD/.guix/modules guile@@3.0.99-git
@end lisp

So klappt es gut und der Vorteil ist, dass Sie den Befehl leicht Ihrer
bevorzugten CI-Plattform beibringen können.

Aber trotzdem können Sie Guix am besten ausnutzen, wenn Sie
@uref{https://guix.gnu.org/de/cuirass,Cuirass} verwenden, ein CI-Werkzeug
speziell für Guix und eng damit integriert. Cuirass zu benutzen statt einem
CI-Werkzeug, das jemand für Sie hostet, macht mehr Aufwand, aber die
Einrichtung hält sich in Grenzen, wenn Sie Cuirass’ Dienst auf Guix System
benutzen (siehe @ref{Kontinuierliche Integration,,, guix.de,
Referenzhandbuch zu GNU Guix}). Kehren wir zu unserem Beispiel zurück,
statten wir Cuirass mit so einer Spezifikationsdatei aus:

@lisp
;; Cuirass-Spezifikationsdatei, um alle Pakete des ‚guile‘-Kanals zu erstellen.
(list (specification
        (name "guile")
        (build '(channels guile))
        (channels
         (append (list (channel
                         (name 'guile)
                         (url "https://git.savannah.gnu.org/git/guile.git")
                         (branch "main")))
                 %default-channels))))
@end lisp

Es gibt zwei wichtige Unterschiede zu dem, was Sie mit anderen CI-Werkzeugen
tun würden:

@itemize
@item
Cuirass weiß über @emph{zwei} Kanäle Bescheid, @code{guile} und
@code{guix}. Tatsächlich zählen viele Pakete vom @code{guix}-Kanal zu den
Abhängigkeiten des von uns entwickelten @code{guile}-Pakets@tie{}– GCC, GNU
libc, libffi und weitere. Es kann passieren, dass sich die Pakete vom
@code{guix}-Kanal ändern und dadurch die Erstellung unseres
@code{guile}-Pakets schiefgeht; so etwas wollen wir als die Entwickler von
Guile so früh erfahren, wie es nur geht.
@item
Die Erstellungsergebnisse werden @emph{nicht} entsorgt, sondern sie können
als @dfn{Substitute}, d.h.@: vorerstellten Binärdateien, allen Nutzern
unseres @code{guile}-Kanals transparent zur Verfügung gestellt werden!
(Siehe @ref{Substitute,,, guix.de, Referenzhandbuch zu GNU Guix} für
Hintergrundwissen zu Substituten.)
@end itemize

Aus Entwicklersicht sieht das Ergebnis am Ende so aus wie die auf Guiles
@uref{https://ci.guix.gnu.org/jobset/guile,Status-Seite} aufgelisteten
@emph{Auswertungen}: Jede Auswertung besteht aus einer Kombination von
Commits der @code{guix}- und @code{guile}-Kanäle, wovon es mehrere
@emph{Aufträge} (Jobs) gibt@tie{}– je einen Job pro Paket, das in
@file{guile-package.scm} definiert ist, mal der Anzahl der
Zielarchitekturen.

Substitute gibt es kostenlos dazu! Zum Beispiel kann jeder, weil unser
@code{guile}-Jobset auf ci.guix.gnu.org erstellt wird und dort @command{guix
publish} (siehe @ref{Aufruf von guix publish,,, guix.de, Referenzhandbuch zu
GNU Guix}) zusätzlich zu Cuirass läuft, automatisch die Substitute für
@code{guile}-Erstellungen von ci.guix.gnu.org beziehen; es ist dazu kein
Mehraufwand nötig.

@node Erstellungs-Manifest
@section Bonus: Erstellungs-Manifest

Mit der Cuirass-Spezifikation oben können wir uns gut anfreunden: Jedes
Paket in unserem Kanal wird erstellt, einschließlich einiger Varianten
(siehe @ref{Kontinuierliche Integration einrichten}). Allerdings können wir in
manchen Fällen noch nicht alles ausdrücken, was wir möchten, etwa wenn wir
in manchen Cuirass-Jobs cross-kompilieren möchten, Transformationen
festlegen oder Docker-Abbilder, RPM-/Deb-Pakete oder sogar Systemtests
wollen.

Das erreichen Sie, indem Sie ein @dfn{Manifest} mit den Angaben schreiben
(siehe @ref{Manifeste verfassen,,, guix.de, Referenzhandbuch zu GNU
Guix}). Das Manifest, was wir für Guile haben, hat Einträge für die oben
definierten Paketvarianten sowie zusätzliche Varianten und
Cross-Erstellungen:

@lisp
;; Dies ist ‚.guix/manifest.scm‘.

(use-modules (guix)
             (guix profiles)
             (guile-package))   ;unser eigenes Paketmodul importieren

(define* (package->manifest-entry* package system
                                   #:key target)
  "Gibt einen Manifest-Eintrag für das Paket PACKAGE für SYSTEM
zurück. Optional wird für das Zielsystem TARGET cross-kompiliert."
  (manifest-entry
    (inherit (package->manifest-entry package))
    (name (string-append (package-name package) "." system
                         (if target
                             (string-append "." target)
                             "")))
    (item (with-parameters ((%current-system system)
                            (%current-target-system target))
            package))))

(define native-builds
  (manifest
   (append (map (lambda (system)
                  (package->manifest-entry* guile system))

                '("x86_64-linux" "i686-linux"
                  "aarch64-linux" "armhf-linux"
                  "powerpc64le-linux"))
           (map (lambda (guile)
                  (package->manifest-entry* guile "x86_64-linux"))
                (cons (package
                        (inherit (package-with-c-toolchain
                                  guile
                                  `(("clang-toolchain"
                                     ,(specification->package
                                       "clang-toolchain")))))
                        (name "guile-clang"))
                      (list guile-without-threads
                            guile-without-networking
                            guile-debug
                            guile-strict-typing))))))

(define cross-builds
  (manifest
   (map (lambda (target)
          (package->manifest-entry* guile "x86_64-linux"
                                    #:target target))
        '("i586-pc-gnu"
          "aarch64-linux-gnu"
          "riscv64-linux-gnu"
          "i686-w64-mingw32"
          "x86_64-linux-gnu"))))

(concatenate-manifests (list native-builds cross-builds))
@end lisp

Wir gehen nicht auf die Details dieses Manifests ein; es genügt zu wissen,
dass wir dadurch mehr Flexibilität haben. Wir müssen jetzt Cuirass die
Information geben, dass damit dieses Manifest erstellt werden soll; dazu
verwenden wir eine leicht abgeänderte Spezifikation verglichen mit vorher:

@lisp
;; Cuirass-Spezifikationsdatei, um alle Pakete des ‚guile‘-Kanals zu erstellen.
(list (specification
        (name "guile")
        (build '(manifest ".guix/manifest.scm"))
        (channels
         (append (list (channel
                         (name 'guile)
                         (url "https://git.savannah.gnu.org/git/guile.git")
                         (branch "main")))
                 %default-channels))))
@end lisp

Wir haben im Teil @code{(build …)} der Spezifikation jetzt @code{'(manifest
".guix/manifest.scm")} verwendet, damit unser Manifest genommen wird, und
das war schon alles!

@node Zusammenfassung
@section Zusammenfassung

In diesem Kapitel haben wir die Vorgehensweise auf Guile angewandt und das
Ergebnis lässt sich hier bestaunen:

@itemize
@item
@uref{https://git.savannah.gnu.org/cgit/guile.git/tree/.guix-channel?id=cd57379b3df636198d8cd8e76c1bfbc523762e79,@code{.guix-channel}},
@item
@uref{https://git.savannah.gnu.org/cgit/guile.git/tree/.guix/modules/guile-package.scm?id=cd57379b3df636198d8cd8e76c1bfbc523762e79,@code{.guix/modules/guile-package.scm}}
auch symbolisch verknüpft als @file{guix.scm} auf der oberstem
Verzeichnisebene,
@item
@uref{https://git.savannah.gnu.org/cgit/guile.git/tree/.guix/manifest.scm?id=cd57379b3df636198d8cd8e76c1bfbc523762e79,@code{.guix/manifest.scm}}.
@end itemize

Heutzutage werden Repositorys gemeinhin mit Dotfiles für vielerlei Werkzeuge
angereichert: @code{.envrc}, @code{.gitlab-ci.yml},
@code{.github/workflows}, @code{Dockerfile}, @code{.buildpacks},
@code{Aptfile}, @code{requirements.txt} und Weiteres. Es wirkt so, als
würden wir Sie zu @emph{noch mehr} Dateien überreden, jedoch können Sie mit
diesen Dateien so viel ausdrücken, dass sie die meisten oder alle der oben
genannten Dateien @emph{ersetzen}.

Mit wenigen Dateien bekommen wir Unterstützung für:

@itemize
@item
Entwicklungsumgebungen (@command{guix shell}),
@item
Test-Erstellungen in naturbelassener Umgebung, auch für Paketvarianten und
cross-kompiliert (@command{guix build}),
@item
kontinuierliche Integration (ob mit Cuirass oder mit einem anderen
Werkzeug),
@item
kontinuierliche Auslieferung an Nutzer (über den Kanal und mit vorerstellten
Binärdateien),
@item
abgeleitete Erstellungsartefakte wie Docker-Abbildern oder Deb-/RPM-Pakete
(@command{guix pack}).
@end itemize

Das ist (wie wir es sehen) ein Schweizer Taschenmesser für reproduzierbare
Software-Auslieferung und diese Erklärung sollte aufgezeigt haben, welchen
Nutzen Sie als Entwickler daraus gewinnen können!


@c *********************************************************************
@node Umgebungen verwalten
@chapter Umgebungen verwalten

Guix liefert mehrere Werkzeuge mit, um die Umgebung zu verwalten. Dieses
Kapitel zeigt solche Werkzeuge.

@menu
* Guix-Umgebung mit direnv::  Mit direnv Guix-Umgebungen einrichten.
@end menu

@node Guix-Umgebung mit direnv
@section Guix-Umgebung mit direnv

Guix stellt ein @samp{direnv}-Paket zur Verfügung, mit der die Shell nach
einem Verzeichniswechsel erweitert werden kann. Dieses Werkzeug kann benutzt
werden, um eine reine, „pure“ Guix-Umgebung vorzubereiten.

Das folgende Beispiel zeigt eine Shell-Funktion für die
@file{~/.direnvrc}-Datei, die in einer Datei @file{~/src/guix/.envrc} in
Guix’ Git-Repository benutzt werden kann, um eine zur Beschreibung im
@ref{Erstellung aus dem Git,,, guix.de, Referenzhandbuch zu GNU Guix}
ähnliche Erstellungsumgebung herzustellen.

Erstellen Sie eine @file{~/.direnvrc} mit einem Bash-Code darin:

@example
# Dank an <https://github.com/direnv/direnv/issues/73#issuecomment-152284914>
export_function()
@{
  local name=$1
  local alias_dir=$PWD/.direnv/aliases
  mkdir -p "$alias_dir"
  PATH_add "$alias_dir"
  local target="$alias_dir/$name"
  if declare -f "$name" >/dev/null; then
    echo "#!$SHELL" > "$target"
    declare -f "$name" >> "$target" 2>/dev/null
    # Beachten Sie, wir fügen Shell-Variable in den Funktionsauslöser ein.
    echo "$name \$*" >> "$target"
    chmod +x "$target"
  fi
@}

use_guix()
@{
    # GitHub-Token festlegen.
    export GUIX_GITHUB_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

    # Deaktivieren von 'GUIX_PACKAGE_PATH'.
    export GUIX_PACKAGE_PATH=""

    # Müllsammlerwurzel neu erzeugen.
    gcroots="$HOME/.config/guix/gcroots"
    mkdir -p "$gcroots"
    gcroot="$gcroots/guix"
    if [ -L "$gcroot" ]
    then
        rm -v "$gcroot"
    fi

    # Verschiedene Pakete.
    PACKAGES_MAINTENANCE=(
        direnv
        git
        git:send-email
        git-cal
        gnupg
        guile-colorized
        guile-readline
        less
        ncurses
        openssh
        xdot
    )

    # In die Umgebung aufzunehmende Pakete.
    PACKAGES=(help2man guile-sqlite3 guile-gcrypt)

    # Dank an <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00859.html>
    eval "$(guix shell --search-paths --root="$gcroot" --pure \
     --development guix $@{PACKAGES[@@]@} $@{PACKAGES_MAINTENANCE[@@]@} "$@@")"

    # configure-Optionen vordefinieren.
    configure()
    @{
        ./configure
    @}
    export_function configure

    # make ausführen und optional etwas erstellen.
    build()
    @{
        make -j 2
        if [ $# -gt 0 ]
        then
            ./pre-inst-env guix build "$@@"
        fi
    @}
    export_function build

    # Git-Befehl zum Pushen vordefinieren.
    push()
    @{
        git push --set-upstream origin
    @}
    export_function push

    clear                        # Den Bildschirm löschen.
    git-cal --author='Ihr Name'  # Kalender bisheriger Beiträge zeigen.

    # Befehlsübersicht anzeigen.
    echo "
build          ein Paket oder, ohne Argumente, ein Projekt erstellen
configure      ./configure mit vordefinierten Parametern
push           ins Upstream-Git-Repository pushen
"
@}
@end example

Jedes Projekt, das eine @file{.envrc} mit einer Zeichenkette @code{use guix}
enthält, wird vordefinierte Umgebungsvariable und Prozeduren verwenden.

Führen Sie @command{direnv allow} aus, um die Umgebung bei der ersten
Nutzung einzurichten.


@c *********************************************************************
@node Reproduzierbare Wissenschaft
@chapter Guix zur reproduzierbaren Wissenschaft heranziehen

@cindex reproducible research
Because it supports reproducible deployment, Guix is a solid foundation for
@dfn{reproducible research workflows}.  This section is targeted at
scientists; it shows how to add Guix to one's reproducible research
toolbox@footnote{This chapter is adapted from a
@uref{https://hpc.guix.info/blog/2023/06/a-guide-to-reproducible-research-papers/,
blog post published on the Guix-HPC web site in 2023.}.}.

With Guix as the basis of your computational workflow, you can get what's in
essence @emph{executable provenance meta-data}: it's like the list of
package name/version pairs some provide as an appendix to their publication,
except more precise and immediately deployable.

This section is a guide in just four steps on how to make your computational
experiments reproducible using Guix, and how to provide that information in
your research paper.

@menu
* Setting Up the Environment::  Step 1: using `guix shell'.
* Recording the Environment::  Step 2: using `guix describe'.
* Ensuring Long-Term Source Code Archiving::  Step 3: Software Heritage.
* Referencing the Software Environment::  Step 4: SWHIDs.
@end menu

@node Setting Up the Environment
@section Step 1: Setting Up the Environment

The first step is to identify precisely what packages you need in your
software environment to run your computational experiment.

Assuming you have a Python script that uses NumPy, you can start by creating
an environment that contains these two packages and to run your code in that
environment (@pxref{Invoking guix shell,,, guix, GNU Guix Reference
Manual}):

@example
guix shell -C python python-numpy -- python3 ./myscript.py
@end example

The @code{-C} flag here (or @code{--container}) instructs @command{guix
shell} to create that environment in an isolated container with nothing but
the two packages you asked for.  That way, if @command{./myscript.py} needs
more than these two packages, it'll fail to run and you'll immediately
notice.  On some systems @code{--container} is not supported; in that case,
you can resort to @code{--pure} instead.

Perhaps you'll find that you also need Pandas and add it to the environment:

@example
guix shell -C python python-numpy python-pandas -- \
  python3 ./myscript.py
@end example

If you fail to guess the name of the package (this one was easy!), try
@code{guix search}.

Environments for Python, R, and similar high-level languages are relatively
easy to set up.  For C/C++ code, you may need more packages:

@example
guix shell -C gcc-toolchain cmake coreutils grep sed make -- @dots{}
@end example

Oder vielleicht denken Sie sich, dass Sie auch gleich eine Paketdefinition
für Ihren Code angeben könnten – siehe @ref{Pakete definieren,,, guix.de,
Referenzhandbuch zu GNU Guix}, wenn sie erfahren möchten, wie das geht.

Eventually, you'll have a list of packages that satisfies your needs.

@quotation What if a package is missing?
Guix and the main scientific channels provide about
@uref{https://hpc.guix.info/browse, tens of thousands of packages}.  Yet,
there's always the possibility that the one package you need is missing.

In that case, you will need to provide a definition for it (@pxref{Defining
Packages,,, guix, GNU Guix Reference Manual}) in a dedicated channel of
yours (@pxref{Creating a Channel,,, guix, GNU Guix Reference Manual}).  For
software in Python, R, and other high-level languages, most of the work can
usually be automated by using @command{guix import} (@pxref{Invoking guix
import,,, guix, GNU Guix Reference Manual}).

Join @uref{https://guix.gnu.org/contact/,the friendly Guix community} to get
help!
@end quotation

@node Recording the Environment
@section Step 2: Recording the Environment

Now that you have that @code{guix shell} command line with a list of
packages, the best course of action is to save it in a @emph{manifest}
file---essentially a software bill of materials---that Guix can then ingest
(@pxref{Writing Manifests,,, guix, GNU Guix Reference Manual}).  The easiest
way to get started is by ``translating'' your command line into a manifest:

@example
guix shell python python-numpy python-pandas \
  --export-manifest > manifest.scm
@end example

Put that manifest under version control! From there anyone can redeploy the
software environment described by the manifest and run code in that
environment:

@example
guix shell -C -m manifest.scm -- python3 ./myscript.py
@end example

Here's what @file{manifest.scm} reads:

@lisp
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(specifications->manifest
  (list "python" "python-numpy" "python-pandas"))
@end lisp

It's a code snippet that lists packages.  Notice that there are no version
numbers! Indeed, these version numbers are specified in package definitions,
located in Guix channels.  To allow others to reproduce the exact same
environment as the one you're running, you need to @emph{pin Guix itself} ,
by capturing the current Guix channel commits with @command{guix describe}
(@pxref{Replicating Guix,,, guix, GNU Guix Reference Manual}):

@example
guix describe -f channels > channels.scm
@end example

@cindex lock files, for reproducibility
This @code{channels.scm} file is similar in spirit to ``lock files'' that
some deployment tools employ to pin package revisions. You should also keep
it under version control in your code, and possibly update it once in a
while when you feel like running your code against newer versions of its
dependencies. With this file, anyone, @emph{at any time and on any machine},
can now reproduce the exact same environment by running:

@example
guix time-machine -C channels.scm -- \
  shell -C -m manifest.scm -- \
  python3 ./myscript.py
@end example

In this example we rely solely on the @code{guix} channel, which provides
the Python packages we need. Perhaps some of the packages you need live
@uref{https://hpc.guix.info/channels,in other channels}---maybe
@code{guix-cran} if you use R, maybe @code{guix-science}.  That's fine:
@code{guix describe} also captures that.

Of course do include a @file{README} file giving the exact command to run
the code. Not everyone uses Guix so it can be helpful to also provide
minimal non-Guix setup instructions: which package versions are used, how
software is built, etc. As we have seen, such instructions would likely be
inaccurate and inconvenient to follow at best. Yet, it can be a useful
starting point to someone trying to recreate a @emph{similar} environment
using different tools. It should probably be presented as such, with the
understanding that the only way to get the @emph{same} environment is to use
Guix.

@node Ensuring Long-Term Source Code Archiving
@section Step 3: Ensuring Long-Term Source Code Archiving

We insisted on version control before: for the @file{manifest.scm} and
@file{channels.scm} files, but of course also for your own code. Our
recommendation is to have these two @file{.scm} files in the same repository
as the code they're about.

Since the goal is enabling reproducibility, source code availability is a
prime concern.  Source code hosting services come and go and we don't want
our code to vanish in a whim and render our published research work
unverifiable. @uref{https://www.softwareheritage.org/,Software Heritage}
(SWH for short) is @emph{the} solution for this: SWH archives public source
code and provides unique intrinsic identifiers to refer to
it---@uref{https://swhid.org, @dfn{SWHIDs}}.  Guix itself is
@uref{https://doi.org/10.1145/3641525.3663622,connected to SWH} to (1)@
ensure that the source code of its packages is archived, and (2)@ to fall
back to downloading from the SWH archive should code vanish from its
original site.

Once your own code is available in a public version-control repository, such
as a Git repository on your lab's hosting service, you can ask SWH to
archive it by going to its
@uref{https://archive.softwareheritage.org/save/,Save Code Now} interface.
SWH will process the request asynchronously and eventually you'll find your
code has made it into @uref{https://archive.softwareheritage.org/,the
archive}.

@node Referencing the Software Environment
@section Step 4: Referencing the Software Environment

This brings us to the last step: referring to our code @emph{and} software
environment in our beloved paper.  We already have all our code and Guix
files in the same repository, which is archived on SWH.  Thanks to SWH, we
now have a SWHID, which uniquely identifies the relevant revision of our
code.

Following
@uref{https://www.softwareheritage.org/howto-archive-and-reference-your-code/,SWH's
own guide}, we'll pick an @code{swh:dir} kind of identifier, which refers to
the directory of the relevant revision/commit of our repository, and we'll
keep @emph{contextual info} for clarity---that includes the original
URL. Putting it all together, we'll conclude our paper with a sentence along
these lines:

@quotation Example
The source code used to produce this study, as well as instructions to run
it in the right software environment using GNU@ Guix, is archived on
Software Heritage as
@uref{https://archive.softwareheritage.org/swh:1:dir:cc8919d7705fbaa31efa677ce00bef7eb374fb80;origin=https://gitlab.inria.fr/lcourtes-phd/edcc-2006-redone;visit=swh:1:snp:71a4d08ef4a2e8455b67ef0c6b82349e82870b46;anchor=swh:1:rev:36fde7e5ba289c4c3e30d9afccebbe0cfe83853a,@code{swh:1:dir:cc8919d7705fbaa31efa677ce00bef7eb374fb80;origin=https://gitlab.inria.fr/lcourtes-phd/edcc-2006-redone;visit=swh:1:snp:71a4d08ef4a2e8455b67ef0c6b82349e82870b46;anchor=swh:1:rev:36fde7e5ba289c4c3e30d9afccebbe0cfe83853a}}.
@end quotation

With this information, the reader can:

@itemize
@item
get the source code;
@item
reproduce its software environment with @code{guix time-machine} and run the
code;
@item
inspect and possibly modify both the code and its environment.
@end itemize

Mission accomplished!

@c *********************************************************************
@node Auf einem Rechencluster installieren
@chapter Auf einem Rechencluster installieren

@cindex Installation auf einem Cluster
@cindex Hochleistungsrechnen (HPC)
@cindex HPC, Hochleistungsrechnen
Guix eignet sich sehr für Forscher und jene, die sich mit
Hochleistungsrechnen (@acronym{HPC, High-Performance Computing}) befassen:
Komplexe Software-Stacks lassen sich leicht aufspielen und deren
Zusammenstellung ist auch noch reproduzierbar@tie{}– Sie können genau die
gleiche Software für andere Maschinen und zu einem späteren Zeitpunkt wieder
installieren.

In diesem Kapitel wird erörtert, wie der Systemadministrator eines Clusters
auf diesem systemweit Guix zur Verfügung stellen kann, so dass es auf allen
Knoten im Cluster benutzt werden kann. Außerdem gehen wir auf mögliche
Probleme ein@footnote{Das Kapitel ist eine aufgearbeitete Fassung eines
@uref{https://hpc.guix.info/blog/2017/11/installing-guix-on-a-cluster/,
Blog-Eintrags auf dem Guix-HPC-Webauftritt von 2017}.}.

@quotation Anmerkung
Wir gehen hier davon aus, dass auf dem Cluster eine andere
GNU/Linux-Distribution als Guix System läuft und wir Guix auf dieser
installieren werden.
@end quotation

@menu
* Den Zentralrechner konfigurieren::  Auf diesem Rechner läuft der Daemon.
* Die Arbeitsrechner konfigurieren::  Die Client-Knoten.
* Netzwerkzugriff im Cluster::  Der Umgang mit eingeschränktem 
                                  Netzwerkzugriff.
* Speicherplatz im Cluster::  Mit dem Plattenplatz haushalten.
* Sicherheit im Cluster::    Sicherheit gewährleisten.
@end menu

@node Den Zentralrechner konfigurieren
@section Den Zentralrechner konfigurieren

Unsere Empfehlung ist, eine Maschine zum Zentralrechner zu ernennen (als
„Head Node“) und auf dieser @command{guix-daemon} auszuführen, wobei
@file{/gnu/store} über NFS mit den Arbeitsrechnern („Compute Nodes“) geteilt
wird.

Zur Erinnerung: @command{guix-daemon} ist das Hintergrundprogramm, mit dem
für Clients Erstellungsprozesse angelegt und Dateien heruntergeladen werden
können (siehe @ref{Aufruf des guix-daemon,,, guix.de, Referenzhandbuch zu
GNU Guix}), und das allgemein auf @file{/gnu/store} zugreift. Dort liegen
dann alle Paket-Binärdateien, die irgendeiner der Nutzer erstellen lassen
hat (siehe @ref{Der Store,,, guix.de, Referenzhandbuch zu GNU Guix}). Mit
„Clients“ meinen wir die Guix-Befehle, die Benutzer aufgerufen haben, wie
etwa @code{guix install}. Auf einem Cluster können diese Befehle auf den
Arbeitsrechnern aufgerufen werden und dennoch werden wir sie mit der
zentralen @code{guix-daemon}-Instanz sprechen lassen.

Legen wir los. Für den Anfang folgen wir auf dem Zentralrechner der
Anleitung zur Installation aus einer Binärdatei (siehe @ref{Aus Binärdatei
installieren,,, guix.de, Referenzhandbuch zu GNU Guix}). Zum Glück gibt es
das Installationsskript, so dass das schnell gehen dürfte. Wenn die
Installation dann abgeschlossen ist, müssen wir daran Anpassungen vornehmen.

Weil wir möchten, dass @code{guix-daemon} @emph{nicht} nur auf dem
Zentralrechner zugänglich ist, sondern von jedem der Arbeitsrechner erreicht
wird, richten wir es so ein, dass er auf Verbindungen über TCP/IP
lauscht. Dazu bearbeiten wir die systemd-Datei zum Start von
@command{guix-daemon}, @file{/etc/systemd/system/guix-daemon.service}, und
fügen ein Argument @code{--listen} zur @code{ExecStart}-Zeile hinzu. Diese
sieht jetzt ungefähr so aus:

@c Since Debian Buster, \ is documented to split lines.
@c https://manpages.debian.org/buster/systemd/systemd.exec.5.en.html
@c Use it in PDF and Info versions to avoid cut-off at the page border.
@ifnothtml
@example
ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon \
    --build-users-group=guixbuild \
    --listen=/var/guix/daemon-socket/socket --listen=0.0.0.0
@end example
@end ifnothtml
@ifhtml
@example
ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild --listen=/var/guix/daemon-socket/socket --listen=0.0.0.0
@end example
@end ifhtml

Die Änderungen wirken sich erst aus, wenn der Dienst neu gestartet wurde:

@example
systemctl daemon-reload
systemctl restart guix-daemon
@end example

@quotation Anmerkung
Mit @code{--listen=0.0.0.0} ist gemeint, dass @code{guix-daemon} @emph{alle}
auf Port 44146 eingehenden TCP-Verbindungen annimmt (siehe @ref{Aufruf des
guix-daemon,,, guix.de, Referenzhandbuch zu GNU Guix}). Das ist
normalerweise auf Rechen-Clustern in Ordnung, weil der Zentralrechner für
gewöhnlich ausschließlich vom lokalen Netzwerk des Clusters aus erreichbar
ist@tie{}– unter keinen Umständen darf er für das gesamte Internet
zugänglich sein!
@end quotation

Als Nächstes müssen wir unsere NFS-Freigaben in
@uref{https://linux.die.net/man/5/exports,@file{/etc/exports}}
definieren. Dazu fügen wir etwas wie hier hinzu:

@example
/gnu/store    *(ro)
/var/guix     *(rw, async)
/var/log/guix *(ro)
@end example

Es genügt, das Verzeichnis @file{/gnu/store} nur lesbar zu exportieren, weil
es nur durch @command{guix-daemon} auf dem Hauptknoten jemals verändert
wird. In @file{/var/guix} befinden sich @emph{Benutzerprofile}, die man mit
@command{guix package} anlegen kann. Damit Benutzer also Pakete mit
@command{guix package} installieren können, muss Lese- und Schreibzugriff
ermöglicht werden.

Nutzer können so viele Profile anlegen, wie sie möchten, zusätzlich zum
Standardprofil, @file{~/.guix-profile}. Zum Beispiel bekommt jemand, die
@code{guix package -p ~/dev/python-dev -i python} ausführt, Python in einem
Profil installiert, das über die symbolische Verknüpfung
@code{~/dev/python-dev} erreichbar ist. Damit dieses Profil @emph{nicht}
irgendwann vom Müllsammler weggeräumt wird@tie{}– d.h.@: damit Python nicht
aus @file{/gnu/store} entfernt wird, solange dieses Profil existiert@tie{}–,
@emph{müssen die Persönlichen Verzeichnisse in @file{/home} auch auf dem
Zentralrechner eingebunden sein}. Wir wollen, dass @code{guix-daemon} über
solche Nicht-Standard-Profile weiß, dass die darin referenzierte Software
noch gebraucht wird.

Es kann allerdings sinnvoll sein, Software die @emph{nicht} gebraucht wird,
regelmäßig aus @file{/gnu/store} zu löschen. Verwenden Sie dazu
@command{guix gc} (siehe @ref{Aufruf von guix gc,,, guix.de,
Referenzhandbuch zu GNU Guix}). Dazu können Sie so einen crontab-Eintrag auf
dem Zentralknoten vornehmen:

@example
root@@master# crontab -e
@end example

@noindent
… und schreiben Sie etwa:

@example
# Jeden Tag um 5 Uhr morgens den Müllsammler schicken,
# damit mindestens 10 GB auf /gnu/store verfügbar sind.
0 5 * * 1  /usr/local/bin/guix gc -F10G
@end example

So viel zum Zentralrechner! Jetzt geht’s an die Arbeitsknoten.

@node Die Arbeitsrechner konfigurieren
@section Die Arbeitsrechner konfigurieren

Zunächst einmal müssen die Arbeitsknoten auch die NFS-Verzeichnisse
einbinden, die vom Zentralrechner angeboten werden. Dafür müssen die
folgenden Zeilen in
@uref{https://linux.die.net/man/5/fstab,@file{/etc/fstab}} hinzugefügt
werden:

@example
@var{zentralrechner}:/gnu/store    /gnu/store    nfs  defaults,_netdev,vers=3 0 0
@var{zentralrechner}:/var/guix     /var/guix     nfs  defaults,_netdev,vers=3 0 0
@var{zentralrechner}:/var/log/guix /var/log/guix nfs  defaults,_netdev,vers=3 0 0
@end example

@noindent
… wobei Sie anstelle von @var{zentralrechner} den Namen oder die IP-Adresse
Ihres Zentralrechners hinterlegen. Von da an sollten Sie diese
Verzeichnisse, wenn die Einhängepunkte auch existieren, jeweils auf den
Arbeitsknoten einbinden können.

Zudem müssen wir unseren Benutzern einen @command{guix}-Befehl
vorinstallieren, den sie verwenden können, wenn sie sich zum ersten Mal mit
dem Cluster verbinden (damit werden sie @command{guix pull} aufrufen,
wodurch ihnen ihr „eigener“ @command{guix}-Befehl zur Verfügung gestellt
wird). Analog zum Installationsskript der Guix-Binärdatei auf dem
Zentralrechner werden wir unser @command{guix} ebenfalls in
@file{/usr/local/bin} unterbringen:

@example
mkdir -p /usr/local/bin
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix \
      /usr/local/bin/guix
@end example

Wir müssen dafür sorgen, dass sich @code{guix} mit dem Daemon auf dem
Zentralrechner verbindet, indem wir diese Zeilen zu @code{/etc/profile}
hinzufügen:

@example
GUIX_DAEMON_SOCKET="guix://@var{zentralrechner}"
export GUIX_DAEMON_SOCKET
@end example

Damit unseren Benutzern keine Warnungen angezeigt werden und damit
@code{guix} die richtigen Locale-Spracheinstellungen benutzen kann, müssen
wir angeben, wo die von Guix bereitgestellten Locale-Daten zu finden sind
(siehe @ref{Anwendungen einrichten,,, guix.de, Referenzhandbuch zu GNU
Guix}):

@example
GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
export GUIX_LOCPATH

# Der Name, den wir hier für die Locale angeben, muss gültig sein.
# Geben Sie "ls $GUIX_LOCPATH/*" ein, um die möglichen Namen zu sehen.
LC_ALL=fr_FR.utf8
export LC_ALL
@end example

Um die Nutzung zu vereinfachen, legt @code{guix package} selbstständig die
Datei @file{~/.guix-profile/etc/profile} an, worin alle Umgebungsvariablen
definiert sind, um die Pakete zu benutzen@tie{}– @code{PATH},
@code{C_INCLUDE_PATH}, @code{PYTHONPATH}, etc. Das Gleiche gilt für
@command{guix pull}, was eine Datei innerhalb von
@file{~/.config/guix/current} anlegt. Diese Definitionen sollten Sie daher
in @code{/etc/profile} mit @code{source} laden lassen:

@example
for GUIX_PROFILE in "$HOME/.config/guix/current" "$HOME/.guix-profile"
do
  if [ -f "$GUIX_PROFILE/etc/profile" ]; then
    . "$GUIX_PROFILE/etc/profile"
  fi
done
@end example

Zu guter Letzt können Guix-Befehle durch Bash und zsh ergänzt werden. In
@code{/etc/bashrc} fügen Sie dazu diese Zeile hinzu:

@verbatim
. /var/guix/profiles/per-user/root/current-guix/etc/bash_completion.d/guix
@end verbatim

Erledigt!

Überprüfen Sie, dass alles klappt, indem Sie sich auf einem der
Arbeitsrechner anmelden und dies ausführen:

@example
guix install hello
@end example

Daraufhin sollte der Daemon auf dem Zentralrechner für Sie die vorerstellten
Binärdateien herunterladen und nach @file{/gnu/store} entpacken, wonach
@command{guix install} dann @file{~/.guix-profile} anlegt und darin wird der
Befehl @file{~/.guix-profile/bin/hello} zu finden sein.

@node Netzwerkzugriff im Cluster
@section Netzwerkzugriff

Guix setzt voraus, dass Netzwerkzugriff besteht, um Quellcode und
vorerstellte Binärdateien herunterzuladen. Die gute Nachricht ist, dass nur
der Zentralrechner Netzwerkzugriff braucht, weil die Arbeitsrechner an
diesen delegieren.

Üblicherweise haben Knoten im Cluster höchstens Zugriff auf eine ausgesuchte
„Positivliste“ erlaubter Kommunikationspartner. Für den Zentralrechner muss
zumindest @code{ci.guix.gnu.org} auf dieser Positivliste stehen, denn von
dort stammen in der Vorgabeeinstellung die vorerstellten Binärdateien für
alle Pakete, die das eigentliche Guix kennt.

Nebenbei ist @code{ci.guix.gnu.org} außerdem ein inhaltsadressierbarer
Spiegelserver für die Quelldateien all dieser Pakete. Daher ist es
ausreichend, wenn Sie @emph{nur} @code{ci.guix.gnu.org} auf die Positivliste
setzen.

Software-Pakete, die in einem getrennten Repository angeboten werden wie
beispielsweise den @uref{https://hpc.guix.info/channels, HPC-Kanälen},
können natürlich nicht von @code{ci.guix.gnu.org} bezogen werden. Für diese
Pakete möchten Sie unter Umständen weitere Server auf die Positivliste
setzen, von denen für die fremden Pakete Quell- und Binärdateien
heruntergeladen werden können (vorausgesetzt jemand stellt vorerstellte
Binärdateien für sie zur Verfügung). Wenn nicht, können Benutzer als Ausweg
auch den Quellcode auf ihre Workstations herunterladen und dann in
@file{/gnu/store} auf dem Cluster hochladen. Das geht so:

@verbatim
GUIX_DAEMON_SOCKET=ssh://compute-node.example.org \
  guix download http://starpu.gforge.inria.fr/files/starpu-1.2.3/starpu-1.2.3.tar.gz
@end verbatim

Der obige Befehl lädt @code{starpu-1.2.3.tar.gz} herunter @emph{und} lässt
es über SSH durch die @code{guix-daemon}-Instanz auf dem Cluster speichern.

Wenn Ihr Cluster gänzlich von der Außenwelt abgeschnitten ist
(„air-gapped“), ist es aufwendiger. In diesem Fall würden wir dazu raten,
dass sie sämtlichen nötigen Quellcode auf eine Workstation herunterladen,
auf der Guix läuft. Dafür gibt es zum Beispiel die Befehlszeilenoption
@option{--sources} für @command{guix build} (siehe @ref{Aufruf von guix
build,,, guix.de, Referenzhandbuch zu GNU Guix}); folgendes Beispiel zeigt,
wie Sie sämtlichen Quellcode, von dem das @code{openmpi}-Paket abhängt,
herunterladen:

@example
$ guix build --sources=transitive openmpi

…

/gnu/store/xc17sm60fb8nxadc4qy0c7rqph499z8s-openmpi-1.10.7.tar.bz2
/gnu/store/s67jx92lpipy2nfj5cz818xv430n4b7w-gcc-5.4.0.tar.xz
/gnu/store/npw9qh8a46lrxiwh9xwk0wpi3jlzmjnh-gmp-6.0.0a.tar.xz
/gnu/store/hcz0f4wkdbsvsdky3c0vdvcawhdkyldb-mpfr-3.1.5.tar.xz
/gnu/store/y9akh452n3p4w2v631nj0injx7y0d68x-mpc-1.0.3.tar.gz
/gnu/store/6g5c35q8avfnzs3v14dzl54cmrvddjm2-glibc-2.25.tar.xz
/gnu/store/p9k48dk3dvvk7gads7fk30xc2pxsd66z-hwloc-1.11.8.tar.bz2
/gnu/store/cry9lqidwfrfmgl0x389cs3syr15p13q-gcc-5.4.0.tar.xz
/gnu/store/7ak0v3rzpqm2c5q1mp3v7cj0rxz0qakf-libfabric-1.4.1.tar.bz2
/gnu/store/vh8syjrsilnbfcf582qhmvpg1v3rampf-rdma-core-14.tar.gz
…
@end example

(Wenn Sie es genauer wissen wollen, haben wir hier mehr als 320@ MiB
@emph{komprimierten} Quellcodes.)

Daraus lässt sich ein gesammeltes Archiv für all den Quellcode basteln
(siehe @ref{Aufruf von guix archive,,, guix.de, Referenzhandbuch zu GNU
Guix}):

@verbatim
$ guix archive --export \
    `guix build --sources=transitive openmpi` \
    > openmpi-quellcode.nar
@end verbatim

… und dieses Archiv können wir dann mittels Wechseldatenträgern auf den
Cluster transportieren und dort entpacken:

@verbatim
$ guix archive --import < openmpi-quellcode.nar
@end verbatim

Wiederholen Sie diesen Vorgang, wann immer Sie neuen Quellcode auf den
Cluster schaffen müssen.

Wir schreiben das, aber zum jetzigen Zeitpunkt haben die
Forschungsinstitute, die mit Guix-HPC arbeiten, gar keinen Cluster mit Air
Gap. Wenn Sie Erfahrung damit haben, freuen wir uns über Rückmeldungen und
Vorschläge.

@node Speicherplatz im Cluster
@section Speicherplatz

@cindex Speicherplatz, auf einem Cluster
Systemadministratoren sind oft besorgt, ob Guix nicht Unmengen an
Plattenplatz verschlingen wird. Aber wenn überhaupt, werden
wissenschaftliche Datensätze und nicht kompilierte Software die
Speicherplatzfresser sein@tie{}– unserer Erfahrung nach, da wir schon fast
zehn Jahre lang Guix auf HPC-Clustern betreiben. Trotzdem lohnt sich ein
Blick, wie Guix zum Speicherplatzverbrauch beiträgt.

Zunächst einmal kostet es @emph{nicht} unbedingt viel, wenn mehrere
Versionen oder Varianten eines bestimmten Pakets in @file{/gnu/store}
liegen, weil @command{guix-daemon} gleiche Dateien dedupliziert und weil
Paketvarianten in der Regel viele Dateien gemeinsam haben.

Dann ist es, wie oben beschrieben, unsere Empfehlung, mit einem „Cron-Job“
regelmäßig @code{guix gc} aufzurufen, was @emph{nicht benutzte} Software aus
@file{/gnu/store} löscht. Dennoch kann es sein, dass Benutzer eine ganze
Menge Software in ihren Profilen übrig lassen oder dass sie viele alte
Generationen ihrer Profile horten, die dann „lebendig“ sind und aus Sicht
von @command{guix gc} @emph{nicht} gelöscht werden dürfen.

Die Lösung besteht darin, dass Nutzer die alten Generationen ihrer Profile
regelmäßig entfernen. Zum Beispiel werden mit folgendem Befehl alle
Generationen entfernt, die älter als zwei Monate sind:

@example
guix package --delete-generations=2m
@end example

Ebenso ist es eine gute Idee, den Nutzern nahezulegen, dass sie ihre Profile
regelmäßig auf den neuesten Stand aktualisieren, weil dann weniger Varianten
einer Software in @file{/gnu/store} bleiben müssen:

@example
guix pull
guix upgrade
@end example

Notfalls können Systemadministratoren die Profile teilweise anstelle der
Nutzer bereinigen. Das widerspricht allerdings einem Vorteil von Guix, dass
Benutzer viel Freiheit und Kontrolle über ihre Software-Umgebungen
bekommen. Wir empfehlen deutlich, die Kontrolle bei den Benutzern zu lassen.

@node Sicherheit im Cluster
@section Sicherheitsüberlegungen

@cindex Sicherheit, auf einem Cluster
Auf einem Hochleistungs-Cluster wird mit Guix normalerweise
wissenschaftliche Software verwaltet. Über sicherheitskritische Software wie
den Betriebssystem-Kernel und Systemdienste wie @code{sshd} und
„Batch“-Auftragsplaner haben weiterhin die Systemadministratoren die
Kontrolle.

Das Guix-Projekt kümmert sich zügig um Sicherheitsaktualisierungen (siehe
@ref{Sicherheitsaktualisierungen,,, guix.de, Referenzhandbuch zu GNU
Guix}). Um die Sicherheitsaktualisierungen zu bekommen, müssen Nutzer
@command{guix pull && guix upgrade} ausführen.

Weil in Guix Software-Varianten eine eindeutige Bezeichnung haben, lässt es
sich einfach überprüfen, ob jemand eine von Schwachstellen betroffene
Software verwendet. Zum Beispiel kann man für die Variante von glibc@ 2.25,
die den Patch zur Behebung der Sicherheitslücke namens
„@uref{https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt,Stack
Clash}“ noch nicht hat, prüfen, ob sie überhaupt in einem Benutzerprofil
verwendet wird:

@example
guix gc --referrers /gnu/store/…-glibc-2.25
@end example

Dadurch werden Profile gemeldet, die diese bestimmte glibc-Variante
verwenden.

@c *********************************************************************
@node Verwalten eines Guix System
@chapter Verwalten eines Guix System
@cindex Systemverwaltung
@cindex Systemadministrator

Weil man in Guix mit Paketen, Systemkonfiguration und Diensten anders
umgeht, als es andere („klassischere“) Distributionen vorsehen, müssen oft
manche gewohnte Arbeitsweisen leicht angepasst werden. In diesem Kapitel
wollen wir bei solchen Sachen helfen.

@menu
* Postgres für Cuirass aktualisieren::  Aktualisieren, wenn man noch das 
                                          vorgegebene Postgres hat.
@end menu

@node Postgres für Cuirass aktualisieren
@section Postgres für Cuirass aktualisieren

Weil der Vorgabewert des Pakets mit postgres in postgresql-configuration
jetzt als veraltet gilt (siehe b93434e656eba4260df82158a96c295000d3ff44),
ist eine Systemaktualisierung nur nach einigen manuellen Schritten
möglich. Hier geben wir einen Überblick.

Beachten Sie, wir beschreiben hier eine direkte Methode, die für kleine
Datenmengen geeignet ist. Für große Datenbanken benutzen Sie eventuell
besser @url{https://www.postgresql.org/docs/current/pgupgrade.html,
@code{pg_upgrade}}. Aber auch dann müssen Sie den Dienst und die
Systemaktualisierung wie hier beschrieben handhaben.

@enumerate
@item
Stoppen Sie Cuirass und deaktivieren Sie es.

Verhindern Sie somit, dass der Dienst neu startet und fehlschlägt, nachdem
rekonfiguriert wird.

    @code{sudo herd stop cuirass && sudo herd disable cuirass}

@item
Exportieren Sie ein Dump Ihrer Datenbank.

    @code{sudo su - postgres -s /bin/sh -c pg_dumpall > /tmp/pg.dump}

@item
Fügen Sie den Postgres-Dienst hinzu oder ändern Sie ihn.

Je nachdem, ob der Postgres-Dienst bei Ihnen implizit definiert ist (als
Abhängigkeit über den Cuirass-Dienst) oder in einem eigenen Eintrag der
@code{(services)}-Eigenschaft in Ihrem Betriebssystem deklariert ist, müssen
Sie ihn entweder hinzufügen oder die bestehende Konfiguration ändern, damit
sie Ihrer gewünschten Versionsänderung entspricht.

Achten Sie darauf, nicht auf einen Schlag zu postgres-16 zu aktualisieren –
aus ungeklärten Gründen mag der Cuirass-Dienst das @emph{nicht} gerne. Nach
einer kaputten Aktualisierung auf Postgres 16 musste ich die betroffenen
Dateien löschen und neu initialisieren.

@lisp
(service postgresql-service-type
         (postgresql-configuration
          (postgresql (@@ (gnu packages databases) postgresql-15))))
@end lisp

Anmerkung: Wenn es Ihnen passiert ist, dass Sie den Text hier ignoriert
haben und irgendwie blind den Beispielen gefolgt sind und @emph{doch auf 16
aktualisiert} haben, ist hier beschrieben, wie Sie den Zustand zurücksetzen:

@enumerate
@item
Löschen Sie die Dateien der Datenbankinstanz.

Nach Vorgabeeinstellung wohnen diese in @file{/var/lib/postgres/data}.

@item
Initialisieren Sie Postgres neu.

@code{sudo su - postgres -s /bin/sh -c 'pg_ctl init -D /var/lib/postgres/data'}
@end enumerate

@item
Rekonfigurieren Sie Ihr System.

@code{sudo guix system reconfigure path/to/your/altered/config.scm}

@item
Stellen Sie den Datenbankinhalt wieder her.

@code{sudo su - postgres -s /bin/sh -c 'psql -d postgres -f /tmp/pg.dump'}

@item
Aktivieren und starten Sie den Dienst.

@example
sudo herd enable cuirass
sudo herd start cuirass
@end example

@end enumerate


@c *********************************************************************
@node Danksagungen
@chapter Danksagungen

Guix baut auf dem @uref{https://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@tie{}– vielen Dank!

Dieses Dokument enthält angepasste Abschnitte aus Einträgen, die zuvor auf
dem Blog von Guix unter @uref{https://guix.gnu.org/blog} und dem
Guix-HPC-Blog unter @uref{https://hpc.guix.info/blog} veröffentlicht wurden.


@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

@bye

@c Local Variables:
@c ispell-local-dictionary: "american";
@c End:
