|
There
are several programs that enable you to get more information
from your Virtual Server. The following is a list of useful
commands:
The above commands are
explained in the following sections.
Using which
The Which program
looks through the various paths in your .cshrc
file (a configuration file in your $HOME directory)
and returns to the path of the first program that matches
the which query. The following is an example
of what a .cshrc path might look like:
set path = (/bin /usr/bin
/usr/local/bin ~/bin ~/usr/bin ~/usr/local/bin)
The tilde ("~")
is another way of specifying $HOME (your home
directory). So, in the above example, entering which
sendmail tells the Virtual Server to search for
the program sendmail in the /usr/home/login_name/bin/
directory. Since the program is there, it returns:
% which sendmail
/usr/home/login_name/bin/sendmail
Using whereis
There are other methods
for checking which program is run. One way of checking
is called whereis. It checks a different set
of paths than the which command to find its programs,
so the same test yields a different result:
% whereis sendmail
/usr/sbin/sendmail
In this instance, the
physical server's sendmail is found (/usr/sbin/
was checked before ~/bin). Why is this important?
When the scripts you write run from a web page instead
of a Telnet prompt, the paths are different. The scripts
no longer have access to libraries or directories above
the $HOME directory when run from the web server.
This is the case even though with Telnet you do have
access to libraries and directories. When scripts are
run from, for example, a web server, /usr/home/login_name
is changed to simply "/", and your
script cannot get above this directory to access any
part of the physical server.
For example, if you were
to write a script with the path /usr/sbin/sendmail
the Virtual Server would begin looking in /usr/home/login_name/
to try to find the path /usr/sbin/sendmail. Since
it does not exist on your Virtual Server by default,
the path /usr/home/login_name/usr/sbin/sendmail
is not present. Therefore, your script would terminate
with an error unable to find sendmail.
The problem escalates
if you were to write a script with the path to sendmail
as /usr/home/login_name/bin/sendmail. When the
script executes it looks in the $HOME directory
(as it is now root "/") to find /usr/home/login_name/bin/sendmail.
Or to make the search more clear, it tries to find /usr/home/login_name/usr/home/login_name/bin/sendmail.
This path also does not exist.
Note: When programming
for a Virtual Server, remember that the Virtual Server
assumes the $HOME directory as the virtual root
directory, and your pathing to sendmail in this
case would just be /bin/sendmail. Then, when
the script runs, it tries to find $HOME/bin/sendmail
(/usr/home/login_name/bin/sendmail). Since this
is present, your script runs as expected.
Specifying Paths
Because your CGI scripts
operate in the virtual environment, you need to author
your script accordingly. Specify pathnames in your CGI
scripts relative to your home directory.
For example, in your
script you may want to do the following from a file
in your directory structure:
Note: Instead
of specifying a pathname that begins with /usr/home/LOGIN/usr/local/...,
use /usr/local/... to access the file.
Setting Permissions
After you have uploaded
your script or have created it online, 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, or execute the file (if anyone).
Setting the "Execute
Bit" on a File
- Connect to your Virtual Server via Telnet or SSH.
- From the command
prompt, type:
% chmod +x FILENAME
FILENAME is
the name of your script. If a script does not have
execute permissions, a 403 Forbidden server
error is reported when it attempts to execute the
script.
Installing Perl5
Perl5 in installed automatically
on your Virtual Server, but if for some reason you need
to reinstall it, here are the instructions for doing
so. From the Telnet command prompt, type:
% vinstall perl5
Note: The above
command is installing the tar file from the physical
server's /usr/local/contrib/ directory to your
Virtual Server.
The installation places
Perl5 (with all the standard libraries) onto your Virtual Server in the directory ~/usr/local/lib/perl5/.
The new Perl5 binary resides in the ~/usr/local/bin/
directory. So, the correct path to Perl5 in your scripts
is:
#!/usr/local/bin/perl
When run from the Web,
the script changes to the virtual environment and runs
$HOME/usr/local/bin/perl.
Testing Scripts in the
Virtual Server Environment
At times, you may create
or use a script from someone else, but you want to test
the script in the virtual environment.Testing a Script
From the Telnet command
prompt, append the "virtual" command before
you call the script. For example:
% virtual ./env.cgi
The above command would
run the env.cgi script in the same virtual environment
that exists for the web server. This action forces each
path in the env.cgi script to run in the "virtual"
mode.
Note: Call the
script by entering a ./ The dot is shorthand
that means "start in the current directory."
Troubleshooting Common
Errors
Some of the common errors
you may find in your Error Log file (along with their
corresponding solutions) are described below. In each
case, the error is displayed first followed by an analysis
of the error and possible solutions."500" Server
Errors
If you encounter the
enigmatic 500 Server Error when you execute your
scripts, examine the Error Log of your web server. Your
Error Log is stored in your ~/usr/local/etc/httpd/logs
directory under the name error_log.
Note: Since you
can modify your web server configuration settings to
change the location or name of the Error Log file, ensure
that you go to the appropriate location to view your
Error Log.
Reviewing the Server
Error Generated in Real Time
- Connect to your Virtual Server via Telnet or SSH.
- From the command
prompt, type:
% cd ~/usr/local/etc/httpd/logs
% tail –f error_log
The tail command
displays the last part of error log file while printing
anything appending to the error log. This can be viewed
through your console window. This is a real time view
of what is being written to your error log file.
For example, use your
browser to execute your CGI script again. When you do
this, the actual error message is displayed during your
Telnet session.
CGI Script Error
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 you use a Perl script, please see
the "Common Problems with Perl Scripts" section
above for the correct first line definition of the Perl
interpreter.
If your Perl interpreter
definition is correct, you may have uploaded the script
to your Virtual Server in BINARY mode from your Windows
computer. If this is the case, uploaded the script again
in ASCII mode to replace the BINARY version and correct
the problem.
Malformed Header Error
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 script runs,
it sends a message back to the web server. This message
is divided into two parts: a header and the message
body. The header tells the web server the "content
type" of the data that will be sent as the body
of the response. A single blank line separates the header
and body of the CGI script response. An example of a
valid 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. Some common header errors include:
- Misspelling Content-type
- Supplying an invalid
content type (e.g. text/html is a valid type)
- Failing to print
out a blank line that separates the header from the
body of the response message
|
