[opensuse-factory] Decission: configuration files in /etc and /usr/etc
Hi, after many months and many discussions, we decided to go with my Proposal for a better configuration file management on openSUSE (https://github.com/thkukuk/atomic-updates_and_etc/) and use /usr/etc as the directory below /usr for distribution provided configuration files. While there is a small risk in using this directory, the feedback was nearly unanimously to go with this directory, as this is well known to people. Having the by-in from so many people is in our opinion really important. If we choose a name nobody likes, we can declare it already as failed. So, what do we plan? -------------------- The plan is, to make updating of configuration files a lot of easier and solve the problems of configuration file updates with atomic updates (transactional-update on openSUSE). Longterm, /etc should only contain the host specific and by the admin modified configuration, all distribution provided configuration files should be in /usr/etc. Additional, the distribution provided configuration files should be moved from /usr/lib and consolidated in /usr/etc. Configuration files in /usr/etc should not be modified by the admin, as /usr/etc can be read-only. Instead, the applications needs to be enhanced, as far as possible and necessary, to read the configuration files from several locations. Take the systemd configuration as example: https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples What needs to be done? ---------------------- In the first place, you need to adopt your packages. What you need to do and what you can do depends on your package. It's not possible to implement this with every kind of configuration file, but on the other side, there are many applications which supports this already, and it is only a question of the right configuration and maybe a little bit of tweaking it. We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf This should make it much easier to port some applications to the new schema. Roadmap: -------- We will start with adding the directory to the filesystem RPM and adjust the scripts to not throw an error if you use this directory. Afterwards we will go through the files in /etc and move the easy ones and continue until we are done. At some point in time we will create new tests which forbids to deliver files in /etc, so that this will really finish at some point in time and we don't add more files to /etc then others remove. Open Questions: --------------- If you read the github document, you will see, that we don't have a solution for everything yet. I hope we can improve here over the time. Second, the big question for packagers: configuration files in /usr/etc, should we mark them as %config or not? As no customer should touch them, %config is not really necessary. On the other side, if we mark them as %config and the user modifies them by accident, the next update would not overwrite the changes, but save them as *.rpmsave file. %config(noreplace) is no option, this would lead again to big problems with not updated configuration files and thus not working services. 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
This is pretty confusing... does this apply to all of openSUSE or? I really hope it doesn't. I for one do not support dropping /etc entirely and forcing people not using atomic updates to use /usr/etc which you have said should not be modified. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 16, simonizor wrote:
This is pretty confusing... does this apply to all of openSUSE or? I really hope it doesn't. I for one do not support dropping /etc entirely and forcing people not using atomic updates to use /usr/etc which you have said should not be modified.
If you read the rationale: this helps us on all kind of updates, even plain ones with RPM. We had in the last months again enough problems/bug reports of not working/insecure systems, since users/admins ignored *.rpmsave and *.rpmnew files and did not merge the configuration files after an update. This proposal should help with this and make the user experience on updates much better. And this change will come, if we do something or not. The systemd people are working on the same and are in contact with several upstream projects already to change their code. The only difference is, they perfer to clobber /usr/lib even more, why we try to cleanup the filesystem (especially /usr/lib) at the same time. If you want to make changes, you still have to do them in /etc. 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
If you read the rationale: this helps us on all kind of updates, even plain ones with RPM. We had in the last months again enough problems/bug reports of not working/insecure systems, since users/admins ignored *.rpmsave and *.rpmnew files and did not merge the configuration files after an update. This proposal should help with this and make the user experience on updates much better.
How does this solve that? I can still place a configuration file in /etc with this proposal and ignore *.rpmsave and *.rpmnew. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, August 16, 2019 8:45:31 AM CDT, simonizor wrote:
If you read the rationale: this helps us on all kind of updates, even plain ones with RPM. We had in the last months again enough problems/bug reports of not working/insecure systems, since users/admins ignored *.rpmsave and *.rpmnew files and did not merge the configuration files after an update. This proposal should help with this and make the user experience on updates much better.
How does this solve that? I can still place a configuration file in /etc with this proposal and ignore *.rpmsave and *.rpmnew.
Also, I am totally one of the people that ignores these files. Why? There's little to no notification that they have been created, nothing telling me what changes have been made, etc. By the time I realize they're even there, months could have passed since they were created. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 16, simonizor wrote:
Also, I am totally one of the people that ignores these files.
So you are one of the people who could have a seucrity problem in the future because of other changes currently done.
Why? There's little to no notification that they have been created,
You can enable that if you want.
nothing telling me what changes have been made, etc.
There is a nice unix command called diff ... 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 16/08/2019 15.53, simonizor wrote:
On Friday, August 16, 2019 8:45:31 AM CDT, simonizor wrote:
If you read the rationale: this helps us on all kind of updates, even plain ones with RPM. We had in the last months again enough problems/bug reports of not working/insecure systems, since users/admins ignored *.rpmsave and *.rpmnew files and did not merge the configuration files after an update. This proposal should help with this and make the user experience on updates much better.
How does this solve that? I can still place a configuration file in /etc with this proposal and ignore *.rpmsave and *.rpmnew.
Also, I am totally one of the people that ignores these files. Why? There's little to no notification that they have been created, nothing telling me what changes have been made, etc. By the time I realize they're even there, months could have passed since they were created.
There was a service that run on boot that searched for those files and told the admin, but it has been removed. I think that going back more years, it emailed root as well. Now, you have to run "rpmconfigcheck" manually. I documented this on the wiki. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am Samstag, 17. August 2019, 10:55:44 schrieb Carlos E. R.: > There was a service that run on boot that searched for those files and > told the admin, but it has been removed. I think that going back more > years, it emailed root as well. > > Now, you have to run "rpmconfigcheck" manually. I documented this on the > wiki. Well, the service does still exist: $ systemctl status rpmconfigcheck * rpmconfigcheck.service - Scan for unresolved .rpmnew, .rpmorig, and .rpmsave files Loaded: loaded (/usr/lib/systemd/system/rpmconfigcheck.service; disabled; vendor preset: disabled) Active: inactive (dead) (it is disabled by default, but that's the case since years if not a decade, AFAIK) It doesn't notify anybody though AFAICS, the output should go to the journal/syslog and should also be visible if you run "systemctl status rpmconfigcheck" (might be necessary to do that as root though). I don't think it ever supported sending emails, though it might be possible to configure journald or the used syslog daemon to do that. I had a quick look at the current rpmconfigcheck script itself, it does add a message to /var/log/update-messages, which would be displayed by YaST/zypper if you do updates I think (it will not be run during updates though, no idea if that was different in the past). Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/08/2019 20.13, Wolfgang Bauer wrote: > Am Samstag, 17. August 2019, 10:55:44 schrieb Carlos E. R.: >> There was a service that run on boot that searched for those files and >> told the admin, but it has been removed. I think that going back more >> years, it emailed root as well. >> >> Now, you have to run "rpmconfigcheck" manually. I documented this on the >> wiki. > Well, the service does still exist: > $ systemctl status rpmconfigcheck > * rpmconfigcheck.service - Scan for unresolved .rpmnew, .rpmorig, and .rpmsave > files > Loaded: loaded (/usr/lib/systemd/system/rpmconfigcheck.service; disabled; > vendor preset: disabled) > Active: inactive (dead) > > (it is disabled by default, but that's the case since years if not a decade, > AFAIK) Only after systemd deployment. Previous to that the default was enabled. > > It doesn't notify anybody though AFAICS, the output should go to the > journal/syslog and should also be visible if you run "systemctl status > rpmconfigcheck" (might be necessary to do that as root though). It goes to a file. > I don't think it ever supported sending emails, though it might be possible to > configure journald or the used syslog daemon to do that. I remember that long ago root got emails about some configuration changes, but I do not remember if this was one of them. Searching on my root (mail) folder I see them: +++....................... Date: Tue, 24 Jun 2014 19:54:40 +0200 From: rootTo: root@telcontar.valinor Subject: rpm config chech run Please check the following files (see /var/adm/rpmconfigcheck): /etc/clamd.conf.rpmnew /etc/init.d/jexec.rpmsave /etc/init.d/jexec.rpmsave /etc/logrotate.d/apache2.rpmnew /etc/pam.d/common-password.rpmnew /etc/pam.d/common-session.rpmnew /etc/texmf/web2c/fmtutil.cnf.rpmnew /etc/texmf/web2c/updmap.cfg.rpmsave /etc/updatedb.conf.rpmnew /usr/share/kde4/config/kdm/kdmrc.rpmnew .......................++- Only that year. I can't say if it was my doing or it came from the distro. > > I had a quick look at the current rpmconfigcheck script itself, it does add a > message to /var/log/update-messages, which would be displayed by YaST/zypper > if you do updates I think (it will not be run during updates though, no idea > if that was different in the past). -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, Aug 22, Carlos E. R. wrote:
On 22/08/2019 20.13, Wolfgang Bauer wrote:
(it is disabled by default, but that's the case since years if not a decade, AFAIK)
Only after systemd deployment. Previous to that the default was enabled.
systemd was deployed 2003? 7 years before systemd development started? I want to have that time machine! rpmconfigcheck isn't enabled now for 16 years: ------------------------------------------------------------------- Tue Sep 23 16:28:12 CEST 2003 - mls@suse.de - really disable rpmconfigcheck Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 247165, AG München) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/08/2019 21.48, Thorsten Kukuk wrote:
On Thu, Aug 22, Carlos E. R. wrote:
On 22/08/2019 20.13, Wolfgang Bauer wrote:
(it is disabled by default, but that's the case since years if not a decade, AFAIK)
Only after systemd deployment. Previous to that the default was enabled.
systemd was deployed 2003? 7 years before systemd development started? I want to have that time machine!
rpmconfigcheck isn't enabled now for 16 years: ------------------------------------------------------------------- Tue Sep 23 16:28:12 CEST 2003 - mls@suse.de
- really disable rpmconfigcheck
Thorsten
Well, dunno, but my machines had it enabled and got it disabled when systemd came. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Fri, Aug 16, simonizor wrote:
If you read the rationale: this helps us on all kind of updates, even plain ones with RPM. We had in the last months again enough problems/bug reports of not working/insecure systems, since users/admins ignored *.rpmsave and *.rpmnew files and did not merge the configuration files after an update. This proposal should help with this and make the user experience on updates much better.
How does this solve that? I can still place a configuration file in /etc with this proposal and ignore *.rpmsave and *.rpmnew.
If you strictly follow systemd, /etc/ will only contain your changes to the original configuration files. And the application will try to merge them or report an error, so that you notice it immeaditly that something is broken. Of course, this is unforunatley not possible with all kind of configuration files, thus will not solve it for all applications. There will be no *.rpmsave nor *.rpmnew files, since longterm, no package should install anything in /etc. 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
Seems my previous reply got mangled up and ended up on the list as an empty mail - so here we go again On Fri, 2019-08-16 at 14:42 +0200, Thorsten Kukuk wrote:
Second, the big question for packagers: configuration files in /usr/etc, should we mark them as %config or not? As no customer should touch them, %config is not really necessary. On the other side, if we mark them as %config and the user modifies them by accident, the next update would not overwrite the changes, but save them as *.rpmsave file. %config(noreplace) is no option, this would lead again to big problems with not updated configuration files and thus not working services.
I'd clearly discourage the use of %config there. Using %config we only move the problem leadnig to bug reports from /etc to /usr/etc. Calling the files 'application default settings' rather than 'config files' might help to clearly distinguish between their usecases. If we clearly state it's not config files, any such bug report could be rejected with "invalid: you modified system files, no config files" Cheers, Dominique
Am 16.08.19 um 17:04 schrieb Dominique Leuenberger / DimStar:
I'd clearly discourage the use of %config there. Using %config we only move the problem leadnig to bug reports from /etc to /usr/etc.
Calling the files 'application default settings' rather than 'config files' might help to clearly distinguish between their usecases.
If we clearly state it's not config files, any such bug report could be rejected with "invalid: you modified system files, no config files"
And a comment in each of these "application default settings" files stating that it must not be modified, and where the modifications should be placed would certainly be helpful ;-) -- 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
On Friday 2019-08-16 14:42, Thorsten Kukuk wrote:
What needs to be done? ---------------------- In the first place, you need to adopt your packages. What you need to do and what you can do depends on your package. It's not possible to implement this with every kind of configuration file, but on the other side, there are many applications which supports this already, and it is only a question of the right configuration and maybe a little bit of tweaking it. We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf
Is there a shortage of ini parser libraries around, or did I miss something? (libini_config, libiniparser, the-unnamed?-parser-from-samba, the-other-thing-with-augeas-lenses) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Aug 17, Jan Engelhardt wrote:
We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf
Is there a shortage of ini parser libraries around, or did I miss something? (libini_config, libiniparser, the-unnamed?-parser-from-samba, the-other-thing-with-augeas-lenses)
And which of them offers any of the functionality we need for this proposal? 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 Saturday 2019-08-17 05:35, Thorsten Kukuk wrote:
On Sat, Aug 17, Jan Engelhardt wrote:
We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf
Is there a shortage of ini parser libraries around, or did I miss something? (libini_config, libiniparser, the-unnamed?-parser-from-samba, the-other-thing-with-augeas-lenses)
And which of them offers any of the functionality we need for this proposal?
What functionality do you mean? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Aug 17, Jan Engelhardt wrote:
On Saturday 2019-08-17 05:35, Thorsten Kukuk wrote:
On Sat, Aug 17, Jan Engelhardt wrote:
We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf
Is there a shortage of ini parser libraries around, or did I miss something? (libini_config, libiniparser, the-unnamed?-parser-from-samba, the-other-thing-with-augeas-lenses)
And which of them offers any of the functionality we need for this proposal?
What functionality do you mean?
To support the proposal and merge the files during reading like systemd is doing? For easier adjustment of applications? libeconf is clearly not to replace the used config file library with another one with the same functionality. 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 17/08/2019 09.20, Thorsten Kukuk wrote:
On Sat, Aug 17, Jan Engelhardt wrote:
On Saturday 2019-08-17 05:35, Thorsten Kukuk wrote:
On Sat, Aug 17, Jan Engelhardt wrote:
We develop currently an universal, really flexible config file parser for config files more or less compatible with the ini file format, it's libeconf: https://github.com/parlt91/libeconf
Is there a shortage of ini parser libraries around, or did I miss something? (libini_config, libiniparser, the-unnamed?-parser-from-samba, the-other-thing-with-augeas-lenses)
And which of them offers any of the functionality we need for this proposal?
What functionality do you mean?
To support the proposal and merge the files during reading like systemd is doing? For easier adjustment of applications? libeconf is clearly not to replace the used config file library with another one with the same functionality.
As admin, I see very problematic having defaults in one place and actual local configuration in another. It makes difficult for the admin to know the actual configuration. Do we have editors that would load both files and present the admin with the actual configuration? If we don't, I see the proposal as worse that the current status. For example, if I have to look at both /usr/etc/postfix/main.cf and /etc/postfix/main.cf, which is a big file, when the local modifications can be in different order than the defaults, it will be a nightmare to know the actual value of any random setting. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am 17.08.19 um 11:02 schrieb Carlos E. R.:
For example, if I have to look at both /usr/etc/postfix/main.cf and /etc/postfix/main.cf, which is a big file, when the local modifications can be in different order than the defaults, it will be a nightmare to know the actual value of any random setting.
view: postconf | less edit: postconf -e foo=bar There would be nothing different than now ;-) nobody should edit main.cf manually anyway. -- 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
On 17/08/2019 11.06, Stefan Seyfried wrote:
Am 17.08.19 um 11:02 schrieb Carlos E. R.:
For example, if I have to look at both /usr/etc/postfix/main.cf and /etc/postfix/main.cf, which is a big file, when the local modifications can be in different order than the defaults, it will be a nightmare to know the actual value of any random setting.
view: postconf | less edit: postconf -e foo=bar
which is very specific to postfix, and needs looking at a terminal for running the command and another for the editor.
There would be nothing different than now ;-)
nobody should edit main.cf manually anyway.
Many do. I do. Would you use YaST instead? I only use it once in the lifetime of the system. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am 17.08.19 um 11:39 schrieb Carlos E. R.:
On 17/08/2019 11.06, Stefan Seyfried wrote:>> nobody should edit main.cf manually anyway.
Many do. I do. Would you use YaST instead? I only use it once in the lifetime of the system.
Why not just use postconf instead of editing main.cf? I do not even have yast installed on most of my systems after initial configuration. -- 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
On 17/08/2019 11.44, Stefan Seyfried wrote:
Am 17.08.19 um 11:39 schrieb Carlos E. R.:
On 17/08/2019 11.06, Stefan Seyfried wrote:>> nobody should edit main.cf manually anyway.
Many do. I do. Would you use YaST instead? I only use it once in the lifetime of the system.
Why not just use postconf instead of editing main.cf? I do not even have yast installed on most of my systems after initial configuration.
Sure. The point is that I do it once, when installing the system, then edit postfix files directly. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Sat, Aug 17, Carlos E. R. wrote:
which is very specific to postfix, and needs looking at a terminal for running the command and another for the editor.
While key/value pair configuration files are very common, not even there is a "standard". Which means: the solution for every application will be different, like the file formats are: key/value, xml, json, yaml, and whatever some developer created. So, no, there will never be one tool able to handle the configuration files of all applications. 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 17/08/2019 12.31, Thorsten Kukuk wrote:
On Sat, Aug 17, Carlos E. R. wrote:
which is very specific to postfix, and needs looking at a terminal for running the command and another for the editor.
While key/value pair configuration files are very common, not even there is a "standard". Which means: the solution for every application will be different, like the file formats are: key/value, xml, json, yaml, and whatever some developer created.
So, no, there will never be one tool able to handle the configuration files of all applications.
In that case, I prefer the configuration files to not change and stay where they are. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Sat, Aug 17, Carlos E. R. wrote:
As admin, I see very problematic having defaults in one place and actual local configuration in another. It makes difficult for the admin to know the actual configuration.
It always depends. If you have to modify only 1-2 variables, a file with only this 1-2 modifications is much easier to maintain und gives you a much better overview over the changes than a file with 10.000 lines where you changed 1-2 variables.
Do we have editors that would load both files and present the admin with the actual configuration? If we don't, I see the proposal as worse that the current status.
The good think on opensource is: if you need something and there is nothing, start write it :) Nearly every editor can show you two files togher, highlight the changes, etc. 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 17/08/2019 12.29, Thorsten Kukuk wrote:
On Sat, Aug 17, Carlos E. R. wrote:
As admin, I see very problematic having defaults in one place and actual local configuration in another. It makes difficult for the admin to know the actual configuration.
It always depends. If you have to modify only 1-2 variables, a file with only this 1-2 modifications is much easier to maintain und gives you a much better overview over the changes than a file with 10.000 lines where you changed 1-2 variables.
That is true. I mark changes with my initials.
Do we have editors that would load both files and present the admin with the actual configuration? If we don't, I see the proposal as worse that the current status.
The good think on opensource is: if you need something and there is nothing, start write it :)
Only if you are a developer with the proper skills (for editors). I am not. And I don't have the money to pay one ;-) Often some things takes decades to appear, others are made once then they rot and disappear.
Nearly every editor can show you two files togher, highlight the changes, etc.
I can't think of any. Joe or mcedit don't do that. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Why not using meld ?
Am Thu, 22 Aug 2019 21:28:45 +0200
schrieb "Carlos E. R."
On 17/08/2019 12.29, Thorsten Kukuk wrote:
On Sat, Aug 17, Carlos E. R. wrote:
As admin, I see very problematic having defaults in one place and actual local configuration in another. It makes difficult for the admin to know the actual configuration.
It always depends. If you have to modify only 1-2 variables, a file with only this 1-2 modifications is much easier to maintain und gives you a much better overview over the changes than a file with 10.000 lines where you changed 1-2 variables.
That is true. I mark changes with my initials.
Do we have editors that would load both files and present the admin with the actual configuration? If we don't, I see the proposal as worse that the current status.
The good think on opensource is: if you need something and there is nothing, start write it :)
Only if you are a developer with the proper skills (for editors). I am not. And I don't have the money to pay one ;-)
Often some things takes decades to appear, others are made once then they rot and disappear.
Nearly every editor can show you two files togher, highlight the changes, etc.
I can't think of any. Joe or mcedit don't do that.
-- Mit freundlichen Grüßen Best Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22/08/2019 23.16, Peter Ragosch wrote:
Why not using meld ?
Certainly. That's what I use now with *.rpmorig, *.rpmold, *.rpmsave vs the active file. rpmconfigcheck tells me the list. With the new system, new defaults will just be deployed to /usr/etc, and I will not know what files changed and what changed on each, so that I can decide what I want to accept or not, unless the *.rpmorig, *.rpmold, *.rpmsave system is applied now to the /usr/etc tree. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (8)
-
Carlos E. R.
-
Dominique Leuenberger / DimStar
-
Jan Engelhardt
-
Peter Ragosch
-
simonizor
-
Stefan Seyfried
-
Thorsten Kukuk
-
Wolfgang Bauer