Thomas Goirand <zigo@debian.org> writes:

> Seriously, can't someone who broke his configuration wget the package,
> and use mc to get into the .deb and get the original configuration
> file???

FWIW, I'd love an easier way to keep track of my /etc, where upstream
changes and my own are on a separate branch. So the idea is not entirely
silly, and would be useful even for folk like myself, who - at least I
dare hope so - are not entirely clueless.

The solution, however, is very simple: wrap dpkg calls, and have a list
of files to watch for. Whenever a package touches a file that's on the
list, fire a trigger, that can run a hook. Said hook can be something
provided by etckeeper or similar, that would extract the appropriate
file from the deb, and commit it to the upstream branch of /etc, for
example.

Then proceed on, and do whatever else needs to be done. And boom! We
have a way to allow experienced users to keep track of their /etc
properly, that does not fall on its face when I notice a bad config
change in the upstream config two updates later.

Oh, and this whole thing need not live in /etc at all, and can follow
anything, not just config files. It's perfectly able to notice changes
in /lib/systemd too, or pretty much anywhere else.

I actually just implemented that (it took 10 minutes, becuase I screwed
up first), and will be testing how it works over the next few weeks.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87y5oyr0eq.fsf@luthien.mhp">http://lists.debian.org/87y5oyr0eq.fsf@luthien.mhp

md@Linux.IT (Marco d'Itri) writes:

> On May 11, Thomas Goirand <zigo@debian.org> wrote:
>
>> > Long story short, I still don't see what the fuss is about.
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> changes, which potentially, will make it horrible to manage
>> upgrades in a decent way without knowing the corner cases.
> No, not even that: if you edit files in /lib without being aware of the
> consequences then you are an idiot and deserve to suffer for it.
> The problem with etc-overrides-lib is that a file must be copied in
> full from /lib to /etc to be modified, and then future changes to the
> same file in /lib will be ignored (so maybe the package will break
> because these changes are required, etc).

And...?

If it were somewhere under /usr/share/doc/$package/examples, how would
that be different? (Assuming that the *default* would then be wired into
the binary)

You'd still need to copy the file, and if the defaults change under you,
you're screwed. Even worse if you have to dig out the possible options,
and their defaults from (possibly stale) documentation.

But even if everything is in /etc, you can still easily screw yourself
over: conf.d/ can very easily break the exact same way.

It's not etc-overrides-lib that is the problem. It's defaults changing
without notice that is. With the defaults being broken out into files,
making a tool that notifies the user preemptively when a default will
change, and stops the upgrade, is possible, and is not even hard.

You can't do that when the defaults are either unavailable, or subject
to change by the admin.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r4uqqzwt.fsf@luthien.mhp">http://lists.debian.org/87r4uqqzwt.fsf@luthien.mhp

Thomas Goirand <zigo@debian.org> writes:

> On 05/11/2012 08:33 PM, Michael Biebl wrote:
>> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>>
>>> The problem with etc-overrides-lib is that a file must be copied in
>>> full from /lib to /etc to be modified, and then future changes to the
>>> same file in /lib will be ignored (so maybe the package will break
>>> because these changes are required, etc).
>>>
>> You can either copy the file or use the .include directive (which was
>> already mentioned) and only override the settings you need.
>> So systemd provides both semantics and you can chose which one you
>> want/need.
>>
>> Michael
>>
> But upon upgrades, it's still a silent thing. The configuration file in /lib
> is overwritten and users wont know about the changes.

Likewise for *every* other case where the default changes. There's
nothing different. Nothing. Nada.

Except you can write a tool to warn in *this* case, because the defaults
are available in a diffable format.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx5eqztf.fsf@luthien.mhp">http://lists.debian.org/87mx5eqztf.fsf@luthien.mhp

OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers
13:20, Gergely Nagy <algernon@balabit.hu> disaitÂ*:

>>> In other words, it does *exactly* the same thing systemd is
>>> criticised for.
>>>
>>
>> Which doesn't mean that it's a good practice.

> Tell me what you would gain, if there were no files under /lib/systemd,
> and all of these were compiled into the binary, please. Because that's
> the other option, as you *do not* let users change the defaults. You let
> them override them, you let them configure the system. (And that *is*
> being done in /etc.)

> There are *very* few programs that come without any kind of default, and
> even less, that let you change the default too.

> apt does not let you change the defaults, nor does dpkg. Both allow you
> to change their settings, but without recompiling, you can't change the
> defaults. Same happens with systemd, the difference is that it's easier
> to see the defaults, as they're broken out into files that are easy to
> copy and change as needed.

Yes, that's very true. We are just used that the kind of "defaults" in
init to be in /etc. But nothing is set in stone. I was first against
this etc-override-lib behaviour but your arguments are sound and I am
now convinced that we should keep the way systemd is doing things.

Moreover, in the case of systemd, there are other mechanisms that can be
used to customize a configuration file for the more common modifications
(handling dependencies and ordering) using symbolic links. This way,
there is no need to copy the file from /lib in /etc to do the
modifications.

Still in the case of systemd, a README put in /etc/systemd may be used
to explain the whole etc-override-lib to users that are not expecting
such behaviour. A README is not a configuration file but there is one in
/etc/init.d as well.
--
Vincent Bernat ☯ http://vincent.bernat.im

#if 0
2.2.16 /usr/src/linux/fs/buffer.c

SEEWEB - Marco d'Itri <md@seeweb.it> writes:

> But this is a user error. The point is that with etc-overrides-lib there
> is no prompt at all when the upstream configuration changes.

Bzzt. There's no prompt ever when upstream defaults change. Unless *all*
the defaults are laid out in /etc, *AND* the user modified that
particular file.

If suddenly /etc/$program.conf, which I never modified changes, and I
have custom snippets under /etc/$program.d/*.conf, those snippets might
very well break.

Do I get a prompt? No. The closest I get is that $program.conf was
upgraded. I see no diff, unless I keep track of my /etc in other ways.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipg2qzmc.fsf@luthien.mhp">http://lists.debian.org/87ipg2qzmc.fsf@luthien.mhp

Thomas Goirand <zigo@debian.org> writes:

> On 05/11/2012 11:08 PM, Marvin Renich wrote:
>> For clarity, the etc-overrides-non-etc model that I am talking about is
>> where the file in /etc can override individual values, not where the
>> file in /etc must replace the entirety of the non-etc configuration.
>>
> This case is much much more acceptable to me. I wouldn't see any
> problem with it. I just don't want that new configuration values to be
> silently ignored upon upgrades, that's all I'm saying.

I agree, that seeing the defaults change would be lovely. With the
defaults being in /lib, it's possible to write a tool that notifies you.

With the defaults being in a monolithic blob, possibly inside a binary,
it is not.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ehqqqzeu.fsf@luthien.mhp">http://lists.debian.org/87ehqqqzeu.fsf@luthien.mhp

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Gergely Nagy
>
>> Tollef Fog Heen <tfheen@err.no> writes:
>>
>> > ]] Gergely Nagy
>
>> >> In that case, the including file can be changed (by the admin) to be a
>> >> separate file, that does not include, and get the usual conffile
>> >> conflict dpkg prompt.
>> >
>> > How would that work?
>> >
>> > I have /lib/systemd/system/foo.service and want to change something in
>> > it, I then create /etc/systemd/system/foo.service with a copy of the
>> > /lib one plus whatever changes I want.
>> >
>> > The version in /lib is then updated. How is the admin notified?
>>
>> NEWS.Debian, like with any significant default change.
>
> So you won't get the dpkg conffile conflict prompt, then? Can you
> explain what the scenario you talked about would look like, since it's
> apparently not the scenario I was thinking about?

I believe we're talking about the same scenario, and I was hasty to
suggest that NEWS.Debian is the only way - see below.

>> Other than that, the best I can think of is keeping track of what
>> version of the package a default changed in, and triggering something
>> from preinst, when upgrading from a version that is older than the
>> change.
>
> This is basically what the tool I'm suggesting to write will do.

During my trip back home, I wrote that tool. It's very crude and hackish
at the moment, but with a little bit of support from, say, apt (or
perhaps dpkg, but that's less likely), it could be made into something
nice.

Basically, I divert dpkg, and catch all -i calls, see what debs we're
called on, list the files therein. If any of the files are on the
watchlist, I launch the triggers, with apropriate parameters. The only
trigger I have implemented so far will extract the files that triggered
it, and put them in version control, onto the appropriate upstream
branch. Then proceed on.

I could enhance it to abort the installation, or send mail, or pause and
do some ucf magic, to check whether overrides in /etc exist at all, and
so on and so forth.

I only needed the shovel-into-a-vcs-branch thing, so that's what I
have. Adding the rest isn't hard, either.

The advantage here, is that the packager need not keep track of what
changed in which version, and admins can extend the watchlist, and
change the triggered actions too, to make it better suit their own
needs. This also means that in case of bugs, we don't need to fix
maintainer scripts, just a single application.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa1eqz1g.fsf@luthien.mhp">http://lists.debian.org/87aa1eqz1g.fsf@luthien.mhp

On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> The FHS is very specific that /etc is for *Host-specific* system
> configuration, not upstream defaults or distribution-specific
> configuration. The clear intent is that this is where files that are
> intended to be modified by the local system administrator are placed.

No, this is a total retcon. When the FHS was written, this was definitely
NOT a shared understanding of a difference between "host-specific
configuration" and "upstream defaults / distribution-specific
configuration".

Distribution defaults still would go in /etc whenever it was expected that
an admin might want to edit the file. This has been the convention for more
than a decade.

> Files containing distribution-specific defaults, whether they match some
> definition of "configuration file" or not, do not belong here unless the
> they are also intended to be edited by the local sysadmin.

Yes. The issue is not that either system is a violation of the standard,
because intent is relevant here. If the upstream *intends* the file to be a
template that's overridden using a separate file, then /usr is the right
place. If the upstream intends the user to edit the provided file to make
their changes, it belongs in /etc. If the defaults are built into the
binary, that's perfectly fine too.

What *is* an issue is when upstreams decide to ship their defaults in /usr,
but require users to duplicate information between /usr templates and /etc
config files and ignore the contents of /usr in favor of the contents of
/etc. This is also not a violation of FHS, but it IS a crappy design.

When software is not able to override configuration *settings* with fine
granularity via /etc, the entire thing should go under /etc. Doing
otherwise makes this horrible for upgrades.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

Steve Langasek <vorlon@debian.org> writes:

> What *is* an issue is when upstreams decide to ship their defaults in
> /usr, but require users to duplicate information between /usr templates
> and /etc config files and ignore the contents of /usr in favor of the
> contents of /etc. This is also not a violation of FHS, but it IS a
> crappy design.

> When software is not able to override configuration *settings* with fine
> granularity via /etc, the entire thing should go under /etc. Doing
> otherwise makes this horrible for upgrades.

Yes, this, with the caveat that coming up with a new tool that would do
the right thing, as Tollef discussed, would be a reasonable substitute for
putting everything in /etc.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sjf6ih8l.fsf@windlord.stanford.edu">http://lists.debian.org/87sjf6ih8l.fsf@windlord.stanford.edu

* Steve Langasek <vorlon@debian.org> [120511 16:17]:
> On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> > The FHS is very specific that /etc is for *Host-specific* system
>
> No, this is a total retcon. When the FHS was written, this was definitely
> NOT a shared understanding of a difference between "host-specific
> configuration" and "upstream defaults / distribution-specific
> configuration".

I obviously read more into "host-specific" than was intended.

> Distribution defaults still would go in /etc whenever it was expected that
> an admin might want to edit the file. This has been the convention for more
> than a decade.

Agree completely. See the next sentence.

> > Files containing distribution-specific defaults, whether they match some
> > definition of "configuration file" or not, do not belong here unless the
> > they are also intended to be edited by the local sysadmin.
>
> Yes. The issue is not that either system is a violation of the standard,
> because intent is relevant here. If the upstream *intends* the file to be a
> template that's overridden using a separate file, then /usr is the right
> place. If the upstream intends the user to edit the provided file to make
> their changes, it belongs in /etc. If the defaults are built into the
> binary, that's perfectly fine too.

I agree completely. I was responding specifically to the assertion that
the definition of "configuration file" from Wikipedia meant that Debian
"must" put files containing distribution-specific defaults in /etc,
regardless of whether or not they were intended to be modified by the
local sysadmin.

> What *is* an issue is when upstreams decide to ship their defaults in /usr,
> but require users to duplicate information between /usr templates and /etc
> config files and ignore the contents of /usr in favor of the contents of
> /etc. This is also not a violation of FHS, but it IS a crappy design.

Again, I agree completely. See the part of my message that you did not
include where I clarified to which etc-overrides-non-etc model I was
referring.

> When software is not able to override configuration *settings* with fine
> granularity via /etc, the entire thing should go under /etc. Doing
> otherwise makes this horrible for upgrades.

Absolutely. Again, see my clarification of how I was using
etc-overrides-non-etc. I did not go into what I think is wrong with
"default in /usr, copy entirety to /etc and edit in order to override a
single setting" because I was specifically trying to address the other
poster's assertion that placing anything that matches the Wikipedia
definition of "configuration file" anywhere other than /etc was a
violation of a "must" in Debian policy.

...Marvin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120511210825.GC7658@cleo.wdw">http://lists.debian.org/20120511210825.GC7658@cleo.wdw