On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nkadel(a)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