In order to use PHP on the SICE server you will need to first set things up exactly as you would for CGI script usage. So, please see the following KB article and set things up as described in the Configuration section there:
Once that is done, you can set up PHP files (with a .php file extension) in the same location as described for CGI scripts.
Your php scripts must meet the following minimum requirements:
File Extension - By default, scripts must end with the .php extension. If you want to have a php file without the .php extension, you can do this by creating a .htaccess file in the same directory where the php file is that contains something like this:
In this example, you would replace somefile with the name of your php script. If you want everything in the directory to be treated as php regardless of the file extension, then just include the SetHandler line in your .htaccess file without the Files lines.
Permissions - The script must be readable by the web server running on the CGI server (user apache and group apache, wwwd, or cgid). The easiest way to accomplish this is to make the file world readable with something like:
If that is not acceptable in your case, you can make the file readable by either the cgi user or the cgid group in a couple different ways. One convenient way to do that is using Access Control Lists (ACLs) and the acl_open script can be used to help with that process. For example, you could make yourscript.php readable by the CGI server group (cgid) as follows:
- Reading/Writing Files - If your php script needs to read and/or write other files, these files must be readable or writable by the owner of the php script. The server uses suphp to run php scripts as the owner of the script.
All php scripts run using suPHP which means that the php is executed as the user who owns the php file. This imposes the following constraints:
- No World-Writable Php - Scripts that are world-writable (eg. have the 'other' write permission bit set) will not be executed. Furthermore, the directory containing the script and the parent of this directory must not be world writable.
- Directory ownership restriction - The owner of the directory that your php files are in must match the owner of the php files itself. Furthermore, the parent directory must also have the same ownership.
These troubleshooting tips apply only to PHP scripts and not CGI. See the CGI Page for more information about running CGI scripts.
There are a number of things that can go wrong when setting up your php scripts. Here are some tips and common pitfalls you are likely to run into:
Use the CGI/PHP Verification Tool - We have an On-Line Verification Tool that you can use to check your URL. It will report many common errors and give you tips on how to fix them. It is not capable of detecting all possible problems, but is definitely the first place to start.
Permissions Problems - The permissions on your php scripts need to be set so they are readable by the web server. In addition, the full path leading up to the script must be searchable by the apache server. The easiest way to do this is to make sure your cgi-pub directory (and any sub-directories you create there) are world searchable. This can be done in a number of different ways but one simple way is as follows:
You will also get errors if your cgi-pub directory is writable by others so you can make sure this is not a problem by running something like:
- suPHP Errors - See the above section on suPHP for information about possible problems you may encounter when running under suPHP.
- Incorrect Script Naming - PHP scripts must end with .php filename extension.
Coding Errors and Log Access - In many cases, if you are getting server errors it is just due to errors in your php code. You can determine the cause of coding problems by looking at the apache error logs. In order to view the error log output you will first need to ssh to the cgi server, cgi.soic.indiana.edu. Once you are logged in there you may find it helpful to tail the error log while you access your page looking for errors. For example:
In this example, the grep for your username (and you need to replace username with your actual username or the username of the account in which the php files reside) is done so you only see your errors and not the errors from every user of the system. Note that not all script errors will contain the username of the user who owns the scripts. If you aren't seeing the appropriate errors this way, you can always view all errors with:
Just keep in mind that this is likely to give you a high volume of errors that you will have to sort through.
Not all possible errors will show up in this log file but you should see errors related to many of the mistakes you are likely to make. Similarly, you can also tail the access_log file in the same way if you want to watch the accesses to your page and not just the errors. Just substitute "error_log" with "access_log" in the above examples. In this case your username will appear in all accesses so you almost certainly want to use the pipe/grep of your username as shown above.