systemd-219 issues with 22 and Rawhide composes

[Lennart Poettering]

On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nkadel at gmail.com) wrote:

> > Hey! Come on. Everything that systemd does is create a symlink for
> > /etc/resolv.conf if nothing else has created on for that. If something
> > else created and owned that file, it leaves the thing alone. That's
> > all. It's very defensively written. Anaconda's file copy routine
> > tripped up on it though, since it follows symlinks on the destination
> > (which is a really bad idea, and needs to be fixed).
> 
> You do not know, and cannot know in advance without testing, how many
> different systems might manipulate or rely on specific resolv.conf
> changes. 

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*. And it won#t be missing if anaconda copies
in its stuff as it currently does. I mean, the issue is really about
this copy routine being broken, and not about systemd having a
fallback logic to create /etc/resolv.conf if it is missing.

If anaconda's file copy routine would not be confused by symlinks in
the destination, the issue goes away entirely: it would create its
file, and systemd's /etc/resolv.conf logic would never touch anything
anymore.

> This is especially true for VPN based environments where the
> order of DNS resolvers is critical to correct local and general
> environment resolution. Puppet, cfengine, chef, tuttle, and many
> virtualization systems such manipulate entire network stacks by either
> stabilizing them or resetting them. And now they have to manipulate
> /etc/resolv.conf as a symlink?

No, they don't. Only anaconda has, since it starts with an empty /etc.

That said, I think it would be a ton better if those frameworks you
list would be able to deal with /etc/resolv.conf being a symlink.

> It's one of the systemd problems: "We know better than the last 30
> years of UNIX work how this should be, and will take it over with our
> own unique, new paradigm."

Note that this would matter here at all /etc/resolv.conf being a
symlink is hardly a new concept. See Debian's "resolvconf" package for
example...

> >> > How many months would you like me to notify people in advance of a
> >> > simple change like this? Isn't 6 month *ample* time?
> >>
> >> Likely not, not everyone has the same schedule as upstream systemd, in
> >> a lot of cases they don't know it's broken until things land and teams
> >> have other priorities.
> >
> > OK, got it, will let everybody know now of changes 5 years in
> > advance. Would that suit your needs?
> 
> Only telling "the people who need to know" is the problem. You
> apparently think you know, personally, who those people are. That's
> not safe or fair to other developers or even to normal admins.

Hey, if you want to know what's going on in systemd development, then
pelase join our upstream mailing list.

And no, I will not forward all systemd design discussions to the
fedora ML, it has no place there. We don't forward them to the suse,
debian, ubuntu MLs either. 

> 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.

Lennart

-- 
Lennart Poettering, Red Hat