On Jun 14, 2014 11:55 AM, "Colin Walters" <<a href="mailto:walters@verbum.org">walters@verbum.org</a>> 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: > > <a href="https://github.com/coreos/coreos-overlay/blob/master/sys-apps/dbus/files/dbus-1.6.x-add-explicit-etc-path.patch">https://github.com/coreos/coreos-overlay/blob/master/sys-apps/dbus/files/dbus-1.6.x-add-explicit-etc-path.patch</a> > > 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. <a href="https://github.com/coreos/nss-altfiles">https://github.com/coreos/nss-altfiles</a> > > 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: <a href="http://blog.verbum.org/2014/01/24/why-ostree-requires-usretc/">http://blog.verbum.org/2014/01/24/why-ostree-requires-usretc/</a> > > > 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!