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

Hallo Steffen und liebe Leser, Ich mache den Export momentan auch direkt in das produktive Nagios-etc. Abgesehen davon, dass bisher die erzeugte Konfiguration auch bei mir noch Grütze ist, scheint das so zu funktionieren, wenn du das nagios-etc für www-data schreibbar machst. Die Kontakte werden über eine Kategorie ins Nagios gebracht. Bei Personengruppen findest Du eine Kategorie "Personengruppen->Nagios", bei Personen die Kategorie "Personen->Nagios". Sobald diese ausgefullt sind, bevölkern sie die contacts.cfg. (Beispiel) Über den dritten Punkt bin ich auch gestolpert. Diese Kommandos sind schlicht noch nicht definiert. Wenn Du das tun möchtest, gehst Du auf "Extras => Nagios => Commands" (vergleiche hier) und legst die Kommandos mit den passenden Namen an. Oder einfacher Du vergibst unter "Extras => Nagios => Config" die bereits vorimplementierten Kommandos. Zum Zeitpunkt der Installation gibt es nur die 2 Benachrichtungen (notify-......) und 2 Checks (check-......), die wir eben schon gesehen haben. Dementsprechend änderst Du den Wert für: -- global_host_event_handler in notify_host_by_email -- global_service_event_handler in notify_service_by_email -- obcp_command in notify_host_by_email und -- ocsp_command in notify_service_by_email All Best BEnnie

Hallo, vielleicht war die Frage ja zu trivial; falls doch der ein oder andere vor dem selben Problem steht: Ja, es geht. Das command maintenance steht auch noch in der console zur Verfügung, auch wenn es im KB-Artikel zu Console nicht auftaucht. Der Weg: KB-Artikel Cronjobs einrichten Aufruf der Console vereinfachen; dazu das Skript idoit mit angepasstem Inhalt anlegen, anschliessend ausführbar machen. Das Jobskript idoit-jobs anlegen, ebenfalls mit angepasstem Inhalt. Als weitere Funktion kann hier dann zusätzlich auch "maintenance" mit eingepflegt werden. Als Nicht-Linuxer bin ich erstmal darüber gestolpert, dass am Anfang der Datei versehentlich eine Leerzeile stand. Damit wurde das Skript mit sh anstatt mit bash ausgeführt, was zum Abbruch führt, sobald das Skript über cron gestartet wird. Manuell ausgeführt lief es komischerweise. Zur Kontrolle ssmtp und mailutils nachinstallieren und die ssmtp.conf sowie revaliases anpassen. Das Paket moreutils nachinstalliert (Darin enthalten ist chronic). Cronjob anlegen, der einmal täglich das Skript idoit-jobs über chronic ausführt. Anschliessend werden die Wartungsmails automatisch verschickt und man kann auch die Benachrichtigunen ("notifications-send") sinvoll nutzen. Gruß