fedora-atomic discussion point: /usr/lib/passwd

[Lennart Poettering]

On Fri, 11.04.14 15:05, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:

> 
> On 04/11/2014 02:47 PM, Lennart Poettering wrote:
> >On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
> >
> >>On 04/11/2014 02:34 PM, Lennart Poettering wrote:
> >>>Within the systemd project we have been working on a scheme we call
> >>>"factory" where packages can drop in static descriptions in /usr/lib of
> >>>stuff they need in /etc and /var to work properly. The idea is to then
> >>>use this information automatically at boot if systemd finds /etc and
> >>>/var empty to populate them.
> >>I dont think /etc the right place to be used here based on the
> >>evolution taking place so suggest containers should source that from
> >>elsewhere.
> >I cannot parse this?
> 
> /etc is "administrator space" and evolving into "administrator only
> space" which means eventually nothing will be placing or flushing or
> populating there  other then the administrators themselves.
> 
> In other words if containers have to "populate" /etc they are doing
> it wrong hence the overall design is wrong

I wish it was that easy. It's not though.

During early boot /etc+/usr are available, but /var is not. System users
must be available during early boot (hence cannot be configured in
/var), and (as indicated earlier in this thread) must also be
manipulatable for the admin (hence cannot be configured in /usr). This
means they need to be stored in /etc, which pushes us towards having to
populate /etc when empty, rather than supporting entirely empty /etc
boots.

And it doesn't stop there. We have binary caches in /etc, like the
selinux policy, hwdb, ... which must be available during early boot but
also aren't so static and immutable that they could be located in
/usr. WHich also means that they need a regeneration step at boot.

Similar for /etc/machine-id, which is something we should always and
unconditionally provide, which needs to be regenerated when /etc is
flushed, and where we cannot support entirely empty /etc boots.

And then, there's the elephant in the room: it's unlikely we can fix
*all* Linux software to be fine with an empty /etc anytime soon. Sure,
systemd itself is carefully prepared to handle this correctly, but we
ship so much old cruft that noody wants to touch, that we need a softer
transition here, and thus need to prvide a way to populate /etc.

I mean, I fully agree that the populating logic should be minimal. We
really shouldn't push more stuff in /etc than really strictly necessary,
but I fear we really have to allow it for the strictly basic stuff, it's
unavoidable.

Lennart

-- 
Lennart Poettering, Red Hat