General discussion on installation and configuration of SOGo

Text archives Help


Re: [SOGo] Any way to backup and restore shared calendars?


Chronological Thread 
  • From: "Christian Mack" ( ) < >
  • To:
  • Subject: Re: [SOGo] Any way to backup and restore shared calendars?
  • Date: Tue, 22 Aug 2017 13:18:41 +0200
  • Dmarc-filter: OpenDMARC Filter v1.2.0 mail.inverse.ca 1AA2EBA7B71

Hello

Am 22.08.2017 um 08:50 schrieb Zhang Huangbin
( ):
>
>> On Aug 21, 2017, at 10:49 PM, Christian Mack
>> ( )
>>
>> < >
>> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.18.

Top of page