[CalendarServer-users] Trouble upgrading from 5.3 to 7.0

Jacques Distler distler at golem.ph.utexas.edu
Wed Jan 20 18:32:44 PST 2016

> On Jan 20, 2016, at 6:25 PM, Morgen Sagen <sagen at apple.com> wrote:
> The .sqlite file gets removed at the end of migrateDelegatesToStore( ), which implies that method completed without error.
> Are there delegate assignments in proxies.sqlite to begin with?
> Are there still records in your directory service for the delegators and delegates?  (migrateDelegatesToStore( ) will only migrate assignments it can locate directory records for.)
> Speaking of the directory service — which one are you using?  XML or LDAP?  Could be some configuration changes need to be made for the new code.


I am using an XML Directory Service which -- I am pretty sure -- I have migrated to the correct new format.

Unfortunately, I ran


before doing so (which is why the delegate assignments didn't transfer). However, I was able to use


to re-add the delegate assignments and to verify (using both user:short_name and uid) that they were correct.
(I also used psql to check that the delegates table in PostgreSQL was populated with the content I expected*.)

Aside from the delegate assignments, is there anything else that


would have screwed-up if (as happened), I ran it before upgrading the XML Directory Service to the new format?

* Actually, I have a question about this: In the old .sqlite delegation database, there were SEPARATE entries for read and for write delegates.
  In the new Postgres table, calendarserver_manage_principals reports that "0" means "read" and "1" means "read/write". Does this mean that I only need one table row to assign someone read/write access, instead of the previous two rows?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/calendarserver-users/attachments/20160120/85046cb1/attachment.sig>

More information about the calendarserver-users mailing list