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

[Colin Walters]

On Fri, Jun 13, 2014, at 12:35 PM, Michael Marineau wrote:
>
> 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

Interesting.  A clean patch might be worth submitting upstream to dbus
for this, i.e. one where it just automatically reads
/usr/share/dbus-1/config or so, supporting overrides in /etc.  I don't
think you'd find anyone today who would defend the current dbus XML and
policy layout, but then again, it was designed in 2001-2002.

It also predates PolicyKit, and back then the thought was that admins
might have to edit the XML to e.g. disallow users from accessing
NetworkManager type services.

I know kdbus is on the horizon, but there'll be services installing
policy files there for quite a while, and it would make sense to move
the ones that really don't have any reason to be configured by admins,
which at least on my workstation is most of them.

> 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

Right.  I think nss-altfiles won't be needed anymore potentially if this
systemd scheme works out.

> 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.

Mmmm...I'd say configuring with --sysconfdir=/usr/share is definitely an
unusual hack =)

> 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. 

systemd has an excellent implementation of this, with a substantial
amount of tooling on top.  "systemd-delta" is quite cool.  But it
requires a lot of though to integrate for various projects, because you
have to carefully think about what should be the defaults, and how the
system administrator can override.

For example, if you have default sudo configuration in /usr/share, is
there a way an admin can mask that?  I think from your patch you
generate a symlink they can unlink?

> 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. 

Yes: http://blog.verbum.org/2014/01/24/why-ostree-requires-usretc/

> If packages did their best to avoid
> installing files to /etc, giving users exclusive control over that
> space, everyone wins. :)

I agree cleanup in this area makes a ton of sense; if more projects
worked like systemd the world would be better.  But there's a large gap
between --sysconfdir=/usr/share/ and systemd's implementation.