Ruhiges IT-Forum

Hallo Marc,

funktioniert das Deployment auf dem primären Standort (ohne sekundäres Repository)? Funktioniert es, wenn du die Regeln für das sekundäre Repository für den betreffenden Rechner/das betreffende Subnetz deaktivierst?

Handelt es sich beim sekundären Repository um einen Windows- oder Linux-Rechner? Wird ein Nginx-Server oder ein Wapt-HTTP-Server verwendet?

Welche Wapt-Version ist im Einsatz?

Viele Grüße,

Denis

Hallo,
wir haben es direkt im LAN versucht, wo der WAPT 2.5-Server auf einem Linux-Server läuft.
Wir haben wapttftpserver für TFTP und nginx für HTTP verwendet.
Auf der Hauptseite passiert nichts.

Für das sekundäre Repository nutzen wir einen Windows-10-Rechner mit einem seit gestern installierten WAPTHttpServer Remote Repository.

Unsere Tests werden heute von der Website des sekundären Repositorys aus durchgeführt.
Das sind alle weiteren Informationen.
Vielen Dank

Hallo,
wir kommen mit unserer Installation voran.
Wir haben den Bluescreen erreicht: IPXE-Bootmenü für die WAPT-Bereitstellung.
Nach Auswahl von „Host registrieren (winpe x64)“
haben wir IPXE ausgewählt, und der PC wurde wieder in der Konsole angezeigt.

Anschließend bleiben wir in einem Eingabeaufforderungsfenster hängen: „VerifyCert: 0
Keine IP-Adresse gefunden“.
Der Befehl „ipconfig“ liefert: „Windows-IP-Konfiguration“.

Der Befehl im vorherigen Fenster lautete: „start cmd /kx:\dlls\wgetwads64.exe --verify-cert=0 --server_url=https://xxx-xxx-wapt“.

Während des Downloads war tatsächlich eine IP-Adresse im korrekten VLAN vorhanden.
Wir möchten nun mit dem nächsten Schritt fortfahren.
Vielen Dank.

Hallo

, es gibt tatsächlich zwei Dinge:

IPXE und WinPE.

In Ihrem Fall erkennt IPXE die Netzwerkkarte korrekt. WinPE hingegen scheint sie nicht zu erkennen.

Sie müssten die Treiber für die Netzwerkkarte zu Ihrer WinPE-Installation hinzufügen. Siehe:
https://www.wapt.fr/fr/doc/wapt-wads.ht ... inpe-files

Hallo,
wir kommen tatsächlich voran; das Laden des Netzwerktreibers hat uns den nächsten Schritt ermöglicht.
Beim LAN-Test des Servers erreichen wir das Fenster „Willkommen WADS Aufgabe #3“
und eine Fehlermeldung, danach passiert nichts mehr:
„Hostdatenverifizierung fehlgeschlagen: Kein Signaturzertifikat in den Daten“.


Auf dem sekundären Repository-Server:
Fehler beim Abrufen der WADS-Datei vom Server: „THttpClientSocket.Wget: xx.xx.xx.xx:443/wads/wads64.exe fehlgeschlagen (404 Nicht gefunden)“.

Der Test, die Datei „wads64.exe“ über einen Browser herunterzuladen, funktioniert über HTTP, aber nicht über HTTPS.
In beiden Fällen habe ich die .exe-Dateien auf dem Server über die Konsole signiert. Das ist der

aktuelle Stand.

Vercingetorix schrieb: ↑14. Okt. 2024 - 11:53 Fehler beim Abrufen der wads-Datei vom Server: THttpClientSocket.Wget: xx.xx.xx.xx:443/wads/wads64.exe fehlgeschlagen (404 Nicht gefunden).
Der Test, die Datei wads64.exe über einen Browser herunterzuladen, funktioniert mit HTTP, aber nicht mit HTTPS.

HTTP, aber nicht HTTPS?

Wenn Sie einfach zu Folgendem gehen:

https://xx.xx.xx.xx

Was beantwortet das?

Auf dem sekundären Server tritt folgender Fehler auf:
https://ip_secondary_server/
WAPTHttpServer Serverfehler 404

HTTP 404 Nicht gefunden

Falsche Route
mORMot 2

Auf dem primären Server, nach Eingabe des WAPT-Serverpassworts
: ENTERPRISE

Zusammenfassend lässt sich sagen: http://ip_serveur_secondaire/wads/wads64.exe funktioniert, https://ip_serveur_secondaire/wads/wads64.exe jedoch nicht . Seltsam, obwohl die Konfiguration identisch ist.

Hallo,
da die verwendete Konfiguration der sekundären Repository-Deklaration in der Wapt-Konsole entspricht,
haben wir die HTTPS-Adresse auf http://xx.xx.xx.xx/wapt geändert.
Nun erhalten wir denselben Fehler:
„Fehler beim Abrufen der ausführbaren Datei ‚wads‘ vom Server: THttpClientSocket.WGet: xx.xx.xx.xx:80/wads/wads64.exe fehlgeschlagen (HTTP-Fehler 404 – Nicht gefunden)“.

Derselbe Fehler, nur mit 80 statt 443.

Dies ähnelt auffällig dem folgenden Thema: viewtopic.php?t=3161.

Schönen Tag noch.

Hallo,
uns wurde empfohlen, wapt-remote-repo-http anstelle von tis-remote-repo-nginx zu verwenden.
Bei der Verwendung von wads auf einem sekundären Repository erhielten wir jedoch die Fehlermeldung: „
Fehler beim Abrufen der wads-Datei vom Server: THttpClientSocket.WGet: xx.xx.xx.xx:80/wads/wads64.exe fehlgeschlagen (HTTP-Fehler 404 – Nicht gefunden)“
Wir sind daher wieder auf nginx umgestiegen und der Fehler tritt nun nicht mehr auf.

Wir können das Thema daher als [GELÖST] markieren
. Schönen Tag noch!