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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel