Now we have all the pieces to run our application. The last remaining thing to do is to get Apache configured correctly. In most UNIX distributions this is done by modifying or adding configuration files to
/etc/apache2. On older systems the configuration might also be in a directory named
The main configuration file is situated in
httpd.conf on older systems. Before we change the configuration of the server and add the Seaside web application, have a look at this file. It is usually instructive to see how the default configuration looks like and there is plenty of documentation in the configuration file itself. On most systems this main configuration file includes other configuration files that specify what modules (plug-ins) are loaded and what sites are served through the web server.
Loading Modules. On Debian the directory
/etc/apache2/mods-available contains all the available modules that could be loaded. To make them actually available from your configuration you have to link (
.load files to
/etc/apache2/mods-enabled. We need to do that for the proxy and rewrite modules:
$ a2enmod proxy $ a2enmod proxy_http $ a2enmod rewrite
If you are running an older version you might need to uncomment some lines in the main configuration file to add these modules.
Adding a new site. Next we add a new site. The procedure here is very similar to the one of the modules, except that we have to write the configuration file ourselves.
/etc/apache2/sites-available/ contains configuration directives files of different virtual hosts that might be used with Apache 2.
/etc/apache2/sites-enabled/ contains links to the sites in
sites-enabled/ that the administrator wishes to enable.
Step 1. In
/etc/apache2/sites-available/ create a new configuration file called
appname.conf as follow.
<VirtualHost *> # set server name ProxyPreserveHost On ServerName www.appname.com # rewrite incoming requests RewriteEngine On RewriteRule ^/(.*)$ http://localhost:8080/appname/$1 [proxy,last] </VirtualHost>
The file defines a default virtual host. If you want to have different virtual hosts (or domain names) to be served from the same computer replace the
* in the first line with your domain name. The domain name that should be used to generate absolute URLs is specified with
ServerName. The setting
ProxyPreserveHost enables Seaside to figure out the server name automatically, but this setting is not available for versions prior to Apache 2. In this case you have to change the Seaside preference ‘hostname’ for all your applications manually, see Section 23.1
RewriteEngine enables the rewrite engine that is used in the line below. The last line actually does all the magic and passes on the request to Seaside. A rewrite rule always consists of 3 parts. The first part matches the URL, in this case all URLs are matched. The second part defines how the URL is transformed. In this case this is the URL that you would use locally when accessing the application. And finally, the last part in square brackets defines the actions to be taken with the transformed URL. In this case we want to proxy the request, this means it should be passed to Squeak using the new URL. We also tell Apache that this is the last rule to be used and no further processing should be done.
Step 2. Now link the file from
/etc/apache2/sites-enabled/ and restart Apache:
$ cd /etc/apache2/sites-enabled $ ln -s /etc/apache2/sites-available/appname.conf . $ sudo apache2ctl restart
If the domain name
appname.com is correctly setup and pointing to your machine, everything should be up and running now. Make sure that you set the ‘server base path’ in the application configuration to
/, so that Seaside creates correct URLs.
Troubleshooting the Proxy. On some systems the above configuration may not suffice to get Seaside working. Check the error_log and if you get an error messages in the Apache log saying
client denied by server configuration just remove the file
/etc/mods-enabled/proxy.conf from the configuration.