Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

mpice-mn
Beiträge: 6
Registriert: 01 Nov 2017, 18:08

Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

Beitragvon mpice-mn » 12 Mär 2018, 16:15

Hallo, bei uns kommt es ab und zu mal vor, dass sich ein Paket nicht installieren lässt, mit folgendem Fehler:

Code: Alles auswählen

root@opsi-server# opsi-product-updater -v
[...]
     ==>>> Failed to get metadata from package '/var/lib/opsi/repository/dfn_blender_2.79a-1.opsi': Failed to extract archive '/tmp/.opsi.unpack.GRNj4/OPSI/OPSI.cpio.gz': Command '/usr/bin/pigz -cd "/tmp/.opsi.unpack.GRNj4/OPSI/OPSI.cpio.gz" | /bin/cpio --quiet -idumv ' failed with code 2: : Invalid argument
preinst
control
/bin/cpio: postinst: Cannot change ownership to uid 216408, gid 992: Invalid argument
postinst

Das Problem ist, dass unsere Server-Umgebung im Filesystem keine hohen UIDs unterstützt (max. 2^16, eine Limitierung von LXD-Containern). Der Package-Maintainer hat aber offenbar einen User mit UID 216408 benutzt.

Lösung könnte sein, beim cpio-Aufruf ein "--no-preserve-owner" mitzugeben. Habe dazu auch von einiger Zeit schonmal einen Pull-Request auf Github erstellt: https://github.com/opsi-org/python-opsi/pull/1/files

Nach einem Update von python-opsi (per apt-get) ist das Problem bei mir gerade wieder aufgetreten, deshalb hier nochmal der Hinweis im Forum. ;)

Benutzeravatar
n.wenselowski
Beiträge: 2815
Registriert: 04 Apr 2013, 12:15

Re: Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

Beitragvon n.wenselowski » 19 Mär 2018, 15:46

Hi,

mpice-mn hat geschrieben:Hallo, bei uns kommt es ab und zu mal vor, dass sich ein Paket nicht installieren lässt, mit folgendem Fehler:

Code: Alles auswählen

root@opsi-server# opsi-product-updater -v
[...]
     ==>>> Failed to get metadata from package '/var/lib/opsi/repository/dfn_blender_2.79a-1.opsi': Failed to extract archive '/tmp/.opsi.unpack.GRNj4/OPSI/OPSI.cpio.gz': Command '/usr/bin/pigz -cd "/tmp/.opsi.unpack.GRNj4/OPSI/OPSI.cpio.gz" | /bin/cpio --quiet -idumv ' failed with code 2: : Invalid argument
preinst
control
/bin/cpio: postinst: Cannot change ownership to uid 216408, gid 992: Invalid argument
postinst

Das Problem ist, dass unsere Server-Umgebung im Filesystem keine hohen UIDs unterstützt (max. 2^16, eine Limitierung von LXD-Containern). Der Package-Maintainer hat aber offenbar einen User mit UID 216408 benutzt.

Lösung könnte sein, beim cpio-Aufruf ein "--no-preserve-owner" mitzugeben. Habe dazu auch von einiger Zeit schonmal einen Pull-Request auf Github erstellt: https://github.com/opsi-org/python-opsi/pull/1/files

Sorry, das ist tatsächlich untergegangen.

Klappt der Schalter denn bei allen von opsi unterstützen Distris bzw. ab welcher Version von cpio kann der Befehl eingesetzt werden?
Und, weil der Traceback oben so ausführlich ist, verschwindet das Problem mit pigz dadurch auch oder ist das noch ein Fehler an anderer Stelle?


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.

mpice-mn
Beiträge: 6
Registriert: 01 Nov 2017, 18:08

Re: Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

Beitragvon mpice-mn » 20 Mär 2018, 18:06

n.wenselowski hat geschrieben:Klappt der Schalter denn bei allen von opsi unterstützen Distris bzw. ab welcher Version von cpio kann der Befehl eingesetzt werden?

Die älteste Version von cpio die ich auf gnu.org finden konnte (v2.5.90 vom 16. September 2004), hat sie schon. Und durch die "--quiet"-Option hab ich schon eine Abhängigkeit zur GNU-Version. Sollte also in allen Distributionen drin sein.
n.wenselowski hat geschrieben:verschwindet das Problem mit pigz dadurch auch oder ist das noch ein Fehler an anderer Stelle?

Mit pigz ist alles OK. Der Fehler wurde da nur zusammen mit pigz ausgegeben weil das halt noch vor der Pipe steht.

Nachdem ich mich jetzt noch etwas damit beschäftig habe, kommt mir das eher wie ein Symptom eines anderen Problems vor:
Der oben beschriebene Fehler tritt nur auf, wenn opsi-product-updater als root läuft. (Ich weiß, sollte man nicht machen, aber ich hatte es warscheinlich irgendwann so als cronjob eingerichtet.)
Mit einem unprivilegiertem User funktionierts. Ist auch klar, nur als root hat cpio die Rechte, den Owner einer Datei beliebig zu setzen.

H̶a̶b̶ ̶a̶l̶s̶o̶ ̶m̶a̶l̶ ̶w̶e̶i̶t̶e̶r̶ ̶g̶e̶s̶c̶h̶a̶u̶t̶,̶ ̶u̶n̶d̶ ̶o̶f̶f̶e̶n̶b̶a̶r̶ ̶w̶e̶r̶d̶e̶n̶ ̶p̶r̶e̶i̶n̶s̶t̶/̶p̶o̶s̶t̶i̶n̶s̶t̶-̶S̶c̶r̶i̶p̶t̶e̶ ̶d̶a̶n̶n̶ ̶a̶u̶c̶h̶ ̶a̶l̶s̶ ̶r̶o̶o̶t̶ ̶a̶u̶s̶g̶e̶f̶ü̶h̶r̶t̶!̶ ̶D̶a̶s̶ ̶h̶a̶l̶t̶e̶ ̶i̶c̶h̶ ̶f̶ü̶r̶ ̶s̶e̶h̶r̶ ̶g̶e̶f̶ä̶h̶r̶l̶i̶c̶h̶,̶ ̶d̶a̶ ̶m̶a̶n̶ ̶k̶e̶i̶n̶e̶ ̶K̶o̶n̶t̶r̶o̶l̶l̶e̶ ̶d̶a̶r̶ü̶b̶e̶r̶ ̶h̶a̶t̶ ̶w̶e̶n̶n̶ ̶m̶a̶n̶ ̶s̶i̶c̶h̶ ̶P̶a̶k̶e̶t̶ ̶a̶u̶s̶ ̶i̶r̶g̶e̶n̶d̶w̶e̶l̶c̶h̶e̶n̶ ̶ö̶f̶f̶e̶n̶t̶l̶i̶c̶h̶e̶n̶ ̶R̶e̶p̶o̶s̶i̶t̶o̶r̶i̶e̶s̶ ̶h̶o̶l̶t̶.̶ ̶A̶l̶s̶o̶ ̶i̶c̶h̶ ̶v̶e̶r̶t̶r̶a̶u̶e̶ ̶d̶e̶n̶ ̶P̶a̶k̶e̶t̶-̶B̶a̶u̶e̶r̶n̶ ̶s̶c̶h̶o̶n̶ ̶i̶n̶ ̶g̶e̶w̶i̶s̶s̶e̶m̶ ̶M̶a̶ß̶e̶,̶ ̶a̶b̶e̶r̶ ̶d̶o̶c̶h̶ ̶n̶i̶c̶h̶t̶ ̶s̶o̶w̶e̶i̶t̶ ̶d̶a̶s̶s̶ ̶i̶c̶h̶ ̶i̶h̶n̶e̶n̶ ̶r̶o̶o̶t̶-̶Z̶u̶g̶r̶i̶f̶f̶ ̶a̶u̶f̶ ̶m̶e̶i̶n̶e̶n̶ ̶S̶e̶r̶v̶e̶r̶ ̶g̶e̶b̶e̶n̶ ̶w̶ü̶r̶d̶e̶.̶ ̶R̶e̶i̶c̶h̶t̶ ̶s̶c̶h̶o̶n̶ ̶d̶a̶s̶s̶ ̶s̶i̶e̶ ̶q̶u̶a̶s̶i̶ ̶A̶d̶m̶i̶n̶-̶R̶e̶c̶h̶t̶e̶ ̶a̶u̶f̶ ̶a̶l̶l̶e̶n̶ ̶C̶l̶i̶e̶n̶t̶s̶ ̶h̶a̶b̶e̶n̶.̶ ̶;̶)̶ ̶

V̶i̶e̶l̶l̶e̶i̶c̶h̶ ̶s̶o̶l̶l̶t̶e̶ ̶m̶a̶n̶ ̶e̶i̶n̶e̶ ̶W̶a̶r̶n̶u̶n̶g̶ ̶a̶u̶s̶g̶e̶b̶e̶n̶ ̶u̶n̶d̶ ̶a̶b̶b̶r̶e̶c̶h̶e̶n̶ ̶w̶e̶n̶n̶ ̶o̶p̶s̶i̶-̶p̶r̶o̶d̶u̶c̶t̶-̶u̶p̶d̶a̶t̶e̶r̶ ̶/̶ ̶o̶p̶s̶i̶-̶p̶a̶c̶k̶a̶g̶e̶-̶m̶a̶n̶a̶g̶e̶r̶ ̶a̶l̶s̶ ̶r̶o̶o̶t̶ ̶l̶a̶u̶f̶e̶n̶.̶ ̶O̶d̶e̶r̶ ̶d̶i̶r̶e̶k̶t̶ ̶o̶r̶d̶e̶n̶t̶l̶i̶c̶h̶e̶ ̶P̶r̶i̶v̶i̶l̶e̶g̶e̶-̶s̶e̶p̶a̶r̶a̶t̶i̶o̶n̶ ̶e̶i̶n̶b̶a̶u̶e̶n̶ ̶u̶n̶d̶ ̶d̶i̶e̶ ̶S̶k̶r̶i̶p̶t̶e̶ ̶z̶.̶B̶.̶ ̶n̶u̶r̶ ̶a̶l̶s̶ ̶U̶s̶e̶r̶ ̶o̶p̶s̶i̶c̶o̶n̶f̶d̶ ̶o̶d̶e̶r̶ ̶p̶c̶p̶a̶t̶c̶h̶ ̶l̶a̶u̶f̶e̶n̶ ̶l̶a̶s̶s̶e̶n̶?̶ ̶D̶a̶s̶ ̶k̶l̶i̶n̶g̶t̶ ̶n̶a̶t̶ú̶r̶l̶i̶c̶h̶ ̶d̶e̶u̶t̶l̶i̶c̶h̶ ̶k̶o̶m̶p̶l̶i̶z̶i̶e̶r̶t̶e̶r̶.̶ ̶V̶i̶e̶l̶l̶e̶i̶c̶h̶t̶ ̶e̶i̶n̶ ̶P̶r̶o̶j̶e̶k̶t̶ ̶f̶ü̶r̶ ̶O̶P̶S̶I̶ ̶4̶.̶2̶.̶
Zuletzt geändert von mpice-mn am 26 Mär 2018, 13:11, insgesamt 1-mal geändert.

mpice-mn
Beiträge: 6
Registriert: 01 Nov 2017, 18:08

Re: Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

Beitragvon mpice-mn » 26 Mär 2018, 13:01

Oh, sieht so aus als würden die preinst/postinst-Scripts doch schon als "opsiconfd" ausgeführt, nicht als root. Dann nehme ich alles Gemecker aus dem vorigen Post zurück! ;)

Habe die Stelle im Code noch nicht gefunden, an der das passiert, aber es wäre doch dann sicher einfach, das Entpacken auch als User "opsiconfd" auszuführen?

Benutzeravatar
n.wenselowski
Beiträge: 2815
Registriert: 04 Apr 2013, 12:15

Re: Fehler bei Installation/Update von Paketen auf dem Server (cpio ownership problem)

Beitragvon n.wenselowski » 07 Aug 2018, 14:17

Hi,

mpice-mn hat geschrieben:Habe die Stelle im Code noch nicht gefunden, an der das passiert, aber es wäre doch dann sicher einfach, das Entpacken auch als User "opsiconfd" auszuführen?

Ist das Paket hochgeladen, so wird dazu die Funktion depot_installPackage aufgerufen.

Ich war da in anderem Zusammenhang in letzter Zeit mal zugange und habe auch am Entpacken etwas geändert: dort werden longopts verwendet (besser lesbar) und dabei habe ich das mit --no-preserve-owner auch gleich eingebaut. Das ist enthalten in python-opsi 4.1.1.42 (aktuell in experimental) oder neuer. Ich würde mich über Feedback freuen!


Gruß

Niko
Kein Support per DM!
_________________________
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.