> On Jun 10, 2016, at 4:46 AM, Axel Rau <axel....@chaos1.de> wrote:
>
>
>> Am 08.06.2016 um 02:29 schrieb Andre LaBranche <d...@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>ad...@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:ad...@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_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
