Hi When upgrading to Version 4. did you switch from 3 tables per user to 9 tables combined layout?
This error messeges seem to indicate, you did partly. If you did, you should do it completely first. Kind regards, Christian Mack Am 25.05.20 um 19:31 schrieb Philipp Kuehne (philipp.kue...@indurad.com): > Hi, > > we recently upgraded our sogo installation from version 2 to version > 4.3.0 on a debian 10. > > Since the migration worked fine I had a colleague who married and got a > new surname. > > So I changed all attributes in ldap and used the "sogo-tool rename-user" > to give him access to his calendar and tasks. > > First thing I noticed was that there were like hundreds of errors > because the database structure changed and there were no more personal > tables for each user. > > Here is an example for one of these errors: > > 2020-05-25 18:47:29.064 sogo-tool[21871:21871] > <MySQL4Channel[0x0x563777b343f0] connection=0x0x563777a14170> SQL: UPDATE > sogosomeposix0014ba520e0_acl SET c_uid = 'newposix' WHERE c_uid = 'oldposix'; > > 2020-05-25 18:47:29.064 sogo-tool[21871:21871] > <MySQL4Channel[0x0x563777b343f0] connection=0x0x563777a14170> ERROR: Table > 'sogodb.sogosomeposix0014ba520e0_acl' doesn't exist > > Since these tables didn't exist anymore I wasn't worried and everything > looked fine. > > Today I got lots of complaints that people couldn't access other > calendars so i checked the database and saw that all the entries in > sogo_acl where wrong. > > Here is a short cutout: > > | 351 | /newposix/Calendar/5A00-59D22100-1-70F14480 | someposix > | ConfidentialDAndTViewer | > | 351 | /newposix/Calendar/5A00-59D22100-1-70F14480 | someotherposix > | PrivateDAndTViewer | > > All 5600 lines in this table looked exactly like this so I took the > table from my backup and changed the according lines manually since > everything else lokked ok. > > So I cloned my Setup to see where things went wrong and found the line: > > root@myserver:~# sogo-tool -v rename-user oldposix newposix > 2020-05-25 18:47:28.915 sogo-tool[21871:21871] MySQL4 connection established > 0x0x563777a14170 > ... > 2020-05-25 18:47:28.987 sogo-tool[21871:21871] > <MySQL4Channel[0x0x563777e3f060] connection=0x0x563777e4f310> SQL: SELECT > c_uid, c_object, c_role FROM sogo_acl WHERE c_folder_id = 424 AND (c_object > LIKE '/oldposix/%'); > 2020-05-25 18:47:28.987 sogo-tool[21871:21871] > <MySQL4Channel[0x0x563777e3f060] connection=0x0x563777e4f310> query has > results, entering fetch-mode. > 2020-05-25 18:47:28.987 sogo-tool[21871:21871] > <MySQL4Channel[0x0x563777e3f060] connection=0x0x563777e4f310> SQL: UPDATE > sogo_acl SET c_object = '/newposix/Calendar/5A00-59D22100-1-70F14480'; > ... > > followed by the errors mentioned above > > Obviously somewhere in this script the update-query is missing the > where-clause which is used in the query before. > > Is this a known bug and we're just on an old version? Or is this a new > bug and nobody noticed yet? > > kind regards > > Philipp > -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416
smime.p7s
Description: S/MIME Cryptographic Signature
