Konfigurationsmanagement und Geräteklassen?
-
Hi,
es würde viel Arbeit und Pflege ersparen wenn es möglich wäre, eine Konfigurationsklasse einem Gerät zuordnen zu können- das individuelle Objekt würde dann nur noch die tatächlich einmaligen Merkmale enthalten.
Anstatt alle einzelnen Merkmale manuell zuzuordnen, könnte das über Zuweisung zu einer Klasse automatisch geschehen.
Ein weiterer Vorteil wäre, dass sich eine Änderung z.b. im Wartungsplan (anderer Dateiname) automatisch in allen betroffenen Objekten
sichtbar wird.Beispiel:
Objekt: server.aussenstelle.dom
< DomaenencontrollerObjekt: Standardserver für Aussenstellen:
< Domaenencontroller
< Sicherungsystem
< Notfallplan
< WartungsplanStandardserver
Objekt: Domaenencontroller:
<samba<br><dhcpd<br><bind<br>> Domaenencontroller(In unserem KMS: < = benötigt, > = ermöglicht)
Grüsse,
radix</bind<br></dhcpd<br></samba<br> -
Hallo Radix,
die Idee ist grundsätzlich sehr gut. Wir hatten etwas ähnliches auch schon zur 0.9 geplant, aber aus Komplexitätsgründen zunächst aufgegeben. Ich denke aber, das über kurz oder lang entsprechende Funktionen kommen werden.
Die dauerhafte Bindung einer "Klasse" mit den daraus erzeugten Objekten ist nur schwierig zu implementieren. Neben seiner Template-Funktion hätte das sicher den Vorteil, das auch Änderungen nur einmalig erfolgen müssen, aber das zusammen zu halten ist sportlich…
Der Hinweis auf den Wartungsplan ist nicht haltbar, da die in i-doit eingepflegten Dateien versioniert werden und somit eine neue Datei automatisch in allen Referenzen aktualisiert wird.
-
Hallo Jocki,
Dankeschön für die Antwort!
@jocki:Die dauerhafte Bindung einer "Klasse" mit den daraus erzeugten Objekten ist nur schwierig zu implementieren. Neben seiner Template-Funktion hätte das sicher den Vorteil, das auch Änderungen nur einmalig erfolgen müssen, aber das zusammen zu halten ist sportlich…
Ich hatte da an sowas wie ein zusaetzliches Class-Field gedacht dass ein Objekt 'flaggt'. Dann muesste man die von der Klasse kontrollierten Unterobjekte laden und beim eigentlichen Laden des abgerufenen Objektes die entsprechenden von der Klasse kontrollierten Unterobjekte mit denen der Klasse überschrieben werden. Solange die Klassenfelder nicht innerhalb des erbenden Objektes nach Zuordnung zu einer Klasse änderbar sind, könnte das gehen. Wenn jeweils nur ein oder zwei Unterhierarchien einer Klasse angezeigt werden sollte sich der Rechenaufwand in Grenzen halten - wenn er auch schätzungsweise doppelt so hoch ist wie der für normale Objekte.
Ok - sobald eine Klassenbindung aufgehoben oder eine Neuzordnung erfolgt, wird es kompliziert, da für alle betroffenen Objekte festgestellt werden müsste, was sich ändert - und gegebenenfalls manuelle Korrektur erfordert.
Hmm - doch nicht so einfach wie ich dachte
Der Hinweis auf den Wartungsplan ist nicht haltbar, da die in i-doit eingepflegten Dateien versioniert werden und somit eine neue Datei automatisch in allen Referenzen aktualisiert wird.
Ok - war dumm formuliert:
Ich meinte damit: das Objekt Wartungsplan wird automatisch über die Klasse zugewiesen und muss nicht für jeden Server einzeln manuell definiert werden obwohl die Datei jeweils dieselbe ist.Grüsse,
radix
(freut sich auf 1.0 ) -
Quasi ein Wartungsplan für alle Objekte des Typs "Server" in diesem Falle?
-
Ja, genau.
Ich arbeite viel mit Standardplänen für Geräteklassen und auch Lokationen, selbes gilt für Prüf- und Fehlersuchlisten etc.
Damit werden gute 90% 'erschlagen'. Nur Applikations- und Projektserver haben eigene, erweiterte Wartungspläne: den Standardwartungsplan
(für Umgebung, Os etc.) und den Applikationswartungsplan (an die App gebunden - geht in I-doi bereits).Grüsse und eine schönes WE,
radix -
Schön wäre also eventuell ein Standardplan, der einem ganzen Objekttyp zugewiesen werden kann, und dazu dann noch die Möglichkeit einen geänderten Plan einem Objekt dieses Objekttyps zuzuweisen.
Danke für den Tipp!
