On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nkadel@xxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
