Moving from shared to VPS

choosing a VPS

Googling 'east coast VPS' got me Linode in New Jersey, and theNYnoc in Port Washington and some others in DC and Atlanta. . I was kind of a chicken-shit so I went for the familiarity of a ContolPanel based system. I hated all the theNYnioc haters. The defenders seemed as though they were doing the job.

find a data-center close by

Tracing the routes to the Atlanta and DC data-centers was no where near as fast as to NY/NJ. they were not even noticeably faster that the 800 ms to Utah. NY/NJ was more like 250ms

sign up for VPS

Sign up with with the domain name that is most important to you even if it is currently just an addon domain on the shared site. Wait

trace the route to you new ip

Traceroute the IP they give you as soon as you get it. Even though theNYnoc sold themselves as east coast, they gave me an IP in Dallas. I guess the assumption is what does it matter, your users could be anywhere. Mine aren't.

backup the old account

There are scripts for moving from cpanel site to cpanel site. They don't work if the sites are big. Niether does phpMyadmin export if the db is over 50mb.

The old site's ControlPanel/backup had an option to backup the whole site. It puts a big tar.gz in the accounts dir.

getting the new site up before re-pointing the domains

The main idea is that you can get to the new versions of your without needing to re-point your domains. http://206.71.150.94/~pathbost/hum09 got me to the account(pathbost) that would eventually be the domain pathboston.com

move the backup

As a big time VPS guy you get root access. So ssh looks like this:

1. ssh root@206.71.159.94.
2. cd /
3. mkdir download
4. cd download
5. sftp pathbost@parthboston.com (to the old site)
6. find the backup and get it

set up accounts on the new VPS

On cpanel this is just a fill in form. domain, user, password ... Even if you don't have the domain you could still set it up and get there by http://IP/~user/ ex: 206.71.170.94/~joesgril/somepage.html

messing with MYSQL

When you are on a cp shared host your (usually 8 character) username_ is the prefix for all your MYSQL databases and MYSQL users. Since some shared hosts limit the number of databases you can have, sometimes one database will have the data for more than one wiki or more than one blog. The tables for one wiki would have a different table prefix (ex:w1_). You set the prefix when you are setting up the wiki/blog using the web tools or some config.php or LocalSettings.php.

The way you deal with your other domains is by having them be "addon domains" placed in some subdirectory off public_html. These addon domains use the same MYSQL db and user prefix as the main site. On MYSQL database can contain the data of wikis from 2 or more different domains.

In a VPS you might as well have each domain have its own account. Then each domain has its own MYSQL db and user prefix. I had data from more than one domain in one database. Now, without the the limits on the number of DB's, each application in each domain can have its own database.

moving the data

One of the databases was too big to import using phpMyAdmin. (there's a limit of 51MB) The oldsite backup created a mysql directory with sql files of the database. To import it into MYSQL I cd'd to there and used the command line:

mysql -p-h localhost sitebuil_wikidb<pathbost_wikidb.sql

Now the big database was in MYSQL and I could use the root version of phpMyAdmin to make copies of the db and then parse each copy into just the files for one app by deleting the files for the others.

re-setting up MediaWiki

1. get the latest version - cd to dir for downloads; start lynx; goto Mediawiki downloads and copy the URL into lynx; navigate then download and save; cp -r media.tar.gz /home/pathbost public_html; gunzip media..; tar -xvf media..; rename dir;
2. configure - cd there; chmod c+a config; http://pathboston.com/humx/config; set db and dbpassword; temporarily $wgScriptPath ="/~pathbost/humx"
3. activate extensions - copy the extensions and image directories to the new installation; add the end of the old LocalSettings.php to the new
4. rebuildall - put dbusernae and password in adminSettings.php; run php rebuildall

pretty URLs

1. add an alias to http.conf - goto WHM http://pathboston.com:2086; Main >> Service Configuration >> Apache Setup >>edit include files in PostVirtualHost Include put: Alias /hum /home/pathbost/public_html/hum4/index.php; restart apache
2. add code to LocalSetting.php - ##rewriting stuff from http://www.mediawiki.org/wiki/Manual:Short_URL
   $wgScriptPath = '/hum4'; # Path to the actual files. This should already be there
   $wgArticlePath = '/hum/$1'; # Virtual path. This directory MUST be different from the one used in $wgSciptPath
   $wgUsePathInfo = true;

memory/php caching

Installed APC as a php compiler. It was almost easy. SSH to site and type "pecl install apc" worked once I added the path_to_apxs "PATH=$PATH:/usr/local/apache/bin" then "export PATH". The improvement isn't obvious.

setting up WordPress blogs

1. move the whole wordpress installation to the new place
2. update wp_config.php
   define('DB_NAME', 'sitebuil_wrdp1'); // The name of the database
   define('DB_USER', 'sitebuil_wrdp1'); // Your MySQL username
   define('DB_PASSWORD', 'nji9ol'); // ...and password
3. put rewrite rules in .htaccess - copy from bottom of admin>settings>permalinks or http://sitebuilt.net/wp-admin/options-permalink.php

re-pointing the domains

• Put in a ticket to have the domain manager not just change the nameservers to ns1.sitebuilt.net (which you can do from the domain manager) but change or set the IP address of the nameservers - ns1.sitebuilt.net>206.71.150.94 and ns2.sitebuilt.net>206.71.150.95
• for the rest of the domains, just change the nameservers in the domain manager

modify the app config files

• change $wgScriptPath from "/~pathbost/hum4" to "/hum4" in LocalSettings.php

Once the new nameserver address propagates then the pretty URLs should work

the long last mile

While the rest of the universe has updated the nameservers and everything works, the BPS servers remain clueless keeping the old IP address for the nameservers and domain in their ipdnscache. Trying to get them to flush the cache is an exercise in being abused by arrogant IT help desk people who insult you and treat you like a moron. IT help desk people are worse than Homeland Security police state types. They won't even talk to a teacher even though they list the helpdesk number on the teachers mybps.org website. You would like IT to have some part of their mission to support the use of technology for education and to support the teachers who are making that happen.

The best hope is probably a server crash that would reset the cache. Meanwhile there is this usatisfying workaround: Install yet another mediawiki (in hum09) but point it to the same database. Get to the class site by http://206.71.150.94/~pathbost/hum09 when in BPS and http://pathboston/hum when in the rest of the universe.