Can't create/update contacts in Evolution | kdav (git) with Core 8.7.82

Manfred

I moved your posts to this topic as it seems to be the same issue.

I didn’t have time yet to debug this more intensively, but it’s on my task list. I’ll post here if I have more questions or in case I’ll find something.

Manfred

ersaxp

@Manfred Thank you!

irreleph4nt

@Manfred
Have you had the chance yet to look at this?

Manfred

Hi,

I was not able to reproduce it on the systems I’ve tested. Those were debian-based systems though. It worked fine using apache as well as nginx with php-fpm. I’ve tested with KC 8.7.0 and 8.7.5.

Manfred

irreleph4nt

@Manfred
So I’ll have to re-test with 8.7 then? Hm … okay.

Edit:
if it helps at all, I can upload my configs somewhere or even get you access to the machine. It’s just a Dev box so nothing sensitive stored on it. I am happy to support debugging this in whichever way is helpful to you.

Manfred

Hi @irreleph4nt,

did you to configure another carddav client except evolution? Maybe configure a carddav account on your mobile device? So that we have a better idea if editing contacts fails in kdav or if it’s related to evolution only.

Manfred

irreleph4nt

@Manfred

Hi,
the blow is the kdav log for when I am trying to set up CardDav-Sync Free on Android, connect it to Kdav and try creating a user. My phone reports a ~~success~~ failure but the new contact does not show up in Kopano (tested in Webapp and Evolution) and the end of the log clearly shows the same stop behavior as the previous attempts with Evolution.

Phone log:

java.lang.Exception: could not upload new resource
org.dmfs.j.a.a(Unknown Source:280)
org.dmfs.j.b.a(Unknown Source:27)
org.dmfs.g.g.a(Unknown Source:9)
org.dmfs.carddav.syncadapter.a.a(Unknown Source:1594)
org.dmfs.h.a.onPerformSync(Unknown Source:989)
android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:334)
caused by:
java.io.IOException: Error 504 during upload of 
BEGIN:VCARD
VERSION:3.0
N:Georgi;Hans Peter;;;
FN:Hans Peter Georgi
PRODID:-//dmfs.org//mimedir.vcard//EN
REV:20190925T002254Z
UID:290d8a4b-922c-43c5-8192-1bd65b51c90e
END:VCARD

org.dmfs.dav.b.a(Unknown Source:180)
org.dmfs.dav.b.a(Unknown Source:2)
org.dmfs.j.a.a(Unknown Source:147)
org.dmfs.j.b.a(Unknown Source:27)
org.dmfs.g.g.a(Unknown Source:9)
org.dmfs.carddav.syncadapter.a.a(Unknown Source:1594)
org.dmfs.h.a.onPerformSync(Unknown Source:989)
android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:334)

App: org.dmfs.carddav.sync
App version: 0.4.21
OS version: 28
OS Info: google/walleye/walleye:9/PQ3A.190801.002/5670241:user/release-keys
Manufacturer: Google
Date: Wed Sep 25 02:23:54 GMT+02:00 2019

Manfred

Hi @irreleph4nt,

could please test the following: download the files attached to the issue https://jira.kopano.io/projects/KDAV/issues/KDAV-20. Edit $user and $pass of kdav-20.php to match a user on your system (also check if $server and $path are correct for your system).

Then run:

php kdav-20.php -f kdav20fail
php kdav-20 php -f kdav20ok

and post the output.

Manfred

irreleph4nt

@Manfred

Hi. I made the changes and ran the commands as instructed. kdav20fail comes back with an error message right away, kdav20ok however hangs infinitely:

[root@mx2 kopano-kdav]# su nginx -s /bin/bash
bash-4.2$ php kdav
kdav20fail   kdav20ok     kdav-20.php  
bash-4.2$ php kdav-20.php -f kdav20fail 
mapi_vcftomapi failed with code: 0xFFFFFFFF8004011B
bash-4.2$ php kdav-20.php -f kdav20ok

Last line is where I am not even getting a cursor back unless I ctrl+c.

Interestingly I see this in the journal throughout the period of time I left the kdav20ok command running as the nginx user:

Sep 25 23:50:47 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="User supplied password" program="php" sid=0x7cb3b803b8f7e0d9
Sep 25 23:50:47 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="User supplied password" program="php" sid=0xa75fe1fcc49d8abd
Sep 25 23:50:55 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="User supplied password" program="php" sid=0xd61a953a3477a7b2
Sep 25 23:50:55 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="User supplied password" program="php" sid=0xa8306aece582626

vs output when running as root:

Sep 25 23:55:06 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="Pipe socket" program="php" sid=0xdd18f36cd65a9b0d
Sep 25 23:55:06 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="Pipe socket" program="php" sid=0x27afd5701a189b31
Sep 25 23:55:11 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="Pipe socket" program="php" sid=0xd25bbea952b2965a
Sep 25 23:55:11 mx2.domain.tld kopano-server[20172]: authenticate ok: from="file:///var/run/kopano/server.sock" user="robert" method="Pipe socket" program="php" sid=0x26ca7c927b1badfb

I am not getting any output in the kdav logs when running these two tests.

irreleph4nt

@Manfred
Have you had any luck tracing down the source for this issue?

Manfred

Hi @irreleph4nt,

I suspect that there’s something wrong with mapi_vcftomapi on your system because php kdav-20.php -f kdav20ok doesn’t output anything. That would be something for someone from Kopano core team to look at, I’m not able to help you with that.

Manfred

irreleph4nt

@Manfred
Hi. Thank you for all you have done so far! Is there any way you could let the relevant people know that this issue exists? Maybe raise a JIRA ticket or something? I’d be happy to provide any kind of data or access that you guys require. :)

Manfred

Hi @irreleph4nt,

there already is https://jira.kopano.io/browse/KC-1529 which is related to creating contacts in with mapi_vcftomapi via kdav. It’s possible that your issue and the one described there are related.

Manfred

irreleph4nt

@Manfred
Just commenting to let you know this error still exists in 8.7.84 on CentOS 8. The same behaviour as previously observed.