Ceci n'est pas une pipe

Chi utilizza RoundCube come applicazione webmail – noi ne utilizziamo una versione nostra con alcuni miglioramenti interessanti – si sarà accorto che la gestione degli allegati avviene in una maniera piuttosto anomala. Per motivi incomprensibili, l’applicazione è stata disegnata ignorando completamente alcuni importanti settaggi del php.ini e di Postfix relativi alle dimensioni dei file allegabili ad un messaggio email:

• vengono completamente ignorati i valori dei parametri upload_max_filesize (=maximum allowed size for uploaded files), post_max_size (=maximum size of POST data that PHP will accept) e memory_limit (=maximum amount of memory a script may consume)  indicati nel file php.ini
• viene completamente ignorato il valore di message_size_limit nel file main.cf di Postfix

Ovviare a questa mancanza però è davvero semplice, è sufficente editare il file /usr/share/roundcube/.htaccess e cambiare a piacimento i valori dei rispettivi parametri:

php_value       upload_max_filesize     20M
php_value       post_max_size           21M
php_value       memory_limit            64M

Tutto qui.

Da un paio di settimane per uno dei miei server di test ho aggiornato Apache2 MPM portandolo dalla versione “Prefork” alla “Worker”. Ho deciso di fare questa prova dopo avere letto alcuni post interessanti che descrivevano un notevole miglioramento nelle performance di WordPress dopo avere effettuato questo tipo di aggiornamento. Il periodo di prova ha confermato tutto: sul server in questione – dove gira una non più fiammante “Lenny” – ho potuto registrare una netta riduzione del load average durante l’esecuzione forzata di un elevato numero di processi PHP5 in FastCGI generati attraverso chiamate concorrenti a WordPress, una sorta di banchwork casalingo ottenuto con semplici script PHP autoprodotti.

Spiego rapidamente in che cosa consista la differenza tra le due versioni di Apache, almeno per gli aspetti che interessano poi le performance di WordPress: mentre la versione normalmente considerata standard – detta “Prefork” – utilizza un Multi-Processing Module basato sui processi, la versione “Worker” utilizza invece i thread. Il modello “Prefork” gestisce un processo per ogni connessione, mentre il modello “Worker” gestisce un processo per ogni gruppo di thread ed un thread per ogni connessione. In questo modo, la versione “Worker” di Apache2 tende ad utilizzare meno memoria e a distribuire meglio le chiamate al processore indirizzandole al maggior numero di core – anche per questo motivo si tende a considerare “Worker” più adatta a server multicore, nel senso che è su quelli che si possono misurare i miglioramenti di performance più significativi.

Attenzione però, lo scotto da pagare può essere notevolmente scoraggiante per moltissimi di voi: PHP5 potrà girare solo in modalità mod_fcgid mentre si dovrà per forza rinunciare al mod_php5 di Apache! Pensateci bene quindi prima di effettuare questo tipo di operazione.

Per come sono solito a configurare i miei server, il passaggio da “Prefork” a “Worker” nel mio caso ha richiesto un solo comando:

aptitude install apache2-mpm-worker

Aptitude mi ha avvisato subito che l’installazione di questo pacchetto avrebbe determinato la rimozione di libapache2-mod-php5:

# aptitude install apache2-mpm-worker
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
Lettura delle informazioni sullo stato esteso
Inizializzazione dello stato dei pacchetti... Fatto
Lettura delle descrizioni dei task... Fatto
I seguenti pacchetti sono DIFETTOSI:
libapache2-mod-php5
I seguenti pacchetti NUOVI (NEW) saranno installati:
apache2-mpm-worker
I seguenti pacchetti saranno RIMOSSI:
apache2-mpm-prefork{a}
0 pacchetti aggiornati, 1 installati, 1 da rimuovere e 0 non aggiornati.
È necessario prelevare 0B/242kB di archivi. Dopo l'estrazione, verranno occupati 8192B.
I seguenti pacchetti hanno dipendenze non soddisfatte:
libapache2-mod-php5: Dipende: apache2-mpm-prefork (> 2.0.52) ma non è installabile o
apache2-mpm-itk ma non è installabile
Le seguenti azioni permetteranno di soddisfare queste dipendenze:
Rimuovere i seguenti pacchetti:
libapache2-mod-php5
Il punteggio è 119


Se si decide di procedere – ripeto: rinunciando definitivamente a mod_PHP5! – l’installazione avverrà in pochi secondi, con il solito riavvio finale di apache mediante:

/etc/init.d/apache2 restart

Da questo momento in avanti non resta che godersi le straordinarie prestazioni di Apache2 MPM “Worker”.

Manca un solo giorno al rilascio ufficiale della nuova Debian GNU/Linux 6.0 – nome in codice: Squeeze. Il mondo intero si prepara a festeggiare la nascita di questa nuova versione di Debian organizzando una doverosissima festa che coinvolge tutti, ma proprio tutti quelli che vogliono partecipare: studenti, appassionati, newbie, simpatizzanti, professionisti e utenti di qualsiasi ordine e grado.

Al momento in Italia solo tre sono i Debian Squeeze Release Party ufficialmente registrati sul sito della distro Linux: Finale Ligure, Firenze e Padova.

Chi si trova da quelle parti, non manchi di partecipare! Chi invece è da qualche altra parte del mondo – e di questi tempi hai voglia se li invidio! – può sempre consultare l’elenco ufficiale dei party che si tengono in ogni nazione a questo indirizzo: http://wiki.debian.org/ReleasePartySqueeze

Segnalo questo tutorial molto ben fatto su come si possano facilmente creare favicon con GIMP. La spiegazione è estremamente dettagliata, quindi ne riporto qui una breve sintesi.

Premesso che le favicon sono sempre più importanti per individuare rapidamente una risorsa web all’interno di un browser, un gestore dei bookmark o anche solo un’applicazione per dispositivi mobile, va detto che realizzare una favicon idonea per tutti questi differentissimi strumenti di lavoro richiede qualche accortezza. Prima fra tutte la multirisoluzione: la favicon deve essere visualizzata correttamente in tutti i più diffusi formati – 16x16px, 32x32px, 64x64px e 128x128px.

Limitarsi al formato minimo per accontentare tutti non è una scelta oculata: avremo infatti molte applicazioni che mostreranno come favicon un incomprensibile riquadro composto da pixeloni stiracchiati. Adottare solo i formati maggiori invece produrrà la totale assenza di favicon nei supporti più datati o che semplicemente non sono in grado di riprodurre l’icona dei preferiti a quelle dimensioni.

Con GIMP – il celeberrimo programma libero e open source di fotoritocco – è possibile creare favicon partendo da immagini preformattate alle varie dimensioni, ottenendo non solo una efficace multirisoluzione ma anche gli effetti di trasparenza caratteristici del formato .png, ecco i semplici step da seguire:

1. creare l’immagine in formato .png ad una dimensione di 128x128px e salvarla
2. creare una copia della prima immagine, ridurla a 64x64px e salvarla separatamente
3. creare una copia della prima immagine, ridurla a 32x32px e salvarla separatamente
4. creare una copia della prima immagine, ridurla a 16x16px e salvarla separatamente
5. aprire nuovamente la prima immagine a 128x128px
6. importare come livello l’immagine a 64x64px
7. importare come livello l’immagine a 32x32px
8. importare come livello l’immagine a 16x16px
9. salvare l’immagine ottenuta come Microsoft Windows Icon (.ico) attribuendo correttamente i diversi livelli a formati corrispondenti

Fatto! Ora non vi resta che includere nelle vostre pagine la favicon multirisoluzione e richiamarla con l’apposito tag HTML:

<link rel="shortcut icon" type="image/x-icon" href="favicon.ico" />


Vi giro un minuscolo javascript che salverà molte delle vostre vite. Si tratta di una function da caricare negli head della pagina HTML per ottenere un resettamento progressivo degli z-index e annullare i problemi di sovrapposizione degli elementi che si verifica spesso quando nella pagina convivono vari elementi dinamici mescolati fra loro – ad esempio: menù a tendina tipo PixoPoint e presentazioni jQuery. In situazioni simili, spesso si verificano spiacevoli errori di valutazione della z-index da parte del browser – specialmente da parte di IE7 – ottenendo come risultato, ad esempio, la fastidiosa scomparsa di un menù a tendina dietro una presentazione a slide di jQuery. Questo piccolo script “miracoloso” risolverà il problema. Occhio che il reset delle z-index avviene in maniera progressiva dall’alto verso il basso, tenetene conto quando posizionate i div per non ottenere l’effetto contrario a quello voluto!


<script lang="javascript">
$(function() {
var zIndexNumber = 1000;
$('div').each(function() {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
</script>

Il sito web in cui mi sono casualmente imbattuto questa mattina rappresenta uno dei grandi classici per il nerdiano doc, una sorta di bildungsroman dello spippolatore da tastiera più accanito. Si tratta di una “succintissima” raccolta di comandi per chi ancora si ostina a governare qualsiasi tipo di server semplicemente inviando comandi testuali, senza finestre, colori, consumo superfluo di CPU e di banda… Le sezioni disponibili sono: Oracle database, Windows CMD, CMD Commands XP/Win7, Bash, VBScript Commands, OS X Commands, Windows PowerShell, SQL Server database. Ovviamente l’unico link che mi sento di mettervi a disposizione è il seguente: http://ss64.com/bash/

Oggi mi è capitata una di quelle cose che è bello dire solo quando sono finite. Stavo sistemando una serie di nuovi virtual host sul webserver di un cliente quando, del tutto improvvisamente, la macchina ha smesso di rispondere a qualsiasi forma di comando. L’ambiente bash in cui stavo digitando i miei comandi sembrava integra, nel senso che mi era possibile effettuare qualsiasi normale operazione purché non avesse a che fare con il filesystem: funzionavano perfettamente comandi come top e ps, ma era impossibile effettuare il less di un file o addirittura ottenere il man di un qualsiasi comando… In tutti i casi ottenevo un brutale e inequivocabile Input/output error, sintomo tristemente evidente di un problema sul filesystem.

Non che sia una situazione in cui mi sono trovato spesso, grazie al cielo, ma trattandosi quasi sicuramente di un problema del controller RAID e non dei dischi (entrambi nuovi di zecca) ho deciso di effettuare un reboot, ma anche questo comando restituiva il medesimo errore: non essendo disponibile in memoria in forma di processo il kernel lo deve per forza prelevare dal filesystem, quindi… Input/output error.

Fatta questa romanzesca e noiosissima introduzione, vengo al sodo e registro qui il paio di comandi con cui sono riuscito a comunicare al kernel le mie cattive intenzioni:

# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger

Con la prima istruzione ho abilitato il flag sysrq che permette di inviare comandi direttamente al kernel, mentre la seconda istruzione costituisce a tutti gli effetti il comando di reboot. Ecco alcuni link utili per conoscere meglio questa potentissima e preziosissima modalità di interazione con il kernel di Linux:

• http://it.wikipedia.org/wiki/Magic_Sys_Req
• http://en.wikipedia.org/wiki/Magic_SysRq_key
• http://www.linuxhowtos.org/Tips%20and%20Tricks/sysrq.htm

Questa è la notizia che tutti aspettavamo: i sempre più fondamentali backport fanno ora ufficialmente parte del progetto Debian GNU/Linux! Si tratta di un repository di pacchetti .deb disponibili da tempo all’URL http://www.backports.org e compilati per girare sulla versione stable e oldstable di Debian. La peculiarità di questa collezione di pacchetti – sempre molto aggiornati – è che sono pensati espressamente per “girare” sulle release stabili di Debian, ovviando così ad uno degli svantaggi – per chi lo considera tale – di questa blasonatissima distro: quello di mettere a disposizione pacchetti estremamente stabili ma sensibilmente datati.

I backport sono in pratica pacchetti prelevati dalla versione testing di Debian e ricompilati per le versioni stable e oldstable. In questo modo non è più necessario rinunciare alla leggendaria stabilità di Debian anche quando si presenta la necessità di utilizzare pacchetti più recenti di quelli messi a disposizione dalla distro, come l’ultima versione di OpenOffice, di Iceweasel, di Evolution ,etc.

L’archivio dei backport è stato spostato all’URL http://backports.debian.org e conta al momento ben 528 pacchetti “backportati” per la Lenny. Una ragione in più per continuare a preferire Debian GNU/Linux al cuginetto Ubuntu, a mio modestissimo parere.

Se volete rendere il vostro server inaccessibile ad un indirizzo IP da cui provengono troppi, sospetti tentativi di autenticazione, fail2ban è lo strumento che fa per voi. Si tratta di uno  script in Python che esegue automaticamente una di quelle noiosissime operazioni che spesso un sistemista UNIX/Linux deve effettuare manualmente: fail2ban cerca nei log di sistema tutti gli indirizzi IP che hanno tentato senza successo di accedere al server; se i tentativi di accesso superano un certo numero massimo consentito in un certo arco di tempo, allora quell’IP viene tagliato fuori mediante iptables per un (altrettanto) certo lasso di tempo. Leggi il resto »

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.