Einrichten in fünf Schritten
Vorausgesetzt ist ein Linux-Server mit Docker (siehe Mit Docker betreiben). Danach kommen HTTPS mit Caddy und – auf einem Server beim Kunden – die Lizenz.
1. Quellen holen und .env anlegen
git clone <Adresse des Repositoriums> /opt/workoffice-pro
cd /opt/workoffice-pro
cp .env.example .env
chmod 600 .env
Die .env enthält alle Schlüssel des Servers; chmod 600 sorgt dafür, dass nur ihr Besitzer sie lesen kann. Das Verzeichnis /opt/workoffice-pro setzen auch die Skripte für Sicherung und Wiederherstellung voraus. Wer mit fertigen Abbildern arbeitet, startet in Schritt 4 anders (siehe Mit Docker betreiben) und baut nichts.
2. Geheimnisse erzeugen
Für keinen dieser Werte gibt es eine Vorgabe – ein mitgeliefertes Geheimnis wäre ein öffentlich bekanntes. Ohne die ersten drei startet der Verbund gar nicht erst.
sed -i \
-e "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -hex 24)|" \
-e "s|^APP_DB_PASSWORD=.*|APP_DB_PASSWORD=$(openssl rand -hex 24)|" \
-e "s|^JWT_SECRET=.*|JWT_SECRET=$(openssl rand -base64 48 | tr -d '\n')|" \
-e "s|^GEHEIMNIS_SCHLUESSEL=.*|GEHEIMNIS_SCHLUESSEL=$(openssl rand -base64 32 | tr -d '\n')|" \
.env
Die beiden Datenbank-Passwörter sind bewusst Hex: Sie stehen in einer Verbindungsadresse, und ein / oder + aus Base64 würde sie zerbrechen.
Sollen Programme über die Lexware-kompatible Schnittstelle Webhooks bekommen – etwa ältere Fassungen von WorkTime Pro –, kommt der Signaturschlüssel dieser Webhooks dazu. Ohne ihn stellt der Server im Betrieb keine zu; sie warten, bis einer eingetragen ist. Die direkte Verbindung zu WorkTime Pro braucht ihn nicht, sie signiert mit einem eigenen Geheimnis je Verbindung. Erzeugen:
sed -i "s|^WEBHOOK_PRIVATE_KEY=.*|WEBHOOK_PRIVATE_KEY=$(openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 | base64 -w0)|" .env
Base64 in einer Zeile übersteht .env, sed und Compose ohne Anführungszeichen und Zeilenumbrüche.
Die .env gehört mit in die Sicherung. Ohne JWT_SECRET und GEHEIMNIS_SCHLUESSEL sind nach einer Wiederherstellung die Anmeldungen und die verschlüsselt gespeicherten Geheimnisse der Betriebe (etwa Passwörter eigener Mailserver) nicht mehr zu gebrauchen.
3. E-Mail eintragen
SMTP_HOST, SMTP_USER, SMTP_PASSWORD und MAIL_FROM in der .env – das Konto verschickt die Systemmails (Passwort vergessen, Einladungen …) und, solange ein Betrieb keinen eigenen Mailserver einträgt, auch seine Rechnungen und Mahnungen. Ohne SMTP werden Mails nur ins Protokoll geschrieben. Einzelheiten: E-Mail des Servers.
4. Starten
docker compose -p workoffice -f docker-compose.selfhost.yml up -d --build
Beim ersten Start spielt die API Migrationen, Mandantentrennung und GoBD-Sperren ein und legt den Anwendungsbenutzer workoffice_app an. Greift die Mandantentrennung nicht, bricht sie ab, statt unsicher zu laufen.
5. Nachsehen, ob es trägt
docker compose -p workoffice -f docker-compose.selfhost.yml ps
curl -s http://127.0.0.1:3100/api/ready
Bei api muss healthy stehen, und die Antwort muss so aussehen:
{ "status": "ok", "mandantentrennung": "greift" }
Dann http://<server>:3100 im Browser öffnen und den ersten Betrieb registrieren. Der erste Betrieb ist auf einem Server mit Lizenzpflicht zugleich der, dessen Inhaber die Lizenz eintragen darf.
Soll sich danach niemand Fremdes mehr registrieren können: SIGNUP_OPEN=false in die .env und up -d.
Wie es weitergeht
- HTTPS mit Caddy – ohne HTTPS hält die Anmeldung im Betrieb nicht.
- Lizenz – auf einem Server beim Kunden.
- Sicherung – die nächtliche Sicherung einrichten.
Unter Integrationen zeigt WorkOffice danach, was verbunden ist und was noch fehlt – auch, was Sache des Servers ist, etwa die FinTS-Produktnummer für die Bankanbindung.