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

[Michael Marineau]

On Jun 14, 2014 11:55 AM, "Colin Walters" <walters at verbum.org> wrote:
>
> 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?

The sudo setup is a little different but in most cases where packages
depend on configs in /etc they are provided as symlinks that can be
replaced in place by a file. Simply removing the symlink likely breaks the
affected package so the link will be recreated on the next boot by
systemd-tmpfiles. I only consider this a short term solution, a missing
config should mean "use defaults" not "omg crash" which is the typical
behavior. :(

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

Agreed, but got to start somewhere!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140614/ed51fe76/attachment.html>