On Mi, 15.04.20 13:27, Daniel J Walsh (dwalsh(a)redhat.com) wrote:
> If a container manager copies in /etc/resolv.conf from the host
into
> the container on container *start*, it might be wise to copy in
> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
> exists. That file in /run contains the currently up-to-date upstream
> DNS info literally.
Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
they can modify it internally,
It looks like podman will just follow the link. I setup this simple test
# ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
# cat /etc/resolv.conf
# Generated by NetworkManager
search
redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
# podman run fedora cat /etc/resolv.conf
search
redhat.com
nameserver 10.5.30.160
nameserver 10.11.5.19
nameserver 192.168.1.1
So as long as the
/run/systemd/resolve/resolv.conf
file is properly formated, our container engines will just work.
Yes, /run/systemd/resolve/resolv.conf is properly formatted, the way
glibc expects it. It only contains IPv4 + IPv6 "nameserver" stanzas as
well as "search" stanzas.
The files systemd-resolved generates there look something like this:
```
nameserver 172.31.0.1
nameserver fd00::3a10:d5ff:fe78:6bbe
search fritz.box
```
(with some additional explanatory comments at the top, which I
stripped here)
Key is to access it under its proper path instead of via the symlink,
for the aforementioned reasons.
Lennart
--
Lennart Poettering, Berlin