Mit tmux¹ verbindet mich eine jahrelange Hassliebe. Auf der einen Seite ist tmux wirklich ein schweizer Taschenmesser und kann tolle Dinge, auf der anderen Seite finde ich das tmux-Ökosystem schwer durchschaubar und die Vielzahl von Tastenkombinationen und Konfigurationseinstellungen tut ihr übriges. Am meisten hat mich aber immer das Copy & Paste Verhalten gestört.

Aber wie so oft muss man halt einmal tief tauchen und dann lichtet sich der Dschungel auch schon.

Wenn man Server mit Ansible verwaltet müssen früher oder später natürlich auch Kennwörter und andere Geheimnisse abgelegt werden. Mit ansible-vault¹ bietet Ansible hier auch entsprechende Tools an, um diese Geheimnisse sicher zu speichern. Mit ansible-vault lassen sich entweder komplette Dateien oder einzelne Zeichenketten verschlüsseln. Zum Entschlüsseln muss entweder ein Kennwort für den Vault in einer Datei hinterlegt, oder bei der Ausführung von Ansible manuell angegeben werden.

Zu den üblichen Tätigkeiten wenn ich einen neuen Server einrichte, gehört die Installation und der Start von fail2ban¹. Um so erstaunter war ich, dass unter Debian 12 die Installation zwar ohne Probleme klappt, der Start jedoch fehlschlägt.

Ansible ist sehr flexibel, wenn es um Struktur und Aufbau der eigenen Playbooks geht. Das ist auf der einen Seite natürlich schön, allerdings macht es gerade den Einstieg natürlich etwas schwerer. Ich möchte daher hier mal meine persönlichen Best Practice Regeln vorstellen, von denen ich denke, dass sie meine Playbooks übersichtlicher und besser wartbar machen.

Ich nutze Prometheus¹ um einige Sensordaten und Statusinformationen meiner Server zu verarbeiten. Prometheus arbeitet mit sog. Exportern². Hierbei handelt es sich um kleine Programme, die von Prometheus abgefragt werden und so ihre Daten übermitteln. Die Exporter können über beliebige interne und externe Systeme verteilt sein. Hierzu muss Prometheus aber natürlich wissen unter welchen Adressen die jeweiligen Exporter erreichbar sind.

Ich verwalte sowohl die Prometheusinstanz selbst als auch meine Exporter mit Ansible. Immer wenn ich einen Exporter auf einem System hinzufüge, muss die zentrale Prometheus-Instanz hierüber natürlich informiert werden. In diesem Artikel geht es darum, wie man das ganz einfach bewerkstelligen kann. Die ersten Schritte mit Ansible habe ich unter ³ beschrieben.

Ansible

Einleitung

Wer Server betreibt wird sich früher oder später die Frage stellen, wie diese Server möglichst sauber (und ggf. auch möglichst homogen) konfiguriert werden können. Weil das so ist, gibt es hierfür auch gleich eine ganze Reihe von entsprechenden Tools, z.B. SaltStack¹, Ansible², Puppet³, Chef⁴, CFEngine⁵ und Terraform⁶, um nur einige zu nennen. Persönlich habe ich sehr viel mit SaltStack gearbeitet, aber auch Ansible kam hier und da zum Einsatz. Im ersten Moment wirken SaltStack und Ansible auch sehr ähnlich. Beide setzen stark auf YAML⁷ und Jinja⁸. Unter der Haube unterscheiden sie sich aber dann doch recht deutlich. Salt setzt auf einen zentralisierten Ansatz mit eigenem Server, Clients und entsprechendem Protokoll, Ansible nutzt einfach SSH-Verbindungen und benötigt keinen zentralen Server zur Steuerung. Ansible ist zudem stärker darauf ausgelegt in den sog. Tasks Bezug auf vorangegangene Schritte zu nehmen dadurch fühlt sich Ansible (für mich) etwas "scriptiger" an. Ob man das gut oder schlecht findet, ist vermutlich Geschmackssache.

An sich mag ich den zentralistischen Ansatz von Salt sehr gern, durch das eigene Protokoll ist Salt auch um einiges schneller als Ansible, welches ja jeden einzelnen Step über eine SSH-Verbindung ausführen muss. Aber gerade wenn man z.B. gar keinen zentralen Server für die Verwaltung der Infrastruktur bereitstellen kann oder möchte, ist Ansible mir hier lieber (auch wenn es salt-ssh⁹ gibt). Deswegen und weil ich einfach gerne mal wieder etwas mit Ansible machen wollte, habe ich mein kleines Heimsetup in den letzten Wochen unter Ansibleverwaltung gestellt.

In letzter Zeit hatte ich häufiger DNS-Probleme nachdem mein Rechner aus dem Suspend zurückkehrt. Ich vermute, dass während bzw. vor dem Suspend mein WLAN Interface deaktiviert wird und aus irgendeinem Grund scheint systemd¹ es nicht für nötig zu halten die DNS Einstellungen erneut zuzuweisen, wenn das Gerät wieder aktiviert wird. Eine korrekte Lösung über systemd-resolved² habe ich auf die Schnelle nicht finden können (und hatte ehrlich gesagt auch wenig Lust mich da tiefer einzuarbeiten und überlege auch ständig einfach wieder die gute alte /etc/resolv.conf zu nutzen).

Aber hier soll es ja auch gar nicht um meine DNS-Auflösung gehen, sondern um das Ausführen von Scripten/Befehlen beim Wechsel des Suspend-Status.

Meine ersten Schritte mit Serverüberwachungstools habe ich vor vielen Jahren mit nagios¹ gemacht. Irgendwann bin ich dann zu Icinga² gewechselt. Immer wieder bin ich auch über checkmk³ gestolpert und habe mich nun endlich einmal dazu entschieden, es mir einmal genauer anzuschauen. Während man nagios und Icinga die Verwandtschaft - gerade wenn es an die Configdateien geht - noch recht gut ansieht, sieht checkmk deutlich anders aus und dieser Eindruck bleibt mitunter auch bestehen, wenn man sich an die Konfigurationsdateien wagt (wenngleich auch hier der Nagios-Ursprung noch gut erkennbar ist). Denn alle zuvor genannten Tools entstammen einer gemeinsamen Wurzel. Und sie sind bis heute in Teilen kompatibel.

checkmk wirkt an einigen Stellen etwas moderner als seine Geschwister und es lässt sich weitestgehend - ohne manuelles Eingreifen in die Konfigurationsdateien - über seine Weboberfläche konfigurieren. Wer mehr Automatisierung wünscht, kann u.a. die REST-API von checkmk nutzen.

Im Artikel SSH-Keys mit Yubikey hatte ich erläutert, wie man einen SSH-Key mit einem Yubikey¹ absichert/ersetzt. Aber natürlich kann man auch die Anmeldung am Rechner mit einem Yubikey absichern.

Bootfähige USB-Sticks zur Betriebssysteminstallation nerven mich. Jedes Mal, wenn man ihn braucht ist dort das falsche OS (oder zumindest eine veraltete Version drauf). Außerdem musste man kürzlich dann doch auch noch andere Daten drauf speichern, hat es mittlerweile natürlich vergessen und es fällt einem genau dann wieder ein, wenn der Stick gerade neu beschrieben wird. Nervig auch die subtilen Unterschiede bei der Erzeugung der Sticks je nach gerade genutzten Betriebssystem und dem zu bootenden Image.

Abhilfe schafft hier Ventoy¹.