Installing Your Own CGIs
Our Virtual Servers are unique because they provide you with
all of the flexibility, power, and control of a Dedicated Server. Because
of this, you are free to customize and configure your Virtual Server for
your specific circumstance and needs. This includes the ability to install
your own custom developed CGI scripts or CGI scripts that you have downloaded
from a third party source
(see CGI Security Issues).
This document is divided into several sections. Each section includes a discussion
about a specific topic. Each topic, though important, may or may not have
applicability to your specific situation.
The "Virtual Environment"
Your Virtual Server services operate in an environment completely
separate of the root system (and any other Virtual Server
hosted on the same host machine). This means that your script
does not have access to any files residing on the root file system,
only those files that are located in your home directory hierarchy.
Path Specification
Because your CGI scripts operate in a "Virtual Environment" (see above),
the pathnames that you specify in your CGI scripts should be declared
with respect to your home directory. For example, your script may
access a file to read from or write to. Instead of specifying a
pathname that begins with
/usr/home/LOGIN/usr/local/...,
you would simply use /usr/local/... instead.
Setting Permissions
After you have uploaded your script or have created it on-line, make
sure you give the script permission to execute. In a UNIX environment,
each file has a specific mode or set of permissions which determine
who can read or write to the file as well as who can execute the file
(if anyone). Setting the "execute bit" on a file is easy to do. You
can either use iManager
or you can Telnet or SSH
to your Virtual Server and type the command
% chmod +x FILENAME
where FILENAME is the name of your
script. If a script does not have execute permissions, your web server
will report a "403 Forbidden" server error when it attempts to execute
the script.
Common Problems with Perl Scripts
- Failure to upload your Perl script in ASCII mode.
Perl scripts, unlike compiled executables, are plain text files.
Plain text files should be transferred from your local computer
to your Virtual Server using ASCII mode (not BINARY mode). Failure
to transfer your Perl scripts to your Virtual Server in ASCII mode
may result in 500 Server Errors.
- Improper path specification of Perl interpreter.
The first line of a Perl script indicates the path name of the
Perl interpreter. In the Virtual Server environment, the correct
specification of your Perl 4 interpreter is /usr/bin/perl.
If you downloaded a Perl script from a third party source,
the Perl interpreter is most often defined based on the author's
host environment which may be different from the Virtual Server
environment (/usr/bin/perl is a fairly common however).
- Using a Perl4 interpreter for a Perl5 script.
If you have uploaded a Perl5 script to your Virtual Server, you
will need to install
Perl5
on your Virtual Server as well.
You would then want to be sure to specify the correct location
of the Perl5 interpreter in your script - which is
/usr/local/bin/perl.
Troubleshooting 500 Server Errors
If you encounter the enigmatic "500 Server Error" when you execute your
scripts, the best way to diagnose the actual source of the problem is to
examine your web server's error log. Your error log is typically stored
in your ~/www/logs directory under the name error_log.
To review the server error generated in real time, perform the following
steps:
- Telnet or SSH to
your Virtual Server
- Type the following command:
% tail -f ~/www/logs/error_log
The tail command displays the last part of error_log
file and will print anything appended to the error_log file to
your console window. This in effect give you a real time view of
what is being written to your error log file.
- Using your browser, attempt to execute your CGI script again.
When you do this, the actual error message will be displayed in
your Telnet session.
Some commonly encountered errors with their corresponding solutions are
given below.
| Error: |
|---|
HTTPd/CGI: exec of [CGI PATH INFO] failed, errno is 2
|
| Analysis and Solution: |
|---|
|
The first line of your CGI script failed to specify the correct location
of the interpreter. If your script is written in Perl, please see the
"Common Problems with Perl Scripts" section above for the proper first line
definition of the Perl interpreter. If your Perl interpreter definition
is correct, it is very likely that you uploaded the script in BINARY mode
from your Windows machine to your Virtual Server. If you originally
uploaded the script in BINARY mode, re-upload the script in ASCII mode to
correct the problem.
|
|
| Error: |
|---|
HTTPd: malformed header from script [CGI PATH INFO]
|
| Analysis and Solution: |
|---|
|
Your script is not printing out a proper header response. When a CGI
is executed, it communicates back to the web server a message which is
divided into two parts: the header and the body. The header typically
tells the web server the "content type" of the data that will be sent
as the body of the response. The header and body are separated by a
single blank line. An example of a CGI response is shown below:
Content-type: text/html
<html>
<head><title>Title</title></head>
<body bgcolor="white">
Hello world!
</body>
</html>
The "malformed header from script" error message indicates
that your script is not properly returning the header portion of the
response. You may not have misspelled "Content-type", not supplied a
valid type (such as "text/html"), or failed to print out a blank line
to separate the header from body of the response.
|
|
|
