Wie dem auch sei: Ich habe den Vergleich nicht erfunden, aber er zeigt
doch sehr schön, dass die Welt (mindestens) zwei Seiten hat.
Eine Seite ist die des (Hobby)admins, der eine Konfiguration ändert
und sich dabei kein vermeidbares Chaos anrichten soll. Die andere
Seite ist die des Fehlersuchers, der weiß, das irgendwas nicht stimmt
und der deshalb nichts ungeprüft glauben darf. Wobei ich da schon nach
steigendem Grad der Professionalität gewichten würde.
Naja, nicht unbedingt. Das Problem ist ja Ursache und Wirkung. Wenn Du
völlig autark als einziger (Hobby)admin eines Systems irgendwas änderst
und das nicht in einer für Dich später nachvollziehbaren Art und Weise
dokumentierst, dann schießt Du _nur_ Dir selbst in den Fuß.
Sobald auch nur eine einzige weitere Person involviert ist (im
professionellen Umfeld der Regelfall, sei es Kollege, Systemhaus oder
der externe Dienstleister, der wegen Projekt XY mal kurz Zugriff auf das
System bekommt), weißt Du nicht, _ob_ und _wie sehr_ Dir wer anders in
den Fuß geschossen hat. Du darfst einfach nicht mehr davon ausgehen, daß
der dokumentierte Zustand (und seiens nur Absichtserklärungen in Konfig-
Dateien) dem realen entspricht. Im Zweifel musst Du davon ausgehen, daß
Doku und Realität auseinanderklaffen und musst Gewahr sein, daß Dich ein
Vertrauen auf Ersteres ggf. unnötig tief in den Wald führt, weil Du den
Fehler machst, anzunehmen, daß es so ist (realer Systemzustand) wie es
sein sollte (dokumentierter Systemzustand).
Wir haben bspw. von einem Systemhaus die Konvention übernommen, alle
Änderungen an Unix-System in einer Datei /etc/CHANGES zu protokollieren
und versuchen das auch Admins bei Kunden beizubringen. Netter Ansatz,
der aber nur funktioniert, solange alle sich sklavisch dran halten.
Sobald da einer das Schludern anfängt (bei Admins nach anfänglicher
Begeisterung nach ca. 1-n Tagen/Wochen der Fall), ist das nix mehr wert,
d.h. taugt bei allfälliger Fehlersuche nur noch als rudimentäre
Informationsquelle, weil man davon ausgehen muß, daß nur ein Teil der
Änderungen drinsteht. Wenn man Glück hat, findet man 'ne Korrelation
zwischen dem gemeldeten Auftreten eines Problems und dokumentierten
Änderungen und erhält dadurch einen schnellen Ansatz, die Korrelation
hinsichtlich Ursache fürs Problem zu prüfen.
Der Umkehrschluß ist aber tödlich, d.h. davon auszugehen, wenn nix in
/etc/CHANGES steht, daß dann auch nichts geändert wurde. Zumal gerade in
komplexeren Applikationslandschaften die Änderungen auf ganz anderen
Systemen Auswirkungen auf das lokale haben können, auf das man beim
Kunden gestubst wird mit der Ansage "geht nimmer".
Der Ansatz, Konfig-Änderungen sauber zu dokumentieren, ist toll, weil er
im Fehlerfall für Zeitersparnis durch schnelleres Eingrenzen des
Problems führen _kann_. Aber im Fehlerfall drauf zu vertrauen, daß Doku
und Realität kongruent sind, ist naiv.
Post by Goetz HoffartPost by Wolfgang MeinersIch würde noch einen Punkt hinzufügen: Wenn du als Admin die
Konfiguration eines Programms änderst, halte dich peinlich genau an
die Standards. Sonst vermehrst du im Zweifel das Chaos.
Welche Standards?
Bleiben wir bei OpenSSH. Die Standards, die in der Konfigurationsdatei
# The strategy used for options in the default sshd_config shipped
# with OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override
# the default value.
Behalte ich diese Strategie bei, dann kann ich im Zweifelsfall sehr
einfach herausfinden, ob ein Fehler auf eine Fehlkonfiguration
meinerseits zurückzuführen ist (fast immer), oder ob doch der böse
Hersteller oder irgendwer dazwischen den schwarzen Peter kriegt.
Nö, leider nicht mal das. Dein Ansatz taugt abseits *ein einziger*
(Hobby)admin eh schon nix, weil Du nicht weißt, was die anderen machen
bzw. wie diese schludern oder nicht. Er taugt noch nicht mal, wenn Du
der einzige Admin des Systems bist und während einer Fehlersuche unter
Zeitdruck viel an der Konfig ändern mußt. Denn anschl. steht in der
Konfig-Datei ein kommentierter Wert, den nicht die OpenSSH-Jungs sondern
Du gesetzt hast. Und den Du von nun an falsch als default interpretierst
(Streßsituationen machen ganz interessante Sachen mit Menschen. Speziell
bzgl. Wahrnehmung. Du kannst Dich ab und an noch nicht mal dran
erinnern, dies&das hier&dort geändert zu haben -- spannendes Feld).
Und im speziellen Fall der sshd_config sich drauf zu verlassen, daß die
Policy, die vielleicht für die Original-Version der Datei mal gegolten
hat, als sie bei OpenSSH ausgecheckt wurde, noch gilt, nachdem sie der
Hersteller des OS, der OpenSSH als Teil seines OS verbaut, ggf. angepaßt
hat, ist ehrlich gesagt nur naiv.
Es kann auch nicht schaden, vor dem Ändern einer Konfigurationsdatei
das Original abzuspeichern.
Aber natürlich. Eine noch viel tollere Idee ist, alles Konfig-Relevante
in einem System in ein Versionskontrollsystem zu klatschen, so daß Du
eine lückenlose Dokumentation sämtlicher Änderungen erhälst (machen wir
in einigen Installationen, alles in SVN zu werfen und überall dort, wo
es keine textbasierte Konfig mehr gibt -- weil Datenbank-basiert bspw.
-- das einerseits 1:1 ins SVN zu werfen und andererseits einen Textdump
der Konfig wegen schnellem Prüfen von Änderungen danebenzulegen).
Nur um dann festzustellen, daß die Datenbank-Dumps der Konfiguration
nach kleinen Änderungen in komplett anderer Reihenfolge ausgespuckt
werden (was diffs zwischen alter und neuer Version witzlos macht) und um
festzustellen, daß diverse Softwares defaults aufweisen, die erstens auf
keinem Weg ausgelesen werden können, zweitens vom Hersteller mit einem
kleinen Update stillschweigend geändert werden und drittens nach
irgendeiner anderen -- auf den ersten Blick völlig unabhängigen --
Änderung sonstwo im System *nicht reproduzierbar* Probleme verursachen.
Wer auch immer von dieser Strategie abweicht -ohne eine bessere
Strategie zu beschreiben- erzeugt Chaos. Und eine solche Strategie in
der Konfiguration zu beschreiben, ist eine gar nicht so dumme Idee.
Die muss man sich ja immerhin angucken, wenn man was daran ändern
will.
Stimmt nach meiner Erfahrung so nicht.
Es ist auf der einen Seite natürlich sehr sinnvoll, so viel wie möglich
an Konfig-Änderungen zu dokumentieren, dafür ggf. eigene Standards zu
implementieren und für deren Einhaltung gegenüber Kollegen, Externen,
etc. zu kämpfen.
Genauso sinnvoll ist es aber auch, in Diagnose-Situationen das maximal
als vagen Anhaltspunkt aber nie für bare Münze zu nehmen.
Und irgendwelche Standards, die sich völlig fremde Menschen beim
Erstellen einer Software auf die Fahnen geschrieben haben als _im
konkreten Fall_ gültig anzusehen, halte ich für naiv bzw. alles andere
als zielführend, wenn man ein Problem analysieren soll. Es sind
Absichtserklärungen, die einem nix bringen, weil man nicht weiß, ob sie
(noch) stimmen. Man muss sie überprüfen. Dummerweise bieten häßlich
viele Softwares nur einen unvollständigen Dump ihrer aktuell zur
Laufzeit aktiven Konfiguration an, der besagte "defaults" sehr oft
ausläßt.
Gruss,
Thomas