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

Raspberry Pi OS Legacy für ältere Raspis

06. Dezember 2021 um 10:36

Die Raspberry-Pi-Foundation bringt neben dem aktuellen Release des Raspberry Pi OS für den hauseigenen Bastelrechnern nun eine zweite Version für die älteren Modelle heraus. Raspberry Pi OS Legacy basiert auf Debian 10 alias Buster und damit auf dem Oldstable-Release.

Der dort eingesetzte Kernel hat die Versionsnummer 5.10.y. Er werde lediglich mit aktuellen Security-Patches versorgt. Die Legacy-Ausgabe folgt den Supportzyklen von Debian. Wenn Debian Buster im Jahr 2024 keinen Support mehr bekommt und wenn Debian Bookworm in dieser Zeit stabil werde, wechsle Raspberry Pi (Legacy) auf das derzeit im aktuellen Betriebssystem eingesetzten Debian 11 Bullseye. Bullseye bekommt noch bis 2026 Updates. Letztlich sei Raspberry Pi Legacy ein Branch, der nur noch Sicherheits- und Hardware-Support-Patches für bestehende Produkte bekommt.

Neben der älteren Linux-Ausgabe bringt die Legacy weitere Anpassungen mit, die der älteren Hardware zugute kommen sollen. Statt dem Chromium Browser, der hardwarebeschleunigt ist, setzt Legacy auf den alten softwarebeschleunigten Browser. In der Ankündigung sind die Downloads verlinkt. Außerdem wird beschrieben, wie man das alte Kamera-Interface Picamera für Bullseye aktiviert.

Der Beitrag Raspberry Pi OS Legacy für ältere Raspis erschien zuerst auf Linux-Magazin.

Raspberry Pi OS (Legacy) – dauerhafte Unterstützung älterer Systeme

03. Dezember 2021 um 08:01
Von: jdo

Die aktuelle Version des offiziellen Betriebssystems für den Raspberry Pi ist Raspberry Pi OS Bullseye, das bekanntlich auf Debian 11 basiert. Im Laufe der letzten neun Jahre wurde immer nur eine Variante des Betriebssystems, früher auch als Raspbian bekannt, unterstützt. Bisher gab es beim Linux-Betriebssystem für den Pi drei große Versionssprünge oder vier verschiedene Unterbauten: Jessie > Stretch > Buster > Bullseye. Damit kommen auch immer neue Bibliotheken und Schnittstellen. Eine ziemlich sichtbare Änderung beim Sprung von Buster auf Bullseye […]

Der Beitrag Raspberry Pi OS (Legacy) – dauerhafte Unterstützung älterer Systeme ist von bitblokes.de.

Neues in Proxmox Mail Gateway 7.1

01. Dezember 2021 um 10:36

Die Proxmox Server Solutions GmbH hat heute die neue Version Proxmox Mail Gateway 7.1 veröffentlicht. Die Open-Source Email Security-Plattform basiert auf Debian Bullseye 11.1, Kernel 5.13 sowie OpenZFS 2.1. Neu ist unter anderem eine Multi-Faktor-Authentifizierung für den Zugriff auf die grafische Oberfläche.

Zur Verfügung als Zweit-Faktoren stehen WebAuthn, einmalige Wiederherstellungsschlüssel und Time-based OATH (TOTP). Zudem bringt die neue Version Verbesserungen für die API mit. Unter anderem wurde Unterstützung für die IP-Konfiguration über DHCP hinzugefügt.

Bei der Weboberfläche sei die Konfiguration von LDAP-Backends über die GUI verbessert worden. Änderungen seien nun ohne wiederholte Eingabe eines Passworts möglich und die APT-Repository-Konfiguration, die bisher auf “root” beschränkt gewesen sei, sei nun für alle Benutzer mit “Administratoren”-Rechten sichtbar und bearbeitbar.

Weitere Neuerungen nennen die Release Notes. Proxmox Mail Gateway ist unter GNU Affero GPL v3 lizenziert.

Der Beitrag Neues in Proxmox Mail Gateway 7.1 erschien zuerst auf Linux-Magazin.

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.

Neues Kamera-System in Raspberry Pi OS Bullseye erklärt

18. November 2021 um 08:23
Von: jdo

Mit der Ankündigung des auf Debian 11 basierendem Raspberry Pi OS Bullseye hat die Raspberry Pi Foundation auch einen separaten Artikel zum neuen Kamera-System versprochen. Der Beitrag ist nun veröffentlicht und das Entwickler-Team erklärt, was es mit libcamera auf sich hat und wie es mit dem Raspberry Pi funktioniert. Das Team weist noch einmal darauf hin, dass der Einsatz von libcamera ein wichtiger Schritt ist, weil es weniger Closed-Source-Code bedeutet. Allerdings heißt das auch, dass die neueren Versionen von Raspberry […]

Der Beitrag Neues Kamera-System in Raspberry Pi OS Bullseye erklärt ist von bitblokes.de.

Rootless-Podman mit Debian Bullseye

15. November 2021 um 06:00

Dieses Tutorial führt ein in:

Viel Spaß beim Lesen und Freude beim Nachmachen. Falls euch das Tutorial gefällt, freue ich mich über einen Kommentar. Falls ich etwas ausgelassen oder falsch dargestellt habe, freue ich mich ebenfalls über einen Hinweis in den Kommentaren oder per E-Mail.

Vorwort

Um sich im Container-Dschungel zurechtzufinden, ist eine fundierte Kenntnis der Terminologie unerlässlich. Die Einführung in die Terminologie ist jedoch nicht Bestandteil dieses Tutorials, da es den Umfang sprengen würde.

Unter folgenden Links kann man sich mit der Terminologie vertraut machen:

Leider wird die Terminologie selbst von jenen nicht stringent verwendet, die sie eigentlich kennen müssten. Dies sorgt gerade beim Einstieg in dieses komplexe Thema häufig für Verwirrung. Ich versuche in diesem Artikel so stringent wie möglich zu sein.

Umgebung

Für dieses Tutorial habe ich eine Installation mit Debian 11.1 (Bullseye) verwendet. Auf dem Host existieren die beiden User Alice und Bob, welche für die Nutzung von rootless-Podman vorbereitet werden.

Die Einrichtung von rootless-Podman unter Debian Bullseye

Rootless-Container haben die Eigenschaft, dass sie in User Namespaces (siehe user_namespaces(7) und namespaces(7)) ausgeführt werden. UIDs und GIDs, welche innerhalb des Containers existieren, werden dabei auf UIDs/GIDs des Hosts abgebildet. So besitzt ein Prozess, welcher innerhalb eines Containers mit der UID 0 (root) läuft, außerhalb des Containers bspw. die UID 165537 und damit die Rechte eines normalen Benutzers.

Damit dies funktioniert, wird jedem Benutzer, welcher in der Lage sein soll rootless-Podman-Container auszuführen, ein disjunktes Intervall sogenannter SUBUIDs und SUBGIDs zugewiesen. Dazu werden zuerst das Paket uidmap installiert und anschließend die Dateien /etc/subuid und /etc/subgid erzeugt, wie in folgendem Codeblock dargestellt.

sudo apt install uidmap
[...]
$ cat /etc/subuid
alice:100000:65536
bob:165536:65536

$ cat /etc/subgid
alice:100000:65536
bob:165536:65536

Ich habe mich hier an der RHEL 8 Dokumentation orientiert, welche am Ende des Artikels verlinkt ist. Darüber hinaus ist das Vorgehen in der Manpage podman(1) im Abschnitt „Rootless mode“ dokumentiert.

Nun werden podman und skopeo installiert, welche im weiteren Verlauf dieses Tutorials zum Einsatz kommen werden.

sudo apt install podman skopeo

Die Konfiguration von Container-Registries

In der Datei /etc/containers/registries.conf befindet sich die systemweite Konfiguration für Container-Registries. Jeder Benutzer kann abweichend von dieser eine eigene Konfiguration unter $HOME/.config/containers/registries.conf pflegen.

Bevor nun die ersten Container-Registries konfiguriert werden, möchte ich kurz auf voll-qualifizierte Image-Namen und Präfixe eingehen.

Im Internet findet man häufig Beispiele für Befehle wie podman pull ubuntu. Dabei ist podman das Kommando, pull ein Subkommando und ubuntu der Kurzname des herunterzuladenden Images.

Obige Kurznamen haben das Problem, dass durch ihre Verwendung nicht spezifiziert wird, aus welcher Container-Registry das Image heruntergeladen werden soll. Existiert ein Image mit gleichem Namen in diversen Container-Registries, wird es aus der ersten heruntergeladen, in der es gefunden wurde. Dies stellt ein potenzielles Sicherheitsrisiko dar!

Nehmen wir an, auf einem System sind die Container-Registries registry-1.de und registry-2.de konfiguriert. Das ubuntu-Image befindet sich unter registry-2.de/canonical/ubuntu. Stellt nun jemand ein Image gleichen Namens unter registry-1.de/boeserbube/ubuntu ein, wird bei Ausführung des oben genannten Kommandos mit Image-Kurznamen das falsche Container-Image heruntergeladen. Dies birgt die Gefahr, dass auf diesem Wege mit Schadcode angereicherte Container-Images ihren Weg ins System finden.

Es wird daher dringend empfohlen, stets den voll-qualifizierten Image-Namen zu verwenden, um vorstehend beschriebenes Sicherheitsrisiko auszuschließen. Der voll-qualifizierte Name hat dabei folgende Form:

host[:port]/namespace[_namespace_...]/repo(:_tag|@digest)
  • host spezifiziert den FQDN unter dem eine Container-Registry erreichbar ist, z. B. registry.fedoraproject.org.
  • port ist optional und wird verwendet, wenn die Registry nicht den Port 443/tcp nutzt.
  • namespace spezifiziert den Namensraum, in dem Container-Repos bereitgestellt werden.
  • repo bezeichnet ein Repository, aus dem konkrete Container-Images heruntergeladen werden können.
  • _tag|@digest optional können spezifische Tags oder Digests mit angegeben werden, um eine spezifische Version eines Container-Images herunterzuladen. Standardmäßig wird immer die letzte Version (mit dem Tag latest) heruntergeladen.

Statt einem podman pull ubuntu wird also ein podman pull registry-2.de/canonical/ubuntu empfohlen. Dabei stellt registry-2.de den Host, canonical den Namespace und ubuntu das Repository dar. Bei Verwendung der Docker-Registry führt man so nicht podman pull ubuntu aus, sondern stattdessen podman pull docker.io/library/ubuntu.

Für dieses Tutorial werden mehrere Registries durch folgenden Eintrag in der Datei /etc/containers/registries.conf konfiguriert:

unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'quay.io', 'registry.opensuse.org', 'registry.suse.com, 'docker.io']

Diese habe ich dem englischsprachigen Artikel unter 2 entnommen und um die Registries aus /etc/containers/registries.conf.d/shortnames.conf ergänzt. Letztere Datei stammt aus dem Paket golang-github-containers-common und stellt Aliase/Shortnames bereit, mit denen man sich einige Tipparbeit ersparen kann, da sie die Shortnames mit den entsprechenden Registries verknüpft. So sorgt z. B. der folgende Eintrag dafür, dass der Befehl podman pull rhel7 das Image ausschließlich aus der Registry „registry.access.redhat.com/rhel7“ herunterlädt und aus keiner anderen.

[aliases]
 "rhel7" = "registry.access.redhat.com/rhel7"

Auf diese Weise können Shortnames gefahrlos verwendet werden.

Jetzt, da einige Registries konfiguriert sind, können wir zum nächsten Abschnitt übergehen und mit Podman nach Images suchen.

Die Suche von Container-Images mit Podman

Mit folgendem Kommando durchsucht man die konfigurierten Registries nach einem Image für ‚debian‘:

$ podman search debian
INDEX      NAME                                                        DESCRIPTI
ON                                      STARS   OFFICIAL  AUTOMATED
docker.io  docker.io/library/debian                                    Debian is
 a Linux distribution that's compos...  4036    [OK]      
docker.io  docker.io/smartentry/debian                                 debian wi
th smartentry                           6                 [OK]
docker.io  docker.io/library/ubuntu                                    Ubuntu is
 a Debian-based Linux operating sys...  12971   [OK]
[Ausgabe gekürzt]

Auf meinem System lieferte die Suche nach ‚debian‘ 271 Treffer zurück. Die Ausgabe wurde zur besseren Übersicht gekürzt. In der Spalte ‚INDEX‘ findet sich der Name der Registry, aus der ein Suchergebnis stammt, gefolgt von der Spalte ‚NAME‘, welche den Namen des gefundenen Repositorys enthält. Nutzer können für einzelne Repos Sterne vergeben, wenn sie diese besonders toll finden. Dies wird in der Spalte ‚STARS‘ ausgedrückt.

Laut Manpage podman-search(1) drückt ein „[OK]“ in Spalte ‚OFFICIAL‘ aus, dass es sich hierbei um ein offizielles Image handelt. Mir ist Stand heute noch unklar, wer diesen Status in den einzelnen Registries vergibt. Er ist in meinen Augen mit etwas Vorsicht zu genießen.

Die Spalte ‚AUTOMATED‘ gibt an, ob das Image automatisiert erstellt wurde und ‚DESCRIPTION‘ sollte selbsterklärend sein.

Die Suche bietet einige Filtermöglichkeiten. So kann man mit folgender Suche nach offiziellen Images filtern:

$ podman search --filter is-official debian
INDEX      NAME                      DESCRIPTION                                      STARS   OFFICIAL  AUTOMATED
docker.io  docker.io/library/debian  Debian is a Linux distribution that's compos...  4036    [OK]      
docker.io  docker.io/library/ubuntu  Ubuntu is a Debian-based Linux operating sys...  12971   [OK]

Damit ist die Ausgabe schon übersichtlicher, viele Informationen bietet sie allerdings nicht. Der folgende Abschnitt zeigt eine Möglichkeit auf, sich etwas mehr Informationen zu verschaffen.

Die Inspektion von Remote-Repos mit Skopeo

Mit skopeo können aus dem Terminal heraus weitere Informationen über ein Remote-Repo abgerufen werden, z.B. für den ersten Suchtreffer von oben:

skopeo inspect docker://docker.io/library/debian

Die Ausgabe obigen Kommandos wird hier stark gekürzt dargestellt. Neben dem Namen befinden sich darin u.a. Informationen zu vorhandenen Tags, das Erstellungsdatum, Layer und Angaben zum Environment:

{
    "Name": "docker.io/library/debian",
    "Digest": "sha256:4d6ab716de467aad58e91b1b720f0badd7478847ec7a18f66027d0f8a3
29a43c",
    "RepoTags": [
        "10.11",
[...]
       "bookworm-20211011",
        "bookworm-20211011-slim",
        "bookworm-backports",
        "bookworm-slim",
        "bullseye",
        "bullseye-20190708",
        "bullseye-20190708-slim",
        "bullseye-20190812",
        "bullseye-20190812-slim",
        "bullseye-20190910",
[...]
        "bullseye-20211011",
        "bullseye-20211011-slim",
        "bullseye-backports",
        "bullseye-slim",
        "buster",
[...]        
    ],
    "Created": "2021-10-12T01:20:30.89167925Z",
    "DockerVersion": "20.10.7",
    "Labels": null,
    "Architecture": "amd64",
    "Os": "linux",
    "Layers": [
        "sha256:bb7d5a84853b217ac05783963f12b034243070c1c9c8d2e60ada47444f3cce04
"
    ],
    "Env": [
        "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ]
}

Probiert dieses Kommando ruhig einmal selbst aus und blättert durch die sehr umfangreiche Tag-Liste. Hier wird deutlich, dass es sich um ein Repository und nicht um ein einzelnes Image handelt. Neben Bullseye lassen sich hier noch Images für Buster, Stretch, Jessie und weitere herunterladen.

Ich selbst verwende skopeo primär, um mir einen Überblick über die verfügbaren Tags zu verschaffen, um darüber das für mich am besten geeignete Image auswählen zu können.

An dieser Stelle sei darauf hingewiesen, dass zu den meisten Repos eine Webseite existiert, auf der sich weitere Informationen zu einem Repo bzw. Image finden lassen. Hier finden sich oft auch Hinweise, wie ein Image bei der Instanziierung zu parametrisieren ist.

Es braucht dann leider doch mehr als ein Werkzeug, um einen guten Überblick zu bekommen.

Anmeldung an einer Container-Registry

Bisher wurde in diesem Tutorial nur die frei zugängliche Registry „docker.io“ verwendet. Neben dieser existieren noch viele weitere Registries. Auf einige davon darf man erst nach erfolgreicher Authentifizierung zugreifen bzw. sind einige Inhalte erst nach erfolgreicher Authentifizierung zugänglich.

Meist muss man sich zuerst über die Webseite einer Registry registrieren, um Zugangsdaten zu erhalten, welche man dann im Terminal verwenden kann.

$ podman login quay.io
Username: alice
Password:
Login Succeeded!

Vorstehender Code-Block zeigt ein einfaches Beispiel für einen Login-Vorgang. Die Manpage podman-login(1) verrät, dass Benutzername und Passwort base64-codiert in der Datei ${XDG_RUNTIME_DIR}/containers/auth.json gespeichert werden. Dabei löst ${XDG_RUNTIME_DIR} zu /run/user/ auf, welches von der entsprechenden UID und Prozessen mit root-Rechten zugreifbar ist.

Hinweis: Bei Base64-Codierung handelt es sich um keine Sicherheitsfunktion, zum Schutz der Zugangsdaten. Diese werden quasi als Klartext gespeichert.

Die Zugangsdaten werden in der Datei auth.json gespeichert, bis man sich wieder abmeldet (z.B. mit podman logout) oder der Host neu gestartet wird. Weitere Informationen dazu bieten die Manpages podman-login(1) und containers-auth.json(5).

Den Download (Pull) von Container-Images mit Podman

Der folgende Befehl zeigt, wie das Container-Image für Debian Bullseye aus dem Repo ‚debian‘ der Registry ‚docker.io‘ heruntergeladen wird:

$ podman pull docker.io/library/debian:bullseye
Trying to pull docker.io/library/debian:bullseye...
Getting image source signatures
Copying blob bb7d5a84853b done  
Copying config f776cfb21b done  
Writing manifest to image destination
Storing signatures
f776cfb21b5e06bb5b4883eb15c09ab928a411476b8275293c7f96d09b90f7f9

Das Image wird im lokalen Image-Speicher abgelegt. Dieser befindet sich bei Rootless-Podman unterhalb von .local/share/containers/storage/overlay-images/. Die lokal gespeicherten Images kann man sich mit dem folgenden Kommando auflisten lassen:

$ podman images
REPOSITORY                TAG       IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8  latest    b1e63aaae5cf  7 days ago   233 MB
docker.io/library/debian         bullseye  f776cfb21b5e  3 weeks ago  129 MB

Auf meinem Beispielsystem existiert aktuell nur das soeben heruntergeladene Debian-Image sowie ein UBI8-Image.

Container starten, stoppen und entfernen mit Podman

An dieser Stelle möchte ich in Erinnerung bringen, dass es sich bei Linux-Containern um zustandslose Prozesse handelt, welche in Kernel-Namespaces ausgeführt werden. Für wen dies eine völlig neue Erkenntnis ist, der sei auf die Artikel unter 3, 4 und 5 verwiesen.

In den folgenden Unterpunkten führe ich noch einige wenige Beispiele exemplarisch auf. Für weitere Optionen sie auf die Manpage podman(1) verwiesen, welche einen Überblick über allgemeine Optionen und Verweise zu verfügbaren Podman-Kommandos bietet.

Befehl in einem Container ausführen

Dieses Beispiel zeigt, wie ein Container von einem lokal gespeicherten Image instanziiert wird, einen einzigen Befehl ausführt, dessen Ausgabe nach STDOUT schreibt und danach beendet und entfernt wird:

$ podman run --rm ubi8 cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.4 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.4 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8.4:GA"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.4
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.4"

Der Container existierte nur für die Zeit, die zur Ausführung des Befehls cat /etc/os-release erforderlich war. Die Ausgabe lässt erkennen, dass das Image ubi8 ein Userland aus RHEL 8.4 bereitstellt.

Einen Dienst in einem Container starten

Möchte man einen Dienst in einem Container laufen lassen, so gibt es dafür die Option ‚-d‘, mit welcher man den Container im Hintergrund startet. Ich demonstriere dies an einem kleinen Webserver:

$ podman run -d -p 8080:80 httpd
✔ docker.io/library/httpd:latest
Trying to pull docker.io/library/httpd:latest...
Getting image source signatures
Copying blob 462e88bc3074 done  
Copying blob 21d69ac90caf done  
Copying blob ca52f3eeea66 done  
Copying blob 7d63c13d9b9b done  
Copying blob 448256567156 done  
Copying config 1132a4fc88 done  
Writing manifest to image destination
Storing signatures
3893630d276a7bfb4a3d8c74c5be8ad353b82c1f45081dec0d31b599a5856944

Da noch kein Image für ‚httpd‘ im lokalen Image-Speicher existiert, wird dieses automatisch heruntergeladen. Mit der Option -p 8080:80 wird der TCP-Port 8080 des Host-Betriebssystems mit dem Port 80 des Containers verknüpft.

Folgender Code-Block zeigt, dass nun ein einfacher Webserver läuft, welcher die Standard-HTML-Seite „It works!“ ausliefert:

$ curl http://localhost:8080
<html><body><h1>It works!</h1></body></html>

Der Container läuft, bis er durch einen Neustart des Betriebssystems oder manuell durch den Benutzer beendet wird.

Container stoppen

Um einen im Hintergrund laufenden Container zu stoppen, wird zunächst dessen ID benötigt. Diese ist in der ersten Spalte der Ausgabe des Kommandos podman ps enthalten:

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS            PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  16 minutes ago  Up 2 minutes ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Gestoppt wird der Container mit folgendem Befehl:

$ podman container stop 3893630d276a
3893630d276a7bfb4a3d8c74c5be8ad353b82c1f45081dec0d31b599a5856944

Es wird die vollständige ID des Containers ausgegeben. Diese kann genutzt werden, um den Container zu entfernen (podman rm ID) oder um ihn wieder zu starten (podman start ID).

Wird ein Container nur gestoppt, bleibt seine Konfiguration erhalten, sodass er mit den gleichen Optionen wieder gestartet werden kann. Eine Übersicht über gestoppte oder anderweitig beendete Container bietet das folgende Kommando:

$ podman ps --all
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS                     PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  13 minutes ago  Exited (0) 16 seconds ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Die Verwaltung von Container-Prozessen und -Images

Eine Übersicht über laufende Container bietet das folgende Kommando:

$ podman ps
CONTAINER ID  IMAGE                           COMMAND           CREATED         STATUS            PORTS                 NAMES
3893630d276a  docker.io/library/httpd:latest  httpd-foreground  16 minutes ago  Up 2 minutes ago  0.0.0.0:8080->80/tcp  optimistic_visvesvaraya

Möchte man einen Container entfernen, so geschieht dies mit dem Kommando podman rm ID. Dabei wird nur die Konfiguration des Containers entfernt, nicht das lokal gespeicherte Image. Folgender Code-Block verdeutlicht dies:

$ podman rm 4476cb9d7eec939281abfe0b12bdb8f2083154dbfbc138492b811e0389ad5bfa
4476cb9d7eec939281abfe0b12bdb8f2083154dbfbc138492b811e0389ad5bfa

$ podman ps --all
CONTAINER ID  IMAGE   COMMAND  CREATED  STATUS  PORTS   NAMES

$ podman images
REPOSITORY                       TAG       IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8  latest    b1e63aaae5cf  7 days ago   233 MB
docker.io/library/httpd          latest    1132a4fc88fa  11 days ago  148 MB
docker.io/library/debian         bullseye  f776cfb21b5e  3 weeks ago  129 MB

Möchte man auch das Image entfernen, so geschieht dies mit folgendem Befehl:

$ podman rmi b1e63aaae5cf
Untagged: registry.access.redhat.com/ubi8:latest
Deleted: b1e63aaae5cffb78e4af9f3a110dbad67e8013ca3de6d09f1ef496d00641e751

Bei ‚b1e63aaae5cf‘ handelt es sich um die Image-ID, welche in der Ausgabe von podman images zu sehen ist.

Die persistente Speicherung von Daten in Podman-Volumes

Container sind, wie bereits erwähnt, zustandslose Objekte. Möchte man Daten persistent speichern, können dafür sogenannte Podman-Volumes verwendet werden.

So ist es bspw. möglich, ein Verzeichnis vom Host in einen Container hinein zu mounten. Schreibt der Container-Prozess nun Daten in diesem Mountpoint, bleiben diese erhalten, nachdem der Container gelöscht wurde. Sie können später in eine neue Container-Instanz hinein gemountet werden.

Beispiel: Verzeichnis vom Host in Container einhängen

Im folgenden Code-Block wird ein Verzeichnis im HOME-Verzeichnis eines normalen Nutzers erstellt und anschließend in einen Container eingehängt. Der Einhängepunkt im Container muss dabei bereits im Container-Image existieren. Der Container erstellt eine Datei namens TEST in diesem Volume. Anschließend wird der Container beendet und entfernt. Die erstellte Datei befindet sich weiterhin in dem Verzeichnis auf dem Host.

$ mkdir testdir
$ podman run --rm -v ~/testdir:/tmp:Z debian touch /tmp/TEST
$ ls -l testdir/
total 0
-rw-r--r--. 1 alice alice 0  7. Nov 14:01 TEST

Die Option ‚Z‘ sorgt dafür, dass der SELinux-Datei-Kontext für das Verzeichnis korrekt gesetzt wird, sodass der Container auf dieses Volumen zugreifen kann. Für weitere Details siehe Option ‚-v‘ in podman-run(1).

Podman-Volume erstellen und einhängen

Mit podman-volume(1) stellt Podman ein einfaches Verwaltungswerkzeug für Podman-Volumes zur Verfügung. Folgendes Code-Beispiel zeigt, wie mit podman-volume-create(1) ein Volume mit einem eindeutigen Beizeichner (testdir2) erstellt wird. Anschließend wird dieses, wie im vorangehenden Beispiel, in einen Container eingehängt und die Datei TESTDATEI hineingeschrieben.

$ podman volume create testdir2
testdir2
$ podman run --rm -v testdir2:/tmp:Z debian touch /tmp/TESTDATEI

Doch wo findet man nun die TESTDATEI außerhalb des Containers wieder? Wo befindet sich der Speicherort des zuvor erstellten Volumes ‚testdir2‘? Auskunft darüber gibt das Kommando podman volume inspect VOLUMENAME:

$ podman volume inspect testdir2
[
    {
        "Name": "testdir2",
        "Driver": "local",
        "Mountpoint": "/home/alice/.local/share/containers/storage/volumes/testdir2/_data",
        "CreatedAt": "2021-11-07T14:39:56.557400855+01:00",
        "Labels": {},
        "Scope": "local",
        "Options": {}
    }
]

Der Schlüssel Mountpoint gibt den Volume-Pfad an. Und tatsächlich findet sich dort die TESTDATEI:

$ ls -l /home/alice/.local/share/containers/storage/volumes/testdir2/_data
total 0
-rw-r--r--. 1 alice alice 0  7. Nov 14:40 TESTDATEI

Die TESTDATEI gehört Alice, welche den Container-Prozess gestartet hat. Möchte man den Inhalt eines Volumes sichern, kann man die enthaltenen Verzeichnisse und Dateien mit bekannten Mitteln kopieren oder mittels podman-volume-export(1) in ein TAR-Archiv verpacken:

$ podman volume export testdir2 -o testdir2.tar

Benötigt man das Volume nicht mehr, kann man es inkl. seines Inhalts mit dem folgenden Befehl löschen:

$ podman volume rm testdir2
testdir2

Möchte man sich die existierenden Volumes anzeigen lassen, gelingt dies mit dem folgenden Befehl:

$ podman volume ls
DRIVER      VOLUME NAME
local       vol1
local       vol2
local       vol3

Der Spalte DRIVER ist zu entnehmen, dass alle diese Volumes im lokalen Dateisystem gespeichert sind. Über weitere Storage-Backends kann ich an dieser Stelle leider noch keine Aussage treffen, da mir hierzu noch das notwendige Wissen fehlt.

Zum Abschluss dieses Abschnitts noch der Befehl, mit dem sich alle ungenutzten Volumes entfernen lassen:

Achtung: Bei folgendem Kommando ist Vorsicht geboten. Ein genauer Blick darauf, welche Volumes entfernt werden sollen, lohnt sich. Andernfalls droht Datenverlust.

$ podman volume prune
WARNING! This will remove all volumes not used by at least one container. The following volumes will be removed:
vol1
vol2
vol3
Are you sure you want to continue? [y/N] y
vol1
vol2
vol3

An dieser Stelle möchte ich den kurzen Überblick über die Podman-Volume-Befehle beenden. Wer sich weitergehend damit auseinandersetzen möchte, findet über die Manpage podman-volume(1) einen guten Einstieg.

Fazit

Am Ende dieses Tutorials sollte man in der Lage sein, Rootless-Podman auf Debian Bullseye einzurichten. Mit ein wenig Abstraktionsvermögen sollte dies auch auf weiteren Distributionen gelingen.

Die grundlegenden Befehle zur Bedienung und Nutzung wurden kurz vorgestellt, sodass man nun über das nötige Wissen verfügt, die ersten eigenen Schritte mit dieser noch recht jungen Technologie zu unternehmen.

Für eure ersten Versuche mit Podman wünsche ich euch viel Spaß und Erfolg.

Quellen und weiterführende Links

  1. RHEL 8 Building, running, and managing containers. Chapter 1.5. Upgrading to rootless containers URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/assembly_starting-with-containers_building-running-and-managing-containers#proc_upgrading-to-rootless-containers_assembly_starting-with-containers
  2. How to manage Linux container registries. Valentin Rothberg (Red Hat). Enable Sysadmin. 2021-02-16.
  3. Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters; [Scott McCarty (fatherlinux)}(https://www.redhat.com/en/authors/scott-mccarty-fatherlinux); July 29, 2015
  4. Architecting Containers Part 2: Why the User Space Matters; Scott McCarty (fatherlinux); September 17, 2015
  5. Architecting Containers Part 3: How the User Space Affects Your Application; Scott McCarty (fatherlinux); November 10, 2015
  6. Beginn der Artikelserie „Kanboard im Container…“; My-IT-Brain; Jörg Kastning; 2021-01-04

Raspberry Pi OS Bullseye

09. November 2021 um 15:45

Die Raspberry Pi Foundation hat eine neue Raspberry-Pi-OS-Version auf der Basis von Debian Bullseye freigegeben. Damit ändert sich Einiges: Zum einen natürlich eine Menge Versionsnummern dank des modernisierten Debian-Unterbaus, zum anderen aber auch durchaus wichtige technische Details. Z.B. verwendet Rasbperry Pi OS nun standardmäßig GTK3 und den Displaymanager Mutter — zumindest auf Rechnern mit 2 GByte. Aber der Reihe nach …

Update 7.12.2021: Die alte Raspberry-Pi-OS-Version (Buster) wird bis auf Weiteres mit Updates versorgt und erhält die Bezeichnung Legacy. Damit wird niemand zum Update auf die neue Version (Bullseye) gezwungen. Mehr Details können Sie im Blog von raspberrypi.com nachlesen.

Der PIXEL-Desktop von Raspberry Pi OS

Desktop

Auf dem Desktop gibt es nur wenige optische Änderungen:

  • Hinweise (Notifications) werden jetzt am rechten Bildschirmrand angezeigt. Diese Funktion kann bei Bedarf deaktiviert werden. Dazu öffnen Sie im Panel das Kontextmenü und führen Leisten-Einstellungen / Erscheinungsbild aus.
  • Zu den neuen Notifications zählt auch der Hinweis auf anstehende Updates. Ein Klick auf den Hinweis öffnet einen neuen, grafischen Update-Manager.

  • Im Dateimanager gibt es nur mehr zwei Darstellungsmodis: die Icon- und die Listenansicht.

Raspberry Pi OS hat jetzt einen grafischen Update-Dialog

Grafiksystem und Gtk

Der erste Eindruck täuscht aber. Hinter den Kulissen hat sich wesentlich mehr verändert als an der Oberfläche:

  • Für die Aktivierung des richtigen Grafikmodus ist jetzt der Kernel zuständig (Kernel Mode Setting, KMS). Dabei kommen offizielle Funktionen des Kernels zum Einsatz, nicht mehr wie bisher Raspberry-Pi-spezifische Funktionen, deren Code nicht öffentlich war (Quelle raspberrypi.com).
  • Raspberry Pi OS verwendet nun standardmäßig GTK3-Bibliotheken (bisher GTK2). Das vereinfacht die Realisierung optischer Effekte (z.B. abgerundeter Fensterecken). Viel wichtiger ist aber: GTK2 ist eine veraltete, nicht mehr aktiv gewartete Bibliothek. Immer mehr moderne Programme setzen GTK3 voraus. Insofern war der Umstieg auf GTK3 überfällig.

  • Auf Raspberry Pis mit zumindest 2 GByte RAM kommt der Fenstermanager Mutter zum Einsatz (bisher openbox). Auch hier gilt: Mutter ist moderner, zukunftssicherer. Bie Raspberry Pi Organisation bezeichnet den Umstieg auf Mutter als den ersten Schritt hin zur Ablöse von X durch Wayland. Einen konkreten Zeitplan für den Wechsel zu Wayland gibt es allerdings noch nicht, und es ist unklar, ob dieser überhaupt möglich ist. Selbst Mutter braucht so viel RAM, dass es nur auf großzügig mit RAM ausgestatteten Geräten zum Einsatz kommt.

Kamera-Software

In bisherigen Raspberry-Pi-OS-Versionen waren proprietäre Software-Treiber und die Programme raspistill und raspivid zuständig, um Fotos bzw. Videos von der Kamera aufzunehmen. Mit dem neuen Raspberry Pi OS wird die Kamera dagegen über die libcamera-Treiber des Kernels angesprochen. Dass im Zuge dieser Umstellung raspistill und raspivid einfach eliminiert wurden, wird viele Scripts vor Kompatibilitätsprobleme stellen. Ja, es gibt mit libcamera-still und libcamera-vid neue Kommandos, diese haben aber komplett andere Optionen. Dokumentation dazu finden Sie hier:

https://www.raspberrypi.com/documentation/accessories/camera.html#libcamera-and-libcamera-apps

Aus dem Konfigurationsprogramm ist die Option zur Kamerakonfiguration verschwunden. Dafür enthält /boot/config.txt jetzt den Parameter camera_auto_detect=1, der sich um die automatische Treiberkonfiguration kümmern soll. Tests zur Nutzung der Kamerafunktionen reiche ich später in einem eigenen Artikel nach, sobald ein neues Kameramodul bei mir eintrifft. Das alte hat überraschend seinen Geist aufgegeben.

Update 11.11.2021: Mittlerweile habe ich auch die neuen libcamera-Tools kurz dokumentiert:

https://pi-buch.info/fotos-und-videos-mit-den-libcamera-tools-aufnehmen

Versionsnummern

Viel getan hat sich bei den Versionsnummern des Software-Stacks. Die wichtigste Änderung für viele Raspberry-Pi-Anwender betrifft Python: Erstmals steht die veraltete Version 2 nicht mehr zur Verfügung. Das Kommando python startet nun Python 3.9 statt Python 2.7. Es ist zu befürchten, dass das bei vielen alten Programmen/Bibliotheken zu Problemen führt. Wirklich überrascht sollte aber keiner sein — vor dem Ende von Python 2 wurde ein Jahrzehnt lange gewarnt.

Basis             Desktop              Programmierung   Server
---------------   ------------------   --------------   --------------
Kernel     5.10   Chromium        92   bash       5.1   Apache     2.4
glibc      2.31   Gimp          2.10   gcc       10.2   CUPS       2.3
X-Server   1.20   LibreOffice    7.0   Java        11   MariaDB   10.5
Mesa       20.3   LXDE            11   PHP        7.4   OpenSSH    8.4
Systemd     247   VLC            3.0   Python     3.9   Samba     4.13

Die »Black-Screen-Edition«?

Ich hatte bei meinen Tests massive Probleme mit meinen Monitoren. Immer wieder passierte es, dass meine Monitore nach einer kurzen Darstellung des Raspberry-Pi-Logos einfach schwarz blieben. In allen Fällen lief der Raspberry Pi, d.h. eine SSH-Verbindung war möglich. Die Monitore erhielten offenbar auch ein Signal, d.h. sie wechselten nicht wie sonst automatisch in den Stand-by-Modus oder schalteten sich aus.

Für meine Tests habe ich einen Pi 4B der ersten Generation (1 GB RAM) sowie ein Modell 400 verwendet. Als Monitore kamen ein moderner LG-4k-Monitor (Modell 27UL850-W) sowie ein uralter Benq-Monitor (G2400-WT) zum Einsatz.

Dass während des Bootprozesses keine Meldungen des Kernels bzw. von systemd angezeigt werden, ist beabsichtigt, auch wenn ich mir nicht sicher bin, dass das eine gute Idee ist. Abhilfe: Entfernen Sie quiet splash aus der Datei /boot/cmdline.txt. Eine echte Lösung des Problems ist dies aber nicht: Während der ersten Sekunden sind nun diverse Meldungen sichtbar. Danach wird der Monitor schwarz. Eine Weile später (nach ca. 10 bis 15 Sekunden) erscheint der Desktop — oder auch nicht.

Manchmal half es, den Monitor einfach kurz aus und wieder ein zu schalten.

Sicher ist, dass die Probleme mit dem neuen Raspberry Pi OS zu tun haben; ich habe die gleiche Hardware auch schon mit der vorigen Version des Betriebssystems verwendet und hatte nie derartige Probleme. Trotzdem bleibt unklar, ob die Fehler nur spezifisch bei meiner Hardware auftreten oder ob auch andere Raspberry-Pi-Anwender betroffen sind. Ein diesbezüglicher Twitter-Post erhielt kaum Resonanz.

Problematisch ist in diesem Zusammenhang auch die Veränderung der Bildschirmauflösung: Bei Systemen mit 2 GB RAM oder mehr (also Gtk3) wird die Änderung erst nach einem Reboot wirksam. Das ist nicht nur unpraktisch, sondern auch äußerst problematisch, wenn die gewählte Auflösung am Bildschirm nicht angezeigt werden kann. Mit Pech bleibt der Bildschirm dann ganz einfach schwarz — ohne eine einfache Möglichkeit, die Änderung der Auflösung rückgängig zu machen. Definitiv nicht benutzerfreundlich!

Wenn »Mutter« als Window Manager läuft (auf allen Pis mit 2 GByte RAM oder mehr), erfordert der Wechsel der Bildschirmauflösung einen Neustart mit ungewissem Ausgang

Abhilfe schafft dann nur die Veränderung der Datei /home/pi/.config/monitors.xml via SSH oder auf einem zweiten Linux-Rechner. (Unter macOS oder Windows können Sie auf direkt auf der SD-Karte auf die Partition mit dem Linux-Dateisystem ja gar nicht zugreifen.)

Ich kann mich nicht erinnern, wann ich zuletzt so viel Zeit damit vergeudet habe, um einfach nur ein Bild am Monitor zu sehen. Meine Vermutung ist, dass der ganze Ärger mit dem neuen Kernel Mode Switching (KMS) zu tun hat, das in Raspberry Pi OS Bullseye erstmals aktiv ist und möglicherweise noch nicht in allen Fällen perfekt funktioniert. (Grundsätzlich ist KMS natürlich eine gute Sache: Es ermöglicht einen flicker-freien Bootprozess und erleichtert die Nutzung der Grafikfunktionen ohne Closed-Source-Treiber.)

Sonstiges

  • Bei RP-Modellen ab 2 GByte RAM ist eine Drehung der Bildschirmdarstellung nicht mehr möglich (z.B. für einen Monitor in Portrait-Modus). Laut der Diskussion auf raspberrypi.com liegt das Problem beim Window Manager Mutter.
  • Auch die neue Raspberry-Pi-OS-Version verbleibt in der 32-Bit-Welt. Eine 64-Bit-Version wäre möglich, aber die Entwickler sehen keine großen Performance-Vorteile. Außerdem würde eine 64-Bit-Version zwei unterschiedliche Betriebssystemversionen je nach CPU erfordern. (Nur die aktuellen Raspberry-Pi-Modelle haben eine 64-Bit-CPU.) Wer also Docker oder ähnliche Funktionen am Raspberry Pi mit einem 64-Bit-Stack ausführen muss, ist mit alternativen Betriebssystemen wie Ubuntu besser bedient.

  • Die CPUs auf aktuelle Raspberry-Pi-Modelle mit 2, 4 oder 8 GByte erreichen nun automatisch eine Taktfrequenz von 1,8 GHz. Voraussetzung dafür ist die auf den neuen Platinen integrierte Switch-mode Power Supply (Quelle: raspberrypi.com).

  • Die Raspberry Pi Foundation rät dringend davon ab, ein Update von Raspberry Pi OS Buster auf die neue Bullseye-Edition zu versuchen — und ich schließe mich diesem Ratschlag an. Grundsätzlich ist so ein Update relativ einfach möglich, in dem Sie in /etc/atp/sources.list jeweils buster durch bullseye ersetzen und dann ein Update aller Pakete durchführen. (So ein Update ist zeitaufwändig — rechnen Sie zumindest mit 30 Minuten, während der Sie immer wieder Rückfragen beantworten müssen.) Aufgrund der vielen grundlegenden Änderungen zwischen den beiden Versionen sind Kompatibilitätsprobleme zu erwarten. Deswegen ist es sicherlich vernünftig, ein Backup aller relevanten Dateien durchzuführen und dann (idealerweise auf eine zweite SD-Karte) die neue Version von Raspberry Pi OS zu installieren.

Fazit

Viele technische Änderungen, die zusammen mit dem Umstieg auf die neue Basis Debian Bullseye durchgeführt wurden, sind aus Open-Source-Sicht erfreulich: Es kommen mehr Open-Source-Treiber als bisher zum Einsatz, Raspberry Pi OS ist näher an Linux-Standards und es gibt sogar einen (vager) Ausblick Richtung Wayland.

Zumindest bei meinen Tests sind allerdings auch erhebliche Probleme aufgetreten. (Ich habe natürlich auch andere Tests gelesen. Deren Autoren hatten offenbar weniger Probleme. Vielleicht liegt es an mir oder an meiner Hardware?)

Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate abwarten, bevor Sie auf das neue Raspberry Pi OS Bullseye umsteigen.

Quellen, Links

Download der aktuellen Version (Bullseye) und der alten Legacy-Version (Buster):

Beschreibung von libcamera-Kommandos:

Bullseye-Bonus: Raspberry Pi 4 auf 1.8 GHz aufgebohrt

09. November 2021 um 13:44
Von: jdo

Gestern wurde das erste Raspberry-Pi-Abbild veröffentlicht, das auf Debian 11 Bullseye basiert. Wer einen Raspberry Pi 4 mit mindestens 2 GByte RAM hat, darf sich über eine neue Desktop-Umgebung freuen, die mit Mutter läuft. Nun hat das Entwickler-Team verraten, dass es noch einen Tweak gibt. Bei neueren Raspberry Pis ist nun der Turbo-Takt-Modus von 1.5 GHz auf 1.8 GHz gestiegen, wie das beim Raspberry Pi 400 der Fall ist. Allerdings gilt das nicht für alle Geräte. Hat Dein Raspberry Pi […]

Der Beitrag Bullseye-Bonus: Raspberry Pi 4 auf 1.8 GHz aufgebohrt ist von bitblokes.de.

Raspberry Pi OS auf Debian Bullseye aktualisiert

09. November 2021 um 11:27

Das Raspberry Pi OS hat seinen Debian-Unterbau auf die im August veröffentlichte Version Debian Bullseye aktualisiert. Damit erfahre das Raspberry Pi OS eine Reihe von signifikanten Änderungen an der Desktop-Umgebung und der Unterstützung für Raspberry Pi Hardware, schreibt Software-Entwickler Simon Long.

Eine dieser Änderungen ist der Umstieg auf GTK+ in Version 3. Damit nutzten alle Desktop-Komponenten und – Anwendungen nun GTK+3, schreibt Long. Bis jetzt habe der größte Teil des Desktops Version 2 des GTK+-Toolkits verwendet, jetzt aber bauten immer mehr Debian-Anwendungen auf GTK+3. Um die Dinge konsistent zu halten, habe das Raspberry-OS-Team die gesamte Software und den Desktop selbst auf die neuere Version aktualisiert, teilt Long mit.

Eine weitere Änderung, die mit der Umstellung auf GTK+3 einhergehe, sei die Verwendung von Mutter als neuen Fenstermanager anstelle von Openbox. Mutter biete unter anderem nette Animationen beim Öffnen und Schließen von Fenstern und Schattierungen, wodurch der Desktop insgesamt moderner wirke.

Allerdings gebe es auch Nachteile. Einer davon sei, dass Mutter den gesamten Bildschirm in den Speicher zeichne, bevor es ihn anzeige, was viel Arbeitsspeicher benötige. Mutter laufe deshalb nur auf einem Raspberry Pi mit 2 GByte oder mehr flüssig. Auf Raspberry Pis mit weniger als 2 GByte komme deshalb immer noch der ältere Fenstermanager Openbox zum Einsatz.

Benachrichtigungen lassen sich über die Einstellungen konfigurieren.

Neru ist auch ein Benachrichtigungsmanager, der von der Taskleiste und allen ihren Plugins verwendet werden könne, berichtet Long weiter. Auch über andere Anwendungen könne darauf zugegriffen werden. Die Benachrichtigungen seien dann in der oberen rechten Ecke des Fensters in chronologischer Reihenfolge zu sehen.

In seiner Ankündigung nennt Simon Long weitere neuen Features von Raspberry Pi OS.

Der Beitrag Raspberry Pi OS auf Debian Bullseye aktualisiert 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.

Redo Rescue 4.0.0 steigt auf Debian 11 um

13. Oktober 2021 um 09:31

Das Live-System Redo Rescue hilft beim Erstellen von Backups und deren Wiederherstellung. Die neue Version 4.0.0 bietet nur eine wesentliche Neuerung: Den Unterbau stellt ab sofort Debian 11 (Bullseye).

Alle Funktionen und die leicht zu bedienende grafische Benutzeroberfläche haben sich nicht geändert. Durch den deutlich aktuelleren Kernel unterstützt Redo Rescue allerdings deutlich mehr Hardwarekomponenten. Vor allem die Benutzeroberfläche soll jetzt auf den meisten Rechnern direkt starten.

Die im Zuge des Umstiegs auf Debian 11 erneuerten Pakete der essentiellen Werkzeuge wie Partclone und Sfdisk könnten jedoch einige deutliche Unterschiede zur alten Redo-Rescue-Version aufweisen. Darauf weisen die Entwickler explizit in ihrer Ankündigung auf GitHub hin.

Der Beitrag Redo Rescue 4.0.0 steigt auf Debian 11 um erschien zuerst auf Linux-Magazin.

Debian 11.1 – Erstes Point-Release für Bullseye

11. Oktober 2021 um 09:53

Das Debian-Projekt hat ein erstes Point-Release für seine Linux-Distribution Debian 11 alias Bullseye veröffentlicht. Es enthält eine Vielzahl von Bugfixes und Sicherheitsupdates.

Mit Debian 11.1 gehen laut den Entwicklern keine neuen Features einher. Zu den vielen gelösten Problemen in dieser Version zählen aber ernsthafte Sicherheitslücken und auch bei den Bugfixes finden sich Lösungen für dickere Brocken. Zu den beseitigten Problemen zählen mögliche Einfallstore für Denial-of-Service-Attacken und Speicherfehler in vielen verschiedenen Paketen der Distribution, etwa in Fetchmail, Clamav und Cyrus-Imapdb.

Sicherheitsupdates gab es etwa für Thunderbird, Firefox, OpenSSL, Ghostscript, Xen und Mediawiki. Daneben sind auch Sicherheitsproleme angegangen worden, für die es kein eigenes Debian Security Advisory (DSA) gegeben hat. Die Pakete Apache2, Lynx, Tomcat9 und Nodejs zählen dazu.

Der Debian-Installer ist auf das Einspielen der Fixes angepasst worden. Wer regelmäßig die Updates von security.debian.org einspielt, müsse nur wenige Pakete installieren, teilen die Entwickler mit. Es ließen sich auch die alten Installationsmedien von Bullseye verwenden, die Updates seien dann über einen der Mirror von Debian zugänglich. Dennoch wird Debian in Kürze für Neueinsteiger die Installationmedien auf Version 11.1 anpassen und zum Download anbieten.

Der Beitrag Debian 11.1 – Erstes Point-Release für Bullseye erschien zuerst auf Linux-Magazin.

Debian Linux 11.1 veröffentlicht

09. Oktober 2021 um 17:30
Das Debian Projekt hat heute mit Debian GNU/Linux 11.1 ein erste Point-Release der neuesten Debian Linux 11 „Bullseye“-Betriebssystemserie veröffentlicht. Debian 11.1 kommt etwa zwei Monate [...]

Nagios - Icinga: Debian Bullseye check_interfaces schlägt fehl

28. September 2021 um 19:16

icinga-logo

Ein kurzer Tipp fürs Interface Monitoring mit Icinga oder Nagios unter Debian.

Nach einem Update auf Debian Bullseye kann es vorkommen, dass einige Check Plugins fehlschlagen. So geschehen mit check_interfaces.

Das Plugin bringt nur noch folgende Ausgabe:

Plugin-Ausgabe
/usr/lib/nagios/plugins/check_interfaces: error while loading shared libraries: libnetsnmp.so.30: cannot open shared object file: No such file or directory

Zunächst kann man natürlich versuchen, die nötigen Dateien auf anderen Systemen zu suchen oder das Paket libsnmp40 zu installieren, leider bringt dies unnötige Arbeit, bzw. keine Abhilfe.

Die Lösung ist ein einfaches neu builden des Plugins:

debian_bullseye

apt-get update
apt-get -y install git build-essential libsnmp-dev

wget https://github.com/NETWAYS/check_interfaces/archive/refs/tags/v1.4.tar.gz

tar xvf v1.4.tar.gz

cd check_interfaces-1.4/

./configure --libexecdir=/usr/lib/nagios/plugins

make
make install

Der Zielpfad kann natürlich je nach Check Plugin Verzeichnis angepasst werden. Nach dem erneuten Builden unter Debian Bullseye sollte das Plugin wieder ohne Probleme funktionieren.

Finnix 123 basiert auf Bullseye – für Administratoren

07. September 2021 um 08:58
Von: jdo

Die Linux-Distribution Finnix ist eine Live-CD für Systemadministratoren. Finnix 123 ist natürlich so schlank wie seine Vorgänger, basiert allerdings nicht wie üblich auf Debian Testing. Die Veröffentlichung liegt so na an der von Debian 11 Bullseye, dass sich der Entwickler anders entschieden. Es gibt auch neue Pakete und neue Funktionen. Der Entwickler Ryan Finnie fasst das so zusammen: Kernel-KOmmandozeilen-Optionen sshd und passwd wurden hinzugefügt. Beispiel: sshd passwd=foo, sshd passwd=root:foo passwd=finnix:bar Die ID der Maschine wird anhand von DMI erstellt und […]

Der Beitrag Finnix 123 basiert auf Bullseye – für Administratoren ist von bitblokes.de.

Debian 11 »Bullseye«

01. September 2021 um 11:21

Es gibt — wie immer — zwei Sichtweise auf das neue Debian: Die positive (»Das Glas ist halb voll«) Interpretation geht in die Richtung, dass Debian im Vergleich zum letzten Release deutlich moderner geworden ist, teilweise nahezu aktuelle Software-Versionen ausliefert, neue Funktionen bietet — und das für viel mehr Plattformen als bei jeder anderen Linux-Distribution.

Die nicht so euphorische Sichtweise (»Das Glas ist halb leer«) bedauert die im Vergleich zu Fedora oder Ubuntu nicht ganz so aktuelle Software-Ausstattung und das unverändert altmodische Erscheinungsbild des Installationsprogramms. Andererseits erfüllt der Installer seinen Zweck — und wer es gerne moderner hat, kann ja den Calamares-Installer der Live-Medien verwenden.

Das Erscheinungsbild des Debian-Installationsprogramms ist seit vielen Jahren unverändert geblieben.

Bei der Installation stehen diverse Desktop-Systeme zur Auswahl.
Standardmäßig verwendet Debian 11 als Desktopsystem Gnome 3.38.

Neuerungen

Abseits von Versionsnummern gibt es nur wenige grundlegende Neuerungen in Debian 11:

  • Unkomplizierte exFAT-Unterstützung (für große SD-Karten)
  • Treiberloses Drucken/Scannen mit vielen neuen Geräten (dank IPP-over-USB sowie eSCL und WSD)

  • Mit open datei kann aus dem Terminal heraus ein GUI-Programm als Hintergrundprozess geöffnet werden. open Downloads/bild.jpg startet beispielsweise den Bildbetrachter. open ist ausgesprochen praktisch und wird vor allem macOS-Umsteiger erfreuen. (Unter macOS gibt es ein entsprechendes Kommando schon seit vielen Jahren.) Intern ist open einfach ein via updates-alternatives --config open verwalteter Link auf das schon länger etablierte Script xdg-open, das die MIME-Einstellungen auswertet. (Anstelle von xdg-open kann auch run-mailcap eingestellt werden.)

  • Control Groups v2: Die Kernel Control Groups zur Überwachung/Steuerung von Prozessen liegt jetzt in Version 2 vor. Das ist wichtig u.a. für Container-Systeme wie Docker oder Podman. Diese Umstellung kann allerdings Probleme mit OpenStack verursachen (Details).

  • User Namespaces aktiv: Eine Neuerung von Kernel 5.10 besteht darin, dass normale Benutzer User Namespaces verwenden dürfen. Das ist wichtig für Containersysteme (Rootless Docker, Podman).

  • FUSE 3: Die Dateisysteme gvfs-fuse, kio-fuse und sshfs nutzen nun FUSE 3 anstelle der bisher üblichen Version 2.

  • Das von systemd stammende Logging-System Journal wird jetzt dauerhaft im Binärformat in /var/log/journal gespeichert, geht also nicht wie in früheren Debian-Versionen mit jedem Reboot verloren. (Parallel zum Journal läuft weiterhin auch der rsyslogd und erzeugt die traditionellen Text-Logging-Dateien in /var/log.)

  • Passwort-Hashes in der Datei /etc/shadow wurden von SHA-512 auf das sicherere Verfahren yescrypt umgestellt.

Ärgernisse

sudo: Ein wenig irritierend ist, dass der »gewöhnliche« Installer (also nicht der der Live-Medien) nach wie vor keine Möglichkeit bietet, den neuen Benutzer zur sudo-Gruppe hinzuzufügen. Das ist mittlerweile bei fast allen anderen Distributionen das Standardverhalten.

Abhilfe: Führen Sie mit root-Rechten usermod -a -G sudo <accountname> aus, um sudo für den betreffenden Account zu aktivieren.

Bitte legen Sie das Medium mit dem Namen ‚Debian GNU/Linux‘ ein: Der Standardinstaller hinterlässt in /etc/apt/sources.list eine Zeile mit dem Installationsmedium (USB-Stick oder DVD). Wenn Sie nach der Installation ein Paket installieren wollen (apt install <name>), will apt, dass Sie das Installationsmedium wieder einlegen, anstatt das betreffende Paket einfach herunterzuladen. Das ist (schon seit vielen Jahren) nicht mehr zeitgemäß.

Abhilfe: Öffnen Sie /etc/apt/sources.list mit einem Editor und entfernen Sie die Zeile, die mit deb cdrom beginnt.

Cannot set locale en_US.utf-8: Wie aktuell bei diversen anderen Distributionen tritt auch bei Debian ein Problem mit den Lokalisierungseinstellungen ein, wenn während der Installation die deutsche Sprache voreingestellt wird. Nach einem SSH-Login jammert Debian: bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf-8). Es wurde also die deutsche Lokalisierung installiert, nicht aber die englische (die als Backup immer zur Verfügung stehen sollte).

Abhilfe: Führen Sie mit root-Rechten dpkg-reconfigure locales aus und aktivieren Sie zusätzlich zur schon voreingestellten Lokalisierung auch en_US.utf-8.

Die fehlende Lokalisierung »en_US.UTF-8« aktivieren

Versionsnummern

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     5.10   Gnome        3.38   bash       5.1   Apache     2.4
glibc      2.31   Firefox ESR    78   docker   20.10   CUPS       2.3
X-Server   1.20   Gimp         2.10   gcc       10.2   MariaDB   10.5
Wayland    1.20   LibreOffice   7.0   Java     11/17   OpenSSH    8.4
Mesa       20.3   Thunderbird    78   PHP        7.4   qemu/KVM?  5.2
Systemd     247                       Python     3.9   Postfix    3.5
NetworkMan 1.30                                        Samba     4.13
GRUB       2.04 

Der Linux-Kernel ist zwar nicht ganz aktuell, dafür genießt er aber Langzeitunterstützung durch das Kernel-Entwickler-Team.

Die Unterstützung von Java 17 ist insofern bemerkenswert, als die kommende LTS-Version von Java noch gar nicht fertig ist. Indem schon jetzt Pakete mitgeliefert werden, können später (vorauss. im Okt. oder Nov. 2021) unkompliziert Updates installiert werden. Als »offizielle« Java-Version von Bullseye gilt aber Java 11. Die Release Notes weisen darauf hin, dass es für Java 17 voraussichtlich keine quartalsmäßigen Updates geben wird (was schade ist).

Plattformen (Architekturen)

Debian 11 steht für die folgenden Plattformen zur Verfügung:

  • Standard-PCs: i386 und amd64
  • ARM: arm64, armhf, armel
  • MIPS: mipsel, mips64el
  • PowerPC: ppc64el
  • S390X: s390x

Weitere Details zur Hardware-Unterstützung können Sie hier nachlesen:

Fazit

Debian hat einmal mehr ein grundsolides Release geliefert. Sensationen bleiben aus, Glanz und Charme versprüht die Distribution auch nicht. Dafür läuft Debian zuverlässig und stabil und bildet direkt (Ubuntu, Raspberry Pi OS) oder indirekt (Ubuntu Derivate) die Basis für zahlreiche weitere Distributionen. Insofern macht Debian — ohne über ein Budget wie Canonical, IBM/Red Hat oder SUSE zu verfügen — alles richtig. Wer mehr Aktualität sucht, kann den Testing-Zweig verwenden.

Quellen und Testberichte

Download-Links (jeweils für AMD/Intel 64 Bit)

Debian 11 alias Bullseye ist fertig

16. August 2021 um 10:08

Nach exakt zwei Jahren einem Monat und neu Tagen Entwicklungszeit hat das Release-Team Debian 11 mit dem Codenamen Bullseye veröffentlicht. Debian 11 erhält fünf Jahre Support.

Zu den Neuerungen von Debian 11 zählt schon die Auswahl an Desktopumgebungen, zu denen Donald Norwood von Debian in der Ankündigung Gnome 3.38, KDE Plasma 5.20, LXDE 11, LXQt 0.16, MATE 1.24 und Xfce 4.16 zählt. Nach der angen Entwicklungszeit kann Norwood auch mit reinen Zahlen beeindrucken, Bullseye enthalte über 11294 neue Pakete und komme damit auf insgesamt 59551 Pakete. 9519 Pakete seien als veraltet entfernt worden und 42821 Pakete habe man aktualisiert. 5434 Pakete seien unverändert geblieben.

Insgesamt unterstützt Debian 11 neun Architekturen. In Anbetracht seiner Fülle an Paketen und unterstützten Atchitekturen sei Bullseye das universelle Betriebssystem, schreibt Norwood in der Ankündigung. Es sei für viele verschiedene Anwendungsfälle geeignet, von Desktop-Systemen bis zu Netbooks, von Entwicklungsservern bis Clustersystemen und für Datenbank-, Web- und Speicherserver.

Bullseye sei auch die erste Veröffentlichung, die einen Linux-Kernel mit Unterstützung für das exFAT-Dateisystem bereitstellt und standardmäßig zum Einhängen von exFAT-Dateisystemen verwendet werde, teilen die Entwickler mit. Es sei also nicht mehr erforderlich, die Implementierung des Dateisystems im Userspace zu verwenden, die über das Paket exfat-fuse bereitgestellt werde. Werkzeuge zum Erstellen und Überprüfen eines exFAT-Dateisystems seien im Paket exfatprogs verfügbar, heißt es weiter.

 

Dass moderne Drucker meist in der Lage seien, treiberlos zu drucken und zu scannen, ohne auf herstellerspezifische und oft unfreie Treiber zurückgreifen zu müssen, ist auch bei Debian angekommen. Debian 11 bringe ein neues Paket, namens ipp-usb mit, das auf das herstellerneutrale IPP-over-USB-Protokoll setzt, das vielen moderne Druckern unterstützten, so Norwood.

Die Ankündigung verlinkt Informationen zu Download und Installation. Debian 11 kann auch als Live-System ausprobiert werden.

Der Beitrag Debian 11 alias Bullseye ist fertig erschien zuerst auf Linux-Magazin.

Debian 11 Bullseye offiziell erschienen

15. August 2021 um 09:00
Die Entwickler der Linux Distribution Debian haben die allgemeine Verfügbarkeit der lange erwarteten Debian GNU/Linux 11 Bullseye Version bekanntgegeben. Nach mehr als zwei Jahren Arbeit [...]

Debian bringt RC3 von Debian 11 Bullseye und verschiebt den Veröffentlichung auf 14. August 2021

03. August 2021 um 08:15
Die Entwickler der traditionellen Linux Distribution Debian haben den Veröffentlichungstermin von Debian GNU/Linux 11 – Codename Bullseye – von ursprünglich 31. Juli im Rahmen des [...]

Das ist Debian 11 Bullseye – Ein voller Überblick

30. Juli 2021 um 16:00
Debian ist eine der ältesten noch aktiven Linux Distributionen, die auch heute noch große Relevanz besitzt. Alle zwei Jahre veröffentlicht das Debian Projekt eine neue [...]

Debian 11 Bullseye nun im Full Freeze – dann ist es bald so weit

18. Juli 2021 um 09:21
Von: jdo

In Debians Mailing-Liste wurde ein Full Freeze für Debian 11 Bullseye angekündigt. Das ist eine der letzten Stufen, vor der Veröffentlichung einer neuen Version. Ab sofort müssen alle Pakete, die von Unstable oder Testing manuell freigeschaltet werden, wenn sie noch in die Distribution einfließen sollen. Da es keinen genauen Ausgabe-Termin gibt, kann man nun ein wenig spekulieren, wann Bullseye das Licht der Welt erblickt. Wirft man einen Blick auf die Vorgänger wie zum Beispiel Buster an, erscheint die neue Debian-Version […]

Der Beitrag Debian 11 Bullseye nun im Full Freeze – dann ist es bald so weit ist von bitblokes.de.

Debian 11 -Bullseye- RC2 veröffenticht und vorläufig geplanter Veröffentlichungstermin steht

17. Juni 2021 um 09:00
Die Debian Entwickler haben den Installer für Debian 11 als RC 2 veröffentlicht. Zeitgleich wurde der voraussichtliche Veröffentlichungstermin terminiert. Am 31. Juli möchten die Entwickler [...]

Debian 11 -Bullseye- RC2 veröffenticht und vorläufig geplanter Veröffentlichungstermin steht

17. Juni 2021 um 09:00
Die Debian Entwickler haben den Installer für Debian 11 als RC 2 veröffentlicht. Zeitgleich wurde der voraussichtliche Veröffentlichungstermin terminiert. Am 31. Juli möchten die Entwickler [...]

Tails-Entwickler stellen Pläne für 2021 vor: Zensur, Storage, Wayland

09. Januar 2021 um 13:17
Von: jdo

Die Entwickler der Linux-Distribution Tails (The Amnesic Incognito Live System) haben ihre Pläne für das Jahr 2021 vorgestellt. Sie wollen einige Kernfunktionen des Systems verbessern. Vor allen Dingen die Umgehung von Zensur steht ganz oben auf dem Plan. Umgehung von Zensur Zensur ist nicht nur lästig, sondern auch omnipräsent. Selbst in der EU wird zensiert. Auf welche Weise Tor (The Onion Router) startet und wie die Tor-Brücken (Bridges) konfiguriert werden, möchte das Tails-Team komplett neu gestalten. Es geht hier vor […]

Der Beitrag Tails-Entwickler stellen Pläne für 2021 vor: Zensur, Storage, Wayland ist von bitblokes.de.

❌