On Fri, Dec 08, 2023 at 10:25:34AM -0500, Stephen Gallagher wrote: > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > > > 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. > > > > One thing that is becoming much more common is for us to ship such > static files in /usr/lib and include a default symlink in /etc for > those packages whose presence there is effectively API (for example > /etc/os-release is a symlink to /usr/lib/os-release, similarly > /etc/resolv.conf). I think this is a very good approach and one that > we should probably look at formalizing in the packaging guidelines.
Those two are not great examples. Those files are widely used, so we cannot really move them. But: /etc/os-release does not have to exist at all. The API is "check for /etc/os-release, and if that doesn't exist, read /usr/lib/os-release". /etc/resolv.conf nowadays is not really a config file, because it's dynamically managed (by systemd-resolved or NetworkManager or some cloud config or config mgmt system). Both of those symlinks are recreated automatically by tmpfiles on boot. But also, a symlink is not great. The admin is likely to open the editor on the symlink and edit the wrong thing by mistkae. Symlinks are a compatiblity machinism. We should do those if there's no other choice. But for majority of programs, the only consumer of that config is one program or a few closely related programs, and we should just teach them to support multiple locations and move the file. > That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/* > and /etc/fstab which are both API *and* sometimes see manual updates. > These are some of the cases that are going to make getting to an empty > /etc very hard to finish off. There's a lot of low-hanging fruit we > can take care of in the meantime, but getting the last 1% of packages > done is going to take a lot of inter-distro conversations. /etc/fstab is local configuration, so it actually belong in /etc. Also, most systems don't need /etc/fstab at all, location of the basic partitions is autodetected. Neal answered about PAM. But yeah, there'll always be a few "special" files. But that's fine, we have mechanisms to handle those. For the other 99%, we should move them out of /etc. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
