forum.opsi.org

Hi,

wir setzen OPSI ebenfalls auf UCS 4.1 ein. Genaue Version kann ich morgen mal nachschauen. Eine Frage habe ich: Habt Ihr den Configed lokal installiert?

Wir hatten das unter UCS 3.x nicht und nach dem Update auf UCS 4 konnte der Configed nicht mehr von https://servername.fqdn:4447 geladen werden. Egal, ob Java 7 oder 8. Der Ladebalken von Java hing irgendwann fest und nach einem relativ langen TimeOut (vermutlich von javaws.exe) kam dann irgendein Connection Error (genau weiß ich das nicht mehr, ist zu lange her...).

Ich konnte das damals auch in einer Mini-VM Testumgebung nachstellen. Update von UCS 3.x auf 4 und vorbei war es mit dem Download des Configed vom UCS Server.

Dann haben wir auf lokale Installation des Configed gewechselt und alles war gut. Muss jetzt nix mit Eurem Problem zu tun haben, ich finde aber ne gewisse Ähnlichkeit

VG
Lars

Danke für Deinen Hinweis!
Das Problem ist aber sowohl beim Standalone-Client als auch über das Server-Plugin nachvollziehbar.

Gruß, Jens

Liebes Support-Team,

ich fasse den Thread mal zusammen:

- Ohne den Confog-Editor ist Opsi schwer zu benutzen. Ich denke, da sind wir uns einig.
- Es gibt ein Problem bei der Benutzung des Editors mit Java 1.8 unter unklaren weiteren Bedingungen.
- Es gibt mehr als eine Installation, in der das Problem auftaucht, der Kollege 'adlerweb' hat ein identisches Problem. Erfahrungsgemäß gibt es eine Anzahl Mitleser, die das Problem auch haben, sich aber nicht melden und nur lesen. Die Zahl von derzeit 973 Views auf diesen Thread spricht stark dafür.
- Ihr habt von 'adlerweb' und uns - wie ich finde - geduldig jede Menge Debug-Daten und sonstige Hinweise bekommen. Dafür ist sehr viel Zeit aufgewandt worden.

Eure Quintessenz bisher, überspitzt formuliert: Wir wissen nicht, was schief läuft, bei uns funktioniert es.

Das fnde ich - neutral formuliert - etwas wenig.
Die Notlösung mit Java7 finde ich schon etwas 'schwierig' und der Start von Java9 wurde erst gestern auf Mitte 2017 verschoben. Das kann es doch nicht sein.

Ich frage mal etwas ketzerisch: Hätte ich bei Buchung des kostenpflichtigen Supports die gleiche Antwort bekommen?

Viele Grüße
Jens

Hallo Jens,

isf hat geschrieben:Eure Quintessenz bisher, überspitzt formuliert: Wir wissen nicht, was schief läuft, bei uns funktioniert es.

Ja klar . Spaß beiseite, natürlich nicht... aber bei einem Supportvertrag, hätten wir auch eine ganz anderen Art der Kommunikation und viel mehr Möglichkeiten, auch direkt bei euch mehr zu sehen, als hier übers Forum. Das wir Logs von euch bekommen ist Super und hilft in der Regel auch. Aber das ist ein Problem, welches nicht so einfach zu lösen ist.

Weiterhin hat hier in dem Thread auch nicht jeder das selbe Problem. Der Titel besagt, dass beim Datenladen was verschluckt wird. Ein anderer User hat ein Problem beim Webstart, dass ist noch viel weiter davor, als die Daten zu laden. Im Code selbst kann es auch nicht liegen, sonst würde das auch auf 7 und 9 brechen. Vielleicht ist auch die aktuelle Version von der javavm (8 101 und 102) kaputt. Aber warum können wir das nicht reproduzieren ist die Frage.

Nachdem dieser Thread geöffnet wurde, haben wir uns hingesetzt, einen Windows-Rechner mit der javavm Version aufgesetzt, die von uns mit 4.0.7 veröffentlicht wurde und haben den configed hoch und runter getestet. Lokal und per Webstart. Es sind keine Probleme zu sehen. Wenn man ein Problem nicht reproduzieren kann, ist eine Lösung schwierig. Der Grund warum wir den configed noch mit Java 1.7 bauen, ist da er (bisher) zumindest dann auch mit Java 8 läuft. Wir überlegen uns momentan, ob wir Testweise den configed mal Java 1.8 bauen. Da aber der Buildprozess, wegen Signierung etc. extrem Aufwendig ist, sind wir noch nicht dazu gekommen eine Experimentierversion dafür zu bauen. Wir versprechen, dass wir dran bleiben und uns mühe geben das Problem zu beheben. Aber wann wir dazu kommen ist schwierig zu sagen. Weiterhin ist hier auch entscheidend, dass es kein Flächendeckendes Problem ist (so wie es aussieht). Denn wenn es so wäre, hätten wir auch schon einen offiziellen Supportcall dazu, was wir aber meines Wissens nicht haben.

isf hat geschrieben:Ihr habt von 'adlerweb' und uns - wie ich finde - geduldig jede Menge Debug-Daten und sonstige Hinweise bekommen

Andersrum habt Ihr von uns auch geduldig antworten bekommen und es hat sich jemand hingesetzt und eure Logdateien mühsam analysiert und versucht das Problem zu lösen. Und das obwohl Ihr keinen Supportvertrag habt und es so aussieht, als wenn es kein Bug in unserem Code zu sein scheint. Ich denke das wir hier so nicht weiterkommen. Was ich sagen kann ist, dass wir definitiv an einer Lösung auch ohne Supportvertrag interessiert sind. Wie diese Lösung aussieht, kann ich jetzt noch nicht sagen, aber ein Probeweise bauen mit java8 Kompilierung werden auf alle Fälle Testen. Ihr könnt, auch vielleicht mal probieren bei so einem Client eine ältere Java8 Version zu installieren, vielleicht entsteht das Problem ja auch wegen der aktuellen 101 Version.

Viele Grüße
das liebe opsi-Team

Hi,

kleines Update, da wir mittlerweile (endlich) das ganze auf einer Maschine selbst erfahren können und Rupert und ich uns die letzten Tage damit beschäftigt haben.

Kleine Zusammenfassung, mit der Bitte um Ergänzungen / Korrekturen:
Das Problem ist, dass nach einer Anmeldung am opsi-Server über den Configed das Laden der Daten hängen bleibt. Die Stelle an welcher das ganze hängt variiert.
Das Aufrufen der Webservice-Methoden über andere Wege (opsi-admin, curl) liefert die angeforderten Daten.
Wir konnten das Problem bei uns nur mit deaktiviertem gzip beobachten, aber es scheint auch mit aktivem gzip aufzutreten.
Das Problem tritt scheinbar nur mit einer 8er JRE auf. Java 7 und 9 sind nicht betroffen und deshalb aktuell ein möglicher Workaround.
Die betroffen Server laufen mit UCS 4.1-2 oder Ubuntu 16.04.



Wir haben ein paar Dinge ausprobiert, um das Problem eingrenzen zu können.
Dadurch, dass wir das Verhalten hier über das (de)aktivieren von gzip steuern konnten, vermuten wir, dass der Hänger mit der übertragenen Datenmenge zusammenhängt. Das könnte erklären wieso es in manchen Umgebungen keine Probleme gibt, in anderen schon.
Wir haben noch keine Beweise, dass es nur an Java liegt, weshalb wir auch auf der Server-Seite schauen.


Viele Grüße

Niko

PS: Es gibt scheinbar ein ähnliches Problem, dass das Laden des Configed über Webstart hängt. Wir vermuten erstmal unterschiedliche Probleme, schließen aber auch nicht aus, dass das ganze zusammen hängt.

Hallo zusammen,

wir lesen noch sehr interessiert mit
Von unserer Seite keine Ergänzugen, es war alles aufgelistet.

Gruß, Jens

Hi,

wir sind vielleicht ein bisschen näher an eine Lösung gerückt.

Könntet ihr mir sagen welche Versionen von openSSL / python-openssl auf euren betroffenen Servern im Einsatz sind?
Gruß

Niko

Hi,

wir sind bisher soweit, dass wir das Problem beim TLS 1.2 unter Java 8 vermuten.
Vermutlich ist es auch nur im Zusammenspiel mit dem OpenSSL / python-openssl vom Server.

Daher gibt es eine neue Version des Configed, bei welchem es möglichst ist über ein Property die Verwendung von TLS 1.1 zu erzwingen.

Wir würden uns über Feedback dazu freuen!


Viele Grüße

Niko