[CalendarServer-users] Trouble upgrading from 5.3 to 7.0

[Jacques Distler]

> 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.

Indeed.

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

Unfortunately, I ran

     bin/calendarserver_upgrade

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


    bin/calendarserver_manage_principals

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

     bin/calendarserver_upgrade

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>