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
