[CalendarServer-users] First request ignored

[Andre LaBranche]

> On Mar 11, 2015, at 6:22 AM, Ulrich Fourier <ulrich.fourier at 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 at 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 at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-users