Kopano Core 8.5.8: A quickfix release

Joost

Hello everyone,

We have released Kapano Core 8.5.8 after receiving feedback from partners and implementing fixes. The kopano-dbadm tool could not clean the database in multi-server setups with duplicate entries in the “properties” table. The updated version contains fixes for these corner-cases and some improvements on the tool in general.

These changes have been merged into the master branch, so tonight’s release of the community packages will have these changes and fixes.

Let me know if you run into any issues.

Kind regards,

Joost

dw2412

Hi Joost,

I’m completely lost and without ideas after this upgrade… Please help.

I got with the “first” 8.5.8 that I’ve installed in morning on 20.04.2018 issues regarding K-1216 and did (despite the DB Backup) as requested with the kopano-dbadm call. This didn’t run through at first time so I’ve started it 2nd time. No success. I found the quickfix release and installed it, The kopano-dbadm this time finished. But now it comes to strange sittuation I’ve ever had since I’ve started with Zarafa/Kopano…

All Mailboxes are accessible using Outlook 2010 and “good old still swinging and dancing” Zarafa Mapi client (latest Version). The latest kopano Webapp 3.4.11.1367 since the upgrade does not show folders in my Inbox and the one of another user. I’ve downgraded the webapp to Version 3.3.1.628 - and I see all folders in both mailboxes. I upgraded to different WebApp Version in 3.4 Series - folders in the both mailboxes are not there. I’ve tried already to find out if there might be an issue using Outlook Spy - but found out nothing.

Please assist to help me to get out this mess.

Thanks

Andreas

Edit: Yes - I’ve cleared browser cache and cookie store…

Andreas,
last night I upgraded to 8.5.8.2_0+27 and run kopano-dbadm to implement the fix. My system works as expected, WebApp 3.4.11.1367-55.1 and z-push 2.4.1 works fine. No need to clear browser cache. OS is SLES12 SP3.
Which OS you use?
Do you see any errors in apache error log?

dw2412

Hi Walter,
thanks for answer, I see no related error entry in server.log, apache error log or anywhere else. Exactly this is part of my problem since I even don’t know where to start searching for. The Subfolders are simply not there in WebApp but they are there in Outlook with Zarafa Mapi Client.

There are some further informations that I can provide right now. With Outlook Spy I managed to open the IPM_SUBTREE Folder. Within this folder I see differences from working User folders. The following Properties are missing:
PR_FOLDER_TYPE, PR_MESSAGE_FLAGS, PR_HASATTACH, PR_CREATION_TIME,
PR_SUBFOLDERS is true in working but False in not working Mailbox
PR_FOLDER_CHILD_COUNT is <> 0 in working but 0 in not working Mailbox
I’ve tried already to add the fields using outlook spy and python but being unsuccessful with both. Outlook Spy - since the last both fields mentioned are Autocalc fields for him is not able to modify them.
If I try to add the fields or modify them with python and query them right after the change, I get shown what I expect. If I recreate the folder object and read the fields again - NUTS! The changes are away again :-(

Only thing in server log that I can find after the update is following - absolutly unrelated - message that is logged so much that I don’t want to count it manually ;-)

Sat Apr 21 14:45:02 2018: [error ] KDatabase::I_Update() query failed: “Table ‘zarafa.clientupdatestatus’ doesn’t exist”, query: DELETE FROM clientupdatestatus where userid=105
Sat Apr 21 14:45:02 2018: [error ] SQL [19541900] Failed: Table ‘zarafa.clientupdatestatus’ doesn’t exist, Query Size: 47, Query: “DELETE FROM clientupdatestatus where userid=105”

Andreas

Hi Andreas,
“Table ‘zarafa.clientupdatestatus’ doesn’t exist” sounds like the old Zarafa client update feature, But this code was removed from Kopano core so fare as I know. Question did you purge all Zarafa components from the server? Look like an old Zarafa code is active.

Walter

dw2412

Hi Walter

yes - the kopano server is running since apprx. September last year. The messages about zarafa,.clientupdatestatus just arrived with kopano-server version 8.5.8. There is no entry in logfile about this earlier than today 10:47am. I don’t know what actually provokes this messages BUT all processes on the server are kopano no single zarafa process is running.

But actually I don’t think that this is the source of all the mess. The main problem is that I cannot see the folders in my Inbox using Kopano WebApp 3.4.x but with WebApp 3.3.1 and with Outlook Zarafa Mapi Client. Only issue with Outlook Zarafa Mapi Client and the both Mailboxes in question is that I cannot even do a Properties -> General -> Foldersize. This results on both mailboxes in no data being displayed.

Andreas

Hi Andreas,

no idea, but try to run the script:
kopano-search-upgrade-findroots.py

Also start Kopano server with parameter “–restart-searches” and leaf it running for about 5 minutes.
/usr/sbin/kopano-server -F --restart-searches

May be it helps.
Walter

dw2412

Hi Walter,
did what you suggested - no change in kopano-server behaviour :-( Means my folders still being lost in webapp and outlook still not working as before the update to 8.5.8 and all this mess :-(

But here some more info about the zarafa.clientupdatestatus source issue… Just changed the level to debug before issuing the both both commands. In Logfile there is now some more info about where the message might have its start:

Sat Apr 21 21:32:15 2018: [debug ] Previous message logged 9 times
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting user 105 from external source
Sat Apr 21 21:32:15 2018: [error ] SQL [19663550] Failed: Table ‘zarafa.clientupdatestatus’ doesn’t exist, Query Size: 47, Query: “DELETE FROM clientupdatestatus where userid=105”
Sat Apr 21 21:32:15 2018: [error ] KDatabase::I_Update() query failed: “Table ‘zarafa.clientupdatestatus’ doesn’t exist”, query: DELETE FROM clientupdatestatus where userid=105
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting user 105 done. Error code 0x80000007
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from file:///var/run/kopano/server.sock
Sat Apr 21 21:32:15 2018: [debug ] Previous message logged 2 times
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from 127.0.0.1
Sat Apr 21 21:32:15 2018: [debug ] Accepted incoming connection from file:///var/run/kopano/server.sock
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting contact 99 from external source
Sat Apr 21 21:32:15 2018: [error ] SQL [19663550] Failed: Table ‘zarafa.clientupdatestatus’ doesn’t exist, Query Size: 46, Query: “DELETE FROM clientupdatestatus where userid=99”
Sat Apr 21 21:32:15 2018: [error ] KDatabase::I_Update() query failed: “Table ‘zarafa.clientupdatestatus’ doesn’t exist”, query: DELETE FROM clientupdatestatus where userid=99
Sat Apr 21 21:32:15 2018: [info ] Auto-deleting contact 99 done. Error code 0x80000007

Looks like that it is autodelete related. Maybe it would make sense to look in kopano server code again - looks like that the clienupdatestatus is not fully removed…

Andreas

Andreas,

no idea, only solution to open a support request tomorrow.

Walter

dw2412

Hi Walter,

thanks for help nevertheless. Since I actually needed to have a working system again I did a kopano-backup of all mailboxes and simply recreated all user mailboxes to be sure and on safe site that the data contained is solid again - yes, that worked!.

I guess it has to do with my setup (multiserver, because of archive server in use) and regarding the both clientupdatestatus messages - actually the user was a test of creating a new account to see what happens with new stores and problems found in both other stores. With new stores the problem is not there, so after the test the user got removed and the “other” problem started… OK - I can live this this. For Auto-deleting contact 99 I have actually no idea. At least no idea why for whatever reason this contact should have ever being using a zarafa client. A contact is just a mail address without any store for my opinion… For my opinion the delete is still having its source here:

strings libkcserver.so.0.0.0|grep -i “delete from clientupdatestatus”
DELETE FROM clientupdatestatus where userid=

So the file is there and it is from Apr 20th:
-rw-r–r-- 1 root root 1792248 Apr 20 12:35 libkcserver.so.0.0.0

and came with following Ubuntu 14.04 LTS Deb File:
-rw-r–r-- 1 root root 568566 Apr 20 12:39 libkcserver0_8.5.8.2-0+27.1_amd64.deb

Maybe you Kopano Devs should have further look into this issue with the clientupdatetable thing…

Andreas

jengelh

Patch is on its way.

Today I also updated a system, database repair needs about 1 hour. It is a hosted Kopano system.
System is working and up again, Outlook sees all folders, I tested with 3 logins.
One issue, a new created user did not get an store, I need to create store manually, will look into this issue tomorrow.

Walter

dw2412

@jengelh said in Kopano Core 8.5.8: A quickfix release:

Patch is on its way.

Thanks ;-) Looks like that this will cure the issue…

Andreas

dw2412

@walterhof Maybe this is all and only related to system that is having such a database history and additionally was used all time with Mapi Client and right with kopano migration got an archiver attached (means actually multiserver because archiver is running on other server):

+-------+-------+-------+------------+------------------+---------------------+
| major | minor | micro | revision   | databaserevision | updatetime          |
+-------+-------+-------+------------+------------------+---------------------+
|     6 |    30 |     0 |      15472 |               29 | 2009-07-05 15:08:33 |
|     6 |    30 |     0 |      15545 |               29 | 2009-07-08 22:47:37 |
|     6 |    30 |     0 |      15765 |               29 | 2009-07-23 14:13:23 |
.
. Edit: shortened...
.
|     8 |     5 |     7 | 2153185280 |               68 | 2018-04-20 08:18:26 |
|     8 |     5 |     8 | 2153250816 |               69 | 2018-04-20 18:21:19 |
|     8 |     5 |     8 | 2153250816 |               70 | 2018-04-20 18:21:35 |
+-------+-------+-------+------------+------------------+---------------------+
133 rows in set (0.02 sec)

Yes - it is running more or less since the days zarafa got opensource… Got upgraded with nearly everything and anything ;-)

Andreas

Andreas,

my system started 3 years later:

+-------+-------+-------+------------+------------------+---------------------+
| major | minor | micro | revision   | databaserevision | updatetime          |
+-------+-------+-------+------------+------------------+---------------------+
|     7 |     1 |     0 |      39121 |               63 | 2012-12-22 20:16:24 |
|     7 |     1 |     0 |      40304 |               63 | 2013-01-26 16:53:07 |
 ...
|     8 |     5 |     7 | 2153185280 |               68 | 2018-04-19 19:15:46 |
|     8 |     5 |     8 | 2153250818 |               69 | 2018-04-20 18:19:33 |
|     8 |     5 |     8 | 2153250818 |               70 | 2018-04-20 18:19:33 |
+-------+-------+-------+------------+------------------+---------------------+
58 rows in set (0.02 sec)

This version should contain a database fix fur older systems.

Walter

dw2412

@walterhof so the last question is - have you kopano-archiver running with 2nd server running on other system? If I understood all the kopano-dbadm issues right the things fixed in the quickfix should be for multiserver installations. Maybe this is the clue in this story…

Andreas

Only single server installations and multi company installations but no kopano-archiver.

Walter

dw2412

With all kopano single server installations that I’m responsible for - including one with multicompany - there was no issue during the upgrades. Just 2 needed at all the use of kopano-dbadm…

Andreas

mcostan

I have a similar issue as posted in:

https://forum.kopano.io/topic/1370/error-in-kopano-core/7

I have never seen this error before 8.5.8