Support /etc/resolv.conf symlinks on the host#380
Closed
martinpitt wants to merge 1 commit intocontainers:masterfrom
martinpitt:resolv-conf-link
Closed
Support /etc/resolv.conf symlinks on the host#380martinpitt wants to merge 1 commit intocontainers:masterfrom martinpitt:resolv-conf-link
martinpitt wants to merge 1 commit intocontainers:masterfrom
martinpitt:resolv-conf-link
Conversation
Contributor
Author
|
I tested this with /etc/resolv.conf being a plain file and a symlink to /run/NetworkManager/resolv.conf (my usual configuration, to avoid writing to /etc), and it now behaves correctly in both cases. Before that, networking was always broken by default, and I had to apply a hack. I didn't go with letting it point to /run/host/monitor/resolv.conf though, as that's just a bind-mount from the host's flatpak helper and I'd rather not introduce this assumption/dependency to resolv.conf handling. |
|
Build succeeded.
|
Contributor
Author
|
Argh, the |
|
Build failed.
|
Contributor
Author
|
I can't look into that podman-rawhide failure (the logs are private or require logging in, etc?), but I don't think it's something that I caused. The previous version (with the leftover debug |
|
I looked into that a bit as well. I'm guessing only a 'member' of the project can kick the job off again. You might ask @debarshiray for access. |
If /etc/resolv.conf is already a symlink on the host [1], fix the link target in toolbox to the corresponding /run/host/<original target>. https://bugzilla.redhat.com/show_bug.cgi?id=1785244 [1] It's common to point it to /run/NetworkManager/resolv.conf or /run/systemd/resolve/resolv.conf #380
Contributor
Author
|
I force-pushed to trigger the job again, but I suppose it's rather some change/regression with podman itself in rawhide. |
Member
|
Hi, @martinpitt! Seems like there's a problem with Zuul itself because the playbook won't even start. The other tests seem to be ok. |
|
Build failed.
|
|
recheck |
|
Build failed.
|
|
recheck |
|
Build succeeded.
|
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
May 27, 2020
There has been a long standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. Second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. Then the function tries first to find the file before it creates the link. Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
May 27, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. Then the function tries first to find the file before it creates the link. Based on: containers#380 [0] containers#187
Contributor
Author
|
FTR, the exact same issue applies to the Go rewrite, but now of course this PR does not apply any more. |
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Jul 23, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. Then the function tries first to find the file before it creates the link. Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Jul 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. The function looks for the links in the chain under /run/host where the host's filesystem is available. Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 11, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. The function looks for the links in the chain under /run/host where the host's filesystem is available. Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 13, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. The function looks for the links in the chain under /run/host where the host's filesystem is available. Relative symlinks are handled by this. Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 13, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. There are many ways how to go about it. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. The function looks for the links in the chain under /run/host where the host's filesystem is available. Relative symlinks are handled by this (thanks Tudor Roman!). Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 19, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and updating the target path. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink and if it is, it's target will be set as the new target. This is repeated if the new target is also a symlink. The function looks for the links in the chain under /run/host where the host's filesystem is available. Relative symlinks are handled by this (thanks Tudor Roman!). Based on: containers#380 [0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 19, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf
to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were
proposed. Hardcode other paths, where the file could be, completely rely
on tools like flatpak-session-helper that will track such files in a
single directory, or update the symlinking function to follow symlinks
and update the target path.
The first solution is the easiest short-term but not very good
long-term. The second solution is possibly the best long-term but there
is a problem with using flatpak-session-helper. It cannot be used as
root. That leaves the third option, follow symlinks and update the
target path if the target is an invalid symlink.
This commit takes the third approach to solve the issue. Now the target
of the symlinking is first tested if it is a symlink. If it's not then
the symlinking is done right away. If it's a symlink then it is resolved.
When the target is valid, symlinking proceeds normally. If it it's not
then symlinking still proceeds but in two different ways depending on
target being an absolute or a relative symlink:
- absolute - target is prepended with /run/host (the target may not be
invalid)
- relative - target is not changed (the target will be invalid)
This commit tries to rely on well-made relative symlinks. Those behave
correctly even when they are placed in a different prefix (in Toolbox's
case under /run/host).
Thanks Tudor Roman for raising concern about relative links.
Based on: containers#380
[0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 19, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf
to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were
proposed. Hardcode other paths, where the file could be, completely rely
on tools like flatpak-session-helper that will track such files in a
single directory, or update the symlinking function to follow symlinks
and update the target path.
The first solution is the easiest short-term but not very good
long-term. The second solution is possibly the best long-term but there
is a problem with using flatpak-session-helper. It cannot be used as
root. That leaves the third option, follow symlinks and update the
target path if the target is an invalid symlink.
This commit takes the third approach to solve the issue. Now the target
of the symlinking is first tested if it is a symlink. If it's not then
the symlinking is done right away. If it's a symlink then it is resolved.
When the target is valid, symlinking proceeds normally. If it it's not
then symlinking still proceeds but in two different ways depending on
target being an absolute or a relative symlink:
- absolute - target is prepended with /run/host (the target may not be
invalid)
- relative - target is not changed (the target will be invalid)
This commit tries to rely on well-made relative symlinks. Those behave
correctly even when they are placed in a different prefix (in Toolbox's
case under /run/host).
Thanks Tudor Roman for raising concern about relative links.
Based on: containers#380
[0] containers#187
martymichal
added a commit
to martymichal/toolbox
that referenced
this pull request
Aug 19, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 27, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
There has been a long-standing issue[0] when symlinking /etc/resolv.conf to /run/host/etc/resolv.conf (host's resolv.conf). Many solutions were proposed. Hardcode other paths, where the file could be, completely rely on tools like flatpak-session-helper that will track such files in a single directory, or update the symlinking function to follow symlinks and update the target path. [0] containers#187 The first solution is the easiest short-term but not very good long-term. The second solution is possibly the best long-term but there is a problem with using flatpak-session-helper. It cannot be used as root. That leaves the third option, follow symlinks and update the target path if the target is an invalid symlink. This commit takes the third approach to solve the issue. Now the target of the symlinking is first tested if it is a symlink. If it's not then the symlinking is done right away. If it's a symlink then it is resolved. When the target is valid, symlinking proceeds normally. If it it's not then symlinking still proceeds but in two different ways depending on target being an absolute or a relative symlink: - absolute - target is prepended with /run/host (the target may not be invalid) - relative - target is not changed (the target will be invalid) This commit tries to rely on well-made relative symlinks. Those behave correctly even when they are placed in a different prefix (in Toolbox's case under /run/host). Thanks Tudor Roman for raising concern about relative links. Based on: containers#380 containers#460
debarshiray
pushed a commit
to martymichal/toolbox
that referenced
this pull request
Aug 28, 2020
Currently toolbox containers can get misconfigured if some configuration files on the host are absolute symbolic links to some other location. For example, when systemd-resolved is used to manage /etc/resolv.conf on the host, and if the file is an absolute link to /run/systemd/resolve/stub-resolv.conf, then /etc/resolv.conf ends up being invalid inside the container. This happens because the container's /etc/resolv.conf points to /run/host/etc/resolv.conf, which in turn points to /run/systemd/resolve/stub-resolv.conf, but that's absent from the container. This is, of course, not a problem with relative symbolic links. If the host had a relative link to ../run/systemd/resolve/stub-resolv.conf, then it would continue to work inside the container. One solution would have been to use flatpak-session-helper to maintain a copy of the host's /etc/resolv.conf in $XDG_RUNTIME_DIR/.flatpak-helper/monitor. However, that doesn't work when toolbox(1) is run as root. The other option is to prepend the destination of the absolute symbolic link with /run/host to make it resolve inside the container. It might not work with funky links, but it's enough for the common case where a an administrator changed the host's /etc/resolv.conf into a sane, but absolute, symbolic link. Properly configured hosts should anyway use relative symbolic links, because they don't need to be adjusted in such scenarios. That's also what Fedora and Ubuntu do, by default. Thanks to Tudor Roman for raising a concern about relative symbolic links. Based on Martin Pitt's work on the POSIX shell implementation: containers#380 containers#187
Member
|
@HarryMichal ported this to the Go implementation in #460 Thanks for pursuing this @martinpitt ! Much appreciated, and my apologies for the delay in getting to it. |
Member
Yes, I agree. We do currently use |
Contributor
Author
|
Thanks @debarshiray ! Glad to see that this is fixed at last. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
If /etc/resolv.conf is already a symlink on the host [1], fix the link
target in toolbox to the corresponding /run/host/.
https://bugzilla.redhat.com/show_bug.cgi?id=1785244
[1] It's common to point it to /run/NetworkManager/resolv.conf or
/run/systemd/resolve/resolv.conf