Dies ist ein Update des Artikels aus dem letzten Jahr.

Smartphone

Mein Sony Xperia XZ2 Compact musste aufgrund mehrerer Macken ersetzt werden. Mein neuer Begleiter ist nun ein Samsung Galaxy S22. Zwar habe ich mir auch ein Fairphone angesehen, doch ist mir dieses einfach viel zu groß. Nutzungsänderungen ergaben sich lediglich bei den Messenger-Diensten und den sozialen Netzwerken:

• Für Chat und Kurznachrichten mit Matrix über Element (dienstlich)/neu: FluffyChat (privat), SMS und Threema (bevorzugt).
• Nutzung diverser sozialer Netzwerkwerke wie Facebook, LinkedIn, Mastodon, Twitter und XING; meine Accounts in den gestrichenen Netzwerken habe ich gelöscht.

Tablet

Hier hat sich gegenüber dem Vorjahr nichts verändert.

Laptop

Hier gab es lediglich ein Upgrade auf Fedora 37 und Rambox ist hamsket gewichen.

Desktop-/Server-PC

Auch hier gibt es keine Änderungen gegenüber dem Vorjahr.

Sonstige Geräte im Netzwerk

Unverwüstlich verrichtet mein Brother DCP-540CN weiterhin zuverlässig seinen Dienst. Meine FHEM-Installation hingegen habe ich eingestampft und meinen Pi-Hole auf den Raspberry Pi 1 Rev. B migriert. Damit habe ich wieder einen Pi für neue Basteleien frei.

Zusammenfassung

Viel hat sich hier nicht verändert und ich bin mit dem aktuellen Setup zufrieden. Ob es im Jahr 2023 etwas mehr Veränderungen geben wird, wird sich zeigen.

Hallo liebe Leserinnen und Leser,

in diesem Beitrag möchte ich um eure Meinungen und Gedanken zur Distribution IPFire 2.x und einer dafür erhältlichen Hardware-Appliance bitten.

IST-Zustand

Es existiert ein einfaches Heimnetzwerk, welches über eine Vodafone ConnectBox mit dem Internet verbunden ist. Die Firewall der ConnectBox ist aktiviert und es sind aktuell keinerlei eingehende Verbindungen zugelassen.

Im LAN existieren eine Vielzahl unterschiedlicher Geräte, wie z.B. Access-Points, Pi-Hole, PCs, Laptops, PV-Anlage, Netzwerkdrucker, etc. pp.

SOLL-Zustand

Das bestehende Heimnetzwerk soll in verschiedene Netzwerkzonen unterteilt werden können, welche durch eine Firewall voneinander getrennt sind. Es soll eine Möglichkeit zur VPN-Einwahl geschaffen werden, um von außerhalb des Netzwerks auf Dienste im Heimnetzwerk zugreifen zu können. Der vorhandene Kabelrouter soll nicht ersetzt werden.

Bei der Internet-Recherche bin ich auf IPFire gestoßen, für welche ich als ehemaliger IPCop-Nutzer eine gewisse Sympathie hege. Zudem habe ich mit der IPFire Mini Appliance (EU) ein Gerät im Blick, welches am Aufstellungsort eine gute Figur machen sollte. Mir ist dabei wichtig, dass das Gerät möglichst sparsam bei der Energieaufnahme ist und passiv gekühlt wird, damit im Betrieb keine Geräusche verursacht werden.

Ich möchte die IPFire als Paketfilter, OpenVPN-Gateway und ggf. IPS nutzen.

Ihr seid gefragt

Bevor ich nun ca. 450 Euro investiere, möchte ich die Chance nutzen und nach euren Erfahrungen mit IPFire und den verfügbaren Appliances fragen.

Habt ihr IPFire genutzt oder nutzt sie noch? Seid ihr damit zufrieden, oder würdet ihr zu einer Alternative raten? Wenn Alternative, welche und warum?

Worauf betreibt ihr IPFire? Auf einer Appliance wie der oben verlinkten, einem Raspberry Pi, in einer VM oder auf etwas ganz anderem? Lasst es mich gerne wissen, warum ihr euch für welche Lösung entschieden habt.

Falls ihr jetzt die Hände über dem Kopf zusammenschlagt und ruft: „Nein alles, nur das nicht!“ Dann bin ich natürlich umso mehr an eurer Erfahrung interessiert.

Bitte nutzt die Kommentare oder schreibt mir an „ipfire (aett) my-it-brain (Punkt) de“, wenn ihr eure Gedanken mit mir teilen möchtet.

Quellen und weiterführende Links

• Wikipedia-Artikel zu IPFire: https://de.wikipedia.org/wiki/IPFire
• Projekt-Webseite: https://www.ipfire.org/
• IPFire Mini Appliance im IPFire-Wiki: https://wiki.ipfire.org/hardware/lightningwirelabs/mini
• IPFire Mini Appliance im Online-Shop: https://store.lightningwirelabs.com/products/IPFIRE-MINI-EU-R1

In diesem Artikel führe ich auf, was ich 2022 für bzw. mit FLOSS getan habe. FLOSS steht dabei für Free/Libre Open Source Software. Es geht dabei nicht um weltbewegende Projekte oder große Beiträge. Es ist mehr eine Sammlung von Kleinigkeiten. Dennoch möchte ich diese öffentlich machen, um zu zeigen, was man mit FLOSS tun und wie man sich beteiligen kann.

Ansible-Rolle zum Deployment von Nextcloud und MariaDB in einem Podman Pod

Dieses kleine Projekt ist etwas verrückt und für den Einsatz in Produktion vermutlich nicht geeignet. Doch konnte ich mich gleich mit zwei Themen intensiv beschäftigen, die mich interessieren, Ansible und Podman. Mein Ziel war es, die Anwendungen Nextcloud und MariaDB zur Bereitstellung einer privaten Cloud in einem rootless Podman Pod zu provisionieren. Die ganze Geschichte kann in der kleinen Serie Nextcloud im Container nachgelesen werden.

Die Quellen der Ansible-Rolle gibt es auf:

• Github: https://github.com/Tronde/ansible_role_deploy_nextcloud_with_mariadb_pod
• Galaxy: https://galaxy.ansible.com/Tronde/deploy_nextcloud_with_mariadb_pod

RHEL-Patchmanagement

Seit 2016 entwickle und pflege ich ein Patch-Management für Red Hat Enterprise Linux Systeme. Dieses Jahr habe ich Release 3.3.0 und 3.3.1 veröffentlicht.

Mit diesem Projekt habe ich ein Patch-Management gebaut, welches sehr gut die Anforderungen meines Arbeitgebers abdeckt und sich ohne Zusatz-Subskriptionen wie das Smart-Management-Addon für RHEL-Subskriptionen realisieren lässt. Seit 2018 läuft es vollautomatisch und stellt sicher, dass verfügbare Sicherheits-Updates mindestens einmal pro Monat installiert werden.

Es erfreut sich auch außerhalb unserer Organisation einiger Beliebtheit:

• Github: https://github.com/Tronde/ansible-role-rhel-patchmanagement/
• Galaxy: https://galaxy.ansible.com/Tronde/ansible_role_rhel_patchmanagement

Drei Ansible-Rollen dank Open Source

Häufig haben Unternehmen/Organisationen sehr individuelle Anforderungen, für die keine fertigen Lösungen von der Stange existieren. Open Source schafft die Möglichkeit, sich selbst helfen zu können. So habe ich ohne großen Aufwand Ansible-Rollen geschrieben, um Proxy-Einstellungen für den subscription-manager und YUM bzw. DNF zu konfigurieren sowie um Red Hat Enterprise Linux registrieren und den System Purpose konfigurieren zu können.

Quellen:

• Github: https://github.com/Tronde/set_proxy4yum_dnf
• Galaxy: https://galaxy.ansible.com/Tronde/set_proxy4yum_dnf
• Github: https://github.com/Tronde/set_proxy4rhsm
• Galaxy: https://galaxy.ansible.com/Tronde/set_proxy4rhsm
• Github: https://github.com/Tronde/register_syspurpose
• Galaxy: https://galaxy.ansible.com/Tronde/register_syspurpose

Meine erste Linux System Role

Die Linux System Roles sind eine Sammlung von Ansible-Rollen zur Konfiguration diverser Betriebssystem-Komponenten von Linux. Ziel der Sammlung ist es, Ansible-Rollen zur einfachen Nutzung durch Systemadministratoren bereitzustellen.

Ich habe viel über den Entwicklungsprozess von Ansible-Rollen gelernt, bis meine erste Rolle pam_pwd aufgenommen wurde. Mit dieser Rolle kann PAM konfiguriert werden, um eine Passwort-Richtlinie zu etablieren.

Sie befindet sich noch in einem sehr frühen Stadium. Nutzt sie auf eigene Gefahr. Der Lerneffekt für mich war jedoch sehr groß, so dass sich die Arbeit in meinen Augen gelohnt hat.

Quelle:

• Github: https://github.com/linux-system-roles/pam_pwd

Mit Ansible Labor-Umgebungen in KVM und vSphere provisionieren

Ich benötige immer mal wieder Labor-Umgebungen mit frischen Betriebssystem-Installationen für verschiedene Versuche und Tests. Um die Provisionierung dieser Laborumgebung zu vereinfachen und zu beschleunigen, habe ich zwei Ansible-Rollen erstellt, mit denen sich diese Labor-Umgebungen auf KVM- und vSphere-Hypervisoren provisionieren lassen:

• Labor-Umgebung mit Ansible in KVM erstellen
• Labor-Umgebungen auf VMware vSphere erstellen mit der Ansible-Rolle vsphere_provision_lab

Blogs, Issue-Reports Pull-Requests

Man kann FLOSS auch dadurch unterstützen, indem man darüber spricht bzw. schreibt. Letzteres tue ich in diesem Blog. Der My-IT-Brain Jahresrückblick 2022 gibt einen Überblick darüber.

Hinzu kommen kleine Beiträge in Form von Issue-Reports und Pull-Requests. Details kann man meiner Contribution Activity auf Github entnehmen.

Spenden

Viele FLOSS-Projekte werden ohne funktionierendes Geschäftsmodell von Menschen in deren Freizeit entwickelt und gewartet. Diese Projekte sind auf Spenden angewiesen.

Ich setze mir jedes Jahr ein persönliches Budget, aus dem ich an die Projekte spende, deren Anwendungen ich häufig benutze oder die mir besonders sympathisch sind. Das ist nicht immer ganz einfach. Ich persönlich bevorzuge eine Banküberweisung oder eine Einmalzahlung per Kreditkarte. Mich erst bei einem Zahlungsdienstleister anzumelden stellt für mich meist eine zu hohe Hürde dar.

Fazit

Es muss nicht das eine große Projekt sein. Auch mit der Summe kleiner Teile kann man eine Menge erreichen.

FLOSS hat mir geholfen, viele meiner Anforderungen zu erfüllen. Für mich ist es selbstverständlich, die Ergebnisse dieser Arbeit ebenfalls wieder unter einer freien Lizenz zu veröffentlichen, um auf diesem Weg etwas an die FLOSS-Gemeinschaft zurückzugeben. Doch denkt immer daran: „Nutzung auf eigene Gefahr.“

Erzeugung in 2022: 11017 kWh (+22 % gegenüber 2021)

Einspeisung 2022: 7650 kWh (+32 % gegenüber 2021)

Bezug in 2022: 1358 kWh (-26 % gegenüber 2021)

Autarkie in 2022: 71,26 % (+7,2 Prozentpunkte gegenüber 2021)

Das Jahr neigt sich dem Ende zu und ich möchte zurückblicken und mich erinnern, wie es in diesem Jahr für meinen Blog verlaufen ist.

In diesem Jahr wurden auf My-IT-Brain insgesamt 29 Artikel veröffentlicht. Dies sind zwei weniger als in 2021. Dafür habe ich jeden Monat mindestens einen Artikel veröffentlichen können.

Während ich mich im Januar mit verschiedenen Themen beschäftigt habe, konzentrierte ich mich im Februar und März auf eine sechsteilige Serie zum Thema Nextcloud im Container. Die daraus entstandene Nextcloud-Instanz läuft immer noch und wurde im Laufe des Jahres mehrmals aktualisiert. Sie ist allerdings ein Wochenendprojekt geblieben. Außer zum Teilen größerer Dateien nutze ich sie nicht aktiv.

Da ich immer mal wieder Systeme für verschiedene Test benötige, habe ich mir zwei Ansible-Rollen geschrieben, welche mir die Erstellung definierter Labor-Umgebungen erleichtern. Dokumentiert habe ich diese in:

• Labor-Umgebung mit Ansible in KVM erstellen
• Labor-Umgebungen auf VMware vSphere erstellen mit der Ansible-Rolle vsphere_provision_lab

Zur Jahresmitte habe ich einen Blick auf AlmaLinux, RHEL und Rocky Linux geworfen und mich gefragt, welche potenziellen Mehrwerte eine RHEL-Subskription bietet.

Nach meiner ersten FrOSCon habe ich entdeckt, dass es doch tatsächlich einige Förderprogramme für Open-Source-Projekte gibt und habe diese in kurzen Artikeln vorgestellt:

• Stipendien bis zu 50.000 EUR für Open Source Projekte
• Der Prototype Fund fördert eure Open-Source-Projektidee
• Der Sovereign Tech Fund öffnet Antragsverfahren 2023

Leider ist es mir aus zeitlichen Gründen nicht gelungen, Kontakt zu den bereits geförderten Projekten aufzunehmen, um über die Erfahrungen zu berichten, welche die Projekte mit den jeweiligen Förderprogrammen gemacht haben. Falls ihr ein Projekt habt, welches durch eines der genannten Programme gefördert wurde und gern darüber berichten möchtet, meldet euch doch gern bei mir. Ich schreibe eure Geschichte gern auf und veröffentliche sie hier.

Zum Jahresende wurde es dann wieder etwas ruhiger hier. Ich arbeite aktuell an einer kleinen Artikelserie, die ich mit dem Beginn des neuen Jahres veröffentlichen möchte. Worum es geht wird an dieser Stelle noch nicht verraten.

Ich freue mich, wenn ihr auch im nächsten Jahr meine Artikel lest, kommentiert, evtl. etwas daraus lern und sie unterhaltsam findet. Ich wünsche euch allen fröhliche Weihnachten und einen guten Rutsch ins Jahr 2023.

Vor einiger Zeit habe ich in Nachfolger für mein Smartphone gesucht (2022) meine Anforderungen an ein Smartphone formuliert und um eure Empfehlungen gebeten.

Ich habe mir die Entscheidung nicht leicht gemacht. In diesem Beitrag möchte ich euch verraten, für welches Gerät ich mich entschieden habe und warum.

Das Sony Xperia XZ2 Compact zeigte immer mehr Aussetzer

Zu den nervigsten Problemen zählte, dass ich sporadisch nicht mehr erreichbar war und auch keine abgehenden Anrufe tätigen konnte. Zur temporären Lösung musste ich das Gerät neustarten.

Während ich noch überlegte, erstmal nur eine neue SIM-Karte zu bestellen, kamen weitere Ausfälle hinzu. Ton wurde sporadisch nicht wiedergegeben und der Touchscreen hatte Aussetzer. Das hat mich schon sehr genervt.

Auch war der Input eines weiteren Stakeholders in diesem Erneuerungsprojekt zu berücksichtigen. Ich war zum Handeln motiviert, nachdem mein Eheweib mir sagte: „Kauf dir THE FU.. ein neues Telefon!“

Fairphone 4 und Samsung Galaxy S22 in der Endrunde

Obwohl ich vor schlechtem Support beim Fairphone gewarnt wurde, habe ich mir ein Gerät bestellt. Denn hier im Blog und von Menschen aus meinem Umfeld erhielt ich Berichte, dass sie mit ihrem Fairphone 4 sehr zufrieden seien. Meine größte Sorge war, dass mir die Größe nicht gefällt.

Auch das Samsung Galaxy S22 hatte ich näher ins Auge gefasst, war jedoch vom hohen Preis zuerst abgeschreckt. Dann habe ich dieses Gerät in einem Angebot für 609 Euro gefunden. Da dies nur knapp über meinem Budget lag, habe ich mir auch dieses Gerät zur Ansicht bestellt.

Samsung Galaxy S22 bleibt, Fairphone 4 geht zurück

Das folgende Bild zeigt mein altes Gerät und die beiden neuen Kandidaten nebeneinander.

Das Fairphone 4 ist mir persönlich deutlich zu groß. Ich kann es nicht in den gewohnten Taschen mitführen und es passt nicht in die Ablageschale in meinem Auto. Daher habe ich mich entschieden, das Samsung Galaxy S22 zu behalten.

Damit könnte dieser Beitrag enden. Ich möchte ihn jedoch mit meiner Kritik am Fairphone-Support abschließen.

Fairphone erschwert den Widerruf unnötig

Gekauft habe ich das Fairphone 4 im deutschsprachigen Online-Shop. Bestellung und Zahlungsabwicklung fanden in deutscher Sprache statt. Dass die Bestellung möglich war, ohne sich zuerst für ein Konto zu registrieren, hat mir gut gefallen. Geliefert wurde das Gerät in der avisierten Lieferzeit durch UPS.

Etwas stutzig wurde ich beim Auspacken, als ich merkte, dass keine Informationen zum 14-tägigem Widerrufsrecht und kein Retourenschein beilagen. Auch per E-Mail habe ich hierzu keine Informationen erhalten. Hier sind andere Händler in meinen Augen deutlich besser.

Um die Rücksendeadresse zu erfragen, musste ich mich nun also an den berüchtigten Support wenden, welcher tatsächlich so schlecht ist, wie mir beschrieben wurde. Dabei stellte ich fest, dass sämtliche Hilfe und Supportseiten ausschließlich in Englisch verfügbar sind. Dies stellt für mich persönlich keine Hürde dar; für andere Kunden vielleicht schon. Ich finde es seltsam, dass man den Online-Shop und Bestellprozess in Deutsch anbietet, die Hilfeseiten mit den Kontaktinformationen jedoch nur in Englisch. Doch die fehlende deutsche Sprache ist hier nicht das Schlimmste.

Am 21. Oktober sendete ich meinen Widerruf per E-Mail an den Fairphone-Support und erhielt eine Empfangsbestätigung. Am 26.10. versuchte ich den Support telefonisch zu erreichen, was mir nicht gelang; das Gespräch wurde nach 4 Minuten in der Warteschleife getrennt. Also schrieb ich erneut eine E-Mail mit der Bitte, mir schnellstmöglich die Rücksendeinformationen mitzuteilen. Noch am selben Tag erhielt ich Antwort per E-Mail. Jedoch nicht mit den Rücksendeinformationen, sondern mit der Aufforderung einen Fairphone-Account zu registrieren. Andernfalls könne mein Anliegen nicht bearbeitet werden.

Nach einem kleinen Wutanfall mittlerer Härte habe ich mir einen Fairphone-Account registriert und wie aufgefordert per E-Mail geantwortet, dass der Account nun erstellt sei und man mit der Bearbeitung fortfahren möge. Es folgten weitere Tage der Stille.

Am Montag, dem 31.10. meldete ich mich an meinem Fairphone-Account an, um den Status meiner Support-Anfrage zu kontrollieren. Zu meiner Überraschung musste ich feststellen, dass meine letzten E-Mails dem Fall gar nicht hinzugefügt wurden. Also aktualisierte ich den Fall im Support-Portal und bat um schnellstmögliche Bearbeitung und Abschluss dieses Falls. Da ich bis zum 08.11. weiterhin keine Rückmeldung bekam, rief ich erneut die Hotline an. Diesmal mit Erfolg. Ed verstand mein Problem, entschuldigte sich für die Unannehmlichkeiten und leitete den RMA-Prozess ein. Am 09.11. erhielt ich ein Retouren-Label per E-Mail. Das Paket ist nun auf dem Weg zurück und ich hoffe, dass es bald ein gutes Ende nimmt.

Es mag sein, dass sie gerade viel zu tun haben. Das ist mir jedoch völlig egal. Sie hätten es sich einfach machen können und die Widerrufs- und Rücksendeinformationen direkt der Sendung beifügen können. Ich bin über den Verlauf sehr verärgert und rate jedem davon ab, bei Fairphone zu kaufen!

Wie GNU/Linux.ch am 19.10.2022 berichtete, startet der Sovereign Tech Fund eine Pilot-Förderrunde mit sieben ausgewählten Projekten. Es ist damit bereits das dritte Förderprogramm neben dem Media Tech Lab und dem Prototype Fund, auf das ich in diesem Jahr aufmerksam geworden bin.

Der Sovereign Tech Fund unterstützt die Entwicklung, Verbesserung und Erhaltung offener digitaler Infrastrukturen. Unser Ziel ist die nachhaltige Stärkung des Open-Source-Ökosystems. Wir konzentrieren uns auf Sicherheit, Stabilität, technologische Vielfalt und die Menschen hinter dem Code.

Unter digitaler Souveränität versteht man die selbstbestimmte Nutzung digitaler Technologien und Systeme durch Einzelpersonen, Unternehmen und Regierungen. Sie kann nicht ohne ein stabiles Open-Source-Ökosystem erreicht werden. Wir müssen eine  offene digitale Infrastruktur stärken, um Sicherheit, Innovation und Wettbewerbsfähigkeit zu fördern und eine stabile digitale Grundlage für Partizipation und Demokratie zu schaffen.

URL: https://sovereigntechfund.de/index.html (Letzter Abruf: 22.10.2022)

Finanziert wird das Programm vom Bundesministerium für Wirtschaft und Klimaschutz. Es wird bei der SPRIND GMBH aufgebaut und unterstützt.

Einzelheiten über die Förderbedingungen und die Höhe bzw. Art der Förderung sind aktuell noch nicht auf der Webseite des Programms veröffentlicht. Anfang 2023 sollen dort weitere Informationen veröffentlicht werden.

Ich freue mich, dass es ein weiteres Förderprogramm gibt. Ebenso bin ich hocherfreut, dass in der Pilotrunde so wichtige Open-Source-Projekte wie OpenPGP, OpenSSH, Wireguard, curl und OpenBGP befinden.

Im September habe ich über das Förderprogramm Media Tech Lab berichtet. Heute möchte ich euch auf den Prototype Fund hinweisen, welcher Open-Source-Projektideen mit bis zu max. 47.500 Euro unterstützt.

Danke an @Kampfradler (Twitter-Link), welcher mich auf dieses Förderprogramm hingewiesen hat.

Der Prototype Fund ist ein Projekt der Open Knowledge Foundation Deutschland, gefördert durch das Bundesministerium für Bildung und Forschung (BMBF). Er existiert seit 2016 und damit schon etwas länger als Media Tech Lab. Seither wurden nach Angabe des Projekts 12,3 Mio. Euro an Fördergeldern bewilligt, mit denen 293 Projekte gefördert wurden.

Bezüglich der Rahmenbedingungen ähneln sich Media Tech Lab und der Prototype Fund auffällig. Hier die wichtigsten Eckdaten:

• Einzelpersonen und kleine (interdisziplinäre) Teams können eine finanzielle und ideelle Unterstützung für die Erprobung von Ideen sowie die Entwicklung von Open-Source-Anwendungen in den Bereichen Civic Tech, Data Literacy, IT-Sicherheit und Software-Infrastruktur (siehe FAQ) erhalten.
• Die Förderung beträgt bis zu 47.500€ über 6 Monate.
• Es gibt Unterstützung durch Mentor*innen und Coaching in den Bereichen User Centered Design, Projektmanagement, Security und Business.
• Es werden ausschließlich Open-Source-Projekte gefördert.

Der Prototype Fund ist bestrebt, Teams und Teilnehmer*innen mit weiteren Geldgeber*innen und potenziellen Partner*innen zu vernetzen. Ziel ist es, Teilnehmer*innen so gut wie möglich bei der Weiterführung ihrer „Produkte“ nach Projektende zu unterstützen.

Projekt und Förderung enden nach sechs Monaten mit der Vorstellung des Prototypen. Damit es danach weitergeht, braucht es Spender, Investoren und ein Geschäftsmodell. Diese Weiterentwicklungen sind jedoch nicht durch die Prototype-Fund-Förderung abgedeckt (Media Tech Lab hat aktuell auch noch kein Konzept für die Maintenance-Phase).

Die Projektseite biete eine gute FAQ, welche die wichtigsten Fragen zu den Rahmenbedingungen und zum Bewerbungsprozess beantwortet. Wenn ihr Interesse an einer Förderung habt, schaut hier hinein.

Ich freue mich, dass es offenbar doch mehr als ein Förderprogramm für Open-Source-Projekte in Deutschland gibt. Falls ihr noch weitere Förderprogramme für Open-Source-Projekte kennt, hinterlasst doch bitte einen Hinweis mit URL auf deren Webseite in den Kommentaren. Ich freue mich, wenn ich hier zukünftig weitere Open-Source-Förderprogramme vorstellen kann.

Ihr betreibt ein Projekt, dass durch den Prototype Fund gefördert wurde und möchtet gerne darüber berichten? Meldet euch gerne bei mir. Gern könnt ihr mir einen Entwurf für einen Erfahrungsbericht senden oder wir führen ein kurzes Interview und ich berichte anschließend von euren Erfahrungen. Because sharing is caring.

Bevor mein aktuelles Smartphone den Geist aufgibt, möchte ich ein Nachfolgemodell eruieren. Dabei setze ich auch auf eure Mithilfe und Empfehlungen.

Das Aktuelle: Sony Xperia XZ2 Compact

Dieses Smartphone ist seit Mai 2018 mein (fast) täglicher Begleiter. Von seinen technischen Daten her ist es für mich auch heute noch mehr als ausreichend. Damals waren vor allem die Größe von nur 5,0-Zoll und der Dual-SIM-Slot meine wesentlichen Kaufkriterien.

Nach knapp 4,5 Jahren leidet es an einer für mich nervigen Macke. Sporadisch können keine Rufe aufgebaut werden und ich bin zeitweise telefonisch nicht erreichbar. Ein Neustart des Geräts heilt das Problem vorübergehend. Dies nervt mich so sehr, dass ich nach einem Nachfolger suche, obwohl meine angestrebte Nutzungsdauer von mindestens 5 Jahren noch nicht erreicht ist.

Wofür nutze ich ein Smartphone

1. Messaging (E-Mail, SMS, soziale Netzwerke, Threema)
2. Telefonie
3. Foto- und Video-Aufnahmen
4. Internet-Recherche
5. Zweiter Faktor zur Authentifizierung

That’s it. In der Reihenfolge.

Anforderungen an den Nachfolger

Der Nachfolger muss mindestens folgende Kriterien erfüllen:

• Größe: Kleiner 6,0-Zoll; ich suche ein Smartphone und kein Tablet
• Betriebssystem: Android >= 11
• Preis: Maximal 600,00 EUR
• Speicher: Mindestens 64 GB
• RAM: Mindestens 4 GB
• Kein SIM-Lock
• Ohne Vertrag

Darüber hinaus sind mir folgende Punkte wichtig:

• Lange Akkulaufzeit
• Dual-SIM
• Fingerabdrucksensor
• NFC, neben dem obligatorischen Bluetooth und WLAN
• Eine gute Kamera; wenn möglich mit Weitwinkelobjektiv

Ob sich mit diesen Anforderungen ein Nachfolger eruieren lässt, oder ob ich an einigen Stellen Abstriche machen muss, wird sich zeigen. Bisher habe ich folgende Geräte ins Auge gefasst.

Samsung Galaxy XCover 5 – Das Outdoor-Handy

Dieses Gerät ist für ca. 245 EUR zu bekommen. Im Test bei NOTEBOOKCHECK schneidet es mit der Gesamtnote befriedigend ab.

Mir gefallen die Größe, das Updateversprechen und der Preis. Die schlechte Kamera und der fehlende Fingerabdrucksensor stören mich hingegen.

Samsung Galaxy Z Flip3 5G – Das Faltbare

Mit besserer Kamera, weiterhin fehlendem Fingerabdrucksensor und in meinen Augen schlechter Akkuleistung. Der Preis liegt noch im Rahmen und die Größe im gefalteten Zustand macht es interessant. Frohlocken lässt auch dieses Gerät mich jedoch nicht.

Link zum Testbericht.

Samsung Galaxy S22 – Ich weiß auch nicht

Gefallen tun mir an diesem Gerät das Updateversprechen, die gute Kamera und die insgesamt gute Ausstattung.

Allerdings ist es größer als meine maximale Wunschgröße und deutlich teurer. Unter 600 EUR ist es ausschließlich als Vorführgerät oder gebraucht erhältlich.

Ob ich bereit bin, an meinen Muss-Kriterien zu rütteln, weiß ich noch nicht. Da mich die Alternativen bisher noch nicht überzeugen, werde ich ggf. darüber nachdenken.

Link zum Testbericht.

Fairphone 4 – Der Sieger der Herzen

Auch das Fairphone 4 ist mir eigentlich zu groß. Davon ab gefällt es mir von den Spezifikationen her gut. Von der Philosophie her sogar sehr gut.

Allerdings sind mir Berichte zu Ohren gekommen, dass der Support nicht berauschend ist.

Fazit

Auf die Schnelle habe ich vier Modelle als mögliche Nachfolger identifiziert. So richtig glücklich bin ich mit keinem. Am besten gefällt mir bisher noch das Fairphone 4.

Mir gefällt nicht, dass Smartphones immer größer werden. Ich hätte gerne ein Gerät, welches komfortabel in die Hosen- oder Hemdtasche passt. Aber offenbar geht der Trend in eine andere Richtung.

Sollte ich statt einem Neukauf evtl. mehr Zeit investieren und versuchen, das Problem meines Xperia XZ2 in den Griff zu bekommen? Das wäre sicher auch die nachhaltigste Lösung.

Oder sollte ich mich doch mal wieder bei Apple umschauen? Bisher nehme ich davon Abstand, da unser Haushalt aktuell Apple-frei ist und ich mich erst wieder intensiv mit iOS beschäftigen müsste.

Was könnt ihr mir empfehlen? Und warum? Bitte schreibt mir eure Empfehlungen und Meinungen in die Kommentare. Ich freue mich auf eure Rückmeldungen.

In diesem Artikel möchte ich euch das Förderprogramm Media Tech Lab des Media Lab Bayern vorstellen.

Wie dem Titel bereits zu entnehmen ist, werden Open Source Projekte mit bis zu 50.000 EUR pro Projekt gefördert. Das Geld dafür kommt aus der Bayerischen Staatskanzlei. Doch der Reihe nach.

Vor einiger Zeit schrieb mich Jessica vom Media Lab Bayern an, um mich auf das Programm aufmerksam zu machen. Sie fragte, ob ich nicht Interesse habe, mich mit ihr und Erkan Kasap (CTO) über das Programm zu unterhalten, um ggf. darüber zu berichten und so dessen Bekanntheitsgrad zu steigern. Der Zufall sorgte dafür, dass Erkan und ich uns auf der FrOSCon 2022 an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin begegnet sind, wo wir uns gemeinsam mit Dirk über das Programm ausgetauscht haben. Erkan strahlte dabei eine Leidenschaft und ein Commitment aus, welche mir den Eindruck vermittelten, dass er für dieses Projekt brennt.

Um was für Projekte geht es?

Das Programm sucht innovative Projektideen zu Themen aus den Bereichen:

• Infrastruktur & Web-Technologie
• UX-Design & User Experience
• Machine Learning & Natural Language Processing
• Web3 & Blockchain
• Augumented & Mixed Reality

Ihr arbeitet bereits an entsprechenden Projekten oder strebt dies an? Ihr seid dabei auf eine Anschubfinanzierung angewiesen oder braucht Unterstützung bei der Projektplanung? Dann könnt ihr euch mit eurer Idee hier bewerben.

Ihr habt noch keine konkrete Idee, würdet aber gern mal an einem Open Source Proejekt arbeiten, welches das Potenzial hat, die Medienbranche zu verändern? Dann schaut in die Projektideen und lasst euch inspirieren.

Wen sucht Erkan?

Erkan ist auf der Suche nach:

• Open Source-Entwickler:innen und
• Software-Freelancer:innen

die Lust auf ein cooles Forschungs- und Entwicklungsprojekt in und für die Medienbranche haben. Wichtig dabei ist, dass nur Einzelpersonen oder Teams aus Einzelpersonen gefördert werden können, jedoch keine Unternehmen.

Seid ihr z.B. Entwickler, die über ein Sabbatical nachdenken, um mal an einem richtig coolen Projekt zu arbeiten, aber in dieser Zeit auch Einkommen erzielen müssen, dann ist dieses Programm für euch.

Ihr seid jung, sprudelt vor innovativen Ideen, die ihr unbedingt umsetzen wollt? Doch es fehlt das Geld und ein wenig Unterstützung darin, wie man ein Projekt erfolgreich durchführt? Dann nehmt Kontakt zu Erkan auf. Vielleicht ist euer Projekt dann schon bald dabei und wird Realität.

Welche Projekte haben keine Chance?

Euer Projekt muss innovativ sein. Nicht innovativ sind z.B.:

• Noch eine Rechtschreib- und Grammatikkorrektur für Office-Programme
• Peer-Review-Portale
• Sync&Share-Lösungen

Halt alles was es prinzipiell schon gibt. Damit sind jedoch nicht bereits existierende Projekte gemeint, denen es vielleicht noch an Funktionalität fehlt, um produktiv eingesetzt zu werden.

TL;DR: Wenn ihr alten Wein in neuen Schläuchen verkaufen wollt, seid ihr bei Erkan an der falschen Adresse.

Die harten Fakten

Wenn dein/euer Projekt angenommen wird, arbeitet ihr bis zu sechs Monate an eurem Projekt. Dies geht remote oder beim Media Lab im Open Space in München. Der Arbeit am Projekt wird dabei die größte Zeit des Tages eingeräumt. Der Verwaltungs-Overhead wird auf ein Minimum reduziert. Die Messung und Kontrolle des Fortschritts gehört jedoch zu jedem ordentlichen Projekt dazu. So gibt es selbstverständlich auch hier Check-ins mit dem Media Lab Team, Tech-Experten auf CTO/Senior Level und Produkt Experten (Medienexperten). Mit diesen könnt ihr Fragen zum Tech-Setup diskutieren, die Nutzerperspektive kennenlernen und erhaltet Feedback zu eurem Projekt.

Ihr erhaltet alle zwei Monate ab Beginn des Projekts eine Auszahlung. An das Projektteam (nicht jedes Projektmitglied) werden so max. 45.000 EUR ausbezahlt, die ihr frei einsetzen könnt. Weitere 5.000 EUR sind zweckgebunden und können für Coaching und Mentoring eingesetzt werden. So könnt ihr euch bspw. Experten-Rat zu Themen wie Community-Management oder wie verwalte ich Contributer für mein Projekt einkaufen.

Was gibt es noch nicht?

Auf der FrOSCon kam unser Gespräch darauf, was mit den Projekten passiert, wenn sie fertig und abgenommen sind. Stichwort: Maintenance.

Dieser Punkt ist noch nicht abschließend geklärt. Erkan äußerte die Idee, dass Medienhäuser, die ein Open Source Projekt einsetzen und zu einem Bestandteil ihrer Geschäftsprozesse machen, als Paten auftreten können, um die Pflege und Wartung des Codes zu finanzieren. Dem Gemeinschaftsgedanken folgend, können sich mehrere Unternehmen auf diesem Weg die Kosten für die Software-Pflege teilen.

Eine interessante Idee, bei der allerdings noch offen ist, ob und in welchem Umfang sich Medienhäuser darauf einlassen.

Mein Eindruck

Ich persönlich finde es schon bemerkenswert, dass in Deutschland ein Förderprogramm aufgelegt wird, welches die Entwicklung von Open Source Projekten in diesem Umfang fördert. Etwas Vergleichbares war mir bis dato nicht bekannt.

Erkan hat auf mich den Eindruck hinterlassen, mit viel Herzblut und bis in die Bartspitzen motiviert hinter diesen Programm zu stehen.

In meinen Augen bietet das Programm eine gute Chance, um Open Source Projekten zu einem erfolgreichen Verlauf zu verhelfen. Auch wenn die Finanzierung der Maintenance-Phase nach Projektende noch nicht geklärt ist.

Im Artikel „Wie kann man Hostnamen ohne Programme aus dem Paket bind-utils auflösen?“ hatte ich getent bereits genutzt, um Hostnamen auflösen zu können, wenn kein Programm aus dem Paket bind-utils installiert ist. In diesem Artikel möchte ich getent einmal ganz allgemein vorstellen.

Das Kommando getent steht auf so gut wie jedem Linux- und UNIX-System zur Verfügung. Es steht für get entries und tut genau das. Es ruft Einträge aus Textdateien ab (in diesem Kontext auch Datenbanken genannt), die auf eurem System vorhanden sind. Genau genommen kann es alle Datenbanken abfragen, die in der Datei /etc/nsswitch.conf (siehe nsswitch.conf(5)) konfiguriert sind. Damit lässt sich auf reichhaltige Informationen zugreifen, ohne eine Internet-Suchmaschine zu bemühen. Es funktioniert sogar auf Systemen ohne Internetkonnektivität (ja auch heutzutage gibt es solche Systeme noch).

Ich möchte hier allerdings nicht die Manpage getent(1) widergeben, sondern euch ein paar Anwendungsbeispiele zeigen, bei denen ich getent hilfreich finde.

Informationen zu Ports, Services und Protokollnummern

Nehmen wir mal an, in einem Firewall-Log fallen uns die Ports 5432 und 11371auf und wir können uns gerade nicht daran erinnern, für welche Services diese üblicherweise verwendet werden. So hilft uns folgende Abfrage auf unserem Linux-/UNIX-System weiter:

$ getent services 5432 11371
postgresql            5432/tcp postgres
hkp                   11371/tcp

Die Ports gehören also zu PostgreSQL und zu OpenPGP-HTTP-Keyservern.

Umgekehrt funktioniert das natürlich auch. Mal angenommen, ihr habt die Standard-Ports für NTP und MySQL vergessen:

$ getent services ntp mysql
ntp                   123/udp
mysql                 3306/tcp

Der Befehl getent services ohne weitere Argumente gibt euch den gesamten Inhalt der Datenbank aus.

Auf dem gleichen Weg lassen sich auch die Protokollnummern gängiger Protokolle ermitteln:

$ getent protocols tcp udp rdp icmp
tcp 6 TCP
udp 17 UDP
rdp 27 RDP
icmp 1 ICMP

Informationen über User und Gruppen

Selbstverständlich kann man diese Informationen auch mit `grep <Suchmuster> /etc/{groups,passwd} erhalten. Es geht aber auch wie folgt:

$ getent passwd root
root:x:0:0:root:/root:/bin/bash
$ getent group root
root:x:0:
$ getent group sudo
sudo:x:27:alice

Ein Beispiel für Hostnamen findet sich bereits hier.

Fazit

Ich finde, getent ist ein einfach zu bedienendes und nützliches Programm. Seid ihr neugierig geworden? Dann schaut doch mal in die Manpage getent(1) für weitere Hinweise, wie und wofür ihr es nutzen könnt.

Um die Paketquellen von Red Hat für Red Hat Enterprise Linux (RHEL) nutzen zu können, wird eine sogenannte Software-Subskription benötigt. Diese bestimmt, auf welche Paketquellen ein System zugreifen und deren Inhalt konsumieren kann.

Das System der Subskriptionen befindet sich im Umbruch (siehe [1]). In diesem Artikel beschreibe ich, wie es bisher war, was sich durch die Aktivierung von Simple Content Access (SCA) [2] ändert und wie ich aktuell meine RHEL-Systeme registriere und deren System Purpose konfiguriere.

Der Text vermittelt dabei Wissen zum Red Hat Subscription Management (RHSM), Simple Content Access (SCA), Subscription Watch (SWatch), dem System Purpose und verlinkt relevante Quellen.

Aus Transparenz-Gründen möchte ich an dieser Stelle darauf hinweisen, dass ich Mitglied der Red Hat Accelerators bin (vgl. hier). Dieser Text spiegelt ausschließlich meine persönliche Meinung wider.

Subskriptions-Verwaltung ohne SCA

Eine Subskription berechtigt zur Nutzung bestimmter Paketquellen von Red Hat. Sie umfasst in der Regel eine gewisse Menge sogenannter Entitlements. Diese bestimmen, wie viele Systeme von einer Subskription abgedeckt werden.

Ein Beispiel: Eine Subskription für „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ beinhaltet zwei Entitlements. Damit lassen sich ein physischer Server mit bis zu zwei CPU-Sockeln oder zwei virtuelle Maschinen (mit einer beliebigen Anzahl CPUs) zur Nutzung der Paketquellen berechtigen.

In der Regel werden RHEL-Systeme über den subscription-manager beim Red Hat Subscription Management (RHSM) oder einem Satellite Server registriert. Anschließend werden sie mit einer Subskription verknüpft. Wie man dies lösen kann, habe ich 2019 in dem Artikel RHEL-System registrieren und Subskription hinzufügen beschrieben.

Vorteile des RHSM

Das RHSM im Customer Portal bietet eine gute Übersicht über die vorhandenen Verträge, die Subskriptionen, deren Laufzeiten und verknüpfte Systeme. Man sieht hier auf einen Blick, ob man ausreichend Subskription hat, um all seine Systeme damit abdecken zu können.

Nachteile des RHSM

Um ein System beim RHSM zu registrieren und mit einer Subskription zu verknüpfen, muss das System eine Verbindung ins Internet zum RHSM-Dienst aufbauen. Dies ist im Datacenter häufig nicht erwünscht. Für Systeme ohne Zugang zum Internet gibt es die optionale Offline-Registrierung [3], welche jedoch etwas umständlich ist und bei vielen Offline-Systemen nicht skaliert.

Registriert man die Systeme nicht, ist man dennoch zu einer ordentlichen Buchführung verpflichtet, um sicherzustellen, dass man nicht dauerhaft mehr Systeme einsetzt, als durch vorhandene Subskriptionen abgedeckt sind.

Läuft ein Subskriptionsvertrag ab, werden die Entitlements ungültig. Die damit verknüpften Systeme fangen an, sich beim Update-Versuch darüber zu beschweren und verweigern den Zugriff auf die Paketquellen. Das ist besonders ärgerlich, weil es nach meiner Erfahrung bei jeder Vertragsverlängerung passiert. Denn tatsächlich wird der Vertrag nicht verlängert. Es gibt einen neuen Vertrag mit der entsprechenden Anzahl Subskriptionen. Diese müssen dann manuell neu verknüpft werden, was jedes Mal manuellen Pflegeaufwand bedeutet.

Vermutlich um dem zuvor genannten Ärgernis entgegenzuwirken hat Red Hat die Funktion auto-attach entwickelt. Wird die mit einem registrierten System verknüpfte Subskription ungültig sucht auto-attach automatisch nach einer geeigneten freien Subskription und verknüpft diese mit dem jeweiligen System. Nun mag sich manch einer Fragen, wie auto-attach wohl entscheidet, wenn es mehrere Subskriptionen gibt, die prinzipiell geeignet sind. Nach meiner Erfahrung wählt auto-attach mit einer Wahrscheinlichkeit von >95 % die am wenigsten geeignete Subskription aus. In meinen Augen nervt es mehr, als das es hilft.

Das Verknüpfen von Subskriptionen ist für die Buchführung praktisch, für den Betrieb eher nervig. Teilweise stört es sogar Betriebsabläufe, wenn z.B. Updates vorübergehend nicht installiert werden können. Um dem zu begegnen, hat Red Hat Simple Content Access (SCA) [2] geschaffen.

Was ändert sich durch SCA?

Wird SCA im RHSM aktiviert, müssen Subskriptionen nicht mehr mit Systemen verknüpft werden. RHEL-Systeme, die im RHSM registriert sind, erkennen dies und setzen für den Zugriff auf die Paketquellen kein Entitlement mehr voraus.

Vorteile

Der Betrieb wird vereinfacht. Ein System muss nur noch registriert werden und kann sofort auf Inhalte der diversen Paketquellen zugreifen.

Unterbrechungen im Betriebsablauf bei Ablauf einer Subskription gehören der Vergangenheit an.

Auch auto-attach bereitet nun keinen Ärger mehr.

Nachteile

Die Buchführung wird aufwändiger, da RHSM mit aktivierten SCA nur noch begrenzt dafür taugt. Man muss sich nun einen anderen Weg überlegen, wie man den Überblick behält.

Subscription Watch

Subscription Watch [4, 5] ist ein SaaS-Dienst in der Hybrid Cloud Console [6], welcher den Kunden dabei unterstützen soll, im Blick zu behalten, wie viele Subskriptionen er besitzt und wie viele er konsumiert. Dabei ist es möglich, mehr zu konsumieren, als man besitzt. Wird dies angezeigt, kann man handeln und fehlende Subskriptionen nachkaufen.

Leider hat die Sache einen Haken. Es funktioniert nicht richtig. In meinem Fall kommt eine Mischung aus kostenpflichtigen Subskriptionen und der Developer Subscription for Teams zum Einsatz. Im Subscription Watch gibt es einen Bug, durch den mir angezeigt wird, ich würde mehr Subskriptionen nutzen, als ich im Bestand habe, obwohl dies nicht der Fall ist.

Ich habe zu dem Fall ein Support-Ticket, in dem das Verhalten reproduziert werden konnte und der Fehler bestätigt wurde. Nur eine Lösung gibt es noch nicht. Leider ist Subscription Watch im aktuellen Status damit nutzlos für mich.

System Purpose

Was der System Purpose ist, wird im Detail in [1] und [7] beschrieben. Red Hat empfiehlt den System Purpose zu pflegen, um u.a. Subscription Watch dabei zu helfen, die konsumierten Inhalte korrekt zu zählen. Das hat folgenden Hintergrund.

Sowohl mit der „Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes)“ Subskription als auch mit der „Developer Subscription for Teams“ darf man das RHEL-8-BaseOS-Repo nutzen. Gezählt werden soll in Subscription Watch jedoch nur die kostenpflichtige Subskription (Erstgenannte). Mit Hilfe des System Purpose gibt man an, ob es sich um ein Produktionssystem oder ein Test-/Entwicklungs-System handelt und steuert darüber, ob ein System in Subscription Watch gezählt wird.

Funktionieren tut das Ganze leider (noch) nicht. Unter anderem ist der zuvor erwähnte Bug dafür verantwortlich. Ich pflege den System Purpose jedoch trotzdem, in der Hoffnung, dass es in der Zukunft funktionieren wird.

Wie registriere ich meine Systeme heute?

Ich habe dazu eine kleine Ansible-Rolle erstellt, welche folgende Struktur besitzt:

roles/register_syspurpose/
├── defaults
│   └── main.yml
├── README.md
└── tasks
    └── main.yml

Das Readme.md enthält eine Beschreibung der notwendigen Variablen und ein Beispiel-Playbook, wie man diese Rolle nutzt:

register_syspurpose
===================

Register host to RHSM and set System Purpose.

Requirements
------------

 * [community.general collection](https://galaxy.ansible.com/community/general)

You might already have installed this collection if you are using Ansible Engine 2.9 or the `ansible` package. It is not included in `ansible-core`. To check whether it is installed, run `ansible-galaxy collection list`.

To install it, use: `ansible-galaxy collection install community.general`.

To use it in a playbook, specify: `community.general.redhat_subscription`.

Role Variables
--------------

```yaml
register_syspurpose_activationkey: register-syspurpose # activationkey for access.redhat.com or Satellite
register_syspurpose_org_id: 123456 # Org ID on access.redhat.com or Satellite
register_syspurpose_role: "Red Hat Enterprise Linux Server"
# possible values are:
# Red Hat Enterprise Linux Server
# Red Hat Enterprise Linux Workstation
# Red Hat Enterprise Linux Compute Node

register_syspurpose_sla: "Self-Support"
# possible values are:
# Premium
# Standard
# Self-Support

register_syspurpose_usage: "Development/Test"
# possible values are:
# Development/Test
# Disaster Recovery
# Production
```

I got these values from the KB [syspurpose_usage: "Development/Test"](https://access.redhat.com/articles/5713081).
There might be other possible values out there. In case you know some valid
addtional values please sent a PR to add them to this documentation.

Dependencies
------------

None.

Example Playbook
----------------

Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:

~~~
- hosts: all
  gather_facts: no
  roles:
    - register_syspurpose
~~~

License
-------

MIT.

Author Information
------------------

Joerg Kastning - "joerg (dot) kastning '@' uni-bielefeld (dot) de"

Auch die Tasks-Datei ist sehr übersichtlich:

---
# tasks file for register_syspurpose
- name: Register system to RHSM and set syspurpose attributes
  redhat_subscription:
    state: present
    activationkey: "{{ register_syspurpose_activationkey }}"
    org_id: "{{ register_syspurpose_org_id }}"
    syspurpose:
      role: "{{ register_syspurpose_role }}"
      service_level_agreement: "{{ register_syspurpose_sla }}"
      usage: "{{ register_syspurpose_usage }}"
      sync: true

Um die Variablen mit Werten zu belegen, nutze ich group_vars. Ich verwende ein statisches Inventory, in dem ich Gruppen für die möglichen Kombinationen aus role, sla und usage definiert habe. So wird jeder neue Host der entsprechenden Gruppe hinzugefügt und anschließend bei der Provisionierung direkt registriert und korrekt konfiguriert. Detaillierte Informationen zum verwendeten Modul redhat_subscription bietet die Dokumentation unter [8].

Ihr seht, es steckt keine Magie in der Rolle. But I like to Keep It Simple, Stupid.

Fazit

Das Red Hat Subscription Management ist kompliziert, hat seine Macken, eine Geschichte und etliche Altlasten. Ein Team um Rich Jerrido hat es sich zur Aufgabe gemacht, das Subskriptions-System zu überarbeiten und alte Zöpfe abzuschneiden. Ich beneide das Team nicht um diese Aufgabe.

Das System befindet sich aktuell im Übergang (siehe [1]). Damit gehen Herausforderungen sowohl für Red Hat als auch dessen Kunden einher.

Das Red Hat die technischen Abhängigkeiten zwischen Betriebssystem und RHSM mit SCA abschafft, weiß ich zu schätzen. Schade, dass die Unterstützung bei der Buchführung dabei auf der Strecke bleibt.

Subscription Watch bietet mir auch in der nahen Zukunft keinen Nutzen. Um meinen Pflichten aus [9] nachzukommen, werde ich mir Red Hat Discovery näher ansehen. Meine Erfahrungen werde ich anschließend hier im Blog niederschreiben.

Quellen und weiterführende Links

1. Transition of Red Hat’s subhttps://access.redhat.com/documentation/en-us/red_hat_subscription_management/2022scriptions 5ervices to console.redhat.com
2. Simple Content Access (SCA)
3. How to register and subscribe a system offline to the Red Hat Customer Portal?
4. Subscription Watch
5. Chapter 1. What is subscription watch?
6. Red Hat Hybrid Cloud Console
7. RHEL 8 Documentation: Chapter 12. Configuring System Purpose
8. community.general.redhat_subscription module – Manage registration and subscriptions to RHSM using the subscription-manager command
9. Red Hat Enterprise Linux subscription guide

Links meint in diesem Artikel insbesondere Lesezeichen (engl. Bookmarks), wie sie häufig im Webbrowser gespeichert werden. Und Shaarli (engl.) ist eine simple und schnelle Anwendung, um diese zu speichern, verwalten und teilen zu können.

In der Vergangenheit habe ich wiederholt Lösungen gesucht, um meine Lesezeichen im Webbrowser auf verschiedenen Geräten synchron zu halten. Bisher habe ich mich stets an einem oder mehreren der folgenden Punkte gestört:

• Die Lösungen funktionierten nur mit einem Browser (z.B. Firefox oder Chrome)
• Die Lösungen waren cloud-basiert. Ich möchte meine Links aber nach Möglichkeit nicht in einem Cloud-Dienst speichern.
• Es mussten Browser-Plugins installiert werden, die mit der nächsten Browserversion nicht mehr funktionierten oder nach ein paar Monaten eingestellt wurden.
• Man musste dazu Dienste hosten, von denen man 90 % der Funktionalität nicht genutzt hat.
• Es funktionierte nie auf allen meinen Geräten.

Dabei ist es mir gar nicht wichtig, dass die Links synchronisiert werden. Ich möchte nur von all meinen Geräten auf die gleiche Sammlung zugreifen können. Eine umfangreiche und wachsende Linksammlung hier im Blog zu pflegen skaliert jedoch auch nicht. Und hier kommt Shaarli ins Spiel.

Nach eigener Darstellung kann Shaarli (engl.) genutzt werden, um:

• interessante Links zu speichern, kommentieren und zu teilen.
• von verschiedenen Computern und mobilen Geräten auf diese Links zuzugreifen.
• als Microblog zu dienen.
• als ToDo-Liste oder lese-ich-später-Liste zu fungieren.
• eine Wissensdatenbank mit Notizen und Code-Schnipseln zu erstellen.
• etc.

Ich selbst nutze Shaarli aktuell vorwiegend zum Speichen von Links, welche ich mit Titel, Beschreibung und Tags versehen und organisieren kann. Zusätzlich können Links als privat markiert werden, wodurch sie erst nach einem Login abrufbar sind.

Mir gefällt die einfache und schnelle Erfassung neuer Links. Die folgenden drei Screenshots veranschaulichen dies.

Die Projektdokumentation ist brauchbar und die Anwendung lässt sich ohne großen Aufwand auch selbst betreiben. Bei mir läuft sie unter Debian in einem rootless-Podman-Container (engl.).

Fazit

Schnelle und einfache Einrichtung der Anwendung sowie Erfassung von Links machen dieses Projekt zu einem nützlichen Werkzeug in meinem Alltag. And of course, it’s Open Source.

Da bleibt mir nur noch zu sagen: „Danke Dirk für den Tipp.“

Referenzen

• Shaarli Documentation (engl.)
• GitHub Project Page (engl.)
• My-Shaarli – Meine persönliche Shaarli-Instanz

Dieses Jahr fand die FrOSCon am 20. und 21. August an der Hochschule Bonn-Rhein-Sieg statt.

Bisher hatte ich es noch nicht zu dieser Konferenz geschafft. Obwohl mich das diesjährige Programm nicht ansprach, habe ich mich aufgerafft, um einige Bekannte nach langer Zeit mal wiederzusehen.

Es folgt ein kurzer Erlebnisbericht.

Die Anreise

Für die Anreise hatte ich folgende Optionen:

1. Mit dem 9-Euro-Ticket und dem Regionalverkehr am Freitag oder Samstag; 4 Std. und 2 Umstiege.
2. Mit dem ICE in ca. 3,5 Std.
3. Mit dem Auto in ca. 2,5 Std.

Um Option 1 oder 2 zu nutzen, wären für mich weitere 20 Minuten Fahrzeit mit dem PkW hinzu gekommen, um den Startbahnhof zu erreichen. Die lange Fahrzeit und die Aussicht während einer Pandemie in einem völlig überfüllten Zug zu sitzen, haben mich das Auto nehmen lassen.

Hier war ich allein, musste keine Makse tragen und durfte selber fahren. Günstiger war es jedoch nicht.

Die Unterkunft

Da das Hotel Kaspar Garni – Siegburg bereits ausgebucht war, bin ich im Motel One Bonn-Beethoven abgestiegen.

Zimmer und Frühstück waren gut. Nur einen Parkplatz gab es nicht für mich. Das hat mich etwas irritiert, da ich dachte ein Motel bietet pro Zimmer auch einen Stellplatz für ein Auto. Also habe ich in einem Parkhaus in der Nähe geparkt.

Besuchte Vorträge und Workshops

• Lecture: Patterns & Anti-Patterns bei der Automatisierung mit Ansible von Henning Rohde
• Lecture: [Keynote] Digitale Souveränität – Verzweifeln oder Handeln? von Christian Theune
• Workshop: Selbstverwaltung und Zeitplanung mit Dirk Deimeke
• Lecture: Troubleshooting (Enterprise) Web Applikationen mit OpenSource Tools von Christoph Stoettner (stoeps)

Die Vorträge und Dirks Workshop haben mir gut gefallen. Aus jedem konnte ich etwas neues mitnehmen, was ich in den nächsten Wochen nochmal in Ruhe anschauen werden.

Insgesamt bot die FrOSCon über 60 Vorträge. Die meisten wurden aufgezeichnet und können auch im Nachgang noch angesehen werden. Im Erdgeschoss füllten 42 Aussteller die Fläche. Hier konnten Besucher mit Projekten und Unternehmen ins Gespräch kommen.

Der Gesamteindruck

Die FrOSCon ist nach eigenen Angaben die zweitgrößte Open-Source-Konferenz in Deutschland und die drittgrößte Europas. Der Veranstaltungsort ist schön und die Konferenz war nach meiner Wahrnehmung gut organisiert. Mit ca. 750 Besuchern in diesem Jahr reicht sie jedoch noch nicht an alte Besucherzahlen (ca. 2000) vor der Pandemie heran.

Besonders genossen habe ich das Social Event am Samstag Abend, wo ich mit alten und neuen Bekannten gefachsimmpelt, War Stories getauscht und ein paar Kölsch getrunken habe.

Ich kann mir gut vorstellen, nochmal wiederzukommen. Bis dahin habe ich einige neue Buchempfehlungen, die ich sicher lesen werde.

In diesem Artikel stelle ich euch meine Ansible-Rolle vsphere_provision_lab vor. Mit dieser ist es möglich, vordefinierte Labor-Umgebungen, bestehend aus virtuellen Maschinen (VMs), in einem VMware vSphere Cluster zu provisionieren.

Um dem Text folgen zu können, ist es hilfreich zu wissen, was eine Ansible-Rolle (engl.) ist und worum es sich bei VMware vSphere handelt.

Anwendungsfall

Zum Test von Ansible-Modulen, -Playbooks und -Rollen sowie neuer Shell-Skripte und Konfigurationsparameter benötige ich wiederholt Test- bzw. Labor-Umgebungen. Diese bestehen aus VMs, welche im Vergleich zum Provisionierungszeitpunkt möglichst wenig Änderungen aufweisen sollten.

Da die Konfiguration der Gast-Betriebssysteme durch einen Testlauf verändert wird, soll eine solche Labor-Umgebung nach einem Test möglichst schnell dekommissioniert und neu-provisioniert werden können.

Der Vorgang der Provisionierung und Dekommissionierung soll automatisiert erfolgen.

Voraussetzungen

Um die Ansible-Rolle vsphere_provision_lab nutzen zu können, benötigt man:

• Einen Ansible Control Node mit einer Ansible-Version >= 2.9
• Eine vCenter Server Appliance oder einen vCenter Server; getestet habe ich die Rolle mit Version 6.7 U3

Die Ansible-Rolle verwendet die Module vmware_guest und vmware_guest_disk aus der Collection community.vmware. Um diese nutzen zu können, muss auf dem Ansible Control Node Python in einer Version >= 2.6 und PyVmomi installiert sein.

Da die Rolle neue VMs aus Templates erstellt, müssen entsprechende vSphere Templates vorhanden sein.

Variablen

In diesem Abschnitt werden die Variablen dokumentiert, welche mit Werten zu belegen sind. Diese sind in defaults/main.yml definiert und können entsprechend der Variablen-Präzedenz überschrieben werden.

vCenter-Variablen

• vsphere_provision_lab_vc_hostname – Der FQDN für die vCenter Server Appliance.
• vsphere_provision_lab_vc_username – Ein Benutzeraccount mit der Berechtigung, neue VMs zu erstellen.
• vsphere_provision_lab_vc_password – Spezifiziert das Benutzer-Passwort.
• vsphere_provision_lab_vc_datacenter – Name des vSphere Datacenter in der Bestandsliste, das verwendet werden soll.
• vsphere_provision_lab_vc_cluster – Der zu verwendende vSphere Cluster aus der Bestandsliste.
• vsphere_provision_lab_vc_datastore – Name des Datenspeichers, in dem die VMDK-Datei(n) erstellt wird/werden.
• vsphere_provision_lab_vc_folder – Der vSphere Folder Name, in dem die VM erstellt wird. Der Wert kann zuvor mit dem Playbook find_vmware_guest_folder.yml ermittelt werden.

Ich empfehle, sensible Informationen wie z.B. Benutzername und Passwort in einer verschlüsselten Ansible-Vault-Datei zu speichern.

Dictionary zur Spezifikation der VMs

Namen und Parameter der zu erstellenden VMs werden in einem YAML-Dictionary gespeichert. Der folgende Code-Block zeigt ein Beispiel für ein solches Dictionary mit einem Eintrag:

  vm1:
    vm_template: rhel8-en
    vm_ram_mb: 1024
    vm_vcpu: 2
    vm_net: VLAN123
    vm_ip: 192.168.0.5
    vm_netmask: 255.255.255.0
    vm_gateway: 192.168.0.254
    vm_domain: sub.example.com
    vm_hostname: host2
    vm_dns_servers:
      - 192.168.0.2
      - 192.168.0.3
    vm_dns_suffix:
      - sub.example.com
      - sub2.example.com
      - sub3.example.com
    vm_second_hdd: true
    vm_second_hdd_size_gb: "10"
    vm_second_hdd_type: "thin"
    vm_second_hdd_datastore: "DS1"
    vm_scsi_controller: "1"
    vm_unit_number: "1"
    vm_scsi_type: 'paravirtual'

Aus dem obigen Dictionary wird eine VM mit den folgenden Parametern erstellt:

• vSphere-Template ‚rhel8-en‘ wird als Vorlage verwendet.
• Der VM werden 1 vCPU und 512 MB RAM zugewiesen.
• Die vNIC an das VM-Netz ‚VLAN123‘ angeschlossen.
• Die VM wird mit der IP 192.168.0.1/24 und dem Standardgateway 192.168.0.254 konfiguriert.
• Im Gast-Betriebssystem wird der Hostname ‚host1‘ konfiguriert.
• Es werden DNS-Server und DNS-Suffixe konfiguriert.
• Es wird eine zweite Festplatte für die VM erstellt.

Diesen Block kann man nun für weitere VMs wiederholen. Wird keine zweite HDD benötigt, setzt man vm_second_hdd auf false.

Beispiel-Playbook

---
- hosts: localhost
  connection: local
  gather_facts: no
  vars_files:
    - /path/to/vault-with-vcenter-creds.vars
    - roles/vsphere_provision_lab/vars/rhel-lab.yml
 
  roles:
    - vsphere_provision_lab

In diesem Beispiel werden die Variablen aus zwei Dateien geladen.

• /path/to/vault-with-vcenter-creds.vars ist eine Ansible-Vault-Datei, welche die Anmeldeinformationen für den vCenter Server beinhaltet.
• roles/vsphere_provision_lab/vars/rhel-lab.yml enthält das Dictionary mit den zu erstellenden VMs.

Wie kann man diese Rolle nutzen?

Die Rolle steht unter der Lizenz GPLv2-or-later und kann aus dem GitLab-Repo vsphere_provision_lab heruntergeladen bzw. das Repo geklont werden. Sie ist im Role Path der Ansible-Installation zu speichern. Anschließend kann man sich an folgendem Ablaufplan orientieren:

1. Im Vorfeld sollten IP-Adressen und FQDNs für die zu erstellenden VMs registriert werden. Dieser Punkt ist spezifisch für eure jeweilige Umgebung.
2. Die Variablen sind mit gültigen Werten zu belegen.
3. Die Rolle ist in ein Playbook einzubinden.
4. Und schon kann das Playbook ausgeführt werden.

Fazit

Die Ansible-Rolle vsphere_provision_lab ermöglicht es, Labor-Umgebungen, bestehend aus VMs, als YAML-Dictionary zu definieren und auf einem VMware vSphere Cluster zu provisionieren.

Damit eignet sie sich, um wiederholt eine Umgebung mit gleichen Ausgangsbedingungen zu schaffen. Gleichzeitig wird die Zeit für die Provisionierung verkürzt, da manuelle Schritte entfallen.

So richtig idempotent arbeitet das Modul vmware_guest allerdings nicht. Führe ich das Playbook ein zweites Mal aus, wird der Status „Changed“ zurückgegeben, obwohl die VMs bereits existieren. Die VMs selbst überstehen den zweiten Lauf auch unbeschadet, jedoch zeigt der vSphere Client, dass sie rekonfiguriert wurden. Das könnte ich mir noch genauer ansehen, um der Ursache auf die Schliche zu kommen.

Was haltet ihr davon? Findet ihr diese Role nützlich, oder bevorzugt ihr andere Wege zur Provisionierung eurer VMs auf vSphere?

Der folgende Text dient mir als Dokumentation. Ich halte darin fest, wie ich LVs von einer VG in eine andere VG verschiebe und die Partitionstabelle der Festplatte mit der Quell-VG bearbeite. Der Verschiebe-Vorgang setzt sich dabei aus den zwei Vorgängen Kopieren und Löschen zusammen.

Der Text mag euch unterhalten und ggf. könnt ihr darauf zurückgreifen, wenn ihr ähnliche Arbeiten an euren Linux-Dateisystemen plant. Euch erwartet jedoch kein Tutorial, das in einzelne Themen oder Programme einführt. Falls ihr von hieran weiterlest, wünsche ich euch viel Spaß mit dem Text.

Ausgangslage

Es geht um meinen Desktop-PC. Dieser besitzt neben einer Geschichte auch einige Altlasten. Nun ist mir meine /boot-Partition zu klein. Da der Platz hinter der Partition jedoch von einer LUKS-verschlüsselten Partition mit LVM belegt ist, muss ich hier erst Platz schaffen, um die /boot-Partition vergrößern zu können.

Folgender Code-Block gibt einen Überblick über die Block-Geräte meines PCs, die darauf befindlichen Partitionen sowie deren Einhängepunkte in /etc/fstab und /etc/crypttab. Identifizierende Merkmale wie UUIDs wurden gekürzt, verändert oder Platzhalter an ihrer Stelle verwendet.

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sdb_crypt                   253:4    0 931,5G  0 crypt 
  └─tower--pc--vg2-lv--images 253:5    0   360G  0 lvm   /var/lib/libvirt/images
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0   243M  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 238,2G  0 part  
  └─sda5_crypt                253:0    0 238,2G  0 crypt 
    ├─tower--pc--vg-root      253:1    0  27,9G  0 lvm   /
    ├─tower--pc--vg-swap_1    253:2    0     4G  0 lvm   [SWAP]
    └─tower--pc--vg-home      253:3    0 204,3G  0 lvm   /home
sr0

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/tower--pc--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=a3809eb1-fc3d191e2ae9 /boot           ext2    defaults        0       2
/dev/mapper/tower--pc--vg-home /home           ext4    defaults        0       2
/dev/mapper/tower--pc--vg-swap_1 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

# 1 TB SSD SANDisk
/dev/mapper/tower--pc--vg2-lv--images	/var/lib/libvirt/images	ext4	defaults	0	0

$ cat /etc/crypttab 
sda5_crypt UUID=07f0d6c5-257591190166 none luks,discard
sdb_crypt UUID="e605980c-307daf28b717" none luks,discard

$ sudo blkid
/dev/sdb1: UUID="a3809eb1-fc3d191e2ae9" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="6ee39e6a-01"
/dev/sdb5: UUID="07f0d6c5-257591190166" TYPE="crypto_LUKS" PARTUUID="6ee39e6a-05"
/dev/sda: UUID="e605980c-307daf28b717" TYPE="crypto_LUKS"
/dev/mapper/sda5_crypt: UUID="AZKTuQ-rVeB5S" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg-root: UUID="be0ff8fd-7aee7ce75f3b" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/tower--pc--vg-swap_1: UUID="90823267-b6828aeca9b9" TYPE="swap"
/dev/mapper/tower--pc--vg-home: UUID="d410241d-04214b690522" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/sdb_crypt: UUID="Ff4Lt0-RKJrGd" TYPE="LVM2_member"
/dev/mapper/tower--pc--vg2-lv--images: UUID="3af3b461-cdd7b2bc9710" BLOCK_SIZE="4096" TYPE="ext4"

Ziel

Mein Ziel ist, die /boot-Partition auf 2 GB zu vergrößern, ohne das System neuinstallieren zu müssen oder die Daten in den vorhandenen Partitionen zu verlieren.

Mögliche Vorgehensweisen

Bei meiner Internet-Recherche bin ich auf folgende Lösungsmöglichkeiten gestoßen:

• Move a logical volume from one volume group to another (StackExchange)
• How to move / copy logical volume (lv) to another volume group (vg)? (askUbuntu)
• Resizing LVGrub NeukonfigurierenM-on-LUKS (ArchWiki)

Wenn man diese Diskussionen und den Wiki-Artikel liest, erkennt man, dass es mehrere Wege zum Ziel gibt. Ich habe mich für folgendes Vorgehen entschieden, da es auf mich den Eindruck macht, unkompliziert zu sein und nur ein geringes Risiko für Datenverlust birgt:

1. Datensicherung
2. LUKS-Devices umbenennen
3. LV und Dateisystem der /home-Partition verkleinern
4. Neue LVs in zweiter VG erstellen
5. Partitionen mit partclone kopieren
6. Grub Neukonfigurieren (2x)

Schritt 1: Datensicherung durchführen

Bevor ich irgendwelche Änderungen an der Partitionstabelle von /dev/sdb durchführe, erstelle ich eine Datensicherung. Dazu verwende ich die freie Software Clonezilla, um die Partitionen von /dev/sdb in eine Image-Datei auf einer externen Festplatte zu sichern.

Das Programm ist einfach in der Bedienung und ermöglicht mir im Fehlerfall, die Partitionen der zu bearbeitenden Festplatte wiederherzustellen.

Schritt 2: LUKS-Devices umbenennen

Im IST-Zustand befindet sich das LUKS-Device sdb_crypt auf dem Gerät /dev/sda, während sich sda5_crypt auf dev/sdb5 befindet. Dies ist unschön und lässt sich wie folgt ändern:

root:~# dmsetup rename sda5_crypt sd_temp
root:~# dmsetup rename sdb_crypt sda5_crypt
root:~# dmsetup rename sd_temp sdb_crypt

Nun wird die Datei /etc/crypttab entsprechend angepasst (vgl. mit IST-Zustand):

root:~# cat /etc/crypttab 
sdb_crypt UUID=07f0d6c5-257591190166 none luks,discard
sda5_crypt UUID="e605980c-307daf28b717" none luks,discard

Damit die Partitionen beim Start des Rechners korrekt entschlüsselt und eingebunden werden, wird abschließend initramfs aktualisiert:

root:~# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64

Nach einem Neustart ergibt sich das gewünschte Bild:

$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sda5_crypt                  253:4    0 931,5G  0 crypt 
  └─tower--pc--vg2-lv--images 253:5    0   360G  0 lvm   /var/lib/libvirt/images
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0   243M  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 238,2G  0 part  
  └─sdb_crypt                 253:0    0 238,2G  0 crypt 
    ├─tower--pc--vg-root      253:1    0  27,9G  0 lvm   /
    ├─tower--pc--vg-swap_1    253:2    0     4G  0 lvm   [SWAP]
    └─tower--pc--vg-home      253:3    0 204,3G  0 lvm   /home

Schritt 3: LV und Dateisystem der /home-Partition verkleinern

Meine /home-Partition ist mir mit 204 GB etwas groß geraten. Daher möchte ich sie um 100 GB verkleinern. Um das Dateisystem verkleinern zu können, darf die Partition nicht eingehängt sein. Um die folgenden Schritte durchzuführen, nutze ich diesmal das Linux-System System Rescue. Dabei handelt es sich um ein Live-System, mit jeder Menge Werkzeugen, um einen (beschädigten) Rechner zu bearbeiten.

Der folgende Code-Block zeigt, wie zuerst das verschlüsselte LUKS-Device geöffnet und anschließend das LV der /home-Partition verkleinert wird. Der dabei verwendete Befehl führt die Verkleinerung des Dateisystems und des LV in einem Schritt aus:

# LUKS-Device öffnen
# cryptsetup open <device> <name> --type <device_type> see cryptsetup(8)

root@sysrescue ~]# cryptsetup open /dev/sda5 crypt_disk --type luks2
Enter passphrase for /dev/sda5: 
[root@sysrescue ~]# lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                        7:0    0 647.7M  1 loop  /run/archiso/sfs/airootfs
sda                          8:0    0 238.5G  0 disk  
├─sda1                       8:1    0   243M  0 part  
├─sda2                       8:2    0     1K  0 part  
└─sda5                       8:5    0 238.2G  0 part  
  └─crypt_disk             254:0    0 238.2G  0 crypt 
    ├─tower--pc--vg-root   254:1    0  27.9G  0 lvm   
    ├─tower--pc--vg-swap_1 254:2    0     4G  0 lvm   
    └─tower--pc--vg-home   254:3    0 204.3G  0 lvm   
sdb                          8:16   0 931.5G  0 disk

# Dateisystem und LV in einem Schritt verkleinern
# Aufgrund der gewählten Größe dauert dieser Vorgang einige Minuten
# lvresize --size [+|-]Size[m|UNIT] --resizefs <lv name> see lvresize(8)

[root@sysrescue ~]# lvresize --size -100G --resizefs /dev/tower-pc-vg/home 
fsck from util-linux 2.38
/dev/mapper/tower--pc--vg-home: Inode 393223 extent tree (at level 1) could be narrower.  IGNORED.
/dev/mapper/tower--pc--vg-home: Inode 12847282 extent tree (at level 1) could be narrower.  IGNORED.
/dev/mapper/tower--pc--vg-home: 20959/13393920 files (1.2% non-contiguous), 14367863/53551104 blocks
resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/mapper/tower--pc--vg-home to 27336704 (4k) blocks.
The filesystem on /dev/mapper/tower--pc--vg-home is now 27336704 (4k) blocks long.

  Size of logical volume tower-pc-vg/home changed from 204.28 GiB (52296 extents) to 104.28 GiB (26696 extents).
  Logical volume tower-pc-vg/home successfully resized.

[root@sysrescue ~]# lsblk
NAME                       MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                        7:0    0 647.7M  1 loop  /run/archiso/sfs/airootfs
sda                          8:0    0 238.5G  0 disk  
├─sda1                       8:1    0   243M  0 part  
├─sda2                       8:2    0     1K  0 part  
└─sda5                       8:5    0 238.2G  0 part  
  └─crypt_disk             254:0    0 238.2G  0 crypt 
    ├─tower--pc--vg-root   254:1    0  27.9G  0 lvm   
    ├─tower--pc--vg-swap_1 254:2    0     4G  0 lvm   
    └─tower--pc--vg-home   254:3    0 104.3G  0 lvm   
sdb                          8:16   0 931.5G  0 disk

Zur Sicherheit führe ich noch eine Dateisystemüberprüfung aus:

[root@sysrescue ~]# fsck -t ext4 /dev/mapper/tower--pc--vg-home
fsck from util-linux 2.38
e2fsck 1.46.5 (30-Dec-2021)
/dev/mapper/tower--pc--vg-home: clean, 20959/6840320 files, 13956503/27336704 blocks

Da alles in Ordnung ist, fahre ich mit dem nächsten Schritt fort. Dazu nutze ich weiterhin die System Rescue Umgebung.

Schritt 4: LVs in zweiter VG erstellen

Da ich für die folgenden Vorgänge Zugriff auf die zweite VG benötige, öffne ich zuerst das LUKS-Device, in dem sich diese befindet:

[root@sysrescue ~]# cryptsetup open /dev/sdb crypt_disk2 --type luks2

Nun erstelle ich drei neue LVs, welche den Inhalt der existierenden LVs root, swap_1 und home aufnehmen sollen. Die Ziel-LVs müssen dazu mindestens gleich groß oder größer als die Quell-LVs sein. Um die erforderliche Größe zu ermitteln, lasse ich mir die Größe der Quell-LVs in Byte anzeigen. Ich wähle bewusst die Einheit Byte, da die Ausgabe bei größeren Einheiten auf zwei Nachkommastellen gerundet wird und ich mir keine Probleme durch die Rundung einhandeln möchte.

# Es werden nur die relevanten Informationen wiedergegeben
root:~# lvdisplay --unit b
LV Path                /dev/tower-pc-vg/root
LV Name                root
VG Name                tower-pc-vg
...
LV Size                29997662208 B
-----
LV Path                /dev/tower-pc-vg/swap_1
LV Name                swap_1
VG Name                tower-pc-vg
...
LV Size                4290772992 B
-----
LV Path                /dev/tower-pc-vg/home
LV Name                home
VG Name                tower-pc-vg
...
LV Size                111971139584 B

Mit diesen Informationen erstelle ich die neuen LVs in der zweiten VG:

:~# lvcreate --size 29997662208B /dev/tower-pc-vg2 --name root
  Logical volume "root" created.
:~# lvcreate --size 4290772992B /dev/tower-pc-vg2 --name swap_1
  Logical volume "swap_1" created.
:~# lvcreate --size 111971139584B /dev/tower-pc-vg2 --name home
  Logical volume "home" created.

Schritt 5: Partitionen mit partclone kopieren

Für diesen Schritt nutze ich die freie Anwendung Partclone. Da meine LVs weiterhin ausgehängt sind, muss ich mir um Schreib-Zugriffe anderer Prozesse während des Kopiervorgangs keine Sorgen machen:

# Manpage partclone(8)
# partclone.<fs_type> --dev-to-dev --source <Quelle> --output <Ziel>

[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/root --output /dev/tower-pc-vg2/root 
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/root) to device(/dev/tower-pc-vg2/root)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%                      
Total Time: 00:00:01, 100.00% completed!
done!
File system:  EXTFS
Device size:   30.0 GB = 7323648 Blocks
Space in use:  20.8 GB = 5078551 Blocks
Free Space:     9.2 GB = 2245097 Blocks
Block size:   4096 Byte
Elapsed: 00:03:16, Remaining: 00:00:00, Completed: 100.00%, Rate:   6.37GB/min, 
current block:    7323648, total block:    7323648, Complete: 100.00%           
Total Time: 00:03:16, Ave. Rate:    6.4GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/root) to the device (/dev/tower-pc-vg2/root)
Cloned successfully.

[root@sysrescue ~]# partclone.ext4 --dev-to-dev --source /dev/tower-pc-vg/home --output /dev/tower-pc-vg2/home 
Partclone v0.3.20 http://partclone.org
Starting to back up device(/dev/tower-pc-vg/home) to device(/dev/tower-pc-vg2/home)
Elapsed: 00:00:01, Remaining: 00:00:00, Completed: 100.00%                      
Total Time: 00:00:01, 100.00% completed!
done!
File system:  EXTFS
Device size:  112.0 GB = 27336704 Blocks
Space in use:  57.2 GB = 13956503 Blocks
Free Space:    54.8 GB = 13380201 Blocks
Block size:   4096 Byte
Elapsed: 00:12:22, Remaining: 00:00:00, Completed: 100.00%, Rate:   4.62GB/min, 
current block:   27336704, total block:   27336704, Complete: 100.00%           
Total Time: 00:12:22, Ave. Rate:    4.6GB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/tower-pc-vg/home) to the device (/dev/tower-pc-vg2/home)
Cloned successfully.

Die SWAP-Partition enthält keine Daten, die kopiert werden müssen. Hier formatiere ich das neue LV einfach als SWAP-Partition:

[root@sysrescue ~]# mkswap /dev/tower-pc-vg2/swap_1
Setting up swapspace version 1, size = 4 GiB (4290768896 bytes)
no label, UUID=f9181521-a06da5b8ade5

Schritt 6: Grub neukonfigurieren (2x)

An diesem Punkt habe ich meinen Rechner normal gestartet, um zu überprüfen, dass er wie gewohnt hochfährt. Die gute Nachricht lautet: „Er ist wie gewohnt gestartet.“

Nun verfüge ich über ein Clonezilla-Image der ersten Festplatte, dessen Wiederherstellbarkeit ich noch nicht durch Restore validiert habe und über die Kopien meiner Partitionen in der zweiten VG. Starten tut mein Rechner jedoch immer noch von den altbekannten Partitionen, da ich der Grub-Konfiguration noch nicht mitgeteilt habe, dass ein Wurzeldateisystem aus einer anderen Partition zu verwenden ist.

Leider habe ich es versäumt, mir während der Nutzung der System-Rescue-Umgebung Notizen zu machen. Daher kann ich die verwendeten Befehle an dieser Stelle nur unvollständig wiedergeben. Es ist mir jedoch gelungen, vom Wurzeldateisystem in /dev/tower-pc-vg2/root zu starten. Dies sieht man z.B. in der Ausgabe von lsblk:

:~$ lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0 931,5G  0 disk  
└─sda5_crypt                  253:0    0 931,5G  0 crypt 
  ├─tower--pc--vg2-lv--images 253:1    0   360G  0 lvm   /var/lib/libvirt/images
  ├─tower--pc--vg2-root       253:2    0  27,9G  0 lvm   /
  ├─tower--pc--vg2-swap_1     253:3    0     4G  0 lvm   [SWAP]
  └─tower--pc--vg2-home       253:4    0 104,3G  0 lvm   /home
sdb                             8:16   0 238,5G  0 disk  
├─sdb1                          8:17   0     2G  0 part  /boot
├─sdb2                          8:18   0     1K  0 part  
└─sdb5                          8:21   0 234,2G  0 part  
  └─sdb_crypt                 253:5    0 234,2G  0 crypt 
    ├─tower--pc--vg-root      253:6    0  27,9G  0 lvm   
    ├─tower--pc--vg-swap_1    253:7    0     4G  0 lvm   
    └─tower--pc--vg-home      253:8    0 104,3G  0 lvm   
sr0

Wer den Code-Block genau studiert hat, wird festgestellt haben, dass meine /boot-Partition gegenüber dem Eingangs erwähnten IST-Zustand auf 2 GB angewachsen ist. Ich habe die Partitionstabelle zwischenzeitlich mit GParted bearbeitet, welches in der System-Rescue-Umgebung enthalten ist.

Damit habe ich mein Ziel erreicht. Der Artikel könnte an dieser Stelle enden. Ich möchte jedoch zukünftig wieder die Partitionen von /dev/sdb verwenden. Dazu muss ich nochmals Grub neukonfigurieren, welches ich diesmal in folgendem Code-Block zeige:

root@tower-pc:~# mount /dev/tower-pc-vg/root /mnt

# Die separate /boot-Partition muss ebenfalls mit eingehängt werden
root@tower-pc:~# mount /dev/sdb1 /mnt/boot

root@tower-pc:~# for DEVICE in /dev /dev/pts /proc /sys; do mount --bind $DEVICE /mnt$DEVICE; done
root@tower-pc:~# mount /dev/tower-pc-vg2/lv-images /mnt/var/lib/libvirt/images

# ID der Partition mit dem Wurzeldateisystem ermitteln
root@tower-pc:~# ls -l /dev/tower-pc-vg/root 
lrwxrwxrwx 1 root root 7 18. Jun 20:13 /dev/tower-pc-vg/root -> ../dm-6
root@tower-pc:~# ls -l /dev/disk/by-id/ | grep dm-6
lrwxrwxrwx 1 root root 10 18. Jun 20:13 dm-name-tower--pc--vg-root -> ../../dm-6

# In eine chroot-Umgebung wechseln
root@tower-pc:~# chroot /mnt
root@tower-pc:/# pwd
/

In der chroot-Umgebung wird die Datei /etc/default/grub mit einem Editor geöffnet und die Zeile GRUB_CMDLINE_LINUX_DEFAULT= bearbeitet. Dort trage ich die ID der Partition meines Wurzeldateisystems ein. Die Zeile sieht anschließend wie folgt aus:

GRUB_CMDLINE_LINUX_DEFAULT="root=/dev/disk/by-id/dm-name-tower--pc--vg-root iommu='soft' quiet"

Der folgende Code-Block stellt die Befehle dar, mit denen Grub neukonfiguriert und installiert sowie initramfs aktualisiert wird.

root@tower-pc:/# grub-mkconfig -o /boot/grub/grub.cfg 
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-15-amd64
Found initrd image: /boot/initrd.img-5.10.0-15-amd64
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/tower--pc--vg2-root
done

root@tower-pc:/# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-15-amd64
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
root@tower-pc:/# exit
exit
root@tower-pc:~# reboot NOW

Nach dem Neustart habe ich noch überprüft, dass der Rechner wirklich die ursprünglichen Partitionen eingehängt hat:

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
└─sda5_crypt 253:4 0 931,5G 0 crypt
├─tower--pc--vg2-lv--images 253:5 0 360G 0 lvm /var/lib/libvirt/images
├─tower--pc--vg2-root 253:6 0 27,9G 0 lvm
├─tower--pc--vg2-swap_1 253:7 0 4G 0 lvm
└─tower--pc--vg2-home 253:8 0 104,3G 0 lvm
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 2G 0 part /boot
├─sdb2 8:18 0 1K 0 part
└─sdb5 8:21 0 234,2G 0 part
└─sdb_crypt 253:0 0 234,2G 0 crypt
├─tower--pc--vg-root 253:1 0 27,9G 0 lvm /
├─tower--pc--vg-swap_1 253:2 0 4G 0 lvm [SWAP]
└─tower--pc--vg-home 253:3 0 104,3G 0 lvm /home
sr0 11:0 1 1024M 0 rom

Ende gut alles gut

Operation gelungen. Patient rechnet noch.

Mein Ziel habe ich erreicht und als Bonus Grub so konfiguriert, dass wieder meine ursprünglichen Partitionen verwendet werden. Die LVs in VG2 behalte ich vorerst. Sie stören nicht und ich kann die dortige Installation ebenfalls booten. Diese kann ich evtl. noch für zukünftige Experimente hernehmen.

Mir gefällt, dass ich frei verfügbare Informationen und Werkzeuge benutzen konnte, um alle notwendigen Aufgaben zu erledigen. So habe ich wieder einiges dazugelernt. Dies ist einer der Gründe, weshalb mir Freie Software und Open Source so gut gefallen.

Nun werde ich diesen Text noch verschlagworten, damit ich ihn in einer fernen Zukunft auch wiederfinde.

Ein Freund bat mich kürzlich um meine Meinung zum Thema Software-Verteilung und Dokumentation des Installations- bzw. Bereitstellungsprozesses. Die Gedanken, die ich mir dazu gemacht habe, möchte ich an dieser Stelle mit euch teilen. Dabei schreibe ich aus dem Blickwinkel eines Systemintegrators, der von Dritten erstellte Software integrieren und betreiben muss.

Den Anwendungsentwicklern, Software-Architekten und Produkt-Managern unter euch soll dieser Text als Information dienen, was ich und ggf. weitere Personen meiner Zunft von einer Dokumentation erwarten bzw. wie wir uns Software-Verteilungsprozesse vorstellen.

Als Leser seid ihr alle eingeladen, eure Gedanken ebenfalls zu teilen und eine Diskussion zu diesem Thema zu führen.

Das Szenario

Ich habe bei meinen Gedanken ein Szenario im Kopf, in dem ein Anwendungsentwickler eine Anwendung in einer Sprache seiner Wahl schreibt. Diese Anwendung soll später über ein Web-Frontend erreichbar und nutzbar sein. Die Anwendung benötigt eine Datenbank, um Informationen darin abzulegen. Binärdateien werden ggf. außerhalb der Datenbank in einem Dateisystem gespeichert.

Die Anwendungsentwickler freuen sich, wenn ihre Software einen hohen Verbreitungsgrad erreicht. Dazu muss die dazugehörige Dokumentation folgende Informationen bieten.

Werkzeuge zum Erstellen und Ausführen der Anwendung

• Welcher Compiler ab welcher Version wird benötigt?
• Welche Bibliotheken werden ab welcher Version benötigt?
• Sind abweichende Versionen möglich oder funktioniert nur genau eine?
• Welche Laufzeitumgebung wird benötigt?
• Was ist in welcher Reihenfolge zu tun, um vom Quelltext zu einem ausführbaren Programm zu kommen?

Voraussetzungen zur Integration der Anwendung

• Wird eine Datenbank benötigt?
• Welche Datenbank-Management-Systeme werden unterstützt?
• Ab welcher Version?
• Über welche Rechte muss ein DB-User mindestens verfügen, damit der Anwendungs-Installer die notwendigen Tabellen, Views, etc. erstellen kann?
• Welche Webserver werden unterstützt?
• Welche Protokolle, Parameter bzw. Optionen sind für die Kommunikation mit der Anwendung notwendig?

Ich bin immer enttäuscht, wenn hier auf ein einziges System eingeschränkt wird. Dies limitiert unnötig den Nutzerkreis.

• Wird ein Snakeoil-Zertifikat mitgeliefert oder hat der Systemintegrator dieses beizustellen? Eigene Zertifikate auf Wunsch verwenden zu können ist obligatorisch.

Die bis jetzt genannten Informationen müssen so umfassend sein, dass Paketbetreuer bzw. Software-Paketierer daraus Debian-, Flatpak-, RPM-, Snap-Pakete, Container-Images und Windows-Installer bauen können.

Nehmen die Anwendungsentwickler in Personalunion die Rolle von Software-Paketierern wahr, scheint es dennoch unrealistisch, dass sie allein alle Formate unterstützen können. Sie sollten sich für einige wenige Formate entscheiden, die auf möglichst vielen Plattformen lauffähig sind. In dem von mir gedachten Szenario sind dies OCI-kompatible Container-Images.

Bei einer GUI-Anwendung würde ich mich vermutlich für Flatpak entscheiden. Die Paketierung als DEB oder RPM würde ich auf jeden Fall den Paketbetreuern der jeweiligen Distributionen überlassen.

Systemintegration

Für den Systemintegrator, welcher den Webserver, die Anwendung und die Datenbank zusammenbringt (integriert), muss klar beschrieben werden:

• Gibt es ein fertiges Container-Image? Wo bekommt man es her?
• Optional: Wie erstellt man das Container-Image selbst?
• Welche (Umgebungs-)Variablen gehören zum Image? Welche Werte können diese annehmen?
• Ein Kommunikationsdiagramm, damit der Sysadmin weiß, was wann mit wem spricht und welche Firewall-Regeln evtl. benötigt werden.

Referenzimplementierungen sind ebenfalls schön. Diese sollten für Docker, Docker-Compose, Kube-YAML (K8s) und Podman bereitstehen. Die Doku zum Container-Image muss jedoch so ausgestaltet sein, dass auch ohne Referenzimplementierung die Instanziierung mit den verschiedenen Engines und Orchestrierern gelingen kann.

Was Sysadmins (wie ich) nicht mögen

Ich mag es nicht, wenn in den Abhängigkeiten ein Webserver (Apache, NGINX, lighttpd) oder ein Datenbank-Management-System unnötig hart verdrahtet ist. Gleiches gilt für die Festlegung der zu verwendenden Container-Registries. Ich will dem Installer sagen können, wo er die Images findet und nicht auf den Dockerhub festgelegt werden.

Und ja, mir ist bewusst, dass eine gute Dokumentation genauso viel Aufwand und Pflege bedeutet wie der Quelltext einer Anwendung selbst. Aber ist es eine Alternative, wenn Systemintegratoren die Anwendung nach dem ersten Installationsversuch hassen?

Eure Meinung ist willkommen

Wie steht ihr als Entwickler zum Thema Dokumentation? Was erwartet ihr als Sysadmin und User von ihr?

Stimmt ihr mit mir überein oder habt ihr ganz andere Ansichten dazu? Nutzt gern die Kommentarfunktion und lasst es mich wissen.

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.

Red Hat Developer Subscription for Individuals

Ein jeder kann über das Red Hat Developers Program (engl.) kostenlos eine persönliche RHEL Developer Subscription (engl.) erhalten. Mit dieser Sub erhält der Besitzer das Recht, bis zu 16 Systeme (physisch oder virtuell) zu betreiben; auch in Produktion.

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:

1. Einführung in Red Hat Insights
2. Erkundung von Red Hat Insights — Advisor
3. Schwachstellen-Management mit Red Hat Insights
4. Red Hat Insights – Compliance
5. Red Hat Insights – Patch and Drift
6. Persönliche Bewertung von Red Hat Insights

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:

1. Wer betreibt das Projekt bzw. steht hinter dem Projekt?
2. Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
3. Welchen Eindruck hinterlässt die Dokumentation?
4. Wie lange wird ein Major-Release unterstützt?
5. Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
6. 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.

Ähnlich wie AlmaLinux finanziert sich das Projekt durch verschiedene Sponsoren. Wie die Webseite Linuxnews am 16. Mai 2022 berichtete, konnte sich Rocky Linux eine Finanzierung in Höhe von 26 Mio. USD von Google sichern.

Hilfe, Unterstützung und Dokumentation

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.

Release	AlmaLinux	RHEL	Rocky Linux
8.4	2021-05-26	2021-05-18	2021-06-21
8.5	2021-11-12	2021-11-09	2021-11-15
8.6	2022-05-12	2022-05-10	2022-05-16
9 beta	2022-04-19	2021-11-03	N/A
9.0 GA	2022-05-26	2022-05-18	2022-07-14

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:

• AlmaLinux Product Errata – https://errata.almalinux.org/
• Red Hat Product Errata – https://access.redhat.com/errata
• Rocky Linux Product Errata – https://errata.rockylinux.org/

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:

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.

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.

Quellen und weiterführende Links

1. Nextcloud im Container – Teil 1: Der Plan
2. Nextcloud im Container – Teil 2: Die Ansible-Rolle
3. Nextcloud im Container — Teil 3: Mit Reverse-Proxy
4. Nextcloud im Container — Teil 4: Hier und da klemmt es
5. Nextcloud im Container – Teil 5: Backup und Restore
6. ansible_role_deploy_nextcloud_with_mariadb_pod auf GitHub
7. Semantic Versioning 2.0.0

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).

$ getent hosts beispiel.de
23.21.157.88    beispiel.de

$ getent ahosts my-it-brain.de
2a02:c207:3005:4920::1 STREAM my-it-brain.de
2a02:c207:3005:4920::1 DGRAM  
2a02:c207:3005:4920::1 RAW    
144.91.83.52    STREAM 
144.91.83.52    DGRAM  
144.91.83.52    RAW

Für weitere Abfragemöglichkeiten verweise ich auf die Manpage getent(1).

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.

Kommando

$ timeout $TIMEOUT_SECONDS bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ timeout 5 bash -c "</dev/tcp/${HOST}/${PORT}"; echo $?
0

Selbstverständlich funktioniert auch folgender Befehl:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/443"; echo $?
0

Fehlgeschlagener Verbindungstest

Jetzt nutze ich einen Port, der nicht erreichbar ist:

$ timeout 5 bash -c "</dev/tcp/beispiel.de/4433"; echo $?
124

Nutzung von nc

Sollte nc bereits installiert sein, kann man auch dieses Programm für einen Verbindungstest nutzen:

Kommando

$ nc -w $TIMEOUT_SECONDS -v $HOST $PORT </dev/null; echo $?

Beispiele

Erfolgreicher Verbindungstest

$ HOST=beispiel.de
$ PORT=443
$ nc -w 2 -v $HOST $PORT </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 23.21.157.88:443.
Ncat: 0 bytes sent, 0 bytes received in 0.54 seconds.
0

Fehlgeschlagener Verbindungstest

$ nc -w 2 -v beispiel.de 4433 </dev/null; echo $?
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: TIMEOUT.
1

Zusammenfassung

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.

Ich habe die im obigen Bild dargestellten Einstellungen wie folgt geändert:

1. Zeitintervall zwischen zwei vollständigen Wiederherstellungspunkten: 7 Tage
2. Die Verschlüsselung für Wiederherstellungspunkte habe ich deaktiviert
3. 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.

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:

$ podman exec -u 33 -it nextcloud bash
www-data@nc_pod:~/html$

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:

backup:point:restore [--force] [--do-not-ask-data] [--do-not-ask-sql] [--file FILE] [--chunk CHUNK] [--data DATA] [--] <pointId>

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.

Während ich im vorherigen Abschnitt einen ausgewählten Wiederherstellungspunkt nach einer Datei durchsucht habe, liste ich diesmal alle Wiederherstellungspunkte bis zum 15.03.2022 auf, welche den gesuchten Pfad enthalten:

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.

Quellen und weiterführende Links

1. Nextcloud im Container – Teil 1: Der Plan
2. Nextcloud im Container – Teil 2: Die Ansible-Rolle
3. Nextcloud im Container – Teil 3: Mit Reverse-Proxy
4. Nextcloud im Container – Teil 4: Hier und da klemmt es
5. Nextcloud im Container – Teil 6: Updates
6. Nextcloud Backup App auf GitHub
7. How to restore a folder with all files in it? #211
8. S3 upload still failes with OOM for 1.0.6 #237
9. Nothing being uploaded to external storage (WebDAV) #238