Parte 9

El alojamiento es un sistema: primero establezca los hechos, después cambie cosas

Un problema de alojamiento suele parecer “el script está roto”, cuando la causa real puede ser una versión de PHP, una extensión ausente, el disco lleno, permisos, una ruta de red o el transporte de correo. El terminal se vuelve más tranquilo cuando primero describe la máquina que realmente tiene.

El mismo proyecto puede comportarse distinto en otro servidor

Los archivos pueden ser idénticos y el entorno de ejecución no. La versión de PHP, extensiones cargadas, límites del sistema de archivos, propietario, permisos, hora, acceso de red y políticas del servidor influyen en lo que puede hacer la aplicación.

Por eso la primera pregunta útil no es “¿qué cambio?”, sino “¿en qué entorno se está ejecutando esto?”. El terminal convierte ese entorno difuso en hechos que puede inspeccionar.

Empiece con una pantalla de hechos

core muestra el lil Core actual, PHP, la capa de interfaz, el archivo de extensiones, actualizaciones, archivo activo y directorio. doctor -q ofrece una vista compacta de salud; sys host y sys uptime describen el servidor y cuánto tiempo lleva funcionando.

Un resumen saludable no demuestra que cada aplicación esté sana. Es una línea base: una forma rápida de descubrir que la máquina, el Core o el entorno de ejecución no son los que esperaba antes de investigar más.

core

doctor -q

sys host

sys uptime

Una función PHP existe solo si este entorno de ejecución realmente la ofrece

php version, php modules y doctor extensions responden directamente a preguntas de capacidad. IMAP, SQLite, GD o una función criptográfica pueden existir en un plan de alojamiento y faltar en otro.

Una capacidad ausente no es lo mismo que un comando incorrecto. Prefiera un error claro de capacidad a soluciones improvisadas: confirme primero la extensión y después decida si habilitarla, usar otra herramienta o mover la tarea a otro entorno.

php version

php modules

php info memory -c

doctor extensions

Espacio libre, uso del directorio y permisos son preguntas distintas

disk . informa de la capacidad del sistema de archivos; disk . -r recorre de forma explícita el árbol actual para calcular su uso. stat dice qué es realmente una ruta. Los permisos son otra capa: un archivo puede existir y haber espacio libre mientras PHP no puede leerlo o escribirlo.

No “arregle permisos” haciendo que todo sea escribible. Inspeccione propietario y modo, cambie el objetivo más pequeño que lo necesite y verifique de nuevo. Los permisos son una frontera local de acceso, no un sustituto de autenticación o cifrado.

disk .

disk . -r

stat .

Lee los registros antes de borrar, reiniciar o adivinar

log -l descubre registros probables. Cuando conoce el archivo relevante, las lecturas limitadas de inicio/final y el filtrado literal permiten revisar la evidencia reciente sin cargar un log enorme en el navegador.

Una línea de log útil contiene contexto: hora, componente, solicitud u operación y el error real. Conserve ese contexto antes de “limpiar”. Muchos incidentes difíciles se vuelven normales cuando puede decir exactamente cuándo empezó el fallo y qué cambió alrededor de ese momento.

log -l

El entorno y el correo son subsistemas separados que conviene probar de forma explícita

env muestra de forma legible valores del entorno, del servidor y de la solicitud, y oculta nombres sensibles. Así puede comprobar qué directorio temporal o dirección de servidor ve PHP sin volcar a ciegas todo el entorno de ejecución.

mail tiene su propia superficie de diagnóstico: el transporte local de correo PHP y una conexión IMAP no son lo mismo. Un sitio puede renderizar perfectamente mientras se rechaza el correo saliente, o IMAP puede no estar disponible porque falta la extensión. Pruebe el subsistema del que realmente depende.

env server SERVER_ADDR

env TMP

mail

Guarde la línea base antes de reparar

Redirija informes compactos a diagnostics/ antes de cambiar ajustes de PHP, módulos, permisos o configuración del alojamiento. Después del cambio, recoja los mismos informes y compare hechos en vez de confiar en “ahora parece mejor”.

Este hábito sirve mucho más allá de lil-terminal. En Linux, macOS, Windows, contenedores y paneles de control, un buen diagnóstico sigue la misma secuencia: identificar entorno, aislar capa, recoger evidencia, cambiar una cosa y verificar.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Guárdalo como script

Guarde esto como hosting-baseline.lil. Recoge una instantánea compacta de diagnóstico en diagnostics/ sin modificar datos de la aplicación. Conserve instantáneas antes y después de un cambio del alojamiento: comparar suele ser más útil que confiar en la memoria.

#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