HOWTO: CGI and PHP scripts on Fog and Hills
Table of Contents
- CGI and PHP script features
- How to adapt your existing HTML pages to use the new-style URLs
- Option One: Editing your HTML files to add missing path information
- Option Two: Relocating your scripts to sync them with existing links
- A Hybrid Option
- Secure directory and file permissions
- CGIWrap's optional direct URLs
- Debugging CGI and PHP scripts with CGIWrap
The Hills and FOG web servers have been reconfigured so that CGI and PHP scripts no longer
have to be restricted to the
php sub-directories of
addition URLs have been simplified — they are now constructed literally, without
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.
- CGI and PHP scripts can be located anywhere inside of a user's
- Script URLs are now literal and clear; they no longer have implied
phpcomponents 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:
- 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.
- Directories containing CGI and PHP scripts can also have restrictive permissions of
0700. Regular files in directories with
0700permissions 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
/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.
- Edit your HTML pages and modify the links that refer to your scripts.
- 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_htmlwith the same name as files in your
cgi-bindirectory, 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
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
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
public_html/hello.cgi. This can be done several ways:
- Use a GUI SFTP client such as FileZilla to move your scripts from
- Use the Unix
mvcommand 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
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
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
|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
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
CGIWrap's optional direct URLs
You can also create URLs that access your scripts as arguments to the
hello.cgi directly using
public_html/php/cs130a/lab8.php directory using
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
Debugging a PHP script