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

"Jóhann B. Guðmundsson" johannbg at gmail.com
Fri Apr 11 15:40:28 UTC 2014


On 04/11/2014 03:22 PM, Lennart Poettering wrote:
> 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:
>> /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.

Interesting I expected a new /foo directory to emerge which provided the 
functionality you described and FSH be evolve accordingly as things 
progressed further into this direction but based on what you say here 
you are indicating that cannot happen as in /etc must be the directory 
that provides this.

Is that the case or am I missing something?

JBG


More information about the devel mailing list