Hello Check your configuration in sogo.conf. You need the following new settings for 9 table layout: OCSStoreURL OCSAclURL OCSCacheFolderURL
I assume OCSAclURL is missing. Kind regards, Christian Mack Am 26.05.20 um 14:46 schrieb Philipp Kuehne (philipp.kue...@indurad.com): > 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 > (christian.m...@uni-konstanz.de): >> 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