Bugzilla – Bug 134558
Samba server configuration overwrites settings made in KDE "samba" control module
Last modified: 2008-06-25 09:53:04 UTC
If I change settings, e.g. the "security level" in the KDE "samba" control module (which has much more option than yast2) and then change something with YaST2 "samba server" module (so that the samba configuration is rewritten) I lose those changes, e.g. the "security level" is set back to "user"
Please attach the y2log's after you reproduced this.
Created attachment 57932 [details] YaST2 logs
Logs are attached.
This is a natural problem: Configuration files are generated using the information you configured with a specific tool. YaST2 however should at least not rewrite those parts of the configuration it cannot change. Please be a bit more specific: Does YaST read the configuration correctly and you cannot recover them with the KDE module after it is written or is it vice versa? As I understand it, YaST (re)writes options which it cannot change with a default value. Lukas: Please look into that.
It´s exactly as you said. YaST reads the configuration correctly but it overwrites any options which you can´t set in it, e.g. the security level. IMHO this is a general problem. There should be only one central place to configure a specific thing, and this is in YaST. The KDE control center should only be there for configuring the Desktop. not the system. Removing all those "system centric" control modules (and perhaps extending YaST a bit) would perhaps be much more consistent and easier than to make sure things like this one work.
Michael: could you, please, attach also that configuration file which yast2-samba-server doesn't understand?
Created attachment 58352 [details] /etc/samba/smb.conf
Thanks for that smb.conf
This seems to be a bit complicated YaST Samba server doesn't drop options which doesn't understand but rewrites some of them and adds or removes others. This is the only change in your smb.conf: --- cut --- - security = share - preferred master = no - server string = + security = user + domain logons = No --- cut --- Removes "server string" because it is not defined at all. Option "security" is set depending on the settings of the SambaRole to "user" or "domain". Option "preferred master" is also set depending on the current configuration SambaConfig->GlobalSetTruth("preferred master", $on); # default = Auto (Yes if LocalMaster and DomainMaster) All in all, YaST adds it's own logic into the configuration based on supported scenarios. Probably the same as KDE samba-control-module does but in a different way with different scenarios. I can't see any possibility for persuading YaST to support if in a different way but let's ask Lars if he has any additional information.
Lars, could you, please, write something for the comment #9? Thx
Resolution: YaST just doesn't support this scenario, because it just can't support all possibilities. If somebody uses YaST to configure the tool decides between supported scenarios and tunes the configuration by that scenario. YaST just adds its own logic to the configuration. Lars, Ralf: if you think this is wrong, please, reopen the bug and propose a solution.
What I find unintuitive for the user: If YaST is the default setup tool for the System why do you include all those other utilities which don´t work? Or why doesn´t YaST writes that it "detected a configuration created by another tool" and asks if it should overwrite it. It´s just bad whan I do some changes in the KDE Samba control module and YaST just resets them.
In reply to comment #9. YaST should never change a setting even if a combination of settings don't fit into a predefined configuration pattern. If we run in such a situation please inform the user about this inconsistency and let the user decide to stay with or to override the current config. Also empty settings like 'server string =' should not be removed as such an empty setting leads to a different result than a non existing config line.
This is definitly an enhancement. This is an unexpected case for the yast2-samba-server. At the moment, it is impossible to deliver it for the SLES10 / SL 10.1. If you feel this functionality should be added, please file a feature request into the FaTE.
You're right. I just want to ensure this will _not_ get lost.
All current enhancements should be changed to -> LATER I'll reopen them after the time comes.
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(