> 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/on-premises-no/konfigurasjon/overleaf-toolkit/sandboxed-compiles.md). # Sandkassekompileringer Overleaf Pro leveres med muligheten til å kjøre kompileringer i et sikret sandkassmiljø for sikkerhet på bedriftsnivå. 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, fordi 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ører hver kompilering i en separat Docker-container med begrensede muligheter, som ikke deles med noen annen bruker eller noe annet prosjekt, og har ingen tilgang til eksterne ressurser som vertsnettverket. {% hint style="warning" %} Hvis du forsøker å kjøre Overleaf Pro **uten** Sandboxed Compiles, kjører kompileringen sammen med andre samtidige kompileringer inne i hoved-Docker-containeren, og brukere har full lese- og skrivetilgang til `sharelatex` containerressursene (filsystem, nettverk og miljøvariabler) når LaTeX-kompileringer kjøres. {% endhint %} ### Enklere pakkehåndtering For å unngå å installere pakker manuelt, anbefaler vi å aktivere Sandboxed Compiles. Dette er en konfigurerbar innstilling i Server Pro som gir brukerne dine tilgang til det samme TeX Live-miljøet 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 skrifttypene som er testet mot galleri-malene våre, 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 schema-versjon 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 utviklet for å fungere frakoblet, finnes det ingen automatisert måte å integrere galleri-malene fra overleaf.com i den lokale installasjonen din på; det er imidlertid mulig å gjøre dette manuelt per mal. For mer informasjon om hvordan dette fungerer, kan du se veiledningen vår om å overføre maler fra overleaf.com: [/pages/0a24238bce8490fa904de2c93549892ae85f2722#transferring-templates-from-overleaf.com](https://ayakaleaf-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å verts-maskinen (via en bind-mount), slik at den kan administrere disse søster-kontainerne for kompilering. {% endhint %} ## Slik fungerer det Når Sandboxed Compiles er aktivert, vil Docker-socketen bli montert fra verts-maskinen inn i `sharelatex` containeren, slik at kompileringstjenesten i containeren kan opprette nye Docker-containere på verten. Deretter vil LaTeX-kompileringstjenesten (CLSI) gjøre følgende for hver kjøring av kompilatoren i hvert prosjekt: * Skriv prosjektfilene til en plassering inne i `OVERLEAF_DATA_PATH`. * Bruk den monterte Docker-socketen til å opprette en ny `texlive` container for kompileringen. * La `texlive` containeren lese prosjektdataene fra plasseringen under `OVERLEAF_DATA_PATH`. * Kompiler prosjektet inne i `texlive` containeren. ### Aktivere Sandboxed Compiles #### For Toolkit-brukere For å aktivere sandboxed compiles (også kjent som Sibling containers), sett følgende konfigurasjonsvalg 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` har miljøvariablene blitt omdøpt fra `SHARELATEX_*` til `OVERLEAF_*`. {% endhint %} Hvis du bruker en `4.x` -versjon (eller tidligere), må du sørge for at variablene har riktig prefiks (f.eks. `SHARELATEX_MONGO_URL` i stedet for `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"
            #...
        #...
### Endre TexLive-bildet {% hint style="info" %} For brukere på fastlands-Kina kan du bruke `ghcr.nju.edu.cn` for å få raskere nedlasting. {% endhint %} Overleaf Pro bruker tre miljøvariabler for å avgjøre 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 brukervennlige 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 nedlastingen, sett `SIBLING_CONTAINERS_PULL=false` i `config/overleaf.rc`. Når du starter Overleaf Pro-instansen din med `bin/up` -kommandoen, vil Toolkit automatisk hente alle bildene som er सूचीført 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. {% tabs %} {% tab title="vanlig installasjon" %} Følgende konfigurasjon installerer alle fullstendige TeX Live Docker-bilder fra 2025 til 2026. Vi anbefaler å ha minst 80 GB tilgjengelig lagringsplass før du bruker denne konfigurasjonen. {% 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="full installasjon" %} Følgende konfigurasjon installerer alle fullstendige TeX Live Docker-bilder fra 2020 til 2026. Vi anbefaler å ha minst 256 GB tilgjengelig lagringsplass før du bruker denne konfigurasjonen. {% 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" %} Det anbefales på det sterkeste å sette **minst 2 texlive-full-bilder**. For en detaljert begrunnelse, se [#known-issues](#known-issues "mention") {% endhint %} ### Tilgjengelige TeX Live-bilder Dette er en serie TeX Live-bilder som er spesielt optimalisert for Overleaf, og som også kan legges til i `TEX_LIVE_DOCKER_IMAGE` og `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2026.1` (også `latest` -taggen) * `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" %} 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 bilderegister > Noen lurer kanskje på om jeg kan erstatte `ghcr.io` med et annet speilnettsted, eller bytte texlive til et annet image fra Docker Hub? Nei, vi anbefaler det ikke fordi konfigurasjonen er relativt komplisert. Hvis du laster ned fra et speilnettsted, kan du gi image-et ditt nytt navn til `ghcr.io/ayaka-notes/texlive-full`. Men hvis du virkelig vil bruke ditt eget bilderegister, 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 texlive-bildene er i `your-repo`, 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 image-root hvis ikke oppgitt 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 bli satt sammen med imageRoot for å danne hele image-stien // Det fullstendige navnet vil være slik: ghcr.io/ayaka-notes/texlive-2023:latest // Sett standard image-navn hvis ikke oppgitt if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Eksporter currentImageName til Settings // Dette er image-navnet for nyopprettede prosjekter Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Kjente problemer Dette er et reelt tilfelle fra Overleaf-fellesskapet: > Ved bruk av `6.0.1-ext-v3.3`har jeg 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`. Imidlertid hentet jeg et annet texlive-bilde `danteev/texlive:2025-10-15` og endret begge disse variablene til det nye image-navnet, 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` image-et, ikke det nye image-et. > > Jeg prøvde å starte på nytt, slette containerne og kjøre igjen, men fortsatt det samme problemet. > > Noen løsninger? På grunn av noen tekniske begrensninger, hvis du bare setter opp ett enkelt Docker TeXLive-image, 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-image-et til `texlive-fullB:latest`. Da vil du se at brukerne dine ikke klarer å 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-image-et (for sandbox-kompilering) i hvert prosjekt er lagret i databasen. *Først når brukeren bytter prosjektets TeXLive-versjon, for eksempel fra 2024 til 2025, vil image-navnet bli endret i databasen*. Når CLSI kompilerer et prosjekt, bruker det image-navnet for containeren som finnes i databasen for å kompilere prosjektet direkte. Hvis du bare tilbyr ett Docker-image, vil brukerne ikke kunne endre image-et som brukes til å kompilere prosjektet. I dette tilfellet må du skrive et skript for å **endre manuelt** TeXLive-image-et 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://ayakaleaf-pro.ayaka.space/on-premises/on-premises-no/konfigurasjon/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.