KDE und ich, das ist eine Hassliebe. Ich ärgere mich über manche Entwicklungen, kann aber trotzdem nicht darauf verzichten. Die Desktopoberfläche Plasma und einige Anwendungen wie Dolphin sind einfach durch nichts zu ersetzen. Ich habe es versucht. Mehrfach. Aber KDE PIM ist eine Katastrophe und diese Katastrophe wird nun verdoppelt. Warum nur?

Vor einigen Jahren habe ich noch gefragt, warum Kubuntu als Standard-Mailclient Thunderbird einführt und damit das homogene KDE-Ökosystem der Distribution bricht. Einige Jahre später bin ich selbst auf Thunderbird umgestiegen. Die Kubuntu-Entwickler hatten also doch recht. Jede Leidensfähigkeit hat ihre Grenzen und für KDE PIM / Kontact ist einfach keine Perspektive in Sicht.

Es gibt gute Gründe, alten PIM-Suites Alternativen an die Seite zu stellen. GNOME hat dies mit Kontakte und Kalender getan. Die Zielgruppe sind Anwender, für die Evolution zu viele Funktionen hat, aber die ihre Kontakte und Termine gerne via DAV über die Geräte hinweg synchronisieren möchte. Es werden unterschiedliche Zielgruppen bedient und das ist sinnvoll.

Als KDE vor einiger Zeit den Kalendar herausbrachte, dachte ich, dass man genau dieses Konzept verfolgen würde. Stattdessen wurde es in den letzten Jahren immer weiter aufgebläht. Erst kamen Kontakte dazu, dann Mails und jetzt heißt das ganze Merkuro. Jetzt, wo das Projekt so aufgebläht ist, kann man in Zukunft die einzelnen Komponenten separat installieren. Woran erinnert uns das? Ach ja, mit Kontact bzw. KAdressBook, KOrganizer und KMail hat das KDE doch schon in einer anderen Variante.

Auch die neue App geht das eigentliche Problem nicht an. Wie Kontact basiert sie auf Akonadi. Ein Produkt aus dem Abstraktionswahn, der KDE um 2010 befallen hat und dem wir legendäre Fehlschläge wie Phonon, Nepomuk & Co. verdanken. Generationen von KDE-Entwicklern haben ihre Energie darauf verschwendet, diese Bug-Hölle zu stabilisieren. Mit dem Ergebnis, dass man zwar irgendwie damit arbeiten kann, aber trotzdem täglich spürbare Fehler hat. Mit neuen Softwareverteilungsmechanismen wie Flatpak stirbt das Konzept eigentlich ohnehin aus.

Mit Merkuro steht den Anwendern eine Alternative zu Kontact zur Verfügung, die genau die gleichen Akonadi-Probleme mit sich herumschleppt wie ihr Gegenstück. Nun tüfteln zu wenige Entwickler an zwei verschiedenen Suiten und die Akonadi-Basis wird mit einem Busfaktor von ~1 gepflegt. Ist es vermessen, nach dem Warum zu fragen? Die Antwort ist wohl, weil ein paar Entwickler Spaß daran hatten und das KDE-Projekt wieder einmal keine Kontrolle hatte. Oder haben KDE-Projekte quasi einen immanenten Zwang zur Featureritis?

Zum Glück entwickelt sich Thunderbird aktuell positiv und Linux-Anwendern bleiben somit eine desktopunabhängige solide E-Mail-Anwendung mit Kontaktverwaltung und Kalenderunterstützung.

Der Artikel KDE erschafft eine Alternative zu Kontact – Die Frage ist nur warum? erschien zuerst auf Curius

Die MZLA Technologies Corporation hat mit Thunderbird 115.2 ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 115.2

Mit dem Update auf Thunderbird 115.2 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht. Das Update bringt diverse Fehlerbehebungen und Verbesserungen, welche sich in den Release Notes (engl.) nachlesen lassen. Auch wurden diverse Sicherheitslücken geschlossen.

Updates von Thunderbird 102 und älter sind zu diesem Zeitpunkt noch nicht aktiv. Nutzer älterer Versionen können sich Thunderbird 115.2 aber über die offizielle Website herunterladen und über die bestehende Version installieren.

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

Mozilla hat Firefox 117 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.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Website-Übersetzungen ohne Cloud

Firefox 117 besitzt erstmals 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. Die Übersetzungsfunktion wird in einem eigenen Artikel ausführlich vorgestellt.

Diese Funktion wird im Laufe der kommenden Wochen schrittweise ausgerollt. Eine manuelle Aktivierung ist in der Zwischenzeit über about:config möglich, indem der Schalter browser.translations.enable per Doppelklick auf true gesetzt wird.

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, den USA, Kanada, Frankreich sowie dem Vereinigten Königreich aktiviert.

Firefox 117 aktiviert die Funktion auch für Nutzer in Österreich, Italien, Spanien, Belgien und Polen.

Sonstige Endnutzer-Neuerungen von Firefox 117

Die Untertitel-Funktion des Bild-im-Bild-Modus wurde erneut für weitere Dienste zugänglich gemacht. Ab sofort werden Disney+, Hotstar sowie Arte unterstützt.

Auf macOS gibt es eine neue sichtbare Einstellung „Tab-Taste verwenden, um den Fokus zwischen Formular-Steuerung und Links zu verschieben“. Wird diese aktiviert, kann mittels Tabulator-Taste auch zwischen Links navigiert werden, wenn die macOS-Einstellung „Tastaturnavigation“ nicht aktiviert ist – welche standardmäßig nicht aktiviert ist.

Auf Wayland-Umgebungen unter Linux wird beim Teilen von Bildschirminhalten ab sofort der entsprechende Indikator des Betriebssystems anstelle eines eigenen genutzt. Außerdem gibt es auf Linux im Dialog zum Öffnen von Dateien jetzt auch PDF als verfügbaren Dokumenttypfilter.

Eine neue Option dom.event.contextmenu.shift_suppresses_event in about:config wurde implementiert, damit das Kontextmenü nicht mehr erscheint, wenn auf einer Website bei gedrückter Shift-Taste ein Rechtsklick ausgeführt wird.

Auf about:addons wird jetzt auch der Link zur Bewertungsseite eines Add-ons angezeigt, wenn noch keine Bewertung für das jeweilige Add-on abgegeben worden ist. Die Seite about:support zeigt nun an, ob die Datei userChrome.css, userContent.css oder beide zur visuellen Anpassung von Firefox und/oder Websites verwendet werden.

Seit Version 115 unterstützt Firefox einen neuen Mechanismus, über welchen die Ausführung von Erweiterungen auf bestimmten Websites durch Mozilla, beispielsweise aus Sicherheitsgründen, standardmäßig verhindert werden kann. Firefox 116 ergänzte in den Einstellungen des jeweiligen Add-ons eine Option, womit dieser Sicherheits-Mechanismus pro Erweiterung ein- oder ausgeschaltet werden kann. Firefox 117 ergänzt eine entsprechende Kontrolloption für betroffene Erweiterungen direkt in das Erweiterungs-Menü.

Mehr Sicherheit für Firefox-Nutzer

Auch in Firefox 117 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 117 daher für alle Nutzer dringend empfohlen.

Verbesserungen der Entwicklerwerkzeuge

Bei Verwendung von CSS-Eigenschaften, welche von mindestens einem relevanten Browser nicht unterstützt werden, zeigt Firefox jetzt ein Symbol an, dessen Tooltip Informationen zur Inkompatibilität darstellt. Außerdem gibt es einen Link zur entsprechenden Dokumentations-Seite in den MDN Web Docs.

Wird das Werkzeug für Abmessungen verwendet, kann der ausgewählte Bereich jetzt mit der Tastatur verschoben oder in der Größe verändert werden.

Die Verwendung von console.clear() in einem Script leert nicht länger die Konsolenausgabe, wenn die Option „Log nicht leeren“ aktiviert ist.

Das Netzwerkanalyse-Werkzeug zeigt jetzt auch HTTP Proxy-Informationen bei den Headern an.

Weitere Neuerungen der Entwicklerwerkzeuge werden im DevTools-Newsletter für Firefox 117 beschrieben.

Webentwicklungs-Revolution? Verschachtelung von CSS

Mit jedem Major-Release von Firefox kommt auch die Unterstützung zusätzlicher Webstandards dazu. Ganz oft handelt es sich dabei um neue CSS-Eigenschaften oder JavaScript-Methoden. Aber eine Neuerung von Firefox 117 hat das Potenzial, die Art und Weise, wie das CSS von Websites geschrieben wird, zu revolutionieren. Daher sei dieser Neuerung ein eigener Abschnitt gewidmet.

Firefox 117 unterstützt die Verschachtelung von CSS. Viele Entwickler nutzen bereits eine solche Funktion über einen Präprozessor wie SASS oder LESS, der daraus dann CSS mit vollständig „ausformulierten“ Selektoren kompiliert. Dies ist in Zukunft nicht länger notwendig, da eine Verschachtelung nun ein natives CSS-Feature ist. Dies macht vor allem komplexes CSS sehr viel übersichtlicher und besser wartbar.

Weitere Verbesserungen der Webplattform

Im Bereich MathML unterstützt Firefox 117 die CSS-Eigenschaften math-style und math-depth sowie den math-Wert für die Eigenschaft font-size. Außerdem wird contain-intrinsic-size: auto none-Syntax jetzt unterstützt.

Inline-SVGs unterstützen jetzt <script>-Elemente mit type="module" sowie die Attribute defer und async.

Weitere Neuerungen für Entwickler von Websites und Browser-Erweiterungen lassen sich in den MDN Web Docs nachlesen.

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

Wer über Mozilla auf dem Laufenden bleiben und keinen Artikel verpassen möchte, kann diesem Blog ab sofort auch auf Mastodon folgen. Natürlich stehen auch die Kanäle auf X (Twitter) sowie Facebook weiterhin zur Verfügung.

Was ist Mastodon?

Mastodon ist der wohl bekannteste Vertreter des sogenannten Fediverse und erlebt aktuell einen regelrechten Hype. Für diejenigen, welche mit dem Begriff Fediverse nichts anfangen können, hat Wikipedia eine Beschreibung parat:

Die Idee des „Fediverse“ ist, dass es möglich sein soll, ein Benutzerkonto auf einer beliebigen Plattform im Fediverse anzulegen und sich darüber mit Nutzern auf allen anderen Plattformen austauschen zu können, ohne dort ein weiteres Konto anlegen zu müssen. Ermöglicht wird das dadurch, dass die einzelnen Plattformen mittels bestimmter Kommunikationsprotokolle miteinander verbunden sind und so die föderierte Identität und Inhalte jeweils auf andere verbundene Plattformen und Instanzen verteilt werden. Diese Praxis steht im Gegensatz zu geschlossenen sozialen Netzwerken wie Twitter oder Facebook, bei denen Benutzer ein eigenes Benutzerkonto in jedem der Netzwerke benötigen, wenn sie mit anderen Nutzern des jeweiligen Netzwerks interagieren möchten.

Auch soeren-hentzschel.at ab sofort auf Mastodon

Auch dieser Blog ist ab sofort auf Mastodon vertreten. Wer keine Neuigkeit aus der Welt rund um Mozilla verpassen möchte und auf Mastodon vertreten ist, darf sehr gerne folgen.

@s_hentzschel auf Mastodon folgen

Natürlich werde ich auch weiterhin sowohl auf X (Twitter) als auch Facebook vertreten sein.

@s_hentzschel auf X (Twitter) folgen
@soerenhentzschelAT auf Facebook folgen

Der Beitrag In eigener Sache: soeren-hentzschel.at auf Mastodon erschien zuerst auf soeren-hentzschel.at.

In diesem Tutorial zeige ich euch, wie ihr eine automatische Aktualisierung für Container in rootless-Podman-Umgebungen konfigurieren und diese Container als systemd-Services verwalten könnt.

Das Tutorial gliedert sich in folgende Abschnitte:

1. Anwendungsfälle
2. Voraussetzungen
3. Umgebung und verwendetes Container-Image
4. Konfiguration des systemd-Service mit Auto-Update-Funktion
5. Container (automatisch) aktualisieren

Wer sich nicht für die möglichen Anwendungsfälle interessiert und lieber gleich starten möchte, kann den ersten Abschnitt überspringen. Die übrigen Abschnitte sollten in der angegebenen Reihenfolge gelesen werden.

Anwendungsfälle

• Container werden auf einem Single-Container-Host ausgeführt und nicht in K8s-Umgebungen
• Man vertraut dem Anbieter, dass dieser stabile und nutzbare Container-Images bereitstellt
• Es soll regelmäßig geprüft werden, ob aktualisierte Container-Images vorhanden sind
• Sind aktuellere Images vorhanden, sollen laufende Container entfernt und unter Verwendung der aktuellen Images neu erstellt werden

Voraussetzungen

Um diesem Tutorial folgen zu können, benötigt ihr einen Host mit einer rootless-Podman-Umgebung. Podman muss dabei in der Version >= 3.3 verfügbar sein. In der folgenden Liste findet ihr einige Links, die euch helfen, eine solche Umgebung aufzusetzen.

• Podman Installation Instructions
• Basic Setup and Use of Podman in a Rootless environment
• Rootless-Podman mit Debian Bullseye
• Kurztipp: Rootless Podman + docker-compose unter Fedora
• RHEL 9: Setting up rootless containers
• RHEL 8: Setting up rootless containers

Darüber hinaus solltet ihr Manpages lesen können.

Umgebung und verwendetes Container-Image

• RHEL 9
• Podman 4.4.1
• Container-Image von louislam/uptime-kuma

Das Betriebssystem spielt eine untergeordnete Rolle, da wir durch die Verwendung von Containern die Anwendung vom Betriebssystem entkoppeln. Alle zur Ausführung der Anwendung notwendigen Abhängigkeiten sind im Container-Image enthalten.

Uptime Kuma ist eine schlanke und schnelle Monitoring-Anwendung, welche unter anderem als Container-Image bereitgestellt wird. Ich habe die Anwendung als Beispiel für dieses Tutorial ausgewählt, da ich die Anwendung selbst nutzen möchte und so Synergieeffekte nutzen kann.

Wer ein anderes Container-Image nutzen möchte, muss in den folgenden Beispielen louislam/uptime-kuma:latest durch den fully qualified container name des zu nutzenden Images ersetzen.

Für die Konfiguration werden die auf dem System verfügbaren Podman-Manpages benutzt.

Konfiguration des Systemd-Service mit Auto-Update-Funktion

Bei den folgenden Schritten habe ich mich am Beispiel aus podman-auto-update(1) orientiert. Ich zeige zuerst den jeweils auszuführenden Befehl in einem Code-Block, gefolgt von einer Erläuterung der genutzten Optionen.

Podman-Volume erzeugen

$ podman volume create uptime-kuma
uptime-kuma

Um Daten persistent speichern zu können, müssen diese außerhalb des Containers abgelegt werden. Der dargestellte Befehl erzeugt ein Podman-Volume mit dem Namen „uptime-kuma“.

Mit dem folgenden Befehl lassen sich detaillierte Informationen zum gerade erstellten Volume anzeigen:

$ podman volume inspect uptime-kuma
[
     {
          "Name": "uptime-kuma",
          "Driver": "local",
          "Mountpoint": "/home/tronde/.local/share/containers/storage/volumes/uptime-kuma/_data",
          "CreatedAt": "2023-08-22T20:52:06.477341481+02:00",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "MountCount": 0,
          "NeedsCopyUp": true,
          "NeedsChown": true
     }
]

Der Schlüssel Mountpoint enthält den Pfad im lokalen Dateisystem, in dem das Volume erstellt wurde.

Manpages zum Nachschlagen:

• podman-volume(1)
• podman-volume-create(1)
• podman-volume-inspect(1)

Container starten

$ podman run --label "io.containers.autoupdate=registry" -d -p 3001:3001 -v uptime-kuma:/app/data:Z --name=uptime-kuma docker.io/louislam/uptime-kuma:latest
Trying to pull docker.io/louislam/uptime-kuma:latest...
Getting image source signatures
Copying blob d7ca72974892 done  
Copying blob 475646a04a73 done  
Copying blob 1d496c24aec8 done  
Copying blob 6a3727d8681d done  
Copying blob b00c91ba9805 done  
Copying blob ddade83992f9 done  
Copying blob b8454ed537a7 done  
Copying blob 849e609eff67 done  
Copying blob f861188db6a1 done  
Copying blob 5f3c3e6d7f1c done  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 68b7bcf7c878 done  
Copying config fb3a3565b2 done  
Writing manifest to image destination
Storing signatures
ad7b049d9b84962311f5bafb5329f59961d8a031e54a571f079b8243ea8059ee

• podman run ist das Kommando, mit dem ein neuer Container gestartet wird
• Die Option --label "io.containers.autoupdate=registry" gibt an, dass Podman die Remote-Registry prüft, ob dort ein aktualisiertes Image vorhanden ist; dieses Label ist Voraussetzung, um die Auto-Update-Funktion nutzen zu können
• Mit der Option -d wird der Container im Hintergrund gestartet und die Container-ID auf STDOUT ausgegeben
• Durch -p 3001:3001 wird der Host-Port 3001 mit dem Port der Anwendung (ebenfalls 3001) im Container verbunden
• Die Option -v uptime-kuma:/app/data:Z hängt das im vorhergehenden Schritt erstellte Podman-Volume in das Verzeichnis /app/data innerhalb des Containers ein; :Z sorgt dafür, dass der SELinux-Kontext korrekt gesetzt wird
• --name=uptime-kuma spezifiziert den Namen des Containers; dieser ist etwas leichter zu merken als die Container-ID
• Der Befehl endet mit dem fully qualified container name docker.io/louslam/uptime-kuma:latest
• Die letzte Zeile des Code-Blocks enthält die Container-ID

Manpages zum Nachschlagen:

• podman-run(1)
• podman-auto-update(1)

Systemd-Service-Unit mit podman-generate-systemd erstellen

$ podman generate systemd --name --new uptime-kuma
# container-uptime-kuma.service
# autogenerated by Podman 4.4.1
# Tue Aug 22 21:29:46 CEST 2023

[Unit]
Description=Podman container-uptime-kuma.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--sdnotify=conmon \
	--replace \
	--label io.containers.autoupdate=registry \
	-d \
	-p 3001:3001 \
	-v uptime-kuma:/app/data:Z \
	--name=uptime-kuma docker.io/louislam/uptime-kuma:latest
ExecStop=/usr/bin/podman stop \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

• Der Befehl gibt den Inhalt der generierten Service-Unit auf STDOUT aus
• Die Option --name verwendet den Namen des Containers anstelle der Container-ID im Dateinamen der Service-Unit (hier: container-uptime-kuma.service)
• Wichtig ist die Option --new, um Container von aktualisierten Images erstellen zu können; ohne diese Option können Systemd-Units Container nur unter Verwendung des ursprünglichen Images starten und stoppen und ein Auto-Update ist nicht möglich
• Der folgende Code-Block fügt dem Befehl die Option --files hinzu, um eine Service-Unit-Datei zu erstellen

$ podman generate systemd --name --new --files uptime-kuma
/home/tronde/container-uptime-kuma.service

Manpages zum Nachschlagen:

• podman-auto-update(1)
• podman-generate-systemd(1)

Die erstellte Systemd-Unit aktivieren und starten

$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reload

• Der erste Befehl verschiebt die Service-Unit in einen Pfad, wo systemd sie findet und einlesen kann
• Die Option -Z stellt sicher, dass die Datei den SELinux-Kontext des Zielverzeichnisses zugewiesen bekommt, andernfalls kann systemd die Datei ggf. nicht verarbeiten
• Durch den zweiten Befehl wird die Unit-Datei systemd bekannt gemacht
• An dieser Stelle ist der neue Systemd-Service geladen, jedoch inaktiv

$ systemctl --user status container-uptime-kuma.service
○ container-uptime-kuma.service - Podman container-uptime-kuma.service
     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>
     Active: inactive (dead)
       Docs: man:podman-generate-systemd(1)
$ podman stop uptime-kumauptime-kuma
$ podman rm uptime-kumauptime-kuma
$ systemctl --user start container-uptime-kuma.service
$ systemctl --user status container-uptime-kuma.service
● container-uptime-kuma.service - Podman container-uptime-kuma.service     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>     Active: active (running) since Tue 2023-08-22 21:59:56 CEST; 14s ago
…

• Der erste Befehl in obigen Code-Block prüft den aktuellen Status des Service
• Der zweite und dritte Befehl stoppen und entfernen den laufenden Container, den wir weiter oben gestartet haben
• Befehl Nummer 4 startet den Uptime-Kuma-Service
• Befehl Nummer 5 prüft den neuen Status des Service; dieser ist nun up-and-running

Manpages zum Nachschlagen:

• mv(1)
• systemd.unit(5)
• systemctl(1)

Auf neue Container-Images prüfen

$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
docker.io/louislam/uptime-kuma:latest false

• Durch die Option --dry-run wird sichergestellt, dass nur auf die Verfügbarkeit neuer Images geprüft wird, es werden jedoch keine Pull-Operationen ausgeführt und keine Container neu erstellt
• Es wird eine Liste von Container-Images ausgegeben, die mit dem Label io.containers.autoupdate=registry gestartet wurden
• Die erste Spalte enthält den Image-Namen
• Die zweite Splate zeigt an, ob ein Update verfügbar ist; in diesem Fall ist kein Update verfügbar (false)

Container (automatisch) aktualisieren

Wurde die Konfiguration erfolgreich abgeschlossen, können die entsprechenden Container durch folgenden Befehl manuell aktualisiert werden:

$ podman auto-update
            UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
            container-uptime-kuma.service  df21116f2573 (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    false

Leider ist aktuell kein Update verfügbar, weshalb es hier nichts zu tun gibt und der Status von Updated gleich false ist.

Podman bringt bei der Installation die beiden systemd units podman-auto-update.timer und podman-auto-update.service mit, welche zumindest unter RHEL 9 manuell aktiviert werden müssen:

$ systemctl --user enable podman-auto-update.{service,timer}
Created symlink /home/tronde/.config/systemd/user/default.target.wants/podman-auto-update.service → /usr/lib/systemd/user/podman-auto-update.service.
Created symlink /home/tronde/.config/systemd/user/timers.target.wants/podman-auto-update.timer → /usr/lib/systemd/user/podman-auto-update.timer.

$ systemctl --user start podman-auto-update.timer
$ systemctl --user status podman-auto-update.{service,timer}
○ podman-auto-update.service - Podman auto-update service
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● podman-auto-update.timer
       Docs: man:podman-auto-update(1)

● podman-auto-update.timer - Podman auto-update timer
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.timer; enabled; preset: disabled)
     Active: active (waiting) since Sat 2023-09-02 20:56:09 CEST; 1s ago
      Until: Sat 2023-09-02 20:56:09 CEST; 1s ago
    Trigger: Sun 2023-09-03 00:12:22 CEST; 3h 16min left
   Triggers: ● podman-auto-update.service

• Der Timer startet jeden Tag um Mitternacht den Auto-Update-Service
• Der Service prüft, ob aktualisierte Container-Images verfügbar sind und führt ggf. ein Update der Container durch
• Schlägt ein Start nach Aktualisierung des Container-Images fehl, wird der Dienst automatisch von der vorherigen Image-Version gestartet; siehe --rollback in podman-auto-update(1)
• Der folgende Code-Block zeigt den Status, nachdem ein Update durchgeführt wurde

$ systemctl --user --no-pager -l status podman-auto-update
○ podman-auto-update.service - Podman auto-update service
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
     Active: inactive (dead) since Sun 2023-09-03 00:12:56 CEST; 7h ago
TriggeredBy: ● podman-auto-update.timer
       Docs: man:podman-auto-update(1)
    Process: 309875 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS)
    Process: 310009 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS)
   Main PID: 309875 (code=exited, status=0/SUCCESS)
        CPU: 5.128s

Sep 03 00:12:50 example.com podman[309875]: Copying config sha256:d56b643e048f2d351ed536ec9a588555dfd4c70de3c8d510ed61078a499ba464
Sep 03 00:12:50 example.com podman[309875]: Writing manifest to image destination
Sep 03 00:12:50 example.com podman[309875]: Storing signatures
Sep 03 00:12:51 example.com podman[309875]: 2023-09-03 00:12:41.98296115 +0200 CEST m=+1.880671312 image pull  docker.io/louislam/uptime-kuma:latest
Sep 03 00:12:55 example.com podman[309875]:             UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
Sep 03 00:12:55 example.com podman[309875]:             container-uptime-kuma.service  814407c7312c (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    true
Sep 03 00:12:56 example.com podman[310009]: fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65
Sep 03 00:12:56 example.com podman[310009]: 2023-09-03 00:12:55.421998943 +0200 CEST m=+0.020260134 image remove fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65 
Sep 03 00:12:56 example.com systemd[686]: Finished Podman auto-update service.
Sep 03 00:12:56 example.com systemd[686]: podman-auto-update.service: Consumed 5.128s CPU time.

Ich hoffe, das Tutorial hat euch gefallen und konnte euch einen Eindruck vermitteln, wie man automatische Updates für Container konfigurieren kann.