Installing kTBS behing an Apache HTTP server

Apache can be used as a proxy in front of a running instance of kTBS. This has a number of advantages:

  • adds HTTPS support;
  • allows kTBS to co-exist with other services under the same domain name and port number;
  • allows to add access control.

kTBS configuration

kTBS must first be installed and run independently, listening on a local port. It must also be aware of the public URI under which it is published (in the example above: https://your.domain.com/path/to/ktbs/). This is achieved with the following configuration directives:

[server]
scheme = http
host-name = localhost
port = 8002

fixed-root-uri = https://your.domain.com/path/to/ktbs/

Apache configuration

A dedicated configuation file can be created, typically in /etc/apache2/conf.d, with the following directives:

# file: /etc/apache2/conf.d/ktbs.conf

<Location /path/to/ktbs/>
    ProxyPass http://localhost:8002/
    ProxyPassReverse http://localhost:8002/
</Location>

This configuration requires that Apache modules proxy and proxy_http are enabled; this can be ensured with:

$ a2enmod proxy proxy_http

Then Apache must be restarted to load the new configuration file:

$ apache2ctl graceful

Restricting access to kTBS with Apache

Traces can contain very sensitive information, so you will probably want to restrict access to your kTBS. To do this, you will need to add some access control directives to the Apache configuration file described above.

For the following examples, we use the htpasswd utility provided with Apache to create (-c) a password file that will be used as source for Apache authentication.

$ htpasswd -c ktbs-users jdoe
New password:
Re-type new password:
Adding password for user jdoe

Later on, you can add users to your password file with the same utility:

$ htpasswd /opt/ktbs-data/ktbs-users aduran
New password:

Basic global restriction

In order to restrict access to kTBS as a whole, the Apache configuration file above can be augmented to restrict access to kTBS, as illustrated below.

<Location /path/to/ktbs/>
    ProxyPass http://localhost:8002/
    ProxyPassReverse http://localhost:8002/

    AuthType Basic
    AuthName "kTBS"
    AuthBasicProvider file
    AuthUserFile /path/to/ktbs-users
    Require valid-user
</Location>

Finer-grain restriction

It might be tempting to define finer-grained ACL through multiple Location directives, to allow different users to access different part of your kTBS. Note however the following drawbacks:

  • kTBS is not aware of these different ACL, and it may leak some information from one user to another one;
  • when the structure of your trace bases changes in kTBS, you must reflect the changes in the Apache configuration.

Eventually, kTBS will provide its own authorization mechanisms, making this workaround moot.

What about mod_wsgi?

mod_wsgi is an Apache module dedicated to hosting Python WSGI applications entirely in Apache. In previous versions of kTBS, this was the recommended method for integrating with Apache.

The problem with mod_wsgi is that it must be compiled with the exact same version of Python as the one used by kTBS. Not only is it a problem if your distribution does not have the correct version of mod_wsgi, but it also prevents using different applications based on different versions of Python in the same Apache instance.