SOGo - BTS - SOGo
View Issue Details
0001156SOGoPackaging (Debian)public2011-02-28 09:132012-11-18 12:38
wsourdeau 
 
normalfeaturehave not tried
closedfixed 
 
2.0.2 
0001156: SOGo should rely on a configuration file in /etc/
This would provide a more standard "unix way" of configuring a server process. Also, it would enable sogo-tool and the OpenChange backend to make use of the same configuration file. Moreover, it would prevent the buggy code in NSUserDefaults from rewriting plist files in XML.

The case of having multiple instances running in parallel could be simply solved by leaving the user-based configuration take over in those cases.
No tags attached.
patch 0004-Read-configuration-from-etc.patch (3,819) 2012-04-04 12:33
https://sogo.nu/bugs/file_download.php?file_id=564&type=bug
Issue History
2011-02-28 09:13wsourdeauNew Issue
2011-11-24 14:55ludovicSeverityminor => feature
2012-04-04 12:33dekkersNote Added: 0003687
2012-04-04 12:33dekkersFile Added: 0004-Read-configuration-from-etc.patch
2012-04-04 12:34wsourdeauCategoryBackend General => Packaging (Debian)
2012-11-18 12:38ludovicNote Added: 0004898
2012-11-18 12:38ludovicStatusnew => closed
2012-11-18 12:38ludovicResolutionopen => fixed
2012-11-18 12:38ludovicFixed in Version => 2.0.2

Notes
(0003687)
dekkers   
2012-04-04 12:33   
I'm not sure that this is the correct approach, but I did some basic testing and it seems to work. When /etc/sogo/sogo.conf doesn't exist we fallback to the old code of using the user defaults, but when it does exists we read it and create a volatile sogod domain from it. Because the domain is volatile it isn't written back to the GNUstep Defaults directory. It will also try to read debconf.conf, the idea is that debconf generated configuration items such as the configured database will live in debconf.conf. This should probably be only included on Debian systems, but I added it because I'd feedback whether this is the right approach.
(0004898)
ludovic   
2012-11-18 12:38   
This is now possible in v2.0.2.