action #46121
closedCalDAV to CalDAV synchronization (Server to Server)
Description
We should evaluate if it is possible to integrate a CalDAV to CalDAV synchronization tool into the invis-Server.
Background: With Kopano or other groupware systems we have a CalDAV Server inside invis-Server. A lot of our (FSP) customers use additional business-software systems which also ships calendar and scheduling components inside. Some of them are CalDAV servers.
For our customers it's difficult to decide which system they should use. Having the possibility to synchronize these systems could be a cool and extremely useful feature.
Updated by flacco over 5 years ago
- Status changed from New to In Progress
vdirsyncer is a possible software to do the job: https://github.com/pimutils/vdirsyncer
Updated by flacco over 5 years ago
- % Done changed from 0 to 10
vdirsyncer is shipped by leap 15: https://build.opensuse.org/package/show/openSUSE:Leap:15.0/python-vdirsyncer
Updated by flacco about 5 years ago
leap 15 contains the packages python3-vdirsyncer and python2-vdirsyncer. We should test with the p3 version.
Updated by flacco about 5 years ago
- Status changed from In Progress to Feedback
vdirsyncer needs one config-file per sync job.
Its possible to sync CalDAV to CalDAV, CardDAV to CardDAV, CalDAV to ics-Files and CardDAV to vcf-Files.
Should we place the config files at a central place or inside the users home-dirs?
Updated by ingogoeppert about 5 years ago
What is in the config-files? If a user needs to store his password there, I think it should be in his home.
Updated by flacco about 5 years ago
ACK. Good argument.
Yes the passwords will be stored inside the config files:
https://vdirsyncer.pimutils.org/en/stable/tutorial.html#configuration
Updated by flacco about 5 years ago
- % Done changed from 10 to 20
First Testresults:
Synchronization from owncloud to kopano: works
Synchronization from kopano to owncloud: fails
owncloud answers with: "415 Client Error: Unsupported Media Type for url"
The reason could be that the exported ics-files from kopano contains DOS-linebreaks. :(
Updated by flacco about 5 years ago
I created a vdirsyncer bugreport at github:
Updated by flacco about 5 years ago
- Status changed from Feedback to In Progress
Updated by flacco almost 5 years ago
- Assignee set to ingogoeppert
Help needed!!
I've tried to build python-vdirsyncer in the new testing repo "spins:invis:15:testing:python" as a branch from "devel:languages:python:python-vdirsyncer". For dependency-reasons I had to build some other python packages there. Building packages which have a "%check" Section with the "%pytest" macro inside fails always for leap 15.0. No problems with building for tumbleweed.
To build the packages, I've disabled the "%check" section inside the spec-files. Not a goog way to solve this problems.
Updated by ingogoeppert almost 5 years ago
- Assignee changed from ingogoeppert to flacco
The problem is: The %pytest macro is undefined in the old python-rpm-macros-package used in leap.
Now you can:
- Do not run tests or
- Run the test command directly without the macro
- Use the latest python-rpm-macros which includes the macro
Updated by flacco almost 5 years ago
OK, after new "fails" with the latest python-rpm-macros, I took option 1.
Updated by flacco almost 5 years ago
- % Done changed from 20 to 30
Kopano-ical in Version 8.7.1 blocks every login with error 401, so I decided to install the new SabreDAV based Kopano-CalDAV implementation Kdav. Login works well, but synchronization fails again:
Synchronization from owncloud to kopano: works
Synchronization from kopano to owncloud: fails
Error: "A calendar object on a CalDAV server MUST NOT have a METHOD property". This problem is discussed here: https://github.com/pimutils/vdirsyncer/issues/502
This is a little bit strange because, both CalDAV implementations (ownCloud and Kopano) are now based on SabreDAV. That could mean, that one of them breaks the CalDAV Standard. It seems that Kopano is the bad guy. They put the Method-Property in their ics-Exports and the use DOS-Linebreaks.
RFC 4791 "Calendaring Extensions to WebDAV (CalDAV)" says:
"Calendar object resources contained in calendar collections MUST NOT
specify the iCalendar METHOD property."
"MUST NOT" in German is: "DARF NICHT"
Updated by flacco almost 5 years ago
Oops, I found another possible Reason for this:
"You might be running ownCloud behind a reverse proxy; in that case you should ensure that your proxy is configured to pass WebDAV queries. See this forum thread for the case of the Pound reverse proxy: https://forum.owncloud.org/viewtopic.php?t=4949 223"
I've to check this, because the ownCloud server I used for my tests is running behind a reverse-proxy.
Updated by flacco almost 5 years ago
OK a local synchronization between ownCloud and Kopano on an invis-Server fails with Error: "A calendar object on a CalDAV server MUST NOT have a METHOD property" too. And again the direction Kopano to ownCloud fails.
Updated by flacco almost 5 years ago
The problem seems much more complicated:
https://sourceforge.net/p/davmail/bugs/628/
Perhaps it's located more on the ownCloud-side...
Updated by flacco over 3 years ago
Ich wechsle mal ins Deutsche:
CalDAV ist ein offener Standard mit recht weiter Verbreitung. Leider werden beim Implementieren von CalDAV in verschiedenster Software versehentlich oder gar absichtlich Fehler gemacht. Fehler die letztlich dazu führen, dass die verschiedenen CalDAV-Implementationen miteinander nicht kompatibel sind. In der Praxis hat das Folgen. So ist beispielsweise Kopano (damals noch Zarafa) von der Absicht eine standardkonforme CalDAV-Implementation zu entwickeln abgerückt und versucht nun mit Kopano-ICAL lediglich die für Kopano wichtigsten CalDAV-Clients Thunderbird und verschiedene Apple-Apps zu bedienen.
Die Entwicklung des von mir hier zur Umsetzung meiner Idee verwendete Tool vdirsyncer wurde zwischenzeitlich mit ordentlich Frust eingestellt. Entsprechend frustriert hatte ich vor auch meine Bestrebung eine CalDAV zu CalDAV Synchronisation im invis-Server zu entwickeln abzubrechen.
Stand heute habe ich allerdings gesehen, dass vdirsyncer auf Github weiterhin rege Unterstützung erfährt. Daher lasse ich das Ticket offen, würde mich über Unterstützung freuen setze aber kein Abschlussdatum für die "Fertigstellung". Sehen wir es als spannendes Hobby--Projekt an.