Danke, ich wusste nicht, dass die xml-Dateien fuer den dbdesigner sind.
Mit dem bin ich naemlich auch schon auf die db losgegangen, der konnte aber die Relationen nicht aufloesen 
src/classes/cmdb/action habe ich mir auch schonmal angeschaut, aber noch nicht alles verstanden - bald ist WE, da habe ich mehr Zeit
Danke und Gruesse,
radix
Hand heb
Ich habe vor ein paar Tagen schon mal etwas rumgespielt.
Die Kernfunktion für neue globale Objekte ist wohl insert_new_obj in src/classes/cmdb/dao/isys_cmdb_dao.class.php
. Wenn ich mit dem SQL Query ab Zeile 1531 ( // store virtual name and sys_id to catg_global) nach Erzeugen einer sys_id in catg_global_list einen Eintrag neu anlege klappt das auch, nur ist das Objekt im Webinterface nicht sichtbar - es fehlt mir also wohl noch eine 'Registrierung' in einer anderen Tabelle.
Was genau machen die catd_ Tabellen?
Ich bin schon mit MicroOlap und der Analysefunktion auf die idoit_data losgegangen (gab erstmal einen 'Uff!'-Effekt :), aber so ganz begriffen habe ich die Abhängigkeiten der Tabellen noch nicht.
BTW: Ist es richtig, dass einige Tabellen nicht mit anderen oder nur mit einer weiteren verknüpft sind (isys_cats_building_list z.b. bzw isysgui_catd und isysgui_catd_tpl) oder hat der Analysator manchmal Mist gebaut?
viele Grüsse,
radix
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
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 )
Hi,
es würde viel Arbeit und Pflege ersparen wenn es möglich wäre, eine Konfigurationsklasse einem Gerät zuordnen zu können
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
< Domaenencontroller
Objekt: Standardserver für Aussenstellen:
< Domaenencontroller
< Sicherungsystem
< Notfallplan
< Wartungsplan
Standardserver
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>
Prüfen ob der i-doIT DB Benutzer tatsächlich auf die DB zugreifen kann.
(mysql -u i-doIT -p ).
Zumindest unter FC4 geht im MySql ein ANY-HOST nicht, muss man auf localhost setzen, dann geht`s.
zumindest bei mir 
docman und mod_docman ist schon ein erheblicher Unterschied. :oops:
Jetzt klappt`s auch.
Allerdings gibt es immer noch eine Menge Notices von PHP bezueglich nicht definierter Variablen.
Hallo,
nach der Installation von 0.8.6 kann ich mich zwar anmelden, allerdings kommt dann folgende Fehlermeldung:
Table 'doit._configuration' doesn't exist
-> richtig, die gibbet ned… zumindest nicht in der doit
Table 'docman._updates' doesn't exist
-> die gibt`s allerdings... in der mod_docman
Beim Einspielen des Sql-Scripts gab es keine Fehlermeldungen,
(Den doppelten ID-Schluessel in der cdromserver-Tabelle habe ich gefixt durch loeschen des doppelten Keys).
Lege ich die _configuration Tabelle manuell in der doit - Db an, bekomme ich zwar das linke Menue und die Unterbereiche erscheinen auch, aber der docman._updates Fehler besteht weiterhin (Anlegen von IT-Elementen).
Beim Versuch einen Arbeitsauftrag zu erstellen gibt es einen "Incorrect Tablename '' " - Fehler.
Bin da gerade ziemlich ratlos...
Wer kann helfen?
Umgebung:
OS: Fedora Core 4
PHP 5.0.4 (mit allow_call ... = true)
MySql 4.1.20
Selinux=off
Dankeschön!
radix