HTTP-Auth beim opsi-product-updater broken

[feltel]

Ich will das hier nochmal "offiziell" als Bugreport einstellen, weil es wohl bei den Release-Ankündigungen etwas untergegangen ist. Mit dem August-Release von OPSI ist ein Bug eingeführt worden, der es verhindert, das der Product-Updater Pakete von HTTP-Passwort-geschützten Verzeichnissen updaten kann. Der Product-Updater bekommt beim ersten Versuch auf so ein Repo zuzugreifen richtigerweise vom Webserver ein HTTP/403 und müsste eigentlich den Zugriff nochmal mit Username+Password probieren, aber genau das erfolgt nicht. Das Ergebnis ist, das der Product-Updater dann abbricht und keine neuen Pakete herunterlädt.

Die Fehlermeldung sieht so aus:

Code: Alles auswählen

[6] [2025-08-27 09:52:45.695] [               ] Getting package infos from repository 'nova' (https://ein_apache_im_internet.de)   (Updater.py:1187)
[6] [2025-08-27 09:52:45.695] [               ] Opening session for repository 'nova' (https://ein_apache_im_internet.de)   (Updater.py:1362)
[6] [2025-08-27 09:52:45.695] [               ] Using proxy settings: http_proxy=None, https_proxy=None, no_proxy='*'   (__init__.py:272)
[7] [2025-08-27 09:52:45.695] [               ] Initiating session with verify=False   (Updater.py:1384)
[7] [2025-08-27 09:52:45.696] [               ] Starting new HTTPS connection (1): ein_apache_im_internet.de:443   (connectionpool.py:1049)
[7] [2025-08-27 09:52:45.785] [               ] https://ein_apache_im_internet.de:443 "HEAD / HTTP/1.1" 403 0   (connectionpool.py:544)
[3] [2025-08-27 09:52:45.786] [               ] Failed to connect to repository nova: 403 -    (Updater.py:1387)
[7] [2025-08-27 09:52:45.793] [               ] https://localhost:4447 "POST /session/logout HTTP/1.1" 200 17   (connectionpool.py:544)
[3] [2025-08-27 09:52:45.795] [               ] Failed to connect to repository 'nova': 403 -    (opsipackageupdater.py:457)

Das ganze tritt sowohl mit Debian 12 als auch mit 13 auf. Die OPSI-Pakete sind auf ff. Releasestand:

Code: Alles auswählen

feltel@nebula:~$ 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            20250902-1                           all          opsi bootimage for netboot tasks.
ii  opsi-server                     4.3.5.1-1                            all          opsi server
ii  opsi-tftpd-hpa                  5.2.9-4                              amd64        HPA's tftp server
ii  opsi-utils                      4.3.17.0-1                           amd64        Utilities for working with opsi
ii  opsiconfd                       4.3.37.7-1                           amd64        opsi configuration service
ii  opsipxeconfd                    4.3.8.1-1                            amd64        opsi pxe configuration service
rc  python-opsi                     4.1.1.101-1                          all          opsi python library

Das Setup lief so seit der OPSI-Einführung vor mehr als zehn Jahren und über mehrere OPSI- und Debian-Generationen hinweg problemlos.

[SirTux]

Das Problem kann ich für uns mit dem o4i-Repository unter Ubuntu 24.04 nicht bestätigen. Vielleicht gibt es ein Problem mit eurer Config

[feltel]

Die hat sich aber dummerweise nicht geändert. Das einzig neue waren die August OPSI-Pakete.

[SirTux]

Das mag ja sein. Aber da es bei uns geht scheint das Feature nicht grundsätzlich kaputt zu sein. Insofern besteht die Möglichkeit, daß eure Config Fehlerhaft ist und es eher ein Bug war, daß es vorher funktioniert hat. Auf jeden Fall gibt es ohne weitere Informationen potentielle Schwierigkeiten den Fehler zu reproduzieren.

UIB wird dieses Feature höchstwahrscheinlich auch für ihre Abos nutzen. Insofern sollte es denen schon aufgefallen sein, wenn dort was grundsätzlich kaputt wäre.

[feltel]

Ich habe einen Ansatz. Die Updates sind bei uns in einem Unterverzeichnis, was dem Configserver entspricht. Hier "nova". Für das Verzeichnis ist auch Directory-Listing per Apache-Config zulässig. Für das übergeordnete Verzeichnis, also /, nicht. Das habe ich jetzt testweise mal dort angeknipst und schon geht der Updater wieder. Insofern ist das eine Änderung in der Funktionsweise des Updaters, die mit dem August-Update eingeführt wurde. Keine Ahnung, warum er auch im übergeordneten Verzeichnis schauen will. Hängt vielleicht mit der Änderung der HTTP-Lib zusammen. OPSI scheint hierfür jetzt python-requests/2.32.3 zu nutzen. Das ist jetzt kein Beinbruch und ich will da auch keine große Sache draus machen.

[feltel]

Nachdem der "Workaround" das Directory-Listing auch fürs übergeordnete Verzeichnis zuzulassen offenbar funktioniert, bin ich heute beim stöbern in den Changelogs auf https://changelog.opsi.org/SERVER_PACKA ... ngelog.txt

Code: Alles auswählen

## [4.3.16.1] - 2025-08-06

### Changed

- updated opsi-cli to 4.3.24.3 (doerrer <n.doerrer@uib.de>)
- checking access to baseUrl in opsi-package-updater (doerrer <n.doerrer@uib.de>)

gestoßen. Das muss mir vorher durchgerutscht sein, bzw. war es auch nicht in den Neuigkeiten verlinkt. Vielleicht kann @n.doerrer was zu sagen, warum das implementiert wurde, das Directory-Listing auch in "baseUrl" notwendig ist und nicht nur in "dirs". Da muss der Updater ja rein technisch gesehen gar nicht reinschauen.

[ewimar]

Hallo!
Vermutlich ist der Zugriff auf die baseUrl nötig, um die optionale Datei packages.json lesen zu können.
(Beispiel: https://opsipackages.43.opsi.org/stable/packages.json)
Sollte der opsi-package-updater die packages.json-Datei bei Vorhandensein als ausschließliche Quelle der Wahrheit nutzen, könnte dies den Traffic auf dem Webserver deutlich reduzieren.

Du kannst die Datei packages.json selbst erzeugen:

Code: Alles auswählen

cd <dein Basisverzeichnis>
opsi-cli manage-repo metafile create
opsi-cli manage-repo metafile scan-packages

Deiner Frage an @n.doerrer möchte ich hinzufügen:
Muss ich opsi-cli auf meinem Webserver installieren, um die packages.json-Datei erzeugen zu können, oder kann ich das auch aus der Ferne (von irgendeinem ollen opsi-Server aus) machen?

Grüße
Martin

[feltel]

Hallo!
Vermutlich ist der Zugriff auf die baseUrl nötig, um die optionale Datei packages.json lesen zu können.

Abrufen könnte er die URL ja auch ohne aktives Directory-Listing, wenn der Dateiname statisch und bekannt ist. Siehe robots.txt u.ä., ist ja das selbe Prinzip. Bekommt dann halt schlimmstenfalls ein 404 zurück und macht weiter. Jetzt fliegt der Updater halt auf die Fresse, wenn Directory-Listing dort nicht zulässig ist.

[n.doerrer]

Moin,

das ist kein Bug, siehe viewtopic.php?p=63577#p63577

[feltel]

Wie schon im anderen Topic geschrieben, danke für die Erläuterung. Für mich wars halt mit dem August-Update eine funktionale Änderung, die ich mir nicht so recht erklären konnte. Hätte ja durchaus ein Bug sein können, so wie der Updater dann auf die Nase gefallen ist.