Self-hosting di un convertitore file con HRConvert2

Perché eseguire in proprio un convertitore di file

Un convertitore di file self-hosted mantiene il file sul proprio disco. Questo è il motivo principale per eseguirne uno. Un sito di conversione gratuito riceve il caricamento e non offre alcun modo per sapere che cosa ne è stato fatto in seguito. Se il file è un contratto firmato di un cliente o una cartella clinica scansionata, il solo caricamento costituisce l'incidente. HRConvert2 è un server di conversione dei file con interfaccia drag-and-drop, scritto in PHP e distribuito con licenza GPLv3. Questa guida è stata scritta sulla versione 3.7.4, rilasciata il 18 August 2026. Da allora il progetto ha avuto uno sviluppo rapido: la versione più recente al 13 October 2026 è v3.9.1, pubblicata il 6 September 2026, e il progetto dichiara il supporto per 488 formati.

Non usa un database, account o cookie. Un utente corrisponde a una directory temporanea. Ogni conversione viene eseguita da uno strumento locale 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 numerosi strumenti minori per gli altri formati. 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 accessibile dal browser. Se serve modificare documenti in una scheda del browser, confrontare OnlyOffice e Collabora self-hosted. Non è nemmeno un sistema di archiviazione. L'output convertito dovrebbe 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: se il server non riesce a creare una sandbox, rifiuta la conversione invece di eseguirla senza sandbox. Il README upstream indica che è sufficiente un Raspberry Pi Model B+, e questo è vero per la parte PHP. I binari del convertitore determinano i requisiti hardware effettivi; questo aspetto viene trattato più avanti.

Sono disponibili 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 questa sera 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.

In questo caso i tag sono importanti. Questa guida fissa v3.7.2, che il 17 agosto 2026 era il tag più recente su Docker Hub e anche la release GitHub più recente di quel giorno. v3.7.4 è stata pubblicata il 18 agosto. Al 13 ottobre 2026, la release GitHub più recente è v3.9.1 (6 settembre 2026), mentre i tag Docker Hub più recenti sono edge (22 settembre 2026) e latest, ovvero v3.8.4 (31 agosto 2026). Il tag latest cambia nel tempo, e questa applicazione espone un'ampia superficie di parsing, quindi fissa una versione ed esegui gli aggiornamenti deliberatamente.

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 rimane nello stato Up e il comando curl restituisce HTTP/1.1 200 OK. Un container che continua a riavviarsi ha un problema durante l'avvio, quindi leggi docker logs hrconvert2 prima di modificare altro.

Due flag sono particolarmente importanti. -p 127.0.0.1:8080:80 pubblica la porta solo sull'interfaccia loopback, quindi nessuna richiesta raggiunge il convertitore finché non configuri deliberatamente un proxy davanti a esso. L'esempio attuale del progetto mappa -p 8080:80, che resta in ascolto su tutte le interfacce, inclusa quella pubblica. --security-opt seccomp=unconfined è necessario perché bubblewrap crea la propria sandbox usando chiamate di sistema per gli user namespace e i mount, bloccate dal profilo seccomp predefinito di Docker. I commenti di config.php per la versione 3.7 aggiungono che su alcuni host è necessario anche --security-opt apparmor=unconfined. Senza il flag, le conversioni falliscono e l'applicazione spiega il motivo: A sandbox blocks the required syscalls unless it was started with the correct options.

Questo flag comporta un compromesso reale. Rende meno restrittivo il filtro delle chiamate di sistema del container, in modo che l'applicazione possa creare al suo interno una sandbox più restrittiva. Le due impostazioni che determinano il comportamento sono $RequireSandbox e $RequireSandboxOnDocker in Resources/config.php. La release v3.7.4 le distribuisce rispettivamente come TRUE e FALSE. Il tag v3.7.2 fissato qui le distribuisce entrambe come FALSE, perché i commenti indicano che un container deve lasciare $RequireSandbox disattivato e lasciare che sia $RequireSandboxOnDocker a decidere. 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.

Le immagini più recenti si avviano in modo diverso. Il progetto ha modificato il processo Docker nella versione v3.8.0 (25 agosto 2026). Il README attuale del progetto e la pagina Docker Hub avviano il container con --cap-add SYS_ADMIN invece dell'opzione seccomp e dichiarano che, senza questa opzione, le conversioni vengono rifiutate. Se sposti il pin a un tag 3.8 o 3.9, usa i flag documentati da quell'immagine. Questa capability è ampia, quindi mantieni il binding della porta 127.0.0.1.

Se Docker è nuovo su questa macchina, configura prima il daemon. Esecuzione di Docker su un VPS illustra l'installazione, il driver di storage e il modo in cui Docker scrive le proprie regole firewall.

Installarlo con Apache e PHP

Fino alla v3.7.4, il file Documentation/INSTALLATION_INSTRUCTIONS.txt nel repository descriveva questa procedura come un'installazione manuale in nove passaggi, e questa sezione segue quella procedura. Dalla v3.8.0, lo stesso file descrive invece uno script di configurazione. Eseguite sudo bash Documentation/Build/hrconvert2-setup.sh dal repository clonato: lo script installa le dipendenze, scrive le impostazioni PHP in un file drop-in invece di modificare php.ini ed estende il profilo AppArmor per bubblewrap. Infine, php convertCore.php -v e --status verificano il risultato. La procedura manuale richiede più tempo, ma consente di sapere esattamente che cosa è stato installato sul server. La struttura è questa. Iniziate 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 in php8.3-* corrispondono a Ubuntu 24.04. Eseguite php -v e usate il prefisso corrispondente alla vostra versione, perché questi nomi di pacchetto cambiano a ogni release di PHP e quello errato produce Unable to locate package.

Passate quindi ai convertitori. Questa selezione copre documenti, immagini, audio, video e OCR, cioè la maggior parte dei formati che gli utenti convertono effettivamente:

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, e alcuni di questi si trovano nel componente multiverse di Ubuntu. Nella v3.7.4, il passaggio 3 delle istruzioni ufficiali conteneva l'elenco completo dei pacchetti apt, mentre il passaggio 5 descriveva le compilazioni dai sorgenti. La guida attuale non contiene elenchi di pacchetti. L'installer legge il manifest Resources/Engine/Contract/depends.php, mentre php convertCore.php --setup --check-depends stampa l'elenco aggiornato e il relativo stato. Due dipendenze possono inoltre essere compilate dai sorgenti. Il repository include Documentation/Build/ffmpeg-build.sh per gli encoder che non sono disponibili nel pacchetto FFmpeg e Documentation/Build/build-imagemagick-v7.sh per ImageMagick 7 su Ubuntu 22.04 o 24.04, che distribuiscono ancora il ramo 6.9. Ubuntu 25.10 e 26.04 LTS distribuiscono ImageMagick 7.1. Il supporto per gli ebook viene fornito dall'installer di calibre, che nelle istruzioni della versione 3.7 era indicato con 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 passato a una shell con privilegi root. È il metodo indicato dal progetto upstream ed è facoltativo: se lo ignorate, l'unica funzionalità persa è la conversione degli ebook.

Passate ora ai limiti di PHP. Le conversioni sono lente e i file sono grandi, quindi i valori predefiniti sono troppo bassi. Le istruzioni della versione 3.7 impostano 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. Riduceteli prima di usarli 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. Riavviate Apache e verificate quali valori PHP ha effettivamente caricato:

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

Ora configurate la directory di lavoro. $ConvertLoc in Resources/config.php la definisce e il valore predefinito è /DATA/HRConvert2. L'utente del server web deve esserne il proprietario:

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

Estraete la release nella document root di Apache. Il layout predefinito la colloca in una directory HRProprietary/HRConvert2, e $InstLoc in Resources/config.php deve indicare il percorso effettivo scelto. Eseguite 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 verifica l'intera installazione: versioni del core, dipendenze, stato della sandbox e pacchetti linguistici. Le conversioni di file non sono supportate dalla riga di comando, quindi questo insieme di argomenti ha esclusivamente funzioni amministrative.

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

La causa è la sandbox. Questo è il problema iniziale più comune. Ubuntu 24.04 limita per impostazione predefinita gli spazi dei nomi utente per i processi non privilegiati tramite AppArmor. Bubblewrap richiede uno spazio dei nomi utente per creare la sandbox, quindi bwrap non può avviarsi. Poiché l'applicazione rifiuta di eseguire conversioni senza sandbox, ogni processo termina con un errore.

Controllare direttamente:

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

Un errore di accesso negato indica che lo spazio dei nomi è stato bloccato. La soluzione consiste nel creare un profilo AppArmor per il binario bwrap. Elencare prima i file ABI e annotare il numero più alto disponibile:

ls /etc/apparmor.d/abi/

Scrivere quindi /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>
}

Caricarlo:

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

Nessun output indica che il profilo è stato caricato. Eseguire nuovamente il controllo bwrap. Dovrebbe stampare sandbox ok. Da questo momento le conversioni funzioneranno.

Debian 12 non presenta questo problema. Il suo kernel consente gli spazi dei nomi utente per i processi non privilegiati e il pacchetto bubblewrap imposta kernel.unprivileged_userns_clone su 1 durante l'avvio. Per questo motivo, il controllo precedente ha esito positivo senza richiedere un profilo. Dalla versione v3.8.0 in poi, lo script di configurazione estende automaticamente il profilo AppArmor di bubblewrap fornito dalla distribuzione.

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. Sono codebase C e C++ di grandi dimensioni, con una lunga storia di bug nei parser. Chi carica il file ne sceglie il formato; di conseguenza sceglie anche quale parser viene eseguito e quale percorso di codice viene seguito al suo interno.

HRConvert2 risponde eseguendo ogni dipendenza all'interno di un namespace 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; nelle parole del progetto, closes every URL handler in every dependency at once. Questo è 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 di server-side request forgery (SSRF) per raggiungere un endpoint di metadati cloud dalla rete interna. Senza rete nel namespace, 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 modo sicuro è più affidabile di uno che registra un avviso in un log che nessuno legge. Per questo il passaggio su AppArmor riportato sopra non è facoltativo. Per lo stesso motivo, conviene esaminare $RequireSandboxOnDocker prima di esporre il container.

Proteggere ImageMagick con policy.xml

Il file di policy di ImageMagick costituisce un secondo livello di protezione sotto la sandbox e conviene configurarlo. Su Ubuntu 24.04 con ImageMagick 6, il file è /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. Nega i coder PS, PS2, PS3, EPS, XPS e MVG, oltre ai 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 come processo esterno e proprio quel delegate è all'origine delle note vulnerabilità di esecuzione di codice da remoto in ImageMagick. Negando il delegate, ImageMagick non passerà mai un file caricato a gs, indipendentemente dal tipo di file dichiarato.

La stessa policy imposta limiti sulle risorse. In questo modo una singola immagine appositamente predisposta 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 allocata la memoria necessaria. Il processo termina invece di provocare l'intervento del kernel.

Esiste anche un rischio nella direzione opposta. La policy predefinita di Ubuntu nega completamente il coder PDF. Di conseguenza, su un sistema non modificato, le operazioni sui PDF falliscono con attempt to perform an operation not allowed by the security policy 'PDF'. Questo messaggio indica che la policy sta funzionando. Riabilitare il coder è una decisione da prendere consapevolmente; quando lo si fa, il delegate gs deve restare negato.

Quanto costa la catena di dipendenze su un VPS di piccole dimensioni

In condizioni di inattività, nulla di tutto questo è costoso. Apache e PHP occupano poche decine di megabyte e i binari di conversione non sono in esecuzione. L'intero costo si manifesta 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 della memoria di 512 MiB in base ai criteri indicati sopra. 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 di PHP è 512M nella configurazione del progetto. Questi valori si sommano durante una singola attività, oltre alla memoria usata dal sistema operativo e dal web server.

Di conseguenza, un VPS con 1 GB di RAM inizia a usare lo swap al primo documento reale e poi entra in thrashing. Quando la memoria si esaurisce, l'out of memory killer del kernel termina il processo con la dimensione residente maggiore. Di solito si tratta di soffice.bin e l'utente vede una conversione non riuscita senza un messaggio utile. A volte si tratta di apache2 e l'intero sito diventa indisponibile. Verificare 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 consiste in documenti e immagini e si accetta l'attesa. Un file di swap non rende più veloce una conversione. Rende un picco di carico lento invece che fatale: questa è la differenza tra una pagina bloccata e un'interruzione del servizio. Assegnare 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 di esaurire qualsiasi altra risorsa.

Le conversioni sono per natura soggette a picchi. Due persone che caricano un video nello stesso momento utilizzano tutti i core disponibili e la richiesta successiva deve attendere. Non c'è una coda di lavori davanti a questo processo, quindi l'unico controllo disponibile consiste nell'impostare dei limiti.

Impostare i limiti che impediscono a un singolo upload di riempire il disco

Riducete 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. Tenete presente che max_execution_time = 1200 consente a una singola richiesta PHP di restare in esecuzione per venti minuti. Questo può essere necessario per la conversione di un video lungo, ma significa anche che un upload lento occupa un worker per venti minuti.

Applicate 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 volete convertire. In caso contrario, nginx restituisce 413 Request Entity Too Large e PHP non riceve mai l'upload. proxy_read_timeout deve essere superiore alla durata della conversione più lunga. In caso contrario, un job che sta funzionando correttamente dietro il proxy restituisce 504 Gateway Time-out al browser. Il resto di quel server block, inclusa la terminazione TLS (transport layer security), è descritto 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 server web. 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. Riducilo a 15 quando il contenuto è sensibile. La pulizia viene eseguita tramite un argomento della riga di comando del 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 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 riservalo alla manutenzione. Gli stessi argomenti funzionano all'interno del container tramite docker exec.

Imposta 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, verifica il risultato con ls /DATA/HRConvert2 e controlla che le directory delle sessioni meno recenti scompaiano. Poiché quella directory appartiene all'utente del server web, proprio quell'account sarebbe disponibile a un parser compromesso. Non deve quindi avere accesso ad altre risorse importanti. Account utente con privilegi minimi su un VPS illustra il modello generale, che in questo caso è ancora più importante.

Proteggilo con l’autenticazione, a meno che l’obiettivo sia renderlo pubblico

L’installazione predefinita non crea 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 loopback, come mostrato sopra, e raggiungilo tramite una rete privata o un tunnel SSH. In questo modo nulla su Internet può inviargli file e rimuovi l’intera superficie di attacco invece di limitarla con filtri. Se i colleghi devono aprirlo in un browser senza pubblicare un hostname o aprire una porta, pubblicarlo come servizio onion v3 mantiene il convertitore associato alla loopback e fornisce comunque un indirizzo da visitare.

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 raggiungere il 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 viene visualizzata una richiesta di autenticazione, la configurazione funziona. Se non viene visualizzata, il blocco location che hai modificato non è quello che gestisce la richiesta. Per usare account reali invece di una password condivisa, termina l’autenticazione presso un provider single sign-on: un server SSO self-hosted Authentik fornisce l’autenticazione forward davanti a un’applicazione che non dispone di un proprio sistema di accesso.

Se l’obiettivo è un convertitore realmente pubblico, devi accettarne le implicazioni e pianificare di conseguenza. Presupponi che la sandbox venga sottoposta a probing. Mantieni fissato il tag dell’immagine, limita in modo rigoroso la policy di ImageMagick, mantieni ridotti i limiti di caricamento ed esegui il servizio su un VPS che non contiene altri dati o servizi importanti.

Modalità di errore e stringhe visualizzate

Tutte le conversioni falliscono immediatamente. La sandbox non può essere creata. In una normale installazione di Ubuntu 24.04, la causa è il profilo AppArmor. Nell'immagine Docker 3.7 fissata, 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 fa riferimento a See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php.

Falliscono solo le conversioni di immagini. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! indica che bwrap non è presente oppure non è raggiungibile tramite il percorso disponibile all'utente del server web.

Un formato non funziona, mentre gli altri sì. 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 può riferirsi a FFmpeg e a LibreOffice. Esegui convertCore.php -v per verificare cosa rileva l'installazione e ricorda che il PATH del processo Apache non coincide con il PATH della tua shell di login.

L'elaborazione dei PDF fallisce con 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 sono presenti tre limiti: uno in nginx e due in PHP. Viene applicato il più restrittivo.

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 la procedura di pulizia venga effettivamente eseguita.

La pulizia segnala un errore nei log. Could not clean the temporary location! e Could not clean the convert location! indicano problemi di proprietà. L'utente del server web deve essere proprietario della directory indicata da $ConvertLoc.

FAQ

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

È sufficientemente sicuro solo se lo si tratta come un parser esposto a utenti sconosciuti. Ogni caricamento viene passato a LibreOffice, ImageMagick, FFmpeg o Ghostscript, e chi carica il file sceglie 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 qualsiasi conversione che non riesce a eseguire in una sandbox, una scelta predefinita efficace. È comunque preferibile richiedere l'autenticazione, mantenere bassi i limiti di caricamento 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 limita gli user namespace non privilegiati tramite AppArmor, mentre bubblewrap ne richiede uno per creare la sandbox. Poiché l'applicazione rifiuta di convertire i file senza una sandbox, tutti i job non riescono 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. Debian 12 consente gli user namespace non privilegiati per impostazione predefinita e non richiede questo passaggio.

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 non è possibile creare la sandbox all'interno del container. Per l'immagine 3.7 fissata in questa guida, avviarla con --security-opt seccomp=unconfined, come indicato nei commenti config.php di quella release. A partire dalla v3.8.0, il progetto documenta invece --cap-add SYS_ADMIN. Tenere presente che $RequireSandboxOnDocker è FALSE per impostazione predefinita, quindi un container avviato senza il flag può eseguire conversioni senza alcuna sandbox. Impostarlo su TRUE dopo aver configurato il flag seccomp.

Quanta RAM richiede un server per la conversione di file?

Il consumo è ridotto quando il servizio è inattivo, ma una conversione in corso richiede più risorse. LibreOffice avvia un runtime Java, ImageMagick utilizza 256 MiB di memoria e una mappa da 512 MiB secondo i criteri forniti, mentre il limite PHP è 512M. Su un VPS da 1 GB questa combinazione causa l'uso della swap e l'out of memory killer termina soffice.bin o apache2. Per un piccolo team, prevedere 4 GB e due core. Controllare dmesg -T | grep -i "killed process" ogni volta che 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à dopo la quale una sessione scade, con 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, incluse quelle attive. Inserire -c in un job cron o in un timer systemd, così l'eliminazione non dipende dall'accesso di qualcuno al sito.