[systemd-devel] [ANNOUNCE] systemd 216

[Colin Guthrie]

Lennart Poettering wrote on 20/08/14 14:54:
> On Wed, 20.08.14 09:40, Dave Reisner (d at falconindy.com) wrote:
> 
>>>> The sysusers.d file shipped with this has:
>>>>
>>>>   u systemd-journal-remote        -               "systemd Journal Remote"
>>>>
>>>> But the tmpfiles.d fragment has:
>>>>
>>>>   z /var/log/journal/remote 2755 root systemd-journal-remote - -
>>>>   z /run/log/journal/remote 2755 root systemd-journal-remote - -
>>>>
>>>> There's no "systemd-journal-remote" group created...
>>>
>>> In sysusers, each system user will always implicitly get a group of the
>>> same name too.
>>>
>>
>> Ok, I see that now. Digging into the logic of how this works, sysusers
>> will probably never run after an online update. Is the expectation that
>> distros just run systemd-sysusers in their post_upgrade scripts?
> 
> Yes. Though it is slightly more complicated than that. Some users need
> to be created by packages before the first file of the package is
> installed, so that files can be owned by the users in question. For
> users like that you actually need to invoke the tool *before* unpacking
> the package. Now, of course, given that the user info is supposed to be
> stored in one of those files that are supposed to be installed we'd have
> a chicken-and-egg problem here: we'd like to create the users before the
> files that include the user definition are installed.
> 
> We break that cycle by also offering a way how user systemd-sysusers can
> be invoked with reading its data from stdin. The idea is then that the
> packages in question duplicate the user definition inline in the pre
> package, if they need users that exist before the package is installed.
> 
> Yeah, it's not pretty, but we couldn't come up with anything better.

Presumably it would be possible to create a suitable filter in RPM to do
this automatically as part of the build... I'm quietly hoping so, but
guessing not!

Still it's not *that* bad.

I guess another "solution" is that for a good chunk of these files, they
would reside in /var and that *should* be something that is actually
shipped as a tmpfile snippet anyway, not something that is actually
"packaged" per-se... (although %ghosting would be nice). And assuming
sysusers and tmpfiles are run as e.g. filetriggers (they are here) then
the chicken and egg problem goes away! But sadly, this is not a
universal solution - plus it's a lot of work on the packaging side. Ho hum!

Cheers for the info re the packaging bits. Good to know as I was just
thinking about this stuff over the last few days.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/