Re: Overriding conf file with symlink under /etc considered harmful
>>>>> On Fri, 09 Apr 2004 09:53:51 -0300, Ben Armstrong <synrg@sanctuary.nslug.ns.ca> said:
Ben> I am CCing debian-custom, as this is an issue for all CDDs.
Ben> Please followup there. Sorry if this is ground that has been
Ben> covered already here or in -devel, but the traffic on these
Ben> two lists is considerable, and I have only just skimmed as I
Ben> have found time, so quite likely I missed this the first time
Ben> it came up.
Ben, thanks for this Cc. I'm somewhat new to this topic, but I do
agree that is a key issue of every CDD. So I'm going to spend some
words on this..
Ben> On Fri, Apr 09, 2004 at 04:48:00AM +0200, Jonas Smedegaard
Ben> wrote:
>> Ok, let me rephrase: Overriding a conffile with a symlink is
>> not handled properly in Debian.
Ben> OK, now I understand you.
>> this is not a problem for developers, but for users. Please
>> read on...
Ben> Got it.
>> Debian Policy is for package maintainers, not for local systems
>> administrators. I warned earlier that Skolelinux packages
>> breaks policy by making changes to conffiles of other packages,
>> but was then told that Skolelinux packages does not do that -
>> they just provide scripts for the local admin to do the changes
>> automatically (and runs those scripts through debconf). I
>> honestly did not buy that argument, but didn't want to waste
>> more time on the issue - I made my point, and it wasn't
>> accepted.
Ben> Hm. Furnish an example? Do you mean the dhcp3.conf symlink
Ben> is made by a debconf script run from a package other than
Ben> dhcp3-server? This seems a bit fishy. If the script
Ben> modifying another package's conf files is run through
Ben> debconf, then I, too, would say the package does indeed
Ben> modify other scripts' conffiles and is in violation of
Ben> policy. But it's all a matter of interpretation. Also, it
Ben> is not an easy problem to solve for CDDs because a CDD aims
Ben> to configure a Debian system in some sane way. It is
Ben> cumbersome to have to coordinate with the package maintainers
Ben> of all packages contained within a CDD to make a mechanism
Ben> that will assist in configuring the system the way we want
Ben> it, but that appears to be the only policy-compliant option.
Well, maybe a CDD configuration package should be not considered in
the same way as ordinary packages.
I think will all agree that one of the main goals of a CDD, a part
from barely installing a specific subset of packages, is to provide a
properly tuned configuration for such subset.
IMHO the two best strategies for this porpoise are:
1) feed the debconf database with custom values and then run
dpkg-reconfigure --all
2) use cfengine to directly tune or create configuration files
AFAIK these two methods were both introduced by Skolelinux.
The second one is needed where the first can't deal, and even though
CDDs developers should cooperate with the maintainers wherever is
possible to introduce or improve the debconf support for a given
package, my opinion is that there will be always cases which can't be
cleanly handled with the first strategy.
A simple real life example from DeMuDi: I have to turn on the kernel
lowlatency flag at boot time, and the best way to do it is by editing
/etc/sysctl.conf adding a single line (kernel.lowlatency = 1).
The sysctl.conf conffile belongs to the procps package, but of course
introducing the debconf support for all possible kernel variables it's
not feasible, so that I ended up using the cfengine strategy.
>> So, the packages are not in violation with Debian Policy
>> because the tampering of other packages is (in a smart way)
>> left to the local admin. I therefore do *not* complain about a
>> breach of policy, but about an unwise thing for (developers to
>> persuade) local admins to do.
Ben> Where "persuasion" is the debconf question (defaulting to
Ben> "no"?) "do you want to modify this other package's conf
Ben> file?"
IMHO if someone wants to install a CDD, it means that he/she wants to
have a pre-canned working system, which hopefully automatically
configures itself.
Thus when installing the CCD configuration package
(e.g. debian-edu-config, debian-med-config, demudi-confg, etc.), the
default answer to the question "do you want to modify this other
package's conf file?" should be "yes".
>> Try this:
>>
>> ~ 1) Install dhcp3-server ~ 2) Replace manually
>> /etc/dhcp3/dhcpd.conf with a symlink ~ 3) Update dhcp3-server
>> to a newer version (with changes to the conffile, so that the
>> "do you want to update this file" dialogue appears.
>>
>> As far as I remember (as a local admin I stopped using symlinks
>> some time ago), the update proces now no longer warns about
>> upgrades, but just silently ignores them. This is bad, because
>> the whole point of the warning is that if the conffile is
>> updated it is quite possible those changes are needed, even if
>> changed locally.
Ben> Why is this? Is it because the symlink itself does not
Ben> change? I should think md5sum would catch this. And I don't
Ben> see a "no dereference" option for md5sum. Or is there a date
Ben> check in there too? I'm confused about what leads to this
Ben> problem.
I don't know if understand correctly, but AFAIK when a new version of
package provides a new version for one of its conffiles *and* the
previously installed version of such confile has been modified, then
dpkg *do* stop asking if you want to keep the locally modified version
or replace it with the new one.
bye,
free
Reply to: