On Mon, 2015-03-02 at 08:42 -0800, Brian C. Lane wrote: > On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote: > > > On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering > > > <mzerq...@0pointer.de> wrote: > > > > On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote: > > > > > > [ notes snipped, ] > > > > > > > You know, that systemd creates a symlink if the file is missing is not > > > > going to change behaviour of anything, since it will only do something > > > > if the file is *missing*. > > > > > > Congratulations. We now have inconsistent behavior if anyone, *ever*, > > > edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp > > > reproduce it from a known good repository, and with a symlink in place > > > we're storing absolutely critical system information in a non /etc > > > location, meaning that non-modified backup systems won't get a copy > > > with valid content. > > > > > > Just..... great. > > > > > > Look, deciding to ignore the File System Hierarchy for installing > > > config files and creating new locations to store system configuration > > Actually it might be considered that we are *starting* to follow FHS. > > In many (most?) setups /etc/resolv.conf configuration is very dynamic: > > the set of resolvers depends on dhcp leases, VPNs, network interfaces > > coming and going. Storing this information in /etc/ is wrong. It's good > > that this ephmeral content is not backed up. If the machine reboots, you > > do not want to restore it, you want to recreate it from scratch. > > > > If someone has a static setup and a static resolv.conf is fine for them, > > there's no problem: just create a normal file. > > The underlying problem here is that it isn't just created when it is > missing. It is created *before* other tools have a chance to create it. > As I explained in 1197204 the boot.iso is created without a > /etc/resolv.conf, this means that NM should create it with whatever > content it needs. Except that systemd-tmpfiles comes along first, > assumes it can create it and then breaks NM.
With NM <= 1.0, it will create a tempfile in /etc and then rename that over top of the existing /etc/resolv.conf, though it does try to follow a link (with realpath(2)) and replace that file atomically (with rename(2)). If that's being broken by systemd we should probably handle this case better in NM too, along with whatever systemd changes need to happen. With NM > 1.0, NM will stop touching resolv.conf at all if it's a symlink, because that file is owned by some other process. NM will still write out it's own resolv.conf to /var/run. If resolv.conf is a file, and NM is allowed to manage DNS through its config, then NM will make resolv.conf a symlink to its file in /var/run, much like I understand systemd does. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
