/etc/resolv.conf is broken when it's an absolute symbolic link on the host #187
Comments
|
Yeah, that wouldn't work. We could bind mount /run too or switch to using the What does |
like the resolved documentation mentions. |
|
So, Ubuntu uses systemd-resolved since 16.04. |
|
I think the best way forward is to switch the However, I'd like to wait a bit longer for flatpak/flatpak#2916 to be more widely installed, to avoid having some unintended fallout. Ultimately, Toolbox's primary use-case is Silverblue, and it doesn't use systemd-resolved, so it's better to lean in favour of it. |
flatpak/flatpak#2916 was introduced in Flatpak 1.4.0, which is too new for Fedora 29. So we need to wait until Fedora 29 is end-of-life:d before we make this change. |
debarshiray
changed the title
Since this date is approaching is there any work on this? Its a bit of a problem to simply not work with many configurations... EDIT: Seems like you can modify toolbox to use |
|
Seems to work with /run/host/monitor/resolv.conf. I set the link stopped the box and started again. The link remained intact. |
Closed
|
I can confirm @fansari's results with @TingPing's work around. I'm running Fedora 31 Workstation, |
|
When will this issue been fixed? I have now again created directory /run/host/monitor (which does not exist on Fedora 31) removed the NetworkManager link and place the resolv.conf there. toolbox should work with NetworkManager without this issue. |
|
Can't add custom DNS servers to |
|
The problem is that in Fedora 31 The I found this Workaround: |
|
I sent a fix for that in PR #380 a while ago. |
|
I tested #380 and it works great for me with Thanks |
|
I have created a toolbox for Fedora 32 Silverblue and again ran into the same issue. |
|
I'm running into this issue right now with Fedora 31 WS that has been upgraded since 24 I think. So it'd be nice, if someone could merge Martin's PR 380. The best software is worthless, if it only creates more problems. |
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
|
Just making sure we stay on top of it :) |
|
This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1785244 as well. |
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
Umm... not quite. I suppose, what you meant is that on Fedora 31 hosts,
However, due to an old (or passing?) NetworkManager bug, Fedora systems that have undergone a series of upgrades from one release to another for a good few years can end up with |
|
An update about the impending By default, Fedora will ship This situation is an illustration of the benefits of a relative symbolic link. It ensures that the link continues to resolve properly even when the prefix or the root is changed. So, if you need a quick solution that works with Toolbox as it's shipping today, I'd suggest switching to a relative symbolic link on your systems. What doesn't work, and we need to fix, are absolute symbolic links. ie., a |
debarshiray
changed the title
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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
HarryMichal
added a commit
to HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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 HarryMichal/toolbox
that referenced
this issue
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
debarshiray
added a commit
to debarshiray/toolbox
that referenced
this issue
Nov 18, 2024
Some Arch Linux hosts have /etc/resolv.conf as an absolute symbolic link to /run/systemd/resolve/stub-resolv.conf, instead of being a relative symbolic link to ../run/systemd/resolve/stub-resolv.conf or a regular file. eg., the images built by arch-boxes [1]. This changes the target that the Toolbx container's /etc/resolv.conf points at and confuses the tests [2]. Ideally, these host operating systems should be fixed to use relative symbolic links. This is highlighted by skipping the tests, because there's no point in failing them until that happens. This is a step towards running the CI on Arch Linux. [1] https://gitlab.archlinux.org/archlinux/arch-boxes https://geo.mirror.pkgbuild.com/images/latest/ [2] Commit 88a95b0 containers@88a95b07af335be2 containers#187 containers#1438
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd-resolved has you symlink
/etc/resolv.confto some other location (under/run/systemd/resolve). When the host volume /etc is mounted, this location of course does not exist, so all hostname access within the container fails.The text was updated successfully, but these errors were encountered: