I have a site www.xforty.com. I have the aliases www-xforty-com.aegir.xforty.com. I cloned it to clone.xforty.com. And it didn't create cline-xforty-com.aegir.xforty.com.

Note from the Aegir maintainers:

This issue overlaps with:

CommentFileSizeAuthor
#32 patch_commit_32fb8e18e38c.patch7.37 KBomega8cc
#31 broken-hostmaster-upgrade.txt120.88 KBomega8cc
#29 patch_commit_8837f9195bae.patch7.07 KBomega8cc
#28 patch_commit_5721cb31550d.patch5.3 KBomega8cc
#27 patch_commit_594841579f45.patch4.63 KBomega8cc
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Title: Cloning a site with site aliases turned on doesn't create the helper aliases » Clone and Migrate form should (again) provide Aliases textfield when Aliases is enabled

It doesn't automagically know what aliases you want.

However - we used to at least give you the Aliases textfield in the clone form if the Aliases feature was turned on. It appears that was ripped out:

http://git.aegirproject.org/?p=hostmaster.git;a=commitdiff;h=ef8bf18eac8...
http://git.aegirproject.org/?p=provision.git;a=commitdiff;h=6cd2e2d3b9a4...

...around when the Rename task got removed.

I'm going to hijack this ticket and make it about restoring the ability to set aliases on clone and migrate (now that we change the main site name too in these forms), but it's never going to automatically presume what aliases you want.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The work I've been doing here is in the branch 'dev-migrate_aliases' in both provision and hostmaster.

http://git.aegirproject.org/?p=hostmaster.git;a=shortlog;h=refs/heads/de...
http://git.aegirproject.org/?p=provision.git;a=shortlog;h=refs/heads/dev...

todo: for some reason the aliases() array is not being set in the drush alias file or the drushrc.php of the site. Everything else works (i.e actually saving the aliases etc!)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Almost there,

The one lingering problem is that in hosting_migrate_form_validate(), we check that no other site is using the alias (if it changes).

The problem is that Clone now inherits hosting_migrate_form_validate(), and so it does its alias check based against the current $node. If you *don't* change the alias, it allows that, because the node is still currently the first site, and that first site is allowed to use that alias.

(Edit: this is why I liked the separate Rename feature: now that migrate can change all sorts of stuff like URL, alias, db server, it becomes somewhat impossible to distinguish the nuances of clone from migrate in the form (And there *are* differences))

whine:end :)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Active » Needs review

I seem to have been able to do a validation of the aliases in the clone validate hook (despite it being basically duplication, but not quite).

So, :

On Migrate: check the aliases specified, and except if they are in use on other sites. If they are already in use on the current site, that is ok

On Clone: check the aliases specified and except if they are in use on any other sites, period.

I think this is ready for testing by others now.

pearcec’s picture

pearcec CreditAttribution: pearcec commented

My original comment was for the sitewide aliases.

Hosting -> Site aliases
Domain used for automatic subdomain hosting:
aegir.xforty.com

What I did notice is that if I clone a site and then verify it, then the sitewide aliases do get put in. Should we trigger a verify after a clone?

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

We do in fact trigger a verify after clone, but this is done sort of 'silently' and in the 'backend' only.

The difference is that in the past, we used to explicitly trigger a 'frontend' verify after import, so no-one probably ever noticed this before.

We need to decide whether:

1) We can somehow fix it so that the automatic aliases are detected properly on clone and just handled in the first place, or
2) We should invoke a hosting_task('verify') as opposed to a provision_backend_invoke('verify') which won't detect those settings from the frontend.

Ideally 1) is better, struggling to figure out how to do it though

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs review » Needs work

I think Migrate doesn't move aliases properly still.

And we need to make the automatic aliases work as well, in the backend, without requiring a second verify from the frontend.

Marking as needs work for now.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Title: Clone and Migrate form should (again) provide Aliases textfield when Aliases is enabled » Aliases are not persisted across Migrate, (Rename), Clone (provision-deploy)

Renaming the ticket to what the issue really is about, as others are seeing the same root cause eg #1061896: rename of site results in no domain alias symlinks recreated

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Title: Aliases are not persisted across Migrate, (Rename), Clone (provision-deploy) » Aliases are not persisted across rename and clone

can we be clear that migrate still keeps aliases and it's only rename and clone that are affected here?

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Title: Aliases are not persisted across rename and clone » Aliases are not persisted across Migrate, (Rename), Clone (provision-deploy)
Priority: Normal » Major

I think it deserves "major" status? It is pretty serious issue. Correct me if I'm wrong.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Title: Aliases are not persisted across Migrate, (Rename), Clone (provision-deploy) » Aliases are not persisted across rename and clone

Oops, I didn't intend to revert the issue title change.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I can confirm that the alias of a site is migrated along with a site on Migrate, to the new platform.

So that's good.

What is annoying (but it's not a show-stopper), is that since we blew away the Rename feature, we let a user 'rename' the site in the migrate form because the site URL is an editable field.

But Aliases are no longer injected into the Migrate form, so while we can rename the site, we can't rename any aliases either, which might be wanted.

This issue described above affects Clone in the same way: you clone a site, (and thus *have* to set a new Site URL), but you can't set any aliases for that new clone site at the same time, which sucks. (we used to be able to)

I don't consider this a blocker however.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

This problem already generated enough WTF?! support issues in our (Omega8.cc) support queue. People can't understand why they have to re-verify both the original and cloned/renamed site to get aliases finally moved to the correct vhost file.

Note - it causes *duplicate* aliases in two vhosts, so while it doesn't break the web server config, it results with major WTF?! when the alias in the old vhost takes precedence and server displays *old* site instead of cloned/renamed - this happens often in our environment because people use "dev" aliases to access the site for debugging etc.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Wouldn't a good stopgap measure be to just carry the aliases through as a #value instead of an editable field? Or just *not* change them?

I am just jumping in here sorry...

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Not ideal but working solution could be what mig5 mentioned in #6 above:

2) We should invoke a hosting_task('verify') as opposed to a provision_backend_invoke('verify') which won't detect those settings from the frontend.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

The problem with that is that the site may be broken in the interval between the cron runs.

I am more interested to know where the aliases get dropped by the backend and why.

Basically, I don't understand the blocker at the code level, especially since we're talking about clone and rename interchangebly here... let's focus on rename for now shall we?

anarcat’s picture

anarcat CreditAttribution: anarcat commented

You're going to laugh here, but maybe Eugen has a solution for us here #1067702: During migration provision-deploy and provision-verify lost the context breaking things like provision.api. We selectively pass only certain elements of the old context in provision-migrate, maybe we need to add the aliases in there?

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I think it is worth to try this fix (add the aliases in there).

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

There is no progress here, so I will try what you suggested and will report results.

michaelfavia’s picture

michaelfavia CreditAttribution: michaelfavia commented

Subscribe

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Version: 6.x-0.4-alpha3 » 6.x-1.3

Okay, so this is what I'm seeing with Aegir 1.3:

Site 1 - With an auto-generated alias.

Rename

Results - new site with the alias for the old site. A verify created the correct alias for the new site name.

Clone

Results - old site still has the alias but new site doesn't have any aliases at all.

It's all a bit odd, but would be cleaned up with an additional verify from the frontend in both cases I think, but if we could do it in a different way we should, because verifies are expensive.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Title: Aliases are not persisted across rename and clone » Automatic aliases are not persisted across rename and clone
Version: 6.x-1.3 » 6.x-1.x-dev

Changing the title. This is fairly simple now we know the root issue. We need to get the backend doing the auto generation of the aliases, not the frontend. That way the backend can manipulate the data on clone. Easy.

halcyonCorsair’s picture

halcyonCorsair CreditAttribution: halcyonCorsair commented

Subscribing.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Assigned: Unassigned » Steven Jones

This basically means that I need to write the code for this fix, as basically I'm the only one that understands it at the moment!

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Version: 6.x-1.x-dev » 6.x-2.x-dev

Bumping to 6.x-2.x from where I'll backport the fix.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

The workaround from #15 works great on clone and import but doesn't work on migrate - and migrate+rename done at the same time (so changing domain while migrating between platforms) is heavily broken right now - see related comment: http://drupal.org/node/1067702#comment-5839402

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Project: Hostmaster (Aegir) » Provision
Status: Needs work » Needs review
FileSize
patch_commit_594841579f45.patch4.63 KB

Here is the patch I have tested and it works fine except the issue with Migrate while domain is changed at the same time - see comments and attached tasks logs: http://drupal.org/node/1067702#comment-5839402

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
FileSize
patch_commit_5721cb31550d.patch5.3 KB

Better patch, with the extra and not working site re-verify via frontend on rename commented out for reference attached.

Now all aliases are persistent on clone (both with the same and changed domain) and migrate (only for the same domain - so w/o rename).

Aliases are still messed up when you rename the site (while moving it between platforms or leaving in the same platform).

While it could be better to fix this in the backend without the extra work/steps via frontend, trying to use the frontend method helped to confirm that there is serious problem in the migrate code which breaks things anyway.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
FileSize
patch_commit_8837f9195bae.patch7.07 KB

Attached new patch fixes all issues.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Oh, and since I probably fixed the issue which otherwise looks like an egg/chicken syndrome we can't avoid - Happy Easter to all!

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Needs review » Needs work
FileSize
broken-hostmaster-upgrade.txt120.88 KB

OK, so the extra platforms verify on the fly breaks Hostmaster upgrade/migrate, so we need to exclude Hostmaster platform.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Needs work » Needs review
FileSize
patch_commit_32fb8e18e38c.patch7.37 KB

Fixed patch attached.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Note also that my patch automates all tasks documented as recommended/required in proper workflow: http://cao.aegir.cc/node/44.html

It is recommended to run the Verify task on your entities routinely to keep them in sync with the Aegir database, and to run a Verify of your site, current platform and target platform prior to attempting a Migration or Clone task.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Assigned: Steven Jones » Unassigned
Status: Needs review » Needs work

While the approach is valid, this does mean that you absolutely cannot call provision-migrate without having a frontend hostmaster for it to talk to. This isn't really the way it should work. Sorry. We used to do it exactly this way, but the need for a two-way coupling was eliminated with storing of data in the backend.

The best way to fix this issue is to get the settings passed down to the backend and then let the backend figure out which aliases to create.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Sure, but since this issue is already 15 months old, I prefer to use even dirty workaround than to deal with hundreds of WTF complaints in our support queue, hence the patch - clearly not a fix, rather dirty workaround, until somebody will figure it out how to fix the problem properly.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented
Issue summary: View changes

Updated issue summary.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Issue summary: View changes

We have managed to automate aliases handling, so they are written when and where expected, albeit it is currently a result of insane hacking, and it is fully possible that we are still missing something obvious and just one right line in a right place could make it just work. Instead, it is a result of a bunch of "this must work at last!" desperate tests/attempts. But it works. Here is related issue on GitHub: https://github.com/omega8cc/boa/issues/542

Note that it is added in addition to already used patch from #32 above, so aliases are no longer lost on site rename, there are no duplicates on clone/migrate etc. Still, it is a hack.

helmo’s picture

helmo CreditAttribution: helmo at Initfour websolutions commented
Status: Needs work » Closed (outdated)

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing
this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open,
or better yet, create a new issue referencing this one.