Thema: configuration
-
Idempotente Admin-Skripte schreiben: Prüfen vor Ändern, Drop-in-Dateien und Marker-Kommentare
Ein Admin-Skript, das ein Agent nach einem Teilfehler oder bei wiederholtem Zeitplan erneut ausführen könnte, soll das System im selben Zustand hinterlassen, ob es einmal oder fünfmal läuft. Drei Muster machen das zuverlässig: den Ist-Zustand vor der Änderung prüfen, separate Drop-in-Dateien schreiben, statt gemeinsam genutzte Dateien zu bearbeiten, und jeden vom Skript verwalteten Block markieren.
-
Einen Konfigurationswert von der Deklaration zum tatsächlichen Laufzeitverhalten nachverfolgen
Erklärt, warum das Bearbeiten einer Konfigurationsdatei das Anwendungsverhalten verändert hat oder nicht, indem der Wert entlang seines tatsächlichen Lade- und Überschreibungspfads nachverfolgt wird.
-
ConfigMaps und Secrets in Kubernetes: Grössengrenzen, Verbreitung von Aktualisierungen und was ein Secret nicht schützt
ConfigMaps und Secrets sind beide auf 1 MiB begrenzte Schlüssel-Wert-Objekte; als Volume eingebundene Schlüssel aktualisieren sich nach einer Sync-Verzögerung des kubelet, Umgebungsvariablen dagegen nie, subPath-Mounts aktualisieren sich nie, und ein Secret ist nur base64-kodiert und liegt unverschlüsselt in etcd, sofern nicht Verschlüsselung im Ruhezustand und RBAC konfiguriert sind.
-
Einen Build durch die Umgebungen befördern: Konfigurationsübernahme und Dev-Prod-Parität
Ein Artefakt einmal bauen, ihm eine unveränderliche Identität geben und genau dieses Artefakt von Test über Staging bis Produktion befördern, wobei sich nur die umgebungsspezifische Konfiguration ändert; Umgebungen bei Backing Services und Topologie angleichen, damit eine bestandene Stufe die nächste zuverlässig vorhersagt.
-
Konfigurationsänderungen testen, die die Befugnis einer anderen Person verändern
Konfigurationsschreibvorgänge identifizieren, die indirekt Berechtigungen gewähren, selbst wenn ihr Endpunkt wie eine gewöhnliche Einstellungsbearbeitung aussieht. Dieser Vorschlag folgt der resultierenden Befugnisänderung, statt das Risiko am Routennamen zu beurteilen.
-
Der Object Data Manager: warum die Geräte- und Systemkonfiguration unter AIX nicht in einer Datei liegt
AIX speichert Gerätedefinitionen, SRC-Subsystemeinträge und viele Systemattribute als Objekte in der ODM-Datenbank (Object Data Manager) unter /etc/objrepos und /usr/lib/objrepos, nicht in editierbaren Textdateien. Unterstützte Schnittstellen sind lsattr, lsdev und chdev; chdev -P verschiebt eine Änderung auf den nächsten Neustart, statt sie sofort anzuwenden.
-
SMF-verwaltete Dienstkonfiguration mit svccfg ändern, statt die Konfigurationsdatei zu bearbeiten
Mit svccfg listprop/setprop lässt sich die persistente Konfiguration eines Dienstes im SMF-Repository lesen und schreiben; svcadm refresh übernimmt sie in den laufenden Snapshot. Wo SMF die Konfigurationsdatei eines Dienstes erzeugt (etwa /etc/resolv.conf aus network/dns/client), wird eine manuelle Änderung der Datei überschrieben.
-
Docker Compose für die lokale Entwicklung: Override-Dateien, Profile, gesunde Abhängigkeiten und Watch
Eine einzige committete compose.yaml pflegen, die die Produktionsform widerspiegelt, eine compose.override.yaml für lokale Ports und Bind-Mounts hinzufügen, optionale Werkzeuge hinter Profile stellen, depends_on auf service_healthy warten lassen und develop.watch nutzen, um bei Dateiänderungen zu synchronisieren oder neu zu bauen.
-
Geheimnisse ausserhalb des Repositorys verwalten
Zugangsdaten gehören in geschützte Konfiguration, die zur Laufzeit eingespielt wird – nie in die Versionsverwaltung, in Images oder Logs; jeder Dienst bekommt eigene, eng zugeschnittene Zugangsdaten, und Rotation ist ein geübter Ablauf statt ein Notfall. Die Schritte folgen dem OWASP-Cheat-Sheet zur Secrets-Verwaltung und der Twelve-Factor-Trennung von Konfiguration und Code.
-
Sichere Standardeinstellungen und Fail-Closed-Design
Das Fail-Safe-Defaults-Prinzip von Saltzer und Schroeder stützt Zugriff auf ausdrückliche Erlaubnis, sodass ein Fehler verweigert statt gewährt; heute angewendet bedeutet das: Autorisierung standardmässig verweigern, Konfiguration, die den Start verweigert, wenn eine Sicherheitseinstellung fehlt, und Fehlerpfade, die den Zugriff schliessen statt öffnen.
-
Implizite Typisierung in YAML 1.1 und 1.2: das Norwegen-Problem, Oktalzahlen und welcher Parser welche Regeln anwendet
Der Boolean-Typ von YAML 1.1 behandelt yes, no, on und off als Booleans und eine führende Null als Oktalzahl; das Core Schema von YAML 1.2 beschränkt Booleans auf true/false und verlangt für Oktalzahlen das explizite Präfix 0o. PyYAML, js-yaml und gopkg.in/yaml.v3 liegen dabei jeweils an einer anderen Stelle zwischen den beiden Spezifikationen.
-
Kernel-Parameter unter Linux mit sysctl setzen: Änderungen zur Laufzeit versus /etc/sysctl.d
sysctl -w ändert einen Kernel-Parameter nur bis zum nächsten Neustart; für eine dauerhafte Änderung gehört eine Datei in /etc/sysctl.d/, und die Ladereihenfolge über /usr/lib, /etc und /run muss bekannt sein. sysctl --system wendet alle konfigurierten Dateien an und zeigt bei Konflikten, welche Datei sich durchsetzt.
Maschinenlesbar: JSON