Re: Add vendor configuration directory installation
Jason Sikes wrote: > You are correct that the > configuration files should only go in one directory when done on behalf > of a distribution. OK, this removes my biggest worry. > >* worse, invites packages to (perhaps inadvertently) restrict user > > freedom. > > Restricting user freedom is certainly not the intent of this proposal. > As a hacker and programmer, this is not something I am interested in for > my own personal use. If I was an admin of a system where security is > important, then, yes, I would be considering this. Sorry for the misunderstanding: I meant that the distro would take away freedom from the admin user (by making /usr read-only). The admin user can control the non-privileged user anyway; there's no change in that area. Anyway, you've blown away this worry. > >- Distributors use --prefix=/usr and don't specify --sysconfdir, because > > its default value $(prefix)/etc is already appropriate. > > My understanding of the "prefix" option is that it for building > something that installs in the case that system rules prohibit > installing in root. The --prefix option is also meant for use by root. --prefix=/usr makes sense when the /usr partition is writable. --prefix=/usr in combination with "make install DESTDIR=/tmp/staging" also makes sense when the /usr partition is read-only and there are some other means for transferring the contents of /tmp/staging/usr to /usr. (Whether this can trigger warnings by future invocations of the package manager apt / rpm / dnf / ... is an independent consideration.) > Another big reason we don't use "prefix" is that we (packagers) already > have macros that determine where various files should go Sure, if a packager has other means to collect the artifacts, a "make install" step that depends on a --prefix option is not needed. > >- Packages define a configure option for the /etc directory, e.g. > >--enable-etcdir=/etc > > through Autoconf [3]. > Yes, and what we are proposing is that this option (by a different name) > will be included in Autoconf so that developers don't have to add it > manually. The proposed patch [1] does more than that. Especially the documentation change suggests that it's OK for the "make install" step to install files in both /usr/etc and /etc. As you clarified above, this is not what is desired. The configure --help output and/or the documentation should state that - "make install" will install into SYSCONFDIR, - but the package will read from ETCDIR and then from SYSCONFDIR. > [4] "sysconfdir" and "distconfdir" are what we use in SUSE packaging to > point to /etc and /usr/etc respectively. So I used them for this > proposal. The problem is that their meanings are different, and their > actual usage is swapped. So that was a terrible idea. Yes, we can't change the meaning of "sysconfdir" (as a directory to install into) or its name, so many years after it was introduced. > Might I suggest: > > * RWCONFDIR, > > * ALTCONFDIR, or > > * ADMCONFDIR? ADMINCONFDIR sounds good to me. I.e. the option's name would be --adminconfdir. ALTCONFDIR is too much from the perspective of the vendor. From the perspective of the administrator, /etc is the primary and /usr/etc is the alternate configuration directory. RWCONFDIR can be misunderstood because - on some systems, both /usr/etc and /etc will be writable by root, - non-privileged users cannot write in either location. The documentation then should make clear that - the package is then supposed to make the value of the --adminconfdir option available to the program by defining a C macro ADMINCONFDIR: E.g. in packages that use Automake: AM_CPPFLAGS += -DADMINCONFDIR=\"$(adminconfdir)\" - the package's code is then supposed to read from that location, - but the package should not install any files into $(adminconfdir). How many packages will likely make use of this facility? Just systemd, PAM, and D-BUS [1]? In my machine's /etc, I see roughly 200 configurations. So, are we talking about a few packages or several hundreds? Bruno > > [0] https://0pointer.net/blog/projects/stateless.html > > [1] > > https://lists.gnu.org/archive/html/autoconf-patches/2023-02/msg7.html > > [2] > > https://www.gnu.org/software/automake/manual/html_node/Hard_002dCoded-Install-Paths.html > > [3] > > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Package-Options.html
Re: Add vendor configuration directory installation
> >- Packages define a configure option for the /etc directory, e.g. > >--enable-etcdir=/etc > > through Autoconf [3]. > Yes, and what we are proposing is that this option (by a different name) > will be included in Autoconf so that developers don't have to add it > manually. The proposed patch [1] does more than that. Especially the documentation change suggests that it's OK for the "make install" step to install files in both /usr/etc and /etc. As you clarified above, this is not what is desired. That would break a bunch of stuff, notably any GNU system where /usr and / are the same. The configure --help output and/or the documentation should state that - "make install" will install into SYSCONFDIR, - but the package will read from ETCDIR and then from SYSCONFDIR. It should absolutley not state that. It is on purpose that `make install' does not trash sysconfdir; if you install a program you do not want your configuration files that you have modified to be overwritten. I'm against this change (--admindir.. ), it is making a problem where there is none. For configuration files that are "global" (which this basically is); one should not use /usr/etc (which might not exist, or point to /etc). What should be used is /usr/share/PACKAGE or similar. This is already configurable by ./configure, so there is no reason to add switch that will not be used by anyone other than systemd.
Re: Add vendor configuration directory installation
We should also be very careful when adding new --foodir options, this breaks things quickly (old ./configure will error for example -- so if you want a single line for all invocations, you'll now have to remeber what is what version of autoconf!).
Re: Add vendor configuration directory installation
On 2/7/23 15:44, Bruno Haible wrote: On 2023-02-06 08:30, Valentin Lefebvre wrote: This patch add a new autoconf argument that allows installation into the vendor configuration directory (/usr/etc/). Some linux distribution now move system configuration files from /etc to /usr/etc. See this ref: [0] [0]https://0pointer.net/blog/projects/stateless.html I think that the proposed patch * is a wrong means to a right goal, * worse, invites packages to (perhaps inadvertently) restrict user freedom. Restricting user freedom is certainly not the intent of this proposal. As a hacker and programmer, this is not something I am interested in for my own personal use. If I was an admin of a system where security is important, then, yes, I would be considering this. Aside from that nitpick, I agree with just about everything else you say here. So I am going to leave what you wrote intact. In detail: From [0] and [1] I understand that the goal is: * to have configuration created by the OS vendor under /usr/etc, inside the read-only and possibly cryptographically secured /usr hierarchy, * to have configuration created by the administrator (user) under /etc, * to have, in the code, a mechanism by which the configuration in /etc overrides the configuration in /usr/etc. (At which level — the entire configuration, or by file, or by configuration element — is not clear, but is not relevant here.) So, a package's "make install" goal should only ever install in *one* of these two directories, namely - in /usr/etc when the build is done on behalf of a distro, - in $(prefix)/etc when the build is done on behalf of a user, never in /etc. The proposed patch "gives the opportunity for a project to install in both location /etc and /usr/etc in same time".[1] I apologize for the confusion; in my understanding what you cited in [1] was not the intention of this proposal. You are correct that the configuration files should only go in one directory when done on behalf of a distribution. And what you suggest later is much closer to what we are hoping for. This is not good because - Installing in /usr/etc should be sufficient if the override mechanism has been implemented. - [PB2] Installing something in /etc would overwrite the administrator's choices. - [PB3] It invites the package's authors to look up certain files in /etc (which is against one of the goals from [0] to be able to have a system with an empty /etc) and other files in /usr/etc (which takes away the freedom from the administrator to override the configuration, if he can't write in /usr). The better solution is that: - Packages install their configuration in $(sysconfdir). This is easily done through Automake [2]. Yes! - Distributors use --prefix=/usr and don't specify --sysconfdir, because its default value $(prefix)/etc is already appropriate. My understanding of the "prefix" option is that it for building something that installs in the case that system rules prohibit installing in root. So, for example, a user can install in their home directory or an admin can install in /opt. Another big reason we don't use "prefix" is that we (packagers) already have macros that determine where various files should go (documentation goes here, executables go here, etc.). So using "prefix" would put a monkey wrench in all of that. - Packages define a configure option for the /etc directory, e.g. --enable-etcdir=/etc through Autoconf [3]. Yes, and what we are proposing is that this option (by a different name) will be included in Autoconf so that developers don't have to add it manually. - Packages implement the said override mechanism, looking first in ETCDIR and then in SYSCONFDIR. YES! Again, I apologize for the confusion; this is what we want. Also, I should add that it doesn't help that my proposed nomenclature[4] is probably confusing. So maybe it's a good idea to change the name of the proposed new parameter? Might I suggest: * RWCONFDIR, * ALTCONFDIR, or * ADMCONFDIR? I guess no matter what we decide, the user will still need to look up documentation. I'm open to other ideas. But yes, Bruno, what you have written is more of what we have in mind. --Jason [4] "sysconfdir" and "distconfdir" are what we use in SUSE packaging to point to /etc and /usr/etc respectively. So I used them for this proposal. The problem is that their meanings are different, and their actual usage is swapped. So that was a terrible idea. If we were to make it easy for packages to install in /etc, in addition to $(prefix)/etc, the problems PB2 and PB3 mentioned above are likely to occur. Bruno [0] https://0pointer.net/blog/projects/stateless.html [1] https://lists.gnu.org/archive/html/autoconf-patches/2023-02/msg7.html [2] https://www.gnu.org/software/automake/manual/html_node/Hard_002dCoded-Instal
Re: Add vendor configuration directory installation
Alfred M. Szmidt wrote: >>The configure --help output and/or the documentation should state that >> - "make install" will install into SYSCONFDIR, > > It should absolutley not state that. It is on purpose that `make > install' does not trash sysconfdir Well, at least 178 packages do install files into sysconfdir. A search for sysconf_DATA in https://codesearch.debian.net shows you these packages [4]. > if you install a program you do > not want your configuration files that you have modified to be > overwritten. Yes. And as far as I understand it: - 178 packages violate this requirement, - [0] is a proposal aimed at fulfilling this requirement. Probably we also need to distinguish vendor installs (through the distro's package manager) and from-source installs (./configure && make && make install). > For configuration files that are "global" (which this > basically is); one should not use /usr/etc (which might not exist, or > point to /etc). What should be used is /usr/share/PACKAGE or similar. But the vendors also want to make /usr "strictly read-only and fully cryptographically verified" [0]. AFAICS, the discussion here is about achieving three goals simultaneously: - Installing or reinstalling a package should not overwrite the admin's configuration files. - The admin can create modified configuration files, based on those shipped by the vendor. - /usr should be read-only, even for the admin. A couple of things are not clear to me, though: If /usr is read-only, then - How does the package manager install updates? - How can the admin install packages from-source, with --prefix=/usr? - What about /usr/local? Is it read-only as well? Thus the GNU default prefix will become dysfunctional not only for the unprivileged user but also for the admin user. Bruno [0] https://0pointer.net/blog/projects/stateless.html [4] curl -s https://codesearch.debian.net/results/1d728e07eed9900a/packages.txt
