z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F

thctlo

Try this :

wget -qO - http://repo.z-hub.io/z-push:/final/Debian_10/Release.key | sudo apt-key add -
echo "deb http://repo.z-hub.io/z-push:/final/Debian_10 /" > /etc/apt/sources.list.d/z-push.list
apt update
apt dist-upgrade 
apt-get install z-push-common

Note: package z-push in debian = z-push-common on the z-push repo.
optional also install : z-push-config-apache z-push-config-apache-autodiscover

hugo21212

I have the same problem:

15/08/2019 13:00:51 [15452] [WARN] [x@y.z] StatusException: ExportChangesICS->InitializeExporter(): Error, mapi_exportchanges_config() failed: 0xFFFFFFFF8004010F - code: 12 - file: /usr/share/z-push/backend/kopano/exporter.php:230

But only for Android using Exchange and synchronizing the calendar.
If I use Outlook with ActiveSync, there is no problem. I can see the calendar and create entries

Installed packages:

ii  z-push-autodiscover                  2.5.1+0-0                     all          Z-Push autodiscover
ii  z-push-backend-caldav                2.5.1+0-0                     all          Z-Push caldav backend
ii  z-push-backend-kopano                2.5.1+0-0                     all          Z-Push Kopano backend
ii  z-push-common                        2.5.1+0-0                     all          open source implementation of the ActiveSync protocol
ii  z-push-config-apache                 2.5.1+0-0                     all          Z-Push apache configuration
ii  z-push-config-apache-autodiscover    2.5.1+0-0                     all          Z-Push autodiscover apache configuration
ii  z-push-ipc-sharedmemory              2.5.1+0-0                     all          Z-Push ipc shared memory provider

on Debian 10 Buster

And one thing: in Debian 10 there is no such thing as php7-mapi.

> apt install z-push-kopano z-push-backend-kopano

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 z-push-backend-kopano : Depends: php7-mapi but it is not installable or
                                  php5-mapi but it is not installable
E: Unable to correct problems, you have held broken packages.

only:

ii  php-mapi                             8.7.0-3                       amd64        Complete and feature rich groupware solution - PHP MAPI bindings

hugo21212

For me it helped to delete all old calender entries. Then synchronization worked.

It would be good to see, why it failed (corrupt entry, too many entries etc.).

thctlo

apt remove php-mapi --autoremove
apt install kopano-server-packages

Ow, before you remove php-mapi, verify the other packages of kopano also.

dpkg -l |grep “8.7.0-3”

Beleggrodion

@badewaschl said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:

Then I tried to clean up using kopano-fsck, but that reported the same 14 issues every time I ran it, claiming the issues were fixed. I ended up manually deleting the affected calendar entries. But the z-push issue still remained.

Thanks. I forgot completely that this tool exists. I tried this on my side and it worked for the affected user :-)

badewaschl

@thctlo said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:

apt install kopano-server-packages

# apt install kopano-server-packages
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package kopano-server-packages

thctlo

@badewaschl
Hai, then you are probely not have the local repo.

I suggest get this and run it, IF the packages are online again.
and i just looked at : https://download.kopano.io/community/
And its not, so reuse the older downloaded kopano files.

wget https://raw.githubusercontent.com/thctlo/Kopano/master/get-kopano-community.sh

get this script run it, ignore the errors then get the files your already downloaded before.
Put them in, based on :

BASE_FOLDER=$HOME/kopano-repo

# A subfolder in BASE_FOLDER.
KOPANO_EXTRACT2FOLDER="apt"

$HOME/kopano-repo/apt

And run the script again.
Now your able to use apt and kopano-server-packages should be available now.

fbartels

So far we have been unable to reproduce this issue. If running kopano-fsk indeed makes a difference, then it would be great if someone could provide a dump of such a store to feedback@kopano.com (or get in contact with our support for a remote session if you have a valid subscription).

Edit: since there is an influx of users saying that they are running an older release on Debian 10 (presumably installed from the downstream Debian repository) I would not recommend to mix our packages with the ones provided by the Debian Maintainers. They are using a different naming schema (and only our packages and releases are actively tested by us) and are not compatible with each other.

thctlo

@fbartels
There is a dependecy problem with php-mapi.
The debian kopano 8.7.0 should never have been release and i really advice everyone not to use it.
Just to buggy. i tried to get 8.7.3 in but Buster was frozen already.

if you have the debian kopano (8.7.0-3) installed and your upgrade to the “development/community” packages, your upgrade will fail due to a missing depend on php7-mapi ( from kopano-repo.)

If kopano adds a “Replaces” php-mapi in the packaging for packages php7-mapi
then this upgrade problem is fixed in the future.

Greetz,

Louis

fbartels

@thctlo said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:

The debian kopano 8.7.0 should never have been release

You would need to complain on the Debian mailinglist about that. We have no influence on packages in the Debian repositories. For the Maintainers there it’s probably also more helpful to list actual problems instead of saying that it was all a mistake.

@thctlo said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:

If kopano adds a “Replaces” php-mapi in the packaging for packages php7-mapi
then this upgrade problem is fixed in the future.

I do doubt that a replaces in a single package would make a difference, the general advice is to not mix packages and when following our documentation to install our packages this will not happen.

thctlo

@fbartels
why complain at #Debian, its not complaining, im just giving a notice that the debian packages are not very good to use and its better to use the Kopano packages.

If i upgrade the kopano packages with debian packages, then yes, i can give them a notice but it’s visaversa.

If you upgrade Debian with Kopano packages, then the Kopano packages should take the “php-mapi” in count.

Debian changed php7-mapi to php-mapi, dont ask my why.
I have to do the same with packaging samba and the python2 too python3 changes.

thctlo

@fbartels
just asking, is there a git of the kopano development packaging, im willing to have a look at this.

Its something like this :
Breaks: kopano-server (= 8.7.0-3)
Replaces: php-mapi (= 8.7.0-3)
Depends: php7-mapi (>> 8.7.82~ )

fbartels

@thctlo the z-push packaging is part of the git repo, but for core nothing like this exists (its anyways a bit OBS specific, as this is what we use for building) a not totally up to date snapshot can be found at https://build.opensuse.org/package/show/server:mail:kopano/kopano.

weini

I can confirm now, that migrating from MariaDB 10.3 to MySQL 8.0 resolves the issue.
I´m on Debian 10, but using current (2 week old nightlys) packages from kopano.io and the current z-push 2.5.1.

I did a migration on database level (mostly using InnoDB transportable tablespaces, partially simple mysqldump). So this means that having an “old” Kopano install with dozends of entries in the version table by itself does not trigger the issue.

Consequences from my perspective:

forget about the Debian repository packages for now, they´re not properly tested - crap IMHO
you have to use MySQL if you´ve more than 3.000 objects in your larger folders

It is a shame that we´re suffering from such problems. But don´t get me wrong, this is no blaming. This is free software and it needs our effort to improve it.

@fbartels: I can´t provide you with a full dump of all my personal emails to reproduce the problem. But I now have two db schemas available, one working and one triggering the issue. Pls let me know how I may further supprt you debugging the issue.

compsos

@thctlo When running z-push-top does it display the php-mapi version? We have a D10 system that works but from the repo it could not load php-mapi. Eventually added other z-push components from D9 code.

bcoms

I can hereby confirm that migrating to mysql 8 solves the issue. With MariaDB I was able to solve the issue partially for calendar items by running kopano-fschk, however the tool only complained about entries which were created by Outlook when acting on appointment e-mails from other users. However kopano-fschk never solved the problem for e-mails as no problems were reported anyways.

bcoms

@weini
I can second your opinion about the Debian Kopano packages. No idea how they made it into the stable distribution in that poor condition - they should be removed asap.

MySQL: I already had problems with MariaDB and inboxes with only about 1K items.

thctlo

@bcoms because now, they can use buster-backports.
If kopano was not in buster, no backport could be made and push into buster.

General_Probe

I’m also on Buster with Debian Kopano 8.7.0-3 and switched from MariaDB 10.3 to MySQL 5.7. It works fine since last wednesday now. I will file a bug report soon at debians bug reporting tool.

I also dont know how these packages got into Debian Stable. I think I hold 90% of the bugs for kopano at debian …
Kopano-Search has lots of apparmor issues
Kopano-Server is missing config files (ldap.cfg and admin.cfg) also user creation, deletion, updating is not working with current config on ldap

I also dont want to blame the Debian developers. They are very helpful, but it is just annoying to run from one issue into another.

fbartels

@weini said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:

But I now have two db schemas available, one working and one triggering the issue. Pls let me know how I may further supprt you debugging the issue.

Sure, its worth a try.