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:

• Was ist der RHEL image mode?
  • Konsolidierung von Bereitstellungsprozessen
  • Immutable RHEL
  • Deklarative Konfiguration des Betriebssystems
• Voraussetzungen
• Meine Laborumgebung
• RHEL Bootc Image erstellen
  • Containerfile
  • Build
    • Login registry.redhat.io
    • Image erstellen
  • Test
• Zwischenfazit
• ISO-Image mit dem bootc-image-builder erstellen
  • Benutzer, Passwort und SSH-Schlüssel hinzufügen
  • Das Container-Image in den passenden Benutzerkontext kopieren
    • Möglichkeit 1
    • Möglichkeit 2
  • Der bootc-image-builder in Aktion
• Offline-Installation mit dem RHEL image mode
• Fazit nach der Installation von RHEL image mode
• Systemupdate und Rollback
  • Bootc Image Installation aktualisieren bzw. Konfiguration ändern
    • Aktualisierung des RHEL Bootc Image
    • Das zu verwendende Image aus dem System heraus wechseln
    • Automatische Aktualisierungen und wie man sie deaktivieren kann
  • Rollback
• Ende
• Quellen und weiterführende Links

Was ist der RHEL image mode?

RHEL image mode ist eine Technology Preview und 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.io RHEL 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.

Weitere Informationen bietet das Kapitel 1 in Using image mode for RHEL to build, deploy, and manage operating systems.

Voraussetzungen

Um die in diesem Tutorial gezeigten Schritte selbst ausführen zu können, werden folgende Dinge benötigt:

• Ein registriertes RHEL 9 System
  • mit einer beliebigen RHEL Subskription,
  • dem installierten Meta-Paket container-tools
• Zugriff auf registry.redhat.io
• Eine virtuelle Maschine oder einen Rechner, auf dem RHEL image mode installiert werden kann

Falls ihr gerade keine geeignete Laborumgebung zur Verfügung habt, könnt ihr den Image Mode auch in diesen interaktiven Labs ausprobieren:

• Introduction to image mode for Red Hat Enterprise Linux
• Day 2 operations with image mode for Red Hat Enterprise Linux

Meine Laborumgebung

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:

1. Containerfile(5) erstellen
2. Container-Image mit podman-build(1) erstellen
3. 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:

$ cat Containerfile 
FROM registry.redhat.io/rhel9/rhel-bootc:9.5
ADD index.html /var/www/html/index.html
RUN dnf -y install httpd \
    openssh-server \
    bind-utils \
    net-tools \
    chrony \
    vim-enhanced \
    man-pages \
    strace \
    lsof \
    tcpdump \
    bash-completion && \
    dnf clean all
RUN systemctl enable httpd sshd

1. Es wird eine index.html-Datei hinzugefügt
2. Die installierten Pakete werden aktualisiert
3. Weitere Pakete werden installiert
4. Der DNF-Paket-Cache wird entfernt
5. 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!

Weitere Unterstützung zur Anmeldung bietet: Red Hat Container Registry Authentication

Image erstellen

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

Wird kein Ziel-Benutzer spezifiziert, wird root als Ziel angenommen. Weitere Informationen zur Verwendung dieses Befehls bietet podman-image-scp(1) und der Artikel: How Podman can transfer container images without a registry?

Möglichkeit 2

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.

$ podman login --tls-verify=false vm1.example.com:5000
Username: registryuser
Password: 
Login Succeeded!
$ podman tag localhost/rhel9.5-bootc:test vm1.example.com:5000/rhel9.5-bootc:test
$ podman push --tls-verify=false jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:test
Getting image source signatures
…
Writing manifest to image destination

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.

$ curl -k -u registryuser:registrypass https://vm1.example.com:5000/v2/_catalog
{"repositories":["rhel9.5-bootc"]}

Der bootc-image-builder in Aktion

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:

1. Der Login erfolgt, um das bootc-image-builder-Image herunterladen zu können
2. Im Projektverzeichnis wird das Verzeichnis output erstellt, welches die ISO-Datei enthalten wird
3. 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.

Weitere Möglichkeiten zum Deployment von RHEL Bootc Images finden sich in der Dokumentation in Chapter 6. Deploying the RHEL bootc images. Darin findet sich auch ein Abschnitt, wie man das RHEL bootc image aus einer Registry mithilfe von Anaconda und Kickstart installiert.

Systemupdate und Rollback

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:

1. Das RHEL Bootc Image wird aktualisiert
2. Das aktualisierte Container-Image wird in einer Registry verfügbar gemacht
3. Das aktualisierte Image wird in den Staging-Bereich des laufenden RHEL image mode Systems geladen
4. Durch einen Neustart wird das aktualisierte Image geladen
5. 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:

$ cat Containerfile
FROM registry.redhat.io/rhel9/rhel-bootc:9.5
ADD index.html /var/www/html/index.html
RUN dnf -y install httpd \
    openssh-server \
    bind-utils \
    net-tools \
    chrony \
    vim-enhanced \
    man-pages \
#    strace \
#    lsof \
#    tcpdump \
    bash-completion && \
    dnf clean all
RUN systemctl enable httpd sshd

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:

$ podman build -t vm1.example.com:5000/rhel9.5-bootc:0.0.1 .
STEP 1/4: FROM registry.redhat.io/rhel9/rhel-bootc:9.5
STEP 2/4: ADD index.html /var/www/html/index.html
--> Using cache eb262e01451d150d95636b3771ca8b5985155edd45bcfef838726002f910a411
…
Successfully tagged vm1.example.com:5000/rhel9.5-bootc:0.0.1
ce3ec0f5ae5af0d27415c76aed480bfda51d39d5aeffdd78c7c06e29907c3d46

$ podman push --tls-verify=false vm1.example.com:5000/rhel9.5-bootc:0.0.1

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:

~]# cat /etc/containers/registries.conf.d/001-labregistry.conf
[[registry]]
location="vm1.example.com:5000"
insecure=true

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:

~]# echo -n "registryuser:registrypass" | base64 -w 0 ; echo
cmVnaXN0cnl1c2VyOnJlZ2lzdHJ5cGFzcw==

~]# cat /etc/ostree/auth.json 
{
	"auths": {
		"vm1.example.com:5000": {
			"auth": "cmVnaXN0cnl1c2VyOnJlZ2lzdHJ5cGFzcw=="
		}
	}
}

Es gibt verschiedene Möglichkeiten, das Pull-Secret zu hinterlegen:

• Manuell, wie gerade gezeigt
• Mit einer Automationslösung wie z.B. Ansible zur Laufzeit des Zielsystems
• Bei der Erstellung des Disk-Images mit bootc-image-builder
• Bei hinreichend gesicherter Container-Registry direkt im RHEL Bootc Image

Siehe für weitere Hinweise hierzu Abschnitt 11.2 bis 11.4 im Anhang Managing users, groups, SSH keys, and secrets in image mode for RHEL.

Nun können wir mit dem folgenden Befehl von Image vm1.example.com:5000/rhel9.5-bootc:test zu Image vm1.example.com:5000/rhel9.5-bootc:0.0.1 wechseln:

~]# bootc switch vm1.example.com:5000/rhel9.5-bootc:0.0.1
layers already present: 67; layers needed: 2 (37.5 MB)
Fetched layers: 35.74 MiB in 23 seconds (1.58 MiB/s)                                                                   Deploying: done (5 seconds)                                                                                        Pruned images: 1 (layers: 0, objsize: 0 bytes)
Queued for next boot: vm1.example.com:5000/rhel9.5-bootc:0.0.1
  Version: 9.20250109.0
  Digest: sha256:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9

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:

$ cat /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[Unit]
Description=Apply bootc updates
Documentation=man:bootc(8)
ConditionPathExists=/run/ostree-booted

[Service]
Type=oneshot
ExecStart=/usr/bin/bootc update --apply --quiet

Das Kommando hinter ExecStart=:

1. Prüft, ob ein neues Image in der Container-Registry verfügbar ist (Prüfung efolgt auf Digest nicht auf Tag)
2. Falls ein neues Image verfügbar ist, wird dieses gestaged
3. 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:

$ sudo bootc status
Current staged image: jkastnin-tpp1-rhel9-podman-1:5000/rhel9.5-bootc:0.0.2
    Image version: 9.20250109.0 (2025-01-15 09:36:38.866194063 UTC)
    Image digest: sha256:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7
Current booted 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
Current rollback 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

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.

Quellen und weiterführende Links

1. What does a „Technology Preview“ feature mean?
2. Technology Preview Features – Scope of Support
3. Image mode for RHEL: 4 key use cases for streamlining your OS
4. How to get list of the packages included in ‚Minimal Install‘ ? (Login notwendig)
5. How Podman can transfer container images without a registry?
6. How to implement a simple personal/private Linux container image registry for internal use
7. Using image mode for RHEL to build, deploy, and manage operating systems
8. Red Hat Container Registry Authentication
9. Composing a customized RHEL system image
10. Deploying a container image by using Anaconda and Kickstart
11. 8.5. Turning off automatic updates

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.

Fazit

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.

Der Beitrag Internet-Geschwindigkeit auf Ubuntu erhöhen erschien zuerst auf intux.de.

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.

Ein neuer adminForge Service kann ab sofort genutzt werden. pixelshot.it Pixelfed ist ein dezentraler Dienst zum Teilen von Bildern und Videos mit millionen Benutzern weltweit – eine freie Alternative zu Instagram. Ein Benutzer auf...

by adminForge.

Mozilla hat eine neue Erweiterungs-Schnittstelle vorgestellt, welche Entwickler von Firefox-Erweiterungen nutzen können, um Anwendungsfälle für Maschinelles Lernen und Künstliche Intelligenz lokal auszuführen.

Nutzer einer Nightly-Version von Firefox können ab sofort eine neue experimentelle Erweiterungs-Schnittstelle nutzen. Diese hat Mozilla auf seinem Blog vorgestellt.

Die Schnittstelle erlaubt die Nutzung jedes maschinellen Lernmodells, welches mit Transformers.js kompatibel ist, im Browser auszuführen, ohne dass dabei Anfragen an externe Server gesendet werden. Lediglich das verwendete Modell muss bei der ersten Nutzung heruntergeladen werden, ansonsten geschieht die Arbeit vollständig lokal.

Zwar können Webanwendungen bereits Transformers.js in JavaScript nutzen. Die Ausführung über Mozillas Erweiterungsschnittstelle bietet aber mehrere Vorteile: So wird die Inferenz-Runtime in einem eigenen isolierten Firefox-Prozess ausgeführt, was die Sicherheit und Robustheit verbessert. Die Modell-Dateien werden in einer IndexedDB gespeichert und über verschiedene Ursprünge hinweg gemeinsam genutzt. Außerdem erlauben Firefox-spezifische Leistungsverbesserungen eine verbesserte Performance.

Transformers.js verwendet „Aufgaben“, um Implementierungsdetails für die Ausführung bestimmter Arten von ML-Workloads zu abstrahieren. Für die erste Iteration stellt Firefox die folgenden Aufgaben zur Verfügung:

• text-classification – Zuweisung eines Labels oder einer Klasse zu einem gegebenen Text
• token-classification – Zuweisung eines Labels zu jedem Token in einem Text
• question-answering – Abrufen der Antwort auf eine Frage aus einem gegebenen Text
• fill-mask – Maskierung einiger Wörter in einem Satz und Vorhersage, welche Wörter diese Masken ersetzen sollen
• summarization – Erstellung einer kürzeren Version eines Dokuments unter Beibehaltung der wichtigen Informationen.
• translation – Konvertierung von Text von einer Sprache in eine andere
• text2text-generation – Konvertierung einer Textfolge in eine andere Textfolge
• text-generation – Erzeugen von neuem Text durch Vorhersage des nächsten Wortes in einer Sequenz
• zero-shot-classification – Klassifizierung von Text in Klassen, die während des Trainings nicht gesehen werden
• image-to-text – Ausgabe von Text aus einem gegebenen Bild
• image-classification – Zuweisung eines Labels oder einer Klasse für ein ganzes Bild
• image-segmentation – Unterteilung eines Bildes in Segmente, in denen jedes Pixel einem Objekt zugeordnet ist
• zero-shot-image-classification – Klassifizierung von Bildern in Klassen, die beim Training nicht gesehen werden
• object-detection – Identifizierung von Objekten bestimmter definierter Klassen in einem Bild
• zero-shot-object-detection – Identifizierung von Objekten von Klassen, die beim Training nicht gesehen werden
• document-question-answering – Beantwortung von Fragen zu Dokumentenbildern
• image-to-image – Umwandlung eines Quellbildes, damit es den Merkmalen eines Zielbildes oder eines Zielbildbereichs entspricht
• depth-estimation – Vorhersage der Tiefe von Objekten in einem Bild
• feature-extraction – Umwandlung von Rohdaten in numerische Merkmale, die verarbeitet werden können, wobei die Informationen im Originaldatensatz erhalten bleiben
• image-feature-extraction – Umwandlung von Rohdaten in numerische Merkmale, die unter Beibehaltung der Informationen im Originalbild verarbeitet werden können
• text-to-speech – Umwandlung von Text in Sprache

Für jede Aufgabe hat Mozilla ein Standard-Modell ausgewählt. Der Erweiterungs-Entwickler kann aber auf jedes Modell zurückgreifen, welches auf Hugging Face entweder von Mozilla oder Xenova veröffentlicht worden ist. Derzeit können nur Modelle dieser zwei Organisationen genutzt werden. Dass diese Einschränkung gelockert wird, ist für die Zukunft denkbar.

So einfach könnte beispielsweise Code zur Zusammenfassung von Text mit dem entsprechenden Standard-Modell aussehen:

async function summarize (text) {
  await browser.trial.ml.createEngine({ taskName: 'summarization' });
  const result = await browser.trial.ml.runEngine({ args: [text] });
  return result[0]['summary_text'];
}

Im Vergleich mit anderen WebExtension-Schnittstellen gibt es zwei wichtige Unterschiede: Zum einen kann die notwendige Berechtigung erst nach der Installation einer Erweiterung durch den Benutzer erteilt werden. Außerdem werden Änderungen der Schnittstelle in der Zukunt erwartet. Aus diesem Grund nutzt die Schnittstelle den browser.trial-Namespace, statt die Funktionen direkt in browser bereitzustellen. Damit wird die Erwartungshaltung entsprechend gesetzt, dass es sich hierbei um eine Art „Vorschau“ handelt und in Zukunft eher Anpassungen der Erweiterungen notwendig werden, als es bei WebExtensions normalerweise üblich ist.

Die KI-unterstützte Generierung eines Beschreibungstextes für Bilder in PDF-Dateien ist ein in Firefox von Haus aus integriertes Feature, welches unter der Haube aber auf genau die gleiche Weise funktioniert. Mozilla hat diesen Anwendungsfall zusätzlich auch noch in Form einer Erweiterung implementiert, um Entwicklern ein praktisches Beispiel zu geben, welches auch andere relevante Themen wie die Abfrage der Berechtigung behandelt.

Der Beitrag Mozilla stellt Erweiterungs-Schnittstelle für Lokale KI in Firefox vor erschien zuerst auf soeren-hentzschel.at.

SMLIGHT hat am Montagabend das Core Firmware Update 2.7.0 für die SLZB-06x Modelle mit folgenden Neuerungen veröffentlicht: Aktive Sockets Multithreading-Verwaltung: Standardmäßig ist 1 aktiver Socket aktiviert (empfohlene Einstellung). Der Benutzer kann dies auf der...

Mozilla hat Firefox 134.0.2 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 134.0.2

Mit Firefox 134.0.2 behebt Mozilla das Problem, dass Links auf lokale Dateien in HTML-Framesets nicht mehr funktionierten.

Für Nutzer von Firefox in manchen Sprachen erschien der Absturzmelder nach einem Firefox-Absturz nicht.

Ein Problem in den Entwicklerwerkzeugen wurde behoben, welches das erneute Senden von Netzwerkanfragen beim Debuggen von Erweiterungen verhinderte.

Außerdem wurden noch ein Problem in Zusammenhang mit Service Workers sowie eine mögliche Absturzursache behoben.

Der Beitrag Mozilla veröffentlicht Firefox 134.0.2 erschien zuerst auf soeren-hentzschel.at.

Nach der Installation von Ubuntu wird man feststellen, dass einige Mediendateien die Wiedergabe verweigern. Betroffen sind u. a. Formate wie AVI, MPEG und MP3. Der Grund hierfür liegt in den Lizenzbeschränkungen der einzelnen Formate, weshalb die benötigten Codecs nicht mit dem Betriebssystem ausgeliefert werden dürfen.

Wer hier Abhilfe sucht, kann das Metapaket ubuntu-restricted-extras nachinstallieren. Dieses enthält nicht nur die zuvor erwähnten Codecs, sondern auch die typischen Microsoft-Schriftarten.

Installation

Das Metapaket wird über das Terminal dem System hinzugefügt.

sudo apt install ubuntu-restricted-extras

Der Beitrag Nützliche Mediacodecs installieren erschien zuerst auf intux.de.

Firefox Klar ist ein spezialisierter Privatsphäre-Browser von Mozilla. Mit Firefox Klar 134 für Apple iOS steht nun ein Update bereit.

Download Mozilla Firefox Klar für Apple iOS

Die Neuerungen von Firefox Klar 134 für Apple iOS

Mozilla hat Firefox Klar 134 (internationaler Name: Firefox Focus 134) für Apple iOS veröffentlicht. Bei Firefox Klar 134 für Apple iOS handelt es sich um ein Wartungs-Update, welches ausschließlich Verbesserungen unter der Haube bringt.

Der Beitrag Mozilla veröffentlicht Firefox Klar 134 für Apple iOS erschien zuerst auf soeren-hentzschel.at.

Zweiter Open-Source-Bericht der Kommunalen Gemeinschaftsstelle für Verwaltungsmanagement (KGSt) erschienen

Logo: KGSt (© KGSt)

Mit Open-Source-Governance meint die KGSt die Gesamtheit aller methodischen, konzeptionellen, organisatorischen und technischen Regelungen und Vorgaben, welche den Einsatz von OSS [Open-Source-Software – Anm. d. Red.] und Offenen Standards in der Verwaltung stärken.

Nachdem die KGSt 2021 den Bericht Open Source in Kommunen – Ein Baustein für mehr Digitale Souveränität herausgebracht hat, folgt nun seit Anfang diesen Jahres Teil 2: Open Source in Kommunen – Aufbau einer Open-Source-Governance.

An den durch die KGSt beschriebenen Wesensmerkmalen einer Open-Source-Governance wird einmal mehr deutlich, dass Kooperation zum Kern der Gelingensbedingungen für Digitale Souveränität gehört. So wie Kooperation zu Open-Source-Software gehört und zum Open-Source-Ökosystem insgesamt. Nur gemeinsam kann es einer Kommune mit ihren verschiedenen Ämtern gelingen, die Governance ihrer ohnehin eingesetzten Open-Source-Software zu organisieren. Der Governance-Bericht beschreibt Rahmenbedingungen und skizziert das Handwerkszeug zum gezielten Umgang mit Open-Source-Software in der praktischen Verwaltungsorganisation.

Die Stadt Dortmund ist mit ihrer Koordinierungsstelle Digitale Souveränität und Open Source sehr gut vorbereitet, um eine Open-Source-Governance kooperativ organisieren zu können und damit gemeinsam stärker im digitalen Raum zu werden. Relevant ist die Open-Source-Governance auch für die derzeit in Entwicklung befindliche Open-Source-Strategie der Stadt Dortmund, die einen kommunalen Weg zu mehr Herstellerunabhängigkeit und Selbstbestimmung aufzeigen soll.

Do-FOSS freut sich erneut an der Berichtsarbeit der KGSt in gutem Austausch mitgewirkt zu haben. Besonders schön ist, dass auch dieser Bericht im Sinne des Open-Source-Gedankens unter einer Creative Commons-Lizenz erschienen ist (CC-BY-SA 4.0). Geteiltes Wissen soll sich mehren.

Neue Chancen für Digitale Souveränität

In ihrer Pressemitteilung zum Bericht sieht die KGSt mit einer Open-Source-Governance neue Chancen für die notwendige Digitiale Souveränität.

Digitale Souveränität wird für Kommunen zunehmend unverzichtbar. Die Nutzung von Open-Source-Software (OSS) in der Verwaltung kann nicht nur Innovationen fördern, sondern auch die Abhängigkeit von proprietären Technologien reduzieren und die Sicherheit erhöhen. Darüber hinaus bietet der Einsatz von OSS vielfältige Nachnutzungsmöglichkeiten. Die Kommunale Gemeinschaftsstelle für Verwaltungsmanagement (KGSt) hat einen neuen Bericht veröffentlicht, der Kommunen auf ihrem Weg zu mehr Unabhängigkeit unterstützt und aufzeigt, welche Prozesse, Rollen und Strukturen es dafür braucht.

Aus Sicht von Do-FOSS sind die organisatorischen Voraussetzungen für neue Impulse zur Stärkung Digitaler Souveränität so gut wie nie. Eine Open-Source-Governance könnte durch eine kommunale Open-Source-Strategie der Stadt Dortmund betrachtet werden, die in Zusammenarbeit mit der Kommunalen Gemeinschaftsstelle für Verwaltungsmanagement (KGSt) und dem Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) für andere Kommunen aufbereitet multipliziert werden könnte. Dadurch könnte unsere digitale Infrastruktur bundesweit wesentliche Modernisierungsimpulse erhalten und unsere Kommunen voneinander profitieren.

Kommunales Open-Source-Board

Was mit den Städten Berlin, München und Dortmund als Open Source Big 3 unter Moderation der KGSt für eine übergeordnete Arbeitsstruktur initialisiert wurde und schnell als Open Source Big X geöffnet wurde, soll sich nun als Kommunales Open Source Board professionalisieren und lokale Arbeitsbeiträge zusammenführen. Es braucht einen zentralen Anlaufpunkt für Kommunen zum Thema Open Source und Möglichkeiten dort Netzwerkstrukturen zu intensivieren. In Zusammenarbeit mit dem ZenDiS könnte ein hochwertiges Organisationsmodell für ein breites ausrollen einer Open-Source-Governance entwickelt werden.

Dokumente zum Herunterladen

Der Bericht der KGSt Open Source in Kommunen – Aufbau einer Open-Source-Governance kann hier und die dazugehörige Pressemitteilung kann hier heruntergeladen werden.

Soweit im gesetzlichen Rahmen möglich verzichtet der Autor auf alle Urheber- und damit verwandten Rechte an diesem Werk.
Es kann beliebig genutzt, kopiert, verändert und veröffentlicht werden.
Für weitere Informationen zur Lizenz, siehe hier.

The post Open-Source-Governance für Kommunen appeared first on Do-FOSS.

Mozilla hat Firefox 134.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 134.0.1

Mit Firefox 134.0.1 behebt Mozilla einen sogenannten Speicher-Leak, der sich zuletzt für einige Nutzer vor allem auf Google-Diensten wie YouTube und Google Docs in Form von Performance-Problemen bemerkbar machte.

Eine mögliche Absturzursache wurde behoben, welche für manche Nutzer nach dem letzten Firefox-Update den Start des Browsers verhindern konnte.

Außerdem wurde ein Problem behoben, welches für Nutzer, die das gleiche Profil mit unterschiedlichen Firefox-Versionen nutzen (was keine offiziell unterstützte Konfiguration ist), verursachen konnte, dass Suchmaschinen und Kontextmenüs nicht mehr korrekt funktionierten.

Der Beitrag Mozilla veröffentlicht Firefox 134.0.1 erschien zuerst auf soeren-hentzschel.at.

Ende letzten Jahres habe ich euch gezeigt, wie ihr die OpenThread RCP Firmware auf dem SMLIGHT SLZB-07 installiert. Neben den SLZB-07 Modellen gibt es von SMLIGHT noch die SLZB-06 Modelle, welche die im Home...