Trouble upgrading from 5.3 to 7.0
bin/calendarserver_upgrade completed without errors. But bin/run -n stalls at 2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old proxies.sqlite file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server.
On Jan 17, 2016, at 12:52 AM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
bin/calendarserver_upgrade
completed without errors. But
bin/run -n
stalls at
2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store
How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old
proxies.sqlite
file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server.
N.B.: The "delegates" and "delegate_groups" tables in postgreSQL both still have zero rows, so none of the delegate data actually got migrated.
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.
On Jan 16, 2016, at 10:52 PM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
bin/calendarserver_upgrade
completed without errors. But
bin/run -n
stalls at
2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store
How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old
proxies.sqlite
file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server.
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
On Jan 20, 2016, at 6:25 PM, Morgen Sagen <sagen@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?
participants (2)
-
Jacques Distler
-
Morgen Sagen