[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: