TMPDIR in chroot nicht verwenden

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
reox
Beiträge: 2521
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

TMPDIR in chroot nicht verwenden

Beitrag von reox » 06.08.2021 17:03:05

Ich versuch gerade eine VM mit Debianvmdb2 und stable als zielsystem aufzusetzen. debootstrap rennt durch und ich kann auch ohne probleme chrooten. Aber apt mag nicht pakete installieren und sagt mir:

Code: Alles auswählen

mktemp: failed to create file via template ‘/tmp/user/0/tmp.XXXXXXXXXX’: No such file or directory
und tatsächlich, wenn ich in das image chroote und mktemp ausführe, kommt diese Fehlermeldung.
Das Problem scheint sehr einfach zu sein: /tmp/user/0 existiert nicht - tatsächlich gibt es nur /tmp.
mktemp nimmt zuerst $TMPDIR und dann /tmp und tatsächlich, in $TMPDIR ist /tmp/user/0 eingetragen.
Dies kommt wohl vom host, wo das so gesetzt wird.

Eine Lösung ist es einfach immer in der chroot zu entfernen: https://review.opendev.org/c/openstack/ ... nctions#68
Das müsste man dann wohl in vmdb2 lösen und dort eben beim chroot befehl die variable entfernen. Ich hab stattdessen jetzt als workaround /tmp/user/0 in der chroot erstellt, nachdem debootstrap fertig ist.
Hat wer noch eine bessere Idee?

edit: habs mal upstream angemerkt: https://gitlab.com/larswirzenius/vmdb2/-/issues/58

Benutzeravatar
Livingston
Beiträge: 1813
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: TMPDIR in chroot nicht verwenden

Beitrag von Livingston » 07.08.2021 16:44:07

$TMPDIR wird vermutlich durch logind gesetzt.
Es gibt sicher noch ganz andere Dinge, die Du bei einem chroot vermissen wirst. Der Grund ist, dass chroot eigentlich nix anderes macht, als eine neue Shell zu starten und das Wurzelverzeichnis neu zu setzen, es also zu "/" zu machen. Es werden keinerlei Dienste oder Daemons gestartet, kein graphisches Login bereitgestellt oder sonstwas getan.
Es werden aber die exportierten Variablen der übergeordneten shell vererbt wie u.a. auch $TMPDIR.
Wenn Du eine saubere Umgebung haben willst, kannst Du auf die Erbschaft verzichten, indem Du chroot zusammen mit env verwendest (siehe auch man pages zu diesen Befehlen):

Code: Alles auswählen

env -i chroot /dein/chrootverzeichnis [u.U. hier noch das gewünschte Kommando]
Dann sind aber auch Variablen weg, die Du vielleicht unbewusst sonst noch benutzt, z.B. $PATH oder $USER.
Eventuell reicht es in Deinem Fall ja, einzelne Variablen zu säubern:

Code: Alles auswählen

env -u TMPDIR chroot ...
Für chroot gilt immer: Alles muss man selber machen :wink:
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams

reox
Beiträge: 2521
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: TMPDIR in chroot nicht verwenden

Beitrag von reox » 07.08.2021 20:03:54

ja, TMPDIR wird durch Debianlibpam-tmpdir gesetzt. Die Frage ist nun wie Debianvmdb2 darauf reagieren sollte. Vermutlich ist es für vmdb2 eine gute idee TMPDIR und PATH neu zu setzen, da man nicht davon ausgehen kann, dass es für die chroot korrekt gesetzt wurde. Im code von vmdb2 wird das env jedenfalls kopiert, also muss sich der benutzer darum kümmern, dass vorher alles korrekt ist - richtig?

Benutzeravatar
Livingston
Beiträge: 1813
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: TMPDIR in chroot nicht verwenden

Beitrag von Livingston » 08.08.2021 01:31:40

Mit vmdb2 hab ich mich noch nicht beschäftigt, aber im Prinzip ist Deine Annahme richtig: Umgebungsvariablen solltest Du im Zusammenhang mit chroot immer unter Kontrolle halten. Schau Dir einfach mal mit

Code: Alles auswählen

# export
an, welche Variablen vererbbar sind und somit auch in der chroot-Umgebung gelten.
Du solltest auch schauen, ob Du die Variablen vor dem chroot-Aufruf veränderst/löschst (dann gilt das für die host-shell und im chroot), oder ob Du dafür lieber ein Script innerhalb des chroot-Käfig aufrufst; dann musst Du Dir in der host-Umgebung keine Gedanken mehr machen, ob dort alle Variablen das erwartete Verhalten bewirken.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams

Antworten