[sage] Protokollierung von Änderungen

[Benedikt Stockebrand]

Moin Liste,

Peter Hinse <loco at d0pefish.de> writes:

> Für Konfigurationen ist das klar - was aber mache ich mit Änderungen wie
>
> "Festplatte an Datenbank Server getauscht"
> "Update der Firmware in Switch XY"

wenn Du einen halbwegs homogenen Zoo von Hardware hast,
kannst/solltest Du das soweit es geht automatisieren.  Diese Sachen
lasse sich typischerweise mit etwas Scripterei auslesen und in ein
Wiki schieben.  (Vermutlich gibt es auch für hinreichend viel Geld
noch kommerzielle Lösungen, die mit Glück vielleicht sogar einen
relevanten Teil Deines Geräteparks kennen.)

Mit automatisierten Inventories lassen sich auch Änderungen einfangen,
bei denen jemand die Doku nicht aktualisiert hat.  Das ganze ist also
auch in Umgebungen, wo ein "richtiges" Change Management eingesetzt
wird, immer noch hilfreich, weil es den Ist-Zustand widerspiegelt,
nicht den Soll-Zustand.

> "Umzug von Server A nach Rack Z"

Da wird's schwierig, und zwar auch in Verbindung mit Wikis: Ab einer
gewissen Größe will ich sowohl über das Rack den Server als auch
umgekehrt über den Server das Rack finden können.  Noch komplizierter
wird es, wenn es um Verkabelungen geht, dann kommen plötzlich
Racks/Patchports mit Switches und VLANs zusammen.  Von virtuellen
Maschinen, die vielleicht auch noch automatisch zwischen Hosts hin und
her geschoben werden, will ich da gar nicht reden.

Entweder wird es dann irgendwann redundant, und damit früher oder
später inkonsistent, oder ich habe die Konfigurationsdaten einer
Maschine über x Seiten verteilt und habe ziemlichen Aufwand, das ganze
zu pflegen.

Noch ein anderes Problem, wenn es um Wikis geht, ist die Frage, was
passiert, wenn mehrere Leute gleichzeitig an der zentralen
Patchfeld-Tabelle oder sowas rumbasteln.  Und ab einer gewissen Größe
machen Tabellen in Wikis nun auch nicht mehr unbedingt Spaß.

Andererseits habe ich bisher für halbwegs überschaubare Umgebungen
nichts besseres als ein Wiki gefunden: Wenn's richtig rappelt, will
ich persönlich nicht erst einen Datenbank-Server wiederbeleben müssen,
weil's den bei der Gelegenheit auch mitgerissen hat.  Wikis sind da
nach meiner Einschätzung etwas robuster: Die kann ich auf ein Notebook
mit zwei Platten packen und habe erstens gleich eine unabhängige USV
drin und kann mir das Ding im Katastrophenfall einfach unter den Arm
klemmen, um vor Ort nachsehen zu können.

In wirklich großen Umgebungen sehe ich aber keinen Weg um eine DB
herum.

Und noch was zu Snoopy's "plod": Ich habe vor fast zwanzig Jahren mal
sowas als reichlich primitives Shell Script geschrieben.  Das hatte
gegenüber plod auch noch den Vorteil, dass ich den Rechnernamen nur
angeben musste, wenn ich den Log-Eintrag von einer anderen Maschine
aus gemacht habe.


Viele Grüße,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.