> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/sandboxed-compiles.md). # Sandboxed-Kompilierungen Overleaf Pro bietet die Option, Kompilierungen in einer gesicherten Sandbox-Umgebung für Unternehmenssicherheit auszuführen. Dabei wird jedes Projekt in seiner eigenen gesicherten Docker-Umgebung ausgeführt. ### Verbesserte Sicherheit Sandboxed Compiles sind der empfohlene Ansatz für Server Pro, da viele LaTeX-Dokumente im Rahmen des PDF-Kompilierungsprozesses beliebige Shell-Befehle ausführen müssen/können. Wenn Sie Sandboxed Compiles verwenden, läuft jede Kompilierung in einem separaten Docker-Container mit eingeschränkten Fähigkeiten, die nicht mit anderen Benutzern oder Projekten geteilt werden, und hat keinen Zugriff auf externe Ressourcen wie das Host-Netzwerk. {% hint style="warning" %} Wenn Sie versuchen, Overleaf Pro auszuführen **ohne** Sandboxed Compiles läuft die Kompilierung zusammen mit anderen gleichzeitig laufenden Kompilierungen im Haupt-Docker-Container, und Benutzer haben vollen Lese- und Schreibzugriff auf die `sharelatex` Container-Ressourcen (Dateisystem, Netzwerk und Umgebungsvariablen), wenn LaTeX-Kompilierungen ausgeführt werden. {% endhint %} ### Einfachere Paketverwaltung Um Pakete nicht manuell installieren zu müssen, empfehlen wir, Sandboxed Compiles zu aktivieren. Dies ist eine konfigurierbare Einstellung in Server Pro, die Ihren Benutzern Zugriff auf dieselbe TeX-Live-Umgebung wie auf overleaf.com bietet, jedoch innerhalb Ihrer eigenen On-Premise-Installation. Die von Sandboxed Compiles verwendeten TeX-Live-Images enthalten die beliebtesten Pakete und Schriftarten, die mit unseren Galerievorlagen getestet wurden, und gewährleisten so maximale Kompatibilität mit On-Premise-Projekten. Durch das Aktivieren von Sandboxed Compiles können Sie konfigurieren, aus welchen TeX-Live-Versionen Benutzer innerhalb ihres Projekts wählen können, und außerdem eine Standardversion des TeX-Live-Images für neue Projekte festlegen. {% hint style="info" %} Wenn Sie versuchen, Overleaf Pro ohne Sandboxed Compiles auszuführen, wird Ihre Instanz standardmäßig eine Basisschema-Version von TeX Live für Kompilierungen verwenden. Diese Basisschema-Version ist schlank und enthält nur einen sehr begrenzten Satz an LaTeX-Paketen, was für Ihre Benutzer sehr wahrscheinlich zu fehlenden Paketfehlern führt, insbesondere wenn sie versuchen, vorgefertigte Vorlagen zu verwenden. {% endhint %} Da Overleaf Pro so konzipiert wurde, dass es offline funktioniert, gibt es keine automatisierte Möglichkeit, Vorlagen aus der overleaf.com-Galerie in Ihre On-Premise-Installation zu integrieren; es ist jedoch möglich, dies manuell pro Vorlage zu tun. Weitere Informationen dazu finden Sie in unserem Leitfaden zum Übertragen von Vorlagen von overleaf.com: [/pages/c8e0340ccef774c2cef246249bad022d8970b489#transferring-templates-from-overleaf.com](https://ayakaleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/pages/c8e0340ccef774c2cef246249bad022d8970b489#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxed Compiles erfordert, dass der `sharelatex` Container Zugriff auf den Docker-Socket auf dem Host-Rechner hat (über ein Bind-Mount), damit er diese benachbarten Kompilierungs-Container verwalten kann. {% endhint %} ## Wie es funktioniert Wenn Sandboxed Compiles aktiviert sind, wird der Docker-Socket von der Host-Maschine in den `sharelatex` Container eingehängt, sodass der Compiler-Dienst im Container neue Docker-Container auf dem Host erstellen kann. Anschließend führt der LaTeX-Compiler-Dienst (CLSI) für jeden Compilerlauf in jedem Projekt Folgendes aus: * Schreibt die Projektdateien an einen Speicherort innerhalb des `OVERLEAF_DATA_PATH`. * Verwendet den eingehängten Docker-Socket, um einen neuen `texlive` Container für den Kompilierungslauf. * Lässt den `texlive` Container die Projektdaten von dem Speicherort unter `OVERLEAF_DATA_PATH`. * Kompiliert das Projekt innerhalb des `texlive` Container. ### Aktivieren von Sandboxed Compiles #### Für Toolkit-Benutzer Um sandboxed compiles (auch bekannt als Sibling-Container) zu aktivieren, legen Sie die folgenden Konfigurationsoptionen in `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Für Docker-Compose-Benutzer {% hint style="danger" %} Ab Overleaf CE/Server Pro `5.0.3` Umgebungsvariablen wurden umbenannt von `SHARELATEX_*` zu `OVERLEAF_*`. {% endhint %} Wenn Sie eine `4.x` Version (oder früher) verwenden, stellen Sie bitte sicher, dass die Variablen entsprechend präfixiert sind (z. B. `SHARELATEX_MONGO_URL` anstatt `OVERLEAF_MONGO_URL`). 
version: '2'
services:
    sharelatex:
        #...
        volumes:
            - /data/overleaf_data:/var/lib/overleaf
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            #...
            DOCKER_RUNNER: "true"
            SANDBOXED_COMPILES: "true"
            SANDBOXED_COMPILES_HOST_DIR: "/data/overleaf_data/data/compiles"
            #...
        #...
### Ändern des TexLive-Images {% hint style="info" %} Für Benutzer auf dem chinesischen Festland können Sie `ghcr.nju.edu.cn` verwenden, um Ihren Download zu beschleunigen. {% endhint %} Overleaf Pro verwendet drei Umgebungsvariablen, um zu bestimmen, welche TeX-Live-Images für Sandboxed Compiles verwendet werden sollen: * `TEX_LIVE_DOCKER_IMAGE` **(erforderlich),** Das standardmäßige TeX-Live-Image, das für die Kompilierung neuer Projekte verwendet wird. Dieses Image muss in `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(erforderlich),** Eine durch Kommas getrennte Liste benutzerfreundlicher Namen für die Images, verwendet für Frontend-Optionen. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(erforderlich),** Eine durch Kommas getrennte Liste der zu verwendenden TeX-Live-Images. Wenn das Overleaf Toolkit für die Bereitstellung verwendet wird, werden diese Images heruntergeladen oder aktualisiert. Um das Herunterladen zu überspringen, setzen Sie `SIBLING_CONTAINERS_PULL=false` in `config/overleaf.rc`. Wenn Sie Ihre Overleaf-Pro-Instanz mit dem `bin/up` Befehl starten, zieht das Toolkit automatisch alle in `ALL_TEX_LIVE_DOCKER_IMAGES`. Hier ist ein Beispiel, bei dem wir für neue Projekte standardmäßig TeX Live 2025 verwenden und 2024 für bestehende Projekte beibehalten. {% tabs %} {% tab title="gemeinsame Installation" %} Die folgende Konfiguration installiert alle vollständigen TeX-Live-Docker-Images von 2025 bis 2026. Wir empfehlen, vor der Verwendung dieser Konfiguration mindestens 80 GB verfügbaren Speicherplatz zu haben. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1, ghcr.io/ayaka-notes/texlive-full:2025.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026, Texlive 2025 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% tab title="vollständige Installation" %} Die folgende Konfiguration installiert alle vollständigen TeX-Live-Docker-Images von 2020 bis 2026. Wir empfehlen, vor der Verwendung dieser Konfiguration mindestens 256 GB verfügbaren Speicherplatz zu haben. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2026.1,ghcr.io/ayaka-notes/texlive-full:2025.1,ghcr.io/ayaka-notes/texlive-full:2024.1,ghcr.io/ayaka-notes/texlive-full:2023.1,ghcr.io/ayaka-notes/texlive-full:2022.1,ghcr.io/ayaka-notes/texlive-full:2021.1,ghcr.io/ayaka-notes/texlive-full:2020.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2026,Texlive 2025,Texlive 2024,Texlive 2023,Texlive 2022,Texlive 2021,Texlive 2020 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2026.1 ``` {% endcode %} {% endtab %} {% endtabs %} {% hint style="danger" %} Es wird dringend empfohlen, festzulegen **mindestens 2 texlive-full-Images**. Den ausführlichen Grund finden Sie unter [#known-issues](#known-issues "mention") {% endhint %} ### Verfügbare TeX-Live-Images Dies ist eine Reihe von TeX-Live-Images, die speziell für Overleaf optimiert sind und auch zu `TEX_LIVE_DOCKER_IMAGE` und `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2026.1` (Auch `latest` Tag) * `ghcr.io/ayaka-notes/texlive-full:2025.1` * `ghcr.io/ayaka-notes/texlive-full:2024.1` * `ghcr.io/ayaka-notes/texlive-full:2023.1` * `ghcr.io/ayaka-notes/texlive-full:2022.1` * `ghcr.io/ayaka-notes/texlive-full:2021.1` * `ghcr.io/ayaka-notes/texlive-full:2020.1` {% hint style="warning" %} Es gibt ein striktes Schema dafür, wie Images **müssen** getaggt werden (der folgende reguläre Ausdruck gilt `^[0-9]+.[0-9]+`, wobei die erste Zahl das TeX-Live-Jahr und die zweite die Patch-Version bestimmt). {% endhint %} ### Kann ich eine andere Image-Registry verwenden? > Manche fragen sich vielleicht, ob ich `ghcr.io` durch eine andere Mirror-Site ersetzen oder texlive durch ein anderes Image von Docker Hub ersetzen kann? Nein, wir empfehlen das nicht, da die Konfiguration relativ kompliziert ist. Wenn Sie von einer Mirror-Site herunterladen, können Sie Ihr Image umbenennen in `ghcr.io/ayaka-notes/texlive-full`. Wenn Sie jedoch wirklich Ihre eigene Image-Registry verwenden möchten, fügen Sie bitte hinzu: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Dann müssen Sie sicherstellen, dass sich alle texlive-Images in `your-repo`, wie * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Für detaillierte Informationen lesen Sie den Quellcode unten, um zu verstehen, wie wir Ihre Umgebungsvariable parsen: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Legt den standardmäßigen Image-Root fest, falls nicht angegeben let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // imageRoot an Settings exportieren Settings.imageRoot = imageRootPath // allowedImageNames sollte sein: // [ // { imageName: "texlive-2023:latest", imageDesc: "TeX Live 2023" }, // { imageName: "texlive-2022:latest", imageDesc: "TeX Live 2022" }, // ] Settings.allowedImageNames = parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGES) .map((texImage, index) => ({ imageName: texImage.split("/")[texImage.split("/").length - 1], imageDesc: parseTextExtensions(process.env.ALL_TEX_LIVE_DOCKER_IMAGE_NAMES)[index] || texImage.split(':')[1], })) // Am Ende wird imageName mit imageRoot zusammengesetzt, um den vollständigen Image-Pfad zu bilden // Der vollständige Name wird etwa so aussehen: ghcr.io/ayaka-notes/texlive-2023:latest // Legt den standardmäßigen Image-Namen fest, falls nicht angegeben if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // currentImageName an Settings exportieren // Dies ist der Image-Name für neu erstellte Projekte Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Bekannte Probleme Dies ist ein echter Fall aus der Overleaf-Community: > Mit `6.0.1-ext-v3.3`, habe ich diese Einstellungen in `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Das funktioniert problemlos mit `texlive/texlive:latest-full`. Allerdings habe ich ein anderes texlive-Image gezogen `danteev/texlive:2025-10-15` und beide dieser Variablen auf den neuen Image-Namen geändert, aber es funktioniert nicht: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > In den Logs sehe ich Folgendes: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) kein solcher Container - Kein solches Image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) kein solcher Container - Kein solches Image: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Es scheint, dass die aktualisierten Einstellungen in `variables.env` nicht wirksam werden. Die Kompilierung versucht immer noch, das `texlive/texlive:latest-full` Image auszuführen, nicht das neue Image. > > Ich habe versucht, neu zu starten, die Container zu löschen und erneut auszuführen, aber das Problem bleibt dasselbe. > > Irgendwelche Lösungen? Aufgrund einiger technischer Einschränkungen: Wenn Sie nur ein einzelnes Docker-TeXLive-Image einrichten, etwa `texlive-fullA:latest` ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Und nachdem Ihre Overleaf-Instanz eine Weile gelaufen ist, möchten Sie das TeXLive-Image möglicherweise auf `texlive-fullB:latest`. Dann werden Sie feststellen, dass Ihre Benutzer nicht alle Projekte kompilieren können. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Der Grund dafür ist, dass der Name des TeXLive-Full-Images (für Sandbox-Kompilierungen) in jedem Projekt in der Datenbank gespeichert wird. *Nur wenn der Benutzer die TeXLive-Version seines Projekts wechselt, zum Beispiel von 2024 auf 2025, wird der Image-Name in der Datenbank geändert*. Wenn CLSI ein Projekt kompiliert, verwendet es den in der Datenbank gefundenen Container-Image-Namen, um das Projekt direkt zu kompilieren. Wenn Sie nur ein Docker-Image bereitstellen, können Benutzer das zum Kompilieren des Projekts verwendete Image nicht ändern. In diesem Fall müssen Sie ein Skript schreiben, um **manuell zu ändern** das TeXLive-Image für alle Benutzerprojekte in MongoDB. ### Fehlersuche Führen Sie den folgenden Befehl aus, um das CLSI-Log aus dem Toolkit zu prüfen: {% code overflow="wrap" %} ```bash bin/logs clsi ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/de/konfiguration/overleaf-toolkit/sandboxed-compiles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.