Remote import of sites - does it work?

We will try to review those docs again, but they were written from our working, well tested how-to we have used w/o issues many times. We don't include obvious stuff like chmod for ssh files, since basic sysadmin experience is listed as a requirement on the project page, but we may need to check if all the rest is up to date. The 003 directory is an example (of course).

I experienced the same issues on three instances of octopus/aegir. Here is a more detailed description, and a (dirty) workaround which solved the issue in my case: #1663066: Can't import remote site

@Nebel54 This may happen when you have the Provision extension installed both on the source and target (which is expected when both source and target were installed with BOA). We should probably add it in the docs that you should remove the extension from the source server. We never experienced the issue in our test when using the extension only on the target server.

Thanks for your reply - it's a weird issue.

I did delete the drush-extension on the source-server:
o1@harald:~$ mv .drush/provision/remote_import ~/backup/provision/

and the remote_import function does not show up anymore when doing drush | grep "remote". But the result is the same when I start an import:
Could not find provision alias named: server_localhost

The frontend (hosting_remote_import) isn't enabled either.

Hmm, weird. Thanks for testing. I guess we should try to reproduce this again then.

I am having exactly the same problem on my install. I removed the remote_import beforehand, but has the same problems.

Basically, I setup BOA as explained here http://larsolesen.dk/node/357 --> and then I got the remote server to verify by following http://drupalcode.org/project/barracuda.git/blob/HEAD:/docs/REMOTE.txt and a couple of notes on http://larsolesen.dk/node/358.

I will try to investigate further soon.

@Isolesen: As mentioned in my comment #3, you can apply a workaround until the source of the problem is found:

On Target Server edit:
/data/disk/o1/.drush/provision/remote_import/hostmaster/hostmaster_service.inc

and replace the line 91:

$local_file = d('@hostmaster')->platform->server->backup_path . '/' . basename($remote_backup_file);

with:

$local_file = '/data/disk/o1/backups/' . basename($remote_backup_file);

This works for me.

Confirmed that this manual workaround will resolve the issue.

I had the same error as well going between two BOA-2.0.5 servers. #8 did the trick for me as well.

Yes, it does work. I just tried it again and it works without any code modifications, as long as you really follow the how-to. Note that I have tested it only between two remote instances where both of them use the same Aegir system username (default Octopus o1). And it just works:

And once again, this time step-by-step another site migrated between those remote Octopus instances - no code modified.

The how-to followed:

http://drupalcode.org/project/octopus.git/blob/HEAD:/docs/REMOTE.txt

The code used on the target only:

https://github.com/omega8cc/remote_import/tree/6.x-2.x
https://github.com/omega8cc/hosting_remote_import

Please don't re-open this issue. We have tested it many times already, and as long as your are using BOA stack and you strictly follow the how-to, it just works. We have tested this between a few different servers in the last few months and it always worked, also with BOA-2.0.6-dev. If you are experiencing issues, it is not related to this how-to and properly used modules.

I followed #8 and it saved me so much hassle.

I was pulling my hair out trying to follow the documentation correctly. I do have a different username than the default o1 examples on both hosts but they're identical and I followed instructions line for line carefully with no joy.

After editing the file in #8 it all worked perfectly.
I have to admit this process could do with some work, not a lot but a little bit of massaging would make moving sites from one place to another an absolute breeze. I'd love to see this functionality work out of the box where you can check a box to designate source/target machine without having to go into code and remove drush extensions etc.

It's also a shame you can't bulk migrate all sites from one instance to another, that would be awesome.

Thanks Nebel54 and omega8cc saved so much time, absolutely stoked :)

Personally I believe it is way too complex and, as experience shows, confusing method, even if it just works in all our tests.

I can only guess that some folks don't really follow the screenshots for adding the remote server properly: http://drupalcode.org/project/octopus.git/blob/HEAD:/docs/REMOTE.txt#l109

No idea what else would break things. We simply documented our tested many times workflow and as you can see above, it always works.

We plan to add a command line only utility to make migrations between instances easy.

It will automate all steps from the how-to, but of course will need some configuration, because there will be no fancy web-based lists to choose the site and the target platform etc.

Agreed, though a cl version would be far more flexible with batching multiple sites :)
I'd be happy to test and report usage if you advise when something is in head.

tx again.