Hello Am 22.08.2017 um 08:50 schrieb Zhang Huangbin ([email protected]): > >> On Aug 21, 2017, at 10:49 PM, Christian Mack >> ([email protected]) <[email protected]> wrote: >> >> That should have worked. >> At least on my last migration test it did. > > Unfortunately, it didn’t work for me. > >> You should open a bug report for that. > > Bug report: https://sogo.nu/bugs/view.php?id=4256 > > Here’s how i got the backup fully restored (SOGo 2.2.15 -> 2.3.22 -> 3.2.10): > 3 machines involved, old server runs SOGo-2.2.15 and we’re going to migrate > it. A temporary virtual machine runs SOGo-2.3.22 and used to help get the > latest SQL structure of SOGo 2.x branch. The final new server runs > SOGo-3.2.10, it is the one we’re going to deploy in production. Steps: > > 1) Old server is running SOGo-2.2.15, backup data with 'sogo-tool backup'. > 2) Setup a new VM with SOGo-2.3.22 (the latest version of 2.x branch). > 3) On new VM, drop sogo db, re-create it, restart sogo service. SOGo creates > required SQL tables automatically. Note: since it’s already 2.3.x with new > SQL structure, i didn’t run the script "sql-update-2.2.17_to_2.3.0-mysql.sh” > to modify SQL table structure. > 4) On new VM, restore backup files with 'sogo-tool restore'. Login to SOGo > and verify restored data. So far so good, all personal contacts/calendars, > and shared calendars are restored. > 5) On new VM, backup sogo data by dumping the whole sogo sql database (not > ‘sogo-tool backup’). > 6) On final new server, runs SOGo-3.2.10 (the latest version of 3.x branch). > 7) On final new server, drop sogo db, re-create it, restart sogo service. > SOGo creates required SQL tables automatically. > 8) On final new server, import dumped sogo sql file (generated on step #5). > 9) On final new server, run script "sql-update-3.0.0-to-combined-mysql.sh” > (shipped in SOGo package) to update SQL structure. > 10) On final new server, backup data with “sogo-tool backup”. Then run > “sogo-tool restore -p -c /etc/sogo/sieve.cred <backup-dir> <user>” to > generate sieve rules. > 11) Login to final new server and review restored data, so far so good, all > personal contacts/calendars, and shared calendars are restored. >
Good to know. > Question: > > - We stores mail accounts in OpenLDAP, why does SOGo backup file contains > full LDIF data of user? I don't know the reason, but that is all information SOGo has about the user. > especially attribute "userPassword". I suppose only uid (full email address) > and/or ldap dn of user should be enough? It may become a security concern if > sysadmin didn’t realize the backup file contains (hashed) password and didn’t > set proper owner/group and file permission. > You can change that. Just do _not_ give the administrative account (used to query the Lprovided DAP) read privileges on attribute userPassword. It is not necessary anyway, as SOGo does a bind with the password provided by the user. Kind regards, Christian Mack -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung Basisdienste 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: S/MIME Cryptographic Signature
