> ## Documentation Index > Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Sandboxed Compiles Ayakaleaf Pro gir deg muligheten til å kjøre kompileringer i et sikret sandkassemiljø for sikkerhet på bedriftsnivå. Dette gjøres ved å kjøre hvert prosjekt i sitt eget sikrede Docker-miljø. ### Forbedret sikkerhet Sandboxed Compiles er den anbefalte tilnærmingen for Ayakaleaf Pro, fordi mange LaTeX-dokumenter krever eller har muligheten til å kjøre vilkårlige skallkommandoer som en del av PDF-kompileringen. Hvis du bruker Sandboxed Compiles, kjøres hver kompilering i en egen Docker-container med begrensede rettigheter som ikke deles med noen annen bruker eller noe annet prosjekt, og som ikke har tilgang til eksterne ressurser som vertsnettverket. Hvis du forsøker å kjøre Ayakaleaf Pro **uten** Sandboxed Compiles, kjøres kompileringen side om side med andre samtidige kompileringer inne i hoved-Docker-containeren, og brukerne har full lese- og skrivetilgang til ressursene i `sharelatex`-containeren (filsystem, nettverk og miljøvariabler) når de kjører LaTeX-kompileringer. ### Enklere pakkehåndtering For å slippe å 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 i din egen lokale installasjon. TeX Live-imagene som brukes av Sandboxed Compiles inneholder de mest populære pakkene og skrifttypene, testet mot malene i galleriet vårt, noe som sikrer maksimal kompatibilitet med lokale prosjekter. Når du aktiverer Sandboxed Compiles, kan du konfigurere hvilke TeX Live-versjoner brukerne kan velge mellom i prosjektene sine, og angi en standardversjon av TeX Live-imaget for nye prosjekter. Hvis du forsøker å kjøre Ayakaleaf Pro uten Sandboxed Compiles, vil instansen som standard bruke en versjon av TeX Live med basic-skjemaet til kompileringer. Denne grunnversjonen er lett og inneholder bare et svært begrenset utvalg LaTeX-pakker, noe som mest sannsynlig vil føre til feil om manglende pakker for brukerne dine, særlig hvis de prøver å bruke ferdige maler. Siden Ayakaleaf Pro er utformet for å fungere uten nettforbindelse, finnes det ingen automatisk måte å integrere galleriets maler fra overleaf.com i den lokale installasjonen; det er imidlertid mulig å gjøre dette manuelt for hver mal. For mer informasjon om hvordan dette fungerer, se veiledningen vår om overføring av maler fra overleaf.com: [#transferring-templates-from-overleaf.com](/no/on-premises/configuration/overleaf-toolkit/templates#transferring-templates-from-overleaf.com "mention"). Sandboxed Compiles krever at `sharelatex`-containeren har tilgang til Docker-socketen på vertsmaskinen (via en bind mount), slik at den kan administrere disse søskencontainerne for kompilering. ## Slik fungerer det Når Sandboxed Compiles er aktivert, monteres Docker-socketen fra vertsmaskinen inn i `sharelatex`-containeren, slik at kompileringstjenesten i containeren kan opprette nye Docker-containere på verten. Deretter gjør LaTeX-kompileringstjenesten (CLSI) følgende for hver kompilering i hvert prosjekt: * Skriver prosjektfilene til en plassering inne i `OVERLEAF_DATA_PATH`. * Bruker den monterte Docker-socketen til å opprette en ny `texlive`-container for kompileringen. * Lar `texlive`-containeren lese prosjektdataene fra plasseringen under `OVERLEAF_DATA_PATH`. * Kompilerer prosjektet inne i `texlive`-containeren. ### Aktivere Sandboxed Compiles #### For Toolkit-brukere For å aktivere Sandboxed Compiles (også kjent som søskencontainere, Sibling containers) angir du følgende konfigurasjonsvalg i `overleaf-toolkit/config/overleaf.rc`: ```dotenv title="config/overleaf.rc" theme={null} SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` #### For Docker Compose-brukere Fra og med Overleaf CE/Server Pro `5.0.3` har miljøvariablene fått nytt navn fra `SHARELATEX_*` til `OVERLEAF_*`. Hvis du bruker en `4.x`-versjon (eller eldre), må du sørge for at variablene har riktig prefiks (f.eks. `SHARELATEX_MONGO_URL` i stedet for `OVERLEAF_MONGO_URL`). ```yml theme={null} 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" #... #... ``` ### Sette opp TeX Live-imaget Brukere i Fastlands-Kina kan erstatte `ghcr.io` med `ghcr.nju.edu.cn` for å få raskere nedlasting. Men **IKKE** bruk `ghcr.nju.edu.cn` direkte i miljøinnstillingene til Toolkit. Du bør beholde `ghcr.io` som eneste valg. Ayakaleaf Pro bruker tre miljøvariabler for å bestemme hvilke TeX Live-images som skal brukes til Sandboxed Compiles: * `TEX_LIVE_DOCKER_IMAGE` (påkrevd), Standard TeX Live-image som brukes til å kompilere nye prosjekter. Dette imaget må være inkludert i `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` (påkrevd), En kommaseparert liste med brukervennlige navn på imagene, som brukes til valgene i frontend. * `ALL_TEX_LIVE_DOCKER_IMAGES` (påkrevd), En kommaseparert liste med TeX Live-images som skal brukes. Hvis Overleaf Toolkit brukes til distribusjonen, blir disse imagene lastet ned eller oppdatert. For å hoppe over nedlastingen, angi `SIBLING_CONTAINERS_PULL=false` i `config/overleaf.rc`. Når du starter Ayakaleaf Pro-instansen med kommandoen `bin/up`, henter Toolkit automatisk alle imagene som er oppført i `ALL_TEX_LIVE_DOCKER_IMAGES`. Her er et eksempel der vi bruker TeX Live 2026 som standard for nye prosjekter, og beholder 2025 for gamle prosjekter. Følgende konfigurasjon installerer alle fullstendige TeX Live Docker-images fra 2025 til 2026. Vi anbefaler at du har minst **64 GB** ledig lagringsplass før du bruker denne konfigurasjonen. ```dotenv title="config/variables.env" wrap theme={null} 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 ``` Følgende konfigurasjon installerer alle fullstendige TeX Live Docker-images fra 2020 til 2026. Vi anbefaler at du har minst **150 GB** ledig lagringsplass før du bruker denne konfigurasjonen. ```dotenv title="config/variables.env" wrap theme={null} 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 ``` Det anbefales sterkt å sette opp **minst 2 texlive-full-images**. For en detaljert begrunnelse, se [#known-issues](/no/on-premises/configuration/overleaf-toolkit/sandboxed-compiles#known-issues "mention") ### Tilgjengelige TeX Live-images Dette er en serie TeX Live-images 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å taggen `latest`) * `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` Det finnes et strengt skjema for hvordan imagene **må** tagges (følgende regex gjelder: `^[0-9]+.[0-9]+`, der det første tallet angir TeX Live-året og det andre patchversjonen). ### Kan jeg bruke et annet image-register? > Noen lurer kanskje på om de 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 imaget nytt navn til `ghcr.io/ayaka-notes/texlive-full`. Men hvis du virkelig vil bruke ditt eget image-register, legger du til: ```dotenv title="config/variables.env" wrap theme={null} IMAGE_ROOT=hub.your.com/your-repo ``` Deretter må du sørge for at alle texlive-imagene ligger 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 kan du lese kildekoden nedenfor for å forstå hvordan vi tolker miljøvariablene dine: ```mjs title="sandboxed-compiles/index.mjs" wrap expandable theme={null} if (process.env.SANDBOXED_COMPILES === 'true') { // Set default image root if not provided let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Export imageRoot to Settings Settings.imageRoot = imageRootPath // allowedImageNames should be: // [ // { 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], })) // In the end, imageName will be put together with imageRoot to form the full image path // The full name will be like: ghcr.io/ayaka-notes/texlive-2023:latest // Set default image name if not provided if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Export currentImageName to Settings // This is the new created projects' image name Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` ### Automatisk synkronisering av TeX Live-images For å slippe å oppdatere instansen manuelt med `bin/up` hver gang, kan du automatisere oppdateringer av TeX Live-imaget. Se [updating-tex-live-full-images-automatically.md](/no/on-premises/maintenance/updating-tex-live-full-images-automatically "mention"). ### Kjente problemer Dette er et reelt tilfelle fra Overleaf-fellesskapet: > Med `6.0.1-ext-v3.3` har jeg disse innstillingene i `variables.env`: > > ```dotenv theme={null} > 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-image, `danteev/texlive:2025-10-15`, og endret begge disse variablene til det nye imagenavnet, og da fungerer det ikke: > > ```dotenv theme={null} > 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: > > ```text wrap theme={null} > {"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 ... > ``` > > Det ser ut til at de oppdaterte innstillingene i `variables.env` ikke trer i kraft. Kompileringen prøver fortsatt å kjøre imaget `texlive/texlive:latest-full`, ikke det nye imaget. > > Jeg har prøvd å starte på nytt, slette containerne og kjøre igjen, men problemet er det samme. > > Noen løsninger? På grunn av enkelte tekniske begrensninger gjelder følgende: hvis du bare setter opp ett enkelt Docker TeXLive-image, for eksempel `texlive-fullA:latest` ```text theme={null} 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 en stund ønsker å endre TeXLive-imaget til `texlive-fullB:latest`, vil du se at brukerne dine ikke kan kompilere noen prosjekter. ```text theme={null} 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-imaget (for sandkassekompilering) for hvert prosjekt lagres i databasen. *Imagenavnet endres i databasen bare når brukeren bytter TeXLive-versjon for prosjektet sitt, for eksempel fra 2024 til 2025*. Når CLSI kompilerer et prosjekt, bruker den containerimagenavnet som finnes i databasen, direkte til å kompilere prosjektet. Hvis du bare oppgir ett Docker-image, kan ikke brukerne endre imaget som brukes til å kompilere prosjektet. I så fall må du skrive et skript som **manuelt endrer** TeXLive-imaget for alle brukerprosjekter i MongoDB. ### Feilsøking og rapportering Kjør følgende kommando for å sjekke clsi-loggen fra Toolkit: ```bash wrap theme={null} bin/logs clsi ``` Hvis du støter på problemer med å kompilere med TeX Live-imagene, kan du opprette en issue her: [https://github.com/ayaka-notes/texlive-full/issues/new?template=texlive-image-bug.yml](https://github.com/ayaka-notes/texlive-full/issues/new?template=texlive-image-bug.yml) For å hjelpe oss med å gjenskape og feilsøke problemet kan du bli bedt om å laste opp prosjektet ditt til Overleaf. Vi henter da prosjektet og kjører kompileringstester med GitHub Action. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.