[CalendarServer-users] Trouble upgrading from 5.3 to 7.0
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...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the calendarserver-users