Da liegt wohl ein Fehler vor: Entweder im Addon oder im Validierungscode von i-doit. Ich würde also empfehlen: Backup der Datenbank machen Unter Verwaltung -> Systemeinstellungen -> Experteneinstellungen einen Eintrag api.validation = 0 erzeugen (Ich glaube, der ist nicht per default vorhanden). Je nach Geschmack dann System- oder Tenent-wide. Noch mal den Import anstoßen und gucken was passiert.

Hi, ist mir auf meinem System auch aufgefallen und scheint ein Bug zu sein, der mit dem kommenden Minor-Release behoben wird. Lieben Gruß Christian

Hallo Christian, danke für die Info, aber das ist leider nicht die Antwort die ich hören wollte. Das Ziel ist ja, möglichst wenig in anderen Tools (wie hier Excel) machen zu müssen. Außerdem hatte ich vor, den Export aus unserem Inventory-Tool zyklisch in i-doit einlesen zu lassen, damit evtl. veränderte Hostnamen auch in i-doit übernommen werden. Dann werde ich mal schauen wie ich irgendwie die Daten möglichst simpel und automatisiert in i-doit bekomme. LG Thomas

Hallo André, den Button siehst du zum einen, wenn du das Recht dazu hast. Heißt, du kannst auch ohne Admin-Rechte arbeiten, um den Button nicht mehr zu sehen. Dazu kannst du ihn an vielen Stellen deaktivieren, in dem du in der Verwaltung in den Systemeinstellungen den Quickpurge-Button deaktivierst: [image: 1549331193744-16f73c97-a0eb-42c8-a199-10f6277760d6-image.png] [image: 1549331154571-6a3829d8-fbf0-49f9-972d-bb6d0cdf5727-image.png] Lieben Gruß Christian

Hi, funktioniert denn die Suche? Hast du mod rewrite aktiviert? -> https://kb.i-doit.com/pages/viewpage.action?pageId=10223831#DebianGNU/Linux-ApacheWebserver Lieben Gruß Christian

Guten Tag Herr Menzel, hier hilft ein leeren des Cache von i-doit damit Änderungen, im Rechtesystem, sofort übernommen werden.

Mit Hilfe des Supports unter help.i-doit.com wurde das Problem nun behoben. Danke! Bei uns war die PHP-Extensions php-zip nicht installiert. Vermutlich lag dies daran, dass der Server unter Debian 8 aufgesetzt worden war und dann später - während i-doit bereits installiert war - auf die Debian-Version 9 aktualisiert wurde. Die Zip-Extension von PHP war in der Installationsdoku von Debian 8 nicht als Requirement aufgeführt. Beim Überprüfen der installierten Extensions fiel dann noch auf, dass auch die Extension php-mbstring fehlte. Falls jemand also dasselbe Problem hat, am besten mal diese beiden Extensions kontrollieren.

@creiss Das hilft aber nicht wirklich. Da wird das Passwort dann in dem Skript an das PHP-Skript weitergegeben und erscheint wieder in der Prozesstabelle für alle sichtbar. Ich hab vom Support aber mittelerweile eine Info bekommen: Unter src/handler/config/examples/isys_handler_ldap.ini findet man die neuen beispielhaften Konfigurationsdateien die mittels --config oder -c dem entsprechenden Command übergeben werden können (absoluter Pfad). In einer solchen Datei gibt es die Gruppen [commandArguments], [commandOptions]. Mittels dieser Gruppen können dem Command Args oder Optionen übergeben werden, welche das sein können sieht man in der Hilfe des entsprechenden Commands (--help). Für diesen Anwendungsfall sähe das dann so aus: [commandArguments] [commandOptions] user=admin password=admin tenantId=1 Das funktioniert problemlos. Die Informationen sollen in Kürze auch in die KB übernommen werden.

Hallo zusammen, gibt es hier ein Best practice Ansatz für dieses Thema? Wir haben hier genau das gleiche Problem. Viele Grüße Daniel

Moin Moin, ich hätte da noch eine Ergänzung. Ich habe die RAIDs über mehrere Shelfs verteilt (wg Performance und Ausfallsicherheit). Könnte das auch mit aufgenommen werden?

Hey @Batzlen und @klaus-langthaler wir haben uns dran gesetzt und letzte Woche die neue Version des Add-ons veröffentlicht, damit sollte das Problem behoben sein Könnt ihr das bestätigen? VG Leo

genau. ich lass meine user ein virtual server objekt befuellen.. mehrere kategorien.. am schluss setzt der user den status auf 'to_deploy', und nur auf dieses event reagiere ich in einem eventhook, und stosse dann den deploy-eine-vm prozess an... die logik um das event zu filtern ist relativ kompliziert geworden.. weil 10mal nachbessern.. function check_event($event) { // at idoit overview category savebutton click -> we get two events, global and overview // at idoit global category savebutton click -> we get only one event if ($event->categoryConst=='C__CATG__OVERVIEW') { die (getmypid().": not reacting on events of overview category. quitting\n"); } //print_r ($event); $proceed=false; if ($event->categoryConst=='C__CATG__GLOBAL') { if (count ($event->changes)==0) die (getmypid().": no changes. quitting\n"); if (isset ($event->changes->C__OBJ__CMDB_STATUS->to)) { if ($event->changes->C__OBJ__CMDB_STATUS->to !=STRING_DEPLOY) die (getmypid().": status didnt change to '".STRING_DEPLOY."'. quitting\n"); else $proceed=true; } if (isset ($event->changes->{'isys_cmdb_dao_category_g_global::cmdb_status'}->to) ) { if ($event->changes->{'isys_cmdb_dao_category_g_global::cmdb_status'}->to!=STRING_DEPLOY) die (getmypid().": status didnt change to '".STRING_DEPLOY."'. quitting\n"); else $proceed=true; } } if ($proceed) debug( "checking server...\n"); else die (getmypid().": event didnt match categories global or cmdb_status, quitting\n"); } function get_event() { $deploy=""; while($l = fgets(STDIN)){ $deploy.=$l; } $event=json_decode(base64_decode($deploy)); if (json_last_error()) die (getmypid().": error json decode, quitting\n"); return $event; }

Ja, daran lag's. Wenn man diesen Fehler nicht macht, klappt es problemlos. Vielen Dank!

Bin ich der einzige, der darauf stößt? Kann das niemand an einem anderen System reproduzieren? Bei dem Thema fällt mir auch auf, dass es das VIVA2 Modul im Demo-System gar nicht gibt. Sonst hätte ich das dort gerne mal getestet.

Hallo zusammen, ich würde auch empfehlen, das Ablaufdatum in der Kategorie "Lizenzschlüssel" inklusive der Benachrichtigungen zu verwenden. Bei einer Verlängerung kann das Datum dann auch einfach hochgesetzt werden. Lieben Gruß Christian