systemd-219 issues with 22 and Rawhide composes

[Zbigniew Jędrzejewski-Szmek]

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
> <mzerqung at 0pointer.de> wrote:
> > On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nkadel at 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.

OK, this change is not transparent to tools that write resolver
information. The new scheme requires some changes, but it's not more
complicated than the old scheme. It is actually easier for the admin,
because it gives full control over the symlink to them, and easier for
the tools, because they don't have to fight over the contents of the
file.

> > Hey, if you want to know what's going on in systemd development, then
> > pelase join our upstream mailing list.
I know that this is not realistic. But it's not really necessary. This
issue discussed before F21, and an number of Anaconda people
participated in the discussion. The bug was open for the last 6 months.

> >> For example, now if I manipulate /etc/resolv.conf for whatever reason,
> >> and I edit it with "vi" or a management tool like "chef" that is
> >> unaware of symlinks, I'll break the link. Will systemd correctly
> >> re-establish the link? Will it wipe out my change, Did anyone even
> >> *think* about this?
> >
> > Nope. All that systemd does is create it as symlinks if it is
> > otherwise missing. If you put something else there, then that's what
> > counts.
The file that is written by systemd-resolved contains the following header:

# This file is managed by systemd-resolved(8). Do not edit.                                     
#                                                                                               
# Third party programs must not access this file directly, but                                  
# only through the symlink at /etc/resolv.conf. To manage                                       
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

I'll try to tweak this text a bit to be clearer on the symlink issue.
I don't have a NetworkManager generated file at hand to see, but it
should probably carry something similar.

> Personally? I'd say "either always use a symlink, or never use one".
> Please do not try to deduce the sys-admin's intent from which editing
> tool they happen to use and its secondary behavior. The handling of
> symlinks can seriously, seriously bite you at odd moments.
We need the file to be a symlink for some usecases.
We *could* deprecate /etc/resolv.conf as a normal file, and always
create it as a symlink. Anaconda would then write (say) /etc/resolv.conf.static,
and symlink /etc/resolv.conf → resolv.conf.static. This is really beyond
systemd, since systemd does not create the static file ever.

Zbyszek