Re: policy for shipping sysctl.d snippets in packages?
On 05/01/2017 01:02 PM, Marc Haber wrote:
> On Mon, 1 May 2017 11:09:26 +0200, Christian Seiler
> <christian@iwakd.de> wrote:
>> And as I said in other places in this thread: I personally
>> think that the separate /usr <-> /etc scheme is much better
>> than just storing everything in /etc, so I would really
>> prefer if as much software as possible would switch to that,
>
> How would you expect the case "local admin has copied over the file
> from /usr to /etc to apply local changes, and a new package version
> changes its defaults so that the service wouldn't run with an
> unadapted configuration any more" to be handled?
>
> The Debian way will handle this through conffile managent or ucf,
> making the local admin immediately aware of the changes, while the way
> you advocate would make the admin end up with a (probably silently)
> failed service, broken by a simple package upgrade.
That's not necessarily true. This may be true if you have a
single configuration file, but several programs come with
multiple configuration files - and sometimes certain settings
depend on each other. Heck, I've seen the following scheme
multiple times:
/etc/$package/$main_config:
include /etc/$package/local
Where it's encouraged to leave the main config file alone
and just configure stuff in the local configuration file.
There you won't get any feedback due to dpkg/ucf either.
Or, let's say a default configuration option changes for
security reasons, but that configuration option makes another
option you're using (and added elsewhere in the file) not work
anymore and the daemon doesn't start either. If you are doing
an automatic 3-way-merge, you'll run into this problem. And
even if you merge manually, you might not realize that the
options are incompatible just from looking at the config file
at that point.
Or, to put it differently: I've experienced the problems
you've been describing very often already with the traditional
"config is in /etc" scheme. It's true that the separate /usr,
/etc scheme has some disadvantages in this specific area, as
there are always trade-offs when it comes to solutions. But
from personal experience I simply don't agree with the case
made here that having everything in conffiles in /etc makes it
possible or even easy to track these kinds of things
consistently enough that it makes up for all of the pain I
experience when it comes to handling configuration files on
updates.
Furthermore, I don't think the "gold standard" for a /usr and
/etc split should be to copy the entire file from /usr into
/etc and just change a small setting. That might be necessary
in some cases (due to limitation of the configuration file
language in question), but I personally think the best solution
here to have .d/-style directories (see e.g.
/etc/apt/preferences.d/) where you can drop in small files that
change only the settings you want to change.
> And I am not yet bringing the case where the package maintainer fixes
> a security issue by a configuration change in the game.
I would expect the DSA announcement to contain information on
this topic, plus potentially even a NEWS file.
>> [1] This is _not_ systemd. systemd introduced an own scheme via
>> /usr/lib/binfmt.d + /etc/binfmt.d, which no package in Debian
>> sid or stretch currently uses.
>>
>> And note that binfmt-support has always worked that way, for
>> at least 15 years, way before systemd came around.
>
> Having configuration in /usr without a possibility to override it via
> /etc is a policy violation, isn't it`
Maybe. (I've been burnt in the past by assuming that certain
things are in policy when they in fact weren't. I'm much more
careful with such statements now.) It certainly is something
that's not desirable. OTOH, one could argue that binfmt is
more like "plugins for the kernel" instead of configuration
(similar to how plugin .so files can be installed into
directories under /usr/lib). Since this has been this way since
forever, I don't think it makes sense to drastically change it
in Stretch so close to the release - but we should probably
revisit this at the beginning of the Buster release cycle.
(There's also the question of whether we'd not rather want to
adopt the binfmt.d scheme on all init systems, as that does
exactly the same with a slightly different syntax, and other
distros are now using just that, and slowly phasing out the
/usr/share/binfmts directory, while still supporting it for the
foreseeable future for compatibility reasons.)
Regards,
Christian
[1] I really wouldn't want to call it the "Debian way". Having
configuration files completely in /etc is something that
predates Debian by a long time.
Reply to: