Fix DNS queries in images with systemd-resolved on hosts without it#1425
Conversation
debarshiray
force-pushed
the
wip/rishi/issues-1410
branch
from
623f4e4 to
5777312
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 6m 46s |
debarshiray
changed the title
debarshiray
force-pushed
the
wip/rishi/issues-1410
branch
2 times, most recently
from
e6fbc82 to
97d9ce3
Compare
|
Build failed. ✔️ unit-test SUCCESS in 6m 51s |
|
Cool, the tests do fail if I had replaced |
debarshiray
force-pushed
the
wip/rishi/issues-1410
branch
2 times, most recently
from
79967d3 to
47aafa8
Compare
|
Build succeeded. ✔️ unit-test SUCCESS in 7m 04s |
On some Toolbx images with systemd-resolved(8), like the fedora-toolbox
images for Fedora 39 onwards, /etc/resolv.conf can end up being a
symbolic link inside the container that expects the host operating
system to also use systemd-resolved(8):
$ ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 39 Nov 28 08:50 /etc/resolv.conf ->
../run/systemd/resolve/stub-resolv.conf
This happens because systemd-resolved(8) already makes /etc/resolv.conf
a symbolic link inside the image, and, hence, the container's entry
point doesn't change it to point at the host's copy of the file at
/run/host/etc/resolv.conf. Instead, it's left pointing at the host's
copy of the files maintained by systemd-resolved(8) under
/run/systemd/resolve, which happen to be also available inside the
container [1].
If the host OS doesn't use systemd-resolved(8), like Red Hat Enterprise
Linux 9, then this leads to a dangling symbolic link and breaks DNS
queries.
Note that the presence of systemd-resolved(8) in the recent
fedora-toolbox images is a regression caused by the ToolbxReleaseBlocker
Change [2] for Fedora 39 where the image was rewritten in terms of
fedora-kickstarts and pungi-fedora instead of a Container/Dockerfile.
By mistake, systemd crept in as an RPM needed by the image [3], which
in turn pulled in the systemd-resolved RPM as a weak dependency [4].
Hopefully, that will get fixed. However, it's also not practical to
keep track of all the Toolbx images out there in the wild, so it's
wise to make toolbox(1) more resilient to such things.
This will have the downside of overwriting some custom user-made
modifications to the container's /etc/resolv.conf. While that's
unfortunate, it's more important to have Toolbx images produce working
containers on a wide range of host OSes. It will be better to come up
with a more explicit way to support custom user-made modifications to
the container's configuration. Perhaps with a persistent stamp file.
[1] Commit af602c7
containers@af602c7d227617d2
containers#707
[2] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker
[3] fedora-kickstarts commit 48e2c3b5598de32f
https://pagure.io/fedora-kickstarts/c/48e2c3b5598de32f
[4] fedora-kickstarts commit 49306cb6eada8777
https://pagure.io/fedora-kickstarts/c/49306cb6eada8777
containers#1410
debarshiray
force-pushed
the
wip/rishi/issues-1410
branch
from
47aafa8 to
9289c2d
Compare
debarshiray
changed the title
|
Build succeeded. ✔️ unit-test SUCCESS in 6m 51s |
1 participant
On some Toolbx images with
systemd-resolved(8), like thefedora-toolboximages for Fedora 39 onwards,
/etc/resolv.confcan end up being asymbolic link inside the container that expects the host operating
system to also use
systemd-resolved(8):This happens because
systemd-resolved(8)already makes/etc/resolv.confa symbolic link inside the image, and, hence, the container's entry
point doesn't change it to point at the host's copy of the file at
/run/host/etc/resolv.conf. Instead, it's left pointing at the host'scopy of the files maintained by
systemd-resolved(8)under/run/systemd/resolve, which happen to be also available inside thecontainer [1].
If the host OS doesn't use
systemd-resolved(8), like Red Hat EnterpriseLinux 9, then this leads to a dangling symbolic link and breaks DNS
queries.
Note that the presence of
systemd-resolved(8)in the recentfedora-toolboximages is a regression caused by the ToolbxReleaseBlockerChange [2] for Fedora 39 where the image was rewritten in terms of
fedora-kickstartsandpungi-fedorainstead of a Container/Dockerfile.By mistake,
systemdcrept in as an RPM needed by the image [3], whichin turn pulled in the
systemd-resolvedRPM as a weak dependency [4].Hopefully, that will get fixed. However, it's also not practical to
keep track of all the Toolbx images out there in the wild, so it's
wise to make
toolbox(1)more resilient to such things.This will have the downside of overwriting some custom user-made
modifications to the container's
/etc/resolv.conf. While that'sunfortunate, it's more important to have Toolbx images produce working
containers on a wide range of host OSes. It will be better to come up
with a more explicit way to support custom user-made modifications to
the container's configuration. Perhaps with a persistent stamp file.
[1] Commit af602c7
af602c7d227617d2
#707
[2] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker
[3] fedora-kickstarts commit 48e2c3b5598de32f
https://pagure.io/fedora-kickstarts/c/48e2c3b5598de32f
[4] fedora-kickstarts commit 49306cb6eada8777
https://pagure.io/fedora-kickstarts/c/49306cb6eada8777
#1410