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.
> > > > 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
manpage, and instead its man 5 sysctl.d lists only files residing
in …/sysctl.d/ directories as being read; hence the legacy symlink.
> > > What does a regular file make different compared to a conffile
> > > concerning its handling?
> >
> > A conffile is user-managed, so any changes you make to a conffile must
> > be respected by the package. It can't just overwrite your changes, or
> > restore a conffile if you've deleted it.
>
> 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.
> * 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.
> 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?
SYSCTL.D(5) sysctl.d SYSCTL.D(5)
NAME
sysctl.d - Configure kernel parameters at boot
SYNOPSIS
/etc/sysctl.d/*.conf ← sysadmin's configuration overrides
/run/sysctl.d/*.conf ← ephemeral overrides
/usr/local/lib/sysctl.d/*.conf ← local package's overrides
/usr/lib/sysctl.d/*.conf ← Debian/systemd's default configuration
> > > > In unstable, apparently, *both* of them are gone.
> > >
> > > No, /etc/sysctl.conf is not gone on existing installations.
> > > It is just no longer read.
> >
> > It's... not? Then what the hell does the procps change text mean?
> >
> > > > while
> > > > <https://metadata.ftp-master.debian.org/changelogs//main/p/procps/procps_4.0.4-5_changelog>
> > > > says:
> > > > 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
> > > > * Updated /etc/sysctld.d/README
> >
> > That sure sounds like it's removed, to me.
>
> The changelog is just wrong... or actually the intended behavior
> was to remove the file, but this is buggy:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352
>
> But just removing the file is against the policy!
But two things:
. This [Policy] manual cannot and does not prohibit every
possible bug or undesirable behaviour.
. The Release Team can, at their discretion, downgrade
a Policy requirement to a Policy recommendation for
a given release of the Debian distribution.
and, of course, unstable is never released.
> Still, it must be
> removed because systemd's decision to remove the symlink was done
> based on the assumption that /etc/sysctl.conf no longer exists.
> IMHO, the best solution would be to propose to move it into
> "/etc/sysctld.d".
>
> > > only for *new* installations.
> >
> > Well... it's a conffile. If you made any changes to it, then the package
> > can't just remove it during an upgrade.
I don't think it would break Policy for a new empty configuration
file to be supplied. You would of course be warned and allowed to
keep your old version in the usual manner, even though it would
become impotent after the upgrade.
> > I'm not sure what would happen to an unmodified /etc/sysctl.conf file
> > during an upgrade. This isn't a common situation.
It gets blown away: "Obsolete configuration files without local
changes should be removed by the package during upgrade."
> On some of my machines (installed quite recently), I hadn't modified
> this file, and it wasn't removed.
Between bookworm and trixie, the migration issue for a modified
/etc/sysctl.conf file will have had to be sorted out. Perhaps it will
migrate it for you, presumably as 99-… so that it sorts in the same
way as now. AIUI your bug report should assist in that process, but
unstable is for finding these snags when packages are split, merged,
or otherwise refactorised.
Cheers,
David.
