The short answer to the usual question is, yes, we do have PHP in Apache, and we do have SQL database servers running (PostgreSQL and MySQL) (see UsingDatabases). If you want to use our main Apache server for your dynamic web sites, you must use CGI or another execution method which requires forking a new script process for every dynamic request. There are a number of more efficient ways of doing dynamic page generation (including `mod_some_language`), but they don't work well with running scripts as their owners from a single main Apache instance, which is crucial from a security perspective in a multi-user environment like ours. However, you are free to run whatever web server you want by [https://members.hcoop.net/portal/sec requesting a port for it] and having Apache proxy to it with the `LocalProxy` directive for VirtualHostConfiguration. In the remainder of this page, we'll assume that you don't want to do this. = Security = We have some basic security measures in place to keep your dynamic page generation programs from using enough server resources to produce service outages for other users. * Your CGI/PHP programs can't use more than 100MB of RAM. If they could use arbitrary amounts, they could cause important daemons to crash because of out-of-memory errors. * No more than 100 processes total with a single owning user can be running. Without this, the above limitation would be ineffective, since that limit only applies on a per-process basis. * Your CGI/PHP programs can't run for more than 10 seconds. While an infinite-looping script may sound like it's far from a security threat, it actually is. Apache has a fixed number of child processes that it uses to service requests, and each script monopolizes one of those processes while it's running. If enough scripts run for long enough, then there will be no child processes left, and no other web pages will be served until some children free up. A single infinite-looping script on a popular site could reach this situation very quickly. The specific numbers here, and even more qualitative aspects of the policy, are open to debate. If you find that these constraints prevent you from doing something reasonable, and if you can suggest alternate enforcement mechanisms that still prevent users from stepping on each other, then suggest it on the `hcoop-discuss` mailing list. An alternative is for you to run your own web server to which Apache proxies requests, as suggested near the beginning of this page. In that case, you have much more freedom, but you will still be under the usual resource limits for regular user processes. (See UsingResourceLimits.) Also, Apache enforces a time-out for proxying, as well, for the same reasons as detailed above, so you will really need to run your own web server on a non-standard port if you want long-running dynamic page generation programs. = PHP = We support PHP via Apache's `mod_suphp`. This module forks a new process for each script execution, like with CGI. It runs scripts as their owners, which is the reason we need to use it instead of `mod_php`. The combined upside/downside compared to suexec CGI is that `mod_suphp` requires that every script be in the `DocumentRoot` of the vhost it's running in. To allow `http://hcoop.net/~you/...` PHP scripts, we've set `hcoop.net`'s `DocumentRoot` to `/home`. This should be safe as long as everything in `/home` has appropriate permissions, but we may decide to revise it later for security reasons. You must use the `User` and `Group` VirtualHostConfiguration directives to make virtual hosts serving dynamic content run as particular users. You'll usually choose either your own user or a special user created to be run for your dynamic web stuff. (You are required to do one or the other to get PHP/CGI working for your own vhosts.) [https://members.hcoop.net/portal/support Create a support ticket] if you want such a user. = CGI = CGI scripts and programs accessed via `http://some.domain/~you/...` run as `you`. When you want to run CGI scripts for your own virtual host, you can use a `ScriptAlias` or `CGI` directive for VirtualHostConfiguration. Like for PHP, you must use `User` and `Group` to set the user/group scripts should run as on your vhost. = Debugging = If your scripts give you "Error 500" pages or similar, you should check the error log for the virtual host you are using. If you're accessing your site via `http://some.domain/~you/` where `some.domain` has the same front page as `hcoop.net`, the error log is `/var/log/apache2/home/error.log`, and it is readable by everyone. If your script is running on a separate vhost, then see the `Group` directive for VirtualHostConfiguration for how to get read access to the logs for all users in a specified group. = Notes = See also MailingListConfiguration for information on adding a Mailman web interface to your virtual host.