HOWTO: CGI and PHP scripts on Fog and Hills

Table of Contents


The Hills and FOG web servers have been reconfigured so that CGI and PHP scripts no longer have to be restricted to the cgi-bin and php sub-directories of public_html. In addition URLs have been simplified — they are now constructed literally, without the hidden cgi-bin and php components that were added behind the scenes in the past.

While virtual links are valuable for generating user-friendly or semantically useful URLs, they also are non-intuitive and create unnecessary confusion. After discussion, it was agreed that Hills and Fog URLs should be more intuitive and literal. To achieve these goals, CGIWrap, the program that manages CGI and PHP scripts on Fog and Hills, was reconfigured to use literal URLs.

CGI and PHP script features

As of Jan 7, 2015, Fog and Hills CGI and PHP scripts have these features.

  1. CGI and PHP scripts can be located anywhere inside of a user's public_html directory.
  2. Script URLs are now literal and clear; they no longer have implied cgi-bin or php components as in the past. If a script is located in:

    it's URL will be what you would expect it to be:

    If a script is in a sub-directory:


    it's URL will be clear and intuitive:
  3. For highest security, permissions on scripts can and should be restrictive, 0700, so that only you can read them. These permissions prevent other users logged in to the system from reading your code.
  4. Directories containing CGI and PHP scripts can also have restrictive permissions of 0700. Regular files in directories with 0700 permissions will not be visible to the web server — move regular files your want to serve to a directory with normal directory permissions.

NOTE: For Hills and Fog URLs, the expression ~UserId is interpretted by the web server as /students/UserId/public_html for student accounts and as /users/UserId/public_html for faculty accounts.

How to adapt your existing HTML pages to use the new-style URLs

With the changes in how URLs are processed, many of us will find that the old-style links embedded in our HTML pages no longer work. There are two ways to fix this problem. Both methods are one-time fixes.

  1. Edit your HTML pages and modify the links that refer to your scripts.
  2. Change the location of your scripts on the file system so that their path will map correctly to the existing URLs in your HTML pages.

TODO Backup your files

Before making any changes to your file system, it's always smart to make a backup. If there are files in public_html with the same name as files in your cgi-bin directory, protect them from being overwritten by either renaming them or by moving the out of the way.

Option One: Editing your HTML files to add missing path information

Edit the HTML files that contain links to your CGI of PHP scripts by adding the missing "cgi-bin" or "php" to URLs that was previously added behind the scenes. For example, you would edit these old-style CGI and PHP URLs to include the missing cgi-bin and php components of the path:

Old style
<a href="/~YourId/hello.cgi">Click me!</a> 
<a href="/~YourId/hello.php">Click me!</a>

Add in "cgi-bin" for CGI scripts and "php" for PHP scripts.

New style
<a href="/~YourId/cgi-bin/hello.cgi">Click me!</a>
<a href="/~YourId/php/hello.php">Click me!</a>

If you have many HTML files to edit, such as complicated documents on Insight, this may be a tedious task. Option 2 may be preferable.

Option Two: Relocating your scripts to sync them with existing links

Relocate your CGI and PHP files :: Move all of the files in the public_html/cgi-bin directory, including any sub-directories of cgi-bin, up one directory into public_html. With this method, the URLs in your HTML pages will automatically link correctly once the file location literally matches the existing existing URLs in your HTML pages.

For example, move hello.cgi from public_html/cgi-bin/hello.cgi to public_html/hello.cgi. This can be done several ways:

  • Use a GUI SFTP client such as FileZilla to move your scripts from cgi-bin to public_html.
  • Use the Unix mv command to move the files. After logging in to the server via your SSH client:
    # Move from      cgi-bin          to public_html
    mv ~/public_html/cgi-bin/hello.cgi ~/public_html

If you have many HTML pages that need editting, this option is appealing — moving files is a simpler process than editing many HTML pages. However, when moving files, you should take precautions not to overwrite any same-named files in public_html.

A Hybrid Option

You may also decide to use a strategy combines both options. You can leave some scripts where they are by editting the HTML files that link to them, while moving other scripts so that the the existing URLs automatically sync up with them.

Secure directory and file permissions

Permissions for Hills and Fog CGI and PHP scripts should be set to strict permissions of 0700 so that the will not be readable by other users logged in to the server. It's not uncommon for scripts to contain private information such as passwords. Scripts also read files — configuration files, password files, etc. — that should also have restrictive permissions. In addtion, files "required" or "included" by CGI and PHP scripts should also have restrictive permissions.

File type Permissions
CGI/PHP scripts; private files read by scripts 700
Directories with CGI/PHP scripts (no regular files) 700
Dirs with mixed CGI/PHP and regular files 711
Regular sub-directories inside public_html 711
Regular files such as HTML, images, JavaScripts, CSS, etc. 644

If you plan to used directories that contain both CGI and PHP scripts and regular files, CGI and PHP scripts should always have 0700 permissions. Regular files will have 0644 permissions.

CGIWrap's optional direct URLs

You can also create URLs that access your scripts as arguments to the cgiwrap and phpwrap programs.

Invoking hello.cgi directly using cgiwrap:

Invoking public_html/php/cs130a/lab8.php directory using phpwrap:

Debugging CGI and PHP scripts with CGIWrap

When your scripts are failing or creating mysterious CGIWrap errors, you can often find the cause by invoking CGIWrap's debugging modes: cgiwrapd for CGI scripts and phpwrapd for PHP scripts. The output will show all components of the HTTP request as well as CGIWrap's construction the script's URL.

Debugging a CGI script with cgiwrapd

Debugging a PHP script