Update von opsi-linux-client-agent überschreibt opsi-rclone und verhindert weitere Aktionen
Verfasst: 25 Aug 2026, 14:57
Hallo,
beim Update des opsi-linux-client-agent (4.3.22.7-1) ist mir aufgefallen, dass dieser sich quasi selber "den Teppich unter den Füßen wegzieht", wenn man diesen über den opsi-configed auf einem Client aktualisiert. Passieren tut das beim Installationsschritt "ShellInAnIcon_install_rclone", da hier einfach das Binary für opsi-rclone im laufenden Betrieb ausgetauscht wird. Bisher ist mir das nicht aufgefallen, da das wohl einfach noch nie in den Worst Case gelaufen ist. Das erfolgreiche Überschreiben einer in Benutzung befindlichen Datei scheint wohl abhängig vom Kernel zu sein.
Bislang hatten wir in unserer Flotte nur Geräte mit AlmaLinux 9.8 (Kernel 5.14.0-687.10.1.el9_8.x86_64) im Einsatz. Hier "funktionierte" das Update des Client Agents immer, aber bei genauerem Blick ins Log sehe ich nun, dass dort folgendes steht:
Offenbar verhindert der Kernel das Überschreiben von opsi-rclone und damit Schlimmeres.
Auf neueren Geräten mit AlmaLinux 10.2 (Kernel 6.12.0-211.49.1.el10_2.x86_64) steht im Log hingegen folgendes:
Hier kann opsi-rclone scheinbar "erfolgreich" überschrieben werden, aber nur bis zu dem Punkt, wo der cp-Befehl im Setup-Skript aufgerufen wird. In dem Moment wird das Binary gelöscht (es ist danach 0 Byte groß), die rclone-Verbindung wird sofort terminiert und es funktionieren keinerlei Installationen/Updates mehr. Im opsiclientd.log sieht man dazu dann folgendes (die Zeitstempel sind andere, da ich das Log gerade von einem anderen System nehmen muss):
Weitere Aktionen scheitern dann an dem IndexError, der daraus resultiert, dass durch das kaputte opsi-rclone-Binary kein Passwort mehr für die rclone-Verbindung erstellt wird. Sofern noch eine Verbindung zum Client hergestellt werden kann, hilft danach bspw. nur noch das manuelle Rüberkopieren des opsi-rclone Binaries und das temporäre Auskommentieren von "ShellInAnIcon_install_rclone" im Setup-Skript, um das Update des Client Agents zum Abschluss zu bringen.
Ist das so beabsichtigt und nutze ich hier den falschen Update-Weg oder sollte diese Stelle vielleicht im Setup robuster ausgeführt sein? Es ist ja etwas ungünstig, wenn das Setup ebendas Binary versucht zu überschreiben, mit dem es gerade eine Verbindung zum OPSI-Depot herstellt. Ein dauerhaftes Auskommentieren/Ausschließen dieser Code-Zeile stellt ja auch keine Option dar, weil ja sonst die Erstinstallationen nicht versorgt würden.
Über eine Rückmeldung hierzu und ob dieses Verhalten vielleicht abstellbar ist wäre ich sehr dankbar.
Viele Grüße
Edit:
Das Verhalten kann auf betroffenen Systemen (also mit Kernel, der beim Überschreiben von opsi-rclone kein ETXTBSY zurückgibt) immer wieder provoziert werden, indem die angeforderte Aktion für opsi-linux-client-agent einfach auf "Setup" gestellt wird.
beim Update des opsi-linux-client-agent (4.3.22.7-1) ist mir aufgefallen, dass dieser sich quasi selber "den Teppich unter den Füßen wegzieht", wenn man diesen über den opsi-configed auf einem Client aktualisiert. Passieren tut das beim Installationsschritt "ShellInAnIcon_install_rclone", da hier einfach das Binary für opsi-rclone im laufenden Betrieb ausgetauscht wird. Bisher ist mir das nicht aufgefallen, da das wohl einfach noch nie in den Worst Case gelaufen ist. Das erfolgreiche Überschreiben einer in Benutzung befindlichen Datei scheint wohl abhängig vom Kernel zu sein.
Bislang hatten wir in unserer Flotte nur Geräte mit AlmaLinux 9.8 (Kernel 5.14.0-687.10.1.el9_8.x86_64) im Einsatz. Hier "funktionierte" das Update des Client Agents immer, aber bei genauerem Blick ins Log sehe ich nun, dass dort folgendes steht:
Code: Alles auswählen
[5] [2026-08-25 12:59:53.195] [opsi-linux-client-agent] comment: Installing rclone (as opsi-rclone).
[5] [2026-08-25 12:59:53.195] [opsi-linux-client-agent] Execution of: ShellInAnIcon_install_rclone
[7] [2026-08-25 12:59:53.195] [opsi-linux-client-agent] Executing /bin/bash /tmp/_opsiscript_h11p76YBuN.cmd
[6] [2026-08-25 12:59:53.296] [opsi-linux-client-agent] Start process as invoker: root
[6] [2026-08-25 12:59:53.296] [opsi-linux-client-agent] Started process "/bin/bash" with Opt: /tmp/_opsiscript_h11p76YBuN.cmd
[7] [2026-08-25 12:59:53.407] [opsi-linux-client-agent]
[7] [2026-08-25 12:59:53.407] [opsi-linux-client-agent] output:
[7] [2026-08-25 12:59:53.407] [opsi-linux-client-agent] --------------
[7] [2026-08-25 12:59:53.407] [opsi-linux-client-agent] cp: reguläre Datei '/usr/bin/opsi-rclone' kann nicht angelegt werden: Das Programm kann nicht ausgeführt oder verändert werden (busy)
Auf neueren Geräten mit AlmaLinux 10.2 (Kernel 6.12.0-211.49.1.el10_2.x86_64) steht im Log hingegen folgendes:
Code: Alles auswählen
[5] [2026-08-24 14:20:37.339] [opsi-linux-client-agent] comment: Installing rclone (as opsi-rclone).
[5] [2026-08-24 14:20:37.339] [opsi-linux-client-agent] Execution of: ShellInAnIcon_install_rclone
[7] [2026-08-24 14:20:37.340] [opsi-linux-client-agent] Executing /bin/bash /tmp/_opsiscript_KS992Fkuv4.cmd
[6] [2026-08-24 14:20:37.441] [opsi-linux-client-agent] Start process as invoker: root
[6] [2026-08-24 14:20:37.441] [opsi-linux-client-agent] Started process "/bin/bash" with Opt: /tmp/_opsiscript_KS992Fkuv4.cmd
[7] [2026-08-24 14:20:37.715] [opsi-linux-client-agent]
[7] [2026-08-24 14:20:37.715] [opsi-linux-client-agent] output:
[7] [2026-08-24 14:20:37.715] [opsi-linux-client-agent] --------------
[7] [2026-08-24 14:20:37.715] [opsi-linux-client-agent] cp: Fehler beim Lesen von '/media/opsi_depot/opsi-linux-client-agent/files/rclone/rclone': Der Socket ist nicht verbunden
[7] [2026-08-24 14:20:37.715] [opsi-linux-client-agent] cp: '/media/opsi_depot/opsi-linux-client-agent/files/rclone/rclone' konnte nicht geschlossen werden: Der Socket ist nicht verbunden
Code: Alles auswählen
[6] [2026-08-24 20:29:29.275] [event processing on_demand{user_logged_in}] Setting config depot_server.depot_id to 'xxxxxxxxxxxxxxxxxxxxxxx' (Config.py:535)
[6] [2026-08-24 20:29:29.275] [event processing on_demand{user_logged_in}] Setting config depot_server.url to 'webdavs://xxxxxxxxxxxxxxxxxxxxxxx' (Config.py:535)
[5] [2026-08-24 20:29:29.275] [event processing on_demand{user_logged_in}] Mounting depot share webdavs://xxxxxxxxxxxxxxxxxxxxxxx' (EventProcessing.py:471)
[6] [2026-08-24 20:29:29.276] [event processing on_demand{user_logged_in}] Executing: /usr/bin/opsi-rclone obscure - (Posix.py:939)
[6] [2026-08-24 20:29:29.277] [event processing on_demand{user_logged_in}] Using encoding 'UTF-8' (Posix.py:981)
[3] [2026-08-24 20:29:29.282] [event processing on_demand{user_logged_in}] Failed to mount depot share: list index out of range (EventProcessing.py:534)
[3] [2026-08-24 20:29:29.292] [event processing on_demand{user_logged_in}] Failed to process product action requests: list index out of range (EventProcessing.py:1069)
Traceback (most recent call last):
File "opsiclientd/EventProcessing.py", line 1034, in processProductActionRequests
File "opsiclientd/EventProcessing.py", line 1179, in runActions
File "opsiclientd/EventProcessing.py", line 543, in mountDepotShare
File "opsiclientd/EventProcessing.py", line 532, in mountDepotShare
File "OPSI/System/Linux.py", line 363, in mount
File "OPSI/System/Linux.py", line 283, in rclone_mount
IndexError: list index out of range
Ist das so beabsichtigt und nutze ich hier den falschen Update-Weg oder sollte diese Stelle vielleicht im Setup robuster ausgeführt sein? Es ist ja etwas ungünstig, wenn das Setup ebendas Binary versucht zu überschreiben, mit dem es gerade eine Verbindung zum OPSI-Depot herstellt. Ein dauerhaftes Auskommentieren/Ausschließen dieser Code-Zeile stellt ja auch keine Option dar, weil ja sonst die Erstinstallationen nicht versorgt würden.
Über eine Rückmeldung hierzu und ob dieses Verhalten vielleicht abstellbar ist wäre ich sehr dankbar.
Viele Grüße
Edit:
Das Verhalten kann auf betroffenen Systemen (also mit Kernel, der beim Überschreiben von opsi-rclone kein ETXTBSY zurückgibt) immer wieder provoziert werden, indem die angeforderte Aktion für opsi-linux-client-agent einfach auf "Setup" gestellt wird.