CGI and PHP scripts
On the SRCF’s webserver, you can run CGI and PHP scripts! What’s more, we have a brilliant system in operation which allows even your PHP scripts to run as ‘you’ rather than as the webserver. Read on for details.
Location of your CGI files
For personal users, PHP scripts must have a filename ending with ‘.php’ and can be placed anywhere in your public_html directory. CGI scripts must have filenames ending ‘.cgi’ and can also go anywhere in public_html.
For group accounts, both of the above methods also work, however
there is an additional method of running CGI scripts which is to place
them in the cgi-bin directory in your group account user area (i.e. not
in public_html). If you do this, the script names do not need to end
‘.cgi’. The URL to access CGI scripts in the cgi-bin directory is
https://<groupname>.soc.srcf.net/cgi-bin, where <groupname> is the
group account name.
For personal users, both PHP and CGI scripts will run as you, not as the web server’s user id.
For group accounts, rather than running CGI/PHP scripts as an individual, we have introduced a UNIX user for each group account. This user cannot log in, however it is used as the user under which all group account PHP/CGI scripts are run. Outgoing email generated by group account CGI/PHP scripts will, by default, appear to come from <groupname>-email@example.com. See Group email addresses.
Note that any CGI/PHP script which hogs the CPU for more than 2 minutes will be terminated by the system. This should not affect anything other than out-of-control scripts, as CGI/PHP scripts typically execute in a few seconds. It is a measure to prevent the server being excessively slowed down by buggy scripts which go into an infinite loop.
For personal users, CGI scripts must be readable and executable by you, and must be owned by you. PHP scripts must be world-readable (but to keep database passwords secret, see the next question). For example:
spqr2@pip$ ls -l -rwx------ 1 saw27 saw27 238 May 5 19:33 env.cgi -rw-r--r-- 1 saw27 saw27 265 May 13 19:34 phptest.php
CGI scripts and PHP scripts belonging to a group account must have their system (UNIX) group owner set to that of the group account. CGI scripts must be system group readable and executable. Group account PHP scripts must additionally be world readable (but to keep database passwords secret, see the next question). For example:
spqr2@pip$ ls -l -rwxrwx--- 1 saw27 casi 238 May 7 23:49 env.cgi -rw-rw-r-- 1 saw27 casi 265 May 14 23:06 phptest.php
We recommend that you ensure that group account files are group-writable, so that other admins of the group account can edit them (not least, when your own personal account expires).
PHP scripts must be world-readable. This requirement is artificially imposed because we felt that if we didn’t require world readability, users might be caught out by assuming that if something (other than a CGI script) is not world readable then it’s not accessible on the web, which wouldn’t be the case for PHP scripts. But it’s easy to get round: put your secret information in a separate file which is not world readable (but is system group readable), and include that file from your main PHP script.
By default we have a maximum memory limit of 64MB set for PHP scripts.
You can override this by placing a file called
php_override.ini at the
top level of your site containing, for example,
memory_limit = 128M.
Please consider the memory requirement of other users, system processes, etc. before doing this.
Turn CGI off
Several kinds of file will automatically be interpreted as CGI scripts, and so the CGI handler will try to run them when you visit their URL, even if you just wanted to download them. The following will turn off CGI handling for Python scripts, displaying them as plain text instead:
AddHandler default-handler .py AddType text/plain .py
Put those lines in a
.htaccess file in the same directory as your
python files, and they will no longer be considered CGI scripts. You can
do a similar thing for other file types by changing the
.py to, for
Last modified on Monday Feb 28, 2022 by Richard Allitt