In order to use PHP on the Luddy 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:
How do I run CGI scripts on the Luddy school web server?
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:
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:
<Files somefile> |
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.
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:
| chmod go+r yourscript.php |
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:
| acl_open -r -g yourscript.php cgid |
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:
There are several examples of how you can limit access to your web pages in the Access Control List (ACL) Errors section of this page Using PHP on a Luddy web server so please see that page for more details.
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:
| $ chmod go+x cgi-pub $ chmod go+x cgi-pub/somedirectory |
You will also get errors if your cgi-pub directory or php scripts are writable by others so you can make sure this is not a problem by running something like:
| $ chmod go-w cgi-pub $ chmod go-w cgi-pub/somedirectory $ chmod go-w cgi-pub/somefile.php |
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.luddy.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:
| $ ssh cgi.luddy.indiana.edu <... then, once logged into the cgi server...> $ tail -f /var/log/apache2/error.log | grep username |
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:
| $ tail -f /var/log/apache2/error.log |
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.
Access Control List (ACL) Errors - If you are getting a "500 Internal Server Error" and also see errors in the logs (when viewed as in the previous step) that look like this:
| ... SystemException in API_Linux.cpp:51: Could not stat "/u/username/cgi-pub/...": Permission denied |
This can be caused by a rather obscure problem with Access Control Lists (ACLs) that should not affect a lot of people but it is the result of some legacy group changes that have been made over the years. We are not expecting you to necessarily understand this issue but you should be able to fix that problem by just cutting/pasting and running this command on our linux systems(eg silo/burrow):
| find ~/cgi-pub -type d | /usr/local/bin/quote | xargs setfacl -m 'group:www-data:--x,default:group:www-data:r-x' |
If you aren't sure this needs to be run, there is no harm in running it.
Guide manager: Rob Henderson
Last updated: June 2023
