- Create a new subdomain and website on the staging server, with client cert auth.
- Directory root should be group-writeable like the others. We'll unpack a tarball there and do some other crazy stuff.
- Needs a new clone of the database. Since we'll be running the database migration repeatedly, it should be easy to reload the 4.2 db. Ops-less reload of the database would be a bonus.
@Jeff_Green: Turns out we need to drop a bunch of tables before restarting the upgrade, do you know of a convenient way to do that?
* ERROR DEBUGINFO: RENAME TABLE `civicrm_contribution_type` TO `civicrm_financial_type` [nativecode=1050 ** Table 'civicrm_financial_type' al ready exists] #0 [internal function](): CRM_Core_Error::exceptionHandler(Object(DB_Error))
@Jgreen, what do you think about mysqldbcopy? There's even a --multiprocess flag for two-handed forkbombing... The db restore currently takes about 4 hours, which isn't exactly an inconvenience yet, but long enough that I'm interested in making improvements ahead of the next time we need to test an upgrade. Looks like the mysql-utils package gets much better performance with version 1.3.6, which might be ported by the time we do another Civi leap.
Random note to self: Put the staging site into maintenance mode, cd $CRM/drupal && drush vset maintenance_mode 1