LWN: Comments on "Control Centre: The systemd Linux init system (The H)"

Control Centre: The systemd Linux init system (The H)

wookey — Fri, 18 May 2012 12:04:44 +0000

There has been a very interesting (and unusually thoughtful!) thread on this in debian-devel over last week or so. Discussing the interesting question of how best to deal with the 3-way merges needed in config files between software updates and local admin updates. Is the model of putting defaults in /lib and local config in /etc the right one, or should all config be in /etc. How are unstated built-in defaults dealt with?

It's a fascinating subject and there is clearly room for improvement even in the distros that do this relatively well currently: dpkg's tech was clever in 1996, it's rather less impressive these days (oh how I long to be given a 3-way merge to do rather than get a choice of 'current' or 'new'). ucf is much smarter but not used everywhere yet.

Rather than repeat it all I suggest you go read the thread. I _think_ the relevant part starts here:
http://lists.debian.org/debian-devel/2012/05/msg00349.html

Control Centre: The systemd Linux init system (The H)

jimparis — Fri, 11 May 2012 16:14:24 +0000

> Since many use cases for /etc/systemd unit files just include the respective /lib/systemd file and add a dependency or similar simple extensions, that won't work.

Why not? You'd still get the warning that /lib/systemd/foo was newer than /etc/systemd/foo. And that would let you know to double-check that things are still OK, and to touch /etc/systemd/foo when you're satisfied.

The case where a timestamp check _would_ fail is if the /lib files retain their upstream timestamps rather than the installation timestamps -- then upgrading systemd might install a "new to you" config file that's still older than the last time you touched the corresponding file in /etc.

Control Centre: The systemd Linux init system (The H)

jschrod — Fri, 11 May 2012 07:48:30 +0000

Since many use cases for /etc/systemd unit files just include the respective /lib/systemd file and add a dependency or similar simple extensions, that won't work.

Control Centre: The systemd Linux init system (The H)

zlynx — Wed, 09 May 2012 18:14:59 +0000

I have not checked, but it is possible that the configuration merges sections with the same names.

That would mean you could override lines in the middle of the configuration too.

Modifying Files In /etc

dgm — Wed, 09 May 2012 17:21:24 +0000

Having a revision history would allow for "fast forward" merges (in git parlance) most of the time, avoiding having to ask the user to choose which set of improvements is more valuable, except when conflict arises.

Modifying Files In /etc

dgm — Wed, 09 May 2012 17:17:02 +0000

This is another problem class entirely.

Control Centre: The systemd Linux init system (The H)

jspaleta — Wed, 09 May 2012 16:07:30 +0000

Now that... is an interesting idea.

-jef

Control Centre: The systemd Linux init system (The H)

JoeBuck — Wed, 09 May 2012 15:52:21 +0000

Finding out whether there is something else interesting about systemd might require clicking the link and reading the article, but it's so much easier to start Slashdot-like threads based on a sentence in the summary.

Modifying Files In /etc

drag — Wed, 09 May 2012 12:36:07 +0000

managing configurations across multiple systems calls for a tool like puppet. The reason why people use them is because they found that managing etc using source code control systems was not sufficient.

Modifying Files In /etc

cortana — Wed, 09 May 2012 11:19:59 +0000

dpkg doesn't version them as such, but when a new version of a "conffile" is installed, dpkg will check to see if the original was modified by the user; if not, the new file replaces the old; if so, the user is asked whether they want to keep the new file, the old file, see a diff, etc. Then the old/new file (whichever the user didn't want to keep) is written out with the suffix .dpkg-{old,new} respectively for reference.

I have always been put off using tools like rcs or git to manage /etc because they don't preserve file metadata such as ownership, permissions, ACLs, xattrs, etc. Some day I'll check out etckeeper.

Modifying Files In /etc

dgm — Wed, 09 May 2012 08:36:49 +0000

And if you used rcs you could keep an annotated history of your modifications. I use rcs because there's a port for absolutely all systems I use, even Windows, but git would do a better job.

And, btw, does anybody now why distributions are not doing this by default? I mean, having configuration files versioned. The rcs package is just a few KB, and would make things so much easier.

Control Centre: The systemd Linux init system (The H)

niner — Wed, 09 May 2012 07:53:37 +0000

rpm detects this just the same, the only difference being that rpm packages specify what to do if the config file was changed (move the changed one aside or install the new one with a .rpmnew extension) which gives the user a less immediate choices but is great for unattended updates.

Control Centre: The systemd Linux init system (The H)

jezuch — Wed, 09 May 2012 07:30:05 +0000

> The problem is that it's not clear if you've modified a script manually or it was modified by the package manager.

Debian's dpkg can tell that. If an upgrade wants to install a new version of a config file (in /etc) which was also modified by the user, it will present a choice to keep the modified version or install the one from the package or even try to merge the changes together.

Control Centre: The systemd Linux init system (The H)

ewan — Wed, 09 May 2012 01:59:25 +0000

"It's not exactly a novel idea"

I'm not sure that untrammelled creativity is really what I'd look for in an init system. A clean implementation that bundles up a lot of existing good ideas, is.

Control Centre: The systemd Linux init system (The H)

clugstj — Wed, 09 May 2012 00:18:45 +0000

I really hope this quote isn't the best thing that can be said about systemd. It's not exactly a novel idea.

Modifying Files In /etc

ldo — Tue, 08 May 2012 23:50:54 +0000

My usual, distro-independent way of customizing files in /etc is first to make a copy of the files (or, in some cases, the whole directory), with a -orig suffix. Then I can find my changes quickly with

find /etc -name \*-orig

and of course see what I changed with

diff -u file{-orig,}

or, for directories,

diff -ur dir{-orig,}

If I’m feeling really brave, I might pipe the output through patch(1) to apply the same changes to another system. :)

Control Centre: The systemd Linux init system (The H)

skitching — Tue, 08 May 2012 23:26:28 +0000

Seems like it would be a good idea for systemd to log a warning for any file in /etc/systemd whose timestamp is older than the file of the same name in /lib/systemd.

Control Centre: The systemd Linux init system (The H)

geuder — Tue, 08 May 2012 22:34:19 +0000

OK, this should work as long as your changes can be expressed by just adding new lines in the beginning and/or end of the stock configuration.

(No I haven't real production experience with systemd yet. Just played a bit with F16, but there were no tricky requrements for playing)

Control Centre: The systemd Linux init system (The H)

geuder — Tue, 08 May 2012 22:23:56 +0000

When using etckeeper on Debian, Ubuntu, Fedora or CentOS it is clear were each change originated from because there will be an automatic commit before each package manager execution (to capture manual edits) and after each package manager execution to capture updates made by a package)

On OpenSUSE there are no hooks (or I failed to find them), so it depends wether the admin remembered to make a commit and how good the cooments are.
In most cases I might recognize my modifications (as you say, rarely needed) from somebody elses changes even with not so perfect commit history.

Control Centre: The systemd Linux init system (The H)

johannbg — Tue, 08 May 2012 22:09:28 +0000

You can create a new unit that has the same name in /etc/systemd/system directory which contains only .include reference and your custom change.

That will ensure that your custom unit will inherit all "updates" security or otherwise made by the distribution relevant package maintainer to the relevant unit to his package while giving you the flexibility to have your own modifications.

For example let's say you want systemd to automatically restart the apache service should the apache daemon exits with an exit code not equaling 0,when it is terminated by a signal,when an operation times out or when the configured watchdog timeout is triggered.

You would create a new unit in the /etc/systemd/system directory called httpd.service and it would contain...

.include /usr/lib/systemd/system/httpd.service

[Service]
Restart=on-failure

That's it...

Control Centre: The systemd Linux init system (The H)

Cyberax — Tue, 08 May 2012 21:33:29 +0000

The problem is that it's not clear if you've modified a script manually or it was modified by the package manager. You need to view its history, at least.

With systemd it's all very clear - if you have a file in /etc/init then it's an override and you are responsible for it. That said, I had to override only one unit in my pretty complicated setup.

Control Centre: The systemd Linux init system (The H)

geuder — Tue, 08 May 2012 21:13:14 +0000

Well, that's half a step into the right direction. But if a (security) update modifies the version in lib, the admin might want to merge the change with her/his own modifications. But who tells when such a merge might be needed?

Myself I like etckeeper (with git) for that purpose. Works perfectly with SysV init scripts (and of course everything else under /etc). Unfortunately it would no longer identify lost update situations with systemd's half solution. Maybe use the right exisiting tool for the purpose, instead of trying to solve a problem of versioning once more. Admittedly git is not 100% the right tool for /etc, but close enough.