hwinvent schlägt fehl: Clients hängen sich auf oder brechen mit Fehler ab

[ThomasG]

Hallo Community,

ich habe einen opsi-4.3-Server auf Debian 13 Trixie aufgesetzt und unserer Domäne hinzugefügt, um mir die Neuinstallation von 8 Rechnern mit Windows 11 bzw. der Alternative Mint 22 zu erleichtern.
Die Benutzer 'opsiconfd' und 'adminuser' sind als Domänenbenutzer angelegt, sowie 'opsiadmin' und 'opsifileadmins' als domänenlokale Gruppen.
Der User 'pcpatch' ist als lokaler Benutzer auf dem opsi-Server angelegt und ist Mitglied der domänenlokalen Gruppe 'opsifileadmins'.

Als erstes wollte ich mit der Hardware-Inventarisierung unserer Clients beginnen, jedoch hängen sich alle Rechner nach dem Booten von 'hwinvent' entweder auf (Lenovo) oder brechen mit einer Fehlermeldung ab (alle anderen). Bei der Fehlersuche, mit 'journalctl -u opsi-tftpd-hpa.service -f' auf dem opsi-Server, geht es bis zum Punkt '/opsi/opsi-linux-bootimage/miniroot-x64' und dann ist Schluss:

Code: Alles auswählen

root@My-opsi-srv:/var/log/opsi# journalctl -u opsi-tftpd-hpa.service -f
Sep 17 19:43:50 My-opsi-srv in.tftpd[1598]: RRQ from 192.168.110.106 filename opsi/opsi-linux-bootimage/loader/opsi-netboot.bios
Sep 17 19:43:50 My-opsi-srv in.tftpd[1598]: tftp: client does not accept options
Sep 17 19:43:50 My-opsi-srv in.tftpd[1599]: RRQ from 192.168.110.106 filename opsi/opsi-linux-bootimage/loader/opsi-netboot.bios
Sep 17 19:43:51 My-opsi-srv in.tftpd[1600]: RRQ from 192.168.110.106 filename opsi/opsi-linux-bootimage/cfg/grub.cfg
Sep 17 19:43:51 My-opsi-srv in.tftpd[1601]: RRQ from 192.168.110.106 filename /opsi/opsi-linux-bootimage/cfg/grub-settings.cfg
Sep 17 19:43:52 My-opsi-srv in.tftpd[1603]: RRQ from 192.168.110.106 filename opsi/opsi-linux-bootimage/cfg/7bcf2f80-6053-11dc-adf0-a468903fca44
Sep 17 19:43:52 My-opsi-srv in.tftpd[1603]: sending NAK (1, File not found) to 192.168.110.106
Sep 17 19:43:52 My-opsi-srv in.tftpd[1604]: RRQ from 192.168.110.106 filename opsi/opsi-linux-bootimage/cfg/01-00-1a-6b-51-01-31
Sep 17 19:43:52 My-opsi-srv in.tftpd[1605]: RRQ from 192.168.110.106 filename /opsi/opsi-linux-bootimage/install-x64
Sep 17 19:43:58 My-opsi-srv in.tftpd[1611]: RRQ from 192.168.110.106 filename /opsi/opsi-linux-bootimage/miniroot-x64

Die Clients bleiben entweder hängen (Lenovo) - im Bildschirm mit dem OPSI-Logo und den darunter durchlaufenden Sechsecken bzw. nach 'ESC' mit der Bootmeldung

Code: Alles auswählen

...
(ok) Started opsi.service - Job that starts the opsi opsimain script.
(ok) Reached target multi-user.target - multi-user System.

oder sie schaffen es bis zum violetten Bildschirm und enden dort mit der Fehlermeldung:

Code: Alles auswählen

RuntimeError('Failed to mount \'//my-opsi-srv.my-domain.tld/opsi_depot\': Command \'/bin/mount -t cifs -o
"iocharset=utf8,vers=3,noserverino,credentials=/tmp/tmprnc1trki" //my-opsi-srv.my-domain.tld/opsi_depot /mnt/opsi\' failed (32):\n mount
Error(13): Permission denied\n Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)\n')

Im opsi-Boot-Log

bootimage.log

(331.84 KiB) 9-mal heruntergeladen

kann ich leider keinen Hinweis finden, warum hier ein 'Permission denied' kommt bzw. welche User-Credentials er unter '/tmp/tmpoqtfg6tw' sucht.
'opsiconfd setup' habe ich ausgeführt, 'opsi-set-rights' ebenfalls, das Passwort von 'pcpatch' zurückgesetzt und auch die Passwörter von 'opsiconfd' und 'adminuser' von ausgefallenen Sonderzeichen befreit, hat alles nichts gebracht.

Der Health-Check beschwert sich übrigens über Trixie:

Code: Alles auswählen

- Version 13 of distribution debian is not supported.
- System and opsi repositories are incompatible. System 'debian 13' using repository: https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.3:/stable/Debian_13

sollte aber nichts ausmachen.
Hat jemand eine Idee, wo der Fehler liegen könnte?

Danke schon mal im Voraus!
Thomas

[n.doerrer]

Moin,

tritt das Problem auch mit dem aktuellen opsi-linux-bootimage auf?
Die credentials, die da zum mounten verwendet werden, müssten user "pcpatch" und das dazugehörige Passwort sein, welches vom server abgefragt wird.
Vielleicht hilft es, das pcpatch-Passwort neu zu setzen

Code: Alles auswählen

opsiconfd setup --set-depot-user-password

[ThomasG]

Genau das gleiche, es hat sich leider nichts geändert. Auch nach nochmaligem Neusetzen des pcpatch-Passworts nicht. Daran kann's eigentlich auch nicht liegen, wie man weiter unten sieht.
Der Lenovo mit UEFI bleibt im Boot-Bildschirm mit den Sechsecken als Ladeanzeige hängen. (Hierzu habe ich im Forum bereits einen Thread gesehen.)
Der Lenovo mit BIOS verhält sich wie alle anderen Clients und zwar wie folgt:

Mit der Linux-Boot-Iso, auf USB-Stick gezogen, kam ich zu dem violetten Bildschirm, auf dem ich die IP-Adressen und Rechnername eingeben kann.
Auf die anschließende Frage nach dem 'Host-Schlüssel' habe ich zwei Möglichkeiten: 'Einmal-Passwort'=Host-Key oder 'Admin-Zugang' z.B. opsiconfd + PW oder anderer Admin + PW.
Beide Möglichkeiten habe ich mehrmals mit unterschiedlichen Anmeldedaten ausprobiert.
Im Anschluss kann ich das Netboot-Produkt auswählen, und das war's dann, hier ist Ende.

Zuerst habe ich mich gefragt, ob ich die falsche Schreibweise, also z.B. 'Domäne\Benutzername' oder 'Benutzername@Domäne' oder nur 'Benutzername' verwendet habe, aber das hat sich so geklärt:
Bei falscher Schreibweise oder ungültigen/erfundenen Login-Credentials beschwert er sich artig mit einem 'authentication error'.
Bei korrekten Anmeldedaten kommt der RuntimeError:

Code: Alles auswählen

RuntimeError('Failed to mount \'//my-opsi-srv.my-domain.tld/opsi_depot\': Command \'/bin/mount -t cifs -o
"iocharset=utf8,vers=3,noserverino,credentials=/tmp/tmprnc1trki" //my-opsi-srv.my-domain.tld/opsi_depot /mnt/opsi\' failed (32):\n mount
Error(13): Permission denied\n Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)\n')

Das heißt bei richtigen Anmeldedaten kommt 'Permission denied'.
Hier endet derzeit noch mein Latein...

[ThomasG]

PS: noch was, was die Lösungsfindung nicht einfacher macht:
Die Logs löschen sich schon nach wenigen Minuten wieder. Hier muss man schnell sein und sich die Dateien rauskopieren, bevor sie wieder leer sind.
Kann eigentlich nicht sein, ich habe an Logrotate nichts geändert und die Einstellungen dazu auch noch mal überprüft, daran kann's eigentlich nicht liegen... Trixie-Bug? Weil es scheint alle Logs zu betreffen, nicht nur die von opsi.
Vielleicht hat hierzu jemand ne Idee?

[ThomasG]

PS: noch was, was die Lösungsfindung nicht einfacher macht:
Die Logs löschen sich schon nach wenigen Minuten wieder. Hier muss man schnell sein und sich die Dateien rauskopieren, bevor sie wieder leer sind.
Kann eigentlich nicht sein, ich habe an Logrotate nichts geändert und die Einstellungen dazu auch noch mal überprüft, daran kann's eigentlich nicht liegen... Trixie-Bug? Weil es scheint alle Logs zu betreffen, nicht nur die von opsi.
Vielleicht hat hierzu jemand ne Idee?

Beim nochmaligen Kontrollieren der Logrotate-Patterns bin ich auf etwas gestoßen:
In den Patterns sind der Benutzer 'opsiconfd' und die Gruppe 'opsiadmin' hart kodiert.
Die Domänengruppen habe ich aber anders benannt und in der Datei '/etc/opsi/opsi.conf' entsprechend angepasst, damit ich testweise schnell zwischen Domänen-Admingruppen und lokalen Admingruppen umschalten kann.

Wenn die Gruppennamen jedoch noch in anderen config-Files hart kodiert drin stecken, dann kann das zu ungewöhnlichem Verhalten des opsi-Servers führen.
Oder werden die anderen config-Files über die Variablen aus '/etc/opsi/opsi.conf' gesteuert und Logrotate ist hier eine Ausnahme?

Bitte in der Dokumentation darauf hinweisen.

[ThomasG]

Das heißt bei richtigen Anmeldedaten kommt 'Permission denied'.
Hier endet derzeit noch mein Latein...

Und wo wir gerade dabei sind... habe ich bei der Thematik zur Datei '/etc/opsi/opsi.conf' einen Tippfehler in der 'opsifileadmins'-group gefunden.
Sieht so aus als sei zumindest das Eingangsproblem gelöst.
Oh Mann, und dabei habe ich die Configdateien doch alle immer noch mal korrekturgelesen vor dem Speichern!
Sorry, dass ich Euch mit einem Problem belästigt habe, das anscheinend gar keins ist.

Es grüßt euch freundlich
Thomas