Server Moves
From DreamHost
You're probably here because you recently received an email either letting you know your account will be moved shortly or that it has already been moved. Please READ THIS PAGE FULLY before contacting support about any move related issues, as the issue you're experiencing is likely covered here already (if not, let us know so that we can add it!).
Here we’ll tell you:
- a little about why these moves are necessary
- what to do to prepare yourself for the move
- what could possibly go wrong,
- what to do if (horrors!) something does go wrong!
Contents
|
Why do servers change?
“Why must servers change??” you may implore.
Lotta reasons. Hosting is a complex business, much as the Happy DreamHost Wizards make it seem easy, and sometimes, DreamHost’s relationship with some of its servers just isn’t working out, and it’s time to kick them to the curb.
Usually, servers are changed to make things better – you know, swifter, higher, stronger, or in DH speak, beefier, cheaper, greener.
For example, in 2008 the geniuses at DH HQ actually looked at the power bill and realized that if we were to upgrade all our old web and file servers onto new hardware (the stuff we’ve been using since May), we could probably cut our data center power usage about 50%, leave more left over for those USB Christmas Trees that we all love.
Other than the fact that it will save energy, the new set up should also:
- Be more stable… we’re phasing out shared file servers (filers) because they were just too big a point of failure.
- Be higher performing… the new servers are on average 4x “beefier”, but we’re putting less than 4x the number of customers on them.
- Get new features (such as Trac) that aren't available on the old server configuration.
- Save us money… not just on data center costs, but also on our green energy credits, and management costs too (there will be less overall servers to manage).
What changes?
Here is some information about what changes on the backend after the move.
Server name
If you always refer to DreamHost servers by yourdomainname.com or the like, you don’t care what the server is actually called. Like I call my dog “dog”. Doesn’t matter if I get a new dog, or gremlins replace her at night, she’s still “dog”. Saves having to remember names.
If, on the other hand (“au contraire” to you francophones), you refer to servers by names like “spunky.dreamhost.com” or “sektor.dreamhost.com”, you will need to change these when servers move.
To find out your server name, go to the panel, and click on “Account Status” in the upper right corner. It’ll also tell you your server names. Pretty cool, eh?
Server software
Our new server clusters are running a more recent version of both Debian and Apache. It is also being transitioned from a 32bit server to a 64bit one. If you don't know what this means, it probably won't cause any issues with your services. If you’re doing anything fancy that relies on software that’s changed (such as custom PHP), you may need to get with the times and upgrade your site software.
Server hardware
This shouldn’t cause problems for you unless you’re super-elite.
For such super-elite folk, I say: I dunno, this shouldn’t cause too many wrinkles, but maybe they’ll replace the old VAX machines with one of those new-fangled Intel things someday, and then your assembly code will break.
Preparing for the move
What you should check on
Below are some things you should check prior to the move to insure that things go as smoothly as possible:
- use your own domain name
- Make sure you ftp/ssh/whatever to your own domain name (example: yourcooldomain.com) and not SERVER.dreamhost.com. If you use your own domain, you don’t need to care about which excellent DreamHost server is actually doing the work.
- remove .dataglob from script paths
- Make sure you don’t have a .dataglob in any paths for any configuration files for any software you have! That is, if you see something like “/home/.blahblah/username” in a configuration file for something you’ve installed on your website (even one-clicks from our panel!), change it to “/home/username” immediately! We’re going to try and automatically find and replace those for people as they’re moved, but it’d be best if they weren’t there at all!
- Custom DNS settings
- If you aren't using our nameservers (ns1.dreamhost.com, ns2.dreamhost.com, ns3.dreamhost.com) to point your domain to us and are manually configuring your DNS outside of our system, your IP address will change!. This means that your site will remain pointing at the old server unless you update the settings and will stop working shortly after the move. Follow the instructions below on the best way to handle your Custom DNS setup.
- Custom PHP (or php.ini)
- If you have setup custom PHP or a php.ini file, it will probabaly break after the move. This is because your site was likely on our older 32bit servers and the ones in our new cluster are 64bit! Unfortunately, this isn't something we can help you troubleshoot, but you'll just need to rebuild your custom php (or php.ini) again. Check Our Wiki for more information on how to recompile that.
- Custom procmail changes
- If you are using an email .procmail (filtering) or .forward (forwarding) file to use custom filtering it will no longer work unless some changes are made. This is because the mailbox is no longer associated with your shell user and it handled by its own mailbox only login (i.e. no shell). Your options are either to setup a filter to forward mail to a shell account (it will then not be available via webmail or other IMAP/POP e-mail clients) or to move to using IMAP/POP and web filters only. See Shell-linked E-mail for discussion.
What is my new server/IP?
Unfortunately, we don't know what this will be ahead of time. The reason is that we schedule a chunk of accounts to be moved at a time. Our mover script then goes through the list and picks an appropriate server that has enough resources available and then moves it. You will be sent an email once the move has completed with the name of your new server in the Subject line. Once you get that email you'll be able to login to your web panel and go to the 'Manage Domains' section to get your new IP. Just click the DNS link for the domain in question and the new DNS information will be listed there.
When will my account be moved?
Unfortunately, we don't have a more specific time frame for when the move will happen other than what is indicated in the pre-move email. This is because we are scheduling the moves in groups and they only run one at a time. How long it takes for your account to be moved after receiving the email depends on how many accounts are in front of yours and how much data they have (more data takes longer to move).
Fixing issues after the move
"Oh no! My site's been moved and now it's broken!". Depending on how your site is broken, it can be an easy fix or it can take a little bit of work. If you are getting an Internal Server Error, you should check your domains error.log (located at /home/username/logs/domain.com/http/error.log) for an error. Below is a list of symptoms, the cause and how to fix them:
I upload my files, but they don't show up online
This is likely because you're using the old server name as your FTP hostname. If you're using something like SERVER.dreamhost.com as your hostname you'll need to change that to your new server name (which is given to you in the email after you've been moved). An even better idea is to use your domain name though (example: yourdomain.com). The domain name will automatically point to the correct server no matter where it's moved.
My browser asks me to download a file instead of display my site
See the htaccess changes section below.
E-mail trouble
You may have e-mail trouble (sending, receiving, or filtering changing) for two reasons:
- You are using an old server name, like server.dreamhost.com rather than yourdomainname.com either for SMTP or IMAP/POP.
- Solve by using yourdomainname.com or the new server name.
- You formerly had Shell-linked E-mail (on an e-mail account from before April 2008), and no longer do.
- See Shell-linked E-mail for how to fix your configuration.
Custom DNS
If you are hosting your DNS outside of our system (i.e. not using ns1.dreamhost.com, ns2.dreamhost.com & ns3.dreamhost.com) you will need to make some changes after the move. Since you're moving servers you will no longer have the same IP information as you did on the old server. As soon as you get the email that you have been moved to a new server, go to Domains > Manage Domains and click on "DNS" under the name of the domain or sub-domain in question. The new IP address for that site will be listed there.
Custom PHP
If you've setup custom php (or a php.ini), its very likely that it will break once you're moved. This is because our older servers are running 32bit and the new servers are a 64bit architecture. If your site is giving an Internal Server Error after the move, you should check your domains error log (located at the /home/yourusername/logs/yourdomain.com/http/error.log) to see if you find a 'cannot open shared object file' error like the one below:
php.cgi: error while loading shared libraries: libsablot.so.0: cannot open shared object file: No such file or directory
If this is the case you will either need to recompile your php install or php.ini again. Unfortunately, this isn't something that DreamHost supports and cannot offer you assistance with.
.htaccess changes
Since these newer servers have a more current version of Apache, it may cause some of your .htaccess directives to not function properly anymore. If you have custom .htaccess files, you should go to This Page to see if any of your parameters need to be updated. A couple of parameters that are known not to work are the following:
SecFilterEngine
SecFilterScanPOST
modsecfilter
Problems relating to these entries will look like this in your domains error.log:
Invalid command 'SecFilterEngine', perhaps misspelled or defined by a module not included in the server configuration
These manage mod_security, which can now be turned on and off from the 'Manage Domains' section of your panel. You should remove any lines referring to mod_security from your .htaccess file and manage that via your control panel instead.
AddType application/x-httpd-php .html
ForceType application/x-httpd-php
DefaultType application/x-httpd-php
This will no longer work because mod_php4 is not enabled on the new servers. Having that param setup will tell the server to try and parse it as mod_php4 and will fail (since it no longer exists), which causes the browser to ask you to download the page instead of serving it up. You will need to change this to the following:
AddType php5-cgi htm html (or ForceType or DefaultType)
Server Key Changes
Since you'll be moving to a new server, the ssh keys will also change. If you have the keys of the old server saved on your local computer, you'll need to remove those. When you login to the new server after that, it will prompt you to resave your keys. Here's an example of what it will look like when you login with the incorrect key saved:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for www.domain.com has changed, and the key for the corresponding IP address xxx.xxx.x.xxx is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 0e:c2:f6:f4:d9:86:9d:4b:c4:3d:77:e7:a4:bb:59:14. Please contact your system administrator. Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message. Offending key in /Users/username/.ssh/known_hosts:3 RSA host key for www.domain.com has changed and you have requested strict checking. Host key verification failed.
In the case above, you'd need to remove the key from the /Users/username/.ssh/known_hosts file from your local computer and then accept the new key on the next login.
Program Specific Issues
Program specific issues usually generate blank pages or Internal Server Errors. Most of the time you can find more information about these errors from your domains error.log (/home/username/logs/domain.com/http/error.log).
Wordpress
Can't upload files
If you get the following error when trying to upload files using your Wordpress interface:
Unable to create directory /home/.blah/username/domain.com/wp-content/uploads/2009/09. Is its parent directory writable by the server?
OR
Unable to create directory /mnt/local/home/username/domain.com/wp-content/uploads/2009/09. Is its parent directory writable by the server?
This is because of the 'upload_path' that is defined in your Wordpress database points to a (now) non-existent path. You'll need to login to your database via phpMyAdmin (or via the shell if you're comfortable) and go to the wp_options table. At around line 60 or so, you'll see an 'upload_path' param. Click the little pencil to the left of that parameter to edit it and edit the path listed like the one above to read just /home/username/domain.com instead of /home/.something/username/domain.com or /mnt/local/home/username/domain.com.
If that seems too complicated for you, and you are really only comfortable in the WordPress Admin backend, there is another way to fix this. Log into the WordPress administrative back end by browsing to http://yourdomian/com/wp-login.php (or http://yourdomian/com/blog/wp-login.php, etc. - where ever your WordPress is located, plus the "wp-login.php" part) and then go in the meunu system to the "Settings -> Miscellaneous" section.
Once there, reset the "Store uploads in this folder" setting (Under "uploading Files") to the default value ("Default is wp-content/uploads"). Save your changes and you should now be good to go.
Blank White Page
This is likely because you have the advanced-cache setup for your blog and it has the wrong path listed for it. Just edit your advanced-cache.php file (which is usually located in the yourdomain.com/wp-content/ or yourdomain/wp-content/plugins folder) and make sure the path to the file starts with /home/username at the beginning and not /home/.something/username.
We've also run across some cases where customers have a symlink setup to point to the cache file, but the symlink is pointing to the wrong location. If you go into the wp-content folders via shell and look in the directory you could see something like this:
lrwxrwxrwx 1 username group 91 2009-09-28 08:47 advanced-cache.php -> /home/.blah/username/domain.com/wp-content/plugins/wp-cache/wp-cache-phase1.php
This simply means there's a shortcut named advanced-cache.php and you can see it's pointing to a bad path (/home/.blah/username instead of just /home/username). In this case you'll need to remove the advanced-cache.php shortcut and readd it with the correct link. You can readd the link using the following command after the bad one has been deleted:
ln -s /home/username/domain.com/wp-content/plugins/wp-cache/wp-cache-phase1.php advanced-cache.php
Joomla
Make sure to edit your configuration.php file (located in the folder that Joomla is installed under) and fix any paths that have the /home/.something/username path name and change them to be just /home/username.
Also, the following line in the .htaccess can cause blank pages, permission or 403 (Forbidden) errors:
## Can be commented out if causes errors, see notes above. Options FollowSymLinks
Put a # at the beginning of that last line to comment it out and that should fix the problem.
ActiveCollab
After being moved, ActiveCollab might start showing a blank page. This is because of the paths listed in the /cache/autoloader.php file in your ActiveCollab directory. All you need to do to resolve this issue is remove that file. It will auto re-generate that file with the correct paths and your site will resume functioning correctly.
WebCalendar
There is a bug with the current version of WebCalendar and the newer version of PHP that is on our new servers. As a result, your WebCalendar install may show a blank page or an Internal Server Error. The fix is very easy. If you have shell access, just edit /includes/functions.php and find the following lines, which are around line 3050:
$midnight = gmmktime ( - ( date ( 'Z', $item->getDateTimeTS () ) / 3600 ), 0, 0, $lt[4] + 1, $lt[3] + 1, $lt[5] );
You will need to add "+ 1900" at the end of the last line and save that file, like so:
$midnight = gmmktime ( - ( date ( 'Z', $item->getDateTimeTS () ) / 3600 ), 0, 0, $lt[4] + 1, $lt[3] + 1, $lt[5] + 1900 );
If you don't have shell access you can download that file with your FTP program and edit it with any text editor, then reupload the file. There has also been a patch released that will fix this issue for you. It can be found here:
http://sourceforge.net/tracker/?func=detail&aid=2534090&group_id=3870&atid=303870
QuickTime Streaming
If you find your movies not playing any more, and it looks like they are just trying to connect but nothing happens, make sure you add the port number to the reference URL.
So, instead of
rtsp://your_streaming_subdomain.com/your_streaming_subdomain.com/yourmovie.mov
you should have
rtsp://your_streaming_subdomain.com:554/your_streaming_subdomain.com/yourmovie.mov
You didn't necessarily need the port number on the old servers (although it's listed in the tutorial), but you will need to use it on your new server.
References
- Let's Save Our Environment Harder at the DreamHost blog
