When migrating your accounts, domains, users etc. from the old FreeBSD based servers, you will inevitably run into some problems, as the layout of the account and the naming schemes had to be made different. See Changes from TextDrive Shared Hosting for a summary.
This walkthrough is specific to those hosted on TextDrive servers. For a more general overview of the process, see Moving to Joyent Shared Accelerators.
Unfortunately, there is no way to have an account automatically migrated for you so you'll need to move any files and databases yourself to the new Shared Accelerator.
Based on suggestions by tweir:
Delete cruft and organize what’s left. Take this chance to go through your sites’ file structure and clean out things you are no longer using, or organize things a little better.
-
Make a list of email users.
Remind email users to clean out their inboxes.
Make a list of domains that need to move.
Make a list of what type of ports you need (lighttpd, trac, instiki, mongrel, generic use)
Make a list of dedicated IPs
Make a list of Share certificates (from Joyent) and third party certificates which will need to be regenerated.
Make a list of protected directories (if you made any)
Set your TTL to a low level if you manage your own
DNS records. If your
DNS records are managed by TextDrive, they are already set at either 1200 or 2400 seconds (depending on when your account was set up) which is a fairly low value - no need to change anything.
Catchall email address users: make a list of email addresses you have used that you want to remain available.
You can keep track of how the migration is going at Joyent's end via the
OpenSolaris Migration Update forum thread. This also has info on how to request a Golden Ticket.
Submit a ticket For port(s) listing how many of each type - lighttpd, mongrel, instiki, trac, general, the details for the share certificates which need to be moved(No charge for replacement), and dedicated IPs (No charge for replacement). If you have a third party certificate submit a request to them on getting a new one generated.
Do the following for each domain - you may wish to use the domain migration checklist below. By the way, start with your least important domains.
Limit access to your website if possible, especially if other people besides you normally contribute to the site (forums, blogs with comments, etc.). For example, put up a simple “down for repairs” index page up and redirect all access to it. Or simply disable comments, etc. If users make additions or changes to any part of your site during the migration, it is likely that it will be lost, and this step helps prevent that from happening.
Back up your files, either to your local hard drive or to strongspace.
In Webmin on your old account, turn on
FTP access for all users (for email migration later).
Add the domain to your account
Create your databases in Virtualmin (if your .sql file doesn't start with a CREATE database_name
declaration)
Either in phpMyAdmin (mysql.servername.textdrive.com
) or from the command line, export your database using as “latin1” character encoding. Download the .sql
file to your hard disk.
Open the .sql
file in a text editor and find/replace all instances of latin1
with utf8
. Note that if your collation is something strange like latin1-swedish-ci
you'll need to change this to utf8-general-ci
.
Check if the file starts with a CREATE database_name
declaration—you will have to comment this out with ”--
” if you've already made the database, and/or alter the USE database_name
command if the new database name is different.
Save the new file and import it into your database on the new server (again, can be done either on the command line or through phpMyAdmin).
Add users or mailboxes:
Create aliases
Upload your site's files. Rather than using SFTP (downloading everything from the old server and uploading it back to the new), why not copy the files directly? Log in to the new server and
cd
into your website's
web/public
directory, then type the following command
1):
rsync -ave ssh oldusername@oldserver.textdrive.com:domains/site.com/public_html/ .
Check paths, usernames and passwords in configuration files for your CMSs and other web apps. The absolute paths given in these files (such as textpattern’s config.php
) are almost certainly incorrect now that you've moved all your files to the new server.
Recreate protected directories if you had them, and if you want to manage them via Virtualmin. Allowed users should appear automatically once you've added the protected directory since the directory's .htpasswd should have been copied over (use the default “users to allow: all users in file”).
-
Copy cron jobs from your old account if you have any you want to keep. The shared accelerators don't have @reboot cron jobs — read up on
Boot-up actions instead.
You may wish to use the email migration checklist below to keep yourself organized through this process.
Check then recreate your current email setup (forwards, aliases etc) on the new server for each email user account so that the emails will be processed as they currently are once we flip the
DNS switch
Send a test email to each new user account to ensure it’s working (you can check via https://usermin.joyent.us/
servername/, eg
https://usermin.joyent.us/caledonia/). The email address format to send to is
username@servername.joyent.us
for your primary domain, and
username-domainname@servername.joyent.us
(you can check 'username(-domainname)' in
Edit Mail and FTP Users → POP3/FTP login, and 'domainname' is generally the first part of your domain name, eg “bbc” for bbc.co.uk)
On the OLD server, switch
FTP access on for each user whose email you are migrating
At the same time add their new server email address to the email forwarding section. This merely ensures that no email is lost during the time it takes the
DNS to switch over later on. (Note: Enabling forwarding can be problematic, especially if you have lots of aliases. Make a copy of all your aliases first so you can check none are dropped in the process. Also the forward is usually successful even if the server times out - try accessing from the user list again to check.)
Copy each email user’s mail. You could simply open both old and new accounts in an
IMAP client like Thunderbird and drag and drop the emails over, or use this suggestion
from anoop:
Two rsyncs appear to be the quickest way to move mail over…On your
new shared accelerator, run this command:
rsync -ave ssh old-login@oldserver.textdrive.com:Maildir some_local_temp_folder
This will bring over a user’s Maildir to the Solaris server. Then run this command
to put it in their new home folder
scp -pr some_local_temp_folder/Maildir new-login@localhost:
Then rm -fr some_local_temp_folder/Maildir to get rid of the temporary copy.
NOTE: The second step used to use rsync, but rsync does not work due to changes in the scponly shell. Use scp instead.
On some of the textdrive servers the first step still works with rsync. On others, you need to replace rsync -ave ssh
with scp -pr
.
Don't forget some of these other items. These aren't covered in detail on this page since they don't apply to most users:
For a totally seamless switchover, save
DNS updates for last.
This assumes that you are using Joyent to serve DNS for you (including the textdrive.com name servers). There are two ways to switch DNS from an old TextDrive shared server to a Shared Accelerator.
If you never requested any custom A type record (pointing a single hostname to an IP external to Joyent/TextDrive), and have either a vanilla DNS zone, or have a custom MX or SPF setup on a domain (anything but an A type record):
Just enable PowerDNS for the domain in Virtualmin on the Shared Accelerator. You do not have to care about the PowerDNS option on the old server or anything else. Virtualmin on the Shared Accelerator will embrace the existing
DNS zone and update all IPs in the zone to match the new server. Any non-IP customizations (e.g. MX pointing to Google or Joyent Connector, a custom SPF, custom CNAME records etc.)
will be preserved. Any
A type records (pointing to IPs) will be reset to point to the Shared Accelerator.
If you do have custom A type records (e.g. a hostname pointing to your own server elsewhere), you can still follow the above approach and then request to have the custom A record(s) reset, or:
Open a support request and let Joyent switch your DNS over. Do not forget to specify which domain(s) to process and what is your original and the new server. Any customizations
will be preserved and Joyent will only update IPs that match the original server.
If you handle
DNS yourself using a third-party service like dnsmadeeasy.com, use that service's interface to change your records to the new IP address and leave PowerDNS off on the new server.
Use these tables to create a spreadsheet or plain-old-paper list of your domains or email users and check off each task in the migration process.
Neither table is all-inclusive of the total migration process; in fact there is no overlap between the two. The domain checklist includes only website-related tasks, and the email checklist includes only email-related tasks. Neither includes the step of switching over your DNS at the very end.
This is essentially a summary process of the migrating each domain section above.
Domain | Files backed up | FTP enabled for all users | Domain created on new acct | Databases created and imported | Users created | Files copied | Verified config files | Site works in Virtualmin | Cron jobs migrated |
foo.com | | | | | | | | | |
gnat.com | | | | | | | | | |
This is essentially a summary process of the migrating your email users section above.
Email User | Old username | Old password | New username | New password | Alternate joyent.us email | Test email works? | Old account forwarded? | Old emails synced? |
jervis@foo.com | jervis | middlename | jervis-foo | swnf9p8y4 | jervis-foo@nicewipe.joyent.us | | | |
Just where to start seems daunting sometimes. So take things step by step. First create a hello.html page so you can start figuring out just where things are going wrong.
<html>
<body>
<h1>hello world testing example.com</h1>
</body>
</html>
first start out with the hello.html page in your ~/web/public or ~/domains/example.com/web/public if this is not your primary domain you are debugging. Then move it to other directories which you are having problems. Change the example.com text to be something unique just so you really know that it is your page rendering.
http://example.com/hello.html doesn't display. Don't fear lets walk through the configuration.
-
-
It Works! I'm seeing this page and not what I expected. Go back and edit your virtual server and make sure that in the bottom section you have Web virtual server enabled
So I'm all moved over and all I have to show for it is 500 errors. To quote Filip “A 500 error typically means that Apache encounters a broken/invalid configuration”. Don't fear here are a couple of quick tips.
.htaccess take a long look at this file. Anything relating to mod_security should be removed.
Solaris Accelerators are using a newer version and the items from FreeBSD will not work.
My static pages(hello.html) are rendering but anything to do with the database renders a blank page.
usernames double check that your usernames are the same from the FreeBSD. This is where using the checklists above will really save you time. From the checklist above jervis went to jervis-foo.
Make sure you've enabled error logging. See PHP configuration
Check if your ~/etc/php5/php.ini or ~/etc/php4/php.ini matches the configuration on TextDrive. For example, you may have to enable allow_url_fopen (which is disabled by default).
Don't fear more resources are available here:
-
-
Missing or wrong version of native package. We tried very hard to make sure that all of the native items are available.
Check against this list
search the Shared Accelerator forum. Use the
search page enter the keywords for the error (start specific then fewer until you get a hit). First limit the search to the Shared Accelerator forum and if no hits search all forums.
-
Help the next person and add your solutions to issues here as well