[Pkg-puppet-devel] Bug#775795: puppet: Service's debian provider assumes SysV init

[Faidon Liambotis]

Package: puppet
Version: 3.7.2-1
Severity: serious

Hi,

Puppet has an abstraction concept called "provider" for its types.  The
Service type, one of puppet's basic types, is implemented by multiple
different providers, depending on the underlying init system.  There is
the "init" provider, which implements SysV init semantics, "systemd" &
"upstart" which implement systemd and upstart semantics respectively,
etc. The default provider on each system is assigned using facter rules,
apparently relying on "operatingsystem" and "osfamily" facts.

On Debian systems (i.e. on $::operatingsystem == "debian"), the default
provider is "debian"; this is a separate provider that inherits the
"init" provider but overrides a few methods to add invoke-rc.d support.
The systemd provider, on the other hand, is default only for osfamily
"archlinux" and for osfamily "redhat" && operatingsystemmajrelease 7.

This is obviously broken behavior -- puppet shouldn't make assumptions
about the init system a system runs purely from its OS version. That is
mostly tracked upstream with PUP-2023[1].

This is especially broken for jessie default installs, which are systemd
now. Service definitions -probably amongst the most used ones- are
assuming init.d semantics, unless "provider => systemd" is supplied as
an argument. The only reason puppet is not completely broken on jessie
is that most packages still ship an init.d script alongside a system
service file and LSB init-functions make sure those init.d scripts call
systemctl instead.

However, this means that Service (without an explicit provider) is
broken for at least those two use cases:
- enable => false/true doesn't work for packages that ship a systemd
  unit file,
- Service doesn't work at all with user-supplied systemd units or for
  (custom, mostly) packages that do not ship init.d scripts.

This is borderline important & serious in my mind, but it is a
regression for Wheezy and it should probably be fixed in time for
jessie, so I'm setting this to an RC severity.

This could be potentially worked around by setting systemd as the
default provider for kernel == Linux && operatingsystem == Debian &&
operatingsystemmajrelease >= 8. This would be a hack, of course, as
jessie optionally supports booting with SysV as well so a more
dynamic/runtime check will be a better but more complicated fix.

Regards,
Faidon

1: https://tickets.puppetlabs.com/browse/PUP-2023