Upload von Paketen in abgesetzte Depots schlägt fehl

[feltel]

Ich möchte hier mal einen Bug melden, der bereits in viewtopic.php?t=15054 gemeldet wurde, aber ggf. überlesen wurde. Mit den aktuellen OPSI-Paketversionen mindestens mal auf einem Debian-Hostsystem kann man keine OPSI-Pakete mehr auf Depots pushen. Das schlägt exemplarisch mit ff. Meldung fehl:

Code: Alles auswählen

[5] [2026-04-13 09:47:15.327] [               ] Calculating delta for depot 'rigel.verw.nz.docemus.net'   (opsipackagemanager.py:990)
[6] [2026-04-13 09:47:15.327] [               ] 'tempDir'   (opsipackagemanager.py:1100)
Traceback (most recent call last):
  File "opsiutils/opsipackagemanager.py", line 1003, in uploadToRepository
KeyError: 'tempDir'
[3] [2026-04-13 09:47:15.329] [               ] 'tempDir'   (opsipackagemanager.py:1101)
[3] [2026-04-13 09:47:15.330] [               ] 'tempDir'   (opsipackagemanager.py:101)
Traceback (most recent call last):
  File "opsiutils/opsipackagemanager.py", line 99, in start
  File "opsiutils/opsipackagemanager.py", line 1003, in uploadToRepository
KeyError: 'tempDir'
[3] [2026-04-13 09:47:15.332] [               ] Task 'Upload of package '/var/lib/opsi/workbench/microsoft-edge/microsoft-edge_147.0.3912.60-1.opsi' to repository 'rigel.verw.nz.docemus.net'' failed: 'tempDir'   (opsipackagemanager.py:593)
[5] [2026-04-13 09:47:15.332] [               ] Upload task failed, skipping install task   (opsipackagemanager.py:597)

Betroffen sind opsi-package-manager als auch der Package Builder. Das zeitgesteuerte Paket-Pull von den Depots aus klappt. Unsere OPSI-Server laufen auf Debian 13 mit den ff. Paketständen:

Code: Alles auswählen

feltel@nova:~$ dpkg -l|grep opsi
rc  opsi-atftpd                          0.7.dfsg-7                              amd64        advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                        4.0.7.6.34-2                            all          OPSI config editor
ii  opsi-linux-bootimage                 20260220-1                              all          Linux-based bootimage for OPSI
ii  opsi-server                          4.3.5.3-1                               all          opsi server
ii  opsi-tftpd-hpa                       5.2.9-4                                 amd64        HPA's tftp server
ii  opsi-utils                           4.3.26.3-1                              amd64        Utilities for working with opsi
ii  opsiconfd                            4.3.50.7-1                              amd64        OPSI configuration service
ii  opsipxeconfd                         4.3.15.2-1                              amd64        OPSI PXE Configuration Service
rc  python-opsi                          4.1.1.101-1                             all          opsi python library

[JakobCGN]

laut der Info ist bei euch opsi-utils_4.3.26.3-1 installiert

der Fix dafür findet sich in opsi-utils 4.3.26.5 aktuell in testing und experimental

Info: viewtopic.php?p=64440#p64440
*tritt das Problem mit dieser opsi-utils Version 4.3.26.5 trotzdem auf?

[feltel]

Hab den Fix eben auch im Github gefunden: https://github.com/opsi-org/opsi-utils/ ... 1921826a05
Die gefixte Version von opsi-utils probier ich mal aus.

[feltel]

Wenn ich das Deb-File auf meinem Haupt-Configserver aufspiele, dann läuft danach der opsi-package-manager nicht mehr.

Code: Alles auswählen

[PYI-2353377:ERROR] Failed to load Python shared library '/usr/lib/opsi-utils/_internal/libpython3.13.so.1.0': /usr/lib/opsi-utils/_internal/libpython3.13.so.1.0: cannot enable executable stack as shared object requires: Invalid argument

[JakobCGN]

kannst du folgendes mit der testing und ggfls. danach mit der stable opsi-utils Version testen?
Installation via opsi-cli statt opsi-package-manager? Ähnliche Probleme hatten in ferner und naher Vergangenheit meine Kollegen aus anderen Abteilungen manchmal auch, aber mit der opsi-cli Methode gings bei denen. Ich kann es heute aus zeitlichen Gründen nicht selbst testen.

Code: Alles auswählen

opsi-cli package install --depots depotXY.intranet.local /home/software/firefox_987.x.y.z-1.opsi

Edit:
die Versionen (in diesem Fall opsi-utils) sollten auf beiden Servern (configserver und depot xy) identisch sein. Also so gehe ich immer vor, um ein Problem mit der Diskrepanz zw. den Versionen auszuschließen.

[JakobCGN]

Mein Testergebnis (wollte es unbedingt selbst testen, da es mich brennend interessiert hat, bevor sich meine Kollegen auch bei mir mit einem Problem via Ticket melden): war erfolgreich

Testablauf:
#getestet mit folgenden Versionen (dieselbe Versionen auf beiden Servern: configserver und depot xy)
opsiconfd_4.3.50.7-1
opsi-utils_4.3.26.5-1

#Paket swaudit genommen
#Umgebung: opsi App 4.3 von Univention auf UCS@School 5.2 Servern
#beide .deb Pakete via wget von hier aus genommen: https://download.opensuse.org/repositor ... 5.2/amd64/

#vom configserver aus
opsi-package-manager -d depotXY.local.intranet -r swaudit
opsi-package-manager -d depotXY.local.intranet -i swaudit_4.3.2.0-1.opsi

opsi-cli package uninstall --depots depotXY.local.intranet swaudit
opsi-cli package install --depots depotXY.local.intranet /var/lib/opsi/workbench/swaudit_4.3.2.0-1.opsi

#lokal auf dem depot
opsi-package-manager -r swaudit
opsi-package-manager -i swaudit_4.3.2.0-1.opsi

opsi-cli package uninstall --depots depotXY.local.intranet swaudit
opsi-cli package install --depots depotXY.local.intranet /var/lib/opsi/workbench/swaudit_4.3.2.0-1.opsi

[j.schneider]

Bitte einmal die neue Version 4.3.26.6 der opsi-utils versuchen:

https://download.opensuse.org/repositor ... _amd64.deb

[JakobCGN]

*auch wenn die Anfrage an das Debian 13 System gerichtet war:
erfolgreich getestet in unserer UCS Umgebung

[feltel]

Bitte einmal die neue Version 4.3.26.6 der opsi-utils versuchen:

https://download.opensuse.org/repositor ... _amd64.deb

Danke. Damit läuft der opsi-package-manager wieder und der Upload klappt auch wieder.
Kleine Sache noch. Wenn ich (aus versehen) das Binary ohne Argumente aufrufe, dann kommen noch Python-Fehler:

Code: Alles auswählen

feltel@nova:~$ opsi-package-manager 
[3] [2026-04-13 16:57:04.060] [               ] No command specified   (opsipackagemanager.py:2093)
Traceback (most recent call last):
  File "opsiutils/opsipackagemanager.py", line 2089, in main
  File "opsiutils/opsipackagemanager.py", line 1561, in __init__
  File "opsiutils/opsipackagemanager.py", line 1996, in setCommandlineConfig
ValueError: No command specified

ERROR: No command specified

Ist nur Optik und ich weiß auch nicht, ob das vielleicht vorher schon so war.

Vielen Dank für den Fix.