On Tue, 2014-01-14 at 22:43 +0100, Helge Kraak wrote: > Am 14.01.2014 um 15:32 schrieb Patrick Ohly: > > > On Tue, 2014-01-14 at 14:25 +0100, Helge Kraak wrote: > > > When I apply as third command (no addressbook at the end of the > > > command) > > > > > > syncevolution --configure SSLVerifyServer=False > > > --template SyncEvolution_Client --sync-property > > > remoteDeviceId=ST23K3J5I4JX username=admin > > > password=admin --source-property addressbook/uri=addressbook > > > sync=two-way Palm-TH55@webdav > > > > > > the command > > > > > > syncevolution --print-config -q @webdav addressbook > > > > > > RETURNS: > > > > > > "[addressbook] > > > backend = CardDAV > > > database = > > > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ > > > # databaseFormat = > > > databaseUser = admin > > > databasePassword = admin" > > > > When you show the config of addressbook for the Palm-TH55 peer, is > > the > > "sync" property set? In other words, what do you get from: > > syncevolution --print-config -q Palm-TH55@webdav addressbook > > > > > [addressbook] > sync = disabled [...]
> [addressbook] > sync = two-way [...] > > When I now initiate a sync I get: > > > [INFO] syncevo-dbus-server: /org/syncevolution/Server: matched > deviceID PN70M9J5V7JX against config palm-th55@webdav > (/root/.config/syncevolution/webdav/peers/palm-th55) Okay, so it is as I thought - configuring unnecessarily/incorrectly checks the source datatabase again and then fails to set the "sync" property because it believes the source to be unusable. I briefly considered disabling that check, but I think it is necessary: otherwise users choosing a template may end up with a sync config which has more sources enabled than possible in the context. The check has to work, of course. > [INFO] sync: /org/syncevolution/Session/15596840391389733215: > addressbook: started > [INFO] sync: /org/syncevolution/Session/15596840391389733215: adding > "Jasmin Heinrich" > [ERROR] sync: /org/syncevolution/Session/15596840391389733215: error > code from SyncEvolution operation not allowed (remote, status 405): > PUT: bad HTTP status: <status 1.1, code 405, class 4, Method Not > Allowed> So that's another issue to look at. You don't need a SyncML client for it, just use "--import <file> @webdav addressvbook". For debugging purposes, use "SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no loglevel=4 --import ...". That'll show the actual WebDAV commands. The SabreDAV server log may also have additional information. > The output of your suggested command above is (beneath I inserted the > debugging output which I get for the split command version of yours > with which I had come up before): > > > root@srv:~/.config# SYNCEVOLUTION_DEBUG=1 syncevolution --configure > SSLVerifyServer=False --template SyncEvolution_Client > remoteDeviceId=PN70M9J5V7JX username=admin password=admin loglevel=4 > sync=two-way databaseUser=admin databasePassword=admin backend=carddav > database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ > Palm-TH55@webdav addressbook[INFO 00:00:00] addressbook: looking for > databases... > [DEBUG 00:00:00] checking password property 'databasePassword' in > source 'addressbook' of config 'palm-th55@webdav' with user identity > 'admin' > [DEBUG 00:00:00] using username 'admin' from source config for WebDAV, > password was set > [DEBUG 00:00:00] using plain username/password for admin > [DEBUG 00:00:00] addressbook: timout 300s, retry 5s => resending > allowed > HTTP session to https://localhost:443 begins. > [DEBUG 00:00:00] client cert is missing [...] > [DEBUG 00:00:00] > https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/: SSL > verification problem: hostname mismatch, untrusted certificate > [DEBUG 00:00:00] ignoring bad certificate Okay, so SSLVerifyServer=False is working. The URL is the configured one, too. > [DEBUG 00:00:00] read relevant properties > of /sabredav/addressbookserver.php/addressbooks/admin/ This is checking whether that URL actually is a CardDAV address book. > [<?xml version="1.0" encoding="utf-8"?> > <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"; > xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/sabredav/addressbookserver.php/addressbooks/admin/</d:href><d:propstat><d:prop><d:current-user-principal><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:current-user-principal><d:resourcetype><d:collection/></d:resourcetype></d:prop><d:status>HTTP/1.1 > 200 > OK</d:status></d:propstat><d:propstat><d:prop><d:alternate-URI-set/><d:principal-URL/><d:group-member-set/><d:group-membership/><d:displayname/><card:addressbook-home-set/><card:principal-address/><card:addressbook-description/><card:supported-address-data/><card:max-resource-size/></d:prop><d:status>HTTP/1.1 > 404 Not Found</d:status></d:propstat></d:response></d:multistatus> > ] And it turns out it isn't (none of the CardDAV properties are set). It's a normal collection. However, and that is the real problem, SyncEvolution doesn't check the content of the collection. If it did, it would list its content and find the actual address book(s) ("list items in ..."). Instead, the next step then is to check out the principal (= current user) and see where its address books are (addressbook-home-set), but that leads us just back to that same URL. > [DEBUG 00:00:00] read relevant properties > of /sabredav/addressbookserver.php/principals/admin/ [...] > [<?xml version="1.0" encoding="utf-8"?> > <d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns"; > xmlns:card="urn:ietf:params:xml:ns:carddav"><d:response><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href><d:propstat><d:prop><card:addressbook-home-set><d:href>/sabredav/addressbookserver.php/addressbooks/admin/</d:href></card:addressbook-home-set><d:alternate-URI-set><d:href>/sabredav/addressbookserver.php/mailto:[email protected]</d:href></d:alternate-URI-set><d:principal-URL><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:principal-URL><d:group-member-set/><d:group-membership/><d:displayname>Administrator</d:displayname><d:current-user-principal><d:href>/sabredav/addressbookserver.php/principals/admin/</d:href></d:current-user-principal><d:resourcetype><d:principal/></d:resourcetype></d:prop><d:status>HTTP/1.1 > 200 > OK</d:status></d:propstat><d:propstat><d:prop><card:principal-address/><card:addressbook-description/><card:supported-address-data/><card:max-resource-size/></d:prop><d:status>HTTP/1.1 > 404 Not Found</d:status></d:propstat></d:resp onse></d:multistatus> > ] It turns out, we were already looking at the URL under which the address books are to be found. Because we already looked there, SyncEvolution doesn't look again and gives up. Where did the database=https://localhost:443/sabredav/addressbookserver.php/addressbooks/admin/ URL come from? Was it the result of a database discovery done by SyncEvolution? You can do that discovery without any config with: syncevolution --print-databases \ backend=carddav \ syncURL=https://localhost:443/sabredav/ \ username=admin \ password=.... \ SSLVerifyServer=False I expect that to fail, too, but it'll be easier to debug. How comfortable are you using gdb and/or compiling from source? I can't reproduce the problem with DAViCal, but I see a relevant difference (DAViCal doesn't have a separate principal URL, so instead of following that, SyncEvolution lists the content right away). If my hunch is right, then uncommenting the "next.empty()" clause in an if check in src/backends/webdav/WebDAV.cpp should fix it: // finally, recursively descend into collections, // unless we identified it as a result (because those // cannot be recursive) if (/* next.empty() && */ !isResult) { // ^^^^^^^^^^^^^^^^^^ std::string type; if (props) { type = (*props)["DAV::resourcetype"]; } if (type.find("<DAV:collection></DAV:collection>") != type.npos) { -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
