| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 107:38:40 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,678 |
Is it reasonable to use this idea as "best practice" and implement itNo: the expected default for systemd-managed services is to use
into Debian style administration recommendations? It works very well
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the distribution part from local overrides.
* Admin can override the standard configuration via /etc/$proj/foo.conf[...]
Upstream projects are moving to this style. I hope that one day Debian packages will stop shipping files under /etc.
On 19/12/24 10:19, Samuel Thibault wrote:
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
* Admin can override the standard configuration via /etc/$proj/foo.conf[...]
Upstream projects are moving to this style. I hope that one day Debian packages will stop shipping files under /etc.
Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.
$ cp /usr/lib/$proj/foo.conf /etc/$proj/
No: the expected default for systemd-managed services is to use /etc/$SERVICE/ .
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the distribution part from local overrides.
On 12/19/24 16:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate
the distribution part from local overrides.
It depends on the package.
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
* Admin can override the standard configuration via /etc/$proj/foo.conf[...]
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under /etc.
Having pre-filled configuration files ready for editting in /etc
(possibly containing only commented lines) is extremely useful for
admins.
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux.
On Thu, 19 Dec 2024 09:01:09 +0100
Marco d'Itri <md@Linux.IT> wrote:
No: the expected default for systemd-managed services is to use /etc/$SERVICE/ .
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV
Gioele Barabucci, le jeu. 19 déc. 2024 10:22:02 +0100, a ecrit:
On 19/12/24 10:19, Samuel Thibault wrote:
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
* Admin can override the standard configuration via /etc/$proj/foo.conf[...]
Upstream projects are moving to this style. I hope that one day Debian packages will stop shipping files under /etc.
Having pre-filled configuration files ready for editting in /etc (possibly containing only commented lines) is extremely useful for admins.
$ cp /usr/lib/$proj/foo.conf /etc/$proj/
Which is not trivial, really.
On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV
Please keep such messages to appropriate mailing lists such as the
Devuan list
this is what can be called "old style" overrides.
The modern way of doing it is the "stateless" style, most commonly associated with systemd but used by plenty of other projects, plus "drop-in" .d directories.
The basic documentation can be found at <https://uapi-group.org/specifications/specs/configuration_files_specification/>. libeconf provides an implementation of the spec and its details.
Simply speaking the stateless style works like this:
* Distro/upstream configuration in /usr/lib/$proj/foo.conf (read-only)
* Admin can override the standard configuration via /etc/$proj/foo.conf
* Runtime overrides can be placed in /run/$proj/foo.conf
* User can override admin's and upstream's config via $HOME/.config/$proj/foo.conf
* User's runtime overrides can be placed in $XDG_RUNTIME_DIR/$proj/foo.conf
In addition, snippets that add or override only part of the configuration can be loaded from {/usr/lib,/etc,/run,$HOME/.config}/$proj/foo.conf.d/extra1.conf
If my suggestions do not apply to situations where systemd is used,
I'd suggest systemd advocates to stay quiet because the topic does
not concern them
$ cp /usr/lib/$proj/foo.conf /etc/$proj/
Which is not trivial, really.
Put another way: would it really be /usr/lib/$proj, or rather (since
it's arch-independent) /usr/share/$proj, or rather (since that's documentation) /usr/share/do/$proj. How an admin would know? That's just hiding things, compared to the decades of habits.
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?
The group is called "The Linux Userspace API (UAPI) Group", and according
to their home page, it consists of from people from Ubuntu Core, Debian, GNOME OS, Fedora CoreOS, Endless OS, Arch Linux, SUSE, Flatcar, systemd, image-builder/osbuild, mkosi, tpm2-software, System Transparency, buildstream, BTRFS, bootc, composefs, (rpm-)ostree, Microsoft, Amazon, and Meta.
You are free to disagree with this design, but please don't call the people behind it idiots. I am pretty sure there are plenty of very competent
people who have given this a lot of thought.
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it
more difficult for the admin to configure their server?
On Thu, 19 Dec 2024 11:00:03 +0100
Ansgar 🙀 <ansgar@debian.org> wrote:
On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV
Please keep such messages to appropriate mailing lists such as the
Devuan list
As long as Debian ships System-V-like init in the official
repository[1] I'm pretty sure I'm on the correct mailing list.
On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
Also, /etc would thus be full of empty /etc/$proj directories? I don't
see the point of not just putting the example files there? Why making it more difficult for the admin to configure their server?
Examples belong to /usr/share/doc though?
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
That was so annoying that Debian started having configuration files for configuring other configuration files, e.g., /etc/default/* to
configure /etc/init.d/*.
And it is actively harmful as if one edits the example configuration to have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
And it is actively harmful as if one edits the example configuration to have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
Samuel Thibault wrote:
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
And it is actively harmful as if one edits the example configuration to have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the configuration file.
Then, we could have a package (e.g. "etc-commented-defaults") with an on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed.
That seems like an improvement over the current situation, in which
there's a mix of packages that ship commented-defaults (causing problems
for the people who want an empty /etc) and packages that don't (causing problems for the people who expect a sample file in /etc).
On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
But isn't it what we already have? If I don't modify the example in /etc and only add files to .d/, I'm getting upgrades without questions.
And if I modify the example in /etc, I'm getting the question. That way
I can decide per-package whether to just augment or change the
default configuration.
For many packages that works well, but the devil is in the details.
For example, the most common configuration change for chrony is to use
a set of custom NTP servers, by dropping a configuration snippet under /etc/chrony/sources.d. But the example config /etc/chrony/chrony.conf
always adds the default pool "2.debian.pool.ntp.org" unless you
modify the configuration file and comment it out, since the "pool" configuration directive can be used multiple times.
But isn't it what we already have? If I don't modify the example in /etc
and only add files to .d/, I'm getting upgrades without questions.
And if I modify the example in /etc, I'm getting the question. That way
I can decide per-package whether to just augment or change the
default configuration.
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.
Users who *don't* want that behavior can remove that package, and users
who *do* want that behavior could install it.
Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
Samuel Thibault wrote:
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
And it is actively harmful as if one edits the example configuration to have a useful configuration as dpkg will start annoying admins with "the example configuration has changed; what do you want to do" messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the configuration file.
Yes, that's why having both the ready-to-be-modified model *and* a .d/ directory fits both cases.
Then, we could have a package (e.g. "etc-commented-defaults") with an on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the case where they've been changed.
But isn't it what we already have? If I don't modify the example in /etc
On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
Samuel Thibault wrote:
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with "the example configuration has changed; what do you want to do" messages.
Yes, but the thing is: I *do* want to see that message, to make sure what changed upstream and fix my manual configuration accordingly.
There are (at least) two different models of handling configuration
here; people used to one model find the other to be awkward and cause problems, and vice versa.
In the model where you augment the default system configuration by
adding files in /etc, you ideally don't *need* a complete copy of the configuration file.
Yes, that's why having both the ready-to-be-modified model *and* a .d/ directory fits both cases.
I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?
What group of idiots came up with a system where instead of having all of the configs in maximum of two places (/etc | ~/.config) have now spread them out across five completely separate directory trees?
The group is called "The Linux Userspace API (UAPI) Group", and according to their home page, it consists of from people from Ubuntu Core, Debian, GNOME OS, Fedora CoreOS, Endless OS, Arch Linux, SUSE, Flatcar, systemd, image-builder/osbuild, mkosi, tpm2-software, System Transparency, buildstream, BTRFS, bootc, composefs, (rpm-)ostree, Microsoft, Amazon, and Meta.
You are free to disagree with this design, but please don't call the people behind it idiots. I am pretty sure there are plenty of very competent people who have given this a lot of thought.
I do tend to reserve my contempt to the few cases where it is appropriate.
But seriously, after 30+ years of working with various systems from NeXTStep to Windows to VAX, this all smacks of people who haven't learned anything from history and/or haven't spent enough time managing more than a few systems in one or two contexts.
"A lot of thought" in an echo chamber still has the same result, only worse. It reinforces itself without any real basis.
So now they're suggesting going down a road we've been down before. More than once.
Therefore, "idiots."
Sorry, but repeating history when nothing about the underlying situation has changed will never be smart.
--J
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random configuration bits, possibly from a random older version of the
package, intermixed with local configuration.
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the
local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.
It also avoids the problem of removed-but-not-purged packages.
On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.
It would obviously be ideal for stateless systems as well: http://0pointer.de/blog/projects/stateless.html
Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
What I completely fail to understand is why people would want to not
see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random configuration bits, possibly from a random older version of the
package, intermixed with local configuration.
With empty-/etc, you would (ideally) only have explicit local
configuration in /etc which makes it much, much easier to see what the local admin changed to diagnose problems, prepare upgrades and so on.
This is practically impossible now.
ucf should be able to provide this?
Put another way: it's not the presence of files in /etc that poses
problem. It's not having the shipped version at hand for comparing it.
Let's fix that rather than dropping something which is useful to admins.
It also avoids the problem of removed-but-not-purged packages.
With files copied into /etc, you will still have configuration files
lying around, and *not tracked*.
I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.
No, the model I was describing would have *no* file in /etc if you
remove `etc-commented-defaults`. The point here is to support the
users who want an empty /etc and the users who want files full of commented-out defaults.
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is
commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example
corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an
on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.
Users who *don't* want that behavior can remove that package, and users
who *do* want that behavior could install it.
Isnt this basically implementing the systemd approach, where a package
would ship default configuration in /usr/lib/package (with all defaults, which dont need to be commented out) and the user can override by
putting files in /etc/package -- either by copy-and-edit or just adding individual changes. (I think systemd-sysctl does this, also suppporting
/run/ for temporary changes?)
I think systemd can already tell you how the locations have been merged together (eg 'systemctl cat' does this), but perhaps what is missing is
a way to see what changed on upgrade (you'd want to save the clean
version from the _previous_ version of a package to be able to do that
after the upgrade)?
It seems way more often to me that I want to easily inspect/modify/amend
the configuration in /etc (without having to look whatever other place
to find out about the default configuration) than checking what changes
I have made to /etc which I may not want any more. And thus having a
special program for the latter looks completely fine to me. That's what people do with etckeeper and such already.
Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
I'm talking about the "empty /etc" model here, which is why I'm trying
to find a solution so that people who *want* the file-full-of-comments
have it, without installing it for people who *don't* want it.
What I completely fail to understand is why people would want to not see
any file in /etc. What harm does it *actually* cause?
And this is the root of the problem: you want one thing for understandable reasons, and other people, like myself, would prefer the opposite behavior
of having /etc empty by default for different understandable reasons. We
both understand the other's point of view and simply disagree about the merits of the features of the two methods.
Neither side of this preference is going to convince the other any more
than I am going to convince everyone to use Emacs, and yet every time we
have this discussion it turns into an extended effort to convince people
with the opposite preference.
Maybe it would be more productive to take the preference disagreement as given and then try to figure out how to proceed given that we're never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?
On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
In my (narrow) experience it's often the version number at the top and
typo and whitespace fixes.
Right now, the model we have is "some packages use the empty /etc model, some packages install commented-out defaults, and there's no
consistency". I'd love to move to the model of "all packages use
whichever model the sysadmin prefers".
Speaking as a sysadmin, I MUST ACCEPT the fact that I don't write this code. This is not my code. I can't always have my way. If the developer for a package decides that a different way is best for their package, so be it.
On 2024-12-19 Andrey Rakhmatullin <wrar@debian.org> wrote:
On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
And it is actively harmful as if one edits the example configuration to >>>> have a useful configuration as dpkg will start annoying admins with
"the example configuration has changed; what do you want to do"
messages.
Yes, but the thing is: I *do* want to see that message, to make sure
what changed upstream and fix my manual configuration accordingly.
In my (narrow) experience it's often the version number at the top and
typo and whitespace fixes.
Hello,
Please submit bug reports against packages keeping (and updating) the
version number in a dpkg conffile and triggerring unnecessary conffile >prompts.
Maybe our conffile handling should be modified to automatically
accept comment-only changes to dpkg-conffiles.
Greetings
Marc
Maybe it would be more productive to take the preference disagreement as given and then try to figure out how to proceed given that we're never
going to all agree on the best way of handling configuration files? Is
there some way that we can try to accomodate both groups?
On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
Right now, the model we have is "some packages use the empty /etc model, some packages install commented-out defaults, and there's no consistency". I'd love to move to the model of "all packages use whichever model the sysadmin prefers".
Speaking as a sysadmin, I MUST ACCEPT the fact that I don't write this code. This is not my code. I can't always have my way. If the developer for a package decides that a different way is best for their package, so be it.
Debian is not a distribution that says "whatever upstream does is always right". We have Debian Policy for a reason, and part of the point of a distribution is to ensure packages meet that policy, providing uniform behavior for sysadmins. Policies don't change overnight, but over time
we can steer in a general direction.
Suppose that packages ship sample configuration files *that exactly
match their defaults* (which should in general mean that everything is commented out) in some standardized path under /usr/share/doc/$package/
(e.g. examples/etc), that makes it easy to see what path the example corresponds to in /etc.
Then, we could have a package (e.g. "etc-commented-defaults") with an on-installation trigger for that location, which automatically copies
over the defaults to /etc if they don't already exist, updates them if
they match the defaults, and (ideally) has a ucf-style mechanism for the
case where they've been changed. That package could also provide scripts
for easily seeing the diffs between your configuration and all the
defaults.
As an example I'm familiar with iproute2 moved it's default config from /etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads* the config from there, it's not just example files so in that case upstream patching or symlink trickery would be required to make the package
conformant to this convention.
I've tried arguing this is a blatant disregard of policy but that fell on deaf ears so far.
On 23/12/24 16:23, Daniel Gröber wrote:
As an example I'm familiar with iproute2 moved it's default config from /etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads* the config from there, it's not just example files so in that case upstream patching or symlink trickery would be required to make the package conformant to this convention.
I've tried arguing this is a blatant disregard of policy but that fell on deaf ears so far.
How is that against policy?
Any configuration files created or *used* by your package must reside in /etc, [...]
All configuration files must reside in /etc.
Is it against policy to have default config values hardcoded in a binary?
Why things change if these hardcoded values are moved to a read-only file in /usr? (The user/admin configuration is still in /etc.)
Debian policy section 10.7.2:
Any configuration files created or *used* by your package must reside in
/etc, [...]
(Emphasis mine)
On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
Right now, the model we have is "some packages use the empty /etc model,
some packages install commented-out defaults, and there's no consistency". I'd love to move to the model of "all packages use whichever model the sysadmin prefers".
no one has a time to make non-upstream
compliant changes (some of which might require making semantic changes
in how config files work