Moving To a New Server

When moving Strongbox security system protected site to a new server there are two things to keep in mind. As with any script, you want to preserve the file permissions (chmod) and file ownership (chown). Also you want to be sure to enable the wildcard "sub-domain" like you have on your current server. As long as those two things are done properly the Strongbox security system should configure itself to work fine on the new server.

Note that these tips about proper file ownership and permissions apply to most ALL scripts, not just Strongbox, so by using these tips you can ensure that your credit card processor's scripts and other scripts continue to work.

If the site has already been moved, without following these instructions

If your site has already been moved, but your scripts don't work, it may be possible to fix the files, or it may be simpler to re-transfer them, but do it correctly. To find out, look at cgi-bin/sblogin/login.cgi. If the file permissions or "chmod" on that file shows "755" or "rwxr-xr-x", things can probably be fixed fairly simply. Delete the contents of these directories AND make sure that all have permission "777" or "rwxrwxrwx", but other than that, leave the directories themselves alone:

• cgi-bin/sblogin/.htcookie/turings/
• cgi-bin/sblogin/.htcookie/
• sblogin/report/pages/

Then skip down the page to the section labeled "Enabling the wildcard". If file permissions or "chmod" is NOT 755, all of your scripts are probably broken so it's often best to just copy the files again, but do it correctly using the instructions below.

Moving a site while preserving file permissions

On any site with any PHP or CGI script installed, you'll want to be sure to keep file permissions (chmod) and ownership correct when you move the files to a new server. For a small to medium sized site, one commonly used way of doing that is to make a tar file of the site, which is similar to a zip file, FTP the tar file, and then extract it. You'll need telnet or SSH access for this. If you haven't used telnet or SSH before you may wish to get your web host or another qualified administrator to help with this. It's been said that "to err is human, to screw up a thousand times per second requires a computer." "cd" into the "document root" of the domain, commonly called "public_html", "httpdocs", or "htdocs". Before rolling the tar file, we'll make sure that the cgi-bin location is compatible on both servers.

Symlinking cgi-bin

On some servers the cgi-bin directory is inside of the document root, while on other servers cgi-bin is one level above document root. In order to make sure that the old server and new server are compatible in this respect, we'll create a "symlink" (shortcut) from the location inside of DOCUMENT_ROOT to the location outside of DOCUMENT_ROOT if needed. The following command will do that:

            ls -ald cgi-bin >>/dev/null || ln -s ../cgi-bin cgi-bin

Rolling the tar ball

Next run this command to make the the tar file:

            tar --gzip --preserve --dereference --same-owner --atime-preserve -B -cvf ../site.tar.gz .

That will create site.tar.gz in the directory one level above document root. Download the tar file via FTP and upload it to the new server. On the new server we'll first create a similar symlink for cgi-bin:

            ls -ald cgi-bin >>/dev/null || ln -s ../cgi-bin cgi-bin

Then we can extract the tar ball:

            tar -B --ungzip --preserve --same-owner -xvf site.tar.gz

If your username on the new server is different from your username on the old server, you may get an error message such as:

            Cannot change ownership to ...

That's normally OK if you get that message. In that case we'll delete some temporary files created by the Strongbox security systemtm:

            rm -rf cgi-bin/sblogin/.htcookie/sb*
            rm -f cgi-bin/sblogin/.htcookie/turings/*

You should now be done transferring your site and the file permissions should be right. After enabling the wildcard if needed you'll be done.

Changing file ownership with "chown -R" or "find"

If for some reason your tarball is extracted while logged in as the "root" user, you may be thinking about changing the file ownership using "chown -R" or "find". This won't be an issue if you are logged in as a regular user rather than root. Also extracting any file as root is not advised any way. Anyway, the obvious "chown -R" won't quite do what's needed because some files may be owned by the "apache" or "nobody" user. These would include files generated by content management scripts, message boards, and some credit card processor's scripts. Also there may be some root owned files such as stats or logs used for billing purposes. the Strongbox security systemtm is another script that creates files. To get this right we need to first chown all files that are owned by the user's old UID to their new UID using a command like:

                 find . -uid OLDUID -exec chown NEWUID:NEWUID

Then look for any files NOT owned by their new UID:

                find . -not -uid NEWUID | less

You can then chown those files to the new "nobody" UID if needed using a command similar to the one used to chown user owned files. If the above discussion made no sense to you, the honest truth is that you probably shouldn't be logging in as root and extracting tar files that could be extracted using an unprivileged user name. Either do the extraction as a regular user rather than root or get some assistance from someone more knowledgeable.

Transferring large sites with a tar pipe

If your site has more than a couple hundred MBs of content you may wish to use a tar pipe rather than FTPing a tar file. Read and familiarize yourself with the instructions above for creating and moving a tar file. Only if your level of Linux/Unix experience is enough that the above is quite unintimidating should you try a tar pipe. For a tar pipe create the cgi-bin links as explained above. Then use a command similar to the one below to transfer the files over the backbone through an SSH connection rather than FTPing. This command will be run from the OLD server:

                tar --gzip --sparse --preserve --same-owner --atime-preserve -B -cvf -  . |
                ssh USER@NEWHOST "cd /home/user/domain/public_html; tar -B --ungzip --preserve --same-owner --atime-preserve --sparse -xvf -"

The exact command will need to be adjusted to fit the particular servers involved.

Enabling the wildcard

• Learn more about the wildcard at Newtons

The Strongbox security system uses a wildcard "sub-domain" which is enabled by default by many hosts. To check to see if it's already enabled, try loading this URL in your browser: http://testing.YOURSITE.COM/ When enabled, the wildcard will make it so that anything.yoursite.com works just like www.yoursite.com. If you haven't switched over to your new hosts DNS yet testing can be tricky. One shortcut is to see if the web host's own site has the wildcard. If so, they probably include it by default, so try: http://testing.YOURNEWHOST.COM

If it's not already enabled, enabling it will require a DNS entry:

• IN A ip.add.ress

and a matching ServerAlias in Apache: ServerAlias *.YOURSITE.COM These entries will need to be added by your server administrator. If your server is managed by a control panel such as Plesk or Ensim contact us for specific instructions applicable to your particular control panel software.

Testing - More than editing your hosts file

If you want to test your site on your new server before switching the DNS, you may be familiar with adding the new IP to your "hosts" file. This works well, but there is one extra step needed with Strongbox that can trip you up. You may have noticed that when you log in through Strongbox, Strongbox avoids requiring cookies by redirecting you to something like "sb8dfidb5pa.yoursite.com" (See Newtons). That name is not in your hosts file, so you'll be sent to the live server and see the log in page. At that point, go back to yoursite.com/members/ and you should now see the members' are on the new server.

Switching from Apache 1.3 to Apache 2 or vice versa (AcceptPathInfo)

If clicking on the members' log in link gives you a 500 internal server error before you even try to log in and the log in page doesn't even load, your old server was probably running Apache 2.0 or 2.2 and the new server is running Apache 1.3. In that case, there is a line you need to comment out in sblogin/.htaccess. Look for the following line:

        AcceptPathInfo on
        

Comment it out so it looks like this:

        # AcceptPathInfo on
        

On the other hand, if clicking on the members' log in link gives you a 404 Not Found error before you even try to log in and the log in page doesn't even load, your old server was probably running Apache 1.3 and the new server is running Apache 2.0 or 2.2. In that case, there is a line you need to UNcomment AcceptPathInfo in sblogin/.htaccess. Look for the following line:

        # AcceptPathInfo on
        

Uncomment it so it looks like this:

         AcceptPathInfo on

Reinstalling in Case of Problems

If the transfer is thoroughly messed up, such as if you didn't read this document until AFTER you moved all of the files and closed your account with your old host, we can re-install the latest version of the Strongbox (tm) security system with all of the latest updates for a fee, to order go to https://www.bettercgi.com/strongbox/order/ (Select Update / re-install existing Strongbox or Upgrade from Strongbox 3.x to SB 5.0)

A DNS trick for busy sites

On busy sites that have frequent changes, such as new members joining every few minutes, you can get tricky with the DNS settings to avoid having some people going to the old server and others going to the new server during a long transition time. In order to make sure that all visitors switch to the new server at the same time, you can set the new DNS with a very low "TTL" (cache time) and put the OLD IP in the new DNS for a day or two after the switch. Once everyone is using the new DNS and it's only caching the IP for up to 600 seconds, you then switch the new DNS to point to the new IP and almost all visitors will start going to the new server within 10 minutes. After the switch, once you're certain that everything is running smoothly on the new server, you can increase the TTL again to reduce traffic to your DNS server and slightly improve the speed at which your site loads.

This TTL manipulation works well for sites with a lot of changes, such as new members joining every few minutes, message board posts, etc. It wouldn't be good if you had 20 new members join and CCBill added their user name to the old server but the customers tried to log in to the new server, which didn't have their user name added.