Parte 9

Hospedagem é um sistema: primeiro estabeleça os fatos, depois mude alguma coisa

Um problema de hospedagem muitas vezes parece “o script quebrou”, quando a causa real é versão do PHP, extensão ausente, sistema de arquivos cheio, permissão, caminho de rede ou transporte de correio. O terminal fica muito mais tranquilo quando você primeiro descreve a máquina que realmente tem.

O mesmo projeto pode se comportar de forma diferente em outro servidor

Os arquivos podem ser idênticos e o ambiente de execução não. Versão do PHP, extensões carregadas, limites do sistema de arquivos, proprietário, permissões, horário, acesso à rede e política do servidor influenciam o que a aplicação consegue fazer.

Por isso a primeira pergunta útil não é “o que eu devo mudar?”, mas “em qual ambiente isto está rodando?”. O terminal transforma esse ambiente vago em fatos que podem ser inspecionados.

Comece com uma tela de fatos

core mostra o lil Core atual, PHP, camada de interface, arquivo de extensões, atualizações, arquivo ativo e diretório. doctor -q dá uma visão compacta de saúde; sys host e sys uptime descrevem o servidor e há quanto tempo o sistema está em execução.

Um resumo saudável não prova que toda aplicação esteja saudável. Ele é uma linha de base: uma forma rápida de perceber que máquina, Core ou ambiente de execução não são o que você esperava antes de investigar mais fundo.

core

doctor -q

sys host

sys uptime

Um recurso PHP só existe se este ambiente de execução realmente o oferecer

php version, php modules e doctor extensions respondem diretamente a perguntas sobre recursos. IMAP, SQLite, GD ou uma primitiva criptográfica podem existir em um plano de hospedagem e faltar em outro.

Um recurso ausente é diferente de um comando errado. Prefira um erro claro de capacidade a soluções improvisadas: confirme a extensão primeiro e então decida habilitá-la, escolher outra ferramenta ou mover a tarefa para outro ambiente.

php version

php modules

php info memory -c

doctor extensions

Espaço livre, uso do diretório e permissões são perguntas diferentes

disk . mostra a capacidade do sistema de arquivos; disk . -r percorre deliberadamente a árvore atual para calcular o uso. stat diz o que um caminho realmente é. Permissões são outra camada: um arquivo pode existir e haver espaço livre, mas o PHP ainda assim não conseguir ler ou escrever.

Não “conserte permissões” tornando tudo gravável. Inspecione proprietário e modo de acesso, altere o menor alvo que realmente precisa e verifique novamente. Permissões são um limite local de acesso, não substituem autenticação nem criptografia.

disk .

disk . -r

stat .

Leia os logs antes de apagar, reiniciar ou adivinhar

log -l encontra logs prováveis. Depois de identificar o arquivo relevante, leituras limitadas de início/fim e filtro por texto exato permitem examinar a evidência mais recente sem carregar um log enorme no navegador.

Uma linha útil de log tem contexto: horário, componente, requisição ou operação e o erro real. Preserve esse contexto antes de “limpar”. Muitos incidentes difíceis ficam comuns quando você consegue dizer exatamente quando a falha começou e o que mudou perto daquele momento.

log -l

Ambiente e correio são subsistemas separados que merecem teste explícito

env expõe valores de ambiente, servidor e requisição de forma legível e mascara nomes sensíveis. Isso ajuda a responder qual diretório temporário ou endereço do servidor o PHP enxerga sem despejar todo o ambiente de execução às cegas.

mail tem sua própria superfície de diagnóstico: transporte local de correio do PHP e conexão IMAP não são a mesma coisa. Um site pode renderizar perfeitamente enquanto o correio de saída é rejeitado, ou IMAP pode estar indisponível só porque falta a extensão. Teste o subsistema do qual você realmente depende.

env server SERVER_ADDR

env TMP

mail

Salve a linha de base antes do conserto

Redirecione relatórios compactos para diagnostics/ antes de mudar configurações do PHP, módulos, permissões ou configuração da hospedagem. Depois da mudança, colete os mesmos relatórios e compare fatos em vez de confiar em “agora parece melhor”.

Esse hábito vale muito além do lil-terminal. Em Linux, macOS, Windows, contêineres e painéis de controle, um bom diagnóstico segue a mesma sequência: identificar o ambiente, isolar a camada, coletar evidência, mudar uma coisa e verificar.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Guarde isto como script

Salve isto como hosting-baseline.lil. Ele coleta um retrato compacto de diagnóstico em diagnostics/ sem alterar dados da aplicação. Guarde retratos antes e depois de uma mudança na hospedagem: comparar costuma ser mais útil do que confiar na memória.

#lil
@install md doctor sys php disk log env
md diagnostics
core > diagnostics/core.txt -r
doctor -q > diagnostics/doctor.txt -r
sys > diagnostics/system.txt -r
php version > diagnostics/php.txt -r
disk . > diagnostics/disk.txt -r
log -l > diagnostics/logs.txt -r
env server SERVER_ADDR > diagnostics/server.txt -r