Configuration

Installation directory

Everything belonging to the installation lives in one directory. Create it somewhere with enough space, for example /opt/rap:

sudo mkdir -p /opt/rap
cd /opt/rap

By the end of the installation it looks like this:

/opt/rap/
├── .env                     # values the Compose file needs
├── rap.config.sh            # values used during installation
├── docker-compose.yml
├── 3240-abcd-1234-acme.cl   # license file
├── config/                  # AI middleware configuration
│   ├── credentials.yaml
│   └── api_keys.yaml
├── rw/                      # application state: ktbs.cl, license.cl, logs
│   ├── ktbs.cl
│   └── license.cl
├── rwshared/                # disk pool for file blobs — grows large
└── data/aimiddleware/       # AI middleware runtime data

Put rwshared/ on its own volume

rwshared/ holds the file blobs and is the part that grows. If you want it on a dedicated partition or LUN, mount that partition at /opt/rap/rwshared before starting the installation.

Directories and ownership

The containers do not run as root. The application runs as UID/GID 1234, the AI middleware as 6000, and both need to write into their directories:

sudo mkdir -p rw rwshared/pool data/aimiddleware sql
sudo chown -R 1234:1234 rw rwshared sql
sudo chown -R 6000:6000 data/aimiddleware

Installation variables

rap.config.sh holds the values for your installation. It is used in the following steps to generate the application configuration and to set up the database. It is not read at runtime.

Download it into the installation directory — Rulemapping Solutions may have pre-filled parts of it for you:

downloads/rap.config.sh

chmod 0600 rap.config.sh

This is its content:

rap.config.sh

#!/bin/bash

# Provided by Rulemapping Solutions
PREFIX=acme
LICENSE=3240-abcd-1234-acme.cl

DOMAIN=example.com
ADMIN_EMAIL=admin@example.com

# Database
DB_HOST=db.example.com
DB_PORT=5432
DB_NAME=ktbs_$PREFIX

DB_SUPERUSER=postgres
DB_SUPERUSER_DB_NAME=postgres

DB_ADMIN_PASSWORD=admin_mysecret
DB_SERVER_PASSWORD=server_mysecret
DB_RO_PASSWORD=ro_mysecret

# Mail
SMTP_HOST=smtp.example.com
SMTP_USER=smtp-user
SMTP_PASSWORD=smtp-password

FROM_ADDRESS=support@$DOMAIN
REPLY_ADDRESS=no-reply@$DOMAIN

Replace every placeholder value — see the table below for what each one means:

$EDITOR rap.config.sh

Only then load the values into your shell:

source ./rap.config.sh

Check that what got loaded is yours and not the template:

echo "$PREFIX | $DOMAIN | $DB_HOST | $DB_NAME | $ADMIN_EMAIL"

Do not source the template unedited

The next steps write $PREFIX, $DB_HOST and the passwords into rw/ktbs.cl and use them to create the database. With the template values still in place you get an instance called acme pointing at db.example.com with the password server_mysecret.

Re-source it in every new shell

The following steps rely on these variables. If you open a new shell, run source ./rap.config.sh again.

Variable	Description
PREFIX	Project name, provided by Rulemapping Solutions. Letters and digits only. Determines the URL path, the database name and the role names.
LICENSE	Filename of your license file; will be copied to /rw/license.cl
DOMAIN	Your domain; used when links are generated
ADMIN_EMAIL	Email address of the first admin user, created during installation; you can login to the platform with this user
DB_HOST, DB_PORT	Database host and port
DB_SUPERUSER	Existing account allowed to create roles and databases. Used only during installation, not at runtime. On managed database services this is rarely called postgres — use the master user of your instance.
DB_SUPERUSER_DB_NAME	An already existing database to connect to while creating the new one — CREATE DATABASE cannot run from inside the database being created. Usually the postgres maintenance database.
DB_NAME	Name of the application database
DB_ADMIN_PASSWORD	Password for the admin_<PREFIX> role, which owns the schema
DB_SERVER_PASSWORD	Password for the server_<PREFIX> role, which the application connects as
DB_RO_PASSWORD	Password for the read-only ro_<PREFIX> role
SMTP_HOST, SMTP_USER, SMTP_PASSWORD	SMTP server and credentials
FROM_ADDRESS, REPLY_ADDRESS	Sender and reply-to address of outgoing mail

Compose variables

.env holds the two values the Compose file needs. Compose reads this file automatically.

cat > .env <<EOF
PREFIX=$PREFIX
TZ=Europe/Berlin
EOF

Application configuration

The application reads its configuration from rw/ktbs.cl. Generate it from the variables you just set:

sudo tee rw/ktbs.cl > /dev/null <<EOF
:process-offset 0
:prefix "$PREFIX"
:listen-port 8080
:proxy-protocol-scheme "https"
:proxy-host-name "$PREFIX.$DOMAIN"
:extra-tabs (:pfe :tabd14 :dcpr :mandanten :deadlines :adressen :rvg)
:database-specification
   (:host "$DB_HOST" :port $DB_PORT :database "$DB_NAME"
    :user-name "server_$PREFIX" :password "$DB_SERVER_PASSWORD")
:from-address "$FROM_ADDRESS"
:reply-address "$REPLY_ADDRESS"
:smtp-server
   (:host "$SMTP_HOST" :username "$SMTP_USER" :password "$SMTP_PASSWORD")
EOF

sudo chown 1234:1234 rw/ktbs.cl
sudo chmod 0600 rw/ktbs.cl

# check the result — the placeholders must all be substituted
sudo cat rw/ktbs.cl

:proxy-host-name is the host name under which users reach the application. It is the host the application puts into absolute URLs whenever the reverse proxy does not send an X-Forwarded-Host header.

Setting it also matters for :proxy-protocol-scheme: the application only uses that scheme for absolute URLs when it knows it is behind a proxy — either from X-Forwarded-Host or from this value. With neither, it falls back to the scheme and port of the incoming request, which is plain HTTP.

License file

The application expects the license at rw/license.cl:

sudo cp "$LICENSE" rw/license.cl
sudo chown 1234:1234 rw/license.cl
sudo chmod 0400 rw/license.cl

sudo cat rw/license.cl

Keep the original file in the installation directory as well — the filename records which version the license is bound to.