r.roeder hat geschrieben:interessant, diese Logs sehen so aus, als würde die Kommunikation mit dem Service bei einem Java8-Client nicht funktionieren, aber bei einem Java7-Client schon. Startet dementsprechend der configed mit Java7 auch korrekt?
sehr strange, ich würde das Verhalten gern reproduzieren und analysieren können (einen Unterschied zwischen der Ausführung des Clients mit Java 7 oder 8 habe ich noch nirgends beobachten können).
Auf die Ferne kann ich nur anregen, die Erforschung voranzutreiben:
Ist die Abhängigikeit von Java 7/8 auf ein- und demselben Rechner reproduzierbar (der Unterschied ist also nicht irgendwie rechnerbedingt)?
Möglicherweise ist es auch hilfreich, die Kommunikation zwischen Server und Client weiter zu analysieren. Dazu könnte man das Loglevel auf dem Server temporär hochsetzen (nicht auf Passwort-Logging!) und die Logausschnitte des fraglichen Zeitraums der /var/log/opsi/opsiconfd/[client-ip].log UND jetzt auch der /var/log/opsi/opsiconfd/[server-ip].log zur Verfügung stellen.
Spannend wäre möglicherweise auch, z,B. temporär auf das mysql-Backend zu wechseln.
Grüße
Rupert
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
r.roeder hat geschrieben:
Ist die Abhängigikeit von Java 7/8 auf ein- und demselben Rechner reproduzierbar (der Unterschied ist also nicht irgendwie rechnerbedingt)?
ja ist sie, auf mindestens 2 Rechnern funktioniert der Client mit Java 7 und gleichzeitig nicht mit Java 8.
r.roeder hat geschrieben:
Möglicherweise ist es auch hilfreich, die Kommunikation zwischen Server und Client weiter zu analysieren. Dazu könnte man das Loglevel auf dem Server temporär hochsetzen (nicht auf Passwort-Logging!) und die Logausschnitte des fraglichen Zeitraums der /var/log/opsi/opsiconfd/[client-ip].log UND jetzt auch der /var/log/opsi/opsiconfd/[server-ip].log zur Verfügung stellen.
schon mal sehr interessant zu sehen, ab wann sich die Logs unterscheiden.
Mein Wunsch ist jetzt, dass ihr schaut, was passiert, wenn SSLv3 wieder zugelassen wird ( http://www.oracle.com/technetwork/java/ ... 89094.html )
d.h. "sslv3" aus den "disabled algorithm" entfernt wird in java/lib/security/java.security
ggfs. für das Verzeichnis java in Program Files und Program Files (x86
)
Ich denke, wir stellen nochmal das Produkt javavm mit der letzten öffentlichen Java-7-Version zur Verfügung, mit der es läuft. Mutige können Java 9 installieren. Da bei uns hier alles in allen Kombinationen läuft, können wir weder etwas debuggen noch einen Bugreport an Oracle schicken (was wir bei einem reproduzierbaren Problem schon gemacht haben und auch Wirkung hatte).
Grüße
Rupert
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Tja, wenn die Logfiles nicht ausreichen, müssen wir wohl auch passen.
Wir haben hier (imagebasierte) Standardinstallationen von Java, nix Besonderes.
Der Fehler trat nachvollziehbar mit Java8 auf, nachdem wir UCS auf Version 4.1.2 gehievt haben.
Keine Ahnung, wann Java9 released wird. So lange müssen wir uns dann wohl oder übel mit Java7 behelfen.
hier tritt das selbe Problem mit einem Ubuntu-Server (16.04) und der aktuell stabilen opsi-configed (4.0.7.1.3-3) ebenfalls auf, ist also (wie von den Logs auch vermuten ließen) nicht Distributionsspezifisch. Java 7 am Client funktioniert, 8 nicht. Die Serverlogs sehen ähnlich aus, hängt ebenfalls bei "auditSoftware_getHashes". SSL ist ebenfalls noch ein SHA1, da vorherige Daten aber korrekt übertragen werden würde ich das als unwahrscheinlich einstufen.
Wenn der Client hängt findet kein Netzdatenverkehr mehr statt. Ich hab mir auf Netzseite den HTTP-Datenverkehr entschlüsselt und grob angesehen, der Call auf auditSoftware_getHashes wird vom RPC-Server begonnen zu beantworten, im HTTP-Header ist sowohl bei JRE7 als auch JRE8 eine Content-Length von 227572 für die Antwort angegeben. Die Daten sind am Anfang auch gleich, bei JRE8 endet die Übertragung allerdings immer bei ~194560 Byte (zahl Identisch, genaue Position zeigt Editor nicht an). Die HTTP-Requests zeigten ab und an verdrehte Argumente, ob das an der JRE liegt oder einfach Timing ist lasse ich aber mal offen. Bei direktem senden per curl werden beide Varianten vom Server fehlerfrei und vollständig beantwortet.
Interessanter Effekt 1: Wenn der JRE8-Client hängt und ich die TCP-Verbindung per Reset beende fängt der Client wieder an zu reagieren und zeigt die bis dahin empfangenen Daten an.
Interessanter Effekt 2: Wenn ich GZIP im Client ausschalte tritt der Fehler schon vorher (bei configState_getObjects) auf. Auch hier sieht der Antwortheader sauber aus, die folgenden JSON-Daten hören aber mittendrin auf. Ist da eventuell irgend ein Pufferspeicher im Java-Client kleiner geworden?
Ich werden hier den Configed fürs erste mit lokaler 7er JRE (hat jemand die 9er als ZIP erspäht?) im Ordner und start-batch verpacken - dürfte wohl für die Zwischenzeit die einfachste Lösung sein, wenn man auch Software hat, die auf 8 angewiesen ist...
es scheint ja so zu sein, dass das Auftreten des Hängers ab irgendeinem übertragenen Datenvolumen eintritt. Vielleicht hilft für den einen oder anderen, ein
opsi-setup --cleanup-backend
die übertragenen Datenmengen zu verringern.
(Auf jeden Fall vorher ein Backup ziehen, da gerade beim File-Backend Inkonsistenzen auftreten können, die durch cleanup-backend weggebügelt werden, aber dann vielleicht das Backend in einem noch schwierigeren Zustand hinterlassen.)
Gibt es eigentlich jemand, der das Problem bei sich feststellt, das mysql-Backend?
Grüße
Rupert
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
r.roeder hat geschrieben:es scheint ja so zu sein, dass das Auftreten des Hängers ab irgendeinem übertragenen Datenvolumen eintritt. Vielleicht hilft für den einen oder anderen, ein