Re: tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)
On 2/19/20 1:55 AM, Michael Hudson-Doyle wrote:
> On Fri, 3 Jan 2020 at 06:29, Simon McVittie <smcv@debian.org
> <mailto:smcv@debian.org>> wrote:
>
> On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote:
> > 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.
>
>
> So in Ubuntu we got this interesting
> bug https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which
> can be summarized as saying that haproxy doesn't work out of the box in
> a docker container, because it installs a tmpfiles.d snippet but nothing
> processes it (I haven't tried, but I very much expect that the behaviour
> is the same between Debian and Ubuntu here).
>
> On the face of it, this is a bug in the package: it depends for its
> operation on a package not listed in Depends but making the package
> depend on systemd wouldn't actually be very useful for getting it
> running in docker, for a few reasons. I think it would be better to
> change debhelper:
>
> * to add "systemd | opentmpfiles" to misc:Depends whenever a package
> installs a tmpfiles.d snippet
> * stop checking for -d /run/systemd/system in
> autoscripts/postinst-init-tmpfiles and check for systemd-tmpfiles /
> opentmpfiles in $PATH instead (and using the one that is found, obviously)
Well, not right now, as we're still not sure on how this will happen,
and what the tech ctte will decide. I'm hoping for a resolution where
the TC will decide what we should do, both in terms of packaging
opemtmpfiles and systemd, and how packages should use them.
> Obviously there are a few variations on the above, like:
>
> * splitting a systemd-tmpfiles package out of the systemd package first
I very much hope this will happen. Though the bug has been opened for a
while already, and I see no communication from systemd maintainers about
it (or did I miss it?).
> * change systemd(-tmpfiles) and opentmpfiles to Provides: tmpfiles and
> use alternatives to provide /usr/bin/tmpfiles, have debhelper reference
> these instead
What you describe above means that we will not have a cross-distro
/sbin/systemd-tmpfiles interface/path. That's annoying. Which is why
it'd be just preferred if opentmpfiles just use systemd's path. Though
that's still under discussion. I also hope that the TC will give
guidance for this.
The "Provides: tmpfiles" is really something I'd love we have.
> Does it make sense to people here? I can try to work on a patch
> (although my perl isn't the greatest).
Very much. Though IMO, it's not up to a single person to decide what
Debian should do.
Cheers,
Thomas Goirand (zigo)
Reply to: