Moving CGI Scripts to a New Server

Moving a website to a different server can be a breeze, or it can be a real headache.

If a website consists only of web pages, no server programs or forms, for example, it generally requires only dragging the site mirror backed up on the hard drive into the upload window of the FTP program. Links need to be checked, of course, and all pages viewed to verify the upload.

When scripts or other server programs need to be moved to the new location, a bit more care needs to be taken.

More often than a person might think to be the case, CGI scripts can be moved to the new server without changes.

But don't bet on it. Keep this article where you can refer to it.

Note: This article does not address everything you may need to know when moving CGI scripts to a new server. There are too many different scripts and too many possible variations of server configurations for that. It does provide enough information, I believe, to allow most such moves to be accomplished with success.

Your Mirror

First, mirror of your website.

A mirror means downloading the files from your server and storing them in the same directory structure as exists on the server. For example, on my hard drive I have a directory named "willmaster.com" where the mirror for that website is located. The "willmaster.com" directory has a sub-directory named "possibilities" where a copy of the files of this ezine's section of the website, in their own respective subdirectories, are located.

Always keep a mirror of your website in a safe place. Don't let the mirror become outdated. If you suddenly need to move to a new server, you won't have to worry about whether or not you can access the account at the old server.

Directory Structure and Paths

Next, using your word processor or a sheet of paper, record the directory structure at the old server. Also note the path to perl and the path to sendmail.

After that, record the directory structure you will need to use at the new server, along with the paths to perl and sendmail. Support at the new hosting company can provide information you don't have readily available.

If the directory structure and paths to perl and sendmail are the same on both old and new server, the Universe is smiling on you.

When Directory Structures Are Different

When the directory structures are different, use a plain text word processor, BBEdit or NotePad or other software that reads, displays, and saves files only as plain text, and replace all old directory structures with the new directory structures.

For example, let's suppose the new server's document directory path is

/www/example.com/htdocs

and the old server's document directory path is

/usr/local/etc/httpd/htdocs

then you would need to replace all instances of "/usr/local/etc/httpd/htdocs" with "/www/example.com/htdocs" -- all CGI scripts need to be searched.

Do the same with the server's cgi-bin directory path if the new is different than the old.

If the name of the cgi-bin directory itself changes (some common names are "cgi", "cgi-bin", and "cgi-local"), then the URL of the scripts in the directory will change also. This means any links, including links from FORM tags, must be changed, too.

Some scripts have a configuration file where the directory path information is specified. Others have a control panel that needs to be used in the newly installed location to specify the information.

Always use a plain text word processor when editing perl CGI scripts.

When Paths To perl Are Different

The two most common perl locations are:

/usr/bin/perl
/usr/local/bin/perl

When the paths to perl on the new server are different than on the old server, the first line of all CGI scripts must be checked and changed if necessary. (Perl modules and include files don't necessarily have the perl location on the first line like main perl programs do.) Some CGI scripts also contain the perl location in other places, scripts that generate other scripts for example. You may wish to do a search and replace through all CGI scripts except than those you know with certainty don't generate other scripts.

When Paths To sendmail Are Different

The path to sendmail can be just about anything, but usually contains either

/bin/

or

/sbin/

The path might begin with

/usr/

When the paths to sendmail on the new server are different than on the old server, do a search and replace through all CGI scripts.

Some scripts have a configuration file or control panel where the sendmail location is specified.

CGI Scripts Running In Document Directories

If your old server allows CGI scripts to run in document directories (in directories other than the usual cgi-bin directories), then your new server must also allow this. If it doesn't, you'll have to move the scripts into the cgi-bin, which means they would have a different URL.

Any links you might have to scripts that are moved to a different URL will no longer be valid. That can be fixed if the links are all on your website. But if the links are on another website, those other links will generate a "404" error.

Verifying the New Server Has Required Modules

When a CGI script uses standard Perl modules, it will have at least one of these lines within it:

use _________;
require _________;

The underline will contain the name of the module the script needs in order to run correctly.

Search your scripts for those types of lines, making a list of each module. Once you have your list, do two things:

1. Check the file names of the files in your cgi-bin that are in the same directory as the script or in one of the script's subdirectories, crossing from your list every file name that matches.

2. Of the file names left on the list, all should be modules already installed on the server. The support personnel of the new server should be able to tell you whether or not each of those modules is indeed installed on the server. If they can't, or if you don't want to ask, you can download and use the Master Pre-Installation Tester program.

The new server must have the modules your CGI scripts need or the scripts won't run correctly, or maybe not run at all.

Scripts That Use Certain Database Modules

This can be a confusing section if you are unfamiliar with Perl CGI scripts or how they work.

If you go through this section and you find that any of your scripts use the modules referred to, you may wish to contact the author(s) of the program and ask them to move the program for you.

Again, warning, this section could make your head spin if you're not familiar with Perl.

A DBM module is used to store information in a special type of database. This database is not a plain text database, so it can't be treated as such.

If you download or upload DBM database files with FTP, you'll need to transfer the files as binary files. Otherwise, you'll corrupt the files. (The file name extensions of DBM database files are usually one or two of the following: ".pag" and ".dir" (a set), ".db", or no extension at all.)

If any of your CGI programs use DBM modules, the same modules should be available for use on the new server.

If a script uses a specific DBM module, it will have one of these lines somewhere in it:

use DB_File;
use SDBM_File;
use GDBM_File;
use NDBM_File;
use AnyDBM_File;
require DB_File;
require SDBM_File;
require GDBM_File;
require NDBM_File;
require AnyDBM_File;

Or, it will have the word

dbmopen

somewhere within it, which function causes the default DBM module (any of the above) to be used if no other DBM module was specified.

Or, it will have the word

tie

somewhere within it, which function causes the specified DBM module to be used.

If any of your scripts use DBM modules, see if the CGI program can export the database. If it can, export it, then import it at the new location. That's almost always the best way to go, so much so that it may be time well spent to ask the program's author how to export and import if the program doesn't already have that functionality.

Keep backups of the original files.

Testing

When you install CGI scripts on the new server, follow the installation instructions. The FAQ may be of assistance if you run into problems not addressed in the instructions.

Some scripts can be tested on the new server by substituting the IP address for the domain name in the URL. Others can be tested only after the site is live on the new server.

Be aware that data files moved from the old server to the new might have incorrect permissions. Data files the script creates on the server have correct permissions. But those moved over from the old might not.

If a script doesn't work and you suspect the reason is data file permissions, try removing the data files in question and running the script. When the script runs, it should create new files. The new files would have the correct permissions. You can now re-upload the data files from the old server and the uploaded files should retain the same permissions as the files they replace.

When All Else Fails (Or, The Easiest Way)

If you can't get a newly installed script to work, or if you just want to do things the easy way, hire the author of the script to do the move. If the author is not available, s/he may be able to recommend someone who can do the job.

Will Bontrager