[opensuse-factory] RFC: configuration files in /etc

Hi, for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md What is this about? RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files. This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations. So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution. The second thing is: people want to have the configuration files in one place, so that it is easy to find. And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today. The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator. The current proposals are: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#prop... A short summary: Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite. This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks. System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this. /etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one. So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it. Your comments and feedback? Thanks, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On pon, Jun 3, 2019 at 1:50 PM, Thorsten Kukuk <kukuk@suse.de> wrote:
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Additionally, we could look into providing default repositories in a package, instead of dynamically loading them in by YaST on install, for the sake of having that be a stable set of repositories that we offer by default for more than just zypp based package management. Something that would live in /usr/share, wouldn't be easily changeable, and live in a directory that could be shared between zypp and dnf (so no mentioning of zypp, dnf or yum in the path). I'm sure dnf folk would be really glad to contribute their ideas in such a conversation :D LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Jun 3, 2019 at 8:00 AM Stasiek Michalski <hellcp@opensuse.org> wrote:
On pon, Jun 3, 2019 at 1:50 PM, Thorsten Kukuk <kukuk@suse.de> wrote:
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Additionally, we could look into providing default repositories in a package, instead of dynamically loading them in by YaST on install, for the sake of having that be a stable set of repositories that we offer by default for more than just zypp based package management. Something that would live in /usr/share, wouldn't be easily changeable, and live in a directory that could be shared between zypp and dnf (so no mentioning of zypp, dnf or yum in the path). I'm sure dnf folk would be really glad to contribute their ideas in such a conversation :D
Zypper would need to stop compulsively attempting to rewrite .repo files, but yes, that would be nice. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6/3/19 1:50 PM, Thorsten Kukuk wrote:
Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
My first feeling: I'm (often) not a fan of such big changes - like in this case. a) You started with this point as source of the problem: "rpm cannot merge properly". Has anyone tried to enhance / fix it? b) Then: "Others have the same problem", e.g. Fedora. What do they do? I mean other rpm-based distros can't ignore the problem. Do they have a workaround or solution which is "good enough"? And looking beyond rpm: how is DEB or other formats (GUIX, etc.) dealing with the problem? c) The proposal: "place defaults in /usr, and sysadmin overrides in /etc". This means that each application has to support this. Regardless of whether the idea is good or bad, this means redundant code. And this also means that openSUSE would diverge quite a lot from other distros, and - more important - from upstream. It's a long and rocky way to persuade upstream projects (with their limited time) to do changes which are from their perspective "a packaging problem in RPM". The point that some programs have already gone this way does not mean that it is a good general solution for the whole system. For the user, this means information in spread places: if she wants to know the details about a setting in her file in /etc, she has to navigate to the well documented twin in /usr. IMO with this, "/etc is not /usr-friendly" (tm). ;-) As a summary: I don't doubt that you have done your homework upfront, but from this email I have the impression that the a) and b) have not been investigated deep enough. Jumping on another train is sometimes tempting, but fighting the actual problem sounds more natural to me. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bernhard Voelker composed on 2019-06-04 08:32 (UTC+0200):
Thorsten Kukuk wrote:
Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
:-) ...
b) Then: "Others have the same problem", e.g. Fedora. What do they do? I mean other rpm-based distros can't ignore the problem. Do they have a workaround or solution which is "good enough"?...
IME (seat of the pants), I have higher total installed package counts in Fedora than in openSUSE, because I find it's easier on openSUSE to not have unneeded/unwanted rpms installed on it. At the same time, I've been more likely to find a file exists in openSUSE's /etc/ that does not in Fedora's /etc/ than the converse. This I attribute to use of fewer deviations from upstream by Fedora, as well as more use of /usr/ for Fedora's deviations from upstream defaults. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 04, Bernhard Voelker wrote:
On 6/3/19 1:50 PM, Thorsten Kukuk wrote:
Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
My first feeling: I'm (often) not a fan of such big changes - like in this case.
If you did read the full document: it's not a big change, in many cases, it's only consequently using the functionality many packages provide already today.
a) You started with this point as source of the problem: "rpm cannot merge properly". Has anyone tried to enhance / fix it?
I don't know for RPM, but in general, yes.
b) Then: "Others have the same problem", e.g. Fedora. What do they do? I mean other rpm-based distros can't ignore the problem.
They have the same problems and all have their own workarounds. As documented in the document: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#exis... Up to now, they do the same as we: ignore the problem. That's why the DNF develoers are very interested in this.
Do they have a workaround or solution which is "good enough"?
No, else I wouldn't have started this discussion.
c) The proposal: "place defaults in /usr, and sysadmin overrides in /etc".
This means that each application has to support this. Regardless of whether the idea is good or bad, this means redundant code.
Correct. But luckily, many libraries and applications support this already, we only don't make use of it.
And this also means that openSUSE would diverge quite a lot from other distros, and - more important - from upstream. It's a long and rocky way to persuade upstream projects (with their limited time) to do changes which are from their perspective "a packaging problem in RPM".
No, it's not a package problem in RPM, it's a config update problem of upstream. And we have currently the same discussion with the fedora coreos people.
The point that some programs have already gone this way does not mean that it is a good general solution for the whole system.
If you did read my proposal: correct, there is not one solution for everything. That's why I devided the problem into four cases.
For the user, this means information in spread places: if she wants to know the details about a setting in her file in /etc, she has to navigate to the well documented twin in /usr. IMO with this, "/etc is not /usr-friendly" (tm). ;-)
Please look at Tumbleweed today: about 75% of configuration files are in /etc about 25% are spread over /usr Tendency is to even move more away from /etc to own directories somewhere in /usr. The claim "Everything is in /etc" is completly wrong today, we have many, many places were you have to look for configuration files already today. That's why I wrote, we need a well defined directory structure.
As a summary: I don't doubt that you have done your homework upfront, but from this email I have the impression that the a) and b) have not been investigated deep enough.
My impression is, you didn't read my proposal, else you would know that a) and b) were investigated deeply. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6/4/19 8:56 AM, Thorsten Kukuk wrote:
My impression is, you didn't read my proposal, else you would know that a) and b) were investigated deeply.
Admittedly I did not, yet the initial email contained enough for discussion. In another message, Jan talks about "Regular programs" vs. "Cooperative duos". I like the idea: many programs could run without a config file, because they could use their built-in default values ... which should be identical to those in the config file anyway. E.g. sshd_config doesn't have too many active settings left because they are identical to the internal defaults; that's good. But I'd like to point the discussion also another direction. On my daily-work PCs, there are regularly showing up .rpmnew and .rpmsave files from packages I certainly never have touched. As an example, this is '/etc/pulse/client.conf.d/50-system.conf' from the pulseaudio package and '/etc/speech-dispatcher/speechd.conf' from speech-dispatcher. Isn't this a simply packaging bug (or a result from an old, already solved bug)? For me the question is what are the packages which really have this kind of problem - regularly? For those, approaching upstream to have the default files separated is fine for me, I only doubt that we can push such changes effectively with introducing downstream patches. We need to have upstream in the boat since day one, otherwise downstream patches will wait for getting applied upstream for ages. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2019-06-04 08:32, Bernhard Voelker wrote:
On 6/3/19 1:50 PM, Thorsten Kukuk wrote:
Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
My first feeling: I'm (often) not a fan of such big changes - like in this case.
a) You started with this point as source of the problem: "rpm cannot merge properly". Has anyone tried to enhance / fix it?
There simply is no algorithmic way for a program to understand *arbitrary-syntax* config files, a prerequisite for editing them in an automated fashion. Entities who tried: 1. the mechanism employed by Debian/apt-get - requires human intervention and is ineffective without 2. the /etc/sysconfig mechanism - only works for specific config file formats
b) [...] And looking beyond rpm: how is DEB or other formats (GUIX, etc.) dealing with the problem? [...] As a summary: I don't doubt that you have done your homework upfront, but from this email I have the impression that the a) and b) have not been investigated deep enough.
I have the impression that you might not have neither. If GUIX is so important to you, it should have been your job to make the case and defend whatever it is they are doing. Why do others have to do it for you, for free? It reeks of a, for lack of a better term, "type 2 whataboutism" device, in which an implementation is delayed by asking for details on niche cases even if there is no imminent danger of unfixableness for not having a response. I see city councils (Stadtrat) pulling such stunts all the time. But openSUSE is not a council. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, June 4, 2019 9:16:29 AM CEST Jan Engelhardt wrote:
On Tuesday 2019-06-04 08:32, Bernhard Voelker wrote:
a) You started with this point as source of the problem: "rpm cannot merge properly". Has anyone tried to enhance / fix it?
There simply is no algorithmic way for a program to understand *arbitrary-syntax* config files, a prerequisite for editing them in an automated fashion.
IMHO this is the crux here. There is not reliable way to merge changes between two configuration files, so we need a different mechanism. Systemd overrides logic can be used here, but a generalization of this will require changes on some libraries and programs. It can be done, but the strategic about what to fix first is relevant. -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Dienstag, 4. Juni 2019, 08:32:23 CEST schrieb Bernhard Voelker:
On 6/3/19 1:50 PM, Thorsten Kukuk wrote:
Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
My first feeling: I'm (often) not a fan of such big changes - like in this case.
a) You started with this point as source of the problem: "rpm cannot merge properly". Has anyone tried to enhance / fix it?
Well, I've done something directly related minutes ago, and will show, that your general solution is able to mitigate the issue (which is a good thing of course, hence thumbs up from my side), but I want to outline the workflow, that has to be done for the cases beyond your proposal. Running a local GitLab installation from home:darix:apps since about 2 years (now on 15.0). I went though a lot of ups and downs due to package complexity. Most of the times, where automatic updates fail (rpms install correctly, but the gitlab-ce-update fails with some obscure traceback...), installation produced a couple of .rpm{new,save} files. Let's not discuss weal and woe of this specific package, Darix is doing a tough job here, but what's needed to address the cases, that your proposal will not fix, and how this could be provided with a real example. GitLab upgrade from 11.11.0 to 11.11.2. $ gitlab-ce-update Hoping into the basedir within env production 3a51abc8a15d4d06511e9b7331b07175a8ec235ef9c9f818e31b39b3ee314ff7 Gemfile.lock 04112ef0c0e80c1be2093ea3f004770a2ae8daa5afccec364d95fa38a18d189d Gemfile Running rake WARNING: Nokogiri was built against LibXML version 2.9.7, but has dynamically loaded 2.9.9 rake aborted! NameError: uninitialized constant Gitlab::ProxyHTTPConnectionAdapter /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:4:in `<class:Client>' /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:3:in `<module:HipChat>' /srv/www/vhosts/gitlab-ce/config/initializers/hipchat_client_patch.rb:2:in `<top (required)>' /srv/www/vhosts/gitlab-ce/config/environment.rb:6:in `<top (required)>' /usr/bin/rake.ruby2.6:23:in `load' /usr/bin/rake.ruby2.6:23:in `<top (required)>' /usr/bin/bundle.ruby2.6:23:in `load' /usr/bin/bundle.ruby2.6:23:in `<main>' Tasks: TOP => db:migrate => environment (See full trace by running task with --trace) Oh well... $ find . -name \*.rpm\* ./gitlab.yml.rpmnew ./config/application.rb.rpmnew ./initializers/hipchat_client_patch.rb.rpmnew ./initializers/lograge.rb.rpmnew ./initializers/1_settings.rb.rpmnew ./initializers/sentry.rb.rpmnew ./initializers/peek.rb.rpmnew ./initializers/sidekiq.rb.rpmnew ./locales/doorkeeper.en.yml.rpmnew ./locales/en.yml.rpmnew ./routes/group.rb.rpmnew ./routes/project.rb.rpmnew ./routes/admin.rb.rpmnew ./gitlab.yml.example.rpmnew ./routes.rb.rpmnew In the end, one have to go through all these, look at the diff, and either: a) accept the new version b) decide on the diff hunks case by case c) ignore/throw away the new version So, I would love to see an interactive mode in zypper, that shows the cases, that would create .rpmnew/.rpmsave files beforehand (ideally including the diffs), provides additional command line switch to make case a) default (dangerous), and if interactive decisions are enabled, go through every hunk and ask: apply, apply all ((case a) -> next file), keep, keep all (case c) -> next file), go to previous patch/pile, go to next patch/file, edit hunk manually. This would greatly improve the operational safety for complex configuration issues, that compliments your proposal. Done right, we wouldn't see any .rpm{new,save} files anymore, and could treat such as an unsolved issue. Hope not being off topic too much. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 3 Jun 2019, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
The second thing is: people want to have the configuration files in one place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today.
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
The current proposals are: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#prop...
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Your comments and feedback?
I agree the current state is a mess and the above proposal is moving in the correct direction. I don't have a good idea on the password files (there's also the rpm database itself, not in /etc though). Maybe at least a related issue is that we ship a (default, active) configuration in the same package as the service it configures. This for example makes /bin/login install requirements unnecessarily big (OK, bad example - /bin/login comes from bloated util-linux). It also doesn't make it easy to provide different "default" configurations. Needless to say activating a service with a default active configuration at install time might be dangerous. So - please think of separating (default) configuration[s] from the actual service package and make the service inactive as long as no configuration is installed (or as long as the admin did not activate the serivce manually). Richard.
Thanks, Thorsten
-- Richard Biener <rguenther@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

On Tue, 4 Jun 2019, Richard Biener wrote:
On Mon, 3 Jun 2019, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
The second thing is: people want to have the configuration files in one place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today.
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
The current proposals are: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#prop...
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Your comments and feedback?
I agree the current state is a mess and the above proposal is moving in the correct direction. I don't have a good idea on the password files (there's also the rpm database itself, not in /etc though).
Maybe at least a related issue is that we ship a (default, active) configuration in the same package as the service it configures. This for example makes /bin/login install requirements unnecessarily big (OK, bad example - /bin/login comes from bloated util-linux). It also doesn't make it easy to provide different "default" configurations. Needless to say activating a service with a default active configuration at install time might be dangerous.
Btw, Debian at least used to package "sample" config files as /etc/mtools.conf.XYZ (or was it even in /usr/doc/mtools/mtools.conf) and the services were never started automatically. The admin usually could copy the sample to /etc with the proper name and get reasonable default behavior. That was all before systemd arrived of course ;) Richard. -- Richard Biener <rguenther@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

On Tue, Jun 04, Richard Biener wrote:
Btw, Debian at least used to package "sample" config files as /etc/mtools.conf.XYZ (or was it even in /usr/doc/mtools/mtools.conf) and the services were never started automatically. The admin usually could copy the sample to /etc with the proper name and get reasonable default behavior.
I see there only one problem: admin copies the sample configuration file and modifies it. Upstream makes changes to the configuration file, how should the admin find out after the next update, that he has to adjust his configuration file again and which changes were made upstream? -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 4 Jun 2019, Thorsten Kukuk wrote:
On Tue, Jun 04, Richard Biener wrote:
Btw, Debian at least used to package "sample" config files as /etc/mtools.conf.XYZ (or was it even in /usr/doc/mtools/mtools.conf) and the services were never started automatically. The admin usually could copy the sample to /etc with the proper name and get reasonable default behavior.
I see there only one problem: admin copies the sample configuration file and modifies it. Upstream makes changes to the configuration file, how should the admin find out after the next update, that he has to adjust his configuration file again and which changes were made upstream?
As it was only a sample (thus, documentation) changes to the sample do not affect the admins configuation. If there's a format change there exist notification mechanisms that can be triggered on an update, aka "please review your configuration for changes XYZ" with optionally "service disabled" to not leave possibly broken state. To address the casual admin (user) I would go for cups-suse-client-config like packages where users leave configuration up to the packager and/or a configuration management tool that knows how to deal with updates (read: yast). That said I wonder how we protect against somebody installing package FOO that requires apache (for whatever reason) and ending up with a running apache with an insecure default configuration (insecure is very much dependent on view). Richard. -- Richard Biener <rguenther@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)

On 03/06/2019 13.50, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
I have a routine, but it is not trivial. Basically I scan the output of "rpmconfigcheck", and use meld on every file pair, deciding what to apply and what not.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
The second thing is: people want to have the configuration files in one place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today.
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
But this makes harder to read the actual configuration, because we then need to read two files: the one put by rpm, and the one we modified. It would be fine if someone creates an special admin editor that automatically loads both files, merging them into one visual result for us to see and decide what to adapt, so that modifications go to the proper site. As to the configs going to somewhere under /usr, I'm not sure I like that. Maybe a directory under etc, or /etc.something -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Tuesday 2019-06-04 09:43, Carlos E. R. wrote:
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
But this makes harder to read the actual configuration, because we then need to read two files: the one put by rpm, and the one we modified.
There are two types of programs (and hence config strategies) to be aware of. 1. "Regular programs". Picking mc as my example. Such programs have built-in defaults and generally only need to read "one file", or more specifically *one kind of file*, namely, the *user preferences* that override parts of the defaults. 2. "Cooperative duos". Picking systemd as my example: systemd itself cannot offer defaults to start arbitrary programs, because arbitrary programs live at arbitrary paths; it has to rely on another package providing additional information. Consequently, systemd needs to read *two kinds* of files, namely the *vendor snippet* from /usr/lib/systemd/system/, and the *user preference snippet* from /etc/systemd/system/. Now, regular programs outnumber cooperative duos, so the config file problem is not nearly as big as some make it out to be. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/06/2019 11.08, Jan Engelhardt wrote:
On Tuesday 2019-06-04 09:43, Carlos E. R. wrote:
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
But this makes harder to read the actual configuration, because we then need to read two files: the one put by rpm, and the one we modified.
There are two types of programs (and hence config strategies) to be aware of.
1. "Regular programs". Picking mc as my example.
Such programs have built-in defaults and generally only need to read "one file", or more specifically *one kind of file*, namely, the *user preferences* that override parts of the defaults.
Right. Or postfix. But the file lists all the options commented out so that we can easily modify them.
2. "Cooperative duos". Picking systemd as my example:
systemd itself cannot offer defaults to start arbitrary programs, because arbitrary programs live at arbitrary paths; it has to rely on another package providing additional information.
Consequently, systemd needs to read *two kinds* of files, namely the *vendor snippet* from /usr/lib/systemd/system/, and the *user preference snippet* from /etc/systemd/system/.
Except the systemd configuration files, such as "/etc/systemd/journald.conf", which have a single copy.
Now, regular programs outnumber cooperative duos, so the config file problem is not nearly as big as some make it out to be. -- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Tue, Jun 04, Carlos E. R. wrote:
2. "Cooperative duos". Picking systemd as my example:
systemd itself cannot offer defaults to start arbitrary programs, because arbitrary programs live at arbitrary paths; it has to rely on another package providing additional information.
Consequently, systemd needs to read *two kinds* of files, namely the *vendor snippet* from /usr/lib/systemd/system/, and the *user preference snippet* from /etc/systemd/system/.
Except the systemd configuration files, such as "/etc/systemd/journald.conf", which have a single copy.
There are always configuation files, which you have to copy as whole. E.g. PAM configuration files, or configuration files using xml or json. But this are the exceptions. And there are libraries, which can do already today what systemd is doing. In go, it took me some minutes to teach an application to read the configuration the systemd way. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, I do not see how the actual issue could be solved by storing config files at a different location. I think the actual issue is the conflict between what the admin wants to have in his config files versus what a Linux distributor wants to have in his config files. I think the actual issue is the conflict who has the final say in what the config files content is. Because I think there is no automated way to solve that conflict I think the functionality that RPM provides is basically all what can be done in practice. Files not marked: The Linux distributor has the final say in the files content (and admin changes get overwritten/lost). Files marked as %config: The Linux distributor has the final say in the files content (and admin changes are saved as file.rpmsave). Files marked as %config(noreplace): The admin has the final say in the files content (and Linux distributor content is provided as file.rpmnew). When files got changed the admin must manually solve things as he needs it in his particular case. I think the crucial point is that the admin can reliably determine all that has changed. On Jun 3 13:50 Thorsten Kukuk wrote (excerpt):
If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
Offhandedly this looks like a packaging issue because when only a cosmetic typo in a comment was fixed the new config file should be marked as '%config(noreplace)' - but I don't know what happens if the old RPM has '%config' and the new one has '%config(noreplace)' and vice versa.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
But https://users.suse.com/~kukuk/SUSE-CaaSP-Docu/transactional-update.8.html reads: "Changes made to the running root filesystem after transactional-update was started are lost after the next reboot" so it is documented what happens when "admin makes changes to the configuration file" after he "starts an transactional update". I do not understand the "overlay filesystem" part in https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#rpm-... that reads "RPM does not see, that there are modified versions of the config file (e.g. they are stored in an overlay filesystem)" I guess what is meant is that in the running system there is an overlay filesystem e.g. for /etc/ but that does not get included in the snapshot (i.e. the snapshot contains old/outdated files underneath the overlay filesystem). Offhandedly this looks like an issue with creating the snapshot of the running system which is in this special case not a valid snapshot of the running system. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - HRB 21284 (AG Nuernberg) GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 04/06/2019 19:53, Johannes Meixner wrote:
Hello,
I do not see how the actual issue could be solved by storing config files at a different location.
I think the actual issue is the conflict between what the admin wants to have in his config files versus what a Linux distributor wants to have in his config files.
It can pretty easily because under this system the version stored in /etc by the system administrator only contains the values the administrator wants to change from defaults (in theory anyway), then the logic is simple for the program if a config value exists in /etc its the one the program should use, meanwhile its easy for the developers to change the defaults to whatever or add / remove new ones without adding any files, this aproach can still sometimes have the occasional issue for example the administrator could choose a default for a security cypher that becomes insecure and is blocked upstream, at this point the new version of the program has to fail on its next start and leave a nice message in the logs for the administrator to fix, of course a Micro OS system might notice the service not running and roll back to the previous version and the admin might not notice but thats a different problem to solve. But in general it seems better then attempting to merge 2 full config files everytime. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 04, Johannes Meixner wrote:
Hello,
I do not see how the actual issue could be solved by storing config files at a different location.
It's not by storing config files at a different location, it's about separating the original configuration files from user made changes.
I think the actual issue is the conflict who has the final say in what the config files content is.
No, the actual issue is, how to merge the changes the admin made to the configuration files with the changes upstream made to the configuration files.
Because I think there is no automated way to solve that conflict I think the functionality that RPM provides is basically all what can be done in practice.
And many people don't agree here, we think there must be something better.
Files not marked: The Linux distributor has the final say in the files content (and admin changes get overwritten/lost).
This is the worst a packager can do and hopefully nobody does this on openSUSE.
Files marked as %config: The Linux distributor has the final say in the files content (and admin changes are saved as file.rpmsave).
And until the admin finds out, his system is not functional/insecure/... And this only because the package fixed e.g. a typo in a comment. Why not store the admin change somewhere else and merge it at runtime? Then the fixed typo in a comment would not cause any trouble. And I have seen this often enough on openSUSE Tumbleweed...
On Jun 3 13:50 Thorsten Kukuk wrote (excerpt):
If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
Offhandedly this looks like a packaging issue because when only a cosmetic typo in a comment was fixed the new config file should be marked as '%config(noreplace)' - but I don't know what happens if the old RPM has '%config' and the new one has '%config(noreplace)' and vice versa.
Correct, nobody wants to change that always, and you never know what the admin had installed.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
But https://users.suse.com/~kukuk/SUSE-CaaSP-Docu/transactional-update.8.html reads: "Changes made to the running root filesystem after transactional-update was started are lost after the next reboot" so it is documented what happens when "admin makes changes to the configuration file" after he "starts an transactional update".
Sorry, but that is a lame excuse to not solving problems. Only because we don't have a better solution today does not mean, we should not try to fix the problem.
Offhandedly this looks like an issue with creating the snapshot of the running system which is in this special case not a valid snapshot of the running system.
No, this is the result of "atomic updates" and the definition, what that means. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

04.06.2019 13:39, Thorsten Kukuk пишет:
On Tue, Jun 04, Johannes Meixner wrote:
Hello,
I do not see how the actual issue could be solved by storing config files at a different location.
It's not by storing config files at a different location, it's about separating the original configuration files from user made changes.
If application can run without configuration file, why do you need "original configuration file" in the first place? Why cannot application contain the same defaults that are provided by "original configuration file"? If application cannot run without configuration file, it should really never be enabled automatically. It must be local admin responsibility to create suitable configuration file that matches local requirement.
I think the actual issue is the conflict who has the final say in what the config files content is.
No, the actual issue is, how to merge the changes the admin made to the configuration files with the changes upstream made to the configuration files.
This cannot be solved on packaging level at all because it requires knowledge of application configuration semantic. If updated application contains new configuration items that do not conflict with existing ones, and includes suitable defaults for them, then updated application will simply work - no "original configuration file" is needed, nothing needs to be merged. If updated application invalidates previous configuration items there is no way packaging framework can automatically modify exiting configuration (file) - it must be done using application-aware helper or manually. I fail to see how splitting configuration files between different locations solves your actual issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6/9/19 7:54 AM, Andrei Borzenkov wrote:
04.06.2019 13:39, Thorsten Kukuk пишет:
On Tue, Jun 04, Johannes Meixner wrote:
It's not by storing config files at a different location, it's about separating the original configuration files from user made changes.
If application can run without configuration file, why do you need "original configuration file" in the first place? Why cannot application contain the same defaults that are provided by "original configuration file"?
A default config file with comments is often used as a template for a admin-generated config file.
If application cannot run without configuration file, it should really never be enabled automatically.
Full ack.
I think the actual issue is the conflict who has the final say in what the config files content is.
No, the actual issue is, how to merge the changes the admin made to the configuration files with the changes upstream made to the configuration files.
This cannot be solved on packaging level at all because it requires knowledge of application configuration semantic.
Full ack again. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, June 4, 2019 12:23:56 PM CEST Johannes Meixner wrote:
Hello,
I do not see how the actual issue could be solved by storing config files at a different location.
As I can see there is a improvement. The goal is separate the default configuration file (provided by the RPM, that maybe is a direct reflect of the one that the developer provides) from the changes that the user have locally in the machine. If you have a mechanism where you can load the default configuration file and add on top of it the changes that the user provide, you will be more resilient and safe to changes. For one you will not have .rpmnew or .rpmsave that you need to check and resolve. And for other, if a new option is provided and the RPM config file have a sensible default value written for it, this will be accounted the next time the service restart. Only this, IMHO, makes the effort worth it. -- SUSE Linux GmbH Maxfeldstrasse 5 90409 Nuernberg Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On Jun 4 13:30 Alberto Planas Dominguez wrote (excerpt):
On Tuesday, June 4, 2019 12:23:56 PM CEST Johannes Meixner wrote:
I do not see how the actual issue could be solved by storing config files at a different location.
As I can see there is a improvement. The goal is separate the default configuration file (provided by the RPM, that maybe is a direct reflect of the one that the developer provides) from the changes that the user have locally in the machine.
I think that is already provided by RPM when files are marked as '%config(noreplace)'. I do not see a substantial functional difference between having the default config files in a separated directory from using a special file name extension for that. Of course a separated directory looks better/cleaner but my point is that I think the actual problem is not solved. Furthermore with a snapshot of the system before an update one has a generic way to compare the whole updated system with its state before the update so that one does not need to hope and pray for things like RPM '%config(noreplace)' or whatever other stuff to be done right in all cases. I think it is a separated topic how to autmatically combine various configuration snippets in various config files for the configuration of one single service/application. Offhandedly it looks to me as if it could become in the end "yet another RFC 1925 items (5) and (6) attempt" but I could be wrong because I am not an expert in this area. Regardless what the outcome is, all is good as long as Linux distributors together with upstream projects agree on something that is doable and maintainable in practice. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - HRB 21284 (AG Nuernberg) GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6/4/19 3:53 PM, Johannes Meixner wrote:
Regardless what the outcome is, all is good as long as Linux distributors together with upstream projects agree on something that is doable and maintainable in practice.
+1 That's by far the most important statement in this thread. Supporting several OS platforms is already a night-mare. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/06/2019 21:20, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
Your comments and feedback?
I really like the fact that were working with other distro's to all fix this in the same way, from a technical perspective I don't have much to add but if all the major distro's end up solving this problem in the same way then thats an awesome outcome so beest of luck and keep up the great work. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday, 3 June 2019 21:20:55 ACST Thorsten Kukuk wrote:
[...] A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
We akready have /usr/etc/ where some applications place their configs (or overrides), rather than /etc. Whilst I can see the value of this, I'm not a fan of putting system (or global) configurations under /usr. I can see the sense of having the configs for applications that are installed in (or under) /usr/bin or /usr/local/bin having their configs in /usr/etc/ and /usr/local/ etc respectively, but I'd prefer to see system or global configs (related to anything installed in /bin or /sbin live perhaps in /lib/etc, with admin- managed (or overridden) configs in /etc.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
Again, I'd prefer to see them under /lib, rather than /usr.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
Or perhaps it is time to consider a roadmap to deprecating these altogether and moving to an LDAP-based solution? Or is that a bridge too far?
[...]
-- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================

On Tue, Jun 04, Rodney Baker wrote:
On Monday, 3 June 2019 21:20:55 ACST Thorsten Kukuk wrote:
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
Or perhaps it is time to consider a roadmap to deprecating these altogether and moving to an LDAP-based solution? Or is that a bridge too far?
There is one important thing to remember: this has to work even if the rest of the system fails (so rescue system, initrd rescue shell, ...). Most of the time in this scenarios, LDAP will not work, too. And having a local LDAP daemon for system accounts running on every system and a second one for the normal users somewhere else in the network: will this really simplify the setup and make it more robust? Somebody had the idea if it wouldn't be possible to write a sssd plugin to merge this files, no idea if this is feasible. There were also ideas to throw away /etc/passwd, /etc/group, ... and invent something completly new. If somebody has ideas for this and time, fine. But we should make that independent of this discussion, to not make it too complex and block ourself. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 4 June 2019 21:23:03 ACST Thorsten Kukuk wrote:
On Tue, Jun 04, Rodney Baker wrote:
On Monday, 3 June 2019 21:20:55 ACST Thorsten Kukuk wrote:
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
Or perhaps it is time to consider a roadmap to deprecating these altogether and moving to an LDAP-based solution? Or is that a bridge too far?
There is one important thing to remember: this has to work even if the rest of the system fails (so rescue system, initrd rescue shell, ...). Most of the time in this scenarios, LDAP will not work, too.
Yes, good point. LDAP isn't necessarily the right answer, however in these cases only the root user absolutely needs to be able to login. A rescue system or initrd rescue shell could manage that separately (or in parallel) to the normal AAA mechanism. Whatever solution is eventually adopted will certainly need to take those cases into account in the design and implementation.
And having a local LDAP daemon for system accounts running on every system and a second one for the normal users somewhere else in the network: will this really simplify the setup and make it more robust?
In this case, I'd see the remote LDAP server would take precedence over the local, with the local being for fallback; however, I concede that this would be less than optimal. I take your point about system accounts - I spend too much time at work dealing with M$ and AD so I tend to think mainly about user authentication/authorisation/accounting, forgetting about system services.
Somebody had the idea if it wouldn't be possible to write a sssd plugin to merge this files, no idea if this is feasible.
Setting sssd rules to apply policies from the primary server, and use local as fallback should be possible, in theory, but I don't know enough about sssd internals to be sure.
There were also ideas to throw away /etc/passwd, /etc/group, ... and invent something completly new. If somebody has ideas for this and time, fine. But we should make that independent of this discussion, to not make it too complex and block ourself.
Thorsten
Agreed. I only mentioned it because of the comment about pam-related files being an "open problem". I'll drop it now. :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================

On 6/4/19 1:53 PM, Thorsten Kukuk wrote:
And having a local LDAP daemon for system accounts running on every system and a second one for the normal users somewhere else in the network: will this really simplify the setup and make it more robust?
Somebody had the idea if it wouldn't be possible to write a sssd plugin to merge this files, no idea if this is feasible.
While I agree that running a local LDAP is server is too heavy for some scenarios I'd also consider sssd to be too fat for those.
There were also ideas to throw away /etc/passwd, /etc/group, ... and invent something completly new.
Maybe something based on nss-pam-ldap's front-end modules compiled with different name and a light-weight embedded DB like lmdb? Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 4 Jun 2019 at 13:16, Rodney Baker <rodney.baker@iinet.net.au> wrote:
Again, I'd prefer to see them under /lib, rather than /usr.
While I'm often an advocate of creative interpretation of any standard, the FHS in this case is so crystal clear that I don't see how /lib is a viable suggestion /lib is clearly intended for essential libraries and modules needed to get the system booting http://www.pathname.com/fhs/2.2/fhs-3.9.html The /usr hierarchy on the otherhand is intended for 'shareable, read-only data' http://www.pathname.com/fhs/2.2/fhs-4.1.html Given under this model distro-provided configuration files like /usr/etc would be intended to be read-only and shareable across similar openSUSE installations, to be then overridden by host-specific overrides in /etc, I absolutely think the suggestion of using /usr is a far better choice than putting any of this new stuff in /lib -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 4 June 2019 21:33:22 ACST Richard Brown wrote:
On Tue, 4 Jun 2019 at 13:16, Rodney Baker <rodney.baker@iinet.net.au> wrote:
Again, I'd prefer to see them under /lib, rather than /usr.
While I'm often an advocate of creative interpretation of any standard, the FHS in this case is so crystal clear that I don't see how /lib is a viable suggestion
/lib is clearly intended for essential libraries and modules needed to get the system booting
http://www.pathname.com/fhs/2.2/fhs-3.9.html
The /usr hierarchy on the otherhand is intended for 'shareable, read-only data'
http://www.pathname.com/fhs/2.2/fhs-4.1.html
Given under this model distro-provided configuration files like /usr/etc would be intended to be read-only and shareable across similar openSUSE installations, to be then overridden by host-specific overrides in /etc, I absolutely think the suggestion of using /usr is a far better choice than putting any of this new stuff in /lib
Fair enough. I take your point. I know that the FHS has modified some definitions compared to traditional *nix uses, but I'll concede on that point. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================

On Tuesday, 4 June 2019 22:33:47 ACST Rodney Baker wrote:
On Tuesday, 4 June 2019 21:33:22 ACST Richard Brown wrote:
On Tue, 4 Jun 2019 at 13:16, Rodney Baker <rodney.baker@iinet.net.au> wrote:
Again, I'd prefer to see them under /lib, rather than /usr.
While I'm often an advocate of creative interpretation of any standard, the FHS in this case is so crystal clear that I don't see how /lib is a viable suggestion
/lib is clearly intended for essential libraries and modules needed to get the system booting
http://www.pathname.com/fhs/2.2/fhs-3.9.html
The /usr hierarchy on the otherhand is intended for 'shareable, read-only data'
http://www.pathname.com/fhs/2.2/fhs-4.1.html
Given under this model distro-provided configuration files like /usr/etc would be intended to be read-only and shareable across similar openSUSE installations, to be then overridden by host-specific overrides in /etc, I absolutely think the suggestion of using /usr is a far better choice than putting any of this new stuff in /lib
Fair enough. I take your point. I know that the FHS has modified some definitions compared to traditional *nix uses, but I'll concede on that point.
Sorry - forgot to update my "Reply-To" address in the last email... -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================

On Mon, 3 Jun 2019 13:50:55 +0200 Thorsten Kukuk wrote:
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
https://www.freebsd.org/cgi/man.cgi?mergemaster%288%29 -- WBR Kyrill

On Thu, Jun 06, Kyrill Detinov wrote:
Think about a cluster of 200 Nodes, you don't want to merge all configuration files on every node with a manual tool. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, (sorry for being late, the last week was completely busy/crazy here) Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Exa mples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
I like that idea, and if it means that more applications start to support config file includes and whatever.d/* sniplets, I like it even more ;-) Even if implementing that config file handling probably isn't too hard - would it make sense to develop a library to read all the config sniplets and merge them? Maybe it could be based on the systemd code, but should be a standalone project to avoid another dependency on systemd, and to avoid that every project has to re-invent this wheel. Oh, and in the end, systemd could use that library ;-)
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
Sounds solvable with *.d/* files ;-)
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
These could be done via passwd.d/* etc. - either one file per user with username == filename (cleanest solution, but probably not the best idea when it comes to performance) or sniplets with as many lines as make sense for that file(name), with a "last one wins" policy. Note: system users don't come with guaranteed static uids, so packages will still need to run useradd in %post. Packaging a passwd.d/$username file won't work. Please avoid LDAP or other complex solutions. If a system is broken, you really want to have something you can fix with $EDITOR from a recovery system ;-)
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way.
Agreed, we should do this, and should coordinate it with all distros, FHS and the upstream projects.
2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed
I'd sum this up as "moving the default config to /usr/ will be an incremental and ongoing effort" (with a priority on packages included in MicroOS), and ...
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
... this one is really a long term goal ;-) (years, not months)
3. We need to agree on a path below /usr for the default configuration files
I don't have a strong preference, but so far /usr/share/defaults/ and maybe /usr/etc/ look best to me. (If existing applications already use different directories for their default config files, they should move to the standardized directory sooner or later.) The layout inside /usr/share/defaults/ should exactly mirror the layout in /etc/.
Your comments and feedback?
I like the idea :-) Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet. Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too. (I don't have a good solution for that - symlinks don't support fallbacks, and letting update-alternatives change the symlinks in /usr/ is also a bad idea. Nevertheless, I wanted to make sure you have this on your radar.) Regards, Christian Boltz -- It's hard to learn how to ride a bike on the road while watching someone else do it from the sidewalk sitting on your trike :) [David C. Rankin in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jun 9, 2019 at 2:25 PM Christian Boltz <opensuse@cboltz.de> wrote:
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Your comments and feedback?
I like the idea :-)
Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet.
Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too. (I don't have a good solution for that - symlinks don't support fallbacks, and letting update-alternatives change the symlinks in /usr/ is also a bad idea. Nevertheless, I wanted to make sure you have this on your radar.)
Probably the unfortunate answer here is that openSUSE will need to make some actual choices and reduce the usage of alternatives. For example, in Fedora, we do not use alternatives by default to allow switching between Python 2 and Python 3 implementations of binaries, we didn't use alternatives for supporting the use of both createrepo and createrepo_c (we just eventually made createrepo_c provide createrepo), and so on. The concept of alternatives is fundamentally a user/admin decision controlled system. It probably can't support a two-tiered model like what this proposes. But hey, on the flip side: reducing the amount of alternatives invocations will speed up openSUSE software installations and updates! -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On nie, cze 9, 2019 at 8:43 PM, Neal Gompa <ngompa13@gmail.com> wrote:
On Sun, Jun 9, 2019 at 2:25 PM Christian Boltz <opensuse@cboltz.de> wrote:
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Your comments and feedback?
I like the idea :-)
Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet.
Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too. (I don't have a good solution for that - symlinks don't support fallbacks, and letting update-alternatives change the symlinks in /usr/ is also a bad idea. Nevertheless, I wanted to make sure you have this on your radar.)
Probably the unfortunate answer here is that openSUSE will need to make some actual choices and reduce the usage of alternatives. For example, in Fedora, we do not use alternatives by default to allow switching between Python 2 and Python 3 implementations of binaries, we didn't use alternatives for supporting the use of both createrepo and createrepo_c (we just eventually made createrepo_c provide createrepo), and so on.
The concept of alternatives is fundamentally a user/admin decision controlled system. It probably can't support a two-tiered model like what this proposes.
But hey, on the flip side: reducing the amount of alternatives invocations will speed up openSUSE software installations and updates!
There are probably a few places where we could get rid of alternatives an clear them up, like that default-displaymanager, which should have probably been switched to systemd service (loaded by presets) and not alternatives a year ago, so we don't need to have xdm installed on every installation ;) I should get rid of alternatives for branding repos, they don't really work that well anyway, and I doubt anybody uses them for anything productive. Anyway, it's a nice system, but there are better and easier ways to manage some of the provided functionality (like literally switching wallpapers in gui instead of managing that stuff through alternatives). LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On Sun, Jun 09, Christian Boltz wrote:
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Exa mples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
I like that idea, and if it means that more applications start to support config file includes and whatever.d/* sniplets, I like it even more ;-)
Even if implementing that config file handling probably isn't too hard - would it make sense to develop a library to read all the config sniplets and merge them?
We are already working on that ;) https://github.com/parlt91/libeconf
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
These could be done via passwd.d/* etc. - either one file per user with username == filename (cleanest solution, but probably not the best idea when it comes to performance) or sniplets with as many lines as make sense for that file(name), with a "last one wins" policy.
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#etcp... I created a PoC for this already. The glibc NSS plugin was easy, but adjusting all tools to be able to change the password or other data (chfn, chsh, ...) is pretty much work. And the worst is, it does not even solve any of our problems on systems with transactional-updates. You would still use an UID or GID twice.
2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed
I'd sum this up as "moving the default config to /usr/ will be an incremental and ongoing effort" (with a priority on packages included in MicroOS), and ...
Correct.
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
... this one is really a long term goal ;-) (years, not months)
I'm not that sure. We did already some changes for MicroOS only in the past (like moving from cron to systemd.timer, and suddenly everybody was modifying his packages, too. But yes, it will take a long time and I'm pretty sure some applications will never be adjusted.
Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet.
Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too.
I don't see a real problem with /etc/alternatives, it's in the end user configuration. Yes, it's not strictly seperated into system defaults and user changes, but in the end, that's defined by the database. At least I haven't found yet update problems with it. But a real problem with update-alternatives is /var There, we really mixed up everything and this does currently not work with transactional-updates (not even really with snapshots and rollback). Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 11, 2019 at 7:38 AM Thorsten Kukuk <kukuk@suse.de> wrote:
Hi,
On Sun, Jun 09, Christian Boltz wrote:
Am Montag, 3. Juni 2019, 13:50:55 CEST schrieb Thorsten Kukuk:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Exa mples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
I like that idea, and if it means that more applications start to support config file includes and whatever.d/* sniplets, I like it even more ;-)
Even if implementing that config file handling probably isn't too hard - would it make sense to develop a library to read all the config sniplets and merge them?
We are already working on that ;) https://github.com/parlt91/libeconf
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
These could be done via passwd.d/* etc. - either one file per user with username == filename (cleanest solution, but probably not the best idea when it comes to performance) or sniplets with as many lines as make sense for that file(name), with a "last one wins" policy.
https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#etcp...
I created a PoC for this already. The glibc NSS plugin was easy, but adjusting all tools to be able to change the password or other data (chfn, chsh, ...) is pretty much work. And the worst is, it does not even solve any of our problems on systems with transactional-updates. You would still use an UID or GID twice.
2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed
I'd sum this up as "moving the default config to /usr/ will be an incremental and ongoing effort" (with a priority on packages included in MicroOS), and ...
Correct.
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
... this one is really a long term goal ;-) (years, not months)
I'm not that sure. We did already some changes for MicroOS only in the past (like moving from cron to systemd.timer, and suddenly everybody was modifying his packages, too. But yes, it will take a long time and I'm pretty sure some applications will never be adjusted.
Just in case you want to make your TODO list a bit bigger ;-) - I just noticed that you didn't look at /etc/alternatives/ yet.
Currently we have several /usr/bin/whatever, /usr/share/man/whatever symlinks pointing to /etc/alternatives/ - we'll need to find a solution for that too.
I don't see a real problem with /etc/alternatives, it's in the end user configuration. Yes, it's not strictly seperated into system defaults and user changes, but in the end, that's defined by the database. At least I haven't found yet update problems with it. But a real problem with update-alternatives is /var There, we really mixed up everything and this does currently not work with transactional-updates (not even really with snapshots and rollback).
I assume you're referring to /var/lib/alternatives? If openSUSE switched to the version of alternatives shipped in chkconfig[1], we could probably make adjustments to the implementation to deal with this problem. I don't see the Debian guys wanting to change this in their implementation, because they don't care about this problem. It probably makes sense to move it to /usr/lib/sysimage/alternatives, actually. I could easily package this up and make it a drop-in replacement for what we have now in SUSE distributions. [1]: https://github.com/fedora-sysv/chkconfig/blob/master/alternatives.c -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 11, Neal Gompa wrote:
On Tue, Jun 11, 2019 at 7:38 AM Thorsten Kukuk <kukuk@suse.de> wrote:
But a real problem with update-alternatives is /var There, we really mixed up everything and this does currently not work with transactional-updates (not even really with snapshots and rollback).
I assume you're referring to /var/lib/alternatives?
Yes, that's what I mean. A file is modified every time an admin calls update-alternatives to change defaults and at install time.
If openSUSE switched to the version of alternatives shipped in chkconfig[1], we could probably make adjustments to the implementation to deal with this problem. I don't see the Debian guys wanting to change this in their implementation, because they don't care about this problem.
I proposed already to switch some time ago, but the package maintainer refused this ...
It probably makes sense to move it to /usr/lib/sysimage/alternatives, actually. I could easily package this up and make it a drop-in replacement for what we have now in SUSE distributions.
Das the chkconfig variant modifies the files during every call, too? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jun 11, 2019 at 11:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Tue, Jun 11, Neal Gompa wrote:
On Tue, Jun 11, 2019 at 7:38 AM Thorsten Kukuk <kukuk@suse.de> wrote:
But a real problem with update-alternatives is /var There, we really mixed up everything and this does currently not work with transactional-updates (not even really with snapshots and rollback).
I assume you're referring to /var/lib/alternatives?
Yes, that's what I mean. A file is modified every time an admin calls update-alternatives to change defaults and at install time.
If openSUSE switched to the version of alternatives shipped in chkconfig[1], we could probably make adjustments to the implementation to deal with this problem. I don't see the Debian guys wanting to change this in their implementation, because they don't care about this problem.
I proposed already to switch some time ago, but the package maintainer refused this ...
Well, I've wanted to swap out chkconfig and alternatives in SUSE distributions for this implementation for a while, but I've never had sufficient motivation to do it...
It probably makes sense to move it to /usr/lib/sysimage/alternatives, actually. I could easily package this up and make it a drop-in replacement for what we have now in SUSE distributions.
Das the chkconfig variant modifies the files during every call, too?
I need to double check to be sure, but I think it only updates /var/lib/alternatives for an alternative when alternatives is being told to adjust alternatives info (such as adding and removing alternatives). -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Mon, 3 Jun 2019 13:50:55 +0200 schrieb Thorsten Kukuk <kukuk@suse.de>:
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
Is there already documentation how a pkg should deal with files in /etc that will no longer be controlled by rpm? I can imagine the corner case that has to be handled is the presence of /etc/file, /etc/file.rpmnew and /etc/file.rpmsave at the same time. Somehow /etc/file has to be preserved in %pre, and some %post has to decide if it was already changed by the admin. If it was already admin controlled, it has to be preserved. Otherwise it could be removed. There are plenty of empty configuration files which exist only because upstream installs them in /etc and the packagers did not know any better and included them in our pkgs. Olaf

Hi, On Tue, Jun 11, Olaf Hering wrote:
Am Mon, 3 Jun 2019 13:50:55 +0200 schrieb Thorsten Kukuk <kukuk@suse.de>:
- long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything
Is there already documentation how a pkg should deal with files in /etc that will no longer be controlled by rpm? I can imagine the corner case that has to be handled is the presence of /etc/file, /etc/file.rpmnew and /etc/file.rpmsave at the same time. Somehow /etc/file has to be preserved in %pre, and some %post has to decide if it was already changed by the admin. If it was already admin controlled, it has to be preserved. Otherwise it could be removed.
This depends on case by case. E.g.: if your package uses %config today, the result of the move will be identical to an update of that config file: RPM will create a *.rpmsave file and the admin has to merge his changes manual. In this case, I wouldn't bother about the problem at all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, just as update: it looks like the biggest blocking issue is the common directory for configuration files below /usr. So I started a thread on the fhs mailing list: https://lists.linuxfoundation.org/pipermail/fhs-discuss/2019-June/000500.htm... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr. I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards. The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc Starting doing the changes and moving the stuff around is simple, we only need to agree on a location. What's the opinion here? Thorsten On Mon, Jun 03, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
The second thing is: people want to have the configuration files in one place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today.
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
The current proposals are: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#prop...
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Your comments and feedback?
Thanks, Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday, 26 July 2019 14:18 Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
All three make good sense to me - and definitely way more sense than /usr/lib. Personally, I would pick /usr/etc for consistency. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On Fri, Jul 26, Michal Kubecek wrote:
On Friday, 26 July 2019 14:18 Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
All three make good sense to me - and definitely way more sense than /usr/lib. Personally, I would pick /usr/etc for consistency.
Something I was made aware of: /usr/etc is used on other Linux and Non-Linux distributions with a different meaning then we would use it. This could confuse people and could prevent other distributions from joining/following us. And it looks like nobody likes /usr/sysconfig because of /etc/sysconfig. So /usr/config? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday, 26 July 2019 15:02 Thorsten Kukuk wrote:
On Fri, Jul 26, Michal Kubecek wrote:
On Friday, 26 July 2019 14:18 Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
All three make good sense to me - and definitely way more sense than /usr/lib. Personally, I would pick /usr/etc for consistency.
Something I was made aware of: /usr/etc is used on other Linux and Non-Linux distributions with a different meaning then we would use it. This could confuse people and could prevent other distributions from joining/following us.
And it looks like nobody likes /usr/sysconfig because of /etc/sysconfig. So /usr/config?
As I said, all three sound good to me. I agree that /usr/sysconfig could be a bit confusing (because of /etc/sysconfig) and if /usr/etc could be confusing for some users too (I don't know what others use /usr/etc for), /usr/config seems to be the best option. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 7/26/19 2:18 PM, Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
I'd prefer /usr/etc/. For example /usr/sysconfig/ looks too much like being directly related to /etc/sysconfig/. Ciao, Michael.

V Fri, 26 Jul 2019 14:18:59 +0200 Thorsten Kukuk <kukuk@suse.de> napsáno:
Hi,
to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr.
I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards.
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
Hi, for me the best one is /usr/config. /usr/etc sounds like another round of moving /bin to /usr/bin /usr/sysconfig sounds too much related to /etc/sysconfig. So winner from selection is clear for me. Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jul 26, Josef Reidinger wrote:
Hi, for me the best one is /usr/config.
/usr/etc sounds like another round of moving /bin to /usr/bin
But exactly this is what we will do: move the stuff from /etc to /usr/... and change the meaning of /etc a little.
/usr/sysconfig sounds too much related to /etc/sysconfig.
That's my problem with it, too.
So winner from selection is clear for me.
Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk composed on 2019-07-26 14:18 (UTC+0200):
- /usr/sysconfig - /usr/config - /usr/etc
I don't like any of them. My understanding is the files to go in the new location are the distribution's deviations from upstream defaults that admins might wish to override in /etc/ or users via their homedirs. None of the suggestions suggest this. Something like /usr/distcfg/ might, but /distcfg/ or /dconfig/ IMO would be better still. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 7/26/19 2:18 PM, Thorsten Kukuk wrote:
to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr.
I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards.
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
If we do want to follow Poettering and Fedora, then to me it would sound logical to at least go the same direction (together with Fedora?). BTW: is there a list of affected packages available? That can't be too long, is it? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Jul 26, Bernhard Voelker wrote:
On 7/26/19 2:18 PM, Thorsten Kukuk wrote:
to come back to this, original email as reference below. Looks like Lennart Poettering wants to do something similar with Fedora for systemd.volatile, /etc should only contain the user modified files, everything distribution provided should be located in /usr.
I only don't like to fill up /usr/lib with even more stuff people will not find anymore afterwards.
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
If we do want to follow Poettering and Fedora, then to me it would sound logical to at least go the same direction (together with Fedora?).
No, we don't want to follow Poettering and Fedora, especially not, if they move everything to /usr/lib. While we share the same idea, but to solve complelty different problems, we hope we can convience them to follow us and put the configuration files in an own directory. /usr/lib is already overcrowded and you cannot really search/grep there for something. The clear feedback I got until now, especially at the openSUSE Conference, was, please make sure that the configuration files are back in one, or at least two locations and not in several hundred ones.
BTW: is there a list of affected packages available? That can't be too long, is it?
rpm -qf /etc/* /etc/*/* | sort -u The list is long, some of them are low hanging fuits, others will be next to impossible to solve. That's why I'm interested in what Lennart is planing, it could save us quite some work. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2019-07-26 at 14:18 +0200, Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Starting doing the changes and moving the stuff around is simple, we only need to agree on a location.
What's the opinion here?
I'd prefer /usr/config. It's concise and meaningful. Regards, Olav Reinert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

And another round ... On Fri, Jul 26, Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Since the feedback clearly shows, that nearly everybody preferes /usr/etc, we re-evaluated this and thinks we can take the risks, choosing something nearly everybody preferes is also important. Additional, as every important directory should only have three letters, /usr/cfg was thrown in the discussion. /usr/sysconfig is clearly out, looks like nearly nobody likes that. So we currently have: /usr/etc /usr/cfg /usr/config Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Jul 29, 2019 at 12:18 PM Thorsten Kukuk <kukuk@suse.de> wrote:
And another round ...
On Fri, Jul 26, Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Since the feedback clearly shows, that nearly everybody preferes /usr/etc, we re-evaluated this and thinks we can take the risks, choosing something nearly everybody preferes is also important. Additional, as every important directory should only have three letters, /usr/cfg was thrown in the discussion. /usr/sysconfig is clearly out, looks like nearly nobody likes that.
So we currently have:
/usr/etc /usr/cfg /usr/config
I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the collision in usage, "etc" is a terrible name for the configuration directory ("etc" was a catch-all directory originally, which is why so many executable shell scripts were in there...), and we can do better than that in 2019. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Moin, On Mon, 29 Jul 2019, 18:21:21 +0200, Neal Gompa wrote:
On Mon, Jul 29, 2019 at 12:18 PM Thorsten Kukuk <kukuk@suse.de> wrote:
And another round ...
On Fri, Jul 26, Thorsten Kukuk wrote:
The discussions on the FHS mailing list were mixed, but in the end: FHS will not specify anything, we should just do it. The most promising suggestions were: - /usr/sysconfig - /usr/config - /usr/etc
Since the feedback clearly shows, that nearly everybody preferes /usr/etc, we re-evaluated this and thinks we can take the risks, choosing something nearly everybody preferes is also important. Additional, as every important directory should only have three letters, /usr/cfg was thrown in the discussion. /usr/sysconfig is clearly out, looks like nearly nobody likes that.
So we currently have:
/usr/etc /usr/cfg /usr/config
I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the collision in usage, "etc" is a terrible name for the configuration directory ("etc" was a catch-all directory originally, which is why so many executable shell scripts were in there...), and we can do better than that in 2019.
+1 for /usr/etc for obvious reasons: everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least from a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? ) Cheers. l8er manfred

On Mon, 2019-07-29 at 18:54 +0200, Manfred Hollstein wrote:
I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the collision in usage, "etc" is a terrible name for the configuration directory ("etc" was a catch-all directory originally, which is why so many executable shell scripts were in there...), and we can do better than that in 2019.
+1 for /usr/etc for obvious reasons:
everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least from a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? )
+1 for /usr/etc from me also. It's important that we establish the relationship between /etc and /usr/etc, and that's easiest done with reflecting that in their names. The objections/alternatives to /usr/etc only ring true to me if we are willing to start a crusade for renaming /etc to something else. And I'm not ;) Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dear Manfred, dear Richard, Am Dienstag, 30. Juli 2019, 15:01:46 CEST schrieb Richard Brown:
On Mon, 2019-07-29 at 18:54 +0200, Manfred Hollstein wrote:
I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the collision in usage, "etc" is a terrible name for the configuration directory ("etc" was a catch-all directory originally, which is why so many executable shell scripts were in there...), and we can do better than that in 2019.
+1 for /usr/etc for obvious reasons: everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least
from
a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? )
+1 for /usr/etc from me also.
It's important that we establish the relationship between /etc and /usr/etc, and that's easiest done with reflecting that in their names.
Well, allow me to bring an answer from Thorsten to your attention (as of Sun, 28 Jul 2019 10:38:07 +0200):
Hmm, do you have any pointer on such distributions and their usage pattern of /usr/etc? I wasn't able to find something, that really matters in this regard.
OSTree is using /usr/etc to store data for their three-way-diff-merge of configuration files. On *BSD, users have to edit the files in /usr/etc, while in our case, this should be "read-only", and user have to create the changes in /etc. There are distributions who did the "UsrMerge" by moving /etc to /usr/etc and makeing /etc a symlink to /usr
I don't care much about *BSD layout, but since OSTree seems an interesting project, as well as the last point renders this approach problematic at least. So he concludes:
What would happen if we choose /usr/etc and other distributions cannot follow us? 1. we are the only one who are doing, and will always be different 2. The others will come up with another standard, and either we are
alone/different, or have to do the work a second time.
I don't like any of this options.
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already). So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it? Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Pete, On Tue, 30 Jul 2019, 16:34:59 +0200, Hans-Peter Jansen wrote:
Dear Manfred, dear Richard,
Am Dienstag, 30. Juli 2019, 15:01:46 CEST schrieb Richard Brown:
[...] OSTree is using /usr/etc to store data for their three-way-diff-merge of configuration files. On *BSD, users have to edit the files in /usr/etc, while in our case, this should be "read-only", and user have to create the changes in /etc. There are distributions who did the "UsrMerge" by moving /etc to /usr/etc and makeing /etc a symlink to /usr
I don't care much about *BSD layout, but since OSTree seems an interesting project, as well as the last point renders this approach problematic at least.
So he concludes:
What would happen if we choose /usr/etc and other distributions cannot follow us? 1. we are the only one who are doing, and will always be different 2. The others will come up with another standard, and either we are
alone/different, or have to do the work a second time.
I don't like any of this options.
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already).
So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it?
Nevertheless, Thorsten still kept /usr/etc in hist list when opening the second round ;) To be honest, libostree has a pretty clear focus, which does not actually cover much of what I care about, at least. OpenEmbedded sounds great, but I doubt, there will be any relevant standard adhered to by any of all the players outside building and selling their embedded Linux appliances - I spent too much time talking with all of them between 1999 to 2006; everybody was listening, but nobody wanted to buy into it... "flatpak", I don't give a shit at all! "GNOME Continuous", again, I don't like GNOME either... So, to me it sounds more how much we can win building on a long established relationship between /etc <-> /usr/etc, rather than running discussions which may lead to nowhere... At least, we're in the second round this time, thanks Thorsten! FWIW, I certainly can live with /usr/config, but from where I come from, /usr/etc appears much more appealing and well known and established.
Cheers, Pete
Cheers. l8er manfred

On 7/31/19 12:04 AM, Hans-Peter Jansen wrote:
Dear Manfred, dear Richard,
Am Dienstag, 30. Juli 2019, 15:01:46 CEST schrieb Richard Brown:
On Mon, 2019-07-29 at 18:54 +0200, Manfred Hollstein wrote:
I'd prefer /usr/config or /usr/cfg over /usr/etc. Aside from the collision in usage, "etc" is a terrible name for the configuration directory ("etc" was a catch-all directory originally, which is why so many executable shell scripts were in there...), and we can do better than that in 2019.
+1 for /usr/etc for obvious reasons: everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least
from
a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? )
+1 for /usr/etc from me also.
It's important that we establish the relationship between /etc and /usr/etc, and that's easiest done with reflecting that in their names.
Well, allow me to bring an answer from Thorsten to your attention (as of Sun, 28 Jul 2019 10:38:07 +0200):
Hmm, do you have any pointer on such distributions and their usage pattern of /usr/etc? I wasn't able to find something, that really matters in this regard.
OSTree is using /usr/etc to store data for their three-way-diff-merge of configuration files. On *BSD, users have to edit the files in /usr/etc, while in our case, this should be "read-only", and user have to create the changes in /etc. There are distributions who did the "UsrMerge" by moving /etc to /usr/etc and makeing /etc a symlink to /usr
I don't care much about *BSD layout, but since OSTree seems an interesting project, as well as the last point renders this approach problematic at least.
So he concludes:
What would happen if we choose /usr/etc and other distributions cannot follow us? 1. we are the only one who are doing, and will always be different 2. The others will come up with another standard, and either we are
alone/different, or have to do the work a second time.
I don't like any of this options.
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already).
So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it?
I tend to agree, OSTree is being used for rpm-ostree which seems to be worked on by fedora / CoreOS people, so if that is a block from them ever being able to ever swap to /usr/etc long term even if we can't convince them away from /usr/lib in the short term then it seems like a poor choice, even if it makes the most sense for users. I have also never looked at libostree so maybe us using /usr/etc for other things won't directly interfere with it. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 2019-07-31 at 14:01 +0930, Simon Lees wrote:
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already).
So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it?
I tend to agree, OSTree is being used for rpm-ostree which seems to be worked on by fedora / CoreOS people, so if that is a block from them ever being able to ever swap to /usr/etc long term even if we can't convince them away from /usr/lib in the short term then it seems like a poor choice, even if it makes the most sense for users.
I have also never looked at libostree so maybe us using /usr/etc for other things won't directly interfere with it.
I have a good working relationship with the rpm-ostree folks through my work I did with moving /var/lib/rpm That case had a number of similarities with that one, and I managed to persuade them to accomodate our changes then I don't expect this time will be any different - we should do as we did in that case, pick the best solution for us, based on our world as we see it, and then work with others. So I'm still all for /usr/etc to solve our problems. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Chairman - openSUSE Phone +4991174053-361 SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Mittwoch, 31. Juli 2019, 10:07:56 CEST schrieb Richard Brown:
On Wed, 2019-07-31 at 14:01 +0930, Simon Lees wrote:
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already).
So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it?
I tend to agree, OSTree is being used for rpm-ostree which seems to be worked on by fedora / CoreOS people, so if that is a block from them ever being able to ever swap to /usr/etc long term even if we can't convince them away from /usr/lib in the short term then it seems like a poor choice, even if it makes the most sense for users.
I have also never looked at libostree so maybe us using /usr/etc for other things won't directly interfere with it.
I have a good working relationship with the rpm-ostree folks through my work I did with moving /var/lib/rpm
That case had a number of similarities with that one, and I managed to persuade them to accomodate our changes then
I don't expect this time will be any different - we should do as we did in that case, pick the best solution for us, based on our world as we see it, and then work with others.
So I'm still all for /usr/etc to solve our problems.
I had a cursory look at libostree to find out, if this is configurable somehow, as well as how subprojects access it, but failed so far. Sorry. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jul 31, 2019 at 4:08 AM Richard Brown <rbrown@suse.de> wrote:
On Wed, 2019-07-31 at 14:01 +0930, Simon Lees wrote:
Let me add: we should not interfere with libostree based projects (which would make libostree based projects unfeasible for our platform, especially since some Fedora-based projects adapt this already).
So this is enough evidence of not using /usr/etc, no matter how much we all agree on this choice otherwise, isn't it?
I tend to agree, OSTree is being used for rpm-ostree which seems to be worked on by fedora / CoreOS people, so if that is a block from them ever being able to ever swap to /usr/etc long term even if we can't convince them away from /usr/lib in the short term then it seems like a poor choice, even if it makes the most sense for users.
I have also never looked at libostree so maybe us using /usr/etc for other things won't directly interfere with it.
I have a good working relationship with the rpm-ostree folks through my work I did with moving /var/lib/rpm
That case had a number of similarities with that one, and I managed to persuade them to accomodate our changes then
I don't expect this time will be any different - we should do as we did in that case, pick the best solution for us, based on our world as we see it, and then work with others.
So I'm still all for /usr/etc to solve our problems.
They haven't even made the switch from /usr/share/rpm to /usr/lib/sysimage/rpm yet, and that one is relatively "easy" to do. I suspect it'll be much harder to get them (and other OSTree users) to change so that /usr/etc is free for this purpose. I'm not as confident about getting that through, but we can *try*. That said, I'm surprised that there is an aspect of Linux you're shy about! I wish we *could* rename /etc to /cfg or /config now... It's much more meaningful than "et cetera"... But one step at a time! So again, I support /usr/config or /usr/cfg (in that order of preference). -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, 1 August 2019 3:06 Neal Gompa wrote:
That said, I'm surprised that there is an aspect of Linux you're shy about!
I wish we *could* rename /etc to /cfg or /config now... It's much more meaningful than "et cetera"... But one step at a time!
Do you seriously wish to break unknown number or custom and third party scripts and applications with hardcoded /etc/* paths (in addition to lots of work on software which is part of the distribution - and be sure that lot of that would end up being permanent openSUSE specific patches) just for... what gain exactly? Sure, some design decisions taken 20+ (in this case, rather 40+) years ago may seem strange (or even "WtF were they thinking?!") today but I'm pretty sure many of the design decisions which seem to make perfect sense now will provoke exactly the same reaction in 20 years... Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Aug 1, 2019 at 1:02 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Thursday, 1 August 2019 3:06 Neal Gompa wrote:
That said, I'm surprised that there is an aspect of Linux you're shy about!
I wish we *could* rename /etc to /cfg or /config now... It's much more meaningful than "et cetera"... But one step at a time!
Do you seriously wish to break unknown number or custom and third party scripts and applications with hardcoded /etc/* paths (in addition to lots of work on software which is part of the distribution - and be sure that lot of that would end up being permanent openSUSE specific patches) just for... what gain exactly?
Sure, some design decisions taken 20+ (in this case, rather 40+) years ago may seem strange (or even "WtF were they thinking?!") today but I'm pretty sure many of the design decisions which seem to make perfect sense now will provoke exactly the same reaction in 20 years...
It wasn't strange 40 years ago. But we've (mostly) moved everything around or otherwise eliminated the things in /etc that are not configuration files now. And no, I wouldn't just go and break everything. I'd start with doing it the same way we're doing usrmerge: moving the content and placing a symlink. Things don't break up front and fixing can be done over time. Applications shouldn't have hardcoded paths for /etc anyway, because that means they can't be installed to /usr/local, which has a different path for configs (/usr/local/etc). And generally, most software has some kind of --sysconfdir= or equivalent config option, so that this can be set. But again, one step at a time... -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jul 31, Neal Gompa wrote:
They haven't even made the switch from /usr/share/rpm to /usr/lib/sysimage/rpm yet, and that one is relatively "easy" to do. I suspect it'll be much harder to get them (and other OSTree users) to change so that /usr/etc is free for this purpose.
I'm not as confident about getting that through, but we can *try*.
That said, I'm surprised that there is an aspect of Linux you're shy about!
I wish we *could* rename /etc to /cfg or /config now... It's much more meaningful than "et cetera"... But one step at a time!
So again, I support /usr/config or /usr/cfg (in that order of preference).
I personal still prefer /usr/share/defaults :) and would like /usr/cfg choose over /usr/etc. But even when we discussed this SUSE internal the last week, the result was unamimously: everybody wanted /usr/etc, no alternative, no new suggestion, nothing else. I have no idea why the OSTree developers did choose /usr/etc and not /usr/lib/ostree, if this would be OStree specific data. In the end, /usr/etc contains the distribution default configuration files. So exctly the same as we plan to do. So from this side, there should be no conflict. OSTree uses /usr/etc to populate /etc. Something which would be obsolete long term, as /etc contains only the changes anyways, independent of our or Lennarts plans. So if OSTree continues to merge /etc with /usr/etc in /etc, there is no conflict with our proposal. And last, CoreOS is not designed that people install their workload as RPM but run it as container. Even if they can now install their own RPMs. So no real problem, too. In the end: currently, I don't see a real problem with ostree on the one side, and on the other side: if so many people prefer /usr/etc, I would choose this to let the people feel more "coming home" than "I have to learn something completly new". Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-07-29 18:54, Manfred Hollstein wrote:
everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least from a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? )
Technically speaking, today's equivalent of the hosts file lives in one or more unspecified databases. In case of Windows, there is a program called "DNS Manager" to edit it (this is probably already outdated information, looks like they have something new in Windows 2016 again). As is common with Microsoft products, the data is stored in binary form in some arcane location somewhere (the registry, an AD, ... needless to say, the data _will_ end up on an actual storage device at some point). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, 18 Aug 2019, 14:59:33 +0200, Jan Engelhardt wrote:
On Monday 2019-07-29 18:54, Manfred Hollstein wrote:
everyone coming from a *NIX background *knows* what /etc is and probably can deduct, what /usr/etc is. Even if you believe it was a terrible name, it *is* a name known to a lot of people, at least from a generation before 2019 or maybe more ;) Even M$ adopted it... (do you know where their /etc/hosts equivalent lives ;) ? )
Technically speaking, today's equivalent of the hosts file lives in one or more unspecified databases. In case of Windows, there is a program called "DNS Manager" to edit it (this is probably already outdated information, looks like they have something new in Windows 2016 again). As is common with Microsoft products, the data is stored in binary form in some arcane location somewhere (the registry, an AD, ... needless to say, the data _will_ end up on an actual storage device at some point).
but, you can still edit the file (C:Windows/System32/drivers/etc/hosts), and it gets respected. So, the interface is still the same. Cheers. l8er manfred

On 6/3/19 1:50 PM, Thorsten Kukuk wrote:
Hi,
for this, who don't want to read a lot of text, there is a video of my talk about this topic from openSUSE Conference: https://youtu.be/ony0ajC0PWA
The slides can be found here: https://github.com/thkukuk/atomic-updates_and_etc/tree/master/Slides
and the full, detailed abstract can be found here: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md
What is this about?
RPM has a really very simple configuration file handling: overwrite the config, move it away and write the new config or write the new config in a different file (*.rpmsave and *.rpmnew). If the rpm contains a configuration file marked as %config, and the packager fixes a typo in a comment, RPM will move the by the admin modified and adjusted configuration file away and put's the default configuration file there, which means, your service will not work until you merge the configuration files.
This is already bad, but it's getting really worse if you think about atomic updates (transactional-updates on openSUSE): - admin modifies configuration files - admin starts an transactional update, the configuration file will be modified - admin makes changes to the configuration file - admin reboots to active the changes -> admin needs to find out which changes where done by whom and needs to merge them all to get the service working again
While this shouldn't happen very often, more really seldom, if it happens, it's really bad. Especially, if you think about big clusters with many machines and not only a few workstations.
So I started looking into different solutions. The first thing is: we are not alone with the problem, every distribution with atomic updates has it, but every distribution has their own solution. Which reminds me on the pre-FHS times, when you had to learn for every distribution again where the configuration files and other tools could be found. So we need something, which helps everybody and is good enough specified, that people will use this solution.
The second thing is: people want to have the configuration files in one place, so that it is easy to find.
And at least, no, there is not the perfect solution solving everything, for some I even have no idea, but for others we make big improvements compared to today.
The goal is to provide a concept working for all Linux Distributors (like the FHS, preferred is to get this into the FHS). Short to midterm, it should solve the problems with atomic updates. Midterm to longterm, the result should be, that no package installs anything in /etc, it should only contain changes made by the system administrator or configuration files managed by the system administrator.
The current proposals are: https://github.com/thkukuk/atomic-updates_and_etc/blob/master/README.md#prop...
A short summary:
Application configuration files: Do something similar to what systemd is already doing today (See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, "Overriding vendor settings"). Put the default, by a Linux distributor shipped configuration files somewhere below /usr, and /etc only contains the overwrite.
This sounds like a lot of work, but in reality, many applications we have on openSUSE Tumbleweed alredy support different locations for configuration files and overwrite of them, like sysctl, dracut, PAM and many more. For this, this is only a packaging exercise and rpmlint checks.
System databases: This are files in /etc like rpc, services and protocols. We can put them somewhere below /usr, and /etc/ only contains the changes. A glibc NSS module could merge them automatcially, different implementations do exist already today for this.
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
So, what is the expected outcome of this mail? 1. We need to agree, if we want to solve the problem or not In my opinion, there is no real choice, if we don't do it coordinated as Linux distributor, this will happen in a chaotic way. 2. We need to agree on the goal, so for me, this would be: - short term: solve the problem for packages on openSUSE MicroOS - mid term: solve the problem for openSUSE Tumbleweed - long term: /etc/ only contains admin created files, a Linux Distribution does not install there anything 3. We need to agree on a path below /usr for the default configuration files 4. We need to agree on how we want to solve it.
Your comments and feedback?
Thanks, Thorsten
Maybe see what Clear Linux does with that? It brands it as "stateless" feature[0]. Not sure about harder ones, e.g. /etc/shadow, but the default configs for packages seem to go under /usr/share/defaults. [0] <https://clearlinux.org/documentation/clear-linux/concepts/stateless> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Jul 28, Oleksii Vilchanskyi wrote:
Maybe see what Clear Linux does with that? It brands it as "stateless" feature[0]. Not sure about harder ones, e.g. /etc/shadow, but the default configs for packages seem to go under /usr/share/defaults.
You did read my referenced document? ;) While I really like /usr/share/defaults best, the problem is, that /usr/share should be shareable, but passwd and group are not shareable. Thorsten
[0] <https://clearlinux.org/documentation/clear-linux/concepts/stateless> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (25)
-
Alberto Planas Dominguez
-
Andrei Borzenkov
-
Bernhard Voelker
-
Carlos E. R.
-
Christian Boltz
-
Felix Miata
-
Hans-Peter Jansen
-
Jan Engelhardt
-
Johannes Meixner
-
Josef Reidinger
-
Kyrill Detinov
-
Manfred Hollstein
-
Michael Ströder
-
Michal Kubecek
-
Neal Gompa
-
Olaf Hering
-
Oleksii Vilchanskyi
-
Richard Biener
-
Richard Brown
-
Richard Brown
-
Rodney Baker
-
seroton10@gmail.com
-
Simon Lees
-
Stasiek Michalski
-
Thorsten Kukuk