dont use resolveconf on systemd

[yuval-k]

trying to address:
#58
#50

it seems like mounting resolv.conf by default lead to failures in systemd systems.

this makes it so it is not mounted on known systemd images.
I'm open for discussion of what's the best way here. mount it on known images? add mount_ressolv boolean option? any other ideas?
cc @joshuaspence @hoshsadiq @micchickenburger

[joshuaspence]

I had a bit of a look into this. The original error in #58 is because os.Stat seems to suggest that /etc/resolv.conf doesn't exist (because it is a symlink to a path that doesn't exist), but os.MkdirAll("/etc/resolv.conf", 0755) fails. I think we can fix this by using os.Lstat instead of os.Stat.

I don't think you need to do anything with /run/systemd.

[joshuaspence]

I tried using os.Lstat instead of os.Stat but have now run into this problem: https://unix.stackexchange.com/questions/429724/how-do-i-mount-a-file-on-top-of-a-broken-symbolic-link

[yuval-k]

i see; so you are saying we should avoid mounting it if it exist.
maybe i'll add an optional mounts field that ignores errors and add resolve conf there?

[joshuaspence]

No, you have to mount it (I think). I mounted the Ubuntu Raspberry Pi image without mounting /etc/resolv.conf and its borked.

root@mnt:/# dig google.com
Unsupported ancillary data: 0/1
Unsupported setsockopt level=41 optname=67
Unsupported setsockopt level=41 optname=66
Unsupported ancillary data: 41/67
Unsupported setsockopt level=41 optname=66
socket.c:2411: setsockopt(20, IPV6_RECVTCLASS) failed: Protocol not available

I am using systemd-nspawn here so it might be doing some magic but things start working if I add --bind /etc/resolv.conf.

root@mnt:/# ls -al /etc/resolv.conf 
lrwxrwxrwx 1 root root 39 Apr 24 01:02 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

[yuval-k]

what about copying it instead of mounting it?

[yuval-k]

@joshuaspence updated pr to copy resolv conf. do you think this will help? i can make the copy default on / optional off.

[hoshsadiq]

In my opinion to maintain backwards compatibility it should default to off.

In addition, can I suggest a possibly different approach. Often the reason for @joshuaspence original issue is because of DNS server is misconfigured or unreachable for one reason or another. In theory it's addressable without resolv.conf hacks like this, but that's usually a lot more time consuming, so this is in general easier. My suggestion is, instead of touching resolv.conf file, you could have an option for custom DNS entries, which, if set, simply writes a minimal resolv.conf file with just the DNS entries (nameserver <entry> for each entry item). What do you think?

[joshuaspence]

Copying is not a good idea as then the file ends up in the image being created. I think we can probably bind mount both /run and /etc/resolve.conf (I think you would need to do /run first)

@hoshsadiq this technique (mounting resolve.conf inside a chroot) is quite common and is very similar to what systemd-nspawn.

[joshuaspence]

For example, arch-chroot (https://wiki.archlinux.org/index.php/Chroot) does this too

[yuval-k]

if the issue that the file ends up in the image, we can make sure it is cleaned up if it was created.

I'm a bit scared bind mounting /run as this gives the image access to the host /run we might be destructive if these are different distributions, no?

[micchickenburger]

I don’t think it would be destructive but the host would have to be a systemd host for mounting /run to be effective.

…

On Wed, May 20, 2020 at 07:29, Yuval Kohavi ***@***.***> wrote: if the issue that the file ends up in the image, we can make sure it is cleaned up if it was created. I'm a bit scared bind mounting /run as this gives the image access to the host /run we might be destructive if these are different distributions, no? — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#70 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABCP2DRZHG6M7O2TD6I5TU3RSPELBANCNFSM4NEAESOA).

[joshuaspence]

I think the best solution would be to mimic systemd-nspawn here. In systemd/systemd#9024 they added --resolv-conf (available from version 239). From https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--resolv-conf:

Configures how /etc/resolv.conf inside of the container (i.e. DNS configuration synchronization from host to container) shall be handled. Takes one of off, copy-host, copy-static, bind-host, bind-static, delete or auto. If set to off the /etc/resolv.conf file in the container is left as it is included in the image, and neither modified nor bind mounted over. If set to copy-host, the /etc/resolv.conf file from the host is copied into the container. Similar, if bind-host is used, the file is bind mounted from the host into the container. If set to copy-static the static resolv.conf file supplied with systemd-resolved.service(8) is copied into the container, and correspondingly bind-static bind mounts it there. If set to delete the /etc/resolv.conf file in the container is deleted if it exists. Finally, if set to auto the file is left as it is if private networking is turned on (see --private-network). Otherwise, if systemd-resolved.service is connectible its static resolv.conf file is used, and if not the host's /etc/resolv.conf file is used. In the latter cases the file is copied if the image is writable, and bind mounted otherwise. It's recommended to use copy if the container shall be able to make changes to the DNS configuration on its own, deviating from the host's settings. Otherwise bind is preferable, as it means direct changes to /etc/resolv.conf in the container are not allowed, as it is a read-only bind mount (but note that if the container has enough privileges, it might simply go ahead and unmount the bind mount anyway). Note that both if the file is bind mounted and if it is copied no further propagation of configuration is generally done after the one-time early initialization (this is because the file is usually updated through copying and renaming). Defaults to auto.

#48 is relevant here :)

[yuval-k]

ok, I think we now have all the options. feedback is welcome

[yuval-k]

will merge and in a day or two if no objections