Re: policy for shipping sysctl.d snippets in packages?
Hi Josh,
On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote:
> Evgeni Golov wrote:
> > LXC recently got a bug (#860974) that is best fixed by bumping a certain
> > sysctl limit above the default.
>
> Note that in addition to going this route, you might consider talking with the
> kernel maintainers about increasing the default limit, or potentially even
> getting the limit raised upstream.
This *specific* issue should go away as soon as we have user-ns aware inotify
counters [1], so it's thankfully just a temporary band-aid.
> > However I could not find any documented policy how to do this (if at all).
> >
> > Both, procps and systemd support (/usr)?/lib/sysctl.d/*.conf, however only
> > one package (systemd-coredump) uses it, all others drop files in
> > /etc/sysctl.d.
> >
> > Some packages also trigger "sysctl -q -p <file>" in their postinst, but
> > most do not.
> >
> > My gut feeling is that droping the file to /usr/lib and allowing the admin
> > to override it later via /etc. And then load it in postinst.
>
> That seems like exactly the right approach, and yes, you should put it
> in /usr/lib/50-yourpackagename.conf , following the conventions
> explicitly established for that purpose.
Do you have a pointer to the conventions?
Neither /etc/sysctl.d/README.sysctl, nor sysctl.conf(5) or sysctl.d(5)
have anything on naming, besides "*.conf".
And the current in-archive packages are not telling much either:
% apt-file search sysctl.d
bit-babbler: /etc/sysctl.d/bit-babbler-sysctl.conf
corekeeper: /etc/sysctl.d/corekeeper.conf
dms-core: /etc/sysctl.d/30-dms-core-net.conf
dms-core: /etc/sysctl.d/30-dms-core-shm.conf
freedombox-setup: /etc/sysctl.d/freedombox.conf
linux-grsec-base: /etc/sysctl.d/grsec.conf
postgresql-common: /etc/sysctl.d/30-postgresql-shm.conf
systemd: /etc/sysctl.d/99-sysctl.conf
systemd-coredump: /usr/lib/sysctl.d/50-coredump.conf
tracker-miner-fs: /etc/sysctl.d/30-tracker.conf
uhd-host: /etc/sysctl.d/uhd-usrp2.conf
> That makes it easy for the
> sysadmin to override *either* by directly creating a file with the same
> name in /etc *or* by adding a file later in the sequence to tweak
> individual settings, both of which can easily be done in packages for
> sysadmins who want to package their configuration tweaks. (By contrast,
> a configuration package can't safely tweak or override existing files in
> /etc, only drop in a file later in the sequence.) This also makes it
> easy to use tools to identify any local overrides, or to just look in
> /etc and see at a glance only what the sysadmin has modified, not large
> swathes of stock values.
>
> Effectively, the bits installed in /usr/lib (or /lib) represent the
> stock state of the package (similar to compiled-in defaults, but more
> easily adjusted by the distribution without patching).
>
> This is something that people have argued over in the past, and will
> likely continue to argue over; it's also highly correlated with general
> argument over systemd, since systemd is the most popular package
> following and encouraging this configuration pattern, though not the
> first such package. However, this pattern is supported by upstream
> convention, convention across multiple distributions (meeting sysadmin
> expectations), and existing use by many other packages already in
> Debian.
Agreed.
> > But this does not account for the fact that this specific tunable may be
> > already overriden in another sysctl.d file and the package would reset
> > it to a lower value?
>
> You might ask systemd upstream if they'd consider extending the syntax
> to support "increase if below this value but don't decrease". But in
> the absence of that, I don't think you need to worry about that kind of
> configuration conflict unless it comes up. Ideally if multiple packages
> need to change this limit, they'll coordinate and agree on the new
> value, or perhaps even depend on a common configuration package.
I think such an extension would be quite tricky and probably not worth it.
Thanks
Evgeni
[1] https://patchwork.kernel.org/patch/9370199/
Reply to: