[opensuse-factory] /etc/sysconfig vs. /etc/default
Hi, Currently we have two directories with similar usage: - /etc/default, seems to come from Debian, mainly used by upstream projects on openSUSE - /etc/sysconfig, mainly based on Red Hat, mainly used for start scripts written by us. I will ignore the subdirectories here. Both have files with in a KEY=VALUE format which can be sources by a shell. /etc/default is controlled by RPM, so changes in the config files lead to *.rpmsave or *.rpmnew files. /etc/sysconfig is controlled by fillup. Adding new variables is easy, changing defaults or removing variables is next to impossible in most cases. Why do I write this? No, I don't want to get rid of /etc/sysconfig, but bring up an idea how to solve quite some of the problems with updating sysconfig files. Many bug reports about sysconfig files get closed as "Wontfix", since changing defaults is really difficult, as we don't want to overwrite user made changes, and adjusting comments is next to impossible. As result, an user may have many sysconfig files with outdated comments and content after a longer time after installation. This can be very irritating or lead to not working configurations and frustrations as following this steps does not lead to success. Hey, we still have comments which tells the user that he has now to run SuSEconfig because of this! To run and manage our openSUSE containers via podman and systemd, we started with as example for the bind container: /etc/sysconfig/container-bind container-bind.service, which did contain: EnvironmentFile=/etc/sysconfig/container-bind and we run immeaditly into problems as there were typos in it which we couldn't fix in an easy way on already installed systems. But we have now /usr/etc and /usr/etc/default :) So /usr/etc/default/container-bind contains now the system default (fillup doesn't make sense here, as this file is RPM controlled and should not be changed by an user), and the user can override single variables by creating a file /etc/default/container-bind with just this modified variables. The container-bind.service looks now like: EnvironmentFile=/usr/etc/default/container-bind EnvironmentFile=-/etc/default/container-bind All update problems solved without the need to find out, if a variable is modified by an user or not. This is not a proposal to change now all sysconfig files, but I think many packages could benefit from such a change, especially if they are really old and the sysconfig template gets often changed. The packaging change is trivial: install the sysconfig template in /usr/etc/default/, adjust your docu and remove the fillup call. And you need to think about, if you want to rename the old sysconfig file to *.rpmsave or move it to /etc/default. Is this something we should propose as "best practise", or are there reasons not to do so we haven't found yet? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 28, 2020 at 5:31 AM Thorsten Kukuk <kukuk@suse.de> wrote:
Hi,
Currently we have two directories with similar usage:
- /etc/default, seems to come from Debian, mainly used by upstream projects on openSUSE - /etc/sysconfig, mainly based on Red Hat, mainly used for start scripts written by us. I will ignore the subdirectories here.
Both have files with in a KEY=VALUE format which can be sources by a shell.
/etc/default is controlled by RPM, so changes in the config files lead to *.rpmsave or *.rpmnew files.
/etc/sysconfig is controlled by fillup. Adding new variables is easy, changing defaults or removing variables is next to impossible in most cases.
Why do I write this? No, I don't want to get rid of /etc/sysconfig, but bring up an idea how to solve quite some of the problems with updating sysconfig files. Many bug reports about sysconfig files get closed as "Wontfix", since changing defaults is really difficult, as we don't want to overwrite user made changes, and adjusting comments is next to impossible. As result, an user may have many sysconfig files with outdated comments and content after a longer time after installation. This can be very irritating or lead to not working configurations and frustrations as following this steps does not lead to success. Hey, we still have comments which tells the user that he has now to run SuSEconfig because of this!
To run and manage our openSUSE containers via podman and systemd, we started with as example for the bind container:
/etc/sysconfig/container-bind
container-bind.service, which did contain: EnvironmentFile=/etc/sysconfig/container-bind
and we run immeaditly into problems as there were typos in it which we couldn't fix in an easy way on already installed systems.
But we have now /usr/etc and /usr/etc/default :)
So /usr/etc/default/container-bind contains now the system default (fillup doesn't make sense here, as this file is RPM controlled and should not be changed by an user), and the user can override single variables by creating a file /etc/default/container-bind with just this modified variables.
The container-bind.service looks now like: EnvironmentFile=/usr/etc/default/container-bind EnvironmentFile=-/etc/default/container-bind
All update problems solved without the need to find out, if a variable is modified by an user or not.
This is not a proposal to change now all sysconfig files, but I think many packages could benefit from such a change, especially if they are really old and the sysconfig template gets often changed. The packaging change is trivial: install the sysconfig template in /usr/etc/default/, adjust your docu and remove the fillup call. And you need to think about, if you want to rename the old sysconfig file to *.rpmsave or move it to /etc/default.
Is this something we should propose as "best practise", or are there reasons not to do so we haven't found yet?
Actually, a question to ask is: why do we need fillup? In Fedora, we don't use fillup at all for /etc/sysconfig files either, and people don't generally miss it. In fact, because we don't have it there, there's been a lot more effort to make things work without environment files or with layered configuration, because the fillup system doesn't exist as a crutch to avoid it. -- 真実はいつも一つ！/ 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 Mon, Sep 28, Neal Gompa wrote:
Actually, a question to ask is: why do we need fillup? In Fedora, we don't use fillup at all for /etc/sysconfig files either, and people don't generally miss it. In fact, because we don't have it there, there's been a lot more effort to make things work without environment files or with layered configuration, because the fillup system doesn't exist as a crutch to avoid it.
The idea behind /etc/sysconfig was: admin changes it, we don't modify their changes, we don't remove their changes if the package gets deinstalled. And here fillup is necessary to add new variables to an existing file. fillup cannot remove variables as user configuration should never get deleted, even if the package gets removed. And here all the problems starts. Of course do we remove variables, and keeping them only confuses users, but does not help them. And of course packages changes, which would require a change in the sysconfig file. And of course do people de-install and re-install a package to start from scratch, means do a "reset" of that package configuration. Keeping the sysconfig file prevents this. When fillup got introduced over 20 years ago, it was a good thing at that time. When I wrote the first mail I also thought about a valid usecase for keeping /etc/sysconfig today. I haven't found one. My question would be: for what is /etc/sysconfig needed at all? In the end, we have {/usr},/etc/default, which solves all the problems very nicely. All my new projects will only use /etc/default, I don't see any sense in /etc/sysconfig anymore, which makes provides a real advantage or benefit. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mon, 28 Sep 2020 15:33:36 +0200 schrieb Thorsten Kukuk <kukuk@suse.de>:
When I wrote the first mail I also thought about a valid usecase for keeping /etc/sysconfig today. I haven't found one.
The obvious one: We are SUSE, we do it that way since two decades. The potential trouble with fillup will also happen with every other location: stale admin controlled key=value entries will remain unless the pkg provides an upgrade path. Some pkgs have one, most pkgs do not. It is up to each pkg to decide how to move forward with existing files. Using two 'EnvironmentFile=' statements is certainly a nice feature, whether it really solves anything depends on the individual pkg. The comments in sysconfig could be adjusted if someone would just have done the hard work of proper text processing... But I think our usage of sysconfig is an example of "how to put documentation in the wrong place". One consumer of properly formatted comments was, and maybe still is, YaST2. A better place for documentation of each potential variable is a man page, and in case of YaST2 a separate rpm-controlled text file. I briefly looked through all files stored in {/usr,}/etc/default. Most of them should be removed right away. Many empty variables, even empty(!) config files. Of course each pkg has different requirements. My prime nit remains grub: None of the variables in /etc/default/grub must be provided by rpm. Undefined variables have to be handled anyway in the shell script. None of the recognized variables are documented. YaST writes /etc/default/grub anyway, so it will be always "dirty". Olaf
On Mon, 2020-09-28 at 17:35 +0200, Olaf Hering wrote:
Am Mon, 28 Sep 2020 15:33:36 +0200 schrieb Thorsten Kukuk <kukuk@suse.de>:
When I wrote the first mail I also thought about a valid usecase for keeping /etc/sysconfig today. I haven't found one.
The obvious one: We are SUSE, we do it that way since two decades.
Doing something in an imperfect way for 20 years isn't really good grounds for not seeking to improve the situation now.
The potential trouble with fillup will also happen with every other location: stale admin controlled key=value entries will remain unless the pkg provides an upgrade path. Some pkgs have one, most pkgs do not. It is up to each pkg to decide how to move forward with existing files.
Indeed. I support Thorsten's suggestion of retiring /etc/sysconfig and instead using /etc/default and /usr/etc/default but that agreement comes with the assumption that we throw the mess that is fillup out of the window at the same time. This makes sense, given /usr/etc/* is an area we should _know_ we control, and we do not have to worry about users tampering with that location (as they have /etc/* for that), so we can take the proper measures to ensure our /usr/etc/* config files are always pristine, sane defaults, without any stale values. Yes, /etc/* might contain user-supplied stale values after an upgrade. But that's fine. /etc/* should be considered _user data_. It's the user's domain, let them put old nonsense in there, or broken nonsense. In the same way we shouldn't be tinkering with what users put in their /home, we should leave /etc well alone and trust in the user to be able to manage that themselves properly. With /usr/etc providing a pristine reference point, it should always be easy for users to evaluate their custom configurations for things that can be removed or optimised. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.20 um 12:04 schrieb Richard Brown:
Yes, /etc/* might contain user-supplied stale values after an upgrade. But that's fine. /etc/* should be considered _user data_. It's the user's domain, let them put old nonsense in there, or broken nonsense. In the same way we shouldn't be tinkering with what users put in their /home, we should leave /etc well alone and trust in the user to be able to manage that themselves properly.
OK.
With /usr/etc providing a pristine reference point, it should always be easy for users to evaluate their custom configurations for things that can be removed or optimised.
So what about YaST? Where would YaST bootloader module write its configuration? To /usr/etc/default/grub? No, that's package's domain to /etc/default/grub? No, that's my (user's) domain to /var/adm/default/grub? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 29 septembre 2020 à 15:04 +0200, Stefan Seyfried a écrit :
Am 29.09.20 um 12:04 schrieb Richard Brown:
Yes, /etc/* might contain user-supplied stale values after an upgrade. But that's fine. /etc/* should be considered _user data_. It's the user's domain, let them put old nonsense in there, or broken nonsense. In the same way we shouldn't be tinkering with what users put in their /home, we should leave /etc well alone and trust in the user to be able to manage that themselves properly.
OK.
With /usr/etc providing a pristine reference point, it should always be easy for users to evaluate their custom configurations for things that can be removed or optimised.
So what about YaST? Where would YaST bootloader module write its configuration?
To /usr/etc/default/grub? No, that's package's domain to /etc/default/grub? No, that's my (user's) domain to /var/adm/default/grub?
I'd say /etc/default/grub : YaST is working on behalf on the user. It is "just" a nicer UI to /etc/default/grub than vi/emacs ;) -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On Tue, 2020-09-29 at 13:56 +0000, Frederic Crozat wrote:
With /usr/etc providing a pristine reference point, it should always be easy for users to evaluate their custom configurations for things that can be removed or optimised.
So what about YaST? Where would YaST bootloader module write its configuration?
To /usr/etc/default/grub? No, that's package's domain to /etc/default/grub? No, that's my (user's) domain to /var/adm/default/grub?
I'd say /etc/default/grub : YaST is working on behalf on the user.
It is "just" a nicer UI to /etc/default/grub than vi/emacs ;)
I'd agree, with the following theoretical caveat: There are some configuration files not owned by any package, such as /etc/fstab In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc. Of course such a option would need some magic done to handle such a split-fstab, so this is just in theory, presented as an idea to consider to see if we feel like going down that road. In practice, the simple straightforward "YaST does /etc, cuz its a tool used by the user" is a good assumption IMHO. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Moin, On Tue, 29 Sep 2020, 16:25:13 +0200, Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
just to be sure I get this right... /etc/fstab is for the local admin to add stuff which otherwise is defined by systemd.mounts? To be honest, this will drive away lots of admins coming from a real UNIX background! I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
Thorsten
Cheers. l8er manfred
On Tue, Sep 29, 2020 at 11:04 AM Manfred Hollstein <mhollstein@t-online.de> wrote:
Moin,
On Tue, 29 Sep 2020, 16:25:13 +0200, Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
just to be sure I get this right... /etc/fstab is for the local admin to add stuff which otherwise is defined by systemd.mounts? To be honest, this will drive away lots of admins coming from a real UNIX background! I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
Upstream systemd does not recommend getting rid of /etc/fstab. Mount units were designed to express dependencies on mounts and to support *transient* mounts via a reasonable API. -- 真実はいつも一つ！/ 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, 2020-09-29 at 11:07 -0400, Neal Gompa wrote:
Upstream systemd does not recommend getting rid of /etc/fstab. Mount units were designed to express dependencies on mounts and to support *transient* mounts via a reasonable API.
Indeed, that was the intent, though if we only used things how they were originally intended, life would be an aweful lot more boring than it is today ;) On Tue, Sep 29, 2020 at 11:04 AM Manfred Hollstein
<mhollstein@t-online.de> wrote:
just to be sure I get this right... /etc/fstab is for the local admin to add stuff which otherwise is defined by systemd.mounts? To be honest, this will drive away lots of admins coming from a real UNIX background! I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
While I can sympathise with your sentiment, I'd like to point out that 'real UNIX' hasn't been a major player in the OS market for decades, and even if you look at its final bastion of Supercomputers, UNIX has been a minority player for at least the last 15 years. Children who were born in the waning days of UNIX are now adults and working in this industry. Kids who learned Linux in highschool are now in their 20's, working in this industry, and have only ever known Linux with systemd. As we all get older in the inescapable forward motion of time, it's an exhausting responsibility of us aging wise ones to accept that, while we do have lessons to teach the young, we should not misuse our knowledge to hinder the progress of the potentially smarter youth seeking to stand on our shoulders. "Come, come, Mr. Scott. Young minds, fresh ideas. Be tolerant." - James T Kirk -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.20 um 17:37 schrieb Richard Brown:
Kids who learned Linux in highschool are now in their 20's, working in this industry, and have only ever known Linux with systemd.
... using /etc/fstab you forgot to append here. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 Sep 2020, 17:37:31 +0200, Richard Brown wrote:
On Tue, Sep 29, 2020 at 11:04 AM Manfred Hollstein
<mhollstein@t-online.de> wrote:
just to be sure I get this right... /etc/fstab is for the local admin to add stuff which otherwise is defined by systemd.mounts? To be honest, this will drive away lots of admins coming from a real UNIX background! I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
While I can sympathise with your sentiment, I'd like to point out that 'real UNIX' hasn't been a major player in the OS market for decades, and even if you look at its final bastion of Supercomputers, UNIX has been a minority player for at least the last 15 years.
UNIX was just a placeholder for a lot of admins who went through a broad variety of UNIX'es, with Linux being one of them - and yes, it has been a long time, but should they all be scared away?
Children who were born in the waning days of UNIX are now adults and working in this industry.
Kids who learned Linux in highschool are now in their 20's, working in this industry, and have only ever known Linux with systemd.
As we all get older in the inescapable forward motion of time, it's an exhausting responsibility of us aging wise ones to accept that, while we do have lessons to teach the young, we should not misuse our knowledge to hinder the progress of the potentially smarter youth seeking to stand on our shoulders.
"Come, come, Mr. Scott. Young minds, fresh ideas. Be tolerant." - James T Kirk
... while Mr Spock would immediately jump in with "this is interesting, but wrong in this case" ;) Cheers. l8er manfred
On Tue, Sep 29, Manfred Hollstein wrote:
On Tue, 29 Sep 2020, 17:37:31 +0200, Richard Brown wrote:
While I can sympathise with your sentiment, I'd like to point out that 'real UNIX' hasn't been a major player in the OS market for decades, and even if you look at its final bastion of Supercomputers, UNIX has been a minority player for at least the last 15 years.
UNIX was just a placeholder for a lot of admins who went through a broad variety of UNIX'es, with Linux being one of them - and yes, it has been a long time, but should they all be scared away?
If you don't go forward, you go backwards. Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. If this means that old UNIX admins go earlier: that's clearly not nice, but Ok as long as more new people are coming. And quite some stuff we did 20-25 years ago are no longer explainable to the "young" people or are out of time, because there are better solutions without the problems. And even worse, some of this things are blocking new stuff. The world moves on. And in 10 years there are again other ideas which people are crying that the now new stuff will change. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 29 Sep 2020, 19:38:22 +0200, Thorsten Kukuk wrote:
On Tue, Sep 29, Manfred Hollstein wrote:
On Tue, 29 Sep 2020, 17:37:31 +0200, Richard Brown wrote:
While I can sympathise with your sentiment, I'd like to point out that 'real UNIX' hasn't been a major player in the OS market for decades, and even if you look at its final bastion of Supercomputers, UNIX has been a minority player for at least the last 15 years.
UNIX was just a placeholder for a lot of admins who went through a broad variety of UNIX'es, with Linux being one of them - and yes, it has been a long time, but should they all be scared away?
If you don't go forward, you go backwards.
Oh, wow!
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. If this means that old UNIX admins go earlier: that's clearly not nice, but Ok as long as more new people are coming.
And quite some stuff we did 20-25 years ago are no longer explainable to the "young" people or are out of time, because there are better solutions without the problems. And even worse, some of this things are blocking new stuff. The world moves on.
And in 10 years there are again other ideas which people are crying that the now new stuff will change.
To cut a long story short, your proposal was not to make /etc/fstab go away and not be used by systemd anymore, correct? If so, I don't have a problem with it at all! I just find it easier to put 20 lines into one file than to create 20 files with more than 1 line each. If you think this is innovation, then I'm afraid you're on your own: $ man systemd.mount Mount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details). Mounts listed in /etc/fstab will be converted into native units dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring mount points through /etc/fstab is the preferred approach. See systemd-fstab-generator(8) for details about the conversion. I read this as /etc/fstab being the _preferred approach_.
Thorsten
Cheers. l8er manfred
On 9/29/20 7:38 PM, Thorsten Kukuk wrote:
On Tue, Sep 29, Manfred Hollstein wrote:
On Tue, 29 Sep 2020, 17:37:31 +0200, Richard Brown wrote:
While I can sympathise with your sentiment, I'd like to point out that 'real UNIX' hasn't been a major player in the OS market for decades, and even if you look at its final bastion of Supercomputers, UNIX has been a minority player for at least the last 15 years.
UNIX was just a placeholder for a lot of admins who went through a broad variety of UNIX'es, with Linux being one of them - and yes, it has been a long time, but should they all be scared away?
If you don't go forward, you go backwards.
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. [...] Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab? Young people doesn't like explicit
I could agree here but... plain lists in text files anymore? ;-) Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.2020 um 22:06 schrieb Ancor Gonzalez Sosa:
Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab? Young people doesn't like explicit plain lists in text files anymore? ;-)
They want an app to control their mount points through the cloud I hear ;) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-09-29 22:06, Ancor Gonzalez Sosa wrote:
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. [...]
Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab?
Why would newcomers even care about such intricate system details? For them, the default install should reasonably work. And if and when they do want to explore the system guts, one simply has to learn the mechanism(s) of the particular system, whatever the system may be. Especially those people that lament all the time about how the Unix ways are seemingly getting lost in contemporary Linux should know better that there were—and are—Unixes that have no /etc/fstab file either. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 30.09.20 um 00:13 schrieb Jan Engelhardt:
On Tuesday 2020-09-29 22:06, Ancor Gonzalez Sosa wrote:
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. [...]
Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab?
Why would newcomers even care about such intricate system details? For them, the default install should reasonably work.
And if and when they do want to explore the system guts, one simply has to learn the mechanism(s) of the particular system, whatever the system may be. Especially those people that lament all the time about how the Unix ways are seemingly getting lost in contemporary Linux should know better that there were—and are—Unixes that have no /etc/fstab file either.
That's not an answer to Ancor's question though. That systems change and people that want to administrate need to be willing to learn is not the point here. The question is: what's so bad about having a simple format to configure and learn about? I.e. what are the actual benefits of going away? Because it's old? That's not an argument you can convince people with in my opinion. If the new ways are better, or more logical or easier to learn - be it. But I haven't seen any such arguments being brought forward. And I can't see them with systemd mount units - they are IMO *clearly* meant to be generated. Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-09-30 08:19, Stephan Kulow wrote:
Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab?
Why would newcomers even care about such intricate system details?
The question is: what's so bad about having a simple format to configure and learn about? I.e. what are the actual benefits of going away?
Looking at, for example dev-hugepages.mount, there is one big [Unit] section whose fields have no equivalent in fstab. [Unit] Description=Huge Pages File System Documentation=https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems DefaultDependencies=no Before=sysinit.target ConditionPathExists=/sys/kernel/mm/hugepages ConditionCapability=CAP_SYS_ADMIN ConditionVirtualization=!private-users In the old fstab-sysvinit world, all these would have been bolt-on solutions elsewhere for which you had to individually go somewhere. Conditions would probably be evaluated somewhere in /etc/init.d/boot.localfs. As for manpages, the user has to look for himself. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 30, Stephan Kulow wrote:
That's not an answer to Ancor's question though. That systems change and people that want to administrate need to be willing to learn is not the point here. The question is: what's so bad about having a simple format to configure and learn about?
Nothing, as long as it fullfills your needs.
I.e. what are the actual benefits of going away? Because it's old? That's not an argument you can convince people with in my opinion.
With "it's old" only you are right. But "simple format" could be one ;) E.g. Product Management is requesting since years the feature, that you can take a snapshot across partition and filesystem boundaries and that you can do a rollback to it. Seems like ZFS is able to do so. Several people looked at this. In the end, for the rollback support, everybody stumbled about /etc/fstab not able to provide what's needed. I think with systemd mount units, this would be possible. This would be for me a very good argument for systemd mount units against /etc/fstab. But no, I'm not working on that and I don't request to replace /etc/fstab because of this. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 30, 2020 at 6:05 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Sep 30, Stephan Kulow wrote:
That's not an answer to Ancor's question though. That systems change and people that want to administrate need to be willing to learn is not the point here. The question is: what's so bad about having a simple format to configure and learn about?
Nothing, as long as it fullfills your needs.
I.e. what are the actual benefits of going away? Because it's old? That's not an argument you can convince people with in my opinion.
With "it's old" only you are right. But "simple format" could be one ;) E.g. Product Management is requesting since years the feature, that you can take a snapshot across partition and filesystem boundaries and that you can do a rollback to it. Seems like ZFS is able to do so. Several people looked at this. In the end, for the rollback support, everybody stumbled about /etc/fstab not able to provide what's needed. I think with systemd mount units, this would be possible. This would be for me a very good argument for systemd mount units against /etc/fstab.
But no, I'm not working on that and I don't request to replace /etc/fstab because of this.
This problem is actually one of the reasons why I haven't yet implemented an automatic snapshot and restore scheme in Fedora. It's very messy to handle that right now. Combined with the fact that we're trying to use the bootloader spec as a bootloader-independent way to generate boot manager entries, all existing solutions for this stuff don't work. It's unfortunate, but fstab(5) is not expressive enough to handle all the problems we need to solve. But for now, I just haven't bothered to deal with it because we don't need it yet. -- 真実はいつも一つ！/ 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, Sep 29, Ancor Gonzalez Sosa wrote:
Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab? Young people doesn't like explicit plain lists in text files anymore? ;-)
That was never requested. Manfred did overreact. I only answered to a proposal to make fstab really complicated with files in different locations, to better use systemd.mount units instead. No need to invent something new which does not solve all problems if there is already something which does solve more problems. But fact is, that /etc/fstab has many problems, which are solved by systemd.mounts, and that systemd.mounts are already used in many places on your system, even if noboy seems to notice that. And I don't mean the by systemd dynamically created ones from /etc/fstab. And I expect that the number of systemd.mount units will increase and the number of entries in /etc/fstab will decrease. But I also see no advantage that the YaST installer writes entries for "/" and other system directories to /etc/fstab, and then a tool tries to generate systemd mount units out of it and tries to guess the correct order. It would be much simpler and more robust if YaST would create the systemd mount units with correct dependencies from the beginning and /etc/fstab only contains the entries the user adds. Which is still sometimes difficult to get correct in regard of dependencies. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Di, 29. Sep, 2020 um 10:06 P. M. schrieb Ancor Gonzalez Sosa <ancor@suse.de>:
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. [...] Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab? Young people doesn't like explicit
On 9/29/20 7:38 PM, Thorsten Kukuk wrote: plain lists in text files anymore? ;-)
Young people don't like waiting 90s for the start job service for fstab to finish, because YaST added an entry to fstab for the installation medium ;) 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 9/30/20 9:11 AM, Stasiek Michalski wrote:
Am Di, 29. Sep, 2020 um 10:06 P. M. schrieb Ancor Gonzalez Sosa <ancor@suse.de>:
Or in other words: the old UNIX admins will go away, that's unavoidable, and cannot be stopped, independent of what we are doing. We need to make sure that enough new people are coming. And we need changes which attract them. [...] Are we still talking about completely removing /etc/fstab in favor of dynamically generated systemd mount points? How is that more attractive to newcomers than the old /etc/fstab? Young people doesn't like explicit
On 9/29/20 7:38 PM, Thorsten Kukuk wrote: plain lists in text files anymore? ;-)
Young people don't like waiting 90s for the start job service for fstab to finish, because YaST added an entry to fstab for the installation medium ;)
So there was a bug at some point with YaST adding to the system a mount point that should not be there? I don't see how that relates to the topic. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-09-30 09:11, Stasiek Michalski wrote:
Young people don't like waiting 90s for the start job service for fstab to finish, because YaST added an entry to fstab for the installation medium ;)
If processing /etc/fstab takes 90s, then there's simply a bug somewhere. I don't see a relation to young people. 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
Am 30.09.20 um 09:11 schrieb Stasiek Michalski:
Young people don't like waiting 90s for the start job service for fstab to finish, because YaST added an entry to fstab for the installation medium ;)
That's not the "fstab start job service" but that's the start of the generated mount unit. systemd-fstab-generator runs so early and does not produce any output that young people will be able to notice. How would that be different if yast added a mount unit for the installation medium instead? And AFAIK that yast bug is fixed for quite some time. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.20 um 17:04 schrieb Manfred Hollstein:
Moin,
On Tue, 29 Sep 2020, 16:25:13 +0200, Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
just to be sure I get this right... /etc/fstab is for the local admin to add stuff which otherwise is defined by systemd.mounts? To be honest, this will drive away lots of admins coming from a real UNIX background! I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
I think he's only talking about what yast does. If you're bound to yast as admin, you don't care so much about /etc/fstab Greetings, Stephan -- Lighten up, just enjoy life, smile more, laugh more, and don't get so worked up about things. Kenneth Branagh -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Manfred Am 29.09.20 um 17:04 schrieb Manfred Hollstein:
I always thought of systemd was a bad thing, but some/a lot of parts really work OK in the meantime, and most admins got used to it. But removing /etc/fstab? No way!
I certainly agree with you about dropping of fstab being a bad idea. However, it would certainly be nice if the system would still boot with emtpy fstab. And I guess it already does. rootfs is available from proc/cmdline, and everything else in my fstab is non-essential: /dev/system/root / ext4 acl,user_xattr 1 1 /dev/mapper/cr_home /home xfs nofail 0 2 /dev/system/swap swap swap discard=once 0 0 LABEL=local /local xfs noatime,logbufs=8,logbsize=262144 1 2 LABEL=space /space xfs noatime,logbufs=8,logbsize=262144 1 2 /local/.debug /usr/lib/debug none bind 0 0 All the old /dev/pts, /dev/shm, ... mountpoints are already autogenerated, or so it seems. Now a standard setup without additional mountpoints might just work, because everything but / is not strictly necessary for booting. And if I look into the "new normal" btrfs fstab, it's only gibberish to me anyway ;-) And having additional mounts in an /etc/fstab.d/ dropin-style directory might actually be sexy wrt automatic configuration management and still be easy enough to understand for us old farts :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
On a _default_ installation neither should be needed for operating system components. The system can discover what goes where if we follow some common pattern. For partitions there's the discoverable partitions spec¹ from systemd for example. Our btrfs subvolume layout also follows some pretty predictable scheme so it's actually redundant to explicitly spell out what goes where. A generator could be used instead. Admin overrides could of course still go into fstab but we wouldn't clutter it by default anymore. cu Ludwig [1] https://systemd.io/DISCOVERABLE_PARTITIONS/ -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-09-29 at 16:25 +0200, Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
and On Wed, 2020-09-30 at 08:52 +0200, Ludwig Nussel wrote:
Admin overrides could of course still go into fstab but we wouldn't clutter it by default anymore.
I like this proposal. Regards, Olav -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 29/09/2020 16.25, Thorsten Kukuk wrote:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts.
Please don't. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Am Dienstag, 29. September 2020, 16:25:13 CEST schrieb Thorsten Kukuk:
On Tue, Sep 29, Richard Brown wrote:
There are some configuration files not owned by any package, such as /etc/fstab
In such an example, it might be advantageous to have YaST produce an /usr/etc/fstab at installation time, to provide the 'default filesystem layout', but then have modifications present in /etc.
I would propose to drop /etc/fstab and only use systemd.mounts. Don't know why upstream systemd thinks mount units should not be used instead of /etc/fstab.
My humble guess: /etc/fstab is a simple file, that could be edited from outside, while systemctl mount units are created/modified/whatever in a running system, requiring the mount -bind and chroot dance with a proper installation. Correct me, if I'm wrong. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 30, Hans-Peter Jansen wrote:
My humble guess: /etc/fstab is a simple file, that could be edited from outside, while systemctl mount units are created/modified/whatever in a running system, requiring the mount -bind and chroot dance with a proper installation.
Correct me, if I'm wrong.
You are wrong. systemd mount units can be modified in the same way as any other systemd unit. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.09.20 um 15:56 schrieb Frederic Crozat:
To /usr/etc/default/grub? No, that's package's domain to /etc/default/grub? No, that's my (user's) domain to /var/adm/default/grub?
I'd say /etc/default/grub : YaST is working on behalf on the user. Well, then this is the same as we have now with all the stuff in /etc.
Many of them are changed without me ever touching them manually, e.g. by yast2 installation module. So there certainly should be a further distinguishing between "user edited" and "system tools edited" ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Tue, 29 Sep 2020 17:34:23 +0200 schrieb Stefan Seyfried <stefan.seyfried@googlemail.com>:
So there certainly should be a further distinguishing between "user edited" and "system tools edited"
What would be the point of such split? The OS provides some built-in defaults in whatever form, the admin tunes it further via /etc/ and potentially ~/.config/. The true benefit of /etc not being owned by rpm anymore is: only what exists will be used, which makes backup/restore of relevant settings easy and obvious. With the current junk in /etc it is cumbersome to extract the relevant configuration snippets. Olaf
Hello, Am Dienstag, 29. September 2020, 12:04:45 CEST schrieb Richard Brown:
On Mon, 2020-09-28 at 17:35 +0200, Olaf Hering wrote:
Am Mon, 28 Sep 2020 15:33:36 +0200 schrieb Thorsten Kukuk: [...]
Doing something in an imperfect way for 20 years isn't really good grounds for not seeking to improve the situation now.
;-)
The potential trouble with fillup will also happen with every other location: stale admin controlled key=value entries will remain unless the pkg provides an upgrade path. Some pkgs have one, most pkgs do not. It is up to each pkg to decide how to move forward with existing files.
Indeed. I support Thorsten's suggestion of retiring /etc/sysconfig and instead using /etc/default and /usr/etc/default but that agreement comes with the assumption that we throw the mess that is fillup out of the window at the same time.
No objections against getting rid of fillup, but wouldn't it be better to fix this in a backwards-compatible way, without changing paths (at least in the first step), without leaving unused files behind, and therefore without leaving users confused? I played around a bit, and it looks like rpm creates *.rpmnew files if you have a file with differing content that isn't owned by any package. Therefore I propose the following backwards-compatible solution: - change rpmlint to no longer block files in /etc/sysconfig/ - package the sysconfig files as %config(noreplace) /etc/sysconfig/$whatever (note: it seems fillup adds an empty line at the end, so we should add that empty line to the packaged files to avoid superfluous *.rpmnew files) I already hear you asking "but what about moving to /usr/etc/?" IMHO that should be a second step (maybe in some months) so that most Tumbleweed (or even Leap, if we wait long enough) users get a smooth upgrade path that avoids manual work. This delay for the second step even comes with an advantage - rpm will delete unmodified (but now owned) files from /etc/sysconfig/ without leaving garbage behind, and will leave modified files as *.rpmsave so that users (and rpmconfigcheck) can easily find them, and know that they are now unused. In theory we could also handle both steps in one by checking the checksum of /etc/sysconfig/$whatever, and then a) delete matching files and b) rename non-matching files to *.rpmsave. However, this comes with more additional work because packagers would have to add the checksum of each (default) sysconfig file to support this. This could be done by a (not yet existing) macro like %delete_unowned_file /etc/sysconfig/foo \ 749b1bcb73cc025e68d45e4b93c9b1294ee9e63bfba85ec0b410946371b237df (As some people already mentioned in this discussion, the final location doesn't need to be /usr/etc/default/$name - something like /usr/etc/$name is probably better.)
Yes, /etc/* might contain user-supplied stale values after an upgrade. But that's fine. /etc/* should be considered _user data_.
That's your long-term goal, but looking at the amount of files in /etc/ vs. /usr/etc/, we still have a long way to go. And that also means that currently /etc/ is mostly system/packaged data, with a few modified files in between ;-)
It's the user's domain, let them put old nonsense in there, or broken nonsense. In the same way we shouldn't be tinkering with what users put in their /home, we should leave /etc well alone and trust in the user to be able to manage that themselves properly.
I know that you like breaking things ;-) but if we can help users to make /etc/sysconfig/ clean(er) without breaking things, we should do that. Regards, Christian Boltz -- Reason why a bot: the bot is just less 'stressed' any makes less mistakes for such obvious things. And people can discuss with the bot as much as they want. [Dominique Leuenberger in opensuse-packaging] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2020-10-04 17:58, Christian Boltz wrote:
I played around a bit, and it looks like rpm creates *.rpmnew files if you have a file with differing content that isn't owned by any package. Therefore I propose the following backwards-compatible solution:
- change rpmlint to no longer block files in /etc/sysconfig/ - package the sysconfig files as %config(noreplace) /etc/sysconfig/$whatever [...] This delay for the second step even comes with an advantage - rpm will delete unmodified (but now owned) files from /etc/sysconfig/ without leaving garbage behind, and will leave modified files as *.rpmsave so that users (and rpmconfigcheck) can easily find them, and know that they are now unused.
No matter how you choose that delay, there will always be someone who upgrades later... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Oct 04, Christian Boltz wrote:
No objections against getting rid of fillup, but wouldn't it be better to fix this in a backwards-compatible way, without changing paths (at least in the first step), without leaving unused files behind, and therefore without leaving users confused?
I played around a bit, and it looks like rpm creates *.rpmnew files if you have a file with differing content that isn't owned by any package. Therefore I propose the following backwards-compatible solution:
- change rpmlint to no longer block files in /etc/sysconfig/ - package the sysconfig files as %config(noreplace) /etc/sysconfig/$whatever (note: it seems fillup adds an empty line at the end, so we should add that empty line to the packaged files to avoid superfluous *.rpmnew files)
I already hear you asking "but what about moving to /usr/etc/?" IMHO that should be a second step (maybe in some months) so that most Tumbleweed (or even Leap, if we wait long enough) users get a smooth upgrade path that avoids manual work.
This would require two times a change to a package: 1. replace fillup with a real %config file 2. move the config file and adjust all code. And this would require two times an action from the user, and two times something new to learn: 1. Check for /etc/sysconfig/*.rpmnew and merge your changes, learn you need to check that after every package update 2. Check for /etc/sysconfig/*.rpmsave and merge that, learn that the default is below /usr/etc and the changes should be below /etc.
This delay for the second step even comes with an advantage - rpm will delete unmodified (but now owned) files from /etc/sysconfig/ without leaving garbage behind, and will leave modified files as *.rpmsave so that users (and rpmconfigcheck) can easily find them, and know that they are now unused.
To a high cost for packagers and users. And: what happens with the migratation of Leap 15.x to Leap 16.x, or however the next major Leap version will be called?
In theory we could also handle both steps in one by checking the checksum of /etc/sysconfig/$whatever, and then a) delete matching files and b) rename non-matching files to *.rpmsave. However, this comes with more additional work because packagers would have to add the checksum of each (default) sysconfig file to support this. This could be done by a (not yet existing) macro like %delete_unowned_file /etc/sysconfig/foo \ 749b1bcb73cc025e68d45e4b93c9b1294ee9e63bfba85ec0b410946371b237df
I would do it really trivial: 1. don't package the fillup-template anymore 2. Install the adjusted config below /usr/etc 3. Move the old /etc/sysconfig/<file> to the new location, where the application now expects the user made changes. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sun, 04 Oct 2020 17:58:52 +0200 schrieb Christian Boltz <opensuse@cboltz.de>:
- change rpmlint to no longer block files in /etc/sysconfig/
This will go into the wrong direction: - /etc must not be polluted by rpm anymore - defaults for each pkg must go into a to-be-defined location below /usr - an admin can still tweak certain settings in the well-known and documented locations below /etc/sysconfig Olaf
Hello, Am Montag, 5. Oktober 2020, 08:18:02 CEST schrieb Olaf Hering:
Am Sun, 04 Oct 2020 17:58:52 +0200 schrieb Christian Boltz:
- change rpmlint to no longer block files in /etc/sysconfig/
This will go into the wrong direction:
Hehe, not really ;-) It won't go into the wrong direction - the main change would be that /etc/sysconfig/$whatever would be rpm-owned instead of being "just there". And that would bring the usual advantages of rpm-handled files, for example *.rpmnew and *.rpmsave and deleting unmodified files when they get dropped from the package. And while it doesn't go into the wrong direction, I admit that it also wouldn't move much towards the final direction of /usr/etc/.
- /etc must not be polluted by rpm anymore - defaults for each pkg must go into a to-be-defined location below /usr - an admin can still tweak certain settings in the well-known and documented locations below /etc/sysconfig
As long as existing /etc/sysconfig/$whatever will still be honored (or there will be migration scripts, and ideally also cleanup scripts for unchanged sysconfig files) - fine. The thing I don't like are breaking changes (unless there is a _very_ good reason for causing the breakage). If you avoid such breaking changes (in whatever way), people will be happy ;-) Regards, Christian Boltz -- a computer without an Internet connection is essentially a very expensive DVD player [http://www.randsinrepose.com/archives/2006/07/10/a_nerd_in_a_cave.html] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/09/2020 15.33, Thorsten Kukuk wrote:
On Mon, Sep 28, Neal Gompa wrote:
When fillup got introduced over 20 years ago, it was a good thing at that time. When I wrote the first mail I also thought about a valid usecase for keeping /etc/sysconfig today. I haven't found one.
It is easy for admin to edit things at a single directory with a common syntax on all files. Comments say what each config is for. It is easy to use. YaST edits them, too. Perhaps obsolete entries can just be commented out with something like: #obsolete VAR=... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hi Thorsten, Thorsten Kukuk <kukuk@suse.de> writes:
My question would be: for what is /etc/sysconfig needed at all? In the end, we have {/usr},/etc/default, which solves all the problems very nicely. All my new projects will only use /etc/default, I don't see any sense in /etc/sysconfig anymore, which makes provides a real advantage or benefit.
Agreed, I think there should be only one of both and preferably it should be controlled by rpm as well (so that we get rpmnew and rpmsave files). So +1 on deprecating and eventually getting rid of /etc/sysconfig. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Thorsten Kukuk wrote:
Currently we have two directories with similar usage:
- /etc/default, seems to come from Debian, mainly used by upstream projects on openSUSE - /etc/sysconfig, mainly based on Red Hat, mainly used for start scripts written by us. I will ignore the subdirectories here.
Both have files with in a KEY=VALUE format which can be sources by a shell.
Only the format of /etc/sysconfig on SUSE is strictly like that. /etc/default could be anything.
[...] This is not a proposal to change now all sysconfig files, but I think many packages could benefit from such a change, especially if they are really old and the sysconfig template gets often changed. The packaging change is trivial: install the sysconfig template in /usr/etc/default/, adjust your docu and remove the fillup call.
Fillup is broken by design and should be killed for good. Not sure /usr/etc/default with an override in /etc/default makes too much sense though. /usr/etc already contains the distro default. And something you modified in /etc/default is no longer the default. So the 'default' in the path seems redundant to misleading :-) Sysconfig usually is some distro specific hack around something that does not have proper config files. So kind of makes sense to keep /etc/sysconfig for that, with ro defaults in /usr/etc/sysconfig and no fillup.
Is this something we should propose as "best practise", or are there reasons not to do so we haven't found yet?
The sysconfig schema allows the yast sysconfig editor to be used as generic tool to configure the settings. It needs to be adjusted if defaults are moved to /usr/etc/sysconfig or dropped if that concept is dropped. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 28 September 2020 10:30:51 IST Thorsten Kukuk wrote:
Hi,
Currently we have two directories with similar usage:
- /etc/default, seems to come from Debian, mainly used by upstream projects on openSUSE - /etc/sysconfig, mainly based on Red Hat, mainly used for start scripts written by us. I will ignore the subdirectories here.
Both have files with in a KEY=VALUE format which can be sources by a shell.
/etc/default is controlled by RPM, so changes in the config files lead to *.rpmsave or *.rpmnew files.
/etc/sysconfig is controlled by fillup. Adding new variables is easy, changing defaults or removing variables is next to impossible in most cases.
Why do I write this? No, I don't want to get rid of /etc/sysconfig, but bring up an idea how to solve quite some of the problems with updating sysconfig files. Many bug reports about sysconfig files get closed as "Wontfix", since changing defaults is really difficult, as we don't want to overwrite user made changes, and adjusting comments is next to impossible. As result, an user may have many sysconfig files with outdated comments and content after a longer time after installation. This can be very irritating or lead to not working configurations and frustrations as following this steps does not lead to success. Hey, we still have comments which tells the user that he has now to run SuSEconfig because of this!
To run and manage our openSUSE containers via podman and systemd, we started with as example for the bind container:
/etc/sysconfig/container-bind
container-bind.service, which did contain: EnvironmentFile=/etc/sysconfig/container-bind
and we run immeaditly into problems as there were typos in it which we couldn't fix in an easy way on already installed systems.
But we have now /usr/etc and /usr/etc/default :)
So /usr/etc/default/container-bind contains now the system default (fillup doesn't make sense here, as this file is RPM controlled and should not be changed by an user), and the user can override single variables by creating a file /etc/default/container-bind with just this modified variables.
The container-bind.service looks now like: EnvironmentFile=/usr/etc/default/container-bind EnvironmentFile=-/etc/default/container-bind
All update problems solved without the need to find out, if a variable is modified by an user or not.
This is not a proposal to change now all sysconfig files, but I think many packages could benefit from such a change, especially if they are really old and the sysconfig template gets often changed. The packaging change is trivial: install the sysconfig template in /usr/etc/default/, adjust your docu and remove the fillup call. And you need to think about, if you want to rename the old sysconfig file to *.rpmsave or move it to /etc/default.
Is this something we should propose as "best practise", or are there reasons not to do so we haven't found yet?
Thorsten Hello all,
Just to add some more context to the discussion http://0pointer.de/blog/projects/on-etc-sysinit.html[1] TL;DR "Of course, there's one very good reason for supporting these files for a bit longer: compatibility for upgrades. But that's is really the only one I could come up with. It's reason enough to keep compatibility for a while, but I think it is a good idea to phase out usage of these files at least in new packages." Anyway, this text is old and is mostly the aspirations for systemd, but I guess is good reading for understanding what systemd wanted to do about that. Guilherme -------- [1] http://0pointer.de/blog/projects/on-etc-sysinit.html
participants (19)
-
Ancor Gonzalez Sosa -
Bernhard Voelker -
Carlos E. R. -
Christian Boltz -
Dan Čermák -
Frederic Crozat -
Guilherme Moro -
Hans-Peter Jansen -
Jan Engelhardt -
Ludwig Nussel -
Manfred Hollstein -
Neal Gompa -
Olaf Hering -
Richard Brown -
seroton10＠gmail.com -
Stasiek Michalski -
Stefan Seyfried -
Stephan Kulow -
Thorsten Kukuk