3

This is almost comical but I'm stuck at this point. Here's the situation:

current host:  no root access, can really only work in .htaccess
current host:  site to be moved to new host is on a shared IP address
current host:  site has .htaccess redirecting all non-www traffic to www.

new host:  root access, WHM, all the knobs/dials
new host:  mod_userdir is disabled

OK. So, at the current host I can't add an .htaccess redirect like this:

RewriteRule ^(.*)$ http://1.2.3.4/~accountname/$1 [R=301,L]

since mod_userdir is disabled at the new host -- and I'm told that enabling it is not exactly simple. So that IP address and account name will not resolve.

Great - so at the new host let's put the site at a dedicated IP address. Nope,that won't work either because the .htaccess rule that rewrites all traffic to "www." means it will break - you get this:

www.1.2.3.4 -- server DNS address could not be found.

I'm afraid to turn off that "www." rewrite rule because it was put in place years ago and I'm not sure what might break if it's not there.

So at this point I see no way to move this site and have the old site redirect to the new site. I have TTL set very low so I am going to have to count on the global DNS caches refreshing in a reasonable amount of time (I can tolerate 24 hours).

My head hurts. Am I missing anything or should I just go with the game plan to move the site and not even attempt to do the redirect from the old location?

C C
  • 413
  • 4
  • 13
  • 2
    Just switch your DNS and be done with it. If your site is super critical, put up a "we're moving" banner to let folks know that they're on the old site and that they'll be directed to the new site soon. – EEAA Dec 28 '16 at 18:54
  • thanks...I was concluding the same. It's not super-critical...a hobby for me but I do have around 13,000 members so don't want to disappoint anyone. I'm really hoping the DNS sorts out quickly enough... – C C Dec 28 '16 at 18:56
  • 1
    You've learned a tough lesson here: you give up a lot of control when you use a shared web host. I must say though, that you're not exactly off on the right foot with a WHM-encumbered new host. Using a GUI control panel only prevents you from learning the skills you need to negotiate situations like this, and also prevents you from being able to admin the server using well-known and easily supportable means. In fact, WHM/cPanel and the like are so abhorrent that we ban questions about them here. – EEAA Dec 28 '16 at 18:58
  • I appreciate that counsel. However, I'm nearly 60 years old, a full time manager at a large company and aside from an ancient MS in comp sci, largely self-taught in the art of this "web stuff". I run a SUSE Linux server at home and do spend a lot of time in bash...but when you are as old and busy as I am sometimes the GUI is helpful ;-) Also I can get root shell access at new host, so maybe not as constrictive as other WHM hosts... – C C Dec 28 '16 at 19:25
  • I just wanted to warn you, it's a bad hole to fall into and you won't be getting help here with the new server. – EEAA Dec 28 '16 at 19:26
  • And it's not that WHM is restrictive, rather it's that after installing them, they fundamentally chance how the server operates, making traditional administration impossible. – EEAA Dec 28 '16 at 19:27
  • Understood. I can always move later to an unmanged server, or continue with AWS EC2 (where I did actually get my entire site up and running, including a separate database instance...but then chickened out). Thank you again for the warning; very much appreciated. – C C Dec 28 '16 at 19:29

1 Answers1

2

I'm copying this answer from your other question, because it's actually more relevant with your new details. It's entirely doable with just .htaccess on the current host.


My example uses the www subdomain but you can adjust it as needed.

On the new server / website, make sure it can service requests on both www.example.com and a second subdomain of your choosing that won't scare end users. I usually go with www2.example.com.

When you are ready to cut over, change DNS to point to the new IP, then on the old server, reconfigure the site so that it does an HTTP redirect for all requests to www2.example.com. This should not be a permanent (301) redirect, use 302 or 307.

The result is that any clients who get the new DNS entry go to the new server as they should.

Any clients who have a cached entry hit the old server, then get redirected to www2 which always pointed at the new IP so it can't be cached, and then they get the new server.

Some things may complicate this. For SSL, the certificate will need to include the temporary host name. If the site uses cookies, I'm not sure they will still work (or they won't transfer). You'll have to consider all the ways a different name might affect things, though in my experience there won't be a whole lot of people hitting the cached one and they will drop off quickly as long as your TTL is reasonably low.

briantist
  • 2,535
  • 18
  • 34
  • Thank you again - but both SSL and cookies are in play so I have a feeling the user experience might not be exactly what we expect. – C C Dec 28 '16 at 19:26
  • 1
    @CC Everyone will have to log back in to the site after the change, but (if your site doesn't do something completely stupid with the cookies) that should be the worst thing that happens. – Michael Hampton Dec 29 '16 at 00:02