NgixProxy_Pathfinder/TODO.md

Relatório de Diagnóstico e Pontos de Dor (Pain Points)

Este documento sumariza os problemas arquiteturais e técnicos identificados durante a tentativa de estabilizar o stack nginx-pathfinder-proxy. O objetivo é fornecer um contexto claro para um futuro Agente de IA simplificar a solução.

1. Arquitetura Excessivamente Complexa (Split Container)

Atualmente, temos dois containers NGINX separados:

1. Frontend (modsecurity): Recebe a internet, faz WAF, termina SSL.
2. Backend (nginx-proxy): Recebe do WAF, faz roteamento, gerencia certificados (Certbot), roda scripts.

Problemas Causados:

• Inferno de Permissões (Permission Hell): O Backend (onde roda o Certbot) gera certificados no volume compartilhado como root. O Frontend tenta ler esses arquivos e falha com Permission denied porque roda com outro UID/GID. Tentar corrigir com chmod é frágil e inseguro.
• Configuração Duplicada: É preciso configurar o Nginx duas vezes. Uma no Frontend (para saber onde estão os certs) e uma no Backend (para saber como tratar a requisição na porta 8080).
• SSL "Ping-Pong": O Backend gerencia a renovação, mas o Frontend é quem usa o certificado. Isso exige reload sincronizado em dois containers diferentes.

2. Problema do "Ovo e a Galinha" (SSL Bootstrap)

• O NGINX não sobe se o arquivo de certificado não existir.
• O Certbot não gera o certificado se o NGINX não estiver rodando (para responder o desafio HTTP-01).
• Solução Atual (Gambiarra): Criamos um script complexo (pre-flight.sh + renew_ssl.sh) que gera certificados falsos (self-signed) só para o NGINX subir, e depois tenta baixar os reais. Isso adiciona muita lógica propensa a falhas.

3. Fragilidade de Deploy (Portainer / Docker)

• Mount Error: O Portainer falha ao tentar montar arquivos de configuração (modsec_conf/...) que ainda não foram baixados pelo git no host.
• Solução Atual: Tivemos que "assar" (bake) as configurações dentro da imagem Docker (COPY conf.d ...). Isso tira a agilidade de alterar uma config no git e dar deploy rápido; agora exige rebuild da imagem.

4. Scripts de Automação Frágeis

• O script pre-flight.sh tenta fazer git clone/pull dentro do container. Isso gera erros de "Resource busy" quando tenta limpar pastas montadas via volume.
• Lógica de sed/grep para ler arquivos .conf e achar domínios é suscetível a erros de sintaxe no arquivo de config.

---

Recomendação de Simplificação (Para o Próximo Agente)

Opção A: Single "Super" Container (Recomendada)

Unificar tudo em um único container.

• Base: Usar a imagem oficial com ModSecurity já compilado (ou compilar num multi-stage build).
• Benefício: Resolve problemas de permissão (mesmo processo lê e escreve). Resolve problema de setup (um único serviço). Remove complexidade de rede (sem proxy pass interno desnecessário).

Opção B: Caddy Server (Radical)

Substituir NGINX + Certbot por Caddy.

• Benefício: Caddy tem HTTPS automático (resolve o problema do Ovo/Galinha nativamente).
• WAF: Existe plugin de WAF para Caddy (Coraza), mas exige validação se atende os requisitos de segurança do Oestepan.

Opção C: NGINX Proxy Manager (GUI)

Usar uma solução pronta como NGINX Proxy Manager.

• Tem interface web.
• Gerencia SSL sozinho.
• Pode ser difícil integrar ModSecurity customizado.

Resumo do Pedido de Refatoração

"Simplificar a infraestrutura eliminando a separação Frontend/Backend. Criar um container único que faça WAF + Proxy + SSL Management, eliminando scripts complexos de bootstrap e problemas de permissão de volume."