[WADS] Fehler 400 beim Deployment aus einem sekundären Repository

[MaximeJ]

Guten Morgen,

Nach der Aktivierung und Bereitstellung eines sekundären Repositorys zur Beschleunigung unserer Bereitstellungen funktioniert dieses nicht. Der Client startet korrekt über den WinPE-Schlüssel und ruft die Regel, die ihn anweist, sein sekundäres Repository zu finden, korrekt ab. Beim Versuch, die Datei wads.exe herunterzuladen, erscheint jedoch die folgende Meldung in der Clientkonsole:

Code: Alle auswählen

"Error getting wads executable from server: THttpClientSocket.WGet: serversecondaire.domaine.local:443/api/v3/get_wads_exe/192.168.1.10/wads64.exe failed as HTTP Error 400 - Bad Request"

Ich sehe dasselbe in den Nginx-Logs des sekundären Repository-Servers. Mein Repository ist jedoch korrekt synchronisiert, und ich kann die Dateien im freigegebenen Verzeichnis sehen. Clients laden ihre Pakete erfolgreich von diesem sekundären Repository herunter. Ich sehe nur diesen Fehler und weiß nicht, wo ich außer in den Client-Logs und im Verzeichnis `/var/log/` nach den Nginx- und Wapt-Dateien suchen soll, aber ich finde nichts anderes.

Hat irgendjemand eine Ahnung, was diesen 400-Fehler verursachen könnte und wie man ihn beheben kann?


Des Weiteren noch eine Frage zu diesem Thema: Wir besitzen Windows 11 Enterprise-Lizenzen, aber unabhängig von den Optionen, die wir der .xml-Antwortdatei hinzufügen (basierend auf der Indexnummer oder der Versionsbezeichnung im entsprechenden Tag) Nach der Bereitstellung befinden sich die Workstations in der Professional Edition.
Wissen Sie, wodurch dieses Verhalten erklärt werden könnte und wo man die Protokolle findet, um es zu verstehen?


WAPT-Agenten und Serverversion: 2.4.0.14.080
Sekundäre Server und Repositories, die unter Debian 12.5 laufen

Vielen Dank im Voraus für Ihre Hilfe oder Ideen, wie es weitergehen kann!
Maxime

[Sfonteneau]

Hallo

, ist die HTTPS-Zertifikatsprüfung unter WinPE aktiviert?

Ist Ihre Regel für das sekundäre Repository auf die Verwendung von HTTPS eingestellt?

Simon

[dcardon]

Hallo Maxime,

Noch eine Frage zu diesem Thema: Wir haben Windows 11 Enterprise-Lizenzen, aber unabhängig von den Optionen, die wir der Antwort-XML-Datei hinzufügen (basierend auf der Indexnummer oder der Versionsbezeichnung im entsprechenden Tag), landen die Workstations nach der Bereitstellung in der Professional Edition.
Wissen Sie, woran dieses Verhalten liegen könnte und wo wir die Protokolle finden, um es zu verstehen?

Um die Diskussion im Forum übersichtlicher zu gestalten, stellen Sie bitte pro Thema nur eine Frage; andernfalls verliert man leicht den Überblick. Könnten Sie Ihre Frage bitte in einem neuen Thema erneut stellen?

WAPT-Agenten und Serverversion: 2.4.0.14.080.
Sekundäre Server und Repositories laufen unter Debian 12.5.

Version 2.5.5 wurde mit einer ganzen Reihe kleinerer Fehlerbehebungen veröffentlicht; ich empfehle Ihnen ein Upgrade

Aufrichtig,

Denis

[MaximeJ]

Ja, ich habe die Option zum Aktivieren von HTTPS unter WinPE ausgewählt, und die Regel für das sekundäre Repository verweist korrekt auf eine HTTPS-URL auf diesem Server. Die Protokolle der bereits bereitgestellten Clients, die dieses sekundäre Repository verwenden, bestätigen die korrekte Validierung des Serverzertifikats.

Es handelt sich um Zertifikate unserer internen Zertifizierungsstelle; ich habe die Zertifikatskette hinzugefügt und die Nginx-Konfiguration fehlerfrei validiert.

Gibt es Protokolle vom Client oder Server, die mir weitere Informationen liefern könnten? Vielleicht die Nginx-Konfiguration?


Okay, guter Hinweis zu Version 2.5.5; dann planen wir ein Upgrade! Die zweite Frage ist berechtigt; ich erstelle dazu einen neuen Thread. Danke!

[dcardon]

Hallo Maxime,

es gab einen Fehler bei der HTTPS-Weiterleitung. Vor Version 2.5.5 stellte das Vorinstallationsprogramm wgetwads.exe eine Verbindung zum Server her, der es dann per HTTP-Weiterleitung zum sekundären Repository weiterleitete. Dabei kam es jedoch zu einer Fehlinterpretation der Rückgabewerte und einem TLS-Kontext-Reset, was den Fehler 400 verursachte.
Wir haben das Verhalten geändert, sodass das Vorinstallationsprogramm wgetwads.exe nun die Regeln des sekundären Repositorys abruft und sich direkt verbindet, ohne die HTTP-Weiterleitung zu verwenden [1].

Ein Upgrade auf Version 2.5.5 sollte Ihr Problem beheben.

Viele Grüße,

Denis

[1] https://www.wapt.fr/en/doc/wapt-changel ... 2024-05-22

[MaximeJ]

Das ist völlig klar, vielen Dank! Ich werde meine Kollegen, die den Server betreuen, bitten, das Upgrade auf Version 2.5.5 durchzuführen, und dann starten wir unsere Deployments neu.

Beste Grüße