Dopo le pulizie fatte sul sito di Mozilla Italia e il cambio di tema sul blog inglese (per un misto di pigrizia e curiosità ho scelto di utilizzare direttamente Twenty Eleven, il tema predefinito di WordPress, con alcune mie fotografie come header), stamattina era il turno di questo blog:

• nuova immagine di testata con fotografia fresca di giornata. Nota di costume: per chi non l’avesse mai notato, il gecko tribale comparso in alto a destra verso la metà del 2010 è in realtà un tatuaggio;
• drastica riduzione del numero di immagini, passando da 39 (225 KB) a 9 (115 KB) grazie all’utilizzo di sprite CSS;
• rimozione dal CSS delle regole obsolete (per capirci, girava ancora roba con nome “blogbabel”…);
• sostituito il badge di flickr utilizzato in home page con un widget (plugin FlickrPress);
• installato un plugin per la condivisione (SexyBookmarks), così gli orsi di passaggio non possono più lamentarsi.

Sul fronte Hosting & Apache, ne ho approfittato per attivare mod_expires (per oscuri motivi ne avevo sempre ignorato l’esistenza).

Sempre il solito server di posta (Debian 6+Postfix+Dovecot+MySql) con ClamAV e SpamAssassin (integrato adattando quest’altra guida).

Premessa:

• da sempre utilizzo una casella @gmail.com come catch-all/archivio. Tutte le mie caselle di posta inoltrano una copia del messaggio alla casella in questione, in questo modo ho costantemente sotto controllo tutti gli indirizzi (una decina) in un unico punto via browser o cellulare Android. Inoltre utilizzando questa soluzione non devo preoccuparmi di limiti e tempi del servizio di recupero messaggi via POP3 messo a disposizione da Gmail;
• lo spam non viene cancellato direttamente, viene archiviato tramite Sieve in una cartella «Spam». Periodicamente controllo la cartella in questione via WebMail alla ricerca di falsi positivi e la svuoto.

Per inoltrare una copia dei messaggi utilizzo direttamente la tabella Forwardings:

• source: indirizzo_originale
• destination: indirizzo_originale, indirizzo_gmail

Problema: la casella e-mail di questo blog riceve un po’ troppa rumenta per i miei gusti, per cui la cartella Spam di Gmail è costantemente piena (le e-mail vengono inoltrate prima dell’applicazione dei filtri). Dovendo tenerla sotto controllo per evitare falsi positivi, la cosa non è piacevole.

La soluzione è inoltrare la posta a livello di Sieve, quantomeno per le caselle più problematiche. Per farlo bisogna modificare la sezione plugin del file /etc/dovecot/dovecot.conf aggiungendo la riga

sieve = /home/vmail/%d/%n/.dovecot.sieve

%d verrà sostituito dal dominio, %n dall’utente (la parte prima della @), per cui il file verrà cercato in un percorso del tipo /home/vmail/example.com/info/.dovecot.sieve per info(at)example.com

Nel file .dovecot.sieve (ricordarsi di assegnare come proprietario l’utente vmail) inserire

require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
  fileinto "INBOX.Spam";
}
else {
  redirect "indirizzo_gmail";
  keep;
}

Nuovo post della serie “appunti per tecnici anziani”.

Una volta configurato il simpatico server utilizzando questa guida come base (Debian 6 con Postfix, Dovecot e MySql per registrare utenti e virtual domain), sorge il dubbio: e adesso come ci accedo via WebMail?

Dopo qualche ricerca ho deciso di provare RoundCube, anche considerando che la nuova versione stabile è stata rilasciata il 14 dicembre 2011 (segno che il progetto è attivo).

Lasciando perdere la versione obsoleta nei repository, configuro il virtual domain per Apache (webmail.example.com) e ci decomprimo i file rimuovendo direttamente la cartella INSTALL. A questo punto bisogna procedere con la configurazione.

Creazione database MySql

Bisogna creare un nuovo database (e volendo un nuovo utente) per gestire sessioni e compagnia bella. Da console di MySql:

CREATE DATABASE roundcubemail;
GRANT ALL PRIVILEGES ON roundcubemail.* TO utente IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
USE roundcubemail;
SOURCE percorsowww/SQL/mysql.initial.sql;

Sostituire username, password e percorsowww con i dati corretti. L’ultima riga esegue un file .sql per creare le tabelle necessarie nel database roundcubemail.

File di configurazione

A questo punto bisogna rinominare (o meglio copiare) i file db.inc.php.dist e main.inc.php.dist in /config rimuovendo il .dist e apportare alcune modifiche.

db.inc.php (stringa di connessione al database MySql)

$rcmail_config['db_dsnw'] = 'mysql://utente:password@localhost/roundcubemail';

main.inc.php

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['smtp_server'] = 'localhost';
$rcmail_config['create_default_folders'] = true;
$rcmail_config['junk_mbox'] = 'Spam';

Spiegazione ultima riga: tramite regole Sieve sposto lo SPAM filtrato da SpamAssassin in una cartella “Spam”, non “Junk” come previsto dal file di configurazione standard.

Plugin per la modifica delle password

Ok, funziona tutto. Ma se un utente non ha accesso al database MySql come può modificare la propria password? Semplice: basta attivare il plugin “Password” cambiando questa riga in main.inc.php

$rcmail_config['plugins'] = array('password');

Anche in questo caso il plugin ha un file di configurazione da sistemare (rinominare o copiare senza .dist il file /plugins/password/config.inc.php.dist).

$rcmail_config['password_confirm_current'] = true;
$rcmail_config['password_db_dsn'] = 'mysql://mailadminutente:mailadminpassword@localhost/maildb';
$rcmail_config['password_query'] = 'UPDATE users SET password=ENCRYPT(%p) WHERE email=%u LIMIT 1';

Nel mio caso l’utente MySql di RoundCube è diverso da quello utilizzato per gestire gli utenti di posta, per cui devo modificare la stringa di connessione specificando user, password e database corretti. Anche la stringa SQL deve essere adeguata in base alla struttura del database.

Permettere al browser di memorizzare utente e password
Anche in questo caso bisogna mettere mano al file di configurazione principale main.inc.php.

// Allow browser-autocompletion on login form.
// 0 - disabled, 1 - username and host only, 2 - username, host, password
$rcmail_config['login_autocomplete'] = 2;

Look

Questo è l’aspetto con il tema default di RoundCube 0.7

Questo invece è il nuovo tema “Larry” su trunk (0.8 via svn)

Benvenuti nella nuova casa

Se state leggendo questo post significa che i DNS hanno terminato la loro magica e incomprensibile danza e il dominio punta al nuovo server. Per i più curiosi, il server scelto è l’EX4 (Intel® Core™ i7-2600 Quad-Core, 16 GB DDR3 RAM, 2×3 TB SATA 6 Gb/s HDD). Inizialmente avevo puntato l’EQ4, ma i soldi risparmiati evitando la licenza di Plesk (7,90 €/mese) li ho girati sul maggior costo di setup iniziale.

Un ringraziamento a Giovanni per avermi fatto scoprire Hetzner a suo tempo e Gianluca per il supporto morale (e quello pratico che dovrà darmi non appena esplode qualcosa).

Molti avranno letto l’articolo sui requisiti di sistema di WordPress 3.2 e, spero, si saranno posti il problema «Posso aggiornare?».

Log in to your hosting account, and check to make sure you have at least  PHP 5.2.4 and MySQL 5.0.

Se non sapete come verificare la versione in uso di PHP e MySQL, installate il plugin health check come suggerito nell’articolo. Se state utilizzando una versione troppo vecchia di PHP vedrete solo un avviso di questo tipo:

Warning: Your server is running PHP version 4.4.9. WordPress 3.2 will require PHP version 5.2.4.

Once your host has upgraded your server you can re-activate the plugin to check again.

Se siete su hosting Aruba, dovete verificare in particolare la versione di PHP: su tutti i domini che ho verificato la versione installata era inferiore a quella minima richiesta.

Per modificare la versione di PHP dovete accedere al pannello di controllo del vostro dominio:

• aprire la sezione Pannello gestione Hosting Linux;
• nella nuova finestra selezionare (in alto) Strumenti e Impostazioni;
• aprire la sezione Scelta della versione di PHP e selezionare la versione 5.3.x.

Il pannello di controllo non è particolarmente informativo – non si capisce neppure se la richiesta di cambio sia stata accettata – ma il cambio di versione avviene immediatamente. Personalmente trovo abbastanza assurdo che questa procedura non sia descritta nella Knowledge Base (o quantomeno io non sono stato in grado di trovarla).

Vi consiglio di seguire questo account twitter (ipotizzando che sia ufficiale) se avete siti ospitati presso Aruba. A quanto pare si è verificato un principio di incendio nella zona UPS, per cui si sta procedendo alla messa in sicurezza della zona e al ripristino dei servizi.

Considerazione a margine: confesso di non aver mai capito a fondo quelli che si lamentano di Aruba (parlo del servizio di hosting, non di dedicati o housing). Il mio sito personale e la mia posta elettronica sono ospitati presso di loro da una decina d’anni, e non mi è mai passato per la testa di cambiare servizio (i down “consistenti” si contano sulle dita di una mano). Ovviamente quando ho bisogno di soluzioni più affidabili per l’hosting mi appoggio ad altri fornitori (es. DreamHost, per la disponibilità di alcune funzioni come l’accesso ssh ma soprattutto per il servizio clienti), ma per la maggior parte delle situazioni e dei clienti Aruba è più che sufficiente.

Per Aruba avrei un’unica contestazione: possibile che serva un incendio e il down di tutta la struttura per scoprire l’utilità di un canale di comunicazione alternativo (es. Twitter)?