Each virtual host is configured in a separate config file which is included into the main httpd.conf
.
Here is an example one:
<VirtualHost *:80> ServerName example.uwaterloo.ca DocumentRoot /software/wwwdata_cs.uwaterloo.ca/data/vhosts/example ErrorLog logs/example/error_log TransferLog logs/example/access_log CustomLog logs/example/combined_log combined </VirtualHost> <VirtualHost *:80> ServerName www.example.uwaterloo.ca ServerAlias www.example example Redirect permanent / http://example.uwaterloo.ca/ ErrorLog logs/example/error_log TransferLog logs/example/access_log CustomLog logs/example/combined_log combined</VirtualHost> </VirtualHost>
This would be placed in /software/wwwdata_cs.uwaterloo.ca/data/vhosts/example.conf
in the core.cs
environment.
Note that this file actually contains two virtual hosts. The first is the "real" one, and would also contain any host-specific directives that are needed. It has a single ServerName
directives and no ServerAlias
directives. The second handles alternate names that also refer to the same virtual host. These should all be redirected as shown to the canonical name. Note that the .uwaterloo.ca
can be omitted from anywhere on campus (or anywhere that has .uwaterloo.ca
specified as a search domain) so it is important to redirect these shorter versions of the name to the canonical name.
Each virtual host has to configure its own log files, if the different virtual hosts are to be logged separately, as seems rather desirable. For some reason the default Apache logging format mixes up all the virtual hosts together, and the entries can't even be distinguished. I don't think there is a neat way of designating the log format for all virtual hosts at once if the logs are to be split. Really the whole area of Apache logging is extremely deficient and poorly designed. Try grabbing column n of a log file with a Unix cut
invocation, for example.
There are two basic ways to arrange for access to the document root by users who need to be able to edit the contents of the virtual host: by Unix user and by Unix group.
If access is by user, a Unix user is chosen or created for the purpose of owning the document root. If there will be a single person who does all the work on the website, it may be appropriate to use their core.cs
user. Alternately, a user can be created and the appropriate people given .rhosts
or ssh
access to the special user. Something like the following commands are appropriate for setting this up:
cd /software/wwwdata_cs.uwaterloo.ca/data/vhosts/example chown -R web_example . chmod -R 2775 .
It would be appropriate to create a symlink in such users' home directories to the document root. Something like:
cd ~example ln -s /software/wwwdata_cs.uwaterloo.ca/data/vhosts/example www
It is not appropriate to name the symlink public_html
because that is reserved for user home pages accessible as http://www.cs.uwaterloo.ca/~example/
.
If access is by group, a Unix group is created for the purpose of owning the document root. This method is more versatile in that users can be themselves while accessing web files, so they can use SMB mounts or a DreamWeaver FTP connection to get at the files from their desktops. Groups for this purpose should have names beginning with www_
.
Users should use umask 2 when doing web work to ensure that other members of the relevant web group can edit their files, and to ensure that all files are accessible by the web server software. In the case of DreamWeaver users we typically configure umask 2 in their .cshrc
file. This is of course a potential security problem, but in practice such users typically use their core.cs
accounts only for web work, so it remains only a potential security problem. Unfortunately their doesn't seem to be a way to set umask 2 on the web directories and a more restrictive umask elsewhere.