Podman 5.0 verbessert Hypervisor-Unterstützung
Das bei Red Hat entwickelte Podman ist eine Alternative zu Docker. Es benötigt keinen Daemon und läuft ohne Root-Rechte. Gerade ist Podman 5.0 erschienen.
Das bei Red Hat entwickelte Podman ist eine Alternative zu Docker. Es benötigt keinen Daemon und läuft ohne Root-Rechte. Gerade ist Podman 5.0 erschienen.
Der Linux-Kernel 6.6 wird die nächste Ausgabe mit Lo
GNU ist gerade 40 Jahre alt geworden. GNU steht im Zentrum der Freie-Software-Bewegung, die Richard Stallman in den 80er-Jahren begonnen hat.
Die Linux-Community startet einen zweiten Versuch, das alte Microsoft-Protokoll RNDIS zu entfernen. Beim ersten Mal gab es zahlreiche Diskussionen.
Neuer Versuch, neues Glück ist offenbar die Devise von Linux-Kernel-Entwickler Greg Kroah-Hartman, der nun erneut anstrebt, das veraltete und von Sicherheitsrisiken geplagte RNDIS-Protokoll aus dem Linux-Kernel zu entfernen.
Bereits im vergangenen Jahr startete der Entwickler eine Diskussion um diesen Schritt und setzte die Änderung zunächst vorläufig auch im Code um. Kroah-Hartman musste diese aber zurücknehmen, da es zahlreiche Einsprüche gegen die Änderung gab. Das wohl größte Problem ist, dass RNDIS für viele Nutzer die wichtigste Komponente ist, um ihren Rechner per Tethering über ein Android-Smartphone mit dem Internet zu verbinden. Darüber hinaus nutzen auch Geräte wie Router weiterhin RNDIS für ihre Netzwerkverbindungen.
Die von Microsoft initiierte Remote Network Driver Interface Specification stammt aus den Zeiten von Windows XP und dient als proprietäres Protokoll, das fast ausschließlich zusammen mit USB genutzt wird. Dazu wird eine Art virtuelle Netzwerkverbindung erzeugt, die wiederum nah an die Windows-Schnittstelle für Netzwerktreiber (NDIS) angelehnt ist.
Das grundlegende Konzept von RNDIS ist darüber hinaus laut Kroah-Hartman, der unter anderem den USB-Zweig in Linux verantwortet, nicht nur unsicher und angreifbar, sondern vor allem auch nicht absicherbar. Außerdem gibt es im USB-Protokoll selbst mehrere offene und standardkonforme Alternativen zu RNDIS.
Ob sich allerdings an der Problematik in Bezug auf das Tethering seit der ersten Diskussion etwas änderte und warum Kroah-Hartman diesen neuen Versuch zum Entfernen von RNDIS unternimmt, ist derzeit noch nicht klar. So bleibt abzuwarten, ob der Patch tatsächlich in den Hauptzweig des Linux-Kernels wandern wird.
Der Beitrag Linux-Entwickler wollen RNDIS erneut rauswerfen erschien zuerst auf Linux-Magazin.
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:
systemd
-Service mit Auto-Update-FunktionWer 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.
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.
Darüber hinaus solltet ihr Manpages lesen können.
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.
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 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 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--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-d
wird der Container im Hintergrund gestartet und die Container-ID auf STDOUT ausgegeben-p 3001:3001
wird der Host-Port 3001 mit dem Port der Anwendung (ebenfalls 3001) im Container verbunden-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-IDdocker.io/louslam/uptime-kuma:latest
Manpages zum Nachschlagen:
$ 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
--name
verwendet den Namen des Containers anstelle der Container-ID im Dateinamen der Service-Unit (hier: container-uptime-kuma.service)--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--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:
$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reload
systemd
sie findet und einlesen kann-Z
stellt sicher, dass die Datei den SELinux-Kontext des Zielverzeichnisses zugewiesen bekommt, andernfalls kann systemd
die Datei ggf. nicht verarbeitensystemd
bekannt gemacht$ 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
…
Manpages zum Nachschlagen:
$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
docker.io/louislam/uptime-kuma:latest false
--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 erstelltio.containers.autoupdate=registry
gestartet wurdenfalse
)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
--rollback
in podman-auto-update(1)$ 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.
Schwimmen, Radfahren, Laufen – das alles hintereinander und in ordentlichen Distanzen. Triathlon ist eine faszinierende Sportart, die leider viel zu selten im Livestream zu sehen ist. Das gilt zumindest für Deutschland. Die Kollegen aus der Schweiz sind da wesentlich besser und übertragen Triathlon häufiger im Free-TV – also bei SRF. Allerdings benötigst Du dafür ein gutes VPN wie NordVPN* oder CyberGhost* (günstig), damit Du den Triathlon-Livestream des Schweizer Fernsehens entsperren kannst. Kurze Anleitung: So schaust Du Triathlon live im Free-TV […]
Der Beitrag Triathlon Livestream kostenlos online schauen ist von bitblokes.de.
Das auf Arch Linux basierende System BlendOS kann Softwarepakete aus anderen Distributionen installieren sowie Android-Apps ausführen. Die Programme laufen dabei ab sofort in Podman-Containern. Vereinfacht haben die Entwickler zudem die Installation von Arch-Linux-Paketen.
BlendOS kann unter anderem Fedora- und Ubuntu-Pakete einspielen. Die entsprechenden Anwendungen hatte bislang das Tool Distrobox in Containern verpackt und so voneinander isoliert. Im neuen BlendOS v2 haben die Entwickler die entsprechenden Funktionen auf Basis von Podman neu implementiert. Nach eigenen Angaben ermöglichte dies, deutlich einfacher weitere Funktionen nachzurüsten.
Die in den Containern gelandeten Programme tauchen in BlendOS v2 sofort nach ihrer Installation im Basissystem auf – wie man es vom „Überblenden“ beziehungsweise Mischen von mehreren Distributionen erwartet. Zudem kann man jetzt festlegen, welche Anwendung gegenüber identischen Kollegen aus anderen Distributionen den Vorzug erhält.
Über WayDroid kann das System von Haus aus Android Apps starten. Letztgenannte lassen sich über bekannte Stores wie Aurora oder F-Droid hinzuholen. Die Apps laufen dabei einträchtig neben den normalen Linux-Anwendungen.
Das Basissystem nutzt wahlweise Gnome 43.4 oder KDE Plasma 5.27. Die Gnome-Variante verwendet ein unmodifiziertes Gnome – mit einer Ausnahme: Der Desktop gruppiert automatisch Anwendungen, die zu verschiedenen Systemen und Kategorien gehören.
In BlendOS v2 kann man Programme direkt aus den Arch- und Chaotic-AUR-Repositories in das Basissystem hinzuholen. Dies ist beispielsweise nützlich, wenn man eine andere VPN-Software nutzen oder weitere Treiber nachinstallieren möchte.
Abschließend kann man sich auf der BlendOS-Website seinen ganz eigenen BlendOS-Remix zusammenstellen. Das ISO-Image unterstützt sowohl UEFI- als auch BIOS-Systeme. Die Nvidia-Treiber gehören zudem zum Lieferumfang.
Der Beitrag BlendOS v2 ersetzt Distrobox durch Podman erschien zuerst auf Linux-Magazin.
Wer diesen Blog regelmäßig liest, kann den Eindruck gewinnen, es sei mein Hobby, Ansible-Rollen zu schreiben, mit denen von mir genutzte Web-Anwendungen auf Servern bereitgestellt werden können. Dieses Mal habe ich es mit Seafile getan und möchte in diesem Beitrag darüber berichten.
Seafile ist eine Sync&Share- bzw. Private-Cloud-Lösung ähnlich wie Nextcloud, ownCloud oder TeamDrive. Auf mich erweckt Seafile den Eindruck, als wenn der Schwerpunkt jedoch auf der Synchronisation und dem Teilen von Dateien liegt und damit genau meinem Suchmuster entspricht.
Seafile gibt es in einer Community und einer Professional Edition. Die Professional Edition darf mit bis zu drei Benutzern kostenlos verwendet werden.
Für weiterführende Informationen wird auf die Seiten des Herstellers und den Wikipedia-Artikel verwiesen.
Nun, es gibt nicht das eine Ziel. Ich habe mit diesem kleinen Wochenendprojekt folgende Ziele verfolgt:
Zuerst habe ich mich informiert, ob es Container-Images für Seafile gibt und ob entsprechende Installationswege in der Dokumentation beschrieben sind. Meine Recherche förderte folgende Treffer zutage:
Ansible-Rollen haben eine einheitliche Struktur. Mit dem Befehl ansible-galaxy role init ansible_role_deploy_seafile_with_rootless_podman
habe ich das Grundgerüst für meine Rolle erstellt. Anschließend habe ich die notwendigen Dateien {defaults,meta,tasks,vars}/main.yml
mit Inhalt gefüllt und nicht benötigte Verzeichnisse wie handlers
gelöscht. Mir ist dabei wichtig, dass alle notwendigen Parameter über Variablen definiert werden, die in defaults/main.yml
zu finden sind. In vars/main.yml
befinden sich hingegen nur Variablen, welche intern von der Rolle verwendet werden und vom Benutzer nicht explizit gesetzt werden sollen. So lässt sich die Rolle leicht wiederverwenden, um verschiedene Seafile-Instanzen auf dem gleichen Host oder in unterschiedlichen Umgebungen zu deployen.
Bevor ich die Rolle zum ersten Mal auf meinen Server angewendet habe, habe ich sie mit yamllint und ansible-lint geprüft und vorhandene Warnungen und Fehler behoben. Allerdings lassen sich mit den Lint-Werkzeugen und der Option --syntax-check
nicht alle Fehler im Vorfeld finden. Da mir ein zweites Augenpaar fehlte, habe ich die letzten Tippfehler erst durch die Verwendung des Ansible Playbook Debugger gefunden.
Das Ergebnis findet ihr auf:
Unter allen drei URLs könnt ihr meine Rolle herunterladen. Es ist damit möglich, eine lauffähige Seafile Pro Instanz bereitzustellen. Ein Test auf Idempotenz und ob diese Rolle auch zur Aktualisierung einer bestehenden Umgebung genutzt werden kann, steht noch aus.
Ihr seid herzlich eingeladen, die Rolle bei Interesse zu testen. Ich freue mich über Rückmeldungen zur Rolle und Dokumentation (Readme.md).
Ich habe das Deployment bisher nur auf Debian Buster getestet. Daher freue ich mich besonders über Rückmeldungen, wenn ihr die Rolle erfolgreich auf anderen Plattformen angewendet habt. Dann kann ich die entsprechenden Angaben für Ansible Galaxy ergänzen.
Eure Rückmeldungen nehme ich in den Kommentaren zu diesem Beitrag, per E-Mail oder in meinem neuen Matrix-Kanal #my-it-brain:matrix.org
entgegen.
Ich interessiere mich für Themen rund um Ansible und Podman und frage mich, wie dies bei euch aussieht. Daher freue ich mich, wenn ihr in den Kommentaren oder gern auch per E-Mail und Chat folgende Fragen beantworten mögt:
Ich freue mich auf eure Antworten.
Man pages formen auf heutigen unixoiden Systeme eine entscheidende Säule. Sie sind das integrierte Handbuch, das einerseits die Kommandos erklärt und andererseits auch eine Referenz für die jeweiligen C-Bibliotheken und Syscalls darstellt. Wer also Anwendungsentwicklung auf Linux o. ä. betreibt und dabei insbesondere auf C zurückgreift, kommt an man pages schwer vorbei. Dabei bieten sie einige Vorteile: sie sind lokal verfügbar, nach einem konsistenten Schema aufgebaut und erklären die verschiedenen Befehle und Schnittstellen. Man pages sind tatsächlich so unverzichtbar, dass jeder C-Entwickler sie regelmäßig konsultieren sollte. Immerhin werden hier nicht nur die Kommandos und ihre Wirkungsweise erklärt, sondern auch auf Seiteneffekte und Fehlermeldungen eingegangen. Dies ist essentiell, da viele Bestätigungen oder Fehler nur über Rückgabewerte kommuniziert und im letzteren Fall über spezielle (globale) Variablen wie errno
erläutert werden.
In diesem Zusammenhang ist es wichtig, diese man pages aufzusuchen und durchsuchen zu können. Den ersteren Teil könnt ihr im Artikel von Ralf Hersel auf gnulinux.ch nachlesen, das konkrete durchsuchen aller man pages möchte ich heute in diesem Artikel kurz betrachten.
Wir können mit dem man
-Kommando alle Beschreibungen der man pages (-k
, apropos
) und auch den gesamten Inhalt der man pages (-K
) durchsuchen.
Für den heutigen Fall möchten wir uns damit beschäftigen, wie wir ein Programm beenden können. Grundsätzlich kann ein exit vielfältig aussehen: wir können ihn auf der Shell durchführen, exit könnte aber auch einen Syscall oder eine C-Funktion aus der Standardbibliothek bezeichnen. Wenn wir schon dabei sind: exits gibts natürlich auch auf der pthread-Ebene, wir können aber auch eine Funktion registrieren, die bei einem normalen exit
aufgerufen werden soll. Kurzum: wir müssen uns vorher erst einmal informieren, was wir überhaupt finden können, um dann die richtige man page aufzurufen. Diese Suche geht mit folgenden Kommandos, die auf das gleiche Ergebnis kommen:
man -k exit
apropos exit
Uns wird eine Liste aller man pages zusammengestellt, die exit im Namen oder der Kurzbeschreibung enthalten. Hier haben wir die Möglichkeit, die richtige Handbuchseite aufzufinden, um dann z. B. exit(0)
im C-Programm aufzurufen.
Manchmal kann es allerdings passieren, dass wir zu einem gegebenen Suchbegriff über apropos
nicht fündig werden. Dann müssen wir den kompletten Inhalt der man pages einbeziehen, weil der gesuchte Begriff mitunter in den detaillierten Beschreibungen erst zu finden ist.
Um bei unserem Beispiel zu bleiben, möchten wir weitere Informationen über die Konstante EXIT_SUCCESS
finden, die oft anstelle von 0
als exit-Code benutzt wird. Hier müssen wir alle man pages nun durchsuchen, weil es keine man page dazu gibt, die diese Konstante in der Kurzbeschreibung erwähnt.
Wir nutzen:
man -K EXIT_SUCCESS
Nun werden alle man pages durchsucht, was zu vielen Ergebnissen führen kann. Das erste Ergebnis wird automatisch geöffnet (bei mir ist es das certtool), das mag uns aber nicht zufriedenstellen.
Wir können den Pager über q
verlassen und nun durch die anderen Ergebnisse uns durcharbeiten. <Enter>
führt zur Anzeige der man page, <Strg + D>
zum Überspringen des Suchergebnisses und <Strl + C >
zum Abbruch der Suche.
Bei dieser konkreten Konstante müssen wir uns Beispiele und Hinweise anschauen, um die Verwendung zu verstehen, deswegen kann es sein, dass man sich mehrere man pages anschauen muss, die thematisch dazu passen.
Man pages sind das klassische Offline-Handbuch von unixoiden Systemen. Wenn man nicht sofort weiß, wo man etwas suchen soll, kann man die beiden Suchfunktionen (Beschreibung, Volltext) nutzen, die das man
-Kommando bereitstellt. Weitere Informationen hierzu sind unter man man
(man(1)
) verfügbar.
Der monatliche Bericht von Linux Mint wurde veröffentlicht und es gibt ein paar interessante Fakten. Blueman wurde etwa auf Version 2.3.4 aktualisiert. Das behebt einen Fehler in Cinnamon, bei dem zwei Bluetooth-Symbole in der Systemsteuerung angezeigt wurde. Den Bug kann ich bestätigen, aber ich habe ihn einfach ignoriert, da er mich nicht gestört hat. Künftig weniger Passwortaufforderungen Das Team hat den Code überarbeitet, mit dem Du Anwendungen aus dem Hauptmenü entfernen kannst. Du musst ab sofort kein Passwort mehr eingeben, […]
Der Beitrag Monatsbericht von Linux Mint – weniger Passwörter notwendig ist von bitblokes.de.
Podman ist Red Hats Antwort auf Docker. Gerade erschien Podman 4.2.0 mit einem umfangreichen Changelog, das die anhaltende Intensität der Entwicklung belegt.
Die Entwickler der Distribution haben in einem Blog- [...]
Der Beitrag Linux-Mint-Team übernimmt Timeshift-Entwicklung erschien zuerst auf LinuxCommunity.
Herzlich willkommen zu Teil 6 meiner Reihe Nextcloud im Container. Dieser Teil behandelt das Thema Updates. Zum Verständnis empfehle ich, zuerst Teil 1 und Teil 2 zu lesen.
Nun wünsche ich euch viel Spaß beim Lesen und gute Unterhaltung.
Meine Nextcloud-Instanz läuft in einem Podman-Pod. Das sieht im Terminal wie folgt aus:
$ podman pod ps
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
e84bec6108d1 nc_pod Running 2 months ago 5e52555c5060 3
Dieser Pod besteht aus den folgenden drei Container-Instanzen:
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e52555c5060 k8s.gcr.io/pause:3.2 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp e84bec6108d1-infra
c6571aa338ce docker.io/library/mariadb:10.5.7 mysqld 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp nc_mariadb
21739d36eef1 docker.io/library/nextcloud:23-apache apache2-foregroun... 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp nextcloud
Diese Container-Instanzen sind zustandslos und ephemeral (engl. für kurzlebig, vergänglich oder flüchtig). Persistent zu speichernde Daten werden außerhalb der Container-Instanzen gespeichert. Diese Eigenschaften erlauben es, Container einfach entfernen und durch neue Instanzen ersetzen zu können.
Um die Nextcloud zu aktualisieren, wird in dieser Umgebung also nicht die Anwendung innerhalb des Containers aktualisiert. Stattdessen werden die Container-Instanzen entfernt und Container-Images mit aktuelleren Versionen der Anwendung und Datenbank instanziiert.
Die aktuell laufenden Versionen von Nextcloud und MariaDB sind obigen Codeblock zu entnehmen. Diese Images wurden durch die beiden folgenden Zeilen in der Datei {role_path}/defaults/main.yml
definiert:
MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
NC_IMAGE: docker.io/library/nextcloud:23-apache
Hier kann man nun die gewünschten Versionen der zu verwendenden Container-Images eintragen. Alternativ kann man die Default-Werte auch durch entsprechende Einträge in {role_path}/vars/main.yml
überschreiben. Die Einträge sehen dann bspw. wie folgt aus:
MARIADB_IMAGE: docker.io/library/mariadb:10.5.9
NC_IMAGE: docker.io/library/nextcloud:23.0.3-apache
Nun kann das Playbook mit der Ansible-Rolle aus Teil 2 dieser Reihe erneut ausgeführt werden:
$ ansible-playbook -i hosts deploy_nextcloud.yml --ask-vault-pass
Vault password:
PLAY [localhost] **************************************************************************************************
TASK [Gathering Facts] *******************************************************************************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Main folder, needed for updating] *************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for installed/modified apps] ***********************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for local configuration] ***************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the actual data of Nextcloud] ******************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the MySQL data files] **************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create the podman-pod(1)] *********************************
changed: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create MariaDB container] *********************************
changed: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Wait for DB to initilize] *********************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create Nextcloud container] *******************************
changed: [localhost]
PLAY RECAP *******************************************************************************************************
localhost : ok=10 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Nun kann man sich auf dem Zielsystem davon überzeugen, dass die neuen Container-Images zur Instanziierung verwendet wurden:
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e52555c5060 k8s.gcr.io/pause:3.2 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp e84bec6108d1-infra
248f87e1135b docker.io/library/mariadb:10.5.9 mysqld 35 seconds ago Up 36 seconds ago 127.0.0.1:40671->80/tcp nc_mariadb
59ac1aad168c docker.io/library/nextcloud:23.0.3-apache apache2-foregroun... 10 seconds ago Up 11 seconds ago 127.0.0.1:40671->80/tcp nextcloud
Fertig. Schon kann Nextcloud in Version 23.0.3 mit einer MariaDB 10.5.9 genutzt werden.
Mit diesem Artikel habe ich das letzte noch offene Ziel Nr. 5 „Konfiguration und Test automatischer durch Ansible gesteuerter Updates“ erreicht. Der Update-Prozess folgte dem Container-Paradigma, die Container komplett zu ersetzen und nicht die Anwendung innerhalb der Container zu aktualisieren.
Es handelte sich im dokumentierten Fall um Updates auf ein neues Patch-Release, bei denen das Risiko für Fehler ohnehin sehr gering ist. Ob das Update auch bei Minor- bzw. Major-Releases so gut funktioniert, muss sich noch zeigen. Ich werde diesen Artikel aktualisieren, wenn es Erkenntnisse dazu gibt.
Mit diesem Artikel endet meine Reihe „Nextcloud im Container“. Ich hoffe, ich habe euch damit ein wenig unterhalten und konnte euer Wissen durch die ein oder andere Information erweitern.
In Teil 1 dieser Artikelserie habe ich mein Ansinnen ausführlich beschrieben. Dieser Teil widmet sich der Entwicklung einer Ansible-Rolle zum Deployment des Nextcloud-Apache-Container-Images.
In den folgenden Abschnitten beschreibe ich die Einrichtung eines Python Virtual Environments, die Installation von Ansible in dem zuvor erstellten Environment und die Installation der Ansible-Collection containers.podman, bevor ich mich abschließend der eigentlichen Ansible-Rolle widme.
Zur Einrichtung habe ich mich an den englischsprachigen Artikel „How to set up and use Python virtual environments for Ansible“ von Gineesh Madapparambath gehalten. Die notwendigen Schritte werden hier kurz und bündig dokumentiert.
[t14s ~]$ python3 --version
Python 3.9.7
[t14s ~]$ mkdir python-venv
[t14s ~]$ cd !$
cd python-venv
[t14s python-venv]$ python3 -m venv ansible-core2.x
[t14s python-venv]$ source ansible-core2.x/bin/activate
(ansible-core2.x) [jkastning@t14s python-venv]$ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in ./ansible-core2.x/lib/python3.9/site-packages (21.0.1)
Collecting pip
Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
|████████████████████████████████| 1.7 MB 2.3 MB/s
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 21.0.1
Uninstalling pip-21.0.1:
Successfully uninstalled pip-21.0.1
Successfully installed pip-21.3.1
(ansible-core2.x) [t14s python-venv]$ python3 -m pip install ansible-core
Collecting ansible-core
[...]
(ansible-core2.x) [t14s python-venv]$ ansible --version
ansible [core 2.11.6]
config file = None
configured module search path = ['/home/tronde/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/tronde/python-venv/ansible-core2.x/lib64/python3.9/site-packages/ansible
ansible collection location = /home/tronde/.ansible/collections:/usr/share/ansible/collections
executable location = /home/tronde/python-venv/ansible-core2.x/bin/ansible
python version = 3.9.7 (default, Aug 30 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)]
jinja version = 3.0.2
libyaml = True
Damit ist die Installation von ansible-core
abgeschlossen. Im folgenden Code-Block wird geprüft, ob Ansible sich grundsätzlich mit dem Zielsystem verbinden und dort einen Python-Interpreter identifizieren kann.
(ansible-core2.x) [t14s python-venv]$ ansible -i hosts --private-key ~/.ssh/ansible_id_rsa -m ping example.com
example.com | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
Um Podman auf dem Zielsystem konfigurieren zu können, wird die genannte Ansible-Collection benötigt, welche mit folgendem Befehl installiert werden kann. Der Code-Block zeigt zusätzlich die Ausgabe während der Installation.
(ansible-core2.x) [t14s ansible-core2.x]$ ansible-galaxy collection install containers.podman
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/containers-podman-1.8.2.tar.gz to /home/tronde/.ansible/tmp/ansible-local-8729oh0om8w3/tmp7tv2yrae/containers-podman-1.8.2-9rw3fd1y
Installing 'containers.podman:1.8.2' to '/home/tronde/.ansible/collections/ansible_collections/containers/podman'
containers.podman:1.8.2 was installed successfully
Nextcloud benötigt für den Betrieb eine Datenbank. Hierfür könnte man eine integrierte SQLite nutzen. Dies wird jedoch nur für kleine Umgebungen empfohlen. Während der Entstehung dieses Artikels wird MariaDB als Datenbank-Backend vom Nextlcoud-Projekt empfohlen. Daher habe ich mich entschieden, das Nextcloud-Image zusammen mit einem MariaDB-Container zu deployen. Dazu greife ich auf die beiden folgenden Container-Repositorien zurück:
Das Grundgerüst bzw. die Verzeichnisstruktur für die Ansible-Rolle wurde erstellt mit:
$ ansible-galaxy role init --offline ansible_role_deploy_nextcloud_with_mariadb_pod
Die aktuelle Version der Ansible-Rolle ist auf GitHub zu finden. Ich werde ihre Bestandteile hier im Einzelnen vorstellen.
In der Datei defaults/main.yml
habe ich Standardwerte für Variablen definiert, die geeignet sind, eine funktionsfähige Nextcloud-Instanz zu initialisieren. Die Bezeichner der Variablen sind dabei der Dokumentation der verwendeten Container-Repositorien entnommen.
In Zeile 4-7 und 10 werden die Namen für Podman-Volumes definiert, welche die persistent zu speichernden Daten aufnehmen werden.
1 ---
2 # defaults file for ansible_role_deploy_nextcloud_with_mariadb_pod
3 # Podman volumes for Nextcloud
4 NC_HTML: nc_html
5 NC_APPS: nc_apps
6 NC_CONFIG: nc_config
7 NC_DATA: nc_data
8
9 # Podman volume for MariaDB
10 MYSQL_DATA: mysql_data
Die Zeilen 13-17 definieren Variablen für die MariaDB-Instanz, wie z.B. Namen der Datenbank, Benutzername und Passwörter für diese Datenbank und den DB-Host. Diese werden neben dem MariaDB-Container auch von dem Nextcloud-Container benötigt, um eine Verbindung zur Datenbank herstellen zu können.
12 # MySQL/MariaDB vars
13 MYSQL_DATABASE: nc_db
14 MYSQL_USER: nextcloud
15 MYSQL_PASSWORD: ToPSeCrEt2021!
16 MYSQL_ROOT_PASSWORD: ToPSeCrEt2021!
17 MYSQL_HOST: 127.0.0.1
18
19 # Vars for MariaDB container
20 MARIADB_CONMON_PIDFILE: /tmp/mariadb_conmon.pid
21 MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
22 MARIADB_NAME: nc_mariadb
Zeile 20-22 definiert Variablen, die für den MariaDB-Container benötigt werden. Hier wird z.B. die Version des Container-Images (MARIADB_IMAGE
) und ein Name für die Container-Instanz (MARIADB_NAME
) festgelegt.
Die folgenden Zeilen widmen sich den Variablen für den Nextcloud-Container. Dort werden in den Zeilen 25 u. 26 Benutzername und Passwort für den Nextcloud-Admin definiert, gefolgt von einigen Variablen, welche bei Nutzung eines Reverse-Proxy benötigt werden und SMTP-Variablen, welche der Nextcloud den Mailversand ermöglichen.
24 # Nextcloud vars
25 NEXTCLOUD_ADMIN_USER: nc_admin
26 NEXTCLOUD_ADMIN_PASSWORD: VSnfD2021!
27 NEXTCLOUD_OVERWRITEPROTOCOL: ""
28 NEXTCLOUD_OVERWRITECLIURL: ""
29 NEXTCLOUD_TRUSTED_DOMAINS: ""
30
31 # SMTP vars
32 SMTP_HOST: smtp.example.com
33 SMTP_SECURE: tls # ssl to use SSL, or tls zu use STARTTLS
34 SMTP_PORT: 587 # (25, 465 for SSL, 587 for STARTTLS)
35 SMTP_AUTHTYPE: LOGIN
36 SMTP_NAME: bob@example.com
37 SMTP_PASSWORD: MailSecret1!
38 MAIL_FROM_ADDRESS: no-reply@example.com
39 MAIL_DOMAIN: "@example.com"
Bei den SMTP-Variablen handelt es sich um Beispiel-Werte. Diese müssen an die konkrete Umgebung angepasst werden.
Es folgen nun noch ein paar Variablen, welche dem Pod und dem Nextcloud-Container einen Namen geben, sowie die Version des zu verwendenden Nextcloud-Container-Images festlegen.
41 # Vars for podman-pod(1)
42 POD_NAME: nc_pod
43 POD_PORT: 127.0.0.1:40231:80
44 POD_INFRA_CONMON_PIDFILE: /tmp/nc_pod_infra.pid
45
46 # Vars for Nextcloud container
47 NC_CONMON_PIDFILE: /tmp/nc_conmon.pid
48 NC_IMAGE: docker.io/library/nextcloud:23-apache
49 NC_NAME: nextcloud
Durch POD_PORT: 127.0.0.1:40231:80
wird definiert, dass der Port 40231 an das Loopback-Interface gebunden und mit Port 80 des Pods verknüpft wird. Mit dieser Einstellung ist die Nextcloud-Instanz nur von dem Host aus erreichbar, auf dem sie ausgebracht wurde. Möchte man sie auch von anderen Hosts aus erreichbar machen, kann man entweder den Teil mit 127.0.0.1:
weglassen oder einen Reverse-Proxy wie z.B. NGINX verwenden. Ich empfehle an dieser Stelle letzteres.
Hinweis: In defauts/main.yml
stehen Passwörter im Klartext. Diese sind mit der Veröffentlichung der Ansible-Rolle allgemein bekannt und sollten gegen solche ersetzt werden, die geheimgehalten werden. Dies kann z.B. geschehen, in dem man die entsprechenden Variablen in vars/main.yml
oder host_vars/hostname
neu definiert. Es bietet sich an, diese zusätzlich mit Ansible-Vault zu verschlüsseln.
Im vorstehenden Abschnitt wurden die Variablen definiert, welche für die nun folgenden Tasks benötigt werden. Diese sind in tasks/main.yml
definiert und werden im folgenden wieder abschnittsweise erläutert.
1 ---
2 # tasks file for ansible_role_deploy_nextcloud_with_mariadb_pod
3 - name: Main folder, needed for updating
4 containers.podman.podman_volume:
5 state: present
6 name: "{{ NC_HTML }}"
7 recreate: no
8 debug: no
9
10 - name: Volume for installed/modified apps
11 containers.podman.podman_volume:
12 state: present
13 name: "{{ NC_APPS }}"
14 recreate: no
15 debug: no
16
17 - name: Volume for local configuration
18 containers.podman.podman_volume:
19 state: present
20 name: "{{ NC_CONFIG }}"
21 recreate: no
22 debug: no
23
24 - name: Volume for the actual data of Nextcloud
25 containers.podman.podman_volume:
26 state: present
27 name: "{{ NC_DATA }}"
28 recreate: no
29 debug: no
30
31 - name: Volume for the MySQL data files
32 containers.podman.podman_volume:
33 state: present
34 name: "{{ MYSQL_DATA }}"
35 recreate: no
36 debug: no
Die ersten Zeilen enthalten Tasks, durch welche die Podman-Volumes zur persistenten Datenspeicherung auf dem Zielsystem erstellt werden. Diese Tasks sind, wie für Ansible üblich, deklarativ und idempotent. Existiert ein Volume bereits, liefert der entsprechende Task ein ‚OK‘ zurück, da keine Aktionen erforderlich sind.
Die folgenden Zeilen erstellen den Podman-Pod und fügen ihm einen Nextcloud- sowie einen MariaDB-Container hinzu. Die Dokumentation der verwendeten Module findet sich in Punkt 5 und 6 im Abschnitt Quellen und weiterführende Links.
38 - name: Create the podman-pod(1)
39 containers.podman.podman_pod:
40 debug: no
41 infra: yes
42 infra_conmon_pidfile: "{{ POD_INFRA_CONMON_PIDFILE }}"
43 publish: "{{ POD_PORT }}"
44 name: "{{ POD_NAME }}"
45 state: started
46
47 - name: Create MariaDB container
48 containers.podman.podman_container:
49 debug: yes
50 conmon_pidfile: "{{ MARIADB_CONMON_PIDFILE }}"
51 image: "{{ MARIADB_IMAGE }}"
52 image_strict: yes
53 pod: "{{ POD_NAME }}"
54 recreate: yes
55 state: started
56 name: "{{ MARIADB_NAME }}"
57 env:
58 MYSQL_USER: "{{ MYSQL_USER }}"
59 MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
60 MYSQL_ROOT_PASSWORD: "{{ MYSQL_ROOT_PASSWORD }}"
61 MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
62 volume: "{{ MYSQL_DATA }}:/var/lib/mysql:Z"
63
64 - name: Wait for DB to initilize
65 wait_for:
66 timeout: 20
67
68 - name: Create Nextcloud container
69 containers.podman.podman_container:
70 debug: no
71 conmon_pidfile: "{{ NC_CONMON_PIDFILE }}"
72 image: "{{ NC_IMAGE }}"
73 image_strict: yes
74 pod: "{{ POD_NAME }}"
75 recreate: yes
76 state: started
77 name: "{{ NC_NAME }}"
78 env:
79 MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
80 MYSQL_USER: "{{ MYSQL_USER }}"
81 MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
82 MYSQL_HOST: "{{ MYSQL_HOST }}"
83 NEXTCLOUD_ADMIN_USER: "{{ NEXTCLOUD_ADMIN_USER }}"
84 NEXTCLOUD_ADMIN_PASSWORD: "{{ NEXTCLOUD_ADMIN_PASSWORD }}"
85 NEXTCLOUD_TRUSTED_DOMAINS: "{{ NEXTCLOUD_TRUSTED_DOMAINS }}"
86 SMTP_HOST: "{{ SMTP_HOST }}"
87 SMTP_SECURE: "{{ SMTP_SECURE }}"
88 SMTP_PORT: "{{ SMTP_PORT }}"
89 SMTP_AUTHTYPE: "{{ SMTP_AUTHTYPE }}"
90 SMTP_NAME: "{{ SMTP_NAME }}"
91 SMTP_PASSWORD: "{{ SMTP_PASSWORD }}"
92 MAIL_FROM_ADDRESS: "{{ MAIL_FROM_ADDRESS }}"
93 MAIL_DOMAIN: "{{ MAIL_DOMAIN }}"
94 OVERWRITEPROTOCOL: "{{ NEXTCLOUD_OVERWRITEPROTOCOL }}"
95 OVERWRITECLIURL: "{{ NEXTCLOUD_OVERWRITECLIURL }}"
96 volume:
97 - "{{ NC_HTML }}:/var/www/html:Z"
98 - "{{ NC_APPS }}:/var/www/html/custom_apps:Z"
99 - "{{ NC_CONFIG }}:/var/www/html/config:Z"
100 - "{{ NC_DATA }}:/var/www/html/data:Z"
In Zeile 64-66 habe ich einen Task definiert, der einfach nur 20 Sekunden wartet. Dies wurde erforderlich, da ich Laufzeitprobleme feststellen konnte, wenn der Nextcloud-Container startet, bevor die Datenbank im MariaDB-Container initialisiert war. Dieses Konstrukt ist nicht schön und ich bin für Verbesserungsvorschläge offen.
Die Erstellung der Ansible-Rolle hat länger gedauert, als angenommen. Dies liegt nur zum Teil in meiner spärlichen Freizeit begründet. Einen größeren Einfluss darauf hatte die Dokumentation zum Nextcloud-Repository. Diese geht davon aus, dass man ein Dockerfile bzw. Docker-Compose verwendet. So war noch etwas Internet-Recherche erforderlich, um den Pod letztendlich ans Laufen zu bringen.
Dieser Artikel beschäftigte sich mit den Tag-1-Aufgaben, an deren Ende eine Nextcloud-Instanz ausgebracht wurde, welche an einen Reverse-Proxy angebunden werden kann.
Im nächsten Artikel gehe ich auf die Konfiguration des NGINX-Reverse-Proxy ein. Hierbei habe ich einige Überraschungen erlebt, welche mich an der Reife des Projekts [2] zweifeln lassen.