Overleaf

Overleaf Community Edition – Installationsanleitung für einen abgeschotteten (Air-Gapped) Behördenserver

Zielbild: Ein Server, der für die Dauer der Installation temporär Internetzugang über einen Proxy erhält, alle benötigten Komponenten herunterlädt, danach vollständig vom Netz getrennt wird und ohne weitere Internetverbindung dauerhaft betrieben werden kann.

Rahmenbedingungen dieses Vorhabens (Entscheidungen aus der Planung):

Kein SSO/AD-Anbindung nötig → lokale Nutzerverwaltung, Accounts manuell per Admin angelegt, Einladung per Mail-Link.
Kein Server Pro (Kostengrund) → offizielle Overleaf Community Edition, kein Fremd-Fork.
Kein Bedarf an Sandboxed Compiles (kleine, bekannte Nutzergruppe: Studierende, die ihre Bachelorarbeiten schreiben) — als bewusst akzeptiertes Restrisiko dokumentiert, nicht übersehen.
BibTeX und Biber müssen funktionieren (biblatex-Workflows).
Installation über ein manuell geschriebenes docker-compose.yml, nicht über das Overleaf Toolkit — direkter nachvollziehbar, weniger bewegliche Teile, entspricht dem hier als Referenz laufenden Aufbau (nur ohne dessen Fork und OIDC-Anbindung).
Kein Docker-freier Weg möglich: Overleaf CE ist architektonisch ~10 einzelne Microservices, die nur im offiziellen Container-Image lauffähig zusammengeschnürt sind; ein natives Setup ist von Overleaf selbst nicht unterstützt.

1. Architekturüberblick

Drei Docker-Container, über ein einziges docker-compose.yml orchestriert:

Container	Image	Zweck
`sharelatex`	`sharelatex/sharelatex` (offizielles CE-Image)	Web-App, Compiler-Orchestrierung
`mongo`	`mongo:8.0` (o. kompatible Version)	Projektdaten, Nutzer, Metadaten — läuft als Single-Node Replica-Set (`rs0`), das ist für Overleaf-Transaktionen zwingend, auch bei einer einzelnen Instanz
`redis`	`redis:6.2`	Sessions, Queues

Dazu ein separat gemountetes TeX-Live-Verzeichnis (nicht im Image, sondern als eigenes Volume), damit Version und Paketumfang unabhängig vom Docker-Image kontrolliert werden können — das ist auch der Grund, warum ein zusätzlicher Schritt für Biber nötig ist (siehe Abschnitt 6).

2. Voraussetzungen an den Server

Linux-Server (Debian/Ubuntu empfohlen), Docker Engine + Docker Compose Plugin installiert.
Ausreichend Plattenplatz: TeX Live (Vollschema) ca. 9–10 GB, Docker-Images ca. 2–3 GB, Projekt-/DB-Daten je nach Nutzerzahl gering (im Referenzsystem mit wenigen Projekten < 200 MB).
Temporärer, geplanter Internetzugang über einen Proxy nur für die Installationsphase.
Admin-Rechte, um systemd-Units anzulegen (Docker-Proxy-Konfiguration) und ggf. ein internes TLS-Root-Zertifikat in den System-Trust-Store einzuspielen.

3. Phase 1 – Vorbereitung (online, mit Proxyfreigaben)

3.1 Docker für den Behördenproxy konfigurieren

Der Docker-Daemon liest keine normalen Shell-Umgebungsvariablen. Proxy-Konfiguration erfolgt über ein systemd-Drop-in:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf <<'EOF'
[Service]
Environment="HTTP_PROXY=http://proxy.eure-behoerde.de:PORT"
Environment="HTTPS_PROXY=http://proxy.eure-behoerde.de:PORT"
Environment="NO_PROXY=localhost,127.0.0.1"
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

Ohne diesen Schritt schlägt jeder docker pull mit Timeout fehl.

3.2 TLS-Interception beachten

Falls der Proxy TLS aufbricht (eigene CA, MITM-Prinzip, wie in vielen Behördennetzen üblich): Das interne Root-Zertifikat muss auf dem Server im System-Trust-Store landen (z. B. /usr/local/share/ca-certificates/ + update-ca-certificates unter Debian/Ubuntu), sonst brechen sowohl docker pull als auch der TeX-Live-Installer mit TLS-Fehlern ab. Das ist die häufigste Fehlerquelle bei Downloads über Behörden-Proxies — vorab mit der Netzwerk-/Security-Abteilung klären.

3.3 Vollständige Liste der benötigten Proxyfreigaben

#	Zweck	Host(s)	Protokoll	Nötig für
1	Docker-Image-Metadaten/Auth	`auth.docker.io`	HTTPS/443	alle drei Container-Images
2	Docker-Registry-API	`registry-1.docker.io`	HTTPS/443	alle drei Container-Images
3	Docker-Image-Layer-CDN	`production.cloudflare.docker.com`	HTTPS/443	eigentliche Bilddaten (großer Traffic-Anteil)
4	(optional, Redirect-Ziel)	`index.docker.io`, `docker.io`	HTTPS/443	Fallback, falls (1)–(3) nicht reichen
5	TeX Live	ein einzelner, fest gewählter CTAN-Mirror, z. B. `ftp.tu-chemnitz.de` (Liste: https://ctan.org/mirrors/mirmon)	HTTPS/443	vollständige TeX-Live-Installation inkl. BibTeX/Biber

Da kein Toolkit von GitHub geklont wird, entfällt die GitHub-Freigabe — es müssen nur Docker Hub und ein einzelner CTAN-Mirror erreichbar sein. Das ist die kleinstmögliche Freigabeliste für dieses Vorhaben.

Bewusst NICHT freigeben: mirror.ctan.org als Ziel selbst — das ist ein GeoIP-Redirector, der bei jedem Aufruf auf einen von ~50 wechselnden Drittservern verweisen kann. Für eine nachvollziehbare, eng gefasste Firewall-Freigabe stattdessen direkt einen festen Mirror aus der Mirror-Liste wählen und diesen sowohl für den Bootstrap-Download als auch als -repository-Parameter des Installers verwenden (siehe 3.5).

3.4 Docker-Images ziehen

docker pull sharelatex/sharelatex
docker pull mongo:8.0
docker pull redis:6.2

3.5 TeX Live frisch herunterladen (voller Umfang, fester Mirror)

# Bootstrap-Installer von GENAU EINEM festen Mirror holen
wget https://ftp.tu-chemnitz.de/pub/tex/systems/texlive/tlnet/install-tl-unx.tar.gz
tar xzf install-tl-unx.tar.gz
cd install-tl-*

# Installer auf denselben Mirror festnageln (keine weiteren Redirects)
# scheme-full = komplette Distribution inkl. BibTeX, Biber, biblatex, alle .bst-Stile
./install-tl -repository https://ftp.tu-chemnitz.de/pub/tex/systems/texlive/tlnet \
             -scheme full

Warum scheme-full statt einer schlanken Auswahl: BibTeX ist zwar in jedem Schema enthalten (collection-basic), Biber inkl. biblatex steckt aber in collection-bibtexextra. Im Air-Gap-Betrieb lässt sich später nichts mehr unkompliziert nachinstallieren — deshalb lieber einmalig alles ziehen (~9–10 GB) als hinterher festzustellen, dass ein Stil/Paket fehlt.

GPG-Verifizierung der heruntergeladenen Pakete lässt der Installer standardmäßig aktiv — nicht mit -no-verify-downloads deaktivieren, damit die Herkunft der Pakete nachvollziehbar bleibt (Supply-Chain-Aspekt, gerade im Behördenkontext relevant).

Ergebnis liegt typischerweise unter /usr/local/texlive/<JAHR>/ — dieses Verzeichnis wird im nächsten Schritt als Volume in den Container gemountet.

4. Phase 2 – Biber-Setup-Skript anlegen

bibtex funktioniert nach der scheme-full-Installation ohne weiteres Zutun. Biber braucht einen zusätzlichen Schritt, weil das separat gemountete TeX-Live-Verzeichnis die im Image vorverdrahteten PATH-Einträge überschreibt.

Datei scripts/050_setup_biber.sh anlegen:

#!/bin/bash
ln -sf /usr/local/texlive/<JAHR>/bin/x86_64-linux/biber /usr/local/bin/biber

<JAHR> an die tatsächlich installierte TeX-Live-Version anpassen (z. B. 2026). Dieses Skript wird über /etc/my_init.d/050_setup_biber.sh beim Container-Start ausgeführt (Hook-Mechanismus von phusion baseimage, auf dem auch das offizielle Image basiert).

5. Phase 3 – `docker-compose.yml`

Verzeichnisstruktur auf dem Server, z. B. unter /opt/overleaf/:

/opt/overleaf/
├── docker-compose.yml
├── overleaf_data/     (wird beim ersten Start automatisch angelegt)
├── mongo_data/
├── redis_data/
└── scripts/
    └── 050_setup_biber.sh

docker-compose.yml:

services:
  sharelatex:
    image: sharelatex/sharelatex
    container_name: sharelatex
    restart: always
    depends_on:
      - mongo
      - redis
    ports:
      - "80:80"
    links:
      - mongo
      - redis
    volumes:
      - ./overleaf_data:/var/lib/overleaf
      - /usr/local/texlive/2026:/usr/local/texlive/2026   # Pfad an installierte Version anpassen
      - ./scripts/050_setup_biber.sh:/etc/my_init.d/050_setup_biber.sh
    environment:
      OVERLEAF_APP_NAME: "<Name der Institution>"
      OVERLEAF_MONGO_URL: mongodb://mongo:27017/sharelatex?replicaSet=rs0
      OVERLEAF_REDIS_HOST: redis
      REDIS_HOST: redis

  mongo:
    image: mongo:8.0
    container_name: mongo
    restart: always
    # WICHTIG: Overleaf braucht zwingend ein Replica-Set, auch bei einem einzelnen Mongo-Knoten
    command: "--replSet rs0 --bind_ip_all"
    volumes:
      - ./mongo_data:/data/db

  redis:
    image: redis:6.2
    container_name: redis
    restart: always
    volumes:
      - ./redis_data:/data

Kein EXTERNAL_AUTH/OIDC-Block nötig, da lokale Accounts ausreichen. TLS/Reverse-Proxy ist hier bewusst nicht enthalten — dafür separat einen Reverse Proxy (z. B. nginx) mit intern gültigem TLS-Zertifikat vor Port 80 setzen, auch im abgeschotteten Netz.

6. Phase 4 – Start, Mongo-Replica-Set, Admin-Account

cd /opt/overleaf
docker compose up -d

Nach dem ersten Start des Mongo-Containers muss das Replica-Set einmalig initialisiert werden:

docker exec -it mongo mongosh --eval "rs.initiate({_id: 'rs0', members: [{_id: 0, host: 'mongo:27017'}]})"

Ersten Admin-Account anlegen:

docker exec sharelatex /bin/bash -ce \
  "cd /overleaf/services/web && node modules/server-ce-scripts/scripts/create-user --admin --email=admin@behoerde.de"

Die Ausgabe enthält einen Link, über den das Passwort für diesen Account gesetzt wird. Weitere Nutzer-Accounts (≤10 geplant): Admin legt sie im Admin-Panel an, jeder Nutzer erhält einen Einladungslink per Mail zum Setzen des eigenen Passworts.

7. Phase 5 – Funktionstests vor der Netztrennung

Vor dem endgültigen Abschotten unbedingt testen:

Einfacher Compile-Test (Standard-LaTeX-Dokument ohne Bibliografie).
BibTeX-Test: Testprojekt mit \bibliographystyle{...} + klassischem .bib, erfolgreicher Compile-Lauf im Log prüfen.
Biber-Test: Testprojekt mit \usepackage[backend=biber]{biblatex}, im Compile-Log prüfen, dass biber tatsächlich aufgerufen wird (nicht "command not found").
Offline-Verhalten: Internetzugang des Servers testweise kappen und die Web-UI erneut durchklicken — prüfen, ob irgendwo externe Ressourcen (Fonts, Assets, Update-Checks) fehlschlagen. Erst danach endgültig abschotten.

8. Phase 6 – Endgültige Netztrennung

Proxy-Freigaben (Abschnitt 3.3) beim Netzwerk-/Security-Team zurückziehen lassen.

Docker-Proxy-Konfiguration wieder entfernen:

sudo rm /etc/systemd/system/docker.service.d/http-proxy.conf
sudo systemctl daemon-reload
sudo systemctl restart docker

Server aus dem Netzwerksegment mit Internetzugang herausnehmen / entsprechende Firewall-Regeln final auf "kein Outbound" setzen.

9. Branding / Vorlage

OVERLEAF_APP_NAME deckt den Produktnamen ab.
Logo/CSS-Anpassung erfordert Überschreiben von Assets im Image bzw. Mounten eigener Dateien an bestimmten Pfaden — vor Produktivsetzung an einem Testsystem verifizieren, nicht ungeprüft übernehmen.
Eine institutsweite Standard-Vorlage für neue Projekte lässt sich nicht per Env-Var setzen, sondern nur über den Admin-Bereich bzw. eine vorbereitete Projekt-Kopie — ebenfalls vorab testen.

10. Backup

Kein automatisches Backup-Konzept im Referenzaufbau vorhanden — für den Produktivbetrieb mindestens einplanen:

Regelmäßiger mongodump der Projekt-/Nutzerdatenbank.
Snapshot/Kopie der Daten-Volumes (overleaf_data, mongo_data, redis_data).
TeX-Live-Volume ändert sich nach der Installation nicht mehr und muss nicht laufend gesichert werden, nur einmalig dokumentiert/archiviert werden (falls der Server neu aufgesetzt werden muss, ohne erneut online zu gehen).

11. Offene Punkte für die Entscheidung / Dokumentation gegenüber Vorgesetzten

Thema	Entscheidung	Begründung
Fork vs. offizielles Image	offizielles `sharelatex/sharelatex`	Herstellersupport, kleinere Angriffsfläche, keine SSO-Anforderung mehr, die den Fork nötig gemacht hätte
Toolkit vs. manuelles `docker-compose.yml`	manuelles Compose	direkter nachvollziehbar, weniger bewegliche Teile, keine zusätzliche GitHub-Freigabe nötig
Server Pro vs. Community Edition	Community Edition	kein Budget vorhanden
Sandboxed Compiles	nicht vorhanden, akzeptiertes Restrisiko	kleine, bekannte Nutzergruppe (Studierende, eigene Abschlussarbeiten)
Nutzerverwaltung	lokal, manuell, ≤10 Accounts	kein AD-Anschluss zum Start nötig/gewünscht
BibTeX/Biber	scheme-full TeX Live + Biber-Symlink-Skript	vermeidet Nachinstallation im abgeschotteten Betrieb
Container-Engine	Docker (kein unterstützter Weg ohne Container)	Overleaf CE ist architektonisch auf Microservices im Container-Image angewiesen; nativ nicht von Overleaf unterstützt