opsi config editor "Lade Tabelle product property" hängt dauerhaft

isf
Beiträge: 20
Registriert: 19 Jan 2015, 13:12

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von isf »

Hallo,
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?
ja tut er.

Grüße
Andreas
Benutzeravatar
r.roeder
uib-Team
Beiträge: 540
Registriert: 02 Jul 2008, 10:08

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von r.roeder »

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.


Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
isf
Beiträge: 20
Registriert: 19 Jan 2015, 13:12

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von isf »

Hallo,
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.
Client Java 7: http://pastebin.com/07g1u6NY
Client Java 8: http://pastebin.com/TPtQZ3q0
Client Log auf dem Server Java 7: http://www.xup.in/dl,23397467/server_client_j7.log/
Client Log auf dem Server Java 8: http://www.xup.in/dl,15104805/server_client_j8.log/
Serverlog Java 7: http://pastebin.com/9ypBW43c
Serverlog Java 8: http://pastebin.com/wSGTY06h

Grüße
Andreas
Benutzeravatar
r.roeder
uib-Team
Beiträge: 540
Registriert: 02 Jul 2008, 10:08

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von r.roeder »

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
)

Ein anderer interessanter Test wäre, das early access release des jdk9, https://jdk9.java.net/download, auszuprobieren.

Grüße
Rupert
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.


Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
isf
Beiträge: 20
Registriert: 19 Jan 2015, 13:12

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von isf »

Okay, folgender Stand:

Das Erlauben von SSLv3 hat nichts gebracht.

Die Java-Versionen habe ich auf einem weiteren Rechner durchprobiert:

Wie gehabt:
Java7 -> funktioniert
Java8 -> funktioniert nicht

Aber:
Java9 Build 134 -> funktioniert

Gruß, Jens
Benutzeravatar
r.roeder
uib-Team
Beiträge: 540
Registriert: 02 Jul 2008, 10:08

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von r.roeder »

und nu?

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.


Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
isf
Beiträge: 20
Registriert: 19 Jan 2015, 13:12

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von isf »

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.

Danke bis hierher und Grüße
Jens
adlerweb
Beiträge: 28
Registriert: 09 Jul 2008, 10:33
Kontaktdaten:

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von adlerweb »

Hallo,

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...
Benutzeravatar
r.roeder
uib-Team
Beiträge: 540
Registriert: 02 Jul 2008, 10:08

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von r.roeder »

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.


Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
isf
Beiträge: 20
Registriert: 19 Jan 2015, 13:12

Re: opsi config editor "Lade Tabelle product property" hängt dauerhaft

Beitrag von isf »

Hallo,
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

opsi-setup --cleanup-backend

die übertragenen Datenmengen zu verringern.

Code: Alles auswählen

# opsi-setup --cleanup-backend
[5] [Sep 12 16:07:01] Modules file signature verified (customer: NAME) (MySQL.py|523)
[5] [Sep 12 16:07:01] Parsing dispatch.conf (CleanupBackend.py|62)
[5] [Sep 12 16:07:01] Mysql-backend detected. Trying to cleanup mysql-backend first (CleanupBackend.py|87)
[5] [Sep 12 16:07:01] Connection to database 'opsi' on 'SERVER' as user 'opsi' (CleanupBackend.py|246)
[5] [Sep 12 16:07:01] Cleaning up defaultValues in productProperties (CleanupBackend.py|250)
[5] [Sep 12 16:07:01] Cleaning up groups (CleanupBackend.py|94)
[5] [Sep 12 16:07:01] Cleaning up products (CleanupBackend.py|97)
[5] [Sep 12 16:07:03] Cleaning up product on depots (CleanupBackend.py|108)
[5] [Sep 12 16:07:03] Cleaning up product on clients (CleanupBackend.py|111)
[5] [Sep 12 16:07:10] Cleaning up product properties (CleanupBackend.py|114)
[5] [Sep 12 16:07:11] Cleaning up product property states (CleanupBackend.py|136)
[5] [Sep 12 16:07:18] Cleaning up config states (CleanupBackend.py|221)
[5] [Sep 12 16:07:21] Cleaning up audit softwares (CleanupBackend.py|224)
[5] [Sep 12 16:07:27] Cleaning up audit software on clients (CleanupBackend.py|227)
brachte für Java 8 keine Änderung.

Grüße
Andreas
Antworten