Die neue Version des Wayland-Compositors Hyprland läuft stabiler, erlaubt ein Farbmanagement, unterstützt HDR, bittet regelmäßig um Spenden und zeigt gerade-runde Ecken.
Die neue Version des Wayland-Compositors Hyprland läuft stabiler, erlaubt ein Farbmanagement, unterstützt HDR, bittet regelmäßig um Spenden und zeigt gerade-runde Ecken.
Neuem Netzwerk-Code im Linux-Kernel werden sagenhafte Effizienzsteigerungen zugeschrieben. Ist die Euphorie berechtigt? (Linux-Kernel, Linux)
Microsoft hat seine dokumentenorientierte Datenbank unter einer MIT-Lizenz auf GitHub veröffentlicht.
Microsoft hat seine dokumentenorientierte Datenbank unter einer MIT-Lizenz auf GitHub veröffentlicht.
Hogwarts bleibt ein fester Bestandteil magischer Abenteuer, und Gerüchte über eine Fortsetzung verdichten sich. Nach dem großen Erfolg des ersten Spiels steigt die Erwartung an eine noch immersivere Welt. Offizielle Ankündigungen fehlen, doch Spekulationen über neue Schauplätze und Spielmechaniken häufen sich. Ein zentrales Feature könnte die größte Überraschung bieten. Welche Geheimnisse birgt die nächste Reise nach Hogwarts?
Der Beitrag Das wahre Vermächtnis von Hogwarts 2 steht bevor: Was wir im Moment darüber wissen erschien zuerst auf Linux Abos.
GitLab hat neue Patch-Releases für seine Plattform bereitgestellt, die Sicherheitslücken in den Versionen 17.8.1, 17.7.3 und 17.6.4 schließen.
OpenWRT lässt sich mit Ansible zentral im Devops-Modus verwalten. Anders als bei den meisten kommerziellen Lösungen geht es auch ohne Cloud. (OpenWRT, Instant Messenger)
In der monatlichen Auswertung der Firma Netcraft zur Verbreitung von Webservern liegt der Nginx-Server im Januar 2025 weiter vorne.
Es gibt viele Möglichkeiten, um XML-Dateien auszulesen und abzufragen. Hier findet ihr eine davon.
Typischerweise sind alle Bestrebungen darauf gerichtet, die Bedenkzeit von Computern zu reduzieren.
LibreELEC 12.0.2 »Omega« bringt mit dem Umstieg von ARM zu aarch64 eine wichtige Änderung für Nutzer eines Raspberry Pi 4 oder 5 sowie anderer 64-Bit fähiger SoCs.
Die eigenständige Rolling-Release-Distribution Solus legt mit Solus 4.7 ein weiteres Erhaltungs-Release mit aktualisierten Desktops und Paketen vor.
FOSDEM 2025 is almost here, and guess what? We want you to be, once again, part of it! Mark your calendars for 1 and 2 February 2025. The Free Software Foundation Europe (FSFE) will be there with a keynote on our Apple court case, talks, devrooms, workshops, and of course, a booth where you can meet us, chat and share ideas. Stop by and say hello!
As one of the most established Free Software conferences in Europe, FOSDEM hosts thousands of developers and Free Software enthusiasts every year, on the first weekend of February to meet, discuss the latest news and updates about Free Software, and collaborate. As always, the FSFE will be there with a booth, co-organizing two devrooms, and giving talks, like the one from our Legal Programme Manager, Lucas Lasota, at the main FOSDEM stage about ongoing legal battle to defend software freedom in the European Union. Come around and check out our latest merchandising, including hoodies, t-shirts, socks and get some stickers for your devices!
We are organising social gatherings throughout the weekend—stay in the loop, come by for a relaxed evening and great discussion while making interesting connections! Join our FOSDEM Matrix Chat Room and be up to date with all the information.
We will start starting the party early! If you are already in Brussels on Friday, you can give us an extra hand in our booth set-up (please, if you can make it, contact us beforehand).
Once our booth is ready for Saturday, we will meet at La Mazzette at 19:00h., where we can have some drinks and some small treats. See in OpenStreetMap.
We are early birds. From the moment the doors open, you will us at our booth, ready to welcome everyone. Come chat with our team about Free Software, learn more about our activities, and grab some stickers and postcards! Our booth is the best place to connect with us. You will find us in Building K, Level 2, Group A – Community Advocacy, Room 5. We look forward to seeing you there!
Saturday will feature the Legal and Policy Issues DevRoom, which we've been co-hosting since 2020. The devroom will take place from 10:30h., H.1301 Cornil. Once again, Matthias Kirschner (FSFE’s president) and Alexander Sander (FSFE Senior Policy Consultant), together with Karen Sandler and Bradley Kuhn (Software Freedom Conservancy), Tom Marble (Informatique, Inc.), and Richard Fontana (Red Hat) will be addressing key legal and policy issues related to Free Software. We anticipate an engaging and insightful discussion!
Lucas Lasota, FSFE Legal Programme Manager, will participate in the fireside chat titled “Breaking Tech Monopolies in Europe: A Fireside Chat with the European Commission”. Later, Alexander Sander, FSFE Senior Policy Consultant, will also participate with two talks: Legislative overlay: anticipating and navigating through regulatory vectors and CRA Q&A on Open Source Stewards under the Cyber Resilience Act.
Additionally, Tobias Diekershoff, FSFE’s System Hacker and core developer of the Friendica project, along with Michael Vogel, also a core member of the Friendica development team, will provide an concise introduction to Friendica that late afternoon.
10:30h - 19:00h. Legal & Policy Devroom: H.1301 (Cornil)
After a long day, it is time to relax and continue our interesting discussions in an informal environment. Join us for dinner at L’Horloge du Sud at 19:00h. See in OpenStreetMap.
We are starting the day with an informal breakfast to meet and connect other QWLINTA*s (Queer, women, lesbians, intersex, non-binary, trans and agender) before kicking off another full day at FOSDEM. If you wish to join, please fill in this form.
While we prepare for keynote speech later this day, by our staffer Lucas Lasota who will talk about the FSFE intervention in the Apple vs. European Commission case, we have several talks and events beforehand.
One way is to start with the “FSFE’s Upcycling Android Workshop”, organized by Darragh Elliot, a former FSFE working student. If you ever wanted to try installing custom Android ROM’s, this workshop is for you! Demonstration phones will be available.
Also in the morning, Bonnie Mehring, FSFE’s Project Manager will explain our programming competition, Youth Hacking 4 Freedom, whose fourth edition is now open for registration! Youth Hacking 4 Freedom invites European teenagers aged 14 to 18 to showcase their creativity and programming skills. Participants will have the opportunity to bring their project ideas to life.
Sunday is also the day of the second devroom that the FSFE is co-organizing, a debuting one on funding the FOSS Ecosystem. Its aim? To bring together developers, maintainers, policymakers, entrepreneurs, donors and funders to explore various models and mechanisms for funding that ensure longevity and security of FOSS projects. Find the schedule here.
Just right after the closing of the Funding the FOSS Ecosystem devroom, run to FOSDEM main stage, Room Janson, where at 16:00h. Lucas Lasota, FSFE's Legal Programme Manager, will give a key speech about “How we are defending Software Freedom against Apple at the EU's highest court”. In this keynote, Lucas Lasota will explain why this case is pivotal for Free Software in Europe, and why we should all care.
The FSFE has been granted the right to intervene in the Apple vs European Commission case at the Court of Justice of the European Union, where Apple is trying to dodge its obligations as gatekeeper under the Digital Markets Act.There will be many more interesting talks going on! You can check the schedule of the two-day conference in the FOSDEM website.
As the weekend wraps up, join us for the final community gathering to say goodbye to FOSDEM 2025 in style.But first... after party packing! We hope to leave FOSDEM with as little merchandising as possible, but we’ll need some extra hands to help pack everything up on Sunday. If you can help us with booth tear down, please get in touch with our Office Assistant, Francesca, fi@fsfe.or. It’s always a challenge, but with a bit of teamwork, we’ll get it done in no time!
Once all is packed and tidy, it is time to meet at L'Ermitage Saint-Gilles at 19:00h. for a laid-back evening of conversation, drinks, and celebration. It’s a chance to unwind, meet new people, and reflect on the amazing time we’ve had. Here’s the OpenStreetMap link to find us!
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.
Die folgende Liste bietet einen Überblick über den Inhalt:
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.
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.
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.
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.
Um die in diesem Tutorial gezeigten Schritte selbst ausführen zu können, werden folgende Dinge benötigt:
Anmeldencontainer-toolsregistry.redhat.ioFalls ihr gerade keine geeignete Laborumgebung zur Verfügung habt, könnt ihr den Image Mode auch in diesen interaktiven Labs ausprobieren:
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:
rhel-bootc-Container-ImagesAnhand von VM 2 werden folgende Dinge demonstriert:
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
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) erstellenpodman-build(1) erstellenMit 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 sshdindex.html-Datei hinzugefügthttpd und sshd werden aktiviert, damit sie nach dem Boot-Vorgang automatisch startenDie 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.
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
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 GBDas 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.
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.
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.
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.
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 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.
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 GBWird 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?
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 destinationDie 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 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:
bootc-image-builder-Image herunterladen zu könnenoutput erstellt, welches die ISO-Datei enthalten wirdpodman run
registry.redhat.io eine neuere Version des bootc-image-builder gefunden wird, wird diese heruntergeladen und genutztbootc-image-builder muss mit erhöhten Rechten ausgeführt werden, weshalb die Ausführung mittels sudo und die Option --privileged erforderlich sindconfig.toml und Verzeichnis für das ISO werden dem Container als Volume zugänglich gemacht--type iso wird festgelegt, dass eine ISO-Datei erstellt werden soll--local gibt an, dass das lokal existierende Image localhost/rhel9.5-bootc.test verwendet und dies nicht aus einer Registry geholt werden sollDass 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.
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.
podman wurde ein rhel9.5-bootc:test Image erstelltbootc-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 eignetAuf 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.
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.
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:
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 sshdAls 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.1Der 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=trueDa 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:
bootc-image-builderSiehe 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:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9Nach 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 presentNach 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:eee2c8ea204615a9341f3747a6156c5b7bc208bbcf60f0a5bb28f142f6b0aa54Auf 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 --quietDas Kommando hinter ExecStart=:
Möchte man Aktualisierungen durch andere Verfahren steuern, kann die automatische Aktualisierung wie folgt gestoppt werden:
$ systemctl mask bootc-fetch-apply-updates.timer
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:c3925bc5d9618e803a3164f8f87a16333e4bf274469e72075d5cb50cf8ac51d9Euch 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 deploymentNur 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:e68453dd17a45ad9243139b5cbb0565bbd97aa2bcd5a230c41e44d295281f9a7Anhand 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.
Hier endet die Einführung in RHEL image mode. Wer dem Tutorial aufmerksam gefolgt ist, sollte an dieser Stelle in der Lage sein:
bootc-image-builder Disk-Images zu erstellenWenn 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.
Derzeit scheinen Betrüger auf Google Anzeigen zu schalten, die auf eine falsche Homebrew-Seite leiten.
Derzeit scheinen Betrüger auf Google Anzeigen zu schalten, die auf eine falsche Homebrew-Seite leiten.
Die neue Version der Distribution Solus trägt den Codenamen Endurance und betreibt im Wesentlichen Produktpflege.
Die neue Version der Distribution Solus trägt den Codenamen Endurance und betreibt im Wesentlichen Produktpflege.
Die RTX 5090 hat sich einer Reihe von Benchmarks unter Linux gestellt. Nicht Spiele, sondern Compute stand im Vordergrund. Für Intels Battlemage-Grafikkarten gibt es nun auch hardwarebeschleunigtes Encoding. AMD bringt einen eigenen Referenz-Desktop für das freie Betriebssystem und exotische Mining-Hardware kann nun auch Spiele.
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.
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.
In KW 4 ist in der FOSS-Welt wieder einiges los gewesen. Von den großen Desktops bis zu WINE.
Canonical hat den geplanten Veröffentlichungstermin für das nächste Point-Release von Ubuntu 24.04 LTS angekündigt. Die Version 24.04.2 soll am 13. Februar 2025 erscheinen. Florent „Skia“ Jacquet hat das Statusdokument für Ubuntu 24.04.2 LTS erstellt, das bekannte kritische Fehler, wichtige Änderungen und den Veröffentlichungsfortschritt bis zum geplanten Release am 13. Februar 2025 dokumentiert. Das zweite Point-Release […]
Der Beitrag Ubuntu 24.04.2 LTS: Der Veröffentlichungstermin steht erschien zuerst auf fosstopia.
