forum.opsi.org

Moin,

wir stehen vor einem Problem mit der OPSI-PXE Boot Konfiguration auf unserem System. Konkret wird die Konfiguration eines Clients, der in einem Depot auf „Setup“ gesetzt wird, nicht übernommen. Dieses Problem konnten wir bei mehreren Clients und auf zwei separaten OPSI-Systemen reproduzieren, weshalb wir von einem möglichen Bug ausgehen.

Umgebung:

Betriebssystem: Ubuntu 20.04 LTS Server (Sowohl für den Config- als auch alle Depotserver)
OPSI-Version: 4.3.18.18
OPSI-Pakete: win11-x64, win10-x64
Systemaufbau: Ein Config-Server mit fünf Depot-Servern

Fehlerbeschreibung und Workflow:

Unser Config-Server wird zur Bereitstellung von Software genutzt, wobei die Clients in den jeweiligen Depots der Standorte zugeordnet sind. Bisher wurden Windows 10 Images erfolgreich verteilt, doch seit Kurzem bricht die Bereitstellung ab, wenn die Installation in einem der Depots erfolgt. Obwohl das Opsi-Linux-Image erfolgreich vom Hauptserver übermittelt wird, wird der Auftrag zur Installation nicht übernommen. Der betroffene Client startet bis zum Fenster „Configuration incomplete“, in dem die Daten manuell eingegeben werden müssen, und zeigt möglicherweise die Meldung „[…] is already used by Host“.

Interessanterweise funktioniert die Installation einwandfrei, wenn sie im Haupt-Depot gestartet wird. Daher sind neue Clients von diesem Verhalten nicht betroffen.

Der Fehler tritt auf zwei unabhängigen OPSI-Systemen auf. Die Logs der OPSI-Konfiguration geben, selbst im höchsten Debug-Level, weder im Webinterface noch in Opsi-configed, Hinweise auf die Ursache.

Netzwerkdiagnose (Wireshark):

Eine Analyse der TFTP-Übertragung zeigt, dass nach der Übertragung die Datei opsi/opsi-linux-bootimage/loader/../cfg/18e54d56-794a-e835-546a-f7f52b724f0d nicht gefunden werden kann:

Frame 620884: 61 bytes on wire (488 bits), 61 bytes captured (488 bits)
...
TFTP ERROR: File not found (1)
Error message: File not found

Die fehlende Datei scheint der Auslöser für das Nichtübernehmen der Instruktionen zu sein. Eine Überprüfung des TFTP-Verzeichnisses zeigt, dass die Datei tatsächlich nicht vorhanden ist.

Fragen:

Könnte es sich bei diesem Verhalten um einen Bug in der OPSI-PXE Boot Konfiguration handeln?
Gibt es bekannte Workarounds oder Updates, die dieses Problem beheben könnten?

Wir wären dankbar für eine kurze Rückmeldung und Unterstützung bei der weiteren Analyse.

Beste Grüße
Mafi

Schaut mal in eurer opsipxeconfd.log nach.

Einen ähnlichen Fehler haben wir auch letzens behoben, in opsipxeconfd.log standen dann etwa solchen Zeilen: "inotify.calls.InotifyError: Call failed (should not be -1): (-1) ERRNO=(0)"
Der opsipxeservice versucht alle PXE-Einträge gleichzeitig zu schreiben und gerät dabei an die Grenzen von inotify.max_user_watches and inotify.max_user_instances

Viele Grüße
Volker

Danke, für den Hinweis Volker!

Folgenden Input haben wir im Log, es scheint als würde die Datei zumindest erzeugt werden:

[4] [2024-07-15 10:21:13.497] [ ] Product 'win11-x64' is using obsolete pxe config template 'install-x64', using default. (opsipxeconfd.py:548)
[5] [2024-07-15 10:21:13.588] [PXEConfigWriter] Creating config ['/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d', '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d'] and waiting for access (pxeconfigwriter.py:185)
[5] [2024-07-15 10:21:13.588] [ ] PXE boot configuration for HOSTNAME.REMOVED is now set at ['/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d', '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d'] (opsipxeconfd.py:496)
[5] [2024-07-15 10:23:00.438] [PXEConfigWriter] Deleting config file '/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d' (pxeconfigwriter.py:220)
[5] [2024-07-15 10:23:00.438] [PXEConfigWriter] Deleting config file '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d' (pxeconfigwriter.py:220)
[…]
[4] [2024-07-15 10:21:13.497] [ ] Product 'win11-x64' is using obsolete pxe config template 'install-x64', using default. (opsipxeconfd.py:548)
[5] [2024-07-15 10:21:13.588] [PXEConfigWriter] Creating config ['/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d', '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d'] and waiting for access (pxeconfigwriter.py:185)
[5] [2024-07-15 10:21:13.588] [ ] PXE boot configuration for HOSTNAME.REMOVED is now set at ['/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d', '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d'] (opsipxeconfd.py:496)
[5] [2024-07-15 10:23:00.438] [PXEConfigWriter] Deleting config file '/tftpboot/opsi/opsi-linux-bootimage/cfg/18e54d56-794a-e835-546a-f7f52b724f0d' (pxeconfigwriter.py:220)
[5] [2024-07-15 10:23:00.438] [PXEConfigWriter] Deleting config file '/tftpboot/opsi/opsi-linux-bootimage/cfg/01-00-0c-29-72-4f-0d' (pxeconfigwriter.py:220)

Leider besteht das Problem weiterhin.

Moin,

wir hatten mal einen Fall, wo ein virenscanner die Dateien geöffnet hat (wodurch sie via inotify direkt gelöscht wurden).
Sobald die Datei einmal angefasst wird, ist sie weg - das ist so by design.

Vielleicht ist es ja etwas in der Richtung (denn angelegt scheint die Datei ja zu werden).

Wir hatten das Problem auch mal, bei uns war die Ursache der nächtlich laufende Backup. Wir haben das Verzeichnis in dem die Configs liegen dann vom Backup ausgenommen, die Daten sind durch erneutes auf Setup setzen ja sowieso schnell wieder generierbar.

Hallo zusammen,

danke für die Rückmeldungen.

Es ist keine AV-Software im Spiel und kein Backup-Client verursacht dieses Problem. Das haben wir ausgeschlossen. Zusätzlich haben wir testweise das Verzeichnis geloggt, keine Anwendung greift darauf zu.

Auch haben wir die Infrastruktur einmal im Testsystem auf Ubuntu 22.04 Basis (Minimal-Server) neu aufgesetzt (normale Installation ohne Quick-Install). Der Fehler persistiert, weshalb wir annehmen, dass das Problem von OPSI aus geht und nicht durch eine Fehlkonfiguration o.Ä,. Bedingt ist.

Getestete Version: opsiconfd 4.3.19.6 [python-opsi-common=4.3.17.2]

Kann hier jemand dieses Verhalten bestätigen?

Grüße
MAF

MaF hat geschrieben: ↑19 Aug 2024, 12:49 Der betroffene Client startet bis zum Fenster „Configuration incomplete“, in dem die Daten manuell eingegeben werden müssen, und zeigt möglicherweise die Meldung „[…] is already used by Host“.

D.h. das Bootimage ist vollständig geladen, man kann sich perr ssh einloggen und es fehlen lediglich Einträge in der Maske?

Gruss
Bardo Wolf

Es funktioniert weder die automatische Vorauswahl "Start opsi bootimage" noch das Übernehmen von konfigurierten Parametern (Siehe Screenshots). Werden die Parameter manuell eingetragen, erscheint logischerweise die Meldung, dass der Client bereits bekannt ist.

Liegt der Client beim Starten der Installation auf dem Config-Server, tritt dieses Verhalten nicht auf.

Grüße
MAF

Hi,

das Verhalten ist in der Tat sehr komisch. Könntest du das Loglevel vom opsipxeconfd erhöhen und erneut den Auszug aus dem Log schicken sobald du den Client auf setup setzt?

Gruß
Mathias

Leider sehe ich keinen Eintrag im Log trotz höchstem Loglevel, wenn ich den Client auf Setup setze.
Weder im opsiconfd Webinterface noch im opsi-configed-Client.

Grüße
MAF.