Ein VPN-Server, der aus einem schreibgeschützten Image startet und seinen Laufzeitzustand im tmpfs hält, ist ein reales und nützliches Design. Es lässt sich auch leicht als „ohne Logs“ beschreiben, was das Design nicht belegt. Der Speicherort bestimmt, wo eine Kopie lebt; Erfassung und Aufbewahrung bestimmen, ob überhaupt ein Datensatz existiert, und ein Neustart betrifft nur Ersteres. Diese beiden Dinge auseinanderzuhalten ist die ganze Prüfung.

Beginnen Sie mit einer Liste jedes Prozesses, der Zustand schreiben kann: der Daemon, der Authentifizierungsdienst, das Journal, jeder Monitoring-Agent und die Verwaltungswerkzeuge.

Speicherung und Erfassung sind verschiedene Fragen

Jeder Schreiber hat sein eigenes Ziel und seine eigene Richtlinie. Der VPN-Daemon schreibt Statusdateien, das Authentifizierungs-Backend schreibt Kontoereignisse, das Journal sammelt Dienstausgaben, und ein Monitoring-Agent versendet Metriken ganz woandershin. Ein Design, das eines davon beim Neustart verschwinden lässt, hat über die anderen drei nichts gesagt. Verfolgen Sie jeden Schreiber bis zu seinem Ziel und notieren Sie, ob dieses Ziel überhaupt auf der Maschine liegt.

Anwendungsspezifische Dateien, hochgeladene Diagnosedaten und externe Dienste brauchen dieselbe Behandlung. Das Fehlen eines vertrauten lokalen Logs beweist nicht, dass Verbindungs- oder Kontodatensätze nirgends existieren; es beweist, dass Sie noch nicht gefunden haben, wohin sie gehen.

tmpfs ist keine Garantie

Linux tmpfs ist keine physische RAM-Disk. Die Kernel-Dokumentation ist eindeutig, dass Seiten in den Swap geschrieben werden können, wenn die Einhängeoption es erlaubt, sodass eine tmpfs-Datei auf eine Festplatte gelangen kann, ohne dass die Anwendung sie jemals dorthin kopiert. mount zeigt, ob ein swap-gestütztes tmpfs im Spiel ist, und andere Speicher-Dateisysteme verhalten sich wieder anders. Lesen Sie die tatsächlichen Einhängeoptionen, statt anzunehmen, ein Pfad unter /run bedeute Flüchtigkeit.

Erfassen Sie dann die Dinge, die einen Neustart überleben, auf Weisen, die Menschen vergessen: ein persistenter Overlay, angeschlossener Speicher, Hibernationsabbilder, Absturz-Dumps und Infrastruktur-Snapshots der gesamten VM. Jedes davon ist ein mögliches Ziel für Zustand, den Sie für flüchtig hielten. Diese Liste ist etwas zum Prüfen, keine Behauptung, dass jeder Host sie alle besitzt.

Journald hat zwei Ziele und einen Weiterleiter

Journald zeigt die Aufteilung gut. Flüchtiger Speicher hält Einträge unter /run/log/journal, persistenter Speicher unter /var/log/journal, und der automatische Modus wählt dazwischen; der geltende Modus kommt vom laufenden System und nicht aus der Beschreibung des Images. Der Wechsel zu flüchtig löscht nicht, was bereits persistent geschrieben wurde. Auch die Weiterleitung ist ein eigener Kanal: Selbst eine Speichereinstellung, die lokal nichts hält, kann Nachrichten an ein anderes Ziel übergeben.

Lesen Sie den wirksamen Modus aus dem Journal selbst oder seiner Konfigurationsdatei und prüfen Sie dann die Weiterleitungsziele getrennt, weil eine Einstellung die andere nicht steuert.

Was einen Neustart überleben muss

Eine zustandslose Laufzeit unterstützt wiederholbaren Austausch und braucht bewusste Quellen für die Konfiguration, Autorisierung und das Wiederherstellungsmaterial, das der Dienst nicht erfinden kann. Den einzigen funktionierenden Registrierungs- oder Widerrufszustand zu verlieren, damit lokale Schreibvorgänge verschwinden, ist ein schlechter Handel, und ein häufiger. Entscheiden Sie bewusst, was überleben muss, und prüfen Sie dann, dass es das tut.

Dieselbe Überlegung gilt für Betriebsdaten. Entscheiden Sie, welche Ereignisse Sicherheit und Dienstverwaltung wirklich benötigen, mit begründetem Umfang und begründeter Aufbewahrung, und minimieren Sie den Rest. Minimieren ist nicht dasselbe wie jede Diagnose abzuschalten.

Vergleichen Sie die wirksame Speicher- und Weiterleitungskonfiguration mit einigen harmlosen Ereignissen, starten Sie dann die Maschine neu oder ersetzen Sie sie und prüfen Sie erneut, was geblieben ist und wo der Dienst seinen Zustand wiederhergestellt hat.

Ähnliche Artikel