Skip to content

Wie ich Ende 2021 arbeite (Infrastruktur)

In der Infrastruktur hat sich ein bisschen getan, hier der Artikel aus dem letzten Jahr.

Alle von mir betriebenen Server laufen mittlerweile mit Ubuntu 20.04 LTS, weil ich das Gehampel rund um CentOS leid bin und E-Mail schon 2020 zu einem Dienstleister umgezogen ist.

Beim Monitoring setze ich mittlerweile auf UptimeRobot, die kostenlose Variante bietet alles, was ich benötige, auch eine Statusseite für die von mir angebotenen Dienste. Das reicht mir aus.

Für das Kapizitätsmonitoring setze ich auf Prometheus mit Node Exporter und Grafana, das läuft super. Einen Überblick über das Setup findet Ihr im Monitoring Zwischenintermezzo.

Ich habe mich aus dem IRC zurückgezogen, daher habe ich den Dienst The Lounge eingestellt.

Nicht nur, weil ich mich mit Hugo auseinandersetzen wollte, habe ich ein ChangeLog aufgesetzt, in dem ich meine "Erzeugnisse" bündele. Sehr auch Changelog und Polywork.

Neben verschiedenen Versionsupdates war es das auch schon.

Mein Arbeitsplatz Ende 2021

Hier gibt es erfahrungsgemäss wenig Änderungen, wie ein Vergleich mit dem letzten Artikel zeigt.

Mitte des Jahres war ich wieder vermehrt im Büro und habe es genossen, ich muss vor den Leuten nicht weglaufen.

Die grösste Arbeitsplatz-Änderung ist, dass ich für die Bereitschaft (Pikett) ein neues iPad Pro (12.9 Zoll) mit Magic Keyboard bekommen habe, ich habe mich bewusst gegen ein MacBook Air und auch gegen ein Notebook mit Windows entschieden. Der Grund dafür ist, dass wir BlackBerry Work als Kommunikationslösung ("Outlook auf dem Tablet und Handy") einsetzen und ich darüber deutlich schneller an die E-Mails komme als über den Virtual Desktop.

Meine Firefox-Addons Ende 2021

Dieser Artikel ist die 2021er Edition des Artikels aus dem letzten Jahr.

Meine Visual Studio Code Plugins Ende 2021

Dieser Artikel ist der Nachfolge-Artikel von diesem hier.

Die Funktionalität des Bracket Pair Colorizer 2 ist mittlerweile im Kern von VSCode enthalten, aus diesem Grund benötige ich das Plugin nicht mehr.

Was sind Eure Empfehlungen?

Minimalkonfiguration Firefox

Da ich gerade mein Notebook neu (mit Fedora) installiere, dachte ich, ich schreibe einmal auf, welche fünf Einstellungen ich minimal bei Firefox konfiguriere, damit ich damit arbeiten möchte.

Natürlich bin ich in diesem Fall ganz besonders an Euren Meinungen und eigenen Konfigurationen interessiert.

Bevor ich noch irgendetwas anderes mache, installiere ich den Werbeblocker uBlock Origin. Von Zeit zu Zeit schalte ich den einmal aus, um festzustellen, dass das Web für mich nicht nutzbar ist ohne eine solche Software.

Wenn ich schon einmal auf den Erweiterungsseiten bin, installiere und konfiguriere ich auch gleich Bitwarden, meinen Passwortmanager.

Im Zuge dessen schalte ich direkt aus, dass Firefox Passwörter speichern soll, ich lasse aber eingeschaltet, dass Firefox mich über gehackte Webseiten informieren soll, die Einstellungen finden sich unter Settings / Privacy & Security / Logins and Passwords.

Als Nächstes stelle ich noch DNS over HTTP ein, das geht über Settings / General / Network Settings / Settings... / Enable DNS over HTTPS / Custom, dort schwanke ich zwischen dnsforge.de (betrieben von einer Privatperson), Quad9 (betrieben von einer Stiftung) und Digitale Gesellschaft (betrieben von einem Verein) als Provider. Achtung: Firefox nutzt als Fallback immer den im System verwendeten DNS-Server. Das lässt sich anders konfigurieren, guckt dazu einmal ins Privacy Handbuch.

Als letzte stelle ich noch ein, dass der Webbrowser nicht mit dem Schliessen des letzten offenen Tabs geschlossen wird, dazu bei Firefox die Seite about:config aufrufen (Achtung: Hier kann man den Browser auch kaputt konfigurieren) und den Parameter browser.tabs.closeWindowWithLastTab auf false setzen.

Natürlich setze ich noch weitere Addons ein, eine Liste der Addons, die ich verwende, wird in einem der Jahresrückblicke nächste Woche veröffentlicht.

Nachtrag: Ein Kommentar von understater hat mich daran erinnert, dass ich natürlich auch die Suchmaschine ändere, von Google auf DuckDuckGo.

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"

Goodbye IRC

Nach sehr vielen Jahren habe ich mich jetzt entschlossen, dem Internet Relay Chat endgültig den Rücken zu kehren. Nein! Doch! Oh!

In den letzten Jahren habe ich mit The Lounge einen eigenen Bouncer betrieben. Das hat wahnsinnig gut funktioniert, aber gebraucht habe ich es selten. Sehr selten.

Und das ist auch der Grund, weshalb ich mich zurück ziehe. Sollte ich noch einmal IRC benötigen, kann ich via Matrix und der entsprechenden IRC Bridge auch wieder teilnehmen. Vermutlich werde ich es aber nicht in Anspruch nehmen müssen.

Bessere Shell-Skripte

Shell-Skripte sind gegenüber anderen Programmiersprachen natürlich nicht das "Non-plus-ultra", aber sie sind für Ablaufsteuerungen - dafür sind sie gemacht - eine gute Wahl. Für alles, was grösser ist, empfehle ich eine "richtige Programmiersprache". Ich bin als Systemadministrator ein grosser Fan von Python und - schon länger nicht mehr genutzt - Perl, aber auch Sprachen wie Raku, Ruby oder irgendetwas mit Compiler sind natürlich gute Alternativen.

Ich beziehe mich im Folgenden auf die Bash, weil das die Shell ist, die ich täglich auf verschiedenen Systemen und Architekturen benutze.

Tipp 1:

Schreibt in den Shebang #! zu Beginn des Skriptes genau die Skriptsprache mit der Ihr auch getestet habt und nicht - weil alle das machen - /bin/sh. Auf Debian basierten Systemen ist /bin/sh ein Link auf dash, bei Alpine ist es ein Link auf Busybox, auf Red Hat basierten Systemen ein Link auf bash.

An dieser Stelle möchte ich gerne noch auf diesen alten Artikel hinweisen.

Tipp 2:

Skripte laufen auch im Falle eines Fehlers weiter. Ich halte das für ein blödes Verhalten, was sehr häufig zu Fehlern führt. Glücklicherweise kann man das Verhalten abstellen.

Entweder man ruft die Shell mit -e auf, setzt den Shebang entsprechend oder schreibt set -e an den Anfang des Skriptes oder vor die Zeilen für die das Setting gelten soll. Mit set +e kann man wieder das alte Verhalten herstellen.

Meine Empfehlung ist, die Langform set -o errexit zu verwenden, das ist deutlich lesbarer. (Altes Verhalten kann man mit set +o errexit wieder herstellen).

Shellzeilen gelten als fehlerhaft, wenn der exit-Code des letzten Kommandos der Zeile ungleich 0 (null) ist. Das bedeutet unter anderem, dass man den Exitcode einer einzelnen Zeile durch Hinzufügen von || true auf "nicht fehlerhaft" ändern kann.

Tipp 3:

Wie im letzten Tipp beschrieben, ist das letzte ausgeführte Kommando einer Zeile ausschlaggebend dafür, ob eine Zeile mit oder ohne Fehlercode beendet wird.

Der Eintrag set -o pipefail sorgt dafür, dass eine Zeile als fehlerhaft "gesehen" wird, wenn auch nur ein Kommando der über Pipes vernetzten Kommandos einer Zeile fehlschlägt.

Tipp 4:

Nicht gesetzte oder "leere" Variablen sind häufig ein Problem.

Um eine nicht gesetzte Variable mit einem Fehler zu quittieren, kann man das Kommando set -o nounset oder set -u verwenden.

Tipp 5:

Es ist generell eine gute Idee, alle Variablen mit doppelten Anführungszeichen zu umgeben, ganz besonders dann, wenn es um Dateien geht. Auch, wenn man selber keine Dateien mit Leerzeichen (oder anderen "Internal Field Separators" (IFS)) erstellt, heisst es nicht, dass man nicht auf solche treffen kann.

Nachtrag:

Christoph hat in diesem Kommentar zur recht darauf hingewiesen, dass es besser ist /usr/bin/env bash zu verwenden, das benutzt die erste Bash, die der Benutzer im Pfad hat und funktioniert auch auf Systemen, auf denen die Bash in einem anderem Pfad liegt als /bin/bash.

Zusammenfassung:

Meine Erfahrung ist, dass man mit den fünf Tipps rund 80% aller Probleme mit Shellskripten umschifft bzw. Skripte mit Fehlern rechtzeitig abbricht.

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

# Und Variablen immer mit doppelten Anführungszeichen verwenden.

echo "${Variable}"

Es gibt noch viele weitere Tipps, aber das sind meiner Ansicht nach die wichtigsten.

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:

Changelog und Polywork

In meinem Kopf ist schon lange herumgespukt, ein Sammelbecken für meine Inhalte auf verschiedenen Plattformen und in verschiedenen Formaten aufzubauen. Die verschiedenen Inhalte sind Bücher, Blog- und andere Artikel, Podcasts, Videos, Vorträge, Workshops, ... Ihr versteht, worauf das hinausläuft. Hintergrund des Gedankens ist, dass nicht alles bei mir im Blog oder auf meinen Plattformen passiert und so eine konsolidierte Sicht relativ schwierig ist.

In der TILpod-Episode 9 hatten wir Michael "dnsmichi" Friedrich zu Gast, der mich auf Polywork hinwies, was genau dafür gedacht ist.

Polywork ist schön gemacht und gut umgesetzt. Die neuen Features, die dort eingebaut werden, ergeben alle Sinn und treiben genau dieses Modell nach vorne. Es macht Spass, sich dort mit anderen "Creatern" zu vernetzen.

Die Profile von dnsmichi und ddeimeke findet Ihr unter den entsprechenden Links.

Aber: Mir leuchtet das Geschäftsmodell noch nicht ein, daher weiss ich nicht, wie lange der Dienst Bestand hat. Das weiss man ja irgendwie nie.

Dieser Gedanke führte mich dann dazu, dass ich ein eigenes Changelog aufgebaut habe, weil ich mich eh schon einmal mit Hugo beschäftigen wollte.

Beide Verfahren haben ihre ganz eigenen Vor- und Nachteile und die Pflege der Inhalte auf den beiden Plattformen bedeutet auch vertretbaren Mehraufwand. Menschen, die alles in alle sozialen Netzwerke teilen, haben einen solchen Mehraufwand ja auch, es sei denn, es passiert automatisiert (so mache ich es bei Mastodon).

Ich bin auf Eure Kommentare gespannt.