Ceci n'est pas une pipe

Risposta minimalistica ad una domanda minimalistica: come faccio a clonare un server Debian replicandone completamente il software installato?

1) sul server da clonare esporta l’elenco dei pacchetti installati:

dpkg --get-selections > installed-software

2) passalo sul server clone:

scp installed-software pippo@nomeserver.test123.com:~

3) sul server clone importa l’elenco dei pacchetti da installare:

dpkg --set-selections < installed-software

4) sul server clone avvia l’installazione dei pacchetti selezionati:

apt-get dselect-upgrade

That’s all folks!

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.

Questo ve lo devo assolutamente segnalare:

http://blog.davejamesmiller.com/2011/03/how-to-install-php-5-2-fastcgi-on-debian-6-0-squeeze

(copia HTML zippata: PHP52_on_Squeeze.zip)

Ci trovate istruzioni chiare e semplici per installare PHP 5.2 su Debian Squeeze senza effettuare il downgrade globale di PHP5! In altre parole in questo modo fate convivere tranquillamente sullo stesso server entrambe le versioni – la 5.3 con la 5.2 – ovviando i numerosi problemi introdotti dal cambio di versione per applicazioni web fondamentali, come Drupal 5.* che su Squeeze non vuole saperne di girare, come sanno ormai in molti – a proprie spese

Segnalo qui un problema che abbiamo riscontrato passando alla release 7.0.1 di NetBeans, anche se sono quasi certo la causa non sia attribuibile all’IDE ma risieda da qualche altra parte. In pratica, dopo l’aggiornamento NetBeans si comportava come se fosse completamente offline, restituendo un errore di connection timeout non solo in fase di pubblicazione di un progetto ma anche avviando il download degli aggiornamenti dai repository ufficiali.

Per risolvere il problema è stata sufficiente una googleata, ma la soluzione me l’appunto qui perché vorrei evitare di perdere lo stesso tempo in futuro, se mai si dovesse verificare un caso analogo.  Pare che a causare il timeout sia il fatto che una delle classi Java dedicate alla gestione del networking esca in IPV6 a meno che non la si istruisca diversamente, aggiungendo il seguente flag al file netbeans.conf:

-J-Djava.net.preferIPv4Stack=true

Il flag va accodato agli altri che si trovano alla riga 6 del file di configurazione:

netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Djava.net.preferIPv4Stack=true"

Spero questa informazione possa essere d’aiuto anche ad altri.

Chi utilizza Postgrey come componente di sistemi anti-SPAM complessi deve effettuare periodicamente un reset del database che l’applicazione ha generato. Questo perché da tempo i server di molti spammer riescono a mantenere lunghi periodi di operatività senza che niente e nessuno li riesca a fermare – facendoli finire in una delle blacklist di riferimento, ad esempio.

Il risultato è che sempre più spesso i server di alcuni grossi spammer finiscono nel database delle combinazioni considerate trustable dal nostro Postgrey, invalidandone di fatto l’efficacia. Per ovviare a scenari come questo esiste un metodo brutale ma efficace: resettare completamente i database di Postgery e i suoi file di lock, riportandolo alla situazione originaria.

Ecco come:

1. interrompere il daemon di Postgrey
2. eliminare la directory /var/lib/postgrey (consiglio vivamente di rinominarla)
3. creare una /var/lib/postgrey vuota
4. riavviare Postgrey

In altre parole, si deve procedere così:

# /etc/init.d/postgrey stop
# cd /var/lib
# mv postgrey postgrey_OLD
# mkdir postgrey
# chown -R postgrey:postgrey postgrey
# /etc/init.d/postgrey start

Queste istruzioni si riferiscono a Debian GNU/Linux – la mia distribuzione di riferimento – ma funzionano per quasi tutte le altre distribuzioni in circolazione. Controindicazioni? Nessuna, se non che dal reset in poi verranno ripresi in esame tutti i nuovi messaggi, anche quelli provenienti da server effettivamente trustable – ovvero che avevano già una loro triplet nel db di Postgrey – causando lievi ritardi nella consegna della posta elettronica. Per questo consiglio di effettuare il reset solo un paio di volte l’anno.

Questo tizio si è trovato nella mia stessa identica situazione ed ha risolto prima di me il problema in maniera semplice ed elegante, per questo motivo segnalo il suo articolo e mi appunto qui la preziosa stringa SQL. E’ proprio vero che prima di fare qualsiasi altra cosa una googolata è di dovere!

Condivido pienamente quanto dice in merito ai limiti del plugin Bulk Delete: funziona solo se i post da eliminare sono poche centinaia, a meno che non si metta mano al server alzando timeout di Apache e riservando maggiore quantità di RAM ai processi PHP – scelta molto sconsigliata, di norma questi tuning vanno fatti in maniera più ragionata e non al solo scopo di far funzionare un plugin di WordPress.

Ecco la stringa, sempclie e immediata, per ottenere la cancellazione definitiva di tutti i post appartenenti ad una determinata categoria:

DELETE a,b,c,d
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON ( a.ID = b.object_id )
LEFT JOIN wp_postmeta c ON ( a.ID = c.post_id )
LEFT JOIN wp_term_taxonomy d ON ( d.term_taxonomy_id = b.term_taxonomy_id )
LEFT JOIN wp_terms e ON ( e.term_id = d.term_id )
WHERE e.term_id = '12345'

Tra le molte applicazioni disponibili per tenere sotto controllo il consumo di banda di un server ce n’é uno che fa davero bene il suo lavoro: si tratta di vnStat, un network traffic monitor per sistemi BSD e Linux. Questa applicazione si comporta in pratica come un logger che tiene traccia dei volumi di dati in entrata e in uscita attingendo alle informazioni fornite in tempo reale direttamente dal kernel. Ecco quali sono le caratteristiche principali di vnStat così come vengono presentate sul sito web ifficiale del progetto:

• quick and simple to install and get running
• gathered statistics persists through system reboots
• can monitor multiple interfaces at the same time
• several output options
  • summary, hourly, daily, monthly, weekly, top 10 days
  • optional png image output (using libgd)
• months can be configured to follow billing period
• light, minimal resource usage
• same low cpu usage regardless of traffic
• can be used without root permissions
• online color configuration editor

La sua installazione è in effetti molto semplice e immediata, specialmente sui sistemi Debian-derivati:

# aptitude install vnstat

Una volta installato il pacchetto, è necessario inizializzare un database dedicato al logging per ogni scheda di rete che si vuole monitorare. Se si vuole monitorare la scheda eth0, ad esempio, è sufficiente lanciare il comando:

# vnstat -u -i eth0

Fatto questo, per tenere monitorato il traffico su quella specifica scheda di rete è sufficiente lanciare il programma senza alcun argomento:

ivan@biberon:~$ vnstat
Database updated: Fri Jun 24 01:00:01 2011
eth0
received:       4.71 GB (13.0%)
transmitted:    31.58 GB (87.0%)
total:          36.29 GB
                rx     |     tx     |  total
-----------------------+------------+-----------
yesterday      1.74 GB |   11.92 GB |   13.66 GB
today         31.97 MB |  162.10 MB |  194.07 MB
-----------------------+------------+-----------
estimated       720 MB |    3.67 GB |    4.38 GB

E’ possibile generare diverse tipologie di report semplicemente passando al programma l’argomento necessario, ma credo che già l’utilizzo standard indicato sopra possa essere più che sufficiente per le ordinarie operazioni di monitoraggio. Maggiori informazioni le trovate a questi indirizzi:

• http://humdi.net/vnstat/
• http://www.debian-administration.org/articles/330

Su tutte le Debian Squeeze c’è una correzione al volo da fare al php.ini dedicato agli script eseguiti lato server (a.k.a. command line). La correzione è di vitale importanza, ma solo se avete messo in cron script php e non volete che il server si rifiuti di eseguirli perché richiedono più memoria di quella allocabile. Il problema è dovuto al parametro:

memory_limit = -1

Visto così sembrerebbe un flag disabilitato e ci aspetteremmo quindi che non ci sia alcun limite nella memoria allocabile, invece il comportamento è tutt’altro:

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 64 bytes) in /var/www/clients/client21/web54/web/XXXXXX.php on line 212

Per ovviare al problema, è bene specificare quale effettivamente è il limite di memoria che intendiamo imporre ad uno script php eseguito da linea di comando. Il parametro si trova nel file:

/etc/php5/cli/php.ini

E la modifica da effettuare è la seguente:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
;memory_limit = -1
memory_limit = 128M

Also sprach Zio Vania

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”.

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" />