Zu den üblichen Tätigkeiten wenn ich einen neuen Server einrichte, gehört die Installation und der Start von fail2ban1. 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 Prometheus1 um einige Sensordaten und Statusinformationen meiner Server zu verarbeiten. Prometheus arbeitet mit sog. Exportern2. 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 3 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. SaltStack1, Ansible2, Puppet3, Chef4, CFEngine5 und Terraform6, 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 YAML7 und Jinja8. 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-ssh9 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 systemd1 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-resolved2 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 nagios1 gemacht. Irgendwann bin ich dann zu Icinga2 gewechselt. Immer wieder bin ich auch über checkmk3 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 Yubikey1 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 Ventoy1.

Das Fediverse1 dürfte den meisten unter dem Schlagwort Mastodon2 bekannt sein. Und Mastodon ist zweifellos die bekannteste Anwendung dieses föderierten Netzwerks. Doch es gibt auch (kompatible) Alternativen. Eine davon ist CalckeyFirefish3.

Wer Docker Container1 nutzt stellt diesen häufig einen Reverse Proxy2 voran. Dies hat verschiedene Vorteile, da man hierbei jedoch schnelle eine Vielzahl von Containern über einen Proxy verwaltet, lohnt es, sich ein paar Gedanken über Struktur und Inhalt dieser Dateien zu machen. Dies sorgt für einen guten Überblick und Änderungen können schneller und einfacher umgesetzt werden.