Ende letzten Jahres habe ich euch gezeigt, wie ihr die OpenThread RCP Firmware auf dem SMLIGHT SLZB-07 installiert. Neben den SLZB-07 Modellen gibt es von SMLIGHT noch die SLZB-06 Modelle, welche die im Home...
Zum Jahresende möchte ich kurz zurückblicken und reflektieren, wie dieses Jahr für meinen kleinen Blog verlaufen ist.
Thematisch haben sich fast alle Artikel mit Freier Software und Open Source beschäftigt oder waren daran angelehnt. Wie auch in den vorangegangenen Jahren habe ich keine bewussten Themenschwerpunkte gesetzt, sonder über die Themen geschrieben, dich mich in der jeweiligen Zeit interessierten und mich beschäftigt haben.
Zu Beginn des Jahres hatte es mir das Thema IPv6 angetan, wozu vier Beiträge erschienen sind:
Das Thema begleitet mich auch weiterhin, jedoch gibt es bisher keine spannenden Neuigkeiten, die ich für berichtenswert halte. Ich fürchte, IPv6 wird sobald nicht die Weltherrschaft an sich reißen.
Ein Thema, welches mir sehr wichtig war und ist, ist die Dokumentation für den Notfall bzw. das digitale Erbe. Wie die Kommentare zu diesem Artikel bezeugen, bin ich nicht der Einzige, der sich darum Gedanken macht. Leider bin ich 2024 kaum damit vorangekommen und schiebe es weiter vor mir her. Dies ärgert mich etwas, da ich mir wünsche, mich für ein so wichtiges Thema besser aufraffen zu können.
In 2024 wurden wir auf allen Kanälen mit Künstlicher Intelligenz, Maschinellem Lernen und großen Sprachmodellen überflutet. Es fällt schon fast schwer noch irgendeine Anwendung oder ein Produkt ohne AI kaufen zu können. Abseits des Hypes habe ich mich ebenfalls mit dem Thema beschäftigt und zwei Beiträge ( [1] und [2]) dazu geschrieben. Ich bin überzeugt, dass die verschiedenen Spielarten der künstlichen Intelligenz unser Leben und unsere Art zu Arbeiten stark beeinflussen und verändern werden. Daher werde auch ich hier am Ball zu bleiben, um nicht von der laufenden Entwicklung abgehängt zu werden.
Damit sind 2024 insgesamt 26 Artikel erschinen. Das sind 19 weniger als in 2023. Mein selbst gestecktes Ziel, jeden Monat mindestens zwei Artikel zu veröffentlichen habe ich ebenfalls nicht erreicht. Da dies mein Hobby ist und mir primär Freude bereiten soll, setze ich mich durch diese Zielverfehlung nicht unter Druck.
Das Jahr 2025 lasse ich ohne große Ziele und Bestrebungen auf diesen Blog zukommen. Nur eines ist sicher, ich werde meine Texte weiterhin selbst und ohne KI-Unterstützung schreiben. Denn damit würde ich mir nur selbst die Freude am Bloggen nehmen.
Ich freue mich, wenn ich auch 2025 wieder interessantes Wissen in meinen Texten mit euch teilen kann. Ich wünsche euch einen guten Rutsch ins Jahr 2025!
Dies ist ein Update des Artikels aus dem letzten Jahr. Eine aktuelle Hardwareübersicht gibt es hier.
Als privates Mobiltelefon benutze ich seit 2022 ein Samsung Galaxy S22 mit einem Congstar-Tarif, welcher mich im Monat 10,- EUR kostet. Ich bin mit dem Gerät weiterhin zufrieden und plane, es in 2025 ebenfalls zu nutzen.
Im Folgenden führe ich einige von mir genutzte Apps auf, mit einer kurzen Erklärung, wofür ich diese verwende. Wo möglich verlinke ich in den F-Droid Store. Wo dies nicht möglich ist, führen diese in den Google Play Store.
Hier die am häufigsten verwendeten Apps zählen in alphabetischer Reihenfolge:
Zu den eher sporadisch genutzten Apps zählen in alphabetischer Reihenfolge:
Evtl. ist euch aufgefallen, dass eine prominente App in obiger Aufzählung fehlt. Tatsächlich widerstehe ich weiterhin dem sozialen Druck und verweigere mich der Nutzung von WhatsApp. Der Verzicht auf WhatsApp schnitt mich leider ausgerechner bei der Freiwilligen Feuerwehr von einem Teil der Kommunikation ab. Daher freue ich mich nun umso mehr, dass unsere Feuerwehr zur Planung von Dienstabenden, Veranstaltungen und sonstigen Terminen auf Spond (Google Play Store) umgestiegen ist.
Ich nutze auch Online-Banking-Apps auf dem Smartphone. ich nutze diese z.B., um am Laptop getätigte Überweisungen oder Online-Einkäufe zu autorisieren. Darüber hinaus schätze ich die Benachrichtigung über getätigte Umsätze.
Insgesamt sind aktuell 168 Apps installiert. Ehrlicherweise werde ich vermutlich erst ausmisten, wenn der Speicher knapp wird.
Ach ja, telefonieren tue ich damit natürlich auch. ;-)
Seit Mitte 2019 [verwende ich] auch ein Samsung T830 Galaxy Tab S4 Wi-Fi Tablet. Durch seine 10,5 Zoll (ca. 27 cm) Bildschirmdiagonale, das geringe Gewicht und mit der App ReadEra eignet es sich hervorragend zum Lesen von PDF-Dateien und E-Books.
https://www.my-it-brain.de/wordpress/meine-privaten-arbeitsmittel-anfang-2022/
Darüber hinaus nutze ich das Gerät:
Dabei verwende ich mehr oder weniger die gleichen Apps wie auf dem Smartphone. Für den Zugriff auf Mastodon verwende ich hier statt Fedilab die App Tusky (F-Droid).
Seit 2024 neu auf dem Tablet sind FeedMe (Google Play Store) und Wallabag (Google Play Store). FeedMe teste ich als Alternative zu Feedly (Google Play Store), da dieser die Synchronisierung mit meiner FreshRSS-Instanz unterstützt. Er ist etwas langsam, ansonsten zufriedenstellend. In Wallabag speichere ich Artikel, die ich später lesen oder für Workshops, Talks und Blog-Artikel nutzen möchte.
Der Laptop ist mein Hauptarbeitsmittel, den ich für so gut wie alle anfallenden Aufgaben verwende. Lediglich zum Lesen von E-Books bevorzuge ich das Tablet und zum Instant Messaging das Smartphone.
Ich habe immer mal wieder Evolution ausprobiert, da dies eine bessere Integration in GNOME bietet. Doch bin ich nie damit warm geworden. Da ich mehrere E-Mail-Konten bei verschiedenen Anbietern sowie Kalender für verschiedene Zwecke habe, finde ich die Zusammenführung und Nutzung in Thunderbird ideal.
Mein ehemaliger Desktop-PC ist in ein 19-Zoll-Gehäuse und mit diesem in einen Serverschrank im Keller umgezogen. Die ganze Geschichte dazu kann in „Ein Serverschrank mit Kompromissen“ nachgelesen werden.
Auf diesem Rechner laufen dauerhaft zwei virtuelle Maschinen:
Als dauerhaft laufender Rechner führt dieser Host meine Cronjobs und Ansible-Playbooks aus, erzeugt Backups und kopiert/synchronisiert Daten von hier nach dort.
Die Untersützung von Podman bzw. der weiteren Container-Tools Buildah und Skopeo in RHEL ist super. Die kostenlose Developer Subscription for Individuals ermöglicht mir die produktive Nutzung von bis zu 16 RHEL-Servern. Das sind mehr als genug für meine privaten Zwecke.
Hier hat es im laufenden Jahr keine Änderungen gegeben. Ich gehe davon aus, dass es hier in 2025 ebenfalls keine Änderungen geben wird. Drei neue Dienste sind hinzugekommen, die ich bei adminforge.de nutze. Dies sind:
Die letzten vier befinden sich noch in der Testphase. Ob die Nutzung in 2025 anhält, werdet ihr im nächsten Rückblick erfahren können.
Ich freue mich, wenn euch dieser kleine Überblick gefällt und ihr vielleicht die ein oder andere Inspiration darin findet. Ich freue mich auch, wenn ich in euren Blogs lesen kann, womit ihr 2024 so gearbeitet habt.
Im Beitrag „SMLIGHT SLZB-07: OpenThread RCP Firmware flashen“ habe ich euch gezeigt, wie ihr die Openthread RCP Firmware auf den SMLIGHT SLZB-07 flasht. In diesem Beitrag zeige ich euch nun, wie ihr mit dem...
Ich habe mir kürzlich einen SMLIGHT SLZB-07 und einen SMLIGHT SLZB-07p7 gekauft. Ersteren um mit Thread irgendwann rumspielen zu können und letzteren als Ersatz für meinen Sonoff ZB Dongle-P. Wenn ihr auf’s Veröffentlichungsdatum dieses...
Unter ‚http://docs.redhat.com‚ findet man gesammelt und sortiert Red Hats Dokumentation, z.B. zu Ansible Automation Platform, OpenShift, RHEL, RHV, Satellite, etc.
Neben der Online-Version im Single- und Multi-Page-Format kann man die einzelnen Texte auch als PDF herunterladen. Dies manuell zu tun, ist allerdings mühselig. Deutlich leichter geht es mit dem PDF Document Downloader von Kazuo Moriwaka. Es handelt sich dabei um ein Bash-Skript, bestehend aus awk, curl, grep, und parallel, welches als Argument die Basis-URL für eine Produktkategorie übernimmt und anschließend alle PDF-Dateien ermittelt und herunterlädt.
Klingt gut? So bekommt ihr das Skript:
Anmelden~/bin/chmod u+x ~/bin/fetchdoc.shFolgender Code-Block zeigt einige Beispiele, mit denen ich mir einen Teil der Dokumentation auf mein Laptop gezogen habe:
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10-beta
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_satellite/6.15
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_satellite/6.16
$ ~/bin/fetchdoc.sh https://docs.redhat.com/en/documentation/red_hat_virtualization/4.4Thank you Kazuo Moriwaka for this awesome little helper!
Kürzlich habe ich auf Fryboyter diesen Artikel gelesen: Wie sollte man Veröffentlichungen versionieren?
Meine Gedanken zu dem Artikel und dem Thema möchte ich an dieser Stelle mit Fryboyter und euch teilen.
Fryboyter favorisiert nach eigener Darstellung Calendar Versioning (CalVer), da dies seiner Meinung nach aussagekräftiger ist, als z.B. 0.78.1, was sehr stark nach Semantic Versioning (SemVer) aussieht. Meiner Meinung nach kann man dies nicht pauschal sagen, da beide Versionsschemata ihre eigenen Vor- und Nachteile haben. Doch wann sollte man zu welchem Schema greifen?
Die folgende Liste ist eine Übersetzung des englischen Textes, welcher hier zu finden ist. Wenn einer der in dieser Liste genannten Punkte auf ein Projekt zutrifft, scheint CalVer ein geeignetes Schema für die Versionierung zu sein.
Einige Betriebssysteme wie z.B. Ubuntu haben einen festen Veröffentlichungsrythmus und Unterstützungszeitraum. So werden Ubuntu LTS Versionen ohne Zusatzverträge für 5 Jahre unterstützt und mit Aktualisierungen versorgt. Bei Ubuntu 24.04 LTS kann man bereits am Namen erkennen, wie alt dieses Release ist und wie lange es mit Aktualisierungen versorgt wird. Ubuntu veröffentlicht Aktualisierungen für die enthaltenen Pakete in unregelmäßigen Abständen, meist sobald diese verfügbar sind. Aufgrund der vielen enthaltenen Pakete und der Aktualisierungsrichtlinie scheint SemVer (siehe nächster Abschnitt) hier nicht vorteilhaft zu sein.
Bei Debian 12, RHEL 9 oder SLES 15 erkennt man das Datum der Veröffentlichung hingegen nicht. Hier hilft nur ein Blick in die jeweilige Versionshistorie der Projekte, um Informationen über den Zeitpunkt der Veröffentlichung und der jeweiligen Unterstützungszeiträume zu finden.
Auf Grundlage einer Versionsnummer von MAJOR.MINOR.PATCH werden die einzelnen Elemente folgendermaßen erhöht:
Quelle: https://semver.org/lang/de/
1. MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,
2. MINOR wird erhöht, wenn neue Funktionalitäten, die kompatibel zur bisherigen API sind, veröffentlicht werden, und
3. PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.
SemVer ist stringent, einfach nachzuvollziehen und bietet für mich als Systemadministrator die folgenden Vorteile.
Wird PATCH erhöht, weiß ich, dass lediglich Fehler behoben wurden, sich am Funktionsumfang einer Anwendung jedoch nichts ändert. Das Einzige, was mir hierbei den Tag vermiesen kann, sind Regressionen. Das Risiko, dass irgendetwas kaputtgeht oder schlimmer wird, ist jedoch gering.
Wird MINOR erhöht, weiß ich, dass die Anwendung neue Funktionalität enthält und ich weiß, dass nun ein genauerer Blick erforderlich ist, um zu entscheiden, ob diese Funktionalität in meiner Umgebung bereitgestellt werden soll bzw. darf. Gegebenenfalls sind vor einer Aktualisierung Anwenderschulungen durchzuführen und interne Prozessbeschreibungen zu aktualisieren, bevor die neue Version zur Nutzung freigegeben werden kann.
Einem an Featureritis erkrankter Nerd mag jede neue Funktion gefallen. Unzureichend geplante Veröffentlichungen neuer Funktionen in Unternehmen können hingegen interessante Folgen haben.
Wird MAJOR erhöht, ist ein Blick in die Release Notes angeraten. Denn man weiß schon mit einem Blick auf die Versionsnummer, dass diese Version Breaking Changes enthält. Dies können sein:
Eine solche Aktualisierung kann man in aller Regel nicht ohne sorgfältige Planung installieren. Das Risiko, dass dabei etwas kaputtgeht und Stress und Produktionsausfall folgen ist einfach zu groß.
Fryboyter schreibt: „Zumal meiner Meinung nach 2024.10.11 aussagekräftiger als 0.78.1 ist.“
Aber ist es wirklich aussagekräftiger? Wenn ich nur das Datum sehe, weiß ich lediglich, wann die Version veröffentlicht wurde. Welchen Funktionsumfang die Version hat, welche Änderungen es zur vorhergehenden Version es gibt, ob diese Version stabil ist oder ob es die aktuellste Version ist, erkennt man nicht. Bei zwei Daten erkennt man zumindest, welches die aktuellere Version ist.
Sehe ich nur 0.78.1, weiß ich nicht, wann diese Version veröffentlicht wurde. Ich sehe jedoch auf den ersten Blick, dass sich diese Version in einer initialen Entwicklungsphase befindet, der Funktionsumfang nicht abschließend definiert ist und sich jederzeit ändern kann. Kurz gesagt, mit jeder weiteren Erhöhung von MINOR und PATCH ist damit zu rechnen, dass sich das Verhalten und der Funktionsumfang signifikant ändern. Da die einzelnen Elemente bei SemVer ausschließlich erhöht jedoch nie gesenkt werden, kann man bei Vorliegen von zwei Versionsnummern der gleichen Anwendung erkennen, welches die aktuellere ist. Details zu Änderungen gegenüber der Vorgängerversion verrät SemVer zwar auch nicht, doch kann ich den Umfang der Änderungen erkennen. Für mich besitzt SemVer damit in den meisten Fällen die größere Aussagekraft.
Die Frage wann es Zeit für Version 1.0.0 ist, beantwortet SemVer wie folgt:
Wenn die Software schon in der Produktion verwendet wird, sollte sie bereits in Version 1.0.0 vorliegen. Falls eine stable API existiert, auf die sich Nutzer bereits verlassen, sollte es ebenfalls die Version 1.0.0 sein. Auch wenn Kompatibilität zu vorherigen Versionen bereits eine wichtige Rolle spielt, ist Version 1.0.0 angebracht.
Quelle: https://semver.org/lang/de/#woher-wei%C3%9F-ich-wann-es-zeit-ist-version-100-zu-ver%C3%B6ffentlichen
Ich gehöre tendenziell eher zu Team SemVer und denke, dass dies eine höre Aussagekraft als CalVer besitzt.
Grundsätzlich halte ich es für sinnvoll und wichtig, wenn sich Entwickler bzw. Organisationen Gedanken machen, welches Versionsschema am besten zu ihrem Projekt passt.
Wie denkt ihr darüber? Hinterlasst doch gern einen Kommentar mit eurer Meinung oder veröffentlicht einen eigenen Text dazu in eurem Blog.
Falls ihr meinen Beitrag „Was läuft auf dem Home Server?“ gelesen habt, wisst ihr, dass auf meinem Home Server unter anderem ein LXC mit Stirling PDF vorhanden ist. Ich hatte Stirling PDF aber noch...
Dieser Artikel gibt meine Motivation für den Bau von Container-Images und die Vorgehensweise wieder und zeigt, wie ich mit Buildah meine OCI-kompatiblen Container-Images erstelle.
Es handelt sich dabei mehr um einen Erfahrungsbericht als ein Tutorial und ich erhebe keinen Anspruch auf Vollständigkeit. Das behandelte Beispiel ist jedoch zum Einstieg und zur Nachahmung für all jene geeignet, die Container ausführen können und diese gerne ohne Verwendung von Containerfiles bauen möchten.
Ich möchte die Ansible-Rollen aus meiner Collection tronde.nextcloud mit Molecule und Podman-Containern testen. Als Zielplattform für das Deployment der Nextcloud unterstütze ich zunächst Debian und RHEL.
Die Tests sollen verifizieren, dass Nextcloud im Container in einer rootless-Podman-Umgebung bereitgestellt werden kann. Da der Test unter Verwendung von Podman-Containern durchgeführt werden soll, müssen diese Container eine solche rootless-Podman-Umgebung bereitstellen.
Für RHEL 8 und RHEL 9 habe ich entsprechende Container-Images gefunden. Für Debian bin ich nicht fündig geworden und habe daher beschlossen, diese Container-Images selbst zu erstellen.
Buildah ist das Werkzeug meiner Wahl, da:
containerfile(5) benötigt undFür mich sind dies ausreichend Gründe, um mich kopfüber in ein neues Container-Projekt zu stürzen. Wer mehr über die Beziehung von Buildah zu Podman erfahren möchte, dem empfehle ich den englischsprachigen Artikel: Buildah and Podman Relationship von Tom Sweeney.
Um rootless Podman in einem Container zum Laufen zu bekommen, habe ich mich an dem englischsprachigen Artikel How to use Podman inside of a container von Dan Walsh orientiert. Das Ergebnis findet ihr in meinem GitHub-Repo tronde/container-image-forge.
Die folgenden Code-Blöcke zeigen Auszüge aus dem Skript buildah_create_debian_bookworm_with_rootless_podman.sh (Commit 7634ed8). Die enthaltenen Befehle werden unter dem jeweiligen Code-Block erläutert. Alle Befehle werden als normaler Benutzer ohne Root-Rechte ausgeführt.
# Name of target container image
tctri=debian_rootless_podman
# Get a base image
ctr=$(buildah from --pull=newer docker://docker.io/library/debian:bookworm)tctri nimmt den Namen des Container-Images auf, welches ich erzeugen werdectr nimmt den Namen des Containers auf, welcher durch den buildah-from(1)-Befehl erzeugt wird; mit diesem Container wird im Folgenden gearbeitet--pull=newer sorgt dafür, dass das Image nur dann aus der angegebenen Registry heruntergeladen wird, wenn es aktueller als das evtl. lokal gespeicherte Image istbuildah run -- $ctr apt -y update
buildah run -- $ctr apt -y upgrade
buildah run -- $ctr apt -y install podman fuse-overlayfs libvshadow-utils libcap2-bin ca-certificatesbuildah-run(1) werden Befehle innerhalb des Arbeits-Containers ausgeführtca-certificates wird benötigt, um später Container-Images aus einer Registry herunterladen zu könnenbuildah run -- $ctr useradd podman
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subgid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subgid"
buildah run -- $ctr setcap cap_setuid+epi /usr/bin/newuidmap
buildah run -- $ctr setcap cap_setgid+epi /usr/bin/newgidmappodman erstellt/etc/sub[g,u]id habe ich mir aus dem ubi9/podman-Image abgeschautsetcap-Befehle sind notwendig, um rootless Podman ausführen zu können; ich habe sie durch Internetrecherche und Trial-and-Error zusammengestelltbuildah config -v /var/lib/containers $ctr
buildah config -v /home/podman/.local/share/containers $ctr/var/lib/containers/home/podman/.local/share/containersbuildah run -- $ctr chown -R podman:podman /home/podman
buildah run -- $ctr sh -c "mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers /var/lib/shared/vfs-images /var/lib/shared/vfs-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock; touch /var/lib/shared/vfs-images/images.lock; touch /var/lib/shared/vfs-layers/layers.lock"
buildah config --env _CONTAINERS_USERNS_CONFIGURED="" $ctrpodman bekommt ein HOME-Verzeichnisbuildah run -- $ctr apt -y reinstall uidmap
buildah run -- $ctr apt -y clean
buildah run -- $ctr rm -rf /var/lib/apt/lists/*uidmap neu installiert werden, um ein UID/GID-Mapping sicherzustellen; dies scheint analog zur Neuinstallation der shadow-utils in Artikel [7] notwendig zu sein# Commit to an image
buildah commit --rm $ctr $tctri
# Alternative: Use this and add GPG fingerprint for image signing
# buildah commit --sign-by <fingerprint> --rm $ctr $tctri
# Tag the image just created
buildah tag $tctri $tctri:bookworm-$(date --iso)buildah-commit(1) wird der Inhalt des Arbeits-Containers $ctr in ein Container-Image namens $tctri geschrieben--rm wird der Arbeits-Container entferntbuildah-tag(1) fügt dem Image einen Tag mit Datumsstempel hinzu; siehe auch: Recommendations for tagging and versioning container imagesDer Befehl buildah-commit(1) fügt dem neuen Image übrigens nur einen weiteren Layer hinzu, egal wie viele Befehle zuvor im Arbeits-Container ausgeführt wurden. Das erzeugte Image umfasst also die Layer des Basis-Image plus einen weiteren.
An diesem Punkt habe ich ein Basis-Image ausgewählt, mithilfe von buildah zusätzliche Software installiert, einen Benutzer hinzugefügt und ein neues Image erzeugt.
Um den Build-Prozess zu automatisieren, habe ich die notwendigen Befehle in Bash-Skripte geschrieben und unter https://github.com/Tronde/container-image-forge abgelegt.
Die fertigen Images halte ich in der Registry https://quay.io/repository/rhn-support-jkastnin/debian_rootless_podman vor. Fühlt euch frei, diese für eigene Experimente zu benutzen, doch verwendet sie nur mit Vorsicht in Produktion. Ich erzeuge diese Images nur nach Bedarf neu, so dass die veröffentlichen Versionen veraltet und voller Sicherheitslücken sein können.
Jetzt, wo die Images fertig sind, kann ich prüfen, ob sich rootless Podman darin auch wie gewünscht ausführen lässt.
Die Prozesse innerhalb des von meinem Container-Image instanziierten Containers laufen als Benutzer root. Um die Prozesse als Benutzer podman auszuführen, ist dies beim Aufruf von podman run explizit mit anzugeben. Der folgende Code-Block verdeutlicht dies und zeigt zugleich den ersten Fehler beim Versuch rootless Podman auszuführen.
]$ podman run --rm localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=0(root) gid=0(root) groups=0(root)
]$ podman run --rm --user podman localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=1000(podman) gid=1000(podman) groups=1000(podman)
]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
time="2024-09-21T18:43:35Z" level=error msg="running `/usr/bin/newuidmap 15 0 1000 1 1 1 999 1000 1001 64535`: newuidmap: write to uid_map failed: Operation not permitted\n"
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1Der Fehler deutet auf fehlende capabilities(7) hin. Um diese Hypothese zu testen, wiederhole ich den letzten Befehl mit der Option --privileged (siehe dazu podman-run(1)):
]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse --privileged localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…Damit funktioniert es. Leider geben sich viele Menschen an dieser Stelle mit dem Ergebnis zufrieden. Doch ich möchte diese Container nicht einfach mit --privileged ausführen. Also studiere ich die Manpage capabilities(7) und teste mich Stück für Stück heran, bis ich mit dem folgenden Kommando ebenfalls erfolgreich bin:
]$ podman run --rm --user podman --security-opt label=disable --device /dev/fuse --cap-add=setuid,setgid,sys_admin,chown localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…Dies ist schon deutlich besser, da dem Container hiermit deutlich weniger Privilegien eingeräumt werden müssen. Das Thema Container-Privilegien und capabilities(7) werde ich noch genauer untersuchen. Eventuell folgt dazu dann auch ein weiterer Artikel. Für den Moment ist das Ergebnis gut genug.
In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen Erfahrungen.
Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.
Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.
Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.
Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage.
Auf Seite 8 findet sich die Aussage, dass 40 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg.
Interessant finde ich die genannten Gründe für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.
Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.
Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.
Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einführen, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.
Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem benötigten Wissen einzustellen.
Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterstützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.
Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.
Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.
Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.
Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.
Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.
Ich erinnere mich an die schöne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam für den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchführen zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.
Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.
Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:
Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.
Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erwägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.
Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.
Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.
Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,
Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am häufigsten eingesetzten Distributionen.
Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit für Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.
Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelmäßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.
In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es häufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.
Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.
Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.
In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%.
Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8.
Der Bericht von 2024 spekuliert, dass Red Hat’s Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.
Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.
Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.
Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.
Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.
Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht.
Ich freue mich darauf, diese Kategorie über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.
Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.
Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.
Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.
Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.
Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.
Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.
Bei Monitoren kann man üblicherweise über Hardwareknöpfe die Helligkeit ändern. Je nach Monitor kann es jedoch bequemer sein, die Helligkeit über eine grafische Oberfläche zu steuern. Hierfür gibt es eine handvoll Programme. DDCcontrol ist...
Ich habe euch bereits in separaten Beiträgen gezeigt, wie ihr Fractional Scaling und VRR unter Gnome aktiviert. Die beiden dort gezeigten Befehle deaktivieren aber die jeweils andere Funktion. Wenn ihr beide Optionen gleichzeitig aktivieren...
In diesem Beitrag erkläre ich kurz, was Ansible Lint ist und demonstriere dessen Anwendung am Beispiel meiner Ansible Collection tronde/nextcloud.
Er richtet sich primär an Personen, die mit Ansible Lint noch nicht vertraut sind. Linting-Profis werden vermutlich keine neuen Erkenntnisse gewinnen.
Lint (englisch für „Fussel“) ist eine Software zur statischen Code-Analyse. Davon abgeleitet hat sich das Verb linten (englisch to lint) für das Durchführen der statischen Code-Analyse etabliert.
https://de.wikipedia.org/wiki/Lint_(Programmierwerkzeug)
Dem obigen Zitat und der Projektdokumentation folgend, ist Ansible Lint dementsprechend ein Werkzeug zur statischen Code-Analyse von Ansible Playbooks, Roles und Collections. Mit der Anwendung dieses Werkzeugs auf die eigenen Ansible-Inhalte kann sichergestellt werden, dass diese gängigen Konventionen und Standards entsprechen.
Die Dokumentation beschreibt verschiedene Installationsverfahren. Ich habe ansible-lint als Bestandteil der Ansible Development Tools (ADT) installiert. Dies ist ein Werkzeugkasten mit weiteren Programmen wie z.B. `ansible-core` und Ansible Molecule, welche ich für die Entwicklung meiner Ansible Collection nutze.
Auf meiner Fedora Workstation habe ich die ADT wie folgt installiert:
~]$ mkdir venv
~]$ cd venv
venv]$ ]$ python -m venv adt
venv]$ source adt/bin/activate
(adt) venv]$ pip install pip --upgrade
Requirement already satisfied: pip in ./adt/lib64/python3.12/site-packages (23.3.2)
Collecting pip
Using cached pip-24.2-py3-none-any.whl.metadata (3.6 kB)
Using cached pip-24.2-py3-none-any.whl (1.8 MB)
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 23.3.2
Uninstalling pip-23.3.2:
Successfully uninstalled pip-23.3.2
Successfully installed pip-24.2
(adt) venv]$ pip install ansible-dev-tools
Collecting ansible-dev-tools
Using cached ansible_dev_tools-24.7.2-py3-none-any.whl.metadata (11 kB)
… Ausgabe gekürzt
(adt) venv]$ adt --version
ansible-builder 3.1.0
ansible-core 2.17.3
ansible-creator 24.7.1
ansible-dev-environment 24.7.0
ansible-dev-tools 24.7.2
ansible-lint 24.7.0
ansible-navigator 24.8.0
ansible-sign 0.1.1
molecule 24.8.0
pytest-ansible 24.8.0
tox-ansible 24.8.0Ansible Lint liefert eine ganze Reihe von Profilen mit, welche Autoren unterstützen, die Code-Qualität schrittweise zu verbessern. Der Befehl ansible-lint --list-profiles gibt die verfügbaren Profile mit einer Beschreibung aus.
Ich werde im Folgenden mit dem Profil shared arbeiten, welches für Autoren gedacht ist, die ihre Collection auf https://galaxy.ansible.com veröffentlichen möchten.
Bevor es zur Sache geht, wechsel ich in das Projektverzeichnis meiner Ansible Collection und erstelle einen neuen Branch, mit dem Befehl git checkout -b lint. Die in meinem Repo vorhandene Datei .ansible-lint-ignore lösche ich, da ich im folgenden alle Fehler und Regelverstöße sehen möchte. Zu Beginn stellt sich mein Arbeitsverzeichnis wie folgt dar:
(adt) nextcloud]$ git status
On branch lint
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
deleted: .ansible-lint-ignore
no changes added to commit (use "git add" and/or "git commit -a")Das Programm ansible-lint besitzt mit der Option --fix die Fähigkeit, Fehler automatisch zu korrigieren und auch YAML-Dateien neu zu formatieren. Der folgende Code-Block umfasst die gekürzte Ausgabe, wenn das Kommando ansible-lint --profile=shared --fix im Arbeitsverzeichnis ausgeführt wird.
(adt) nextcloud]$ ansible-lint --profile=shared --fix
WARNING Listing 37 violation(s) that are fatal
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.
galaxy.yml:1
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4
…
risky-file-permissions: File permissions unset or incorrect.
roles/backup_restore_nextcloud/tasks/main.yml:18 Task/Handler: Copy backup files to container host
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:40 Task/Handler: Import tarball contents into an existing podman volume
no-changed-when: Commands should not change things if nothing needs doing.
roles/backup_restore_nextcloud/tasks/main.yml:54 Task/Handler: Export podman volumes to tarballs
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (MYSQL_DATABASE) (vars: MYSQL_DATABASE)
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml:13
…
Read documentation for instructions on how to ignore specific rule violations.
Modified 6 files.
Rule Violation Summary
count tag profile rule associated tags
33 var-naming[pattern] basic idiom
1 risky-file-permissions safety unpredictability
1 galaxy[no-changelog] shared metadata
2 no-changed-when shared command-shell, idempotency
Failed: 37 failure(s), 0 warning(s) on 25 files. Profile 'shared' was required, but 'min' profile passed.Obige Ausgabe:
galaxy[no-changelog]: No changelog found. Please add a changelog file. Refer to the galaxy.md file for more info.risky-file-permissions: File permissions unset or incorrect.no-changed-when: Commands should not change things if nothing needs doing.var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.ansible-lint Änderungen an 6 Dateien vorgenommen hatMit git diff verschaffe ich mir einen Überblick, welche Änderungen ansible-lint vorgenommen hat. Dies sind in meinem Fall:
Als Nächstes sehe ich mir die übrigen Fehler der Reihe nach an. Die Dokumentation beinhaltet eine Übersicht mit Beschreibungen der einzelnen Regeln. Dies ist nützlich, wenn der kurze Text in der Ausgabe von ansible-lint nicht ausreichend ist.
galaxy[no-changelog]: No changelog found. Please add a changelog file.Unter Galaxy: Changelog Details finden sich Hinweise, wie dieser Fehler zu beheben ist. Ich erstelle die leere Datei CHANGELOG.md im Wurzelverzeichnis meiner Collection und der Fehler ist abgestellt.
Natürlich werde ich diese Datei zukünftig nutzen, um die wichtigsten Änderungen zu dokumentieren. ;-)
risky-file-permissions: File permissions unset or incorrect.Auch hier habe ich kurz in der Dokumentation unter risky-file-permissions nachgesehen. Den Fehler habe ich abgestellt, indem ich den Parameter mode: 0600 zum Task hinzugefügt habe.
Dies war ein Flüchtigkeitsfehler, wie er häufig passieren kann, wenn man seinen Code nicht konsequent überprüft. Ohne den Dateimode explizit zu setzen, kann dies zu unvorhersehbaren bzw. überraschenden Verhalten führen.
no-changed-when: Commands should not change things if nothing needs doing.An zwei Stellen bin ich leider nicht herumgekommen, das ansible.builtin.command Modul zu verwenden, da kein natives Modul für diese Aufgabe existiert. Betrachtet man sich die beiden Tasks fällt auf, dass diese jedes Mal Daten verarbeiten werden. Sie sind nicht idempotent. Im Ergebnis können sie erfolgreich sein oder fehlschlagen, aber sie werden immer Daten verarbeiten und dadurch ändern.
41 - name: Import tarball contents into an existing podman volume
42 ansible.builtin.command:
43 cmd: |
44 podman volume import
45 {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
46 loop:
47 - "{{ NC_HTML }}"
48 - "{{ NC_APPS }}"
49 - "{{ NC_CONFIG }}"
50 - "{{ NC_DATA }}"
51 - "{{ MYSQL_DATA }}"
52
53 # I need to use the command module as the volume module lacks the functionality
54 # to export podman volumes.
55 - name: Export podman volumes to tarballs
56 ansible.builtin.command:
57 cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
58 loop:
59 - "{{ NC_HTML }}"
60 - "{{ NC_APPS }}"
61 - "{{ NC_CONFIG }}"
62 - "{{ NC_DATA }}"
63 - "{{ MYSQL_DATA }}"
64 tags:
65 - never
66 - backupUm herauszufinden, wie ich ansible-lint zufriedenstellen kann, schaue ich wieder in der Doku unter no-changed-when nach. Nach der dortigen Beschreibung ist mein Fehler, dass ich den Rückgabewert des Kommandos nicht behandel. Daher registriere ich nun eine Variable je Task, die die Task-Ausgabe aufnimmt und prüfe den Rückgabewert. Ist der Rückgabewert gleich 0 wird der Task-Status auf changed gesetzt, ist der Rückgabewert ungleich 0 wird der Status entsprechend auf failed gesetzt. Das ganze sieht nun wie folgt aus:
41 - name: Import tarball contents into an existing podman volume
42 ansible.builtin.command:
43 cmd: |
44 podman volume import
45 {{ item }} {{ backup_restore_nextcloud_import_path }}/{{ item }}.tar
46 register: __import_tar_output
47 changed_when: __import_tar_output.rc == 0
48 failed_when: __import_tar_output.rc != 0
49 loop:
50 - "{{ NC_HTML }}"
51 - "{{ NC_APPS }}"
52 - "{{ NC_CONFIG }}"
53 - "{{ NC_DATA }}"
54 - "{{ MYSQL_DATA }}"
55
56 # I need to use the command module as the volume module lacks the functionality
57 # to export podman volumes.
58 - name: Export podman volumes to tarballs
59 ansible.builtin.command:
60 cmd: podman volume export {{ item }} --output {{ backup_restore_nextcloud_export_path }}/{{ item }}.tar
61 register: __import_tar_output
62 changed_when: __import_tar_output.rc == 0
63 failed_when: __import_tar_output.rc != 0
64 loop:
65 - "{{ NC_HTML }}"
66 - "{{ NC_APPS }}"
67 - "{{ NC_CONFIG }}"
68 - "{{ NC_DATA }}"
69 - "{{ MYSQL_DATA }}"
70 tags:
71 - never
72 - backupCollection-intern verwendete Variablen leite ich mit zwei Unterstrichen (‚_‘) ein, um mir zu verdeutlichen, dass diese nicht durch den Nutzer gesetzt werden und daher auch nicht im README.md oder defaults/main.yml dokumentiert sind.
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex.Hier brauche ich nicht weiter nachzuschlagen. Ich verstoße gegen diese Regel, da ich meine Variablen-Namen großgeschrieben habe. Die Ausgabe von ansible-lint zeigt dies deutlich:
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML)
roles/backup_restore_nextcloud/defaults/main.yml:4Diese Meldungen lassen sich mit folgendem Bash-Einzeiler abstellen:
$ for text in $(cut -d':' -f 1 roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml | grep -v '^$\|^#\|---'); do find roles -type f -iname "*.yml" | xargs sed -i -e "s/$text/\L&/g"; doneAus verschiedenen Gründen hebe ich mir die Überarbeitung für später auf und nutze die Meldung, um zu demonstrieren, wie man ansible-lint dazu bringt, bestimmte Fehler zu ignorieren.
Um Regeln für ausgewählte Dateien zu ignorieren, spezifiziert man den jeweiligen Dateinamen und den Namen der Regel in der Datei .ansible-lint-ignore, welche im Wurzelverzeichnis der Collection erstellt wird:
nextcloud]$ cat .ansible-lint-ignore
roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml var-naming[pattern]
roles/backup_restore_nextcloud/defaults/main.yml var-naming[pattern]Damit habe ich alle Probleme, die im ersten Durchlauf von ansible-lint gefunden wurden, adressiert. Ein zweiter Durchlauf zeigt das Ergebnis meiner Arbeit:
(adt) nextcloud]$ ansible-lint --profile=shared
WARNING Listing 33 violation(s) marked as ignored, likely already known
var-naming[pattern]: Variables names should match ^[a-z_][a-z0-9_]*$ regex. (NC_HTML) (vars: NC_HTML) (warning) # ignored
roles/backup_restore_nextcloud/defaults/main.yml:4
…Ausgabe gekürzt
WARNING Listing 1 violation(s) that are fatal
yaml[octal-values]: Forbidden implicit octal value "0600"
roles/backup_restore_nextcloud/tasks/main.yml:22
Read documentation for instructions on how to ignore specific rule violations.
Rule Violation Summary
count tag profile rule associated tags
1 yaml[octal-values] basic formatting, yaml
Failed: 1 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'min' profile passed.Die ignorierten Regelverstöße werden als Warnung weiterhin ausgegeben, nehmen jedoch keinen Einfluss auf die abschließende Bewertung. Dafür habe ich einen neuen Fehler (yaml[octal-values]) eingebaut. Nach dem aktuellen Regelwerk erfordern oktale Werte ein explizites Quoting, um als Strings verarbeitet zu werden.
Nachdem ich das Problem mit mode: '0600' behoben habe, endet ein weiterer Lauf von ansible-lint schlussendlich mit:
Passed: 0 failure(s), 33 warning(s) on 27 files. Profile 'shared' was required, but 'production' profile passed.Damit erfüllt meine Collection aktuell sogar die Anforderungen des nächst höheren Profils production; allerdings nur, weil ich einige Regeln bewusst ignoriere. Daher ist aktuell noch nicht sichergestellt, dass meine Collection tatsächlich bei einem Import auf Ansible Galaxy akzeptiert wird.
Ich persönlich führe ansible-lint gern in einem eigenständigen Schritt aus. Es besteht jedoch auch die Möglichkeit, dies in den verwendeten Editor, die genutzte IDE oder Molecule zu integrieren und bei Änderungen automatisch laufen zu lassen.
Ich freue mich, wenn euch dieser Artikel gefallen hat.
Gnome unterstützt seit Version 46 Variable refresh rate (VRR). Ich habe mir kürzlich einen neuen Monitor gekauft, welcher VRR unterstützt. VRR ist standardmäßig nicht unter Gnome aktiviert und muss per Terminal zuerst aktivieren werden....
Der TS101 lässt sich, wie auch der Pinecil v2, mit einem eigenen Bootlogo versehen. Beim TS101 muss das Logo der IronOS Firmwaredatei hinzugefügt werden # Arch Linux sudo pacman -S python-pillow python-intelhex git #...
Dies ist ein Erfahrungsbericht zur Migration meiner Ansible-Rolle „Nextcloud im Container“ in eine Ansible Collection. Er umfasst die Migration der bestehenden Rolle und die Ergänzung der neuen Collection um eine weitere Rolle, welche sich um die Aufgaben Backup und Restore kümmert.
Wer es ganz eilig hat, kann direkt zur Zusammenfassung springen. Allen anderen wünsche ich viel Spaß bei der Lektüre.
Für grundlegende Informationen zu Ansible Collections siehe:
Randnotiz: Dass ihr zu meiner ersten Ansible Collection hier im Blog nicht fündig werdet, liegt darin begründet, dass meine Arbeit daran eingeschlafen ist.
Die Entwicklung der hier beschriebenen Collection könnt ihr auf Codeberg.org verfolgen. Die Repo-URL lautet: https://codeberg.org/Tronde/nextcloud
Für mein Wochenendprojekt „Nextcloud im Container“ habe ich eine Ansible-Rolle entwickelt und auf Github veröffentlicht, die dem Zweck dient, Nextcloud mit einer MariaDB in einer rootless Podman-Umgebung zu installieren.
Wie ihr in Teil 5 der Artikel-Serie nachlesen könnt, war ich mit der Lösung für Backup und Restore nicht ganz zufrieden. Ich möchte dieses Thema erneut angehen und mithilfe einer Ansible-Rolle lösen.
Backup und Restore beschreiben jedoch andere Anwendungsfälle als die Bereitstellung, weswegen ich den dafür notwendigen Quelltext nicht mit in die bestehende Rolle pressen möchte. Da Backup und Restore für mich jedoch zum Betrieb dazugehören, möchte ich alle Ansible-Rollen, die ich zum Betrieb meines Nextcloud-Setups benötige, in einer Collection zusammenfassen.
Ich orientiere mich hierzu an der englischsprachigen Dokumentation „Migrating a role to a collection“. Da ich bereits einen Galaxy Namespace besitze, nutze ich diesen auch für die Erstellung der Collection. Der folgende Codeblock zeigt die verwendeten Befehle.
]$ ansible-galaxy collection init tronde.nextcloud
- Collection tronde.nextcloud was created successfully
]$ mkdir tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod && rsync -a ../roles/ansible_role_deploy_nextcloud_with_mariadb_pod/ tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/
]$ tree -L 3 tronde/nextcloud/
tronde/nextcloud/
├── docs
├── galaxy.yml
├── meta
│ └── runtime.yml
├── plugins
│ └── README.md
├── README.md
└── roles
└── deploy_nextcloud_with_mariadb_pod
├── defaults
├── meta
├── README.md
├── tasks
├── tests
└── vars
]$ rm -rf tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/.gitIm letzten Schritt entferne ich das .git-Verzeichnis, da ich die Collection als Ganzes in einem Repository verwalten möchte, statt alle Rollen einzeln zu versionieren und dann in die Collection einzufügen.
Anschließend aktualisiere ich die Dateien galaxy.yml und README.md. In der Rolle habe ich ein Playbook zum Testen verwendet, welches im Pfad deploy_nextcloud_with_mariadb_pod/tests/test.yml liegt. Um konform mit der Struktur einer Ansible Collection zu sein, erstelle ich im Wurzelverzeichnis meiner Collection das Verzeichnis playbooks und kopiere das Test-Playbook hier hinein:
]$ tree playbooks/
playbooks/
└── deploy_nextcloud_with_mariadb_pod.ymlAn dieser Stelle halte ich zunächst inne und überlege mir, welche Tools ich noch benötige, um meine Collection entwickeln und testen zu können.
Ansible Development Tools (ADT) ist ein Projekt mit dem Ziel, einen Werkzeugkasten mit allen wichtigen Werkzeugen zur Entwicklung von Ansible Content zu bieten. Genau so etwas habe ich gesucht. Das probiere ich gleich aus.
Um mir mein System nicht zu verhunzen, installiere ich die ADT in ein Python Virtual Environment und lasse mir anzeigen, welche Werkzeuge ADT mitbringt:
]$ python -m venv adt
]$ . adt/bin/activate
(adt) ]$ pip install --upgrade pip
(adt) ]$ pip install ansible-dev-tools
(adt) ]$ pip install molecule-podman
(adt) ]$ adt --version
ansible-builder 3.1.0
ansible-core 2.17.1
ansible-creator 24.7.0
ansible-dev-environment 24.7.0
ansible-dev-tools 24.7.1
ansible-lint 24.7.0
ansible-navigator 24.7.0
ansible-sign 0.1.1
molecule 24.7.0
pytest-ansible 24.7.0
tox-ansible 24.7.0Bei molecule-podman handelt es sich um einen Molecule-Treiber, welcher benötigt wird um Molecule-Tests in Podman-Containern ausführen zu können. Ich habe dieses Paket mitinstalliert, da ich mir vorstellen kann, dies in naher Zukunft zu nutzen.
Ansible Lint ist das erste Werkzeug aus der ADT-Sammlung, welches ich verwende, um den Quelltext meiner Collection zu prüfen. Dazu wird das Kommando einfach im Wurzelverzeichnis der Collection ausgeführt. Anschließend können die gefundenen Fehler behoben werden.
Da es den Rahmen dieses Artikels sprengen würde, werde ich dem Thema einen eigenen Text widmen.
Ansible Molecule eignet sich zum Testen von Ansible-Rollen und Collections. Ich nutze meine Ansible Collection, um mich mit diesem Werkzeug vertraut zu machen.
Zwar gibt es auch hier erst eine Lernkurve, doch wird mir eine durchdachte Test-Konfiguration bei der weiteren Entwicklung sicher zugutekommen. Ich orientiere mich zu Beginn am Ansible Molecule Getting Started Guide.
Zu Beginn möchte ich meine in die Collection migrierte Rolle testen. Dazu bearbeite ich die Datei tronde/nextcloud/extensions/molecule/default/converge.yml. Sie enthält schließlich folgenden Inhalt:
extensions]$ cat molecule/default/converge.yml
---
- name: Converge
hosts: localhost
gather_facts: false
tasks:
- name: Test collection role deploy_nextcloud_with_mariadb_pod
ansible.builtin.import_role:
name: tronde.nextcloud.deploy_nextcloud_with_mariadb_podUnd mit folgendem Befehl teste ich, ob meine Nextcloud-Instanz erfolgreich deployt wird:
extensions]$ molecule converge
…
PLAY RECAP *********************************************************************
localhost : ok=10 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
extensions]$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
48438d1bd884 quay.io/centos/centos:stream8 bash -c while tru... 7 minutes ago Up 7 minutes instance
104c525a6b50 localhost/podman-pause:5.1.1-1717459200 About a minute ago Up About a minute 127.0.0.1:40671->80/tcp e34ddf4d4203-infra
f27842b12d56 docker.io/library/mariadb:10.11.2 mariadbd About a minute ago Up About a minute 127.0.0.1:40671->80/tcp nc_mariadb
9ee391a57fbd docker.io/library/nextcloud:25-apache apache2-foregroun... 13 seconds ago Up 13 seconds 127.0.0.1:40671->80/tcp nextcloudDas Ergebnis ist positiv und kann durch Aufruf von http://127.0.0.1:40671 im Webbrowser überprüft werden. Ein Login mit den Default-Werten aus tronde/nextcloud/roles/deploy_nextcloud_with_mariadb_pod/defaults/main.yml bestätigt das erfolgreiche Deployment.
Es handelt sich hierbei noch nicht um ein adäquates Test-Setup; doch für den Moment ist es ausreichend. Ich werde mich noch weiter einarbeiten müssen, um das Test-Setup verbessern zu können. Vermutlich wird auch dazu dann ein weiterer Artikel folgen.
Falls sich jemand wundert, es ist durchaus Absicht, dass die Nextcloud nur via 127.0.0.1 und per HTTP erreichbar ist. Ich betreibe diese hinter einem Reverse-Proxy. Details können in Nextcloud im Container — Teil 3: Mit Reverse-Proxy nachgelesen werden.
Um die Konfiguration und die in der Nextcloud gespeicherten Daten sichern und wiederherstellen zu können, werde ich eine Offline-Sicherung der verwendeten Podman Volumes durchführen. Der Ablauf für die Sicherung sieht wie folgt aus:
Die Wiederherstellung läuft sinngemäß andersherum ab:
nc_pod wird wieder gestartetUm diese neue Rolle der Collection hinzuzufügen, navigiere ich in das Rollenverzeichnis tronde/nextcloud/roles/ und erstelle dort das Grundgerüst für die Rolle: ansible-galaxy role init backup_nextcloud
Die Struktur sieht bei mir wie folgt aus, wobei nicht benötigte Verzeichnisse noch nicht entfernt wurden:
ansible_collections]$ tree -L 2 tronde/nextcloud/roles/backup_restore_nextcloud/
tronde/nextcloud/roles/backup_restore_nextcloud/
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
9 directories, 8 filesDen aktuellen Entwicklungsstand könnt ihr unter dieser URL einsehen: https://codeberg.org/Tronde/nextcloud/src/branch/main/roles/backup_restore_nextcloud
Das dortige README.md enthält wie bei dedizierten Rollen die Dokumentation zu dieser Rolle. Um doppelte Texte zu vermeiden, verweise ich im Collection-README auf die jeweiligen README-Dateien in den einzelnen Rollen.
Getestet wird diese Rolle ebenfalls mit Molecule. Zu den Tests mit Molecule werde ich noch mehr schreiben, sobald ich dies etwas verfeinert habe.
Fallen mir noch weitere Anwendungsfälle ein, können diese nun einfach als weitere Rollen der Collection hinzugefügt werden.
Jede Rolle in dieser Collection ist für sich alleine nutzbar. Somit definiert jede Rolle die Eingangs-Variablen in der defaults/main.yml der jeweiligen Rolle.
Bei der Entwicklung achte ich darauf, dass Variablen, die z.B. den Namen eines Podman Volumes enthalten, in allen Rollen gleich geschrieben werden. Damit ist es möglich, diese Variablen an anderer Stelle zu definieren und in den verschiedenen Rollen nutzbar zu machen. So können an individuelle Deployments angepasste Variablen in Playbooks, group_vars, host_vars, etc. definiert werden.
Wo Variablen definiert werden können und welche Präzedenz diese besitzen, kann in der offiziellen Doku nachgelesen werden: Variable precedence: Where should I put a variable?
Eine Ansible-Rolle ohne Plug-ins in eine Ansible Collection zu überführen, ist mit dem kurzen Abschnitt aus der Dokumentation schnell erledigt.
Weitere Rollen können der Collection hinzugefügt werden, indem man sie im Verzeichnis roles der Collection-Verzeichnisstruktur wie gewohnt mit ansible-galaxy role init <Rollenname> erstellt und mit Leben füllt. Sorgfalt ist und bleibt bei der Benennung von Variablen und deren Präzedenz geboten, um nicht wahnsinnig zu werden. Dies ist nicht wirklich schwierig, doch muss ich fast jedes Mal in der Dokumentation nachschlagen, um sicher zu sein.
Die Ansible Development Tools (ADT) sind eine praktische Sammlung von Werkzeugen zur Entwicklung von Rollen und Collections für Ansible. Für mich sind aktuell Ansible Lint und Ansible Molecule die wichtigsten Werkzeuge aus dieser Sammlung. Wobei gerade die Dokumentation von Molecule auf dem Weg zu meinem Ziel, nämlich meine Collections in verschiedenen rootless Podman Containern mit nested Podman und Ansible zu testen, leider viele Fragen offen lässt. Grundsätzlich lassen sich Testpläne damit realisieren und vereinfachen mein bisheriges Testsetup bestehend aus diversen Skripts und virtuellen Maschinen. Und sie bieten Stoff für weitere Einträge in diesem Blog.
Die weitere Entwicklung meiner Nextcloud Collection findet auf Codeberg statt. Ihr findet sie dort unter der URL: https://codeberg.org/Tronde/nextcloud
Vor einigen Wochen habe ich um Empfehlungen für Laptop-Hardware, eine Linux-Distribution und eine Desktopumgebung gebeten. Für die vielen Rückmeldungen, die ich erhalten habe, an dieser Stelle vielen Dank.
Heute möchte ich euch wissen lassen, welche Kombination es geworden ist.
Ich habe mich für ein wiederaufbereitetes Lenovo T570 entschieden, welches für günstige 240 Euro im Onlinehandel verfügbar war. Da war dann auch noch für 30 Euro ein Schutzbrief drin, der Flüssigkeiten und Stürze abdeckt.
Mit dem Intel Core-i5 der 6. Generation, 8 GB RAM und einer 256 GB SSD bietet dieses Gerät mehr als ausreichend Leistung.
Das Gerät weist einige Gebrauchsspuren auf. Den Preis empfinde ich dennoch günstig, da Geräte dieser Klasse nicht unter 1.000 Euro Neupreis zu bekommen sind. Viel wichtiger jedoch ist, dass der Nutzer sich ebenfalls über das Gerät freut.
Wer die Wahl hat, hat die Qual. Um mir einen ersten Eindruck zu verschaffen, habe ich mir einen USB-Stick mit Ventoy und einer Auswahl an verschiedenen Linux-Distributionen erstellt. So konnte ich die verschiedenen Live-Systeme booten und prüfen, ob alles funktioniert und wie es sich in der Oberfläche navigieren lässt.
Schlussendlich habe ich mich für Debian Cinnamon entschieden. Dies machte nach dem ersten kurzen Test insgesamt den besten Eindruck. Firefox, Thunderbird, Bookmarks, Desktop-Verknüpfungen und Zoom-Client waren schnell eingerichtet und das Gerät bereit zur Übergabe.
Mit der Übergabe gab es eine kurze Einweisung in das Gerät:
So reibungslos hat das bisher noch nie geklappt. Die Nutzungserfahrung ist positiv. Wir freuen uns.
Ende 2021 bin ich von einem Raspberry Pi 4 mit 4 GB auf einen Intel NUC7PJYH mit Proxmox VE umgestiegen. Hauptgrund damals war, dass bei mir das Upgrade von Raspberry Pi OS 10 auf...
Die Entwickler von Immich haben nach der Kritik bzgl. der „Unlicensed“ Meldung nachgebessert und die Meldung heißt nun „Buy Immich“. Wie zuvor wird diese Meldung unten links angezeigt. Nach einem Klick auf die Meldung...
Mit der Veröffentlichung von Immich v1.109.0 haben die Entwickler optionale Lizenzen angekündigt. Man bekommt nun unten links angezeigt, dass man eine unlizenzierte Version einsetzt, sofern man keine Lizenz gekauft hat. Nachfolgend beide Lizenzoptionen und...
Das mit Firefox 128 und der „Privacy Preserving Attribution“ (PPA) Funktion dürften die meisten mitbekommen haben. Ich zeige euch in diesen Beitrag, wie ihr die PPA Funktion unter Linux, Windows, macOS und Android deaktivieren...
Seit Firefox 127 kann man sich das Wetter auf der Startseite anzeigen lassen. Startet euren Firefox, gebt in der Adresszeile about:config ein und bestätigt die Warnung. Sucht nach browser.newtabpage.activity-stream.system.showWeather und stellt den Wert mit...
Liebe Leser*innen,
heute seid ihr gefragt. Denn ich möchte von euch wissen, welchen Laptop und welche Linux-Distribution, ihr für ältere, nicht EDV-affine Menschen und Windows-Umsteiger empfehlen könnt.
Der Laptop soll über folgende Merkmale verfügen:
Die Unterstützung von Linux und Windows ist sehr wichtig. Sollte der Feldversuch mit Linux scheitern, möchte auf der gleichen Hardware ein aktuelles Windows-Betriebssystem installieren können.
Mir schwebt etwas in der Richtung der Lenovo IdeaPad oder ein ThinkPad der L-Serie vor, ich bin jedoch auf eure Empfehlungen gespannt.
Ich suche nach einer Desktop-Umgebung, die folgende Merkmale bietet:
Dies sind Muss-Kriterien, die unbedingt erfüllt sein müssen. Ich möchte, dass die Desktopoberfläche diese Eigenschaften in der Standardkonfiguration erfüllt und ich diese nicht erst konfigurieren oder drölfzig Plug-ins installieren muss, um diesen Zustand zu erreichen.
Die wichtigsten Anwendungen sind:
Die Linux-Distribution muss die oben genannten Anforderungen an die Desktop-Umgebung und die Software erfüllen und dabei stabil allerdings nicht steinalt sein.
Ich möchte nicht vor jeder Videokonferenz mit den Audio-Einstellungen kämpfen müssen, um deutlich zu machen, wo meine Priorität liegt.
Kandidaten, die ich mir ansehen möchte, sind:
Was könnt ihr mir empfehlen? Bitte nutzt die Kommentare und verlinkt, wo möglich zu den Projekten, die ihr empfehlt.
Wer ein GitHub Account hat, kann sich sehr einfach über neue Releases (Veröffentlichungen) von Projekten per E-Mail informieren lassen. Es benutzen aber nicht alle Projekte das „Releases“ Feature, sondern setzen stattdessen auf Git Tags....
Dies ist mein Erfahrungsbericht der Chemnitzer Linux-Tage 2024. Es war mal wieder eine sehr schöne Veranstaltung.
Im vergangenen Jahr hatte mich die Deutsche Bahn in Chemnitz sitzengelassen und ich musste mit einem kurzfristig angemieteten Leihwagen heimfahren.
Da die Deutsche Bahn und die Gewerkschaft Deutscher Lokomotivführer sich noch immer nicht auf einen neuen Tarifvertrag einigen können und ich mich nicht erneut über eine schlechte Verbindung ärgern wollte, bin ich dieses Jahr mit dem eigenen Pkw gefahren.
Am Freitag um 13:30 Uhr ging die Reise los. Mit viel Verkehr, Baustellen und Stau waren ich etwa 4,5 Stunden später im Hotel, wo ich direkt über Stoeps gestolpert bin.
Wir spazierten vom Residenz Hotel Chemnitz zum Veranstaltungsgebäude, um uns anzumelden und unsere Badges zu empfangen. Damit ersparten wir uns das Warten in der Schlange am Samstagmorgen.
Am Hörsaalgebäude traf ich schon erste vertraute Gesichter, wie z.B. Andreas, welcher fleißig beim Aufbau geholfen hat. Hier haben wir uns auch mit Michael von der Aspicon GmbH getroffen, mit dem ich für Sonntag einen Vortrag geplant hatte. Wir sind gemeinsam in die Stadt gegangen, um uns bei Speis und Trank kennenzulernen und den Abend zu verplaudern.
Um 07:00 Uhr begann ich den Tag mit dem Frühstück. So war der erste Hunger bereits gestillt, als der Frühstücksraum sich zu füllen begann. Bekannte Gesichter und nerdige T-Shirts verrieten, dass es sich bei sehr vielen der Gäste um Besucher der Chemnitzer Linux-Tage handelte.
Die 20 Minuten zum Veranstaltungsort wurden auch diesmal wieder zu Fuß zurückgelegt. Und der erste Konferenztag konnte beginnen.
Um 10:00 Uhr war ich an der Reihe und durfte in einem rappelvollen Raum V6 meinen „::1“-Vortrag halten. An dieser Stelle euch allen nochmal vielen Dank für eure Teilnahme. Ich hoffe, ihr hattet so viel Spaß wie ich und konntet ein paar neue Eindrücke gewinnen.
Es hat mich gefreut, auch nach dem Vortrag noch einige Fragen beantworten zu können und über IPv6 zu fachsimpeln. Ganz nebenbei konnte ich auch noch die Frage eines Red Hat-Kunden beantworten. Darüber freute sich dieser sehr, bleibt ihm der Support eine zufriedenstellende Antwort doch seit langer Zeit schuldig. Es ist halt stets eine gute Erfahrung, einen TAM zu treffen.
Die Chemnitzer Linux-Tage gibt es übrigens schon seit 25 Jahren. Da eine Veranstaltung aufgrund der Pandemie ausfallen musste, findet die 25. Veranstaltung allerdings erst im nächsten Jahr am 22. und 23. März statt.
20-jähriges Jubiläum feiert in diesem Jahr Ubuntu, weshalb der Community-Stand dieses Jahr besonders schön geschmückt war und toddy mehrfach mit Luftschlangen gefesselt wurde.
Ich genieße die Zeit unter gleichgesinnten Nerds oder wie Stoeps es ausdrückte: „Endlich wieder unter normalen Menschen“. Mich hat es dieses Jahr sehr gefreut, auch viele jüngere Gesichter zu sehen. So sehr ich mich freue, auch die gleichen alten Nasen immer wiederzutreffen ist es doch schön, dass die Gemeinschaft nicht einfach alt wird, sondern auch junge Menschen mit Interesse, Motivation und Freude an Open Source nachwachsen.
Da die Hörsäle hier bei den Vorträgen meist aus allen Nähten platzen, hatte ich mich im Vorfeld als Sessionleitung für die drei Vorträge
gemeldet. So war mir ein guter Platz im Raum sicher. Ich danke den drei Referenten für ihre interessanten Vorträge.
Am Abend waren alle Aussteller, Helfer und Referenten zum gemütlichen Beisammensein in die Mensa eingeladen, welche schräg gegenüber dem Veranstaltungsgebäude liegt. Hier gab es ein reichhaltiges Angebot an warmem und kaltem Essen sowie eine Auswahl verschiedenster Getränke. Vielleicht ist es in der Zukunft möglich, die Getränke zu kühlen. Dann wird das Bier nicht so schnell warm und schmeckt länger gut.
Ich schätze es sehr, mich auf Konferenzen mit alten und neuen Bekannten auszutauschen, zu fachsimpeln und ganz allgemein angeregte Gespräche zu führen. Das musikalische Rahmenprogramm traf auch in diesem Jahr nicht meinen Geschmack. Ich würde mir etwas Hintergrundberieselung wünschen, um sich gut unterhalten zu können. Doch sind Geschmäcker verschieden und ich erkenne durchaus an, was das Organisations-Team der Chemnitzer Linux-Tage hier Jahr für Jahr auf die Beine stellt. Euch allen vielen Dank für euren unermüdlichen Einsatz.
Nach einem frühen Frühstück und Check-out ging es heute mit dem Auto zum Veranstaltungsgelände. Noch vor dem zweiten Kaffee wurden hier die Folien für den nächsten Vortrag nochmal geprüft. Um 10:00 Uhr war es wieder soweit. Diesmal durfte ich zusammen mit Michael den Vortrag „Mit Ansible Collections & Workflows gegen das Playbook-Chaos“ halten.
@Michael: „Es hat mir gut gefallen, mit dir einen Vortrag zu halten. Das können wir gerne wiederholen.“
Beim Mittagessen habe ich dann auch noch Christian getroffen. Für ihn waren es die ersten Chemnitzer Linux-Tage und auch ihm haben sie sehr gut gefallen.
Und wie immer war die Zeit auch viel zu schnell wieder vorbei. So habe ich Henning zwar kurz gesehen, doch für mehr als ein kurzes „Hi und Tschüss, bis zum nächsten Mal“ reichte es diesmal leider nicht.
Auch die schönsten Chemnitzer Linux-Tage gehen vorbei. Doch im Auto sitzend freute ich mich auch schon darauf, meine Familie wiederzusehen. Die Straße war frei und nach nur 3 Stunden 20 Minuten war ich wieder daheim. Zum Vergleich, mit der Bahn wäre ich je nach Verbindung erst nach 5,5-6,5 Stunden daheim gewesen, wenn alles nach Plan fährt.
So konnte ich mehr Zeit vor Ort verbringen und war rechtzeitig daheim, um noch etwas Zeit mit meinem Sohn zu verbringen, bevor dieser ins Bett ging.
Es war schön. Ich hoffe, ihr seid alle wieder gut heimgekommen und behaltet auch diese Chemnitzer Linux-Tage in guter Erinnerung.
