Setting up a homepage
The UTCS web host, www.cs.utexas.edu, runs Ubuntu Linux. The HTTP server software is Apache 2.2. When you are reading documentation about working with a Web server, be sure that the information is appropriate to our environment, since every Web site has its own features and peculiarities.
You actually don't need to know much about how the server works. You do need to know where and how to create your Web documents so that the server can find them and make them accessible to the world. The steps to do so are fairly straightforward:
- You must have a UTCS UNIX account.
- If your login ID is, say, username, an empty public Web directory has already been created for you in your home directory: /u/username/public_html. This directory is accessible by NFS from any UNIX host on the CS production network. You should leave this directory world readable (or at least world searchable), and make sure your home directory is also at least world searchable. This directory is where you will create and maintain your personal Web documents.
- In your Web directory, /u/username/public_html, you need to create an index file. This file will be what is generally referred to as your "home page". A directory should contain only one index file. Depending on use, it might be named any of: index.htm index.html index.shtml index.cgi nph-index.cgi index.php. Your public_html directory must be executable (chmod o+x ~/public_html). All html files within this directory must be readable as well (chmod o+r ~/public_html/*.html).
(You may use "welcome" instead of "index" if you wish, and either may be capitalized as "Index" or "Welcome".) This file, like any Web file you wish to publish, should be world readable. This filename is also used as a default in the context of a URL. In the example above, opening the URL http://www.cs.utexas.edu/~username/ would actually cause the index file in the directory /u/username/public_html to be delivered if it exists -- otherwise, a listing of the directory would be produced.
TIP: If you don't have an index file, and you don't want a directory list to be produced, create a world readable .htaccess file in the directory and in it put this directive: Options -Indexes
TIP: For historical reasons, we create a symbolic link /u/www/users/username pointing to your public_html directory. This alternate path can be referenced by the URL http://www.cs.utexas.edu/users/username/. This use is deprecated other than for research project web pages with no corresponding user account.
- When the once-nightly Web batch job notices that you have created an index file in your public Web directory, it will automatically add a link for your home page to the master page for your UNIX group, if your account's primary group is dept, grad, undergrad, or guest. This step is not necessary for your page to be accessible, it just provides a convenient link to your page. Your public_html folder must be world readable for this link to be created.
Scripts and SSIs
CGI scripts for the UTCS web must be written in a portable interpreted language such as Shell, Perl, Python, or PHP5, or in a language such as C or C++ compiled for the server host platform (Intel Linux). Most of the usual UNIX software is available to a script, depending on the script's notion of $PATH.
Scripts are run by the server as the user www, with a minimal environment and no special user permissions. Thus, such a script must be world-executable and in a world-searchable directory if the server is to be able to run it. If it is absolutely necessary to your application, a mechanism does exist for running a .cgi script (but not .php) with the permissions of your UNIX user account.
When you install a CGI script in your Web area, it should have the filename extension .cgi. Scripts returning their own special header information, e.g., a 204 "No response" status code, should have the prefix nph- (for "non parsed headers"). A script does not have to be installed in any particular directory in your Web area (e.g. "cgi-bin"), although some people find it convenient to do so.
Mod_php scripts should have the extension .php and will be processed by a PHP5 interpreter rather than by the CGI handler.
A public area is available for user-maintained scripts (and other Web info) serving the common interest. The UNIX directory is /u/www/pub. This area is accessible by members of the public UNIX group. Users can request membership in this group by sending mail to firstname.lastname@example.org; they should also announce their intention to install and maintain scripts by sending mail to email@example.com.
An alternative mechanism for command execution is provided by server-side includes, or SSIs. SSIs allow you to include information in a document dynamically. Examples of SSI directives might be:
- <!--#exec cmd="command to execute using /bin/sh" -->
- <!--#include file="relative path of file to include" -->
The syntax is important; there should be no space between the components <!-- and #exec. When a document is delivered, the output of the specified directive will be inserted in the document at the point of the directive. A file should have the extension .shtml to enable its use of SSIs; we do not enable the XBitHack by default. The server does not understand SSI directives which are part of the output of a CGI script; the script would need to do all of the processing. See the list of SSI Basic Elements for more information.
Sometimes, you may wish to restrict access to certain documents in a directory, or configure the way in which they are delivered. This can be accomplished by using dynamic configuration files. Typically, this involves creating a file called .htaccess in the directory and placing access control directives in it.
For more information, see the server documentation on using the basic authentication module.
TIP: The /usr/bin/htpasswd program may be helpful in managing auth password files.
Web use policy
Web publishing at UTCS, like any other use of the department's computing facilities, is subject to certain guidelines and restrictions. You should take time to familiarize yourself with the applicable policies. You are solely responsible for the content and impact of your Web pages.
In particular, you may wish to review: