On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:
> On 2024-07-28 00:07:56 -0500, David Wright wrote:
> > On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote:
> > > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:
> >
> > > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> > > > > The configuration got broken by a *systemd* upgrade:
> > > > >
> > > > > * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> > > > > /etc/sysctl.conf (Closes: #1076190)
> > > >
> > > > The systemd change was only done because of the procps change. After
> > > > the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
> > > > provided by the systemd package was dangling/broken. So the systemd
> > > > maintainer removed the symlink.
> > >
> > > No, the /etc/sysctl.conf file has not been removed (yet) for
> > > existing installations.
> > >
> > > If the goal were to fix the dangling symlink for new installations,
> > > then the solution should have been to no longer generate the
> > > /etc/sysctl.d/99-sysctl.conf symlink for new installations (and
> > > for existing installations, possibly remove it *only* if it was
> > > dangling).
> >
> > It looks accidental to me that systemd did that tidying up before
> > procps had attempted to remove the file that it (procps) owned.
>
> No, the breakage was done on purpose: my bug report specifically
> about this breakage by systemd was closed in a rather abrupt way:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184
I only wrote that the /order/ was accidental: upgrading systemd before
procps had removed its conffile. When the latter happens, you should
get asked about that conffile, and if not, then that's surely a bug
in procps, not systemd: procps owned the file, so procps disowned it.
In fact, here's procps disowning /etc/sysctl.conf:
procps (2:4.0.4-5) unstable; urgency=medium
* Add Recommends: linux-sysctl-defaults Closes: #1074156
* Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
(the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)
> > > > > > As it turns out, it's a combination of the two packages. In
> > > > > > bookworm,
> > > > > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > > > > the systemd package.
> >
> > That symlink was suggested as legacy support for reading the conf file
> > over a decade ago. Bullseye's man 8 sysctl indicates it still reads
> > /etc/sysctl.conf with its --system option, but bookworm lacks that
↑↑↑↑↑↑↑↑ trixie
> > manpage, and instead its man 5 sysctl.d lists only files residing
> > in …/sysctl.d/ directories as being read; hence the legacy symlink.
>
> No, I have a bookworm machine, and the sysctl.conf(5) man page is
> still there (in addition to the sysctl.d(5) man page).
Sorry, I meant to write trixie, not bookworm; stable and oldstable are
the same. Your complaint is with unstable.
> > > This is rather poor design, because
> > > * there isn't a way to say that some default setting must be
> > > preserved;
> >
> > There is: just add an empty comment line. Now you own that default.
>
> No, this is not sufficient. During an upgrade, a package is allowed
> to do a merge of the new defaults (this occurs quite frequently).
That doesn't square with Policy, and this typical dialogue that
we've all seen:
Configuration file `foo'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** foo (Y/I/N/O/D/Z) [default=N] ?
Might your merges apply to configuration files rather than conffiles?
> > > * changes by a user must be respected by the package, but a package
> > > may decide that such a file is no longer read!
> >
> > As I said, I think that happened by accident rather than design,
> > a consequence of refactorising two packages with two maintainers.
>
> See my bug report above.
I would file a bug against procps rather than systemd, for dropping
the conffile status of /etc/sysctl.conf. Once you upgrade to Debian's
4.0.4-5, that file becomes just any old file that you happen to have
under /etc/, and I don't see why systemd should be obliged to retain
the legacy symlink any longer.
Actually I think you already have.
> > > A better design could be to provide Debian / vendor defaults (which
> > > may change) by some kind of include mechanism. This is more or less
> > > what fail2ban does, with .conf files and .local files (the .conf
> > > files are not meant to be changed by the user, so that /usr/lib
> > > might be a better place than /etc).
> >
> > Um, isn't that what systemd provides as a matter of routine?
>
> More or less. In the systemd case, for each file, either one chooses
> it, i.e. one has all the current defaults, or one chooses to provide
> a replacement under /etc, i.e. one entirely replaces the defaults by
> one's own settings. An include mechanism would allow a finer control
> of the settings. The sysctl.d configuration system does not allow one
> to include a file (to get the current defaults and possibly change
> some of them just after).
Instead of having one big file /etc/sysctl.conf, systemd gives you any
number of small /etc/sysctl.d/*conf files for any and every individual
aspect of sysctl, and in addition you can order them. I don't see the
difference between that (at the filesystem level) and an include
mechanism (at the level of a file).
Cheers,
David.
