Re: opentmpfiles & opensysusers, and its use in the Debian policy
On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote:
> On Thu, Jan 2, 2020 at 9:22 PM Thomas Goirand <zigo@debian.org> wrote:
> [...]
> > My proposal is for Debian to standardize on:
> > /bin/tmpfiles
> >
> > and:
> > /usr/bin/sysusers
FWIW, the systemd versions of both tools are canonically in /bin (that's
their only location on the non-merged-/usr systems where it matters) so
it might be best to stay consistent with that. They're named systemd-foo
because that's systemd's convention for tools that are meant to be only
rarely run by hand, like a weaker version of the GNU Coding Standards'
${libexecdir} (tools that are meant to be run by hand more frequently,
like loginctl, don't get that prefix).
> I don't understand why we need these.
>
> The advantages of sysusers.d and tmpfiles.d are that you don't need to
> call some magic scripts.
> You only need to write declarative configuration files.
Individual packages only need to install declarative configuration files,
but the OS distribution infrastructure needs to do something to make
the contents of those configuration files take effect (and, crucially,
know when the implementation has finished running).
On systemd systems, that's approximately:
- run systemd-tmpfiles when a package installs a tmpfiles.d snippet
(this is added to the package's postinst by dh_installsystemd)
- run systemd-sysusers when a package installs a sysusers.d snippet
(I don't think we have tools to add this to the postinst yet, because
packages are currently meant to run adduser --system instead, but
more-systemd-centric distributions probably already do this in their
equivalent of the postinst)
- run systemd-tmpfiles during boot (this is systemd-tmpfiles-setup.service,
part of systemd)
- run systemd-sysusers during boot (this is
systemd-sysusers.service, part of systemd)
The opentmpfiles and opensysusers packaging will need to arrange to do
something analogous, most likely in cooperation with dh_installsystemd
or some other debhelper step for the first two points, and with LSB init
scripts for the tasks where systemd uses one-shot services.
Using dpkg triggers to run the tmpfiles and sysusers tools automatically
is probably not enough, because a package's postinst will often run system
services (systemd unit, LSB init script, etc.), and those system services
need to be run *after* creating at least this package's tmpfiles hierarchies
and system users, because they probably rely on those directories and users
to work correctly.
At the moment, the policy is that system users are created by running
adduser, and installing sysusers.d files is allowed but redundant. For
example, dbus installs /usr/lib/sysusers.d/dbus.conf, but doesn't rely
on it being processed - the postinst calls adduser, so the sysusers.d
snippet will only have any effect if the messagebus user somehow gets
deleted, in which case systemd-booted systems will recover by recreating
it during the next boot.
smcv
Reply to: