HowTos/ApacheConfiguration

Scalix Wiki -> How-Tos -> Apache configuration

How does Scalix use Apache ?

The web-based applications are Scalix Web Access (/webmail), Scalix Management Services (/sac), Scalix Management Agent, Scalix Messaging Services (/api) and Scalix Mobile Web Client (/m). These are all Tomcat applications.

Prior to Scalix 10.0, it was necessary to talk directly to tomcat using port 8080 (or 8443 for SSL). This was confusing for administrators who were used to using Apache and had to come up with ways to redirect a regular URL (without a port number) to the Tomcat application. They also needed to set up SSL certificates with the Java key store.

With Scalix 10.0, we started to use mod_jk which is a link between Apache and Tomcat. This means that Apache can be separated somewhat from the Tomcat implementation and the familiar concepts of Apache configuration are now available. For more recent distributions, the use of mod_proxy_ajp has replaced mod_jk. Typically, these are Fedora Core 5 and RedHat ES 4.

In this document, when I use $APACHE, I mean either /etc/httpd or /etc/apache2 depending on the distribution being used.

What configuration files are used ?

scalix-tomcat-connector.conf

The Scalix Apache configuration starts from a file called scalix-tomcat-connector.conf' in $APACHE/conf.d. This file contains details about loading the mod_deflate module to allow compression on text, XML, CSS and javascript files. It will also load either mod_jk or mod_proxy_ajp depending on what is available. The final step is to include /etc/opt/scalix-tomcat/connector/[ajp|jk]/instance-*.conf. These files are definitions for each Scalix instance defined on the machine.

instance-*.conf

The instance-*.conf file differs between the ajp and jk implementation and I will detail those differences later. The common configuration is that the installer will create VirtualHost entries for the hostname that the Scalix instance is configured for. There are 2 VirtualHost entries defined. One is for port 80 (http) and the other is for port 443 (https). Both VirtualHost entries will have Include lines to point to the app-$instance.*.conf files that define the Scalix web applications that are available.

NOTE: These VirtualHost entries define the hostname that should be included in the URL in order for the web applications to be called. If you use a different hostname, you can change them. HOWEVER if you use the *:80 or *:443 notation to indicate that you want to listen on ALL names, you are likely to get Apache warnings that these VirtualHost definitions conflict with existing ones. If this is the case, you should consider moving the Scalix-specific configuration into the general Apache configuration. Consult the Apache documentation for your distribution on how to do this as the configuation will be distribution-specific.

For mod_jk, the instance-*.conf file defines the mod_jk worker that will be used. A worker is a thread/process that is responsible for the connection to tomcat. The worker will have a hostname and port number definition. This hostname should be the hostname that tomcat is listening on. The port number should remain as 8009.

The file workers.conf contains a list of all the workers are defined. There is one worker defined per Scalix instance.

NOTE: For a regular Scalix installation, the SSL configuration options from the default Apache configuration are used as a template. If you are looking to provide SSL access to your users, you should make sure that the certificate and keys are specific to that hostname otherwise browsers will complain about hostname mismatch or invalid certificates.

app-$instance.*.conf

These files define the URLs that will be redirected to tomcat. For mod_jk, this is done using the JKMount directive and specifies the worker that will be used. For mod_proxy_ajp, this is done using the ProxyPass directive which specifies the hostname and port number of the listening tomcat process.

Why did we do it like this ?

This configuration makes it easier to operate in a multi-instance or HA environment as the configuration for each instance is self-contained.