Die MZLA Technologies Corporation hat mit Thunderbird 128.7 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 128.7
Mit dem Update auf Thunderbird 128.7 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt wie immer diverse Fehlerbehebungen und Verbesserungen unter der Haube, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.
Mozilla hat Firefox 135 für Windows, Apple macOS und Linux veröffentlicht. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.
Für Nutzer in den USA und Kanada wurde mit Firefox 134 ein angepasstes Layout für die Startseite ausgerollt, welches bis zu vier statt drei Content-Empfehlungen pro Zeile erlaubt und die Positionierung von Logo (und Wetter-Widget in Ländern, in denen dieses Feature bereits ausgerollt wird) so anpasst, dass die Suchleiste, Verknüpfungen und Content-Empfehlungen weiter oben erscheinen. Ab Firefox 135 erfolgt eine Ausrollung in allen anderen Ländern, welche Pocket-Empfehlungen unterstützen.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserungen der Übersetzungsfunktion
Firefox besitzt eine Übersetzungsfunktion für Websites, welche im Gegensatz zu Cloud-Übersetzern wie Google Translate lokal arbeitet, die eingegebenen Texte also nicht an einen fremden Server sendet. Mit dem heutigen Tag folgt die Unterstützung von Übersetzungen aus dem Chinesischen, Japanischen sowie Koreanischen. Ebenfalls neu: Übersetzungen ins Russische.
Grundsätzlich ist die Unterstützung neuer Sprachen nicht an Firefox-Versionen gebunden, womit diese Sprachen auch in älteren Firefox-Versionen zur Verfügung stehen. Allerdings gab es in Firefox 135 Anpassungen, welche die Qualität für die Übersetzungen aus den asiatischen Sprachen verbessern.
Außerdem wurden allgemeine Verbesserungen an der Übersetzungsfunktion vorgenommen, von denen auch andere Sprachen profitieren und welche die Wahrscheinlichkeit verringern, dass unter bestimmten Umständen neue Wörter erfunden werden.
Speicherung von Kreditkarten-Daten
Firefox unterstützt die Speicherung von Kreditkarten-Daten, sodass Nutzer diese in Online-Shops nicht jedes Mal manuell eingeben müssen. Bislang war diese Funktion für Nutzer in Deutschland, Österreich, den USA, Kanada, Frankreich, Italien, Spanien, Belgien, Polen sowie dem Vereinigten Königreich aktiviert. Beginnend mit Firefox 135 startet eine weltweite Ausrollung dieses Features.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
KI-Chatbots
Firefox 135 integriert mehrere KI-Chatbots. Dabei stehen Google Gemini, ChatGPT, HuggingChat, Anthropic Claude sowie Le Chat Mistral zur Verfügung. Die Chatbots können direkt über die Sidebar genutzt werden.
Über das Kontextmenü oder, falls über eine Option im Abschnitt „Firefox Labs“ der Firefox-Einstellungen aktiviert, eine Schaltfläche nach dem Markieren von Text können auch direkt Funktionen zur Zusammenfassung des markierten Inhalts, zur Vereinfachung der Sprache sowie zu einem Abfragen des Inhalts ausgewählt werden.
Neu gegenüber früheren Versionen, in denen dieses Feature über eine versteckte Option bereits vorab getestet werden konnte, ist ein vordefinierter Prompt zum Korrekturlesen. Ebenfalls im Vergleich neu ist ein Kommando, um die Chatbot-Sidebar per Tastatur öffnen und schließen zu können (Strg + Alt + X; macOS: Control + X).
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserung der Zurück-Navigation
Es wurden Schutzmechanismen implementiert, die verhindern, dass Websites die Verlaufs-API missbrauchen, indem sie die Verlaufseinträge überladen und damit die Navigation mit den Schaltflächen „Zurück“ und „Vorwärts“ erschweren. Firefox versucht nun, solche Einträge auszulassen.
Kleinere Installationsarchive für Linux
Mozilla hat seine Linux-Pakete von .tar.bz2 auf .tar.xz und damit auf eine LZMA-Kompression umgestellt. Dies resultiert in 25 Prozent kleineren Installationsarchiven sowie einer mehr als doppelt so schnellen Dekompressionszeit.
Sonstige Endnutzer-Neuerungen in Firefox 135
Für Nutzer von Apple macOS und Linux bietet Firefox beim Betätigen des Tastatur-Kommandos zum Beenden des Browsers die zusätzliche Option an, nur den aktuellen Tab zu schließen.
Die sichtbare Datenschutz-Einstellung für „Do not Track“ (DNT) wurde entfernt, da dieser Standard als gescheitert gilt und nicht mehr empfohlen wird. Der indirekte Nachfolger ist die „Global Privacy Control“ (GPC), für welche Firefox bereits eine eigene Einstellung besitzt („Websites anweisen, meine Daten nicht zu verkaufen oder weiterzugeben“).
Der Kontextmenü-Eintrag „Link ohne Website-Tracking kopieren“ wurde in „Saubere Link-Adresse kopieren“ umbenannt. Außerdem werden jetzt weitere Parameter von Facebook-Links entfernt und die Funktion steht auch für ausgeschriebene Links nach Markierung zur Verfügung.
Für Nutzer der neuen Seitenleiste, welche aktuell an einen kleinen Prozentsatz der Nutzer ausgerollt ist (oder manuell über die Option sidebar.revamp in about:config aktiviert werden kann), wurde ein Tastaturkommando implementiert, um diese ein- und auszufahren (Strg + Alt + Z; macOS: Control + Z). Außerdem wurde das Verhalten der Tastaturkommandos zum Ein- und Ausklappen der Sidebars für die Lesezeichen und Chronik im Zusammenspiel mit der neuen Seitenleiste verbessert.
Im Konto-Menü, welches auch Mozilla Monitor, Firefox Relay sowie das Mozilla VPN bewirbt, wird nach Anmeldung in das Mozilla-Konto jetzt zwischen „Meine Dienste“ und „Probieren Sie andere Schutzwerkzeuge von Mozilla aus“ getrennt, sofern der Nutzer auch Anwender von Firefox Relay ist.
Mit accessibility.typeaheadfind.wrappedSoundURL wurde eine neue Option in about:config hinzugefügt, um einen Sound abzuspielen, wenn das Ende einer Suche erreicht wurde.
Auf macOS 15 und höher werden seit Firefox 132 die neuen Auswahlfunktionen des Apple-Betriebssystems für die Bildschirm- und Fensterfreigabe unterstützt. Firefox 135 bringt die Unterstützung auch auf macOS 14.
Auf Linux unterstützt Firefox jetzt sogenanntes Native Messaging zur Kommunikation zwischen WebExtensions und auf dem System installierten Anwendungen auch, wenn Firefox als Snap-Paket installiert ist. Voraussetzung hierfür ist das XDG Desktop Portal in Version 1.19 oder höher (wobei Ubuntu die Unterstützung bereits vorab in Version 22.04 inkludiert hat) sowie die about:config-Option widget.use-xdg-desktop-portal.native-messaging in Firefox mit einem Wert von 1 oder 2.
Das Netzwerkanalyse-Panel der Entwicklerwerkzeuge zeigt jetzt auch Anfragen für data:-URIs sowie lokale Ressourcen, die über das file:-Protokoll eingebunden sind, an.
Mehr Sicherheit für Firefox-Nutzer
Auch in Firefox 135 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 135 daher für alle Nutzer dringend empfohlen.
Firefox erzwingt nun die sogenannte „Certificate Transparency“ und verlangt von Webservern einen ausreichenden Nachweis, dass ihre Zertifikate öffentlich bekannt gegeben wurden, bevor sie als vertrauenswürdig eingestuft werden. Dies betrifft nur Server, welche Zertifikate verwenden, die von einer Zertifizierungsstelle in Mozillas Stammzertifikats-Programm ausgestellt wurden.
Darüber hinaus wird der CRLite-Mechanismus zur Überprüfung des Widerrufs von Zertifikaten eingeführt, wodurch die Leistung dieser Überprüfungen erheblich verbessert wird.
Diese Neuerung wird schrittweise im Laufe der kommenden Wochen für alle Nutzer ausgerollt werden.
Verbesserungen der Webplattform
Verbesserungen der Webplattform lassen sich wie immer in den MDN Web Docs nachlesen.
Wolvic, der Browser für Virtual und Mixed Reality, wurde in der Version 1.8 veröffentlicht.
Igalia hat Wolvic 1.8 veröffentlicht. Bei Wolvic handelt es sich um einen Browser für Virtual und Mixed Reality, welcher auf dem eingestellten Firefox Reality basiert.
Neuerungen von Wolvic 1.8
Die Rendering-Engine wurde aktualisiert. So basiert Wolvic jetzt auf der Mozilla-Engine Gecko in Version ESR 128.5.1.
Einzelne Fenster oder auch alle Fenster zusammen können jetzt beliebig in der Umgebung verschoben werden. Die Möglichkeit, die Größe der Fenster zu verändern, wurden optisch verbessert.
Die Anzeige-Einstellungen wurden überarbeitet und die am meisten genutzten Optionen weiter oben platziert. Außerdem lässt sich jetzt eine von vier Standard-Fenstergrößen auswählen.
Für die Darstellung der Tabs gibt es nun drei verschiebene Optionen: eine horizontale Tableiste, vertikale Tabs oder eine Tab-Schaltfläche, welche bei Klick eine Raster-Darstellung aller Tabs öffnet.
Die Navigationsleiste hat jetzt auch Schaltflächen für Lesezeichen und Downloads.
Auch mit dieser Version wurden wieder neue Umgebungen hinzugefügt. Außerdem können Erweiterungen nun auch in Form zuvor heruntergeladener Dateien installiert werden.
Dies war nur eine Auswahl der größten Highlights. Dazu kommt wie immer eine Reihe weiterer Korrekturen und Verbesserungen unter der Haube.
SMLIGHT hat am 31. Januar 2025 die Beta von SLZB OS 2.8.0 mit folgenden Neuerungen veröffentlicht: Zigbee–Hub–Modus – Ihr SMLIGHT–Coordinator kann jetzt als eigenständiger Zigbee–Hub fungieren! Sie benötigen keinen separaten Mini-PC oder Server –...
Mozilla hat Version 2.25 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.25.
Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.
Das Update auf das Mozilla VPN 2.25 bringt keine neuen Funktionen, sondern vor allem Fehlerbehebungen und Verbesserungen unter der Haube. Die Option zum Starten des Mozilla VPNs mit Starten des Gerätes ist auf Desktop-Systemen jetzt standardmäßig aktiv. Das Adjust-SDK zwecks Kampagnenmessung wird nicht länger genutzt. Für Nutzer eines Smartphones oder Tablets von Apple ist iOS 15 die neue Mindestanforderung.
Ein neuer adminForge Service kann ab sofort genutzt werden. linklist.me LinkStack ist ein Ort, an dem du alle deine wichtigen Links in einem Profil verwalten kannst, ähnlich dem bekannten Linktree. https://linklist.me Features: Beispiel Profil:...
Solo ist ein Website-Builder von Mozilla, der auf Künstliche Intelligenz (KI) und einen maximal einfachen Erstellungsprozess setzt. Nun steht Solo 1.5 bereit und bringt viele Neuerungen.
Im Rahmen der Innovation Week im Dezember 2023 hatte das Mozilla Innovation Studio Solo angekündigt. Dabei handelt es sich um einen sogenannten Website-Builder mit Fokus auf Selbständige, der auf generative Künstliche Intelligenz für einen maximal einfachen Erstellungsprozess setzt.
Seit dem Start hat Mozilla einige Funktionen ergänzt. Jetzt hat Mozilla Solo 1.5 fertiggestellt. Die vollständigen Release Notes:
Exportieren von CSV-Dateien aller Kontaktformulare und Newsletter-Einträge
Neuer Share-Button, um Ihre Website über einen Link oder in sozialen Netzwerken zu teilen
Neuer Abschnitt „Code einbetten“ zum Einbetten von benutzerdefinierten Audio, Video oder anderen Anwendungen
Unterstützung für mobiles Onboarding
Neue Google Safe URL-Erkennung beim Erstellen von Links auf Ihrer Website
Link zu den Abschnitten Textbanner, Bildbanner und Code-Einbettung
Hinzufügen einer Schaltfläche „Ablehnen“ auf dem Cookie-Banner, falls aktiviert
Mobile und Desktop-Vorschau Ihrer Website anzeigen
Weitere allgemeine Fehlerbehebungen und Aktualisierungen
Die Nutzung von Solo ist kostenlos. Geringe Kosten fallen höchstens bei Verwendung einer benutzerdefinierten Domain an. Als Nächstes stehen weitere Optionen zum Bearbeiten und Gestalten, ein Abschnitt für Kundenlogos sowie eine neue Bibliothek zur Verwendung von Icons auf der Website auf der Roadmap.
Zukünftig wird Solo außerdem im Abschnitt „Mehr von Mozilla“ in den Firefox-Einstellungen beworben werden.
Danke Kollegen! Ich habe bisher noch nie eine so reibungslose Hardware-Erneuerung erlebt. Dies war wirklich eine schöne Erfahrung, an der ich euch in diesem Beitrag gerne teilhaben lasse.
Womit ich bisher gearbeitet habe
Ich habe im März 2023 bei Red Hat angefangen. Zu Beginn bekam ich ein Lenovo P1 Gen3 mit 32 GB RAM, Intel(R) Core(TM) i7-10850H CPU und 500 GB NVMe als Arbeitsgerät. Das Gerät war damals nicht mehr brandneu, es erfüllt jedoch all meine Anforderungen. Schon damals war ich von der Inbetriebnahme positiv überrascht und nahezug begeistert. Einschalten, Anweisungen auf dem Bildschirm folgen und kurze Zeit später war ich via VPN mit dem Unternehmensnetzwerk verbunden und einsatzbereit.
Ausgeliefert wurde das Gerät mit einem RHEL 8 Corporate Standard Build (CSB). Das bedeutet, dass ich das Betriebssystem nicht selbst installieren musste, sondern eine Installation bekam, die von unserer IT-Abteilung vorbereitet wurde. Ich darf durchaus mein eigenes Betriebssystem installieren, jedoch bin ich mit unserem CSB zufrieden und nutze dies gern. Ich darf Befehle mittels sudo ausführen und fühle mich in keinster Weise durch den CSB eingeschränkt.
Während der Nutzungsdauer folgte ein Wechsel von RHEL CSB zu Fedora CSB. Dazu gab es von unserer IT-Abteilung eine Anleitung, die durch den Prozess führte:
USB-Stick mit Fedora CSB Boot-ISO erstellen
Von USB-Stick booten
Anweisungen auf dem Bildschirm befolgen
Mittagessen gehen
Mit Fedora weiterarbeiten
Auch für diese Erfahrung geht nochmals ein Dankeschön raus.
Manchmal stört der Lüfterlauf ein wenig, doch von der Hardwareausstattung her hätte ich kein neues Gerät benötigt. Nun ist dieses Gerät aus der Garantie gelaufen, welche nicht mehr verlängert werden kann. Wenn ich das Gerät ohne Garantie weitergenutzt hätte, hätte ich mich damit dem Risiko ausgesetzt, im Falle eines Defekts keinen kurzfristigen Ersatz erhalten zu können. Das ist der Grund, weshalb ich ein neues Gerät angefordert habe.
Der Hardware-Erneuerungsprozess in Kürze
Ich habe das entsprechende Formular ausgefüllt und die gewünschte Notebook-Kategorie benannt
Nach 3 Werktagen ist das neue Gerät eingetroffen
Ich habe es über Nacht Zimmertemperatur annehmen lassen
Wir können zwischen verschiedenen Modellen von Lenovo und Apple wählen, welche mit der Zeit erneuert werden. Ich habe mich für ein Mainstream Modell entschieden, welches in meinem konkreten Fall ein Lenovo T14 Gen4 mit 32 GB RAM, 13th Gen Intel(R) Core(TM) i7-1365U und 500 GB NVMe ist.
Dieses Gerät ist nicht brandneu, doch dies ist in meinen Augen auch nicht erforderlich. Es besitzt noch 22 Monate Garantie und es gefällt mir, nun ein 14-Zoll-Gerät zu haben.
Reibungslose Inbetriebnahme
Auspacken
Einschalten
Anweisungen auf dem Bildschirm befolgen
Mit dem lokalen Netzwerk verbinden
VPN-Verbindung herstellen
Kerberos-Zugangsdaten eintippen
Zwei-Faktor-Token bestätigen
LUKS-Passwort für Festplattenverschlüsselung eingeben
Zum Schluss nochmal dnf -y up laufen lassen
Fertig
Nach nicht ganz 30 Minuten kann ich nun mit Fedora 41 CSB arbeiten.
Wir können unsere Linux-Laptops mit Deja-Dup sichern. Ich konnte die Daten von meinem P1 einfach auf dem neuen Gerät wiederherstellen.
Mein altes Gerät wurde Anfang der Woche vom Paketdienst abgeholt und befindet sich bereits auf dem Weg zurück nach Brno.
Tja, die Umstellung verlief tatsächlich so langweilig und problemlos, so dass ich jetzt schon am Ende bin.
Wie sind eure Erfahrungen? Wird der Hardwareaustausch bei euch ähnlich durchgeführt? Klappt dies ebenfalls so reibungslos? Wenn ihr eure Erfahrungen teilen möchtet, könnt ihr dazu gern die Kommentarfunktion nutzen.
Bislang erhält Thunderbird nur ein großes Update pro Jahr. Ab diesem März wird es auf Wunsch Feature-Updates im Monats-Takt geben, wie man es bereits von Firefox kennt.
Bereits vor knapp zwei Jahren hatte ich zum ersten Mal darüber berichtet, dass MZLA plant, einen monatlichen Release-Zyklus für Feature-Updates einzuführen, wie man es auch von Firefox kennt. Nun ist es soweit: Ab März 2025 mit Veröffentlichung von Thunderbird 136 werden die monatlichen Feature-Updates zum Standard.
Doch was bedeutet das genau? Neue Nutzer, welche sich Thunderbird über die Website herunterladen wollen, werden ab dann standardmäßig die Version von Thunderbird erhalten, welche dem neuen Release-Modell folgt. Für bestehende Nutzer ändert sich nichts. Wer derzeit Thunderbird auf dem sogenannten ESR-Kanal nutzt und damit ein Feature-Update pro Jahr und dazwischen lediglich Sicherheits- und Bugfix-Updates erhält, wird weiterhin auf diesem Veröffentlichungskanal bleiben.
Für die Zukunft ist es denkbar, dass über Benachrichtigungen innerhalb von Thunderbird ESR ein Wechsel der Thunderbird-Version beworben wird. Eine automatische Umstellung ist nicht geplant.
Mit Veröffentlichung von Thunderbird 136 wird sich dann auch die Berichterstattung auf diesem Blog ändern. Wie bei Firefox ESR werde ich nicht länger über neue Versionen auf dem ESR-Kanal berichten, sondern stattdessen ausschließlich über Updates auf dem Release-Kanal, der monatliche Feature-Updates bringt. Aber natürlich werde ich auch weiterhin über Sicherheits- und Bugfix-Updates auf dem neuen Release-Kanal berichten.
Die MZLA Technologies Corporation hat mit Thunderbird 128.6.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.
Neuerungen von Thunderbird 128.6.1
Mit Thunderbird 128.6.1 hat die MZLA Technologies Corporation ein Update für seinen Open Source E-Mail-Client veröffentlicht. Die neue Version bringt mehrere Korrekturen für die Versionsreihe 128, welche sich in den Release Notes (engl.) nachlesen lassen.
Dieses Tutorial führt in den RHEL image mode ein und zeigt, wie ein solches Image in einer virtuellen Maschine (VM) installiert werden kann. Es wird ebenfalls gezeigt, wie ein installiertes Image aktualisiert und bei Bedarf zurückgerollt werden kann.
Während diese Einführung in Deutsch gehalten ist, liegen die Dokumentation und weitere verwendete Quellen ausschließlich in englischer Sprache vor.
Das Tutorial richtet sich in erster Linie an Sysadmins, die bereits Erfahrung mit dem Betrieb von RHEL oder einer verwandten Enterprise Linux Distribution haben. Es bietet keine allgemeine Einführung in die Installation und den Betrieb von Red Hat Enterprise Linux.
Zum Inhalt
Die folgende Liste bietet einen Überblick über den Inhalt:
RHEL image modeist eine Technology Preview und (RHEL image mode ist bereits GA; lediglich der in diesem Tutorial verwendete bootc-image-builder ist noch eine Technology Preview) stellt eine neue Methode dar, um RHEL zu konfigurieren, installieren bzw. deployen und zu verwalten.
Durch Nutzung von Container-Tools wird ein Container-Image erstellt, welches neben dem RHEL-Userland auch den RHEL-Kernel, Boot Loader, Firmware und Treiber umfasst. Dieses RHEL-Container-Image (auch RHEL Bootc Image genannt) kann anschließend genutzt werden, um RHEL im Datacenter oder in der Cloud – auf Bare-Metal-Servern, virtuellen Maschinen oder Edge-Geräten zu deployen. Das RHEL-Container-Image kann direkt als Container ausgeführt werden, um die Funktionalität zu testen. Für das Deployment kann das Container-Image in ein Disk-Image für die entsprechende Zielplattform konvertiert werden. Ein installiertes oder als Disk-Image provisioniertes System läuft anschließend nativ auf der Hardware bzw. in der virtuellen Maschine und wird dort nicht als Container ausgeführt.
Konsolidierung von Bereitstellungsprozessen
In vielen Unternehmen kommen heute neben klassischen virtuellen Maschinen auch Linux-Container zum Einsatz. RHEL image mode bietet die Möglichkeit, Bereitstellungsprozesse zu konsolidieren, indem für die Bereitstellung von RHEL-Images die gleichen Werkzeuge genutzt werden, wie für die Bereitstellung von Container-Images für Anwendungen.
Immutable RHEL
Mit Ausnahme von /etc und /var ist das Wurzel-Dateisystem in RHEL image mode immutable (read-only).
Anwendungen und Updates werden durch aktualisierte RHEL-Container-Images verteilt. Ein provisioniertes System lädt dazu das aktualisierte Image auf die lokale Festplatte und startet dieses nach einem Neustart. Im Fehlerfall kann durch einen weiteren Neustart einfach das vorherige Image gestartet werden. So können fehlgeschlagene Updates einfach zurückgerollt werden.
Dies bietet dem Admin die Sicherheit, bei Bedarf zum vorherigen Zustand zurückkehren zu können, ohne dafür auf VM-/Storage-Snapshots oder andere Mechanismen außerhalb des Betriebssystems zurückgreifen zu müssen.
Deklarative Konfiguration des Betriebssystems
RHEL image mode macht es einfach, zu konfigurieren und zu verfolgen, welche Pakete in einem Basis-Image enthalten sind und wann welche Pakete hinzugefügt wurden.
Red Hat veröffentlicht in der Container-Registry registry.redhat.ioRHEL Bootc Base Images, welche die Basis für eigene Images darstellen. Zu jeder Version wird eine Liste der enthaltenen Pakete veröffentlicht. Diese ist über den Red Hat Ecosystem Catalog einsehbar:
Hier ist zu beachten, dass obwohl amd64 als Architektur ausgewählt wurde, die Liste Pakete aller verfügbaren Architekturen zeigt. Natürlich sind im Basis-Image nicht 2302 Pakete enthalten. Die Filtermöglichkeiten und die Ergebnisliste zeigen leider unerwartete Ergebnisse. Ich habe dies bereits intern gemeldet und hoffe, dass sich bald jemand der Sache annimmt.
Das in obiger Abbildung gezeigte Image enthält für die amd64-Architektur 441 Pakete. Vergleiche ich dies mit zwei meiner RHEL 9 Installationen, die auf der Minimalinstallation basieren, so umfassen diese 591 bzw. 510 Pakete. Der Vergleich hinkt allerdings, da ich auf den RHEL package mode Installationen bereits weitere Software nachinstalliert habe. Ich bin jedoch erfreut, dass das Basis-Image nicht mehr Pakete als eine Minimalinstallation enthält.
Pakete, die zusätzlich hinzugefügt werden sollen, werden im Containerfile aufgeführt, welches üblicherweise einer Versionskontrolle unterliegt. Änderungen können so jederzeit nachvollzogen werden.
Meine Laborumgebung besteht aus zwei virtuellen Maschinen, welche auf einem Laptop ausgeführt werden. Beide VMs verfügen über 2 vCPU, 8 GB RAM und 40 GB Speicher.
Auf VM 1 werden folgende Tätigkeiten ausgeführt:
Erstellung und Ausführung einer einfachen Container-Registry
Erstellung und Pflege eines oder mehrerer rhel-bootc-Container-Images
Erstellung von Disk-Images
Anhand von VM 2 werden folgende Dinge demonstriert:
Installation von RHEL image mode
Aktualisierung der Installation
Wechsel des verwendeten Images
Rollback
Die in diesem Tutorial verwendeten Containerfiles, Dateien und Skripte habe ich in einem Git-Repository gesammelt. Fühlt euch frei, die dortigen Dateien auf eigene Gefahr für eigene Versuche zu verwenden. Repository-URL: https://github.com/tronde/image-mode-demo
RHEL Bootc Image erstellen
Dieser Abschnitt wurde aus Kapitel 2 der Dokumentation Using image mode for RHEL to build, deploy, and manage operating systems abgeleitet. In ihm wird das RHEL-Container-Image erstellt, welches im nächsten Schritt für das Deployment in einer VM vorbereitet wird. Dieser Abschnitt behandelt folgende Schritte:
Containerfile(5) erstellen
Container-Image mit podman-build(1) erstellen
Container-Image auf dem Build-System testen
Containerfile
Mit dem folgenden Containerfile(5) wird konfiguriert, wie das RHEL Bootc Base Image ‚rhel-bootc:9.5‚ angepasst werden soll:
Die Dienste httpd und sshd werden aktiviert, damit sie nach dem Boot-Vorgang automatisch starten
Die im Containerfile aufgeführten Pakete sind eine persönliche Auswahl, die ich gern auf meinen Systemen habe. Ihr könnt hier natürlich die Pakete eurer Wahl eintragen.
Für dieses Tutorial installiere ich den Dienst httpd. Das von dem Image provisionierte System wird also einen Webserver hosten. Dass ich die index.html-Datei ebenfalls dem Image hinzufüge, soll mir lediglich den späteren Test in diesem Tutorial vereinfachen. Je nach Aufbau, Inhalt und Änderungsrate der auszuliefernden Webseite bzw. Webanwendung ist es nicht sinnvoll, diese in das Image zu integrieren.
Build
Login registry.redhat.io
Bevor das erste Container-Image erstellt werden kann, ist eine Anmeldung an der Container-Registry registry.redhat.io notwendig:
$ podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
Mit dem folgenden Befehl kann nun ein Image aus obigen Containerfile erstellt werden:
$ time podman build -t localhost/rhel9.5-bootc:test .
…
Successfully tagged localhost/rhel9.5-bootc:test
c958185aa4c578af37b5bca796c7c5e50a270f7b7de38126c31fa6ab97046f41
real 2m52.574s
user 2m31.787s
sys 0m59.680s
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test c958185aa4c5 40 seconds ago 1.68 GB
registry.redhat.io/rhel9/rhel-bootc 9.5 7cf5466a7756 2 days ago 1.56 GB
Das Container-Image wird unter dem Namen localhost/rhel9.5-bootc:test im lokalen Dateisystem gespeichert.
Der Build-Vorgang dauerte insgesamt knapp 3 Minuten. Darin ist die Zeit zum Herunterladen des Basis-Image registry.redhat.io/rhel9/rhel-bootc:9.5 enthalten. Ist dieses Image bereits vorhanden, dauert der Build-Vorgang nur knapp über 1 Minute.
Test
Der nun folgende Code-Block zeigt, wie das soeben erstellte Container-Image mit Podman im interaktiven Modus gestartet werden kann. Es wird geprüft, ob die index.html-Datei vorhanden ist und wie viele Pakete das Image enthält.
$ podman run -it --rm --name mybootc localhost/rhel9.5-bootc:test /bin/bash
bash-5.1# ls -l /var/www/html
total 4
-rw-r--r--. 1 root root 342 Jan 11 11:20 index.html
bash-5.1# rpm -qa | wc -l
465
bash-5.1#
Als nächste teste ich, ob die index.html-Datei auch ausgeliefert wird:
$ podman run -d --rm -p 127.0.0.1:8888:80 --name mybootc localhost/rhel9.5-bootc:test
fa9c1f5110cd58c3f28760fb5a5d69cdc4595a5cba2f29ff67f85eaa076204ab
$ curl http://127.0.0.1:8888
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Bootc Demo Page</title>
</head>
<body>
<p>Diese Seite wird von einem Webserver ausgeliefert, der mit RHEL Bootc Image Mode bereitgestellt wurde.</p>
</body>
</html>
Test erfolgreich! Die konfigurierte Webseite wird wie erwartet ausgeliefert. Der Container wird mit podman stop mybootc gestoppt und der Test ist beendet.
Zwischenfazit
Bis hier wurde ein Containerfile erstellt, welches das zu verwendende Basis-Image, die zusätzlich zu installierenden Pakete und die auszuführenden Dienste definiert. Mit Hilfe dieses Containerfiles und Podman wurde anschließend das Container-Image localhost/rhel9.5-bootc:test erzeugt. Mit einem einfachen Test konnte auf dem Build-System verifiziert werden, dass die index.html-Datei wie gewünscht ausgeliefert wird.
Das Image enthält keinerlei Passwörter oder SSH-Schlüssel. Es sind somit bisher keinerlei Geheimnisse enthalten, die mit dem Image verloren gehen könnten.
Verglichen mit einer klassischen RHEL-Minimalinstallation, die als Basis für ein Golden-Image dient, konnte der Vorgang deutlich schneller abgeschlossen werden.
ISO-Image mit dem bootc-image-builder erstellen
Der bootc-image-builder ist eine Container-Variante des RHEL Image Builder. Mit diesem wird in den folgenden Schritten ein ISO-Image aus dem zuvor erstellten Container-Image erzeugt. Mit dem ISO-Image wird anschließend eine Installation in einer VM durchgeführt.
Mit dem bootc-image-builder können auch Disk-Images wie AMI, GCE, QCOW2, RAW und VMDK erzeugt werden. Ich habe mich für ISO entschieden, da dies am vielseitigsten verwendbar ist. Man kann damit VMs unter KVM/Qemu und VMware genauso installieren, wie Bare-Metal-Server.
Benutzer, Passwort und SSH-Schlüssel hinzufügen
Um sich nach der Installation interaktiv am System anmelden zu können, werden dem ISO-Image ein Benutzer mit Passwort und SSH-Schlüssel hinzugefügt. Dafür wird die folgende Datei toml.config genutzt:
$ cat config.toml
[[customizations.user]]
name = "alice"
password = "changeme"
key = "ssh-ed25519 AAAAC3NzaC…cr alice@example.com"
groups = ["wheel"]
Durch Hinzufügen des Benutzers zur Gruppe wheel darf dieser privilegierte Kommandos mittels sudo ausführen.
Das Container-Image in den passenden Benutzerkontext kopieren
Das Image localhost/rhel9.5-bootc:test wurde mit einem rootless-Benutzer erstellt. Der Befehl im folgenden Abschnitt muss jedoch mit root-Rechten ausgeführt werden. Rootful-Podman kann jedoch nicht auf das Image zugreifen, welches wir mit rootless-Podman erstellt haben. Der Vorgang würde fehlschlagen mit der Meldung: Error: localhost/rhel9.5-bootc:test: image not known.
Um dies zu verhindern, gibt es zwei Möglichkeiten. Möglichkeit 1 bietet sich an, wenn man das ISO-Image auf dem gleichen System wie das Container-Image erzeugen möchte. Hierbei wird das Container-Image einfach in den passenden Benutzerkontext kopiert. Die zweite Möglichkeit besteht darin, das Container-Image in eine Container-Registry zu pushen, aus der es dann im nächsten Schritt wieder gepullt werden kann.
Möglichkeit 1
Das Container-Image wird mit folgendem Befehl aus dem Kontext des Benutzers ‚alice‘ in den Kontext des Benutzers ‚root‘ kopiert.
$ podman image scp alice@localhost::rhel9.5-bootc:test
…
$ sudo podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/rhel9.5-bootc test fb6237fff684 21 minutes ago 1.68 GB
Selbstverständlich kann das Container-Image auch in einer Container-Registry gespeichert und im root-Kontext von dort wieder heruntergeladen werden. Für die spätere Aktualisierung eines installierten RHEL image mode Systems ist die Nutzung einer Container-Registry von Vorteil.
How to implement a simple personal/private Linux container image registry for internal use beschreibt die Einrichtung einer einfachen Registry. Ich habe die auszuführenden Schritte in dem Skript create_simple_container_registry.sh zusammengefasst. Die zur Ausführung notwendigen Parameter werden in der Datei registry.vars konfiguriert. Diese Datei ist bereits mit Standardwerten gefüllt, die direkt verwendet werden können. Installiert und konfiguriert wird die Registry mit dem Kommando:
$ sudo bash create_simple_container_registry.sh
Ich trage die IP-Adresse und den Hostnamen meiner VM 1 in die Datei /etc/hosts ein, damit die Namensauflösung funktioniert. Der folgende Code-Block zeigt, wie das Image localhost/rhel9.5-bootc in die Registry gepusht wird.
Die Option --tls-verfiy=false ist notwendig, da ein selbstsigniertes TLS-Zertifikat verwendet wird. Mit dem folgenden Befehl kann überprüft werden, ob sich das Image in der Registry befindet.
Der folgende Code-Block zeigt, wie mit dem bootc-image-builder eine ISO-Datei erzeugt wird, die sich für eine RHEL-Installation in einer Offline-Umgebung eignet. Der Befehl muss mit sudo ausgeführt werden, da erweiterte Benutzerrechte erforderlich sind.
Da das Container-Image des bootc-image-builder noch nicht lokal vorliegt, muss zuerst ein Login bei registry.redhat.io erfolgen. Dies wurde weiter oben bereits für den rootless-Benutzer durchgeführt, muss für den rootful-Benutzer jedoch wiederholt werden, da Logins nicht zwischen verschiedenen Benutzerkontexten geteilt werden.
Achtung: Der folgende Befehl funktioniert nur, wenn das Image localhost/rhel9.5-bootc:test für root verfügbar ist. Dies kann durch eine der Methoden, die im vorherigen Abschnitt beschrieben wurden, sichergestellt werden. Ich habe in diesem konkreten Fall Möglichkeit 1 verwendet.
$ sudo podman login registry.redhat.io
Username: alice
Password:
Login Succeeded!
$ mkdir output
$ time sudo podman run \
> --rm \
> -it \
> --privileged \
> --pull=newer \
> --security-opt label=type:unconfined_t \
> -v /var/lib/containers/storage:/var/lib/containers/storage \
> -v $(pwd)/config.toml:/config.toml \
> -v $(pwd)/output:/output \
> registry.redhat.io/rhel9/bootc-image-builder:latest \
> --type iso \
> --config /config.toml \
> --local \
> localhost/rhel9.5-bootc:test
…
real 22m31.407s
user 0m1.997s
sys 0m2.049s
$ ls -lh output/bootiso/
total 2.4G
-rw-r--r--. 1 root root 2.4G Jan 11 14:26 install.iso
Nun zur Erklärung des Ganzen:
Der Login erfolgt, um das bootc-image-builder-Image herunterladen zu können
Im Projektverzeichnis wird das Verzeichnis output erstellt, welches die ISO-Datei enthalten wird
Nun folgt ein ziemlich langer Aufruf von podman run
Falls in registry.redhat.io eine neuere Version des bootc-image-builder gefunden wird, wird diese heruntergeladen und genutzt
bootc-image-builder muss mit erhöhten Rechten ausgeführt werden, weshalb die Ausführung mittels sudo und die Option --privileged erforderlich sind
Ort der config.toml und Verzeichnis für das ISO werden dem Container als Volume zugänglich gemacht
Mit --type iso wird festgelegt, dass eine ISO-Datei erstellt werden soll
Die Option --local gibt an, dass das lokal existierende Image localhost/rhel9.5-bootc.test verwendet und dies nicht aus einer Registry geholt werden soll
Dass der Vorgang ganze 22 Minuten dauerte, ist den 2 vCPU-Kernen und den 8 GB RAM meiner VM geschuldet. Während der Arbeitsspeicher gerade ausreichend war, dürften weitere CPU-Kerne den Vorgang deutlich beschleunigen.
Das nun erstellte ISO kann zur Installation in VM 2 verwendet werden.
Offline-Installation mit dem RHEL image mode
Das im vorherigen Abschnitt erstellte Disk-Image install.iso wird nun verwendet, um VM 2 zu installieren. Die Installation läuft wie eine normale unbeaufsichtigte Anaconda-Installation ab.
In der Datei toml.config wurde ein Benutzer mit einem SSH-Schlüssel spezifiziert, der nun zum Login in das neue System verwendet werden kann.
$ ssh -o StrictHostKeyChecking=no alice@vm2.example.com
Warning: Permanently added 'vm2.example.com' (ED25519) to the list of known hosts.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 7.1M 1 loop
sr0 11:0 1 2.4G 0 rom
zram0 251:0 0 7.8G 0 disk [SWAP]
vda 252:0 0 30G 0 disk
├─vda1 252:1 0 1G 0 part /boot
├─vda2 252:2 0 1G 0 part [SWAP]
└─vda3 252:3 0 28G 0 part /var
/sysroot/ostree/deploy/default/var
/etc
/sysroot
$ $ mount | grep -E '"/"|var|sysroot|etc'
/dev/vda3 on /sysroot type ext4 (ro,relatime,seclabel)
composefs on / type overlay (ro,relatime,seclabel,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on)
/dev/vda3 on /etc type ext4 (rw,relatime,seclabel)
/dev/vda3 on /sysroot/ostree/deploy/default/var type ext4 (rw,relatime,seclabel)
/dev/vda3 on /var type ext4 (rw,relatime,seclabel)
$ less /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[jkastnin@localhost ~]$ systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-01-14 15:29:07 UTC; 28min ago
Docs: man:httpd.service(8)
Main PID: 829 (httpd)
…
Da ich im Vorfeld keine genaueren Angaben gemacht habe, wurde der Datenträger automatisch partitioniert. Die Installation lässt sich durch Kickstart-Dateien steuern. Dazu wird der Inhalt der Kickstart-Datei in die Datei config.toml eingefügt. Siehe hierzu Kapitel 4.9. Using bootc-image-builder to build ISO images with a Kickstart file in der RHEL-Dokumentation.
Fazit nach der Installation von RHEL image mode
Mit rootless podman wurde ein rhel9.5-bootc:test Image erstellt
Mit dem bootc-image-builder wurde ein ISO-Image erstellt, welchem ein Benutzer mit Passwort und öffentlichem SSH-Schlüssel hinzugefügt wurde und welches sich für die Installation von Offline-Systemen eignet
Das ISO-Image wurde genutzt, um RHEL image mode in einer VM zu installieren
Test von Login und einiger weniger Kommandos
Der konfigurierte Webserver wird ausgeführt und liefert die kleine Beispielwebseite aus
Auf dem Weg hier her wurde erklärt, wie Container-Images mittels podman-image-scp(1) ohne Container-Registry zwischen Benutzerkontexten und Hosts kopiert werden können. Es wurde gezeigt, wie eine einfache Container-Registry betrieben und genutzt werden kann.
Zu den Aufgaben des IT-Betriebs gehört es, Betriebssysteme zu aktualisieren, ihre Konfiguration neuen Anforderungen anzupassen und im Fehlerfall die letzten Änderungen schnell rückgängig machen zu können. Diesen Aufgaben widmen sich die beiden folgenden Abschnitte.
Bootc Image Installation aktualisieren bzw. Konfiguration ändern
Während RHEL package mode Systeme zur Laufzeit mit DNF bzw. YUM aktualisiert werden und mit diesen Werkzeugen Software (de-)installiert wird, ist der Ablauf bei RHEL image mode Systemen anders:
Das RHEL Bootc Image wird aktualisiert
Das aktualisierte Container-Image wird in einer Registry verfügbar gemacht
Das aktualisierte Image wird in den Staging-Bereich des laufenden RHEL image mode Systems geladen
Durch einen Neustart wird das aktualisierte Image geladen
Bei Bedarf, z.B. bei auftretenden Problemen, kann das vorherige Image geladen werden
Aktualisierung des RHEL Bootc Image
Ich möchte die Pakete lsof, strace und tcpdump doch nicht in meiner Standardinstallation haben und sie aus der existierenden Installation entfernen. Deshalb kommentiere die entsprechenden Zeilen aus:
Als Nächstes wird ein neues Image erstellt und in die Registry gepusht. Diesmal verwende ich den Tag 0.0.1, um für den Verlauf dieses Tutorials leichter den Überblick zu behalten:
Das zu verwendende Image aus dem System heraus wechseln
Der nun folgende Schritt wird in dem laufenden RHEL image mode System in VM 2 ausgeführt. In der RHEL-Dokumentation ist dieser Schritt in Abschnitt 8.1. Switching the container image reference beschrieben.
Für diesen Schritt ist eine funktionierende Namensauflösung zwischen VM 1 und VM 2 erforderlich. In der Laborumgebung kann dies mithilfe der Datei /etc/hosts erfolgen. Da in der Registry ein selbstsigniertes Zertifikat verwendet wird und das Kommando bootc keine Option --tls-verify besitzt, muss eine insecure registry in VM 2 konfiguriert werden. Der folgende Codeblock zeigt den Inhalt der Datei, mit der die insecure registry konfiguriert wird:
Da bootc auch nicht über ein Login-Kommando verfügt und keinen Zugriff auf die Login-Informationen von Podman hat, wird in VM 2 ein Pull-Secret für bootc konfiguriert. Dazu wird eine Zeichenkette bestehend aus Benutzername:Passwort in Base-64 kodiert und zusammen mit der Registry-URL in die Datei /etc/ostree/auth.json geschrieben. Der folgende Code-Block zeigt dies mit den Beispielwerten aus diesem Tutorial:
Nach dem Wechsel befindet sich das ab nun zu verwendende Image zunächst im Staging-Bereich des lokalen Systems und wird beim nächsten Neustart aktiviert. Der Befehl bootc status gibt dazu übersichtlich Informationen aus, welches Image gestaged ist und welches aktuell verwendet wird:
~]# bootc status
Current staged image: vm1.example.com:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current booted image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
No rollback image present
Nach einem Neustart wird der Status mit bootc status erneut kontrolliert und wir sehen, dass nun das Image aus der Registry verwendet wird und das vorherige Image für ein Rollback vorgehalten wird:
~]$ sudo bootc status
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: localhost/rhel9.5-bootc:test
Image version: 9.20250109.0 (2025-01-11 12:40:29.172146867 UTC)
Image digest: sha256:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54
Automatische Aktualisierungen und wie man sie deaktivieren kann
Auf RHEL image mode Systemen existiert ein systemd.timer(5), welcher automatische Updates anstößt. Folgender Code-Block zeigt die Timer- und Service-Unit in VM 2:
$ systemctl status --no-pager bootc-fetch-apply-updates.{timer,service}
● bootc-fetch-apply-updates.timer - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.timer; disabled; preset: disabled)
Active: active (waiting) since Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Until: Wed 2025-01-15 08:29:37 UTC; 1h 1min ago
Trigger: Wed 2025-01-15 10:28:13 UTC; 57min left
Triggers: ● bootc-fetch-apply-updates.service
Docs: man:bootc(8)
Jan 15 08:29:37 localhost systemd[1]: Started Apply bootc updates.
○ bootc-fetch-apply-updates.service - Apply bootc updates
Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.service; static)
Active: inactive (dead)
TriggeredBy: ● bootc-fetch-apply-updates.timer
Docs: man:bootc(8)
Ein Blick in die Service-Unit verrät, was passiert, wenn diese getriggert wird:
Prüft, ob ein neues Image in der Container-Registry verfügbar ist (Prüfung efolgt auf Digest nicht auf Tag)
Falls ein neues Image verfügbar ist, wird dieses gestaged
Der Host wird automatisch neugestartet, um das neue Image zu laden
Möchte man Aktualisierungen durch andere Verfahren steuern, kann die automatische Aktualisierung wie folgt gestoppt werden:
$ systemctl mask bootc-fetch-apply-updates.timer
Rollback
Angenommen, das System soll auf das zuvor verwendete Conatiner-Image zurückgerollt werden. So kann man sich zuvor mit bootc status einen Überblick verschaffen, welches Image als Rollback-Image eingetragen ist:
Euch fällt evtl. auf, dass zwei Images den gleichen Tag, aber unterschiedliche SHA-256-Prüfsummen haben, und zwei Tags die gleiche Prüfsumme und unterschiedliche Tags. Lasst euch davon bitte nicht irritieren; dies ist nur meiner Spielerei geschuldet.
Bei einem Rollback wird das Image hinter dem Eintrag Current rollback image als Boot-Image verwendet. Ein Rollback wird mit folgendem Kommando ausgeführt:
$ sudo bootc rollback
Next boot: rollback deployment
Nur den Neustart muss man noch selbst durchführen. Nach dem Neustart sieht der Status wie folgt aus:
$ sudo bootc status
[sudo] password for jkastnin:
No staged image present
Current booted image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-14 19:58:27.484294313 UTC)
Image digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9
Current rollback image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.1
Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Anhand der SHA-256-Prüfsumme ist zu erkennen, dass das vorherige rollback image nun den Platz mit dem vorherigen booted image gewechselt hat. Ein weiterer Aufruf von bootc rollback führt zu einem weiteren Image-Wechsel.
Hinweis: Wenn nach einem Update ein Rollback durchgeführt wird und der Systemd-Timer für automatische Updates nicht deaktiviert wurde, führt dieser Timer bei Ablauf zu einem erneuten Update des Systems.
Ende
Hier endet die Einführung in RHEL image mode. Wer dem Tutorial aufmerksam gefolgt ist, sollte an dieser Stelle in der Lage sein:
RHEL Bootc Images zu erstellen
Eine einfache Container-Registry mit Podman zu betreiben
Mit bootc-image-builder Disk-Images zu erstellen
Ein System im RHEL image mode zu installieren
Das installierte System zu aktualisieren
Zu einem anderen Image zu wechseln
Ein Rollback auf das vorherige Image durchzuführen
Wenn euch diese Einführung gefallen hat, freue ich mich, wenn ihr sie mit euren Netzwerken teilt. Nutzt gern die Kommentarfunktion, um mich wissen zu lassen, wie euch diese Einführung gefallen hat.
Falls ihr euch weitere Artikel rund um den RHEL image mode wünscht, teilt mir dies gern ebenfalls über die Kommentarfunktion mit.
Die Geschwindigkeit und Stabilität der Internetverbindung auf einem Ubuntu-System können durch die Wahl eines schnellen und zuverlässigen Nameservers erheblich verbessert werden. In diesem Artikel zeige ich, wie man den Nameserver auf Ubuntu für IPv4 und IPv6 konfigurieren und optimieren kann.
Installation
Durch die Nutzung schneller öffentlicher DNS-Server wie Google DNS können die Ladezeiten von Webseiten und die allgemeine Netzwerkperformance gesteigert werden.
Hierzu geht man in die Netzwerkeinstellungen des Systems und trägt die IP-Adressen der DNS-Server für IPv4 (8.8.8.8, 8.8.4.4) und für IPv6 (2001:4860:4860::8888, 2001:4860:4860::8844), jeweils durch ein Komma getrennt, im Kabelnetzwerk und WLAN ein.
Die Optimierung der Nameserver auf Ubuntu ist ein einfacher, aber effektiver Schritt, um die Geschwindigkeit und Zuverlässigkeit der Internetverbindung zu erhöhen. Mit schnellen DNS-Servern wie Google DNS kommt es zu einer spürbaren Verbesserung bei der Webnutzung.
Mobilfunk ist eine unverzichtbare Technologie unseres Alltags – und gleichzeitig ein faszinierendes Beispiel für moderne Funksysteme. Während wir bei WLAN als Endnutzer oft sowohl das Endgerät als auch die Basisstation, den sogenannten Access Point, betreiben, ist der Mobilfunk weitaus komplexer und auch fachlich schwieriger zugänglich. Die Mobilfunknetze werden von großen Telekommunikationsunternehmen im lizenzierten Spektrum betrieben, und selbst auf unseren Telefonen bleibt die Interaktion mit dem Mobilfunknetz minimal. Meist reicht es, die SIM-Karte einzulegen, und schon funktioniert alles. Was viele nicht wissen: Auch Betriebssysteme wie Android oder iOS kommunizieren nicht direkt mit dem Mobilfunknetz. Diese Aufgabe übernimmt ein spezieller Chip, der sogenannte Baseband-Prozessor.
Open Source und Mobilfunk: Das Osmocom-Projekt
In der Open-Source-Welt gibt es nur wenige Projekte, die diese Funktechnologie zugänglich machen. Eines herausragendes Beispiel ist das Osmocom-Projekt. Schon ein erster Blick auf die Übersicht zeigt, dass es nicht "die eine" Mobilfunksoftware gibt. Vielmehr müssen viele verschiedene Komponenten ineinandergreifen und wie in einem Orchester zusammenspielen, um ein funktionierendes Netz bereitzustellen.
Sicherheitsforschung im Mobilfunk
Der Blick auf die Sicherheit sollte im Mobilfunk nicht vernachlässigt werden. So mag es überraschen, dass ältere GSM-Mobiltelefone deutlich unsicherer sind, als moderne Geräte, die auf LTE und 5G basieren. Hintergrund sind die verbesserten kryptographischen Verfahren.
Im Risikozone-Podcast haben wir uns in der Episode 65 mit der Mobilfunksicherheit genauer beschäftigt. Wir sprechen mit Adrian Dabrowski und Gabriel Gegenhuber über ihre Forschungsarbeiten und geben gemeinsam Einblick in eine Technologie, die als selbstverständlich wahrgenommen wird, aber in der Arbeitsweise völlig anders herangeht, als wir es aus der IETF-Welt mit TCP/IP & Co. gewöhnt sind.
Zusätzlich stellen Gabriel und Adrian das Open-Source-Projekt MobileAtlas vor. Dieses Projekt, inspiriert vom RIPE Atlas, widmet sich der Vermessung der Mobilfunkqualität und schafft eine interessante Plattform für weitere Analysen und Forschungsarbeiten.
Die 90-minütige Episode ist auf der Podcastseite oder direkt unter diesem Artikel abrufbar.