> 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/sv/konfiguration/overleaf-toolkit/kompileringar-i-sandlada.md). # Kompileringar i sandlåda Overleaf Pro levereras med möjligheten att köra kompileringar i en säker sandbox-miljö för företagsäkerhet. Det gör detta genom att köra varje projekt i sin egen säkra Docker-miljö. ### Förbättrad säkerhet Sandboxade kompileringar är den rekommenderade metoden för Server Pro, eftersom många LaTeX-dokument kräver eller har möjlighet att köra godtyckliga shell-kommandon som en del av PDF-kompileringsprocessen. Om du använder sandboxade kompileringar körs varje kompilering i en separat Docker-container med begränsade rättigheter som inte delas med någon annan användare eller något annat projekt och har ingen åtkomst till externa resurser såsom värdnätverket. {% hint style="warning" %} Om du försöker köra Overleaf Pro **utan** sandboxade kompileringar, körs kompileringen tillsammans med andra samtidiga kompileringar i den huvudsakliga Docker-containern och användarna har full läs- och skrivåtkomst till `sharelatex` containerresurserna (filsystem, nätverk och miljövariabler) när LaTeX-kompileringar körs. {% endhint %} ### Enklare pakethantering För att slippa installera paket manuellt rekommenderar vi att aktivera sandboxade kompileringar. Detta är en konfigurerbar inställning i Server Pro som ger dina användare tillgång till samma TeX Live-miljö som på overleaf.com, men inom din egen lokala installation. TeX Live-avbildningar som används av sandboxade kompileringar innehåller de mest populära paketen och typsnitten som testats mot våra gallerimallar, vilket säkerställer maximal kompatibilitet med lokala projekt. Genom att aktivera sandboxade kompileringar kan du konfigurera vilka TeX Live-versioner användarna får välja mellan i sina projekt, samt ange en standardversion av TeX Live-avbildningen för nya projekt. {% hint style="info" %} Om du försöker köra Overleaf Pro utan sandboxade kompileringar kommer din instans att som standard använda en grundläggande schemaversion av TeX Live för kompileringar. Denna grundversion är lättviktig och innehåller endast en mycket begränsad delmängd av LaTeX-paket, vilket med stor sannolikhet leder till fel med saknade paket för dina användare, särskilt om de försöker använda förbyggda mallar. {% endhint %} Eftersom Overleaf Pro har utformats för att fungera offline finns det inget automatiserat sätt att integrera mallar från overleaf.com:s galleri i din lokala installation; det är dock möjligt att göra detta manuellt per mall. För mer information om hur detta fungerar, se vår guide för överföring av mallar från overleaf.com: [/pages/f623ff96e4601888b696fbe9a3038fba9a81037e#transferring-templates-from-overleaf.com](https://overleaf-pro.ayaka.space/on-premises/sv/konfiguration/overleaf-toolkit/pages/f623ff96e4601888b696fbe9a3038fba9a81037e#transferring-templates-from-overleaf.com "mention"). {% hint style="info" %} Sandboxade kompileringar kräver att `sharelatex` containern har åtkomst till Docker-socketen på värddatorn (via en bind-mount) så att den kan hantera dessa syskoncontainrar för kompilering. {% endhint %} ## Så fungerar det När sandboxade kompileringar är aktiverade kommer Docker-socketen att monteras från värddatorn in i `sharelatex` containern, så att kompileringstjänsten i containern kan skapa nya Docker-containrar på värden. För varje körning av kompilatorn i varje projekt kommer sedan LaTeX-kompileringstjänsten (CLSI) att göra följande: * Skriva ut projektfilerna till en plats inuti `OVERLEAF_DATA_PATH`. * Använda den monterade Docker-socketen för att skapa en ny `texlive` container för kompileringskörningen. * Låta `texlive` containern läsa projektdata från platsen under `OVERLEAF_DATA_PATH`. * Kompilera projektet i `texlive` containern. ### Aktivera sandboxade kompileringar #### För Toolkit-användare För att aktivera sandboxade kompileringar (även kallat syskoncontainrar), ställ in följande konfigurationsalternativ i `overleaf-toolkit/config/overleaf.rc`: {% code title="config/overleaf.rc" %} ```dotenv SERVER_PRO=true SIBLING_CONTAINERS_ENABLED=true ``` {% endcode %} #### För Docker Compose-användare {% hint style="danger" %} Från och med Overleaf CE/Server Pro `5.0.3` miljövariablerna har bytt namn från `SHARELATEX_*` till `OVERLEAF_*`. {% endhint %} Om du använder en `4.x` versionen (eller tidigare), se till att variablerna har motsvarande prefix (t.ex. `SHARELATEX_MONGO_URL` i stället för `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"
            #...
        #...
### Ändra TexLive-avbildningen {% hint style="info" %} För användare i fastlandskina kan du använda `ghcr.nju.edu.cn` för att snabba upp nedladdningen. {% endhint %} Overleaf Pro använder tre miljövariabler för att avgöra vilka TeX Live-avbildningar som ska användas för sandboxade kompileringar: * `TEX_LIVE_DOCKER_IMAGE` **(krävs),** Standardavbildningen av TeX Live som används för att kompilera nya projekt. Denna avbildning måste ingå i `ALL_TEX_LIVE_DOCKER_IMAGES`. * `ALL_TEX_LIVE_DOCKER_IMAGE_NAMES` **(krävs),** En kommaseparerad lista över vänliga namn för avbildningarna, som används för alternativ i gränssnittet. * `ALL_TEX_LIVE_DOCKER_IMAGES` **(krävs),** En kommaseparerad lista över TeX Live-avbildningar som ska användas. Om Overleaf Toolkit används för distribution kommer dessa avbildningar att laddas ner eller uppdateras. För att hoppa över nedladdning, ange `SIBLING_CONTAINERS_PULL=false` i `config/overleaf.rc`. När du startar din Overleaf Pro-instans med `bin/up` kommandot kommer Toolkit automatiskt att hämta alla avbildningar som anges i `ALL_TEX_LIVE_DOCKER_IMAGES`. Här är ett exempel där vi använder TeX Live 2025 som standard för nya projekt och behåller 2024 för befintliga projekt. {% 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 rekommenderas starkt att ange **minst 2 texlive-full-avbildningar**. För detaljerad förklaring, se [#known-issues](#known-issues "mention") {% endhint %} ### Tillgängliga TeX Live-avbildningar Detta är en serie TeX Live-avbildningar som är särskilt optimerade för Overleaf och kan också läggas till i `TEX_LIVE_DOCKER_IMAGE` och `ALL_TEX_LIVE_DOCKER_IMAGES`: * `ghcr.io/ayaka-notes/texlive-full:2025.1` (även `senaste` 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 finns ett strikt schema för hur avbildningar **måste** taggas (följande regex gäller `^[0-9]+.[0-9]+`, där det första numret anger TeX Live-året och det andra patchversionen). {% endhint %} ### Kan jag använda ett annat bildregister > Vissa kanske undrar om jag kan ersätta `ghcr.io` med en annan spegelsida, eller byta texlive till en annan avbildning från Docker Hub? Nej, vi rekommenderar det inte eftersom konfigurationen är relativt komplicerad. Om du laddar ner från en spegelsida kan du döpa om din avbildning till `ghcr.io/ayaka-notes/texlive-full`. Men om du verkligen vill använda ditt eget bildregister, lägg till: {% code title="config/variables.env" overflow="wrap" %} ```dotenv IMAGE_ROOT=hub.your.com/your-repo ``` {% endcode %} Sedan måste du se till att alla avbildningar av texlive finns i `your-repo`, som till exempel * `hub.your.com/your-repo/texlive-full:2025.1` * `hub.your.com/your-repo/texlive-full:2024.1` För detaljerad information, läs källkoden nedan för att förstå hur vi tolkar din miljövariabel: {% code title="sandboxed-compiles/index.mjs" overflow="wrap" expandable="true" %} ```mjs if (process.env.SANDBOXED_COMPILES === 'true') { // Ange standardavbildningens rot om den inte anges let imageRootPath = process.env.IMAGE_ROOT || "ghcr.io/ayaka-notes"; // Exportera imageRoot till Settings Settings.imageRoot = imageRootPath // allowedImageNames ska vara: // [ // { 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], })) // I slutändan kommer imageName att sättas ihop med imageRoot för att bilda den fullständiga bildsökvägen // Det fullständiga namnet kommer att vara till exempel: ghcr.io/ayaka-notes/texlive-2023:latest // Ange standardavbildningens namn om det inte anges if(!process.env.TEX_LIVE_DOCKER_IMAGE) { process.env.TEX_LIVE_DOCKER_IMAGE = imageRootPath + "/" + Settings.allowedImageNames[0].imageName } // Exportera currentImageName till Settings // Detta är namnet på nyss skapade projekts avbildning Settings.currentImageName = process.env.TEX_LIVE_DOCKER_IMAGE } ``` {% endcode %} ### Kända problem > Använda `6.0.1-ext-v3.3`, jag har dessa inställningar i `variables.env`: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=texlive/texlive:latest-full > ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texlive:latest-full > ``` > > Det fungerar bra med `texlive/texlive:latest-full`. Men jag hämtade en annan texlive-avbildning `danteev/texlive:2025-10-15` och ändrade båda dessa variabler till det nya avbildningsnamnet men det fungerar inte: > > ```dotenv > TEX_LIVE_DOCKER_IMAGE=danteev/texlive:2025-10-15 > ALL_TEX_LIVE_DOCKER_IMAGES=danteev/texlive:2025-10-15 > ``` > > I loggarna ser jag följande: > > {% code overflow="wrap" %} > > ``` > {"name":"clsi","level":50,"err":{"message":"(HTTP-kod 404) ingen sådan container - Ingen sådan avbildning: texlive/texlive:latest-full ","name":"Error","stack":"Error: (HTTP-kod 404) ingen sådan container - Ingen sådan avbildning: texlive/texlive:latest-full ... > ``` > > {% endcode %} > > Det verkar som om de uppdaterade inställningarna i `variables.env` inte får genomslag. Kompileringen försöker fortfarande köra `texlive/texlive:latest-full` avbildningen, inte den nya avbildningen. > > Jag försökte starta om, radera containrarna och köra igen, men samma problem kvarstår. > > Några lösningar? På grund av vissa tekniska begränsningar, om du bara sätter upp en enda Docker TeXLive-avbildning, till exempel `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 ``` Och efter att ha kört din Overleaf-instans ett tag kanske du vill ändra TeXLive-avbildningen till `texlive-fullB:latest`. Då kommer du att se att dina användare inte kan kompilera alla projekt. ``` ALL_TEX_LIVE_DOCKER_IMAGES=texlive/texliveA:latest-full ALL_TEX_LIVE_DOCKER_IMAGE_NAMES=TeXLiveA TEX_LIVE_DOCKER_IMAGE=texlive/texliveA:latest-full ``` Detta beror på att namnet på TeXLive-Full-avbildningen (för sandbox-kompilering) i varje projekt lagras i databasen. *Först när användaren byter sitt projekts TeXLive-version, till exempel från 2024 till 2025, ändras avbildningsnamnet i databasen*. När CLSI kompilerar ett projekt använder den avbildningsnamnet som finns i databasen för att direkt kompilera projektet. Om du bara tillhandahåller en Docker-avbildning kommer användarna inte att kunna ändra avbildningen som används för att kompilera projektet. I så fall behöver du skriva ett skript för att **manuellt ändra** TeXLive-avbildningen för alla användarnas projekt i MongoDB. ### Felsök Kör följande kommando för att kontrollera CLSI-loggen från 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/sv/konfiguration/overleaf-toolkit/kompileringar-i-sandlada.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.