y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

openSUSE arbeitet an LUKS mit TPM und FIDO2

28. November 2021 um 12:43
Von: Gerrit

Wie Benjamin Brunner, Entwickler bei SUSE, vor einigen Tagen über die Mailingliste kommunizierte, arbeitet man momentan an der Implementierung der neuen systemd-Funktionen, um LUKS2-Volumes mittels TPM oder FIDO2 zu entsperren.

Dabei handelt es sich um eine Funktion, die Lennart Poettering Anfang diesen Jahres ankündigte und über die ich hier bereits berichtete hatte. Mittels systemd-cryptenroll lassen sich unter anderem TPM oder FIDO2 als Entsperrmechanismen für LUKS2 hinterlegen. Diese neuen Verfahren stehen in einem direkten Kontext zu weiteren Bestrebungen, um den Sicherheitslevel der verbreiteten Linux-Verschlüsselung auf ein zeitgemäßes Niveau zu bringen.

Die Zielrichtung der Bestrebungen bei SUSE/openSUSE ist noch nicht klar. Also ob und inwieweit das in die Installationsroutine oder YaST implementiert wird. Zudem sind noch einige Vorarbeiten notwendig. Genaueres können interessierte Anwender im Wiki nachlesen.

Die Funktion systemd-cryptentroll benötigt LUKS2-Volumes. Das ist für SUSE/openSUSE ein Problem, weil die Installationsroutine bis zuletzt LUKS1-Volumes angelegt hat. Daran hat man allerdings anderweitig bereits gearbeitet und ich denke, hier dürfte sich zukünftig was ändern. Bestehende Installationen lassen sich zudem relativ leicht mittels eines Live-Mediums von LUKS1 auf LUKS2 migrieren. Allerdings benötigt systemd-cryptenroll auch eine unverschlüsselte Boot-Partition und das ist standardmäßig bei SUSE/openSUSE schon länger nicht mehr der Fall.

Hinzu kommen noch ein paar Probleme, weil z. B. die FIDO2-Abfrage upstream noch nicht in Plymouth integriert ist und somit nicht optisch schön beim Startvorgang erscheint, sondern „blind“ durch den Anwender erfolgen muss.

Die beiden neuen Authentifizierungsmethoden sind wichtige Ergänzungen für die Legacy-Verfahren mittels Passwort. Teilweise lösen sie auch zusammen gestückelte Skripte bei z. B. Debian und Arch Linux ab, die bereits Sicherheitssticks wie den YubiKey unterstützten. FIDO2 adressiert das Problem der unsicheren Passwörter und TPM2 bietet unter anderem Schutz gegen Angriffe mittels Brute Force und vor allem das beliebte Kopieren der Daten, um sie danach in aller Ruhe zu untersuchen.

Es ist also noch ein wenig Wegstrecke zu meisten, bis diese Funktionen standardmäßig umgesetzt werden können. Wer aber schon ein System mit LUKS2 und unverschlüsselter Boot-Partition hat oder eine Testinstallation betreibt, kann sich die neuen Funktionen mal ansehen. Meiner Meinung nach geht das absolut in die richtige Richtung.

Der Artikel openSUSE arbeitet an LUKS mit TPM und FIDO2 erschien zuerst auf [Mer]Curius

MX Linux 21 AHS mit Advanced Hardware Support

24. November 2021 um 09:38

Die Distribution MX Linux 21 basiert auf Debian 11 („Bullseye“), kommt aber ohne Systemd aus. Das letzte große stabile Release erschien bereits im Oktober. Jetzt schieben die Entwickler eine Variante nach, die vor allem den Grafik-Stack und den Kernel erneuert.

MX-21 AHS setzt auf neuere Softwarepakete, die allerdings nicht so gut getestet und stabil sind, wie das im Oktober veröffentlichte MX-21. Die AHS-Variante nutzt den Linux-Kernel 5.14, sowie aktuelle Versionen von Mesa, X.org und den Vulkan-Treibern. Dadurch läuft das System auf neuerer Hardware deutlich besser. Die Entwickler empfehlen es vor allem auf Systemen mit AMD Ryzen-Prozessoren, Grafikkarten der Serie AMD Radeon RX, sowie Intel-Prozessoren der 9. bis 11. Generation.

Einige Anwendungen haben die Entwickler zudem neu übersetzt, so dass sie von den Neuerungen im Linux-Kernel profitieren. Die AHS-Fassung soll regelmäßig Updates für den Grafik-Stack erhalten. Wer ihn nicht zwingend in einer aktuellen Fassung benötigt, dem raten die Entwickler, weiterhin das normale MX-21 zu verwenden. MX-21 AHS gibt es zudem nur in einer 64-Bit-Fassung mit Xfce-Desktop.

Sämtliche Informationen zur AHS-Variante hält die offizielle Ankündigung bereit.

Der Beitrag MX Linux 21 AHS mit Advanced Hardware Support erschien zuerst auf Linux-Magazin.

Devuan 4 Chimaera baut auf Debian 11 Bullseye

15. Oktober 2021 um 11:15

Das Devuan-Projekt hat sich das Ziel gesetzt, eine Debian-basierte Distribution herauszubringen, die auf Systemd verzichtet. Devuan 4 Chimaera hat den Unterbau auf Debian 11 Bullseye aktualisiert.

Schon bei der Installation macht sich Debian 11 bemerkbar. Der Installer für Devuan 4 Chimaera basiere auf dem Debian 11 Installer und bringe damit die dort möglichen Prozeduren für Barrierefreiheit zum Starten des Installers mit. Die Optionen Software-Spracheingabe, Hardware-Sprachsynthesizer oder eine aktualisierbare Braillezeile seien enthalten.

Neu in Devuan 4 Chimaera sei die Möglichkeit, eine Desktop-Umgebung ohne Pulseaudio zu installieren. Dies ermöglicht die Sprachsynthese sowohl in einer grafischen als auch in einer Konsolensitzung zur gleichen Zeit.

Devuan unterstütze praktisch alle Desktops und Display-Manager die Debian anbietet. Zu den neu verfügbaren Display-Managern in Devuan 4 Chimaera zähen die Entwickler gdm3 und sddm. Der Lxde-Desktop sei ebenfalls neu hinzugekommen. Devuan 4 ist für die Architekturen i386, AMD64, Armel, Armhf, Arm64 und PPC64el verfügbar. Die Release Notes verlinken die Downloads und bieten weitere Informationen.

Der Beitrag Devuan 4 Chimaera baut auf Debian 11 Bullseye erschien zuerst auf Linux-Magazin.

InitWare als Systemd-Fork auch für macOS

25. August 2021 um 11:51

InitWare ist ein Systemd-Fork für die BSD-Familie. Jetzt hat der Entwickler den Init-Dienst nach NetBSD, FreeBSD, DragonFly und OpenBSD auch auf macOS portiert.

Quelle

InitWare als Systemd-Fork auf OpenBSD

04. August 2021 um 07:29

Lennart Poettering hat Systemd ausschließlich für Linux konzipiert. Seit einem halben Jahr arbeiten BSD-Entwickler an der Umsetzung für die eigene Plattform

Quelle

Sicherheitslücken im Kernel und bei Systemd geschlossen

21. Juli 2021 um 14:52

Zwei bereits gepatchte Sicherheitslücken im Kernel und bei Systemd wurden jetzt vom Entdecker Qualys veröffentlicht

Quelle

Docker-Container automatisch starten

15. Juli 2021 um 18:01

Beim Arbeiten mit Docker besteht oft der Wunsch, einen Container automatisch bei jedem Rechnerstart auszuführen, z.B. um einen Netzwerkdienst anzubieten. In diesem Text stelle ich Ihnen drei Wege vor, wie Sie diesen Wunsch realisieren können. Die ersten beiden Varianten setzen voraus, dass es einen systemweiten Docker-Dienst gibt (dockerd), dass Sie also mit einer »normalen« Docker-Installation arbeiten (nicht rootless oder mit mit Podman).

Variante 1: docker run --restart always

Wenn Sie beim Start eines Docker-Containers mit docker run die Option --restart always übergeben, dann wird dieser Container in Zukunft automatisch gestartet:

docker run -p 8080:80 --name apache  -v "${PWD}":/usr/local/apache2/htdocs -d --restart always httpd

Für die Option --restart gibt es vier mögliche Einstellungen:

  • --restart no gilt standardmäßig. Wenn der Container endet, egal aus welchem Grund, wird er nicht neu gestartet.
  • --restart always bewirkt, dass der Container automatisch neu gestartet wird, sobald er endet. Diese Neustartregel gilt auch für einen Reboot des Rechners! Dabei wird im Rahmen des Init-Prozesses der Docker-Dienst gestartet; dieser startet wiederum alle Container, die zuletzt mit der Option --restart always liefen. Aber Vorsicht: --restart always gilt auch für ein Programmende aufgrund eines Fehlers. Wenn der Container einen Fehler enthält, kann es passieren, dass der Container immer wieder gestartet wird. Die einzige Ausnahme ist ein manueller Stopp (docker stop): In diesem Fall wird der Container nicht unmittelbar neu gestartet. Wenn Sie aber Ihren Rechner herunterfahren, dann wird der Container beim nächsten Docker-Neustart wiederum gestartet.

  • --restart unless-stopped funktioniert ganz ähnlich wie --restart always. Der Unterschied besteht darin, dass ein mit docker stop beendeter Container beim nächsten Docker-Neustart nicht mehr automatisch gestartet wird.

  • --restart on-failure führt zu einem automatischen Neustart nach einem Fehler im Container, aber zu keinem Autostart bei einem Neustart des Docker-Systems.

Das für einen Container eingestellte Restart-Verhalten können Sie mit docker inspect ermitteln:

docker inspect <containername>
  ...
  "RestartPolicy": {
      "Name": "always",
      "MaximumRetryCount": 0
  },
  ...

Mit docker update können Sie das Update-Verhalten eines Containers verändern, während er läuft:

docker update --restart on-failure <containername>

Variante 2: docker-compose-Datei mit der restart-Option

Einen automatischen Neustart können Sie auch in der Datei docker-compose.yml festschreiben, und zwar mit dem Schlüsselwort restart:

services:
   db:
     image: mariadb:latest
     restart: always

Die vier zulässigen Einstellungen lauten no (gilt per Default), always, unless-stopped und on-failure. Die Bedeutung der Schlüsselwörter ist wie bei der vorhin erläuterten Option --restart von docker run. Die Einstellung
restart: always gilt solange, bis die durch die Datei docker-compose.yml beschriebenen Dienste explizit durch compose down wieder beendet und gelöscht werden.

Achten Sie darauf, dass Sie das Schlüsselwort restart in der richtigen Ebene angeben, also direkt bei den Einstellungen des jeweiligen Containers (im vorigen Beispiel db)! Zuletzt habe ich mich wochenlang gewundert, warum bei der folgenden Datei docker-compose.yml das Restart-Verhalten nicht funktionierte:

# Vorsicht, die restart-Einstellung ist hier fehlerhaft!
services:
   db:
     image: mariadb:latest
     volumes:
       - vol-db:/var/lib/mysql
     environment:
       MYSQL_USER: wpuser
       MYSQL_PASSWORD: geheim
       restart: always

Die Fehlerursache sollte klar sein: Die Option restart ist zu weit eingerückt und bezieht sich nicht auf den Container db, sondern auf dessen environment~~Einstellungen. Dort wird restart einfach ignoriert. Die falsch platzierte Option führt aber zu keiner Warnung oder gar Fehlermeldung.

Variante 3: systemd

Anstatt den Start von Containern durch Docker zu steuern, besteht auch die Möglichkeit, dies durch Funktionen des Betriebssystems zu erledigen. Diese Vorgehensweise ist relativ umständlich und wird in der Praxis daher nur recht selten gewählt. Sie hat aber den Vorteil, dass ein Container wie ein Dienst des Betriebssystem behandelt werden und mit den gleichen Kommandos gesteuert kann.

Ich gehe im Folgenden davon aus, dass Sie eine Linux-Distribution mit systemd verwenden. Sobald die Konfiguration einmal funktioniert, können auf den betreffende Container Kommandos wie systemctl restart oder systemctl enable --now angewendet werden.

Der Ausgangspunkt des folgenden Beispiels ist ein MySQL-Container, der zuerst testweise eingerichtet wurde und der nun dauerhaft gestartet werden soll. Das Volume mit den Datenbanken befindet sich in /home/kofler/docker-mysql-volume. Beim erstmaligen Einrichten des Containers wurde das MySQL-Root-Passwort festgelegt. Es ist in einer Datenbank im Volume-Verzeichnis gespeichert und muss deswegen nicht mehr mit -e MYSQL_ROOT_PASSWORD=... übergeben werden.

Eine eigene Servicedatei

Damit sich systemd selbstständig um den Start kümmert, muss im Verzeichnis /etc/systemd/system eine *.service-Datei eingerichtet werden. Für dieses Beispiel sieht die Datei so aus:

# Datei /etc/systemd/system/docker-mysql.service
[Unit]
Description=starts MySQL server as Docker container
After=docker.service
Requires=docker.service

[Service]
RemainAfterExit=true
ExecStartPre=-/usr/bin/docker stop mysql-db-buch
ExecStartPre=-/usr/bin/docker rm mysql-db-buch
ExecStartPre=-/usr/bin/docker pull mysql
ExecStart=/usr/bin/docker run -d --restart unless-stopped \
  -v /home/kofler/docker-mysql-volume:/var/lib/mysql \
  -p 13305:3306 --name mysql-db-buch mysql
ExecStop=/usr/bin/docker stop mysql-db-buch

[Install]
WantedBy=multi-user.target

Der Unit-Abschnitt beschreibt den Dienst. Die Schlüsselwörter Requires und After stellen sicher, dass der Dienst nicht vor Docker gestartet wird.

Der Service-Abschnitt legt fest, welche Aktionen zum Start bzw. zum Stopp des Diensts erforderlich sind. Die drei ExecStartPre-Anweisungen stellen sicher, dass der Container mit dem Namen mysql-db-buch gestoppt und gelöscht wird und dass die neueste Version des MySQL-Images heruntergeladen wird. Das Minuszeichen vor den stop– und rm-Kommandos bedeutet, dass ein Fehler beim Ausführen dieser Kommandos einfach ignoriert wird. (Wenn das Image bereits zuvor gestoppt und/oder gelöscht wurde, dann ist das kein Grund zur Sorge.)

Die über mehrere Zeilen verteilte ExecStart-Anweisung startet schließlich den Container, wobei das Volume-Verzeichnis /home/kofler/docker-mysql-volume und der Host-Port 13306 verwendet werden.

ExecStop gibt an, was zu tun ist, um den Dienst zu stoppen.

RemainAfterExit=true bedeutet, dass sich systemd den gerade aktivierten Status merkt. Ohne diese Option würde systemd nach der erfolgreichen Ausführung von docker run glauben, der Dienst sei bereits wieder beendet. Tatsächlich wird der Container aber im Hintergrund weiter ausgeführt.

WantedBy im Install-Abschnitt legt fest, dass der Dienst Teil des Multi-User-Targets sein soll. (Dieses Target beschreibt den normalen Betriebszustand eines Linux-Servers.)

Selbstverständlich können Sie in der Service-Datei anstelle von docker auch docker compose aufrufen. Das ist zweckmäßig, wenn der gewünschte Dienst nicht aus nur einem Container besteht, sondern aus einer ganze Gruppe von Containern. Denken Sie daran, dass Sie beim Aufruf von docker compose den vollständigen Ort der Datei docker-compose.yml mit der Option -f explizit angeben müssen.

Den Service starten und beenden

Damit systemd die neue Servicedatei berücksichtigt, müssen Sie einmalig das folgende Kommando ausführen:

systemctl daemon-reload

Sollten Sie in der Servicedatei einen Fehler eingebaut haben und ihn später korrigieren, vergessen Sie nicht, das obige Kommando neuerlich auszuführen!

Mit den folgenden Kommandos testen Sie, ob der manuelle Start und Stopp des Docker-Containers funktioniert:

systemctl start docker-mysql

systemctl status docker-mysql
  docker-mysql.service - starts MySQL server as Docker container
     Loaded: loaded (/etc/systemd/system/docker-mysql.service; 
                     disabled; vendor preset: enabled)
     Active: active (exited) since 19:28:20 CEST; 3min 41s ago
     ...

systemctl stop docker-mysql

Sofern alles klappt, müssen Sie den automatischen Start des Dienstes nun noch dauerhaft aktivieren:

systemctl enable --now docker-mysql

Sollten Sie den Dienst später nicht mehr brauchen, beenden Sie ihn wie folgt dauerhaft:

systemctl disable --now docker-mysql

Quellen/Links

Aktualisierung eines Kanboard-Pods

26. April 2021 um 07:00

Dies ist der letzte Artikel in meiner kleinen Reihe, über meinen Ausflug ins Container-Land, zur Bereitstellung der Anwendung Kanboard.

Wie meine Reise ins Container-Land begonnen hat, kann in „Kanboard im Container…“ nachgelesen werden. Wie man einen Reverse-Proxy vor einem Pod betreibt sowie mit dem Thema Backup und Restore habe ich mich inzwischen ebenso beschäftigt. Letzteres habe ich zum Glück implementiert und getestet, bevor ich mit der Dokumentation Datenverlust erlitten habe. Damit die Anwendung nach einem Neustart automatisch startet und für ein bisschen Komfort, habe ich Systemd-Service-Units generiert. In diesem Teil geht es nun um die Aktualisierung dieser Umgebung.

Umgebung

Aktuell läuft Kanboard 1.2.18 auf einer RHEL 8 VM. Zur Ausführung sind folgende Werkzeuge und Container-Images beteiligt.

$ podman --version
podman version 2.2.1
$ podman images
REPOSITORY                              TAG      IMAGE ID      CREATED        SIZE
registry.redhat.io/rhel8/postgresql-96  latest   4ce7daa6dc1d  7 weeks ago    451 MB
docker.io/kanboard/kanboard             v1.2.18  e7ee6403944b  3 months ago   58.6 MB
k8s.gcr.io/pause                        3.2      80d28bedfe5d  14 months ago  688 kB

Um mir die Erstellung eines Pods und das Einhängen von Podman-Volumes zu erleichtern, nutze ich folgendes kleines Skript:

#!/bin/bash
podman run -d --pod new:kanboardpod --name kanboard --privileged -p 127.0.0.1:8080:80 -v kanboard_datadir:/var/www/app/data:Z -v kanboard_pluginsdir:/var/www/app/plugins:Z kanboard/kanboard:v1.2.18

podman run -d --pod kanboardpod --name pgsql_db -e POSTGRESQL_USER=<USERNAME> -e POSTGRESQL_PASSWORD=<Verrate ich nicht> -e POSTGRESQL_DATABASE=kanboard -v pgsql_dbdir:/var/lib/pgsql/data:Z rhel8/postgresql-96:1-107

Mein Pod und die drei dazugehörigen Container werden während der folgenden Schritte noch normal ausgeführt.

Die Container selbst sind dabei zustandslos. Die persistent zu speichernden Daten werden in Podman-Volumes im lokalen Dateisystem der VM abgelegt.

Vorgehensweise

Ich verzichte in diesem Fall bewusst auf podman-auto-update(1), da ich mir erstmal einen Überblick verschaffen möchte, was denn generell zu tun ist und wie die einzelnen Schritte aussehen können. Die grundsätzliche Reihenfolge für ein Update sieht dabei wie folgt aus:

  1. Aktuelle Container-Images aus einer Registry holen (podman-pull(1))
  2. Laufende Pod-Instanz stoppen und entfernen (podman-pod(1))
  3. Neue Pod-Instanz mit angepasstem Wrapper-Skript erstellen
  4. Systemd-Service-Units erneut generieren (podman-generate-systemd(1))
  5. Pod-Instanz stoppen
  6. Generierte Systemd-Service-Unit starten

An dieser Stelle möchte ich vorweg nehmen, dass es genau so einfach war, wie es sich anhört. Die neuen Container-Images habe ich mit folgenden Kommandos heruntergeladen.

$ podman pull docker.io/kanboard/kanboard:v1.2.19
Trying to pull docker.io/kanboard/kanboard:v1.2.19...
Getting image source signatures
Copying blob 0c2b98bb5f7e done
Copying blob ca3cd42a7c95 done
Copying blob e994ab432c32 done
Copying blob 7b30337f40d2 done
Copying blob f58d66ecc40b done
Copying config 2cb48121b7 done
Writing manifest to image destination
Storing signatures
2cb48121b7437ba15cd984472754b300395026c3e09e7c659b4f9b62e5b5b4dd

$ podman pull registry.redhat.io/rhel8/postgresql-96:1-127
Trying to pull registry.redhat.io/rhel8/postgresql-96:1-127...
Getting image source signatures
Copying blob 64607cc74f9c done
Copying blob 320ae7fa06a7 done
Copying blob 13897c84ca57 done
Copying blob b3b2bbe848df done
Copying config 9c6ab01c14 done
Writing manifest to image destination
Storing signatures
9c6ab01c14748f7ff79483759122cb28e0f2c8b0310e5c8d9b5af8383e91f163

$ podman images
REPOSITORY                              TAG      IMAGE ID      CREATED        SIZE
docker.io/kanboard/kanboard             v1.2.19  2cb48121b743  4 days ago     61.3 MB
registry.redhat.io/rhel8/postgresql-96  1-127    9c6ab01c1474  2 weeks ago    449 MB
registry.redhat.io/rhel8/postgresql-96  latest   4ce7daa6dc1d  7 weeks ago    451 MB
docker.io/kanboard/kanboard             v1.2.18  e7ee6403944b  3 months ago   58.6 MB
k8s.gcr.io/pause                        3.2      80d28bedfe5d  14 months ago  688 kB

Mit den folgenden Befehlen werden Informationen zum laufenden Pod angezeigt, der Service wird gestoppt und der Pod inkl. seiner Container entfernt.

$ podman pod ls
POD ID        NAME         STATUS   CREATED      INFRA ID      # OF CONTAINERS
2f3aa7d07e6e  kanboardpod  Running  4 weeks ago  34e8479a2847  3

$ systemctl --user stop pod-kanboardpod.service

$ podman pod ls
POD ID        NAME         STATUS  CREATED      INFRA ID      # OF CONTAINERS
2f3aa7d07e6e  kanboardpod  Exited  4 weeks ago  34e8479a2847  3

$ podman pod rm kanboardpod
2f3aa7d07e6eb7d4c3a0c9927dac222be52b8992f95929c12af8ce4afafd4eb1

In mein Wrapper-Skript (siehe Abschnitt Umgebung) trage ich die neuen Versionsnummern bei den entsprechenden Aufrufen ein:

#!/bin/bash
podman run -d --pod new:kanboardpod --name kanboard --privileged -p 127.0.0.1:8080:80 -v kanboard_datadir:/var/www/app/data:Z -v kanboard_pluginsdir:/var/www/app/plugins:Z kanboard/kanboard:v1.2.19

podman run -d --pod kanboardpod --name pgsql_db -e POSTGRESQL_USER=<USERNAME> -e POSTGRESQL_PASSWORD=<Verrate ich nicht> -e POSTGRESQL_DATABASE=kanboard -v pgsql_dbdir:/var/lib/pgsql/data:Z rhel8/postgresql-96:1-127

Nachdem das obige Wrapper-Skript ausgeführt wurde, prüfe ich, ob die neue Pod-Instanz läuft, erstelle die Service-Units und aktiviere diese:

$ podman pod ls
POD ID        NAME         STATUS   CREATED             INFRA ID      # OF CONTAINERS
85273ee9bb82  kanboardpod  Running  About a minute ago  82f45a722dff  3

$ podman container ls
CONTAINER ID  IMAGE                                         COMMAND         CREATED             STATUS                 PORTS                   NAMES
6becc68a9c20  registry.redhat.io/rhel8/postgresql-96:1-127  run-postgresql  About a minute ago  Up About a minute ago  127.0.0.1:8080->80/tcp  pgsql_db
82f45a722dff  k8s.gcr.io/pause:3.2                                          About a minute ago  Up About a minute ago  127.0.0.1:8080->80/tcp  85273ee9bb82-infra
e72ca46110be  docker.io/kanboard/kanboard:v1.2.19                           About a minute ago  Up About a minute ago  127.0.0.1:8080->80/tcp  kanboard

$ podman generate systemd --files --name kanboardpod
/home/bob/pod-kanboardpod.service
/home/bob/container-kanboard.service
/home/bob/container-pgsql_db.service

$ mv *.service .config/systemd/user/

$ podman pod stop kanboardpod
85273ee9bb82e49e236ae37d9320fd95af1eb186d7d965d72b9e2a270ca5cedf

$ systemctl --user daemon-reload
$ systemctl --user start pod-kanboardpod.service

Fazit

Das war einfacher als gedacht. Oder anders formuliert, es hat tatsächlich so funktioniert, wie ich es erwartet habe.

Mein kleines Wochenend-Projekt skaliert sicher nicht gut und ist als Beispiel für Produktionsumgebungen vermutlich weniger geeignet. Doch um Software als rootless-Container auszuführen und in kleinem Umfang zu testen, scheint dieser Weg durchaus geeignet zu sein.

Vielleicht schiebe ich in Zukunft noch einen Artikel unter Verwendung von podman-auto-update(1) nach.

Podman kann auch Systemd-Service-Units generieren

22. Februar 2021 um 08:00

Mit „Kanboard im Container…“ hat mein Ausflug ins Containerland begonnen. Mittlerweile läuft mein Pod bereits eine Weile und ich nutze die Anwendung regelmäßig. Jedoch musste ich nach jedem Neustart des Hosts den Pod kanboardpod manuell starten. Ich hatte mir daher vorgenommen, hierfür eine Systemd-Service-Unit zu erstellen, welche diesen Task automatisiert. Doch habe ich mit Freude festgestellt, dass podman-generate-systemd(1) mir diese Arbeit abnehmen kann.

Also starte ich einen ersten Versuch und erzeuge entsprechende Service-Unit-Dateien in meinem HOME-Verzeichnis. Die Option „--name“ sorgt dafür, dass in den Service-Unit-Dateien die Namen des Pods bzw. der Container verwendet werden, anstatt der UUIDs. Die Option „--files“ sorgt dafür, dass die Ausgabe in Dateien und nicht auf die Standard-Ausgabe geschrieben wird.

$ podman generate systemd --name --files kanboardpod
/home/alice/pod-kanboardpod.service
/home/alice/container-kanboard.service
/home/alice/container-pgsql_db.service

$ cat pod-kanboardpod.service
# pod-kanboardpod.service
# autogenerated by Podman 2.0.5
# Mon Jan 25 13:19:51 CET 2021

[Unit]
Description=Podman pod-kanboardpod.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
Requires=container-kanboard.service container-pgsql_db.service
Before=container-kanboard.service container-pgsql_db.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start 62cdd29105a4-infra
ExecStop=/usr/bin/podman stop -t 10 62cdd29105a4-infra
ExecStopPost=/usr/bin/podman stop -t 10 62cdd29105a4-infra
PIDFile=/run/user/1000/containers/overlay-containers/b3c9bd9754cdc999108d0f4aad7d808c007cc34eee34faefd41ee39c3e1ca18b/userdata/conmon.pid       
KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target default.target

$ cat container-kanboard.service 
# container-kanboard.service
# autogenerated by Podman 2.0.5
# Mon Jan 25 13:19:51 CET 2021

[Unit]
Description=Podman container-kanboard.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
BindsTo=pod-kanboardpod.service
After=pod-kanboardpod.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start kanboard
ExecStop=/usr/bin/podman stop -t 10 kanboard
ExecStopPost=/usr/bin/podman stop -t 10 kanboard
PIDFile=/run/user/1000/containers/overlay-containers/99d386a42b186efb3347d909cea265b990469dc33e1889a3006425a71956699b/userdata/conmon.pid
KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target default.target

$ cat container-pgsql_db.service 
# container-pgsql_db.service
# autogenerated by Podman 2.0.5
# Mon Jan 25 13:19:51 CET 2021

[Unit]
Description=Podman container-pgsql_db.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
BindsTo=pod-kanboardpod.service
After=pod-kanboardpod.service

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
ExecStart=/usr/bin/podman start pgsql_db
ExecStop=/usr/bin/podman stop -t 10 pgsql_db
ExecStopPost=/usr/bin/podman stop -t 10 pgsql_db
PIDFile=/run/user/1000/containers/overlay-containers/fe757283f0662220fee23a563053ea7f30dbdf6d9fbb492c010a01dd7598fc9b/userdata/conmon.pid
KillMode=none
Type=forking

[Install]
WantedBy=multi-user.target default.target

Um die generierten Service-Units zu installieren und zukünftig als derjenige User auszuführen, welcher den Pod und die Container erzeugt hat, verschiebe ich sie in das zu erstellende Verzeichnis ~/.config/systemd/user. Anschließend werden die neuen Units in die Systemd-Konfiguration eingelesen und aktiviert.

$ mkdir -p .config/systemd/user
$ mv *.service .config/systemd/user/
$ systemctl --user enable pod-kanboardpod.service
$ podman pod stop kanboardpod
$ systemctl --user start pod-kanboardpod.service

Nachdem ich die Service-Units an die richtige Stelle verschoben und aktiviert hatte, habe ich meine laufende Pod-Instanz gestoppt und über die entsprechende Service-Unit gestartet.

Ich wähnte mich nun bereits am Ziel. Doch nach einem Neustart des Hosts war die Anwendung wieder nicht verfügbar. Die Service-Unit war nicht gestartet worden. Podman kann hier nichts dafür, denn es ist systemd, welcher dafür sorgt, dass im User-Kontext laufende Services beendet werden, wenn sich der entsprechende User ausloggt und diese erst startet, wenn der User sich einloggt.

Valentin Rothberg von Red Hat gab mir den entscheidenden Tipp, um dieses Problem zu lösen. Die Lösung versteckt sich in der Manpage zu podman-generate-systemd(1):

The systemd user instance is killed after the last session for the user is closed. The systemd user instance can be kept running ever after the user logs out by enabling lingering using

$ loginctl enable-linger <username>

Manual page podman-generate-systemd(1)

@Valentin: Thanks a lot, that solved my issue!

Fazit

Ich bin ehrlich gesagt hoch erfreut, dass die Entwickler hier eine Möglichkeit vorgesehen haben, um aus bestehenden Pods bzw. Container-Instanzen Systemd-Service-Units generieren zu können. Dies ermöglicht es, Container-Instanzen und Pods mit den gewohnten Werkzeugen zu starten, zu stoppen und deren Status zu kontrollieren.

So besteht die Möglichkeit, die rootless-Podman-Container auch als unprivilegierte Dienste laufen zu lassen. Das gefällt mir.

Systemd 247 stellt den Out-of-Memory Daemon vor

27. November 2020 um 14:07

Systemd 247 integriert unter anderem den bei Facebook entwickelten Out-of-Memory Daemon, um besser auf Speicherengpässe reagieren zu können.

Die unendliche Geschichte: Debian und Systemd

20. November 2020 um 08:01

Debian und Systemd ist eine endlose Geschichte, die jetzt in eine weitere Runde geht. Die Frage ist, ob Maintainer alternative Init-Systeme blockieren dürfen.

Fedora 33

28. Oktober 2020 um 11:47

In Fedora 33 gibt es abseits der üblichen Versions-Updates drei vier grundlegende Neuerungen:

  • Als minimaler Texteditor ist nano vorinstalliert, nicht vim. Persönlich empfinde ich das als großen Fortschritt. Alle vi-Freunde müssen eben dnf install vim ausführen (so wie ich nach jeder Linux-Installation dnf/apt install joe ausführe, damit mir der Mini-Emacs jmacs zur Verfügung steht).
  • Das Defaultdateisystem für die Desktop-Version von Fedora lautet nun btrfs und nicht mehr ext4. (Details dazu folgen gleich.)

  • Als lokaler DNS-Client kommt systemd-resolved zum Einsatz.

  • Update 29.10.2020: Standardmäßig wird weder eine Swap-Datei noch eine Swap-Partition eingerichtet. Stattdessen werden bei Bedarf Datenblöcke komprimiert in ein ZRAM-Device ausgelagert.

Überraschenderweise wird Fedora in diesem Fall seiner Vorreiterrolle nur teilweise gerecht. (open)SUSE verwendet btrfs schon seit Jahren standardmäßig. systemd-resolved kommt wiederum in Ubuntu schon seit geraumer Zeit zum Einsatz (wenn ich mich recht erinnere, seit Version 18.04).

btrfs

Das Dateisystem btrfs gilt mittlerweile als ausgereift. Nicht nur (open)SUSE setzt es standardmäßig ein, auch Facebook und Synology sind von den Vorzügen dieses Dateisystems überzeugt. Dessen ungeachtet war ich immer ein wenig skeptisch, ob btrfs das ideale Dateisystem für Privatanwender ist (und bin dies nach wie vor): Die Administration ist deutlich komplexer als bei einem simplen ext4-Dateisystem.

Im Gegensatz zu openSUSE verzichtet Fedora darauf, unzählige Subvolumes mit unterschiedlichen Eigenschaften zu definieren. Stattdessen ist das Default-Setup denkbar einfach: Es gibt (falls notwendig) ein VFAT-Dateisystem für EFI, ein ext4-Dateisystem für /boot und ein btrfs-Dateisystem für die Subvolumes / und /home. Entsprechend übersichtlich sind die Datei /etc/fstab und die Ergebnisse der Kommandos mount -t btrfs oder df -t btrfs.

Das einfache Setup hat allerdings den Nachteil, dass manche Features von btrfs nicht optimal genutzt werden: Zum einen wäre es schön, wenn (zumindest für manche Verzeichnisse) die Komprimierfunktion von btrfs aktiviert würde. Zum zweiten ist der Copy-on-Write-Ansatz von btrfs für manche Anwendungen (Datenbanksysteme, Virtualisierung) langsam. Abhilfe schaffen eigene Subvolumes, in denen CoW deaktiviert ist. Zu guter Letzt könnten dnf-Operationen durch Snapshots abgesichert werden.

Die Fedora-Entwickler denken über diese in openSUSE bereits implementierten Features ebenfalls nach und wollen, wenn sich btrfs in Fedora 33 bewährt, mehr btrfs-Funktionen mit Fedora 34 liefern. (Dann werde ich an dieser Stelle kritisieren, dass btrfs zu komplex ist …)

systemd-resolved

systemd-resolved ist ein Network Name Resolution Manager, also ein Programm, das herausfindet, welche IP-Adresse einem Hostnamen wie kofler.info zugeordnet ist. systemd-resolved merkt sich die IP-Adressen der zuletzt angefragten Hostname und agiert somit auch als DNS-Cache.

/etc/resolv.conf verweist nicht, wie dies früher üblich war, auf die IP-Adressen der externen Nameserver, sondern vielmehr auf die lokale IP-Adresse 127.0.0.53 des Programms systemd-resolved. Welche externe DNS-Server tatsächlich zum Einsatz kommen, verrät resolvectl status.

Swap on ZRAM

Beim ersten Test glatt übersehen habe ich, dass der Fedora-Installer standardmäßig keine Swap-Partition mehr einrichtet. Ubuntu macht das auch nicht mehr, dort gibt es aber stattdessen eine Swap-Datei, die diese Rolle übernimmt. Was macht aber Fedora, wenn so viele speicherintensive Prozesse laufen, dass das RAM zur Neige geht?

Während des Systemstarts wird das Device /dev/zram0 wie eine Swap-Partition eingerichtet. Das Device beansprucht anfänglich keinen Speicherplatz. Die maximale Größe (unkomprimiert) wird je nach Größe des RAMs festgelegt, z.B. 4 GiB, wenn 16 GiB RAM zur Verfügung stehen.

Wenn der Arbeitsspeicher knapp wird, lagert der Swap-Mechanismus des Kernels Speicherblöcke in die Swap-Partition aus. Da sich diese ebenfalls im RAM befindet, sieht das nach einem Nullsummenspiel aus. Der Clou besteht darin, dass die Datenblöcke in /dev/zram0 automatisch komprimiert werden, wobei der sehr schnelle LZO-Algorithmus zum Einsatz kommt. Anders als bei einem echten Swap-System wird also nicht 1:1 so viel RAM frei, wie Speicherblöcke ausgelagert werden.

Der wesentliche Vorteil von Swap on ZRAM besteht darin, dass der Swap-Speicher trotz der Komprimierung deutlich schneller ist als bei einer herkömmlichen Konfiguration mit einer Swap-Partition oder -Datei auf einem physischen Datenträger. Informationen über die maximale Größe des Swap-Speichers (unkomprimiert) sowie über die aktuelle Nutzung gibt wie üblich swapon -s. Wie gut die Komprimierung des Swap-Speichers gelingt, verrät das relativ neue Kommando zramctl:

ls -l /dev/zram0 

  brw-rw----. 1 root disk 251, 0 Oct 29 08:21 /dev/zram0

cat /sys/block/zram0/disksize

  2009071616   (max. Größe in Byte)

swapon -s

  Filename      Type            Size      Used    Priority
  /dev/zram0    partition       1961980   0       100
                                ^
                                (max. Größe in 1k-Blöcken)

zramctl 

  NAME        ALGORITHM  DISKSIZE  DATA  COMPR  TOTAL  STREAMS  MOUNTPOINT
  /dev/zram0  lzo-rle        1.9G    4K    74B    12K        2  [SWAP]

Mehr Details zur Motivation dieses Features sowie zur technischen Umsetzung sind hier protokolliert.

Installation

Beim Wettstreit, welche Distribution die einfachste Desktop-Installation anbietet, hat Fedora aktuell die Nase vorn — zumindest solange Sie nichts an der Default-Partitionierung verändern möchten. Nach der Einstellung der Sprache können Sie gleich weiter auf Installation starten drücken.

Bei der Installation gibt es nicht viel einzustellen

Unerfreulich wird die Angelegenheit aber, wenn Sie statt btrfs ein anderes Dateisystem wünschen oder sonst eine Änderung an der Partitionierung vornehmen möchten. Dann müssen Sie eine manuelle Partitionierung vornehmen, die unübersichtlich wie eh und je ist. Das können beinahe alle anderen Distributionen besser.

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel      5.8   Gnome        3.38   bash       5.0   Apache     2.4
glibc      2.32   Firefox        81   gcc       10.2   CUPS       2.3
X-Server   1.20   Gimp         2.10   Java   8/11/15   MariaDB   10.4
Wayland    1.18   LibreOffice   7.0   PHP        7.4   OpenSSH    8.4
Mesa       20.2   Thunderbird    78   Python     3.9   qemu/KVM   5.1
Systemd     246                                        Postfix    3.5
NetworkMan 1.26                                        Samba     4.13
GRUB       2.04 

Quellen und Links

Details zu btrfs, systemd-resolved und Swap on ZRAM

Plasma 5.21 erhält neue Startoption

07. Oktober 2020 um 12:11

Start und Stopp einer Plasma-Sitzung waren bisher von Bootscripten gesteuert. Mit Plasma 5.21 kann der Vorgang alternativ über Systemd gesteuert werden.

tdps.service — Service-Unit für den TeamDrive Personal Server

17. August 2020 um 07:00

Kaum eine Software verwende ich so lange wie TeamDrive. Die ersten Artikel dazu in diesem Blog stammen bereits aus dem Jahr 2011 [0], [1].

Nachdem ich den TeamDrive Personal Server schon auf einem NAS installiert und als Dienst konfiguriert habe, dokumentiere ich in diesem Artikel die Erstellung einer Systemd-Service-Unit. Dazu sei gesagt, dass ich kein Experte für Systemd-Units bin. Tatsächlich kenne ich mich nichtmal besonders gut damit aus. Folgende Lösung funktioniert auf meinem Server. Anregungen zur Verbesserung der Service-Unit nehme ich gern in den Kommentaren entgegen.

Installation des TeamDrive Personal Server

Zuerst muss der TeamDrive Personal Server heruntergeladen und installiert werden. Dabei hilft das dazugehörige Handbuch. Auch wenn dieses schon einige Jahre auf dem Buckel hat, sind die enthaltenen Informationen weiterhin aktuell.

Da die Installation hier im Blog bereits einmal beschrieben wurde, gehe ich hier im Detail nicht weiter darauf ein. Im vorliegenden Fall wurde die Software im Verzeichnis /opt/tdps installiert. Darüber hinaus wurde ein Benutzer tdps erstellt, welchem das Verzeichnis /opt/tdps und die darin enthaltenen Dateien gehören.

Systemd-Service-Unit tdps.service

Ich habe den TeamDrive Personal Server (TDPS) auf einem Debian 10 System installiert. Um diesen wie alle übrigen Dienste mit dem Programm systemctl verwalten zu können, habe ich die Datei /etc/systemd/system/tdps.service mit folgendem Inhalt erstellt:

[Unit]
Description="TeamDrive Personal Server"
After=network.target

[Service]
User=tdps
PIDFile=/opt/tdps/tdpsd.pid
ExecStart=/opt/tdps/tdpsd -c /opt/tdps/tdps.config -m /opt/tdps/mime.types -w /opt/tdps
ExecStop=/opt/tdps/stop-tdps -p /opt/tdps/tdpsd.pid
KillMode=process
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Im Abschnitt [Unit] findet sich eine kurze Beschreibung der Service-Unit. Die Option After=network.target gibt an, dass diese Unit erst gestartet werden soll, wenn das Netzwerk zur Verfügung steht. Dies ist Voraussetzung, um den Dienst über das Netzwerk nutzen zu können.

Die Zeile im letzten Abschnitt [Install] definiert, dass diese Unit Bestandteil des multi-user.target ist und mit diesem geladen wird.

Der Abschnitt [Service] definiert die für den Dienst relevanten Parameter. Die gewählten Optionen werde ich im Folgenden erläutern.

User= gibt den Namen des Benutzers an, mit dessen Rechten der Dienst ausgeführt werden soll. In diesem Fall wird der extra für diesen Zweck erstellte User tdps verwendet.

PIDFile= gibt den Pfad an, wo der Dienst seine PID speichert. Der Service-Manager liest die PID des Hauptprozess aus dieser Datei, nachdem der Service gestartet wurde.

ExecStart= gibt das Kommando mit allen notwendigen Argumenten an, um den Dienst zu starten. Ich habe hier ein wenig mit verschiedenen Aufrufen experimentiert. Dabei habe ich verschiedene Möglichkeiten gefunden, den Dienst erfolgreich zu starten. Worin die Unterschiede im Aufruf genau bestehen, kann ich leider nicht sagen. Am Ende habe ich mich für obige Kommandozeile entschieden, die ich im TeamDrive-Forum gefunden habe. Aus diesem Foren-Beitrag habe ich auch Stumpf die Option KillMode=process übernommen. Zur Option selbst kann ich (noch) nicht viel sagen. Dies änderst sich vielleicht noch, da ich mich noch etwas damit beschäftigen möchte.

Mit ExecStop= gibt man entsprechend an, wie der Dienst zu stoppen ist. Auch hier stammt die Kommandozeile aus oben verlinktem Foren-Thread.

Die nächsten drei Optionen PrivateTmp=, ProtectHome= und ProtectSystem= dienen dazu den Dienst zu härten. Durch PrivateTmp=yes erhält der gestartete Prozess einen eigenen Dateisystem-Namespace für /tmp und /var/tmp. So kann der Prozess nicht auf die Dateien anderer Prozesse und Benutzer in den normalen Verzeichnissen /tmp und /var/tmp zugreifen. Mit ProtectHome=yeswird der Zugriff des Dienstes auf die Verzeichnisse /home, /root und /run/user verhindert. ProtectSystem=full sorgt dafür, dass die Verzeichnisse /boot, /etc und /usr im Nur-Lese-Modus für den Prozess zur Verfügung stehen. Damit ist sichergestellt, dass der von dieser Unit gestartete Prozess keine Dateien innerhalb dieser Verzeichnisse verändern kann.

Die drei im vorhergehenden Abschnitt genannten Optionen stellen einen zusätzlichen Schutz dar. Zwar darf der Benutzer tdps schon aufgrund der Datei- und Verzeichnisberechtigungen nicht in den genannten Verzeichnissen schreiben und Dateien verändern bzw. diese überhaupt lesen, doch bieten diese Optionen einen zusätzlichen Schutz und greifen auch noch, wenn jemand Schindluder mit den Berechtigungen getrieben hat. Daher halte ich es für sinnvoll diese Optionen wenn möglich in allen Service-Units zu nutzen.

Neben den drei hier vorgestellten Optionen gibt es noch einige weitere, welche im englischsprachigen Artikel „Mastering systemd: Securing and sandboxing applications and services“ nachgelesen werden können. Ich finde diese so sinnvoll, dass ich mich ehrlich gesagt frage, warum die genannten Einstellungen nicht der Standard sind und man diese editieren muss, wenn man entsprechende Zugriffe explizit erlauben möchte.

Damit ist alles getan und dokumentiert. Der TDPS lässt sich mit oben beschriebener Service-Unit starten und stoppen. Den Status abfragen kann man selbstverständlich auch.

Es bleibt ein kleiner Schönheitsfehler. Wird der Dienst mittels sudo systemctl stop tdps.service gestoppt, endet die Unit im Status „failed“. Warum das so ist, habe ich noch nicht herausgefunden. Ich vermute, es hängt damit zusammen, dass der Dienst mittels SIGTERM beendet wird. Bin mir an dieser Stelle jedoch nicht sicher. Falls von euch jemand eine Idee dazu hat, freue ich mich über euren Kommentar.

Wie schreibt ihr eure Service-Units? Welche Optionen sollten eurer Meinung nach in keiner Unit fehlen? Wenn ihr mögt, lasst uns gerne in den Kommentaren darüber diskutieren.

Ältere Artikel zu TeamDrive in diesem Blog

Systemd 246 bringt viele Änderungen

03. August 2020 um 10:50

Mit der neuen Version 246 haben die Entwickler des Linux-Init-Systems und System-Managers Systemd eine ganze Reihe von Neuerungen verbunden.

Zu den neuen Funktionen zählt die Unterstützung der Zstd-Kompression bei Journal-Files durch Systemd-Journald. Auch Coredumps über Systemd-Coredump könne die Zstd-Kompression nutzen, teilen die Entwickler im zugehörigen News-File für Systemd 246 mit.

Systemd protokolliert nun alle verbleibenden Prozesse im System, wenn es gestoppt wird. Zudem warnt Systemd vor Services, die mit “KillMode=none” arbeiten. Diese Option zu verwenden sei eine prinzipiell unsichere Angelegenheit, so die Entwickler.

Entfernt haben die Entwickler die Unterstützung für die “.include”-Syntax in den Unit Files. Das Konzept dahinter sei bereits seit sechs Jahren obsolet und man warne bereits seit zwei Jahren, dass die Syntax entfernt werde.

Mit einer neuen Hardware-Datenbank-Datei sammeln die Entwickler zudem Informationen zu PCI- und USB-Geräten, die Auto-Suspend korrekt beherrschen. ChromeOS und ChromiumOS sind dafür die initialen Datenlieferanten.

Die lange Liste der Änderungen und Neuerungen ist im News-File nachzulesen.

Der Beitrag Systemd 246 bringt viele Änderungen erschien zuerst auf Linux-Magazin.

Systemd-oomd räumt den Speicher auf

14. Juli 2020 um 07:49

Mit Systemd 247 könnte systemd-oomd das Licht der Welt erblicken. Der Daemon soll bei Bedarf Speicher schneller freigeben als der Kernel.

Flatpak 1.8.0 setzt beim Sideloading auf Systemd

26. Juni 2020 um 11:42

Die Entwickler der Paketverwaltung Flatpak haben eine neue Version 1.8.0 freigegeben, die neben Fehlerkorrekturen auch einige Änderungen aufweist. Unter anderem liefert Flatpak seinen Apps jetzt immer die aktuellen Zeitzonendaten des Host-Systems.

Damit sollen auch Apps wieder fehlerfrei laufen, die zuvor Probleme mit der Zeitzone aufwiesen. Mit an Bord ist jetzt auch eine Systemd Unit, die automatisch einen angestöpselten USB-Stick mit einem Sideload-Repository erkennt. Solche Repositories bestehen aus einem (in Teilen) kopierten und lokal verfügbaren Flatpak-Repository, das zum einen die Installation beschleunigen soll und zum anderen beim Ausfall der Internetverbindung einspringt. Die neue Systemd Unit ist allerdings standardmäßig nicht aktiv.

Die Erstellung eines Sideload-Repositories übernimmt “create-usb”, das jetzt standardmäßig partielle Commits exportiert. Des Weiteren installiert Flatpak 1.8.0 nicht mehr die GDM env.d-Datei – die entsprechende Aufgabe übernehmen Systemd Generators. Abschließend kennt “FlatpakTransaction” das neue Signal “install-authenticator”, das die Installation eines für eine Transaktion notwendigen Authenicators anstößt. Sämtliche Neuerungen fassen die Release Notes zusammen.

Der Beitrag Flatpak 1.8.0 setzt beim Sideloading auf Systemd erschien zuerst auf Linux-Magazin.

Systemd 245 bringt portable Home-Verzeichnisse

09. März 2020 um 13:15

Die aktuelle Version von Systemd bringt den Homed-Systemdienst für portable und verschlüsselte Home-Verzeichnisse. Hinzu kommen eine Nutzerdatenbank und ein Werkzeug zum Repartitionieren.

Die Entwickler des Linux-Userspace-Werkzeugkastens Systemd haben Version 245 ihres Projekts veröffentlicht. Neu hinzugekommen ist dabei der Homed-Systemdienst, mit dem verschlüsselte Home-Verzeichnisse besser verwaltet werden sollen. Die kompletten Metadaten der Nutzer sind dabei vereinheitlicht, wie das Team schreibt. Das führe dazu, dass die Home-Verzeichnisse leicht migriert werden können.

Erstmals vorgestellt hatte die Idee zu Homed der Systemd-Projektgründer Lennart Poettering im September 2019 auf der eigenen Community-Konferenz. Der Dienst Systemd-Homed soll dabei nicht unbedingt traditionelle Home-Verzeichnisse abschaffen, sondern lediglich eine Zusatzoption schaffen, um das Home-Verzeichnis auf einem USB-Stick einfach mitnehmen zu können. Gedacht ist der Dienst etwa für Laptops im Unternehmenseinsatz.

Ebenfalls neu hinzugekommen zu der Werkzeugsammlung ist Systemd-Repart, mit dem GPT-Partitionstabellen repartitioniert werden können. Das Werkzeug nutzt dabei eine Deklaration einer neuen Tabelle und setzt diese um, indem vorhandene Partitionen vergrößert oder neue hinzugefügt werden. Gedacht ist das neue Hilfsprogramm vor allem für verkleinerte Betriebssystem-Abbilder, die verkleinert verteilt und beim ersten Boot vergrößert werden.

Als neue Komponente verfügt Systemd nun außerdem über eine Userdb mit dazugehörigem Systemdienst und Kommandozeilenclient. Ziel ist es dabei, die bisherigen Structs für Gruppe und Passwort durch ein Framework zu erweitern, das nun das Verarbeiten von erweiterten Informationen ermöglichen soll. Das Systemd-Team hofft, dass langfristig Frameworks wie SSSD künftig das neue Format nutzen, so dass etwa Ressourcenverwaltung oder ähnliche Einstellungen pro Nutzer etwa in LDAP-Verzeichnissen konfiguriert werden können. Diese sollen dann wiederum von Logind oder dem Systemd-PAM-Dienst beim Login genutzt werden können.

Eine Vielzahl weiterer Neuerungen listet die Ankündigung. Dazu gehören kleinere Änderungen am eigenen Init-Dienst, die Unterstützung des neuen PIDFD des Linux-Kernels, Änderungen am Networkd oder die Unterstützung für Smartcards oder auch Token wie Yubikeys.

Der Beitrag Systemd 245 bringt portable Home-Verzeichnisse erschien zuerst auf Linux-Magazin.

Linux from Scratch 9.1 (LFS) ist veröffentlicht – BLFS ebenfalls

03. März 2020 um 08:09
Von: jdo

Die Community um LFS hat Linux From Scratch 9.1 angekündigt. Zeitgleich wurden LFS 9.1 (systemd), BLFS 9.1 und BLFS 9.1 (systemd) veröffentlicht. Laut eigenen Angaben handelt es sich um eine große neue Version von LFS und BLFS. Linux From Scratch ist keine Linux-Distribution, sondern eher eine Anleitung, wie Du selbst eine erstellen kannst. Es ist eine schritt-für-Schritt-Anleitung, wie Du Dein eigenes Linux-System erstellst und das komplett aus dem Quellcode. Das Projekt ist ein großartiger Blick hinter die Kulissen des Open-Source-Betriebssystems. […]

Der Beitrag Linux from Scratch 9.1 (LFS) ist veröffentlicht – BLFS ebenfalls ist von Linux | Spiele | Open-Source | Server | Desktop | Cloud | Android.

Debian-Projekt stimmt über Init-Systeme ab

02. Januar 2020 um 11:18

Das Debian-Projekt hat einmal mehr über den Einsatz von Systemd abgestimmt. Die Entwickler halten an dem komplexen Init-System fest, wollen aber Alternativen erforschen.

Es ist kein Sieg auf ganzer Linie für Systemd, denn das wäre laut der Abstimmung (General Resolution) die Option 1 gewesen: „Focus on Systemd“. Stattdessen hat Option 2 gewonnen, die auch die Suche nach Systemd-Alternativen unterstützt („Systemd but we support exploring alternatives“). Doch weder betrachten die Debianer den Support für mehrere Init-Systeme als „wichtig“, noch als „zwingend erforderlich“.

Die erste Abstimmung zu Systemd hatte sich 2014 als mehrteiliges Drama mit einigen Rücktritten vollzogen. Grund für die erneute Abstimmung war eine Feststellung, laut der „systemd-shim“ und „sysvinit“ zu wenig Pflege erhalten. Beide Pakete sind nötig, um alternative Init-Systeme mit Debian zu verwenden. Das aber fällt dem Projekt offenbar schwer, obwohl es zugleich einige Kritiker am alleinigen Systemd-Support gibt.

Alternative Init-Systeme

Sam Hartman entschied schließlich, eine General Resolution ins Leben zu rufen, um unter anderem die Aufnahme von Elogind abzusichern. Dieser Systemd-Logind-Daemon unterstützt den Dbus-basierten Login-Mechanismus von Systemd, aber nicht den Rest des Systems. Die Implementierung erwies sich allerdings als schwierig genug, um den Support für Nicht-Systemd-Systeme an sich in Frage zu stellen.

Die nun gewählte Option stammt vom aktuellen Projektleiter Sam Hartman selbst. Sie bestätigt einen vom Projekt bevorzugten Support für Systemds Service-Units, ohne aber die Arbeit an alternativen Init-Systemen abzuwerten. Das Debian-Projekt unterstütze auch Entwickler, die an solchen Alternativen arbeiten. Allerdings müssen die Interessierten dann selbst an den Paketen und dem Code feilen und die dafür benötigten Ressourcen aufbringen. Das Projekt und seine Mitglieder können solche Anstrengungen aber mit Patches und Diskussionen unterstützen. Außerdem will Debian auch mit Derivaten zusammenarbeiten, die alternative Init-Systeme bevorzugen.

Der Beitrag Debian-Projekt stimmt über Init-Systeme ab erschien zuerst auf Linux-Magazin.

NFS-Freigaben per Systemd einbinden

22. Dezember 2019 um 20:28

Beim Einbinden von Netzlaufwerken gibt es mehrere Möglichkeiten. Das automatisierte Einhängen per Systemd geht schnell und ist robust.

❌