Hi, aktuell ist der einzige Workaround, die CPUs als eigenen Objekttypen anzulegen, dem Server zuzuweisen und darüber die Lizenz zu dokumentieren. Derzeit ist aber noch offen, wie wir zukünftig mit der Dokumentation von unterschiedlichen Lizenzarten umgehen werden. Besten Gruß

Hi, in unserer Knowledge Base wird es bald einen ausführlichen Eintrag zu dem Thema geben. Hier aber mal die Unterschiede vorab: Die Unterschiede zwischen JEDI und JDisc im Detail Es können keine Add-Ons installiert werden. Dazu gehören das Dependency Mapping Add-On für die grafische Anzeige der TCP- und UDP-Verbindungen untereinander und das Device History Add-On für die Anzeige aller Änderungen zwischen den Scans. Allerdings ist in JEDI das Networking Add-On enthalten, das die Netzwerktopologie aufzeigt. JEDI enthält keine Custom Attribute und Custom Reports. Das ist auch nicht nötig, denn das Reporting findet ausschließlich in i-doit statt. Die Gerätegruppierung ist mit JEDI nicht möglich. Überbrücken lässt sich dies durch unterschiedliche JDisc-Profile beim Datenimport. Es sind keine zeitgesteuerten Scans möglich. Über die Remote-Steuerung kann i-doit allerdings via Cronjob jederzeit Scans anstoßen. Es werden keine graphischen Maps angezeigt. Außerdem werden die folgenden Elemente von JEDI nicht eingesammelt: Video Controller Netzwerk Adapter Direkt angeschlossene Geräte Tonerstände bei Druckern Benutzer Prozesse Ports von Datenbanken Liste aller ausführbaren Dateien Liste aller Services Liste aller Patches Ausführen von Custom Scripten zum Füllen von Custom Attributen Besten Gruß

Hallo Leo, das ist aber sehr schade bzw. schon fast frustrierend. LOGINventory ist bei uns seit vielen Jahren "gesetzt" - an Datenqualität bzw. weitestgehend auch -quantität quasi konkurrenzlos. Würde mich gerne näher mit euerem Tool beschäftigen aber mit diesen Aussichten…. Mich würde interessieren warum der Support auf einmal fallen gelassen wurde!? Normalerweise arbeitet man doch in diesem Bereich - gerade wenn man Schnittstellen zur Verfügung stellt - mit dem Hersteller zusammen!? Das scheint hier wohl nicht der Fall gewesen zu sein oder? Sehr schade vielleicht überlegt Ihr euch das noch mfg Stefan

Ich bin jetzt weiter, oder auch nicht. Habe nun eine SQL-Standardinstanz. In i-doit passiert schlicht nichts, wenn ich die Importfunktion aufrufe. Es wird nur eine einzeilige Logdatei geschrieben, jedes Mal: i-doit 1.6.1 PRO host URL cmdb.domain.de log for "import_loginventory" started at 2015-11-29T20:55:20+01:00 written to "/var/www/vhosts/cmdb.domain.de/httpdocs/log/import_loginventory_2015-11-29_20_55_20.log" Aber sonst nichts, keine Fehlermeldung, keine Reaktion, keine Assets. Dem Umstand, dass die Fehlermeldung weg ist, entnehme ich, dass i-doit wohl wirklich versucht, auf eine SQL-DB zuzugreifen. Man muss ja Reverse Engineering betreiben, wenn man das Produkt nutzen möchte

Merkwürdig, heute geht es wieder. Verändert habe ich nichts.

Hallo, gab es hierzu eine Lösung?

Hat sich natürlich gerade im Moment und nach mehrmaligem Import erledigt. Es funktioniert jetzt! Gruß Borste

Hallo, von welcher Anleitung ist hier die Rede? Meiner Information nach unterstützen wir aktuell noch die die 14. EL. Besten Gruß

Hallo, die Struktur der CSV-Datei kann jeder für sich selber überlegen, da beim Import händisch die Spalten den einzelnen Attributen zugewiesen werden. Besten Gruß

Hallo, vielen Dank für den Hinweis. Leider habe ich mit keinem User Zugriff auf die Rechteverwaltung. Ist es möglich die Rechteverwaltung über die Datenbank z.b. mit phpmyadmin zurückzusetzen? Vielen Dank & Gruss

Lokale IP-Adreßräume sollten in Zeiten von VRF, VPN und Virtualisierten Instanzen nicht global einzigartig sein. Zumindest Netzbereiche müssen mehrfach anlegbar sein, nicht nur als aufeinander aufbauende Supernets, sondern mit gleicher Maskierung. Aktuell kommt bei der Anlage eines Layer-3-Netzes beim Check eine Overlapping Warning, dass das Netz andere Netzbereiche überschneidet (das ist mit einem Supernet "Global v4" keine Kunst). Der Trick sollte hier aber normalerweise sein, das Layer3-Netz einem distinguierten (von anderen Netzen abgeschlossenen) Layer2 Netz zuzuordnen, dann müßte die Kollision / Overlapping verschwinden bzw. nicht mehr angezeigt werden. Oder ist das so zu verstehen, daß man nur die doppelt angelegten / sich theoretisch überschneidenden Netze angezeigt bekommen soll? Das wird mit der Zeit aber sehr unübersichtlich…. Zumindest die nicht-öffentlichen Netze sollten von einer Overlapping Warning ausgenommen werden, weil diese dazu tendieren, in größeren IT-Installationen (oder Dokumentationen, siehe mein Vorredner / TE) doppelt aufzutauchen. Dazu zählen auch die neuen CGN-Netzbereiche, die von RIPE nur für Carriergrade-NAT Zwecke reserviert wurden. Zusammenfassend geht es hier um folgende Standards: RFC1918: (Private address) 10.0.0.0/8 (10.0.0.0-10.255.255.255) 172.16.0.0/12 (172.16.0.0-172.31.255.255) 192.168.0.0/16 (192.168.0.0-192.168.255.255) RFC6598: (Shared address /CGNAT) 100.64.0.0/10 (100.64.0.0-100.127.255.255) RFC 5735: (Link local) 169.254.0.0/16 (169.254.0.0-169.254.255.255) Evtl. eine Idee für die nächsten Updates? Gruß, Frank

Hi, ich wusste mir nicht mehr zu helfen: pxxxxxx:/home/www/pxxxxxx/html/idoit > ls -la ... drwxrwxrwx  4 pxxxxxx users    4096 23\. Jul 09:26 upload ... und pxxxxxx:/home/www/pxxxxxx/html/idoit > ls -laR upload upload: insgesamt 16 drwxrwxrwx  4 pxxxxxx users 4096 23\. Jul 09:26 . drwxrwxrwx 17 pxxxxxx users 4096 29\. Okt 07:28 .. drwxrwxrwx  2 pxxxxxx users 4096 29\. Okt 07:27 files drwxrwxrwx  2 pxxxxxx users 4096 23\. Jul 09:26 images upload/files: insgesamt 12 drwxrwxrwx 2 pxxxxxx users 4096 29\. Okt 07:27 . drwxrwxrwx 4 pxxxxxx users 4096 23\. Jul 09:26 .. -rw-r--r-- 1 pxxxxxx users  51 29\. Okt 07:27 .htaccess upload/images: insgesamt 8 drwxrwxrwx 2 pxxxxxx users 4096 23\. Jul 09:26 . drwxrwxrwx 4 pxxxxxx users 4096 23\. Jul 09:26 .. Das sieht doch alles gut aus. Meine Lösung war eine Änderung in hypergate.inc.php, Zeile 124 - 129 $g_cache_dirs = array( "temp"            => $g_absdir . "/temp", /*"file upload"    => $g_dirs["fileman"]["target_dir"], "image upload"    => $g_dirs["fileman"]["image_dir"],*/ "template cache"  => $g_absdir . "/src/themes/default/smarty/templates_c" ); Augenscheinlich läufts, ein gutes Gewissen ist allerdings etwas anderes.

Danke, ist mir bisher nicht aufgefallen.

Hallo Stephan, db_names="idoit_system idoit_data"          #Database names to backup separated with space Heissen Deine Datenbanken so? Bei mir wuerde das schon nicht funktionieren… Ach, jetzt seh ich es. Man soll die Values vorher anpassen... /usr/bin/mysqldump –user=${db_user} --password=${db_pass} --host=${db_host} ${i} > ${tmp_sqlfile} Scheint, als wuerde das Skript auch nur ein mysqldump machen. Das erklaert aber nicht, wieso da auf einmal Daten fehlen sollten. Mit welchem User hast Du das Backup durchgefuehrt? Wobei ich nicht davon ausgehe, dass Dein User nur auf bestimmte Tabellen Berechtigungen hat… Gruss, jkondek

So, Problem ist gefunden. Das neue Passwort des DB Users muss im Admin Center auch unter dem Mandanten gespeichert werden, dann passt alles! Thread kann dann geschlossen werden

Und wie darstelle ich die Verbindungen zu Steckdosen, Lichtschalter und Klimaanlagen?

Hallo, ist das in der Aktuellen Version 1.6 immer noch so? Es ist aus meiner Sicht Sinnvoll, wenn man Daten hinzfügen könnte, wie z.B. Stromverbraucher, wenn ich das z.B. für alle Fortigate 100D machen will, muss ich aktuell, das im jedem Objekt aktivieren (in das Objekt gehen und Speichern drücken).