EXIT4web ha il piacere di annuncia l’avvio di un’importante partnership tecnico/commerciale con la X-Globe Srl e la bitHOUSEweb Snc per la fornitura di nuovi servizi web.

In collaborazione con la bitHOUSEweb siamo ora in grado di gestire in modo autonomo e centralizzato, con server  di proprietà e su rete Italiana, i servizi di DNS Server per il pacchetto domini in nostra gestione, alla bitHOUSEweb e all’X-Globe Srl.
Questa importante novità ci consentirà di garantire tempi di risposta notevolmente inferiori rispetto alla media con un particolare occhio di riguardo per l’high-availability del servizio, garantito dall’installazione dei server su due distinte reti.

E’ stato infine introdotto un potente servizio di caching per i contenuti statici dei siti quali immagini, script JavaScript, fogli di stile CSS e altro ancora. Tale servizio, da poco entrato ufficialmente in beta-testing, sarà a breve reso disponibile a tutti i clienti che ne facciano richiesta. Grazie ad esso si potranno garantire tempi di risposta nella gestione e visualizzazione dei contenuti mediamente del 20% superiori rispetto alla configurazione standard, con un notevole miglioramento generale nella velocità di consultazione delle pagine dei propri siti.

Per maggiori informazioni o per richiedere l’attivazione del servizio è possibile contattarci telefonicamente o via e-mail.

Dopo poco meno di un anno dall’attivazione del nuovo server su rete Maki è con immenso piacere che annuncio l’inserimento nell’infrastruttura tecnologica di EXIT4web di un nuovo server Linux dalle caratteristiche tecniche veramente importanti.

Questa macchina è stata installata su rete Aruba con una connessione 100Mbps e si compone di un sistema Linux Ubuntu con Apache, PHP in modalità fast-cgi, APC, librerie GD, pdfLib, MySQL ecc.. Stiamo parlando di un server IBM x3650 equipaggiato con un doppio processore QuadCore Xeon a 2,50 Ghz con 12MB di cache L2 a basso consumo (50W), 8GB di RAM, 4 dischi da 1TB configurati in RAID-1 per un ottimo compromesso tra sicurezza e performance e Firewall Hardware ZyXel con banda passante gestita dal Firewall di 100Mbps.

Lo storage interno è stato organizzato al fine di garantire performance d’avanguardia nell’elaborazione dei dati. Il primo mirror si suddivide in una partizione primaria di root ed una secondaria dedicata ai servizi Apache; il secondo invece gestisce i dati del database MySQL e l’archiviazione dei servizi di backup dati, garantendo in questo modo incredibili performance nell’elaborazione dei dati archiviati nei database di sistema (disponendo di un bus dati separato rispetto ai dischi principali di sistema). Oltre alle performance si è avuto un particolare occhio di riguardo nei confronti della sicurezza globale della macchina; si è infatti proceduto all’installazione di un potente firewall Hardware con i servizi ADP e IDP, servizi in grado di individuare e bloccare in modo trasparente e sicuro eventuali tentativi d’aggressione o d’accesso non autorizzato al Server.

Infine ma non per questo meno importanti sono state programmate ed attivate complesse regole di backup dei dati gestiti del Server con politiche globali di data retention in grado di garantire un veloce ed immediato restore di tutti gli eventuali dati persi (contenuti statici, applicazioni web o archivi database) per un periodo di un intero mese solare.

Modifica degli indirizzi IP del server.

Nella giornata di ieri è stato operato il cambio della VLAN del server con relativo cambio dell’indirizzo IP primario. Questa modifica potrebbe comportare dei limitati disservizi temporanei che verranno risolti nelle prossime ore.

In particolare accedendo ai pannelli EXIT4business e EXIT4municipality verrà notificato un messaggio di “Licenza non valida”.

Nell’articolo pubblicato sabato scorso dal titolo “Possibili problemi con Latin1” manca un aspetto fondamentale da ricordare una volta convertito il proprio database MySQL e i files del proprio sito dal charset ISO-8859-1 a UTF-8.

MySQL tende infatti ad aprire una connessione con il proprio server utilizzando il charset latin1 (ISO-8859-1) fintanto che non lo si convince del contrario; questo potrebbe creare dei spiacevoli problemi durante la visualizzazione dei testi delle pagine, in particolar modo di quelli che presentano al loro interno caratteri speciali quali gli accenti; per evitare che ciò accada è consigliato ricordare a MySQL di utilizzare una connessione in UTF-8 richiamando la funzione mysql_set_charset(), nel caso utilizziate le vecchie librerie MySQL, oppure mysqli::set_charset() qualora si utilizzino le nuove librerie MySQLi

// Connessione al DB
$db = mysql_connect('localhost', 'myuser', 'mypassword') or
die('Problemi di connessione al database remoto');
mysql_set_charset('utf8', $db);
mysql_select_db('mydb');

// Esecuzione delle query
mysql_query('SELECT * FROM users WHERE 1', $db);
...

oppure

// Connessione al DB
$db = new MySQLi('localhost', 'myuser', 'mypassword', 'mydb') or
die('Problemi di connessione al database remoto');
$db->set_charset('utf8');

//Esecuzione della query
$rs = $db->query('SELECT * FROM users WHERE 1');

Così facendo si avranno alla sorgente i dati memorizzati in UTF-8 (nel DB), i files HTML e/o PHP codificati in UTF-8 e la connessione tra il client e il server MySQL avverrà anch’essa in UTF-8, garantendo la correttezza nella gestione e nella visualizzazione delle informazioni gestite.

La migrazione dal vecchio al nuovo server potrebbe creare alcuni disagi soprattutto ai vecchi clienti che utilizzano applicazioni dinamiche o semplici pagine web HTML sviluppate utilizzando il charset Latin1(ovvero l’ISO-8859-1); il nuovo server infatti opera in UTF-8 sia nella distribuzione delle pagine web (su Apache) che nell’archiviazione delle informazioni nel database MySQL. Il problema si manifesta prevalentemente durante la visualizzazione di caratteri speciali quali le lettere accentate (àèìòùé…) o altri caratteri non standard (°…).

Per maggiore semplicità riporto un breve vademecum sulla conversione dei contenuti da ISO-8895-1 a UTF-8 in modo da limitare i possibili disservizi che si potrebbero riscontrare.

Conversione di contenuti statici (files JavaScript, HTML ecc..)

Qualora fosse stato utilizzato Dreamweaver assicurarsi di specificare UTF-8 come charset per la generazione delle pagine web del proprio progetto. Questo cambiamento comporta, in genera, la conversione dei files del progetto dal vecchi al nuovo formato e la sostituzione del meta-tag Content-Type da ISO-8859-1 a UTF-8:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Completata la conversione del progetto è necessario caricare, via FTP, i nuovi files HTML nella cartella /httpdocs/

Conversione di siti dinamici (con database MySQL)

In generale la conversione di un sito dinamico da ISO-8859-1 a UTF-8 è un’operazione particolarmente complessa e che potrebbe richiedere più di qualche ora di lavoro a seconda, ovviamente, dell’entità del progetto. La conversione del progetto si estende su due livelli: 1. Livello dati 2. Livello applicazione   - Conversione a livello dati Gran parte dei siti sviluppati in ISO-8859-1 fanno uso di tabelle memorizzate in MySQL utilizzando il charset latin1_*. La conversione di tale tipi di dati potrebbe limitarsi all’esecuzione di un numero ristretto di query SQL necessarie per convertire le tabelle e i dati in esse contenute da latin1_* a utf8_*. Nello specifico dovrà essere eseguita la query sottostante per ciascuna tabella presente nel sito sostituendo opportunamente tableName con il nome della tabella da convertire.

ALTER TABLE tableName CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Nella maggior parte dei casi non dovrebbero presentarsi problemi di conversione ma potrebbe, in taluni casi, generare un errore interno n°150.

Tale errore si presenta solitamente qualora si utilizzi tabelle InnoDB con relazioni attive su chiavi di tipo stringa; in questo caso la conversione del database (o delle tabelle in questione) potrebbe non concludersi correttamente. In tal caso potrebbe essere necessario intervenire direttamente nel server per fare un dump completo del Database, convertirlo utilizzando iconv da ISO-8895-1 a UTF-8, effettuare una ricerca e sostituzione veloce della direttiva CHARSET da latin_1 a utf_8, cancellare il vecchio database (o le vecchie tabelle) e caricare il nuovo dump MySQL opportunamente modificato.

Sintetizzando:

mysqladmin --opt -umioUtente -p mioDB > ./mioDB_latin1.sql
****
iconv -c -f latin1 -t utf-8 ./mioDB_latin1.sql > mioDB_utf8.sql

A questo punto aprire il nuovo documento mioDB_utf8.sql con un editor di testo (che possibilmente lavori in UTF-8), cercare la stringa “CHARSET=latin1″ e sostituirla con “CHARSET=utf8″.

mysql -umioUtente -p
****
use mioDB
\. ./mioDB_utf8.sql 

A questo punto non resta che convertire gli scripts PHP in modo da non interferire con il charset UTF-8.

- Conversione a livello applicazione

Per il completamento di questa seconda fase di lavoro è consigliato scaricare l’intera cartella /httpdocs nel proprio computer e operare con un editor di testo che consenta la ricerca globale del testo all’interno di un progetto (sotto Mac consiglio l’uso di TextMate).

Il primo aspetto da tenere in considerazione è che la funzione htmlentities() opera in ISO-8859-1 di default e spesso è la causa dei problemi di visualizzazione dei testi delle pagine dinamiche. Per risolvere questo problema si può optare per una delle due soluzioni disponibili:
1. completamento della chiamata alla funzione
2. conversione della funzione

Completamento della chiamata alla funzione

Per rendere la funzione htmlentities() compatibile con il charset UTF-8 è necessario aggiungere come secondo parametro la constante ENT_QUOTES e come terzo parametro la stringa ‘utf-8′

// Esempio di chiamata alla funzione pre-utf8
echo htmlentities($rs->nome);

// Ecco come deve essere modificata la chiamata alla funzione:
echo htmlentities($rs->nome, ENT_QUOTES, 'utf-8');

Tale soluzione potrebbe non essere una delle migliori dovendo intervenire con una regular expression per la sostituzione di tutte le chiamate ad htmlentities() del proprio progetto. Qualora non si disponga di sufficiente pazienza si consiglia di optare per la soluzione 2, altrettanto efficace e meno impegnativa.

Conversione della funzione

La funzione htmlentities() può essere nella maggior parte dei casi sostituiti da htmlspecialchars().
La prima infatti tende ad interferire con i caratteri speciali quali le lettere accentate andandole a sostituire con gli equivalenti in HTML (per esempio è diventa è). La seconda invece si limita a convertire un set limitato di caratteri quali il maggiore e il minore, la e commerciale, il singolo e il doppio apice in entità HTML (per esempio la e commerciale & diventa &)

// Esempio di chiamata alla funzione pre-utf8
echo htmlentities($rs->nome);

// Ecco come deve essere modificata la chiamata alla funzione
echo htmlspecialchars($rs->nome);

Questa operazione è molto più semplice da fare e con l’opportuna accortezza potrebbe richiedere non più di qualche minuto di lavoro; per prima cosa è necessario aprire il progetto nel proprio editor di testi, lanciare una ricerca globale in tutti i files del progetto della stringa “htmlentities(” e sostituirla con “htmlspecialchars(”.

Note conclusive

Completata la conversione del database e dell’applicazione è necessario assicurarsi che tutte le pagine facciano uso del charset UTF-8; volendo si può lanciare un iconv per ciascun documento HTML o PHP del proprio progetto ricordandosi però di impostare nel proprio editor di test il charset UTF-8 come codifica principale di lavoro. E’ infine fondamentale ricordarsi di sostiture il meta-tag Content-type come descritto nella sezione “Conversione di contenuti statici”.

E’ con immenso piacere che annuncio la conclusione della migrazione dei siti e servizi EXIT4web dal vecchio al nuovo server.

Sono passati due anni dall’installazione e configurazione del primo server, un egregio Linux Debian 3.0 con CPU Pentium IV 3.00 Ghz, 1 GB di RAM e 2 HardDisk 160 GB in Raid 1; in questi due lunghi anni di attività il server ha raggiunto e superato i 350 giorni di uptime consecutivi e nella sessione corrente ha superato la soglia dei 260 giorni di lavoro continuo. Un sinonimo di qualità e di garanzia per tutti i clienti che hanno scelto EXIT4web come proprio partner web.

La nuova macchina è in attività da poco più di una settimana e con l’ultimo intervento eseguito ieri nel tardo pomeriggio ha raggiunto lo status di Gold Master. Sotto al cofano sfoggia un Processore Xeon Quad-Core Q6700 a 2,66 Ghz, passando in questo modo su architettura a 64bit e quadruplicando la potenza di calcolo rispetto il precedente Single-Core da 3.0 Ghz; anche la memoria RAM è aumentato passando dal precedente Giga di RAM agli attuali 4 GB di RAM DDR2 a 800Mhz. Lo spazio disco è aumentato con un occhio di riguardo per la sicurezza e la protezione dei dati; sono stati installati 4 dischi, i primi due (in modalità RAID 1) da 250 GB sono stati destinati al Sistema Operativo (Linux Debian 4.0) e ai servizi web (Apache, Mail server, MySQL server ecc.) mentre gli altri 2 dischi, anch’essi configurati in MIRRORING utilizzando 2 dischi da 500GB, verranno utilizzati come archivio interno per i backup del servizi e dei contenuti presenti nel Server.

Dopo anni di tormentata agonia finalmente il sito torna on-line con un blog che vuole diventare un mezzo di comunicazione e di aggiornamento con il resto del mondo.

Niente comunicati stampa, non rientra nella mia linea editoriale, niente leccatine qua e la; solamente informazione e soprattutto disinformazione a 360°.

Al prossimo post!