> 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/nl/configuratie/overleaf-toolkit/sandboxed-compiles.md). # Sandboxed Compiles Overleaf Pro biedt de optie om compilaties uit te voeren in een beveiligde sandboxomgeving voor bedrijfsbeveiliging. Dit doet het door elk project in zijn eigen beveiligde Docker-omgeving uit te voeren. ### Verbeterde beveiliging Sandboxed Compiles zijn de aanbevolen aanpak voor Server Pro vanwege het feit dat veel LaTeX-documenten de mogelijkheid vereisen/hebben om willekeurige shell-opdrachten uit te voeren als onderdeel van het PDF-compilatieproces. Als u Sandboxed Compiles gebruikt, draait elke compilatie in een aparte Docker-container met beperkte mogelijkheden die niet worden gedeeld met andere gebruikers of projecten en heeft die geen toegang tot externe bronnen zoals het hostnetwerk. {% hint style="warning" %} Als u Overleaf Pro probeert uit te voeren **zonder** Sandboxed Compiles, wordt de compilatie uitgevoerd naast andere gelijktijdige compilaties binnen de hoofd-Dockercontainer en hebben gebruikers volledige lees- en schrijftoegang tot de `sharelatex` containerbronnen (bestandssysteem, netwerk en omgevingsvariabelen) tijdens het uitvoeren van LaTeX-compilaties. {% endhint %} ### Eenvoudiger pakketbeheer Om te voorkomen dat u pakketten handmatig moet installeren, raden we aan Sandboxed Compiles in te schakelen. Dit is een configureerbare instelling binnen Server Pro die uw gebruikers toegang geeft tot dezelfde TeX Live-omgeving als op overleaf.com, maar dan binnen uw eigen on-premise installatie. De TeX Live-images die door Sandboxed Compiles worden gebruikt, bevatten de populairste pakketten en lettertypen die zijn getest tegen onze galerijsjablonen, zodat maximale compatibiliteit met on-premise projecten wordt gewaarborgd. Door Sandboxed Compiles in te schakelen kunt u configureren welke TeX Live-versies gebruikers kunnen kiezen binnen hun project, samen met het instellen van een standaard TeX Live-imageversie voor nieuwe projecten. {% hint style="info" %} Als u Overleaf Pro probeert uit te voeren zonder Sandboxed Compiles, gebruikt uw instantie standaard een basis-schemeversie van TeX Live voor compilaties. Deze basisversie is lichtgewicht en bevat slechts een zeer beperkte subset van LaTeX-pakketten, wat er waarschijnlijk toe leidt dat uw gebruikers pakketfouten tegenkomen, vooral als zij vooraf gebouwde sjablonen proberen te gebruiken. {% endhint %} Omdat Overleaf Pro is ontworpen om offline te werken, bestaat er geen geautomatiseerde manier om overleaf.com-galerijsjablonen te integreren in uw on-premise installatie; het is echter wel mogelijk om dit handmatig te doen per sjabloon. Voor meer informatie over hoe dit werkt, bekijk onze handleiding voor het overzetten van sjablonen van overleaf.com: [/pages/93ab258be8724ccf8d09e16545bed31805f33333#transferring-templates-from-overleaf.com](https://ayakaleaf-pro.ayaka.space/on-premises/nl/configuratie/overleaf-toolkit/pages/93ab258be8724ccf8d09e16545bed31805f33333#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxed Compiles vereist dat de `sharelatex` container toegang heeft tot de Docker-socket op de hostmachine (via een bind mount), zodat hij deze naastgelegen compilecontainers kan beheren. {% endhint %} ## Hoe het werkt Wanneer Sandboxed Compiles zijn ingeschakeld, wordt de Docker-socket vanaf de hostmachine gemount in de `sharelatex` container, zodat de compiler-service in de container nieuwe Docker-containers op de host kan aanmaken. Vervolgens zal de LaTeX-compilerdienst (CLSI) voor elke uitvoering van de compiler in elk project het volgende doen: * Schrijf de projectbestanden weg naar een locatie binnen de `OVERLEAF_DATA_PATH`. * Gebruik de gemounte Docker-socket om een nieuwe `texlive` container voor de compilatie uit te voeren. * Laat de `texlive` container de projectgegevens lezen vanaf de locatie onder `OVERLEAF_DATA_PATH`. * Compileer het project in de `texlive` container. ### Sandboxed Compiles inschakelen #### Voor Toolkit-gebruikers Om sandboxed compilaties (ook wel sibling-containers genoemd) in te schakelen, stelt u de volgende configuratieopties in in `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### Voor Docker Compose-gebruikers {% hint style="danger" %} Vanaf Overleaf CE/Server Pro `5.0.3` omgevingsvariabelen zijn hernoemd van `SHARELATEX_*` naar `OVERLEAF_*`. {% endhint %} Als u een `4.x` versie (of eerder) gebruikt, zorg er dan voor dat de variabelen dienovereenkomstig zijn geconfigureerd met het juiste voorvoegsel (bijv. `SHARELATEX_MONGO_URL` in plaats van `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"
            #...
        #...
### De TexLive-image wijzigen {% hint style="info" %} Voor gebruikers op het Chinese vasteland kunt u `ghcr.nju.edu.cn` gebruiken om uw download te versnellen. {% endhint %} Overleaf Pro gebruikt drie omgevingsvariabelen om te bepalen welke TeX Live-images worden gebruikt voor Sandboxed Compiles: * `TEX_LIVE_DOCKER_IMAGE` **(vereist),** De standaard TeX Live-image die wordt gebruikt voor het compileren van nieuwe projecten. Deze image moet zijn opgenomen in `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(vereist),** Een door komma's gescheiden lijst met gebruiksvriendelijke namen voor de images, gebruikt voor frontendopties. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(vereist),** Een door komma's gescheiden lijst met TeX Live-images die moeten worden gebruikt. Als de Overleaf Toolkit wordt gebruikt voor implementatie, worden deze images gedownload of bijgewerkt. Om het downloaden over te slaan, stelt u `SIBLING_CONTAINERS_PULL=false` in `config/overleaf.rc`. Wanneer u uw Overleaf Pro-instantie start met behulp van de `bin/up` opdracht, zal de Toolkit automatisch alle images ophalen die worden vermeld in `ALL_TEX_LIVE_DOCKER_IMAGES`. Hier is een voorbeeld waarin we standaard TeX Live 2025 gebruiken voor nieuwe projecten en 2024 in gebruik houden voor bestaande projecten. {% tabs %} {% tab title="standaardinstallatie" %} De volgende configuratie installeert alle volledige TeX Live Docker-images van 2025 tot 2026. We raden aan om ten minste 80 GB beschikbare opslag te hebben voordat u deze configuratie gebruikt. {% 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="volledige installatie" %} De volgende configuratie installeert alle volledige TeX Live Docker-images van 2020 tot 2026. We raden aan om ten minste 256 GB beschikbare opslag te hebben voordat u deze configuratie gebruikt. {% 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" %} Het wordt sterk aanbevolen om in te stellen **ten minste 2 texlive-full-images**. Zie voor de gedetailleerde reden [#known-issues](#known-issues "mention") {% endhint %} ### Beschikbare TeX Live-images Dit is een reeks TeX Live-images die speciaal zijn geoptimaliseerd voor Overleaf en ook kunnen worden toegevoegd aan `TEX_LIVE_DOCKER_IMAGE` en `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2026.1` (ook `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" %} Er is een strikt schema voor hoe images **moeten** worden getagd (de volgende regex is van toepassing `^[0-9]+.[0-9]+`, waarbij het eerste getal het TeX Live-jaar bepaalt en het tweede de patchversie). {% endhint %} ### Kan ik een andere image registry gebruiken > Sommige mensen vragen zich misschien af of ik `ghcr.io` kan vervangen door een andere mirrorsite, of texlive kan omzetten naar een andere image van Docker Hub? Nee, we raden het niet aan omdat de configuratie relatief ingewikkeld is. Als u downloadt vanaf een mirrorsite, kunt u uw image hernoemen naar `ghcr.io/ayaka-notes/texlive-full`. Maar als u echt uw eigen image registry wilt gebruiken, voeg dan toe: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Vervolgens moet u ervoor zorgen dat alle texlive-images zich in `uw-repo`, zoals * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Voor gedetailleerde informatie: lees de broncode hieronder om te begrijpen hoe we uw omgevingsvariabele parseren: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Stel standaard image-root in als deze niet is opgegeven let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Exporteer imageRoot naar Settings Settings.imageRoot = imageRootPath // allowedImageNames zou moeten zijn: // [ // { 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], })) // Uiteindelijk wordt imageName samen met imageRoot gecombineerd om het volledige imagepad te vormen // De volledige naam zal bijvoorbeeld zijn: ghcr.io/ayaka-notes/texlive-2023:latest // Stel standaard image-naam in als deze niet is opgegeven if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Exporteer currentImageName naar Settings // Dit is de image-naam voor nieuw aangemaakte projecten Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Bekende problemen Dit is een echt geval uit de Overleaf-community: > Met `6.0.1-ext-v3.3`heb ik deze instellingen in `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Dit werkt prima met `texlive/texlive:latest-full`. Maar ik heb nog een andere texlive-image opgehaald `danteev/texlive:2025-10-15` en beide variabelen gewijzigd naar de nieuwe image-naam, maar het werkt niet: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > In de logboeken zie ik het volgende: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP code 404) no such container - No such image: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP code 404) no such container - No such image: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Het lijkt erop dat de bijgewerkte instellingen in `variables.env` geen effect hebben. De compilatie probeert nog steeds de `texlive/texlive:latest-full` image uit te voeren, niet de nieuwe image. > > Ik heb geprobeerd opnieuw op te starten, de containers te verwijderen en opnieuw uit te voeren, maar nog steeds hetzelfde probleem. > > Oplossingen? Vanwege enkele technische beperkingen, als u slechts één Docker-TeXLive-image instelt, zoals `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 ``` En nadat uw Overleaf-instantie enige tijd heeft gedraaid, wilt u misschien de TeXLive-image wijzigen naar `texlive-fullB:latest`. Dan zult u zien dat uw gebruikers niet in staat zijn om alle projecten te compileren. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Dit komt doordat de naam van de TeXLive-Full-image (voor sandboxcompilaties) in elk project in de database wordt opgeslagen. *Alleen wanneer de gebruiker de TeXLive-versie van zijn project wijzigt, bijvoorbeeld van 2024 naar 2025, wordt de image-naam in de database gewijzigd*. Wanneer CLSI een project compileert, gebruikt het de container-image-naam die in de database is gevonden om het project rechtstreeks te compileren. Als u slechts één Docker-image opgeeft, kunnen gebruikers de image die wordt gebruikt om het project te compileren niet wijzigen. In dat geval moet u een script schrijven om **handmatig te wijzigen** de TeXLive-image voor alle gebruikersprojecten in MongoDB. ### Debuggen Voer de volgende opdracht uit om de clsi-log van de Toolkit te controleren: {% 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/nl/configuratie/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.