Control Centre: The systemd Linux init system (The H) [LWN.net]

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

Posted May 8, 2012 21:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Control Centre: The systemd Linux init system (The H) by geuder
Parent article: Control Centre: The systemd Linux init system (The H)

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.

(Log in to post comments)

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

Posted May 8, 2012 22:23 UTC (Tue) by geuder (subscriber, #62854) [Link]

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.

Modifying Files In /etc

Posted May 8, 2012 23:50 UTC (Tue) by ldo (subscriber, #40946) [Link]

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

Modifying Files In /etc

Posted May 9, 2012 8:36 UTC (Wed) by dgm (subscriber, #49227) [Link]

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.

Modifying Files In /etc

Posted May 9, 2012 11:19 UTC (Wed) by cortana (subscriber, #24596) [Link]

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

Posted May 9, 2012 12:36 UTC (Wed) by drag (subscriber, #31333) [Link]

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

Posted May 9, 2012 17:17 UTC (Wed) by dgm (subscriber, #49227) [Link]

This is another problem class entirely.

Modifying Files In /etc

Posted May 9, 2012 17:21 UTC (Wed) by dgm (subscriber, #49227) [Link]

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.