Dirks Logbuch (Artikel mit Tag linux)

Vaultwarden selbst hosten

nospam@example.com (Dirk Deimeke) — Tue, 20 Jan 2026 06:49:00 +0100

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

nospam@example.com (Dirk Deimeke) — Thu, 31 Jul 2025 06:05:00 +0200

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

nospam@example.com (Dirk Deimeke) — Thu, 10 Oct 2024 18:03:00 +0200

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:

Citrix Workspace (falls ich mal etwas für die Firma tun muss)
Espanso für die ganzen Standard-Floskeln
Fastfetch, weil ich kann
Hugo für zwei Blogs, die ich damit betreibe
Mullvad VPN spricht für sich
tmux-xpanes erleichtert die Arbeit mit mehreren Maschinen und tmux

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

nospam@example.com (Dirk Deimeke) — Sun, 15 Sep 2024 12:11:00 +0200

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:

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

Und als User

Bitwarden als Flatpak installiert und konfiguriert.
Firefox koniguriert und alle Erweiterungen installiert.
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

nospam@example.com (Dirk Deimeke) — Fri, 04 Aug 2023 15:54:00 +0200

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

nospam@example.com (Dirk Deimeke) — Tue, 26 Jul 2022 05:19:00 +0200

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

nospam@example.com (Dirk Deimeke) — Tue, 14 Dec 2021 07:29:00 +0100

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

nospam@example.com (Dirk Deimeke) — Tue, 23 Nov 2021 05:45:00 +0100

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:

LanguageTool

nospam@example.com (Dirk Deimeke) — Tue, 09 Nov 2021 11:37:00 +0100

Schon seit längerem setze ich LanguageTool zur Grammatik- und Rechtschreibprüfung ein und es hat mir mehr als einmal geholfen, halbwegs korrekte Texte zu verfassen.

Das Tool besteht aus einem Plugin für gängige Software, wie beispielsweise Webbrowser und Textverarbeitung und einer Serverkomponente, die man selber hosten kann oder die in "der Cloud" (tm) liegt. Momentan schreibe ich zu wenig, als dass sich ein Premium-Account für mich lohnen würde, allerdings bietet dieser zusätzliche Features.

Bei mir kommen beispielsweise die Plugins für Firefox und LibreOffice zum Einsatz. Für LaTeX setze ich das Visual Studio Code Plugin LanguageTool Extension und die dazu passenden Sprachen Deutsch und Englisch ein. Achtung: der Autor der VSCode-Extensions ist leider verstorben und daher werden sie nicht weiterentwickelt. Momentan funktionieren sie aber noch sehr gut. Für Thunderbird gibt es übrigens auch ein Plugin, was ich allerdings nicht getestet habe, weil ich kein Thunderbird benutze.

Wenn man den Server lokal betreiben will - das mache ich auf allen meinen Linux-Clients - benötigt man ein installiertes Java und den LanguageTool embedded HTTP Server, den man sich unter diesem Link herunterladen kann.

Ein aktuelles Java, kann man sich von der Webseite des OpenJDK-Projektes herunterladen.

Installation Java.

cd ~/Downloads

curl -LO https://download.java.net/java/GA/jdk17.0.1/2a2082e5a09d4267845be086888add4f/12/GPL/openjdk-17.0.1_linux-x64_bin.tar.gz

tar xzf openjdk-17.0.1_linux-x64_bin.tar.gz

ln -s jdk-17.0.1 java

Anmerkung: Wenn ein aktuelleres oder anderes Java benutzt werden soll, muss man einfach den Link umsetzen.

Funktionstest.

export JAVA_HOME=~/Downloads/java

export PATH=${JAVA_HOME}/bin:${PATH}

java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-39)
OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing)

Installation LanguageTool-Server.

cd ~/Downloads

curl -LO https://languagetool.org/download/LanguageTool-5.5.zip

unzip LanguageTool-5.5.zip

ln -s LanguageTool-5.5 LanguageTool

Sollte die aktuelle Version mit einem Plugin oder einer Extension nicht funktionieren, so findet man vorhergehende Versionen auf der Download-Seite.

Funktionstest.

Für den Funktionstest würde ich gleich ein Start-Skript - hier ~/Downloads/LanguageTool.bash - schreiben, dass man später auch für das automatische Starten des Servers via systemd verwenden kann.

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

export JAVA_HOME=~/Downloads/java

cd ~/Downloads/LanguageTool

${JAVA_HOME}/bin/java -cp languagetool-server.jar \
org.languagetool.server.HTTPServer --port 8081 --allow-origin "*"

Getestet wird mit dem folgenden curl-Aufruf, der JSON zurückliefert.

curl --noproxy localhost -d "language=en-US" -d "text=a simple test" http://localhost:8081/v2/check

{"software":{"name":"LanguageTool","version":"5.5","buildDate":"2021-10-02 12:33:00 +0000","apiVersion":1,"premium":false,"premiumHint":"You might be missing errors only the Premium version can find. Contact us at support<at>languagetoolplus.com.","status":""},"warnings":{"incompleteResults":false},"language":{"name":"English (US)","code":"en-US","detectedLanguage":{"name":"French","code":"fr","confidence":0.815771}},"matches":[{"message":"This sentence does not start with an uppercase letter.","shortMessage":"","replacements":[{"value":"A"}],"offset":0,"length":1,"context":{"text":"a simple test","offset":0,"length":1},"sentence":"a simple test","type":{"typeName":"Other"},"rule":{"id":"UPPERCASE_SENTENCE_START","description":"Checks that a sentence starts with an uppercase letter","issueType":"typographical","category":{"id":"CASING","name":"Capitalization"}},"ignoreForIncompleteSentence":true,"contextForSureMatch":-1}]}

Automatisches Starten mit systemd.

Erstellen der Datei /etc/systemd/system/LanguageTool.service mit folgendem Inhalt ("EuerUser" und "EuerHome" müssen ent1sprechend ersetzt werden). Zu systemd-user-services mache ich einmal einen separaten Artikel.

[Unit]
Description=LanguageTool
Wants=network.target
After=network.target

[Service]
User=
Type=simple
Restart=on-failure
RestartSec=10s
ExecStart=/Downloads/LanguageTool.bash
WorkingDirectory=/Downloads/LanguageTool

[Install]
WantedBy=multi-user.target

Aktivieren des Services.

sudo systemctl daemon-reload
sudo systemctl enable --now LanguageTool

sudo systemctl status LanguageTool

Viel Spass!

Disk Performance

nospam@example.com (Dirk Deimeke) — Thu, 25 Mar 2021 13:19:00 +0100

Der neue Rechner ("terrania") ist mittlerweile da und läuft.

Die Performance NVMe vs. SSD beim fünf Jahre alten Notebook ("crest") ist schon beeindruckend:

$ grep IOPS crest.rand*
crest.randread.txt: read: IOPS=94.5k, BW=369MiB/s (387MB/s)(4096MiB/11096msec)
crest.randrw.txt: read: IOPS=63.4k, BW=248MiB/s (260MB/s)(3070MiB/12391msec)
crest.randrw.txt: write: IOPS=21.2k, BW=82.8MiB/s (86.8MB/s)(1026MiB/12391msec); 0 zone resets
crest.randwrite.txt: write: IOPS=66.6k, BW=260MiB/s (273MB/s)(4096MiB/15734msec); 0 zone resets

$ grep IOPS terrania.rand*
terrania.randread.txt: read: IOPS=391k, BW=1528MiB/s (1602MB/s)(4096MiB/2681msec)
terrania.randrw.txt: read: IOPS=254k, BW=992MiB/s (1040MB/s)(3070MiB/3094msec)
terrania.randrw.txt: write: IOPS=84.9k, BW=332MiB/s (348MB/s)(1026MiB/3094msec); 0 zone resets
terrania.randwrite.txt: write: IOPS=117k, BW=458MiB/s (480MB/s)(4096MiB/8939msec); 0 zone resets

Es werden drei Tests durchgeführt: "random read", "random read/write" (75% read, 25% write) und "random write". Spannend ist, dass das Lesen generell vier Mal schneller ist, vom alten zum neuen Rechner. Im Mix ist auch das Schreiben vier Mal schneller. Beim ausschliesslichen Schreiben ist der Neue aber "nur" noch knapp doppelt so schnell.

Als Tool kommt fio - Flexible IO Tester zum Einsatz. Wenn jemand eine bessere URL kennt, nur her damit. FIO ist in den meisten Distributionen enthalten.

Über synthetische Tests kann man natürlich geteilter Meinung sein, die Werte geben aber einen guten Anhaltspunkt für Vergleiche.

Ich benutze dieses kleine Skript, um die Daten zu sammeln.

#!/bin/bash

echo randrw
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 --output=$(hostname --short).randrw.txt --output-format=normal
[[ -r test ]] && rm test
echo

echo randread
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randread --output=$(hostname --short).randread.txt --output-format=normal
[[ -r test ]] && rm test
echo

echo randwrite
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite --output=$(hostname --short).randwrite.txt --output-format=normal
[[ -r test ]] && rm test
echo

Rolle von Linux Distributionen

nospam@example.com (Dirk Deimeke) — Mon, 15 Feb 2021 05:12:00 +0100

Ich weiss, dass das eine streitbare Meinung ist und bin auf Eure Ansichten gespannt.

Meiner Meinung werden Distributionen zunehmend keine Rolle mehr spielen.

Meine privaten Server laufen auf CentOS 7 und ich werde sie auf Ubuntu 20.04 migrieren.

Um aktuelle Applikationen unter CentOS betreiben zu können, habe ich zusätzliche Repositories aktivieren müssen. Andere Applikationen - es sind genau zwei - betreibe ich mit Containern unter Docker, wohlgemerkt nicht das Docker aus CentOS, sondern die Community-Edition von Docker selber. Weitere Repos sind die Remi-Repositories (für PHP), EPEL und MariaDB. Ja, ich kenne die Software Collections, ich habe aber vom Einsatz abgesehen, weil sie sich nicht so "sauber" in das System integrieren, wie die anderen Repos.

Zwischenfazit: Je länger die Laufzeit einer Distribution ist, desto mehr "Kunstgriffe" muss man unternehmen, um aktuelle Applikationen betreiben zu können. Das bedeutet im Umkehrschluss, dass von der Basis-Distribution immer weniger "übrigbleibt".

Jetzt ist es aber so, dass auch nicht alle Applikationen mit neueren Paketversionen zurechtkommen. Meine Blogsoftware tut sich beispielsweise mit neuen PHP-Versionen schwer, das Entwicklungsteam ist einfach zu klein. Das führt dazu, dass man mindestens zweigleisig fahren muss.

In der Firma setzen wir Red Hat Enterprise Linux ein, weil es die Distribution mit den meisten Zertifizierungen für Business-Software ist. Einer der Gründe dafür ist, dass die Firma über einen langen Zeitraum API-Kompatibilität garantiert. Das ist für Business-Software toll, für aktuelle "Free/Libre Open Source Software" (FLOSS) oder Eigenentwicklungen aber nicht.

Das führt unter anderem dazu, dass wir den Applikationen beibringen, dass sie ihre Applikation bitte möglichst unabhängig vom Basisbetriebssystem betreiben sollen, um von unseren Patchzyklen unabhängig zu sein. Wir würden gerne häufiger Patchen, aber wir bekommen die Downtimes nicht. Bei uns durchlaufen die Patches auch die verschiedenen Betriebsstufen und müssen wenigstens zwei Monate in Acceptance sein bevor sie in Produktion gehen.

Wenn ich die Zeit hätte, würde ich privat auf Alpine Linux wechseln und alles mit Containern betreiben, im Basis-OS würde dann nur ein Reverse-Proxy (Caddy, beispielweise) und vielleicht die Datenbanksoftware laufen.

Das gilt für den Desktop in einem ähnlichen Mass. Da kommt zum Basisbetriebssystem noch die Desktopumgebung dazu, die vielleicht von "der Distribution" bereitgestellt wird. Applikationen kommen mehr und mehr in Distribution-übergreifenden Formaten wie Snaps, Flatpaks oder AppImages.

Die Kehrseite ist, dass wir dadurch von Unix-Errungenschaften wie Shared Libraries Abstand nehmen und das Patching dadurch ungleich aufwendiger wird. Bei einer Schwachstelle in einer Shared Library muss ich sie nur ein Mal patchen, bei Containerformaten, gekapselten Applikationen und autonomen Anwendungen muss ich jede einzelne Instanz aktualisieren (lassen).

Der Gewinn ist ungleich grösser, wenn Anwendungen - wie oben beschrieben bereitgestellt werden - laufen sie auf jeder Distribution, die die Laufzeitumgebung zur Verfügung stellt. Das wiederum beschert den Entwicklern die Möglichkeit, ihre Anwendung für alle Distributionen gleichzeitig bereitstellen zu können.

In Summe führt das dazu, dass das Basis-Betriebssystem nur noch sehr klein sein muss und eine deutliche kleinere Rolle als bisher spielt.

Bildschirm teilen mit Jitsi unter Fedora

nospam@example.com (Dirk Deimeke) — Wed, 25 Mar 2020 10:28:00 +0100

Fedora setzt als Default Wayland als Display-Server Protokoll ein. Leider funktioniert damit das Teilen des Bildschirms via Jitsi nicht.

Um das Protokoll - zumindest für diese Zeit mit vielen Videokonferenzen - auszuschalten, genügt es, Wayland in der Datei /etc/gdm/custom.conf auszuschalten, so dass wieder X11 verwendet wird. Danach muss die Maschine neu gestartet werden.

WaylandEnable=false

Server OS LifeCycle

nospam@example.com (Dirk Deimeke) — Mon, 10 Feb 2020 13:31:00 +0100

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.

Zurück auf liquidprompt ...

nospam@example.com (Dirk Deimeke) — Sat, 04 May 2019 06:05:00 +0200

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

nospam@example.com (Dirk Deimeke) — Thu, 02 May 2019 05:50:00 +0200

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.

devLUG ...

nospam@example.com (Dirk Deimeke) — Sun, 28 Apr 2019 11:55:00 +0200

Diesen Beitrag möchte ich gerne einmal nutzen, um über die devLUG zu informieren.

Die devLUG ist eine deutschsprachige "virtuelle" Linux User Group mit realen Menschen (deshalb ist das "virtuell" in Anführungszeichen).

Das Ziel der devLUG ist die Erstellung, Verbreitung und Förderung von Free/Libre Open Source Software (kurz FLOSS), insbesondere aber nicht ausschliesslich im Zusammenhang mit LinuxÂbasierenden Betriebssystemen und Distributionen.

Um dieses Ziel zu erreichen, bedient sich der Verein moderner Kommunikationsmittel, die auf Verbindungen über das Internet basieren.

Wir sind in der devLUG an einen Punkt gekommen, ernsthaft über eine Vereinsgründung nachzudenken. Ohne die Gründung kommt es immer wieder zu Situationen in denen es aus verschiedenen auch rechtlichen Gründen nicht weitergeht.

Selbstverständlich bringt die Gründung eines - vielleicht sogar gemeinnützigen - eingetragenen Vereins einige Nachteile mit sich, jedoch denken wir, dass die Vorteile für die devLUG überwiegen.

Die "Aktiven" unter uns haben sich schon mal Gedanken gemacht, was sie in der devLUG sehen und was das Ziel sein soll.

Aktivitäten rund um Linux und FLOSS (Free/Libre Open Source Software), Nutzung von digitalen Möglichkeiten zur Kommunikation, Aktivitäten können Workshops, Anleitungen, Hilfe (zur Selbsthilfe), Podcasts, ... sein. Ziel ist es von und miteinander zu lernen, Linux User Groups im deutschsprachigem Raum miteinander zu vernetzen, Synergien zu nutzen, dezentrale Strukturen aufzubauen.

Wir wollen versuchen, uns kleine Ziele zu setzen welche auf virtuellen Stammtischen besprochen werden können. Dies können kleine online Workshops sein oder vieles andere mehr.

Wenn jemand Interesse an der Gründung eines Vereins für die virtuelle Linux User Group hat, kann sich einfach hier melden oder uns im IRC-Kanal #devlug aufFreenode (hinter dem Link verbirgt sich ein Webchat) vorbeischauen.

Einen Stammtisch gibt es auf Freenode in dem angegebenen Kanal, jeweils um 20:30 Uhr und alle zwei Wochen im Wechsel Dienstag / Donnerstag. Die nächsten Termine sind: 30. April, 16. Mai, 28. Mai, 13. Juni. Generell gibt es aber immer jemanden, der im Freenode-Kanal #devlug ansprechbar ist. Wir freuen uns auf Euren Besuch.

Ein Friendica-Forum wartet ebenfalls auf Euren Besuch.

Mein Arbeitsplatz ...

nospam@example.com (Dirk Deimeke) — Wed, 06 Feb 2019 05:20:00 +0100

Systemadministrator (aktueller "Jobtitel Senior System Engineer Linux/Unix") bin ich schon relativ lange und so lange ich diesen Job mache, so lange schraube ich und verbessere mein Arbeitssetup.

Das berufliche "Virtual Desktop"-Betriebssystem ist leider Windows, aktuell in der Version 10, via Thin Client, wobei ich bis auf Mailclient und Webbrowser (via SSL Interception Proxy) nur Zugriff auf die Linux- und Solaris-Infrastruktur benötige.

Dafür habe ich sehr vieles ausprobiert. Wir haben einen Remote Desktop mit NoMachine, den ich lange genutzt habe - vor allem, da ich ihn auch über beide Monitore strecken kann - aber so richtig warm geworden bin ich damit nicht. In einem anderen Kontext nutzen wir xrdp und auch X2Go habe ich getestet. Auf der Gegenseite läuft jeweils ein Red Hat Enterprise Linux 7 mit KDE 4 als Desktop (privat bin ich auf Fedora 29 mit KDE Plasma).

Nach allem Hin und Her bin ich mittlerweile bei PuTTY und - falls ich wirklich einmal (sehr selten) Grafik brauche - XMing, das reicht für mich völlig aus.

In PuTTY gibt es vier Settings, die ich jedem empfehlen möchte, der ernsthaft damit arbeitet.

Unter Window / Behaviour habe ich "Full screen und Alt-Enter" gesetzt, damit lässt sich PuTTY in einem rahmenlosen Vollbild-Fenster betreiben.
Unter Window / Selection ist die "Action of mouse buttons" auf "xterm (Right extends, Middle pastes)" gesetzt. Ihr wisst schon ... alter Sack ... Schwierigkeiten umzugewöhnen ... besser es funktioniert so wie auf jedem gewohnten Linux Desktop.
Ebenfalls unter Windows / Selection gibt es den Punkt "Paste to clipboard in RTF as well as plain text" - gerade in Verbindung mit Outlook als Zwangsclient hilft das sehr, formatierte Dinge (inklusive Farben) aus der Shell zu pasten.
Unter Connection / SSH / X11 muss natürlich "Enable X11 forwarding" eingeschaltet sein, sonst wird das nichts mit XMing.

Apropos XMing, das wird über einen Shortcut mit folgenden Parametern gestartet: Xming.exe :0 -clipboard -multiwindow -xkblayout ch -xkbvariant de

Was das ganze Setup aber zu meiner Administrationslösung macht, ist tmux. Meine Konfiguration findet Ihr am Ende das Artikels. Vielleicht erläutere ich sie einmal in einem weiteren Blogposting.

Bis vor kurzem habe ich immer ClusterSSH benutzt, wenn ich auf mehreren Systemen gleiche Befehle ausführen musste. Das hat auch mit XMing super funktioniert, bringt aber eine Inflation an Fenstern mit sich.

Daher bin ich richtig froh, dass ich tmux-xpanes entdeckt habe. Das Tools ist mit einer Fullscreen Terminal-Session via tmux einfach unschlagbar.

Meine zwei Monitore sind jetzt wie folgt aufgeteilt. Der linke Monitor trägt den ganzen Windows-Kram und der rechte eine PuTTY-Session im Fullscreen mit tmux. Das ist für mich perfekt.

# .tmux.conf
# Dirk Deimeke

set -s escape-time 1
set -g base-index 1
setw -g pane-base-index 1

bind r source-file ~/.tmux.conf \; display "Reloaded!"
bind S set-window-option synchronize-panes

bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

bind -r C-h select-window -t :-
bind -r C-l select-window -t :+

bind -r H resize-pane -L
bind -r J resize-pane -D
bind -r K resize-pane -U
bind -r L resize-pane -R

set -g default-terminal "xterm-256color"

set -g status-fg black

setw -g window-status-fg black
setw -g window-status-bg default
setw -g window-status-attr dim

setw -g window-status-current-fg white
setw -g window-status-current-bg red
setw -g window-status-current-attr bright

set -g pane-border-fg green
set -g pane-border-bg black

set -g pane-active-border-fg white
set -g pane-active-border-bg yellow

set -g message-fg white
set -g message-bg black
set -g message-attr bright

#### COLOUR (Solarized 256)

# default statusbar colors
set-option -g status-bg colour235 #base02
set-option -g status-fg colour136 #yellow
set-option -g status-attr default

# default window title colors
set-window-option -g window-status-fg colour244 #base0
set-window-option -g window-status-bg default
#set-window-option -g window-status-attr dim

# active window title colors
set-window-option -g window-status-current-fg colour166 #orange
set-window-option -g window-status-current-bg default
#set-window-option -g window-status-current-attr bright

# pane border
set-option -g pane-border-fg colour235 #base02
set-option -g pane-active-border-fg colour240 #base01

# message text
set-option -g message-bg colour235 #base02
set-option -g message-fg colour166 #orange

# pane number display
set-option -g display-panes-active-colour colour33 #blue
set-option -g display-panes-colour colour166 #orange

# clock
set-window-option -g clock-mode-colour colour64 #green

Docker-Hilfe ist hilfreich ...

nospam@example.com (Dirk Deimeke) — Wed, 18 Apr 2018 15:38:00 +0200

Prinzipiell finde ich es ja super, dass die Docker-Kommandos eine eingebaute Hilfsfunktion haben, aber manchmal ist die Hilfe schon anders als erwartet.

Ich war mir nicht sicher, ob ich zuerst den Quell- oder Zieltag angeben muss beim Docker-Tag-Kommando:

$ docker tag --help

Usage: docker tag IMAGE[:TAG] IMAGE[:TAG]

Tag an image into a repository

Options:
--help Print usage

Hotel-WLAN ...

nospam@example.com (Dirk Deimeke) — Tue, 20 Mar 2018 07:55:00 +0100

Am vergangenen Wochenende durfte ich einmal mehr in einem Hotel zu Gast sein, das ein kaputt konfiguriertes WLAN hatte. Manchmal frage ich, was die Dienstleister befürchten, wenn sie den Zugang so kastrieren.

Für mich ist elementar, dass ich via SSH auf meine Server zugreifen kann, aber Port 22 ausgehend war geblockt. Das habe ich relativ schnell in den Griff bekommen, in dem ich via "Remote Console" auf einem meiner Server sslh installiert habe. sslh nimmt Verbindungen auf Port 443 (https) an und entscheidet mit dem Handshake an welchen Dienst die Verbindung "übergeben wird". Das klappt problemlos und ziemlich gut, wenn der WLAN-Administrator nicht auf Protokollebene blockt.

Zugriff geht dann via:

ssh -p 443 user@sslh-server.example.net

Die Weiterverbindung auf andere Server lässt sich dann mittels folgendem Befehl realisieren (das geht auch transparent mit der unten aufgeführten Lösung):

ssh -o ProxyJump=user@sslh-server.example.net user@ziel.example.com

Für reine SSH-Verbindungen ist das prima, aber es gibt ja zum einen noch andere Dienste (unter anderem Usenet, Protokoll nntp, Port 119), die ich auch noch nutzen möchte.

Da kommt dann das Tool sshuttle zum Einsatz. sshuttle benutzt SSH, um darüber alle tcp-Verbindungen plus DNS mittels Paketfilterregeln weiter zu leiten. Um die lokalen Regeln anzupassen wird sudo-Zugriff auf den root-Account benötigt.

sshuttle --dns --remote=user@sslh-server.example.net:443 0/0

Für mich funktioniert das und es macht "falsch" konfigurierte Netzwerke benutzbar.

Powerline ...

nospam@example.com (Dirk Deimeke) — Sun, 17 Dec 2017 14:39:00 +0100

Ich habe jetzt einmal meinen Prompt von Liquid Prompt auf Powerline umgestellt, weil es damit ein wenig konsistenter ist, da sowohl die Shell wie auch Vim und tmux unterstützt werden.

Bei Fedora 27 ist Powerline direkt dabei, bei CentOS muss man Powerline "von Hand" installieren, das Verfahren wird auch bei anderen Distributionen funktionieren.

Fedora 27:

dnf install powerline tmux-powerline vim-powerline
systemctl enable powerline
systemctl start powerline

CentOS 7:

yum install python-pip
pip install powerline-status

cd /usr/share/fonts
curl -LO https://github.com/powerline/powerline/raw/develop/font/PowerlineSymbols.otf
fc-cache -vf /usr/share/fonts/

cd /etc/fonts/conf.d/
curl -LO https://github.com/powerline/powerline/raw/develop/font/10-powerline-symbols.conf

.bashrc

export POWERLINE_BASH_CONTINUATION=1
export POWERLINE_BASH_SELECT=1

# Fedora 27:
source /usr/share/powerline/bash/powerline.sh

# CentOS 7:
source /usr/lib/python2.7/site-packages/powerline/bindings/bash/powerline.sh

.vimrc

# Nur CentOS 7:
set rtp+=/usr/lib/python2.7/site-packages/powerline/bindings/vim/

# Fedora 27 und CentOS 7:
set laststatus=2

.tmux.conf

# Fedora 27:
source /usr/share/tmux/powerline.conf

# CentOS 7:
source /usr/lib/python2.7/site-packages/powerline/bindings/tmux/powerline.conf

while true ...

nospam@example.com (Dirk Deimeke) — Tue, 09 May 2017 07:22:00 +0200

Neben vielen anderen Pluspunkten ist die Shell etwas, was ich an Linux besonders mag.

Bis vor kurzem habe ich meine LaTeX-Präsentationen und andere Dokumente mittels Makefile und einer Endlos-Schleife entwickelt. Dokumentbetrachter wie beispielsweise Okular oder Evince (Adobe Reader kann es nicht) erlauben es, dass eine gerade angeschaute Datei verändert werden darf und zeigen die Veränderungen auch direkt an.

Dazu benutze ich ein (nahezu) generisches Makefile (make clean löscht beispielsweise alle Temporärdateien):

.PHONY: clean
.DEFAULT_GOAL := lessons-learned.pdf

clean:
find . $ -name '*.dvi' -o -name '*.aeb' -o -name '*.aux' -o -name '*.idx' -o -name '*.ilg' -o -name '*.ind' -o -name '*.ivz' -o -name '*.ivz.xml' -o -name '*.log' -o -name '*.pic.xml' -o -name '*.toc' -o -name '*.nav' -o -name '*.out' -o -name '*.snm' -o -name '*.vrb' -o -name '*~' -o -name '*.pdfpc' -o -name '*.fls' -o -name '*.fdb_latexmk' -o -name '*.xdv' $ -delete

lessons-learned.pdf: *.tex *.png # *.jpg
xelatex lessons-learned
xelatex lessons-learned
xelatex lessons-learned

Und der Rest wird durch eine Endlossschleife erledigt:

while : # oder while true
do
make -q || make
date
sleep 5
done

Allerdings hat sich dieses Verfahren erledigt, nachdem ich bei Sujeevan von latexmk gelesen habe.

Seit dem reicht ein:

latexmk -pvc -xelatex lessons-learned.tex
make clean

Supportzeiträume ...

nospam@example.com (Dirk Deimeke) — Tue, 04 Apr 2017 17:43:00 +0200

Weil ich ab und zu mal danach gefragt werde, habe ich einmal die Supportzeiträume gängiger paketbasierter Linuxdistributionen zusammengesucht.

Kritik und Korrekturen sind ausdrücklich erwünscht.

Bei Korrekturen wäre ein offizieller Link sehr hilfreich

Eingeschränkter Support:

Eingeschränkter Support bedeutet insbesondere, dass nicht alle Pakete unterstützt werden.

Bei Debian LTS sind nicht alle Pakete enthalten. Bei Red Hat Enterprise Linux wird eine ELP (Extended Life Phase) Lizenz benötigt, um weiteren eingeschränkten Support zu bekommen, SUSE erfordert ein Extended Support Package. Bei Debian und OpenSUSE wird der langfristige Support über ein separates Team gewährleistet und nicht vom Securityteam der jeweiligen Distribution.

Überblick:

Version:	Release:	Support:	Limited Support:
Debian 7, Wheezy (oldstable)	04.05.2013	24.04.2016	05.2018
Debian 8, Jessie (stable)	25.04.2015	ca 04.2018	05.2020
Ubuntu 12.04 LTS, Precise Pangolin	26.04.2012	26.04.2017	ESM
Ubuntu 14.04 LTS, Trusty Tahr	17.04.2014	04.2019
Ubuntu 16.04 LTS, Xenial Xerus	21.04.2016	04.2021
Ubuntu 16.10, Yakkety Yak	13.10.2016	04.2017
CentOS 6	10.07.2011	30.11.2020
CentOS 7	07.07.2014	30.06.2024
Red Hat Enterprise Linux 5, Tikanga	14.03.2007	31.03.2017	31.03.2020
Red Hat Enterprise Linux 6, Tikanga	10.11.2010	30.11.2020	30.11.2023
Red Hat Enterprise Linux 7, Tikanga	10.06.2014	30.06.2024	30.06.2027
openSUSE Leap 42.1	04.11.2015	05.2017
openSUSE Leap 42.2	16.11.2016	ca 05.2018
SUSE Linux Enterprise Server 11	23.03.2009	31.03.2019	31.03.2022
SUSE Linux Enterprise Server 12	27.10.2014	31.10.2027	31.10.2027
Fedora 24	21.06.2016
Fedora 25	22.11.2016

Standard-Support-Zeiträume:

Debian supported bis "next stable + 1 Jahr", LTS bis fünf Jahre nach Erscheinen (Releasezyklus "fertig, wenn es fertig ist").

Ubuntu supported bis neun Monate nach Erscheinen, LTS fünf Jahre nach Erscheinen. Release alle sechs Monate, LTS-Versionen alle zwei Jahre. Seit neuestem bietet Ubuntu eine Extended Security Maintenance für LTS-Versionen (Link in der Tabelle oben), die käuflich erworben werden kann. Danke Mario!

CentOS bis zehn Jahre nach Erscheinen des korrespondierendes RHEL Releases.

RHEL bis zehn Jahre nach Erscheinen, ELP bis 13 Jahre nach Erscheinen.

openSUSE, Major Release soll mindestens 36 Monate unterstützt werden, Minor-Releases bis 18 Monate nach Erscheinen.

SLES analog RHEL.

Fedora, Support bis zum Erscheinen des zweiten Nachfolgreleases plus ein Monat, keinen Langzeitsupport, neue Releases alle sechs Monate.

Neues Notebook ...

nospam@example.com (Dirk Deimeke) — Fri, 15 Apr 2016 17:07:00 +0200

Nicht zuletzt, weil die VGA-Schnittstelle insbesondere auf Veranstaltungen ausstirbt und mein Notebook doch ziemlich "in die Jahre" gekommen ist, habe ich mich auf die Suche nach etwas Neuem gemacht und festgestellt, dass das gar nicht so einfach ist.

Dabei dachte ich das meine Anforderungen nicht so wahnsinnig hoch sind.

Weniger als zwei Kilo
12" bis maximal 14" (kleiner ist besser)
Full HD Auflösung (mehr ist besser)
HDMI (gerne auch mit Adapter)
16 GB RAM (zur Not auch 8 GB)
256 GB SSD (mehr ist besser)
Dockingstation (!) oder Portreplikator
Möglichkeit, Netzwerk via Kabel zu verwenden (würde auch mit Adapter gehen, so häufig brauche ich das ausserhalb der Dockingstation nicht, eigentlich nur bei Vorträgen)
Englisches oder Schweizerdeutsches Tastaturlayout
kein optisches Laufwerk nötig
Muss mit Linux laufen, kein Windows nötig
Preisobergrenze 2000 CHF, es darf aber auch weniger sein

Für mich spannend ist, dass gerade das "Musskriterium" Dockingstation (oder Portreplikator) die Auswahl auf ein Minimum reduziert hat.

Mit dem Dell XPS 13 Developer Edition (wird mit Ubuntu ausgeliefert) hatte ich gehofft, fündig geworden zu sein. Der Support hat leider auf meine Anfragen nicht geantwortet, aber dankenswerter Weise hat mir ein lieber Bekannter einen Kontakt vermittelt, bei dem ich alle Fragen loswerden konnte.

Linux unterstützt leider die Dockingstation nicht und nach Erfahrung des Kontaktes - hier noch einmal in aller Form DANKE! - ist die HiDPI-Unterstützung bei Linux noch (sagen wir einmal) ausbaufähig.

Für mobile E-Mail und vieles andere reicht sicher mein Tablet inklusive Tastatur. Um "richtig" arbeiten zu können, braucht es aber etwas mehr. Gerade die Arbeiten an der vierten Auflage unseres Buchs (geplanter Erscheinungstermin viertes Quartal 2016, um der Frage vorzubeugen) möchte ich nicht mit dem Tablet erledigen.

Tatsächlich sind nach dem Reinfall nur drei Hersteller übrig geblieben. Wobei das so nicht richtig ist, es sind zwei plus ein Hersteller. Lenovo (ein Thinkpad, so wie immer), Dell (Latitude, warum nicht mal was anderes?) und Apple (leider - oh - ohne Dockingstation). Interessant ist, dass Apples Notebook günstiger sind als die von Lenovo im gleichen Leistungssegment.

Als alter Sack hätte ich auch gerne etwas wertiges und nicht unbedingt ein Gerät, das komplett aus Plastik besteht.

Ich habe mich jetzt für ein Dell Latitude E7450 entschieden. Ausschlaggebend war zum Einen, dass es komplett durch Linux unterstützt wird (Chipsatz ist Broadwell und nicht Skylake) und zum Anderen, dass ich es durch Lösen von zwei Schrauben erweitern kann.

Eckdaten:

Core i7 Prozessor
8 GB RAM (werde noch einmal 8 GB separat bestellen)
256 GB SSD
Gigabit Netzwerkschnittstelle
HDMI
E-Dock
1,5 Kilogramm
3 Jahre Vor-Ort-Support

Neben dem, dass Dell anscheinend Platz machen möchte für die nächste Generation scheint es die Geräte bereits am Lager zu haben. Konfigurationsänderungen speziell dieses Modells waren nur in sehr geringem Umfang möglich (ich benötige aber auch nichts anderes), gibt es reichlich Rabatte.

Kostenloser Versand
35% Rabatt
Sie bekommen eine Docking-Station für den halben Preis ausgewählten Dell Latitude
ProSupport Plus zum Preis von ProSupport

Über die Linux Foundation hätte ich 10% Rabatt auf Hardware und 20% Rabatt auf Peripherie bekommen, aber das war gar nicht nötig.

Windows mit Linux-Kernel?

nospam@example.com (Dirk Deimeke) — Thu, 31 Mar 2016 10:16:26 +0200

Mit der letzten Ankündigung bin ich tatsächlich der Meinung, dass wir den Beginn der Umstellung von Windows auf einen Linuxkernel sehen. Es mehren sich die Zeichen, dass die Integration von Windows und Linux - durch Microsoft getrieben - immer stärker wird.

Dem vorangegangen sind eine Reihe von anderen Meldungen.

Windows Containers mit Docker.

Der Datenbankserver MS SQL wird auf Linux portiert.

OpenSSH wird in Windows Server 2016 enthalten sein.

Nebenbei: Wer es schafft das Takswarrior-Kommando "task color" im Linux-Subsystem von Windows 10 zu zeigen, bekommt ein Taskwarrior-T-Shirt und einen Sticker (Twitter)

openSUSE Leap 42.1 ...

nospam@example.com (Dirk Deimeke) — Thu, 24 Dec 2015 05:31:00 +0100

Da kann man mal sehen, wie viel Zeit es braucht bis ein Artikel fertig wird ...

Wer einen Distributionstest sucht, sollte meiner Ansicht nach lieber bei Pro-Linux oder Michael Kofler nachlesen.

Meine Anmerkung ist eher "philosophischer Natur"

Zum Einen finde ich es klasse, dass sich bei OpenSUSE endlich wieder etwas getan hat. Tot gesagte leben bekanntlicherweise länger. SUSE war "meine Einstiegsdroge" in die Linuxwelt und ich hätte es sehr schade gefunden, wenn diese Distribution einfach sang- und klanglos verschwunden wäre.

Zum Anderen gefällt mir das Konzept sehr (keine Angst, ich denke derzeit nicht darüber nach, zu wechseln). Es bietet eine sehr gute Alternative zu bestehenden Distributionen, die sich (bis jetzt) bezogen auf Softwareversionen ganz grob in drei Lager einteilen liessen:

Abgehangen (ich möchte nicht veraltet sagen, weil es nicht passt), stabile Software, die lange unterstützt wird. Vertreter dieser Gattung finden sich besonders bei den Server-Systemen, seltener auf dem Desktop.

CentOS
Debian
Ubuntu LTS

Schnell drehend, relativ viele Updates, aktuelle Software, kurze Support-Zeiträume. Typische Verwendung als Desktopsystem für (ambitionierte) Endbenutzer.

Fedora
Ubuntu (ohne LTS)

Ständig aktualisierend ("rolling release"), meist topaktuelle Software häufig zu Lasten der Stabilität. Wer nicht regelmässig mitspielt ("aktualisiert") manövriert sich in Schwierigkeiten.

ArchLinux
Sabayon
Gentoo
OpenSUSE Tumbleweed

Klar, dass noch wesentlich mehr Distributionen gibt, die obigen seien nur als Beispiele genannt.

Es gibt natürlich Zwitter, so lassen sich die abgehangenen Systeme durch zusätzliche (nicht vom Hauptrojekt unterstützte) Paketquellen mit aktuellerer Software bestücken.

Und diesen "Zwitter-Weg" geht jetzt auch OpenSUSE Leap. Sie bauen auf der stabilen Basis von SUSE Enterprise Linux auf und portieren aktuelle Applikationen aus Tumbleweed zurück in die Distribution und unterstützen sie auch offiziell.

In der Summe ist das eine Mischung aus der ersten und der dritten gerade genannten Kategorie. Für mich ist dieser Weg das Beste aus allen Welten für Endanwender und ich hoffe, dass einige weitere Distributionen dem Beispiel folgen werden. Allerdings, das darf man nicht vergessen, kann der hohe Takt auch zu Problemen führen.