Hi Christian,

we have all these settings in our config.

If you want I can anonymize the data and send it to you so you can have
a look!

Thanks in advance.

Kind regards

Philipp

Am 26.05.20 um 16:18 schrieb Christian Mack
([email protected]):
> 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 ([email protected]):
>> 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/>

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to