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#pro… 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

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.

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

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?

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.

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.

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

Your comments and feedback?

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#pro… 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(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

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#pro… 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