Come installare HRConvert2 sul proprio VPS

Perché eseguire in proprio un convertitore di file

Un convertitore di file self-hosted mantiene il file sul proprio disco. Questo è l'unico motivo per eseguirne uno. Un sito di conversione gratuito riceve il caricamento e non offre alcun modo per sapere cosa ne farà in seguito; quando il file è un contratto firmato di un cliente o una cartella clinica acquisita tramite scansione, il semplice caricamento costituisce già l'incidente. HRConvert2 è un server per la conversione dei file con interfaccia drag-and-drop, scritto in PHP e distribuito con licenza GPLv3. La versione 3.7.4 è stata rilasciata il 18 agosto 2026 e il progetto dichiara di supportare 488 formati.

Non usa database, account o cookie. Un utente corrisponde a una directory temporanea. Ogni conversione viene eseguita localmente da uno strumento a riga di comando: LibreOffice per i documenti, FFmpeg per audio e video, ImageMagick per le immagini, Tesseract per il riconoscimento ottico dei caratteri (OCR) e molti altri strumenti più piccoli per i formati rimanenti. HRConvert2 gestisce la pagina di caricamento, la pipeline e le operazioni di pulizia associate.

Converte un file da un formato a un altro. Non è una suite per l'ufficio nel browser. Se l'obiettivo è consentire agli utenti di modificare documenti in una scheda del browser, confrontare OnlyOffice e Collabora self-hosted. Non è nemmeno un sistema di archiviazione. L'output convertito deve essere eliminato; se i file devono essere conservati, questo compito spetta a un file manager self-hosted.

Requisiti

Debian o Ubuntu, Apache 2.4, PHP 8 o versioni successive e bubblewrap. Bubblewrap (bwrap) è la sandbox e non è opzionale: un server che non riesce a crearne una rifiuta la conversione invece di eseguirla senza sandbox. Il README upstream indica che è sufficiente un Raspberry Pi Model B+, e questo è corretto per la parte PHP. I binari del convertitore determinano i requisiti hardware effettivi; questo aspetto viene trattato più avanti.

Esistono due modalità di installazione. L'immagine Docker è operativa in breve tempo. L'installazione di Apache e PHP richiede una serata, ma mostra esattamente quali componenti sono presenti sul server.

Eseguilo stasera con Docker

L'immagine include tutti i binari dei convertitori, quindi è grande: circa 3 GB ad agosto 2026. Controlla lo spazio libero su disco prima di eseguire il pull.

I tag sono importanti in questo caso. Il tag più recente pubblicato su Docker Hub al 17 agosto 2026 è v3.7.2, mentre la release GitHub più recente è v3.7.4. Il tag latest cambia senza preavviso e questa applicazione espone una superficie di parsing ampia, quindi fissa una versione ed esegui gli upgrade intenzionalmente.

docker pull zelon88/hrconvert2:v3.7.2
docker run -d --name hrconvert2 \
  -p 127.0.0.1:8080:80 \
  --security-opt seccomp=unconfined \
  zelon88/hrconvert2:v3.7.2

docker ps
curl -I http://127.0.0.1:8080/

Un container integro resta nello stato Up e curl restituisce HTTP/1.1 200 OK. Se un container continua a riavviarsi, esiste un problema durante l'avvio: leggi docker logs hrconvert2 prima di modificare qualsiasi altra impostazione.

Due flag sono fondamentali. -p 127.0.0.1:8080:80 pubblica la porta soltanto sull'interfaccia di loopback, quindi nessuna richiesta può raggiungere il convertitore finché non configuri deliberatamente un proxy davanti a esso. L'esempio del progetto usa -p 8080:80 -p 8443:443, che resta in ascolto su tutte le interfacce, inclusa quella pubblica. --security-opt seccomp=unconfined è necessario perché bubblewrap crea la propria sandbox usando le system call per gli user namespace e i mount, bloccate dal profilo seccomp predefinito di Docker. Senza questo flag, le conversioni falliscono e l'applicazione indica il motivo: A sandbox blocks the required syscalls unless it was started with the correct options.

Questo flag comporta un compromesso reale. Allenti il filtro delle system call del container, consentendo all'applicazione di creare al suo interno una sandbox più restrittiva. Le due impostazioni che determinano il comportamento sono $RequireSandbox e $RequireSandboxOnDocker in Resources/config.php, che per impostazione predefinita hanno rispettivamente valore TRUE e FALSE. Poiché il requisito Docker è disattivato per impostazione predefinita, un container senza il flag seccomp può eseguire conversioni senza alcuna sandbox. Dopo aver aggiunto il flag, imposta $RequireSandboxOnDocker = TRUE; per ripristinare il comportamento di rifiuto all'interno del container.

Se Docker è appena stato installato su questa macchina, configura prima il daemon. Eseguire Docker su un VPS descrive l'installazione, il driver di storage e il modo in cui Docker scrive le proprie regole firewall.

Installarlo con Apache e PHP

Il file Documentation/INSTALLATION_INSTRUCTIONS.txt nel repository è la fonte di riferimento e contiene nove passaggi. Questa è la struttura. Iniziare dal server web, dal linguaggio e dalla sandbox:

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-all-dev php8.3-zip php8.3-gd bubblewrap

I nomi php8.3-* corrispondono a Ubuntu 24.04. Eseguire php -v e usare il prefisso corrispondente alla propria versione, perché i nomi dei pacchetti cambiano a ogni release di PHP e quello errato produce Unable to locate package.

Poi installare i convertitori. Questa configurazione copre documenti, immagini, audio, video e OCR, cioè la maggior parte dei formati che vengono effettivamente convertiti:

sudo apt install -y imagemagick ffmpeg libreoffice-common libreoffice-java-common \
  default-jre ghostscript poppler-utils libgxps-utils tesseract-ocr inkscape \
  xvfb clamav curl tar libxcb-cursor0

I formati di archivio, i modelli 3D, gli ebook e le immagini ISO avviabili richiedono più pacchetti. Alcuni sono disponibili nel componente multiverse di Ubuntu. I passaggi 3 e 5 delle istruzioni ufficiali riportano l’elenco completo nell’ordine corretto. Due dipendenze non sono pacchetti apt: il repository fornisce Documentation/Build/ffmpeg-build.sh e Documentation/Build/build-imagemagick-v7.sh per chi ha bisogno di encoder o di ImageMagick 7, che Ubuntu non include nei propri pacchetti. Il supporto per gli ebook proviene dall’installer fornito da calibre. Le istruzioni lo riportano su una sola riga:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdin

Si tratta di uno script del fornitore inoltrato a una shell con privilegi root. È il metodo upstream ed è facoltativo: omettendolo, si perde soltanto la conversione degli ebook.

Ora configurare i limiti di PHP. Le conversioni sono lente e i file sono grandi, quindi i valori predefiniti sono troppo bassi. Il progetto imposta questi valori in php.ini:

max_execution_time = 1200
max_input_time = 90
memory_limit = 512M
post_max_size = 5000M
upload_max_filesize = 5000M
max_file_uploads = 100
display_errors = Off
zlib.output_compression = On

Questi valori presuppongono una macchina con risorse sufficienti. Ridurli prima di installare il programma su un VPS di piccole dimensioni, perché upload_max_filesize = 5000M con max_file_uploads = 100 descrive una singola richiesta che può scrivere una quantità di dati molto superiore alla capacità di un disco da 40 GB. Riavviare Apache e verificare quali valori ha effettivamente caricato PHP:

sudo service apache2 restart
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

Ora configurare la directory di lavoro. $ConvertLoc in Resources/config.php la specifica e il valore predefinito è /DATA/HRConvert2. Il relativo proprietario deve essere l’utente del server web:

sudo mkdir -p /DATA/HRConvert2
sudo chmod -R 0755 /DATA/HRConvert2
sudo chown -R www-data:www-data /DATA/HRConvert2

Estrarre la release nella document root di Apache. La struttura predefinita la colloca in una directory HRProprietary/HRConvert2, mentre $InstLoc in Resources/config.php deve indicare il percorso in cui è stata effettivamente installata. Eseguire quindi la diagnostica integrata, che è il modo più rapido per individuare una dipendenza mancante prima che lo faccia un utente:

sudo php /path/to/HRConvert2/convertCore.php -v

-v controlla l’intera installazione: versioni del core, dipendenze, stato della sandbox e language pack. Le conversioni dei file non sono supportate dalla riga di comando, quindi questo insieme di argomenti ha soltanto una funzione amministrativa.

Perché ogni conversione fallisce su una nuova installazione di Ubuntu 24.04?

La causa è la sandbox ed è il problema iniziale più comune. Ubuntu 24.04 e Debian 12 limitano per impostazione predefinita gli user namespace per gli utenti non privilegiati. Bubblewrap richiede uno user namespace per creare la sandbox, quindi bwrap non può avviarsi. Poiché l'applicazione rifiuta di convertire i file senza una sandbox, ogni job fallisce.

Verificalo direttamente:

bwrap --ro-bind / / --dev /dev /bin/true && echo sandbox ok

Un errore di autorizzazione negata indica che lo user namespace è stato bloccato. La soluzione consiste nel creare un profilo AppArmor per il binario bwrap. Per prima cosa, elenca i file ABI e individua il numero più alto presente:

ls /etc/apparmor.d/abi/

Quindi scrivi /etc/apparmor.d/bwrap, sostituendo 4.0 con il numero più alto:

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}

Caricalo:

sudo apparmor_parser -r /etc/apparmor.d/bwrap

Nessun output indica che il profilo è stato caricato. Esegui di nuovo il controllo bwrap: dovrebbe stampare sandbox ok. Da questo momento le conversioni funzioneranno.

Un convertitore pubblico è un parser esposto a utenti sconosciuti

Questa è la ragione per cui esiste il resto dell'articolo. Un convertitore di file raggiungibile da Internet accetta un file arbitrario da una persona anonima e lo passa a LibreOffice, ImageMagick, FFmpeg o Ghostscript. Si tratta di codebase C e C++ di grandi dimensioni, con una lunga storia di bug nei parser. Chi carica il file sceglie il formato e quindi decide quale parser viene eseguito e quale percorso di codice al suo interno viene utilizzato.

HRConvert2 esegue ogni dipendenza all'interno di uno spazio dei nomi bubblewrap. Ogni conversione vede due directory: quella che contiene l'input, montata in sola lettura, e quella che riceve l'output. La rete non è condivisa; secondo le parole del progetto, closes every URL handler in every dependency at once. Questo aspetto è più importante di quanto possa sembrare. ImageMagick e Ghostscript accettano entrambi riferimenti che recuperano un URL. In questo modo un convertitore può diventare uno strumento per effettuare server-side request forgery (SSRF) e raggiungere un endpoint di metadati cloud dall'interno della rete. Senza rete nello spazio dei nomi, il recupero non può avvenire.

Il rifiuto è l'altra metà del meccanismo: A server that cannot build a sandbox refuses the conversion rather than quietly running without one. Uno strumento che interrompe l'operazione in caso di errore è più utile di uno che scrive un avviso in un log che nessuno legge. Per questo il passaggio relativo ad AppArmor riportato sopra non è facoltativo e $RequireSandboxOnDocker merita una verifica prima di esporre il container.

Rafforzare ImageMagick con policy.xml

Il file di policy di ImageMagick aggiunge un secondo livello di protezione sotto la sandbox e conviene configurarlo. In Ubuntu 24.04 con ImageMagick 6, il file si trova in /etc/ImageMagick-6/policy.xml. Visualizzare la configurazione attualmente attiva:

identify -list policy

Il progetto fornisce una policy in Documentation/Build/policy.xml, che costituisce un buon modello. Questa policy nega i coder PS, PS2, PS3, EPS, XPS e MVG e nega i delegate URL, HTTPS, HTTP e gs, consentendo invece PDF:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="delegate" rights="none" pattern="URL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="read|write" pattern="PDF" />

La riga gs è quella più importante. ImageMagick non analizza direttamente PostScript. Avvia Ghostscript tramite una shell, e proprio quel delegate è all'origine delle note vulnerabilità di remote code execution di ImageMagick. Negando il delegate, ImageMagick non passerà mai un file caricato a gs, indipendentemente dal tipo dichiarato dal file.

La stessa policy imposta limiti alle risorse. In questo modo una singola immagine appositamente costruita non può consumare tutte le risorse del sistema:

<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="width" value="16KP"/>
<policy domain="resource" name="height" value="16KP"/>
<policy domain="resource" name="area" value="128MP"/>

Una decompression bomb è un file di piccole dimensioni che dichiara dimensioni enormi. I limiti width, height e area lo rifiutano prima che venga effettuata l'allocazione, quindi il processo termina invece di lasciare che il kernel termini un altro processo.

Esiste anche un problema nella direzione opposta. La policy predefinita di Ubuntu nega completamente il coder PDF, quindi in un sistema non modificato l'elaborazione dei PDF termina con attempt to perform an operation not allowed by the security policy 'PDF'. Questa stringa indica che la policy sta funzionando correttamente. Riabilitare il coder è una scelta da effettuare deliberatamente; anche in quel caso, è opportuno mantenere negato il delegate gs.

Il costo della catena di dipendenze su un VPS di piccole dimensioni

Quando il sistema è inattivo, nulla di tutto questo è costoso. Apache e PHP occupano poche decine di megabyte e i binari di conversione non sono in esecuzione. Il costo complessivo si manifesta tutto insieme quando arriva un file.

La conversione di un documento avvia LibreOffice, che a sua volta avvia un runtime Java. La conversione di un'immagine assegna a ImageMagick 256 MiB di memoria e una mappatura di memoria di 512 MiB secondo la policy precedente. La conversione di un video assegna a FFmpeg tutti i core disponibili, perché questo è il comportamento di FFmpeg con i video. Il valore di memory_limit configurato per PHP è 512M. Questi valori si sommano durante un singolo job, oltre alla memoria usata dal sistema operativo e dal web server.

Di conseguenza, un VPS con 1 GB va in swap al primo documento reale e inizia a thrashare. Quando la memoria termina, l'oom killer del kernel termina il processo con la maggiore dimensione residente. Di solito si tratta di soffice.bin e l'utente vede una conversione fallita senza un messaggio utile. A volte viene terminato apache2 e l'intero sito diventa non disponibile. Verificalo a posteriori con dmesg -T | grep -i "killed process".

Queste sono indicazioni per il dimensionamento, non un benchmark: 4 GB di RAM e due core sono sufficienti per un piccolo team, mentre 2 GB con un file di swap funzionano se il carico è costituito da documenti e immagini e si accetta un'attesa maggiore. Un file di swap non rende più veloce una conversione. Rende lento un picco di carico invece di causare un errore irreversibile. Questa è la differenza tra una pagina bloccata e un'interruzione del servizio. Assegna al disco più spazio di quanto sembri necessario, perché l'immagine da 3 GB, un limite elevato per gli upload e l'output convertito riempiono il disco molto prima che si esaurisca qualsiasi altra risorsa.

Le conversioni sono per natura caratterizzate da picchi di carico. Due persone che caricano un video nello stesso momento utilizzeranno tutti i core e la richiesta successiva dovrà attendere. Non c'è una coda di job davanti a questo processo, quindi l'unico controllo disponibile consiste nei limiti.

Impostare i limiti per impedire che un singolo caricamento riempia il disco

Riduci prima i valori di PHP. Valori come upload_max_filesize = 512M, post_max_size = 512M e max_file_uploads = 20 sono un punto di partenza ragionevole per un server condiviso con 4 GB. Tieni presente che max_execution_time = 1200 consente a una singola richiesta PHP di restare in esecuzione per venti minuti. Questo tempo può essere realmente necessario per una conversione video lunga, ma significa anche che un caricamento lento occupa un worker per venti minuti.

Applica quindi i limiti di dimensione e velocità sul proxy, prima che la richiesta raggiunga PHP:

limit_req_zone $binary_remote_addr zone=convert:10m rate=6r/m;

server {
    listen 443 ssl;
    server_name convert.example.com;

    client_max_body_size 512M;
    client_body_timeout 300s;

    location / {
        limit_req zone=convert burst=4 nodelay;
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 1200s;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

client_max_body_size deve essere almeno pari alla dimensione del file più grande che vuoi convertire. In caso contrario, nginx restituisce 413 Request Entity Too Large e PHP non riceve mai il caricamento. proxy_read_timeout deve essere superiore alla durata della conversione più lunga. In caso contrario, un processo che sta funzionando correttamente dietro il proxy restituisce 504 Gateway Time-out al browser. Il resto di questo server block, inclusa la terminazione TLS (transport layer security), è illustrato in una configurazione di reverse proxy nginx spiegata riga per riga.

Eliminare i file convertiti

Ogni conversione lascia una copia di un file sensibile in una directory leggibile dal web server. La pulizia distingue un convertitore da un archivio di tutto ciò che è stato convertito.

$DeleteThreshold in Resources/config.php indica dopo quanti minuti una sessione scade e il valore predefinito è 60. Impostarlo a 15 quando il contenuto è sensibile. La pulizia viene eseguita passando un argomento della riga di comando al core:

sudo -u www-data php /path/to/HRConvert2/convertCore.php -c
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c=15

-c elimina le sessioni scadute da entrambe le posizioni dei dati usando la soglia configurata. -c=15 usa quindici minuti solo per quella specifica esecuzione. -c=now elimina tutte le sessioni indipendentemente dalla loro età, inclusa quella che un utente sta utilizzando in quel momento per una conversione, quindi va riservato alle attività di manutenzione. Gli stessi argomenti funzionano anche all'interno del container tramite docker exec.

Configurare la pulizia tramite un timer, in modo che non dipenda dal caricamento di una pagina. È sufficiente una riga in /etc/cron.d/hrconvert2:

*/10 * * * * www-data php /path/to/HRConvert2/convertCore.php -c

Dopo alcuni minuti, verificare il risultato con ls /DATA/HRConvert2 e monitorare la scomparsa delle vecchie directory delle sessioni. Poiché quella directory appartiene all'utente del web server, quell'account corrisponde esattamente all'identità che otterrebbe un parser compromesso. Per questo non dovrebbe avere la proprietà di altri file o risorse di valore. Account utente con privilegi minimi su un VPS descrive il modello generale, che in questo caso è ancora più importante.

Inseriscilo dietro l’autenticazione, a meno che l’obiettivo non sia renderlo pubblico

L’installazione predefinita non include account, per progettazione. Chiunque possa raggiungere la pagina può caricare un file ed eseguire i binari del convertitore; i limiti di frequenza rallentano soltanto l’attività. Devi quindi stabilire in quale situazione ti trovi.

Se il servizio è destinato a te e a pochi colleghi, non esporlo affatto. Associa il container all’interfaccia di loopback come mostrato sopra e raggiungilo tramite una rete privata o un tunnel SSH. In questo modo nulla su Internet può inviargli file, eliminando l’intera superficie di attacco invece di limitarsi a filtrarla.

Se deve essere raggiungibile da un browser, configura l’autenticazione davanti al proxy. La Basic auth richiede due comandi e impedisce agli utenti non autorizzati di accedere al modulo di caricamento:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice

location / {
    auth_basic "Converter";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:8080;
}

Ricarica nginx e apri la pagina. Se compare una richiesta di autenticazione, la configurazione funziona. Se non compare, il blocco location modificato non è quello che gestisce la richiesta. Per usare account reali invece di una password condivisa, termina l’autenticazione presso un provider di single sign-on: un server SSO Authentik self-hosted fornisce l’autenticazione forward davanti a un’applicazione che non dispone di un proprio sistema di login.

Se l’obiettivo è un convertitore realmente pubblico, devi accettare le conseguenze e pianificare di conseguenza. Presumi che il sandbox venga sottoposto a tentativi di attacco. Mantieni fissato il tag dell’immagine, applica una policy ImageMagick restrittiva, mantieni bassi i limiti di caricamento ed esegui il servizio su un VPS che non ospita altri dati o servizi importanti.

Modalità di errore e stringhe visualizzate

Ogni conversione non riesce immediatamente. La sandbox non può essere creata. In un'installazione normale, la causa è il profilo AppArmor. In Docker manca --security-opt seccomp=unconfined. L'applicazione lo indica con A sandbox blocks the required syscalls unless it was started with the correct options. e rimanda a See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php.

Non riescono solo le conversioni delle immagini. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! significa che bwrap non è presente o non è raggiungibile tramite il PATH disponibile all'utente del web server.

Non riesce un solo formato, mentre gli altri funzionano. Manca un binario, come indicato chiaramente da ImageMagick may not be installed, or may not be reachable on the system path used by the web server user.. Lo stesso messaggio esiste per FFmpeg e LibreOffice. Esegui convertCore.php -v per verificare cosa riesce a trovare l'installazione e ricorda che il PATH del worker Apache non è quello della shell di login.

Le operazioni sui PDF non riescono a causa di un errore di policy. attempt to perform an operation not allowed by the security policy 'PDF' proviene da policy.xml di ImageMagick, non da HRConvert2.

I caricamenti di grandi dimensioni restituiscono 413. client_max_body_size di nginx è inferiore alle dimensioni del file. Nella catena esistono tre limiti: uno in nginx e due in PHP. Viene applicato il più basso.

Le conversioni si interrompono senza modifiche evidenti. The device where data is stored has an insufficient amount of storage space available. Controlla lo spazio libero e verifica che l'operazione di pulizia venga effettivamente eseguita.

La pulizia genera messaggi nel log. Could not clean the temporary location! e Could not clean the convert location! indicano problemi di proprietà. L'utente del web server deve essere proprietario della directory specificata da $ConvertLoc.

FAQ

È sicuro esporre su Internet un convertitore di file self-hosted?

È sufficientemente sicuro solo se lo si considera un parser esposto a utenti sconosciuti. Ogni upload viene passato a LibreOffice, ImageMagick, FFmpeg o Ghostscript, e chi carica il file può scegliere quale strumento utilizzare. HRConvert2 esegue questi strumenti all'interno di un namespace bubblewrap senza rete e con una directory di input in sola lettura. Inoltre rifiuta le conversioni che non riesce a eseguire in sandbox, un'impostazione predefinita efficace. È comunque preferibile richiedere l'autenticazione, mantenere ridotti i limiti di upload ed eseguire il servizio su un VPS che non contenga altri dati importanti.

Perché ogni conversione non riesce in una nuova installazione di Ubuntu 24.04?

Ubuntu 24.04 e Debian 12 limitano gli user namespace degli utenti non privilegiati, mentre bubblewrap ne richiede uno per creare la sandbox. Poiché l'applicazione rifiuta di convertire i file senza una sandbox, tutti i job falliscono invece di fallire solo in alcuni casi. Scrivere un profilo AppArmor per /usr/bin/bwrap con flags=(unconfined), caricarlo con sudo apparmor_parser -r /etc/apparmor.d/bwrap, quindi verificarlo con bwrap --ro-bind / / --dev /dev /bin/true.

Perché le conversioni non riescono in Docker ma funzionano in un'installazione normale?

Il profilo seccomp predefinito di Docker blocca le system call utilizzate da bubblewrap, quindi la sandbox non può essere creata all'interno del container. Avviarlo con --security-opt seccomp=unconfined, come fa il comando di esecuzione del progetto. Tenere presente che $RequireSandboxOnDocker è FALSE per impostazione predefinita. Un container avviato senza questo flag può quindi eseguire conversioni senza alcuna sandbox. Impostarlo su TRUE dopo avere configurato il flag seccomp.

Quanta RAM richiede un server per la conversione dei file?

Quando è inattivo, il consumo è ridotto, ma una conversione in corso richiede più risorse. LibreOffice avvia un runtime Java, ImageMagick usa 256 MiB di memoria e una mappa da 512 MiB secondo la policy fornita, mentre il limite specifico di PHP è 512M. Su un VPS da 1 GB questa combinazione provoca l'uso della swap e l'out of memory killer termina soffice.bin o apache2. Prevedere 4 GB e due core per un piccolo team e controllare dmesg -T | grep -i "killed process" quando una conversione termina senza messaggi.

Dove vengono salvati i file convertiti e quando vengono eliminati?

Vengono salvati nella directory di lavoro indicata da $ConvertLoc in Resources/config.php, che per impostazione predefinita è /DATA/HRConvert2. $DeleteThreshold imposta, in minuti, l'età oltre la quale una sessione scade e il valore predefinito è 60. La pulizia viene eseguita dalla riga di comando: php convertCore.php -c elimina le sessioni scadute, mentre -c=now elimina immediatamente tutte le sessioni, comprese quelle attive. Inserire -c in un cron entry o in un timer systemd, in modo che l'eliminazione non dipenda dall'accesso di qualcuno al sito.