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 использует systemd-resolved с 16.04.

Я думаю, что лучший способ продвинуться вперед - это переключить символическую ссылку /etc/resolv.conf на копию, поддерживаемую flatpak-session-helper адресу /run/host/monitor/resolv.conf .

Однако я бы хотел немного подождать, пока https://github.com/flatpak/flatpak/pull/2916 будет более широко установлен, чтобы избежать непредвиденных последствий. В конечном счете, основным вариантом использования Toolbox является Silverblue, и он не использует systemd-resolved, поэтому лучше склониться в его пользу.

Я бы хотел подождать еще немного Flatpak / Flatpak # 2916
должны быть установлены более широко, чтобы избежать непреднамеренных выпадений.
В конечном счете, основным вариантом использования Toolbox является Silverblue, и он не использует
systemd-resolved, поэтому лучше склоняться к нему.

https://github.com/flatpak/flatpak/pull/2916 был представлен в Flatpak 1.4.0, что слишком ново для Fedora 29. Поэтому нам нужно дождаться окончания срока службы Fedora 29

Поэтому нам нужно дождаться окончания срока службы Fedora 29

Поскольку эта дата приближается, есть ли над этим работа? Это небольшая проблема - просто не работать со многими конфигурациями ...

РЕДАКТИРОВАТЬ: Похоже, вы можете изменить набор инструментов, чтобы использовать /run/host/monitor/resolv.conf вместо /run/host/etc/resolv.conf .

Кажется, работает с /run/host/monitor/resolv.conf. Я установил ссылку, остановил бокс и запустил заново. Ссылка осталась нетронутой.

Я могу подтвердить @fansari «результаты s с @TingPing» s работа вокруг. Я использую Fedora 31 Workstation, 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.

toolbox должен работать с NetworkManager без этой проблемы.

Невозможно добавить пользовательские DNS-серверы в /etc/resolv.conf из панели инструментов. Пришлось скопировать, отсоединить и скопировать обратно.

Проблема в том, что в 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.

Я столкнулся с этой проблемой прямо сейчас с Fedora 31 WS, которая была обновлена ​​с 24, я думаю. Так что было бы неплохо, если бы кто-то мог объединить PR 380 Мартина. Лучшее программное обеспечение ничего не стоит, если оно только создает больше проблем.

Просто убедитесь, что мы остаемся в курсе :)
Fedora стремится включить systemd-resolved по умолчанию в Fedora 33 ( ссылка ).

Это также отслеживается в 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 до Fedora 33. Начиная с Fedora 33 и далее , он будет управляться systemd-resolved и действительно будет символической ссылкой. Вы можете убедиться в этом, установив систему Fedora <33 с нуля на виртуальную машину или что-то в этом роде.

Однако из - за старой (или передача?) NetworkManager ошибка , Fedora системы , которые претерпели ряд обновлений с одной версии на другую в течение многих лет , может в конечном итоге с /etc/resolv.conf является символической ссылкой , как вы упоминаете .

Обновление о предстоящем изменении systemd-resolved в Fedora 33 .

По умолчанию Fedora отправляет /etc/resolv.conf как относительную символическую ссылку на ../run/systemd/resolve/stub-resolv.conf , как и Ubuntu. Это уже работает с Toolbox 0.0.14 из-за фиксации d63b0a9c0f1cd8a137ebc818b297f3b9303b5c32

Эта ситуация является иллюстрацией преимуществ относительной символической ссылки. Это гарантирует правильное разрешение ссылки даже при изменении префикса или корня.

Итак, если вам нужно быстрое решение, которое работает с Toolbox в том виде, в каком оно поставляется сегодня, я бы предложил переключиться на относительную символическую ссылку в ваших системах.

Что не работает, и нам нужно исправить, так это абсолютные символические ссылки. т.е. /etc/resolv.conf который ссылается на /run/systemd/resolve/stub-resolv.conf .