goal: booting with an empty /etc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

There is a long-term goal of moving packaged files out of /etc, so that
only actual local configuration remains in /etc. This has some advantages:

- Local configuration, i.e. the result of local administrative actions,
  is nicely split from static configuration that is part of package payload.
  'find /etc' will show what is special to this local system, while
  'find /usr' lists stuff that is part of packages and the same between
  systems.
- We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
  to return everything to distro defaults. We're not there _yet_, but it
  works with a surprisingly large subset of packages.
- We can support "factory reset" at a package level, by removing all the
  configuration and state of an individual package, without reinstalling it
  (possibly combined with some tmpfiles.d config to recreate things
  automatically.)
- It becomes easier to build systems which are delivered as a stand-alone
  /usr-partition. This could be ostree-style systems, or image-based systems
  with the /usr-partition read-only and protected by dm-verity. We're not
  there _yet_, but many people are experimenting with this.

When one looks in /etc, many of the files there are not "configuration".
For example, /etc/services is a list of port:service mappings, and people
maybe used to edit that twenty years ago, but now it's just a static file
that just as well may be somewhere under /usr/lib/. The same is also
true for /etc/bash_completion.d/ — people do not edit completion scripts.
Most of those have been moved to /usr/share/bash-completion/completions/,
but there's still a dozen or so in /etc.

Another common case is "empty" configuration files, i.e. templates that show the
default configuration. E.g. systemd has files that show commented-out defaults,
so if the file is removed, there is no change in behaviour.

Other distributions are ahead of us in supporting empty /etc. In particular,
OpenSUSE has done a lot of work with libeconf, which adds support for
systemd-style config in /usr/lib, /etc, and /run, and has convinced various
projects to switch to libeconf and allow empty /etc. There is a specification
codifying best practices in this area at:
https://uapi-group.org/specifications/specs/configuration_files_specification/

systemd-255-3.fc40 that was just built for rawhide moves "empty" config files
from /etc/systemd to /usr/lib/systemd. Systemd programs look in both locations,
so there should be no change in behaviour. Ideally, when administrators want
to make local modifications, they will use a drop-in file, instead of editing
the main config file, so the location of the main config file doesn't matter.
(To make this all nicer, we have
  systemd-analyze cat-config
which will display all config files in priority order, including drop-ins, and
we now added
  systemd-analyze cat-config --tldr
which will suppress "empty" stuff (empty lines and comments).)

If you are a maintainer of a package with files in /etc, please consider
whether they are strictly necessary, and if possible, move stuff to /usr.

If you are a maintainer of an upstream project, make sure that it supports
loading files from under /usr, so that the distro can put its config files there.

See https://github.com/uapi-group/specifications/issues/76 for a tracker
bug with a list of usptream projects which don't support this.

At some point, I think we should make this an explicit goal in Fedora.
I don't think we're at the point yet where it'd be feasible to put this
in Packaging Guidelines, but we can already convert individual packages.

Zbyszek
(on behalf of various folks working on this)
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux