Re: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)
On Fri, Sep 27, 2024 at 5:50 AM Michael J Gruber wrote: > > Am Fr., 27. Sept. 2024 um 11:33 Uhr schrieb Florian Weimer > : > > > > Do you see any problems if glibc starts using /usr/etc/services if > > /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc > > and so on. It's already used on openSUSE, apparently. > > > > And alternative proposal was to use /usr/share/services (which I really > > dislike), or /usr/share/nss/services (to which I do not have any > > objections). > > Is OpenSUSE the only precedent so far? > Solus put everything in /usr/share/defaults (though I think "defaults" isn't the right name for this) long before openSUSE did /usr/etc. https://help.getsol.us/docs/user/software/configuration_files/ My preference would be /usr/share// e.g. /usr/share/nss/services for nss services, /usr/share/pam/ for pam stuff, etc. (We have /usr/share/pam.d, but when I tried to move sddm configs to it, it didn't take effect and I noticed pam isn't configured anymore for configs in /usr). -- 真実はいつも一つ！/ 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: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)
* Colin Walters: > On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote: >> Do you see any problems if glibc starts using /usr/etc/services if >> /etc/services does not exist? > > Please avoid having projects unconditionally read `/usr/etc` > because on ostree based systems `/usr/etc/services` will always > exist; we use it for our 3-way merge of /etc. > (It's actually also really nice to have the defaults always > visible, that's how `ostree admin config-diff` works) > Now we have discussion of this split across 3 different forums; > probably the glibc list is the best place to hash this out. Makes sense. Would you please raise your objection there? 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: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)
Am Fr., 27. Sept. 2024 um 11:33 Uhr schrieb Florian Weimer : > > Do you see any problems if glibc starts using /usr/etc/services if > /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc > and so on. It's already used on openSUSE, apparently. > > And alternative proposal was to use /usr/share/services (which I really > dislike), or /usr/share/nss/services (to which I do not have any > objections). Is OpenSUSE the only precedent so far? I'd say we should look at the bigger picture: moves to /usr were motivated (and justified) by the fact that we think of /usr as "tied" to the state of the system installation, that is everything that is rolled back when an installation is rolled back to a different state, modified at install and update time, unchanged/immutable otherwise. /etc is there to provide or override config. Where does the config live that we override from /etc? If the files we want to move are not "host specific" (otherwise we couldn't move them to in stall-specific, host-agnostic /usr) and not arch-specific then /usr/share seems to make sense. /ust/etc looks like redefining the meaning of "etc", which we could, of course, but hopefully on common grounds with other distros :) Michael -- ___ 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: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)
On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote: > Do you see any problems if glibc starts using /usr/etc/services if > /etc/services does not exist? Please avoid having projects unconditionally read `/usr/etc` because on ostree based systems `/usr/etc/services` will always exist; we use it for our 3-way merge of /etc. (It's actually also really nice to have the defaults always visible, that's how `ostree admin config-diff` works) It will start to conflict if other projects put things there. Now our technical direction may go in a place where we move away from `/usr/etc` and do things differently (and this is a whole *other* big thing to align in api probably). Please use a project-specific namespace as you suggested below. > Same for /usr/etc/protocols, /usr/etc/rpc > and so on. It's already used on openSUSE, apparently. Hmmm. OK, messy. > Tracking upstream projects that do not support hermetic-usr for > configuration > <https://github.com/uapi-group/specifications/issues/76> Now we have discussion of this split across 3 different forums; probably the glibc list is the best place to hash this out. -- ___ 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
Using /usr/etc/services as a fallback for /etc/services (and other NSS files)
Do you see any problems if glibc starts using /usr/etc/services if /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc and so on. It's already used on openSUSE, apparently. And alternative proposal was to use /usr/share/services (which I really dislike), or /usr/share/nss/services (to which I do not have any objections). Background: [PATCH] nss: look for databases in /usr/share/ if they don't exist in /etc/ <https://inbox.sourceware.org/libc-alpha/ZvZj2jkpJjhaP-Yc@gardel-login/> Tracking upstream projects that do not support hermetic-usr for configuration <https://github.com/uapi-group/specifications/issues/76> 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: /usr/etc?
Am 08.08.2013 10:05, schrieb Ondrej Vasik: > I already nuked /usr/etc yesterday - as FHS even disallows it (see > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY > Rationale note). But I still see /usr/local/etc there - and mentioned as > beneficial, so keeping it for now yes "/usr/local/etc" makes sense because /usr/local is for me the same filesystem-structure as /usr with files outside the package-management we use /usr/local/etc/bash_profile for aliases included by any user __ [harry@rh:~]$ cat .bashrc # .bashrc PS1="\[\033[1;32m\][\u@\h:\w]$\[\033[0m\] " # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi if [ -f /usr/local/etc/bash_profile ]; then . /usr/local/etc/bash_profile fi __ [root@rh:~]$ cat .bashrc # .bashrc PS1="\[\033[1;31m\][\u@\h:\w]$\[\033[0m\] " # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi if [ -f /usr/local/etc/bash_profile ]; then . /usr/local/etc/bash_profile fi signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On Wed, 2013-08-07 at 11:35 -0400, Bill Nottingham wrote: > Ondrej Vasik (ova...@redhat.com) said: > > Now I probably see why I did that - it was in the RPM_BUILD_ROOT from > > some reason and because of the capabilities change, I needed to > > explicitly mention all directories created in RPM_BUILD_ROOT. So this > > commit just exposed /usr/etc explicitly what was in the package payload > > since at least 2004 (I don't have older data). If noone knows why this > > directory should exist, I'll be more than happy to drop it... > > Yeah, it's always been in there back to 1998, at least. It came from > FSSTND (the FHS precursor): > http://ibiblio.org/pub/linux/docs/fsstnd/old/fsstnd-1.2.txt > > ... > > 4.5 /usr/etc : Site-wide system configuration > > Storing configuration in /usr/etc for the software found in /usr/bin and > /usr/sbin is a problem. It makes the read-only mounting of /usr through > CD-ROM or NFS delivery very difficult at best. > > One possible solution that we considered was to completely eliminate > /usr/etc and specify that all configuration be stored in /etc. A > problem with this approach is that it does not properly anticipate the > possibility that many sites may want to have some configuration files > that are not machine-local. > > We eventually decided that /etc should be the only directory that is > actually referenced by programs (that is, everything should look for > configuration in /etc and not in /usr/etc). Any configuration files > that need to be site-wide and are not needed before /usr is mounted (or > in an emergency situation) should then be placed in /usr/etc. Then, > specific files (in /etc) on specific machines may or may not be > symbolically linked to appropriate configuration files located in > /usr/etc. This also means that /usr/etc is technically an optional > directory in the strictest sense, but we still recommend that all Linux > systems incorporate it. > > It is not recommended for /usr/etc to contain symbolic links that point > to files in /etc. This is unnecessary and interferes with local control > on machines that share a /usr directory. > ... > > It (and /usr/local/etc) were dropped in FHS 2.1 in 2001. So... nuke it? I already nuked /usr/etc yesterday - as FHS even disallows it (see http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY Rationale note). But I still see /usr/local/etc there - and mentioned as beneficial, so keeping it for now. Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
Ondrej Vasik (ova...@redhat.com) said: > Now I probably see why I did that - it was in the RPM_BUILD_ROOT from > some reason and because of the capabilities change, I needed to > explicitly mention all directories created in RPM_BUILD_ROOT. So this > commit just exposed /usr/etc explicitly what was in the package payload > since at least 2004 (I don't have older data). If noone knows why this > directory should exist, I'll be more than happy to drop it... Yeah, it's always been in there back to 1998, at least. It came from FSSTND (the FHS precursor): http://ibiblio.org/pub/linux/docs/fsstnd/old/fsstnd-1.2.txt ... 4.5 /usr/etc : Site-wide system configuration Storing configuration in /usr/etc for the software found in /usr/bin and /usr/sbin is a problem. It makes the read-only mounting of /usr through CD-ROM or NFS delivery very difficult at best. One possible solution that we considered was to completely eliminate /usr/etc and specify that all configuration be stored in /etc. A problem with this approach is that it does not properly anticipate the possibility that many sites may want to have some configuration files that are not machine-local. We eventually decided that /etc should be the only directory that is actually referenced by programs (that is, everything should look for configuration in /etc and not in /usr/etc). Any configuration files that need to be site-wide and are not needed before /usr is mounted (or in an emergency situation) should then be placed in /usr/etc. Then, specific files (in /etc) on specific machines may or may not be symbolically linked to appropriate configuration files located in /usr/etc. This also means that /usr/etc is technically an optional directory in the strictest sense, but we still recommend that all Linux systems incorporate it. It is not recommended for /usr/etc to contain symbolic links that point to files in /etc. This is unnecessary and interferes with local control on machines that share a /usr directory. ... It (and /usr/local/etc) were dropped in FHS 2.1 in 2001. So... nuke it? Your partner in archaeology, Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On Mon, 2013-08-05 at 13:00 +0200, Ondrej Vasik wrote: > Now I probably see why I did that - it was in the RPM_BUILD_ROOT from > some reason and because of the capabilities change, I needed to > explicitly mention all directories created in RPM_BUILD_ROOT. So this > commit just exposed /usr/etc explicitly what was in the package payload > since at least 2004 (I don't have older data). If noone knows why this > directory should exist, I'll be more than happy to drop it... Yeah, nuke it. I can't think of any reason it should exist, and it looks like mirall is the only package putting anything in it. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On Mon, 2013-08-05 at 12:53 +0200, Ondrej Vasik wrote: > On Sun, 2013-08-04 at 18:51 -0400, Colin Walters wrote: > > On Sun, 2013-08-04 at 13:16 +0200, Lennart Poettering wrote: > > > I noticed this: > > > > > > $ rpm -qf /usr/etc > > > filesystem-3.2-12.fc19.x86_64 > > > > A quick git annotate shows it originates from: > > > > http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=cd01d2d6d54f59ef8e177d0391bc734fba470ef4 > > > > With no comment as to why...just a copy/paste error? > > Probably not copy&paste but I don't think it was intentional. I'll > remove this line from filesystem spec file, I had no intention to > introduce /usr/etc (thanks for spotting this). Now I probably see why I did that - it was in the RPM_BUILD_ROOT from some reason and because of the capabilities change, I needed to explicitly mention all directories created in RPM_BUILD_ROOT. So this commit just exposed /usr/etc explicitly what was in the package payload since at least 2004 (I don't have older data). If noone knows why this directory should exist, I'll be more than happy to drop it... Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On Sun, 2013-08-04 at 18:51 -0400, Colin Walters wrote: > On Sun, 2013-08-04 at 13:16 +0200, Lennart Poettering wrote: > > I noticed this: > > > > $ rpm -qf /usr/etc > > filesystem-3.2-12.fc19.x86_64 > > A quick git annotate shows it originates from: > > http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=cd01d2d6d54f59ef8e177d0391bc734fba470ef4 > > With no comment as to why...just a copy/paste error? Probably not copy&paste but I don't think it was intentional. I'll remove this line from filesystem spec file, I had no intention to introduce /usr/etc (thanks for spotting this). Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On Sun, 2013-08-04 at 13:16 +0200, Lennart Poettering wrote: > I noticed this: > > $ rpm -qf /usr/etc > filesystem-3.2-12.fc19.x86_64 A quick git annotate shows it originates from: http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=cd01d2d6d54f59ef8e177d0391bc734fba470ef4 With no comment as to why...just a copy/paste error? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
On 08/04/2013 01:16 PM, Lennart Poettering wrote: I noticed this: $ rpm -qf /usr/etc filesystem-3.2-12.fc19.x86_64 $ repoquery --whatprovides '/usr/etc/*' mirall-common-0:1.3.0-1.fc19.x86_64 mirall-common-0:1.3.0-1.fc19.i686 Since when do we have /usr/etc, and what is it for? Maybe I am the only one but I see very little benefit in introducing a new Fedoraism like this... IMO, this is a packaging bug, nothing else, Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: /usr/etc?
2013/8/4 Lennart Poettering > I noticed this: > > $ rpm -qf /usr/etc > filesystem-3.2-12.fc19.x86_64 > > $ repoquery --whatprovides '/usr/etc/*' > mirall-common-0:1.3.0-1.fc19.x86_64 > mirall-common-0:1.3.0-1.fc19.i686 > > Since when do we have /usr/etc, and what is it for? > > Maybe I am the only one but I see very little benefit in introducing a > new Fedoraism like this... > That rather looks like CMakeism, which is strange in this case as Mirall has its own fix for that ( https://github.com/owncloud/mirall/blob/master/CMakeLists.txt#L35). Maybe that fix is not working here. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
/usr/etc?
I noticed this: $ rpm -qf /usr/etc filesystem-3.2-12.fc19.x86_64 $ repoquery --whatprovides '/usr/etc/*' mirall-common-0:1.3.0-1.fc19.x86_64 mirall-common-0:1.3.0-1.fc19.i686 Since when do we have /usr/etc, and what is it for? Maybe I am the only one but I see very little benefit in introducing a new Fedoraism like this... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
