1.1 Ein Schnellkurs in Scheme

Die von Guix benutzte Scheme-Implementierung nennt sich Guile. Um mit der Sprache herumspielen zu können, installieren Sie Guile mit guix install guile und starten eine interaktive Programmierumgebung (englisch Read-Eval-Print-Loop, kurz REPL), indem Sie guile auf der Befehlszeile ausführen.

Alternativ können Sie auch den Befehl guix shell -- guile ausführen, wenn Sie Guile lieber 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 „⇒“ beginnt, zeigt sie das Ergebnis einer Auswertung, während Zeilen, die mit „-|“ beginnen, für eine angezeigte Ausgabe stehen. Siehe Using Guile Interactively in das Referenzhandbuch zu GNU Guile für mehr Details zur REPL.

• Die Scheme-Syntax ist an sich ein Baum von Ausdrücken (Lisp-Programmierer nennen sie symbolische Ausdrücke, kurz S-Ausdrücke bzw. englisch 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 #true und #false (abgekürzt auch #t und #f) jeweils für die Booleschen Werte „wahr“ und „falsch“.

  Beispiele für gültige Ausdrücke

  "Hallo Welt!"
  ⇒ "Hallo Welt!"
  
  17
  ⇒ 17
  
  (display (string-append "Hallo " "Guix" "\n"))
  -| Hallo Guix!
  ⇒ #<unspecified>
  

• 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.
• Anonyme Funktionen – bzw. Prozeduren, wie man in Scheme sagt – werden mit dem lambda-Term deklariert:

  (lambda (x) (* x x))
  ⇒ #<procedure 120e348 at <unknown port>:24:0 (x)>
  

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

  ((lambda (x) (* x x)) 3)
  ⇒ 9
  

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

• Allem kann mit define ein globaler Name zugewiesen werden:

  (define a 3)
  (define quadrat (lambda (x) (* x x)))
  (quadrat a)
  ⇒ 9
  

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

  (define (quadrat x) (* x x))
  

• Eine Listenstruktur kann mit der list-Prozedur erzeugt werden:

  (list 2 a 5 7)
  ⇒ (2 3 5 7)
  

• Für die Erzeugung und Verarbeitung von Listen stehen im Modul (srfi srfi-1) Standardprozeduren zur Verfügung (siehe Listenverarbeitung in Referenzhandbuch zu GNU Guile). Hier ein kurzer Überblick:

  (use-modules (srfi srfi-1))  ;Prozeduren zur Listenverarbeitung importieren
  
  (append (list 1 2) (list 3 4))
  ⇒ (1 2 3 4)
  
  (map (lambda (x) (* x x)) (list 1 2 3 4))
  ⇒ (1 4 9 16)
  
  (delete 3 (list 1 2 3 4))        ⇒ (1 2 4)
  (filter odd? (list 1 2 3 4))     ⇒ (1 3)
  (remove even? (list 1 2 3 4))    ⇒ (1 3)
  (find number? (list "a" 42 "b")) ⇒ 42
  

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

• Mit dem 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 nicht auf den anderen Termen aufgerufen (siehe quote in Referenzhandbuch zu GNU Guile). Folglich liefert es quasi eine Liste von Termen.

  '(display (string-append "Hallo " "Guix" "\n"))
  ⇒ (display (string-append "Hallo " "Guix" "\n"))
  
  '(2 a 5 7)
  ⇒ (2 a 5 7)
  

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

  `(2 a 5 7 (2 ,a 5 ,(+ a 4)))
  ⇒ (2 a 5 7 (2 3 5 7))
  

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

• In Guix gibt es außerdem eine aufgeputschte Form von S-Ausdrücken: die G-Ausdrücke oder „Gexps“, die ihre eigene Art von quasiquote und unquote haben: #~ (oder gexp) und #$ (oder ungexp). Mit Ihnen kennzeichnen Sie, welcher Code 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:

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

  Siehe G-Ausdrücke in Referenzhandbuch zu GNU Guix für Details zu G-Ausdrücken.

• Mehrere Variable können in einer lokalen Umgebung mit Bezeichnern versehen werden, indem Sie let benutzen (siehe Local Bindings in Referenzhandbuch zu GNU Guile):

  (define x 10)
  (let ((x 2)
        (y 3))
    (list x y))
  ⇒ (2 3)
  
  x
  ⇒ 10
  
  y
  error→ In procedure module-lookup: Unbound variable: y
  

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

  (let* ((x 2)
         (y (* x 3)))
    (list x y))
  ⇒ (2 6)
  

• Mit Schlüsselwörtern bestimmen wir normalerweise diejenigen Parameter einer Prozedur, die einen Namen haben sollen. Ihnen wird #: (Doppelkreuz und Doppelpunkt) vorangestellt, gefolgt von alphanumerischen Zeichen: #:etwa-so. Siehe Keywords in Referenzhandbuch zu GNU Guile.
• Das Prozentzeichen % 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 _ in C. Scheme behandelt % genau wie jedes andere Zeichen.
• Module werden mit Hilfe von define-module erzeugt (siehe Creating Guile Modules in Referenzhandbuch zu GNU Guile). Zum Beispiel definiert man mit

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

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

  Siehe Paketmodule in Referenzhandbuch zu GNU Guix für Informationen zu Modulen, in denen Pakete definiert werden.

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:

• Ein Scheme-Primer, von Christine Lemmer-Webber und dem Spritely Institute, auf Deutsch übersetzt von Florian Pelz.
• Scheme at a Glance von Steve Litt.
• 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 kostenlose Ausgabe online. Viele kennen es unter dem Akronym SICP.

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

  guix install sicp info-reader
  info sicp
  

Sie finden noch mehr Bücher, Anleitungen und andere Ressourcen auf https://schemers.org/.

2.1 Anleitung zum Paketeschreiben

GNU Guix zeichnet sich in erster Linie deswegen als das hackbare Paketverwaltungswerkzeug aus, weil es mit GNU Guile arbeitet, einer mächtigen, hochsprachlichen Programmiersprache, die einen der Dialekte von Scheme darstellt. Scheme wiederum gehört zur 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.

• Sie können sich Funktionen, Strukturen, Makros und all die Ausdrucksstärke von Scheme für Ihre Paketdefinitionen zu Nutze machen.
• Durch Vererbung können Sie ohne viel Aufwand ein Paket anpassen, indem Sie von ihm erben lassen und nur das Nötige abändern.
• 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 #:make-flags "..."-Argument an die Paketliste. Es wäre nicht übertrieben, hier an die 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 programmieren!

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.

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

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

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

$ 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

$ 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

$ guix package --install-from-file=my-hello.scm

$ guix package --list-installed=my-hello
my-hello	2.10	out
/gnu/store/f1db2mfm8syb8qvc357c53slbvf1g9m9-my-hello-2.10

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

mkdir ~/my-channel

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

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

my-hello

guix show -L ~/my-channel my-hello
guix build -L ~/my-channel my-hello

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

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

$ git clone https://git.savannah.gnu.org/git/guix.git

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

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

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

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

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

(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
            install-license-files
            reset-gzip-timestamps
            compress-documentation)))

(add-to-load-path "/path/to/guix/checkout")
,use (guix build gnu-build-system)
(map first %standard-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 install-license-files reset-gzip-timestamps compress-documentation)

(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? #true))
      (begin
        (if (string-suffix? ".zip" source)
            (invoke "unzip" source)
            (invoke "tar" "xvf" source))
        (chdir (first-subdirectory "."))))
  #true)

(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")))
    ;; …
    #true))

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

$ guix refresh hello

$ guix refresh hello --update

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

3.1 Automatisch an virtueller Konsole anmelden

Im Guix-Handbuch wird erklärt, wie man ein Benutzerkonto automatisch auf allen TTYs anmelden lassen kann (siehe auto-login to TTY in 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 tty1 in Ruhe lassen, weil dorthin nach Voreinstellung Warnungs- und Fehlerprotokolle ausgegeben werden.

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

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

Mit Hilfe von compose (siehe Higher-Order Functions in das Referenzhandbuch zu GNU Guile) kann man etwas wie 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.

3.2 Den Kernel anpassen

Im Kern ist Guix eine quellcodebasierte Distribution mit Substituten (siehe Substitute in 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 linux-libre-Kernelpaketdefinition ist tatsächlich eine Prozedur, die ein Paket liefert.

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

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

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

Alle Schlüssel, denen kein Wert zugewiesen wird, erben ihren Vorgabewert von der Definition von make-linux-libre. Wenn Sie die beiden Schnipsel oben vergleichen, ist anzumerken, dass sich der Code-Kommentar in ersterem auf #: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.

Es gibt zwei Möglichkeiten, einen Kernel mit eigener Kernel-Konfiguration zu erzeugen. Die erste ist, eine normale .config-Datei als native Eingabe zu unserem angepassten Kernel hinzuzufügen. Im Folgenden sehen Sie ein Schnipsel aus der angepassten 'configure-Phase der make-linux-libre-Paketdefinition:

(let ((build  (assoc-ref %standard-phases 'build))
      (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Wir benutzen eine eigene Kernel-Konfigurationsdatei oder eine
  ;; vorgegebene Konfigurationsdatei.
  (if config
      (begin
        (copy-file config ".config")
        (chmod ".config" #o666))
      (invoke "make" ,defconfig)))

Nun folgt ein Beispiel-Kernel-Paket. Das linux-libre-Paket ist nicht anders als andere Pakete und man kann von ihm erben und seine Felder ersetzen wie bei jedem anderen Paket.

(define-public linux-libre/E2140
  (package
    (inherit linux-libre)
    (native-inputs
     `(("kconfig" ,(local-file "E2140.config"))
      ,@(alist-delete "kconfig"
                      (package-native-inputs linux-libre))))))

Im selben Verzeichnis wie die Datei, die linux-libre-E2140 definiert, befindet sich noch eine Datei namens E2140.config, bei der es sich um eine richtige Kernel-Konfigurationsdatei handelt. Das Schlüsselwort defconfig von make-linux-libre wird hier leer gelassen, so dass die einzige Kernel-Konfiguration im Paket die im native-inputs-Feld ist.

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

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

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

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

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

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

Im obigen Beispiel ist %file-systems eine Sammlung solcher „Flags“, mit denen Unterstützung für verschiedene Dateisysteme aktiviert wird, %efi-support aktiviert Unterstützung für EFI und %emulation ermöglicht es einer x86_64-linux-Maschine, auch im 32-Bit-Modus zu arbeiten. Die Prozedur default-extra-linux-options ist die oben definierte, die hinzugefügt werden musste, um die vorgegebenen Konfigurationsoptionen für das 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 Gentoo-Handbuch, zum anderen die Dokumentation des Kernels selbst. Aus der Kernel-Dokumentation erfahren wir, dass make localmodconfig der Befehl sein könnte, den wir wollen.

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

tar xf $(guix build linux-libre --source)

Sobald wir im Verzeichnis mit dem Quellcode sind, führen Sie touch .config aus, um mit einer ersten, leeren .config anzufangen. make localmodconfig funktioniert so, dass angeschaut wird, was bereits in Ihrer .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:

guix shell -D linux-libre -- make localmodconfig

und uns die Ausgabe davon anzuschauen. Beachten Sie, dass die .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:

module pcspkr did not have configs CONFIG_INPUT_PCSPKR

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

CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m

Nachdem Sie alle Konfigurationsoptionen kopiert haben, führen Sie noch einmal 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. CONFIG_MODULES brauchen Sie, damit Sie Module getrennt erstellen und laden können und nicht alles im Kernel eingebaut sein muss. Sie brauchen auch 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 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.

3.3 Die Image-Schnittstelle von Guix System

In der Vergangenheit drehte sich in Guix System alles um eine 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 – diese kann alles von einer normalen x86_64-Maschine sein bis zu einem kleinen ARM-Einplatinenrechner wie dem Pine64 –, 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 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.

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

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

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

• gnu/system/images/hurd.scm
• gnu/system/images/pine64.scm
• gnu/system/images/novena.scm
• gnu/system/images/pinebook-pro.scm

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

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

Die Felder kernel und bootloader verweisen auf platinenspezifische Pakete.

Direkt darunter wird auch die Variable pine64-image-type definiert.

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

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

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

Der Hauptzweck dieses Verbunds ist, einer Prozedur, die ein operating-system in ein 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 operating-system-Konfigurationsdatei erzeugt wird:

guix system image my-os.scm

Dieser Befehl erwartet eine 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, image-type, indem wir die Befehlszeilenoption --image-type oder -t übergeben, und zwar so:

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

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

Es ergibt sich ein Abbild wie dieses:

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

Das ist das Aggregat aus dem in my-os.scm definierten operating-system und dem 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:

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

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

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

Führen Sie aus:

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

oder

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

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

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

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

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

3.4 Sicherheitsschlüssel verwenden

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.

• Einrichten einer Zwei-Faktor-Authentisierung (2FA)
• Abschalten der OTP-Code-Erzeugung beim Yubikey
• Yubikey verlangen, um eine KeePassXC-Datenbank zu entsperren

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

guix shell ungoogled-chromium -- chromium chrome://settings/securityKeys

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

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

guix shell yubikey-manager-qt -- ykman-gui

3.5 Dynamisches DNS als mcron-Auftrag

Wenn Sie von Ihrem Internetdienstanbieter nur dynamische IP-Adressen bekommen, aber einen statischen Rechnernamen möchten, können Sie einen Dienst für dynamisches DNS (Domain Name System) einrichten (auch bekannt unter der Bezeichnung 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 DuckDNS. Er sollte auch mit anderen Anbietern von dynamischem DNS funktionieren, die eine ähnliche Schnittstelle zum Wechsel der IP-Adresse haben, etwa https://freedns.afraid.org/, wenn Sie Kleinigkeiten anpassen.

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

(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/DOMAIN.token"
                                  get-string-all)))
                        (query-template (string-append "https://www.duckdns.org/"
                                                       "update?domains=DOMAIN"
                                                       "&token=~a&ip=")))
                    (http-get (format #f query-template token))))))
         "duckdns-update"
         #:user "nobody"))

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

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

3.6 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. wireguard-tools oder 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 – in nachfolgenden Kernelversionen ist das Modul bereits eingebaut und keine derartige Konfiguration ist nötig.

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

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.

• Die Wireguard Tools benutzen
• NetworkManager benutzen

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

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

# nmcli connection modify wg0 connection.autoconnect no

3.7 Fensterverwalter (Window Manager) anpassen

• StumpWM
• Sitzungen sperren

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

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

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

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

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

xss-lock -- slock &
exec stumpwm

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

3.8 Guix auf einem Linode-Server nutzen

Um Guix auf einem durch 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.

ssh-keygen

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:

cat ~/.ssh/<benutzername>_rsa.pub

Fahren Sie den Linode-Knoten herunter.

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

• Label: "Guix"
• Filesystem: ext4
• Wählen Sie als Größe den übrigen Speicherplatz.

Drücken Sie im Karteireiter „Configurations“ auf „Edit“. Unter „Block Device Assignment“ klicken Sie auf „Add a Device“. Dort müsste /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:

• Label: Guix
• Kernel: GRUB 2 (Das steht ganz unten! Dieser Schritt ist WICHTIG!)
• Block device assignment:
• /dev/sda: Guix
• /dev/sdb: swap
• Root device: /dev/sda
• Schalten Sie alle Dateisystem-/Boot-Helfer ab.

Starten Sie den Knoten jetzt wieder mit der Debian-Konfiguration. Sobald er wieder läuft, verbinden Sie sich mittels SSH zu Ihrem Server über ssh root@<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 Aus Binärdatei installieren in Referenzhandbuch zu GNU Guix weitermachen:

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

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

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

Ersetzen Sie in der obigen Konfiguration aber folgende Felder:

(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

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. ~/.ssh/id_rsa.pub) in die Datei <Ihr-Benutzername>_rsa.pub und Ihre guix-config.scm ins selbe Verzeichnis. Führen Sie dann diese Befehle in einem neuen Terminal aus:

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

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

mkdir /mnt/guix
mount /dev/sdc /mnt/guix

Aufgrund der Art und Weise, wie wir den Bootloader-Abschnitt von 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:

mkdir -p /mnt/guix/boot/grub
cp -r /boot/grub/* /mnt/guix/boot/grub/

Initialisieren Sie nun die Guix-Installation:

guix system init guix-config.scm /mnt/guix

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:

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

Löschen Sie entweder die ganze Datei ~/.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.

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

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.

3.9 Guix auf einem Kimsufi-Server nutzen

Um Guix auf einem von 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 Aus Binärdatei installieren in Referenzhandbuch zu GNU Guix):

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

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

mdadm --stop /dev/md127
mdadm --zero-superblock /dev/sda2 /dev/sdb2

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

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%

Legen Sie das Array an:

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

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

mkfs.ext4  /dev/sda1
mkfs.ext4  /dev/sdb1

Dann die Wurzelpartition:

mkfs.ext4 /dev/md127

Initialisieren Sie die Swap-Partitionen:

mkswap /dev/sda3
swapon /dev/sda3
mkswap /dev/sdb3
swapon /dev/sdb3

Binden Sie das Guix-Laufwerk ein:

mkdir /mnt/guix
mount /dev/md127 /mnt/guix

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

(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 "Server-IP-Adresse/24"))))
		    (routes (list (network-route
				   (destination "default")
				   (gateway "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 "SSH-Name-des-Schlüssels.pub"
                                      "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))))))))

Vergessen Sie nicht, anstelle der Variablen Server-IP-Adresse, Server-Netzwerkzugang, SSH-Name-des-Schlüssels und 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 ‘37.187.79.10’ haben, dann ist sein Gateway ‘37.187.79.254’.

Übertragen Sie Ihre Datei mit Betriebssystemdeklaration os.scm auf den Server mittels des Befehls scp oder sftp.

Bleibt nur noch, Guix mit 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:

guix install bash-static parted util-linux-with-udev coreutils guix

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

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

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

cp /etc/resolv.conf etc/

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

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/

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

chroot /mnt/ /bin/bash

guix system init /root/os.scm /guix

Schlussendlich können Sie in der Web-Oberfläche von ‘netboot’ auf ‘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: ssh guix@Server-IP-Adresse -i Pfad-zu-Ihrem-SSH-Schlüssel

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

3.10 Bind-Mounts anlegen

Um ein Dateisystem per „bind mount“ einzubinden, braucht man zunächst ein paar Definitionen. Fügen Sie diese noch vor dem operating-system-Abschnitt Ihrer Systemdefinition ein. In diesem Beispiel binden wir ein Verzeichnis auf einem Magnetfestplattenlaufwerk an /tmp, um die primäre SSD weniger abzunutzen, ohne dass wir extra eine ganze Partition für /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.

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

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.

;; Dem "quellverzeichnis" kann man einen beliebigen gültigen Variablennamen geben.
(define (%quellverzeichnis) "/hier-der-pfad-zur-magnetfestplatte/tmp")

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

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

                ))

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

Warnung: Nicht aller Datenverkehr des Guix-Daemons wird dadurch über Tor laufen! Nur HTTP und HTTPS durchläuft den Proxy, nicht so ist es bei FTP, dem Git-Protokokl, SSH etc., diese laufen weiterhin durch’s „Clearnet“. Die Konfiguration ist also 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 guix pull aktualisieren, müssen Sie noch immer torsocks benutzen, wenn Sie die Verbindung zu Guix’ Git-Repository über Tor leiten wollen.

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:

(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 "\
https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion")
                      (http-proxy "http://localhost:9250")))))))

Dadurch wird ständig ein Tor-Prozess laufen, der einen HTTP-CONNECT-Tunnel für die Nutzung durch den guix-daemon bereitstellt. Der Daemon kann andere Protokolle als HTTP(S) benutzen, um entfernte Ressourcen abzurufen, und Anfragen über solche Protokolle werden Tor nicht durchlaufen, weil wir hier nur einen HTTP-Tunnel festlegen. Beachten Sie, dass wir für 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 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 guix-configuration. Führen Sie einfach das hier aus, wenn Sie ein Substitut über den Tor-Tunnel laden möchten:

sudo herd set-http-proxy guix-daemon http://localhost:9250
guix build \
  --substitute-urls=https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion …

3.12 NGINX mit Lua konfigurieren

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 index.lua bei HTTP-Anfragen an den Endpunkt http://localhost/hello auszuwerten:

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)

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

3.13 Musik-Server mit Bluetooth-Audio

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 – einem Mobiltelefon, Laptop oder einer Desktop-Workstation – 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 bluetooth-service geliefert wird.

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

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

Starten Sie den bluetooth-Dienst und benutzen Sie dann 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:

$ 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

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 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 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 alsa-configuration für den alsa-service-type. In der Konfiguration deklarieren Sie den pcm-Typ bluealsa aus dem Modul bluealsa des Pakets bluez-alsa. Für diesen Typ definieren Sie dann ein 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:

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

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

4.1 Guix-Container

Der einfachste Einstieg ist, guix shell mit der Befehlszeilenoption --container aufzurufen. Siehe Aufruf von guix shell in 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.

guix shell --container

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 /gnu/store hat seine für gewöhnlich gigantischen Ausmaße verloren und ist nur mehr ein Schatten seiner selbst.

$ 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

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

Sie können zusätzliche Verzeichnisse in der Container-Umgebung zugänglich machen. Verwenden Sie dazu --expose=VERZEICHNIS für eine Verzeichniseinbindung nur mit Lesezugriff innerhalb des Containers oder verwenden Sie --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 /etc aus dem Wirtssystem auf /das/wirtssystem/etc innerhalb eines Containers abbilden, in dem die GNU coreutils installiert sind.

$ guix shell --container --share=/etc=/das/wirtssystem/etc coreutils
$ ls /das/wirtssystem/etc

Gleichermaßen können Sie verhindern, dass das aktuelle Arbeitsverzeichnis eine Zuordnung in den Container bekommt, indem Sie die Befehlszeilenoption --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.

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 nicht zusammenpassen und in R nicht benutzt werden können. In einer Container-Shell gibt es das Problem nicht, denn die Bibliotheken und Programme des äußeren Systems sind schlicht gar nicht da, weil der mount-Namensraum getrennt ist.

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

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

Nehmen wir dieses Manifest und richten uns eine Container-Umgebung ein, in der wir R ausführen. Der Einfachheit halber wollen wir den 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.

$ 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!

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.

4.2 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 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 Dienste in Referenzhandbuch zu GNU Guix) auf dieselbe Weise eingerichtet wie wenn Sie Guix System in einer virtuellen Maschine oder auf echter Hardware booten – auch die Daemons, die durch GNU Shepherd gestartet werden (siehe Shepherd-Dienste in Referenzhandbuch zu GNU Guix) und andere Arten, das System zu erweitern (siehe Dienstkompositionen in 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 – 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.

• Ein Datenbank-Container
• Netzwerkverbindungen im Container

(service postgresql-service-type
         (postgresql-configuration
          (postgresql postgresql-14)))

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

$ 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

$ sudo /gnu/store/…-run-container
system container is running as PID 5983
…

$ 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

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

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

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

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

sudo kill $pid
sudo ip netns del $ns
sudo ip link del $host

5.1 Netzwerkbrücke für QEMU

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 nicht alles machen. In diesem Modus bekommt die Gast-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, keine ICMP-basierten Netzwerkprogramme wie 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.

• Eine Netzwerkbrücken-Schnittstelle aufbauen
• Das QEMU-Bridge-Helper-Skript konfigurieren
• QEMU mit den richtigen Befehlszeilenoptionen aufrufen
• Durch Docker verursachte Netzwerkprobleme

# nmcli con add type bridge con-name br0 ifname br0

# nmcli con add type bridge-slave ifname enp2s0 master br0

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

(extra-special-file "/etc/qemu/host.conf" "allow br0\n")

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

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

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

5.2 Netzwerk-Routing anschalten in libvirt

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 Netzwerkbrücke für QEMU). Ihnen bleibt die zweitbeste Option, eine virtuelle Netzwerkbrücke 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 virt-manager). Das ist ähnlich zu dem voreingestellten Betriebsmodus von QEMU/libvirt, außer dass wir, statt NAT (Network Address Translation) zum Einsatz zu bringen, mit statischen Routen die IP-Adresse der VM (virtuellen Maschine) ins 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.

• Eine virtuelle Netzwerkbrücke anlegen
• Statische Routen für Ihre virtuelle Netzwerkbrücke einrichten

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

virsh net-define /tmp/virbr0.xml
virsh net-autostart virbr0
virsh net-start virbr0

6.1 Guix-Profile in der Praxis

Guix gibt uns eine sehr nützliche Funktionalität, die Neuankömmlingen sehr fremd sein dürfte: 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 traditioneller Paketverwaltung, doch sind sie sehr praktisch, sobald man im Umgang mit ihnen den Dreh ’raushat.

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

Oftmals dürfte es für Sie einfacher sein, mit 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!

Wenn Ihnen Pythons ‘virtualenv’ vertraut ist, können Sie sich ein Profil als eine Art universelles ‘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:

• Klare semantische Trennung der verschiedenen Pakete, die ein Nutzer für verschiedene Kontexte braucht.
• Mehrere Profile können in der Umgebung verfügbar gemacht werden, entweder beim Anmelden oder in einer eigenen Shell.
• Profile können bei Bedarf geladen werden. Zum Beispiel kann der Nutzer mehrere Unter-Shells benutzen, von denen jede ein anderes Profil ausführt.
• 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.
• Deduplizierung: Profile teilen sich Abhängigkeiten, wenn sie genau gleich sind. Dadurch sind mehrere Profile speichereffizient.
• 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 jederzeit und überall einrichten kann und man dafür nur die Commit-Informationen braucht. Siehe den Abschnitt über Reproduzierbare Profile.
• 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.

Konkret wären diese hier typische Profile:

• Die Abhängigkeiten des Projekts, an dem Sie arbeiten.
• Die Bibliotheken Ihrer Lieblingsprogrammiersprache.
• Programme nur für Laptops (wie ‘powertop’), für die Sie auf einem „Desktop“-Rechner keine Verwendung haben.
• TeXlive (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).
• Spiele.

Tauchen wir ein in deren Einrichtung!

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

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

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

guix package --list-profiles

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

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

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

guix package --search-paths=prefix --profile=$my_profile"

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

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

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

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

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

guix install paket-foo
guix upgrade paket-bar

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

7.1 Einstieg

Wie lässt sich also ein Repository „guixifizieren“? Unser erster Schritt ist, wie wir sehen konnten, eine Datei guix.scm im obersten Verzeichnis des fraglichen Repositorys unterzubringen. Nehmen wir 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 – einer C-Compiler-Toolchain, C-Bibliotheken, Autoconf und seinen Freunden, LaTeX und so weiter. Daraus ergibt sich eine guix.scm, die ziemlich wie andere Paketdefinitionen auch aussieht (siehe Pakete definieren in Referenzhandbuch zu GNU Guix), nur fehlt das define-public am Anfang:

;; 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+))

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

guix shell

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

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

guix shell --container --link-profile

… oder kurz:

guix shell -CP

So erhält man eine Shell in einem isolierten Container und alle Abhängigkeiten finden sich in $HOME/.guix-profile, was die Nutzung von Zwischenspeichern wie config.cache (siehe Cache Files in Autoconf) erleichtert und wodurch absolute Dateinamen, die in erzeugten Dateien wie Makefiles 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.

7.2 Stufe 1: Erstellen mit Guix

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

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

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

Dies sind unsere Änderungen verglichen mit dem vorherigen Abschnitt:

1. Wir haben (guix git-download) zu unseren importierten Modulen hinzugefügt, damit wir dessen Prozedur git-predicate benutzen können.
2. Wir haben 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.
3. Wir setzen source auf local-file – einer rekursiven Kopie des aktuellen Verzeichnisses ("."), eingeschränkt auf solche Dateien, die unter Versionskontrolle gestellt sind (mit #:select?).

Von da an erfüllt 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 – Sie können sich sicher sein, das Ergebnis der Erstellung beruht nicht auf Dateien in Ihrem Quellbaum oder anderen Dingen in Ihrem System – und auch, dass Sie viele Möglichkeiten testen können. Als Erstes wäre da eine einfache native Erstellung:

guix build -f guix.scm

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

guix build -f guix.scm -s aarch64-linux -s riscv64-linux

… oder Sie cross-kompilieren:

guix build -f guix.scm --target=x86_64-w64-mingw32

Möglich sind auch Paketumwandlungsoptionen, womit Sie Varianten Ihres Pakets testen können (siehe Paketumwandlungsoptionen in Referenzhandbuch zu GNU Guix):

# 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

Praktisch!

7.3 Stufe 2: Das Repository als Kanal

Jetzt haben wir ein Git-Repository mit (unter anderem) einer Paketdefinition (siehe Stufe 1: Erstellen mit Guix). Wäre es nicht besser, wenn wir daraus einen Kanal machen würden (siehe Kanäle in Referenzhandbuch zu GNU Guix)? Schließlich sind Kanäle entwickelt worden, um Nutzer mit Paketdefinitionen zu versorgen, und genau das tun wir mit guix.scm.

Tatsächlich sollten wir es zu einem Kanal machen, aber aufgepasst: Die .scm-Datei(en) unseres Kanals gehören in ein gesondertes Verzeichnis, damit guix pull nicht versucht, die falschen .scm-Dateien zu laden, wenn jemand damit den Kanal herunterlädt – und in Guile gibt es viele .scm-Dateien! Wir fangen mit der Trennung an, behalten aber auf oberster Ebene eine symbolische Verknüpfung guix.scm zur Nutzung mit guix shell:

mkdir -p .guix/modules
mv guix.scm .guix/modules/guile-package.scm
ln -s .guix/modules/guile-package.scm guix.scm

Damit es als Kanal verwendet werden kann, erweitern wir unsere guix.scm-Datei zu einem Paketmodul (siehe Paketmodule in Referenzhandbuch zu GNU Guix). Das geschieht, indem wir die use-modules-Form am Anfang durch eine define-module-Form ersetzen. Auch müssen wir dann eine Paketvariable exportieren, mit define-public, und dennoch am Ende der Datei den Paketwert zurückliefern, damit guix shell und guix build -f guix.scm weiterhin funktionieren. Das Endergebnis sieht so aus (ohne zu wiederholen, was wir nicht verändern):

(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

Zuletzt brauchen wir noch eine .guix-channel-Datei, um Guix zu erklären, woher es die Paketmodule in unserem Repository bekommt:

;; Mit dieser Datei kann man dieses Repo als Guix-Kanal eintragen.

(channel
  (version 0)
  (directory ".guix/modules"))  ;Paketmodule finden sich unter .guix/modules/

Zusammengefasst liegen diese Dateien jetzt im Repository:

.
├── .guix-channel
├── guix.scm → .guix/modules/guile-package.scm
└── .guix
    └── modules
       └── guile-package.scm

Und das war alles: Wir haben einen Kanal erschaffen! (Noch besser wäre es, auch 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 ihn zu ~/.config/guix/channels.scm hinzufügen, etwa so:

(append (list (channel
                (name 'guile)
                (url "https://git.savannah.gnu.org/git/guile.git")
                (branch "main")))
        %default-channels)

Nach einem Aufruf von guix pull sind die neuen Pakete zu sehen:

$ 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.savannah.gnu.org/git/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

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 guix pack anfertigen (siehe Aufruf von guix pack in Referenzhandbuch zu GNU Guix):

# 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

7.4 Bonus: Paketvarianten

Jetzt, wo wir es zu einem richtigen Kanal gebracht haben (siehe Stufe 2: 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 Paketvarianten (siehe Paketvarianten definieren in Referenzhandbuch zu GNU Guix) in unserer Datei guile-package.scm festlegen, und zwar Varianten, die wir Entwickler von Guile gerne testen würden – wofür wir oben noch Paketumwandlungsoptionen gebraucht haben. Wir können Sie auf diese Weise eintragen:

;; 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

Sobald wir den Kanal mit 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:

guix build -L $PWD/.guix/modules guile-without-threads

7.5 Stufe 3: Kontinuierliche Integration einrichten

Mit dem oben definierten Kanal (siehe Stufe 2: Das Repository als Kanal) können wir erst recht etwas anstellen, sobald wir 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:

guix build -L $PWD/.guix/modules guile@3.0.99-git

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 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 Kontinuierliche Integration in Referenzhandbuch zu GNU Guix). Kehren wir zu unserem Beispiel zurück, statten wir Cuirass mit so einer Spezifikationsdatei aus:

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

Es gibt zwei wichtige Unterschiede zu dem, was Sie mit anderen CI-Werkzeugen tun würden:

• Cuirass weiß über zwei Kanäle Bescheid, guile und guix. Tatsächlich zählen viele Pakete vom guix-Kanal zu den Abhängigkeiten des von uns entwickelten guile-Pakets – GCC, GNU libc, libffi und weitere. Es kann passieren, dass sich die Pakete vom guix-Kanal ändern und dadurch die Erstellung unseres guile-Pakets schiefgeht; so etwas wollen wir als die Entwickler von Guile so früh erfahren, wie es nur geht.
• Die Erstellungsergebnisse werden nicht entsorgt, sondern sie können als Substitute, d.h. vorerstellten Binärdateien, allen Nutzern unseres guile-Kanals transparent zur Verfügung gestellt werden! (Siehe Substitute in Referenzhandbuch zu GNU Guix für Hintergrundwissen zu Substituten.)

Aus Entwicklersicht sieht das Ergebnis am Ende so aus wie die auf Guiles Status-Seite aufgelisteten Auswertungen: Jede Auswertung besteht aus einer Kombination von Commits der guix- und guile-Kanäle, wovon es mehrere Aufträge (Jobs) gibt – je einen Job pro Paket, das in guile-package.scm definiert ist, mal der Anzahl der Zielarchitekturen.

Substitute gibt es kostenlos dazu! Zum Beispiel kann jeder, weil unser guile-Jobset auf ci.guix.gnu.org erstellt wird und dort guix publish (siehe Aufruf von guix publish in Referenzhandbuch zu GNU Guix) zusätzlich zu Cuirass läuft, automatisch die Substitute für guile-Erstellungen von ci.guix.gnu.org beziehen; es ist dazu kein Mehraufwand nötig.

7.6 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 Stufe 3: 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 Manifest mit den Angaben schreiben (siehe Manifeste verfassen in 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:

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

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:

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

Wir haben im Teil (build …) der Spezifikation jetzt '(manifest ".guix/manifest.scm") verwendet, damit unser Manifest genommen wird, und das war schon alles!

7.7 Zusammenfassung

In diesem Kapitel haben wir die Vorgehensweise auf Guile angewandt und das Ergebnis lässt sich hier bestaunen:

• .guix-channel,
• .guix/modules/guile-package.scm auch symbolisch verknüpft als guix.scm auf der oberstem Verzeichnisebene,
• .guix/manifest.scm.

Heutzutage werden Repositorys gemeinhin mit Dotfiles für vielerlei Werkzeuge angereichert: .envrc, .gitlab-ci.yml, .github/workflows, Dockerfile, .buildpacks, Aptfile, requirements.txt und Weiteres. Es wirkt so, als würden wir Sie zu 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 ersetzen.

Mit wenigen Dateien bekommen wir Unterstützung für:

• Entwicklungsumgebungen (guix shell),
• Test-Erstellungen in naturbelassener Umgebung, auch für Paketvarianten und cross-kompiliert (guix build),
• kontinuierliche Integration (ob mit Cuirass oder mit einem anderen Werkzeug),
• kontinuierliche Auslieferung an Nutzer (über den Kanal und mit vorerstellten Binärdateien),
• abgeleitete Erstellungsartefakte wie Docker-Abbildern oder Deb-/RPM-Pakete (guix pack).

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!

8.1 Guix-Umgebung mit direnv

Guix stellt ein ‘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 ~/.direnvrc-Datei, die in einer Datei ~/src/guix/.envrc in Guix’ Git-Repository benutzt werden kann, um eine zur Beschreibung im Erstellung aus dem Git in Referenzhandbuch zu GNU Guix ähnliche Erstellungsumgebung herzustellen.

Erstellen Sie eine ~/.direnvrc mit einem Bash-Code darin:

# 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
"
}

Jedes Projekt, das eine .envrc mit einer Zeichenkette use guix enthält, wird vordefinierte Umgebungsvariable und Prozeduren verwenden.

Führen Sie direnv allow aus, um die Umgebung bei der ersten Nutzung einzurichten.

9.1 Den Zentralrechner konfigurieren

Unsere Empfehlung ist, eine Maschine zum Zentralrechner zu ernennen (als „Head Node“) und auf dieser guix-daemon auszuführen, wobei /gnu/store über NFS mit den Arbeitsrechnern („Compute Nodes“) geteilt wird.

Zur Erinnerung: guix-daemon ist das Hintergrundprogramm, mit dem für Clients Erstellungsprozesse angelegt und Dateien heruntergeladen werden können (siehe Aufruf des guix-daemon in Referenzhandbuch zu GNU Guix), und das allgemein auf /gnu/store zugreift. Dort liegen dann alle Paket-Binärdateien, die irgendeiner der Nutzer erstellen lassen hat (siehe Der Store in Referenzhandbuch zu GNU Guix). Mit „Clients“ meinen wir die Guix-Befehle, die Benutzer aufgerufen haben, wie etwa guix install. Auf einem Cluster können diese Befehle auf den Arbeitsrechnern aufgerufen werden und dennoch werden wir sie mit der zentralen 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 Aus Binärdatei installieren in 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 guix-daemon 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 guix-daemon, /etc/systemd/system/guix-daemon.service, und fügen ein Argument --listen zur ExecStart-Zeile hinzu. Diese sieht jetzt ungefähr so aus:

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

Die Änderungen wirken sich erst aus, wenn der Dienst neu gestartet wurde:

systemctl daemon-reload
systemctl restart guix-daemon

Anmerkung: Mit --listen=0.0.0.0 ist gemeint, dass guix-daemon alle auf Port 44146 eingehenden TCP-Verbindungen annimmt (siehe Aufruf des guix-daemon in 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 – unter keinen Umständen darf er für das gesamte Internet zugänglich sein!

Als Nächstes müssen wir unsere NFS-Freigaben in /etc/exports definieren. Dazu fügen wir etwas wie hier hinzu:

/gnu/store    *(ro)
/var/guix     *(rw, async)
/var/log/guix *(ro)

Es genügt, das Verzeichnis /gnu/store nur lesbar zu exportieren, weil es nur durch guix-daemon auf dem Hauptknoten jemals verändert wird. In /var/guix befinden sich Benutzerprofile, die man mit guix package anlegen kann. Damit Benutzer also Pakete mit 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, ~/.guix-profile. Zum Beispiel bekommt jemand, die guix package -p ~/dev/python-dev -i python ausführt, Python in einem Profil installiert, das über die symbolische Verknüpfung ~/dev/python-dev erreichbar ist. Damit dieses Profil nicht irgendwann vom Müllsammler weggeräumt wird – d.h. damit Python nicht aus /gnu/store entfernt wird, solange dieses Profil existiert –, müssen die Persönlichen Verzeichnisse in /home auch auf dem Zentralrechner eingebunden sein. Wir wollen, dass guix-daemon über solche Nicht-Standard-Profile weiß, dass die darin referenzierte Software noch gebraucht wird.

Es kann allerdings sinnvoll sein, Software die nicht gebraucht wird, regelmäßig aus /gnu/store zu löschen. Verwenden Sie dazu guix gc (siehe Aufruf von guix gc in Referenzhandbuch zu GNU Guix). Dazu können Sie so einen crontab-Eintrag auf dem Zentralknoten vornehmen:

root@master# crontab -e

… und schreiben Sie etwa:

# 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

So viel zum Zentralrechner! Jetzt geht’s an die Arbeitsknoten.

9.2 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 /etc/fstab hinzugefügt werden:

zentralrechner:/gnu/store    /gnu/store    nfs  defaults,_netdev,vers=3 0 0
zentralrechner:/var/guix     /var/guix     nfs  defaults,_netdev,vers=3 0 0
zentralrechner:/var/log/guix /var/log/guix nfs  defaults,_netdev,vers=3 0 0

… wobei Sie anstelle von 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 guix-Befehl vorinstallieren, den sie verwenden können, wenn sie sich zum ersten Mal mit dem Cluster verbinden (damit werden sie guix pull aufrufen, wodurch ihnen ihr „eigener“ guix-Befehl zur Verfügung gestellt wird). Analog zum Installationsskript der Guix-Binärdatei auf dem Zentralrechner werden wir unser guix ebenfalls in /usr/local/bin unterbringen:

mkdir -p /usr/local/bin
ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix \
      /usr/local/bin/guix

Wir müssen dafür sorgen, dass sich guix mit dem Daemon auf dem Zentralrechner verbindet, indem wir diese Zeilen zu /etc/profile hinzufügen:

GUIX_DAEMON_SOCKET="guix://zentralrechner"
export GUIX_DAEMON_SOCKET

Damit unseren Benutzern keine Warnungen angezeigt werden und damit guix die richtigen Locale-Spracheinstellungen benutzen kann, müssen wir angeben, wo die von Guix bereitgestellten Locale-Daten zu finden sind (siehe Anwendungen einrichten in Referenzhandbuch zu GNU Guix):

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

Um die Nutzung zu vereinfachen, legt guix package selbstständig die Datei ~/.guix-profile/etc/profile an, worin alle Umgebungsvariablen definiert sind, um die Pakete zu benutzen – PATH, C_INCLUDE_PATH, PYTHONPATH, etc. Das Gleiche gilt für guix pull, was eine Datei innerhalb von ~/.config/guix/current anlegt. Diese Definitionen sollten Sie daher in /etc/profile mit source laden lassen:

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

Zu guter Letzt können Guix-Befehle durch Bash und zsh ergänzt werden. In /etc/bashrc fügen Sie dazu diese Zeile hinzu:

. /var/guix/profiles/per-user/root/current-guix/etc/bash_completion.d/guix

Erledigt!

Überprüfen Sie, dass alles klappt, indem Sie sich auf einem der Arbeitsrechner anmelden und dies ausführen:

guix install hello

Daraufhin sollte der Daemon auf dem Zentralrechner für Sie die vorerstellten Binärdateien herunterladen und nach /gnu/store entpacken, wonach guix install dann ~/.guix-profile anlegt und darin wird der Befehl ~/.guix-profile/bin/hello zu finden sein.

9.3 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 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 ci.guix.gnu.org außerdem ein inhaltsadressierbarer Spiegelserver für die Quelldateien all dieser Pakete. Daher ist es ausreichend, wenn Sie nur ci.guix.gnu.org auf die Positivliste setzen.

Software-Pakete, die in einem getrennten Repository angeboten werden wie beispielsweise den HPC-Kanälen, können natürlich nicht von 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 /gnu/store auf dem Cluster hochladen. Das geht so:

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

Der obige Befehl lädt starpu-1.2.3.tar.gz herunter und lässt es über SSH durch die 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 --sources für guix build (siehe Aufruf von guix build in Referenzhandbuch zu GNU Guix); folgendes Beispiel zeigt, wie Sie sämtlichen Quellcode, von dem das openmpi-Paket abhängt, herunterladen:

$ 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
…

(Wenn Sie es genauer wissen wollen, haben wir hier mehr als 320 MiB komprimierten Quellcodes.)

Daraus lässt sich ein gesammeltes Archiv für all den Quellcode basteln (siehe Aufruf von guix archive in Referenzhandbuch zu GNU Guix):

$ guix archive --export \
    `guix build --sources=transitive openmpi` \
    > openmpi-quellcode.nar

… und dieses Archiv können wir dann mittels Wechseldatenträgern auf den Cluster transportieren und dort entpacken:

$ guix archive --import < openmpi-quellcode.nar

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.

9.4 Speicherplatz

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 – 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 nicht unbedingt viel, wenn mehrere Versionen oder Varianten eines bestimmten Pakets in /gnu/store liegen, weil 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 guix gc aufzurufen, was nicht benutzte Software aus /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 guix gc 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:

guix package --delete-generations=2m

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 /gnu/store bleiben müssen:

guix pull
guix upgrade

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.

9.5 Sicherheitsüberlegungen

Auf einem Hochleistungs-Cluster wird mit Guix normalerweise wissenschaftliche Software verwaltet. Über sicherheitskritische Software wie den Betriebssystem-Kernel und Systemdienste wie sshd und „Batch“-Auftragsplaner haben weiterhin die Systemadministratoren die Kontrolle.

Das Guix-Projekt kümmert sich zügig um Sicherheitsaktualisierungen (siehe Sicherheitsaktualisierungen in Referenzhandbuch zu GNU Guix). Um die Sicherheitsaktualisierungen zu bekommen, müssen Nutzer 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 „Stack Clash“ noch nicht hat, prüfen, ob sie überhaupt in einem Benutzerprofil verwendet wird:

guix gc --referrers /gnu/store/…-glibc-2.25

Dadurch werden Profile gemeldet, die diese bestimmte glibc-Variante verwenden.