Toolbox: /etc/resolv.conf ist defekt, wenn es sich um einen absoluten symbolischen Link auf dem Host handelt

Erstellt am 7. Juni 2019  ·  19Kommentare  ·  Quelle: containers/toolbox

systemd-resolved weist Sie /etc/resolv.conf mit einem anderen Ort (unter /run/systemd/resolve ) an. Wenn das Host-Volume /etc gemountet ist, existiert dieser Speicherort natürlich nicht, sodass jeglicher Zugriff auf den Hostnamen innerhalb des Containers fehlschlägt.

1. Bug

Hilfreichster Kommentar

Ich habe vor einiger Zeit in PR #380 einen Fix dafür geschickt.

Alle 19 Kommentare

Ja, das würde nicht funktionieren. Wir könnten auch mount /run binden oder auf die flatpak-spawn gepflegten Kopien umsteigen.

Was zeigt ls -l /etc/resolv.conf auf dem Host an? Könnten Sie bitte die Ausgabe hier einfügen?

lrwxrwxrwx. 1 root root 32 Jun  6 13:23 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

wie die aufgelöste Dokumentation erwähnt .

Ich denke, der beste Weg ist, den symbolischen Link /etc/resolv.conf auf die Kopie zu ändern, die von flatpak-session-helper bei /run/host/monitor/resolv.conf .

Ich würde jedoch gerne etwas länger warten, bis https://github.com/flatpak/flatpak/pull/2916 breiter installiert ist, um unbeabsichtigte Auswirkungen zu vermeiden. Letztendlich ist der Hauptanwendungsfall von Toolbox Silverblue, und es verwendet nicht systemd-resolved, daher ist es besser, sich darauf zu stützen.

Ich würde gerne etwas länger auf flatpak/flatpak#2916 warten
breiter installiert werden, um einen unbeabsichtigten Fallout zu vermeiden.
Letztendlich ist der Hauptanwendungsfall von Toolbox Silverblue, und es wird nicht verwendet
systemd-resolved, also ist es besser, sich dafür zu lehnen.

https://github.com/flatpak/flatpak/pull/2916 wurde in Flatpak 1.4.0 eingeführt , die für Fedora 29 zu neu ist also wir warten müssen , bis Fedora 29 End-of ist das Leben: d , bevor wir machen dieser Wandel.

Wir müssen also warten, bis Fedora 29 das End- of -

Da dieses Datum näher rückt, gibt es diesbezüglich irgendwelche Arbeiten? Es ist ein bisschen ein Problem, mit vielen Konfigurationen einfach nicht zu arbeiten ...

BEARBEITEN: Anscheinend können Sie die Toolbox so ändern, dass sie /run/host/monitor/resolv.conf anstelle von /run/host/etc/resolv.conf .

Scheint mit /run/host/monitor/resolv.conf zu funktionieren. Ich habe den Link gesetzt, die Box gestoppt und wieder gestartet. Der Link blieb erhalten.

Ich kann die Ergebnisse von @fansari mit Workaround bestätigen. Ich verwende Fedora 31 Workstation, toolbox-0.0.17-1.fc31.src.rpm , podman-1.6.2-2.fc31.src.rpm und registry.fedoraproject.org/f31/fedora-toolbox 31 a198bc8c3cda 4 weeks ago 448 MB und habe dieses Problem. Lassen Sie es mich wissen, wenn ich weitere Details zur Verfügung stellen kann, um das Problem zu lösen (kein Wortspiel beabsichtigt).

Wann wird dieses Problem behoben? Ich habe jetzt wieder das Verzeichnis /run/host/monitor erstellt (das es auf Fedora 31 nicht gibt), den NetworkManager-Link entfernt und die resolv.conf dort abgelegt.

Toolbox sollte mit NetworkManager ohne dieses Problem funktionieren.

Benutzerdefinierte DNS-Server können aus der Toolbox nicht zu /etc/resolv.conf hinzugefügt werden. Ich musste es kopieren, trennen und zurückkopieren.

Das Problem ist, dass in Fedora 31 /etc/resolv.conf ein symbolischer Link zu /run/host/etc/resolv.conf der wiederum ein symbolischer Link zu /var/run/NetworkManager/resolv.conf ist. Diese Datei existiert nicht im Container, da sie nicht verwendet wird Netzwerk Manager.

Das Image registry.fedoraproject.org/f31/fedora-toolbox:31 muss korrigiert werden, um dieses Problem zu vermeiden.

Ich habe diesen Workaround gefunden:

⬢[ichavero<strong i="12">@toolbox</strong> ~]$ sudo -i
sudo: setrlimit(RLIMIT_CORE): Operation not permitted
⬢[root<strong i="13">@toolbox</strong> ~]# ping google.com
ping: google.com: Name or service not known
⬢[root<strong i="14">@toolbox</strong> ~]# mkdir /var/run/NetworkManager
⬢[root<strong i="15">@toolbox</strong> ~]# echo "nameserver 192.168.1.254" > /var/run/NetworkManager/resolv.conf
⬢[root<strong i="16">@toolbox</strong> ~]# ping -c2 google.com
PING google.com (216.58.217.14) 56(84) bytes of data.
64 bytes from qro02s15-in-f14.1e100.net (216.58.217.14): icmp_seq=1 ttl=57 time=6.74 ms
64 bytes from qro02s15-in-f14.1e100.net (216.58.217.14): icmp_seq=2 ttl=57 time=5.63 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.632/6.187/6.742/0.555 ms
⬢[root<strong i="17">@toolbox</strong> ~]# 

Ich habe vor einiger Zeit in PR #380 einen Fix dafür geschickt.

Ich habe #380 getestet und es funktioniert großartig für mich mit systemd-resolved .

Vielen Dank

Ich habe eine Toolbox für Fedora 32 Silverblue erstellt und bin wieder auf das gleiche Problem gestoßen.
Der einzige schnelle Workaround war wieder den Link /etc/resolv.conf zu entfernen und auf /run/host/monitor.resolv.conf zu setzen.

Ich stoße gerade auf dieses Problem mit Fedora 31 WS, das seit 24 aktualisiert wurde, glaube ich. Es wäre also schön, wenn jemand Martins PR 380 zusammenführen könnte. Die beste Software ist wertlos, wenn sie nur noch mehr Probleme macht.

Stellen Sie nur sicher, dass wir den Überblick behalten :)
Fedora zielt darauf ab, systemd-resolved standardmäßig in Fedora 33 zu aktivieren ( Link ).

Das Problem ist, dass in Fedora 31 /etc/resolv.conf ein Symlink zu . ist
/run/host/etc/resolv.conf was wiederum ein Symlink zu . ist
/var/run/NetworkManager/resolv.conf , diese Datei existiert nicht in
den Container, da er NetworkManager nicht verwendet.

Ähm... nicht ganz.

Ich nehme an, was Sie meinten, ist, dass auf Fedora 31-Hosts /etc/resolv.conf ein symbolischer Link zu /run/NetworkManager/resolv.conf (weil /var/run ein symbolischer Link zu /run ) .

/etc/resolv.conf ist nicht als symbolischer Link auf Fedora-Hosts vor Fedora 33 gedacht. Ab Fedora 33 wird es von systemd-resolved und wird tatsächlich ein symbolischer Link sein. Sie können dies überprüfen, indem Sie ein Fedora < 33-System von Grund auf in einer virtuellen Maschine oder so installieren.

Aufgrund eines alten (oder vorübergehenden?) NetworkManager- Fehlers können Fedora-Systeme, die seit einigen Jahren eine Reihe von Upgrades von einer Version auf eine andere durchlaufen haben, jedoch dazu führen, dass /etc/resolv.conf ein symbolischer Link ist, wie Sie bereits erwähnt haben .

Ein Update zur bevorstehenden systemd-resolved Änderung in Fedora 33 .

Standardmäßig liefert Fedora /etc/resolv.conf als relativen symbolischen Link zu ../run/systemd/resolve/stub-resolv.conf , ebenso Ubuntu. Dies funktioniert bereits seit Toolbox 0.0.14 wegen Commit d63b0a9c0f1cd8a137ebc818b297f3b9303b5c32

Diese Situation veranschaulicht die Vorteile einer relativen symbolischen Verbindung. Es stellt sicher, dass der Link auch dann ordnungsgemäß aufgelöst wird, wenn das Präfix oder die Wurzel geändert wird.

Wenn Sie also eine schnelle Lösung benötigen, die mit Toolbox funktioniert, wie es heute ausgeliefert wird, würde ich vorschlagen, auf Ihren Systemen zu einem relativen symbolischen Link zu wechseln.

Was nicht funktioniert und wir beheben müssen, sind absolute symbolische Links. dh ein /etc/resolv.conf , das mit /run/systemd/resolve/stub-resolv.conf verknüpft ist.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen