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!
- 1 Why do servers change?
- 2 What changes?
- 3 Preparing for the move
- 4 Fixing issues after the move
- 4.1 Perl Scripts are not working!
- 4.2 I upload my files, but they don't show up online
- 4.3 My browser asks me to download a file instead of display my site
- 4.4 E-mail trouble
- 4.5 DNS Changes
- 4.6 Custom PHP, Python, Ruby, etc.
- 4.7 .htaccess changes
- 4.8 Server Key Changes
- 4.9 Program Specific Issues
- 5 References
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).
Here is some information about what changes on the backend after the move.
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?
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.
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. A quick temporary fix is to modify your OS's host file to alias old domain to point to new.
- 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 page for more information on how to recompile that. Hint: The output of phpinfo, or php -v, or your config.log in the source directory, has the original configure command used to compile. Do a
make distcleanand recompile.
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:
Perl Scripts are not working!
Unfortunately, the newer packages for Perl no longer include the old /usr/local/bin/perl link that they once did, so that no longer works. You'll just need to update your Perl scripts' she-bang (#!) lines to use "/usr/bin/env perl" (preferred) or "/usr/bin/perl" instead. :)
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.
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.
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(es) for that site will be listed there. If you added an IPv6 address to a domain, be sure to update that as well.
Keep in mind, Unique IP's may or may not change as well!
Custom PHP, Python, Ruby, etc.
If you've setup custom php (or a php.ini), or compiled your own programs from SSH its very likely that they 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
Since these newer servers have a more current version of Apache (Apache/2.2.11) and newer versions of some Apache modules like mod_security, 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 mod_security parameters that are known not to work are the following:
SecFilterEngine replaced by SecRuleEngine
SecFilterDefaultAction replaced by SecDefaultAction
SecFilterScanPOST replaced by SecDefaultAction
SecFilterDebugLog replaced by SecDebugLog
SecFilterDebugLogLevel replaced by SecDebugLogLevel
SecFilter or SecFilterSelective replaced by SecRule SecFilterInheritance replaced by SecRuleInheritance
SecFilterScanPOST replaced by SecRequestBodyAccess
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
Additionally, <IfModule mod_security.c> will no longer have any effect.
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.
Complete mod_security changes are outlined by the developers in this PDF: ModSecurity-Migration-Matrix.pdf
AddType application/x-httpd-php .html
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)
If your previous server was running a version of Apache older than about 2.2.14, you may get internal server errors if your .htaccess file contains redirect commands like:
Redirect /oldpage.html http://www.example.com/newpage.html [R=301,L]
You should change those lines to be of the form:
Redirect permanent /oldpage.html http://www.example.com/newpage.html
Redirect 301 /oldpage.html http://www.example.com/newpage.html
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.
Mac OS X
Open a terminal window (Applications>Utilities>Terminal) and at the prompt type:
cd .ssh ls
It should contain a text file named known_hosts. You may open this in a text editor and remove the offending lines. Alternatively, if DreamHost is the only server you have keys for, you may delete this file:
rm known_hosts # ONLY do this if DreamHost is only server
(If you log in to other servers, do not delete the known_hosts file, or you’ll have no way of knowing if they have changed.)
If you log in from multiple user accounts, you may have to do this logging in for each user account on your computer.
The OpenSSH version of ssh provides a command-line utility to remove specific host keys without disturbing the others. This is especially useful if you use ssh to connect to more than the one host and you don't want to hand-edit the known_hosts file. At your shell prompt, type:
ssh-keygen -R www.mydomain.com
This will create a backup of the ~/.ssh/known_hosts file and remove the old key of www.mydomain.com from the current known_hosts. Repeat as necessary for each host that had been moved.
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).
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?
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 can fix this through your Wordpress Admin interface.
For WordPress versions prior to 3.0, 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 menu 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.
For WordPress 3.0 (and, presumably, later versions) the process is similar but the menu locations are different. After logging into the WordPress admin backend, you go to "Settings", then "Media", then the "Uploading Files" section of the page. There, change the "Store uploads in this folder" field to the default "wp-content/uploads". Save your changes and you should now be good to go.
You can also change this through 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.
WP-Database Manager Plugin
If you use the WP-Database Plugin, you will need to make a similar change to get rid of the "Your backup folder MIGHT be visible to the public" error message. In the Wordpress admin, go to the Database plugin box, click on DB Options, and edit the line that says "Path to Backup." Delete the part that says .blah. It should now read something like /home/username/domain name/wp-content/backup-db.
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
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.
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.
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 + 1, $lt + 1, $lt );
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 + 1, $lt + 1, $lt + 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:
After the upgrade, you may run into an error saying that the calendar requires Magic Quotes to be turned on. This is something that was turned on in our php4 installation, but is shut off in php5 (which all our new servers run by default). In order to enable Magic Quotes, you would need to install your own version of PHP5 or create your own php.ini (for use with a local copy of Dreamhost's default PHP installation) to change the setting.
There is also an option to turn off the Magic Quotes requirement in Webcalendar itself by following these instructions in their wiki:
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
you should have
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.
Slide Show Pro Director
Since SSP uses caching, which will break after a server move, just follow step #2 on the official SSP wiki page:
Delete any folders/files inside the following folders:
After a server move, visits to a MediaWiki site may fail with an error that refers to "require_once" in Setup.php. This probably means that MediaWiki's global variable $IP now refers to a non-existent path (directory). The $IP variable is set in LocalSettings.php. Make a backup of LocalSettings.php then edit it to change for example /home/.natwick/youraccount/yourdomain.com/yourwiki to /home/youraccount/yourdomain.com/yourwiki. Study the bit about ".dataglob" and the very similar fix for Joomla, above. The search for ".dataglob" above may be supposed to find this but it did not seem to find ".natwick".
There is also a similar setting in the data/skins/ LocalSettings.php file that will also have to be fixed. These are both under the "enahnced DB security: commented section.
- Let's Save Our Environment Harder at the DreamHost blog