Installer HRConvert2 pour auto-héberger vos conversions

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 d’en utiliser un. Un site de conversion gratuit reçoit le fichier envoyé et ne vous permet pas de savoir ce qu’il devient 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 août 2026 et le projet annonce 488 formats pris en charge.

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 spécialisés 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, comparez 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, cette tâche revient à un gestionnaire de fichiers auto-hébergé.

Ce qu’il faut

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

Deux options sont possibles. L’image Docker fonctionne immédiatement. L’installation d’Apache et de PHP prend une soirée et permet de voir exactement ce qui est installé sur la machine.

Exécutez-le ce soir avec Docker

L’image contient tous les binaires de conversion. Elle est donc 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 publiée sur GitHub est v3.7.4. Le tag latest peut changer sans préavis. 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 sain reste dans l’état Up et la commande curl renvoie HTTP/1.1 200 OK. Un conteneur qui redémarre en boucle présente un problème au démarrage. Consultez donc docker logs hrconvert2 avant de modifier quoi que ce soit d’autre.

Deux options sont importantes. -p 127.0.0.1:8080:80 publie le port uniquement sur l’interface loopback. Rien ne peut donc atteindre le convertisseur tant que vous n’avez pas placé explicitement un proxy devant lui. L’exemple fourni par le projet utilise -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 aux montages, que le profil seccomp par défaut de Docker bloque. Sans cette option, les conversions échouent et l’application indique pourquoi : A sandbox blocks the required syscalls unless it was started with the correct options.

Cette option implique un véritable compromis. Vous assouplissez le filtre des appels système du conteneur afin que l’application puisse construire son propre sandbox plus strict à l’intérieur de celui-ci. 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 présente l’installation, le storage driver et la manière dont Docker écrit ses propres règles de firewall.

Installez-le avec Apache et PHP à la place

Le fichier Documentation/INSTALLATION_INSTRUCTIONS.txt du dépôt fait autorité et contient neuf étapes. Voici sa structure. Commencez par le serveur web, le langage et la 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 de php8.3-* correspondent à Ubuntu 24.04. Exécutez php -v et utilisez le préfixe correspondant à votre version, car ces noms de paquets changent à chaque version de PHP. Un préfixe incorrect produit Unable to locate package.

Installez ensuite les convertisseurs. Cela 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’archive, les modèles 3D, les ebooks et les images ISO bootables 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 package pas. La prise en charge des ebooks vient de l’installer propre à calibre, fourni sur une seule ligne dans les instructions :

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

Il s’agit d’un script fourni par l’éditeur, envoyé à un shell avec les privilèges root. C’est la méthode upstream et elle reste facultative : si vous l’ignorez, seule la conversion des ebooks ne sera pas disponible.

Passez ensuite aux 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 valeurs 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 toute installation sur un petit VPS, car upload_max_filesize = 5000M avec max_file_uploads = 100 décrit une seule requête capable d’écrire bien plus que ce que peut contenir un disque de 40 GB. Redémarrez Apache et vérifiez ce que PHP a réellement chargé :

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 définit son emplacement, et la 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 la racine documentaire d’Apache. La structure par défaut la place dans un dossier HRProprietary/HRConvert2, et $InstLoc dans Resources/config.php doit indiquer l’emplacement réel choisi. 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 le fasse :

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

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

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

Le problème vient de la sandbox. C’est le problème le plus fréquent lors de la première journée d’utilisation. Ubuntu 24.04 et Debian 12 restreignent par défaut les user namespaces pour les utilisateurs non privilégiés. Bubblewrap a besoin d’un user namespace pour créer sa sandbox. bwrap ne peut donc pas démarrer. Comme l’application refuse de convertir sans sandbox, chaque tâche échoue.

Vérifiez directement :

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

Une erreur « permission denied » signifie que le namespace 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/

Créez 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 indique que le profil a été chargé. Exécutez à nouveau le contrôle bwrap. Il doit afficher sandbox ok. Les conversions fonctionnent à partir de ce moment.

Un convertisseur public est un parseur exposé à des inconnus

C’est la raison d’être de la suite 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 grandes bases de code en C et C++, qui comportent depuis longtemps des vulnérabilités dans leurs parseurs. La personne qui envoie le fichier choisit son format. Elle choisit donc le parseur exécuté et le chemin de code utilisé.

HRConvert2 exécute chaque dépendance dans un namespace bubblewrap. Chaque conversion ne voit que 2 répertoires : celui qui contient son entrée, monté en lecture seule, et celui qui reçoit sa sortie. Le réseau n’est pas partagé, ce qui, selon les termes du projet, closes every URL handler in every dependency at once. C’est plus important qu’il n’y paraît. ImageMagick et Ghostscript acceptent tous les 2 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 mécanisme : 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 journal que personne ne lit. C’est aussi pourquoi l’étape AppArmor présentée plus haut n’est pas facultative, 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 à /etc/ImageMagick-6/policy.xml. Affichez la configuration actuellement active :

identify -list policy

Le projet fournit une stratégie à l’emplacement Documentation/Build/policy.xml. Elle 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 lui-même le PostScript. Il lance Ghostscript via un processus externe. C’est dans ce delegate que se trouvent les failles d’exécution de code à distance bien connues d’ImageMagick. Refusez le delegate : ImageMagick ne transmettra alors jamais le fichier envoyé à gs, quel que soit le type déclaré par le 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.

Il existe aussi un piège dans l’autre sens. La stratégie fournie par Ubuntu refuse complètement le coder PDF. Sur un système non modifié, 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. Lorsque vous le faites, 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. Le coût total apparaît d’un seul coup lorsqu’un fichier arrive.

Une conversion de document démarre LibreOffice, qui démarre un runtime Java. Une conversion d’image réserve 256 MiB de mémoire à ImageMagick, ainsi qu’une memory map de 512 MiB avec la policy ci-dessus. Une conversion vidéo donne à FFmpeg tous les cœurs disponibles, car c’est ainsi que FFmpeg traite une vidéo. Le memory_limit de PHP est lui-même défini à 512M dans la configuration du projet. Ces valeurs s’additionnent pendant une seule tâche, en plus du système d’exploitation et du 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 resident size est la plus élevée. 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, et tout le site devient indisponible. Vérifiez-le a posteriori 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 conviennent confortablement à une petite équipe, et 2 GB avec un fichier de swap peuvent suffire si la charge concerne des documents et des images et si vous acceptez l’attente. Un fichier de swap n’accélère pas une conversion. Il transforme un pic de charge lent en erreur évitable, ce qui fait la différence entre une page bloquée et une interruption de service. Prévoyez plus 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 ensemble le disque bien avant toute autre ressource.

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 en amont, donc les seules possibilités de contrôle sont les limites.

Définir les limites qui empêchent un seul envoi 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é avec 4 GB de mémoire. Notez que max_execution_time = 1200 autorise chaque requête PHP à s’exécuter pendant vingt minutes. Cette durée peut être nécessaire pour convertir une longue vidéo. Elle signifie aussi qu’un envoi lent monopolise un worker pendant vingt minutes.

Appliquez ensuite la limite de taille et de débit sur le 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 souhaitez convertir. Sinon, nginx répond avec 413 Request Entity Too Large et PHP ne reçoit jamais l’envoi. 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 présenté 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 contenant tout ce qui y a été converti.

$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 pour cette exécution uniquement. -c=now supprime toutes les sessions, quel que soit leur âge, y compris celle qu’un utilisateur est en train d’utiliser pour effectuer une conversion. Réservez donc cette option à la maintenance. Les mêmes arguments fonctionnent dans le conteneur avec docker exec.

Planifiez le 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 quelques minutes plus tard avec ls /DATA/HRConvert2 et surveillez la disparition des anciens répertoires de session. Comme le serveur web possède ce répertoire, c’est exactement ce que pourrait obtenir un compte ayant exploité l’analyseur. 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. 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 comporte aucun compte, par conception. Toute personne qui peut atteindre la page peut envoyer un fichier et exécuter vos binaires de conversion. Les limites de débit ne font que ralentir ces tentatives. 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 la filtrer.

S’il doit être accessible depuis un navigateur, placez une authentification devant le proxy. L’authentification Basic se configure avec deux commandes et empêche les personnes inconnues 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 et ouvrez la page. L’affichage d’une invite confirme que cela fonctionne. Si aucune invite ne s’affiche, 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 réellement de proposer un convertisseur public, acceptez les conséquences et préparez-vous en conséquence. Partez du principe que le sandbox fera l’objet de sondes. Épinglez le tag de l’image, conservez une policy ImageMagick stricte, limitez la taille des envois et exécutez le service sur un VPS qui ne contient rien d’autre d’important pour vous.

Modes d’échec et messages affichés

Toutes les conversions échouent immédiatement. Le sandbox ne peut pas être créé. Sur une installation normale, le problème vient du profil AppArmor. Dans Docker, il s’agit de --security-opt seccomp=unconfined manquant. L’application l’indique avec A sandbox blocks the required syscalls unless it was started with the correct options. et pointe vers 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 et les autres fonctionnent. Il manque un binaire, comme l’indique clairement 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 peut trouver. N’oubliez pas que le PATH du worker Apache n’est pas celui de votre shell de connexion.

Le traitement des PDF échoue avec une erreur de policy. attempt to perform an operation not allowed by the security policy 'PDF' provient de policy.xml d’ImageMagick, et non de HRConvert2.

Les chargements volumineux renvoient 413. La valeur de nginx pour 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 limite s’applique.

Les conversions s’arrêtent sans modification apparente. 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 est bien exécuté.

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été. 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 traitez comme un analyseur 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 espace de noms 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 bon comportement par défaut. 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 espaces de noms utilisateur non privilégiés, alors que bubblewrap en a besoin pour créer son sandbox. Comme l’application refuse de convertir un fichier sans sandbox, toutes les tâches échouent plutôt qu’une partie d’entre elles. É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 avec bwrap --ro-bind / / --dev /dev /bin/true.

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

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 paramètre peut donc effectuer des conversions sans aucun sandbox. Définissez-le sur TRUE une fois l’option seccomp activée.

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

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

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

Ils sont placés dans le répertoire de travail indiqué par $ConvertLoc dans Resources/config.php. Sa valeur par défaut est /DATA/HRConvert2. $DeleteThreshold définit, en minutes, l’âge à partir duquel une session expire. Sa valeur par défaut est 60. Le nettoyage s’exécute en ligne de commande : php convertCore.php -c supprime les sessions expirées, tandis que -c=now supprime immédiatement toutes les sessions, y compris celles qui sont 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.