On Mon, 1 Jun 2020 David Wright wrote:
On Sun 31 May 2020 at 16:28:34 (+0700), Victor Sudakov wrote:
David Wright wrote:
On Fri 29 May 2020 at 21:57:06 (+0700), Victor Sudakov wrote:
[big snip]
I, too, was surprised by some Debian features like its tendency
to start daemons with a vanilla configuration right after
installation. Still can't say I like this decision.
This has been discussed in the past.
Idly curious for links, in case anyone has them at hand. (Not asking
anyone to search for me, but not curious enough to search for everyone
else.)
[David Wright continued:]
Using the term "vanilla" suggests that an ordinary upstream
configuration is applied to the daemon, which is not true: the
Debian developers apply what they consider are sensible secure
defaults, designed to integrate with the distribution. This work
is usually documented in changelog.Debian.gz or various READMEs.
[Victor Sudakov asked:]
Is the /usr/sbin/policy-rc.d method still the official supported
one of disabling this behavior when it is not desirable?
I have for a while assumed that this is what
/etc/systemd/system-preset/*.preset
files are for (on systems with systemd).
Selective excerpts from systemd.preset(5):
NAME
systemd.preset - Service enablement presets
SYNOPSIS
/etc/systemd/system-preset/*.preset
/run/systemd/system-preset/*.preset
/lib/systemd/system-preset/*.preset
/etc/systemd/user-preset/*.preset
/run/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
DESCRIPTION
Preset files may be used to encode policy which units shall be
enabled by default and which ones shall be disabled. They are read
by "systemctl preset" (for more information see systemctl(1)) which
uses this information to enable or disable a unit according to
preset policy. "systemctl preset" is used by the post install
scriptlets of RPM packages (or other OS package formats), to
enable/disable specific units by default on package installation,
enforcing distribution, spin or administrator preset policy.
[With respect to that last bit about the post install scriptlets of
packages, see my note at bottom.]
This allows choosing a certain set of units to be enabled/disabled
even before installing the actual package.
For more information on the preset logic please have a look at the
Presets document [at
https://www.freedesktop.org/wiki/Software/systemd/Preset/ ].
[...]
PRESET FILE FORMAT
The preset files contain a list of directives consisting of either
the word "enable" or "disable" followed by a space and a unit name
(possibly with shell style wildcards), separated by newlines. [...]
[...] Files in /etc/ override files with the same name in /usr/lib/
and /run/.
Files in /run/ override files with the same name in /lib/.
Packages should install their preset files in /lib/. Files in /etc/
are reserved for the local administrator, who may use this logic to
override the preset files installed by vendor packages. [...]
EXAMPLES
Example 1. Default to off
# /lib/systemd/system-preset/99-default.preset
disable *
This disables all units. Due to the filename prefix "99-", it will
be read last and hence can easily be overridden by spin or
administrator preset policy.
[...]
Example 3. Administrator policy
# /etc/systemd/system-preset/00-lennart.preset
enable httpd.service
enable sshd.service
enable postfix.service
disable *
This enables three specific services and disables all others. This
is useful for administrators to specifically select the units to
enable, and disable all others. Due to the filename prefix "00-" it
will be read early and override all other preset policy files.
It's many years since I ran servers in what one might call "hostile"
environments,
(Myself I claim no experience whatsoever.)
so the current situation suits me, and I don't keep up with
discussions like those in
https://manpages.debian.org/experimental/policy-rcd-declarative/policy-rc.d-declarative.8.en.html
So others would have to comment here, after the discussion of
resetting Windows has subsided.
NOTE
Regarding,
"systemctl preset" is used by the post install scriptlets of RPM
packages (or other OS package formats), to enable/disable specific
units by default on package installation, enforcing distribution,
spin or administrator preset policy.
it seems we are not supposed to take that (weirdly
distro-inappropriate) language too literally:
$ for deb in /var/cache/apt/archives/*.deb ; \
> do dpkg-deb -I $deb preinst postinst 2>/dev/null ; \
> done |
> grep -i 'preset' ; \
> if [ $? == 1 ] ; then echo SORRY BOSS ; fi
SORRY BOSS
Nonetheless, doing like so before issuing "apt-get install privoxy"
# echo disable privoxy.service >>
/etc/systemd/system-preset/05-privoxy-test.preset
yields this installation message
[...]
Creating config file /etc/privoxy/config with new version
privoxy.service is a disabled or a static unit, not starting it.
instead of this one:
[...]
Creating config file /etc/privoxy/config with new version
Created symlink /etc/systemd/system/multi-user.target.wants/privoxy.service →
/lib/systemd/system/privoxy.service.
So it appears to work, though any understanding of the causal chain
eludes me.
--
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe. The frost giant turns to flee.
