In editing a site, when I add to aliases the domain name of the alias of another site, the system responds by telling me that it's already in use and rejects my submission.

... which is fair enough. However, I am in a situation where I have a site (call it Site 1) to be "migrated" from a development server (call it Server A) to a new platform (as Site 2) on another server (call it Server B). Both Site 1 and Site 2 have internal domain names as their primary names, with Site 1 possessing Domain X as an alias for public access. What I want to do is:

  1. Lock down Site 1 (but keep it live and accessible)
  2. Clone Site 1 from Server A to Site 2 on Server B
  3. Check Site 2 and perform extra migration tasks
  4. Change the DNS record for Domain X from Server A to Server B
  5. Archive (and/or delete) Site 1 and unlock Site 2.

And voila! The live site is seamlessly changed to the new server as the new DNS record propagates around the world. But, I am now stuck in step 4 above, where I have no choice but to request a DNS change (from my organization's IT) and hope I catch it in time to remove Domain X from Site 1's aliases and add it to Site 2.

I feel that it would make sense not to force unique site aliases across servers. Would anyone have better ideas about how to manage this scenario? I don't want to have to set up a stub site for users still visiting Domain X on Server A (with a cached DNS record) when it's already pointing to Server B on the nameserver.

Comments

zhangtaihao’s picture

zhangtaihao commented

Anyone? This is getting more and more annoying as the setup either (1) takes a while for switching aliases to take effect or (2) runs into unexpected hiccups if I try to manually maintain a temporary link.

anarcat’s picture

anarcat commented

Yeah, that is certainly a pain to do in Aegir. The solution would involve two things:

1. allow site renames
2. allow migrate/rename/clone to overwrite existing sites, probably by having "parent/child" relationships (see #699920: site relationships)

#2 is an extension of #1, basically. #1 is much simpler because we do not need to store data about sites relationships - just allow the user to change the canonical site name and propagate that in the backend.

Another thing that would be important here would be to *optimize* rename so that it doesn't run "migrate" if it's not crossing platform boundaries, a bit like mv does a cp only if it crosses filesystem boundaries...

Would that resolve the issue for you?

zhangtaihao’s picture

zhangtaihao commented

Unfortunately, no. Both solutions sound fine initially, but they assume that the transition from Site 1 being migrated/cloned to Site 2 and Site 2 going live is seamless. In fact, there can be quite a bit of preparation required before Site 2 can be made live. As it happens, many of our site builders may not be particularly aware of the significance of some forms of URLs, among other issues that prevent scripted migration. So, the step 3 I mentioned above is actually a manual, asynchronous task. Only when I, as the platform maintainer, have assured the quality of the migration can I request the DNS change. EDIT: In short, there doesn't seem to be any way around the necessity of having both sites running during transition.

At the moment, what I've done to minimize downtime is to remove the alias from the old site and added it to the new one. While the tasks are queued, I prepare myself to quickly fix the old vhost config and re-link the site folder. The moment the tasks are completed, I perform those changes and restart the server, and voila! I have both sites listening to the same public domain. After the DNS change is made and some time is allowed for it to propagate, I shutdown the old site.

P.S. As a matter of fact, for renaming a site I have used migrate.

Robin Millette’s picture

Robin Millette commented

subbing

Paul Simard’s picture

Paul Simard commented

As an added suggestion in this vein, Aegir appears to be nearly complete in terms of a Site Builder/Developer site manager solution, as is. The platform I envision here is a 'local' Aegir installation managed by the builder/developer, where three versions of a site are maintained, a Dev site, a Staging site, and a Production site.

Aegir can pull from the Production site, and install it into the Dev site. Builder/developer makes changes and pushes site to the Staging server for testing. When testing and changes are complete, Aegir can push the Staging version to the live site. About the only major consideration I see ATM is avoiding the over-writing of user and existing content, but that might be managed using customized migration profiles to avoid over-writing specific database tables/columns during the migration.

Just my $0.02,

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
commented
Version: 6.x-1.1 » 6.x-2.0
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

Please confirm whether this is still an issue in Aegir 2.0+.

helmo’s picture

helmo commented
Status: Postponed (maintainer needs more info) » 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.