Hi all,
Once upon a time there were a few YaST modules which overwrote manually edited configuration files. Instead of changing only certain configuration options YaST overwrote all entries of the specific configuration file. In this case values were lost which had been manually changed before running YaST.
YaST doesn't accidentally overwrite configuration values anymore!
If it does it's a bug. If you know any YaST module that still destroys manually changed configuration files. please report a bug (and cc me).
We want to get rid of the myth that YaST accidentally overwrites files.
Thank you Thomas
Le 16/02/2011 17:07, Thomas Goettlicher a écrit :
We want to get rid of the myth that YaST accidentally overwrites files.
it was probably very rare anyway :-). I remember YaST stores a file md5sum somewhere.
That said, what is the prefered action? backup the old file or write some sort of file.ext.yast prefered example?
for example what is yast doing with /boot/grub/menu.lst?
thanks jdd NB: this situation should be reported on the yast page of the wiki, with the bugzilla action needed. It's very nice to have somebody identified try solve any such question :-)
On Wednesday, February 16, 2011 05:33:44 pm jdd wrote:
Le 16/02/2011 17:07, Thomas Goettlicher a écrit :
We want to get rid of the myth that YaST accidentally overwrites files.
it was probably very rare anyway :-). I remember YaST stores a file md5sum somewhere.
That said, what is the prefered action? backup the old file or write some sort of file.ext.yast prefered example?
It depends. If YaST can parse the whole configuration file it should only change the affected values and leave the other values untouched. If that isn't possible I think YaST should warn the user that not all manually edited config options can be preserved.
for example what is yast doing with /boot/grub/menu.lst?
For this file it add lines like: ###Don't change this comment - YaST2 identifier: Original name: linux###
thanks jdd NB: this situation should be reported on the yast page of the wiki, with the bugzilla action needed. It's very nice to have somebody identified try solve any such question :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 16.2.2011 17:50, Thomas Goettlicher napsal(a):
On Wednesday, February 16, 2011 05:33:44 pm jdd wrote:
Le 16/02/2011 17:07, Thomas Goettlicher a écrit :
We want to get rid of the myth that YaST accidentally overwrites files.
it was probably very rare anyway :-). I remember YaST stores a file md5sum somewhere.
That said, what is the prefered action? backup the old file or write some sort of file.ext.yast prefered example?
It depends. If YaST can parse the whole configuration file it should only change the affected values and leave the other values untouched. If that isn't possible I think YaST should warn the user that not all manually edited config options can be preserved.
Sometimes this can still happen - it's actually not YaST fault but configuration-design fault:
If a configuration is generated from sysconfig (/etc/sysconfig/...) and user changes the generated file, YaST doesn't read the changed file but reads/writes sysconfig variables instead. After that, a particular service can rewrite the user-crafted configuration file by using values from sysconfig.
Bye Lukas
- --
Lukas Ocilka, Appliances Department, Novell Inc.
* Lukas Ocilka lukas.ocilka@suse.cz [Feb 18. 2011 10:34]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 16.2.2011 17:50, Thomas Goettlicher napsal(a):
On Wednesday, February 16, 2011 05:33:44 pm jdd wrote:
Le 16/02/2011 17:07, Thomas Goettlicher a écrit :
We want to get rid of the myth that YaST accidentally overwrites files.
it was probably very rare anyway :-). I remember YaST stores a file md5sum somewhere.
That said, what is the prefered action? backup the old file or write some sort of file.ext.yast prefered example?
It depends. If YaST can parse the whole configuration file it should only change the affected values and leave the other values untouched. If that isn't possible I think YaST should warn the user that not all manually edited config options can be preserved.
Sometimes this can still happen - it's actually not YaST fault but configuration-design fault:
If a configuration is generated from sysconfig (/etc/sysconfig/...) and user changes the generated file, YaST doesn't read the changed file but reads/writes sysconfig variables instead. After that, a particular service can rewrite the user-crafted configuration file by using values from sysconfig.
Thats the magig "SuSEconfig" which should not touch the file if it was changed by a user.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
* Thomas Goettlicher thomas.goettlicher@suse.de [Feb 16. 2011 17:45]:
for example what is yast doing with /boot/grub/menu.lst?
For this file it add lines like: ###Don't change this comment - YaST2 identifier: Original name: linux###
Which might be one of the (perceived) problems of YaST - its inability to read/parse config files and its insistence to re-generate such stuff.
Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Thomas Goettlicher write:
On Wednesday, February 16, 2011 05:33:44 pm jdd wrote:
Le 16/02/2011 17:07, Thomas Goettlicher a écrit :
We want to get rid of the myth that YaST accidentally overwrites files.
it was probably very rare anyway :-). I remember YaST stores a file md5sum somewhere.
That said, what is the prefered action? backup the old file or write some sort of file.ext.yast prefered example?
It depends. If YaST can parse the whole configuration file it should only change the affected values and leave the other values untouched. If that isn't possible I think YaST should warn the user that not all manually edited config options can be preserved.
for example what is yast doing with /boot/grub/menu.lst?
For this file it add lines like: ###Don't change this comment - YaST2 identifier: Original name: linux###
It is really good reason to have such line. Main purpose is to store identification done during installation like detect windows on different partition and remember it. Nowadays main purpose is to recognize normal and failsafe boot section, because it differs just via kernel append ( and it is hard to guess it) and failsafe is kernel which should not be default one, so when you remove your boot kernel I use it to choose good kernel to be used during boot.
To compare ubuntu had ( for legacy grub) a lot more info in comments - https://help.ubuntu.com/community/GrubHowto
Josef
thanks jdd NB: this situation should be reported on the yast page of the wiki, with the bugzilla action needed. It's very nice to have somebody identified try solve any such question :-)
-
jdd -
Josef Reidinger -
Klaus Kaempf -
Lukas Ocilka -
Thomas Goettlicher