staging.inyokaproject.org

2022 Woche 16

23. April 2022

Ubuntu 22.04 liefert Firefox als Snap aus und nicht mehr als klassische DEB-Datei. Man kann das Snap deinstallieren und Firefox in der ESR-Version über ein PPA installieren. Wie du das tun kannst und vor allem wann du das tun solltest, steht in diesem Artikel.

Warum macht Canonical das bei Ubuntu?

Der Internetbrowser und der Mailclient sind die häufigsten Einfallstore für Schadsoftware am Desktop. Entsprechend oft werden hier Sicherheitslücken entdeckt und ausgebessert. Das bedeutet für Distributoren viel Arbeit.

Klassische Linux-Programme, wie sie in DEB oder RPM-Dateien paketiert sind, haben zudem keine modernen Sicherheitsfunktionen, wie z. B. Sandboxes oder Beschränkungen der Berechtigungen. Diese sind durch die mobilen Betriebssysteme Android und iOS inzwischen weit verbreitet und werden auch am Desktop adaptiert. Die Entwicklungen bei Linux heißen Flatpak und Snap. Große und wichtige Distributoren wie SUSE, Red Hat oder Canonical entwickeln bereits länger in diese Richtung.

Außerdem gibt es Probleme durch die Verschränkung von Basissystem und Anwenderprogrammen und dadurch Schwierigkeiten, neue Programme für eine alte Basis zurück zu portieren. Deshalb sind Linux-Distributionen momentan in zwei Lager „Rolling Release“ und „Stable“ getrennt und du bekommst in Ubuntu-Versionen während der Supportdauer nie neue Programme. Das wollen die Entwickler damit auch lösen.

Das Snap wird zudem direkt durch Mozilla, die Entwicklerorganisation hinter Firefox, gepflegt. Das spart Arbeit für den Distributor und sorgt für Verlässlichkeit für die Anwender. Verzögerungen bei Updates, wie sie bisher immer mal wieder vorkamen, gehören damit vermutlich der Vergangenheit an.

Aber man liest so viel schlechtes darüber

Die meisten schreiben nur nach, was sie irgendwo gelesen haben. Die meisten Kritiker nutzen es nicht selbst und haben eher ideologische Vorbehalte. Bei Linux ist die Zahl der Novitätenskeptiker noch größer als in anderen gesellschaftlichen Bereichen, weil viele Linux-Anwender mal vor Entwicklungen bei Windows oder macOS zum konservativen Linux geflohen sind. Wenn man diesen Leuten immer gefolgt wäre, hätte die Menschheit heute weder Rad noch Feuer.

Vertraue niemandem, der irgendetwas von bewährter Technik schreibt. Hinterfrage bei denjenigen immer, ob sie sich wirklich mit der neuen Technik beschäftigt haben oder einfach nur aus Prinzip alles doof finden. Mit krampfhaftem Festhalten an alten Konzepten manövrierst du dich in eine Sackgasse und landest da, wo die Novitätenskeptiker jetzt schon stehen. Vollkommen überfordert durch die Entwicklung, ängstlich gegenüber der Gegenwart, was sie hinter einem Schutzpanzer aus Trotz und „Brauch ich nicht“ verstecken, bis es gar nicht mehr anders geht, weil dein Arbeitgeber, Familie oder Freunde dich zwingen jahrzehntelange Entwicklungen auf einen Schlag nachzuholen.

Ein anderes Problem sind konzeptionelle Differenzen, ob Flatpak oder Snap der richtige Weg sind und ob es nicht noch eine bislang unbekannte noch bessere Lösung gibt. Darüber kann und sollte man diskutieren, aber das tangiert dich als normalen Anwender nicht. Ist man wie du Ubuntu-Anwender folgt man den Entscheidungen von Canonical und das ist gegenwärtig Snap. Wenn Canonical in ein paar Jahren was anderes macht, gibt es für dich einen Upgradepfad, auch darum brauchst du dich nicht kümmern.

Wann sollte ich also mein Snap durch ein PPA ersetzen?

Wenn du ein konkretes Problem hast, von dem du belegbar weißt, dass es durch die Umstellung auf Snap ausgelöst wurde. Dann solltest du überlegen, das PPA einzubinden. Aber nur dann!

Also nicht, wenn du irgendwie das Gefühl hast, ein Problem zu haben oder dir ein Schlaumeier erzählt, dass Snaps irgendwie blöd sind, sondern wenn du ein verifizierbares Problem hast. Davon gibt es ein paar, aber es sind nicht so viele wie oft suggeriert wird. Beispielsweise weil du eine KeePass-Passwortdatenbank nutzt und diese mit einem Browseraddon mit Firefox verbinden möchtest. Oder weil du richtig alte Hardware hast und z. B. noch eine normale Festplatte, wodurch Firefox als Snap merkbar verzögert startet.

Soll ich zu Distribution xyz wechseln?

Wenn du ansonsten mit Ubuntu zufrieden bist nicht. Auch in anderen Teilen des Linux-Universums wird die Welt nicht stehen bleiben. Alle Distributoren mit sogenannten LTS-Distributionen experimentieren aktuell mit neuen Zukunftsmodellen. Red Hat arbeitet bei Fedora an Projekt Silverblue, dagegen ist das eine Snap in Ubuntu gar nichts. Bei SUSE überlegt man aktuell eine ganz neue Linux Plattform zu konzipieren.

Aber über das PPA gibt es nur Firefox ESR

In dem unten aufgeführten PPA ist nicht der normale Firefox enthalten, weil den Mozilla ja als Snap bereitstellt, sondern die ESR-Variante von Firefox. Manche erzählen, dass das doof ist und du deshalb die Distribution wechseln solltest. Das ist Quatsch.

Erstens ist Firefox ESR bis auf ganz kleine Unterschiede ein normaler Firefox. Man überspringt lediglich einige Releases und bekommt neue Funktionen nur alle paar Monate. Wer eine LTS bei Linux nutzt, dürfte dieses Konzept eher befürworten.

Zweitens hilft ein Wechsel auf eine andere Distribution nicht. Debian, die RHEL-Klone (Alma Linux, Oracle Linux oder Rocky Linux) oder openSUSE Leap nutzen ebenfalls die ESR-Version von Firefox.

Wie ersetze ich das Snap Paket durch ein PPA?

Vor der Umstellung unbedingt das Firefox-Profil sichern, wenn du bereits Daten in Firefox hast.

Wenn du wirklich ein Problem hast und deshalb das klassische DEB-Programm brauchst, ist das nicht weiter schwierig. Mozilla pflegt nämlich extra für Ubuntu mehrere PPAs, weil Ubuntu die wichtigste Linux-Distribution ist.

Du brauchst nur drei Terminalbefehle, um deinen Snap-Firefox gegen das PPA zu ersetzen.

$ sudo snap remove firefox
$ sudo add-apt-repository ppa:mozillateam/ppa && sudo apt update
$ sudo apt install firefox-esr firefox-esr-locale-de

Fertig! Total einfach und sicher kein Grund, die Distribution zu wechseln.

Änderung 23.04.2022

Zwei Punkte dazugenommen (Distributionswechsel, Firefox ESR) und einen Aspekt umgestellt.

22. April 2022

Nun ist es soweit. Ubuntu ist da und die Firefox-Snap-Realität ist eingetreten. Die Hölle gefriert, es regnet tote Frösche und so mancher Altvorderer vor seinem 19″ (4:3 Formaaaaat!) beißt in seine mechanische IBM-Tastatur. Eine nicht ganz ernst gemeinte Presseschau.

Ich hatte überlegt, einen Test zu schreiben, aber alles wesentliche hatte ich hier bereits in einer Vorschau geschildert. Das Osterwochenende nutzte ich bereits um ein paar Maschinen auf Kubuntu 22.04 (es ist leider vorerst kein openSUSE geworden) umzustellen. Teilweise per Upgrade, teilweise per Neuinstallation, um hartnäckige Probleme endlich loszuwerden. Kubuntu 22.04 ist ein sehr rundes Release geworden. Plasma 5.24 LTS in Kombination mit KDE Gear 21.12 ist in einem Zustand, den man bedenkenlos 3 Jahre nutzen kann. Angesichts des demnächst sicher irgendwann mal einsetzenden Wechsels auf Qt 6 bzw. Plasma 6 ist Kubuntu 22.04 vielleicht für manche Anwender ein sicherer Hafen, um die Stürme auszusitzen (die hoffentlich nicht Orkanstärke erreichen). Die Zahl der Neuerungen hält sich aber dermaßen in Grenzen – standardmäßig setzt Kubuntu nicht mal auf Wayland – dass ich mir einen umfassenden Testbericht spare. Ich wüsste gar nicht, was ich schreiben sollte. KDE-Software liegt halt in einer neuen Version vor.

Das erledigen andere und ich hatte ja bereits prognostiziert, dass die Entscheidung für Snaps es in viele Artikel schaffen würde. Gewohnt niveaulos und schwer zu übertreffen startet Heise, die in ihrem Titel schreiben: „GNOME 42, Wayland als Standard und Snap-Ärger„. Was dieser Snap-Ärger sein soll, erschließt sich nach Lektüre des Artikels nicht. Es werden viele Behauptungen in den Raum gestellt, aber der Autor hat vor allem Probleme mit KeePass. Nun, logische Argumentation darf man bei Heise-Autoren schon lange nicht mehr erwarten. Letztlich sind die Artikel ja auch nur noch der Auftakt für den Trollsportverein im Forum, dessen Klicks vermutlich die Existenz des Verlags sichern.

Michael Kofler mag Snaps auch nicht. Aber wenigstens argumentiert er nicht auf Heise-Niveau, sondern zeigt ein paar Lösungswege auf. Dass Snaps eine Antwort auf die von ihm bemängelten veralteten Versionsstände sind, ist ihm irgendwie entgangen. Ansonsten scheint das Problem mit KeePass als Textbaustein wohl an alle Snap-Gegner geschickt worden zu sein. Ich wünschte ja wirklich, dass das ein Problem für die Allgemeinheit wäre, denn dann wären Passwortverwaltungen endlich Standard. Träume darf man noch haben. Kofler hat auch noch nichts von modernen Dateisystemen mit Deduplizierung gehört (die mag er auch nicht so), wobei das in diesem Fall sogar in Ordnung geht, weil Ubuntu ja standardmäßig ext4 nimmt. Wenigstens kommt er abschließend zur Einschätzung, dass Ubuntu (oder Mint) eben doch die Einstiegsdistribution ist und bleibt. Bei vielen im Linux-Universum hat sich ja hier eine komische Wahrnehmungsverzerrung eingebürgert und alle glauben jeder würde MX Linux oder Arch Linux nutzen.

Bei Golem haben sie Snaps mit keinem Wort erwähnt. Sakrileg! Ich bin schwer enttäuscht. Zum Glück hat ein Kommentator diesen Fauxpas erkannt und halbherzig ergänzt. Mal schauen, ob noch jemand den KeePass-Textbaustein einbaut.

Auf Linuxnews werden Snaps auch nicht gerne gesehen, aber Ferdinand Thommes verweist da eher auf den Ubuntu-Sonderweg und fragt sich, ob die Reise nicht doch eher in Richtung Flatpak geht. Kann man definitiv so sehen, wir erinnern uns ja alle an Unity, Mir, Upstart usw. usf.

MichlFranken hat immerhin mal einen tieferen Blick ins System geworfen und festgestellt, dass außer Firefox gar keine anderen Snaps vorinstalliert sind. Bei Heise & Co hört sich das manchmal anders an. Aber vielleicht konnten die auch einfach nicht so gut testen, weil Virtualisierung auf den neuen Apple M1 Maschinen ja nicht mehr so gut klappt.

Andreas Proschofsky hat für DerStandard einen sehr lesenswerten und umfassenden Testbericht geschrieben. Snap ist bei ihm nur ein Thema unter vielen und Proschofsky konzentriet sich auf wirkliche Probleme anstelle pauschaler Kritik. Außerdem wirft er die Frage auf, warum Canonical es nicht gleich richtig macht und viel stärker auf Snap setzt. Wenn schon, denn schon. Berechtige Fragen.

Den meisten Anwendern wird dieses Problem wohl verborgen sein. Hast du ein Problem mit Snaps? Nein, nur ohne. Zum Wohl! Auf ein weiteres gutes Release. Mal sehen, wie die Linux-Welt bei der nächsten LTS 2024 aussieht.

Bild von anncapictures auf Pixabay

Nachtrag 24.04.2022

Test aus dem Standard ergänzt.

21. April 2022

Die MZLA Technologies Corporation hat mit Thunderbird 91.8.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.8.1

Mit dem Update auf Thunderbird 91.8.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen.

Der Beitrag Thunderbird 91.8.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Do, 21. April 2022, Ralf Hersel

Canonical hat heute Ubuntu 22.04 LTS mit dem Namen 'Jammy Jellyfish' zum Download freigegeben. Diese Long-term-support Version erhält während der nächsten fünf Jahre Updates. Wer es genau wissen möchte, kann die Details über LTS hier nachlesen. Ubuntu 22.04 LTS enthält die neueste GNOME-42-Desktop-Umgebung mit dem Triple-Buffering-Patch, verwendet aber aufgrund von Kompatibilitätsproblemen zwischen GTK4-Applikationen in der Upstream-Version und Ubuntus Yaru-Theme noch Anwendungen aus dem GNOME-41-Stack, wie z.B. den Dateimanager Nautilus (Files).


In dieser Version gibt es neue Einstellungen, um das Aussehen und Verhalten des Docks zu steuern, einen systemweiten dunklen Stil für alle Anwendungen und Dialoge, eine verbesserte Integration von Dock-Geräten und Dateimanager sowie 10 Akzentfarben für die dunklen und hellen Stile des Standard-Yaru-Themas, das nun das Aussehen und die Bedienung von GTK4-Anwendungen nachahmt.


Ein weiteres wichtiges Merkmal von Ubuntu 22.04 LTS ist die langjährig unterstützte Linux-Kernel-Serie 5.15 LTS, die eine neue Implementierung des NTFS-Dateisystems mit sich bringt, mit der man Daten lesen und schreiben kann, ohne auf einen Treiber oder eine Software eines Drittanbieters angewiesen zu sein. Der Linux-Kernel 5.15 LTS wird bis mindestens Oktober 2023 mit Sicherheits- und Bugfix-Updates unterstützt.

Darüber hinaus bringt Jammy Jellyfish RDP-Unterstützung für die gemeinsame Nutzung des Desktops aus der Ferne mit besserer Sicherheit, Privatsphäre und Leistung, Wayland als Standardsitzung für die meisten Systeme, die keine NVIDIA-Grafikkarte haben, es gibt Unterstützung für Hardware mit Privacy-Screen-Unterstützung, UDP ist jetzt standardmässig für NFS-Mounts deaktiviert und es gibt ein neues Logo, das man auf dem Startbildschirm und auf der Info-Seite der Einstellungen-App sehen kann.

Zu den weiteren Änderungen in dieser Version gehört die Unterstützung des Pakets linux-restricted-modules auf der ARM64-Plattform (AArch64) für NVIDIA-Treiber, um die Verwendung des Tools ubuntu-drivers zur Installation und Konfiguration von NVIDIA-eigenen Treibern aus den Ubuntu-Repositories zu ermöglichen, sowie die Unterstützung der neuesten Linux 5.17-Kernel-Serie für OEMs. Ausserdem ist ssh-rsa jetzt standardmässig in OpenSSH deaktiviert, um die Sicherheit zu erhöhen.

Darüber hinaus zeigt Ubuntu beim Upgrade keine anderen installierten Betriebssysteme mehr im Boot-Menü an, es sei denn, man führt eine Neuinstallation durch und hat bereits ein anderes Betriebssystem installiert. Nftables ist jetzt das Standard-Backend für die Firewall und der Mozilla Firefox Webbrowser wird in Ubuntu nur noch als Snap-Paket angeboten.

Ubuntu 22.04 LTS (Jammy Jellifish) steht als Desktop- und Server-Images sowie als eine der offiziellen Varianten (z.B. Kubuntu, Xubuntu, Lubuntu, etc.) zum Download bereit. Eine Übersicht über die Neuerungen bei den Varianten findet ihr hier. Ubuntu wird in den nächsten 5 Jahren bis April 2027 mit Standard-Wartungsupdates und regelmässigen Point-Releases alle sechs Monate unterstützt, während die anderen Varianten bis April 2027 verfügbar sein werden.

Wie immer, gibt es die "Things to do After Installing Ubuntu", zum Beispiel hier. Abhishek Prakash hat dort eine ziemlich vollständige Liste mit 22 Punkten abgeliefert, die man sich nach der Installation anschauen kann. Einen wichtigen Punkt hat er jedoch vergessen: Firefox als Snap-Paket kommt nicht mit dem KeePass-Plugin zurecht. Denn das Keepass-Plugin für Firefox versucht, ein externes Hilfswerkzeug aus GNOME für die Passwort-Eingabe aufzurufen – aber das entsprechende Binary ist im Snap-Paket nicht vorhanden. Daher ist es ratsam, das Snap-Paket vollständig zu entfernen und durch ein Debian-Paket von Firefox zu ersetzten.

Quelle: https://www.releases.ubuntu.com/22.04/

Für Videokonferenzen nutze ich das Tool Jitsi Meet Electron. Das ist das einzige Programm, welches ich auf meinem GNU/Linux Desktop als AppImage ausführe.
Ich gehe auf GitHub https://github.com/jitsi/jitsi-meet-electron und lade mir das AppImage jitsi-meet-x86_64.AppImage herunter. Nun werden noch die Rechte auf die Datei gesetzt.

chmod u+x Downloads/jitsi-meet-x86_64.AppImage

Jetzt ist das AppImage ausführbar und kann z.B. mit einem Doppelklick gestartet werden.
Der Vorteil im Gegensatz zu Jitsi Meet im Webbrowser ist unter anderem der, dass ihr Jitsi Meet schon vorher konfigurieren(*) könnt, bevor ihr einer Videokonferenz beitretet.

(*) Nickname festlegen; Mikrofon und Kamera AN oder Aus stellen

20. April 2022

Die Veröffentlichung von openSUSE Leap 15.4 steht in einigen Wochen an. Die revolutionären Veränderungen bei SUSE für die Enterprise-Distribution SUSE Linux Enterprise werfen jedoch schon ihre Schatten voraus. Einen ersten Ausblick gibt es nun.

Lubos Kocman, seines Zeichens Produktmanager für openSUSE Leap, äußerte sich dazu auf der Factory Mailingliste. Natürlich sind das alles noch frühe Überlegungen, da die Entwicklungen bei SUSE für SLE 16 noch nicht substanziell begonnen haben. Klar scheint aber zu sein, dass es nächstes Jahr nochmal eine Leap-Version des bewährten 15er-Zweiges gibt. Diese wird deutlich konservativer als die unmittelbar bevorstehende Version 15.4 werden und sich mehr auf Produktpflege konzentrieren.

Während es für SLE 15 noch weitere Service Packs geben wird, ist für openSUSE Leap aktuell keine Veröffentlichung des 15er Zweiges über die Version 15.5 hinaus geplant. Stattdessen soll danach auf das neue ALP-SUSE umgestellt werden. Das angekündigte offene Entwicklungsmodell von SLE 16 soll hier dabei helfen die Umbrüche frühzeitig einschätzen zu können, um für openSUSE die richtigen Schlüsse ziehen zu können. Ob das alles so kommt, weiß zum aktuellen Zeitpunkt sowieso niemand sicher.

Bis dahin wird aber noch einiges an Zeit vergehen. Bei einer Veröffentlichung von openSUSE Leap 15.5 im Juni 2023 und der Nachfolgeversion im Sommer 2024 und der obligatorischen Übergangsperiode können Anwender also noch bis Ende des Jahres 2024 den bewährten openSUSE Leap 15er Zweig nutzen. Genug Zeit also um das neue ALP-Konzept auf sich wirken zu lassen und zu entscheiden, ob man den Weg mitgehen möchte oder eben nicht,.

19. April 2022

Di, 19. April 2022, Ralf Hersel

In einem Blog-Beitrag äussert sich der Debian-Entwickler Steve McIntyre zum Umgang mit proprietärer Firmware im Debian Projekt. Seiner Meinung nach ist die Art und Weise, wie das Projekt mit (unfreier) Firmware in Debian umgehen, ein Schlamassel, das vielen Benutzer:innen schadet. Lange Zeit habe man so getan, als ob die Unterstützung und Einbindung von (unfreier) Firmware auf Debian-Systemen nicht notwendig sei. Man wollte den Benutzern keine (unfreie) Firmware zur Verfügung stellen, was in einer idealen Welt auch nicht nötig wäre. Für McIntyre ist dies jedoch kein vernünftiger Weg mehr, wenn man aktuelle Hardware unterstützen möchte.

Firmware ist die Low-Level-Software, die dafür sorgt, dass Hardwaregeräte funktionieren. Firmware ist eng an die Hardware gekoppelt, stellt ihre Funktionen zur Verfügung und bietet übergeordnete Funktionen und Schnittstellen für andere Software an. Aus einer Vielzahl von Gründen ist sie typischerweise keine Freie Software.


In der Vergangenheit wurde die gesamte erforderliche Firmware normalerweise direkt von den Herstellern in die Geräte/Erweiterungskarten integriert. Im Laufe der Zeit wurde es jedoch für die Gerätehersteller immer attraktiver (und daher auch üblicher), nicht auf allen Geräten eine vollständige Firmware mitzuliefern. Stattdessen enthalten einige Geräte nur einen sehr einfachen Satz von Firmware, der das Hochladen eines vollständigeren Firmware-"Blob" in den Speicher ermöglicht. Von den Gerätetreibern wird dann erwartet, dass sie diesen Blob während der Initialisierung des Geräts bereitstellen.

Für diese Änderung gibt es mehrere Hauptgründe. Kosten: Es ist in der Regel billiger, einen kleineren Flash-Speicher (oder gar keinen Flash-Speicher) in ein Gerät einzubauen. Flexibilität: Es ist viel einfacher, das Verhalten eines Geräts zu ändern, indem man einfach zu einem anderen Blob wechselt. Aus diesen Gründen müssen heute immer mehr Geräte in einem typischen Computer zur Laufzeit mit Firmware versorgt werden, damit sie korrekt funktionieren.

Vor etwa 10 Jahren brauchten die meisten Computer nur Firmware-Uploads, damit die WiFi-Hardware funktionierte. Eine wachsende Zahl von kabelgebundenen Netzwerkadaptern erfordert jetzt Firmware-Uploads. Einige funktionieren in begrenztem Umfang, sind aber auf zusätzliche Firmware angewiesen, um erweiterte Funktionen zu ermöglichen. Andere weigern sich, ohne Firmware-Upload überhaupt zu funktionieren. Immer mehr Grafikkarten benötigen jetzt auch Firmware-Uploads, um alle nicht grundlegenden Funktionen bereitzustellen. Ein einfacher (S)VGA-kompatibler Framebuffer reicht den meisten Anwendern heutzutage nicht mehr aus; moderne Desktops erwarten 3D-Beschleunigung, und viele aktuelle Hardware bietet diese nicht ohne zusätzliche Firmware. Aktuelle Generationen gängiger Intel-basierter Laptops benötigen ebenfalls Firmware-Uploads, damit Audio funktioniert.

Debians Main-Repository enthält einen kleinen Satz von Free-Firmware-Binärdateien, welche auf den Installations- und Live-Medien enthalten sind. Allerdings gibt es viele weitere Firmware-Binärdateien, die nicht frei sind. Wenn das Projekt rechtlich in der Lage ist, diese Binärdateien weiterzugeben, werden sie paketiert und dem unfreien Teil des Archivs beigefügt. Die Debian-Richtlinien trennen klar zwischen Freier und unfreier Software. Daraus ergibt sich eine Spannung, die auch die Installations- und Live-Medien betrifft. Da non-free offiziell nicht als Teil von Debian angesehen wird, können die offiziellen Medien nichts von non-free enthalten. Dies ist eine bewusste Politik für viele Jahre gewesen. Stattdessen hat das Projekt seit einiger Zeit einen begrenzten parallelen Satz von "inoffiziellen Non-Free"-Images erstellt, die Non-Free-Firmware enthalten. Diese unfreien Images werden mit der gleichen Software erstellt, die auch für die offiziellen Images verwendet werden, und zwar vom gleichen Team. Daraus ergeben sich Probleme:

  1. Das Erstellen, Testen und Veröffentlichen von zwei Image-Sets erfordert mehr Aufwand.
  2. Vom philosophischen Standpunkt aus möchte das Projekt gar keine unfreien Images anbieten. Deshalb werden hauptsächlich die bevorzugten offiziellen Images beworben. Das kann bei den Nutzern zu Verwirrung führen, weil die unfreien Images nicht so leicht zu finden sind.
  3. Die Verwendung unfreier Installationsmedien wird dazu führen, dass mehr Installationen standardmässig unfreie Software verwenden, obwohl diese kein Teil des Debian Projekts ist.
  4. Eine Reihe von Benutzern und Entwicklern beschweren sich, dass das Projekt offizielle Images veröffentlicht, die für viele der Benutzer einfach nicht nützlich sind.

Um diese Probleme zu lösen, schlägt McIntyre fünf Optionen vor:

  1. Nichts ändern
  2. Einstellen der non-free unofficial Images
  3. Aufhören, so zu tun, als ob die unfreien Images inoffiziell wären
  4. Das Image-Team könnte unfreie Pakete in die offiziellen Images aufnehmen und Firmware-Pakete zu den Eingabelisten für diese Images hinzufügen.
  5. Man könnte die unfreien Firmware-Pakete in eine neue Komponente für unfreie Firmware im Archiv ausgliedern und nur eine bestimmte Ausnahme zulassen, um die Aufnahme dieser Pakete in die offiziellen Medien zu ermöglichen. Dann würde nur einen Satz offizieller Medien generiert, der diese unfreien Firmware-Pakete enthält.

Steve McIntyre bevorzugt die letzte Option.

Quelle: https://blog.einval.com/2022/04/19

18. April 2022

Herzlich willkommen zu Teil 6 meiner Reihe Nextcloud im Container. Dieser Teil behandelt das Thema Updates. Zum Verständnis empfehle ich, zuerst Teil 1 und Teil 2 zu lesen.

Nun wünsche ich euch viel Spaß beim Lesen und gute Unterhaltung.

Gedanken zum Update

Meine Nextcloud-Instanz läuft in einem Podman-Pod. Das sieht im Terminal wie folgt aus:

$ podman pod ps
POD ID        NAME    STATUS   CREATED       INFRA ID      # OF CONTAINERS
e84bec6108d1  nc_pod  Running  2 months ago  5e52555c5060  3

Dieser Pod besteht aus den folgenden drei Container-Instanzen:

$ podman ps
CONTAINER ID  IMAGE                                  COMMAND               CREATED       STATUS         PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                         2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  e84bec6108d1-infra
c6571aa338ce  docker.io/library/mariadb:10.5.7       mysqld                2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nc_mariadb
21739d36eef1  docker.io/library/nextcloud:23-apache  apache2-foregroun...  2 months ago  Up 7 days ago  127.0.0.1:40671->80/tcp  nextcloud

Diese Container-Instanzen sind zustandslos und ephemeral (engl. für kurzlebig, vergänglich oder flüchtig). Persistent zu speichernde Daten werden außerhalb der Container-Instanzen gespeichert. Diese Eigenschaften erlauben es, Container einfach entfernen und durch neue Instanzen ersetzen zu können.

Um die Nextcloud zu aktualisieren, wird in dieser Umgebung also nicht die Anwendung innerhalb des Containers aktualisiert. Stattdessen werden die Container-Instanzen entfernt und Container-Images mit aktuelleren Versionen der Anwendung und Datenbank instanziiert.

Der Update-Prozess

Die aktuell laufenden Versionen von Nextcloud und MariaDB sind obigen Codeblock zu entnehmen. Diese Images wurden durch die beiden folgenden Zeilen in der Datei {role_path}/defaults/main.yml definiert:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
NC_IMAGE: docker.io/library/nextcloud:23-apache

Hier kann man nun die gewünschten Versionen der zu verwendenden Container-Images eintragen. Alternativ kann man die Default-Werte auch durch entsprechende Einträge in {role_path}/vars/main.yml überschreiben. Die Einträge sehen dann bspw. wie folgt aus:

MARIADB_IMAGE: docker.io/library/mariadb:10.5.9
NC_IMAGE: docker.io/library/nextcloud:23.0.3-apache

Nun kann das Playbook mit der Ansible-Rolle aus Teil 2 dieser Reihe erneut ausgeführt werden:

$ ansible-playbook -i hosts deploy_nextcloud.yml --ask-vault-pass                                                 
Vault password:                                                                                                   
                                                                                                                  
PLAY [localhost] **************************************************************************************************
                                                                                                                  
TASK [Gathering Facts] *******************************************************************************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Main folder, needed for updating] *************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for installed/modified apps] ***********************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for local configuration] ***************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the actual data of Nextcloud] ******************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the MySQL data files] **************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create the podman-pod(1)] *********************************
changed: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create MariaDB container] *********************************
changed: [localhost]                                                                                               
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Wait for DB to initilize] *********************************
ok: [localhost]                                                                                                    
                                                                                                                  
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create Nextcloud container] *******************************
changed: [localhost]                                                                                               
                                                                                                                  
PLAY RECAP *******************************************************************************************************
localhost                   : ok=10   changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Nun kann man sich auf dem Zielsystem davon überzeugen, dass die neuen Container-Images zur Instanziierung verwendet wurden:

$ podman ps
CONTAINER ID  IMAGE                                      COMMAND               CREATED         STATUS             PORTS                    NAMES
5e52555c5060  k8s.gcr.io/pause:3.2                                             2 months ago    Up 7 days ago      127.0.0.1:40671->80/tcp  e84bec6108d1-infra
248f87e1135b  docker.io/library/mariadb:10.5.9           mysqld                35 seconds ago  Up 36 seconds ago  127.0.0.1:40671->80/tcp  nc_mariadb
59ac1aad168c  docker.io/library/nextcloud:23.0.3-apache  apache2-foregroun...  10 seconds ago  Up 11 seconds ago  127.0.0.1:40671->80/tcp  nextcloud

Fertig. Schon kann Nextcloud in Version 23.0.3 mit einer MariaDB 10.5.9 genutzt werden.

Fazit

Mit diesem Artikel habe ich das letzte noch offene Ziel Nr. 5 „Konfiguration und Test automatischer durch Ansible gesteuerter Updates“ erreicht. Der Update-Prozess folgte dem Container-Paradigma, die Container komplett zu ersetzen und nicht die Anwendung innerhalb der Container zu aktualisieren.

Es handelte sich im dokumentierten Fall um Updates auf ein neues Patch-Release, bei denen das Risiko für Fehler ohnehin sehr gering ist. Ob das Update auch bei Minor- bzw. Major-Releases so gut funktioniert, muss sich noch zeigen. Ich werde diesen Artikel aktualisieren, wenn es Erkenntnisse dazu gibt.

Mit diesem Artikel endet meine Reihe „Nextcloud im Container“. Ich hoffe, ich habe euch damit ein wenig unterhalten und konnte euer Wissen durch die ein oder andere Information erweitern.

Quellen und weiterführende Links

  1. Nextcloud im Container – Teil 1: Der Plan
  2. Nextcloud im Container – Teil 2: Die Ansible-Rolle
  3. Nextcloud im Container — Teil 3: Mit Reverse-Proxy
  4. Nextcloud im Container — Teil 4: Hier und da klemmt es
  5. Nextcloud im Container – Teil 5: Backup und Restore
  6. ansible_role_deploy_nextcloud_with_mariadb_pod auf GitHub
  7. Semantic Versioning 2.0.0