[systemd-devel] new user/group population on bootup

[Lennart Poettering]

On Fri, 13.06.14 06:37, Colin Walters (walters at verbum.org) wrote:

> 
> On Fri, Jun 13, 2014, at 05:36 AM, Colin Walters wrote:
> 
> > My high level takeaway right now is that this looks OK for nspawn
> > containers, but it's not clear to me it's viable or right for the host
> > OS, at least for general purpose systems.
> 
> That was wrongly stated - basically I'm just skeptical of seeing an
> empty /etc on general purpose systems in the next few years, at least
> without lots of non-upstream patches and hacks.  A good example is this:
>
>https://github.com/coreos/baselayout/commit/98c6211c45c8c53d84df1657776314cc5f5f9ec1

For cases like this I would simply ask:

a) the upstream developers to always check some file in /usr/ somewhere
   as fallback, if the file they are looking for in /etc doesn't exist. For
   sudo this means: check /etc/sudoers first, and use that if it exists as
   only source. If it doesn't, fallback to /usr/lib/sudo/sudoers or so,
   which is some vendor supplied default. Alternatively, in many cases
   instead of such a fallback it might also be a good choice to just build
   some defaults into the code itself (for example, that's what logind does
   if /etc/systemd/logind.conf is missing, it will not consult
   anything else).

b) for packagers that need a quick solution, or where upstream cannot or
   will not make such a change I'd recommend to simply drop in some
   tmpfiles snippet that copies the absolute minimum over from
   /usr/share/etc to /etc, but only the absolute minimum necessary. To
   make this easy, I will add a new tmpfiles directive for easy copying
   of files /usr/share/etc → /etc. Note however, that not even this
   sounds necessary for things like apache for example. After all apache
   is something that inherently needs configuration. It is kinda useless
   without. If apache fails to start after a factory reset, then that
   appears quite OK, until you actually dropped in configuration
   again...

> The other stuff like update-done.service looks useful, though lately
> I've been thinking that we should try to do as much as possible before
> reboot as well - stuff like journalctl --update-catalog already supports
> --root, which will work for OSTree because it has a separate root.

Well, in our model, where we want one golden master /usr of which we
want to boot one 100 containers, we need the ability to apply changes to
/etc and /var "offline", and hence after rebooting. If you just change
the golden master tree, and that fixes the master's /etc and /var, then
that's not too useful because those directories will not be replicated
to the instances...

Lennart

-- 
Lennart Poettering, Red Hat