Seite 3 von 3

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

Verfasst: 01 Feb 2018, 08:57
von damien.leviet
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

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

Verfasst: 20 Nov 2018, 09:12
von damien.leviet
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 :)

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

Verfasst: 26 Nov 2018, 12:16
von n.wenselowski
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

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

Verfasst: 10 Jan 2019, 15:03
von damien.leviet
n.wenselowski hat geschrieben:Hi,

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.

[...]

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


Hier mal die hostcontrol.conf:

Code: Alles auswählen

# -*- coding: utf-8 -*-

module = 'HostControl'
config = {
    "opsiclientdPort":    4441,
    "hostRpcTimeout":     15,
    "resolveHostAddress": True,
    "maxConnections":     50,
    "broadcastAddresses": ["<adressen>"]
}


Denke da ist aber alles Standard

Gruß,
Damien