subject:"\[SOGo\] sogo\-tool rename"

Re: [SOGo] sogo-tool rename-user erases all acl's

2020-05-26 Thread Philipp Kuehne

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
(christian.m...@uni-konstanz.de):
> 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] 
  SQL: UPDATE 
 sogosomeposix0014ba520e0_acl SET c_uid = 'newposix' WHERE c_uid = 
 'oldposix';

 2020-05-25 18:47:29.064 sogo-tool[21871:21871] 
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] 
  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] 
query has 
 results, entering fetch-mode.
 2020-05-25 18:47:28.987 sogo-tool[21871:21871] 
  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


indurad GmbH| the industrial radar company

Belvedereallee 5 | 52070 Aachen | Germany
phone: +49 241 538070-103 | front desk: +49 241 538070-0
email: philipp.kue...@indurad.com  |
web: www.indurad.com 


signature.asc
Description: OpenPGP digital signature

Re: [SOGo] sogo-tool rename-user erases all acl's

2020-05-26 Thread Christian Mack

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] 
>>>  SQL: UPDATE 
>>> sogosomeposix0014ba520e0_acl SET c_uid = 'newposix' WHERE c_uid = 
>>> 'oldposix';
>>>
>>> 2020-05-25 18:47:29.064 sogo-tool[21871:21871] 
>>>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] 
>>>  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] 
>>>query has 
>>> results, entering fetch-mode.
>>> 2020-05-25 18:47:28.987 sogo-tool[21871:21871] 
>>>  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

Re: [SOGo] sogo-tool rename-user erases all acl's

2020-05-26 Thread Philipp Kuehne

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] 
>>  SQL: UPDATE 
>> sogosomeposix0014ba520e0_acl SET c_uid = 'newposix' WHERE c_uid = 'oldposix';
>>
>> 2020-05-25 18:47:29.064 sogo-tool[21871:21871] 
>>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] 
>>  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] 
>>query has 
>> results, entering fetch-mode.
>> 2020-05-25 18:47:28.987 sogo-tool[21871:21871] 
>>  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


indurad GmbH| the industrial radar company

Belvedereallee 5 | 52070 Aachen | Germany
phone: +49 241 538070-103 | front desk: +49 241 538070-0
email: philipp.kue...@indurad.com  |
web: www.indurad.com 


signature.asc
Description: OpenPGP digital signature

Re: [SOGo] sogo-tool rename-user erases all acl's

2020-05-26 Thread Christian Mack

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] 
>  SQL: UPDATE 
> sogosomeposix0014ba520e0_acl SET c_uid = 'newposix' WHERE c_uid = 'oldposix';
> 
> 2020-05-25 18:47:29.064 sogo-tool[21871:21871] 
>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] 
>  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] 
>query has 
> results, entering fetch-mode.
> 2020-05-25 18:47:28.987 sogo-tool[21871:21871] 
>  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

[SOGo] sogo-tool rename-user erases all acl's

2020-05-25 Thread Philipp Kuehne

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]  SQL: UPDATE sogosomeposix0014ba520e0_acl SET c_uid 
= 'newposix' WHERE c_uid = 'oldposix';

2020-05-25 18:47:29.064 sogo-tool[21871:21871]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]  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]query has results, entering fetch-mode.
2020-05-25 18:47:28.987 sogo-tool[21871:21871]  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


indurad GmbH| the industrial radar company

Belvedereallee 5 | 52070 Aachen | Germany
phone: +49 241 538070-103 | front desk: +49 241 538070-0
email: philipp.kue...@indurad.com  |
web: www.indurad.com 


signature.asc
Description: OpenPGP digital signature

Re: [SOGo] sogo-tool rename

2017-04-11 Thread Ludovic Marcotte


On 2017-04-11 8:28 AM, Paul van der Vlis (p...@vandervlis.nl) wrote:


I try to rename a user with something like:
sogo-tool -v rename-user adegraaf avandermeer

I get an output like this:
<0x0x8616ac0[SOGoCache]> Cache cleanup interval set every 300.00 seconds
<0x0x8616ac0[SOGoCache]> Using host(s) 'localhost' as server(s)

But when I login as the new user I don't see an calendar or adress-book.

What will be wrong?
If you logged in with that user just before renaming it, cached data 
will be in memcached. In your case, you can wait up to 300 seconds for 
the cached data to expire.


--
Ludovic Marcotte
lmarco...@inverse.ca  ::  +1.514.755.3630  ::  http://inverse.ca
Inverse inc. :: Leaders behind SOGo (http://sogo.nu), PacketFence 
(http://packetfence.org) and Fingerbank (http://fingerbank.org)

--
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] sogo-tool rename

2017-04-11 Thread Paul van der Vlis

Hello list,

I try to rename a user with something like:
sogo-tool -v rename-user adegraaf avandermeer

I get an output like this:
<0x0x8616ac0[SOGoCache]> Cache cleanup interval set every 300.00 seconds
<0x0x8616ac0[SOGoCache]> Using host(s) 'localhost' as server(s)

But when I login as the new user I don't see an calendar or adress-book.

What will be wrong?

With regards,
Paul van der Vlis



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] sogo-tool rename-user mess

2015-03-20 Thread Ian McMichael

I have recently changed the authentication of our SOGo instance 
(together with Dovecot and Postfix) to use e-mail addresses (in the form 
u...@example.net) instead of account names (in the form user).  
Sadly I made a mistake whilst doing this (which I have done before on 
other systems successfully).  I restarted the SOGo daemons and logged 
into a few accounts via webmail before running sogo-tool rename-user 
commands.


When I realised my mistake I shut everything down and immediately ran:

sogo-tool rename-user user u...@example.net

for each user on the system.

Sadly this was too late and I seem to have broken the settings for 
several users who now have duplicate entries for their calendar and 
contacts.


sogo-tool user-preferences get settings usera Contacts gives:

Contacts: {FolderShowAlarms: 
{us...@example.net:Contacts\/3E92-539F0080-1-5AAFDB80: 0, 
userb:Contacts\/personal: 0, us...@example.net:Contacts\/personal: 
0}, FolderDisplayNames: {us...@example.net:Contacts\/personal: 
Userb Address Book (Userb us...@example.net)}, DragHandleVertical: 
365, SubscribedFolders: [us...@example.net:Contacts\/personal]}


I have checked the folder_info table in MySQL and only one version of 
each address book/calendar actually exists and is correct with the new 
u...@example.net format in both the c_path and c_path2 columns.


Can anyone suggest an easy way for me to fix the mess I have made? I 
could unsubscribe from all the calendar/address books and stop sharing 
them.  This may help but wouldn't fix the personal ones. I'm afraid that 
if I try and edit them manually I will make a typo somewhere and cause a 
bigger mess!


All suggestions very gratefully received...


Ian.
--
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] sogo-tool rename-user erases all acl's

Re: [SOGo] sogo-tool rename-user erases all acl's

Re: [SOGo] sogo-tool rename-user erases all acl's

Re: [SOGo] sogo-tool rename-user erases all acl's

[SOGo] sogo-tool rename-user erases all acl's

Re: [SOGo] sogo-tool rename

[SOGo] sogo-tool rename

[SOGo] sogo-tool rename-user mess

8 matches

Site Navigation

Mail list logo

Footer information