Discussion:
Processed: Re: Bug#1090811: debian-installer: install linux-sysctl-defaults by default
(too old to reply)
Debian Bug Tracking System
2024-12-19 17:20:01 UTC
Permalink
reassign -1 general
Bug #1090811 [src:debian-installer] debian-installer: install linux-sysctl-defaults by default
Bug reassigned from package 'src:debian-installer' to 'general'.
No longer marked as found in versions debian-installer/20240914.
Ignoring request to alter fixed versions of bug #1090811 to the same values previously set
--
1090811: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1090811
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Chris Hofstaedtler
2024-12-19 21:00:02 UTC
Permalink
On Thu, Dec 19, 2024 at 12:12:13PM -0500, Noah Meyerhans wrote:
[..]
In theory, if we don't want to explicitly install the package in d-i,
another possibility might be to bump it to Priority: standard and let
tasksel install it. I'm not sure what the tradeoffs might be that would
drive the decision one way or another.
[..]
Regarding tasksel vs. Priority, the latter has a potential for a much
wider impact: lots of Debian system are installed without d-i and/or
tasksel, and most if not all would get the package via Priority. (Think
of all the tools building Debian images, chroots, containers, etc., on
top of debootstrap/mmdebstrap/etc.)
I'm not sure it's the case that most of those other systems install
Priority: standard. Debootstrap certainly doesn't by itself, and I
don't think the debuerreotype tool for building OCI images does either.
In any case, your point still stands. I'll re-assign this to general
for now, and we can discuss the options in a broader context.
We have a mechanism for installing iputils-ping into "most" systems, why
not use the same mechanism to install linux-sysctl-defaults?

Systems that want iputils-ping likely also want
linux-sysctl-defaults.

Chris
Noah Meyerhans
2024-12-19 21:40:02 UTC
Permalink
Post by Chris Hofstaedtler
In theory, if we don't want to explicitly install the package in d-i,
another possibility might be to bump it to Priority: standard and let
tasksel install it. I'm not sure what the tradeoffs might be that would
drive the decision one way or another.
[..]
Regarding tasksel vs. Priority, the latter has a potential for a much
wider impact: lots of Debian system are installed without d-i and/or
tasksel, and most if not all would get the package via Priority. (Think
of all the tools building Debian images, chroots, containers, etc., on
top of debootstrap/mmdebstrap/etc.)
I'm not sure it's the case that most of those other systems install
Priority: standard. Debootstrap certainly doesn't by itself, and I
don't think the debuerreotype tool for building OCI images does either.
In any case, your point still stands. I'll re-assign this to general
for now, and we can discuss the options in a broader context.
We have a mechanism for installing iputils-ping into "most" systems, why
not use the same mechanism to install linux-sysctl-defaults?
Systems that want iputils-ping likely also want
linux-sysctl-defaults.
Both iputils-ping and systemd declare Recommends on
linux-sysctl-defaults. The expectation is very much that it's installed
everywhere by default. The only reason it isn't today is that those
packages are installed by deboostrap, which doesn't install Recommends.

I believe that it's important for linux-sysctl-defaults to be part of
the default installation except in unusual cases. In addition to the
"make ping work" sysctl, it sets a number of other important sysctls
that should be set by default (e.g. net.core.default_qdisc,
fs.protected_symlinks, net.ipv4.conf.default.rp_filter and others).

These are system-wide settings that we don't want changed with the
installation of some package after the fact.

There are at least a couple of ways we can accomplish this:

* Raise the linux-sysctl-defaults priority to 'standard', which will get
it installed by tasksel under d-i while still leaving it out of other
debootstrapped installations (containers, etc)
* Raise its priority to 'important', in which case debootstrap will
install it

And there are probably more.

noah
Chris Hofstaedtler
2024-12-19 22:10:02 UTC
Permalink
Post by Noah Meyerhans
Post by Chris Hofstaedtler
In theory, if we don't want to explicitly install the package in d-i,
another possibility might be to bump it to Priority: standard and let
tasksel install it. I'm not sure what the tradeoffs might be that would
drive the decision one way or another.
[..]
Regarding tasksel vs. Priority, the latter has a potential for a much
wider impact: lots of Debian system are installed without d-i and/or
tasksel, and most if not all would get the package via Priority. (Think
of all the tools building Debian images, chroots, containers, etc., on
top of debootstrap/mmdebstrap/etc.)
I'm not sure it's the case that most of those other systems install
Priority: standard. Debootstrap certainly doesn't by itself, and I
don't think the debuerreotype tool for building OCI images does either.
In any case, your point still stands. I'll re-assign this to general
for now, and we can discuss the options in a broader context.
We have a mechanism for installing iputils-ping into "most" systems, why
not use the same mechanism to install linux-sysctl-defaults?
Systems that want iputils-ping likely also want
linux-sysctl-defaults.
Both iputils-ping and systemd declare Recommends on
linux-sysctl-defaults. The expectation is very much that it's installed
everywhere by default. The only reason it isn't today is that those
packages are installed by deboostrap, which doesn't install Recommends.
I believe that it's important for linux-sysctl-defaults to be part of
the default installation except in unusual cases. In addition to the
"make ping work" sysctl, it sets a number of other important sysctls
that should be set by default (e.g. net.core.default_qdisc,
fs.protected_symlinks, net.ipv4.conf.default.rp_filter and others).
Agreed.

[..]
[..]
Post by Noah Meyerhans
* Raise its priority to 'important', in which case debootstrap will
install it
And there are probably more.
For d-devel, I'll state that I'm in favor of raising the priority of
linux-sysctl-defaults to important.

Chris
Tianon Gravi
2024-12-20 00:00:01 UTC
Permalink
Control: reassign -1 general
Regarding tasksel vs. Priority, the latter has a potential for a much
wider impact: lots of Debian system are installed without d-i and/or
tasksel, and most if not all would get the package via Priority. (Think
of all the tools building Debian images, chroots, containers, etc., on
top of debootstrap/mmdebstrap/etc.)
I'm not sure it's the case that most of those other systems install
Priority: standard. Debootstrap certainly doesn't by itself, and I
don't think the debuerreotype tool for building OCI images does either.
In any case, your point still stands. I'll re-assign this to general
for now, and we can discuss the options in a broader context.
FWIW, we have added linux-sysctl-defaults to the sid/trixie VM images
built by the cloud team.
noah
I think "Priority: important" is probably appropriate here?

https://salsa.debian.org/installer-team/debootstrap/-/blob/c019a546a37b9284f0503c955d0f198044a7e2f0/scripts/debian-common#L29

Then it's installed by default in standard / d-i, but not part of minbase,
buildd, etc.

(It wouldn't affect/do anything in most container images or runtimes
anyhow, which is also an argument for it being harmless to include. 🀷)

❀,
- Tianon
Cyril Brulebois
2024-12-20 01:20:01 UTC
Permalink
I'm not sure it's the case that most of those other systems install
Priority: standard. Debootstrap certainly doesn't by itself, and I
don't think the debuerreotype tool for building OCI images does either.
In any case, your point still stands. I'll re-assign this to general
for now, and we can discuss the options in a broader context.
FWIW, we have added linux-sysctl-defaults to the sid/trixie VM images
built by the cloud team.
Sorry, I should have extended my reply a bit: I really meant “using the
Priority field” in general, not “Priority: standard” specifically.

Previous requests that reached us were generally about using (or moving
away from) “Priority: important” but my comment about the installer
team's not calling the shots stands. :) We do appreciate the heads-up
given by the ftp team when they end up dealing with such requests, since
priority changes led to some fun/fallout during the installation process
in the past.

Regarding this specific case I see Tianon's already followed up, so I'll
go quiet now. :)


Cheers,
--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Loading...