bei mir gehts nun auch wieder, die GD Lib hat gefehlt (wobei mir nicht bewusst ist, das das bei der Installation als Fehler angezeigt worden wäre)
Viel Grüße,
Matthias
Hallo,
bei mir werden nach dem Update auf 1.3 auch keine QR Codes mehr angezeigt.
Die Kategorie Zugriff ist definiert und eine primäre Zugriffs URL eingetragen.
Viele Grüße,
Matthias
Hallo,
bei mir werden nach dem Update auf 1.3 auch keine QR Codes mehr angezeigt.
Die Kategorie Zugriff ist definiert und eine primäre Zugriffs URL eingetragen.
Viele Grüße,
Matthias
Hallo,
das Problem ist möglicherweise allgemeiner.
Ich konnte es heute nachvollziehen. Es tritt auf, wenn Objekte dupliziert werden.
Das Bild wird nicht mit dupliziert und man kann dann auch kein neues Bild hochladen.
Hallo,
gibts hier schon Neuigkeiten? In der 1.24 scheint der Bug ja noch nicht behoben worden zu sein,
Viele Grüße,
Matthias
Hallo zusammen,
es stimmt, es gab anscheinend Änderungen. Wir werden die Schnittstelle selbstverständlich auf einen neuen Stand bringen. Wie lang das dauern wird, kann ich leider zum aktuellen Zeitpunkt noch nicht sagen.
Liebe Grüße
Hallo,
ich kann den Bug bestätigen.
Ab der Version 4.2 funktioniert das i-doit Plugin im Request Tracker leider nicht mehr. Es wäre schön, wenn es hier bald ein Update geben könnte.
Hallo,
bei genauem Hinschauen, ist es wahrscheinlich nur ein kosmetisches Problem.
Die Serverzeit ist korrekt.
Das Lizenzablaufdatum wird korrekt berechnet.
Die Meldung im Dashbord ist aber falsch.
Ich habe mal einen Screenshot angehängt, in dem man das schön sehen kann.
Viele Grüße,
Matthias
Hallo,
habe gerade das Update von 1.2 auf 1.2.1 installiert und sehe im Dashboard die Meldung
"Die Lizenz wurde am 05. November 2012 erstellt und läuft am 04. November 2013 ab. Die Lizenz ist somit noch 0 Jahre, 0 Monate und 5 Tage gültig:"
Das stimmt so natürlich nicht. Ist das nur ein Anzeigefehler oder haben wir in 5 Tagen ein Problem, das wir erst in 20 Tagen haben sollten?
(Client und Server haben jeweils das korrekte Datum)
Viele Grüße,
Matthias
Hallo,
ja es wird noch ungewöhnlicher. Mal gehts, mal nicht…
Gleicher Browser, gleiches Bild, mal hat man Glück, mal nicht. Das ist uns bis jetzt aber nur bei Druckern aufgefallen.
Fehlermeldungen sehe ich in den Apache Logs nicht. An Zugriffsrechten fürs Verzeichnis kann es ja auch nicht liegen (es gibt ja nur eins).
In den Access Logs fehlt, wenn es schief geht, aber folgender Eintrag
/index.php?viewMode=1100&tvMode=1006&objID=2210&objGroupID=2&moduleID=2&editMode=0&objTypeID=11&catgID=27&file_manager=image&file=2210__1379580036__DC242.jpg HTTP/1.1" 200 12646
Kann man irgendwo den Log Level hoch setzen oder Debug Code einschleusen?
m.
Hallo Leo,
das Problem mit den Bildern gibts (bekannt) nur bei den Druckern. Bei anderen Objekttypen können wir erfolgreich Bilder hochladen.
Das Problem der fehlenden Platzhalter ist verschwunden, nachdem die Hosteinträge als primär gekennzeichnet wurden, danke für diesen Tip.
Viele Grüße,
Matthias
Hallo,
wir haben mit dem Objekttyp Drucker seltsame Probleme.
1. es lassen sich unter Objektbilder keine Bilder hinterlegen (beim Speichern passiert einfach nichts)
2. in der Kategorie Zugriff ist sind alle Platzhalter wie %hostname% und %ipaddress% nicht definiert.
Hat jemand eine Ahnung, woran das liegen kann und wie man das wieder in Ordnung bringt?
Viele Grüße,
Matthias
ich habe noch mal die Doku durchgeschaut und gesehen, dass die RT Integration unter dem Menüpunkt "Module" konfigurierbar sein soll.
Den Menüpunkt habe ich aber (auch als admin) gar nicht. Kann man den irgendwie freischalten?
Ich habe den RT bis jetzt nur unter Schnittstelle/externe Daten/TroubleTicket-System konfiguriert und sehe sowohl Daten im RT und kann über die RT Erweiterung im RT auch Objekte im i-Doit referenzieren… Grundsätzlich geht das also.
Viele Grüße,
Matthias
Hallo,
wenn man Request Tracker hinter https betreibt, funktioniert die i-doit Integration nicht.
Bis zur Version 1.1 habe ich nach jedem Update in
src/classes/protocol/isys_protocol_http.class.php
folgende Zeile modifiziert:
public static function get_instance($p_host, $p_port = 80, $p_protocol = self::C__HTTP) wurde zu
public static function get_instance($p_host, $p_port = 443, $p_protocol = self::C__HTTPS)
In der 1.1.1 hat das nicht mehr geholfen. Auf die Schnelle habe ich nun die Zeile 248 modifiziert und die Variablen für Port und Protokoll im Funktionsaufruf durch Konstanten ersetzt.
return "https://{$this->m_host}:443{$this->m_base_url}{$p_path}";
Es hat sich also offensichtlich etwas geändert. Kann man Protokoll und Port nun irgendwo als Parameter angeben? Das wäre in jedem Fall eleganter, als mein Flickwerk.
Viele Grüße,
Matthias
Hallo,
ich versuche gerade unsere Speicherinfrastruktur, die wir mit Hilfe von Datacore gerade virtualisiert haben, zu dokumentieren und komme an einer entscheidenden Stelle nicht weiter.
Kurz zur Info.
Ein Datacore Server kombiniert Storage, den er lokal "sieht" (egal ob eine gemountete iSCSi bzw. FC LUN, Storage eines lokalen RAID Systems oder eine über USB angeschlossenen Festplatte etc), in einen oder mehrere Storage Pools.
Aus diesen Storage Pools können virtuelle LUNs gebildet werden, die anderen Servern über FC oder iSCSI zur Verfügung gestellt werden.
Mindestens zwei solcher Datacore Instanzen können einen Cluster bilden, der die virtuellen LUNs spiegelt. Ein Client kann sich über iSCSI bzw. FC und MPIO an eine solche LUN binden und hat somit mehrere redundante Pfade zum redundanten Speicher.
Wenn ich im Backend Client LUNs aus dem Speichernetz lokal zu einem RAID0 zusammenfassen könnte, um einen Storage Pool zu modellieren , wäre ich schon ein ganzes Stück weiter. Wie kann man das realisieren?
Aus diesem Pool könnte ich dann unter Speichernetze/Logische Geräte (LDEV Server) logische LUNs als Frontend Storage modellieren, die über ein Cluster Objekt, das aus zwei Datacore Server besteht, an Clients präsentiert wird.
Im Zusammenhang mit iSCSI wäre es schön, wenn man die Speicherpfade mit angeben könnte. Wenn ich nichts übersehen habe, kann man derzeit nur FC Pfade als Speicherpfade auswählen.
Über Lösungsvorschläge würde ich mich sehr freuen.
Viele Grüße,
Matthias
Hallo,
vielen Dank,
das hat geklappt,
Viele Grüße,
Matthias
Hallo,
nach dem Upgrade von i-doit Pro 1.0 auf 1.1 kann ich keine einzelnen Ports mehr anlegen.
Beim Sichern fehlt die Bestätigung (eine Fehlermeldung gibts aber auch nicht).
Mehrere Ports kann ich nur anlegen, wenn ich den Defaultwert im Feld "beginnend ab" auf 1 setze.
Derzeit steht als default immer "isys_nagios_timeperiods_plus" drin. Ich nehme an, deshalb kann auch kein einzelner Port angelegt werden.
Wie kann man das beheben?
Viele Grüße,
Matthias
Hallo,
ich habe den Code etwas modifiziert und bin jetzt etwas weiter.
In
/opt/rt4/local/plugins/RT-Extension-ReferenceIDoitObjects/html/Elements/SelectIDoitObjects und
/opt/rt4/local/plugins/RT-Extension-ReferenceIDoitObjects/html/Elements/ShowIDoitObjects
habe ich in Zeile 114 bzw. 113
use Switch;
auskommentiert und in
in SelectIDoitObjects ab Zeile 182 ds Switch Statement durch folgenden Code ersetzt:
use feature qw {switch};
given ($IDoitDefaultView) {
when ('object') { $IDoitView = 0; }
when ('tree') { $IDoitView = 1; }
when ('item') { $IDoitView = 2; }
}
Viele Grüße,
Matthias
Hallo,
ich versuche ReferenceIDoitObjects 0.9 mit i-doit 0.9.9.9 pro zum Laufen zu bekommen unter Perl 5.16 zum Laufen zu bekommen.
Leider bekomme ich beim Aufruf einer Ticket Detail Seite im RT den Fehler
Can't locate Switch.pm in @INC (@INC contains: …
at /opt/rt4/local/plugins/RT-Extension-ReferenceIDoitObjects/html/Elements/SelectIDoitObjects line 114.
Switch.pm ist wohl seit perl 5.14 nicht mehr inkludiert, gibt es einen Workarround?
Viele Grüße,
Matthias Peplow