Allo stato attuale lo Staff Aruba è riuscito a ripristinare la visibilità della quasi totalià dei domini e di tutti gli altri Servizi.

Il problema è stato causato, da ciò che si legge in Rete, da un surriscaldamento delle batterie dell’Ups che ha poi portato alle fiamme vere e proprie per le quali sono intervenuti i Pompieri.

Una volta domato l’incendio si è passati alla pulizia dei locali danneggiati e al ripristino graduale di tutti i Servizi.

Il Provider vista la situazione di emergenza e l’irraggiungibilità di tutti i Servizi compreso il sito Aziendale ha provveduto ad aprire una pagina Twitter dove ha comunicato ai Clienti lo stato dei lavori e del ripristino.

Per maggiori informazioni fate riferimento ai seguenti url:

Aruba.it – Twitter

News Aruba.it

#1 – 29/4/2011 – 22.00 – Comunicato Stampa di Aruba.it

L’ingresso è gratuito e coloro interessati possono inviare le proprie richieste e proposte così da stilare un programma che soddisfi tutti gli amanti di questo Cms giunto ormai alla versione 1.6.1.

Non appena ci saranno maggiori informazioni provvederò ad aggiornare l’articolo.

Buona domenica!

Problema

I problemi che si riscontrano utilizzando detto componente in Hosting che hanno abilitato il “Mod_Security” sono principalmentdue due:

1) Mancato accesso all’interfaccia di gestione dal Pannello di Controllo del Joomla;

2) Errore nell’upload dei file tramite l’interfaccia Flash.

Perché?

Entrambe le problematiche nascono dalla presenza in diverse cartelle del file “.htaccess” contenente due istruzioni che, se abilitate nel Server in Hosting, consentono di disabilitare il “Mod_Security” per evitare che blocchi il passaggio di dati/file tra l’interfaccia Flash e il Server.

Il codice di questo file è il seguente:

SecFilterEngine Off
SecFilterScanPOST Off

Sul mio ed altri Hosting tale possibilità è disabilitata in quanto le misure di Sicurezza devono (giustamente) essere sempre attive e, quindi, il file “.htaccess” genera il manifestarsi di errori “500 Internal Server Error” e il mancato funzionamento degli applicativi/componenti dove esso è posizionato.

Al fine di risolvere le due problematiche precedentemente indicate, quindi, è necessario eliminare il file .htaccess dai seguenti percorsi:

/components/com_expose/expose/manager/amfphp
/components/com_expose/expose/manager/upload

Le righe in questione sono le seguenti:

<?
ob_clean();
flush();
?>

Cosa sono?

ob_clean() – E’ il comando che cancella/svuota il contenuto dell’output_buffer senza, però, eliminare il buffer stesso.

flush() -E’ il comando che elimina il buffer.

Perché? Cos’è l’Output Buffer?

Il mio Hosting attuale ha l’output_buffer attivo di default e anche provando a disattivarlo tramite override con php.ini resta comunque abilitato. Solitamente non crea problemi in quanto si tratta di un buffer creato appositamente per migliorare le performance del Web Server e del Php. Una volta, quando ancora avevamo 56K e ISDN eravamo abituati a vedere la pagina caricarsi piano piano, pezzo per pezzo. Appariva il logo, poi il menu e via dicendo si componeva tutta la pagina. Con l’avvento delle attuali ADSL questa situazione non si verifica più, almeno a livello visivo. A livello prettamente tecnico l’intepretazione e la visualizzazione di una pagina Web continuano ad avere questo comportamento.

L’output_buffer server a migliorare tutto ciò aggiungendo un buffer dove viene caricata la pagina prima ancora che venga “servita” al Client, ossia il vostro Browser. In questo modo quello che una volta era il vedere il singolo pezzo caricato ora diventa un’attesa temporale, seppur minima. Utilizzando un buffer è necessario attendere che si riempia tutto prima che vengano inviati i dati al Browser (e quindi prima che iniziate a vedere la pagina visivamente).

Come e Dove?

Da quel che ho scoperto facendo varie prove è consigliato inserire le due righe di codice prima di qualsiasi output della pagina. Io nel caso di WordPress l’ho inserito prima di qualsiasi cosa nella pagina header del mio Template che si trova a questo percorso:

/<root_di_wordpress>/wp-content/themes/<nome del template utilizzato>/header.php

Ho inserito le righe prima della dicitura “<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0…” nel seguente modo:

<?
ob_clean();
flush();
?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

Risultati

Da quel che ho potuto constatare sul mio sito e su quello di (pochi) altri le performance e soprattuto i tempi di risposta del Server migliorano.

Tengo a precisare che al momento non ho prove “scientifiche”  a sostegno della mia tesi e, quindi, vi invito a provare e se avete voglia ad informarmi dell’eventuale miglioramento (e speriamo non peggioramento) del vostro sito commentate questo post fornendo quante più informazioni possibili.

Il mio attuale Hosting ha il Php configurato come Cgi di Apache e l’output_buffering impostato a 4096.

Configurazione Php come CGI

Configurazione output_buffering a 4096

Non vi sono consigli veri e propri da dare in merito ma, per mia esperienza personale, l’utilizzo di un “php.ini” con abilitate alcune funzioni quali, ad esempio, la “Compressione Gzip“, permette di diminuire il numero di volte in cui il proprio sito va in Timeout o in errore “500 – Internal Server Error“.

La Compressione Gzip consente di far si che il Server comprima alcuni oggetti delle pagine ottimizzando così le performance in quanto il “peso” generale della pagina risulta ridotto.

Per attivare tale opzione vi sono vari modi ma, sinceramente, io preferisco utilizzare l’override tramite “php.ini”. Tale file contiene tutte le configurazioni del Web Server che sono, praticamente, quelle che vengono visualizzate quando si esegue il comando “phpinfo()” del Php. Per vederlo in azione basta creare e, successivamente, caricare via browser una pagina .php contenete le seguenti righe:

<?php

phpinfo();

?>

Utilizzando un php.ini opportunamente modificato è possibile variare (quando consentito del Provider) alcuni parametri come, ad esempio, il “memory_limit“, il “max_execution_time“, l’”output_buffering“, etc.

A questo link potete leggere tutti i parametri impostabili in tale file e la loro descrizione.

Tornando al discorso “Compressione Gzip” eccovi di seguito il codice da inserire nel vostro “php.ini” per abilitarla.

Io utilizzo il metodo che si appoggia alle Librerie Zlib. Il file “php.ini” per utilizzarle è il seguente:

output_buffering = 4096
output_handler =
zlib.output_compression = On
zlib.output_compression_level = 3
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

Per chi non avesse sbattimento eccovi il file già preparato da copiare nella root del proprio sito (o dove richiesto):

Php.ini – Compressione Gzip On – Librerie Zlib

In alternativa a tale metodo è possibile abilitare la compressione utilizzando le Gzip e, in tal caso, il codice da inserire è il seguente:

output_buffering = 4096
output_handler = ob_gzhandler
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

e questo il file già preparato:

Php.ini – Compressione Gzip On – Librerie Gzip

NOTE – Il file “php.ini” ha la particolarità di resettare alle impostazioni di default di Apache le eventuali impostazioni  omesse. Se inserite solo una riga contenente l’impostazione da cambiare le restanti verrebbero resettate ai valori minimi. E’ quindi importante inserire sempre tutte le impostazioni di base necessarie per evitare il crearsi di tale situazione. Il file da me pubblicato vale per il mio Hosting e, quindi, è possibile che su altri Provider crei problemi oppure necessiti di maggiori impostazioni inserite.

Se riscontrate problemi contattatemi tramite i Commenti che provvederò a darvi una mano.