Parte 9

L’hosting è un sistema: prima stabilite i fatti, poi cambiate qualcosa

Un problema di hosting sembra spesso “lo script è rotto”, quando la vera causa può essere una versione PHP, un’estensione mancante, filesystem pieno, permessi, rete o trasporto mail. Il terminale diventa più sereno quando per prima cosa descrivete la macchina che avete davvero.

Lo stesso progetto può comportarsi diversamente su un altro host

I file possono essere identici mentre l’ambiente di esecuzione non lo è. Versione di PHP, estensioni caricate, limiti del filesystem, proprietario, permessi, ora, accesso di rete e regole del server influenzano ciò che l’applicazione può fare.

Per questo la prima domanda utile non è “che cosa devo cambiare?”, ma “in quale ambiente viene eseguito?”. Il terminale trasforma quell’ambiente vago in fatti ispezionabili.

Iniziate con una schermata di fatti

core mostra lil Core corrente, PHP, livello d’interfaccia, file delle estensioni, aggiornamento, file attivo e directory. doctor -q offre una vista sanitaria compatta; sys host e sys uptime descrivono host e durata di esecuzione.

Un riepilogo sano non prova che ogni applicazione lo sia. È una baseline: un modo rapido per accorgersi che macchina, Core o ambiente di esecuzione non sono quelli attesi prima di indagare più a fondo.

core

doctor -q

sys host

sys uptime

Una funzione PHP esiste solo se questo ambiente di esecuzione la fornisce davvero

php version, php modules e doctor extensions rispondono direttamente alle domande di funzionalità disponibile. IMAP, SQLite, GD o una primitiva crittografica possono esserci in un piano hosting e mancare in un altro.

Una funzionalità disponibile mancante è diversa da un comando sbagliato. Meglio un errore chiaro che soluzione alternativa casuali: verificate prima l’estensione, poi decidete se abilitarla, scegliere un altro strumento o spostare la mansione altrove.

php version

php modules

php info memory -c

doctor extensions

Spazio libero, uso della directory e permessi sono domande diverse

disk . mostra la capacità del filesystem; disk . -r attraversa intenzionalmente l’albero corrente per calcolarne l’uso. stat dice che cosa è davvero un path. I permessi sono un altro livello: un file può esistere e lo spazio può esserci, mentre PHP non riesce comunque a leggere o scrivere.

Non “aggiustate i permessi” rendendo tutto writable. Ispezionate owner e mode, cambiate il target minimo necessario e verificate di nuovo. I permessi sono un confine locale d’accesso, non un sostituto di autenticazione o cifratura.

disk .

disk . -r

stat .

Leggete i log prima di cancellare, riavviare o indovinare

log -l individua i log probabili. Quando conoscete il file rilevante, letture limitate di testa/coda e filtri letterali permettono di vedere le prove più recenti senza caricare un log enorme nel browser.

Una riga utile ha contesto: tempo, componente, richiesta o operazione ed errore reale. Conservate quel contesto prima di “pulire”. Molti incidenti difficili diventano ordinari quando potete dire esattamente quando è iniziato il problema e che cosa è cambiato vicino a quel momento.

log -l

Ambiente e mail sono sottosistemi separati da testare esplicitamente

env presenta in modo leggibile i valori dell’ambiente, del server e della richiesta, mascherando i nomi sensibili. Permette, per esempio, di verificare quale directory temporanea o indirizzo del server vede PHP senza mostrare indiscriminatamente tutto l’ambiente di esecuzione.

mail ha una propria superficie diagnostica: trasporto mail locale di PHP e connessione IMAP non sono la stessa cosa. Un sito può renderizzare perfettamente mentre l’uscita mail viene rifiutata, oppure IMAP può non esserci per un’estensione mancante. Testate il sottosistema da cui dipendete.

env server SERVER_ADDR

env TMP

mail

Salvate la baseline prima della correzione

Reindirizzate report compatti in diagnostics/ prima di cambiare settings PHP, moduli, permessi o configurazione hosting. Dopo il cambio, raccogliete gli stessi report e confrontate i fatti invece di affidarvi a “ora sembra meglio”.

Questa abitudine vale oltre lil-terminal. In Linux, macOS, Windows, container e pannelli di controllo una buona diagnostica segue la stessa sequenza: identificare l’ambiente, isolare il livello, raccogliere prove, cambiare una cosa, verificare.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Conservalo come script

Salvate questo come hosting-baseline.lil. Raccoglie uno snapshot diagnostico compatto in diagnostics/ senza modificare i dati dell’applicazione. Conservate snapshot prima e dopo un cambiamento dell’hosting: il confronto è quasi sempre più utile della 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