Migrare server mail e caselle IMAP con Imapsync.

Può capitare di dover migrare per necessità proprie, caselle email o addirittura interi server mail che magari utilizzano formati di memorizzazione email diversi come Mailbox e Maildir, candidati incompatibili per una migrazione grezza spostando solamente i file da una cartella all’altra lavorando a livello filesystem, oppure semplicemente la volontà di voler migrare il contenuto di una casella mail (magari una di quelle gratuite come gmail, al nostro nuovo dominio).

La soluzione migliore, più professionale e performante è quella di utilizzare il tool IMAPSYNC che lavorando a riga di comando permette di effettuare una migrazione incrementale da casella A a casella B in modo del tutto indolore.

Questo tool recuperabile su http://freshmeat.net/projects/imapsync/ e disponibile per sistemi windows e Linux può essere installato con estrema semplicità tramite l’apt per i sistemi debian e derivati e yum per sistemi redhat derivati dopo aver aggiunto il repository Rpmforge alla configurazione di yum.

Il suo utilizzo è decisamente elementare: in pratica è necessario passargli i dati per collegarsi al server da cui copiare e poi quelli del server in cui vanno copiate le mail.
Questo un esempio di sintassi:

imapsync --host1 INDIRIZZO_SERVER1 --user1 UTENTE_1 --host2 INDIRIZZO_SERVER2 --user2 UTENTE_2 --authmech1 PLAIN --authmech2 PLAIN --noauthmd5 --ssl2

Ovviamente dovrete sostituire le parti in maiuscolo:

INDIRIZZO_SERVER1 e’ l’indirizzo IP o l’hostname del server numero 1
INDIRIZZO_SERVER2 e’ l’indirizzo IP o l’hostname del server numero 2
UTENTE_1 e’ l’utente sul server numero 1
UTENTE_2 e’ l’utente sul server numero 2

Lo script vi chiedera’ le password dei due utenti, dopodiche comincera’ la sincronizzazione.

Il parametro –ssl2 e’ necessario in quanto l’autenticazione PLAIN e’ solitamente permessa solo su canale criptato ssl.

imapsync ha il vantaggio di sincronizzare i server in maniera incrementale, i file gia’ sincronizzati non vengono piu’ spostati consentendo un minor tempo in caso di sincronizzazioni successive.

Tra le opzioni disponibili possiamo indicare se usare una connessione ssl, escudere messaggi troppo grossi o troppo vecchi e/o escudere intere directory.

Tuning e ottimizzazione server web linux. Quando il gioco si fa duro …

Quando il gioco si fa duro … i duri cominciano giocare” esclamava il buon John Belushi in Animal House.
Questa regola era validissima nei tempi passati in cui l’informatica era un terreno poco fertile, l’hardware aveva dei prezzi proibitivi e si era disposti a passare intere nottate in bianco per risparmiare 50k di RAM ottimizzando le routine più complesse direttamente in assembly.

Oggi il panorama è cambiato, l’hardware ha costi irrisori se paragonati a quelli dell’epoca e non c’è più tempo, capacità e voglia di ottimizzare : quando qualcosa non funziona bene si passa semplicemente ad hardware più potente. Quando la banda non basta più si compra più banda.

La convinzione ovvero che basti mettere mano al portafogli per risolvere tutti i problemi informatici del momento.

Questo è vero in alcuni casi ma rimane sempre una soluzione errata ed eticamente scorretta quando magari con un’ora di intelligente ottimizzazione si può incrementare le performance di oltre il 400%.
Il concetto è valido in particolar modo per i Webserver che sono spesso il risultato di sottocomponenti distinte (DBMS, Linguaggio lato server, Server web) su cui gira un sito internet che elabora dati e presenta contenuti multimediali al navigante.

Morale della favola : aspettate prima di montare un altro processore e quadruplicare la RAM, provate invece ad ottizzare le singole componenti software per rendere il sito web snello e scattante e in grado di sopravvivvere ad un traffico di centinaia di visite al secondo senza crashare.

Un buon modo di iniziare è sapere su cosa metter mano, ovvero ciò che il mercato offre nell’ambito di server LAMP, cosa installare e cosa ottimizzare per avere i miglior risultati possibili.

Innanzitutto vale sempre il metodo top-down, ovvero risolvere il problema scomponendo il problema in più sottoproblemi, ricordando in questo caso che l’inefficienza di ogni sottocomponente si ripercuoterà in modo incisivo sull’efficienza o meno dell’intero server. L’imperativo è dunque : evitare i colli di bottiglia.

Se ad esempio facciamo un uso massiccio di PHP, molti accessi concorrenti al Database con query complesse, utilizzo di CMS del calibro di Drupal, Joomla o WordPress e ci aspettiamo di riuscire a soddisfare una mole di richieste non indifferente bisogna seguire scrupolosamente i seguenti passi :

Scelta di un Hardware decente : ormai un server di fascia alta ce lo si può permettere per meno di 100 euro al mese. Configurazioni interessanti basate su intel i7 o addirittura Xeon, quad o six core, 12 giga o più in triple channel e dischi raid sata3.
Se si vuol essere performanti bisogna sempre fare una scelta a livello hardware adatta alle esigenze. Dischi SSD in RAID 1 sicuramente aumentano le performance diminuendo la latenza disco.
Se invece siamo nella condizione di avere un “macinino” e il nostro sito diventa sempre più popolare e non abbiamo voglia di migrare tutto su hardware più potente … ottimizziamo.
Qualunque siano i casi ottimizziamo a prescindere.

Web server : è ormai uno standard, lo danno installato di default con la nostra distribuzione Linux e ce lo teniamo come se fosse il miglior webserver del mondo. Apache esatto. Ottimo webserver facilmente ottimizzabile variando i parametri in httpd.conf.
Oppure possiamo optare per il meno conosciuto NGINX. Nginx si sta configurando sempre più chiaramente come una valida alternativa ad Apache: sembra infatti che, benchmark alla mano, Nginx risulti molto più leggero e performante del famoso rivale che spesso e volentieri soffre di memory leak i quali possono causare un consumo di memoria piuttosto “imbarazzante”. Se poi Nginx viene utilizzato in abbinamento con PHP FPM (FastCGI Process Manager), una versione di PHP ottimizzata per siti a traffico elevato, allora la differenza con la classica configurazione Apache+PHP diventa sensibile!

Database : normalmente ci si appoggia a MySQL come DBMS standard, più raramente a PostgreSQL. Database relazionali destinati alla realizzazione di progetti molto ambiziosi grazie a feature come integrità referenziale, stored procedure, stored function, viste, triggers, transazioni ACID.
Qualora il vostro sito non faccia uso di queste funzionalità optate per un DBMS senza queste funzioni ma più veloce e performante come ad esempio Drizzle.
Se siete pigri per passare a Drizzle e l’applicazione web (o sito) non ha una business logic complessa e non avete bisogno dell’integrità referenziale e tutte le altre belle cosucce elencate prima limitatevi a utilizzare tabelle MyISAM di MySQL piuttosto che le più complete ma meno performanti InnoDB.
A livello di progettazione Database vale la pena ricordare che una progettazione ad-hoc è fondamentale per una buona performance dell’intero progetto. Dunque ottimizzare i tipi di dato in uso nella creazione del database, le giuste tabelle, eliminare le ridondanze, fare un buon uso di indici, partizionare le tabelle, ma sopratutto ottimizzare le query SQL. A volte la performance di una query ottimizzata può essere di oltre il 1000 % (mille avete letto bene).
Una meticolosa analisi in ambito di progettazione a partire da uno schema E/R corretto è d’obbligo.
Vale la pena ricordare che un corretto tuning delle variabili d’ambiente in my.cnf (il file di configurazione di MySQL) può portare a vantaggi tangibili (spesso addirittura notevoli) sopratutto all’aumentare delle richieste concorrenti.

Script server side : diamo per scontato che programmiate in PHP e che dunque gli script siano scritti bene, o se magari non l’abbiate scritti voi che comunque siano performanti, o che comunque performanti o non performanti che siano non avete la possibilità o la capacità per modificarli.
E’ bene sapere che esistono degli opcode cacher per PHP come APC o eAccelerator che possono far risparmiare importanti risorse nella fase di fetching del codice php. Sarebbe complesso e decisamente lungo da spiegare nel dettaglio ma vi basti sapere che in media con l’adozione di tali strumenti (gratis oltretutto) le prestazioni aumentano da un 50% fino ad oltre il 400%.

Qualora intendiate dunque ottimizzare le performance del vostro sito web o vogliate consulenza per la realizzazione di siti web ad alto traffico, contattateci. Siamo in grado di metter mano ad ogni aspetto del vostro webserver e aumentare sensibilmente l’efficienza del vostro server benchmark alla mano.

Aggiornare da PHP 5.2 a PHP 5.3. Errori e non funziona pi

Un errore frequente negli ultimi mesi è quello di aggiornare incautamente da PHP 5.2 a PHP 5.3

Per quanto sia diritto e dovere di ogni sistemista che si rispetti, mantenere sempre aggiornato il proprio sistema, è sempre meglio informarsi sulle problematiche in cui si può incappare nell’aggiornamento di pacchetti software come il PHP, un vero e proprio linguaggio di programmazione web.

Ad essere onesti una parte della colpa andrebbe accollata agli sviluppatori di PHP che hanno creato confusione e svariati fraintendimenti in quanto si presupponeva a rigor di logica e buon senso che siccome l’upgrade da 5.1 a 5.2 non diede nessun problema di retrocompatibilità allora nemmeno l’aggiornamento a php 5.3 avrebbe dovuto darla.

Sarebbe stato inoltre saggio aspettare il rilascio del php 6 in ambiente di produzione, dato che php 5.3 è stato definito all’unanimità “una palestra per abituarsi prima di passare al 6“.

Addirittura alcuni panneli di controllo Point e click come Plesk proponevano l’aggiornamento automatico e con un paio di click si riusciva seriamente a compromettere il funzionamento degli script PHP non pienamente compatibili col 5.3

Fatto sta che in questa problematica sono incappati non solo novellini e sedicenti sistemisti ma anche serissimi hosting provider e sistemisti carrozzati con un decennio di esperienza su server linux.

Esistono tuttavia alcune soluzioni pratiche per ovviare al problema in base a diversi scenari, esperienza e sopratutto necessità.

In uno scenario di hosting condiviso ad esempio, laddove ci siano molti siti non compatibili con la nuova versione di PHP a causa delle funzioni deprecate, la soluzione migliore consiste nel fare un downgrade alla versione 5.2 dell’interprete PHP. Ovvero disinstallare tramite package manager (ad esempio apt, yum o yast) la versione del php 5.3 e i relativi moduli e installare nuovamente il php 5.2.

Nell’ipotesi invece che il server ospiti solo un paio di siti (magari gestiti dallo stesso cliente) è possibile valutare qualora usasse piattaforme di pubblicazione contenuti o ecommerce (come ad esempio: Joomla, Drupal, Zencart, Magento, Prestashop, WordPress, ecc…) la possibilità di aggiornare la piattaforma del CMS all’ultima versione che potrebbe essere compatibile col nuovo PHP 5.3. A titolo puramente informativo con Zencart funziona perfettamente.

Nella più remota ipotesi invece che si possa mettere mano al codice PHP (l’abbiamo scritto noi, il cliente è daccordo o magari il cliente stesso vuole aggiornare la compatibilità al 5.3) non rimane altro che armarsi di pazienza e correggere gli script rimpiazzando le funzioni deprecate. Un valido aiuto è quello di abilitare il logging degli errori e dei warning PHP nonchè di verificare i vari errori nel file error.log di apache.
Sicuramente la via più ardua e meno percorribile ma sicuramente la via più indicata se lungimiranti ad un ulteriore passaggio a PHP 6.

Si ricorda che forniamo assistenza sistemistica e siamo in grado di risolvere questa problematica in tempi e costi decisamente interessanti e competitivi.

Contattateci subito.

Virtual Hosting. Limiti, Pro e Contro di un hosting condiviso

hostingAlbert Einstein disse “Non hai veramente capito qualcosa finché non sei in grado di spiegarlo a tua nonna“.

Se volessimo parlare di Virtual Hosting o Shared Hosting a nostra nonna o ad un utente non troppo tecnico, potremmo fare un paragone con il vivere in condominio.

Comprare un hosting condiviso sta al vivere in appartamento in un condominio come un VPS o un server dedicato stanno alla casa o alla villa.

Mentre un condominio (server) può contenere centinaia di siti (appartamenti) appartenenti a diversi proprietari con diverse esigenze, un VPS o un Server Dedicato è una casa o una villa di un unico proprietario.

Molto spesso il vantaggio dello scegliere un hosting condiviso è derivato esclusivamente di un minor costo annuale ed una gestione outsourcing tutto incluso di tutta la parte sistemistica nella gestione di tutti i servizi (web, mail solitamente) senza costi aggiuntivi.
Vien dunque da chiedersi, perchè esistono aziende che dopo un’accurata analisi decidono di intraprendere la strada del server dedicato o del VPS (Virtual Private Server n.d.t.), quando l’hosting condiviso sembra esser la panacea di tutti i mali a costi decisamente irrisori che oscillano dai 10 ai 50 euro l’anno ?

La risposta è che ogni soluzione comporta dei vantaggi e degli svantaggi e ogni strumento ha una determinata funzione in relazione all’obiettivo da raggiungere.

Se continuassimo dunque il parallelismo tra hosting condiviso e vivere in condominio ci troveremo di fronte alle seguenti limitazioni.

  •  Condivisione delle risorse tra i vari “abitanti del server”.
    Come in condominio esistono delle risorse condivise in cui l’utilizzo non è garantito al singolo utente ma appunto condiviso tra i vari ospiti che sono presenti sullo stesso server.Avere risorse condivise consiste nell’impossibilità di determinare e prevedere quali e quant risorse saranno disponibili in un preciso momento. Non ci è dato infatti sapere quali risorse allocheranno gli altri ospiti del server e quante ne rimarranno disponibili per noi. Ciò può determinare inefficienza del nostro sito web (imputabile a colpe non nostre) o addirittura indisponibilità delle risorse che si traduce in lentezza del sito fino ad arrivare alla non visibilità.
  • Minor grado di sicurezza.
    Come in condominio, la sicurezza del nostro sito web viene messa a dura prova nonostante le accortezze prese in fase di sviluppo. E’ infatti cosa comune (sopratutto in hosting condivisi standard che non hanno attuato un sistema di separazione privilegi) che violando la sicurezza di un hosting condiviso (appartamento), si possa violare la sicurezza degli altri siti ospitati nello stesso server (ovvero altri appartamenti).
  • Limitazione nella libertà di scelta per modifiche tecniche.
    Come in condominio, non si ha la possibilità di fare modifiche sostanziali. Potete scegliere come arredare il vostro appartamento, ma non potrete ad esempio decidere da soli di come ritinteggiare l’intero stabile, di installare un ascensore più grande, o di installare una sedia scorrevole per salire le scale senza aver prima ascoltato il parere e ricevuta l’approvazione degli altri condomini.
    A livello sistemistico ciò potrebbe significare che nel caso vorreste fare modifiche sostanziali per (aggiornare, migliorare) il vostro sito come ad esempio installare un cacher, aggiornare la versione dell’interprete PHP, installare moduli PHP personalizzati, cambiare Webserver (ad esempio il performante NGINX al posto del classico Apache), non avrete nessun margine di manovra. Dovrete cioè accontentarvi di ciò che normalmente è lo standard in ambito hosting, e che di default l’hoster fornisce.
  • Elevata probabilità di finire in blacklisting
    Può capitare che qualora un utente sul nostro server decida di inviare newsletter non idonee, o qualche hacker lo faccia a suo posto al fine di fare spamming (magari dopo che è stato oggetto del furto delle password di posta). A quel punto le liste antispam di tutto il mondo segnaleranno l’IP in oggetto (su cui siamo anche noi) come malevolo e non riusciremo più per un arco di tempo che normalmente oscilla tra le 3 e le 12 ore a recapitare le nostre email.

Scegliere un hosting condiviso dunque significa in pratica “affidarsi alla sorte”, laddove sorte significa appunto la casualità o meno di imbattersi in un server con “coinquilini” rispettosi che siano in grado di non intasare il server (e dunque limitare le vostre performance) e un amministratore di sistema capace in grado di diagnosticare eventuali utenti problematici ed isolarli dai restanti clienti.

Viceversa scegliere un VPS o un server dedicato significa avere il controllo totale di tutto il server, del software a corredo nonchè della configurazione dei vari servizi.
E’ ovvio che gestire un servizio dedicato (sia esso Virtuale o Dedicato) comporta un dispendio di risorse (anche economiche) maggiore a vantaggio appunto di una libertà totale nonchè l’evitare tutti quei contro pocanzi elencati.

Con l’avanzare degli anni però, con la nascita di servizi managed si può realmente disporre di servizi ottimali configurati ad-hoc in base alle esigenze del cliente a prezzi irrisori sopratutto per attività professionali.

Vien da chiedersi infatti quale possa essere il problema nell’investire (investire, non spendere badate bene) una cifra che oscilla sulle 500 euro annuali ad un azienda che vende online o offre servizi professionali e deve attenersi a standard qualitativi ben più elevati dell’utente privato o del ragazzino che ha un sito internet per hobby.
Oltretutto disponendo di un servizio dedicato si può avere garanzie di intervento e un’assistenza più immediata che giustamente non si può pretendere (ne viene menzionata nei soliti contratti) in un servizio hosting condiviso di tipo best effort.

Riassumendo dunque :

Con l’espressione hosting condiviso (in inglese shared hosting) si intende la forma classica di hosting in cui un unico server è destinato ad ospitare una pluralità di siti web (a volte anche diverse centinaia se non addirittura migliaia) appartenenti a diversi titolari.

Nell’hosting condiviso tutti i siti web presenti sullo stesso server devono, ovviamente, condividere le capacità e le risorse della stessa macchina con il rischio che i problemi di un singolo sito web si riflettano anche su tutti gli altri.

L’hosting condiviso è la scelta tipica per siti web a basso traffico oppure destinati ad un uso non professionale. Per chi fa business con internet ed ha bisogno di garanzie di continuità di servizio potrebbe essere preferibile un hosting dedicato.