SPY HILL Research
Spy-Hill.net
Poughkeepsie, New York [DIR] [UP]

Apache httpd Configuration for BOINC

This page describes how to set up and configure the Apache web server for a BOINC project.
Last modified: 3 October 2009
Topics
Configuration Files
File Permissions
Control Panel
Scheduler restrictions
Configuring your web server for a BOINC project involves several things: The configuration files have to be set up properly. Certain files and directories must have the proper ownerships and permissions. The ops pages should be restricted via a .htaccess file, and the cgi-bin directory can be restricted in the same way for testing.

Useful information about configuring the web server may also be found on the more general page

Perhaps this page and that section should be merged some day?

Configuration Files

The main configuration file for the Apache web server is httpd.conf, generally found in the directory /etc/httpd/conf/ (yours may live somewhere else). Our BOINC project is currently hosted on the same machine that serves several other web sites (as virtual servers). So to keep things more organized we put all the configuration for a single BOINC project into a separate file, called pirates.conf. We then put that file in a separate subdirectory, /etc/httpd/conf/local.d, and then add to the end of httpd.conf the line:
Include conf/local.d/*.conf
This loads any config files in that sub-directory.
A similar mechanism is used by httpd.conf to load all the files in /etc/httpd/conf.d/ (this name is confusing). You will likely find there the configurations to turn on PHP, and perhaps other features of the web server.
The actual contents of the pirates.conf file can be viewed here:
If you have troubles viewing the file directly in your browser then right-click to down-load it to your desktop.

Notes

Host Name - The name for the virtual host (eg. pirates.spy-hill.net) must be in the DNS; you cannot make up just any old name. In our case this name is a DNS CNAME record (an alias) for the already existing host name www.spy-hill.net. 1

Permissions - You really should specify permissions and options for every separate directory tree served from your site, so we include separate entries for ops, download, stats, and help areas. The upload area is not served directly by the web server 2 so we could leave it out here, but I've added it explicitly to show that access is to be denied.

configtest - When you are ready to try a new web server configuration, don't just restart the server. You should always run the server script with the configtest option first to test the configuration file. To do this run the Unix start/stop script /etc/rc.d/init.d/httpd (or some similar location) with that argument:

# /etc/init.d/httpd configtest Syntax OK.
If the syntax is not okay then you need to fix that first. When it's okay you can then restart your server with something like:
# /etc/init.d/httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ]
(On Red Hat Linux and maybe some similar distributions the service command lets you run a Unix start/stop script without giving the full path name to the directory. You may find that more convenient if it is available.)

File Permissions

You need to configure file permissions on the server so that the scheduler can talk to the feeder. This is detailed at In particular, see the bit about how certain directories need to be writeable by user 'apache'.
This page and that section should perhaps someday be merged?

Control Panel

Certain web pages are included in the BOINC distribution for use only by the project administrators. These are in the html/ops subdirectory. To prevent just anybody from the whole Internet from using these pages you should restrict access by creating a file in this directory called .htaccess containing something like:
AuthUserFile /usr02/pirates/html/ops/.htpasswd AuthGroupFile /dev/null AuthName " Captain and Officers of Pirates@Home " AuthType Basic <Limit GET> order deny,allow deny from all Allow from 192.168.1.47 require valid-user satisfy any </Limit>
This allows access from one host on my local network without a password, or from outside if the user provides a username and password given in the .htpasswd file. You can create or modify the password file with the htpasswd command.

The main index page of the control panel will now warn you if the ops subdirectory is unprotected.

Scheduler restrictions via cgi-bin

Because clients contact the server via cgi-bin scripts to talk to the scheduler and file_upload_handler it is possible to restrict both work given out and results returned to a selected set of network addresses using a .htaccess file in the cgi-bin directory.

To open up the site, rather than deleting the file we just rename it to OFF.htaccess so that we can put it back in place when needed.

If you want to deny access to the scheduler but still collect files from clients who are finishing work then open the directory up (rename the file .htaccess to something else) but then make the scheduler non-executable:

# chmod -x cgi-bin/cgi
I like to change the name of the scheduler from 'cgi' to 'scheduler' or something clearer. If you do this, you need to change the name in the <link> tag or <scheduler> block on the project home page.

To allow the use of a .htaccess file in the cgi-bin directory you need to add some configuration directives to your web server configuation. In particular you need to add

AllowOverride AuthConfig Limit Order allow,deny Allow from all
According to the Apache web server documentation on .htaccess files there is a performance penalty for their use. Basically, it costs extra cycles to search for the .htaccess file and to load it each time a document is requested. So you should only consider doing this when testing and developing your project, but turn this mechanism off for full production.

Footnotes

1 When Pirates@Home was started at Vassar College we requested the CNAME record pirates.vassar.edu. The networking department questioned the choice of the name "pirates" until we explained to them that we were not supporting sofware or music pirating.

2 Instead, when a file is to be uploaded the client contacts the file_upload_handler in the cgi-bin directory, which then writes the files it gets to the upload area. There is no reason for anybody but a project administrator to be able to look in the upload directory.
  Copyright © 2009 by Spy Hill Research http://www.Spy-Hill.net/~myers/help/boinc/httpd-conf.html (served by Islay.spy-hill.com) Last modified: 03 October 2009