Welche Konfigurationselemente verfolgen Sie für ein ordnungsgemäßes Konfigurationsmanagement? [geschlossen]

Welche Konfigurationselemente halten Sie als professioneller Systemadministrator für wichtig, um eine ordnungsgemäße Konfiguration oder Änderungsverwaltung durchzuführen?

Verfolgen Sie unter Windows beispielsweise Registrierungsänderungen zusätzlich zu Hardware oder Software? Unter Linux unterscheiden Sie Konfigurationsdateien?

BEARBEITEN: Zur Verdeutlichung suche ich nach speziell zu verfolgenden (oder nicht zu verfolgenden) Elementen. Wenn Sie zusätzlich zu den Elementen, die Ihrer Meinung nach nachverfolgbar sind, Tools empfehlen möchten , fahren Sie fort.

[Hauptsächlich Unix / Linux-Voreingenommenheit, ich arbeite nicht auf Windows-Systemen :-)]

Alles, was nach einer Änderung den Status des laufenden Systems ändert, muss nachverfolgt werden. Die Konfiguration muss in einem Repository gespeichert werden, das den vollständigen Änderungsverlauf unterstützt, z. B. Git oder Subversion, und sie muss automatisiert bereitgestellt werden, z. B. mit Opscode's Chef oder Reductive Labs 'Puppet .

Einige Beispiele für Elemente, die den Status des Systems ändern:

• Installierte Paket- / Patch-Versionen.
• Bereitgestellte Anwendungen, Anwendungsbibliotheken.
• Administrations- und Anwendungsbenutzer.
• Hardwarekonfiguration und Gerätetreiber / -module.
• Geplante Wartungsarbeiten (cron unter Unix / Linux).
• Services und Komponenten, die von externen Tools überwacht werden.

Eine solche Nachverfolgung muss mit automatisierten Tools durchgeführt werden, die eine ausreichende Protokollierung für die Überwachung von Änderungen bieten. Ein Software-Repository-Verlauf zeigt den Verlauf der Änderungen in den im Repository gespeicherten Konfigurationsdateien an. In einem deklarativen Konfigurationstool wie Chef oder Puppet repräsentiert jede Konfigurationsdatei eine Reihe von Ressourcen wie Benutzer, Pakete oder Dienste, und der Repository-Verlauf zeigt Änderungen an diesen an.

Aus Sicht der Anwendung ist es wichtig zu dokumentieren

• Betriebssystem und Patch-Level
• Welche mehrschichtigen Produkte werden installiert und welche Patches wurden angewendet?
• Welche benutzerdefinierten und / oder Produkte und Bibliotheken von Drittanbietern werden einschließlich der Version installiert?
• Wo Sie Ihre Hände auf die Installationsquelle für diese benutzerdefinierten / Drittanbieter-Artikel legen können
• Produktschlüssel / SNs für alle oben genannten
• Serverkonfiguration auf Anwendungsebene (z. B. Web, E-Mail usw.)
• Eine Kontaktliste, wenn auf Anwendungsebene ein separates Entwicklungsteam zuständig ist
• Backup-Konfiguration

Hinweis - Als Antwort auf den Kommentar von romandas in der Frage weiß ich, dass dies nicht genau ein Element ist, aber ich betrachte das Gesamtdokument in diesem Fall als ein Element

Für Windows sollten Sie keine Patch-Levels des Betriebssystems "verfolgen" müssen, da diese jederzeit über WMI abgefragt werden können. Wenn Sie dem Änderungsmanagement folgen, können Sie vor und nach einer Änderung eine globale Abfrage durchführen, um die Ergebnisse eines Betriebssystem-Patches zu überprüfen. (Stellen Sie sicher, dass der MSI-Anbieter installiert ist.)

Treiberaktualisierungen sollten nachverfolgt werden (wmi kann verwendet werden, um sie abzufragen, aber es lohnt sich nicht, sie alle abzufangen). Aktualisierungen von Softwareanwendungen sollten in der CMDB gespeichert werden, sollten jedoch (außer anfangs) vom Änderungsmanagement stammen, wenn Sie dies wirklich wollten Um Registrierungsänderungen zu verfolgen, legen Sie eine Gruppenrichtlinie fest, um den Datei- und Objektzugriff zu ermöglichen, und wählen Sie aus, welche Schlüssel überwacht werden sollen ( http://support.microsoft.com/kb/324739 ). Dies ist nicht für eine CMDB gedacht, aber Sie können verfolgen, wer Änderungen vornimmt.

Das ist es, was Leute normalerweise in einer CMDB verfolgen möchten und warum es manchmal keine gute Idee ist, also was in eine CMDB gehen sollte. Die Antwort ist, es kommt darauf an. Eine ITIL-definierte CMDB kümmert sich möglicherweise nicht um Maschinenkonfigurationen, es sei denn, diese bestimmte Maschinenkonfiguration bezieht sich auf einen Dienst. ACMDB enthält möglicherweise auch eine Asset-Tracking-Lösung (z. B. Speicherort der Hardwarekonfiguration und Garantieinformationen), befasst sich jedoch eher mit den Beziehungen eines bestimmten Konfigurationselements zu einem anderen CI. Zu den Beziehungen gehören Dinge wie "ist verantwortlich für", "ist verbunden mit", "hängt ab von" und (schwieriger, aber in vielen Fällen wichtiger) "erforderlich für SLA tier_". Kurz gesagt, notieren Sie, was zum erneuten Erstellen des Dienstes erforderlich ist - nicht des Servers.

Zum Beispiel. Wenn E-Mail der Dienst wäre, würde ich Dinge auflisten wie:

Hardware: 64-Bit-CPU, 3 GB RAM (basierend auf der Anzahl der Benutzer auf @today) 7 GB Speicherplatz für die Serverinstallation, 100 GB Speicher für Exchange-DBS und Wiederherstellung (basierend auf der Nutzung ab @today), DVD-ROM-Laufwerk.

Software: Server 2003 R2, Exchange 2007 SP2, MPIO-Treiber für das SAN

usw...

CMDBs sind normalerweise nicht für die Verwendung durch Serveradministratoren vorgesehen. Administratoren werden mit einer Asset-Management-Lösung weitaus zufriedener sein.

Betriebssystem-Patch-Level. Was viele Dinge bedeuten könnte. Im Idealfall verfolgen Sie in einer Matrix, welche einzelnen Patches sich auf welchen Computern befinden. Die Version des armen Mannes ist ein "letztes Patch-Datum" für jeden Server (vorausgesetzt, Sie ziehen jedes Mal alle Updates im Großhandel ein).

Unter UNIX / Linux teile ich Konfigurationsdateien in zwei Gruppen ein: diejenigen, die vom Betriebssystem bereitgestellt werden, und diejenigen, die Teil unserer benutzerdefinierten Anwendung (en) sind.

Alle Anwendungskonfigurationsdateien werden in unserem Quell-Repo gespeichert. Ich habe unterschiedliche Standardkopien für jede Installation (Entwickler, Qualitätssicherung, Produktion, Vorproduktion, Demo ...). Wenn wir feststellen, dass wir eine dieser Änderungen vornehmen müssen, erfolgt die Änderung zuerst in der Quell-Repo-Kopie und wird dann auf den erforderlichen Servern bereitgestellt. Wir öffnen auch eine entsprechende Änderungsanforderung im Issue-Tracker.

Für Konfigurationsdateien vom Typ Betriebssystem haben wir sie möglicherweise im Quell-Repo oder nicht. Wenn dies der Fall ist, verwenden wir den oben beschriebenen Prozess. Wenn nicht, werden sie in das Repo aufgenommen, wenn die Anzahl der Änderungen einen bestimmten willkürlichen Schwellenwert erreicht. Bis dahin öffnen wir mindestens ein Ticket im Issue-Tracker, um diese Änderung zu verfolgen.

Ein großartiges Merkmal unseres Issue-Trackers ist auch die Möglichkeit, Quell-Repo-Commits zu indizieren. Es bindet Ihre Tickets ganz gut an Ihre Konfigurationsänderungen.

Für Netzwerkgeräte wie Cisco-Switches sammle und verfolge ich gerne deren Start- und Ausführungskonfigurationen in einem Versionskontrollsystem. Wenn möglich, speichere ich auch den Benutzernamen, der die Bearbeitung durchgeführt hat.

Ich rufe dies normalerweise über ein Perl-Skript ab, es sei denn, ich habe die Option, die Protokolle automatisch zu überwachen und die Konfigurationssammlung aus Protokolldaten auszulösen.

Für Netzwerkgeräte ist RANCID (der automatische Konfigurations-Grabber) ideal.

Für Server eine Kombination aus Etckeeper (/ etc / in einem VCS behalten) und Puppet (mit seiner Konfiguration in einem VCS).

Windows:

• OS Version
• OS Service Pack
• Sicherheitspatches
• Prüfungsrichtlinie (sollte über das Gruppenrichtlinienobjekt durchgesetzt werden)
• Mitglieder von Administratoren, Hauptbenutzern und Remotedesktopbenutzern
• Liste der installierten Anwendungen
• Netzwerkfreigaben