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

[Michael Marineau]

On Fri, Jun 13, 2014 at 6:37 AM, 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 what its worth, in my efforts to make CoreOS boot with a
completely empty root filesystem I found that the changes required
were usually not too dramatic. Fixing many packages, like sudo, just
amounted to shipping different config files and adding
--sysconfdir=/usr/share to ./configure at build time. For dbus it only
takes that configure option plus a update to session.conf and
system.conf to support both /usr/share/dbus-1 and /etc/dbus-1 for
configs: https://github.com/coreos/coreos-overlay/blob/master/sys-apps/dbus/files/dbus-1.6.x-add-explicit-etc-path.patch

Where new code is required it is similarly not very complicated, to
support reading account information, services, hosts, and other nss
data files we have a small project that is just a strait-up copy of
the files nss module from glibc with some hard coded paths changed to
configurable macros. https://github.com/coreos/nss-altfiles

So working through all these details is a damn tedious task and I
don't doubt it could be years before we and others get around to
getting good support for reading configuration from both /usr and /etc
into upstream packages. The good news is that while we bang out the
best way to implement this the changes aren't any weirder than the
patches and hacks that distros typically have to do when integrating
packages.

As a side note, regardless of whether an empty /etc is actually viable
or not the more packages that support gracefully dealing with
configuration in both /etc and /usr the fewer files there will be in
/etc that are in the awkward position of being managed by both users
and packages. rpm and dpkg's behavior of just picking one and backing
up the other or gentoo's scheme of forcing users to wade through 3-way
diffs are all pretty terrible. If packages did their best to avoid
installing files to /etc, giving users exclusive control over that
space, everyone wins. :)