> For the complete documentation index, see [llms.txt](https://overleaf-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://overleaf-pro.ayaka.space/on-premises/nl/configuratie/overleaf-toolkit/geisoleerde-compilaties.md). # Geïsoleerde compilaties Overleaf Pro wordt geleverd met de optie om compilaties uit te voeren in een beveiligde sandboxomgeving voor enterprisebeveiliging. Dit doet het door elk project uit te voeren in zijn eigen beveiligde Docker-omgeving. ### Verbeterde beveiliging Sandboxed Compiles is de aanbevolen aanpak voor Server Pro, omdat veel LaTeX-documenten de mogelijkheid vereisen/hebben om willekeurige shell-commando's uit te voeren als onderdeel van het PDF-compileproces. Als je Sandboxed Compiles gebruikt, draait elke compilatie in een afzonderlijke Docker-container met beperkte mogelijkheden die niet gedeeld worden met andere gebruikers of projecten en die geen toegang heeft tot externe bronnen zoals het hostnetwerk. {% hint style="warning" %} Als je probeert Overleaf Pro uit te voeren **zonder** Sandboxed Compiles, draait de compilatie naast andere gelijktijdige compilaties in de hoofd-Docker-container en hebben gebruikers volledige lees- en schrijftoegang tot de `sharelatex` containerbronnen (bestandssysteem, netwerk en omgevingsvariabelen) wanneer LaTeX-compilaties worden uitgevoerd. {% endhint %} ### Eenvoudiger pakketbeheer Om handmatige installatie van pakketten te vermijden, raden we aan Sandboxed Compiles in te schakelen. Dit is een configureerbare instelling binnen Server Pro die je gebruikers toegang geeft tot dezelfde TeX Live-omgeving als op overleaf.com, maar dan binnen je eigen on-premise installatie. TeX Live-afbeeldingen die door Sandboxed Compiles worden gebruikt, bevatten de populairste pakketten en lettertypen die zijn getest met onze galeriemodellen, wat maximale compatibiliteit met on-premise projecten garandeert. Door Sandboxed Compiles in te schakelen kun je 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 je probeert Overleaf Pro uit te voeren zonder Sandboxed Compiles, zal je instantie standaard een basisversie van TeX Live gebruiken voor compilaties. Deze basisversie is lichtgewicht en bevat slechts een zeer beperkte subset van LaTeX-pakketten, wat waarschijnlijk zal resulteren in fouten over ontbrekende pakketten voor je gebruikers, vooral als ze vooraf gebouwde sjablonen proberen te gebruiken. {% endhint %} Omdat Overleaf Pro zo is ontworpen dat het offline werkt, is er geen geautomatiseerde manier om overleaf.com-galeriemodellen te integreren in je 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://overleaf-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 naastliggende 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 compilerservice in de container nieuwe Docker-containers op de host kan maken. Vervolgens zal voor elke uitvoering van de compiler in elk project de LaTeX-compilerservice (CLSI) 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 aan te maken voor de compile-run. * Laat de `texlive` container de projectgegevens lezen vanaf de locatie onder `OVERLEAF_DATA_PATH`. * Compileer het project binnen de `texlive` container vertrouwt. ### Sandboxed Compiles inschakelen #### Voor Toolkit-gebruiker Om gesandboxte compilaties in te schakelen (ook bekend als sibling containers), stel je 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-gebruiker {% hint style="danger" %} Vanaf Overleaf CE/Server Pro `5.0.3` zijn omgevingsvariabelen hernoemd van `SHARELATEX_*` naar `OVERLEAF_*`. {% endhint %} Als je een `4.x` versie gebruikt (of eerder), zorg er dan voor dat de variabelen dienovereenkomstig zijn voorafgegaan (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 kun je `ghcr.nju.edu.cn` gebruiken om je 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` **(verplicht),** 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` **(verplicht),** Een kommagescheiden lijst van gebruiksvriendelijke namen voor de images, gebruikt voor frontend-opties. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(verplicht),** Een kommagescheiden lijst van TeX Live-images die gebruikt moeten worden. Als de Overleaf Toolkit wordt gebruikt voor de implementatie, worden deze images gedownload of bijgewerkt. Om het downloaden over te slaan, stel `SIBLING_CONTAINERS_PULL=false` in `config/overleaf.rc`. Wanneer je je Overleaf Pro-instantie start met het `bin/up` commando, zal de Toolkit automatisch alle images in `ALL_TEX_LIVE_DOCKER_IMAGES`. Hier is een voorbeeld waarbij we TeX Live 2025 als standaard nemen voor nieuwe projecten, en 2024 behouden voor bestaande projecten. {% code title="config/variables.env" overflow="wrap" %} ```dotenv ALL_TEX_LIVE_DOCKER_IMAGES=ghcr.io/ayaka-notes/texlive-full:2025.1, ghcr.io/ayaka-notes/texlive-full:2024.1 ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=Texlive 2025, Texlive 2024 TEX_LIVE_DOCKER_IMAGE=ghcr.io/ayaka-notes/texlive-full:2025.1 ``` {% endcode %} {% hint style="danger" %} Het wordt sterk aanbevolen om **ten minste 2 texlive-full-images**in te stellen. Zie voor een gedetailleerde reden [#known-issues](#known-issues "mention") {% endhint %} ### Beschikbare TeX Live-images Dit zijn een reeks TeX Live-images die speciaal zijn geoptimaliseerd voor Overleaf, en kunnen ook worden toegevoegd aan `TEX_LIVE_DOCKER_IMAGE` en `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (ook de `latest` tag) * `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 met betrekking tot 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, dat raden we niet aan omdat de configuratie relatief ingewikkeld is. Als je van een mirrorsite downloadt, kun je je image hernoemen naar `ghcr.io/ayaka-notes/texlive-full`. Maar als je echt je eigen image-registry wilt gebruiken, voeg dan toe: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Daarna moet je ervoor zorgen dat alle images van texlive in `your-repo`staan, zoals * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` Voor gedetailleerde informatie, lees de onderstaande broncode om te begrijpen hoe we je omgevingsvariabele parsen: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Stel de standaard image-root in als die 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 zal imageName samen met imageRoot worden gebruikt om het volledige imagepad te vormen // De volledige naam zal zijn: ghcr.io/ayaka-notes/texlive-2023:latest // Stel de standaard image-naam in als die 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 van nieuw aangemaakte projecten Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Bekende problemen > 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 een andere texlive-image opgehaald `danteev/texlive:2025-10-15` en beide variabelen gewijzigd naar de nieuwe imagenaam, 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 logs 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. 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 je 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 je je overleaf-instantie een tijdje hebt gebruikt, wil je misschien de TeXLive-image wijzigen naar `texlive-fullB:latest`. Dan zul je zien dat je gebruikers niet al hun projecten kunnen 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 omdat de naam van de TeXLive-Full-image (voor sandbox-compilatie) in elk project in de database wordt opgeslagen. *Alleen wanneer een 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 containerimaginenaam die in de database staat om het project rechtstreeks te compileren. Als je slechts één Docker-image opgeeft, kunnen gebruikers de image die wordt gebruikt om het project te compileren niet wijzigen. In dat geval moet je een script schrijven om **handmatig te wijzigen** de TeXLive-image voor alle gebruikersprojecten in MongoDB. ### Debug Voer het volgende commando 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://overleaf-pro.ayaka.space/on-premises/nl/configuratie/overleaf-toolkit/geisoleerde-compilaties.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.