Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I can't seem to import a remote site. The 'importing a site' wizard seems to work fine, retrieving a listing of remote sites, and prompting for the local platform on which to import the site. However, the 'Import remote site' task itself fails. I've included the entire task log below. I don't really know where to start debugging this. Any help is greatly appreciated.
Log message
Task starts processing
Running: /usr/share/drush/drush.php @server_prodo8local provision-remote_import --backend 2>&1
The external command could not be executed due to an application error.
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Load alias @server_prodo8local
Bootstrap to phase 0.
Found command: provision-remote_import (commandfile=remote_import)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @server_master
Loading apache driver for the http service
Loading hostmaster driver for the remote_import service
Initializing drush commandfile: user
Running: ssh -o PasswordAuthentication=no 'aegir'@'prod.o8.local' 'drush @test.o8.local '\''provision-backup'\'' --backend 2>&1' 2>&1
Bootstrap to phase 0.
Drush bootstrap phase : _drush_bootstrap_drush()
Load alias @test.o8.local
Loading drushrc "/var/aegir/platforms/drupal-7.14/sites/test.o8.local/drushrc.php" into "site" scope.
Bootstrap to phase 1.
Drush bootstrap phase : _drush_bootstrap_drupal_root()
Loading drushrc "/var/aegir/platforms/drupal-7.14/drushrc.php" into "drupal" scope.
Initialized Drupal 7.14 root directory at /var/aegir/platforms/drupal-7.14
Found command: provision-backup (commandfile=provision)
Initializing drush commandfile: drush_make
Initializing drush commandfile: drush_make_d_o
Initializing drush commandfile: provision
Load alias @server_localhost
Load alias @server_master
Loading apache driver for the http service
Loading mysql driver for the db service
Load alias @platform_drupal714
Initializing drush commandfile: user
Including /usr/share/drush/commands/provision/db/backup.provision.inc
Including /usr/share/drush/commands/provision/platform/backup.provision.inc
Drush bootstrap phase : _drush_bootstrap_drupal_site()
Initialized Drupal site test.o8.local at sites/test.o8.local
Loading drushrc "/var/aegir/platforms/drupal-7.14/sites/test.o8.local/drushrc.php" into "site" scope.
Drush bootstrap phase : _drush_bootstrap_drupal_configuration()
Adding sites directory to /var/aegir/backups/test.o8.local-20120627.163044.tar.gz
Temporarily uncloaking database credentials for backup
Template loaded: /usr/share/drush/commands/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to 440
Change group ownership of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to www-data
Re-cloaking database credentials after backup
Template loaded: /usr/share/drush/commands/provision/platform/provision_drupal_settings.tpl.php
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to 640
Generated config Drupal settings.php file
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to 440
Change group ownership of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/settings.php to www-data
Deleted mysql dump from sites directory
Backed up site up to /var/aegir/backups/test.o8.local-20120627.163044.tar.gz.
Client backup directory for admin path /var/aegir/clients/admin/backups exists.
Client backup directory for admin ownership of /var/aegir/clients/admin/backups has been changed to aegir.
Client backup directory for admin permissions of /var/aegir/clients/admin/backups have been changed to 750.
Client backup directory for admin path /var/aegir/clients/admin/backups is writable.
Created symlink /var/aegir/clients/admin/backups/test.o8.local-20120627.163044.tar.gz to /var/aegir/backups/test.o8.local-20120627.163044.tar.gz
Template loaded: /usr/share/drush/commands/provision/provision_drushrc_site.tpl.php
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/drushrc.php to 640
Generated config Site Drush configuration file
Changed permissions of /var/aegir/platforms/drupal-7.14/sites/test.o8.local/drushrc.php to 440
Command dispatch complete
Peak memory usage was 14.09 MB
Load alias @hostmaster
Loading drushrc "/var/aegir/hostmaster-6.x-1.9/sites/dev.o8.local/drushrc.php" into "site" scope.
Could not find provision alias named: server_localhost
Trying to get property of non-object db.drush.inc:45
Could not find provision alias named: platform_drupal714
Drush command terminated abnormally due to an unrecoverable error. Error: Call to a member function get_services() on a non-object in /usr/share/drush/commands/provision/provision.context.inc, line 395
Output from failed command : Fatal error: Call to a member function get_services() on a non-object in /usr/share/drush/commands/provision/provision.context.inc on line 395
Command dispatch complete
Peak memory usage was 26.41 MB
Comment | File | Size | Author |
---|---|---|---|
#11 | hardcode_backup_path.patch | 784 bytes | ergonlogic |
Comments
Comment #1
ergonlogicI believe this is the line that's failing for me: http://drupalcode.org/project/remote_import.git/blob/refs/heads/6.x-1.x:...
Comment #2
ergonlogicIn fact, just loading the @hostmaster context causes this failure:
Comment #3
ergonlogicA bit more debugging:
In provision_context_factory(), called for "@hostmaster", drush_get_context('stdin') returns:
... but re-writing platform & db_server to add '@' doesn't appear to help any. :-/
Comment #4
ergonlogicWhile not fixing the underlying problem, a working solution (for a standard Aegir setup, at least) is to just hardcode the backup directory:
It now imports the site successfully, though it still throws some (apparently harmless) warnings towards the bottom:
Comment #5
ergonlogicAnarcat and I worked on debugging this, and while we think we've discovered the cause of the problem, we haven't yet found a proper solution. It appears that when Aegir prepares to deploy the backed-up site, that it inherits the remote @hostmaster context. We renamed the importer's server_localhost server (with all the manual edits that entails), and saw that it continued to try and load that alias.
Since we've begun to deploy this on Koumbit's AegirVPSs I started a sandbox project to host the work-around fix mentioned in the previous comment.
Comment #6
omega8cc CreditAttribution: omega8cc commentedMake sure that you have
remote_import
extension only on the target server, or weird things will happen if you have it on both source and target.Comment #7
lsolesen CreditAttribution: lsolesen commentedRelated to #1594588: Remote import of sites - does it work?
Comment #8
cafuego CreditAttribution: cafuego commentedI'm hitting the same problem on a local-only installation, when attempting to migrate a site from D6 to D7.
Comment #9
cafuego CreditAttribution: cafuego commentedSo in my case this seems to have been caused by my typoing the platform alias. Perhaps an early check to validate aliases would be a good thing to have ;-)
Comment #10
omega8cc CreditAttribution: omega8cc commentedFYI: http://drupal.org/node/1594588#comment-7160544
Comment #11
ergonlogicI just tested this on a stock Aegir 1.9 server, installed from the .debs, and with remote_import only on the target server. The same issue occurs.
I've attached a patch that hardcodes the backup path, as described in #4. Obviously this isn't a permanent solution, but at least this'll get it working.
Comment #12
ergonlogicI wonder if d('@hostmaster') isn't hitting a cached value from provision_sitealias_get_record(), or maybe just $instances directly in d(). Perhaps we need to add an $invalidate_cache parameter?
Comment #13
ergonlogicThis appears to work in 6.x-2.x. The patch in #11 will have to suffice for 6.x-1.x.