This document describes what a custom, user-managed webserver is at CSLab and why they exist. If you would like to set one up, please see the User-Managed Webserver HOWTO page.
The main webserver at CSLab serves user home pages as well as the
www.cs.toronto.edu URL namespace in general. Since it is
shared by many users and needs to be secure, we need to keep things
run by different users separate from each other. This means that it
can't support things like PHP or a system-wide MySQL database, only CGI
programs that can be run by the user that owns them.
But some people need to run more sophisticated web applications, especially PHP-based applications; blogs, content management systems, and advanced wikis are all examples of things that want more than basic CGI. To accommodate this need CSLab has introduced the idea of a user managed web server: instead of trying to accommodate everyone's needs in our single main webserver, we enable people to run their own webserver (and then hide it behind ours so that people using your web applications don't have to care about it).
A user-managed webserver is another instance of the Apache server binary running concurrently on the machine hosting the main CSLab webserver. Unlike the main web server, which is shared by everyone and run by a system account, a user-managed webserver is run by the user that owns it and is only used by that user. This means that it can have features that cannot be supported in the shared main webserver, such as PHP and a MySQL database.
CSLab supplies a standard user-managed webserver configuration that is basically a normal 'LAMP' configured Apache webserver and an optional MySQL database server to go along with it. However, you are free to customize Apache or even run whatever other webserver you want as your user-managed webserver.
A user-manged webserver cannot run on the normal port 80, because that's used by the main web server. Instead it runs on a high-numbered port on the webserver that was assigned to it when it was created. However, these ports are not normally accessible from the outside world; instead, we use reverse proxying to make your user-managed webserver available to people as if it was part of the main wwww.cs.toronto.edu website.
(In reverse proxying, the main CSLab webserver passes all requests for things under some URL to your user-managed webserver and then relays your webserver's replies back to the original requester.)
There is one unfortunate drawback to reverse proxying: the applications that you're running on your user-managed webserver need to be aware that they are operating behind a reverse proxy. If your applications are not reverse proxy aware, they will require some modification to operate properly (although a certain amount of this can be fixed up with increasingly creative and twisted Apache configuration). Talk to your Point of Contact for more help with this issue.
(A full discussion of this issue is beyond the scope of an overview.)
Reverse proxying sends some URL on the main webserver to some URL on your user-managed webserver. The URL on your webserver is up to you, but the URL on the main webserver is normally something under your normal user page; for example, you might have http://www.cs.toronto.edu/~user/wiki mapped to the URL /wiki on your user-managed webserver.