Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023 at 12:53:00PM -0500, Stephen Smoogen wrote: > > > 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. There isn't much real difference between /usr/share and /usr/lib. Officially /usr/share is for stuff that is "shared between architectures", but the approach of mounting in /usr/share and actually _sharing_ it between different systems separately from /usr has mostly gone away. Realistically, any location under /usr is going to share the same storage, become available at the same point during boot (very very early), and be ro/rw in the same way. So I guess individual projects will pick a specific location in a way that makes the the most sense to them. https://uapi-group.org/specifications/specs/configuration_files_specification/ says: "The precise location under /usr/ is left open for the implementation to decide - it could be hard-coded to /usr/lib/ or it could be left to each application to pick from various options, such as /usr/share/ or /usr/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. Ah, that's a bummer. I think some projects are using /usr/etc, so this is going to become a problem. > My other problem with using /usr/etc is if we decide in N years that we > want to get rid of /usr altogether (reverse usrmerge so /usr/sbin -> /sbin, > /usr/bin -> /bin etc) and put everything at top-level.. we have to then > figure out where we would put all this content anyway. No, this is not going to happen. With /usr, the whole OS is a single mount point. So for example, it's easy to have a system where the OS is delivered as a dm-verity-protected signed read-only partition, and the root is a writable-fs-over-luks, created on the fly when the machine is first booted. With "reverse usrmerge", we get a bunch of directories which need to be handled separately, making things harder and less clean. It also doesn't bring any benefit, so I don't see why we'd want to go through the pain of a move. > At some point I think we are also looking at large enough changes that we > need to 'update FHS' and similar guidelines mainly so that third party > standards and tools can know where things 'should' go. FHS is alive as https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html (and the XDG standards for files under $HOME). I think that the recommendations there describe the consensus in the Linux ecosystem. 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
Re: goal: booting with an empty /etc
On Mo, 11.12.23 11:10, DJ Delorie (d...@redhat.com) wrote: > Lennart Poettering writes: > > Well, as you might be aware many distributions these days do more than > > "files dns" for "hosts", and similar for the other databases, and > > hence a built-in default in glibc is great, but most distributions and > > image builders probably want to pick different defaults without having > > to patch glibc for this. > > I agree. My point was that (1) glibc has a built-in default, and (2) > most distros/users/installers customize it anyway, so storing a > "default" version anywhere other than /etc is not needed. This doesn't work though. Take Fedora for example. It supports a systemd feature called "DynamicUser=". If you turn that on for some service it will get a transient UID assigned the moment it is started and it's released again when it is stopped. It's a resonably popular feature. It requires that the "nss-systemd" modules is listed in nsswitch.conf. The glibc built-in default does not list "systemd" in its nsswitch.conf line though. On Fedora, the module is patched in via /etc/nsswitch.conf. But then you already lost, because now the distro default and the configuration the user made are all mixed up in a hairy ball and cannot be separated anymore. I don't think it's realistic to ask the glibc maintainers to change their built-in version of nsswitch.conf to always list systemd though (as that doesn't even make sense in many cases, i.e. when you run glibc inside a docker container without any systemd). Hence it makes sense to isolate this cleanly: 0. have upstream defaults built-in to the binaries, where this applies 1. have distro/OS image defaults in /usr/ 2. have user's own configuration in /etc/ That's a very clear separation of ownership, and means you can always very clearly trace back where a change comes from, and combine things flexibly in a multitude of ways without ever losing this concept of provenance. In systemd we have a tool "systemd-delta" which makes use of this separation of ownership, and allows you to diff local settings vs. distro/OS defaults. Lennart -- Lennart Poettering, Berlin -- ___ 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
Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023, at 12:31 PM, Neal Gompa wrote: > > 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. If there was general consensus on using /usr/etc in upstreams/OSes/distros outside of having it be an implementation detail of ostree (mostly today) then we could certainly figure out how to support having content from RPMs (and other sources) in /usr/etc. But consensus has been for projects to use other places (/usr/share or /usr/lib) - which I agree with too - so there's no need to keep bringing this up AFAICS. -- ___ 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
Re: goal: booting with an empty /etc
On 12/11/23 12:31, Neal Gompa wrote: > On Mon, Dec 11, 2023 at 11:36 AM David Cantrell wrote: >> >> On 12/8/23 10:25, Stephen Gallagher wrote: >>> On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek >>> 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. Right, my mention of /usr/etc in parens was merely to mention some directory I remember from IRIX. The documentation noted that /usr/etc was for "Critical system configuration files and maintenance commands" which was not to be confused with /etc on IRIX which was for "Critical system configuration files and maintenance commands". :) I think /usr/share/etc would be appropriate for Fedora. >> 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@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 -- David Cantrell Red Hat,
Re: goal: booting with an empty /etc
On Mon, 11 Dec 2023 at 12:34, Neal Gompa wrote: > On Mon, Dec 11, 2023 at 11:36 AM David Cantrell > wrote: > > > > On 12/8/23 10:25, Stephen Gallagher wrote: > > > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > > > 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. > > My other problem with using /usr/etc is if we decide in N years that we want to get rid of /usr altogether (reverse usrmerge so /usr/sbin -> /sbin, /usr/bin -> /bin etc) and put everything at top-level.. we have to then figure out where we would put all this content anyway. At some point I think we are also looking at large enough changes that we need to 'update FHS' and similar guidelines mainly so that third party standards and tools can know where things 'should' go. > > 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@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:
Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023 at 11:36 AM David Cantrell wrote: > > On 12/8/23 10:25, Stephen Gallagher wrote: > > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > > 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@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
Re: goal: booting with an empty /etc
On 12/8/23 10:25, Stephen Gallagher wrote: > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > 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. > 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. 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. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT -- ___ 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
Re: goal: booting with an empty /etc
Lennart Poettering writes: > Well, as you might be aware many distributions these days do more than > "files dns" for "hosts", and similar for the other databases, and > hence a built-in default in glibc is great, but most distributions and > image builders probably want to pick different defaults without having > to patch glibc for this. I agree. My point was that (1) glibc has a built-in default, and (2) most distros/users/installers customize it anyway, so storing a "default" version anywhere other than /etc is not needed. -- ___ 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
Re: goal: booting with an empty /etc
Once upon a time, Peter Boy said: > I would like to go even further and also separate distribution default code > and locally installed code in the /usr tree. OpenSuse has developed a good > proposal for this some time ago. More separation than /usr vs. /usr/local? -- Chris Adams -- ___ 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
Re: goal: booting with an empty /etc
On 12/11/23 09:55, Peter Boy wrote: Am 11.12.2023 um 15:09 schrieb David Both : What is the objective of achieving this "boot with empty /etc"? What does it accomplish? What problem does it solve? For me, from a sysadmin POV, the great advantage is the clear separation of sysadmin made configuration and distribution provided (default) configuration. It makes the life of a sysadmin much easier, easier backup and selective restore, easier hunting for the cause of issues in a local app configuration, easier recovery and easier rebuild of a system that has become completely unusable. And all this for an RPM-based system and has nothing to do with containers. However, I would consider a simple and unmistakable structure, i.e. 2 separate directories with XFS or BTRFS file system, to be reasonable and not an overlay file system. This only makes the recovery in emergency mode and limited tool availability prone to errors. I would like to go even further and also separate distribution default code and locally installed code in the /usr tree. OpenSuse has developed a good proposal for this some time ago. The nice thing about the overlay solution is that individual commands would not need to be modified to understand the new configuration. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast -- ___ 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 -- ___ 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
Re: goal: booting with an empty /etc
> Am 11.12.2023 um 15:09 schrieb David Both : > > What is the objective of achieving this "boot with empty /etc"? What > does it accomplish? What problem does it solve? For me, from a sysadmin POV, the great advantage is the clear separation of sysadmin made configuration and distribution provided (default) configuration. It makes the life of a sysadmin much easier, easier backup and selective restore, easier hunting for the cause of issues in a local app configuration, easier recovery and easier rebuild of a system that has become completely unusable. And all this for an RPM-based system and has nothing to do with containers. However, I would consider a simple and unmistakable structure, i.e. 2 separate directories with XFS or BTRFS file system, to be reasonable and not an overlay file system. This only makes the recovery in emergency mode and limited tool availability prone to errors. I would like to go even further and also separate distribution default code and locally installed code in the /usr tree. OpenSuse has developed a good proposal for this some time ago. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast -- ___ 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
Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023 at 09:09:33AM -0500, David Both wrote: > > I think I understand the immediate goal here, but I am still confused. > What is the objective of achieving this "boot with empty /etc"? What > does it accomplish? What problem does it solve? Is it a solution for a > small use case such as containers or something else? What problem does > it solve for me - a sysadmin with a few servers and some workstations? > > If the answer is in one of the early bits of this thread, could you > point me to it please? https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UCVYQVWHYPGYRB7U47WJWJP5CRLFSLCZ/ I'd be happy to talk more about this, if this is not clear. 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
Re: goal: booting with an empty /etc
I think I understand the immediate goal here, but I am still confused. What is the objective of achieving this "boot with empty /etc"? What does it accomplish? What problem does it solve? Is it a solution for a small use case such as containers or something else? What problem does it solve for me - a sysadmin with a few servers and some workstations? If the answer is in one of the early bits of this thread, could you point me to it please? Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Mon, 11 Dec 2023, Zbigniew Jędrzejewski-Szmek wrote: Date: Mon, 11 Dec 2023 08:35:08 From: Zbigniew Jędrzejewski-Szmek Reply-To: Development discussions related to Fedora To: Florian Weimer Cc: Development discussions related to Fedora Subject: SPAM (302.2) Re: goal: booting with an empty /etc On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote: * Zbigniew Jędrzejewski-Szmek: No, it would be the other way round. We might have a /usr/share/glibc/services which contains :include: /etc/services somewhere in it. Ah, OK. I understand how the format would look, but I don't understand why you'd want to implement it rather than something simpler. /etc/services is essentially a flat file that is scanned from top to bottom until a matching entry is found. In the proposed syntax, it'd need to have ':include: /etc/services' at the very top, so that the local config in /etc/services has higher priority. Consider the following alternative: each of [/etc/services, /usr/etc/services] is scanned in order, if the file exists. This is simpler to implement and allows either of the files to exist independently of the other. A stanza like ':include:' also opens the door for additional complications like different paths on different distros and include loops. It is _possible_, but the simpler scheme has the properties that we want. I want to replace nss_wrapper with a simple set of environment variables. Once we have a multi-file search path, it's no longer so simple because it's not clear if the default search path is amended or replaced when the environment variable is set. nss_wrapper currently fully overrides the system config. I think it'd be reasonable to keep that behaviour. But anyway: having to make that choice here is not a great argument against having multiple files, we just have to remember about the issue and implement and document one of the possibilities, whatever makes the most sense. Loop detection on traditional file systems wouldn't be very difficult to implement, except that we increasingly have file systems which have dev_t/ino_t values that are not unique. But that impacts any form of loop detection, so I'm not overly concerned. Yes, it certainly _can_ be done… The systemd-style drop-in mechanism works well and is at this point widely documented and understood. We also have cases where alternative mechanisms based on 'include' were implemented, and, at least in my opinion, they have proven to work less well. (E.g. sshd, sudo). Anyway, I think that at this point the technical arguments have been laid out, and we're down to questions of style. I _like_ the proposal with a fixed set of file paths better, but I'd be happy to take the version with include directives too, if it means we move some files 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 -- ___ 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
Re: goal: booting with an empty /etc
On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > >> No, it would be the other way round. We might have a > >> /usr/share/glibc/services which contains :include: /etc/services > >> somewhere in it. > > > > Ah, OK. I understand how the format would look, but I don't understand > > why you'd want to implement it rather than something simpler. > > > > /etc/services is essentially a flat file that is scanned from top to > > bottom until a matching entry is found. In the proposed syntax, it'd > > need to have ':include: /etc/services' at the very top, so that the local > > config in /etc/services has higher priority. > > > > Consider the following alternative: each of [/etc/services, > > /usr/etc/services] is scanned in order, if the file exists. This is > > simpler to implement and allows either of the files to exist > > independently of the other. A stanza like ':include:' also opens the > > door for additional complications like different paths on different > > distros and include loops. It is _possible_, but the simpler scheme > > has the properties that we want. > > I want to replace nss_wrapper with a simple set of environment > variables. Once we have a multi-file search path, it's no longer so > simple because it's not clear if the default search path is amended or > replaced when the environment variable is set. nss_wrapper currently fully overrides the system config. I think it'd be reasonable to keep that behaviour. But anyway: having to make that choice here is not a great argument against having multiple files, we just have to remember about the issue and implement and document one of the possibilities, whatever makes the most sense. > Loop detection on traditional file systems wouldn't be very difficult to > implement, except that we increasingly have file systems which have > dev_t/ino_t values that are not unique. But that impacts any form of > loop detection, so I'm not overly concerned. Yes, it certainly _can_ be done… The systemd-style drop-in mechanism works well and is at this point widely documented and understood. We also have cases where alternative mechanisms based on 'include' were implemented, and, at least in my opinion, they have proven to work less well. (E.g. sshd, sudo). Anyway, I think that at this point the technical arguments have been laid out, and we're down to questions of style. I _like_ the proposal with a fixed set of file paths better, but I'd be happy to take the version with include directives too, if it means we move some files 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
Re: goal: booting with an empty /etc
On Fr, 08.12.23 20:20, DJ Delorie (d...@redhat.com) wrote: > Lennart Poettering writes: > > That said, I would certainly enjoy more if glibc would natively > > fallback to /usr/lib/glibc/nsswitch.conf or something like that if > > /etc/nsswitch.conf does not exist. > > glibc has an internal default for nsswitch.conf if one isn't found. > Putting a custom nsswitch.conf in yet another non-standard directory is > not needed. Well, as you might be aware many distributions these days do more than "files dns" for "hosts", and similar for the other databases, and hence a built-in default in glibc is great, but most distributions and image builders probably want to pick different defaults without having to patch glibc for this. Lennart -- Lennart Poettering, Berlin -- ___ 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
Re: goal: booting with an empty /etc
* Zbigniew Jędrzejewski-Szmek: >> No, it would be the other way round. We might have a >> /usr/share/glibc/services which contains :include: /etc/services >> somewhere in it. > > Ah, OK. I understand how the format would look, but I don't understand > why you'd want to implement it rather than something simpler. > > /etc/services is essentially a flat file that is scanned from top to > bottom until a matching entry is found. In the proposed syntax, it'd > need to have ':include: /etc/services' at the very top, so that the local > config in /etc/services has higher priority. > > Consider the following alternative: each of [/etc/services, > /usr/etc/services] is scanned in order, if the file exists. This is > simpler to implement and allows either of the files to exist > independently of the other. A stanza like ':include:' also opens the > door for additional complications like different paths on different > distros and include loops. It is _possible_, but the simpler scheme > has the properties that we want. I want to replace nss_wrapper with a simple set of environment variables. Once we have a multi-file search path, it's no longer so simple because it's not clear if the default search path is amended or replaced when the environment variable is set. Loop detection on traditional file systems wouldn't be very difficult to implement, except that we increasingly have file systems which have dev_t/ino_t values that are not unique. But that impacts any form of loop detection, so I'm not overly concerned. Thanks, Florian -- ___ 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
Re: goal: booting with an empty /etc
On 12/9/23 16:55, DJ Delorie wrote: Zbigniew Jędrzejewski-Szmek writes: I'm not entirely sure if you're just doing Friday trolling or if you're serious. Serious. I have many machines and VMs, and every time I do a Fedora install, I have a list of your choices I have to revert because they don't work for me. It's tiring. I fear this will end like the /tmp fiasco where one /tmp became many tmp directories, and no consistent rule about which one to use. /tmp is generally backed by RAM and does not survive a reboot. Not on any of my machines. I want tmp files around after a reboot so I can figure out what caused the reboot. This can be achieved without "empty /etc" as a goal. For example, why can't we use podman's overlay filesystem to mount /usr/etc under /etc so that all the configuration appears in /etc but installed vs changed files are kept segregatable? (FTR, not "podman's". The filesystem is a kernel thing.) If the goal was to just move everything wholesale, that'd be a I meant, rpms install into the lower fs, and the user edits the upper fs. You can "revert" to "factory settings" by wiping just the upper fs. You can expose the two layers elsewhere (like /usr/etc) if that helps with the merging. (Another problem is that this scheme only works "live". If you want to look *into* an image from the outside, the overlay wouldn't be assembled, so the tools need to know how to handle the config split manually.) If you get your way, /etc would be empty anyway ;-) For example, /etc/services is a list of port:service mappings, and people maybe used to edit that twenty years ago, I still edit this one. Great for you. So you can be the one person who uses the override mechanism for this file. That you assume I'm the only one is part of the problem. Another common case is "empty" configuration files, i.e. templates that show the default configuration. I find these VERY helpful when trying to fix configuration issues on my machines. Right. I'm not saying that those should go away. Quite the opposite. If you move them away from where I expect to find them, effectively they've gone away. Instead of having everything I need in the one spot, I have to go hunting for it. If history is right, everyone will choose a different spot and finding info will become very difficult. Even *documenting* where to find this information will become difficult, because everyone puts their docs in different places. Please figure out a way to make upgrades more reliable without having to retrain millions of Linux users or turn Fedora into Windows. I'm not sure I'm exaggerating here. -- ___ 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 ostree does something like this. Having a lower /usr/etc and a upper /var/etc mapped at /etc, would be interesting. although there would be no ability to merge, the upper overrides the lower. -- ___ 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
Re: goal: booting with an empty /etc
Zbigniew Jędrzejewski-Szmek writes: > I'm not entirely sure if you're just doing Friday trolling or if > you're serious. Serious. I have many machines and VMs, and every time I do a Fedora install, I have a list of your choices I have to revert because they don't work for me. It's tiring. >> I fear this will end like the /tmp fiasco where one /tmp became many tmp >> directories, and no consistent rule about which one to use. > > /tmp is generally backed by RAM and does not survive a reboot. Not on any of my machines. I want tmp files around after a reboot so I can figure out what caused the reboot. >> This can be achieved without "empty /etc" as a goal. For example, why >> can't we use podman's overlay filesystem to mount /usr/etc under /etc so >> that all the configuration appears in /etc but installed vs changed >> files are kept segregatable? > > (FTR, not "podman's". The filesystem is a kernel thing.) > > If the goal was to just move everything wholesale, that'd be a I meant, rpms install into the lower fs, and the user edits the upper fs. You can "revert" to "factory settings" by wiping just the upper fs. You can expose the two layers elsewhere (like /usr/etc) if that helps with the merging. > (Another problem is that this scheme only works "live". If you want > to look *into* an image from the outside, the overlay wouldn't be > assembled, so the tools need to know how to handle the config split > manually.) If you get your way, /etc would be empty anyway ;-) >> > For example, /etc/services is a list of port:service mappings, and people >> > maybe used to edit that twenty years ago, >> >> I still edit this one. > > Great for you. So you can be the one person who uses the override > mechanism for this file. That you assume I'm the only one is part of the problem. >> > Another common case is "empty" configuration files, i.e. templates >> > that show the default configuration. >> >> I find these VERY helpful when trying to fix configuration issues on my >> machines. > > Right. I'm not saying that those should go away. Quite the opposite. If you move them away from where I expect to find them, effectively they've gone away. Instead of having everything I need in the one spot, I have to go hunting for it. If history is right, everyone will choose a different spot and finding info will become very difficult. Even *documenting* where to find this information will become difficult, because everyone puts their docs in different places. Please figure out a way to make upgrades more reliable without having to retrain millions of Linux users or turn Fedora into Windows. I'm not sure I'm exaggerating here. -- ___ 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
Re: goal: booting with an empty /etc
Zbigniew Jędrzejewski-Szmek writes: > That built-in would be enough only if it enabled all the modules > that we need it to support. It enables the ones that *glibc* needs to run at a minimum. Your case is different, which is why you modify /etc/nsswitch.conf. > I tried to figure out what the default is, but could find that info. > Is is documented somewhere? Yes. It's in the glibc manual, section "Notes on the NSS Configuration File". It boils down to either "files dns" or "files" for most entries. -- ___ 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
Re: goal: booting with an empty /etc
On Fri, Dec 08, 2023 at 07:25:08PM +0100, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote: > >> * Stephen Gallagher: > >> > >> > 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 add some sort of :include: processing to glibc, but that's > >> going to impact much more than just glibc in the end (Go has its own > >> parser for /etc/passwd, I believe others have their own for > >> /etc/nsswitch.conf). > > > > IIUC, you mean that e.g. /etc/services would still exist, but > > would contain ":include:/usr/etc/services". That's not a great answer, > > because you still need /etc/services to exist. > > No, it would be the other way round. We might have a > /usr/share/glibc/services which contains :include: /etc/services > somewhere in it. Ah, OK. I understand how the format would look, but I don't understand why you'd want to implement it rather than something simpler. /etc/services is essentially a flat file that is scanned from top to bottom until a matching entry is found. In the proposed syntax, it'd need to have ':include: /etc/services' at the very top, so that the local config in /etc/services has higher priority. Consider the following alternative: each of [/etc/services, /usr/etc/services] is scanned in order, if the file exists. This is simpler to implement and allows either of the files to exist independently of the other. A stanza like ':include:' also opens the door for additional complications like different paths on different distros and include loops. It is _possible_, but the simpler scheme has the properties that we want. > > It's also a rather complex solution, because special parsing is > > needed… It's both easier and more powerful to say "check for > > /etc/services, and if doesn't exist, fall back to > > /usr/etc/services". It's: > > - simple to implement and understand, > > - backwards compatible in the sense that a local system that has > > the file modified will work without changes, > > - and as discussed in another part of the thread, we can add > > optionally add tmpfiles.d config to symlink /etc/services → > > /usr/etc/services > > on boot if there are other consumers that don't yet support the new > > location. > > Are you sure you mean check “for /etc/services, and if doesn't exist, > fall back to /usr/etc/services”? That suggests that in order to edit > the file, you have to make a copy, and that means that the system won't > receive any services added to the system file. “Look for the service in > /etc/services, and if it's not there, check /usr/etc/services” would > make more sense to me. But that's not so far off from :include: > processing … Yeah, I see the misunderstanding now. With config files, we generally want the behaviour that _only one_ file is used. Either /etc/foobar.conf or /usr/lib/foobar.conf, but not both. But for /etc/services, we want to combine both parts, and doing it as you describe (or as I wrote above before reading part of your mail ;) ), is better. (Of course, there's always the option of allowing both, i.e. having a main config file that is fully overriden by a file with the same name, and allowing drop-ins to extend the configuration.) 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
Re: goal: booting with an empty /etc
On Fri, Dec 08, 2023 at 12:14:09PM -0500, Steve Grubb wrote: > On Friday, December 8, 2023 11:57:55 AM EST Adam Williamson wrote: > > On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote: > > > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > 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. > > > > > > > > > The problem is that there would need to be a standard that all upstream > > > authors agree on. There are some like systemd which have a [SECTION_NAME] > > > > followed by config items. Others do not make sections. What if the > > > config is in yaml, json, or XML? How can you see the end result? We > > > would need to have a standard library that everyone can use. From that, > > > we need a utility to compile the actual configuration that would be > > > consumed by the service so we can inspect it during troubleshooting. > > > > Eh? What does the format of the files have to do with where they live? > > At face value, it shouldn't matter. But when you have the first override, now > you need to have a reproducible, correct assembly of the configuration. Each > format has peculiarities about how to place the override in the correct spot. I think that there's a misunderstanding because there are two separate ideas in play: 1. moving of the default "main" config file from /etc or somewhere under /usr and allowing the the file in /etc as an override. 2. allowing extensions of that configuration with additional "drop-ins". Systemd implements both, so people tend to think of them together, but strictly speaking, they are completely orthgonal. Systemd has it easy, because its INI config files can be just contatenated. As AdamW said, there are formats like XML or JSON where this wouldn't work. *Some* custom mechanism of extension may be defined, but it won't be a trivial sort-and-concatenate. Points 1 and 2 each separately are beneficial. 1. has all the advantages that I described in the initial mail, 2. has the advantage that it's much becomes trivial to insert and remove "edits" to the configuration, and it's easy to combine configuration from multiple sources, e.g. main package, extension packages, and local overrides. If we don't have that, we must do some scripting to "merge" additional config, but in many cases this is very brittle. 1. + 2. together gives the most benefits. > > I don't see any reason we can have heterodox config file formats in > > /etc, but not in /usr. (Indeed, practically speaking, we already have > > lots of different formats in both places). > > Because it's in one place and not expected to be built up by looking all over > the place for the pieces. Making this easy for security scanner and upstream > developer adoption really needs to be considered. Don't misunderstand that > I'm against the idea...I'm just trying to say we need to consider the > ramifications across the broader ecosystem. If a given program only supports item 1. above, then there's no merging. But I agree with the more general premise: security scanners and other software needs to "understand" and support the effective configuration mechanism. In an earlier mail, Steve Grubb wrote: > The problem is that there would need to be a standard that all upstream > authors agree on. There are some like systemd which have a [SECTION_NAME] > followed by config items. Others do not make sections. What if the config is > in > yaml, json, or XML? How can you see the end result? We would need to have a > standard library that everyone can use. From that, we need a utility to > compile the actual configuration that would be consumed by the service so we > can inspect it during troubleshooting. All those problems already exist. We have hundreds of custom file formats in play. Even the same software can change over time, adding new syntax. So to make *any* inference about some piece of configuration, the scanner or other tool needs to support that specific configuration format. What's even harder, it must understand the implicit defaults. If frobnicator-1.0 defaults to "allow everything", and frobnicator-2.0 defaults ot "deny everything", a scanner that supports the syntax of the configuration, but doesn't know this, is not very useful. All of that is already true, and the additional complication of multiple config file locations is just a small addition on top. > Without this, security scanners are going to have a hard time determining > what the security posture of a system is. And the Security Content everywhere > will need to be changed, STIG, Common Criteria, CIS, USGCB, etc. Some of > these are very opinionated about the file permissions. Something would have to > check all files everywhere that make up a configuration. Again, security > scanners are not going to like this. So, the library would also probably need > to be
Re: goal: booting with an empty /etc
On Sat, Dec 09, 2023 at 08:03:48AM +, Zbigniew Jędrzejewski-Szmek wrote: > I'm not entirely sure if you're just doing Friday trolling or if > you're serious. I'll reply for real, apologies if this was meant as > a joke. DJ has been hacking on free software since I was still at school, so no, he's not trolling. > On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote: > > Zbigniew Jędrzejewski-Szmek writes: > > > There is a long-term goal of moving packaged files out of /etc, > > > > I will note that I'm opposed to this goal as a goal per-se. > > > > If you want an empty directory, "mkdir /etc2" should work for you. > > > > I fear this will end like the /tmp fiasco where one /tmp became many tmp > > directories, and no consistent rule about which one to use. > > /tmp is generally backed by RAM and does not survive a reboot. And that's a really bad idea, which I always turn off in any computer or server I manage. Limiting /tmp to using RAM + swap and having it erase at reboot is pointless additional complexity. This caused us to go through countless lines of code deciding if a temporary file is "small" (how small? don't know!) and whether it should live in /tmp or /var/tmp for people who have to suffer this configuration. Filesystems already use RAM for caching when necessary, and I want temporary directories with a controlled lifetime, not "whenever the power happens to go off". Plus more typing. > > > At some point, I think we should make this an explicit goal in Fedora. > > > > Please don't. > > You seem to like the current scheme. But it was designed in the times where > people did much more manual tweaking of their systems. We now care a lot > about clean and automatic upgrades. Having to resolve three-way differences > between a bunch of config files conflicts with that. People use their systems in different ways. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- ___ 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
Re: goal: booting with an empty /etc
I'm not entirely sure if you're just doing Friday trolling or if you're serious. I'll reply for real, apologies if this was meant as a joke. On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote: > Zbigniew Jędrzejewski-Szmek writes: > > There is a long-term goal of moving packaged files out of /etc, > > I will note that I'm opposed to this goal as a goal per-se. > > If you want an empty directory, "mkdir /etc2" should work for you. > > I fear this will end like the /tmp fiasco where one /tmp became many tmp > directories, and no consistent rule about which one to use. /tmp is generally backed by RAM and does not survive a reboot. /var/tmp is backed by disk and survives a reboot. The general rule is pretty clear: ISOs go to /var/tmp, quick temporary files go to /tmp. > > so that only actual local configuration remains in /etc. > > This can be achieved without "empty /etc" as a goal. For example, why > can't we use podman's overlay filesystem to mount /usr/etc under /etc so > that all the configuration appears in /etc but installed vs changed > files are kept segregatable? (FTR, not "podman's". The filesystem is a kernel thing.) If the goal was to just move everything wholesale, that'd be a possible solution. But we actually want to keep things that are local configuration and move things that are not. So the distinction between the two types of files still needs to be made. At least at the packaging level, we would need to put files in a different place. And then the software that reads the files would occasionally want to distinguish the two types of config (e.g. to present to the user whether it's the packaged default or local config, or to merge with other configuration sources with different priority). So the split would "leak" into the software anyway, and then it'd need to be prepared to handle the overlay, and possibly go into the lower layers. So now we have a much higher level of complexity (three locations, upper, lower, and combined) to achieve essentially the same functionality. (Another problem is that this scheme only works "live". If you want to look *into* an image from the outside, the overlay wouldn't be assembled, so the tools need to know how to handle the config split manually.) > > For example, /etc/services is a list of port:service mappings, and people > > maybe used to edit that twenty years ago, > > I still edit this one. Great for you. So you can be the one person who uses the override mechanism for this file. > > The same is also true for /etc/bash_completion.d/ > > I delete this package completely, so I don't care where its config goes. YMMV. > > Another common case is "empty" configuration files, i.e. templates > > that show the default configuration. > > I find these VERY helpful when trying to fix configuration issues on my > machines. Right. I'm not saying that those should go away. Quite the opposite. My first email had a long paragraph about how to display those files for systemd in a nice way (with priority sorting, highlighting, and other niceties.) Please note that the proposed scheme makes those files *more* useful: the user can have a local copy with changes. Before, when the package was updated, we wouldn't override the user's copy, so at best there'd be a .rpmnew file. Now, the package copy is in a different location and can be updated freely. > > Other distributions are ahead of us in supporting empty /etc. > > "Be like everyone else" is not one of our goals. > > > 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. > > Unless such file could be changed by a user, in which case it belongs in > /etc. The option of modifying a package file in place doesn't work great. The package updates the file and then the user is left with a copy that stops being updated. The approach of only overriding the parts that should be overriden is better. > > At some point, I think we should make this an explicit goal in Fedora. > > Please don't. You seem to like the current scheme. But it was designed in the times where people did much more manual tweaking of their systems. We now care a lot about clean and automatic upgrades. Having to resolve three-way differences between a bunch of config files conflicts with that. 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
Re: goal: booting with an empty /etc
On Fri, Dec 08, 2023 at 08:20:25PM -0500, DJ Delorie wrote: > Lennart Poettering writes: > > That said, I would certainly enjoy more if glibc would natively > > fallback to /usr/lib/glibc/nsswitch.conf or something like that if > > /etc/nsswitch.conf does not exist. > > glibc has an internal default for nsswitch.conf if one isn't found. > Putting a custom nsswitch.conf in yet another non-standard directory is > not needed. That built-in would be enough only if it enabled all the modules that we need it to support. I tried to figure out what the default is, but could find that info. Is is documented somewhere? 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
Re: goal: booting with an empty /etc
Lennart Poettering writes: > That said, I would certainly enjoy more if glibc would natively > fallback to /usr/lib/glibc/nsswitch.conf or something like that if > /etc/nsswitch.conf does not exist. glibc has an internal default for nsswitch.conf if one isn't found. Putting a custom nsswitch.conf in yet another non-standard directory is not needed. -- ___ 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
Re: goal: booting with an empty /etc
On Fr, 08.12.23 10:25, Stephen Gallagher (sgall...@redhat.com) wrote: > That being said, there are files like /etc/nsswitch.conf, > /etc/pam.d/* So for /etc/nsswitch.conf (and some degree of /etc/pam.d/) a short-term half-way fix is this I guess: https://github.com/authselect/authselect/issues/355 (hopefully @pbrezina merges my two PRs soon). With that if you boot up with an empty /etc/, you'll get a proper /etc/nsswitch.conf set up automatically, like you would on a regular Fedora install. That said, I would certainly enjoy more if glibc would natively fallback to /usr/lib/glibc/nsswitch.conf or something like that if /etc/nsswitch.conf does not exist. Lennart -- Lennart Poettering, Berlin -- ___ 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
Re: goal: booting with an empty /etc
On Fr, 08.12.23 17:23, Florian Weimer (fwei...@redhat.com) wrote: > * Stephen Gallagher: > > > 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 add some sort of :include: processing to glibc, but that's > going to impact much more than just glibc in the end (Go has its own > parser for /etc/passwd, I believe others have their own for > /etc/nsswitch.conf). I'd always suggest going for .d/ style drop-in dirs (i.e. /etc/services.d/*.conf, /usr/share/services.d/*.conf, /etc/protocols.d/*.conf, /usr/share/protocols.d/*.conf and similar) rather than include logic, for the simple reason that ensuring includes don't result in potentially endless recursion is a bit nasty. Moreover, it's kinda nice if the conceptual logic that allows users to split things up doesn't leak into the contents of the files, but remains in the structure of the file system. That said, if you give me an "include" style logic in glibc's database handling I'd also be happy. Beggars can't be choosers, after all. Lennart -- Lennart Poettering, Berlin -- ___ 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
Re: goal: booting with an empty /etc
* Zbigniew Jędrzejewski-Szmek: > On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote: >> * Stephen Gallagher: >> >> > 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 add some sort of :include: processing to glibc, but that's >> going to impact much more than just glibc in the end (Go has its own >> parser for /etc/passwd, I believe others have their own for >> /etc/nsswitch.conf). > > IIUC, you mean that e.g. /etc/services would still exist, but > would contain ":include:/usr/etc/services". That's not a great answer, > because you still need /etc/services to exist. No, it would be the other way round. We might have a /usr/share/glibc/services which contains :include: /etc/services somewhere in it. > It's also a rather complex solution, because special parsing is > needed… It's both easier and more powerful to say "check for > /etc/services, and if doesn't exist, fall back to > /usr/etc/services". It's: > - simple to implement and understand, > - backwards compatible in the sense that a local system that has > the file modified will work without changes, > - and as discussed in another part of the thread, we can add > optionally add tmpfiles.d config to symlink /etc/services → > /usr/etc/services > on boot if there are other consumers that don't yet support the new > location. Are you sure you mean check “for /etc/services, and if doesn't exist, fall back to /usr/etc/services”? That suggests that in order to edit the file, you have to make a copy, and that means that the system won't receive any services added to the system file. “Look for the service in /etc/services, and if it's not there, check /usr/etc/services” would make more sense to me. But that's not so far off from :include: processing … Thanks, Florian -- ___ 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
Re: goal: booting with an empty /etc
Zbigniew Jędrzejewski-Szmek writes: > There is a long-term goal of moving packaged files out of /etc, I will note that I'm opposed to this goal as a goal per-se. If you want an empty directory, "mkdir /etc2" should work for you. I fear this will end like the /tmp fiasco where one /tmp became many tmp directories, and no consistent rule about which one to use. > so that only actual local configuration remains in /etc. This can be achieved without "empty /etc" as a goal. For example, why can't we use podman's overlay filesystem to mount /usr/etc under /etc so that all the configuration appears in /etc but installed vs changed files are kept segregatable? > For example, /etc/services is a list of port:service mappings, and people > maybe used to edit that twenty years ago, I still edit this one. > The same is also true for /etc/bash_completion.d/ I delete this package completely, so I don't care where its config goes. > Another common case is "empty" configuration files, i.e. templates > that show the default configuration. I find these VERY helpful when trying to fix configuration issues on my machines. > Other distributions are ahead of us in supporting empty /etc. "Be like everyone else" is not one of our goals. > 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. Unless such file could be changed by a user, in which case it belongs in /etc. > At some point, I think we should make this an explicit goal in Fedora. Please don't. -- ___ 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
Re: goal: booting with an empty /etc
On Friday, December 8, 2023 11:57:55 AM EST Adam Williamson wrote: > On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote: > > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > 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. > > > > > > The problem is that there would need to be a standard that all upstream > > authors agree on. There are some like systemd which have a [SECTION_NAME] > > followed by config items. Others do not make sections. What if the > > config is in yaml, json, or XML? How can you see the end result? We > > would need to have a standard library that everyone can use. From that, > > we need a utility to compile the actual configuration that would be > > consumed by the service so we can inspect it during troubleshooting. > > Eh? What does the format of the files have to do with where they live? At face value, it shouldn't matter. But when you have the first override, now you need to have a reproducible, correct assembly of the configuration. Each format has peculiarities about how to place the override in the correct spot. > I don't see any reason we can have heterodox config file formats in > /etc, but not in /usr. (Indeed, practically speaking, we already have > lots of different formats in both places). Because it's in one place and not expected to be built up by looking all over the place for the pieces. Making this easy for security scanner and upstream developer adoption really needs to be considered. Don't misunderstand that I'm against the idea...I'm just trying to say we need to consider the ramifications across the broader ecosystem. -Steve -- ___ 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
Re: goal: booting with an empty /etc
On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote: > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek > wrote: > > 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. > > The problem is that there would need to be a standard that all upstream > authors agree on. There are some like systemd which have a [SECTION_NAME] > followed by config items. Others do not make sections. What if the config is > in > yaml, json, or XML? How can you see the end result? We would need to have a > standard library that everyone can use. From that, we need a utility to > compile the actual configuration that would be consumed by the service so we > can inspect it during troubleshooting. Eh? What does the format of the files have to do with where they live? I don't see any reason we can have heterodox config file formats in /etc, but not in /usr. (Indeed, practically speaking, we already have lots of different formats in both places). -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net -- ___ 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
Re: goal: booting with an empty /etc
On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek wrote: > 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. The problem is that there would need to be a standard that all upstream authors agree on. There are some like systemd which have a [SECTION_NAME] followed by config items. Others do not make sections. What if the config is in yaml, json, or XML? How can you see the end result? We would need to have a standard library that everyone can use. From that, we need a utility to compile the actual configuration that would be consumed by the service so we can inspect it during troubleshooting. Without this, security scanners are going to have a hard time determining what the security posture of a system is. And the Security Content everywhere will need to be changed, STIG, Common Criteria, CIS, USGCB, etc. Some of these are very opinionated about the file permissions. Something would have to check all files everywhere that make up a configuration. Again, security scanners are not going to like this. So, the library would also probably need to be able report all permissions used or set all permissions used. And then there is the SE Linux labeling... There would probably need to be some written standard on how to assess the system security posture in this kind of world. This way tools can be adjusted using the standards. -Steve -- ___ 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
Re: goal: booting with an empty /etc
On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote: > * Stephen Gallagher: > > > 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 add some sort of :include: processing to glibc, but that's > going to impact much more than just glibc in the end (Go has its own > parser for /etc/passwd, I believe others have their own for > /etc/nsswitch.conf). IIUC, you mean that e.g. /etc/services would still exist, but would contain ":include:/usr/etc/services". That's not a great answer, because you still need /etc/services to exist. It's also a rather complex solution, because special parsing is needed… It's both easier and more powerful to say "check for /etc/services, and if doesn't exist, fall back to /usr/etc/services". It's: - simple to implement and understand, - backwards compatible in the sense that a local system that has the file modified will work without changes, - and as discussed in another part of the thread, we can add optionally add tmpfiles.d config to symlink /etc/services → /usr/etc/services on boot if there are other consumers that don't yet support the new location. Yet another approach is to allow *multiple* files, like with sysusers.d or tmpfiles.d. For '/etc/services', this would make a lot of sense, because users generally would want to override or add a few lines, and keep the rest of the config unchanged. The case of glibc is very special. It'd be great to move its files out of /etc too, but each file might need some custom mechanism and discussion about the best approach. 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
Re: goal: booting with an empty /etc
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 > 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
Re: goal: booting with an empty /etc
* Stephen Gallagher: > 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 add some sort of :include: processing to glibc, but that's going to impact much more than just glibc in the end (Go has its own parser for /etc/passwd, I believe others have their own for /etc/nsswitch.conf). Thanks, Florian -- ___ 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
Re: goal: booting with an empty /etc
On Fri, Dec 8, 2023 at 10:26 AM Stephen Gallagher wrote: > > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > 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. > > 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. PAM configuration has been able to move to /usr/share/pam.d (%_pam_vendordir) since Fedora 33. It is part of RHEL 9 too. That's seriously good low-hanging fruit to move. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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
Re: goal: booting with an empty /etc
On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek 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. 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. -- ___ 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
goal: booting with an empty /etc
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@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
