FAS IT’s web site helpfully points out that their servers support PHP “in cgi-mode,” but does not explain what that means. What follows are three fairly straightforward steps for setting up PHP in your FAS web space. This assumes some basic UNIX knowledge. If you lack it, find a friend to help you.
The method described here may not be officially supported (or appreciated) by FAS IT. Since they don’t provide documentation, who knows. Exercise due caution.
- SSH into fas.harvard.edu and create a public_html directory if you don’t already have one. Make sure it has permissions 755. Also make sure your home directory is world executable.
- Copy the PHP binary into your public_html directory (note: this file is nearly 5MB in size and will count towards your quota). Since it is stored on the web servers but not the shell servers, you need to do this by creating a CGI script and visiting it in your web browser. This one does the trick:
#!/bin/sh cp `which php` php.cgi && chmod 755 php.cgi
After using it once, delete it. You should now have a php.cgi executable in your public_html directory.
- Create an .htaccess file to tell the web server how to server your PHP files. It should look like this:
Options +ExecCGI AddHandler application/x-httpd-php .php Action application/x-httpd-php /~youruser/php.cgi
Now create PHP files as you normally would and they should work fine without any special permissions or modifications. Tada!
Copying php itself sounds scary as any security holes or bugs will be stuck there when the system copy gets upgraded.
A few questions/suggestions:
– How does step 2 work? Does the server just execute anything with with the execute bit set? If so, you could just use the shebang notation (something along the lines of “#!/usr/bin/php” or “#!/usr/bin/env php”) at the top of your PHP scripts and run them that way?
– Does “AddHandler cgi-script .php” work? I suppose it doesn’t really matter much since even if it did, you’d still need the shebang so the suggestion above would probably work just as well anyway
– In the worst case, how about symlinking instead of copying, so then at least you’ll always be up-to-date with whatever is latest on the system
Agreed, copying PHP is non-ideal, and it would be wise to repeat the procedure when new versions are released. Since these particular machines are running Dapper, that should be fairly infrequent. As to your other points:
1. The server executes CGI scripts using suexec. A shell script is perfectly valid as a CGI script.
2. The point of this is to remove the need for the shebang line so that one can simply drop in, say, WordPress or MediaWiki or any other standard PHP application and have it “just work.” The current supported method is to use the shebang line in every script and rename all of them to .cgi instead of .php, which is ridiculous for anything larger than a guestbook or formmailer.
3. If you symlink, the php binary is not owned by you, and suexec will refuse to run it.