[CalendarServer-dev] Migrating from 5.1 to 8.0 --was: Re: Circular reference in 8.0 (cannot import name GroupCacherPollingWork)

[Andre LaBranche]

> On Jun 10, 2016, at 4:46 AM, Axel Rau <Axel.Rau at Chaos1.DE> wrote:
> 
> 
>> Am 08.06.2016 um 02:29 schrieb Andre LaBranche <dre at apple.com>:
>> 
>>> 
>>> After putting the users e-mail address into short-name, everyone can configure his account by e-mail and pw. (-:
>> 
>> Yay!
> 
> I have prepared a README about upgrading from 5.1 to 8.0 for my port users.
> I just wrote down, what I did. Please review and comment.

Hi,

Looks pretty good. Some comments:

guid is optional. If specified, it must be a uuid.
uid can be any valid unicode, and doesn't have to be a uuid. It helps if it's a uuid, but usually only in retrospect ;)

If I define an account like this, with no guid:

<record>
    <uid>admin</uid>
    <short-name>admin</short-name>
    <password>admin</password>
    <full-name>Super User</full-name>
    <email>admin at example.com</email>
</record>

... then view this user's principal page http://whatever/principals/users/admin, I see the following under "Calendar user addresses":

mailto:admin at example.com
urn:x-uid:admin

Notably, there is no CUA in urn:uuid form because this record has no <guid> attribute. CUAs in urn:uuid form must contain uuids, while urn:x-uid doesn't have that restriction. The CUA forms you have in 5.x don't include urn:x-uid, so if you had guid defined in 5.x as something other than a uuid (and possibly also if you DIDN'T have guid defined), there is work to do at upgrade time to fix this.

It is recommended to specify a guid record attribute that contains a UUID.

> Then edit the dump and replace all occurences of [old_uid] by [new_uid]


This step is potentially destructive if not done correctly. I suspect some users might not be aware of the perils of, say, substring-based find/replace when old_uid might exist as a substring of other old_uids. I would recommend at least mentioning this possibility, or maybe even offering a basic but safe find / replace technique for people to use. Be especially mindful of instances of any such strings in icalendar body texts that might need to be replaced, as the line wrapping in there is ... something to be aware of :) It's possible that a formally correct solution would require 'extreme' measures like exporting calendar_object.icalendar_text from the DB separately and using a find / replace tool built around an iCalendar parser, to handle the details of the iCalendar format itself (un-wrapping the lines to get accurate matches and then maybe re-wrapping them to conform to the spec). If it comes to that, pycalendar.utils <http://trac.calendarserver.org/browser/PyCalendar/trunk/src/pycalendar/utils.py> should help.

Along the same lines, the steps as written will have the user edit the backup and then drop the DB from the server, leaving them with (maybe) only one backup that might have been incorrectly edited. Consider adding a suggestion to make a copy of the pg backup before editing it.

(if I seem overly cautious, that may be because freebsd users are not my primary audience in my day job ;)

Also, I note that you are opting to allow the server to upgrade itself instead of requiring manual invocation of calendarserver_upgrade. Is this done to avoid the circular import error?

Thx,
-dre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/calendarserver-dev/attachments/20160610/cea0a13e/attachment.html>