Skip to content

Vaultwarden selbst hosten

linux

Auf mehrfachen Wunsch einer Person beschreibe ich hier einmal, wie ich Vaultwarden selbst hoste. Vaultwarden ist eine nicht offizielle auf Open Source basierende Serverkomponente, mit der sich jeder Bitwarden-Client verbinden lässt. Bitwarden ist der Passwort-Manager, den ich verwende, dazu vielleicht später einmal mehr. Nur so viel an dieser Stelle, der Client ist ebenfalls Open-Source-Software. Er existiert für nahezu jede Plattform und als Plugin / Extension / Addon für die gängigen Browser.

Zunächst habe ich einen User angelegt, unter dem die Serverkomponente laufen soll. Bei mir heisst der User vault.

$ groupadd --gid 201 vault
$ useradd -u 201 -s /bin/bash -g vault -m -k /etc/skel -b /srv vault

Bei mir wird eine Fehlermeldung geworfen, weil die User-ID nicht in der vorgegebenen Range ist, ich ignoriere die. Wenn es Euch wichtig ist, nutzt eine andere ID.

Das Homeverzeichnis des Users liegt unter /srv/vault, wo später auch die Daten liegen werden.

Ich weiss, dass das alles mit Quadlets geht, mir geht aber in der Experimentierphase das ständige Daemon-Reload auf die Nerven, daher wird der Dienst bei mir mit Skripten gestartet und gestoppt und mit dem folgenden systemd-Unit-File automatisiert.

$ cat /etc/systemd/system/vault.service

[Unit]
Description=Vaultwarden
Documentation=https://github.com/dani-garcia/vaultwarden
Requires=network-online.target
After=network.target

[Service]
Restart=on-failure
User=vault
Group=vault
Type=simple
WorkingDirectory=/srv/vault
ExecStart=/srv/vault/start.bash
ExecStop=/srv/vault/stopp.bash

[Install]
WantedBy=multi-user.target

Ach ja, um über Port 443 erreichbar zu sein, benötigen wir noch einen Reverse-Proxy. Da hat sich bei mir Caddy bewährt. Der Eintrag im Caddyfile ist gerade einmal drei Zeilen lang. Caddy sorgt automatisiert für Let's Encrypt-Zertifikate.

$ cat /etc/caddy/Caddyfile

vault.deine.domain {
    reverse_proxy localhost:3201
}

Nach einem Wechsel auf den User vault (su - vault), erstelle ich ein Verzeichnis data und lege die Skripte start.bash und stopp.bash an und mache sie ausführbar. Die "set -o"-Einträge habe ich grundsätzlich in Skripten. Ich benutze Podman für Container und nicht Docker.

Um den Container starten zu können, braucht man noch ein paar User-IDs und die Möglichkeit, dass der Dienst auch laufen kann, wenn der User nicht angemeldet ist. Dass die Zeilen so aussehen, ist reiner Bequemlichkeiteit geschuldet. Da gibt es noch Tuning-Potenzial.

$ grep vault /etc/subuid
vault:100000:65536

$ grep vault /etc/subgid
vault:100000:65536

$ loginctl enable-linger vault
$ cat start.bash

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail

podman ps -a | awk '! /^CONTAINER/ {print $1}' | xargs podman rm || true

podman run --rm \
        --name vaultwarden \
        --env DOMAIN="https://vault.deine.domainr/" \
        --volume /srv/vault/data/:/data/ \
        --publish 127.0.0.1:3201:80 \
        docker.io/vaultwarden/server:latest
$ cat stopp.bash

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail

podman stop vaultwarden

Nach systemctl restart caddy könnt Ihr testen.

Wenn alles richtig ist, sollte nach einer Ausführung von start.bash die Webseite von Vaultwarden aufrufbar sein und Ihr könnt einen Account anlegen. Falls nicht, müssen die Fehlermeldungen behoben werden. Wenn Ihr nicht weiterkommt, meldet Euch bitte.

Für die Automatisierung braucht es ein systemctl daemon-reload und ein systemctl enable --now vault.

Viel Spass!

Huch, vergessen, Ihr braucht ja auch noch die Adminseite unter /admin.

Dazu muss einmal das start.bash-Skript und die Zeile -e ADMIN_TOKEN= ergänzt, die Webseite unter vault.deine.domain/admin aufgerufen, Einstellungen gespeichert und die Zeile danach wieder gelöscht werden.

Achtung: Das beschriebene ist die einfache, unsichere Variante, wie man das Token sicher generiert, ist auf der Vaultwarden-Webseite beschrieben.

Bluefin

bluefin

Die Idee, ein minimales Kernbetriebssystem zu nutzen und darauf aufbauend alles in einer atomaren Art und Weise zu verwalten, hat es mir angetan.

Durch einige Vorträge von Christoph "stoeps" Stoettner habe ich mich von Bluefin anstecken lassen.

Damit mache ich gerade meine ersten Gehversuche. Der Weg zurück zu Gnome fühlt sich auch gut an. Wer es sich lieber mit KDE als Desktop anschauen möchte, dem sei Aurora ans Herz gelegt.

Wichtiger Hinweis: Bluefin zielt nicht darauf ab, jeden Nutzer zufrieden zu stellen. Lest Euch bitte zuerst diese Seite bevor Ihr mit der der Installation startet. Auf der Instllations-Seite sind auch die Hardware-Anforderungen zu finden.

Bluefin versteht sich nicht als Distribution. Die Basis ist Universal Blue.

Schaut Euch doch als Einstieg die Vorträge von Christoph an:

Tuxedo OS

linux

Auf dem bereits erwähnten neuen Notebook ist standardmässig Tuxedo OS installiert.

Die meisten meiner Leser wissen, dass ich "bekennender" Distrohopper bin und gerne neue Distributionen ausprobiere. Wer sich dafür interessiert wird in meiner Computergeschichte sicherlich fündig.

Also warum nicht einmal Tuxedo OS eine Chance geben?

Tuxedo OS basiert auf Ubuntu, aktuell Version 22.04, und hat einige Anpassungen vorgenommen. So wurde beispielsweise Snap herausgeworfen und stattdessen auf Flatpak gesetzt, eine Entscheidung, die ich nur befürworten kann.

Ein eigenes Repository hält die Tuxedo-Pakete mit Treibern, dem Tool Tomte und den Anpassungen, die sie vorgenommen haben, vor.

Als Standard Desktop-Umgebung kommt KDE zum Einsatz (was ich schon seit Jahren nicht mehr verwendet habe). Allerdings muss ich an der Stelle zugeben, dass ich die grafische Oberfläche im Grossen und Ganzen so nehme wie sie ist und keine bzw. kaum eigene Anpassungen vornehme.

Vielen Dank an Vinzenz für den Tipp, die globale Skalierung anzupassen. Das ist sehr hilfreich und macht es mir einfacher, die volle Auflösung zu verwenden.

Mit der Kombination aus Ubuntu, Tuxedo-Repositories und Flatpak konnte ich bis auf wenige Ausnahmen fast alles installieren, was ich zum Arbeiten benötige.

Einige Tools habe ich dennoch "von Hand" mit den passenden Paketen von deren Webseite oder GitHub installiert:

Mit dem Gerät und dem Setup bin ich (bis jetzt) sehr zufrieden und hoffe, dass das auch so bleibt. Momentan denke ich darüber nach, meinen Desktop-Rechner "Terrania" (ebenfalls ein Tuxedo-Gerät( mit Tuxedo OS zu betanken.

Erste Schritte neues Notebook

linux

Am vergangenen Donnerstag ist mein neues Notebook gekommen. Es ist ein TUXEDO InfinityBook Pro 14 - Gen9 - AMD geworden, der Link zeigt auf meine aktuelle Konfiguration. Liebes Tuxedo-Team. es wäre super, wenn die Links auch nach einem Modellwechsel noch funktionieren.

Mir gefällt das Notebook sehr gut, ich werde vielleicht später einmal ausführlicher darauf eingehen.

Erwartungsgemäss brauche ich bei der Maximalauflösung eine Lesebrille, um alles erkennen zu können, ich habe das jetzt vorerst einmal auf 1920x1200 herunter konfiguriert. Das klappt prima. Zweite Beobachtung ist, dass es nur 50 Gramm leichter ist als das InfinitiyBook Pro 16 meiner Frau. Aluminium ist vermutlich schwerer als Plastik.

Das alte Notebook war 8.5 Jahre alt. Ich möchte gerne Tuxedo OS (Basis: Ubuntu) eine Chance geben und damit bin ich nach langer Zeit wieder bei KDE (sonst Arch Linux mit Gnome).

Gerne möchte ich mit Euch teilen, was meine ersten drei Schritte als Systemverwalter und die ersten drei Schritte als User nach der Installation waren. Mich würde es sehr interessieren zu hören, was Eure ersten drei Schritte bei der Einrichtung eines neuen Systems sind.

Als Admin:

  1. etckeeper installieren. Im Rahmen der Konfiguration habe ich ssh-Keys erstellt, ein Repository auf meiner Forgejo.Instanz angelegt und automatischen Push eingerichtet.
  2. Standard-Editor auf Vim ändern.
  3. Backup mit Borg einrichten.

Und als User

  1. Bitwarden als Flatpak installiert und konfiguriert.
  2. Firefox koniguriert und alle Erweiterungen installiert.
  3. Daten vom alten Notebook in ein separates Verzeichnus kopiert. Die Daten nutze ich nur, wenn ich ohne sie nicht weiterkomme. So eine neue Installation ist auch eine gute Möglichkeit, Altlasten aufzuräumen.

Laufzeiten und Produktionsbetrieb von Linux-Distributionen

linux

Mein Kommentar zur Episode Newsupdate 07/23 vom Focus on: Linux-Podcast ist etwas länger geworden, aus diesem Grund habe ich das in einen Blogartikel verpackt.

Prima Episode. Leider muss ich ein wenig Erbsen zählen.

Eine Distribution wird nicht über die komplette Laufzeit (im Podcast war die Sprache von zehn Jahren) produktiv eingesetzt.

Wenn wir uns mal einen mittelprächtig konservativen Ansatz anschauen, dann beginnt man mit dem Testen einer Linuxdistribution ein halbes Jahr nach dem Erscheinen.

Man bringt erste Workloads (Development- und Test-Systeme) darauf, wenn das gut läuft, folgt irgendwann die Abnahmeumgebung und zum Schluss die Produktion. Wenn es gut läuft, sind wir ein Jahr nach dem Erscheinen der Distribution produktiv. Ich habe deutlich progressivere Vorgehensweisen in meiner Berufslaufbahn erlebt, aber deutlich konservativere.

Das oben genannte ist im übrigen der Grund, weshalb es Distributionen mit kurzer Supportzeit gar nicht erst in viele Unternehmen schaffen.

Weil wir Warmduscher sind, wollen wir wenigstens ein Jahr Support übrig haben, wenn wir auf ein neues Release gehen, das bedeutet insbesondere, dass wir 18 Monate vor Supportende mit dem Testen beginnen und das Nachfolgrelease muss dann wenigstens ein halbes Jahr alt sein. Wir können so immer noch zurück, wenn in der Produktion etwas schieflaufen sollte.

In Summe bedeutet das, dass nur acht von zehn Jahren produktiv genutzt werden.

Daten von endoflife.date:

Beispiel Red Hat Enterprise Linux (RHEL):

  • RHEL 7 erscheint Dezember 2013, Laufzeit bis Juni 2024
  • Wir testen ab Juni 2014
  • Produktion ab Dezember 2014
  • Testen Nachfolgerelease ab Dezember 2022
  • Produktion auf dem Nachfolgerelease ab Juni 2023

Wenn wir den Sprung auf RHEL 9 wagen, dann sind wir wieder rund 7,5 Jahre dabei. Glücklicherweise ist RHEL 9 genau passend erschienen. Zufall?

Das gleiche Verfahren mit RHEL 6:

  • RHEL 6 erscheint November 2010, Laufzeit bis November 2020
  • Produktion ab November 2011
  • Testen Nachfolgerelease ab Mai 2019
  • Produktion auf dem Nachfolgerelease ab November 2019

Mai 2019 ist zu früh für RHEL 8, das heisst, wir müssen im November 2019 auf RHEL 7 migrieren und hätten dann nur 4,5 Jahre Laufzeit (bis Juni 2024).

Wenn man sich das einmal so anschaut, ist es nicht mehr "Zehn Jahre Laufzeit müssen für alle reichen ...".

Arch Linux

linux

Irgendwie war es ja auch nur eine Frage der Zeit, dass ich bei meinem Distrohopping auch einmal bei Arch Linux lande. Der Wikipedia-Artikel gibt eine sehr gute Einführung.

Vor einigen Monaten habe ich testweise mein Notebook umgezogen, was ich eh so gut wie gar nicht mehr benötige (ausser, um diesen Artikel zu schreiben und demnächst mal wieder auf einer Konferenz).

Ich bin überrascht, wie gut das läuft. Der Paketmanager ist vermutlich der schnellste, mit dem ich es je zu tun hatte. Alles funktioniert von Anfang an prima. Die Dokumentation im Wiki gehört zu den besten, die es im Linuxumfeld gibt. Ich habe sie schon vor meinem Wechsel relativ häufig zu Rate gezogen.

Woran ich mich gewöhnen muss, ist, dass der Installationsumfang sehr schlank gehalten ist. Das führt dazu, dass ich viel Software, die in anderen Distributionen "einfach so" mitkommt, von Hand nachinstallieren musste.

"Bis jetzt" bin ich begeistert. Mal schauen, wie lange das anhält.

Grund für den Artikel ist, dass ich meinen Hauptrechner migriert habe und ich mich einmal mehr darüber freue, wie leicht ein Distributionswechsel bei Linux ist. Die meiste Zeit benötigt tatsächlich das Kopieren der Daten.

etckeeper

linux

Wenn ich einen Rechner neu installiere, ist etckeeper eines der ersten Programme, die ich einrichte. Es stellt das Verzeichnis /etc unter Versionskontrolle und hilft, alte Konfigurationen wieder herzustellen bzw. die Veränderungen einer Konfiguration über die Zeit zu beobachten. Da es einen "Hook" (bzw. ein "Plugin") für die gängigen Paketmanager mit sich bringt und ausserdem täglich automatisch einen commit durchführt, verrichtet es seine Arbeit sehr schön im Hintergrund. Manuelle commits sind natürlich auch noch möglich.

Dazu muss man einfach etckeeper mit dem Paketmanagementtool installieren und zusätzlich noch Git.

apt install etckeeper git
# oder
dnf install etckeeper git
# oder
zypper install etckeeper git

Danach sorgen die beiden folgenden Befehle für die Initialisierung. Wenn man nicht mehr möchte, ist danach alles eingerichtet.

etckeeper init
etckeeper commit -m "Initial"

Bei meinen Systemen gehe ich noch einen Schritt weiter und übertrage die commits auf ein Remote-Repository ("git push"). Dazu legt man sich "irgendwo" ein Git-Repository an und nutzt die folgenden Befehle, um das Repository mit der lokalen etckeeper-Installation zu verheiraten. Aller Wahrscheinlichkeit nach gibt es noch keinen ssh-Key für den root-User der muss natürlich vorgängig erstellt werden. Ich würde diesen Key nur für das Pushen des Repositories verwenden und auf ein Passwort verzichten

ssh-keygen -t ed25519

git remote add origin ssh://user@provider/project/repository.git
git push -u origin master

Abschliessend muss noch in der /etc/etckeeper/etckeeper.conf das Remote-Repository bekannt gegeben werden, damit wird dann auch automatisch gepusht.

PUSH_REMOTE="origin"

systemd user services

linux

Bei uns in der Firma ist es so, dass es auf virtuellen Maschinen eine strikte Trennung der Plattform von den Applikationen gibt. Wir sind für die Plattform verantwortlich und Applikationsteams für ihre Anwendungen.

Damit die Applikationsteams in der Lage sind, Ihre Dienste via systemd zu verwalten (Start, Stopp, Logs anschauen, etc.) erstellen wir systemd-Services und berechtigen die Applikationsteams mit entsprechenden sudo-Regeln.

Allerdings bietet systemd Benutzern die Möglichkeit, Dienste unter eigener Regie zu verwalten. Das geht vom Anlegen des Dienstes bis zu den Dingen, für die es vorher sudo-Regeln brauchte.

Einrichtung

Um systemd-User-Services für einen User zu aktivieren, muss im Hintergrund ein Prozess gestartet werden, der die Dienste verwaltet. Tut man das nicht, werden Dienste des Users bei der Abmeldung vom System gestoppt.

# loginctl enable-linger <user>

Im Homeverzeichnis des Users liegen die Servicedefinitionen unter ~/.config/systemd/user/NAME.service.

Im Service selber muss braucht es die folgenden Zeilen, damit die Dienste auch automatisch gestartet werden können. Andere Einstellungen sind auch möglich, aber ich habe herausgefunden, dass es wenigstens den einen Eintrag braucht.

[Install]
WantedBy=default.target

Der User muss in seine .bashrc die folgende Variable setzen, wenn sie nicht schon durch das System zur Verfügung gestellt wird.

# ~/.bashrc

export XDG_RUNTIME_DIR=/run/user/$(id -u)

Verwaltung der Dienste

$ systemctl --user enable NAME.service
$ systemctl --user start NAME.service
$ systemctl --user stop NAME.service
...
$ journalctl --user -u NAME.service
...

Weiterführende Links:

Applikationen unter Linux am Beispiel CentOS

centos Aus CentOS 8 wird CentOS Stream.

Über die Meldung, dass CentOS 8 zugunsten von CentOS Stream einstellt, habe ich mich sehr geärgert. Ich war sogar richtig gehend angepisst.

CentOS war immer die Möglichkeit, eigene Dinge auf Red Hat Kompatibilität zu testen, ohne Subskriptionskosten (für das Patching) bezahlen zu müssen.

Leider hat es das CentOS-Team mit der Version 8 nicht geschafft, zeitnah auf Updates und Hotfixes durch Red Hat zu reagieren und ist aus diesem Grund auch nicht mehr meine Distribution der Wahl. Mein Kram wird im Lauf der nächsten Wochen und Monate auf Ubuntu LTS migriert.

Machen wir uns aber bitte nichts vor. CentOS ist keine "schöne" Linux-Distribution. Das Tooling ist nicht so berühmt. Durch die lange Unterstützung und die durch Red Hat versprochene API-Kompatibilität über die ganze Laufzeit veraltet Software in Red Hat Enterprise Linux (RHEL) und damit auch in CentOS sehr schnell. (Gilt übrigens für andere paketbasierte Distributionen im gleichen Mass, die helfen sich nur mit häufigeren Releases).

RHEL (CentOS) möchte man eigentlich nur aus genau einem Grund einsetzen, nämlich, dass nahezu jede Business-Software für RHEL zertifiziert wird. Und aufgrund der versprochenen Kompatibilität ist es nahezu garantiert, dass sie auch über die komplette Laufzeit das Major-Releases von zehn Jahren bzw. 13 Jahren mit extended Support auch lauffähig bleibt.

Wenn man aktuelle Open-Source-Software auf CentOS einsetzen möchte, so konnte man sich nur dadurch behelfen, dass man entweder darauf vertraut hat, dass die irgendwann in den Software-Kollektionen aufgeschlagen ist, da wurde sie dann "neben" der Basisinstallation installiert oder dass man externe Repositories verwendet hat. Bei meinen Servern habe ich beispielsweise PHP aus den Remi Repositories, sowie Docker und MariaDB direkt vom Hersteller bezogen.

Das hat auch Red Hat erkannt und mit Version 8, Modules oder "Application Streams" eingeführt. Hier gibt es eine sehr gute englischsprachige Erklärung dazu. Kurz zusammengefasst, lassen sich mit diesem Konzept mehrere Versionen der gleichen Software parallel installieren und auch benutzen.

Vermutlich hat dieses neue Konzept die Ressourcen vom CentOS-Projekt gesprengt, ich habe keinen Beweis für diese Vermutung. Für mich ist dieses Konzept aber nur ein Zwischenschritt auf dem Weg, das Basis-Betriebssystem komplett vom Applikationsteil zu trennen.

Im Grossen und Ganzen: Kernel, Netzwerk, Infrastruktur (Backup, Authentifizierung, ...) macht die Distribution und den ganzen Rest können Applikationen alleine besser.

Wenn wir die Distributionen nur als stabile Basis ansehen, auf der wir Dienste mit den Hersteller-Repositories (Docker, MariaDB, ...) oder Snaps, Flatpaks und AppImages oder Containern (Docker, Podman, ...) aufsetzen, dann würden wir allem gerecht werden.

Es entspricht einer Trennung von Applikation und Plattform, die in vielen Firmen trotz DevOps immer noch betrieben wird. DevOps bezieht sich im Grossen und Ganzen auch mehr auf Applikationsentwicklung und -betrieb. DevOps (oder EngOps) für die Plattformentwicklung ist davon getrennt.

Wenn wir diese Sichtweise weiterspinnen, werden paketbasierte Linuxdistributionen obsolet.

Wohin das in Summe führen kann, sehen wir mit Kubernetes (und OpenShift) oder durch den Einsatz von Containern (mit Docker oder Podman oder ...).

Kubernetes ist es egal, auf welchem linuxbasierten OS es läuft, wenn die Voraussetzungen gegeben sind. Den Leuten, die Kubernetes benutzen (nicht verwalten), ist die komplette Infrastruktur darunter egal, so lange das Cluster zur Verfügung steht.

Und, die alten erinnern sich, das hatten wir schon einmal, aber nicht ganz so ausgereift.

Java hat den Ruf (weitestgehend) plattformunabhängig zu sein. Klar, dafür muss man mit der Runtime (JRE) oder dem JDK auch ein halbes OS mitinstallieren. Darauf kann man Applikationsserver wie Tomcat, JBoss, Weblogic, Websphere, ... betreiben und auch da gab es das Versprechen, sich nicht um die darunter liegenden Schichten kümmern zu müssen.

Meiner Meinung nach wurde dieses Versprechen nie komplett eingelöst, obwohl sehr viele gute Konzepte vorhanden waren.

Mit Containern und Orchestrierungslösungen sind wir aber der Erfüllung dieses Versprechens einen Schritt näher gekommen.

Bin an Euren Meinungen und einer Diskussion darüber sehr interessiert.

Server OS LifeCycle

linux

Meine Server laufen seit etwa fünf Jahren unter CentOS 7. In der Zeit gab es ordentlich Updates und tatsächlich keine Probleme, die auf der Software basierten.

Eigentlich läge damit CentOS 8 als neues Betriebssystem für die Server nahe. Allerdings schreibt schon Michael Kofler, dass CentOS 8 über sechs Wochen ohne Updates war und wirft Oracle Linux in die Waagschale.

Das hört sich auf den ersten und zweiten Blick komisch an, ist es auch. Aber Oracle bietet sein Linux als FLOSS-Lösung an, die gratis ist, solange man kein System hat, bei dem man für den Support durch Oracle bezahlt. In dem Fall werden alle Instanzen kostenpflichtig. Komisches Modell, oder?

Nebenbei: Ich nutze sehr gerne VirtualBox, ebenfalls von Oracle, da muss man aufpassen, dass sich die Lizenzbestimmungen mit der Nutzung des Extension Packs ändern.

Also, was tun?

Der Vorteil von CentOS war und ist, dass es sehr lange (rund zehn Jahre) unterstützt wird und tatsächlich bin ich auch noch nicht in der Not zu wechseln. Der Support für CentOS 7 läuft erst am 30. Juni 2024 (Tabelle) aus, also erst in viereinhalb Jahren. Der Nachteil ist, dass CentOS über die Lebenszeit garantiert, API-kompatibel zu bleiben, was zum Teil in sehr alter Software resultiert (Tabelle bei DistroWatch. Das wiederum bedeutet, dass man reichlich Fremdrepositories verwenden muss - bei mir EPEL, die Remi-Repostitories für PHP und Repos für MariaDB - um halbwegs aktuelle Webanwendungen betreiben zu können. Das Web ist voll von Fragen, wie man eine bestimmte Software unter CentOS zum Laufen bekommt.

Also Plan A ist, bei CentOS zu bleiben. Die "Synergien" zwischen dem, was ich beruflich mache(n muss), nämlich Red Hat Enterprise Linux zu betreiben, und dem, was ich dann privat mache, sind schon sehr gross. Bedingung dafür wäre, dass es regelmässiger Updates gibt.

Plan B wäre, die Distribution zu wechseln, hier bieten sich quasi sofort Ubuntu und Debian an, wobei ich im Fall eines Wechsels zu Debian tendieren würde.

Es gibt natürlich noch einen Plan C, das wäre ein Docker (bzw. Podman) basiertes Setup. Mich würde sehr reizen, das mit Alpine Linux als Basis zu versuchen. Eine Alternative könnte sogar Fedora Core OS sein.

Kein Plan D, aber eine interessante Alternative könnte tatsächlich Fedora in der Server-Variante sein. Allerdings sind die Wechsel zwischen den halbjährlichen Releases schon sehr drastisch und bedürfen der ständigen Nacharbeit (vermute ich). Fedora auf dem Desktop ist super (langweilig), das funktioniert einfach richtig gut, selbst mit aktiviertem SELinux sind keine Nacharbeiten nötig.

Jetzt Ihr. Was wären Eure Empfehlungen? Viel wichtiger als "was" wäre mir das "warum" Ihr ein bestimmtes Server-OS empfehlt. FreeBSD oder OpenBSD wären auch noch nachdenkenswerte Varianten.

Region Settings ...

fedora Das bezieht sich jetzt nicht nur auf XFCE, aber da ist es mir aufgefallen ...

XFCE bietet keinen Dialog, um die Region-Settings anzupassen, ich habe gerne mein System in Englisch und die Regionaleinstellungen auf Deutsch oder der Schweizer Variante von Deutsch (Uhrzeit im 24 Stunden Format, Dezimaltrenner, ...).

Die Einstellungen kann man in der Datei /etc/locale.conf vornehmen, standardmässig ist nur die erste Zeile gesetzt:

LANG="en_US.UTF-8"
LC_COLLATE="de_CH.UTF-8"
LC_CTYPE="de_CH.UTF-8"
LC_TIME="de_CH.UTF-8"
LC_NUMERIC="de_CH.UTF-8"
LC_MESSAGES="en_US.UTF-8"


Weitere Informationen dazu gibt es unter System Locale and Keyboard Configuration.

Da ich das nur auf Desktop-Systemen so mache, bin ich noch nie darüber gestolpert.

Nextcloud-Client unter XFCE ...

fedora Ich habe den Nextcloud-Client aus den Fedora-Repositories installiert, Fedora liefert Version 2.5.2 aus.

Leider musste ich nach jedem Neustart den Login und das Passwort für die drei Accounts, die ich synchronisiere, neu eingeben, was ziemlich nervig ist.

Das Paket libgnome-keyring schafft da Abhilfe.
$ sudo dnf install libgnome-keyring

Neues Tablet ...

android Seit dem 30. April besitze ich ein neues Tablet, es ist ein Samsung Galaxy Tab S5e mit Book Cover Keyboard (ich habe leider keinen Link dazu auf den offiziellen Seiten) geworden.

Interessant, dass es knapp 14 Monate gedauert hat, ein Ersatz für mein altes Tablet zu finden, Details zum Verlust des alten Tablets hier. Wider Erwarten ist es doch ein Samsung Tablet geworden. Der Markt für Android Tablets mit Displays um 10 Zoll oder grösser ist halt relativ beschränkt.

Die Zeit habe ich mit einem iPad Pro (12.9 Zoll, 2. Generation), was mir gute Dienste geleistet hat, aber sehr einschränkend ist, wenn man die Freiheit unter Android gewohnt ist. So lassen sich aufgrund von Restriktionen im Apple Store beispielsweise keine Plugins in Firefox installieren oder Firefox als Default-Browser des Systems nutzen.

Das User Interface des Tablets ist ... nun ja ... bunt und sehr gewöhungsbedürftig. Das Display ist klasse und gestochen scharf. Die Tastatur ist unerwartet gut, ich muss nur noch meine grossen Hände trainineren, damit umzugehen, aber das Tippen geht - mit gelegentlichen falschen Tastendrücken - gut "von der Hand".

Die Grösse des Geräts ist prima, aber das Gewicht ist gefühlt höher als ich gedacht habe.

(Ich finde gerade spannend, dass mein Tablet mit Tastatur, mein Handy und meine "not so smart" Watch in Summe weniger kosten als das Handy eines Arbeitskollegen).

Zurück auf liquidprompt ...

linux Nachdem ich jetzt rund 1,5 Jahre Powerline genutzt habe, bin ich mit der Neuinstallation zurück auf Liquidprompt gewechselt.

Es gibt drei Gründe dafür: Zum Einen ist Liquidprompt deutlich schneller als Powerline und das merke ich sofort. Zum Anderen merkt man Powerline an, dass es "eigentlich" für die ZSH gemacht wurde und die Bash, na ja, rudimentärer unterstützt wird, weil sie vermutlich deutlich weniger Möglichkeiten für den Prompt bietet als ZSH. Weiterhin ist die Konfiguration deutlich einfacher ...

Wermutstropfen ist, dass das Projekt Liquidprompt nur sehr langsam bis gar nicht weiterentwickelt wird. Die ältesten nicht gelösten "Issues" sind knapp sieben Jahre alt.

Aber es tut seinen Job und das sogar sehr schnell und gut.

Fedora 30 ...

fedora Trotz der wirklich guten Erfahrungen, die ich mit dem Update von Fedora gemacht habe, habe ich mit der Version 30 - "aus Gründen" - eine komplette Neuinstallation gemacht.

Neben der "Datenhygiene" war dieses Mal der Grund, dass ich das Desktop Environment von KDE nach XFCE gewechselt habe.

Einer der Hauptgründe ist, dass ich kaum KDE-eigene Programme genutzt habe und gefühlt jede Tastenkombination mit einer Funktion belegt ist. XFCE ist deutlich schlanker, was die Menge der mit installierten Software betrifft und der weitgehende Verzicht auf Desktop Effekte macht die Arbeit gefühlt schneller.

Ich will nicht verhehlen, dass ich verärgert darüber bin, dass sich bei Borgbackup ein alter Fehler eingeschlichen hat, interessanterweise hat die Installation via pip in einem "Virtual Environment" auch nicht funktioniert. Wenn ich wieder zu Hause bin, werde ich einen Bugreport erstellen.

Am Rande bemerkt, bei Linux ist so etwas relativ leicht machbar.
cronjob