Re: goal: booting with an empty /etc

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

 



On Mon, Dec 11, 2023 at 11:36 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
>
> On 12/8/23 10:25, Stephen Gallagher wrote:
> > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> 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.
>
> I'd rather see defaults under somewhere in /usr/share rather than /usr/lib.
>

I agree with this. I really would rather it be in /usr/share.

> > 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.
>
> We could just have an /etc tree like we see now but in /usr/share/etc
> (or /usr/etc, but then I get IRIX nightmares) and your local overrides
> exist in /etc.  Things like fstab will probably just have to always be
> host-dependent so they will always exist in /etc.
>

We're currently not allowed to use /usr/etc (not that I like that path
anyway) because it breaks RPM-OSTree. My understanding is that this
directory is reserved by RPM-OSTree for storing pristine copies of
/etc content for each OSTree commit.

> For this to be really clean and nice, everything that drops a file in
> /etc needs to handle the "read in the default; then read in the optional
> local overrides" model.  I know a lot of stuff already does this, but
> some things don't.  It would be a nice goal to aim for and maybe we can
> submit patches to upstream projects where the functionality is missing.
>

Indeed.





--
真実はいつも一つ!/ Always, there's only one truth!
--
_______________________________________________
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