Como hospedar seu próprio conversor com HRConvert2

Por que alojar um conversor de ficheiros

Um conversor de ficheiros alojado localmente mantém o ficheiro no seu próprio disco. Essa é a razão principal para executar um. Um site de conversão gratuito recebe o upload e não lhe dá forma de saber o que aconteceu ao ficheiro depois disso. Quando o ficheiro é um contrato assinado de um cliente ou um registo médico digitalizado, o próprio upload já constitui o incidente. O HRConvert2 é um servidor de conversão de ficheiros com interface de arrastar e largar, escrito em PHP e licenciado ao abrigo da GPLv3. Este guia foi escrito com base na versão 3.7.4, lançada em 18 August 2026. O projeto evoluiu rapidamente desde então: a versão mais recente em 13 October 2026 é a v3.9.1, publicada em 6 September 2026, e o projeto indica ter 488 formatos suportados.

Não tem base de dados, contas nem cookies. Cada utilizador corresponde a um diretório temporário. Cada conversão é executada por uma ferramenta local de linha de comandos: LibreOffice para documentos, FFmpeg para áudio e vídeo, ImageMagick para imagens, Tesseract para reconhecimento ótico de caracteres (OCR) e muitas outras ferramentas menores para os restantes formatos. O HRConvert2 fornece a página de upload, o pipeline e a limpeza necessária.

Converte um ficheiro de um formato para outro. Não é uma suite de escritório no browser. Se pretende que as pessoas editem documentos num separador, consulte OnlyOffice e Collabora alojados localmente. Também não é armazenamento. O resultado convertido deve ser eliminado. Se os ficheiros precisarem de permanecer armazenados, essa função pertence a um gestor de ficheiros alojado localmente.

O que é necessário

Debian ou Ubuntu, Apache 2.4, PHP 8 ou posterior e bubblewrap. O Bubblewrap (bwrap) é o sandbox e não é opcional: um servidor que não consegue criar um sandbox recusa a conversão em vez de executá-la sem um. O README upstream informa que um Raspberry Pi Model B+ é suficiente, o que é verdade para a parte do PHP. Os binários do conversor determinam os requisitos reais de hardware, abordados mais abaixo.

Há duas formas de começar. A imagem Docker funciona ainda hoje. A instalação do Apache e do PHP demora uma noite e mostra exatamente o que está instalado no servidor.

Execute hoje à noite com Docker

A imagem inclui todos os binários de conversão, por isso é grande: cerca de 3 GB em agosto de 2026. Verifique o espaço livre em disco antes de fazer pull.

As tags são importantes neste caso. Este guia fixa v3.7.2, que era a tag mais recente no Docker Hub em 17 de agosto de 2026 e também a versão mais recente no GitHub nesse dia. v3.7.4 foi publicada em 18 de agosto. Em 13 de outubro de 2026, a versão mais recente no GitHub é v3.9.1 (6 de setembro de 2026), e as tags mais recentes no Docker Hub são edge (22 de setembro de 2026) e latest, que é v3.8.4 (31 de agosto de 2026). A tag latest pode mudar sem aviso, e esta aplicação tem uma superfície de análise extensa, por isso fixe uma versão e faça upgrades de forma deliberada.

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/

Um contentor saudável permanece no estado Up e curl devolve HTTP/1.1 200 OK. Um contentor que reinicia continuamente tem um problema no arranque, por isso consulte docker logs hrconvert2 antes de alterar qualquer outra coisa.

Duas flags são especialmente importantes. -p 127.0.0.1:8080:80 publica a porta apenas na interface de loopback, por isso nenhum tráfego chega ao conversor até colocar deliberadamente um proxy à sua frente. O exemplo atual do projeto mapeia -p 8080:80, que escuta em todas as interfaces, incluindo a interface pública. --security-opt seccomp=unconfined é necessário porque o bubblewrap cria a sua sandbox usando chamadas de sistema de user namespace e mount que o perfil seccomp predefinido do Docker bloqueia. Os comentários da versão 3.7 config.php acrescentam que alguns hosts também precisam de --security-opt apparmor=unconfined. Sem essa flag, as conversões falham e a aplicação indica o motivo: A sandbox blocks the required syscalls unless it was started with the correct options.

Essa flag implica uma troca de segurança. O filtro de chamadas de sistema do contentor fica menos restritivo, para que a aplicação possa criar uma sandbox mais restritiva dentro do próprio contentor. As duas definições que determinam o comportamento são $RequireSandbox e $RequireSandboxOnDocker em Resources/config.php. A versão v3.7.4 fornece-as como TRUE e FALSE. A tag v3.7.2 fixada aqui fornece ambas como FALSE, porque os comentários indicam que um contentor deve manter $RequireSandbox desativado e deixar $RequireSandboxOnDocker decidir. Como o requisito do Docker está desativado por predefinição, um contentor sem a flag seccomp pode converter sem qualquer sandbox. Depois de adicionar a flag, defina $RequireSandboxOnDocker = TRUE; para recuperar o comportamento de recusa dentro do contentor.

As imagens mais recentes arrancam de outra forma. O projeto alterou o processo Docker na versão v3.8.0 (25 de agosto de 2026). O README atual e a página do Docker Hub executam o contentor com --cap-add SYS_ADMIN em vez da opção seccomp e indicam que as conversões são recusadas sem essa opção. Se alterar a versão fixada para uma tag 3.8 ou 3.9, use as flags documentadas por essa imagem. Essa capacidade é abrangente, por isso mantenha a associação da porta 127.0.0.1.

Se o Docker for recente nesta máquina, configure primeiro o daemon. Executar o Docker numa VPS explica a instalação, o controlador de armazenamento e a forma como o Docker escreve as suas próprias regras de firewall.

Instalar no Apache e PHP

Até à v3.7.4, o ficheiro Documentation/INSTALLATION_INSTRUCTIONS.txt do repositório descrevia uma instalação manual em nove passos, e esta secção segue esse procedimento. Desde a v3.8.0, o mesmo ficheiro descreve um script de configuração. Execute sudo bash Documentation/Build/hrconvert2-setup.sh a partir do repositório clonado. O script instala as dependências, grava as definições do PHP num ficheiro separado em vez de editar php.ini e estende o perfil AppArmor para o bubblewrap. Depois, php convertCore.php -v e --status verificam o resultado. O método manual demora mais, mas mostra exatamente o que foi instalado no sistema. A sequência é esta. Comece pelo servidor Web, pela linguagem e pela sandbox:

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

Os nomes em php8.3-* correspondem ao Ubuntu 24.04. Execute php -v e use o prefixo correspondente à sua versão, porque esses nomes de pacotes mudam em cada versão do PHP e o prefixo errado produz Unable to locate package.

Depois, instale os conversores. Isto abrange documentos, imagens, áudio, vídeo e OCR, que corresponde à maior parte do que é efetivamente convertido:

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

Os formatos de arquivo, os modelos 3D, os ebooks e as imagens ISO inicializáveis precisam de mais pacotes, e alguns estão no componente multiverse do Ubuntu. Na v3.7.4, o passo 3 das instruções oficiais continha a lista completa do apt, e o passo 5 continha as compilações a partir do código-fonte. O guia atual não tem listas de pacotes. O instalador lê o manifesto Resources/Engine/Contract/depends.php, e php convertCore.php --setup --check-depends mostra a lista atual e o respetivo estado. Também é possível compilar duas dependências a partir do código-fonte. O repositório inclui Documentation/Build/ffmpeg-build.sh para os codificadores que não existem no FFmpeg fornecido pelos pacotes, e Documentation/Build/build-imagemagick-v7.sh para o ImageMagick 7 no Ubuntu 22.04 ou 24.04, que ainda fornecem a versão 6.9. O Ubuntu 25.10 e o Ubuntu 26.04 LTS fornecem o ImageMagick 7.1. O suporte para ebooks vem do instalador próprio do calibre, que as instruções da versão 3.7 apresentavam numa única linha:

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

Isto executa um script do fornecedor através de um shell como root. É o método do projeto a montante e é opcional: se o ignorar, perde apenas a conversão de ebooks.

Em seguida, ajuste os limites do PHP. As conversões são lentas e os ficheiros são grandes, por isso os valores predefinidos são demasiado baixos. As instruções da versão 3.7 definiam estes valores em 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

Estes números pressupõem uma máquina com recursos disponíveis. Reduza-os antes de os aplicar num VPS pequeno, porque upload_max_filesize = 5000M com max_file_uploads = 100 descreve um único pedido que pode escrever muito mais dados do que um disco de 40 GB consegue armazenar. Reinicie o Apache e confirme o que o PHP carregou efetivamente:

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

Agora configure o diretório de trabalho. $ConvertLoc em Resources/config.php identifica esse diretório, e o valor predefinido é /DATA/HRConvert2. O utilizador do servidor Web tem de ser o proprietário:

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

Extraia a versão no document root do Apache. O esquema predefinido coloca-a numa pasta HRProprietary/HRConvert2, e $InstLoc em Resources/config.php tem de identificar o local onde a colocou. Depois, execute o diagnóstico integrado. É a forma mais rápida de encontrar uma dependência em falta antes de um utilizador a encontrar:

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

-v verifica toda a instalação: versões do núcleo, dependências, estado da sandbox e pacotes de idiomas. As conversões de ficheiros não são suportadas pela linha de comandos, por isso este conjunto de argumentos serve apenas para administração.

Por que toda conversão falha numa instalação nova do Ubuntu 24.04?

Por causa do sandbox. Este é o problema inicial mais comum. O Ubuntu 24.04 restringe por padrão os user namespaces de utilizadores sem privilégios através do AppArmor. O Bubblewrap precisa de um user namespace para criar o seu sandbox, por isso bwrap não consegue iniciar. Como a aplicação recusa converter sem um sandbox, todos os trabalhos falham.

Verifique diretamente:

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

Um erro de permissão negada significa que o namespace foi bloqueado. A correção é criar um perfil AppArmor para o binário bwrap. Primeiro, liste os ficheiros ABI e identifique o número mais alto presente:

ls /etc/apparmor.d/abi/

Depois, escreva /etc/apparmor.d/bwrap, substituindo 4.0 por esse número:

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

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

Carregue o perfil:

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

A ausência de saída significa que o perfil foi carregado. Execute novamente a verificação bwrap. Ela deverá apresentar sandbox ok. A partir desse momento, as conversões funcionam.

O Debian 12 não tem este problema. O kernel permite user namespaces de utilizadores sem privilégios e o pacote bubblewrap define kernel.unprivileged_userns_clone como 1 durante o arranque. Por isso, a verificação acima passa nesse sistema sem um perfil. A partir da v3.8.0, o script de configuração estende automaticamente o perfil AppArmor do bubblewrap fornecido pela distribuição.

Um conversor público é um analisador exposto a desconhecidos

Esta é a razão de existir do resto do artigo. Um conversor de ficheiros acessível pela Internet aceita um ficheiro arbitrário de uma pessoa anónima e entrega-o ao LibreOffice, ImageMagick, FFmpeg ou Ghostscript. Estas são bases de código C e C++ grandes, com um longo historial de erros em analisadores. A pessoa que faz o upload escolhe o formato. Isso significa que também escolhe qual analisador é executado e qual caminho de código é usado.

A resposta do HRConvert2 é executar cada dependência dentro de um namespace do bubblewrap. Cada conversão vê dois diretórios: o diretório que contém a entrada, montado como somente leitura, e o diretório que recebe a saída. A rede não é partilhada. Nas palavras do projeto, closes every URL handler in every dependency at once. Isto é mais importante do que parece. O ImageMagick e o Ghostscript aceitam referências que obtêm uma URL. É assim que um conversor se transforma numa ferramenta de falsificação de pedidos do lado do servidor (SSRF) para aceder a um endpoint de metadados da cloud a partir da sua rede. Sem rede no namespace, essa obtenção não pode ocorrer.

A recusa é a outra metade: A server that cannot build a sandbox refuses the conversion rather than quietly running without one. Uma ferramenta que falha de forma segura é mais útil do que uma ferramenta que apenas regista um aviso num log que ninguém consulta. É também por isso que o passo do AppArmor acima não é opcional e que $RequireSandboxOnDocker merece ser analisado antes de expor o contentor.

Fortaleça a segurança do ImageMagick com policy.xml

O ficheiro de políticas do próprio ImageMagick é uma segunda camada de proteção sob o sandbox e vale a pena configurá-lo. No Ubuntu 24.04 com ImageMagick 6, o ficheiro está em /etc/ImageMagick-6/policy.xml. Apresente a configuração atualmente ativa:

identify -list policy

O projeto fornece uma política em Documentation/Build/policy.xml, que é um bom modelo. Ela bloqueia os coders PS, PS2, PS3, EPS, XPS e MVG, e bloqueia os delegates URL, HTTPS, HTTP e gs, permitindo 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" />

A linha gs é a mais importante. O ImageMagick não analisa PostScript diretamente. Ele executa o Ghostscript externamente, e é nesse delegate que estão as conhecidas vulnerabilidades de execução remota de código do ImageMagick. Bloqueie o delegate e o ImageMagick não entregará um ficheiro carregado a gs, independentemente do tipo que o ficheiro declarar.

A mesma política define limites de recursos. É assim que uma única imagem criada para esse fim é impedida de consumir toda a máquina:

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

Uma bomba de descompressão é um ficheiro pequeno que declara dimensões enormes. Os limites width, height e area rejeitam o ficheiro antes da alocação, fazendo o processo terminar em vez de o kernel terminar outro processo.

Existe uma armadilha no sentido contrário. A política padrão do Ubuntu bloqueia diretamente o coder PDF. Por isso, num sistema sem alterações, o processamento de PDF falha com attempt to perform an operation not allowed by the security policy 'PDF'. Essa mensagem indica que a política está a funcionar. Reativar o coder é uma decisão deliberada, e, nesse caso, mantenha o delegate gs bloqueado.

O custo da cadeia de dependências numa VPS pequena

Em inatividade, nada disto é dispendioso. O Apache e o PHP ocupam algumas dezenas de megabytes, e os binários de conversão nem sequer estão em execução. Todo o custo surge de uma vez, quando chega um ficheiro.

Uma conversão de documentos inicia o LibreOffice, que inicia um runtime Java. Uma conversão de imagens atribui ao ImageMagick 256 MiB de memória, além de um mapeamento de memória de 512 MiB segundo a política acima. Uma conversão de vídeo atribui ao FFmpeg todos os cores disponíveis, porque é isso que o FFmpeg faz com um vídeo. O memory_limit do próprio PHP está definido como 512M na configuração do projeto. Esses valores acumulam-se durante uma única tarefa, além do sistema operativo e do servidor Web.

Por isso, uma VPS com 1 GB começa a usar swap no primeiro documento real e depois entra em thrashing. Quando a memória se esgota, o OOM killer do kernel termina o processo com o maior tamanho residente. Normalmente, esse processo é o soffice.bin, e o utilizador vê uma conversão que falhou sem uma mensagem útil. Por vezes, é o apache2, e todo o site fica indisponível. Confirme isso posteriormente com dmesg -T | grep -i "killed process".

Isto é uma orientação de dimensionamento, não um benchmark: 4 GB de RAM e dois cores são suficientes para uma equipa pequena, e 2 GB com um ficheiro de swap funcionam se a carga consistir em documentos e imagens e aceitar a espera. Um ficheiro de swap não torna uma conversão mais rápida. Torna uma rajada de carga lenta em vez de fatal. Essa é a diferença entre uma página bloqueada e uma indisponibilidade. Reserve mais espaço em disco do que parece necessário, porque a imagem de 3 GB, um limite de upload elevado e o resultado convertido ocupam todo o disco muito antes de ficar sem qualquer outro recurso.

As conversões são naturalmente irregulares. Duas pessoas a carregar vídeos ao mesmo tempo utilizam todos os cores, e o pedido seguinte fica à espera. Não existe uma fila de tarefas à frente deste processo, por isso o único controlo disponível são os limites.

Defina limites para impedir que um único upload encha o disco

Reduza primeiro os valores do PHP. Uma configuração como upload_max_filesize = 512M, post_max_size = 512M e max_file_uploads = 20 é um ponto de partida razoável para um servidor partilhado com 4 GB. Tenha em conta que max_execution_time = 1200 permite que um pedido PHP seja executado durante vinte minutos. Esse tempo pode ser realmente necessário para uma conversão de vídeo longa. Também significa que um upload lento mantém um worker ocupado durante vinte minutos.

Depois, aplique o limite de tamanho e de taxa no proxy, antes de o pedido chegar ao 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 tem de ser pelo menos igual ao maior ficheiro que pretende converter. Caso contrário, o nginx responde com 413 Request Entity Too Large e o PHP nunca recebe o upload. proxy_read_timeout tem de ser superior ao tempo da conversão mais longa. Caso contrário, um trabalho que esteja a executar corretamente atrás do proxy devolve 504 Gateway Time-out ao browser. O restante desse server block, incluindo a terminação TLS (transport layer security), é explicado em uma configuração de reverse proxy nginx explicada linha a linha.

Eliminar os ficheiros convertidos

Cada conversão deixa uma cópia de um ficheiro sensível num diretório que o servidor Web consegue ler. A limpeza é o que distingue um conversor de um arquivo com tudo o que alguém já converteu nele.

$DeleteThreshold em Resources/config.php é a idade, em minutos, após a qual uma sessão expira, e o valor predefinido é 60. Reduza-a para 15 quando o conteúdo for sensível. A própria limpeza é um argumento da linha de comandos do núcleo:

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 as sessões expiradas das duas localizações de dados, usando o limite configurado. -c=15 usa quinze minutos apenas nessa execução. -c=now elimina todas as sessões, independentemente da idade, incluindo a sessão que um utilizador está a usar para fazer uma conversão naquele momento; por isso, reserve-o para manutenção. Os mesmos argumentos funcionam dentro do contentor através de docker exec.

Agende a limpeza com um temporizador, para que ela nunca dependa de alguém carregar uma página. Uma linha em /etc/cron.d/hrconvert2 é suficiente:

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

Verifique alguns minutos depois com ls /DATA/HRConvert2 e monitorize o desaparecimento dos diretórios de sessão antigos. Como o utilizador do servidor Web é o proprietário desse diretório, essa conta é exatamente o que um analisador explorado obteria; por isso, não deve ser proprietária de mais nada que seja importante. Contas de utilizador com privilégio mínimo numa VPS apresenta o padrão geral, que é ainda mais importante neste caso.

Coloque-o atrás de autenticação, a menos que o objetivo seja torná-lo público

A instalação padrão não tem contas, por conceção. Qualquer pessoa que consiga aceder à página pode carregar um ficheiro e executar os seus binários de conversão, e os limites de taxa apenas atrasam esse processo. Portanto, determine em que situação se encontra.

Se for para si e para alguns colegas, não o exponha. Faça o bind do contentor ao loopback, como mostrado acima, e aceda-lhe através de uma rede privada ou de um túnel SSH. Assim, nada na Internet pública poderá enviar-lhe um ficheiro, o que elimina toda a superfície de ataque em vez de apenas a filtrar. Se esses colegas precisarem de o abrir num browser sem que publique um nome de host ou abra uma porta, servi-lo como serviço onion v3 mantém o conversor ligado ao loopback e continua a fornecer-lhes um endereço para visitar.

Se tiver de estar acessível a partir de um browser, coloque a autenticação à frente do proxy. A autenticação básica requer dois comandos e mantém o formulário de carregamento afastado de desconhecidos:

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

Recarregue o nginx e abra a página. Um pedido de credenciais significa que está a funcionar; a ausência do pedido significa que o bloco location editado não é o que está a processar o pedido. Para utilizar contas reais em vez de uma palavra-passe partilhada, termine a autenticação num fornecedor de single sign-on: um servidor SSO Authentik autoalojado fornece autenticação de encaminhamento à frente de uma aplicação que não tem autenticação própria.

Se o objetivo for um conversor realmente público, aceite as implicações e planeie em conformidade. Parta do princípio de que a sandbox será analisada. Mantenha a tag da imagem fixada, mantenha a política do ImageMagick restritiva, mantenha baixos os limites de carregamento e execute-o num VPS que não contenha mais nada que lhe seja importante.

Modos de falha e as mensagens que verá

Todas as conversões falham imediatamente. A sandbox não pode ser criada. Numa instalação normal do Ubuntu 24.04, a causa é o perfil do AppArmor. Na imagem Docker 3.7 fixada, é a ausência de --security-opt seccomp=unconfined. A aplicação indica-o: A sandbox blocks the required syscalls unless it was started with the correct options. e aponta para See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php.

Apenas as conversões de imagens falham. Bubblewrap is missing or non functional, so this image conversion cannot be isolated! significa que bwrap está ausente ou não está acessível através do PATH que o utilizador do servidor Web tem.

Um formato falha e os restantes funcionam. Falta um binário, indicado claramente por: ImageMagick may not be installed, or may not be reachable on the system path used by the web server user.. A mesma mensagem existe para FFmpeg e LibreOffice. Execute convertCore.php -v para ver o que a instalação consegue encontrar e lembre-se de que o PATH do worker do Apache não é o PATH da sua shell de início de sessão.

O processamento de PDF falha com um erro de política. attempt to perform an operation not allowed by the security policy 'PDF' vem de policy.xml do ImageMagick, não do HRConvert2.

Os uploads grandes devolvem 413. client_max_body_size do nginx é menor do que o ficheiro. Existem três limites na cadeia: um no nginx e dois no PHP. Prevalece o menor.

As conversões param sem que nada evidente tenha mudado. The device where data is stored has an insufficient amount of storage space available.. Verifique o espaço livre e confirme que a limpeza periódica está efetivamente a ser executada.

A limpeza gera erros no log. Could not clean the temporary location! e Could not clean the convert location! são problemas de propriedade. O utilizador do servidor Web tem de ser proprietário do diretório indicado por $ConvertLoc.

FAQ

É seguro expor um conversor de ficheiros self-hosted à internet?

Só é suficientemente seguro se o tratar como um parser exposto a desconhecidos. Cada upload é entregue ao LibreOffice, ImageMagick, FFmpeg ou Ghostscript, e a pessoa que faz o upload escolhe qual deles será usado. O HRConvert2 executa essas ferramentas dentro de um namespace do bubblewrap, sem rede e com um diretório de entrada apenas de leitura. Também recusa qualquer conversão que não consiga colocar numa sandbox, o que é uma predefinição robusta. Ainda assim, é preferível exigir autenticação, manter os limites de upload baixos e executar o serviço num VPS que não contenha outros dados importantes.

Porque falha todas as conversões numa instalação nova do Ubuntu 24.04?

O Ubuntu 24.04 restringe os user namespaces não privilegiados através do AppArmor, e o bubblewrap precisa de um para criar a sandbox. Como a aplicação recusa fazer conversões sem uma sandbox, todos os trabalhos falham em vez de apenas alguns. Escreva um perfil AppArmor para /usr/bin/bwrap com flags=(unconfined), carregue-o com sudo apparmor_parser -r /etc/apparmor.d/bwrap e confirme com bwrap --ro-bind / / --dev /dev /bin/true. O Debian 12 permite user namespaces não privilegiados por predefinição e não precisa deste passo.

Porque falham as conversões no Docker, mas funcionam numa instalação normal?

O perfil seccomp predefinido do Docker bloqueia as chamadas de sistema usadas pelo bubblewrap, pelo que a sandbox não pode ser criada dentro do container. Para a imagem 3.7 fixada aqui, inicie-a com --security-opt seccomp=unconfined, conforme indicado pelos comentários de config.php nessa release. A partir da v3.8.0, o projeto documenta --cap-add SYS_ADMIN em alternativa. Tenha em atenção que $RequireSandboxOnDocker é FALSE por predefinição, pelo que um container sem essa flag pode fazer conversões sem qualquer sandbox. Defina-o como TRUE depois de ativar a flag seccomp.

De quanta RAM precisa um servidor de conversão de ficheiros?

Em idle, o consumo é reduzido, mas uma conversão em execução não é. O LibreOffice inicia um runtime Java, o ImageMagick usa 256 MiB de memória e um mapa de 512 MiB com a política fornecida, e o limite próprio do PHP é 512M. Num VPS com 1 GB, essa combinação provoca swap e o out of memory killer termina soffice.bin ou apache2. Planeie 4 GB e dois cores para uma equipa pequena e consulte dmesg -T | grep -i "killed process" sempre que uma conversão termine sem apresentar uma mensagem.

Onde são guardados os ficheiros convertidos e quando são eliminados?

São guardados no diretório de trabalho indicado por $ConvertLoc em Resources/config.php, cujo valor predefinido é /DATA/HRConvert2. $DeleteThreshold define, em minutos, a idade a partir da qual uma sessão expira, e o valor predefinido é 60. A limpeza é executada a partir da linha de comandos: php convertCore.php -c limpa as sessões expiradas e -c=now limpa imediatamente todas as sessões, incluindo as ativas. Coloque -c numa entrada do cron ou num temporizador systemd para que a eliminação não dependa de alguém visitar o site.