Kategorie: Allgemein

Momentan beschäftige ich mich parallel mit dem Thema OpenTofu mit Proxmox inklusive cloud-init. Ein Punkt der mir besonders wichtig war bei der initialen Konfiguration von VMs während des Deployments war das Vergrößern des (LVM) root Volumes bei Bedarf. Und das ist ein bekanntes Problem und scheinbar löst es jeder anders – oder gar nicht.

(mehr …)

Im ersten Teil einer Serie von AWX Beiträgen zeige ich, wie man AWX grundsätzlich so einrichtet, dass die Kernfunktionen genutzt werden können. Ziel ist es, gegen ein System ein Ansible ad-hoc Kommando auszuführen.

(mehr …)

Nach dem Upgrade von Proxmox 8 auf 9 ist mir aufgefallen, dass die Lüfter meiner Intel NUCs deutlich öfter und hörbar lauter aufgedreht haben. Neue und alte Probleme treffen hier zusammen.

(mehr …)

In diesem Artikel beschreibe ich, wie nun alle Komponenten aus den letzten Artikeln zusammengebracht werden: AWX, MetalLB und die Gateway API von Kubernetes – um dann endlich AWX auch über SSL betreiben zu können.

(mehr …)

Manchmal hat es auch seine guten Seiten keine Zeit für gewisse Dinge zu haben – wie sich mit IT Themen auseinandersetzen und darüber zu schreiben. Das Thema Ingress mit Kubernetes bspw. habe ich länger vor mir hergeschoben, bzw. es falsch eingesetzt (u.a. aufgrund einer OnPrem Installation). Wie sich jetzt herausgestellt hat, ist Ingress abgekündigt und wird nicht weiterentwickelt. Die K8s Gateway API ist jetzt der Standard.

(mehr …)

Kubernetes hat eine steile Lernkurve, keine Frage. Eine Sache, über die ich mir aber auch erst einmal klar werden musste ist, wie unterschiedlich sich Kubernetes Instanzen in Hyperscalern und OnPremise verhalten. Viele der Artikel die im Internet kuriseren, basieren nämlich auf der Annahme, dass man sich auf einem Hyperscaler bewegt (AKS whatever…). Wie man K8s aber OnPrem betreibt, danach muss man sehr gezielt suchen.

(mehr …)

Seit einigen Jahren beschäftige mich mich mit Ansible, noch länger mit der Automatisierung. Im Laufe der Jahre habe ich sehr viele Lösungen für die Automatisierung in IT Infrastrukturen gesehen und genutzt. Viele hatten etwas gemeinsam: Eine GUI. Ich bin bei weitem kein Verfechter von grafischen Benutzeroberflächen, Ansible bietet eigentlich alles was man benötigt, solange man sich auf der Kommandozeile wohl fühlt. Aber ein Interface zur Steuerung von Ansible Playbook bzw. Jobs, hat mir immer gefehlt.

Es gibt mittlerweile viele Lösungen. RunDeck, oder Semaphore, um nur zwei Alternativen zu AWX für Ansible zu nennen. Aber AWX ist schließlich ein Upstream Projekt der Red Hat Ansible Automation Platform – genauer gesagt das, was was später der Ansible Controller im AAP ist. Warum also nicht direkt auf das „Original“ setzen. Schließlich stammt Ansible aus dem gleichen Haus.

Leider befindet sich das AWX Projekt derzeit in einer Art Freeze-Zustand. Der letzte Release (24.6.1) ist von Sommer 2024. Der Grund ist, dass das gesamte Projekt von Grund auf überarbeitet wird. Ich empfehle dennoch, zumindest noch, AWX als Alternative zum AAP, wenn Ansible im großen Stil in Infrastrukturen eingesetzt wird. Die Basis-Installation ist denkbar einfach (dank Operator und Container-Deployment) und ich glaube nicht, dass sich die Platform im Kern komplett verändern wird. Dafür ist die Lösung zu weit verbreitet.

AWX Operator

Die Installation auf Kubernetes erfolgt mittels des sogenannten Operator. Dieser führt das das Deployment von AWX auf Kubernetes aus. Hierbüber laufen auch Updates und Lifecyles. Genau wie AWX selbst, ist der letzte Release (2.19.1) von Sommer 2024.

Ich habe mich lange und viel zu viel damit auseinandergesetzt, wie man AWX mit HTTPS Zugriff installiert. Zudem habe ich mich in eine falsche Richtung bewegt (Spoiler: Die eigene Unwissenheit über K8s war der Grund). In den nächsten Artikeln werde ich darauf genauer eingehen. Hier und jetzt zeige ich nur, wie AWX simpel und einfach auf einer K8s Umgebung deployed werden kann. Einzige Besonderheit: Ich verwende einen bereits bestehenden dedizierten PostgreSQL Server. Dadurch ist das AWX Deployment schmaler und man benötigt keinen separates persistant volume.

Die Installation des Operators ist super simpel.

Das Git-Projekt klonen:

git clone https://github.com/ansible/awx-operator.git

In das Verzeichnis wechseln und auf den Branch des letzten Release wechseln:

cd awx-operator  
git checkout 2.19.1

Den Operator bzw. die Pods deployen:

make deploy

Nach kurzer Zeit sollten zwei Operator Pods zu sehen sein:

Ab diesem Punkt ist man bereits in der Lage eine AWX Instanz zu installieren.

Einrichten der PosgreSQL Datenbank

Erstellen der Datenbank und des Users:

CREATE DATABASE awx;

CREATE USER awx WITH ENCRYPTED PASSWORD 'xyz';

GRANT ALL PRIVILEGES ON DATABASE awx TO awx;

ALTER DATABASE awx OWNER TO awx;

Listener Address für PostgreSQL anpassen (postgresql.conf):

Kann natürlich enstprechend der eigenen Bedürfnisse und Sicherheitsansprüche verändert werden.

Zugriffe auf den DBMS und die Datenbank erlauben (pg_hba.conf):

Auch hier gilt: Bitte entsprechend der eigenen Umgebung anpassen. In meinem Fall reicht diese Konfiguration vollkommen aus, da es sich um eine abgeschottete Testinfrastruktur handelt.

Damit die AWX Pods auf die PostgresSQL Datenbank zugreifen zu können, muss ein secret erstellt werden.

nano awx-postgres-secret.yml

apiVersion: v1
kind: Secret
metadata:
 name: sos-awx-postgres-configuration
 namespace: awx
data:
 host: xyz              # “IP of Host” (base64)
 port: NTQzMg==         # “5432” (base64)
 database: YXd4         # “awx” (base64)
 username: YXd4         # “awx” (base64)
 password: xyz          # “yourpassword” (base64)
 type: dW5tYW5hZ2Vk     # “unmanaged” (base64)
 sslmode: ZGlzYWJsZQ==  # “disable” (base64)
type: Opaque

Die Werte muss man entsprechend anpassen. Alle Werte sind base64 Strings.

Sytnax um einen base64 verschlüsselten String zu erstellen:

echo -n 'mystring' | base64

Secret erstellen:

kubectl apply -f awx-postgres-secret.yml

AWX Instanz Deployment

Damit sind bereits alle Vorbereitungen für ein AWX Deployment abgeschlossen. An dem folgenden Teil habe ich mir lange die Zähne ausgebissen, u.a. wegen LoadBalancern, Ingress, HTTPS uvm. Am Ende kann man aber sagen: Folgendes Manifest für das Deployment reicht vollkommen aus:

nano ansible-awx-ext-db.yml

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: ansible-awx
  namespace: awx
spec:
  service_type: nodeport
	nodeport_port: 30080
  postgres_configuration_secret: sos-awx-postgres-configuration

Im Grunde sagt das auch die Dokumentation.

Mehr benötigt man nicht. Der Typ, Name, Namespace und der Service Typ – in diesem Fall einfach als Nodeport. Was das bedeutet, sieht man gleich nach dem Deployment. Der Wert „postgres_configuration_secret“ gibt das secret an, welches für die Datenbank-Verbindung erstellt wurde.

AWX ausrollen:

kubectl apply -f ansible-awx-ext-db.yml

Nach einiger Zeit sollten drei Deployments mit mehreren Pods zu sehen sein:

Bei Bedarf, kann man sich die Logs des Deployments im Operator anschauen:

kubectl -n awx logs -f deployments/awx-operator-controller-manager

Der Operator hat jetzt aber nicht nur die Pods installiert, sondern auch einen neuen Service erstellt (vom Typ NodePort). Diesen kann man sich anzeigen lassen:

kubectl get svc -n awx

Hier sieht man, dass der Service auf Port 30080 nach außen und auf 80 nach innen (auf die Pods) läuft. So wie im Manifest angegeben.

Um herauszubekommen, wie man nun auf AWX zugreifen kann, muss man schauen, auf welchem K8s Worker-Node der entsprechende Pod (web) läuft:

kubectl get pods -n awx -o wide

In diesem Fall: kube02 – mein zweiter Worker-Node.

Der Aufruf kann also per

http://[IP kube02]:30080

erfolgen.

Das initiale Admin-Passwort erhält man folgendermaßen:

kubectl get secret ansible-awx-admin-password -o jsonpath="{.data.password}" -n awx | base64 --decode ; echo

Nach der Anmeldung lässt sich dies normal ändern.

That’s it 🙂 An dieser Stelle kann man AWX bereits vollumfänglich nutzen.

Da ich auch intern meine Services auf HTTPS laufen lasse, wollte ich AWX natürlich ebenso mit einem SSL Zertifikat austatten. Hierzu komme ich in einem nachfolgenden Artikel. Die Einrichtung von AWX (Repos, Projects usw.) folgt anschließend.

Containerize all the things! Seit vielen Jahren ist die Container-Technologie aus der IT-Welt nicht mehr wegzudenken. Mittlerweile gibt es viele Lösungen und Varianten, einige sogar schon wieder veraltet. Über die Container-Engine hinaus gibt es auch Komplettlösungen, die eine Verwaltung bzw. Orchestrierung bieten – wie zum Beispiel Kubernetes.

Weiterlesen

HTTPS dürfte im Zusammenhang mit Internetdiensten heutzutage jedem ein Begriff und zudem Standard sein. Hierbei wird die HTTP Kommunikation verschlüsselt, was in den meisten Anwendungsfällen herkömmliche Webseiten wie diese betrifft. Und bei dieser Kommunikation stoßen wir auf ein sehr altes grundsätzliches Problem, denn das Internet ist eigentlich kaputt…

Die Adressermittlung (bzw. Umwandlung) im Internet findet nach wie vor über das Dynamic Name System, kurz DNS, statt. Ich werde ich jetzt nicht im Detail auf die Arbeitsweise von DNS eingehen, aber kurz gesagt, nach wie vor kommunizieren Computer im Internet über IP Adressen, welche zu einer (oder mehreren) Adressen gehören (das Telefonbuchprinzip). Daher muss ein Computer bevor er eine Webseite o.Ä. aufruft, zunächst seinen bekannten DNS Resolver befragen, welcher weiß, welche IP zu der aufgerufenen Adresse gehört. Einige Webseiten laden externen Inhalt, sei es duch Werbung, oder die Verlinkung zu anderen Artikeln o.Ä. Daher kann das Aufrufen einer einzigen Webseite u.U. mehrere DNS Anfragen zur Folge haben. Alleine nur das Aufrufen der Seite www.heise.de beinhaltet über 50 Anfragen zu weiterführenden Webseiten. Wieviele Anfragen nochmals jede dieser 50 Seiten produziert, lässt sich nicht einmal erahnen.

Und hier kommt die Krux an der Sache: Diese (DNS) Anfragen sind standardmäßig nicht verschlüsselt. Damals (in den 1980ern) hat man sich über Verschlüsselung wenig bis keine Gedanken gemacht. Und es hat zu dieser Zeit bestimmt niemand damit gerechnet, wie man DNS Anfragen missbrauchen kann bzw. was sich mit diesen Informationen sonst noch anstellen lässt.

Problem 1:

Da die Anfragen unverschlüsselt sind, lassen sich diese natürlich an jeder beliebigen Stelle mitlesen, was eine sogenannte „Man in the Middle“ Attacke (MITM) zulässt. Hierbei kann der Angreifer DNS Anfragen umlenken indem er statt auf www.abc.de das Opfer auf www.xyz.de umleitet, dieses davon aber nicht mitbekommt, bzw. erst wenn es zu spät ist (der Schadcode ist auf dem PC, oder die wertvollen Daten wurden abgegriffen, da das Opfer diese auf der gefälschten Seite gutgläubig eingegeben hat).

Problem 2:

Von dem oben genannten „Phishing“ hat fast jeder schon einmal gehört. Aber abseits von sicherheitsrelevanten Problemen im DNS, gibt es ein weiteres nicht unerhebliches Problem im Bereich der digitalen Privatsphäre. Dadurch das die DNS Anfragen unverschlüsselt sind, ist angefangen beim ISP (Telekom, Vodafone etc.) einsehbar, welche Webseiten wann besucht wurden. Hier befinden wir uns im Bereich des User-Tracking, sprich dem Sammeln von Benutzerdaten, welche anhand der IP- und ggf. der MAC Adresse des Quellgerätes personifiziert werden können und somit ein wahrer Goldschatz für die Werbeindustriee sind. Dr. Dominik Hermann hat hierzu eine ausführliche Dissertation veröffentlicht.

DoH oder DoT (DNS over TLS) ermöglicht es diesen Datenstrom zu verschlüsseln. Allerdings passiert dies nur bis zum ISP, danach findet die DNS Kommunikation wieder unverschlüsselt statt. Angeblich soll es hierzu aber Pläne geben, diese weiterführende Kommunikation ebenfalls komplett auf Verschlüsselung umzustellen.

Das „Einer kennt alles“ Problem

Im Regelfall benutzen Systeme einen einzigen DNS Resolver. Man kann zwar mehr als einen konfigurieren, aber üblicherweise wird der erste solange genutzt, bis dieser nicht mehr erreichbar ist. Das bedeutet, ein Resolver kennt alle DNS Anfragen. Jetzt kann man natürlich gut und gerne die Frage stellen, was machen ISPs wie die Telekom, Vodafone, 1&1 usw. mit unseren ganzen DNS Anfragen? Jedenfalls werden diese zunächst einmal geloggt und gespeichert. Was damit weiterhin passiert, kann niemand mit absoluter Sicherheit sagen und vielleicht werden diese sogar an Dritte weitergegeben/verkauft. Und selbst wenn damit nichts passieren sollte, ist theoretisch der Datenstrom der Benutzer mitsamt IP und DNS Anfragen nach dem ISP wieder erfassbar. Und diese „Ausgänge“ sind natürlich nur bedingt dynamisch und relativ leicht aufzufinden.

Es spricht also einiges dafür unabhängig von der Verschlüsselung seinen DNS Resolver genauer auszuwählen, oder vielleicht sogar einen eigenen DNS Resolver zu betreiben. Einige Resolver werben auch extra dafür, dass z.B. keinerlei Logging erfolgt. Ein Abschöpfen des ausgehenden Datenstroms ist bei kleineren unbekannten Resolvern natürlich ebenfalls unwahrscheinlich. Somit wird das Risiko minimiert, auch wenn es nicht gänzlich verschwindet. Zumindest ist eine Rückverfolgung des ursprünglichen Systems, welches die Anfrage gestartet hat, deutlich schwieriger.

DoH, DoT, DNSCrypt, DwasBitte?

Bei DoH (DNS over HTTPS) wird tatsächlich normal über den Port 443 (das reguläre HTTPS Protokoll) kommuniziert, was es ermöglicht, dass eine DNS Anfrage nicht von einer normalen Webseiten-Anfrage zu unterscheiden ist. Dieses Verfahren macht es allerdings auch zu dem langsameren, wobei die Unterschiede bei herkömmlichen Verbindungsgeschwindigkeiten marginal ausfallen dürften. DoH ist als RFC 8484 standardisiert.

DNS over TLS (DoH) nimmt die bisherige Basis der DNS Kommunkation per UDP/53 und entwickelt diese weiter indem eine Verschlüsselung per TLS hinzugefügt und ein eigenständiger Port (normalerweise 853) verwendet wird. Dadurch ist DoT schneller als DoH. DoT ist zwar nicht standardisiert, aber als RFC 7858 vorgeschlagen.

DNSCrypt ist gegenüber den beiden anderen das ältere Verfahren und basiert weder auf HTTPS noch TLS, sondern setzt auf einen eigenen Algorithmus. Allerdings läuft DNSCrypt ebenfalls über den Port 443 (standardmäßig allerdings UDP, Fallback TCP) was somit bis zu einem gewissen Grad auch den Vorteil der „Paketverschleierung“ beinhaltet. DNSCrypt  wurde jedoch nie als Standard vorgeschlagen.  
Weitere Protokolle zur Verschlüsselung von DNS ist bspw. QUIC, auf welches ich hier aber nicht weiter eingehe.

DoH und DoT sind somit derzeit die gängisten Lösungen. Aber wie nutzt man nun verschlüsseltes DNS?

Die betriebssystemseitige Lösung

Ich habe bereits im Sailfish Artikel oder auch auf Mastodon mehrfach auf die Software dnscrypt-proxy hingewiesen. Anders als der Name vermuten lässt, unterstützt dies natürlich auch DoH/DoT.
Der Vorteil dieser Software ist, dass die Verschlüsselung auf OS Ebene erfolgt, unabhängig von den nachfolgenden Geräten/Zugängen. Somit hat man DoH/DoT/DNSCrypt bspw. auf seinem Notebook, egal wo man sich befindet. Zusätzlich bietet die Software die Nutzung von Domain- und IP Blacklists und dadurch natürlich auch Whitelists. Der zu verwendende Resolver ist frei wählbar, wobei auch mehrere Resolver mit unterschiedlichen Protokollen genutzt werden können.

dnscrypt-proxy arbeitet mit sogenannten DNS Stamps. Diese Stamps beinhalten alle relevanten Informationen um sich mit den gesicherten DNS Resolver verbinden zu können. Eine Liste mit Resolvern und den dazugehörigen Stamps findet sich hier. Zusätzlich kann man Stamps auch selbst generieren.

Pihole

Der PiHole dürfte eines der bekanntesten und weit verbreitetesten Raspberry Pi Projekte überhaupt sein. Mit seiner Hilfe lässt sich die gesamte DNS Kommunikation in einem Netzwerk filtern – überwiegend natürlich dazu gedacht, Werbung und Tracking zu unterbinden. Der PiHole arbeitet dabei auch nur mit einfachen Blocklisten, welche beinhalten, was für DNS Namen gefiltert werden sollen. Um den PiHole im Netzwerk nutzen zu können, muss dieser natürlich auch als erster DNS Resolver im Netzwerk konfiguriert werden (z.B. am Router). Leider bietet PiHole aber bisher von Haus aus nicht die Möglichkeit, die DNS Kommunikation zu verschlüsseln bzw. DoH o.Ä. zu nutzen, weshalb hier Hand angelegt werden muss.

Auf der eigenen PiHole Webseite wird beschrieben, wie man einen DoH Client von Cloudflare (cloudflared) installieren kann.
Zwar kann man theoretisch auch einen anderen Resolver verwenden als Cloudflare, für mich persönlich hatte aber die Firma im Hintergrund bei der Lösung einen bitteren Beigeschmack (siehe Punkt „Firefox“).

Die o.g. Software dnscrypt-proxy ist allerdings so vielseitig einsetzbar, dass auch diese auf einem PiHole funktioniert. Man muss nur beachten, dass der dnscrypt-proxy Daemon nicht auf Port 53 läuft, sondern bspw. auf 5053. Anschließend muss dann der PiHole selbst mit der 127.0.0.1#5053 als Custom Upstream DNS Server in der grafischen Konfiguration eingetragen werden.

Firefox

Seit 2018 experimentiert Firefox mit DoH als implementierte Lösung innerhalb des Browsers, was seit 2019 Bestandteil ist und auch standardmäßig aktiviert wird. Diese Lösung birgt allerdings mehrere Nachteile. Erstens findet die Verschlüsselung der DNS Anfragen nicht auf OS Ebene statt, sprich es werden nur Anfragen aus dem Firefox Browser verschlüsselt. Damit fällt die restliche Kommunikation diverser Anwendungen etc. hinten runter. Zweitens setzt Firefox (bzw. Mozilla) zunächst auf Cloudflare als DNS Resolver, welcher auch von Haus aus eingestellt ist.

Hierbei kommen wir wieder auf das „einer kennt alles“ Problem, zudem die Firma Cloudflare recht fragwürdig ist. Cloudflare wird in der Security/Privacy Szene mittlerweile skeptisch betrachtet, da diese die Benutzerdaten loggen und analysieren. Was das bedeutet kann man zwar nur erahnen, aber lässt höchstwahrscheinlich darauf schließen, dass ein Datentrog exisitiert. Und wo ein Trog ist…
Zusätzlich untersteht das große Unternehmen mit Sitz in San Francisco natürlich der US Administration. Nach einigen Protesten ist man mittlereweile in der Lage eigene Resolver einzutragen, was aber nicht den ersten Nachteil löst, dass DoH nicht systemweit läuft.

Fazit

Das Thema DNS Verschlüsselung wird gerade in heutiger Zeit immer wichtiger. Unabhängig von den sicherheitsrelevanten Aspekten, nützt es auch der digitalen Privatsphäre um es Internetfirmen zu erschweren, personenbezogene Profile für Werbung o.Ä. erstellen zu können.

Ich für meinen Teil setze bisher vollumfänglich auf die Software dnscrypt-proxy mit zusätzlicher Blacklist und wechsel hin und wieder den Resolver. Auf lange Sicht hin wäre es allerdings wünschenswert, wenn die DNS Kommunikation endlich als Standard im Internet verschlüsselt wäre.

---

Datum	Änderung
16.10.2020	Veröffentlichung
07.07.2025	– Wiederveröffentlichung – Veraltete Links entfernt

Auf die Firma Jolla und ihre Hard- bzw. Software wurde ich bereits im Jahr 2013 aufmerksam, als das erste Jolla Phone mit dem hauseigenen OS Sailfish auf den Markt kam und dies breit durch die Medien ging. SailfishOS basiert auf Mer, welches eine Fortführung von MeeGo ist. MeeGo sollte eigentlich (u.a.) in Nokias neuen Smartphones Verwendung finden, was allerdings durch den damaligen Kauf Nokias von Microsoft nicht mehr stattfand (das einzige MeeGo Gerät war das Nokia N9). Im Nachhinein betrachtet eine bedauerliche Entwicklung, denn was hätte aus Nokias bekanntlich guter Hardware mit diesem System werden können…

Hardware

Jolla selbst produziert seit längerer Zeit keine eigene Hardware mehr und ein Test auf einem 7 Jahre alten Gerät kam eher nicht in Frage. Stattdessen kann man nun alternativ unterstützte Hardware und eine SailfishX Lizenz für ca. 50€ erwerben. Nach Erfahrungsberichten in der Community, scheinen die Xperia Geräte von Sony eine gute Wahl zu sein, weshalb ich mich auch für ein XA2 entschied und die Meinung der Community insofern bestätigen kann.

Installation

Die Installation von SailfishX findet fast genauso wie bei einem Android Custom ROM statt. Benötigt wird hier nur fastboot bzw. die Android Tools um sich mit dem Gerät zu verbinden. Einziger Unterschied ist, dass noch ein Unlock-Key auf Basis der IMEI bei Sony abgefragt werden muss, welchen man vor der Installation angibt. Die eigentliche Installation (flashen) findet über ein Shellscript auf Kommandozeile statt, welches aufgerufen wird.
Übrigens ist die Lizenz anschließend an das Gerät gebunden (eigentlich auch an die Person). Ein Weiterverkauf der Lizenz ist also leider nicht möglich.

Design

Sailfish hob sich damals schon von der Masse ab und die Entwickler haben sich scheinbar einige Gedanken zur Bedienbarkeit eines Smartphones ohne Tasten gemacht. Das System war seiner Zeit voraus. Nach einem sehr guten Tutorial ist man eigentlich sofort in der Lage das UI bzw. die eingängige Gestensteuerung zu bedienen. Das Ganze ist dabei auch noch nett anzuschauen. Sailfish ist recht minimalistisch gehalten, was mir persönlich sehr gut gefällt. Der Ansatz laufende Apps auf dem Home-Screen statt im Hintergrund anzuzeigen ist zwar einzigartig, aber bestimmt auch Geschmackssache. Das System kommt von Haus aus mit einigen Themes, sogenannten Ambients, welche sich auch selber erstellen lassen. Über diese Funktion werden auch die Hintergrundbilder verwaltet bzw. geändert.

Basissystem

Das Basissystem ist sehr aufgeräumt und kommt nur mit den notwendigsten bzw. gängigsten vorinstallierten Apps (Kalender, Kontakte, Taschenrechner, Kamera etc.). Von Bloatware ist hier natürlich keine Spur, das System kann individuell „aufgebaut“ werden. Die Einstellungen sind übersichtlich und intuitiv aufgebaut. Ein „verirren“ in den Unterpunkten, wie es mir manchmal bei Android erging, ist hier eher ausgeschlossen. Das System verhält sich in seiner Basis schnell und flüssig. Ruckler, Abstürze, Hänger gibt es hier selten bis gar nicht. Dies kommt nur manchmal (aber in meinem Fall fast gar nicht) bei den Android Apps vor. Die Telefonqualität, welche bei Smartphones gerne mal außer Acht gelassen wird, ist bei Sailfish in Kombination mit dem XA2 meines Erachtens sehr gut.
Auch die vorinstallierte Kamera macht einen soliden Eindruck. Zwar liefert diese nur 16MP, aber für den ein oder anderen Schnappschuss reicht dies vollkommen aus. Wer hier mehr rausholen möchte, kann natürlich auf Drittanbieterapps zurückgreifen. Beim Thema Sicherheit kann das Sailfish noch durch eine Vollverschlüsselung des Systems punkten, welche nach der Installation automatisch aktiv ist.
Ein nicht weiter analysierter Fehler scheint in den Energiesparoptionen zu stecken. Selbst wenn diese gänzlich deaktiviert sind, ist das Gerät nicht mehr nutzbar wenn der Akku unter 10% fällt. Scheinbar wird die CPU dennoch massiv gedrosselt.
Die Akkuleistung bewegt sich in einem normalen Rahmen. Ich kam auf ca. 1-2 Tage.

Apps

Und hier kommen wir zu einem Vor- und gleichzeitig großen Nachteil bei SailfishX. Die native App-Unterstützung ist wie zu erwarten war vergleichsweise mau. Was mich wirklich erstaunt hatte, war das (nicht vorhandene) Angebot an nativen Webbrowsern. Der mitgelieferte Browser ist sehr langsam, was unter anderem an dem Unterbau liegt (Render-Engine Gecko mittels Qt5-Embedding) und es gibt nur sehr wenige Alternativen im Jolla-Store. Das Problem scheint länger bekannt zu sein und nur für das XA2 zu bestehen.

Sofern es native Apps gibt, sind diese allgemein entweder akzeptabel, oder nicht zumutbar. Das trifft bspw. auch auf die Mastodon App „Tooter“ zu. Mir persönlich gefiel das durchsichtige Design nicht und die Bedienung war leider umständlich. Die Verfolgung von zusammenhängenden Toots und das Antworten auf solche ist enorm umständlich. Außerdem meinte Tooter mir nach einiger Zeit immer wieder alle Benachrichtigungen anzeigen zu müssen, auch solche die Tage zurücklagen. Wenn man Toot! unter iOS gewohnt ist, ist Tooter zweifelsohne ein enormer Rückschritt. Auch die populärste OSM App aus dem Jolla Store gehörte in diese Kategorie. Für das nötigste reicht es, wobei die Suche nach einigen Orten keinerlei Ergebnisse lieferte. Für Matrix gab es leider noch nicht einmal eine native App. Bei meinem Ausflug über ein paar Tage hatte ich am Ende lediglich nur noch zwei native alltägliche Apps installiert (KeePass, GhostCloud). Der Rest kam aus dem Android Store bzw. F-Droid.

SailfishX lebt nach meiner Meinung also von der Android App Unterstützung. Diese läuft dafür auch sehr gut. Apps wie Osmand sind tatsächlich performant. Bis der richtige Webbrowser gefunden war, dauerte es allerdings eine Weile, da Firefox Focus bspw. recht langsam ist. Schlussendlich erwies sich Firefox Preview sogar mit uBlockOrigin Addon als gut nutzbar (während Firefox for Android Beta noch das Gegenteil bewies).

Da es den Signal Messenger nativ nicht gibt und dies mein Hauptmessenger ist, musste auch dieser über den Android Store kommen. Signal funktionierte grundsätzlich zwar, aber ein Bug mit Nextcloud und CardDAV sorgt dafür, dass die Kontakte nicht synchronisiert werden. Spiele habe ich abgesehen von Shakes&Fidget, welches einigermaßen ok lief, nicht getestet.

Nextcloud

Seit kurzem hat Sailfish eine im System implementierte Nextcloud Unterstützung, was ein riesiger Pluspunkt ist. So lassen sich direkt Dinge wie Kontakte, Kalender, usw. systemseitig konfigurieren.
Einzig die Möglichkeit mehrere Bilder auf einmal hochzuladen funktioniert leider nicht. Hierfür muss man auf auf die native App GhostCloud zurückgreifen. Die integrierte Datensicherung des Systems, welche allerdings warum auch immer Medieninhalte ausschließt, kann ebenfalls mit Nextcloud out of the box realisiert werden.

Unterbau

Eine der größten Stärken wie bei allen Linux basierten Smartphones ist natürlich der Unterbau und die Möglichkeit diesen auch nutzen zu können. Unter Sailfish läuft ein vollwertiges Linux, dass sich theoretisch nach belieben anpassen lässt. Ein sehr gutes Beispiel ist hier die Nutzung eines eigenen DNS-Proxy.
Ein hilfreicher Tipp für die Nutzung der Linux Kommandozeile ist die native App ShellEx, mit welcher sich schnell Befehle absetzen lassen, welche man auch speichern kann. Das ist z.B. praktisch für die Android-Systemeinstellungen, über die man anders nich drankommt (der Punkt fehlt in den Einstellungen).
Seit Version Sailfish 3.3 wird übrigens auch Flatpak unterstützt.

Nach der Aktivierung der Remote-Verbindung ist der Zugriff auf Sailfish per SSH möglich:

Zusätzliche Software

Das Basissystem kommt stellenweise nur recht spartanisch daher. So fehlt bspw. wget.
Um zusätzliche Software installieren zu können kann man pkcon verwenden, oder zypper nachinstallieren. Für wget reicht aber pkcon vollkommen aus. Als zusätzliche Paketquellen eignet sich openrepos.net. Über diese Seite bin ich auf den User NielDK auf openrepos.net gekommen, in dessen Repo alles notwendige für wget vorhanden ist.

Nachdem man unter den Einstellungen Fremdsoftware erlaubt hat, muss der openrepos.net Hauptschlüssel importiert werden:

rpm --import https://sailfish.openrepos.net/openrepos.key

Das Repo kann man mit ssu hinzufügen und sollte sofort aktiviert (enabled) sein:

ssu addrepo openrepos https://sailfish.openrepos.net/NielDK/personal/main/

Mit „ssu repos“ kann kontrolliert werden, ob das Repo im User-Bereich aktiv ist.
Die Installation von wget erfolgt dann nur noch mit

pkcon install wget

dnscrypt-proxy

Auf allen meinen Systemen läuft mittlerweile dieses kleine Stück Software. Umso erfreulicher fand ich es, dass dnscrypt-proxy ebenfalls auf Sailfish ohne größere Probleme installiert werden kann.

Benötigt wird die arm-Version von dnscrypt-proxy (Version 2.0.44 verlinkt). Voraussetzung für die Installation ist natürlich, dass der Entwicklermodus aktiv ist und man per SSH auf dem Gerät ist.

Vor der Installation bzw. Nutzung muss der vorhandene DNS Proxy connmand deaktiviert werden:

    touch /var/lib/environment/connman/nodnsproxy.conf

    echo "CONNMAN_ARGS=--nodnsproxy" > /var/lib/environment/connman/nodnsproxy.conf

Diese Arbeit übernimmt anschließend dnscrypt-proxy, was noch für die mobilen Verbindungen konfiguriert werden muss. Dies erfolgt über Datei /home/.system/var/lib/connman/settings.
Dort sollte in der [WiFi] Sektion folgende Zeile stehen:

Nameservers=127.0.0.1;

Damit die Einstellungen wirksam werden, kann man connmand mit

systemctl restart connman.service

neustarten.

Die Installation von dnscrypt-proxy unterscheidet sich ansonsten nicht zu anderen Linux basierten Systemen.
Nachdem man die Konfigurationsdatei (dnscrypt-proxy.toml) nach seinen Anforderungen angepasst hat, kann der Dienst installiert und gestartet werden.

Fazit

Ich bin seit 2009 iOS User, allerdings mit einer einjährigen Unterbrechung mit Cyanogen Mod. Ich gebe daher offen zu, dass ich in der Hinsicht ein absolutes Gewohnheitstier bin und einige Vorzüge von iOS genieße. Ein Smartphone ist nun einmal ein alltäglicher Gebrauchsgegenstand und muss oder sollte in manchen Situationen einfach funktionieren. Sailfish ist da nur durch die Android App Unterstützung einigermaßen nah dran. Ohne diese wäre Sailfish nur zum experimentieren und entwickeln geeignet. Einen kleinen bitteren Nachgeschmack hat Sailfish insofern, dass es nur in Teilen Open Source ist. Das kann natürlich an dem Android-System Layer liegen, aber auch an der Exchange Unterstützung, welche Jolla ebenfalls nur bei einem lizensierten SailfishX anbietet.

---

Datum	Änderung
16.10.2020	Veröffentlichung
07.07.2025	– Wiederveröffentlichung – Fazit angepasst