Return CGI Library

In the most basic webserver configuration, all programs run under the userid that the web server runs under. For a shared virtual hosting system like ours, that is unacceptable. If you and your neighbour both write scripts that create output files, you can't stop his script from over-writing your file! Any files that your script creates aren't owned by your userid, they're owned by the web server userid, and this is a nuisance because you have to change the access permissions to let the web server ID write into your directories.

The first fix to this solution (mid 90s) is described in detail below. It is a "cgiwrapper", a script that can change userids and your your script under your userid. Since then, authors of the Apache webserver provided a similar script which is better integrated into the webserver and is consequently much easier to use. All you need to do (on our servers) is make sure your filename ends in .cgi and that chmod'ed to be executable. There are two advantages to using the cgiwrap approach described below: 1) if your script doesn't run correctly then the debugging help can be very usefull, and 2) since all cgiwrap files need to be in a special directory, we can provide a script to set the execute permissions.

Please note the debugging notes :-).

The solution: a "wrapper".

By using a special "wrapper" program we can get around these problems. The wrapper program "changes" to your userid, and runs a program that you specify on your behalf.

The Details:

There are four steps:

Create the cgi-bin directory.

The relevent directory is called cgi-bin and is located off of your home directory. For example: if your virtual webserver is called abc.com, then we probably created an abc directory for you to put your HTML files in. Create a directory BESIDE the abc directory called "cgi-bin" to put your scripts in. This would leave you with (at least) the directories cgi-bin and abc in your "home directory".

(This is non-standard. On most servers (non-BareMetal), it would be a "cgi-bin" under your public_html directory.)

Create a test file.

Place the following text in a file in that cgi-bin directory.

#!/usr/bin/perl
print "Content-type: text/html\n";
print "\n";
print "Hello WORLD!<P>\n";
print "<blink>It works!</blink>\n";

It is important to get the spacing right. The first line must start with the #!/usr/bin/perl (no leading blank lines or spaces).

You MUST upload cgi scripts in TEXT MODE. (Text mode, ASCII, whatever your FTP program calls it. NOT binary, and preferably not automatic.) If you get this wrong, the trailing carriage return causes the following strange error:

CGIwrap Error: System Error: execv() failed

Error: No such file or directory (2)

Mark the file as executable.

This is pretty simple. Just point your browser at:

http://your.domain/sec-bin/chmod

You'll be asked for your userid and password. Enter them. The script will find your cgi-bin directory based on your userid and mark all the files in it as executable.

Note: There are some security implications if you store datafiles in your cgi-bin directory. We suggest that you store datafiles in a different directory.

(Note: the /sec-bin/chmod script will take a directory parameter if needed. e.g. visiting http://baremetal.com/sec-bin/chmod/test will mark the files in your 'test' directory as executable.)

Run the script!

Let's use the above script as an example. It simply prints out a message, so we can call it like any other page.

The wrapper program (/cgi-bin/cgiwrap), needs to know at least two things: the user who owns the file (USER), and the file name (FILE). We specify these as follows:

/cgi-bin/cgiwrap/USER/FILE

If your script doesn't run, be sure to check the debugging tips at the bottom of the page.

That's all.

Well, that's almost all.

Here's the documentation that "ships" with cgi-wrap. This contains information on things like how to get your own copy, and how to subscribe to the cgi-wrap mailing list... most of this is targetted at system administrators.

Here's the "man page" for cgi-wrap.

Here are some (perhaps) helpful links:

• CGI Overview
• Using Forms

Debugging tips:

As referred to in the cgiwrap-man page, using /cgi-bin/cgiwrapd/USER/FILE (note the extra "d" in cgiwrapd) will cause cgiwrap to print out it's own header info and run your script after that... this can be a big help if your script isn't producting a Content-type: header, or if PERL is choking on your script.

Server Error - This pretty much means that your script didn't produce a valid Content-type header. Use cgiwrapd here to see what your script DID spit out. Note that a script that produces NO output, will cause this error (and correctly so, ALL scripts must print the Content-type: header).

CGIwrap Error: Script File Not Found! You've gotten your file or directory names mixed up. cgiwrap can't find the script you're trying to run.

CGIwrap Error: System Error: execv() failed
Error: No such file or directory (2) - this means you got the path to the script interpreter wrong. Usually that's a result of having uploaded in binary mode instead of text mode.

Failing that: perl lives in /usr/bin/perl on all machines. [While we're at it... sendmail is /usr/sbin/sendmail ;-]

CGIwrap Error: System Error: execv() failed
Error: Exec format error (8) - Assuming this was supposed to be a perl script... it means you probably got the first two characters wrong. They are supposed to be #! ... but you likely got a blank line or some blanks in front of it.

CGIwrap Error: Script is not executable. Issue chmod 755 This one is pretty self explanitory, except that we've got an easier solution... Just jump over to http://your.domain/sec-bin/chmod ... you'll be asked for your userid and password... the script will use your userid to mark all the scripts in your cgi-bin directory as executable... (and while we're at it... chmod 700 works fine... the scripts run under your userid, so the group and other permissions are redundant).