Ständige Verbindungsabbrüche im Opsi Config Editor

damien.leviet
Beiträge: 86
Registriert: 24 Feb 2014, 11:30

Re: Ständige Verbindungsabbrüche im Opsi Config Editor

Beitragvon damien.leviet » 01 Feb 2018, 08:57

Hallo Niko,

bzgl. dem Hänger auf Seiten des opsiconfd: das Problem besteht nur in Verbindung mit Java und tritt beim Handshake für eine TLS-Verbindung auf


Ich *glaube* das wars! Habe in der opsiconfd.conf mal unter "service" folgenden Eintrag hinzugefügt:

Code: Alles auswählen

# Workaround für Verbindungsabbrüche
# https://forum.opsi.org/viewtopic.php?t=9581
accepted ciphers = AES128-GCM-SHA256


Seitdem kann ich die host_reachable() Funktion so oft feuern wie ich will; es hängt sich nichts mehr auf!
Liegt also wirklich an Java :D

Falls ihr einen Supportvertrag habt, klopf doch mal kurz bei uns an. Ich habe einen Prototyp für eine neue Implementierung in der Schublade, die ich nur zu gerne mal testen würde!


Haben wir nicht, wenn es aber kein Problem darstellt würde ich es trotzdem gerne testen ;)

MfG Damien

damien.leviet
Beiträge: 86
Registriert: 24 Feb 2014, 11:30

Re: Ständige Verbindungsabbrüche im Opsi Config Editor

Beitragvon damien.leviet » 20 Nov 2018, 09:12

Ich muss das Thema leider nochmal aufwärmen, da ich mittlerweile eine Idee habe, warum es zu diesen Aufhängern kommt.

Vor geraumer Zeit hatte ich den OPSI Server auf eine neue, modernere VM migrieren müssen und es kam auch zu einem IP Adresswechsel.
Was ich gemacht habe: im Config Editor den neuen Depot Namen samt neuer IP Adresse für alle Clients hinterlegt und von dort aus ein On Demand Event abgefeuert, damit jeder Client die neue Konfiguration mitbekommt und sich auf die neuen Einstellungen aktualisiert.

Das hat für ca. 85% der Clients funktioniert, überwiegend für Fest-PCs. Bei den Laptops jedoch war die Sache schwieriger, da diese nicht immer erreichbar sind. Und ich denke das Problem, welches seitdem auftritt, lässt sich wie folgt erklären:
- Zunächst hatte ich den alten Server heruntergefahren - somit konnten verbliebene Geräte kein Konfigurationsupdate mehr erhalten
- Beim Prüfen der Erreichbarkeit und/oder der Session Informationen kommt es zu einer niemals endenden Anfrage, da der Config Server einen Client auffordert, ihm mitzuteilen, ob er erreichbar ist oder nicht, dieser jedoch nicht antworten kann, da er noch die alte Serveradresse in der Konfiguration hat.

Hier ist meiner Meinung nach der Grund für den Aufhänger. Es passiert logischerweise nicht, wenn der betroffene Host ausgeschaltet ist, da er nicht antworten kann und es schlichtweg zu einem Timeout kommt. Ist er jedoch an, kann er nicht antworten und der Server hat scheinbar an dieser Stelle keinen Timeout definiert, dass wenn innerhalb von z.B. 30 Sekunden keine Antwort kommt, er abbricht.
Es kommt zu einem Prozesszustand S, einem "Interruptible sleep (waiting for an event to complete)". Genauso verbleibt der Server dann auch, da er keine Rückantwort von einem angeschalteten Host erhält, der aufgrund der falschen IP Adresse nicht antworten kann.

Es müsste an dieser Stelle nochmal ein Timeout greifen, der nur für eine bestimmte Zeit auf eine Rückantwort eines erreichbaren Hosts wartet, damit es eben nicht zu diesen Aufhängern kommt.

Danke :)

Benutzeravatar
n.wenselowski
Beiträge: 2898
Registriert: 04 Apr 2013, 12:15

Re: Ständige Verbindungsabbrüche im Opsi Config Editor

Beitragvon n.wenselowski » 26 Nov 2018, 12:16

Hi,

damien.leviet hat geschrieben:Das hat für ca. 85% der Clients funktioniert, überwiegend für Fest-PCs. Bei den Laptops jedoch war die Sache schwieriger, da diese nicht immer erreichbar sind. Und ich denke das Problem, welches seitdem auftritt, lässt sich wie folgt erklären:
- Zunächst hatte ich den alten Server heruntergefahren - somit konnten verbliebene Geräte kein Konfigurationsupdate mehr erhalten
- Beim Prüfen der Erreichbarkeit und/oder der Session Informationen kommt es zu einer niemals endenden Anfrage, da der Config Server einen Client auffordert, ihm mitzuteilen, ob er erreichbar ist oder nicht, dieser jedoch nicht antworten kann, da er noch die alte Serveradresse in der Konfiguration hat.

Bei dem Check prüft nur der Server in Richtung des Clients. Welche Adresse der Client für den Configserver konfiguriert hat, ist an der Stelle irrelevant, weil die vom Server geöffnete Verbindung für die Antwort verwendet wird - der Client baut keine eigenständige Verbindung zum Server für die Antwort auf.

Hier ist meiner Meinung nach der Grund für den Aufhänger. Es passiert logischerweise nicht, wenn der betroffene Host ausgeschaltet ist, da er nicht antworten kann und es schlichtweg zu einem Timeout kommt. Ist er jedoch an, kann er nicht antworten und der Server hat scheinbar an dieser Stelle keinen Timeout definiert, dass wenn innerhalb von z.B. 30 Sekunden keine Antwort kommt, er abbricht.
Es kommt zu einem Prozesszustand S, einem "Interruptible sleep (waiting for an event to complete)". Genauso verbleibt der Server dann auch, da er keine Rückantwort von einem angeschalteten Host erhält, der aufgrund der falschen IP Adresse nicht antworten kann.

Wir haben hier im Standard Timeouts eingebaut: 3 Sekunden für die Erreichbarkeitsprüfung, 15 Sekunden für RPCs (beinhaltet auch Session-Abfrage) an den Client. Habt ihr dort abweichende Werte eingestellt oder sie gar komplett entfernt?


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.