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
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:
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"
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