Hey everybody, I've setup calendarserver 3.2 on my debian wheezy using the filesystem as storage. Every time I add a new appointment to my calendar in iCal and give it a Name, after the next sync with the Server it reverts to the old name ("new Event"). It seems like just the second change will be actually changed on the server. Same Behavior when I change the time. And I also need to delete every appointment two times. I attached the access.log file, there you can clearly see that the server gets a GET request right after deletion and I need to delete the appointment a second time. Hope you can help me out Ulrich Fourier
Hi Ulrich, --On January 16, 2015 at 4:46:27 PM +0100 Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
I've setup calendarserver 3.2 on my debian wheezy using the filesystem as storage. Every time I add a new appointment to my calendar in iCal and give it a Name, after the next sync with the Server it reverts to the old name ("new Event"). It seems like just the second change will be actually changed on the server. Same Behavior when I change the time. And I also need to delete every appointment two times. I attached the access.log file, there you can clearly see that the server gets a GET request right after deletion and I need to delete the appointment a second time.
Looks like the client is not handling ETags properly and so gets 412 errors after each change. Can you try this with a more recent version of the client and see if the problem persists? -- Cyrus Daboo
Ok so I tried it with the mac of a colleague who has the Calendar.app 7.0 under Mac OS 10.9.5. The same Problem occured. Is it because I'm using the file system as storage? On 16.01.15 16:50, Cyrus Daboo wrote:
Hi Ulrich,
--On January 16, 2015 at 4:46:27 PM +0100 Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
I've setup calendarserver 3.2 on my debian wheezy using the filesystem as storage. Every time I add a new appointment to my calendar in iCal and give it a Name, after the next sync with the Server it reverts to the old name ("new Event"). It seems like just the second change will be actually changed on the server. Same Behavior when I change the time. And I also need to delete every appointment two times. I attached the access.log file, there you can clearly see that the server gets a GET request right after deletion and I need to delete the appointment a second time.
Looks like the client is not handling ETags properly and so gets 412 errors after each change. Can you try this with a more recent version of the client and see if the problem persists?
Hi Ulrich, --On January 16, 2015 at 5:16:12 PM +0100 Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
Ok so I tried it with the mac of a colleague who has the Calendar.app 7.0 under Mac OS 10.9.5. The same Problem occured. Is it because I'm using the file system as storage?
That is a possibility as we really don't use or test the file system implementation any more (beyond maintaining it solely for the purpose of migrating data to the SQL DB). Still I am a little surprised this is happening as ETag handling is a pretty basic piece of the protocol - but if there is a bug we would likely tell you to upgrade since you have a pretty old server version. If you want to try and debug this further (rather than doing an upgrade) then please try and get HTTP protocol logs of a bunch of requests prior to and after a 412 response. -- Cyrus Daboo
I'm sorry to bring that old topic up, but I didn't have enough time to take on the problem. I had problems installing calendar server by hand, so I would like to stay with the 3.2 version if possible. Is there a changelog somewhere, where I can figure out if it is worth upgrading? But how do I migrate to a SQL DB, solely by adding the DB parameters in my caldavd.plist? I didn't found anything on the Internet regarding the migration. Thanks Ulrich Fourier On 16.01.15 17:30, Cyrus Daboo wrote:
Hi Ulrich,
--On January 16, 2015 at 5:16:12 PM +0100 Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
Ok so I tried it with the mac of a colleague who has the Calendar.app 7.0 under Mac OS 10.9.5. The same Problem occured. Is it because I'm using the file system as storage?
That is a possibility as we really don't use or test the file system implementation any more (beyond maintaining it solely for the purpose of migrating data to the SQL DB).
Still I am a little surprised this is happening as ETag handling is a pretty basic piece of the protocol - but if there is a bug we would likely tell you to upgrade since you have a pretty old server version. If you want to try and debug this further (rather than doing an upgrade) then please try and get HTTP protocol logs of a bunch of requests prior to and after a 412 response.
On Mar 11, 2015, at 6:22 AM, Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
I'm sorry to bring that old topic up, but I didn't have enough time to take on the problem. I had problems installing calendar server by hand, so I would like to stay with the 3.2 version if possible. Is there a changelog somewhere, where I can figure out if it is worth upgrading?
Sorry, there is not. You can browse the SVN history, but that would take a long time. The very highest level features are sometimes included as bullet points in Server.app descriptions, but there’s very little detail there. We should probably start writing release notes...
But how do I migrate to a SQL DB, solely by adding the DB parameters in my caldavd.plist?
In general the way it’s supposed to work is to install a newer version of calendar server such that it can access all your existing data and configs, and then use calendarserver_upgrade to migrate the filesystem data (and also the proxy db, for 6.x) into the database. There are at least two challenges: * Your config file most likely needs to be upgraded, to remove obsolete entries and maybe add new entries when the default values aren’t suitable for you. This is a manual process, and a good reference to look at is twistedcaldav/stdconfig.py for your chosen version - this file contains all the config defaults. Do not edit that file :) * The build and installation itself pretty much never works ‘out of the box’ on any platform (except OS X), because they are all unique snowflakes. This is why people have created CalendarServer packages for linux and freebsd. If I were in your position (and I have been, and this is what I actually did :), I would take the following approach: 1) Figure out how to bring up your current version of calendar server including all your data and config, on another machine. Verify that it works. This will help you identify the most important moving parts. 2) Install your destination version of Calendar Server on another host, and get it working with the default config. Do not proceed until you are satisfied that this installation works. Feel free to run ./test and / or ./testserver from the SVN root to run our bundled tests. 3) Manually upgrade your config file, and try to get your customized config file working as best you can on the test server without actually having your production data on the system yet. 4) Delete the “data” directory on your test host, then copy your production data over to the test host. Snapshot. Now you can begin testing the upgrade process. Once you are able to successfully upgrade and end up with a service that works, you should know all the techniques required to upgrade your production data ‘for real’. The upgrade / import process itself is rather robust and safe once you get off the ground (meaning, a proper installation with all dependencies satisfied). We have pushed a relatively insane amount of data through it, including various kinds of invalid data (which can certainly exist in server versions prior to when we got very strict about what we accept). The hardest part of all this will involve much of the same work as would be required to make a port of CalendarServer. It is usually a complicated process that involves a good amount of “system administration” and software development knowledge. The complexity of the task underscores the importance of having a safe, measured approach to the upgrade. Good luck, -dre
I didn't found anything on the Internet regarding the migration. Thanks Ulrich Fourier
On 16.01.15 17:30, Cyrus Daboo wrote:
Hi Ulrich,
--On January 16, 2015 at 5:16:12 PM +0100 Ulrich Fourier <ulrich.fourier@rockyourlife.de> wrote:
Ok so I tried it with the mac of a colleague who has the Calendar.app 7.0 under Mac OS 10.9.5. The same Problem occured. Is it because I'm using the file system as storage?
That is a possibility as we really don't use or test the file system implementation any more (beyond maintaining it solely for the purpose of migrating data to the SQL DB).
Still I am a little surprised this is happening as ETag handling is a pretty basic piece of the protocol - but if there is a bug we would likely tell you to upgrade since you have a pretty old server version. If you want to try and debug this further (rather than doing an upgrade) then please try and get HTTP protocol logs of a bunch of requests prior to and after a 412 response.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
participants (3)
-
Andre LaBranche
-
Cyrus Daboo
-
Ulrich Fourier