Ceci n'est pas une pipe

Oggi vi scrivo dalla mia nuova postazione di lavoro.  Sono al terzo piano di un palazzo in una zona non meglio identificata della città di Brescia. Come i salmoni, alla fine ho risalito a ritroso il flusso carsico della mia linea esistenziale e sono ritornato alle origini. Questa in fondo è la città da cui provengo. Qui è ancora tutto sottosopra, ma abbiamo quello che ci serve per lavorare, per lavorare bene, alle rifiniture penseremo più in là. C’è un bel cielo oggi qui a Brescia, spero tenga per il resto della settimana. Bene, ora torno alle mie cose. Dopo tutto, ora sono un mezzo bresciano, non posso mica restarmene con le mani in mano… Solo una cosa, la foto qui accanto l’ho presa sul web, mica è roba mia. Arrivederci!

Lo scrivo qui a titolo di promemoria per la prossima volta che dovesse succedermi… Questa mattina ho messo a disposizione di un collega un nuovo accesso FTP ad uno dei miei server Debian, su cui gira da sempre un ProFTPD molto ben performante.

Il collega mi ha segnalato gravi problemi di lentezza e ripetuti timeout sulla connessione FTP, fenomeno che in oltre un anno di produzione quel server non aveva mai evidenziato: decine di clienti accedono regolarmente via FTP alle DocumentRoot dei proprio VirtualHost godendo della piena disponibilità di banda e spazio disco.

Dopo avere verificato che il problema riguardava solo l’accesso FTP al mio server e dopo esserci assicurati che la sua connessione non avesse problemi sulla porta 21, dalle nebbie della mia scarsa memoria è riemersa come per magia la questione del reverse lookup! Disabilitarlo in ProFTPD ha infatti risolto completamente il problema… è stato sufficiente accodare al file /etc/proftpd/proftpd.conf le due direttive che seguono:

UseReverseDNS off
IdentLookups off

Riavviato ProFTPD il problema è tornato nel nulla da cui era provenuto

Segnalo qui un succulentissimo video pubblicato ieri da Luigi Rizzo dell’Università di Pisa sul Google Tech Talk. Davvero interessante, non perdetevela!

Quelli che hanno la cattiva abitudine di installare le applicazioni web nella document root si trovano  spesso a dover affrontare un fastidioso problema: l’impossibilità di gestire directory e sub-directory estranee all’applicazione a causa delle restrizioni di accesso imposte dal file .htaccess.

L’esempio più tipico è quello del CMS Drupal. Supponiamo di averlo installato e reso completamente accessibile all’URL:

http://www.miodominio.xx/

Il file .htaccess di Drupal controllerà tutto quello che può o non può essere accessibile al di sotto della propria document root, che in questo caso coincide esattamente con la document root del virtual host. Infatti il file .htaccess si trova nella radice del filesystem dedicato a questa applicazione:

http://www.miodominio.xx/.htaccess

In questo modo, se decidiamo di creare una qualsiasi nuova directory, questa subirà le medesime restrizioni scritte nel file .htaccess durante l’installazione di Drupal, come ad esempio l’impossibilità di navigare liberamente tra i suoi file e le subdirectory che essa contiene:

http://www.miodominio.xx/test/

Questa directory non è accessibile in questo modo, ma solo richiamando il nome del file in essa contenuto a cui vogliamo accedere, ad esempio:

http://www.miodominio.xx/test/pippo.html
http://www.miodominio.xx/test/imago.jpg

Se non viene indicato alcun file, viene cercato e mostrato il solo file index.php:

http://www.miodominio.xx/test/index.php

Se il file index.php non esiste, non viene mostrato il contenuto della directory – come molti si aspetterebbero – ma al contrario viene generato un bell’errore 404  (File Not Found).

Per ovviare a questo problema è sufficiente agire sul file .htacces, aggiungendo le istruzioni che rendono la directory /test/ immune da queste regole, immediatamente dopo l’inizializzazione del RewriteEngine:

<IfModule mod_rewrite.c>
RewriteEngine on
#
# ECCO LE DUE RIGHE DI ISTRUZIONI:
RewriteCond %{REQUEST_URI} "/test/"
RewriteRule (.*) $1 [L]
#

Provare per credere.

Un dritta veloce per chi mi ha chiesto un modo per ovviare al timeout delle connessioni SSH. Premetto che si tratta di una situazione sempre più diffusa, dovuta alla configurazione di default dei nuovi di router distribuiti da Telecom per Alice ADSL. Il problema può essere ovviato passando al comando ssh il parametro:

-o ServerAliveInterval=10

Il parametro manda un messaggio di noop al server ogni n secondi (in questo caso: 10) notificando al router che la connessione è di fatto operativa, anche in mancanza di alcun tipo di attività. Dato che non è comodissimo digitarlo ogni volta, è possibile aggiornare il proprio file .bashrc con un alias che incorpori l’opzione nel comando base:

alias ssh="ssh -o ServerAliveInterval=10"

Questo è quanto