> 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/da/konfiguration/overleaf-toolkit/sandboxed-compiles.md). # Sandboxed Compiles Overleaf Pro leveres med mulighed for at køre kompileringer i et sikkert sandkassemiljø til virksomhedssikkerhed. Det gør det ved at køre hvert projekt i sit eget sikre Docker-miljø. ### Forbedret sikkerhed Sandboxede kompileringer er den anbefalede tilgang til Server Pro, fordi mange LaTeX-dokumenter kræver/har mulighed for at udføre vilkårlige shell-kommandoer som en del af PDF-kompileringsprocessen. Hvis du bruger sandboxede kompileringer, kører hver kompilering i en separat Docker-container med begrænsede rettigheder, som ikke deles med andre brugere eller projekter, og som ikke har adgang til eksterne ressourcer såsom værtsnetværket. {% hint style="warning" %} Hvis du forsøger at køre Overleaf Pro **uden** sandboxede kompileringer, kører kompileringen side om side med andre samtidige kompileringer inde i den primære Docker-container, og brugerne har fuld læse- og skriveadgang til `sharelatex` containerressourcerne (filsystem, netværk og miljøvariabler), når der køres LaTeX-kompileringer. {% endhint %} ### Nemere pakkehåndtering For at undgå manuelt at installere pakker anbefaler vi at aktivere sandboxede kompileringer. Dette er en konfigurerbar indstilling i Server Pro, som giver dine brugere adgang til det samme TeX Live-miljø som på overleaf.com, men inden for din egen on-premise-installation. TeX Live-images, der bruges af sandboxede kompileringer, indeholder de mest populære pakker og skrifttyper, som er testet mod vores galleri-skabeloner, hvilket sikrer maksimal kompatibilitet med on-premise-projekter. Ved at aktivere sandboxede kompileringer kan du konfigurere, hvilke TeX Live-versioner brugerne kan vælge imellem i deres projekt, samt angive en standardversion af TeX Live-image'et til nye projekter. {% hint style="info" %} Hvis du forsøger at køre Overleaf Pro uden sandboxede kompileringer, vil din instans som standard bruge en grundlæggende scheme-version af TeX Live til kompileringer. Denne grundversion er letvægts og indeholder kun et meget begrænset udvalg af LaTeX-pakker, hvilket sandsynligvis vil medføre fejl på manglende pakker for dine brugere, især hvis de forsøger at bruge færdiglavede skabeloner. {% endhint %} Da Overleaf Pro er arkitektonisk designet til at fungere offline, findes der ikke en automatiseret måde at integrere skabeloner fra overleaf.coms galleri i din on-premise-installation; det er dog muligt at gøre dette manuelt pr. skabelon. For mere information om, hvordan dette fungerer, kan du se vores guide til overførsel af skabeloner fra overleaf.com: [/pages/9ee007b02001686e96a51de909eb27a9d6b39e68#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/da/konfiguration/overleaf-toolkit/pages/9ee007b02001686e96a51de909eb27a9d6b39e68#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxede kompileringer kræver, at `sharelatex` containeren har adgang til Docker-socketen på værtsmaskinen (via en bind mount), så den kan administrere disse søster-kompileringcontainere. {% endhint %} ## Sådan fungerer det Når sandboxede kompileringer er aktiveret, vil Docker-socketen blive monteret fra værtsmaskinen ind i `sharelatex` containeren, så kompileringsservicen i containeren kan oprette nye Docker-containere på værten. Derefter vil LaTeX-kompileringsservicen (CLSI) for hver kørsel af kompilatoren i hvert projekt gøre følgende: * Skriv projektfilerne til en placering inde i `OVERLEAF_DATA_PATH`. * Brug den monterede Docker-socket til at oprette en ny `texlive` container til kompileringskørslen. * Lad `texlive` containeren læse projektdataene fra placeringen under `OVERLEAF_DATA_PATH`. * Kompilér projektet inde i `texlive` containeren. ### Aktivering af sandboxede kompileringer #### For Toolkit-brugere For at aktivere sandboxede kompileringer (også kendt som søstercontainere) skal du angive følgende konfigurationsindstillinger i `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### For Docker Compose-brugere {% hint style="danger" %} Fra og med Overleaf CE/Server Pro `5.0.3` miljøvariabler er blevet omdøbt fra `SHARELATEX_*` til `OVERLEAF_*`. {% endhint %} Hvis du bruger en `4.x` version (eller tidligere) skal du sørge for, at variablerne har det korrekte præfiks (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"
            #...
        #...
### Ændring af TexLive-image'et {% hint style="info" %} For brugere på det kinesiske fastland kan du bruge `ghcr.nju.edu.cn` for at fremskynde din download. {% endhint %} Overleaf Pro bruger tre miljøvariabler til at bestemme, hvilke TeX Live-images der skal bruges til sandboxede kompileringer: * `TEX_LIVE_DOCKER_IMAGE` **(påkrævet),** Det standard TeX Live-image, der bruges til at kompilere nye projekter. Dette image skal være inkluderet i `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(påkrævet),** En kommasepareret liste over venlige navne til images, som bruges til frontend-indstillinger. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(påkrævet),** En kommasepareret liste over TeX Live-images, der skal bruges. Hvis Overleaf Toolkit bruges til implementering, vil disse images blive hentet eller opdateret. For at springe download over, skal du angive `SIBLING_CONTAINERS_PULL=false` i `config/overleaf.rc`. Når du starter din Overleaf Pro-instans ved hjælp af `bin/up` kommandoen, vil Toolkit automatisk hente alle de images, der er angivet i `ALL_TEX_LIVE_DOCKER_IMAGES`. Her er et eksempel, hvor vi bruger TeX Live 2025 som standard for nye projekter og fortsat bruger 2024 for eksisterende projekter. {% 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 anbefales kraftigt at angive **mindst 2 texlive-full-images**. For en detaljeret forklaring, se [#known-issues](#known-issues "mention") {% endhint %} ### Tilgængelige TeX Live-images Dette er en række TeX Live-images, der er særligt optimeret til Overleaf, og som også kan tilføjes til `TEX_LIVE_DOCKER_IMAGE` og `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (Også `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" %} Der er et strengt skema for, hvordan images **skal** mærkes (følgende regex gælder `^[0-9]+.[0-9]+`, hvor det første tal angiver TeX Live-året, og det andet patch-versionen). {% endhint %} ### Kan jeg bruge et andet image-registry > Nogle vil måske undre sig over, om jeg kan erstatte `ghcr.io` med et andet spejlsite eller skifte texlive til et andet image fra Docker Hub? Nej, det anbefaler vi ikke, fordi konfigurationen er relativt kompliceret. Hvis du downloader fra et spejlsite, kan du omdøbe dit image til `ghcr.io/ayaka-notes/texlive-full`. Men hvis du virkelig vil bruge dit eget image-registry, skal du tilføje: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Derefter skal du sørge for, at alle texlive-images er i `your-repo`, ligesom * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` For detaljerede oplysninger kan du læse kildekoden nedenfor for at forstå, hvordan vi fortolker din miljøvariabel: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Angiv standard-image-roden, hvis den ikke er angivet let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Eksportér imageRoot til Settings Settings.imageRoot = imageRootPath // allowedImageNames bør 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 sidst vil imageName blive kombineret med imageRoot for at danne den fulde image-sti // Det fulde navn vil være sådan her: ghcr.io/ayaka-notes/texlive-2023:latest // Angiv standard-image-navn, hvis det ikke er angivet if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Eksportér currentImageName til Settings // Dette er det nyoprettede projekts image-navn Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Kendte problemer > Brug af `6.0.1-ext-v3.3`, jeg har disse indstillinger 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 hentede et andet texlive-image `danteev/texlive:2025-10-15` og ændrede begge disse variabler til det nye image-navn, men det virker 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 ud til, at de opdaterede indstillinger i `variables.env` ikke træder i kraft. Kompileringen forsøger stadig at køre `texlive/texlive:latest-full` image'et, ikke det nye image. > > Jeg forsøgte at genstarte, slette containerne og køre igen, men stadig det samme problem. > > Nogen løsninger? På grund af nogle tekniske begrænsninger, hvis du kun opsætter et enkelt Docker TeXLive-image, såsom `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 efter at have kørt din Overleaf-instans et stykke tid, vil du måske ændre TeXLive-image'et til `texlive-fullB:latest`. Så vil du se, at dine brugere ikke kan kompilere alle projekter. ``` 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 skyldes, at navnet på TeXLive-Full-image'et (til sandboxkompilering) i hvert projekt gemmes i databasen. *Først når brugeren skifter sit projekts TeXLive-version, for eksempel fra 2024 til 2025, ændres image-navnet i databasen*. Når CLSI kompilerer et projekt, bruger det container-image-navnet, der findes i databasen, til direkte at kompilere projektet. Hvis du kun angiver ét Docker-image, kan brugerne ikke ændre det image, der bruges til at kompilere projektet. I så fald skal du skrive et script til **manuelt at ændre** TeXLive-image'et for alle brugerprojekter i mongoDB. ### Fejlretning Kør følgende kommando for at tjekke 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/da/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.