Also bind mount systemd-resolved /run directories #707
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hasn't yet been gone through end-to-end testing. |
|
Build failed.
|
Since systemd >= 247, systemd-resolved offers a Varlink interface over the socket at /run/systemd/resolve/io.systemd.Resolve. containers#707
debarshiray
force-pushed
the
systemd-resolved-varlink
branch
from
cd973b3 to
af602c7
Compare
|
Build succeeded.
|
|
Thanks for working on this, @nanonyme ! |
|
Retroactively this should fix https://bugzilla.redhat.com/show_bug.cgi?id=1933433 for programs using glibc NSS in F34 toolbox. |
debarshiray
added a commit
to debarshiray/toolbox
that referenced
this pull request
Dec 18, 2023
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 to 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
added a commit
to debarshiray/toolbox
that referenced
this pull request
Dec 18, 2023
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This directory structure contains in distros that have systemd247
or higher (eg F34) systemd-resolved varlink socket which toolbox
guest can use