Mit offiziellen Images
Getestet mit i-doit 38 und Debian 13 Trixie
Diese Anleitung beschreibt die Installation von i-doit Pro mit den offiziellen synetics-Container-Images über Docker Compose. Der Stack besteht aus zwei Services — app (Apache + PHP + i-doit) und db (MariaDB) — und ist auf einem Linux-Server in wenigen Minuten einsatzbereit.
Für TLS-Termination wird optional ein dritter Service mit nginx ergänzt.
Systemvoraussetzungen#
Es gelten die allgemeinen Systemvoraussetzungen. Zusätzlich werden benötigt:
- Docker ≥ 24 mit Compose-Plugin
- Root-Rechte oder
sudo-Zugang - Internetverbindung zur Registry
registry.on.ops.docupike.net(Images sind öffentlich, kein Login)
Docker installieren#
Zunächst die benötigten Basispakete installieren:
1 2 | |
Docker wird über das offizielle Repository eingerichtet:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Versionscheck:
1 2 | |
Projektstruktur anlegen#
Ein Verzeichnis für den i-doit-Stack wird erstellt. Die Unterordner nginx/, tls/ und apache/ werden für die TLS-Variante benötigt — wer i-doit zunächst nur über HTTP betreibt, kann sie weglassen:
1 2 | |
Konfigurationsdateien erstellen#
compose.yaml#
1 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 | |
Reiner HTTP-Betrieb
Wer ohne TLS startet, ersetzt im app-Service den expose:-Block durch ports: ["8080:8080"] und lässt den ganzen nginx-Service weg. Die Anleitung geht im Folgenden vom kompletten TLS-Stack aus.
.env#
1 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | |
Passwörter ersetzen
Die Werte root, idoit, admin sind nur für die Erstinbetriebnahme gedacht. Vor produktivem Einsatz durch sichere, individuelle Passwörter ersetzen.
Wichtig: IDOIT_APP_URL
IDOIT_APP_URL muss auf die extern erreichbare URL der Anwendung zeigen — inklusive Schema (https://) und Hostname. Der Wert wird nur beim allerersten Containerstart in die i-doit-Settings übernommen; spätere Änderungen in der .env allein reichen nicht (siehe Abschnitt Fehlerbehebung).
Apache-Override für Reverse-Proxy-Header#
1 | |
1 2 3 4 | |
Diese Datei signalisiert dem Apache im app-Container, dass extern HTTPS terminiert wird. Ohne sie generiert i-doit interne Links als HTTP.
nginx-Konfiguration#
1 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | |
TLS-Zertifikat#
Für Test- und Inhouse-Umgebungen reicht ein selbst-signiertes Zertifikat. CN und subjectAltName an die echte Adresse anpassen — Hostname und/oder IP, unter der i-doit erreichbar sein soll:
1 2 3 4 5 | |
Produktiv-Zertifikat
Im produktiven Einsatz das Zertifikat aus der hauseigenen PKI oder von Let's Encrypt verwenden und unter tls/idoit.crt (Public-Cert + Zwischenzertifikate) sowie tls/idoit.key (Private Key) ablegen — der nginx-Service lädt beide automatisch.
Container starten#
1 2 3 | |
Beim ersten Start lädt i-doit die Datenbankschemata, legt den Default-Mandanten an und führt das initiale Setup aus. Das dauert je nach Maschine 30–90 Sekunden. Status verfolgen:
1 2 | |
Sobald app und db im Status healthy stehen, ist die Anwendung über die in IDOIT_APP_URL angegebene URL erreichbar. Schnellcheck:
1 | |
Erwartete Antwort:
1 | |
Erster Login#
- Browser öffnen:
https://idoit.example.com/ - Auf der Login-Seite den Mandanten
CMDBwählen (entsprichtIDOIT_DEFAULT_TENANT). - Mit den in der
.envdefinierten Werten einloggen (Default:admin/admin). - Über das Benutzermenü oben rechts das Passwort sofort ändern.
- Admin-Center mit dem Passwort aus
IDOIT_ADMIN_CENTER_PASSWORDöffnen (Link in der Login-Maske) und dort ebenfalls das Passwort ändern.
Standardzugänge nach der Installation
- i-doit: Benutzer
admin, Passwortadmin - Admin Center: Benutzer
admin, Passwortadmin
Pro-Modus aktivieren#
Das Standard-Image initialisiert i-doit im Cloud-Modus. Für den klassischen Pro-Betrieb (alle Add-ons im Subscription Center installierbar, kein Cloud-Indikator in der UI) ist ein einmaliger Umbau nötig — direkt nach dem ersten erfolgreichen Setup, vor dem produktiven Einsatz:
1 2 3 4 5 6 7 8 9 10 11 | |
Was die drei Befehle tun:
| Befehl | Wirkung |
|---|---|
--unset-cloud | Setzt das Cloud-Flag in der i-doit-Datenbank zurück. |
--noncloudable --enable all | Aktiviert alle Funktionen, die im Cloud-Modus standardmäßig deaktiviert sind (LDAP, JDisc-Integration, Logbook-Archiv etc.). |
sed-Befehl | Setzt $g_is_cloud in der persistenten config.inc.php auf 0. |
Add-on-Install und Pro-Features
Ohne diesen Schritt scheitert der Add-on-Install aus dem Subscription Center bzw. einzelne Module sind nicht sichtbar. Der Schritt ist einmalig pro Installation.
Lizenz einspielen#
i-doit Pro benötigt zur Aktivierung einen gültigen Lizenz-Token oder eine Lizenz-Datei. Im Auslieferungszustand der .env steht IDOIT_LICENSE_TOKEN=changeme — die initiale Lizenzaktivierung schlägt in den Logs erwartet fehl, der Stack startet aber trotzdem.
Variante A — Web-Lizenz-Token#
Token aus dem synetics Kundenportal kopieren, in die .env eintragen und den app-Container neu starten:
1 2 | |
Variante B — Lizenz-Datei#
Lizenz-Datei (license.key) in das Daten-Volume legen und die Token-Zeile durch die File-Variante ersetzen:
1 2 3 4 | |
Nach dem Restart lässt sich der Lizenzstatus im Admin-Center (Tab Lizenz) prüfen.
Update#
Auf eine neuere Image-Version aktualisieren:
compose.yamlöffnen und den Image-Tag (:38) in beiden Services auf die Ziel-Version setzen.IDOIT_VERSIONin der.envauf denselben Wert anheben.- Update durchführen:
1 2 3 | |
docker compose up -d erkennt geänderte Tags, zieht das neue Image und ersetzt den Container in-place. Beim Start führt das Entrypoint-Skript automatisch die Datenbank-Migration aus. Die Anwendungsdaten in den Volumes app und db bleiben erhalten.
Vor dem Update sichern
Volumes sichern, bevor die Major-Version geändert wird. Siehe Abschnitt Backup.
Backup#
Beide Persistenz-Volumes sichern: app (Konfigurationen, Uploads, Logs, Lizenz) und db (Datenbank-Dateien). Das folgende Script legt täglich ein Backup unter /opt/idoit-backup/ ab:
1 2 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
1 | |
Damit das Script täglich automatisch ausgeführt wird:
1 2 | |
Deinstallation#
1 2 | |
Datenverlust
--volumes löscht die Volumes app und db unwiderruflich. Vorher sichern, falls die Daten weiter benötigt werden.
Fehlerbehebung#
app startet in Crashloop, Log endet mit unbound variable#
Die .env ist unvollständig. Das Entrypoint-Skript läuft mit set -u und bricht ab, sobald eine erwartete Variable nicht gesetzt ist. Häufige Lücken in eigenen .env-Vorlagen:
IDOIT_VERSION— muss zum Image-Tag passen (Tag:38⇒IDOIT_VERSION=38).IDOIT_SYSTEM_SETTINGS— darf leer bleiben, muss aber gesetzt sein.
Lizenz-Fehler Authentication failed, please check your weblicense token#
Token ist falsch oder noch der Vorlagewert changeme. Korrekten Token aus dem Kundenportal in der .env ablegen, dann sudo docker compose restart app.
Add-on aus dem Subscription Center: rmdir: Device or resource busy#
Volltext-Fehler:
1 2 | |
Ursache: In manchen Compose-Vorlagen ist beim app-Service ein tmpfs-Mount auf /var/www/html/temp gesetzt. /var/www/html ist innerhalb des Containers ein Symlink auf /var/www/idoit/updates/versions/<version>/files, der Mount liegt also genau auf dem Verzeichnis, das der Add-on-Installer per rmdir neu erzeugen will. Das schlägt fehl, solange ein tmpfs-Mount aktiv ist.
Fix: Den tmpfs-Block beim app-Service aus compose.yaml entfernen (siehe Beispiel-Compose oben — dort ist er bewusst nicht enthalten) und Stack neu starten:
1 | |
Add-ons fehlen, UI zeigt Cloud-Hinweise#
Das Image initialisiert i-doit als Cloud-Instanz. Pro-spezifische Funktionen und einige Add-on-Installationen sind dann deaktiviert. Den Schritt Pro-Modus aktivieren durchführen.
Nach dem Logout landet der Browser auf localhost:8080 mit ERR_CONNECTION_REFUSED#
IDOIT_APP_URL steht noch auf http://localhost:8080, der Zugriff erfolgt aber von einem anderen Rechner.
Wichtig
Der Wert aus der .env wird nur beim allerersten Containerstart in die i-doit-Settings übernommen. Bei nachträglicher Korrektur reicht ein Container-Restart nicht — der Wert muss zusätzlich per Console-Befehl in der Anwendung gesetzt werden.
1 2 3 4 5 6 7 8 9 10 11 | |
Der idoit:set-env-var-Befehl ist auch der saubere Weg, später z. B. von HTTP auf HTTPS oder auf einen anderen Hostnamen zu wechseln.
Links wie /admin springen auf http://...:8080/...#
Apache im app-Container hört nativ auf Port 8080/HTTP. Bei automatischen DirectorySlash-Redirects (z. B. /admin ohne Trailing-Slash → /admin/) baut Apache einen absoluten Location-Header mit dem internen Port. Da Apache nichts vom vorgeschalteten TLS-Proxy weiß, erscheint im Browser eine nicht erreichbare http://<host>:8080/...-URL.
Fix: Im nginx-Reverse-Proxy die proxy_redirect-Direktive setzen, die diese Location-Header umbiegt. Im Beispiel nginx/idoit.conf dieser Anleitung ist die Zeile bereits enthalten:
1 | |
Anschließend sudo docker compose restart nginx.
Healthcheck schlägt fehl, obwohl die UI erreichbar ist#
Der Healthcheck verwendet curl --fail http://localhost:8080/health. Tritt der Fehler nur kurz beim Start auf, ist es das start_period von 30 s — das Setup ist einfach noch nicht durch. Bleibt der Status dauerhaft unhealthy, in den Logs nach Fehlern im Setup-Schritt suchen:
1 | |
Nächster Schritt#
Die Installation ist abgeschlossen. Im nächsten Schritt eine Lizenz einspielen und die ersten Einstellungen vornehmen: