Configurare le Sandbox Compiles

Se vuoi configurare le Sandbox Compiles per lo sviluppo, ci sono alcune piccole differenze tra l’ambiente di sviluppo e quello di produzione. Ci sono 3 aspetti a cui prestare attenzione:

• Problema dei permessi dei file
• Condivisione del volume tra history-v1 e filestore
• Problema delle sottodirectory

​

Abilitare le Sandbox Compiles

Qui basta abilitare le Sandbox Compiles come si fa in Overleaf CE. L’unica cosa a cui prestare attenzione è l’utente: qui lo impostiamo a root.

Nell’ambiente di produzione usiamo www-data come utente condiviso tra il container di Overleaf e il container di compilazione TeX. Nell’ambiente di sviluppo, invece, l’utente predefinito nel container è node e non esiste un utente www-data da agganciare. Per questo usiamo root come soluzione alternativa.

Non usare un’immagine costruita da te, altrimenti potresti incorrere in una serie di errori.

#################
#   Sandbox     #
#################
SANDBOXED_COMPILES=true
TEXLIVE_IMAGE_USER=root
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

​

Correggere i permessi dei file

LaTeX viene eseguito nei container fratelli con l’utente specificato nella variabile d’ambiente TEXLIVE_IMAGE_USER. Nell’esempio sopra è impostato su root, che ha uid 0. Questo crea un problema con i permessi indicati sopra, poiché l’utente root non ha il permesso di scrivere nelle sottocartelle di compiles.

Una soluzione rapida consiste nell’assegnare al gruppo root la proprietà e i permessi di lettura e scrittura su compiles, impostando setgid in modo che anche le nuove sottocartelle ereditino questa proprietà:

bash

sudo chown -R 1000:root compiles
sudo chmod -R g+w compiles
sudo chmod g+s compiles

Per la documentazione dettagliata, consulta services/clsi/README.md.

​

Condivisione del volume tra history-v1 e filestore

Per impostazione predefinita, filestore funge da ponte tra S3 e gli altri servizi di Overleaf. Tuttavia, in Overleaf CE o Server Pro tutti i file sono memorizzati localmente per impostazione predefinita. Per questo Overleaf ha introdotto un metodo piuttosto ingegnoso.

server-ce/config/settings.js

switch (process.env.OVERLEAF_FILESTORE_BACKEND) {
  case 's3':
    // s3 case...
  default:
    settings.filestore = {
      backend: 'fs',
      stores: {
        template_files: Path.join(DATA_DIR, 'template_files'),

        // NOTE: The below paths are hard-coded in server-ce/config/production.json, so hard code them here as well.
        // We can use DATA_DIR after switching history-v1 from 'config' to '@overleaf/settings'.
        project_blobs:
          process.env.OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET ||
          '/var/lib/overleaf/data/history/overleaf-project-blobs',
        global_blobs:
          process.env.OVERLEAF_HISTORY_BLOBS_BUCKET ||
          '/var/lib/overleaf/data/history/overleaf-global-blobs',
      },
    }
}

Allo stesso tempo, data/history è usato anche dal servizio history. In questo modo i diversi microservizi possono condividere gli stessi dati. Devi aggiungere il volume history-v1-buckets al servizio filestore nell’ambiente di sviluppo. Altrimenti clsi non sarà in grado di recuperare i file blob dal servizio filestore.

develop/docker-compose.yml

  filestore:
    build:
      context: ..
      dockerfile: services/filestore/Dockerfile
    env_file:
      - dev.env
#    environment:
#      - ENABLE_CONVERSIONS=true
    volumes:
      - filestore-public-files:/overleaf/services/filestore/public_files
      - filestore-template-files:/overleaf/services/filestore/template_files
      - filestore-uploads:/overleaf/services/filestore/uploads
      - history-v1-buckets:/buckets

Devi inoltre aggiungere il nome del BUCKET alle impostazioni di dev.env:

develop/dev.env

OVERLEAF_EDITOR_PROJECT_BLOBS_BUCKET='/buckets/project_blobs'
OVERLEAF_EDITOR_BLOBS_BUCKET='/buckets/blobs'

​

Usare le sottodirectory

Filestore usa useSubdirectories impostato a true per impostazione predefinita; tuttavia, in sviluppo, history v1 appiattisce tutti i dati. Questo causa alcuni conflitti. Per risolvere, devi aggiungere quanto segue:

develop/dev.env

OVERLEAF_EDITOR_PROJECT_BLOBS_BUCKET='/buckets/project_blobs'
OVERLEAF_EDITOR_BLOBS_BUCKET='/buckets/blobs'
NODE_CONFIG='{"persistor":{"useSubdirectories":true}}'

In history v1, tutti i file project_blobs sono originariamente memorizzati così:

node@43eb5dac5b1b:/buckets/project_blobs$ ls
169_609_71360f687c431b9796_5b_889ef3cf71c83a4c027c4e4dc3d1a106b27809  
94e_655_88cb5cc77ab70c9796_a0_e21c740cf81e868f158e30e88985b5ea1d6c19
169_609_71360f687c431b9796_a0_e21c740cf81e868f158e30e88985b5ea1d6c19
94e_655_88cb5cc77ab70c9796_fd_3c0326302e49486d3ea86c833edf9b88320c41
169_609_71360f687c431b9796_fd_3c0326302e49486d3ea86c833edf9b88320c41 

Devi impostare useSubdirectories a true per passare alla modalità a sottodirectory. In questo modo, il carattere _ originale nel blob verrà sostituito con /.