IN THIS SECTION:
CGI-bin General Information | Where
To Put CGI Scripts
Paths
to Date, Mail, Perl, etc. | How
To Set Permissions
Permission
Definitions | Troubleshooting
CGI-bin Problems
CGIwrap
- Secure Server CGI Wrapper | Back
To Table Of Contents
CGI-bin General Information
CGI stands for "Common Gateway Interface," a fancy name meaning computer
programs running on the web server that can be invoked from a www
page at the browser. The "bin" part alludes to the binary executables
that result from compiled or assembled programs. It is a bit misleading
because cgi's can also be Unix shell scripts or interpreted languages
like Perl. CGI scripts need to be saved in ASCII format and uploaded
to your server's cgi-bin in ASCII or text format. This is very important.
This chapter provides you with information needed when configuring
scripts we have not provided and other information regarding your
CGI-bin.
Back
to the top
Where to put CGI scripts
Put your cgi-bin scripts in the www subdirectory named "cgi-bin".
Back
to the top
Paths to Date, Mail, Perl,
etc.
Here are your paths to the common server resources that CGI scripts
often require:
Date: /bin/date
Sendmail: /usr/sbin/sendmail
Perl5: #!/usr/bin/perl
Serverpath: /home/username/domain_name-www/cgi-bin
Root path: /home/username/
(puts you in your the root of your account)
Domain directory: /home/username/domain_name-www
(puts you in your www directory)
Cgi-bin path: /home/username/domain_name-www/CGI-bin/filename
(puts you in your CGI-bin)
NOTE:
Replace domain_name with your domain name. Do not
include the domain extension (.com, etc.) in the above listed paths.
If you domain name is www.acme.com and your assigned username
is john, the path to your WWW folder would be: /home/john/acme-www.
Back
to the top
How To Set Permissions
There are three different ways to set permissions for your files and
directories within your account. 1) File Manager, 2) FTP, and 3) Telnet.
We DO NOT encourage the use of Telnet if it is only being used for
setting permissions and will forego its explanation here.
Setting Permissions
Using Your File Manager:
Log into your Control Panel and then click on File
Manager. You will now see a list of directories within the root of
your account. Since all of your html files and subdirectories are
uploaded and created within your www directory you need to click on
the directory labeled "www".
Once inside your www folder, you will see, as in all directories,
the first column is the Permissions Column, click on the link pertaining
to the directory or file that you wish to set the settings for and
the Permissions screen will open as seen in the screen shots below.
(Refer to Permission Definitions further down this page for an explanation
of settings.
Setting Permissions using Fetch for MAC:
If you have Fetch for the Mac, you have an easy way to change permissions.
Go to the file you want to change the permissions on, and highlight
it. Under the Remote menu, select Change Permissions. A window will
pop up showing the current permissions for the file you had highlighted,
as shown in the screenshot below. Click on the boxes to change permissions
as needed. (Refer to the Permission Definitions further down this
page for an explanation of settings.
Setting Permissions Using WS_FTP for Windows:
WS_FTP accomplishes the same task as above. Just highlight the file
you want to check, and right-click on it. A menu will pop up, then
select CHMOD. You will see the window as shown below in the screenshot
we've provided. Click on the appropriate settings as needed. (Refer
to the Permission Definitions further down this page for an explanation
of settings.
Back
to the top
Permission Definitions
Owner = the files users (you)
Group = the files group
Others = others
Permissions Definitions:
r = read access
x = execute access
w = write access
Numerical Definitions:
r = 4
x = 2
w = 1
You will come to recognize, if you do not already, Chmod as a word
used for changing Permissions from within Telnet or your FTP client.
Some scripts will tell you to chmod 775 (for example). When using
the numeric system, the code for permissions is as follows:
4 + 2 + 1 (rwx) = 7
The first number applies to Owner, the second number applies to Group,
and the third number applies to Others. Therefore the first 7 of the
chmod 775 tells Unix to change the Owner's permissions to rxw (because
r=4 + w=2 + x=1 adds up to 7, this giving the Owner Read, Write, and
Execute Permission. The second 7 applies to the group, this giving
the Group Read, Write, and Execute Permission, and the last number
5, refers to Others (4 + 1= 5), giving Others only Read and Execute
Permission. The permissions for chmod 775 look like this: rwx rwx
-rx.
Permissions are always broken up into three groups of letters, however
if there is a dash, this dash simply means that Permission wasn't
given for that particular function, for example in the chmod 775,
Permission to Write was not given to Others.
Remember: the first 3 letters always apply to Owner, the second 3
apply to Group, and the third 3 apply to Others.
Back
to the top
Troubleshooting CGI-bin
Problems
Below are solutions to some of the more common CGI script problems.
When I activate my CGI
program, I get back a page that says "Internal Server Error. The server
encountered an internal error or mis-configuration and was unable
to complete your request."
This is generally caused by a problem within the script. Check your
script settings again to see that you have entered the correct server
information and have set the correct permissions for the script. If
this information is correct, you'll need to contact whoever wrote
or is distributing the script for further assistance.
I am being told "File Not Found," or
"No Such File or Directory."
Upload your Perl or CGI scripts in ASCII mode, not binary mode.
When I test my Perl script
in local mode (by Telnet), I have the following error: "Literal @domain
now requires a back slash at myscript.pl line 3, within string. Execution
of myscript.pl aborted due to compilation errors."
This is caused by a misinterpretation by Perl. You see, the "@" sign
has a special meaning in Perl; it identifies an array (a table of
elements). Since it cannot find the array named domain, it generates
an error. You should place a back slash (\) before the "@" symbol
to tell Perl to see it as a regular symbol, as in an email address.
I am getting the message "POST not implemented."
You are probably using the wrong reference for cgiemail. Use the reference
/cgi-bin/cgiemail/mail.txt. Another possibility is that you are pointing
to a cgi-bin script that you have not put in your cgi-bin directory.
In general, this message really means that the web server is not recognizing
the cgi-bin script you are calling as a program. It thinks it is a
regular text file.
Back
to the top
Cgiwrap - Secure Server
CGI Wrapper
We now have a cgi wrapper for the secure server called cgiwrap. We
have configured it to be automatically invoked when you make a call
containing "cgi-domain", like this:
https://host.the-web-host.com/cgi-domain/script.cgi
You can call cgiwrap explicitly with this call, which does the same
thing as the above call:
https://host.the-web-host.com/cgi-bin/cgiwrap/domainname/script.cgi
This assumes script.cgi is in your cgi-bin. You can also use cgiwrapd
in place of cgiwrap to get extra debugging information if there is
a problem. For nph-style scripts, use nph-cgiwrap or nph-cgiwrapd
instead.
Back
to the top
|
