Toolbox: /etc/resolv.confは、ホスト上の絶対シンボリックリンクである場合に壊れます

ええ、それはうまくいきません。 mount / runもバインドするか、 flatpak-spawn維持されているコピーを使用するように切り替えることができます。

ls -l /etc/resolv.confはホストに何を表示しますか？ ここに出力を貼り付けていただけますか？

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

解決されたドキュメントが言及しているように。

そのため、 Ubuntuは16.04以降

/etc/resolv.confシンボリックリンクをflatpak-session-helperが/run/host/monitor/resolv.conf管理しているコピーに切り替えるのが最善の方法だと思います。

ただし、意図しないフォールアウトが発生しないように、 https：//github.com/flatpak/flatpak/pull/2916がより広くインストールされるまでもう少し待ちたいと思い

flatpak / flatpak＃2916を
意図しない放射性降下物が発生しないように、より広くインストールする必要があります。
最終的に、Toolboxの主なユースケースはSilverblueであり、使用しません
systemd-resolvedなので、それを支持する方が良いでしょう。

https://github.com/flatpak/flatpak/pull/2916はFlatpak1.4.0で導入されましたが、これはFedora 29には新しすぎます。したがって、Fedora 29が終了するまで待つ必要があります：d作成する前にこの変更。

したがって、この変更を行う前に、Fedora 29がサポート終了になるまで待つ必要があります：d 。

この日付が近づいているので、これに関する作業はありますか？ 多くの構成で機能しないのは少し問題です...

編集： /run/host/monitor/resolv.conf代わりに/run/host/etc/resolv.conf /run/host/monitor/resolv.confを使用するようにツールボックスを変更できるようです。

/run/host/monitor/resolv.confで動作するようです。 リンクを設定してボックスを停止し、再開しました。 リンクはそのまま残りました。

私の周りの仕事@fansari「@TingPingとの結果」を確認することができます。 私はFedora31ワークステーション、 toolbox-0.0.17-1.fc31.src.rpm 、 podman-1.6.2-2.fc31.src.rpm 、およびregistry.fedoraproject.org/f31/fedora-toolbox 31 a198bc8c3cda 4 weeks ago 448 MBを実行していますが、この問題が発生しています。 これを解決するのに役立つ他の詳細を提供できるかどうか教えてください（しゃれは意図されていません）。

この問題はいつ修正されますか？ ディレクトリ/ run / host / monitor（Fedora 31には存在しません）を再度作成し、NetworkManagerリンクを削除して、そこにresolv.confを配置しました。

ツールボックスは、この問題なしでNetworkManagerで動作するはずです。

ツールボックスから/etc/resolv.confカスタムDNSサーバーを追加できません。 私はそれをコピーし、リンクを解除してコピーし直さなければなりませんでした。

問題は、Fedora 31では/etc/resolv.confが/run/host/etc/resolv.confへのシンボリックリンクであり、これが/var/run/NetworkManager/resolv.confへのシンボリックリンクであり、このファイルは使用しないため、コンテナーに存在しないことです。ネットワーク管理者。

この問題を回避するには、 registry.fedoraproject.org/f31/fedora-toolbox:31イメージを修正する必要があります。

私はこの回避策を見つけました：

⬢[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> ~]# 

少し前にPR＃380でその修正を送信しました。

＃380をテストしましたが、 systemd-resolvedでうまく機能します。

ありがとう

Fedora 32 Silverblueのツールボックスを作成しましたが、同じ問題が発生しました。
簡単な回避策は、リンク/etc/resolv.confを削除し、それを/run/host/monitor.resolv.confに設定することだけでした。

私は今、24からアップグレードされたFedora 31WSでこの問題に直面していると思います。 ですから、誰かがマーティンのPR 380をマージできれば、それは素晴らしいことです。それがより多くの問題を引き起こすだけなら、最高のソフトウェアは無価値です。

その上にいることを確認してください:)
Fedoraは、Fedora 33でデフォルトでsystemd-resolvedを有効にすることを目指しています（リンク）。

これはhttps://bugzilla.redhat.com/show_bug.cgi?id=1785244でも追跡されています。

問題は、Fedora 31では/etc/resolv.confがへのシンボリックリンクであるということです
/run/host/etc/resolv.confこれはへのシンボリックリンクです
/var/run/NetworkManager/resolv.conf 、このファイルはに存在しません
NetworkManagerを使用しないため、コンテナ。

うーん...そうではありません。

おそらく、Fedora 31ホストでは、 /etc/resolv.confは/run/NetworkManager/resolv.confへのシンボリックリンクです（ /var/runは/runへのシンボリックリンクであるため） 。

/etc/resolv.confは、Fedora 33より前のFedoraホスト上のシンボリックリンクを意味するものではありません。Fedora33以降は、 systemd-resolvedによって管理され、実際にシンボリックリンクになります。 Fedora <33システムを仮想マシンなどに最初からインストールすることで、それを確認できます。

ただし、古い（または合格した？）NetworkManagerのバグが原因で、あるリリースから別のリリースへの一連のアップグレードを数年間受けたFedoraシステムは、あなたが言及したように、 /etc/resolv.confがシンボリックリンクになる可能性があります。 。

Fedora 33で差し迫ったsystemd-resolved変更に関する更新。

デフォルトでは、Fedoraは/etc/resolv.confを../run/systemd/resolve/stub-resolv.confへの相対シンボリックリンクとして出荷し、Ubuntuも同様です。 コミットd63b0a9c0f1cd8a137ebc818b297f3b9303b5c32のため、これはToolbox0.0.14以降すでに機能しています。

この状況は、相対的なシンボリックリンクの利点を示しています。 これにより、プレフィックスまたはルートが変更された場合でも、リンクが適切に解決され続けることが保証されます。

したがって、今日出荷されているToolboxで機能する迅速なソリューションが必要な場合は、システム上の相対的なシンボリックリンクに切り替えることをお勧めします。

動作せず、修正する必要があるのは、絶対シンボリックリンクです。 つまり、 /etc/resolv.confにリンクする/run/systemd/resolve/stub-resolv.confです。