Is an init required to obey policy-rc.d during boot ?

[Lorenzo]

[ 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

Re: Is an init required to obey policy-rc.d during boot ?

[Andrej Shadura]

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

Re: Is an init required to obey policy-rc.d during boot ?

[Andreas Henriksson]

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 ?

[Simon McVittie]

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 ?

[Sam Hartman]

> "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).

Bug#958472: ITP: telemetry-tempest-plugin -- OpenStack Integration Test Suite - Telemetry plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: telemetry-tempest-plugin
  Version : 1.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/telemetry-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Telemetry plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Telemetry plugin.

Bug#958475: ITP: murano-tempest-plugin -- OpenStack Integration Test Suite - Murano plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: murano-tempest-plugin
  Version : 2.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/murano-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Murano plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Murano plugin.

Re: Bits from the new DPL

[Benjamin Abels]

unsubscribe

On Tue, Apr 21, 2020 at 3:28 PM Jonathan Carter  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> My fellow Debianites,
>
> It's been one month, one week and one day since I decided
> to run[1] for this DPL term. The Debian community has been
> through a variety of interesting times during the last
> decade, and instead of focusing on grand, sweeping changes
> for Debian, core to my DPL campaign was to establish a
> sense of normality and stability so that we can work on
> community building, continue to focus on technical excellence
> and serve our users the best we can.
>
> Thing don't always work out as we plan, and for many of us,
> Debian recently had to take a back seat to personal
> priorities. Back when I posted my intention to run, there
> were 125 260[2] confirmed cases of COVID-19 globally.
> Today, that number is 20 times higher[3], with the actual
> infected number likely to be significantly higher. A large
> number of us are under lock-down, where we not only fear the
> disease and its effect on local hospitals and how it will
> affect our loved ones, but also our very likelihoods and the
> future of our local businesses and industry.
>
> I don't mean to be gloomy with the statement above, I am
> after all, an optimist - but unfortunately it does get even
> worse. Governments and corporations around the world have
> started to take advantage COVID-19 in negative ways and are
> making large sweeping changes that undermine the privacy and
> rights of individuals everywhere.
>
> For many reasons, including those above, I believe that the
> Debian project is more important and relevant now than it's
> ever been before. The world needs a free, general purpose
> operating system, unburdened by the needs of profit, which puts
> the needs of its users first, providing a safe and secure
> platform for the computing needs of the masses.
>
> While we can't control or fix all the problems in the world,
> we can control our response to it, and be part of the solutions
> that bring the change we want to see.
>
> During my term as DPL, I will be available to help with
> problems in our community to the maximum extent that my time
> permits. If we help ourselves, we will be in a better position
> to help others. If you (or your team) get stuck and are in need
> of help, then please do not hesitate to e-mail[4] me.
>
> == A few thank-yous ==
>
> As incoming DPL, I'd like to thank Sam Hartman on behalf of the
> project for the work that he's done over the last year as DPL.
> It's a tremendous time commitment that requires constant
> attention to detail.
>
> On Sunday, Sam and I had a handover meeting where we discussed
> various DPL responsibilities including finances, delegations
> (including specifics of some delegations), legal matters,
> outreach and other questions I had. I'd also like to thank Sam
> for taking the time to do this.
>
> Thank you to Sruthi Chadran and Brian Gupta who took the time
> to also run for DPL this year. Both candidates brought
> important issues to the forefront and I hope to work with both
> of them on those in the near future.
>
> == DPL Blog ==
>
> Today, I've started a new blog for the Debian Project Leader to
> help facilitate more frequent communication, and to reach a
> wider audience via Planet Debian. This will contain
> supplemental information to what I send to the
> debian-devel-announce[6] mailing list. It's not quite up yet,
> I'll share a link once it's available.
>
> == Want to help? ==
>
> In my platform[7], I listed some key areas that I'd like to
> work on. My work won't be limited to those, but it should give
> you some idea of the type of DPL that I'll be. If you'd like to
> get involved, feel free to join the #debian-dpl channel on the
> oftc IRC network, and please introduce yourself along with any
> areas of interest that you'd like to contribute to.
>
> - -Jonathan, Debian Project Leader
>
> [1] https://lists.debian.org/debian-vote/2020/03/msg7.html
>
> [2]
> https://www.who.int/docs/default-source/coronaviruse/situation-reports/2
> 0200312-sitrep-52-covid-19.pdf?sfvrsn=e2bfc9c0_4
> 
>
> [3]
> https://www.who.int/docs/default-source/coronaviruse/situation-reports/2
> 0200421-sitrep-92-covid-19.pdf
> 
>
> [4] mailto:lea...@debian.org
>
> [5] https://lists.debian.org/debian-devel-announce/
>
> [6] https://www.debian.org/vote/2020/platforms/jcc
>
> - --
>   ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
>   ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
>   ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
>   ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl6fV2wACgkQsB0acqyN
> yaGZRg/8CE9m7bb4hasz8xyPMOg81bs3IQu+B6AXGw7

Bug#958481: ITP: python3-yoyo-migrations -- database schema migration tool

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: python3-yoyo-migrations
  Version : 7.0.2
  Upstream Author : Oliver Cope 
* URL : https://pypi.org/project/yoyo-migrations/
* License : Apache software license
  Programming Lang: Python
  Description : database schema migration tool

Yoyo is a database schema migration tool.
You write database migrations as Python scripts containing raw
SQL statements or Python functions.

Extra information on this packaging:
 - I wish to maintain this package together with DPMT
 - This library is a dependency for the authenticator gnome app which I would
   like to package as well once dependencies are resolved.

Bug#958486: ITP: python3-text-unidecode -- text-unidecode is the most basic port of the Text::Unidecode Perl library.

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 

* Package name: python3-text-unidecode
  Version : 1.3
  Upstream Author : Mikhail Korobov 
* URL : https://pypi.org/project/text-unidecode/
* License : Artistic License
  Programming Lang: Python
  Description : text-unidecode is the most basic port of the 
Text::Unidecode Perl library.

Extra information on this packaging:
 - I wish to maintain this package together with DPMT
 - This library is a dependency for the authenticator gnome app which I would
   like to package as well once dependencies are resolved.

Re: Is an init required to obey policy-rc.d during boot ?

[Thomas Goirand]

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 ?

[Michael Biebl]

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 ?

[Marvin Renich]

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