Wer Red Hat Enterprise Linux (RHEL) betreiben möchte, benötigte dazu eine sogenannte Subskription, im Folgenden RHEL-Sub genannt. Die Kosten für eine RHEL-Sub ergeben sich aus der Art der RHEL-Sub und dem damit verbundenen Service-Level. Der schon etwas ältere Artikel Support-Subskriptionen von SUSE und Red Hat gibt hierzu einen kleinen Einblick.
Da RHEL-Klone wie AlmaLinux und Rocky Linux kostenlos verfügbar sind, kommt schnell die Frage auf: „Warum soll ich für RHEL soviel Geld bezahlen, wenn ich quasi das gleiche OS unter anderem Namen kostenlos nutzen kann?“
Um bei der Beantwortung dieser Frage zu helfen, stelle ich in diesem Artikel einige potenzielle Mehrwerte vor, die man mit dem Erwerb einer RHEL-Sub erhält.
Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.
Kostenlose RHEL-Subs
Nicht alle RHEL-Subs kosten Geld. Es gibt auch zwei Subskriptionen, mit denen sich RHEL und bestimmten Rahmenbedingungen kostenlos betreiben lässt.
Die Subskription muss jedes Jahr verlängert werden. Die Verlängerung ist ebenfalls kostenlos.
Die Subskription beinhaltet keinen kommerziellen Support. Man hat lediglich Zugriff auf die Wissensdatenbank und die Customer Portal Community. Die SaaS-Dienste Red Hat Insights und Image Builder können auch mit dieser Subskription genutzt werden.
Red Hat Developer Subscription for Teams
Im Unterschied zur oben vorgestellten individuellen Subskription dürfen Systeme mit der RHEL-Sub-for-Teams nicht in Produktion betrieben werden. Sie dient ausschließlich der Entwicklung, dem Test und der Qualitätssicherung. Dafür dürfen mit dieser Sub eine sehr große Anzahl RHEL-Systeme provisioniert werden.
Ich bin mir nicht sicher, ob ich eine genaue Zahl nennen darf. Darum glaubt mir bitte, wenn ich euch sage: „Es sind wirklich eine Menge Berechtigungen für physische und virtuelle Systeme enthalten.“
Diese Subskription erhaltet ihr nur über euer Red Hat Account Management. Falls ihr dieses (noch) nicht kennt, wendet euch im Zweifel an die Firma, wo ihr eure RHEL-Subs kauft.
Mich selbst hat es einige Mühen gekostet, an diese Sub zu kommen. Laut Aussage meines Account-Managers war ich der erste Kunde in Deutschland, der diese Sub kannte und haben wollte. Dank der Red Hat Accelerators und meines Account-Managers, der nicht aufgegeben hat, hat es schlussendlich geklappt. Falls ihr Probleme habt, diese Sub zu bekommen, schreibt mich einfach an. Vielleicht habe ich noch einen Tipp für euch.
Für den Support, Zugriff auf Red Hat Insights und Image Builder gelten die gleichen Bedingungen wie für die RHEL Developer Subscription for Individuals.
Support
Support meint an dieser Stelle nicht die Hilfe und Unterstützung, die man auf Mailinglisten, in Foren oder Chats erhalten kann. Gemeint ist ausschließlich der kommerzielle Support der Firma Red Hat, welchen man per Telefon, E-Mail oder das Customer Portal erreichen kann.
Über den Support hat man Kontakt zu den Menschen, die sich vermutlich am besten mit dem Produkt auskennen. Hier sitzen Menschen, die dafür bezahlt werden, uns Kunden bestmöglich zu unterstützen. Dabei mag es von Fall zu Fall Schwankungen in der Reaktionszeit und/oder der Qualität geben.
Mir persönlich hat der Support schon in etlichen Fragestellungen und bei einigen hartnäckigen Problemen weiterhelfen können. Dabei waren so schöne Dinge wie Kernel Panic bei Zugriff auf eine eingehängte DFS-Ressource, deren Shares in einer HNAS-Speicher-Infrastruktur liegen. Ich glaube, sowas haben die wenigsten Menschen bei sich daheim im Keller stehen. Und die Chance, bei diesem Problem Hilfe in einem Forum oder Chat zu finden, dürfte dementsprechend gering sein. Der Support stellte in diesem Fall Kontakt zu einem Engineer her, der über eine hervorragende Kenntnis der beteiligten Protokolle und Protokollversionen verfügte und beim Debugging unterstützte. Am Ende erhielten wir einen angepassten Kernel, der das Problem löste und den wir nutzen konnten, bis das Problem auch Upstream und im regulären RHEL-Kernel gefixt wurde.
Nicht zuletzt ist kommerzieller Support ein guter Verbündeter, wenn man selbst nicht weiterweiß und sich Druck aufbaut. Nach dem Motto: „Wenn selbst der Hersteller nicht weiter weiß, woher soll ich dann wissen, warum es nicht geht?“ Es ist nie schön, wenn es soweit kommt. Noch hässlicher wird es, wenn man dann nicht auf jemand anderen zeigen kann.
Red Hat Insights
Zu Red Hat Insights (engl.) habe ich in der Vergangenheit bereits eine eigene Serie geschrieben, auf die ich an dieser Stelle verweise:
Dieser Dienst steht auch mit den kostenlosen Developer-Subs zur Verfügung. Vorausgesetzt, die Nutzung ist unter geltendem Recht möglich, stellt dieser Dienst einen echten Mehrwert dar. Ein vergleichbarer Dienst existiert für AlmaLinux und Rocky Linux nicht.
Image Builder (SaaS)
In größeren Umgebungen (IHMO >2 Systeme) werden Server meist nicht mehr individuell installiert, sondern von sogenannten Images oder Templates provisioniert. Diese sind initial zu erstellen und fortlaufend zu pflegen.
Image Builder ist ein SaaS-Dienst in Red Hat Insights, welcher bei der Erstellung solcher Templates unterstützt. Dabei können Images direkt für die Cloud Anbieter Amazon Web Services, Google Cloud Platform, Microsoft Azure, VMware vSphere, KVM/QEMU (.qcow2) und Bare Metal erstellt werden.
Es handelt sich dabei um einen noch recht jungen Dienst, der einige Einschränkungen hat. So ist das einzige derzeit unterstützte Dateisystem für Images XFS. Ein RFE, um Ext4 als unterstütztes Dateisystem hinzuzufügen, ist gestellt.
Auch lassen sich aktuell über diesen Dienst noch keine User oder SSH-Public-Keys in die Images integrieren. Für diese Funktionalität habe ich ebenfalls bereits RFEs geschrieben.
Ich bin gespannt, wie Red Hat diesen Dienst weiterentwickelt. In meinen Augen hat er das Potenzial, zu einem nützlichen Werkzeug zu reifen.
Diesen Dienst kann man ebenfalls mit den kostenlosen Developer-Subs nutzen, während ein vergleichbarer Dienst meines Wissens für AlmaLinux und Rocky Linux nicht existiert.
Fazit
Ob die genannten Mehrwerte tatsächlich zum Tragen kommen, muss jeder für sich und seine Organisation selbst beurteilen. Sie sollten jedoch vor einer Entscheidung in die Überlegungen mit einbezogen werden.
Die Nutzung von Red Hat Insights ist in unserem Rechtsraum schwierig, bis nahezu unmöglich. Dort wo der Dienst genutzt werden kann, stellt er ein gutes Werkzeug dar, welches dem Admin die tägliche Arbeit erleichtert.
Ich werde ein kleines Heimlabor aus RHEL-Servern aufbauen und diese in Red Hat Insights integrieren. Vielleicht gewinne ich dadurch Erkenntnisse, die sich auch auf den Betrieb im Rechenzentrum übertragen lassen.
Der Image Builder ist als SaaS in seiner jetzigen Form nur von geringem Nutzen für mich. Ich hoffe, dass meine RFEs akzeptiert und umgesetzt werden, um diesen Service und dessen Nutzen weiter auszubauen.
In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:
Wer betreibt das Projekt bzw. steht hinter dem Projekt?
Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
Welchen Eindruck hinterlässt die Dokumentation?
Wie lange wird ein Major-Release unterstützt?
Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
Wie handhaben die Projekte Sicherheits-Updates?
Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.
Was haben beide Projekte gemeinsam?
Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:
Produktionsreife Betriebssysteme
Binärkompatibel zu RHEL
Werden aus den RHEL-Quelltexten übersetzt
Für den Nutzer kostenlos
Bieten 10 Jahre Unterstützung für ein Major-Release
Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.
Wer steht hinter den Distributionen?
Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.
Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.
Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.
RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.
Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.
Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.
Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.
Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.
Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.
Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.
Softwareunterstützung
Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.
Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.
Dokumentation
Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.
Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.
Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.
Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.
Release-Zyklen
Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.
Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.
Bereitstellung von Sicherheits-Updates
Alle drei Projekte stellen Produkt-Errata im Internet bereit:
Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.
Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.
Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.
Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.
Zusammenfassung
Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.
Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.
Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.
Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.
Update 13.05.2022: Das Plug-in ist in Version 220513 repariert und wurde wieder deaktiviert. Danke an BobaWebDev für den schnellen Fix.
Liebe Leser*innen, leider ist das Plugin Subscribe to Comments Reloaded in der installierten Version 220512 offenbar defekt. Daher habe ich das Plugin vorerst deaktiviert.
Der Fehler wurde bereits in GitHub-Issue 707 gemeldet. Ich hoffe, dass der Fehler bald durch den Anbieter behoben wird.
Die Kommentarfunktion kann weiterhin wie gewohnt genutzt werden. Nur könnt ihr euch aktuell nicht über neue Kommentare benachrichtigen lassen.
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.
Gedanken zum Update
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.
Der Update-Prozess
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:
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:
$ 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.
Fazit
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.
Den allermeisten IT-Systemadministratoren werden die Programme dig, host und nslookup aus dem Paket bind-utils bekannt sein. Sie dienen der Auflösung von Hostnamen. Mir sind jedoch wiederholt Systeme begegnet, auf denen diese Programme nicht zur Verfügung stehen. Dies führte mich zur Eingangsfrage, wie ich Hostnamen auflösen kann, ohne das Paket bind-utils nachinstallieren zu müssen.
Die Antwort liefert der folgende Codeblock. Das Programm getent(1) stammt aus der glibc, welche auf jedem Linux-System vorhanden ist. Voraussetzung ist lediglich, dass das System für die Nutzung von DNS-Resolvern konfiguriert ist (z.B. /etc/resolv.conf).
Diese Frage habe ich mir selbst schon mehrmals gestellt. Und mindestens genauso oft wurde sie mir schon von anderen gestellt. Als Antwort kommen hier meist zuerst telnet oder netcat (nc) in den Sinn. Doch in einer RHEL-Minimal-Installation sind diese beiden Programme nicht enthalten und müssen erst nachinstalliert werden. Was tut man in diesem Fall (ohne den Paketmanager zu starten)?
Ich möchte in diesem Artikel mehrere Antworten auf die Eingangsfrage festhalten. Dabei beginne ich mit denen, die ich auf stackoverflow gefunden habe.
Bash und timeout
Von RHEL 6 aufwärts sollte das Programm timeout in der Minimal-Installation enthalten sein. In Fedora 35 und Debian 11 ist es ebenfalls enthalten. Es stammt aus dem Paket coreutils, in dem es meines Wissens spätestens seit Version 8.22 enthalten ist.
Mit timeout und nc habe ich meine beiden Favoriten festgehalten. Mit beiden lässt sich die Erreichbarkeit von entfernten TCP-Ports testen (die von lokalen TCP-Ports übrigens auch).
Falls ihr noch weitere Möglichkeiten kennt, mit Bordmitteln, die in der Minimal-Installation einer Distribution enthalten sind, um einen Verbindungstest durchzuführen, schreibt sie mir gern in die Kommentare. Ich nehme sie dann gern mit in den Artikel auf.
Hallo und herzlich willkommen zu Teil 5 von Nextcloud im Container. In diesem Artikel geht es um Backup und Restore. Die vorhergehenden Teile dieser Serie sind weiter unten verlinkt.
Backup
Mit dem Thema Backup und Restore im Containerland habe ich mich bereits in einem früheren Artikel beschäftigt. Da ich mit dem Ansatz von dort nicht ganz zufrieden bin, gehe ich in diesem Wochenend-Projekt einen anderen Weg.
Für Nextcloud existiert die App Backup, welche im Folgenden zum Einsatz kommt. Diese wird über die App-Verwaltung in den Admin-Einstellungen der Nextcloud aktiviert.
Die englischsprachige Dokumentation (siehe [5]) macht einen soliden und verständlichen Eindruck. Ich habe mich von dieser durch die Konfiguration führen lassen.
Standard-Einstellungen der Nextcloud-Sicherungs-App
Ich habe die im obigen Bild dargestellten Einstellungen wie folgt geändert:
Zeitintervall zwischen zwei vollständigen Wiederherstellungspunkten: 7 Tage
Die Verschlüsselung für Wiederherstellungspunkte habe ich deaktiviert
Richtlinie für die lokalen App-Daten: 4
Nun kann man über die entsprechende Schaltfläche einen vollständigen Wiederherstellungspunkt erstellen. Alternativ kann man auch warten, bis das Zeitfenster für den ersten vollständigen Wiederherstellungspunkt erreicht ist.
Ich habe die Sicherung einige Tage mitlaufen lassen. Wie der folgende Screenshot zeigt, wurden ein Full-Backup und zwei darauf folgende differenzielle Backups erzeugt, bevor ein neues Full-Backup erstellt wurde.
Backup-Historie am 13.03.2022
Hierbei ist zu beachten, dass die Backups in der gleichen Container-Instanz liegen wie die Live- bzw. Produktions-Daten. Damit ist es noch kein richtiges Backup. Denn wenn diese Instanz komplett zerstört wird, ist auch das Backup weg. Die Backups müssen daher unbedingt an einem anderen Ort gespeichert werden. Ich habe mich entschieden, diesem Thema einen eigenen Artikel zu widmen und es in Teil 6 Desaster-Recovery zu behandeln.
Wiederherstellung einer einzelnen Datei
An dieser Stelle möchte ich festhalten, wie eine einzelne Datei wiederhergestellt werden kann. Mit der Wiederherstellung einer kompletten Nextcloud-Instanz beschäftige ich mich in einem folgenden Artikel.
Wiederherstellungspunkte auflisten
Um vorhandene Wiederherstellungspunkte auflisten zu können, wechselt man auf dem Container-Host zuerst in die Container-Instanz mit der laufenden Nextcloud:
Durch ‚-u 33′ betritt man den Container mit der UID des Users www-data, welcher berechtigt ist, die folgenden Kommandos auszuführen. In obigem Beispiel heißt die Container-Instanz schlicht ’nextcloud‘. Für weitere Informationen zum Kommando siehe podman-exec(1). Die Restore-Points können nun wie folgt aufgelistet werden:
www-data@nc_pod:~/html$ ./occ backup:point:list
- retreiving data from local
> found RestoringPoint 20220305001002-full-3ebDDoh2yinj55C
> found RestoringPoint 20220307235028-differential-W558tuHGTnCbwgx
> found RestoringPoint 20220310234002-differential-1NHETYudPSx6Yxc
> found RestoringPoint 20220312001002-full-i1SY9VxDZRL8n1O
Ausgabe gekürzt.
Einen Wiederherstellungspunkt nach einer Datei durchsuchen
Angenommen, die Bilddatei Frog.jpg ist abhandengekommen. Nun kann ein Wiederherstellungspunkt wie folgt nach dem Dateinamen durchsucht werden:
www-data@nc_pod:~/html$ ./occ backup:file:search --point 20220305001002-full-3ebDDoh2yinj55C Frog.jpg
- searching in 20220305001002-full-3ebDDoh2yinj55C (2022-03-05 00:10:02)
1/1 [============================] 100%
> found tronde/files/Photos/Frog.jpg (447.02 KB) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
> found bob/files/Photos/Frog.jpg (447.02 KB) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
1/1 [============================] 100%
> found core/skeleton/Photos/Frog.jpg (447.02 KB) in nextcloud/nextcloud-853e4f81-7f34-4a85-a428-1f569fe7efb5
1/1 [============================] 100%
In dem angegebenen Wiederherstellungspunkt existiert die Datei Frog.jpg insgesamt dreimal. Es wird jeweils der komplette Pfad angezeigt.
Wiederherstellung von bob/files/Photos/Frog.jpg
Nun soll die Datei Frog.jpg für den Benutzer Bob aus dem oben verwendeten Wiederherstellungspunkt wiederhergestellt werden. Da meine Wiederherstellungspunkte komprimiert gespeichert werden, dient der erste Befehl im folgenden Codeblock jedoch erstmal dazu, einen Wiederherstellungspunkt zu entpacken.
www-data@nc_pod:~/html$ ./occ backup:point:unpack 20220305001002-full-3ebDDoh2yinj55C
Unpacking Restoring Point 20220305001002-full-3ebDDoh2yinj55C
> lock and set status to unpacking
> Browsing RestoringData data
> Unpacking RestoringChunk data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e: proceeding
* copying parts to temp files
- 00001-Ur86KyoXRnp8Evt: /tmp/phpkzVs4Y
* merging parts into single file: /tmp/phpyLjmxZ
* Extracting /tmp/phpyLjmxZ: /tmp/phpmJG1O1
- storing chunk in appdata ok
* removing old chunk parts
> Browsing RestoringData nextcloud
> Unpacking RestoringChunk nextcloud-853e4f81-7f34-4a85-a428-1f569fe7efb5: proceeding
* copying parts to temp files
- 00001-EUEeVME26dbQyf6: /tmp/phpVfSAt3
* merging parts into single file: /tmp/phpc3kVw0
* Extracting /tmp/phpc3kVw0: /tmp/phpF1kt52
- storing chunk in appdata ok
* removing old chunk parts
> Browsing RestoringData apps
> Unpacking RestoringChunk apps-14864f48-87a9-4c61-82f5-33defc3de2d2: proceeding
* copying parts to temp files
- 00001-65lDdATRHTQde5b: /tmp/phpDngG62
* merging parts into single file: /tmp/php9U5X7Y
* Extracting /tmp/php9U5X7Y: /tmp/phpXGwXP0
- storing chunk in appdata ok
* removing old chunk parts
> Browsing RestoringData config
> Unpacking RestoringChunk config-a8809c3e-5259-49b4-b2cb-2dbeb755949f: proceeding
* copying parts to temp files
- 00001-HMfvJewXGLEckCH: /tmp/phpPePsK1
* merging parts into single file: /tmp/phpVlxXA1
* Extracting /tmp/phpVlxXA1: /tmp/phpBUIDm0
- storing chunk in appdata ok
* removing old chunk parts
> Browsing RestoringData apps-custom_apps-84a585e6
> Unpacking RestoringChunk apps-custom_apps-84a585e6-c4e2adaa-eb06-4318-8196-62aea73b89c8: proceeding
* copying parts to temp files
- 00001-pXttjhVm9cRU6DU: /tmp/phpATT8t2
* merging parts into single file: /tmp/php8HMcR1
* Extracting /tmp/php8HMcR1: /tmp/phpmHRKS1
- storing chunk in appdata ok
* removing old chunk parts
> Browsing RestoringData sqldump
> Unpacking RestoringChunk sqldump-d0ebed1c-81dd-418b-a8ba-cecca8d92c00: proceeding
* copying parts to temp files
- 00001-QYOIpn2zOj43TsL: /tmp/phpcEUqQZ
* merging parts into single file: /tmp/phpOwn0g1
* Extracting /tmp/phpOwn0g1: /tmp/phpiJxrh3
- storing chunk in appdata ok
* removing old chunk parts
> removing status packed
> unlocking restoring point
www-data@nc_pod:~/html$ ./occ backup:point:restore 20220305001002-full-3ebDDoh2yinj55C --file bob/files/Photos/Frog.jpg --data data
> restoring bob/files/Photos/Frog.jpg (447.02 KB) from /data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e (rewind: 8 days, 20 hours, 51 minutes and 20 seconds): ok
Die allgemeine Befehlsform für die Wiederherstellung lautet:
Es ist nicht gut dokumentiert, wie man den korrekten Wert für --data herausfindet. Ich habe diesen durch Ausprobieren gefunden. Dann war der Restore jedoch kein Problem mehr. Wie man die korrekten Werte für --data bzw. --chunk sicher identifiziert, muss ich noch herausfinden. Falls hier jemand einen Tipp für mich hat, freue ich mich über euren Kommentar oder eine E-Mail.
Um Speicherplatz zu sparen, komprimiere ich den genutzten Wiederherstellungspunkt wieder und verlasse den Container:
www-data@nc_pod:~/html$ ./occ backup:point:pack 20220305001002-full-3ebDDoh2yinj55C
Packing Restoring Point 20220305001002-full-3ebDDoh2yinj55C
> lock and set status to processing
> Browsing RestoringData data
> Packing RestoringChunk data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e: proceeding
* copying chunk to temp file /tmp/phpsyGIxw: ok
* compressing /tmp/phpsyGIxw: /tmp/phpjuZY7z
* spliting /tmp/phpjuZY7z in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e.zip
> Browsing RestoringData nextcloud
> Packing RestoringChunk nextcloud-853e4f81-7f34-4a85-a428-1f569fe7efb5: proceeding
* copying chunk to temp file /tmp/php6f6Kfx: ok
* compressing /tmp/php6f6Kfx: /tmp/phpz3Ndtz
* spliting /tmp/phpz3Ndtz in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file nextcloud-853e4f81-7f34-4a85-a428-1f569fe7efb5.zip
> Browsing RestoringData apps
> Packing RestoringChunk apps-14864f48-87a9-4c61-82f5-33defc3de2d2: proceeding
* copying chunk to temp file /tmp/phpf19OHA: ok
* compressing /tmp/phpf19OHA: /tmp/phpZMcpmw
* spliting /tmp/phpZMcpmw in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file apps-14864f48-87a9-4c61-82f5-33defc3de2d2.zip
> Browsing RestoringData config
> Packing RestoringChunk config-a8809c3e-5259-49b4-b2cb-2dbeb755949f: proceeding
* copying chunk to temp file /tmp/phpykt9Rw: ok
* compressing /tmp/phpykt9Rw: /tmp/phpxik6bx
* spliting /tmp/phpxik6bx in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file config-a8809c3e-5259-49b4-b2cb-2dbeb755949f.zip
> Browsing RestoringData apps-custom_apps-84a585e6
> Packing RestoringChunk apps-custom_apps-84a585e6-c4e2adaa-eb06-4318-8196-62aea73b89c8: proceeding
* copying chunk to temp file /tmp/php1oAWAA: ok
* compressing /tmp/php1oAWAA: /tmp/phpOtyrjA
* spliting /tmp/phpOtyrjA in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file apps-custom_apps-84a585e6-c4e2adaa-eb06-4318-8196-62aea73b89c8.zip
> Browsing RestoringData internal
> Packing RestoringChunk app.zip: already packed
> Packing RestoringChunk restore.php: already packed
> Browsing RestoringData sqldump
> Packing RestoringChunk sqldump-d0ebed1c-81dd-418b-a8ba-cecca8d92c00: proceeding
* copying chunk to temp file /tmp/phpFfW2zy: ok
* compressing /tmp/phpFfW2zy: /tmp/phpvXl8qy
* spliting /tmp/phpvXl8qy in parts: 1 part(s)
- storing parts in appdata .ok
* Removing old chunk file sqldump-d0ebed1c-81dd-418b-a8ba-cecca8d92c00.zip
> removing status processing, adding status packed
> unlocking restoring point
www-data@nc_pod:~/html$ exit
exit
Wiederherstellung eines Ordners inkl. Inhalt
Manchmal ist es erforderlich, statt einzelner Dateien ganze Ordner inkl. Inhalt wiederherzustellen. Wie dies funktioniert, demonstriere ich im Folgenden für den Ordner Documents des Benutzers Bob. Dazu wechsle ich zuerst wieder in den Container, wie in diesem Abschnitt bereits beschrieben wurde.
TL;DR: Die Wiederherstellung eines Ordners inkl. dessen Inhalts ist aktuell nicht möglich (siehe [6]). Wer es eilig hat, kann direkt zum Fazit springen.
www-data@nc_pod:~/html$ ./occ backup:file:search bob/files/Documents --until 2022-03-15
- searching in 20220305001002-full-3ebDDoh2yinj55C (2022-03-05 00:10:02)
1/1 [============================] 100%
> found bob/files/Documents/Example.md (1.07 KB) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
> found bob/files/Documents/Nextcloud flyer.pdf (365.24 KB) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
> found bob/files/Documents/Readme.md (136 B) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
> found bob/files/Documents/Welcome to Nextcloud Hub.docx (24.56 KB) in data/data-baa61d4a-85a8-4cc7-b43b-5a6270b7143e
1/1 [============================] 100%
- searching in 20220307235028-differential-W558tuHGTnCbwgx (2022-03-07 23:50:28)
1/1 [============================] 100% no result
- searching in 20220310234002-differential-1NHETYudPSx6Yxc (2022-03-10 23:40:02)
1/1 [============================] 100% no result
- searching in 20220312001002-full-i1SY9VxDZRL8n1O (2022-03-12 00:10:02)
1/1 [============================] 100%
> found bob/files/Documents/Example.md (1.07 KB) in data/data-f55df957-3368-4b84-b957-4dc3e819c0ce
> found bob/files/Documents/Nextcloud flyer.pdf (365.24 KB) in data/data-f55df957-3368-4b84-b957-4dc3e819c0ce
> found bob/files/Documents/Readme.md (136 B) in data/data-f55df957-3368-4b84-b957-4dc3e819c0ce
> found bob/files/Documents/Welcome to Nextcloud Hub.docx (24.56 KB) in data/data-f55df957-3368-4b84-b957-4dc3e819c0ce
1/1 [============================] 100%
- searching in 20220314234502-differential-suwLdJJegRlO4XI (2022-03-14 23:45:02)
1/1 [============================] 100% no result
Es muss der vollständige Pfad zum gesuchten Verzeichnis angegeben werden. Wildcards wie z.B. */Documents oder "*/Documents" funktionieren genauso wenig wie reguläre Ausdrücke. Dies kann die Suche nach einem Ordner schonmal schwierig gestalten. Denn welcher Anwender kennt schon den vollständigen Pfad zu dem Ordner, der vermisst wird?
Im obigen Codeblock ist zu sehen, dass der Pfad zum Ordner lediglich als Bestandteil der Pfade zu den darin enthaltenen Dateien angezeigt wird. Dies und die Erkenntnis, keine Suchmuster verwenden zu können, lassen bei mir erste Zweifel aufkommen, ob das Verzeichnis inkl. Inhalt wiederhergestellt werden kann, oder ob ich jede enthaltene Datei einzeln wiederherstellen muss.
Doch bevor ich mich an der Wiederherstellung versuchen kann, muss ich zuerst den ausgewählten Wiederherstellungspunkt entpacken. Wie dies aussieht, kann dem Abschnitt über die Dateiwiederherstellung entnommen werden.
Der folgende Codeblock zeigt dann auch, dass der Ordner nicht wiederhergestellt werden kann:
www-data@nc_pod:~/html$ ./occ backup:point:restore 20220312001002-full-i1SY9VxDZRL8n1O --file bob/files/Documents --data data
In ChunkService.php line 925:
[OCA\Backup\Exceptions\ArchiveFileNotFoundException]
backup:point:restore [--force] [--do-not-ask-data] [--do-not-ask-sql] [--file FILE] [--chunk CHUNK] [--data DATA] [--] <pointId>
Eine Wiederherstellung ist offenbar nur auf Dateiebene möglich (siehe [6]). Das ist sehr schade, da dies die Wiederherstellung deutlich verkompliziert. Vor allem da Wildcards ebenfalls nicht funktionieren.
Fazit
In diesem Artikel habe ich das Thema Backup und Recovery aufgegriffen. Ich habe kurz beschrieben, wie eine Sicherung mit der Nextcloud-Backup-App konfiguriert werden kann. Nachdem einige Wiederherstellungspunkte erstellt wurden, habe ich exemplarisch eine Datei wiederhergestellt.
Da die Wiederherstellungspunkte komprimiert gespeichert werden, musste der ausgewählte Wiederherstellungspunkt vor dem Restore erst dekomprimiert werden, was einige Zeit gedauert hat. Hier muss jeder für sich selbst entscheiden, ob man sich die kürzere Zeit zur Wiederherstellung mit einem erhöhten Speicherbedarf durch unkomprimierte Wiederherstellungspunkte erkaufen möchte oder nicht.
Die zu Beginn des Artikels noch gelobte Dokumentation offenbarte schnell Lücken und ich muss mein Urteil revidieren. Sie ist im besten Fall ausreichend.
Der Versuch, einen Ordner inkl. Inhalt wiederherzustellen, endete hingegen in einer Enttäuschung. Dies ist aktuell offenbar nicht möglich, da nur der Datei-Restore oder die Wiederherstellung der gesamten Nextcloud-Instanz unterstützt wird. Diese Erfahrung lässt mich ein wenig enttäuscht und unzufrieden zurück.
Wie sichert ihr eure Nextcloud? Welche Restore-Fälle habt ihr damit bereits durchgespielt? Ich freue mich auf eure Kommentare und darauf euch zu Teil 6: Desaster-Recovery Updates wieder begrüßen zu dürfen.
Update 27.03.2022
Der obige Text wurde dahingehend angepasst, dass nun deutlich wird, dass die Wiederherstellung ganzer Verzeichnisse inkl. deren Inhalt aktuell nicht unterstützt wird (siehe [6]). Nicht mehr zutreffende Textstellen habe ich gestrichen.
Entgegen meiner ursprünglichen Planung wird es keinen Artikel zum Thema Desaster-Recovery geben, da es mir aktuell nicht möglich ist, die Restore-Points auf externem Speicher abzulegen (siehe [7] und [8]).
Damit ist die Backup-App in ihrem aktuellen Zustand (Version 1.0.6; Stand 27.03.2022) in meinen Augen unbrauchbar. Das ist schade, da mir die Idee, die Backup&Recovery-Funktion als App direkt zu integrieren, vom Grundsatz her gut gefällt.
Bis auf Weiteres verfahre ich daher so, wie analog im Artikel Backup und Restore im Kanboard-Container-Land beschrieben. Das dort beschriebene Verfahren lässt sich auch hier anwenden und genügt meinen Anforderungen.
Nach Teil 3 habe ich die Zwei-Faktor-Authentisierung über TOTP für meine Nutzerkonten aktiviert, die Bookmark-, Calendar- und Contact-App installiert bzw. aktiviert, ein paar Kalendertermine erstellt und ein paar Dateien hochgeladen. Nichts Wichtiges. Lediglich ein paar Daten, die ich nach einem Backup zerstören kann, um anschließend den Restore-Prozess zu testen. Zuvor möchte ich aber noch ein paar Dinge festhalten, die mir bisher aufgefallen sind.
Background jobs: Cron does not run
In den Grundeinstellungen der Nextcloud werden Hintergrund-Aufgaben konfiguriert. Diese sind laut des dortigen Hinweises wichtig, um die optimale Geschwindigkeit zu erreichen:
Um die optimale Geschwindigkeit zu erreichen ist es wichtig, dass die Hintergrund-Aktivitäten richtig konfiguriert sind. Für größere Installationen ist ‚Cron‘ die empfohlene Einstellung. Weitere Informationen findest Du in der Dokumentation.
Grundeinstellungen in den Nextcloud-Einstellungen
Die Überschrift ist der Titel des GitHub-Issues #1695. Dieser beschäftigt sich damit, dass Cron in der Container-Instanz nicht läuft. Halt genau so, wie Cron dies bei mir auch nicht tut.
Der Benutzer beryl03, welcher den Issue eröffnet hat, beschreibt, dass Cron in der Container-Instanz nicht verfügbar ist und er in der Dokumentation keinen Hinweis darauf gefunden hat. Um das Problem zu mitigieren hat beryl03 einen Cronjob auf seinem Container-Host konfiguriert, welcher sich mit der Container-Instanz verbindet und darin die Datei cron.php ausführt. Welch elender Workaround. Aber immerhin gibt es einen. Denn die Hintergrund-Aufgaben mit AJAX auszuführen, scheitert leider ebenfalls. Schade, so habe ich mir das tatsächlich nicht vorgestellt.
Im Verlauf von Issue #1695 wird darauf hingewiesen, dass zur Verwendung von Cron ein weiterer Container benötigt wird (siehe [3]). Dies wird in den Beispielen zu den Compose-Dateien beschrieben (siehe [4]). Da ich Podman und Ansible statt Docker-Compose verwende, habe ich mir diese Beispiele natürlich nicht angesehen. Das ist dem Projekt nicht anzulasten, da ich mich ja bewusst für einen anderen Weg entschieden habe. Doch denke ich, dass man das Thema Hintergrund-Aufgaben innerhalb der Projekt-Dokumentation als auch in der Nextcloud-Dokumentation etwas ausführlicher behandeln könnte und sollte. Doch wie gehe ich nun mit dem Problem um, dass meine Hintergrund-Aufgaben nicht ausgeführt werden?
Docker-Compose mit Podman nutzen
Tatsächlich habe ich einen Artikel gefunden, welcher beschreibt, wie man Docker-Compose ab Podman 3.0 nutzen kann. Allerdings bietet dieser nur eine Lösung für den Fall, dass man Podman als User root bzw. mit Root-Rechten ausführt. Da Podman bei mir rootless läuft, kommt die Lösung für mich nicht in Frage.
Nach etwas weiterer Recherche habe ich einen RFE gefunden, welcher diese Funktionalität auch für rootless-Podman fordert. Die gute Nachricht lautet, dass diese Funktion mit Podman 3.2 veröffentlicht wurde. Pech für mich, dass unter Debian stable lediglich Podman 3.0.1 in den Quellen verfügbar ist.
Ein Workaround ist besser als gar keine Lösung
Tatsächlich erscheint mir aktuell der Workaround von beryl03 (siehe [1]) der beste Weg zu sein, um die Hintergrund-Aufgaben ausführen zu lassen. Dazu führe ich auf meinem Container-Host folgenden Befehl aus:
Damit wird das Skript cron.php innerhalb der Container-Instanz mit der Nextcloud ausgeführt. Mit -u 33 wird die UID von www-data innerhalb der Container-Instanz angegeben. Für eine genaue Erklärung des Befehls und seiner Optionen siehe podman-exec(1).
Die Hintergrund-Aufgaben wurden nun erfolgreich ausgeführt
Da ich nicht gern lange Befehle in die Crontab schreibe, erstelle ich ein kurzes Skript namens nextcloud_cron.sh, welches obigen Befehl aufnimmt und welches ich alle 5 Minuten von Cron ausführen lasse. Damit werde ich sich noch sehr lange arbeiten, denn nicht umsonst sagen manche: „Nichts hält so lange, wie ein gutes Improvisorium.“
Fazit von Teil 4
Ich hoffe, die Artikelserie hat euch bis hierhin ein wenig unterhalten. Wer nach einer einfachen Lösung gesucht hat, bei der man ein bis zwei Container-Images aus dem Regal nimmt, ein paar Variablen mit Werten füllt, sie auf einen Container-Host provisioniert, ausführt und fertig ist, wird sicher gemerkt haben, dass er diese Lösung in dieser Artikelreihe nicht findet.
Auch ich habe mir zu Beginn nicht vorgestellt, dass es so hakelig werden würde. Schließlich soll mit Containern doch alles einfacher werden, nicht wahr? Warum mache ich also weiter und lasse das ganze Wochenend-Projekt nicht einfach fallen? Neugier, Sturheit, eine nutzbare Nextcloud-Instanz und auch ein bisschen Spaß bilden die Antwort auf vorstehende Frage. Und deshalb mache ich auch weiter. In Teil 5 wird es um Backup und Restore gehen.
Wie betreibt ihr eure Nextcloud? Mit Container oder ohne? Unter Docker, K3s, K8s, Podman, OpenShift oder einer noch ganz anderen Lösung? Lasst es mich gern in den Kommentaren wissen. Habt ihr über eure Erfahrungen in eurem eigenen Blog geschrieben, lasst mir gern einen Link hier. Macht es gut, bis nächste Woche.
In diesem Teil beschreibe ich die Konfiguration von NGINX als Reverse-Proxy für mein Wochenend-Projekt „Nextcloud im Container“. Und was so langweilig klingt, wie lediglich die Direktive proxy_pass in die NGINX-Konfiguration einzufügen, dauerte dann doch überraschend lange.
Darüber hinaus dokumentiere ich die Konfiguration von fail2ban, um die Anmeldemaske der Nextcloud vor Brute-Force-Angriffen zu schützen.
Falls ihr Teil 1 und Teil 2 dieser Reihe noch nicht kennt, empfehle ich euch, diese Teile zuerst zu lesen.
Die Fehlschläge
Bevor ich zur aktuellen Konfig komme, möchte ich kurz die Fehlschläge auf dem Weg dorthin festhalten.
Nextcloud im Unterverzeichnis nicht so einfach wie gedacht
Auf meinem Server läuft bereits ein Dienst, welcher unter der URL https://www.example.com/service1 erreichbar ist. Mir gefiel die Idee, die Nextcloud unter einer URL wie https://www.example.com/service2 erreichbar zu machen.
Die Dokumentation des Container-Repos [3] ist in meinen Augen zu kurz geraten und reicht für eine erfolgreiche Konfiguration längst nicht aus.
Nachdem ich einiges über die Generierung von Back-to-URLs und Redirects gelesen und im Nextcloud-Forum gestöbert hatte, ließ ich die Idee fallen. Ich warte mal ab, wie sich Issue #401 entwickelt. Vielleicht greife ich die Idee später nochmal auf.
Falsche Back-to-URLs und Protokoll-Probleme
Im nächsten Versuch, sollte Nextcloud unter einer eigenen Domain wie nextcloud.example.com erreichbar sein. Doch auch hier klemmte es zunächst. Zuerst stolperte ich in den bekannten Untrusted-Domain-Fehler.
Bekannte Fehlermeldung, wenn trusted_domains in config.php nicht korrekt gesetzt ist.
Diesen Fehler konnte ich schnell abstellen, da ich lediglich vergessen hatte die Variable NEXTCLOUD_TRUSTED_DOMAINS mit einem Wert zu belegen. Als Wert ist der FQDN einzutragen, unter dem die Nextcloud erreichbar sein soll. Dieser ist explizit anzugeben, da der Apache-Prozess innerhalb des Nextcloud-Containers den FQDN, auf den der NGINX-Reverse-Proxy lauscht und welcher im HTTP-Header übertragen wird, nicht kennt.
Des Weiteren musste ich noch die Variablen NEXTCLOUD_OVERWRITEPROTOCOL und NEXTCLOUD_OVERWRITECLIURL in vars/main.yml mit Werten belegen, um die entsprechenden Umgebungsvariablen für die Container-Instanz zu setzen (vgl. [3]). Dies ist notwendig, da die Anwendung im Nextcloud-Container andernfalls Back-to-URLs für das HTTP-Protokoll generiert. Versucht der Browser diese aufzurufen, erscheint ein Fehler oder man landet in einer endlosen Redirect-Schleife.
Nachdem ich die Nextcloud mit Hilfe der Ansible-Rolle [2] erneut deployt habe, war der Login-Screen erreichbar:
Nextcloud-Login-Screen
Der Weg hierher war für meinen Geschmack aufwändiger als er hätte sein müssen. Nur durch Lektüre und Recherche der Quellen unter [4], [5] und [6] konnte ich mich von Problem zu Problem hangeln und diese lösen. Hier ist in meinen Augen noch Raum für Verbesserungen.
Die aktuell funktionierende Konfiguration
Meine NGINX-vHost-Konfiguration habe ich mir mithilfe von [4], [5] und [6] zusammengesucht und bin bei folgender Konfig gelandet (es werden nur relevante Abschnitte wiedergegeben):
Ob dies eine gute Konfiguration ist, mag ich nicht beurteilen. Sie funktioniert zumindest. Die Nextcloud ist erreichbar und über die Weboberfläche können weitere Einstellungen vorgenommen, Nutzerkonten erstellt und Apps installiert werden.
Fail2ban für Nextcloud
Nun steht die Nextcloud mit ihrer Login-Maske im Wind. Sie stellt damit ein schönes Ziel für Brute-Force-Angriffe dar. Um es den Angreifern nicht zu leicht zu machen, habe ich für den Nextcloud-Admin keinen einfach zu erratenen Namen wie Admin, Nextcloud-Admin oder meinen Namen verwendet. Um Angreifer weiter auszubremsen, konfiguriere ich fail2ban. Wie dies installiert wird, schlagt bitte in der Dokumentation eurer Distribution nach. Ich gehe hier nicht auf die Installation ein.
Damit fail2ban fehlgeschlagene Anmeldeversuche erkennt, habe ich die Datei /etc/fail2ban/filter.d/filter.d/jk_nextcloud.conf mit folgendem Inhalt erstellt:
Wenn innerhalb der findtime von 43200 Sekunden von einer IP-Adresse mehr als drei fehlgeschlagene Anmeldeversuche (maxretry) registriert werden, wird die entsprechede IP-Adresse für 86400 Sekunden (bantime) gesperrt. Eine Statusabfrage ist wie folgt möglich:
$ sudo fail2ban-client status jk_nextcloud
[sudo] password for tronde:
Status for the jail: jk_nextcloud
|- Filter
| |- Currently failed: 1
| |- Total failed: 5
| `- File list: /home/tronde/.local/share/containers/storage/volumes/nc_data/_data/nextcloud.log
`- Actions
|- Currently banned: 0
|- Total banned: 1
`- Banned IP list:
Es ist zu erkennen, dass aktuell keine IP-Adresse gesperrt ist. In der Vergangenheit wurde jedoch bereits eine IP gebannt.
Für mich stellt fail2ban einen Baustein zur Sicherung der Nextcloud bereit. Zusätzlich werde ich eine Zwei-Faktor-Authentisierung konfigurieren, um die Sicherheit weiter zu steigern.
Zusammenfassung
An diesem Punkt meines Wochenend-Projekts kann ich eine Nextcloud-Instanz mit meiner Ansible-Rolle deployen und hinter einem Reverse-Proxy nutzen. Bisher schützt fail2ban vor Brute-Force-Angriffen. Zukünftig wird jedoch eine Zwei-Faktor-Authentisierung diesen Schutz verstärken.
Eine lauffähige Konfiguration zu erstellen, hat dabei länger gedauert, als ich mir vorgestellt habe. Dabei hat mir missfallen, dass dies nicht mit der Dokumentation allein gelang, sondern das Forum [5] und die Internetsuchmaschine meines geringsten Misstrauens zurate gezogen werden mussten. Damit ist dieses Projekt jedoch bei weitem kein Einzelfall.
307 offene Issues (Stand 05.02.2022) zeugen davon, dass hier noch längst nicht alles rund läuft. Von der Idee, dass es sich hierbei um ein Fire-and-Forget-Projekt handeln könnte, verabschiede ich mich lieber. So bin ich auch gleich in das unter [7] beschriebene Problem getreten. Erfreulicher Weise hat die dort beschriebene Lösung funktioniert, so dass meine Cloud mir jetzt E-Mails senden kann. Ich werde mir Gedanken machen, wie die entsprechenden Abschnitte in der Dokumentation verbessert werden können und dem Projekt einen Pull-Request senden. Mal schauen wie man darauf reagiert.
Damit sind die in Teil 1 formulierten Ziele 1-3 erreicht. In Teil 4 beschäftige ich mich mit einigen weiteren Steinen, über die ich gestolpert bin, bevor ich mich dann in Teil 5 dem Thema Backup & Recovery widme.
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.
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.
Installation der Ansible-Collection containers.podman
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
Ansible-Rolle: Deployment von Nextcloud und MariaDB als Pod
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.
Die Variablen in defaults/main.yml
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.
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.
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.
Die Tasks in tasks/main.yml
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.
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.
Zwischenfazit
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.
Dies ist der Beginn meines zweiten Container-Projekts. Nach Kanboard im Container möchte ich diesmal eine Nextcloud-Instanz als Container, zusammen mit einem Datenbank-Container, in einem Podman-Pod betreiben.
Da ein einzelner Artikel vermutlich zu lang wird, teile ich das Projekt in mehrere Artikel auf. Wie viele es genau werden, kann ich jetzt noch nicht sagen. Am Ende der Reihe werde ich hier eine Übersicht einführen und die einzelnen Teilen entsprechend miteinander verbinden.
In diesem ersten Teil geht es um meine Motivation, das eigentliche Ziel und den groben Plan.
Was Leser dieser Reihe erwartet
Ihr könnt mich durch diese Reihe begleiten und euch von meinen Erlebnissen und Erkenntnissen unterhalten lassen. Dabei dürft ihr nicht annehmen, dass es sich bei dem von mir beschriebenen Vorgehen um eine gute Praxis handelt. Hier gilt eher: Der Weg ist das Ziel.
Ihr seid herzlich eingeladen, die Artikel zu kommentieren und über das Vorgehen und Alternativen dazu zu diskutieren. Gern in der Kommentarsektion unter den jeweiligen Beiträgen oder als Artikel in euren eigenen Blogs.
Ich plane die Artikel im Wochenrhythmus, wenigstens monatlich, zu veröffentlichen. Bitte verzeiht, wenn es etwas unregelmäßig wird. Dies ist ein Hobby, dem nur begrenzt Zeit zur Verfügung steht.
Motivation
Bei Linux-Containern handelt es sich um eine Technologie, die gekommen ist, um zu bleiben. Sie hat bereits in vielen Branchen Fuß gefasst und immer mehr Projekte bieten ihre Anwendungen zusätzlich oder ausschließlich in Form von Containern an.
Als Sysadmin mittleren Alters werden mich Linux-Container sicher noch viele Jahre begleiten. Um praktische Erfahrungen mit dem Betrieb zu sammeln, möchte ich einige private Projekte in Containern betreiben.
Beruflich arbeite ich überwiegend mit RHEL. Red Hat engagiert sich stark in den Projekten Ansible und Podman, welche ich auch unter anderen Distributionen, wie z.B. Debian, einsetze. Ich möchte das Projekt als Chance nutzen, mein Wissen auch in diesen Werkzeugen zu festigen und auszubauen.
Ich spiele schon seit einiger Zeit mit dem Gedanken, wieder eine eigene Nextcloud-Instanz zu betreiben. Da auf dem zur Verfügung stehenden Server bereits eine Nextcloud-Instanz läuft und ich meine Anwendung von der bestehenden Instanz getrennt und möglichst losgelöst vom Betriebssystem betreiben möchte, habe ich mich entschieden, Nextcloud im Container zu betreiben.
Ziele
Ziel dieses Projekts sind das Deployment und der Betrieb einer Nextcloud-Instanz als Podman-Pod. Im Einzelnen sollen folgende Ziele erreicht werden:
Entwicklung eines wiederverwendbaren Verfahrens zum Deployment einer Nextcloud im Container
Persistente Speicherung von Konfigurations- und inhaltlichen Daten im Dateisystem des Hosts
Konfiguration eines Reverse-Proxies (NGINX) für den Zugriff auf die Nextcloud-Instanz
Konfiguration von Backup und Restore für Konfiguration und Inhalte der Nextcloud-Instanz
Konfiguration und Test automatischer durch Ansible gesteuerter Updates
Umgebung
Für die Umsetzung des Projekts steht mir ein Virtual Private Server (VPS) mit genügend Ressourcen zur Verfügung. Dieser wird in einem Rechenzentrum in Deutschland betrieben. Auf diesem sind Debian Bullseye, NGINX, ein OpenSSH-Server, Podman 3.0.1 (rootless) und Python 3.9.2 installiert. Damit erfüllt dieses System die Voraussetzungen, um mit Ansible konfiguriert zu werden und Container ausführen zu können.
Ansible selbst läuft in meiner privaten Arbeitsumgebung auf meinem Debian-PC und einem Fedora-35-Notebook.
Methodik und verwendete Werkzeuge
Zu Beginn habe ich mich etwas in der Nextcloud-Dokumentation und den verfügbaren Nextcloud-Images belesen. Besagte Dokumentation sowie die der verwendeten Werkzeuge sind im folgenden Abschnitt verlinkt.
Um die oben formulierten Ziele zu erreichen, werde ich in einem Python Virtual Environment eine Ansible-Version installieren, mit der ich die Collection containers.podman nutzen kann. Hiermit werde ich eine Ansible-Rolle entwickeln, die ich wiederverwenden kann, um Nextcloud-Instanzen in einer rootless-Podman-Umgebung zu deployen. Die Ansible-Rolle wird anschließend auf meinem GitHub-Account veröffentlicht.
Die Konfiguration von NGINX und acme.sh für die TLS-Zertifikate erfolgt manuell.
Quellen und weiterführende Links
In diesem Abschnitt liste ich Links zu Artikeln und Dokumentationen auf, welche ich im Vorfeld gelesen habe und deren Kenntnis ich für die Umsetzung als nützlich erachte. Zur besseren Übersicht gliedere ich diese in die Unterabschnitte Hintergrundwissen, Dokumentation und Eigene Artikel.
In Dirks Artikel „Wechsel auf Thunderbird“ wurden einige interessante und gute Einstellungen für den Donnervogel genannt, die ich in mein Setup übernommen habe. Um diese nicht jedes Mal in Dirks Logbuch nachschlagen zu müssen, dokumentiere ich sie hier kurz.
Alle Einstellungen werden unter Edit / Preferences / General / Config Editor vorgenommen.
Damit der Donnervogel standardmäßig alle Ordner auf eingehende E-Mails prüft, wird mail.server.default.check_all_folders_for_new auf true geändert. Um global die Thread-Ansicht zu aktivieren, wird mailnews.default_view_flags auf 1 gesetzt. Wer gern per Tastatur mit der Taste ’n‘ zur nächsten ungelesenen Nachricht geht, freut sich evtl. wenn dies auch ohne Nachfrage Ordner-übergreifend funktioniert. Dafür wird mailnews.nav_crosses_folders auf 0 gesetzt.
Danke Dirk, vinzv, Bad Penguin und Jens für den Artikel und eure Tipps.
Denn in seinem Linkdump bin ich über den Artikel „Journaling: Schreib dich erfolgreich und glücklich“ von Eric Kubitz gestolpert. Der Text hat grundsätzlich mein Interesse an der Methode geweckt. Jedoch zweifelte ich, ob mir das tägliche Ausfüllen vorgedruckter Bücher nicht schnell langweilig wird. Zum Glück hatte Dirk einen Tipp für mich parat.
Dirk hat mir diesen Kurs auf Udemy empfohlen, welcher Ende 2021 noch für knapp 10 Euro zu kaufen war. Für den Preis kann man in meinen Augen nicht viel falsch machen und so buchte ich den Kurs.
Der Kurs führt in englischer Sprache in die Methode „Journaling“ ein, stellt diverse Prompts vor und gibt Tipps, wie man beginnt und durchhält. Der Trainer spricht klar und deutlich (habe ich auch schon schlechter gehört). So konnte ich dem Kurs gut folgen. Für den günstigen Preis ist es in Ordnung, dass auch ein paar Minuten Marketing dabei sind. Mir hat der Kurs gut gefallen.
Für mich ist das Journal wie ein Logbuch. Ich führe es morgens zwischen Frühstück und dem Öffnen meines Posteingangs. Ich halte darin Dinge fest, an denen ich gerade arbeite, was ich kürzlich gelernt habe, wofür ich dankbar bin, worauf ich mich freue und was die wichtigsten Aufgaben des Tages sind, die ich erledigen muss.
Zu Weihnachten bekam ich ein Logbuch geschenkt, das geradezu Lust darauf macht, hineinzuschreiben.
Dies ist mein erstes Journal. Und ja, ich mag schöne Einbände.
Ungefähr seit Weihnachten schreibe ich regelmäßig. Es wird langsam zu einem Ritual, auf das ich mich freue. Es hilft mir, den vorangegangenen Tag zu reflektieren und mich auf die dringendsten und wichtigsten Aufgaben des Tages zu fokussieren. Zudem hilft es, die positiven Dinge in den Vordergrund zu holen. Denn wenn man ein wenig darüber nachdenkt, findet man in fast jedem Tag auch Dinge, die gut waren. Leider spielt unser Gehirn uns gern einen Streich und fokussiert sich auf die negativen Dinge, die schiefgelaufen sind bzw. genervt haben. Journaling hilft, dies zu ändern und auf positive Gedanken zu kommen.
Anmelden
