Re: Is an init required to obey policy-rc.d during boot ?
On Fri, 24 Apr 2020 at 12:41:01 +0200, Simon Richter wrote: > On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote: [Simon Richter wrote:] > > > Can maintainer scripts expect systemd services to be available (mainly > > > thinking about tmpfilesd here, but there might be others that become > > > relevant in the future)? > > > To be clear about that, there is no tmpfilesd daemon: the d in tmpfiles.d > > stands for directory like rc2.d, not daemon like sshd. On package > > installation, tmpfiles.d fragments are processed by maintainer scripts > > (driven by dh_installtmpfiles), without taking policy-rc.d into account. > > Yes, I stumbled across this mostly because samba now fails to configure on > sysvinit systems because /var/run/samba is missing -- so there is an > expectation the maintainer script has that isn't met anymore. That would be > Policy territory. I believe the current situation is that tmpfiles.d fragments are only processed by maintainer scripts or during boot if systemd is the current init system, so any package that wants to support being used under a non-systemd init (or with no init at all) cannot rely on tmpfiles.d fragments to have created its transient directories first. If this is something you need, I'd suggest sending a tested patch that creates /run/samba on a just-in-time basis when needed (in the LSB init script, or in the maintainer script if those need it) - I expect that'll involve one line doing a 'mkdir -p' in the right place. However, systemd units *are* entitled to assume that tmpfiles.d has been processed, because tmpfiles.d is part of systemd's documented interface. For example, the dbus system service requires /var/lib/dbus. /lib/systemd/system/dbus.service assumes that a tmpfiles.d fragment to set up /var/lib/dbus has already been processed, but /etc/init.d/dbus cannot make that same assumption, and creates /var/lib/dbus itself if necessary; I believe that's a correct implementation. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269 proposes making tmpfiles.d a recommended interface, but that is not currently Policy. sysusers.d is basically "the same shape" as tmpfiles.d, although current best-practice in Debian is to use adduser rather than relying on sysusers.d. Packages can ship sysusers.d fragments (and for example dbus does), but they won't usually have any practical effect, because adduser ran first. smcv
Re: Is an init required to obey policy-rc.d during boot ?
Hi, On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote: > policy-rc.d and invoke-rc.d are not documented in Policy to be a way to > control what happens after you reboot, and neither sysv-rc nor systemd > runs invoke-rc.d or consults policy-rc.d during normal system boot. Ah, that explains it. I was under the impression that policy-rc.d would also be evaluated during normal boot (but since it is removed after installation, it would do nothing unless the admin added another local one). > Just to make sure I wasn't spreading misinformation, I tested this in > a VM, using sysvinit: Mh, I checked that by reading the scripts, and arrived at the same conclusion. Sorry for the noise. > systemd targets do have a well-defined interface, described in > systemd.target(5) and in the KERNEL COMMAND LINE section of systemd(1). > However, if you are setting up special-purpose targets, that's getting > into OS design rather than sysadmin territory (the line between the two > is of course very blurred, and the difference between a special-purpose OS > and an extensively configured instance of a general-purpose OS is mostly > a matter of point of view). Yes, that's basically what I'd expect people to do in complex installations, and a large part of Debian's role is to enable them to do that. Shipping a system that runs well on single machines is the easy part, and since most of the integration work for that has moved from distributions into systemd, there is little that differentiates us from the others for that use case. > > Can maintainer scripts expect systemd services to be available (mainly > > thinking about tmpfilesd here, but there might be others that become > > relevant in the future)? > To be clear about that, there is no tmpfilesd daemon: the d in tmpfiles.d > stands for directory like rc2.d, not daemon like sshd. On package > installation, tmpfiles.d fragments are processed by maintainer scripts > (driven by dh_installtmpfiles), without taking policy-rc.d into account. Yes, I stumbled across this mostly because samba now fails to configure on sysvinit systems because /var/run/samba is missing -- so there is an expectation the maintainer script has that isn't met anymore. That would be Policy territory. Simon
Re: Is an init required to obey policy-rc.d during boot ?
On Thu, 23 Apr 2020 at 16:59:43 +0200, Simon Richter wrote:
> The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the
> appropriate way to start an init script in Policy, so sysadmins have a
> reasonable expectation that all init scripts use that mechanism.
It's documented in Policy as the appropriate way for *a maintainer
script* to start an init script. debhelper-generated maintainer-script
fragments in packages that have systemd services often don't actually
use invoke-rc.d any more, but they do use deb-systemd-invoke, a
Debian-specific program closely resembling invoke-rc.d; it does similar
checks, including policy-rc.d. Policy should ideally document those two
as being equally valid, if it doesn't already.
policy-rc.d and invoke-rc.d are not documented in Policy to be a way to
control what happens after you reboot, and neither sysv-rc nor systemd
runs invoke-rc.d or consults policy-rc.d during normal system boot.
Just to make sure I wasn't spreading misinformation, I tested this in
a VM, using sysvinit:
- apt install sysvinit-core (systemd is removed)
- reboot
- write "#!/bin/sh\nexit 101\n" into /usr/sbin/policy-rc.d
- apt install apache2
(prints "invoke-rc.d: policy-rc.d denied execution of start")
- pgrep apache (no output)
- reboot
- pgrep apache (now it is running)
> As far as I can see, there is no similar mechanism in systemd that allows
> blanket refusal or logging of unknown services, only masking of known
> services by name.
Taking a step back from policy.d specifically (since it is not a suitable
tool to control what happens during boot), I think your statement is
correct, but that's a bit like saying there's no mechanism in Unix
that allows blanket refusal or logging of unknown executable programs,
only deleting or `chmod -x` known programs by name.[1] Yes, it's true;
but if there was such a mechanism, a large part of its practical effect
would be to prevent the programs you do want, some of which probably
run unknown-to-you programs as an implementation detail, from working
correctly.
systemd.preset(5) (see below) is probably the closest. However, systemd
services can and do depend on other services (some of which might be an
implementation detail of how a larger, user-facing service is broken up
into modules, rather than something directly user- or network-facing). If
they do, both targets and presets will normally start the depended-on
service, in order to make the dependent service work.
If you have looked at everything that depends on a specific service
and decided that, even at the risk of breaking the dependent services,
you still don't want to run it, that's what masking services is for.
> On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote:
> > In a systemd-based system, I would achieve the equivalent of #950851
> > by telling systemd to start a restricted target that only contains the
> > services I specifically want, instead of the default 'graphical.target'
> > (targets are analogous to sysvinit runlevels, but you can have any number
> > of them). Perhaps runit has, or could have, something similar?
>
> Can that be automated through a well-defined interface, to allow sysadmins
> overseeing larger installations to control this centrally through one of
> the automation frameworks?
The submitter of #950851 was talking about special-purpose, single-use
containers, rather than about full machines with sysadmins and a normal
init system, and my suggestion was specific to that use-case. (Containers
as a heavier-weight alternative to a chroot, rather than containers as
a lighter-weight alternative to a VM.)
systemd targets do have a well-defined interface, described in
systemd.target(5) and in the KERNEL COMMAND LINE section of systemd(1).
However, if you are setting up special-purpose targets, that's getting
into OS design rather than sysadmin territory (the line between the two
is of course very blurred, and the difference between a special-purpose OS
and an extensively configured instance of a general-purpose OS is mostly
a matter of point of view).
If (as it sounds like to me) your use-case is not the same as that of the
submitter of #950851, and you want to control what (high-level, user-
and/or network-facing) services are started on a full machine that has
a sysadmin and a normal init system and "mostly" boots in the normal
Debian way, I'd suggest looking into systemd.preset(5) instead.
Debian's normal policy is that "most" installed services get started on
boot ("enabled" in systemd terminology), on the assumption that if you
don't want the service, you wouldn't install it. Our systemd's default
behaviour is configured accordingly.
In systemd-using OSs that are more like the Red Hat family, where a
standard installation includes a lot more potentially-unwanted services
and as a result the policy is that "most" installed services *don't*
get started on boot (not "enabled"), the systemd.preset(5) mechanism is
how that policy is
Re: Is an init required to obey policy-rc.d during boot ?
Am 23.04.2020 um 16:59 schrieb Simon Richter: > As far as I can see, there is no similar mechanism in systemd that allows > blanket refusal or logging of unknown services, only masking of known > services by name. The method of using a custom target comes closest, is > there a namespace of target names that can be used by sysadmins that will > never conflict with upstream target names? Just in case this is not obvious to everyone: deb-systemd-invoke (which is what's used in maintainer scripts of packages using dh_installsystemd) does respect policy-rc.d (although policy-rc.d is a rather horrible interface tbh). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Is an init required to obey policy-rc.d during boot ?
Thanks everybody for your help :) On 4/22/20 4:09 PM, Simon McVittie wrote: > [ ... ] > In a systemd-based system, I would achieve the equivalent of #950851 > by telling systemd to start a restricted target that only contains the > services I specifically want, instead of the default 'graphical.target' > (targets are analogous to sysvinit runlevels, but you can have any number > of them). Perhaps runit has, or could have, something similar? > > smcv Yes, I think I will try something similar with a dedicated service directory that by default provides only one getty plus one getty on serial tty. Lorenzo
Re: Is an init required to obey policy-rc.d during boot ?
Hi, On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote: > In a systemd-based system, I would achieve the equivalent of #950851 > by telling systemd to start a restricted target that only contains the > services I specifically want, instead of the default 'graphical.target' > (targets are analogous to sysvinit runlevels, but you can have any number > of them). Perhaps runit has, or could have, something similar? Can that be automated through a well-defined interface, to allow sysadmins overseeing larger installations to control this centrally through one of the automation frameworks? The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the appropriate way to start an init script in Policy, so sysadmins have a reasonable expectation that all init scripts use that mechanism. We have two custom implementations in the archive (policy-rcd-declarative and policyrcd-script-zg2), and I'd expect that lots of others exist that are local to installations. As far as I can see, there is no similar mechanism in systemd that allows blanket refusal or logging of unknown services, only masking of known services by name. The method of using a custom target comes closest, is there a namespace of target names that can be used by sysadmins that will never conflict with upstream target names? Can maintainer scripts expect systemd services to be available (mainly thinking about tmpfilesd here, but there might be others that become relevant in the future)? Simon
Re: Is an init required to obey policy-rc.d during boot ?
On Thu, 23 Apr 2020, Thomas Goirand wrote: doesn't exist but will proceed) - apt install foo (shipping a foo.service) → foo.service will not be started Good to know, thanks! Is https://www.freedesktop.org/software/systemd/man/systemd.preset.html perhaps something that could help here? -Timo
Re: Is an init required to obey policy-rc.d during boot ?
On 4/23/20 1:42 AM, Michael Biebl wrote: > Am 23.04.20 um 00:43 schrieb Thomas Goirand: >> On 4/22/20 4:11 PM, Sam Hartman wrote: > >>> And a native interface for a sysadmin overriding that (masking). >> >> Unless I'm mistaking, that's not useful if you want to disable starting >> the daemon before installing it (ie: before the .service exists in the >> system). > > Your assumption is wrong. You can mask a service before installing a package > - systemctl mask foo.service (will issue a warning that foo.service > doesn't exist but will proceed) > - apt install foo (shipping a foo.service) > → foo.service will not be started Good to know, thanks! Thomas
Re: Is an init required to obey policy-rc.d during boot ?
Reply-To debian-devel@lists.debian.org: In-Reply-To: * Michael Biebl [200422 19:43]: > Am 23.04.20 um 00:43 schrieb Thomas Goirand: > > On 4/22/20 4:11 PM, Sam Hartman wrote: > > >> And a native interface for a sysadmin overriding that (masking). > > > > Unless I'm mistaking, that's not useful if you want to disable starting > > the daemon before installing it (ie: before the .service exists in the > > system). > > Your assumption is wrong. You can mask a service before installing a package > - systemctl mask foo.service (will issue a warning that foo.service > doesn't exist but will proceed) > - apt install foo (shipping a foo.service) > → foo.service will not be started With the limitation that you need to know, before installing the package, the names of all the services it contains. ...Marvin
Re: Is an init required to obey policy-rc.d during boot ?
Am 23.04.20 um 00:43 schrieb Thomas Goirand: > On 4/22/20 4:11 PM, Sam Hartman wrote: >> And a native interface for a sysadmin overriding that (masking). > > Unless I'm mistaking, that's not useful if you want to disable starting > the daemon before installing it (ie: before the .service exists in the > system). Your assumption is wrong. You can mask a service before installing a package - systemctl mask foo.service (will issue a warning that foo.service doesn't exist but will proceed) - apt install foo (shipping a foo.service) → foo.service will not be started signature.asc Description: OpenPGP digital signature
Re: Is an init required to obey policy-rc.d during boot ?
On 4/22/20 4:11 PM, Sam Hartman wrote: >> "Andreas" == Andreas Henriksson writes: > > Andreas> Hello, FWIW I do not share Andrej Shaduras view on this. My > Andreas> interpretation is basically the opposite. The invoke-rc.d, > Andreas> policy-rc.d and update-rc.d policy mandated abstraction is > Andreas> solely for the use of maintainer scripts in debian packages > Andreas> (and should not be used by init systems or elsewhere). > > Andreas> Note also that the 'service' utility abstraction, which is > Andreas> supposed to be for (interactive) administator usage also > Andreas> does not care about policy-rc.d (as designed). > > And note that all of the above is only for init scripts. > As an example systemd has a native interface for turning on and off > service units. > (disable/enable). > And a native interface for a sysadmin overriding that (masking). Unless I'm mistaking, that's not useful if you want to disable starting the daemon before installing it (ie: before the .service exists in the system). Cheers, Thomas Goirand (zigo)
Re: Is an init required to obey policy-rc.d during boot ?
> "Andreas" == Andreas Henriksson writes: Andreas> Hello, FWIW I do not share Andrej Shaduras view on this. My Andreas> interpretation is basically the opposite. The invoke-rc.d, Andreas> policy-rc.d and update-rc.d policy mandated abstraction is Andreas> solely for the use of maintainer scripts in debian packages Andreas> (and should not be used by init systems or elsewhere). Andreas> Note also that the 'service' utility abstraction, which is Andreas> supposed to be for (interactive) administator usage also Andreas> does not care about policy-rc.d (as designed). And note that all of the above is only for init scripts. As an example systemd has a native interface for turning on and off service units. (disable/enable). And a native interface for a sysadmin overriding that (masking).
Re: Is an init required to obey policy-rc.d during boot ?
On Wed, 22 Apr 2020 at 14:20:13 +0200, Lorenzo wrote:
> In bug #950851 the reporter says that runit is not policy compliant
> because during boot it does not check the policy-rc.d hack before
> starting sysv services.
>
> However I read policy 9.3.3 as referring to maintainer scripts (
> install, upgrade, remove) but I can't find anything about
> boot or shutdown.
You are correct. Other init systems do not consult policy-rc.d during
boot, and runit probably shouldn't either.
policy-rc.d only determines what happens when a package with a service
is installed or upgraded, most importantly during initial installation:
- install a machine/VM/container/chroot/thing with some init system
(historically sysvinit/sysv-rc) and without, for example, apache2
- install apache2
- is apache2 running now? The answer should depend on policy-rc.d.
For systemd, this logic is implemented by deb-systemd-invoke - but it's
rarely needed, because chroots that were not "booted" in the usual
way don't have systemd running, even if it is installed, so there is
no systemd instance that could take responsibility for starting the
service anyway.
For sysv-rc, this logic is implemented by invoke-rc.d - but it's rarely
needed now, because invoke-rc.d does not normally start services when it
detects that it is running in a chroot or with no init system installed,
which was the most common reason to want policy-rc.d in the past.
When a machine gets *rebooted*, the services that get started are
determined by the init system's concept of whether a service is "enabled"
or not. For sysv-rc and systemd, update-rc.d and deb-systemd-helper
work together to make sure that if /etc/init.d/apache2 is enabled in
/etc/rc*.d, then the corresponding systemd unit
/lib/systemd/system/apache2.service is enabled in /etc/systemd/system/,
and vice versa.
Services that get started manually by a sysadmin, either via the
init-agnostic service(8) or an init-system-specific mechanism like
'systemctl start', do not check policy-rc.d either.
Container frameworks vary in whether they behave like a more powerful
version of a chroot, with no init system or boot procedure (Docker is
designed to be used like this); or whether they behave like a lightweight
virtual machine, with a full init system and a real-machine-like boot
procedure (lxc is designed to be used like this); or whether it is
user-defined (systemd-nspawn is designed to work either way, and Docker
technically can too, although the full-machine-like mode is usually
discouraged for Docker containers).
> In my mind the severity of that bug ranges from
> wishlist ("please implement this new feature") to important (policy-rc.d
> is part of an interface that is defined in policy and has a should for
> maintainer scripts)
The reporter of #950851 describes a use-case that might be useful (being
able to install runit in a container and use it to launch selected
services, without having it manage or start *all* the services that
would normally run at boot-time, such as LSB init scripts). Having a
way to make that happen is a valid wishlist bug. However, I don't think
policy-rc.d is a good way to implement that feature.
In a systemd-based system, I would achieve the equivalent of #950851
by telling systemd to start a restricted target that only contains the
services I specifically want, instead of the default 'graphical.target'
(targets are analogous to sysvinit runlevels, but you can have any number
of them). Perhaps runit has, or could have, something similar?
smcv
Re: Is an init required to obey policy-rc.d during boot ?
Hello, FWIW I do not share Andrej Shaduras view on this. My interpretation is basically the opposite. The invoke-rc.d, policy-rc.d and update-rc.d policy mandated abstraction is solely for the use of maintainer scripts in debian packages (and should not be used by init systems or elsewhere). Note also that the 'service' utility abstraction, which is supposed to be for (interactive) administator usage also does not care about policy-rc.d (as designed). Regards, Andreas Henriksson
Re: Is an init required to obey policy-rc.d during boot ?
Hi, On Wed, 22 Apr 2020 at 14:20, Lorenzo wrote: > Is an init required to implement a mechanism like policy-rc.d or it's > optional? Yes. > It has to be policy-rc.d or it can be a different (native) one? It has to be policy-rc.d. -- Cheers, Andrej
Is an init required to obey policy-rc.d during boot ?
[ please keep me in CC ]
Hello,
In bug #950851 the reporter says that runit is not policy compliant
because during boot it does not check the policy-rc.d hack before
starting sysv services.
However I read policy 9.3.3 as referring to maintainer scripts (
install, upgrade, remove) but I can't find anything about
boot or shutdown. In my mind the severity of that bug ranges from
wishlist ("please implement this new feature") to important (policy-rc.d
is part of an interface that is defined in policy and has a should for
maintainer scripts)
I can think of many ways to fix #950851 but I'm unsure if solutions I'm
thinking about are policy compliant or not, for example:
Is an init required to implement a mechanism like policy-rc.d or it's
optional?
It has to be policy-rc.d or it can be a different (native) one? Maybe
policy.rc-d is mandatory only for
sysv scripts but not for runit services?
It has to be effective only for maintainer script, or it has to cover
every way to start a service?
It has to be effective also during system boot?
Regards,
Lorenzo
