Auto-héberger HRConvert2 pour convertir vos fichiers

Pourquoi auto-héberger un convertisseur de fichiers

Un convertisseur de fichiers auto-hébergé conserve le fichier sur votre propre disque. C’est la seule raison de l’utiliser. Un site de conversion gratuit reçoit le fichier envoyé sans vous permettre de savoir ce qu’il en fait ensuite. Lorsque le fichier est un contrat client signé ou un dossier médical numérisé, l’envoi constitue déjà l’incident. HRConvert2 est un serveur de conversion de fichiers avec glisser-déposer, écrit en PHP et distribué sous licence GPLv3. La version 3.7.4 est sortie le 18 August 2026 et le projet revendique la prise en charge de 488 formats.

Il n’utilise ni base de données, ni comptes, ni cookies. Un utilisateur correspond à un répertoire temporaire. Chaque conversion est effectuée localement par un outil en ligne de commande : LibreOffice pour les documents, FFmpeg pour l’audio et la vidéo, ImageMagick pour les images, Tesseract pour la reconnaissance optique de caractères (OCR), ainsi qu’une longue liste d’outils plus petits pour les autres formats. HRConvert2 fournit la page d’envoi, le pipeline et le nettoyage associés.

Il convertit un fichier d’un format vers un autre. Ce n’est pas une suite bureautique dans le navigateur. Si vous voulez que des utilisateurs modifient des documents dans un onglet, consultez plutôt OnlyOffice et Collabora auto-hébergés. Ce n’est pas non plus un espace de stockage. Les fichiers convertis sont destinés à être supprimés. Si les fichiers doivent être conservés quelque part, utilisez plutôt un gestionnaire de fichiers auto-hébergé.

Ce qu’il faut

Debian ou Ubuntu, Apache 2.4, PHP 8 ou une version ultérieure, et bubblewrap. Bubblewrap (bwrap) fournit le sandbox et il est obligatoire : un serveur qui ne peut pas créer de sandbox refuse la conversion au lieu de l’exécuter sans sandbox. Le README amont indique qu’un Raspberry Pi Model B+ suffit, ce qui est vrai pour la partie PHP. Les binaires de conversion déterminent les besoins matériels réels. Ce point est détaillé plus loin.

Deux approches sont possibles. L’image Docker fonctionne immédiatement. L’installation d’Apache et de PHP prend une soirée, mais elle permet de voir exactement ce qui est installé sur le serveur.

Exécutez-le ce soir avec Docker

L’image contient tous les binaires de conversion, donc elle est volumineuse : environ 3 GB en août 2026. Vérifiez l’espace disque disponible avant de la télécharger.

Les tags sont importants ici. Le tag le plus récent publié sur Docker Hub au 17 août 2026 est v3.7.2, tandis que la version la plus récente sur GitHub est v3.7.4. Le tag latest change sans préavis, et cette application expose une surface d’analyse importante. Épinglez donc une version et effectuez les mises à niveau volontairement.

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 conteneur en bon état reste dans l’état Up et la commande curl renvoie HTTP/1.1 200 OK. Un conteneur qui redémarre en boucle a un problème au démarrage. Consultez donc docker logs hrconvert2 avant de modifier quoi que ce soit d’autre.

Deux options sont déterminantes. -p 127.0.0.1:8080:80 publie le port uniquement sur loopback. Rien n’atteint donc le convertisseur tant que vous ne placez pas volontairement un proxy devant lui. L’exemple fourni par le projet mappe -p 8080:80 -p 8443:443, qui écoute sur toutes les interfaces, y compris l’interface publique. --security-opt seccomp=unconfined est nécessaire, car bubblewrap construit son sandbox à l’aide d’appels système liés aux user namespaces et au montage, que le profil seccomp par défaut de Docker bloque. Sans cette option, les conversions échouent et l’application vous indique pourquoi : A sandbox blocks the required syscalls unless it was started with the correct options.

Cette option implique un compromis réel. Vous assouplissez le filtre d’appels système du conteneur afin que l’application puisse construire son propre sandbox plus restrictif à l’intérieur du conteneur. Les deux paramètres qui déterminent le comportement sont $RequireSandbox et $RequireSandboxOnDocker dans Resources/config.php. Ils valent par défaut TRUE et FALSE. Comme l’exigence Docker est désactivée par défaut, un conteneur sans l’option seccomp peut effectuer des conversions sans aucun sandbox. Une fois l’option ajoutée, définissez $RequireSandboxOnDocker = TRUE; pour rétablir le comportement de refus à l’intérieur du conteneur.

Si Docker est nouveau sur cette machine, configurez d’abord le daemon. Exécuter Docker sur un VPS couvre l’installation, le storage driver et la manière dont Docker écrit ses propres règles de firewall.

Installez-le avec Apache et PHP

Le fichier Documentation/INSTALLATION_INSTRUCTIONS.txt du dépôt fait foi et comporte neuf étapes. Voici sa structure. Commencez par le serveur web, le langage et le sandbox :

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

Les noms indiqués dans php8.3-* correspondent à Ubuntu 24.04. Exécutez php -v et utilisez le préfixe correspondant à votre version, car les noms des paquets changent à chaque version de PHP et un mauvais préfixe provoque Unable to locate package.

Passons ensuite aux convertisseurs. Cette liste couvre les documents, les images, l’audio, la vidéo et l’OCR, c’est-à-dire la plupart des formats que les utilisateurs convertissent réellement :

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

Les formats d’archives, les modèles 3D, les ebooks et les images ISO amorçables nécessitent davantage de paquets. Certains se trouvent dans le composant multiverse d’Ubuntu. Les étapes 3 et 5 des instructions officielles fournissent la liste complète, dans l’ordre. Deux dépendances ne sont pas des paquets apt : le dépôt fournit Documentation/Build/ffmpeg-build.sh et Documentation/Build/build-imagemagick-v7.sh pour les utilisateurs qui ont besoin d’encodeurs ou d’ImageMagick 7, qu’Ubuntu ne fournit pas sous forme de paquet. La prise en charge des ebooks passe par l’installateur de calibre, fourni par les instructions sous la forme d’une seule ligne :

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

Il s’agit d’un script du fournisseur transmis à un shell exécuté avec les privilèges root. C’est la méthode proposée par le projet amont et elle reste facultative : si vous l’ignorez, seule la conversion des ebooks ne sera pas disponible.

Vérifiez ensuite les limites de PHP. Les conversions sont lentes et les fichiers volumineux ; les valeurs par défaut sont donc trop faibles. Le projet définit ces paramètres dans 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

Ces valeurs supposent que la machine dispose de suffisamment de ressources. Réduisez-les avant d’utiliser un petit VPS, car upload_max_filesize = 5000M avec max_file_uploads = 100 décrit une seule requête pouvant écrire bien plus que ne peut contenir un disque de 40 GB. Redémarrez Apache et vérifiez les valeurs réellement chargées par PHP :

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

Configurez maintenant le répertoire de travail. $ConvertLoc dans Resources/config.php le définit, et sa valeur par défaut est /DATA/HRConvert2. L’utilisateur du serveur web doit en être propriétaire :

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

Décompressez la release dans le document root d’Apache. La disposition par défaut la place dans un dossier HRProprietary/HRConvert2, et $InstLoc dans Resources/config.php doit indiquer l’emplacement où vous l’avez réellement installée. Exécutez ensuite le diagnostic intégré. C’est le moyen le plus rapide de détecter une dépendance manquante avant qu’un utilisateur ne la rencontre :

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

-v parcourt toute l’installation : versions du cœur, vérification des dépendances, état du sandbox et packs de langues. Les conversions de fichiers ne sont pas prises en charge depuis la ligne de commande. Ces arguments servent donc uniquement à l’administration.

Pourquoi chaque conversion échoue-t-elle sur une nouvelle installation d’Ubuntu 24.04 ?

Le problème vient du sandbox. C’est le problème le plus fréquent le premier jour. Ubuntu 24.04 et Debian 12 restreignent par défaut les espaces de noms utilisateur non privilégiés. Bubblewrap a besoin d’un espace de noms utilisateur pour créer son sandbox. bwrap ne peut donc pas démarrer. Comme l’application refuse de convertir sans sandbox, chaque tâche échoue.

Vérifiez-le directement :

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

Une erreur de type « permission denied » signifie que l’espace de noms a été bloqué. La solution consiste à créer un profil AppArmor pour le binaire bwrap. Commencez par lister les fichiers ABI et notez le numéro le plus élevé :

ls /etc/apparmor.d/abi/

Écrivez ensuite /etc/apparmor.d/bwrap, en remplaçant 4.0 par ce numéro :

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

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

Chargez-le :

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

L’absence de sortie signifie que le profil a été chargé. Relancez le contrôle bwrap. Il doit afficher sandbox ok. Les conversions fonctionnent alors.

Un convertisseur public est un parseur exposé à des inconnus

C’est la raison d’être du reste de cet article. Un convertisseur de fichiers accessible depuis Internet accepte un fichier arbitraire envoyé par une personne anonyme, puis le transmet à LibreOffice, ImageMagick, FFmpeg ou Ghostscript. Ces logiciels reposent sur de vastes bases de code C et C++, qui présentent depuis longtemps des bugs dans les parseurs. La personne qui envoie le fichier choisit son format. Elle choisit donc aussi le parseur exécuté et le chemin de code utilisé.

HRConvert2 exécute chaque dépendance dans un namespace bubblewrap. Chaque conversion voit deux répertoires : celui qui contient son fichier d’entrée, monté en lecture seule, et celui qui reçoit son fichier de sortie. Le réseau n’est pas partagé, ce qui, selon les termes du projet, closes every URL handler in every dependency at once. Cette mesure est plus importante qu’il n’y paraît. ImageMagick et Ghostscript acceptent tous deux des références qui récupèrent une URL. Un convertisseur peut ainsi devenir un outil de server-side request forgery (SSRF) permettant d’atteindre un endpoint de métadonnées cloud depuis votre réseau. Sans réseau dans le namespace, la récupération ne peut pas avoir lieu.

Le refus constitue l’autre moitié du dispositif : A server that cannot build a sandbox refuses the conversion rather than quietly running without one. Un outil qui échoue de manière sécurisée vaut mieux qu’un outil qui écrit un avertissement dans un log que personne ne consulte. C’est aussi pourquoi l’étape AppArmor ci-dessus est obligatoire, et pourquoi $RequireSandboxOnDocker mérite d’être examiné avant d’exposer le conteneur.

Renforcer ImageMagick avec policy.xml

Le fichier de stratégie d’ImageMagick constitue une deuxième couche de protection sous le sandbox. Il est utile de le configurer. Sur Ubuntu 24.04 avec ImageMagick 6, le fichier se trouve dans /etc/ImageMagick-6/policy.xml. Affichez la configuration actuellement active :

identify -list policy

Le projet fournit une stratégie dans Documentation/Build/policy.xml, qui constitue un bon modèle. Elle refuse les coders PS, PS2, PS3, EPS, XPS et MVG, ainsi que les delegates URL, HTTPS, HTTP et gs, tout en autorisant 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 ligne gs est la plus importante. ImageMagick n’analyse pas directement le PostScript. Il lance Ghostscript, et c’est dans ce delegate que se trouvent les vulnérabilités connues d’exécution de code à distance d’ImageMagick. Refusez ce delegate : ImageMagick ne transmettra jamais le fichier envoyé à gs, quelle que soit la déclaration de type du fichier.

Cette stratégie définit également des limites de ressources. Elles empêchent une image spécialement conçue de saturer la machine :

<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"/>

Une bombe de décompression est un petit fichier qui déclare des dimensions énormes. Les limites width, height et area le refusent avant l’allocation mémoire. Le processus se termine alors au lieu de laisser le kernel tuer un autre processus.

Le problème inverse existe également. La stratégie fournie par Ubuntu refuse entièrement le coder PDF. Sur un système vierge, le traitement des PDF échoue donc avec attempt to perform an operation not allowed by the security policy 'PDF'. Ce message indique que la stratégie fonctionne. Réautoriser ce coder est une décision à prendre délibérément. Dans ce cas, laissez le delegate gs refusé.

Le coût de la chaîne de dépendances sur un petit VPS

Au repos, rien de tout cela n’est coûteux. Apache et PHP utilisent quelques dizaines de mégaoctets, et les binaires de conversion ne s’exécutent pas du tout. Toute la charge arrive d’un coup lorsqu’un fichier est déposé.

La conversion d’un document démarre LibreOffice, qui démarre un runtime Java. Une conversion d’image attribue 256 MiB de mémoire à ImageMagick, ainsi qu’un memory map de 512 MiB avec la policy ci-dessus. Une conversion vidéo attribue tous les cœurs disponibles à FFmpeg, car c’est ainsi que FFmpeg traite une vidéo. Le memory_limit de PHP est défini à 512M dans la configuration du projet. Ces valeurs s’additionnent pendant un même job, en plus de la mémoire utilisée par le système d’exploitation et le serveur web.

Un VPS de 1 GB utilise donc le swap dès le premier document réel, puis entre en thrashing. Lorsque la mémoire est épuisée, l’out of memory killer du kernel termine le processus dont la taille résidente est la plus importante. Il s’agit généralement de soffice.bin, et l’utilisateur voit une conversion échouer sans message utile. Il s’agit parfois de apache2, ce qui arrête tout le site. Vérifiez-le après coup avec dmesg -T | grep -i "killed process".

Il s’agit d’une recommandation de dimensionnement, pas d’un benchmark : 4 GB de RAM et deux cœurs offrent un fonctionnement confortable pour une petite équipe, tandis que 2 GB avec un swap file suffisent si la charge se limite aux documents et aux images et si vous acceptez l’attente. Un swap file n’accélère pas une conversion. Il transforme un pic de charge lent en problème non fatal. C’est la différence entre une page bloquée et une interruption de service. Prévoyez davantage d’espace disque que nécessaire en apparence, car l’image de 3 GB, une limite d’upload élevée et le fichier converti remplissent un disque bien avant les autres ressources.

Les conversions sont par nature irrégulières. Deux personnes qui uploadent une vidéo au même moment utilisent tous les cœurs, et la requête suivante attend derrière elles. Aucun job queue ne se trouve devant ce traitement. La seule possibilité de contrôle consiste donc à définir des limites.

Définir les limites qui empêchent un seul téléversement de remplir le disque

Commencez par réduire les valeurs PHP. Des valeurs comme upload_max_filesize = 512M, post_max_size = 512M et max_file_uploads = 20 constituent un point de départ raisonnable pour un serveur partagé de 4 GB. Gardez à l’esprit que max_execution_time = 1200 permet à une requête PHP de s’exécuter pendant vingt minutes. Cette durée peut être nécessaire pour une conversion vidéo longue. Elle signifie aussi qu’un téléversement lent monopolise un worker pendant vingt minutes.

Appliquez ensuite les limites de taille et de débit au niveau du proxy, avant que la requête n’atteigne 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 doit être au moins égal à la taille du plus gros fichier que vous voulez convertir. Sinon, nginx renvoie 413 Request Entity Too Large et PHP ne reçoit jamais le téléversement. proxy_read_timeout doit être supérieur à la durée de votre conversion la plus longue. Sinon, une tâche qui s’exécute normalement derrière le proxy renvoie 504 Gateway Time-out au navigateur. Le reste de ce server block, notamment la terminaison TLS (transport layer security), est expliqué dans une configuration de reverse proxy nginx expliquée ligne par ligne.

Supprimer les fichiers convertis

Chaque conversion laisse une copie d’un fichier sensible dans un répertoire lisible par le serveur web. Le nettoyage distingue un convertisseur d’une archive de tout ce que n’importe qui a déjà converti sur ce serveur.

$DeleteThreshold dans Resources/config.php correspond à l’âge, en minutes, auquel une session expire. Sa valeur par défaut est 60. Réduisez-la à 15 lorsque le contenu est sensible. Le nettoyage lui-même est un argument de ligne de commande du cœur :

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

-c supprime les sessions expirées dans les deux emplacements de données en utilisant le seuil configuré. -c=15 utilise quinze minutes uniquement pour cette exécution. -c=now supprime toutes les sessions, quel que soit leur âge, y compris celle qu’un utilisateur est en train de convertir. Réservez donc cette option aux opérations de maintenance. Les mêmes arguments fonctionnent dans le conteneur via docker exec.

Programmez ce nettoyage avec un timer afin qu’il ne dépende jamais du chargement d’une page. Une ligne dans /etc/cron.d/hrconvert2 suffit :

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

Vérifiez le résultat quelques minutes plus tard avec ls /DATA/HRConvert2 et surveillez la disparition des anciens répertoires de session. Comme le compte du serveur web possède ce répertoire, c’est exactement ce que pourrait obtenir un parser compromis. Ce compte ne doit donc posséder aucun autre élément important. Comptes utilisateur avec privilèges minimaux sur un VPS est le principe général, et il s’applique ici plus que d’habitude.

Protégez-le par une authentification, sauf si l’objectif est de le rendre public

L’installation par défaut ne crée aucun compte, et c’est intentionnel. Toute personne qui peut accéder à la page peut envoyer un fichier et exécuter vos binaires de conversion. Les limites de débit ne font que ralentir ces actions. Déterminez donc dans quelle situation vous vous trouvez.

Si le service est destiné à vous-même et à quelques collègues, ne l’exposez pas du tout. Liez le conteneur à l’interface loopback comme indiqué plus haut, puis accédez-y via un réseau privé ou un tunnel SSH. Rien sur Internet ne pourra alors lui envoyer de fichier. Vous supprimez ainsi toute la surface d’attaque au lieu de simplement la filtrer. Si ces collègues doivent l’ouvrir dans un navigateur sans que vous publiiez de nom d’hôte ni n’ouvriez de port, le servir comme service onion v3 conserve le convertisseur lié à l’interface loopback tout en leur fournissant une adresse à ouvrir.

S’il doit être accessible depuis un navigateur, placez une authentification devant le proxy. Basic auth se configure avec deux commandes et empêche les inconnus d’accéder au formulaire d’envoi :

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;
}

Rechargez nginx, puis chargez la page. L’affichage d’une invite indique que la configuration fonctionne. L’absence d’invite signifie que le bloc location que vous avez modifié ne traite pas la requête. Pour utiliser de vrais comptes plutôt qu’un mot de passe partagé, terminez l’authentification auprès d’un fournisseur de single sign-on : un serveur SSO Authentik auto-hébergé fournit une authentification forward devant une application qui ne possède pas son propre système de connexion.

Si l’objectif est de rendre le convertisseur réellement public, acceptez les conséquences et prévoyez-les. Partez du principe que le sandbox sera sondé. Épinglez le tag de l’image, maintenez la policy ImageMagick restrictive, limitez la taille des fichiers envoyés et exécutez le service sur un VPS qui ne contient rien d’autre d’important.

Modes d’échec et messages affichés

Toutes les conversions échouent immédiatement. Le sandbox ne peut pas être créé. Dans une installation normale, le problème vient du profil AppArmor. Dans Docker, il s’agit de --security-opt seccomp=unconfined manquant. L’application le signale avec le message A sandbox blocks the required syscalls unless it was started with the correct options. et indique See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php..

Seules les conversions d’images échouent. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! signifie que bwrap est absent ou inaccessible dans le PATH dont dispose l’utilisateur du serveur web.

Un format échoue, mais les autres fonctionnent. Il s’agit d’un binaire manquant, signalé clairement par ImageMagick may not be installed, or may not be reachable on the system path used by the web server user.. Le même message existe pour FFmpeg et LibreOffice. Exécutez convertCore.php -v pour voir ce que l’installation trouve. N’oubliez pas que le PATH du worker Apache n’est pas celui de votre shell de connexion.

Les opérations sur les PDF échouent avec une erreur de stratégie. attempt to perform an operation not allowed by the security policy 'PDF' provient de policy.xml d’ImageMagick, et non de HRConvert2.

Les envois volumineux renvoient une erreur 413. La valeur nginx de client_max_body_size est inférieure à la taille du fichier. La chaîne comporte trois limites : une dans nginx et deux dans PHP. La plus petite s’applique.

Les conversions s’arrêtent sans changement apparent. The device where data is stored has an insufficient amount of storage space available. Vérifiez l’espace disque disponible et assurez-vous que le nettoyage automatique s’exécute réellement.

Le nettoyage génère des erreurs dans le journal. Could not clean the temporary location! et Could not clean the convert location! indiquent un problème de propriétaire. L’utilisateur du serveur web doit être propriétaire du répertoire indiqué par $ConvertLoc.

FAQ

Est-il sûr d’exposer un convertisseur de fichiers auto-hébergé sur Internet ?

C’est suffisamment sûr uniquement si vous le considérez comme un parseur exposé à des inconnus. Chaque fichier envoyé est transmis à LibreOffice, ImageMagick, FFmpeg ou Ghostscript, et l’utilisateur choisit lequel sera utilisé. HRConvert2 exécute ces outils dans un namespace bubblewrap sans réseau et avec un répertoire d’entrée en lecture seule. Il refuse toute conversion qu’il ne peut pas isoler, ce qui constitue un réglage par défaut robuste. Il reste préférable d’exiger une authentification, de limiter la taille des fichiers envoyés et de l’exécuter sur un VPS qui ne contient aucune autre donnée importante.

Pourquoi chaque conversion échoue-t-elle sur une nouvelle installation d’Ubuntu 24.04 ?

Ubuntu 24.04 et Debian 12 restreignent les user namespaces non privilégiés, et bubblewrap en a besoin pour créer son sandbox. Comme l’application refuse d’effectuer une conversion sans sandbox, toutes les tâches échouent au lieu que certaines seulement échouent. Écrivez un profil AppArmor pour /usr/bin/bwrap avec flags=(unconfined), chargez-le avec sudo apparmor_parser -r /etc/apparmor.d/bwrap, puis vérifiez le résultat avec bwrap --ro-bind / / --dev /dev /bin/true.

Pourquoi les conversions échouent-elles dans Docker alors qu’elles fonctionnent sur une installation standard ?

Le profil seccomp par défaut de Docker bloque les appels système utilisés par bubblewrap. Le sandbox ne peut donc pas être créé dans le conteneur. Démarrez-le avec --security-opt seccomp=unconfined, comme le fait la commande d’exécution du projet. Notez que $RequireSandboxOnDocker vaut FALSE par défaut. Un conteneur lancé sans ce flag peut donc effectuer des conversions sans sandbox. Définissez cette valeur sur TRUE une fois le flag seccomp configuré.

De combien de RAM un serveur de conversion de fichiers a-t-il besoin ?

La consommation est faible au repos, mais une conversion en cours consomme davantage. LibreOffice démarre un runtime Java, ImageMagick utilise 256 MiB de mémoire et une map de 512 MiB avec la policy fournie, et la limite propre à PHP est de 512M. Sur un VPS doté de 1 GB de RAM, cette combinaison provoque du swap et l’out of memory killer arrête soffice.bin ou apache2. Prévoyez 4 GB de RAM et deux cœurs pour une petite équipe. Consultez dmesg -T | grep -i "killed process" lorsqu’une conversion s’arrête sans message.

Où vont les fichiers convertis et quand sont-ils supprimés ?

Ils sont placés dans le répertoire de travail défini par $ConvertLoc dans Resources/config.php, dont la valeur par défaut est /DATA/HRConvert2. $DeleteThreshold définit l’âge, en minutes, à partir duquel une session expire. Sa valeur par défaut est 60. Le nettoyage s’effectue en ligne de commande : php convertCore.php -c supprime les sessions expirées et -c=now supprime immédiatement toutes les sessions, y compris les sessions actives. Ajoutez -c à une entrée cron ou à un timer systemd afin que la suppression ne dépende pas de la visite d’un utilisateur sur le site.