Hi, We did install version 4 with the 9-table layout. However we did not do an upgrade, we exported the data with sogo-tool on the SOGo 2 server and imported with sogo-tool on the SOGo 4 server.
So seems like we missed something. Does anyone have an idea how to solve that issue? Kind regards, Philipp Am 26.05.20 um 09:15 schrieb Christian Mack ([email protected]): > 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 ([email protected]): >> 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 >> > -- ___________________________________________ Philipp Kühne | IT Administrator <https://indurad.com/> indurad GmbH| the industrial radar company Belvedereallee 5 | 52070 Aachen | Germany phone: +49 241 538070-103 | front desk: +49 241 538070-0 email: [email protected] <mailto:[email protected]> | web: www.indurad.com <https://indurad.com/>
signature.asc
Description: OpenPGP digital signature
