systemd-219 issues with 22 and Rawhide composes

[Nico Kadel-Garcia]

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
is part of what killed the old "daemontools" init system replacement.
tool. You and the other developers have gone well past that. But these
are not tiny surprises, and the anaconda team is far, far, far from
the only people who need a heads up on structural surprises like this.

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

You probably wouldn't like it. I'd scream about things like this. The
time I can spare for this is spent cleaning up the mess when systemd
based tools from Fedora are unusable under RHEL 5 or 6 without folks
like me putting in hooks to detect and handle real init scripts, and
vice versa. It's over hat https://github.com/nkadel/.

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

This wasn't merely a "discussion", it was an unexpected behavioral
change in a vital system configuration file.

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

And you've introduced a permanent inconsistency between systems that
were ever touched by an admin or a tool aware of symlinks, and one
that has not been so touched. And introduced a backup configuration
issue: network configuration backups, or even source control systems
that store /etc/resolv.conf, all need to be tweaked.

These are not the largest of issues, but they're very real.
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.

This is also not a new problem: this is not the first time that
out-of-band information got stuck someplace weird and took extra work
and knowledge to deal with. When tools like "system-config-network"
started hiding content in /etc/sysconfig/networking/profiles and
/etc/sysconfig/networking/devices, some of us had to learn about
scrubbing those away or making them consistent in order to make sure
that /etc/sysconfig/network-scripts/ifcfg-*  changes got propagated
reliably in Fedora and RHEL systems. But it's a *surprise* when it
happens, and it's extra work in day to day network administration.

And yeah, it happened Monday dealing with virtualized OS image given a
new MAC address and with old  MAC address embedded in weird places.