Images on this site were compressed using e-Vue MPEG4 technology in 2001, which was groundbreaking at the time for its DRM component and higher compression than JPG, however e-Vue is no more — we are transitioning these images to JPEG for 2004.
The Hierarchy of Directories Almost all Web servers have a folder for each domain name, which is located inside a "sites" directory, or something similar. Learning the correct "directory path" for your domain on the server where your site(s) live is a primary step. You may need to ask your server administrator, or hosting provider, for this info. A typical directory path might be: "/home/sites/site3/web/cgi-bin" where /site3/ in this example might be your username, or your domain name.
Figure 2: Example of Web server account directory structure.
On some Web servers, /web/ might be /public_html/ or similar.
Looking at Figure 2, you can see the "root directory"
of a virtual domain, and the contents of the /web/ directory,
then the /cgi-bin/ directory, where a script lives called "formmail.cgi."
You can also see a second cgi directory called /cgib/ as well
as other directories called /images/ and /backup/. If you have
a "free" hosting provider, meaning any hosting space
where you’re not using your own domain name, you likely won’t
have the ability to use your custom scripts.
Permission Slips
The hardest thing to approach at first is the idea of "permissions."
Every file, directory (folder), and script on a Web server has
two types of permissions. One is ownership, which is a bit complex
and usually requires telnet knowledge (see the Web Hosting glossary
in my article "Points of Presence").
The one that concerns us today is read/write/execute permissions,
which tell the server who may view or execute (run) a script,
and who can write over it. For instance, this controls why some
directories allow you to view all the contents, and some don’t,
and is the most common reason a script doesn’t work once
you install it the first time. Luckily, most FTP applications
allow you to set the permissions of files that you upload to a
Web server. Generally, your scripts will live in the /cgi-bin/
directory.
Looking at Figure 3, using NetFinder on the Mac, you can see the
info on a script I have on a domain. At the bottom you can see
a 3x3 grid showing read, write, execute (right to left), and Owner,
Group, and Everyone (top to bottom). This helps to visualize that
if you were to set the permission on a file as shown, then everybody
could read and execute the file, but only the owner (the person
who uploaded the file: you) has the ability to write to it. Each
type of entity has the potential to read, write and/or execute
a file. For scripts, the most common is rwxr-xr-x (755) as shown.
Figure 3: Example of permissions info for a PERL script.
What makes this so confusing is that some directions for installing
scripts specify the permissions you must set, but some use the
number method (e.g., 755, 666, 777), and some use the literal
UNIX method (e.g., rwxr-xr-x). The way to translate this is to
imagine that the first letters "rwx" mean read/write/execute
for "Owner," then the second three "r-x" mean
that the "Group" has read/not write/execute permission,
and finally, the last three "r -x" refer to "Everyone"
(a visitor to your site). If you look at Figure 4, you can see
some examples of how this translates to the different formats.
Here, a permission of 666 (often used for script data files) would
be rw-rw-rw, meaning anybody could read and write to the file
such as a database, but nobody could execute (or "see")
the file from a Web browser.
Basically, to set
permissions on a file you upload (e.g., "formmail.cgi"
in Figure 2), you use the "set permissions" option in
your FTP software, which gives you a dialog option somewhat like
Figure 3.
The
Nature of the Beast
Figure 4: Conversion chart for permissions.
PERL scripts are actually text files, and must be treated as such.
This means they must be uploaded via FTP in ASCII mode (as opposed
to binary mode), and should only be opened and edited in an application
like BBEdit on the Mac, or TextPad for Windows, which do not introduce
word processor coding (like MS Word does). The main thing needed
to work with scripts is opening the main file (usually scriptname.cgi,
or scriptname.pl) and following the comment lines found at the
top of all PERL scripts, and setting the path to directories as
needed. As mentioned above, you must know the "directory
path" on your server, so that you can edit the example variables
within either your main script, or the supplied configuration
(or "config") file.
Every script will have options to set, and will typically include the path to the main PERL application on the server, as the first line in the script (often /usr/bin/Perl). In a typical config file, or script header, you will set the path to the script on your server, so that it can find itself and any of its support files, this is usually the "directory path" to your cgi-bin. Some scripts also ask for the "URL path" which is "http://www.yoursite.com/cgi-bin/filename.cgi" or how a Web browser would find the script on the Internet. If the script uses E-mail for any purpose, you need to also check for the proper location of "sendmail" as it can vary from /usr/bin/sendmail to /usr/lib/sendmail (the former is more common). Sendmail is the common method of sending E-mail on UNIX/Linux.
The "readme.txt" file, which usually comes with any script, will also indicate other variables you may need to set, such as a "referer," which would be your domain name, and/or IP (Internet Protocol) address, A referer variable prohibits others from using your script from another location on the Web. Other variables you might set could be the E-mail address to show in the reply-to when sending E-mail, locations of other files such as images, and sometimes passwords.
