Die Meldung Parameter Error erscheint hier bei Kontaktzuordnungen und bei der neuen Kategorie Simkarte beim zuweisen eines Telefons und umgekehrt.
leider sieht man keine naeheren infos auch nicht mit aktiviertem debug modus.
Die Standortzuweisung funktioniert hier allerdings
Ein ähnliches Problem ist bei uns auch aufgetreten:
nach dem update auf 9.9.9-1 habe ich erst mal die standard reports neu installiert und dabei zufaellig ein paar alte unfertige stromobjekte gefunden. diese wollte ich archivieren und löschen.
3918 generated POWER CONSUMER 1232375605 Sicherungskasten SYSID_1232375605 Ausgeschieden
4201 generated POWER CONSUMER 1234965578 Sicherungskasten SYSID_1234965578 Andere
6393 generated POWER CONSUMER 1251204782 Sicherungskasten SYSID_1251211175 Andere
6769 generated POWER CONSUMER 1253702635 Sicherungskasten SYSID_1253709404 Andere
7038 generated POWER CONSUMER 1256804793 Sicherungskasten SYSID_1256811831 Andere
die objekte sind archiviert - wenn ich nun auf löschen klicke erhalte ich folgende fehlermedung…
isys_exception_database : Query error: 'DELETE FROM isys_obj WHERE isys_obj__id = '3918'': Cannot delete or update a parent row: a foreign key constraint fails (idoit_data/isys_catg_power_consumer_list, CONSTRAINT isys_catg_power_consumer_list_ibfk_2 FOREIGN KEY (isys_catg_power_consumer_list__isys_cats_pobj_list__id) REFERENCES `isys_cats_pobj_)
irgendwelche tips ?
lG,
Philipp
Hallo,
seit dem Update auf 0.9.9 kann man in der suche nicht mehr nach kontakten suchen ?!
zudem kommt bei einem client beispielsweise wenn man aucf Netzwerk -> Ports anzeigen klickt nur eine weisse seite. Import laufen ohne fehler aber zu keinem rechner findet man die mac adressen mehr.
Am wichtigsten waere auf jeden fall nach personen, telefonnummern, raumnummern usw. suchen zu koennen was derzeit nur umstaendlich oder gar nicht moeglich ist.
Unter Redhat basierenden Distributionen legt man einfach folgende Datei an:
/etc/httpd/conf.d/idoit.conf
### idoit
<location i-doit="">AddDefaultCharset ISO-8859-1
# AddDefaultCharset ISO-8859-15</location>
selbige Datei unter Debian basierender Distributionen (also z.B. auch Ubuntu) muss nach /etc/apache2/mods-enabled/idoit.conf
Charset je nach Bedarf anpassen (in obrigen Beispiel also ISO-8859-1
Das Beispiel geht davon aus, dass i-doit unter http://servername/i-doit/ erreichbar ist.
ad mysql:
Ich habe die datenbank erst mal so belassen wie sie ist. Ich werde das bei gelegenheit mal in der Testinstanz ausprobieren.
ad Softwareliste:
Dank des Patches ist die Softwareliste nun wieder in Ordnung.
ad Archivierung:
scheint auch zu funktionieren.
Leider ist das Import Problem immer noch vorhanden. Wie schon einmal versucht zu erklären handelt es sich offenbar um ein Problem beim erkennen von Anführungszeichen sowohl als einfaches ' als auch als " .
Im konkreten Fall sind es momentan 3 Verschiedene Software einträge die immer wieder neu angelegt werden:
sala's Terminal Server Patch 2.1
Dienstprogramm "ThinkPad UltraNav" 2.05
Malwarebytes' Anti-Malware
Es wäre toll wenn ihr das noch beheben könntet.
OK, ein mysqldump, loeschen von ibdata und mysql <dump.sql sollte="" aber="" kein="" problem="" darstellen="" oder="" ?="" <br="">davon abgesehen loest es mein hauptproblem dass ich nicht upgraden kann ohne danach nur eine leere seite in der software liste zu sehen nicht.
zur Archivierung:
wie man an den 2 geänderten zeilen sehen kann scheint die Export Funktion mit einem Hochkomma: ' im namen nicht klar zu kommen. Der select Befehl dazu enthaelt dann 3x ' und mysql meldet einen ungültigen SQL Statement</dump.sql>
Nachdem die Updates für die meisten Probleme in i-doit 0.9.8 behoben haben (Doppelte Softwareeintraege werden immer noch nicht erkannt), gibt es bei einem Update auf 0.9.8-1 wieder ein Problem mit der Softwareliste. Diese bleibt nach einem Update nämlich wieder leer.
Bei der 0.9.8 version mussten wir dennoch noch in den Code eingreifen, da Software mit einem ' im Namen nicht Archiviert werden konnte, da es zu einem Mysql Error kam:
isys_component_dao_archive.class.php
[…]
$this->convertEntry($entry["isys_logbook__event_static"]).", ".
$this->convertEntry(str_replace("'","",$entry["isys_logbook__obj_name_static"])).", ".
$this->convertEntry(str_replace("'","",$entry["isys_logbook__category_static"])).", ".
$this->convertEntry($entry["isys_logbook__obj_type_static"]).", ".
[…]
zusätzlich funktioniert in der 0.9.8 Version das Update von Nagios nicht wobei sich an der Datenbank nichts verändert hat.
php controller.php -v -m nagios
[…]
PHP Warning: gethostbyaddr(): Address is not a valid IPv4 or IPv6 address in /var/www/html/i-doit/src/ndo.inc.php on line 15
PHP Warning: mysql_connect(): Too many connections in /var/www/html/i-doit/src/classes/components/isys_component_database.class.php on line 41
Eine weitere Frage die sich mir gestellt hat: Ist es möglich die i-doit Datenbanken als MyISAM Datenbanken zu nutzen und nicht als InnoDB. Der eigentliche Datenbestand als sql export belaeuft sich auf etwa 50MB wohingegen die InnoDB 1,4GB im ibdata file verschlingt.
Die komplette Exception kann man nichtmal mehr darstellen im Firefox
Habe jetzt mal folgendes versucht:
Backup rueckgesichert auf 0.9.7-1 - dann alle Anwendungen entfernt und danach das upgrade neu gestartet. Das funktioniert dann auch. Allerdings liest das neue importmodul
die Namen der installierten Software mit umlauten nicht richtig ein:
aus "Sicherheitsupdate für Windows XP (KB890046) 1" im XML File kommt in der CMDB nur noch "Sicherheitsupdate f" an.
Entsprechend dieser Problematik werde ich erst einmal wieder auf v0.9.7-1 zurueckstellen und die datenbank auf einem Testserver kopieren.
Den output der Exception generiere ich dann morgen nochmals
Schlüssel: int_pageLimit
Wert: 100
hab's testweise auf 10 reduziert - ergebnis bleibt gleich
mit
index.php?viewMode=1001&objTypeID=2 ?
kommt ebenfalls eine exception:
Exception occurred:
isys_exception_database : Query error: 'INSERT INTO tempObjList_khu2linvaqdbf1r56rjg31si90 VALUES ('10', '2', 'Microsoft Windows 2000 Server', NULL, '', '', '', '', '0', NULL, '', '0', '2', 'SYSID_1227623770',
usw.
ich hab das ganze mal auf einem unserer Server ausgeführt wo noch etwas mehr speicher zur verfügung steht:
Dort erhalte ich nach einiger zeit folgendes als bug report:
Notice: Undefined index: bug_description in /var/www/html/i-doit/bugreport.php on line 146
Notice: Undefined index: e in /var/www/html/i-doit/bugreport.php on line 148
Notice: Undefined variable: g_product_info in /var/www/html/i-doit/bugreport.php on line 172
URL : ?viewMode=1001&objTypeID=2&&ajax=1
REF : http://loki/i-doit/index.php
Date : Thu, 13 Aug 2009 15:58:09 +0200
Host : sc-te-ap01
IP : 10.246.243.50
Client : Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Server : Apache/2.2.3 (CentOS) Server at loki Port 80
BaseConfig : array ( 'base_dir' => '/var/www/html/i-doit/', 'www_dir' => '/i-doit/', 'override_host' => false, 'sess_time' => 3600, 'theme' => 'default', 'startpage' => 'index.php', 'debugging' => false, 'bugreport' => false, 'forum' => false, 'show_proc_time' => true, 'smarty_debug_host' => 'localhost', 'encoding' => 'latin1', 'adminpass' => '21232f297a57a5a743894a0e4a801fc3', 'show_barcodes' => 1, 'ajax_calls' => true, 'wiki_url' => '',)
DBConfig : array ( 'host' => 'localhost', 'port' => '3306', 'user' => 'idoit', 'name' => 'idoit_sys',)
DirConfig : array ( 'css_abs' => '/var/www/html/i-doit/src/themes/default/css/', 'js_abs' => '/var/www/html/i-doit/src/tools/js/', 'temp' => '/var/www/html/i-doit/temp/', 'class' => '/var/www/html/i-doit/src/classes/', 'temp_www' => '/i-doit/temp/', 'images' => '/i-doit/images/', 'import' => '/var/www/html/i-doit/src/classes/import/', 'theme_images' => '/i-doit/src/themes/default/images/', 'handler' => '/var/www/html/i-doit/src/handler/', 'fileman' => array ( 'target_dir' => '/var/www/html/i-doit/upload/files/', 'temp_dir' => '/var/www/html/i-doit/temp/', 'image_dir' => '/var/www/html/i-doit/upload/images/', ),)
ProductInformation : NULL
nachfolgend noch 2 bildchen um den Speicherverlauf zu zeigen
2GB Physisch, 4G auslagerung - verwendet 628MB
da der fehler erst seit den imports aufgetreten ist, denk ich mal wird sich ein fehlerhafter eintrag in die datenbank geschlichen haben.
Als notlösung hatte ich eine Frage: Ist es möglich sämtliche Eintraege in Software zu löschen ohne damit die gesamte struktur in der datenbank zu gefährden ? Die Software sollte ja mittels import script wieder automatisch gefüttert werden
Die Java konsole wirft folgenden fehler aus:
Fehler: [Exception… "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIXMLHttpRequest.responseText]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: http://loki/i-doit/src/tools/js/prototype/prototype.js?30caf80ad0333b69f980d53f72f054b3 :: anonymous :: line 1372" data: no]
Quelldatei: http://loki/i-doit/src/tools/js/prototype/prototype.js?30caf80ad0333b69f980d53f72f054b3
Zeile: 1372
ich vermute eher ein speicherproblem - klickt man die Software -> Anwendungen an verbraucht der Firefox schlagartig 60MB speicher tut aber sonst nichts mehr weiter.
ich habe auch schon versucht das speicherlimit auf 128MB zu erhöhen was keinen erfolg gebracht hat
Apache Error log - kein eintrag
nur offizielle Release installiert. Das ist unsere Produktionsumgebung !
in der php.ini:
; Maximum allowed size for uploaded files.
upload_max_filesize = 8M
ändern in zb.
; Maximum allowed size for uploaded files.
upload_max_filesize = 20M
Absolutes maximum ist soweit ich weiss 2048M (mehr ist vom Apache aus nicht vorgesehen)
wenn man Software -> Anwendungen anklickt bekommt man eine leere Seite.
Übrigens kann man idoit mit Internet Explorer v6 - v8 i-doit nicht mehr verwenden (egal mit welchen browsereinstellungen für Javascript)
Jetzt hat sich leider ein (folge?)problem eingeschlichen.
Unter dem Punkt Software -> Anwendungen kommt gar nichts mehr. Zwar kann man Anwendungen über Server bzw Client ansehen aber das hilft ja nicht wirklich weiter.
Ich hab mal in die datenbank geschaut
isys_catg_application_list hat ueber 40000 eintraege waerend die Applikationsliste nur etwa 3800 umfasst.
in diesem Zusammenhang wäre es ausserdem praktisch wenn man beispielsweise
Sicherheitsupdate für Windows XP (KB890046) 1
Sicherheitsupdate für Windows XP (KB893756) 1
Sicherheitsupdate für Windows XP (KB896358) 1
Sicherheitsupdate für Windows XP (KB896422) 1
Sicherheitsupdate für Windows XP (KB896423) 1
Sicherheitsupdate für Windows XP (KB896424) 1
alle auf einmal eine Lizenz zuweisen könnte
wie du richtig vermutet hast ist die version äter gewesen und daher klappte es nicht.
mit den neuen modulen kommt auch keine fehlermeldung mehr.
Loading module: import
Logging in
Connected to mandator: 1 ()
Logged in as: admin
–----------------------------------------------
i-doit import
–----------------------------------------------
Import-Handler initialized (2009-08-12 15:58:56)
[!] Running in force mode.
Loading Import: /var/www/html/i-doit/imports/clients/07667200-ws-005-1060433.xml of type inventory
Parsing XML-Data
Importing host: 07667200-ws-005
Scantime: 12.08.2009 15:58:14
Found obect-id: 1237
Category mode
Could not read export. Wrong type!
Import done.
Logging out
etwas stutzig macht mich die Zeile "* Could not read export. Wrong type!" Soll das so sein ?
das Datum wird übrigens auch nicht aktualisiert nach einem neuerlichen Import - sollte das so sein ?
lG,
PGO
Hi !
Seit dem update auf 0.9.8 ist das import modul nicht lauffaehig.
auf der Synetics Support seite steht mir nur folgene downloads zur auswahl
i-doit v0.9.6 report-update
i-doit v0.9.6.1 import-update
[!] Running in force mode.PHP Fatal error: Class isys_import_handler_inventory contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (isys_import_iface::import) in /var/www/html/i-doit/src/classes/import/handler/isys_import_handler_inventory.class.php on line 12
Soll ich auf ein Update warten oder zwischenzeitlich auf 0.9.7-1 zurueckgehen ?
lG,
PGO