Cronache di un vecchio sistemista che non si fa fregare da PHP.
C’è un momento, nella vita di ogni vecchio sistemista, in cui senti quella vocina interiore che sussurra: «È uscito Debian nuovo… che fai, aggiorni?»
E tu, invece di ascoltare l’istinto di sopravvivenza, aggiorni.
Finché, ovviamente, non arriva lui:
apache2.service: FAILED
e il tuo server di fiducia ti guarda in silenzio come un gatto offeso.
Primo atto: Apache muore, ma con stile
Scenario: server Debian 13 nuovo di zecca dopo upgrade. Apache non parte, journalctl ti spara in faccia qualcosa del tipo:
Syntax error su una riga di apache2.conf, e poi:
Syntax error on line 3 of /etc/apache2/mods-enabled/php8.2.load:
Cannot load /usr/lib/apache2/modules/libphp8.2.so into server: ...
Traduzione per umani:
- Apache di suo è tranquillo.
- È PHP 8.2 che è rimasto appeso come un ex che non capisce di essere stato lasciato.
- Il file libphp8.2.so non c’è più, ma la configurazione prova ancora a caricarlo.
Apache, giustamente, si rifiuta di partire con mezzo arto fantasma attaccato.
Il sistemista giovane a questo punto formatta il server o dà la colpa a systemd.
Il sistemista navigato invece fa una cosa molto blasfema ma efficace:
apachectl -t
legge l’errore con calma, individua il colpevole (php8.2.load) e lo spegne:
a2dismod php8.2
apachectl -t
systemctl restart apache2
E Apache torna a respirare. Senza PHP, ma respira.
Come quando riaccendi un vecchio server rimuovendo a mano la scheda SCSI di cui nessuno si ricordava.
Secondo atto: il 403 che ti guarda giudicante
Risolto il crash, arriva il passivo-aggressivo di Apache:
403 Forbidden – You don’t have permission to access this resource.
E tu pensi: «Ma se ha SEMPRE funzionato, perché ora no?»
Classico mantra del sysadmin: “ma non ho toccato niente” (tranne un major upgrade, tre moduli e mezza distro nuova, dettagli).
Qui entra in gioco il lato artigiano di bottega del sistemista.
- DocumentRoot del sito di test, per esempio: /home/utente/www/sito.local
- In apache2.conf c’è un blocco tipo:
<Directory /home/utente/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
Sulla carta è tutto giusto. Nella pratica, Apache gira come utente www-data e, se la home è un bunker tipo:
drwx------ /home/utente
allora www-data non entra. Non per cattiveria: manca la “x” sul percorso, e senza execute sulle directory, nel mondo Unix non passi.
Quindi, con mano ferma (non in modalità “chmod 777 a pioggia”, quello è peccato mortale) si fa:
chmod 711 /home/utente
chmod 755 /home/utente/www
chmod 755 /home/utente/www/sito.local
- 711 sulla home: nessuno vede i file, ma Apache può attraversare la directory.
- 755 sul webroot: la vecchia scuola, onesta e prevedibile.
Risultato: il 403 sparisce.
Il sistemista sorride.
Per 5 secondi.
Terzo atto: il PHP che invece di girare… si scarica
Appena pensi “ok, è fatta”, apri il sito e il browser ti chiede candidamente:
“Vuoi aprire o salvare un file di tipo application/x-httpd-php?”
Ed è lì che un brivido ti scende lungo la schiena. Quando il browser ti propone di scaricare un file .php, vuol dire una cosa semplice:
“Il server non lo sta più eseguendo. Te lo sta dando paro paro.”
Apache è vivo, ma nessun modulo PHP è attivo. È come avere il forno acceso senza la resistenza: luce c’è, calore zero.
Un occhio a mods-available e mods-enabled:
ls /etc/apache2/mods-available/php*
# php8.2.conf, php8.2.load, php8.4.conf, php8.4.load (per esempio)
ls /etc/apache2/mods-enabled/php*
# (vuoto)
La nuova Debian, nel frattempo, ha fatto il salto generazionale:
- sul sistema c’è libapache2-mod-php8.4,
- il PHP CLI è 8.4,
- ma Apache… non lo sa ancora.
E qui entra in scena l’esperienza.
Il pivello scriverebbe:
a2enmod php
e si offenderebbe per l’errore:
ERROR: Module php does not exist!
Il sistemista navigato guarda i nomi dei file e dice: “Ok, tu vuoi il nome esatto del modulo, non le astrazioni filosofiche.”
Quindi:
a2enmod php8.4
apachectl -t
systemctl restart apache2
E, come un vecchio televisore a valvole preso a schiaffi sul lato giusto, PHP riprende a funzionare.
Quarto atto: archeologia digitale, ovvero “purga gli ex”
A questo punto PHP 8.4 gira, Apache è felice, il sito risponde. Nel sistema però sono rimasti i fossili di PHP 8.2 in stato rc nei pacchetti:
rc php8.2-...
rc libapache2-mod-php8.2 ...
Ed il vecchio sysadmin sa che i residui, oggi non danno fastidio, ma fra tre anni, in una notte di manutenzione, ti salta fuori un conflitto assurdo.
Quindi, senza pietà:
apt-get purge 'php8.2*' 'libapache2-mod-php8.2'
apt-get autoremove --purge
Non è solo pulizia: è igiene mentale. È come buttare via finalmente i floppy da 3,5" vuoti “che non si sa mai”.
Quinto atto: il log, la shell e l’ennesima trollata
Nel frattempo, mentre controlli i moduli:
apachectl -M | grep php || echo "Nessun modulo php caricato"
la shell, se ti scappa un punto esclamativo non quotato, potrebbe rispondere con il classico:
-bash: !: event not found
Non è Apache.
Non è PHP.
È bash che decide di interpretare il “!” come espansione di history.
Questo è il momento in cui il vecchio sistemista sospira, guarda la console e pensa:
“Io e te ci conosciamo da decenni e ancora mi fai questi scherzi…”
Si sistema la cosa, si toglie il punto esclamativo, e si va avanti.
Perché il diavolo sta sempre nel dettaglio, ed il dettaglio parla shell.
Epilogo: vecchio sistemista, nuovo Debian
Alla fine della storia, la situazione è questa:
- Debian aggiornata.
- Apache in piedi, tranquillo.
- PHP 8.4 attivo via libapache2-mod-php8.4.
- Vecchi moduli falciati, permessi sistemati chirurgicamente.
- Il sito in /home/utente/www/sito.local gira come se nulla fosse successo.
E il vecchio sistemista?
Non ha reinstallato, non ha “dockerizzato tutto per disperazione”, non ha invocato l’AI gridando al miracolo.
Ha solo:
- letto i log,
- analizzato gli include,
- capito chi tirava giù chi,
- sistemato moduli, permessi e residui,
- mantenuto il controllo dall’inizio alla fine.
Perché la differenza vera non è tra chi conosce il comando giusto da copiare, ma tra chi sa leggere cosa sta succedendo e ricostruire il film mentale della macchina.
Alla fine, questo upgrade è stato solo un’altra puntata della stessa serie:
“Debian cambia, i moduli cambiano, i log trollano… ma il vecchio sistemista resta lì, con il suo apachectl -t e quella calma da meccanico che sente il motore dal rumore.”
E quando il sito torna su e il PHP gira, non servono fanfare. Basta un curl -I andato a buon fine e quel piccolo, soddisfatto: “Ok, anche stavolta non mi hai fregato.” Alla prossima.
P.S. Curla i trolls. Ripeto: Curla i trolls.
Nessun commento:
Posta un commento