staging.inyokaproject.org

2022 Woche 08

27. Februar 2022

Das finnische Unternehmen Jolla geriet 2015 in massive finanzielle Schwierigkeiten und wurde maßgeblich durch eine enge Kooperation mit russischen (Staats-)Unternehmen gerettet. Wie geht es da jetzt eigentlich angesichts massiver Sanktionen gegen Russland weiter? Nur Fragen, keine Antworten.

Ich hatte mich in diesem Blog in zwei Artikeln mit der nicht sehr transparenten Finanzierungsstruktur hinter Jolla befasst:

Ein der wenigen offiziell von Jolla bekannt gegebenen Investoren war Rostelecom. Eben jener Konzern steht neben vielen anderen auf einer US-Sanktionsliste, nachdem Russland seinen völkerrechtswidrigen Angriffskrieg gegen die Ukraine vom Zaun gebrochen hat. Interessant dürften ebenfalls die Beschränkungen zum Technologieexport nach Russland sein, wobei mir nicht klar ist, ob Smartphone-Betriebssysteme darunter fallen. Wobei auch unabhängig davon die engen Wirtschaftsbeziehungen zwischen Jolla und dem russischen Staat problematisch werden dürften angesichts der Sanktionen. Schließlich war die Kooperation mit Russland und die Verwendung der angepassten Sailfish-Version Aurora OS ein wichtiges Standbein für Jolla.

Ich bin gespannt ob und wenn ja wann wir offiziell etwas von Jolla dazu hören.

Der Artikel Wie geht es eigentlich weiter mit Jolla? erschien zuerst auf [Mer]Curius

Der Kern von Android ist freie Software, aber dieser Kern hat keinen App Store. Die meisten Anwender von Aftermarket-Systemen wie LineageOS oder GrapheneOS nutzen daher F-Droid, um Open Source-Apps zu beziehen. Das ist nicht unproblematisch, aber leider alternativlos.

Via Linuxnews erreichte mich heute dieser sehr lesenswerte Artikel zu den problematischen Implikationen von F-Droid für die Sicherheit von Android. Der Autor nennt einige substanzielle Probleme von F-Droid, die ich im Folgenden knapp zusammenfassen möchte. Für die ausführliche Darstellung bitte den Artikel lesen.

  • Die Probleme beginnen schon bei den Signaturen der Apps, da F-Droid alle Apps mit seinen eigenen Keys signiert. Das untergräbt den sonst verfolgten Ansatz, dass Entwickler ihre Apps selbst signieren und der Anwender dem Vertriebskanal nicht vertrauen muss.
  • Die Apps bei F-Droid müssen frei von proprietären Bibliotheken sein und unterscheiden sich deshalb von den Varianten der gleichen App, die auf anderen Wegen bezogen werden können.
  • Die Qualitätskontrollen von F-Droid sind praktisch wertlos. Ein offener Quellcode bedeutet nicht, dass die Überprüfung leicht ist.
  • Updates werden mit teils starker Verzögerung verteilt.
  • F-Droid hinkt beim API-Level hinterher, für den Apps gebaut werden, was wiederrum negativ für die Sicherheit sein kann.
  • Mehrere Repositorien in einer einzigen App widersprechen dem Android-Sicherheitsprinzip.
  • Die neue API in Android für automatische Hintergrundaktualisierungen von Apps ohne Root-Privilegien wird mit F-Droid nicht funktionieren bzw. nur mit einem „schmutzigen“ Hack.
  • Viele kleinere Probleme, die der Autor als „mangelnde gute Praxis“ beschreibt wie z. B. fehlendes Zeritfikat-Pinning oder ganz allgemein, dass Änderungen bei F-Droid erst nachvollzogen werden, wenn sie dazu durch Änderungen in der Android-Basis gezwungen werden und nicht wenn diese bereits ratsam sind.

Einige dieser Probleme wie die Updateverzögerung, die fehlende tiefgreifende Überprüfung von Anwendungen oder die Signaturproblematik könnte man auch auf Linux-Distribution übertragen, ebenso den oft unbegründete Konnex von Open Source und Sicherheit. Das ist keineswegs ein Problem, das auf Android oder F-Droid beschränkt wäre. Andere Probleme wie das fehlende tiefergehende Verständnis für Sicherheit und laxe Praktiken kann man auch bei anderen Projekten im AOSP-Umfeld wie LineageOS, XDA & Co beobachten und wurde von mir bereits mehrfach kritisiert. Ein Grund, weshalb ich inzwischen GrapheneOS nutze.

Der Autor empfiehlt als sichere Alternative den Play Store. So mancher mag da aufschreien, aber das ist eben einer dieser Bereiche, bei denen sich Datenschutz und Sicherheit in die Quere kommen. Was für die Sicherheit geboten wäre, muss nicht zwangsläufig gut für den Datenschutz sein. Deshalb finde ich persönlich den Artikel zwar interessant und bedenkenswert, aber werde trotzdem vorerst weiter an F-Droid festhalten, denn mein GrapheneOS ist frei von Play Diensten und Play Store und es gibt aktuell keinen anderen App Store außer F-Droid.

Mittelfristig interessant könnte der „App Store“ werden, den die GrapheneOS-Entwickler in der Pipeline haben.

Hier bleibt aber abzuwarten, was der alles enthalten wird und ob das ausreicht, um auf F-Droid zu verzichten.

Der Artikel F-Droid untergräbt die Sicherheit von Android erschien zuerst auf [Mer]Curius

26. Februar 2022

Es gibt viele Distributionen, aber nur wenige Distributionen mit langfristigem Support. Doch auch zwischen diesen Distributionen gibt es erhebliche Unterschiede. Der Versuch einer kleinen Einordnung.

Natürlich können Anwender genau die Distribution verwenden, die sie bevorzugen. Das kann ein Rolling Release sein oder eine Distribution mit nur kurzer Laufzeit wie Fedora oder Mageia. Die meisten Anwender machen sich aber meiner Erfahrung nach nicht so viel aus Updates, wollen über mehrere Jahre in Ruhe ihre Systeme nutzen und bekommen neue Funktionen lieber mit einem großen Schwung. Das betrifft nicht exklusiv Linux-Anwender, sondern ich erlebe das auch bei macOS-Nutzern und Windows 10-Anwendern, wo meist erst mit deutlicher Verzögerung und kurz vor Supportende einer jeweiligen Version aktualisiert wird. Das mögen nicht mehr die 10 Jahre von früher sein, aber häufiger als alle 2-3 Jahre möchten die meisten Anwender keine umstürzenden Aktualisierungen. Sie arbeiten schließlich mit den Systemen und nicht an den Systemen.

Die hier getroffenen Abwägungen haben einen Fokus auf den Sicherheitsaspekt. Wer ideologische Gesichtspunkte höher gewichtet, kann durchaus zu anderen Ergebnissen zu kommen. Grundsätzlich respektiere ich es, wenn einem dieser Aspekt nicht so wichtig ist, da Linux gegenwärtig keinem großen Schadsoftwaredruck ausgesetzt ist und längerfristig offene Sicherheitslücken mit hoher Wahrscheinlichkeit keine direkten nachteiligen Auswirkungen auf den normalen Anwender haben. Vermutlich könnte man sogar mit einer seit Längerem abgekündigten Version ohne jegliche Sicherheitsupdates noch einige Zeit problemlos auch im Internet unterwegs sein. Doch wenn man Sicherheit ernst nimmt, dann auch konsequent.

Ich habe 2015 im freien magazin mal einen Artikel zu LTS-Distributionen für den Linux-Desktop geschrieben, der die Grundlage für den hiesigen Schwerpunkt-Bereich zu Linux wurde. Erstaunlich wenig hat sich in dem Bereich seitdem getan. Allerdings würde ich das heute teilweise anders bewerten. Da aufgrund meiner Debian-Serie mich einige gefragt haben, möchte ich das hier kurz einordnen.

Folgende Reihenfolge sehe ich bei den LTS-Distributionen. Die wesentlichen Vor- und Nachteile habe ich mal aufgelistet.

1. Red Hat Enterprise Linux & Klone

Wer gerne mit der GNOME Shell arbeitet, sollte sich RHEL oder einen der freien Klone wie Alma Linux genauer ansehen. Für diese Enterprise-Distribution gibt es keine andere Desktopumgebung, deshalb ist diese Einschränkung die maßgebliche erste Abwägung, die jeder Anwender treffen muss.

Red Hat beschäftigt wohl die meisten Entwickler im Linux- und GNOME-Umfeld in einer Firma. Die Entwicklungen aus der Red Hat-Schmiede sind heute überwiegend die Quasi-Standards im Linux-Segment. Nach einem ausführlichen Test in Fedora landen diese immer in RHEL.

RHEL bietet für Anwender einige substanzielle Vorteile:

  • RHEL folgt mit Verzögerung direkt der Upstream-Entwicklung und die Wahrscheinlichkeit, in Entwicklungssackgassen zu geraten, wie dies oft bei Canonicals Eigenentwicklungen der Fall ist, sind äußerst gering. RHEL ist deshalb für seine Anwender sehr nachhaltig. Red Hat ist ebenso in der Position, in entscheidenden Momenten Einfluss auf die GNOME-Entwicklung zu nehmen, um Enterprise-Tauglichkeit herzustellen. Das hat man in der Vergangenheit beim Classic-Mode gesehen, der genau dann kam, als der Wechsel von GNOME 2 zu GNOME Shell in RHEL anstand.
  • Red Hat besitzt die Leistungsfähigkeit, um Sicherheitsprobleme schnell und konsequent zu beheben. Das gilt sowohl für die versionsstabil gehaltenen Bestandteile wie den Linux-Kernel, aber auch für die variableren Bestandteile, bei denen Red Hat durchaus mal pragmatisch Versionen anhebt, um die hohe Qualität für den Anwender zu gewährleisten.
  • Keine andere Distribution setzt das Sicherheitsframework SELinux so konsequent ein wie RHEL.

Der Einsatz von RHEL hat aber zwei substanzielle Nachteile:

  • Der Fokus liegt eindeutig auf dem Servereinsatz. Der Kernel ist daher einige Zeit nach dem Release veraltet und unterstützt moderne Desktop-Hardware unzureichend.
  • Die Paketauswahl ist auf einen klassischen Office-Desktop beschränkt und beinhaltet meist nur sehr wenige Softwarelösungen und nicht die komplette FOSS-Bandbreite. Viele Anwender setzen daher auf Drittanbieter wie EPEL mit den üblichen Folgen für die Sicherheit, da diese Drittanbieterquellen nicht im gleichen Maße gepflegt werden.

2. openSUSE Leap

Bevorzugt man einen anderen Desktop als die GNOME Shell, wäre openSUSE Leap eine Alternative. Die stabile openSUSE-Variante unterstützt alle verbreiteten Linux-Desktopumgebungen auf einer stabilen SUSE Linux Enterprise-Basis. SLE selbst bietet eigentlich nur GNOME und deshalb eigentlich keine Vorteile gegenüber RHEL und taucht deshalb nicht als eigener Eintrag in diesem Artikel auf.

Der Einsatz von openSUSE Leap hat für den Anwender gegenüber RHEL substanzielle Vorteile:

  • Die SLE-Basis wird sehr gut gepflegt und Sicherheitsaktualisierungen kommen zeitnah und umfassend.
  • Durch das leistungsfähige Entwicklerteam werden auch Bugs in der SLE-Basis sehr konsequent behoben.
  • Das openSUSE-Projekt trifft keine ideologischen Entscheidungen – weder konzeptionell noch während des Betriebs.
  • Die Paketauswahl ist deutlich größer als bei RHEL und umfasst die übliche Mainstream-Software im FOSS-Bereich.

Allerdings gibt es auch Nachteile:

  • Die Qualität der Pflege fällt von der SLE-Basis zu den Bestandteilen ab, die das openSUSE-Projekt beisteuert.
  • Der Umfang der Aktualisierungen bei den jährlichen Minor-Versionen ist schwer vorherzusagen und damit nicht gut planbar.
  • Neue Hauptversionen folgen den SLE-Hauptversionen und für diese gibt es keine langfristige Roadmap.

3. Ubuntu

Bei Ubuntu muss man differenzieren zwischen der Kerndistribution Ubuntu und den Derivaten. Die Derivate halte ich für keine empfehlenswerte LTS-Distribution, wenn der Fokus auf Sicherheit liegt, da es für diese kein Sicherheitsversprechen gibt, sondern alle Pakete in universe liegen und durch die jeweiligen Communitys höchst unterschiedlich intensiv gepflegt werden.

Wenn man aber die Hauptvariante nutzt und primär Pakete aus main nutzt, dann ist Ubuntu eine sehr gut gepflegte Distribution. Es gibt substanzielle Vorteile:

  • Planbare Releasezyklen und ein Supportversprechen für 5 Jahre ohne die Pflicht jährliche Minoraktualisierungen wie bei RHEL oder openSUSE Leap vornehmen zu müssen.
  • Halbjährlich aktuelle Kernel- und Grafikstackversionen ermöglichen den Einsatz moderner Hardware.

Folgende Nachteile gibt es:

  • Die Universe-Paketquelle ist bei Desktopinstallationen standardmäßig aktiviert. Anwender müssen hier genau prüfen, welche Pakete sie aus welcher Quelle installieren und ob es für diese Support gibt. Die beliebte Oberfläche Synaptic zeigt dies aber praktisch mit kleinen Icons an.
  • Universe ist ungepflegt und teilweise in einem extrem schlechten Zustand. Mit wachsendem zeitlichen Abstand zum Releasedatum der LTS verstärkt sich dieses Problem.
  • Canonical bzw. Ubuntu entwickeln gerne eigene Lösungen, die vom Linux (RHEL) Mainstream abweichen. Es gab in der Vergangenheit deshalb häufiger starke Brüche, bei denen Anwender sehr plötzlich mit Entwicklungen konfrontiert wurden, die bei RHEL oder openSUSE längerfristig vorbereitet wurden.

4. Debian

Kaum überraschend kommt Debian bei mir tatsächlich als letzte Distribution. Debian hat den Vorzug – im Gegensatz zu den drei oben genannten Distributionen – von keiner Firma entwickelt zu werden oder direkt von einer Firma abhängig zu sein. Damit kommt es dem FOSS-Gedanken sehr nahe, ebenso mit der konsequenten Thematisierung unfreier Bestandteile.

Es gibt durchaus Vorteile von Debian die für den Einsatz sprechen:

  • Debian ist sehr nachhaltig. Es gibt immer einen Upgradepfad und Anwender bleiben von tiefgreifenden Umbrüchen verschont.
  • Der Umfang der Paketquellen ist unübertroffen. Die direkte Notwendigkeit unsichere Fremdquellen einzubinden ist selten gegeben.

Inzwischen gibt es aber auch viele substanzielle Nachteile:

  • Die Software in den Paketquellen ist unterschiedlich gut gepflegt. In einigen Bereichen werden über viele Jahre veraltete Versionen mitgeschleppt.
  • Das Supportversprechen ist für einige Pakete über die Release Notes eingeschränkt, was sich faktisch auf weitere Pakete, die diese nutzen, auswirkt und nicht transparent gemacht wird.
  • Versionsstabilität oder Reproduzierbarkeit von Builds wird im Zweifel höher als die zeitnahe Verteilung von Sicherheitsupdates gewichtet.
  • Backports sind von Supportversprechen ausgenommen.

Der Artikel Welche Linux LTS Distribution wählen? erschien zuerst auf [Mer]Curius

23. Februar 2022

Mozilla hat Version 2.7 seiner VPN-Clients für das Mozilla VPN veröffentlicht. Dieser Artikel beschreibt die Neuerungen vom Mozilla VPN 2.7.

Mit dem Mozilla VPN bietet Mozilla in Zusammenarbeit mit Mullvad sein eigenes Virtual Private Network an und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Jetzt Mozilla VPN nutzen

Die Neuerungen vom Mozilla VPN 2.7

Multi-Hop für Android und iOS

Standardmäßig leitet das Mozilla VPN den Datenverkehr über einen Server an einem Standort. Mit dem Multi-Hop-Feature kann der Verkehr seit dem Mozilla VPN 2.5 von einem Standort über einen anderen Standort geleitet werden, quasi ein VPN nach dem VPN. Dieses Feature stand bislang nur unter Windows, MacOS und Linux zur Verfügung. Mit dem Mozilla VPN 2.7 bekommen auch Android und iOS die Möglichkeit zum Multi-Hop.

Mozilla VPN 2.7

Nach Updates suchen

Updates für das Mozilla VPN konnten bisher dann installiert werden, wenn das Mozilla VPN mitgeteilt hat, dass es ein Update gibt. Eine neue Schaltfläche im Info-Dialog erlaubt jetzt die manuelle Suche nach Updates.

Mozilla VPN 2.7

Sonstige Neuerungen

Dazu kommen diverse Fehlerbehebungen und Verbesserungen unter der Haube, die sich auf GitHub nachvollziehen lassen. Das Mozilla VPN 2.7.1 für Windows beinhaltet außerdem noch die Behebung einer Sicherheitslücke.

Der Beitrag Mozilla VPN 2.7 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

PeerTube 4.1 das Opensource Videoportal ist veröffentlicht worden.

 

Das ist an sich eine sehr tolle Nachricht. Auch dass manche Funktionen standardmäßig ausgeschaltet werden können. Wie zum Beispiel das P2P Protokoll, das die Bandbreitenlast vom anbietenden Server zwischen den KonsumentInnen aufteilen kann.

 

Was an sich eine sehr solidarische Funktion ist, ist im Gegenzug natürlich auch ein Privatsphärenproblem. Darüber sollten wir anfangen eine gesellschaftliche Diskussion zu führen, ohne dass die großen Konzerne in Altherren und -damen Manier “hörthört” grunzen.

 

Zuallererst sei vorangestellt: Privatssphäre ist wichtig! Aber darauf folgt ein sehr dickes ABER. Viele der extremen PrivatsphärenverferchterInnen blockieren mit ihrem Verhalten eine Ausbreitung des Schutzes der Privatsphäre!

 

Die Zwei Finanzierungs-Aspekte leiten mich zu dieser Aussage

  1. Die Person die Geld investiert, um diesen Service zur Verfügung zu stellen
  2. Die Person, die die Inhalte zur Verfügung stellt.

 

Wir alle haben es gerne und dankend angenommen, dass “Internet” und alle damit zusammengehörigen Dienste für die Allgemeinheit wenig bis gar nichts kostet (kostenlos). Dafür haben Konzerne neue Wege gefunden “kostenlos” so gewinnbringend zu vermarkten, dass selbst die Hölle vor Neid erblasst.

 

Übersetzt heißt das “kostenlos gewinnbringend": wir bezahlen dafür.

 

Wir bezahlen dafür vielleicht nicht direkt mit Geld, aber indirekt schon mit Geld. Es gibt genügend Beispiele die das beweisen (Schufa, Cambridge Analytica, uvm).

 

Dienste die von irgendjemand bereit gestellt werden kosten Geld. Ob diese Dienste ein laufendes System sind, oder ob diese Dienste Ergebnisse von Recherchen, oder Zusammenfassungen sind, die uns interessieren. Wir haben ein Interesse solche Dienste in Anspruch zu nehmen und es wäre extrem egozentrisch, sich auf den Standpunkt zu stellen, dass man einen kostenlosen Anspruch darauf hätte!

 

Im Gegenzug darf man sich aber auch nicht beschweren, wenn bei ausbleibendem Support der Anbieter sich eine Finanzierungsquelle sucht. Egal ob es um die Erhaltung des Dienstes, oder eine Gewinnerzielungsabsicht trägt. Eine Diskussion darum ist eine reine Neiddebatte, die es nicht gäbe, wenn wir so einen Dienst überhaupt nicht wollten.

 

Daher mein Aufruf an alle PrivatspährennutzerInnen: Wenn ihr Dienste in Anspruch nehmt, die die Privatspähre schützen wollen, dann sehr euch auch in der Pflicht etwas dafür zu tun. Das heißt nicht immer Geld. Aber das heisst IMMER bezahlen.

Das umschließt auch die sogenannten Datenkraken, bei denen ebenso von ContentanbieterInnen konsumiert wird. Dort ist das Zahlungsmittel Likes, Abos und vor allem Kommentare. Der Algorithmus ist das Transaktionssystem!

 

Wenn ihr als PrivatspährennutzerInnen also den Menschen nicht schaden wollt, die für euch wichtige oder interessanten Dienste oder Content zur Verfügung stellen, dann seid fair und beraubt sie nicht, um das finanzielle Fundament, dass das erst möglich macht!

 

#FairShare

Hier der Link zur Veröffentlichung: https://joinpeertube.org/en_US/news#release-4.1

 

 

 

22. Februar 2022

Di, 22. Februar 2022, Lioh Möller

Nach über zwei Jahren Entwicklungszeit konnte Tomas Matejicek eine neue Version der Live-Distribution Slax veröffentlichen.

Ursprünglich basierte Slax, wie der Name nahelegen kann, auf Slackware. 2017 entschied sich der Entwickler jedoch auf Debian GNU/Linux als Basis zu wechseln.

Slax ist primär zur Nutzung als Live-System geeignet, unterscheidet sich jedoch von vielen anderen Distribution dadurch, dass mittels aufs eine Persistenz realisiert wurde.

Letzteres erwies sich bei der Portierung auf die aktuelle Debian 11 Version (Codename Bullseye) allerdings als grössere Hürde, da Debian standardmässig nur noch overlayfs unterstützt.

Erste Versuche mit overlayfs zeigten jedoch, dass ich damit nicht ohne weiteres der von Slax gewohnte Komfort, wie das automatische Applizieren von Änderungen, realisieren lies.

Dies bewog Tomas dazu einen eigenen angepassten Kernel mit aufs Unterstützung zu verwenden.

Darüber hinaus wird Chromium nicht mehr standardmässig ausgeliefert, lässt sich allerdings weiterhin mit wenigen Klicks installieren.

Zur Netzwerkverwaltung kommt neu connman statt wicd zum Einsatz und scite ist der Standard-Texteditor.

Changelog: https://www.slax.org/changelog.php

Di, 22. Februar 2022, Lioh Möller

Die Slackware Distribution unterstützt schon seit einiger Zeit die Installation auf EFI-basierten Systemen mithilfe des Installationsprogramms. Die Einrichtung einer verschlüsselten Partition ist allerdings eine manuelle Vorbereitung notwendig.

Nach dem Start von dem Installationsmedium in UEFI-Modus sollte zunächst das Tastaturlayout definiert werden.


In der Konsole kann daraufhin die Festplatte partitioniert werden. Im Folgenden gehen wir davon aus, dass die gesamte Festplatte für die Slackware Installation zur Verfügung steht.

Zur Erstellung des Partitionslayouts kann cfdisk verwendet werden, welches initial mit der Option -z gestartet werden sollte. Die Device-Nodes müssen dabei an die lokalen Gegebenheiten angepasst werden.

cfdisk -z /dev/sda

Als Partitionslabel sollte gpt gewählt werden.

Zunächst wird eine unverschlüsselte EFI Boot-Partition mit einer empfohlenen Grösse von 512MB erstellt.

Im verbleibenden Speicherplatz wird eine Partition des Typs Linux LVM angelegt.

Nach dem Speichern der Änderungen kann cfdisk verlassen werden.

Nun erfolgt die eigentliche LUKS-Einrichtung.

Zunächst wird die Partition entsprechend formatiert. Während des Systemstarts wird standardmässig das US-Tastaturlayout verwendet. Daher sollte zu diesem Zeitpunkt ein Passwort verwendet werden, welches auch mit diesem Layout gut zu nutzen ist.

Alternativ kann eine angepasste initrd mithilfe von mkinitrd und der Angabe des Parameters -l KeyboardLayout erstellt werden. Beispiel -l sg-latin1 für Schweizerdeutsch.

cryptsetup luksFormat /dev/sda2

Dies muss durch die Eingabe von YES bestätigt werden

Daraufhin lässt sich das Volumen wie folgt öffnen:

cryptsetup open /dev/sda2 slackware

In diesem können nun die Logical Volumes erstellt werden. Üblicherweise wird dort zunächst ein Physical Volume definiert.

pvcreate /dev/mapper/slackware

Daraufhin kann eine Volume Group angelegt werden:

vgcreate slackwarevg /dev/mapper/slackware

In dieser lassen sich die eigentlichen Logical Volumes erstellen. Dabei wird in diesem Beispiel eine SWAP Partition von 4G Grösse angelegt und der verbleibende Speicherplatz als Root-Partition genutzt:

lvcreate -L 4G slackwarevg -n swap
lvcreate -l 100%FREE slackwarevg -n root


Mit mkswap kann der SWAP Speicher aktiviert werden und mittels mkfs.ext4 das Root-Logical-Volume formatiert werden.

mkswap -L swap /dev/mapper/slackwarevg-swap
mkfs.ext4 /dev/mapper/slackwarvg-root

Abschliessen kann die eigentliche Installation von Slackware mithilfe des setup Befehls gestartet werden.

Es ist dabei wichtig zu beachten, dass das richtige Volumen als Root Partition ausgewählt wird (/dev/mapper/slackwarevg-root) und elilo statt lilo installiert wird.

Offizielle Anleitung: http://ftp.riken.jp/Linux/slackware/slackware-15.0/README_CRYPT.TXT

KaTex übersetzt die wichtigsten LaTex-Mathe-Notationen in HTML. Die Verwendung unterscheidet sich in Blogdown und HUGO.

21. Februar 2022

übersetzt die wichtigsten -Mathe-Notationen in HTML. Es ist dabei schneller als MathJax, hat im Gegenzug aber noch nicht (sooooo) viele Notationen umgesetzt wie der Platzhirsch. Zudem unterscheidet sich die Anwendung in Blogdown und HUGO.

KaTeX in HUGO einbinden

In meinem Themeordner erstelle ich die Datei /MEINTHEME/layouts/partials/katex.html und gebe ihr folgenden Inhalt:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.css" integrity="sha384-MlJdn/WNKDGXveldHDdyRP1R4CTHr3FeuDNfhsLPYrq2t0UBkUdK2jyTnXPEK1NQ" crossorigin="anonymous">

<!-- The loading of KaTeX is deferred to speed up page rendering -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.js" integrity="sha384-VQ8d8WVFw0yHhCk5E8I86oOhv48xLpnDZx5T9GogA/Y84DcCKWXDmSDfn13bzFZY" crossorigin="anonymous"></script>

<!-- To automatically render math in text elements, include the auto-render extension: -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/contrib/auto-render.min.js" integrity="sha384-+XBljXPPiv+OzfbB3cVmLHf4hdUFHlWNZN5spNQ7rmHTXpd7WvJum6fIACpNNfIR" crossorigin="anonymous" onload="renderMathInElement(document.body);"></script>

<script>
    document.addEventListener("DOMContentLoaded", function() {
        renderMathInElement(document.body, {
            delimiters: [
                {left: "$$", right: "$$", display: true},
                {left: "$", right: "$", display: false}
            ]
        });
    });
</script>

Ihr solltet nachschauen, ob die Version 0.15.2 immer noch die aktuellste ist und ggfs. die Zeilen entsprechend anpassen.

In der Datei /MEINTHEME/layouts/partials/head.html ergänze ich:

 {{ if .Params.math }}{{ partial "katex.html" . }}{{ end }}

Wenn ich später in Blogdown bei einem Post im Meta-Kopf folgenden Paramter setze:

 math: true

…dann wird KaTeX geladen und kann verwendet werden. Die Informationen hierzu hab ich in Mert Bakirs Blog gefunden.


Beispiele

Die Anwendung unterscheidet sich, je nachdem, ob .md, .Rmarkdown oder .Rmd-Files verwendet werden.



.md

In einfachen Markdowndokumenten funktioniert die Inline-Verwendung mittels Dollarzeichen:

 Dies ist ein Text mit $E=m\cdot c^2$ 

Das ergibt:

Dies ist ein Text mit

Das funktioniert auch mit Sonderzeichen:

 Wir verwenden $\LaTeX \rightarrow \KaTeX$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden mit zwei Dollarzeichen eingerahmt:

$$
E=m\cdot c^2
$$ 

Das ergibt:

Mit dem align-Environment werden die Formelzeilen automatisch am rechten Rand durchnummeriert. Environments müssen nicht per Dollarzeichen eingeführt werden sondern funktioniert direkt im Text :

Dies ist eine Formel

\begin{align}
E=m\cdot c^2
\end{align}

und ich finde sie gut

Das ergibt:

Dies ist eine Formel \begin{align} E=mc^2 \end{align} und ich finde sie gut

So funktioniert auch das equation-Environment direkt im Text:

Einstein hat mal gesagt:

\begin{equation}
E=m\cdot c^2
\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Einstein hat mal gesagt:

\begin{equation} E=mc^2 \end{equation}

und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



.Rmarkdown

In .Rmarkdown-Files ist die Notation leicht anders. So müssen bei der Inline-Verwendung die Dollarzeichen mittels Backslash auskommentiert werden:

 Dies ist ein Text mit \$a^2 + b^2 = c^2\$ 

Das ergibt:

Dies ist ein Text mit

Das gilt auch für alle Sonderzeichen:

 Wir verwenden \$\\LaTeX \\rightarrow \\KaTeX\$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden wie gewohnt mit zwei Dollarzeichen eingerahmt.

$$
a^2 + b^2 = c^2
$$ 

Das ergibt:

Auch hier müssen die Backslashs von Sonderzeichen auskommentiert werden:

$$
\\LaTeX \\rightarrow \\LaTeX
$$ 

Das ergibt:

In .Rmarkdown-Files müssen bei allen Environments und Sonderzeichen die \ von \begin{} und \end{} auskommentiert werden, damit sie direkt im Text funktionieren. Für das align-Environment sieht das dann so aus:

Irgendwas mit Dreiecken
\\begin{align}
a^2 + b^2 = c^2
\\end{align}
Was war das noch?

Das ergibt:

Irgendwas mit Dreiecken \begin{align} a^2 + b^2 = c^2 \end{align} Was war das noch?


Genau so funktioniert auch das equation-Environment:

Pythagoras hat mal gesagt:

\\begin{equation}
a^2 + b^2 = c^2
\\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Pythagoras hat mal gesagt:

\begin{equation} a^2 + b^2 = c^2 \end{equation}

und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



.Rmd

In .Rmd-Dokumenten funktioniert die Inline-Verwendung wieder mittels Dollarzeichen:

 Dies ist ein Text mit $\Reals \backsim 2^\N$ 

Das ergibt:

Dies ist ein Text mit

Das funktioniert auch mit Sonderzeichen:

 Wir verwenden $\LaTeX \rightarrow \KaTeX$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden mit zwei Dollarzeichen eingerahmt:

$$
\Reals \backsim 2^\N
$$ 

Das ergibt:

Mit dem align-Environment werden die Formelzeilen automatisch am rechten Rand durchnummeriert. Environments müssen nicht mit Dollarzeichen eingerahmt werden, sondern funktionieren direkt im Text:

Was war das noch für eine Formel
\begin{align}
\Reals \backsim 2^\N
\end{align}
Und was bedeutet sie?

Das ergibt:

Was war das noch für eine Formel \begin{align} \mathbb{R} \backsim 2^N \end{align} Und was bedeutet sie?

Das equation-Environment funktioniert genau so:

Cantor hat mal gesagt:

\begin{equation}
\Reals \backsim 2^\N
\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Cantor hat mal gesagt: und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



Allgemein

Zeilenumbrüche funktionieren per \newline, aber nicht mit \\:

\begin{align}
 E &= m \cdot c^2 \newline
 a^2 + b^2 &= c^2 \newline
 \Reals &\backsim 2^\N
\end{align}

Das ergibt:

Das Prozentzeichen muss mit zwei Backslashs auskommentiert werden:

$$
14\\% + 15\\% = 29\\%
$$

Das ergibt:

Links

übersetzt die wichtigsten -Mathe-Notationen in HTML. Es ist dabei schneller als MathJax, hat im Gegenzug aber noch nicht (sooooo) viele Notationen umgesetzt wie der Platzhirsch. Zudem unterscheidet sich die Anwendung in Blogdown und HUGO.

KaTeX in HUGO einbinden

In meinem Themeordner erstelle ich die Datei /MEINTHEME/layouts/partials/katex.html und gebe ihr folgenden Inhalt:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.css" integrity="sha384-MlJdn/WNKDGXveldHDdyRP1R4CTHr3FeuDNfhsLPYrq2t0UBkUdK2jyTnXPEK1NQ" crossorigin="anonymous">

<!-- The loading of KaTeX is deferred to speed up page rendering -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/katex.min.js" integrity="sha384-VQ8d8WVFw0yHhCk5E8I86oOhv48xLpnDZx5T9GogA/Y84DcCKWXDmSDfn13bzFZY" crossorigin="anonymous"></script>

<!-- To automatically render math in text elements, include the auto-render extension: -->
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.15.2/dist/contrib/auto-render.min.js" integrity="sha384-+XBljXPPiv+OzfbB3cVmLHf4hdUFHlWNZN5spNQ7rmHTXpd7WvJum6fIACpNNfIR" crossorigin="anonymous" onload="renderMathInElement(document.body);"></script>

<script>
    document.addEventListener("DOMContentLoaded", function() {
        renderMathInElement(document.body, {
            delimiters: [
                {left: "$$", right: "$$", display: true},
                {left: "$", right: "$", display: false}
            ]
        });
    });
</script>

Ihr solltet nachschauen, ob die Version 0.15.2 immer noch die aktuellste ist und ggfs. die Zeilen entsprechend anpassen.

In der Datei /MEINTHEME/layouts/partials/head.html ergänze ich:

 {{ if .Params.math }}{{ partial "katex.html" . }}{{ end }}

Wenn ich später in Blogdown bei einem Post im Meta-Kopf folgenden Paramter setze:

 math: true

…dann wird KaTeX geladen und kann verwendet werden. Die Informationen hierzu hab ich in Mert Bakirs Blog gefunden.


Beispiele

Die Anwendung unterscheidet sich, je nachdem, ob .md, .Rmarkdown oder .Rmd-Files verwendet werden.



.md

In einfachen Markdowndokumenten funktioniert die Inline-Verwendung mittels Dollarzeichen:

 Dies ist ein Text mit $E=m\cdot c^2$ 

Das ergibt:

Dies ist ein Text mit

Das funktioniert auch mit Sonderzeichen:

 Wir verwenden $\LaTeX \rightarrow \KaTeX$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden mit zwei Dollarzeichen eingerahmt:

$$
E=m\cdot c^2
$$ 

Das ergibt:

Mit dem align-Environment werden die Formelzeilen automatisch am rechten Rand durchnummeriert. Environments müssen nicht per Dollarzeichen eingeführt werden sondern funktioniert direkt im Text :

Dies ist eine Formel

\begin{align}
E=m\cdot c^2
\end{align}

und ich finde sie gut

Das ergibt:

Dies ist eine Formel \begin{align} E=mc^2 \end{align} und ich finde sie gut

So funktioniert auch das equation-Environment direkt im Text:

Einstein hat mal gesagt:

\begin{equation}
E=m\cdot c^2
\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Einstein hat mal gesagt:

\begin{equation} E=mc^2 \end{equation}

und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



.Rmarkdown

In .Rmarkdown-Files ist die Notation leicht anders. So müssen bei der Inline-Verwendung die Dollarzeichen mittels Backslash auskommentiert werden:

 Dies ist ein Text mit \$a^2 + b^2 = c^2\$ 

Das ergibt:

Dies ist ein Text mit

Das gilt auch für alle Sonderzeichen:

 Wir verwenden \$\\LaTeX \\rightarrow \\KaTeX\$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden wie gewohnt mit zwei Dollarzeichen eingerahmt.

$$
a^2 + b^2 = c^2
$$ 

Das ergibt:

Auch hier müssen die Backslashs von Sonderzeichen auskommentiert werden:

$$
\\LaTeX \\rightarrow \\LaTeX
$$ 

Das ergibt:

In .Rmarkdown-Files müssen bei allen Environments und Sonderzeichen die \ von \begin{} und \end{} auskommentiert werden, damit sie direkt im Text funktionieren. Für das align-Environment sieht das dann so aus:

Irgendwas mit Dreiecken
\\begin{align}
a^2 + b^2 = c^2
\\end{align}
Was war das noch?

Das ergibt:

Irgendwas mit Dreiecken \begin{align} a^2 + b^2 = c^2 \end{align} Was war das noch?


Genau so funktioniert auch das equation-Environment:

Pythagoras hat mal gesagt:

\\begin{equation}
a^2 + b^2 = c^2
\\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Pythagoras hat mal gesagt:

\begin{equation} a^2 + b^2 = c^2 \end{equation}

und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



.Rmd

In .Rmd-Dokumenten funktioniert die Inline-Verwendung wieder mittels Dollarzeichen:

 Dies ist ein Text mit $\Reals \backsim 2^\N$ 

Das ergibt:

Dies ist ein Text mit

Das funktioniert auch mit Sonderzeichen:

 Wir verwenden $\LaTeX \rightarrow \KaTeX$ und das klappt ganz gut

Das ergibt:

Wir verwenden und das klappt ganz gut

Mathe-Umgebungen werden mit zwei Dollarzeichen eingerahmt:

$$
\Reals \backsim 2^\N
$$ 

Das ergibt:

Mit dem align-Environment werden die Formelzeilen automatisch am rechten Rand durchnummeriert. Environments müssen nicht mit Dollarzeichen eingerahmt werden, sondern funktionieren direkt im Text:

Was war das noch für eine Formel
\begin{align}
\Reals \backsim 2^\N
\end{align}
Und was bedeutet sie?

Das ergibt:

Was war das noch für eine Formel \begin{align} \mathbb{R} \backsim 2^N \end{align} Und was bedeutet sie?

Das equation-Environment funktioniert genau so:

Cantor hat mal gesagt:

\begin{equation}
\Reals \backsim 2^\N
\end{equation}

und ich glaube, er hatte Recht

Das ergibt:

Cantor hat mal gesagt: und ich glaube, er hatte Recht

Eine Übersicht aller unterstützer Environments findet ihr hier.



Allgemein

Zeilenumbrüche funktionieren per \newline, aber nicht mit \\:

\begin{align}
 E &= m \cdot c^2 \newline
 a^2 + b^2 &= c^2 \newline
 \Reals &\backsim 2^\N
\end{align}

Das ergibt:

Das Prozentzeichen muss mit zwei Backslashs auskommentiert werden:

$$
14\\% + 15\\% = 29\\%
$$

Das ergibt:

Links

Die MZLA Technologies Corporation hat mit Thunderbird 91.6.1 ein Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.6.1

Mit dem Update auf Thunderbird 91.6.1 hat die MZLA Technologies Corporation ein Update außer der Reihe für seinen Open Source E-Mail-Client veröffentlicht und behebt damit mehrere Fehler der Vorgängerversion. Diese lassen sich in den Release Notes (engl.) nachlesen. Dies schließt auch eine geschlossene Sicherheitslücke ein.

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

In Teil 1 dieser Artikelserie habe ich mein Ansinnen ausführlich beschrieben. Dieser Teil widmet sich der Entwicklung einer Ansible-Rolle zum Deployment des Nextcloud-Apache-Container-Images.

In den folgenden Abschnitten beschreibe ich die Einrichtung eines Python Virtual Environments, die Installation von Ansible in dem zuvor erstellten Environment und die Installation der Ansible-Collection containers.podman, bevor ich mich abschließend der eigentlichen Ansible-Rolle widme.

Python Virtual Environments für Ansible

Zur Einrichtung habe ich mich an den englischsprachigen Artikel „How to set up and use Python virtual environments for Ansible“ von Gineesh Madapparambath gehalten. Die notwendigen Schritte werden hier kurz und bündig dokumentiert.

[t14s ~]$ python3 --version
Python 3.9.7

[t14s ~]$ mkdir python-venv
[t14s ~]$ cd !$
cd python-venv

[t14s python-venv]$ python3 -m venv ansible-core2.x
[t14s python-venv]$ source ansible-core2.x/bin/activate
(ansible-core2.x) [jkastning@t14s python-venv]$ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in ./ansible-core2.x/lib/python3.9/site-packages (21.0.1)
Collecting pip
  Downloading pip-21.3.1-py3-none-any.whl (1.7 MB)
     |████████████████████████████████| 1.7 MB 2.3 MB/s 
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 21.0.1
    Uninstalling pip-21.0.1:
      Successfully uninstalled pip-21.0.1
Successfully installed pip-21.3.1

(ansible-core2.x) [t14s python-venv]$ python3 -m pip install ansible-core
Collecting ansible-core
[...]

(ansible-core2.x) [t14s python-venv]$ ansible --version
ansible [core 2.11.6] 
  config file = None
  configured module search path = ['/home/tronde/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/tronde/python-venv/ansible-core2.x/lib64/python3.9/site-packages/ansible
  ansible collection location = /home/tronde/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/tronde/python-venv/ansible-core2.x/bin/ansible
  python version = 3.9.7 (default, Aug 30 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)]
  jinja version = 3.0.2
  libyaml = True

Damit ist die Installation von ansible-core abgeschlossen. Im folgenden Code-Block wird geprüft, ob Ansible sich grundsätzlich mit dem Zielsystem verbinden und dort einen Python-Interpreter identifizieren kann.

(ansible-core2.x) [t14s python-venv]$ ansible -i hosts --private-key ~/.ssh/ansible_id_rsa -m ping example.com
example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Installation der Ansible-Collection containers.podman

Um Podman auf dem Zielsystem konfigurieren zu können, wird die genannte Ansible-Collection benötigt, welche mit folgendem Befehl installiert werden kann. Der Code-Block zeigt zusätzlich die Ausgabe während der Installation.

(ansible-core2.x) [t14s ansible-core2.x]$ ansible-galaxy collection install containers.podman
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/containers-podman-1.8.2.tar.gz to /home/tronde/.ansible/tmp/ansible-local-8729oh0om8w3/tmp7tv2yrae/containers-podman-1.8.2-9rw3fd1y
Installing 'containers.podman:1.8.2' to '/home/tronde/.ansible/collections/ansible_collections/containers/podman'
containers.podman:1.8.2 was installed successfully

Ansible-Rolle: Deployment von Nextcloud und MariaDB als Pod

Nextcloud benötigt für den Betrieb eine Datenbank. Hierfür könnte man eine integrierte SQLite nutzen. Dies wird jedoch nur für kleine Umgebungen empfohlen. Während der Entstehung dieses Artikels wird MariaDB als Datenbank-Backend vom Nextlcoud-Projekt empfohlen. Daher habe ich mich entschieden, das Nextcloud-Image zusammen mit einem MariaDB-Container zu deployen. Dazu greife ich auf die beiden folgenden Container-Repositorien zurück:

Das Grundgerüst bzw. die Verzeichnisstruktur für die Ansible-Rolle wurde erstellt mit:

$ ansible-galaxy role init --offline ansible_role_deploy_nextcloud_with_mariadb_pod

Die aktuelle Version der Ansible-Rolle ist auf GitHub zu finden. Ich werde ihre Bestandteile hier im Einzelnen vorstellen.

Die Variablen in defaults/main.yml

In der Datei defaults/main.yml habe ich Standardwerte für Variablen definiert, die geeignet sind, eine funktionsfähige Nextcloud-Instanz zu initialisieren. Die Bezeichner der Variablen sind dabei der Dokumentation der verwendeten Container-Repositorien entnommen.

In Zeile 4-7 und 10 werden die Namen für Podman-Volumes definiert, welche die persistent zu speichernden Daten aufnehmen werden.

     1	---
     2	# defaults file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	# Podman volumes for Nextcloud
     4	NC_HTML: nc_html
     5	NC_APPS: nc_apps
     6	NC_CONFIG: nc_config
     7	NC_DATA: nc_data
     8	
     9	# Podman volume for MariaDB
    10	MYSQL_DATA: mysql_data

Die Zeilen 13-17 definieren Variablen für die MariaDB-Instanz, wie z.B. Namen der Datenbank, Benutzername und Passwörter für diese Datenbank und den DB-Host. Diese werden neben dem MariaDB-Container auch von dem Nextcloud-Container benötigt, um eine Verbindung zur Datenbank herstellen zu können.

    12	# MySQL/MariaDB vars
    13	MYSQL_DATABASE: nc_db
    14	MYSQL_USER: nextcloud
    15	MYSQL_PASSWORD: ToPSeCrEt2021!
    16	MYSQL_ROOT_PASSWORD: ToPSeCrEt2021!
    17	MYSQL_HOST: 127.0.0.1
    18	
    19	# Vars for MariaDB container
    20	MARIADB_CONMON_PIDFILE: /tmp/mariadb_conmon.pid
    21	MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
    22	MARIADB_NAME: nc_mariadb

Zeile 20-22 definiert Variablen, die für den MariaDB-Container benötigt werden. Hier wird z.B. die Version des Container-Images (MARIADB_IMAGE) und ein Name für die Container-Instanz (MARIADB_NAME) festgelegt.

Die folgenden Zeilen widmen sich den Variablen für den Nextcloud-Container. Dort werden in den Zeilen 25 u. 26 Benutzername und Passwort für den Nextcloud-Admin definiert, gefolgt von einigen Variablen, welche bei Nutzung eines Reverse-Proxy benötigt werden und SMTP-Variablen, welche der Nextcloud den Mailversand ermöglichen.

    24	# Nextcloud vars
    25	NEXTCLOUD_ADMIN_USER: nc_admin
    26	NEXTCLOUD_ADMIN_PASSWORD: VSnfD2021!
    27	NEXTCLOUD_OVERWRITEPROTOCOL: ""
    28	NEXTCLOUD_OVERWRITECLIURL: ""
    29	NEXTCLOUD_TRUSTED_DOMAINS: ""
    30	
    31	# SMTP vars
    32	SMTP_HOST: smtp.example.com
    33	SMTP_SECURE: tls # ssl to use SSL, or tls zu use STARTTLS
    34	SMTP_PORT: 587 # (25, 465 for SSL, 587 for STARTTLS)
    35	SMTP_AUTHTYPE: LOGIN
    36	SMTP_NAME: bob@example.com
    37	SMTP_PASSWORD: MailSecret1!
    38	MAIL_FROM_ADDRESS: no-reply@example.com
    39	MAIL_DOMAIN: "@example.com"

Bei den SMTP-Variablen handelt es sich um Beispiel-Werte. Diese müssen an die konkrete Umgebung angepasst werden.

Es folgen nun noch ein paar Variablen, welche dem Pod und dem Nextcloud-Container einen Namen geben, sowie die Version des zu verwendenden Nextcloud-Container-Images festlegen.

    41	# Vars for podman-pod(1)
    42	POD_NAME: nc_pod
    43	POD_PORT: 127.0.0.1:40231:80
    44	POD_INFRA_CONMON_PIDFILE: /tmp/nc_pod_infra.pid
    45	
    46	# Vars for Nextcloud container
    47	NC_CONMON_PIDFILE: /tmp/nc_conmon.pid
    48	NC_IMAGE: docker.io/library/nextcloud:23-apache
    49	NC_NAME: nextcloud

Durch POD_PORT: 127.0.0.1:40231:80 wird definiert, dass der Port 40231 an das Loopback-Interface gebunden und mit Port 80 des Pods verknüpft wird. Mit dieser Einstellung ist die Nextcloud-Instanz nur von dem Host aus erreichbar, auf dem sie ausgebracht wurde. Möchte man sie auch von anderen Hosts aus erreichbar machen, kann man entweder den Teil mit 127.0.0.1: weglassen oder einen Reverse-Proxy wie z.B. NGINX verwenden. Ich empfehle an dieser Stelle letzteres.

Hinweis: In defauts/main.yml stehen Passwörter im Klartext. Diese sind mit der Veröffentlichung der Ansible-Rolle allgemein bekannt und sollten gegen solche ersetzt werden, die geheimgehalten werden. Dies kann z.B. geschehen, in dem man die entsprechenden Variablen in vars/main.yml oder host_vars/hostname neu definiert. Es bietet sich an, diese zusätzlich mit Ansible-Vault zu verschlüsseln.

Die Tasks in tasks/main.yml

Im vorstehenden Abschnitt wurden die Variablen definiert, welche für die nun folgenden Tasks benötigt werden. Diese sind in tasks/main.yml definiert und werden im folgenden wieder abschnittsweise erläutert.

     1	---
     2	# tasks file for ansible_role_deploy_nextcloud_with_mariadb_pod
     3	- name: Main folder, needed for updating
     4	  containers.podman.podman_volume:
     5	    state: present
     6	    name: "{{ NC_HTML }}"
     7	    recreate: no
     8	    debug: no
     9	
    10	- name: Volume for installed/modified apps
    11	  containers.podman.podman_volume:
    12	    state: present
    13	    name: "{{ NC_APPS }}"
    14	    recreate: no
    15	    debug: no
    16	
    17	- name: Volume for local configuration
    18	  containers.podman.podman_volume:
    19	    state: present
    20	    name: "{{ NC_CONFIG }}"
    21	    recreate: no
    22	    debug: no
    23	
    24	- name: Volume for the actual data of Nextcloud
    25	  containers.podman.podman_volume:
    26	    state: present
    27	    name: "{{ NC_DATA }}"
    28	    recreate: no
    29	    debug: no
    30	
    31	- name: Volume for the MySQL data files
    32	  containers.podman.podman_volume:
    33	    state: present
    34	    name: "{{ MYSQL_DATA }}"
    35	    recreate: no
    36	    debug: no

Die ersten Zeilen enthalten Tasks, durch welche die Podman-Volumes zur persistenten Datenspeicherung auf dem Zielsystem erstellt werden. Diese Tasks sind, wie für Ansible üblich, deklarativ und idempotent. Existiert ein Volume bereits, liefert der entsprechende Task ein ‚OK‘ zurück, da keine Aktionen erforderlich sind.

Die folgenden Zeilen erstellen den Podman-Pod und fügen ihm einen Nextcloud- sowie einen MariaDB-Container hinzu. Die Dokumentation der verwendeten Module findet sich in Punkt 5 und 6 im Abschnitt Quellen und weiterführende Links.

    38	- name: Create the podman-pod(1)
    39	  containers.podman.podman_pod:
    40	    debug: no
    41	    infra: yes
    42	    infra_conmon_pidfile: "{{ POD_INFRA_CONMON_PIDFILE }}"
    43	    publish: "{{ POD_PORT }}"
    44	    name: "{{ POD_NAME }}"
    45	    state: started
    46	
    47	- name: Create MariaDB container
    48	  containers.podman.podman_container:
    49	    debug: yes
    50	    conmon_pidfile: "{{ MARIADB_CONMON_PIDFILE }}"
    51	    image: "{{ MARIADB_IMAGE }}"
    52	    image_strict: yes
    53	    pod: "{{ POD_NAME }}"
    54	    recreate: yes
    55	    state: started
    56	    name: "{{ MARIADB_NAME }}"
    57	    env:
    58	      MYSQL_USER: "{{ MYSQL_USER }}"
    59	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    60	      MYSQL_ROOT_PASSWORD: "{{ MYSQL_ROOT_PASSWORD }}"
    61	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    62	    volume: "{{ MYSQL_DATA }}:/var/lib/mysql:Z"
    63	
    64	- name: Wait for DB to initilize
    65	  wait_for:
    66	    timeout: 20
    67	
    68	- name: Create Nextcloud container
    69	  containers.podman.podman_container:
    70	    debug: no 
    71	    conmon_pidfile: "{{ NC_CONMON_PIDFILE }}"
    72	    image: "{{ NC_IMAGE }}"
    73	    image_strict: yes
    74	    pod: "{{ POD_NAME }}"
    75	    recreate: yes
    76	    state: started
    77	    name: "{{ NC_NAME }}"
    78	    env:
    79	      MYSQL_DATABASE: "{{ MYSQL_DATABASE }}"
    80	      MYSQL_USER: "{{ MYSQL_USER }}"
    81	      MYSQL_PASSWORD: "{{ MYSQL_PASSWORD }}"
    82	      MYSQL_HOST: "{{ MYSQL_HOST }}"
    83	      NEXTCLOUD_ADMIN_USER: "{{ NEXTCLOUD_ADMIN_USER }}"
    84	      NEXTCLOUD_ADMIN_PASSWORD: "{{ NEXTCLOUD_ADMIN_PASSWORD }}"
    85	      NEXTCLOUD_TRUSTED_DOMAINS: "{{ NEXTCLOUD_TRUSTED_DOMAINS }}"
    86	      SMTP_HOST: "{{ SMTP_HOST }}"
    87	      SMTP_SECURE: "{{ SMTP_SECURE }}"
    88	      SMTP_PORT: "{{ SMTP_PORT }}"
    89	      SMTP_AUTHTYPE: "{{ SMTP_AUTHTYPE }}"
    90	      SMTP_NAME: "{{ SMTP_NAME }}"
    91	      SMTP_PASSWORD: "{{ SMTP_PASSWORD }}"
    92	      MAIL_FROM_ADDRESS: "{{ MAIL_FROM_ADDRESS }}"
    93	      MAIL_DOMAIN: "{{ MAIL_DOMAIN }}"
    94	      OVERWRITEPROTOCOL: "{{ NEXTCLOUD_OVERWRITEPROTOCOL }}"
    95	      OVERWRITECLIURL: "{{ NEXTCLOUD_OVERWRITECLIURL }}"
    96	    volume:
    97	      - "{{ NC_HTML }}:/var/www/html:Z"
    98	      - "{{ NC_APPS }}:/var/www/html/custom_apps:Z"
    99	      - "{{ NC_CONFIG }}:/var/www/html/config:Z"
   100	      - "{{ NC_DATA }}:/var/www/html/data:Z"

In Zeile 64-66 habe ich einen Task definiert, der einfach nur 20 Sekunden wartet. Dies wurde erforderlich, da ich Laufzeitprobleme feststellen konnte, wenn der Nextcloud-Container startet, bevor die Datenbank im MariaDB-Container initialisiert war. Dieses Konstrukt ist nicht schön und ich bin für Verbesserungsvorschläge offen.

Zwischenfazit

Die Erstellung der Ansible-Rolle hat länger gedauert, als angenommen. Dies liegt nur zum Teil in meiner spärlichen Freizeit begründet. Einen größeren Einfluss darauf hatte die Dokumentation zum Nextcloud-Repository. Diese geht davon aus, dass man ein Dockerfile bzw. Docker-Compose verwendet. So war noch etwas Internet-Recherche erforderlich, um den Pod letztendlich ans Laufen zu bringen.

Dieser Artikel beschäftigte sich mit den Tag-1-Aufgaben, an deren Ende eine Nextcloud-Instanz ausgebracht wurde, welche an einen Reverse-Proxy angebunden werden kann.

Im nächsten Artikel gehe ich auf die Konfiguration des NGINX-Reverse-Proxy ein. Hierbei habe ich einige Überraschungen erlebt, welche mich an der Reife des Projekts [2] zweifeln lassen.

Quellen und weiterführende Links

  1. Nextcloud System Requirements — https://docs.nextcloud.com/server/latest/admin_manual/installation/system_requirements.html
  2. Nextcloud (Official Image) — https://hub.docker.com/_/nextcloud
  3. MariaDB (Official Image) — https://hub.docker.com/_/mariadb
  4. GitHub Tronde/ansible_role_deploy_nextcloud_with_mariadb_pod
  5. podman_pod – Manage Podman pods
  6. podman_container – Manage podman containers