fix: ensure systemd-resolved is set by default #344
Conversation
dosubot
bot
added
size:XS
build_scripts/40-services.sh
Outdated
| # Resolved by default as DNS resolver | ||
| ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf |
There was a problem hiding this comment.
Is it best to symlink this here, or via tmpfiles?
Is /etc/resolv.conf something the user may want to change?
This may be perfectly fine - I'm just not sure of any implications of symlinking via the container build if the user wants to update the config file
I guess it should be fine - the symlink will just mean the changes on a running system are accessible in /run/systemd/..?
There was a problem hiding this comment.
Probably here, if there is any /etc/resolv.conf file there by default it doesnt get replaced by networkmanager or tailscale. We can iterate on this later if for whatever reason this breaks
There was a problem hiding this comment.
I agree it should be here (or some similarly appropriate location in the Container build). It should not be in tmpfiles since tmpfiles may override a user's change, but doing it here we default to the desired behavior (using systemd-resolved's stub config) but anyone can modify this.
There was a problem hiding this comment.
We probably should change this symlink however...
ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf is how this is configured on Fedora
|
|
why? |
|
@bsherman When we build stuff, |
I thought it would be something like this. I'm quite strongly opposed to the use of It may work to follow the lead of systemd-resolved itself...
That should work for DNS lookups from within container, and create the symlink pointing to the desired location. |
…n modify it later
dosubot
bot
added
size:S
| # Necessary so that we get DNS resolution when podman build --dns none is specified | ||
| # FIXME: Maybe figure out some better solution for this | ||
| cp -f /etc/resolv-host.conf /etc/resolv.conf | ||
| cat /etc/resolv.conf |
There was a problem hiding this comment.
@tulilirockz I think you've confirmed this approach is working, correct?
There was a problem hiding this comment.
Works locally, but github actions hates it.
There was a problem hiding this comment.
Because it seems to be mounting a systemd resolved stub: https://github.com/ublue-os/bluefin-lts/actions/runs/13571468379/job/37937333918?pr=344#step:7:157
There was a problem hiding this comment.
Not sure why this would work locally unless you aren't using systemd-resolved on your local build host.
There was a problem hiding this comment.
Because it seems to be mounting a systemd resolved stub: ublue-os/bluefin-lts/actions/runs/13571468379/job/37937333918?pr=344#step:7:157
It being a stub doesnt seem like it matters? Thats what my /etc/resolv.conf looks like. I think that just binding the resolv.conf from the host like that wont work, as not specifying a dns flag seems to create an entirely new resolv file. It at the very least seems to strip out comments
There was a problem hiding this comment.
I think that just binding the resolv.conf from the host like that wont work, as not specifying a
dnsflag seems to create an entirely new resolv file.
This is my point, I think the podman dns feature is doing more than copying the host's /etc/resolv.conf, which your comment agrees with since you see comments removed, etc.
The problem is the stub resolv.conf tells anything using glibc's nss to lookup addr by name to use IP 127.0.0.53 which is specially created on the host by systemd-resolved. That IP is not accessible in the container.
I don't have time to dive in as I'm about to catch a flight.
If this bug is a significant blocker and you have a tmpfiles.d solution, I think it's worth trying that. But I would appreciate an issue filed for me to work on an improvement when I become available again.
Fixes: #246