TL/DR: by design, Aegir's remote server verification procedure breaks remote Aegir configuration and all sites hosted on the remote Aegir.
* * *
A critical documentation issue, huh? Read on.
I have two independed Aegir installations on different servers: Aegir #1 and Aegir #2. Both are clean vanilla Aegir v.1.9 environments installed from Debian packages, they did not suffer any messy things like upgrades or recoveries.
The hosting_remote_import says:
Usage
-----You'll need to add the remote Aegir server as any other server in the frontend
So i configured Aegir #2 MySQL server to be accessible from the web, then i opened the Aegir #1 web interface and created a new server, fill in the Aegir #2 properties.
When i clicked "Save", Aegir #1 verified the Aegir #2 server. During the verification, Aegir #1 overwrote the /var/aegir/config/apache.conf symbolic link file on the Aegir #2 filesystem.
Originally, the symlink had pointed at /var/aegir/config/server_master/apache.conf.
After the verification, it started pointing at /var/aegir/config/server_linlolmaus/apache.conf.
In the course of server verification Aegir #1 also restarted Apache on Aegir #2.
Carefully following README.txt resulted in breaking all sites on Aegir #2, including the Aegir web interface.
I was lucky to realize that it was only the symlink and quickly recovered Aegir #2 (which is my production hosting!).
I suppose that this is normal Aegir behavior. Aegir is not designed to manage another Aegir environment. To be able to leverage a remote server, Aegir the remote /var/aegir folder and database.
I don't even know whether this is only a documentation issue of hosting_remote_import or the whole concept of Aegir-to-Aegir imports via Aegir remote servers is faulty.
Comments
Comment #1
lolmaus commentedOkay, ergonlogic made it clear for me that hosting_remote_import works flawlessly on Aegir v.2.0 and/or BOA, so it's certainly not a hosting_remote_import design flaw.
Ergonlogic also suggested that i shouldn't have enabled the web server and mysql options when adding a remote server to Aegir #1. This may be the point.
It is critical to modify hosting_remote_import documentation to explicitly warn against either enabling the webserver and mysql options or using the module on Aegir 1.9 at all.
Comment #2
lolmaus commentedComment #3
ergonlogicComment #4
lolmaus commentedCan you please comment on resolving this one? It had caused a lot of trouble for me.
Comment #5
ergonlogicIn the README, I added that one should only enable the remote import service. I also pointed more specifically to the ssh setup steps in our wiki.
I'm looking into how we might add a warning to the UI, but I haven't found anything obvious yet.
Comment #6
lolmaus commentedThank you ergonlogic, you're awesome!
Comment #8
Anonymous (not verified) commentedHello,
I am getting a can't connect to database error after following ALL the boa 2.1.3 instructions. Does the database 'SeCrEt' need to be an existing MySQL password or is any new password OK? This refers to this point in this how-to: (http://drupalcode.org/project/barracuda.git/blob/HEAD:/docs/REMOTE.txt):
77 ### On source server - as root
78 $ mysql
79 mysql> GRANT ALL PRIVILEGES ON *.* TO o1@target-ip IDENTIFIED BY 'SeCrEt' WITH GRANT OPTION;
80 mysql> GRANT ALL PRIVILEGES ON *.* TO o1@target-host IDENTIFIED BY 'SeCrEt' WITH GRANT OPTION;
81 mysql> FLUSH PRIVILEGES;
82 mysql> exit
Whatever I do I can't get it to work. This is from one boa 2.1.3 o1 instance to another boa 2.1.3 o1 instance on a different server.
Comment #9
Anonymous (not verified) commentedFYI the referenced BOA instructions still instruct to activate both the hostmaster import and the database import. Has this changed?
Comment #10
Anonymous (not verified) commentedWell I tried it anyways, just modifying the remote import server so that it did NOT include the MySQL server (just the hostmaster), and it appears to be working, so the instructions and screenshots should be updated, if this is correct.