Regeln, die sich selbst durchsetzen

Die meiste Server-Automatisierung ist eine Frage der Uhrzeit: Um drei Uhr nachts laufen die Updates, sonntags das Backup. Das funktioniert gut für alles, was ein Vorgang ist – aber schlecht für alles, was ein Zustand ist. Eine Firewall soll nicht um drei Uhr nachts richtig konfiguriert sein. Sie soll es immer sein.

Genau dafür kennt LCM neben den geplanten Regeln eine zweite Art: die Grundsatz-Regel.

Zwei Arten von Regeln

Server werden in LCM zu Gruppen gebündelt, und eine Gruppe trägt Zeitpläne und Regeln. Eine geplante Regel hängt an einem Zeitplan und läuft zur Cron-Zeit nacheinander auf allen Servern der Gruppe – Updates, Skripte, ein Neustart im Wartungsfenster.

Eine Grundsatz-Regel hängt an keiner Uhrzeit. Sie wird bei jeder Verbindung zum Server geprüft, mindestens also beim regelmäßigen Health-Check. Und sie läuft dabei nicht einfach los: Sie sieht zuerst nach, wie es tatsächlich aussieht, und greift nur bei Abweichung ein.

Für die Firewall heißt das: Entspricht die Port-Konfiguration dem, was die Regel vorschreibt, passiert nichts – kein Kommando, kein Eintrag, kein Rauschen. Hat jemand von Hand einen Port aufgemacht oder ein Paketupdate die Konfiguration zurückgesetzt, wird der Soll-Zustand wiederhergestellt. Und weil das eine Änderung an einem Produktivsystem ist, erscheint sie als Audit-Eintrag und im Protokoll. Eine Konfigurationsänderung soll nicht nur im Output eines fremden Jobs stehen.

Warum nicht alles eine Grundsatz-Regel sein kann

Das Verfahren setzt etwas voraus, das nicht jede Regel mitbringt: einen Soll-Zustand, mit dem sich der Ist-Zustand vergleichen lässt. Deshalb gibt es Grundsatz-Regeln nur für die vier Typen, die einen tragen – Firewall, APT-Cache und die beiden Regeln rund um Verzeichnisrechte.

Ein Shell-Kommando trägt keinen. Es lässt sich nicht fragen, ob es „schon erledigt“ ist; als Grundsatz-Regel liefe es bedingungslos bei jedem Health-Check mit. Für so etwas ist ein Zeitplan der richtige Ort, wo jede Ausführung ein eigener Job mit eigenem Ergebnis ist.

Umgekehrt gilt das genauso: Die Regeln für Verzeichnisrechte lassen sich nicht an einen Zeitplan hängen. Sie beschreiben einen Zustand, keine Aktion zu einer Uhrzeit.

Wenn zwei Gruppen dasselbe regeln

Ein Server darf in beliebig vielen Gruppen sein – das ist praktisch, erzeugt aber einen Konflikt, sobald zwei davon eine Grundsatz-Regel desselben Typs tragen. Zwei Firewall-Regeln beschreiben denselben Soll-Zustand unterschiedlich; durchsetzen kann sich nur eine.

Entschieden wird das über den Vorrang der Gruppe, und zwar mit der kleineren Zahl – Leserichtung wie bei MX-Records. Eigene Gruppen starten bei 100, die System-Gruppe liegt bei 1000 und ist damit bewusst die schwächste: Ihre Regeln gelten für alle Server und bilden die Grundlinie, die eine spezifischere Gruppe überstimmen darf.

Die zurückgestellte Regel verschwindet dabei nicht still, sondern steht im Bericht des Health-Checks:

Grundsatz-Regeln:
  [Basis-Firewall] firewall ok – regel umgesetzt (ports: 22,443)
  [Web-Firewall] übersprungen – Vorrang liegt bei Gruppe "Basis-Härtung" (10).

Haben beide Gruppen denselben Vorrang, gewinnt die ältere. Das ist nachvollziehbar, aber es ist keine Entscheidung, die jemand getroffen hat – deshalb weist LCM auf den Gleichstand ausdrücklich hin, statt ihn zu verschweigen.

Eine Sperre, die einen Fehler nicht zulässt

Eine Firewall-Grundsatzregel muss ausdrücklich sagen, welche Ports offen sein sollen. Fehlt die Angabe, wird die Regel abgewiesen – nicht als Vorsicht, sondern weil die Alternative fatal wäre: Eine Firewall-Regel ohne Portliste schlösse auf allen Servern der Gruppe sämtliche Dienstports und stellte diesen Zustand bei jedem Health-Check wieder her. Man hätte sich selbst ausgesperrt, mit Wiederholung.

Soll wirklich nur SSH offen sein, ist das mit einer leeren Liste [] anzugeben. Der Unterschied zwischen „ich will nichts offen haben“ und „ich habe vergessen, etwas einzutragen“ gehört zu den Dingen, die ein Werkzeug nicht erraten sollte.

Zum Nachlesen

Die vollständige Beschreibung mit allen Regel-Typen steht in der Dokumentation unter Gruppen, Schedules & Regeln. Einen Überblick über LCM gibt es auf der Produktseite – und wer es einfach ausprobieren möchte, findet unter lcm-demo.techeve.de ein Demo-System.