This bug was originally reported on the community site here:
Hi everyone, I am trying to get AEgir working on my VPS. It runs on Debian 7, AEgir has been installed via auto install (apt-get install aegir2). After install, i patched the RC2 of aegir as stated in the current release notes.
1/ I create new platform, and a new site (example.com) in the platform.
2/ I clone the example.com to example2.com, into the same platform.
If I verify both sites (example.com and example2.com), they both show the same database name.
Is this how it should be? Or am I missing something very obvious?
It seems to cause troubles later on, when I try to migrate the clone (in order to test out new platform). And once that fails, the original copy of the site (its database) is also damaged.
I would imagine that the original and clone are completely separate - as stated in the manual:
"Is there any relationship between the original and cloned site?
Currently there is no real relationship between the original site and any of its clones."
Could someone point me in the right direction please?
Any help is very appreciated.
Martin
I have since replicated it on the latest 6.x-2.x. It seems pretty clear that this is related to #2055949: Migrate drops wrong database when domain name changes. I'm investigating now.
Comment | File | Size | Author |
---|---|---|---|
#3 | provision-reset_context_after_clone-2067603-3a.patch | 631 bytes | ergonlogic |
#3 | provision-do_not_verify_after_clone-2067603-3b.patch | 503 bytes | ergonlogic |
Comments
Comment #1
ergonlogicWhile the vhosts have the proper credentials, the drushrc.php's for the two sites both have the new site's credentials:
$ head ../platforms/drupal-7.23/sites/test0.local/drushrc.php
$ head ../platforms/d1/sites/test1.local/drushrc.php
Below is a task log for a clone task. Note that right at the end, we see:
Note that right at the end, we see:
Comment #2
ergonlogicI think the problem is that we're re-writing the source site's drushrc.php here, and presumably using the new site's credentials to do it:
I'm not sure why we're doing anything with the source site's drushrc.php at this point... The simpler solution is probably to reset the active config to the source site, as we do here in #2055949: Migrate drops wrong database when domain name changes.
Comment #3
ergonlogicFixed in c477816 in the same way as #2055949: Migrate drops wrong database when domain name changes. This is attached as the first patch (3a) too, for those wanting to patch RC2.
However, an alternative solution that also appears to work is just not to trigger a verify on the new site. Maybe there's some reason to do this, but I don't see it at the moment. I'd prefer this approach, since it removes code, but it'll require further testing and feedback from other maintainers. So, I'm leaving this issue as 'needs review'.
Comment #4
ergonlogicDowngrading priority, as this is mostly a coding style/optimization issue now.
Comment #5
anarcat CreditAttribution: anarcat commentedwell, not triggering the verify wouldn't actually fix the problem - it would just delay it, wouldn't it?
but yeah, i have always wondered why the heck we reverify like this, but I am not sure we should drop this during the RC cycle. this should be a separate issue.
Comment #6
anarcat CreditAttribution: anarcat commentedComment #7
ergonlogicIIRC, the (3b) in #3 (not doing the extra verify), actually solved the problem because up to that point everything worked properly. The drushrc.php was properly written, but then got overwritten by the wrong context during the last verify.
See #2088761: Do not verify after clone for the follow-up issue.