> 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/on-premises-no/konfigurasjon/overleaf-toolkit/sandboxede-kompileringer.md). # Sandboxede kompileringer Overleaf Pro leveres med muligheten til å kjøre kompileringer i et sikkert sandkassemiljø for bedriftssikkerhet. Det gjør dette ved å kjøre hvert prosjekt i sitt eget sikre Docker-miljø. ### Forbedret sikkerhet Sandboxed Compiles er den anbefalte tilnærmingen for Server Pro på grunn av at mange LaTeX-dokumenter krever/har muligheten til å kjøre vilkårlige shell-kommandoer som en del av PDF-kompileringsprosessen. Hvis du bruker Sandboxed Compiles, kjøres hver kompilering i en separat Docker-container med begrensede egenskaper som ikke deles med noen annen bruker eller noe annet prosjekt, og den har ingen tilgang til eksterne ressurser som vertsnettverket. {% hint style="warning" %} Hvis du forsøker å kjøre Overleaf Pro **uten** Sandboxed Compiles, kjøres kompileringen sammen med andre samtidige kompileringer inne i den viktigste Docker-containeren, og brukerne har full lese- og skrivetilgang til `sharelatex` containerressursene (filsystem, nettverk og miljøvariabler) når de kjører LaTeX-kompileringer. {% endhint %} ### Enklere pakkehåndtering For å unngå å installere pakker manuelt, anbefaler vi å aktivere Sandboxed Compiles. Dette er en konfigurerbar innstilling i Server Pro som vil gi brukerne dine tilgang til samme TeX Live-miljø som på overleaf.com, men innenfor din egen lokale installasjon. TeX Live-bildene som brukes av Sandboxed Compiles inneholder de mest populære pakkene og skriftene testet mot våre galleri-malene, noe som sikrer maksimal kompatibilitet med lokale prosjekter. Ved å aktivere Sandboxed Compiles kan du konfigurere hvilke TeX Live-versjoner brukerne kan velge mellom i prosjektet sitt, samt angi en standard TeX Live-bildeversjon for nye prosjekter. {% hint style="info" %} Hvis du forsøker å kjøre Overleaf Pro uten Sandboxed Compiles, vil instansen din som standard bruke en grunnleggende skjemaversjon av TeX Live for kompileringer. Denne grunnleggende versjonen er lettvekts og inneholder bare et svært begrenset utvalg av LaTeX-pakker, noe som mest sannsynlig vil føre til feil om manglende pakker for brukerne dine, spesielt hvis de prøver å bruke forhåndsbygde maler. {% endhint %} Siden Overleaf Pro er arkitektert for å fungere offline, finnes det ikke en automatisert måte å integrere galleri-maler fra overleaf.com i din lokale installasjon; det er imidlertid mulig å gjøre dette manuelt per mal. For mer informasjon om hvordan dette fungerer, kan du se guiden vår for overføring av maler fra overleaf.com: [/pages/0a24238bce8490fa904de2c93549892ae85f2722#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/on-premises-no/konfigurasjon/overleaf-toolkit/pages/0a24238bce8490fa904de2c93549892ae85f2722#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxed Compiles krever at `sharelatex` containeren har tilgang til Docker-socketen på vertsmaskinen (via en bind-mount), slik at den kan administrere disse søsken-kompileringscontainerne. {% endhint %} ## Slik det fungerer Når Sandboxed Compiles er aktivert, blir Docker-socketen montert fra vertsmaskinen inn i `sharelatex` containeren, slik at kompileringstjenesten i containeren kan opprette nye Docker-containere på verten. Deretter vil LaTeX-kompileringstjenesten (CLSI) for hver kjøring av kompilatoren i hvert prosjekt gjøre følgende: * Skriv prosjektfilene til en plassering inne i `OVERLEAF_DATA_PATH`. * Bruk den monterte Docker-socketen til å opprette en ny `texlive` container for kompileringkjøringen. * La `texlive` containeren lese prosjektdataene fra plasseringen under `OVERLEAF_DATA_PATH`. * Kompiler prosjektet i `texlive` beholderen. ### Aktivering av Sandboxed Compiles #### For Toolkit-brukere For å aktivere sandboxed compiles (også kjent som søskencontainere), sett følgende konfigurasjonsalternativer i `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### For Docker Compose-brukere {% hint style="danger" %} Fra og med Overleaf CE/Server Pro `5.0.3` miljøvariabler har blitt omdøpt fra `SHARELATEX_*` til `OVERLEAF_*`. {% endhint %} Hvis du bruker en `4.x` versjon (eller tidligere), sørg for at variablene er prefikset tilsvarende (f.eks. `SHARELATEX_MONGO_URL` i stedet for `OVERLEAF_MONGO_URL`). 
version: '2'
tjenester:
    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"
            #...
        #...
### Endre TeX Live-imaget {% hint style="info" %} For brukere på fastlands-Kina kan du bruke `ghcr.nju.edu.cn` for å akselerere nedlastingen din. {% endhint %} Overleaf Pro bruker tre miljøvariabler for å bestemme hvilke TeX Live-bilder som skal brukes for Sandboxed Compiles: * `TEX_LIVE_DOCKER_IMAGE` **(påkrevd),** Standard TeX Live-bilde som brukes til å kompilere nye prosjekter. Dette bildet må være inkludert i `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(påkrevd),** En kommaseparert liste med vennlige navn for bildene, brukt for alternativer i frontend. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(påkrevd),** En kommaseparert liste over TeX Live-bilder som skal brukes. Hvis Overleaf Toolkit brukes til utrulling, vil disse bildene bli lastet ned eller oppdatert. For å hoppe over nedlasting, sett `SIBLING_CONTAINERS_PULL=false` i `config/overleaf.rc`. Når du starter din Overleaf Pro-instans med `bin/up` kommandoen, vil Toolkit automatisk hente alle bildene som er listet opp i `ALL_TEX_LIVE_DOCKER_IMAGES`. Her er et eksempel der vi bruker TeX Live 2025 som standard for nye prosjekter, og beholder 2024 i bruk for eksisterende prosjekter. {% 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" %} Det er sterkt anbefalt å sette **minst 2 texlive-full-imager**. For en detaljert begrunnelse, se [#known-issues](#known-issues "mention") {% endhint %} ### Tilgjengelige TeX Live-imager Dette er en serie TeX Live-imager som er spesielt optimalisert for Overleaf, og kan også legges til i `TEX_LIVE_DOCKER_IMAGE` og `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (Også `latest` tagg) * `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" %} Det finnes et strengt skjema for hvordan bilder **må** merkes (følgende regex gjelder `^[0-9]+.[0-9]+`, der det første tallet bestemmer TeX Live-året og det andre patch-versjonen). {% endhint %} ### Kan jeg bruke et annet bilde-register > Noen lurer kanskje på om jeg kan erstatte `ghcr.io` med et annet speilsidelager, eller bytte texlive til et annet bilde fra Docker Hub? Nei, vi anbefaler det ikke fordi konfigurasjonen er relativt komplisert. Hvis du laster ned fra et speilsidelager, kan du gi nytt navn til bildet ditt til `ghcr.io/ayaka-notes/texlive-full`. Men hvis du virkelig vil bruke ditt eget bilde-register, legg til: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Deretter må du sørge for at alle bildene av texlive er i `your-repo`, som for eksempel * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` For detaljert informasjon, les kildekoden nedenfor for å forstå hvordan vi tolker miljøvariabelen din: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Sett standard bildekatalog hvis den ikke er angitt let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Eksporter imageRoot til Settings Settings.imageRoot = imageRootPath // allowedImageNames skal være: // [ // { 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], })) // Til slutt vil imageName settes sammen med imageRoot for å danne den fullstendige bildebane // Det fullstendige navnet vil være slik: ghcr.io/ayaka-notes/texlive-2023:latest // Sett standard bildenavn hvis det ikke er angitt if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Eksporter currentImageName til Settings // Dette er bildenavnet for nyopprettede prosjekter Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Kjente problemer > Bruk av `6.0.1-ext-v3.3`, jeg har disse innstillingene i `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Dette fungerer fint med `texlive/texlive:latest-full`. Men jeg hentet et annet texlive-bilde `danteev/texlive:2025-10-15` og endret begge disse variablene til det nye bildenavnet, men det fungerer ikke: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > I loggene ser jeg følgende: > > {% 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 %} > > Det ser ut til at de oppdaterte innstillingene i `variables.env` ikke trer i kraft. Kompileringen prøver fortsatt å kjøre `texlive/texlive:latest-full` bildet, ikke det nye bildet. > > Jeg prøvde å starte på nytt, slette containerne og kjøre på nytt, men fortsatt det samme problemet. > > Noen løsninger? På grunn av noen tekniske begrensninger, hvis du bare setter opp ett enkelt Docker TeXLive-bilde, for eksempel `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 ``` Og etter å ha kjørt Overleaf-instansen din en stund, kan det hende du vil endre TeXLive-bildet til `texlive-fullB:latest`. Da vil du se at brukerne dine ikke kan kompilere alle prosjekter. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Dette er fordi navnet på TeXLive-Full-bildet (for sandkassekompilering) i hvert prosjekt er lagret i databasen. *Bare når brukeren bytter prosjektets TeXLive-versjon, for eksempel fra 2024 til 2025, vil bildenavnet bli endret i databasen*. Når CLSI kompilerer et prosjekt, bruker den container-bildenavnet som finnes i databasen til å kompilere prosjektet direkte. Hvis du bare tilbyr ett Docker-bilde, vil ikke brukerne kunne endre bildet som brukes til å kompilere prosjektet. I dette tilfellet må du skrive et skript for å **manuelt endre** TeXLive-bildet for alle brukerprosjekter i mongoDB. ### Feilsøk Kjør følgende kommando for å sjekke clsi-loggen fra Toolkit: {% 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/on-premises-no/konfigurasjon/overleaf-toolkit/sandboxede-kompileringer.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.