Windows Netinstall ohne PXE: Verbindung mit opsiconfd aus WinPE fehleranfällig

Antworten
mdecker
Beiträge: 65
Registriert: 26 Mär 2012, 16:20

Windows Netinstall ohne PXE: Verbindung mit opsiconfd aus WinPE fehleranfällig

Beitrag von mdecker »

Hallo zusammen,

nachdem ich das Problem jetzt mehrere Monate mangels Zeit vor mir her geschoben habe, habe ich gestern endlich genauer rein geschaut. Einen Eintrag hier im Forum konnte ich nicht finden, deswegen hier meine Beobachtungen:

Im Detail:
Was sollte passieren?
Wenn ich ein Windows(10) Netinstall-Produkt per ISO/CD/USB-Stick - nicht PXE - installiere, muss ich den OPSI-Config-Server in der Linux-Stufe manuell nachtragen, da er nicht von unserem DHCP kommt. Dabei habe ich von Anfang an immer die Kurzform des Hostnames verwendet, also weder voll qualifiziert noch mit Port-Spezifikation. Bis irgendwann in 2020 hat die Installation wie erwartet funktioniert.

Was ist passiert?
Wenn ich nach obiger Beschreibung vorgehe: Seit irgendeinem Update der Netboot-Produkte oder des Boot-Image, das ich nicht mehr genau verfolgen kann, dauert die WinPE-Stufe zur Windows-Installation ca. 40 Minuten, während das OPSI-Script Fenster "connect to OPSI server" anzeigt. Der Aufruf von

Code: Alles auswählen

opsiservicecall_authenticated
schlägt dabei immer fehl.

Die Ursache habe ich jetzt endlich identifizieren können. Hier der entsprechende Abschnitt aus dem opsiscript.log, der den fehlerhaften Aufruf zeigt:

Code: Alles auswählen

Execution of: opsiservicecall_authenticated /username $clientId$ /password $hostKey$ /serviceurl $serviceurl$
[5] [2021-03-03 19:36:55.481] []     
[6] [2021-03-03 19:36:55.481] []          "method": "authenticated"
[7] [2021-03-03 19:36:55.857] []       Lib should be: ssleay32.dll
[7] [2021-03-03 19:36:55.857] []       SLLVersion : TLSv1.2
[7] [2021-03-03 19:36:55.857] []       Loaded: ssl_openssl
[7] [2021-03-03 19:36:55.857] []       HTTPSender.Sock.SSL.LibVersion: OpenSSL 1.0.2u  20 Dec 2019
[3] [2021-03-03 19:37:16.900] []       HTTPSender Post failed
[3] [2021-03-03 19:37:16.900] []       HTTPSender result: 500 msg:
[6] [2021-03-03 19:37:16.915] []       Retry with communicationmode: 1
[3] [2021-03-03 19:37:37.943] []       HTTPSender Post failed
[3] [2021-03-03 19:37:37.943] []       HTTPSender result: 500 msg:
[6] [2021-03-03 19:37:37.943] []       Retry with communicationmode: 2
[3] [2021-03-03 19:37:58.960] []       HTTPSender Post failed
[3] [2021-03-03 19:37:58.960] []       HTTPSender result: 500 msg:
[5] [2021-03-03 19:37:58.960] []       opsi Server Version :
[7] [2021-03-03 19:37:58.976] []       Lib should be: ssleay32.dll
[7] [2021-03-03 19:37:58.976] []       SLLVersion : TLSv1.2
[7] [2021-03-03 19:37:58.976] []       Loaded: ssl_openssl
[7] [2021-03-03 19:37:58.976] []       HTTPSender.Sock.SSL.LibVersion: OpenSSL 1.0.2u  20 Dec 2019
[3] [2021-03-03 19:38:19.999] []       HTTPSender Post failed
[3] [2021-03-03 19:38:19.999] []       HTTPSender result: 500 msg:
[6] [2021-03-03 19:38:19.999] []       Retry with communicationmode: 1
[3] [2021-03-03 19:38:41.007] []       HTTPSender Post failed
[3] [2021-03-03 19:38:41.007] []       HTTPSender result: 500 msg:
[6] [2021-03-03 19:38:41.007] []       Retry with communicationmode: 2
[3] [2021-03-03 19:39:02.051] []       HTTPSender Post failed
[3] [2021-03-03 19:39:02.051] []       HTTPSender result: 500 msg:
[3] [2021-03-03 19:39:02.051] []       Error:
(TCPdump zeigt, dass es daran liegt, dass die WinPE-Stufe auf Port 80 mit dem Config-Server kommunizieren will, was natürlich nicht klappt.
Nach langem Timeout (~40 Minuten) läuft die Installation auch ohne jemals erfolgreiche Verbindung durch. An der Stelle stellt sich mir die Frage, wozu die überhaupt nötig ist.)

Die Ursache dafür ist eine falsche URL zum OPSI-Server, wie sich dann weiter oben im gleichen Log zeigt:

Code: Alles auswählen

Set  $serviceurl$ = GetValueFromIniFile ("c:\opsi\opsi-client-agent\files\opsi\cfg\config.ini","opsiclientd","config_service.url","")
[...]
[6] [2021-03-03 19:36:48.278] []   The value of the variable "$serviceurl$" is now: "https://mein-opsi.example.com:4447"
[...]
[6] [2021-03-03 19:36:48.278] [] Set  $serviceurl$ = GetValueFromIniFile ("c:\opsi\opsi-script-infos.ini","infos","serviceurl","")
[6] [2021-03-03 19:36:48.278] []   The value of the variable "$serviceurl$" is now: "mein-opsi"
Wie man sieht, wird "serviceurl" zwei mal gesetzt und dabei in jedem Fall vom zweiten Aufruf überschrieben. Der Wert aus der zuerst gelesenen Datei wäre dabei korrekt, der aus der zweiten Datei kommt von den Werten, die das Bootimage basierend auf den dort gemachten Eingaben setzt, obwohl es bereits Kontakt mit dem Server hatte und in der ersten Datei der richtige Wert drin steht. Insgesamt erschließt sich mir nicht, warum zwei mal der gleiche Wert gelesen werden sollte. An dieser Stelle sehe ich einen möglichen Bug, der leicht zu beheben ist: In meinen Versuchen reichte es, die zweite Zuweisung zu entfernen. Der Wert in config.ini sieht für mich zuverlässig aus.

Das Problem lässt sich ebenfalls vermeiden, indem man in der Linux-Stufe explizit die Port-Nummer des Servers mit angibt ("mein-opsi:4447"). Dass dies nötig ist, ist allerdings erstens nicht immer so gewesen und zweitens auch unverständlich, da zumindest das Linux-System auch ohne explizite Port-Nummer problemlos mit dem opsiconfigd Kontakt aufnehmen kann. Dieser Automatismus funktioniert also mindestens nicht mehr konsistent. Würde die Linux-Stufe die von ihr anscheinend ja auch zur Kommunikation verwendete URL so in die zweite INI-Datei schreiben oder würde der Client der WinPE-Stufe ähnlich tolerant sein, würde das Problem ebenfalls nicht auftreten.

Bei PXE tritt das Problem nicht auf, weil der Servername korrekt an das Boot-Image übergeben wird, soweit ich das beurteilen kann.

Mit welchen Schritten kann das Problem nachgestellt werden?
Installation eines Rechners von ISO/CD/USB ohne automatische Konfiguration des Config-Servers per DHCP, Eingabe des Server-Namens ohne Port.

(Keiner der anderen von mir befragten OPSI-Admins hat das Problem bis jetzt gesehen, was aber mit Verwendung von PXE oder entsprechender DHCP-Konfiguration erklärt werden kann. Ich habe nicht weiter nach gehakt.)

Bei welche Versionen der beteiligten Komponenten tritt das Problem auf?
Aktueller OPSI 4.1 stable Server, win10-x64 Version 4.1.0.2-9, alle getesteten Boot-CDs, letzter Stand: 2021-02-01
Benutzeravatar
m.radtke
uib-Team
Beiträge: 1114
Registriert: 10 Jun 2015, 12:19

Re: Windows Netinstall ohne PXE: Verbindung mit opsiconfd aus WinPE fehleranfällig

Beitrag von m.radtke »

Hi

ich habe eben eine VM mit der opsi 4.1 iso 20210122 mit DHCP gestartet und in die configserviceurl einfach nur den Hostnamen des opsi-Server angegeben, ohne domain und Port

ich konnte dann erfolgreich ein Produkt auswählen und installieren.

Liefert euer DHCP die option "search domain ..." aus?

Gruß
Mathias
Kein Support per DM!
_________________________
opsi support - http://www.uib.de/
For productive opsi installations we recommend support contracts.
hobbyist
Beiträge: 30
Registriert: 29 Mai 2018, 13:38

Re: Windows Netinstall ohne PXE: Verbindung mit opsiconfd aus WinPE fehleranfällig

Beitrag von hobbyist »

Hi,

danke für diesen Post! Genau das ist vorhin bei mir aufgetreten und ich habe damit zu kämpfen. Das Irre ist: Es ging alles, ich habe das Windows-Image ausgetauscht, es hing. Ältere Windows-Version genommen, hing immer noch. Original-Version genommen, da nun auch. Netboot-Produkt gelöscht und neu zusammengesetzt, immer noch da. Server gebootet... VirtualBox und deren Netzwerkverbindung in Verdacht, aber die ging ja auch vorher.

OPSI 4.2 stable, win10-x64 4.1.0.2-14, opsi4.2.0-client-boot-cd_20210519

Was hätte denn die "search domain" damit zu tun? Die kommt per DHCP rüber und ist auch im Server eingetragen.

Grüße
mdecker
Beiträge: 65
Registriert: 26 Mär 2012, 16:20

Re: Windows Netinstall ohne PXE: Verbindung mit opsiconfd aus WinPE fehleranfällig

Beitrag von mdecker »

Ich habe leider keine Benachrichtigung für die Antwort bekommen, obwohl das eigentlich so eingestellt ist, weswegen ich erst so spät darauf zurück komme. :?

Jetzt ist das Problem mit 4.2 wieder aufgetreten, obwohl ich die Port-Nummer mit eingegeben habe. Allerdings funktioniert der Login mit User (Einmalpasswort ist ja kaputt, siehe viewtopic.php?t=12676) nur, wenn man den Port beim User-Login wieder weg macht, sonst bekommt man nur "name or service not known". Nun weiß ich nicht, ob das die Ursache ist oder es neue Probleme damit gibt. Nach ca. 40 Minuten Wartezeit wurde das Windows dann wie vorher schon beschrieben fehlerfrei installiert.

Die search domain wird per DHCP gesetzt und es macht ja auch keinen Unterschied, ob ich FQDN des Severs oder nur den lokalen Namen nutze - beide werden gefunden. Das Problem ist ziemlich eindeutig auf die Port-Nummer (4447) zurück zu führen, die anscheinend nicht automatisch ergänzt wird.

@m.radtke: Wie weit ist die Installation denn im Test gelaufen? Komplett durch, bis das Windows vollständig drauf war? Der Hänger tritt ja erst im PE auf. Die Linux-Stufe läuft komplett unauffällig durch.
Antworten