Partie 9

L’hébergement est un système : établir les faits avant de modifier quoi que ce soit

Un problème d’hébergement ressemble vite à « le script est cassé », alors que la vraie cause peut être une version de PHP, une extension absente, un disque plein, des permissions, un chemin réseau ou le transport mail. Le terminal devient plus serein quand on commence par décrire la machine réellement disponible.

Le même projet peut se comporter différemment sur un autre hôte

Les fichiers peuvent être identiques alors que l’environnement d’exécution ne l’est pas. La version de PHP, les extensions chargées, les limites du système de fichiers, le propriétaire, les permissions, l’heure, l’accès réseau et les règles du serveur influencent ce que l’application peut faire.

La première bonne question n’est donc pas « que dois-je changer ? », mais « dans quel environnement ceci s’exécute-t-il ? ». Le terminal transforme cet environnement vague en faits que l’on peut inspecter.

Commencez par un écran de faits

core montre le lil Core courant, PHP, la couche d’interface, le fichier d’extensions, les mises à jour, le fichier actif et le répertoire. doctor -q donne une vue de santé compacte ; sys host et sys uptime décrivent l’hôte et sa durée de fonctionnement.

Un état général sain ne prouve pas que chaque application fonctionne correctement. Il fournit toutefois une référence initiale : un moyen rapide de vérifier que la machine, le Core et l’environnement d’exécution correspondent bien à ce qui est attendu avant d’aller plus loin.

core

doctor -q

sys host

sys uptime

Une fonctionnalité PHP n’existe que si cet environnement d’exécution la fournit réellement

php version, php modules et doctor extensions répondent directement aux questions de capacité. IMAP, SQLite, GD ou une primitive cryptographique peuvent exister sur une offre d’hébergement et manquer sur une autre.

Une capacité absente n’est pas une mauvaise commande. Préférez une erreur claire à des contournements au hasard : vérifiez l’extension, puis décidez de l’activer, de choisir un autre outil ou de déplacer la tâche.

php version

php modules

php info memory -c

doctor extensions

Espace libre, taille du répertoire et permissions sont trois questions différentes

disk . indique la capacité du système de fichiers ; disk . -r parcourt explicitement l’arbre courant pour calculer son usage. stat dit ce qu’est réellement un chemin. Les permissions sont encore une autre couche : un fichier peut exister et l’espace être libre alors que PHP ne peut ni lire ni écrire.

Ne « réparez » pas les permissions en rendant tout inscriptible. Inspectez propriétaire et mode, modifiez la plus petite cible nécessaire, puis vérifiez. Les permissions sont une frontière d’accès locale, pas un remplacement de l’authentification ou du chiffrement.

disk .

disk . -r

stat .

Lisez les logs avant de supprimer, redémarrer ou deviner

log -l découvre les logs probables. Une fois le bon fichier connu, des lectures bornées du début ou de la fin et un filtre littéral permettent d’examiner les dernières preuves sans charger un journal énorme dans le navigateur.

Une ligne de log utile garde son contexte : heure, composant, requête ou opération, et erreur réelle. Préservez ce contexte avant tout « nettoyage ». Beaucoup d’incidents deviennent ordinaires dès que l’on sait précisément quand la panne a commencé et ce qui a changé autour de ce moment.

log -l

Environnement et mail sont des sous-systèmes distincts à tester explicitement

env présente de façon lisible les valeurs d’environnement, du serveur et de la requête, tout en masquant les noms sensibles. Vous pouvez ainsi vérifier, par exemple, le répertoire temporaire ou l’adresse serveur vus par PHP sans afficher aveuglément tout l’environnement d’exécution.

mail possède sa propre surface de diagnostic : le transport mail local de PHP et une connexion IMAP ne sont pas la même chose. Un site peut s’afficher parfaitement pendant que le mail sortant est refusé, ou IMAP peut manquer simplement parce que l’extension n’est pas installée. Testez le sous-système dont vous dépendez.

env server SERVER_ADDR

env TMP

mail

Sauvegardez la référence initiale avant la réparation

Redirigez les rapports compacts vers diagnostics/ avant de modifier réglages PHP, modules, permissions ou configuration d’hébergement. Après le changement, collectez les mêmes rapports et comparez les faits plutôt que de vous fier à « ça a l’air mieux ».

Cette habitude dépasse lil-terminal. Sous Linux, macOS, Windows, dans des conteneurs ou panneaux de contrôle, un bon diagnostic suit la même séquence : identifier l’environnement, isoler la couche, recueillir des preuves, changer une chose, vérifier.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Conservez ceci comme script

Enregistrez ceci sous hosting-baseline.lil. Le script collecte un instantané compact dans diagnostics/ sans modifier les données de l’application. Conservez un snapshot avant et après un changement d’hébergement : la comparaison est souvent plus utile que la mémoire.

#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