OPSI 4.3 – opsi-script ignoriert Proxy / Kommunikation mit ConfigServer scheitert

[convoy74]

Hallo zusammen,

wir haben bisher erfolgreich mit einer OPSI 4.2 Umgebung gearbeitet. Das Setup bestand aus einem zentralen OPSI ConfigServer in einem gesicherten Netz sowie mehreren Depot-Servern in verschiedenen Netzsegmenten. Die Clients haben sich ihre Konfigurationen über die jeweiligen Depot-Server vom zentralen ConfigServer geholt.

Nun evaluieren wir aktuell OPSI 4.3 in einer Testumgebung und müssen natürlich ein vergleichbares Setup mit zentralem ConfigServer und verteilten Depot-Servern aufbauen.

Problem:

Registriert man einen Windows-Client am Depot-Server, wird dieser korrekt angelegt, jedoch scheint der MessageBus zunächst nicht zu funktionieren. Durch Setzen der proxy_url in der opsiclientd.conf (mittels opsi-configed verteilt) können wir die Kommunikation mit dem zentralen ConfigServer herstellen – der MessageBus funktioniert, Konsolen können geöffnet und Nachrichten versendet werden, der Client wird als online angezeigt. Soweit, so gut.

Neues Problem beim Software-Rollout:

Beim Ausrollen von Produkten – sowohl bei on_demand als auch nach einem Neustart – zeigt sich folgendes Verhalten:

• Der Client erkennt korrekt, dass ein Produkt installiert werden soll.

• opsi-script wird gestartet.

• Es erscheint kurz das opsi-script-Fenster – jedoch passiert danach nichts mehr.

• Es erscheinen keine sichtbaren Fehlermeldungen.

Nach ausführlichem Debugging haben wir festgestellt, dass opsi-script offenbar keinen Proxy berücksichtigt. Es wird:

• das Depot-Share erfolgreich gemountet,

• das Produkt erkannt,

• und dann versucht, sich direkt mit dem zentralen ConfigServer zu verbinden.

An dieser Stelle scheitert opsi-script, da es den Proxy ignoriert. Auch ein gesetzter System-Proxy bringt leider keine Besserung. In den Logs ist zu erkennen, dass opsi-script beim Versuch, den ConfigServer direkt zu kontaktieren, sofort beendet wird.

Setzen wir testweise den DepotServer als ConfigServer, läuft opsi-script hingegen problemlos durch.

Frage:

Wie können wir in einem verteilten Setup mit zentralem ConfigServer und mehreren Depots sicherstellen, dass opsi-script den Proxy verwendet – oder zumindest den Zugriff auf den ConfigServer über den Depot-Server oder eine Proxy-Komponente korrekt abwickelt?

Gibt es hier empfohlene Best Practices oder zusätzliche Konfigurationen, die wir übersehen haben?

Viele Grüße

Manfred

[j.schneider]

Hallo,

standardmäßig verwenden opsi-script und opsiclientd die Proxy-Einstellungen des Systems.
Daher ist es normalerweise nicht notwendig explizit eine proxy_url in der opsiclientd.conf zu setzen.
Ich vermute daher ein Problem mit den Proxy-Einstellungen des Systems.

Grüße
Jan Schneider

[convoy74]

opsiclient_1.log

(21.55 KiB) 24-mal heruntergeladen

Hallo und danke für die Rückmeldung,

nach unserer Erfahrung scheint das Verhalten in unserem Setup nicht mit der Aussage übereinzustimmen, dass opsi-script automatisch den System-Proxy verwendet.

Wir haben dazu zwei gezielte Tests durchgeführt, deren Ergebnisse wir anhand der jeweiligen opsiclient.log-Dateien belegen können (Logfiles hänge ich unten an):

Test mit gesetztem proxy_url in der opsiclientd.conf:
(opsiclient_1.log)

Der MessageBus funktioniert, der Client wird als online angezeigt, Konsolen lassen sich öffnen.Allerdings wird kein Rollout des Produkts durchgeführt – opsi-script wird zwar gestartet, es erfolgt jedoch keine Verbindung zum ConfigServer.

Test mit gesetztem System-Proxy (ohne proxy_url in der opsiclientd.conf):
(opsiclient_2.log)

Gleiches Verhalten – opsi-script scheint den Proxy nicht zu verwenden. Hier sieht man, dass weder opsi-client-agent noch opsi-script eine Verbindung via Proxy aufbaut.

Zum Vergleich haben wir opsi-script manuell in der Konsole gestartet:

Mit Angabe des ConfigServers:

opsi-script versucht eine Verbindung aufzubauen, scheitert aber ohne ersichtliche Fehlermeldung (siehe mitproxy_0.log).

Mit Angabe des DepotServers als /opsiservice:

opsi-script baut die Verbindung erfolgreich auf, der Ablauf funktioniert (siehe depot_0.log).

Unser Fazit bisher:Während der opsiclientd offenbar mit der proxy_url umgehen kann (z. B. für den MessageBus), scheint opsi-script diese nicht auszuwerten – auch ein gesetzter System-Proxy wird anscheinend nicht berücksichtigt. Die Tests deuten darauf hin, dass opsi-script den direkten Zugriff auf den angegebenen /opsiservice benötigt.

Wir freuen uns über Hinweise, ob es hier eine versteckte Konfigurationsmöglichkeit gibt oder ob dies ein bekanntes Verhalten in OPSI 4.3 ist.

Viele Grüße

Manfred

opsiclient_2.log

(4.6 KiB) 53-mal heruntergeladen

opsiclient_1.log

(21.55 KiB) 24-mal heruntergeladen

Der Dateianhang depot_0.log existiert nicht mehr.

[convoy74]

Hier noch das mitproxy_0.log

[j.schneider]

Hallo,

der opsiclientd ist ein Windows-Dienst der opsi-script als Subprozess ausführt.
Die reg query Ausgabe scheint sich auf die Proxy-Settings des Administrator-Accounts zu beziehen.

Grüße
Jan Schneider

[convoy74]

Hallo Herr Schneider

vielen Dank für deine Antwort!

Sie haben natürlich recht, dass sich die reg query-Ausgabe auf die Proxy-Einstellungen des aktuell angemeldeten Benutzers bezieht – in diesem Fall Administrator. Genau deshalb habe ich im Screenshot auch direkt darunter den manuellen Aufruf von opsi-script.exe mit /opsiservice eingebaut – im selben Benutzerkontext, also exakt unter den Bedingungen, unter denen auch der Proxy aktiv ist.

Zusätzlich habe ich auch getestet, ob opsi-script eventuell den globalen WinHTTP-Proxy (Systemkontext) verwendet. Wie man im angehängten Screenshot (netsh winhttp show proxy) sieht, ist dieser korrekt gesetzt. Dennoch scheitert auch dieser Test. (siehe Bild)

Zur Übersicht:

• opsiclient_1.log: Test mit gesetztem proxy_url in der opsiclientd.conf. - Messagebus Okay, Software Installation scheitert

• opsiclient_2.log: Test mit gesetztem globalen WinHTTP-Proxy, wie im Screenshot zu sehen. - Kein Messagebus, Keine Software installation

• mitproxy_0.log: Manueller Aufruf von opsi-script mit /opsiservice zum zentralen ConfigServer – schlägt fehl.

• global_0.log: Manueller Aufruf mit dem Depot als /opsiservice – funktioniert wie erwartet.

Fazit:
opsi-script verwendet offenbar weder Benutzer- noch System-Proxy-Einstellungen. Nur wenn /opsiservice direkt erreichbar ist (z. B. über das Depot), funktioniert der Ablauf. Der opsiclientd hingegen scheint mit proxy_url umgehen zu können, was z. B. für den MessageBus gut funktioniert.

Leider ist der globale Proxy für uns keine Option, wir wären auf proxy_url angewiesen.

Ich freue mich über weitere Hinweise oder Korrekturen – vielleicht habe ich ja doch eine Konfigurationsoption übersehen.

Grüße

Manfred

proxy_global.png (103.52 KiB) 2376 mal betrachtet

[j.werner]

Hallo Manfred,

vielen Dank für Ihr Interesse an opsi. Bitte haben Sie Verständnis, dass wir im Rahmen dieses Forums nur bedingt Support leisten können.

Wenn Sie opsi professionell einsetzen, empfehlen wir einen Support-Vertrag abzuschließen (https://opsi.org/de/support/) und evtl. opsi-Schulungen (https://opsi.org/de/training/) zu besuchen.

Schauen Sie sich auch unsere Software/Patchespakete an (https://opsi.org/de/update-subscriptions/). Vielleicht ist ja etwas Interessantes für Sie dabei!

Haben Sie noch Fragen zu unserem Produkt bzw. möchten diesbezüglich beraten werden, dann wenden Sie sich gerne direkt an uns. Sie erreichen uns telefonisch unter +49(0) 6131/275610 oder per Mail unter info@uib.de.

Unser freundliches Team unterstützt Sie gerne!

Viele Grüße

Jan Werner