Running CGIs on www.cs.wisc.edu
The web server running on
www.cs.wisc.edu now has the ability to run user scripts. This replaces the functionality available via
cgi.cs.wisc.edu.
www now provides for both
.cgi and
.php scripts to run from a user's home pages.
HOWTO
For instructions on general web page setup and usage, see:
Web Server FAQs
Scripts can be run from your webpage directory by putting an appropriately named file in
~/public/html/ along with your other webpages. The name of the file determines how the file will be handled by the server.
- Make sure that the file is
executable by all users (ex: rwxr-xr-x).
- Name the file according to the following:
- If your script needs the ability to write/read from certain files, you must change the afs acls to allow the access from the webserver,
host:www. Example:
mkdir ~/public/html/foo
fs setacl ~/public/html/foo host:www write
- If you want to further limit the users who can write/read to a directory required by your script, see the 'Xcgi' documentation below.
Rules and policies
See the policies at:
World Wide Web Policies
Most relevantly, all files and scripts
Must Not Interfere with any other user's usage of the web server. This most importantly includes only creating
responsible scripts and reasonably sized files. This is mostly describes as what not to do.
- DO NOT use too much cpu to process each script.
- DO NOT make extremely large files available for download - this ties up the cpu with io wait.
- DO NOT create scripts that attack other processes/ servers/ files/ etc.
- DO NOT create scripts that violate the security of any process/ server/ file/ other user, etc.
- DO NOT do anything in violation of the policies at: CSL Account Policies
If you have any questions on whether or not your script violates CSL policies, email
lab@cs.wisc.edu.
Using Extension For Plain Text Files
If you need to serve files with one of the above extensions but do not want the web server to display them as dynamic content, you need to create a
.htaccess file. This file goes in the directory containing the file in question.
For example, to serve a
.pl file as static content, the
.htaccess file would contain the following:
RemoveHandler .pl
Converting CGIs from cgi.cs.wisc.edu
Scripts currently run from
http://cgi.cs.wisc.edu/scripts/<username> need to be moved to
http://www.cs.wisc.edu/~<username>. The
www server is
linux, while the
cgi server is
solaris. In order to move to the new server, scripts must be moved from
~/public/cgi-bin to
~/public/html. To keep these new files apart from the existing ones, it is probably preferable to move them into a new directory inside of
~/public/html.
Timeline
Because the cgi feature is now allowed on
www.cs.wisc.edu, scripts on
cgi.cs.wisc.edu must be moved by July 1, 2005. On July 1, 2005,
cgi.cs.wisc.edu will be turned off and no longer available.
Copy the Files
To more these files into your web directory at
http://www.cs.wisc.edu/~<username>:
- cp -R ~/public/cgi-bin ~/public/html
- chmod -R o+x public/html/cgi-bin/
Potentially Convert the Files
Once the files are copied over, you may need to edit the files themselves. These edits may only be for anything that specifies a url or directory path. However, because www is a
linux machine and cgi is a
solaris machine, any compiled binaries will also need to be edited and recompiled.
Change html Links
Search for any links in your current html files and change any links from
cgi.cs.wisc.edu/scripts/<username> to
www.cs.wisc.edu/~<username>
It is probably best to do this search by
grep'ing for the line and changing links by hand.
Set up a 'Moved' Script.
You may want to set up a script in place of the script at
cgi.cs.wisc.edu. This can either be complicated or simple. Replace any file in
~/public/cgi-bin with something like the following:
#!/s/std/bin/perl
use CGI qw(:standard);
print header, "\n", start_html(-title=>"Page Moved"), "\n",
p("This script has moved to: ",
"<a href=http://www.cs.wisc.edu/~user/new.cgi>",
"http://www.cs.wisc.edu/~user/new.cgi</a>. "),
"Please update your bookmarks. \n";
Xcgi: Running an authenticated cgi as your www instance
If your script needs access to files that you either:
- Don't want the entire world to be able to directly access, and
- Don't want other CSL hosted scripts to be able to access,
then you probably want to run your script as a subset of your user account. It is now possible to run scripts from your home directory as your
www instance:
<username>.www. In order to do this, read below.
Basic HOWTO
- Rename your cgi to have the extension .xcgi. Example:
mv test.cgi test.xcgi
- Modify the directory you want the script to have read/write access for. Example:
fs setacl ~/public/html/foo <username>.www write
What it does/ How it works
This script handles all the necessary kerberos bits to make the script run as your
www instance. This only works for scripts run from
Your directory (
www.cs.wisc.edu/~<username>) and will only run as
<Your username>.www.
A Note about ACLs and Xcgi
By default, your
public/html directory allows any user to view the contents of a file. If you want to limit this, you remove
system:anyuser and grant
host:www access - this allows the webserver to access your pages. However, xcgi scripts run as
<username>.www. If you've locked down a directory to
host:www, you also need to add access for
<username>.www.
A Note About Projects and Xcgi
In general, the Xcgi functionality is not available for projects unless the project has a user associated with it. If a project has a user associated with it, scripts run from:
www.cs.wisc.edu/~<username>
can be run with the
.xcgi extention as detailed above to run scripts authenticated as
<username>.www.
IMPORTANT: Even if symlinks exist so that www.cs.wisc.edu/<username> is the same as www.cs.wisc.edu/~<username>, the xcgi functionality is only available by using the '~' address.
The xcgi functionality is only available on
www.cs.wisc.edu to actual users. Projects that want cgis run as a specific user must (and currently do) request a separate webserver through the CSL. Setting up a dedicated web server is a relatively quick and easy - setting up that webserver to run with specific afs tokens/tickets is standard.
Questions?
If you have any questions about these processes or functionality, please email
lab@cs.wisc.edu.