> 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/da/konfiguration/overleaf-toolkit/sandboxed-compiles.md). # Sandboxede kompileringer Overleaf Pro leveres med muligheden for at køre kompileringer i et sikkert sandbox-miljø for 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 muligheder, som ikke deles med nogen anden bruger eller noget andet projekt, og har ingen adgang til eksterne ressourcer såsom værtens netværk. {% 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` containerressourcer (filsystem, netværk og miljøvariabler), når de kører LaTeX-kompileringer. {% endhint %} ### Nemmere 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. Aktivering af sandboxede kompileringer giver dig mulighed for at konfigurere, hvilke TeX Live-versioner brugerne kan vælge imellem i deres projekt, samt at angive en standard TeX Live-imageversion for nye projekter. {% hint style="info" %} Hvis du forsøger at køre Overleaf Pro uden sandboxede kompileringer, vil din instans som standard bruge en basisudgave af TeX Live til kompileringer. Denne basisversion er letvægts og indeholder kun et meget begrænset delmængde af LaTeX-pakker, hvilket sandsynligvis vil resultere i fejl om manglende pakker for dine brugere, især hvis de prøver at bruge forudbyggede skabeloner. {% endhint %} Da Overleaf Pro er arkitektureret til at fungere offline, findes der ikke en automatisk måde at integrere galleriskabeloner fra overleaf.com 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://ayakaleaf-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øskende-kompileringcontainere. {% endhint %} ## Sådan virker det Når sandboxede kompileringer er aktiveret, bliver Docker-socketen monteret fra værtsmaskinen ind i `sharelatex` containeren, så compiler-tjenesten i containeren kan oprette nye Docker-containere på værten. Derefter vil LaTeX-compiler-tjenesten (CLSI) for hver kørsel af compiler 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 kompileringen. * 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 Sibling-containere), 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` er miljøvariabler blevet omdøbt fra `SHARELATEX_*` til `OVERLEAF_*`. {% endhint %} Hvis du bruger en `4.x` -version (eller tidligere), skal du sørge for, at variablerne er præfikset korrekt (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 {% 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 afgøre, 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, brugt 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, bliver disse images downloadet 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 som standard bruger TeX Live 2025 til nye projekter og beholder 2024 i brug for eksisterende projekter. {% tabs %} {% tab title="almindelig installation" %} Følgende konfiguration installerer alle fulde TeX Live Docker-images fra 2025 til 2026. Vi anbefaler at have mindst 80 GB tilgængelig lagerplads, før du bruger denne konfiguration. {% 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="fuld installation" %} Følgende konfiguration installerer alle fulde TeX Live Docker-images fra 2020 til 2026. Vi anbefaler at have mindst 256 GB tilgængelig lagerplads, før du bruger denne konfiguration. {% 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 kraftigste at angive **mindst 2 texlive-full-images**. For en detaljeret begrundelse, se [#known-issues](#known-issues "mention") {% endhint %} ### Tilgængelige TeX Live-images Dette er en række TeX Live-images, der er specielt 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:2026.1` (Også `latest` -tagget) * `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" %} Der er et strengt skema for, hvordan images **skal** tagges (følgende regex gælder `^[0-9]+.[0-9]+`, hvor det første tal bestemmer TeX Live-året og det andet patch-versionen). {% endhint %} ### Kan jeg bruge et andet image-registry > Nogle spekulerer måske på, 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 forholdsvis 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, så tilføj: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Derefter skal du sikre dig, at alle texlive-images er i `your-repo`, som f.eks. * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` For detaljerede oplysninger, læs 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-rod, hvis den ikke er angivet let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Eksportér 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 sidst bliver imageName sat sammen med imageRoot for at danne den fulde image-sti // Det fulde navn vil være som: 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 navnet på de nyoprettede projekters image Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Kendte problemer Dette er et reelt tilfælde fra Overleaf-fællesskabet: > Ved brug af `6.0.1-ext-v3.3`har jeg disse indstillinger i `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Det virker 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` træder ikke i kraft. Kompileringen forsøger stadig at køre `texlive/texlive:latest-full` image'et, ikke det nye image. > > Jeg prøvede at genstarte, slette containerne og køre igen, men det er stadig det samme problem. > > Nogen løsninger? På grund af visse tekniske begrænsninger, hvis du kun sætter et enkelt Docker TeXLive-image op, 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, kan du få lyst til at æ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 er gemt 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 image-navnet på containeren, som findes i databasen, til direkte at kompilere projektet. Hvis du kun leverer ét Docker-image, vil brugerne ikke kunne ændre det image, der bruges til at kompilere projektet. I dette tilfælde skal du skrive et script til **manuelt ændre** TeXLive-image'et for alle brugerprojekter i MongoDB. ### Fejlsøgning 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://ayakaleaf-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.