Chi utilizzava  una versione precedente ha avuto la possibilità di effettuare l’aggiornamento automatico senza dover stare a scaricare il pacchetto, unzipparlo, uploadarlo via Ftp etc..

Terminato l’aggiornamento  alcuni hanno avuto la triste sorpresa di riscontrare l’errore “500 Internal Server Error” su tutte le pagine del proprio sito. Questa problematica si manifesta negli Hosting (nel mio caso Aruba) dove i permessi di default per avere il corretto funzionamento dei file devono essere impostati a CHMOD 0755 (dovuti all’utilizzo del suExec di Apache) dato che l’aggiornamento automatico comporta il reset dei permessi a CHMOD 0644.

L’errore è facilmente risolvibile reimpostando i permessi CHMOD corretti per tutti i file e cartelle che compongono il WordPress.

La community di WordPress aveva rilasciato già in data 5/12/2008 una modifica da apportare al file “wp-config.php” per evitare il manifestarsi di questo problema.

ARTICOLO ORIGINALE

Tale modifica consente di impostare manualmente i permessi CHMOD di default (attualmente sono a 0644) da assegnare ai file del WordPress in occasione di aggiornamenti o similari.

Per implementarlo è sufficiente seguire questi pochi semplici passi:

1) Aprire con un Editor il file “wp-config.php“;

2) Aggiungere le seguenti due righe in qualsiasi punto del file:

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Fine! d’ora in poi tutti gli eventuali aggiornamenti automatici assegneranno di default i permessi 0755

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.

Tale Exploit è un DoS PoC (Proof Of Concept) che sfruttando la funzione “alert” del JavaScript opportunamente formattata consente di far aumentare il carico in memoria di Google Chrome in pochi secondi causando un crash dell’applicativo. Ricorda come realizzazione quei JavaScript che venivano utilizzati forse 10 anni fa per far crashare i Browser (o in certi casi il Pc) generando un loop di apertura di PopUp.

Per chi volesse testarlo sulla propria pelle ecco l’Exploit versione Html e, successivamente, compresso con WinRar (non vorrei farvi crashare i PC  ):

Exploit Google Chrome – Milw0rm 6554

Ed eccovi alcuni screenshot del TaskManager di Chrome durante le prove.

Stato del TaskManager di Chrome appena avviato

Dopo 15 secondi la situazione era questa:

Lo stato della memoria dal TaskManager di Google Chrome dopo circa 15 secondi dal caricamento dell'Exploit

Aspettando qualche minuto la memoria Ram del proprio Pc sarà satura e Google Chrome andrà in errore

Il risultato di poco più di un minuto di attività dell'Exploit

L’unica cosa che mi permetto di osservare è che durante la navigazione, se si incappa in un sito contenente tale Exploit, potrebbe capitare di non accorgersi di quanto sta accadendo poiché, mentre Mozilla FireFox segnala e blocca l’apertura del Popup, in Google Chrome appare una barra in basso che, a mio avviso, non si nota particolarmente.

Rimango fiducioso verso gli Sviluppatori Google e come detto all’apertura di questo articolo tengo a sottolineare che stiamo parlando di una versione Beta. Penso che in occasione della primea Release Stabile questo genere di errori e falle saranno risolte a vantaggio di un nuovo concetto di Browser

Tale applicativo giunto alla recente versione 2.2.6 scaricabile qui risulta generare un errore presso alcuni Hosting Provider come, per esempio, Aruba nello step 2 dell’installazione quando viene effettuata il check dei requisiti di Sistema.

Solitamente l’errore è un “500 Internal Server Error” causato dal superamento del tempo di Timeout impostato in Apache. Nel file “error_log” questo è l’errore che si riscontra:

[Mon Sep 22 14:18:54 2008] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Output filter: Failed to read bucket (rc 70007): The timeout specified has expired [hostname "<nome_host>"] [uri "<gallery_folder>/install/index.php?step=2"] [unique_id "M2dscH8FFFEDDDryFQ3AAAC5"]

La soluzione migliore sarebbe quella di far variare i limiti di Timeout al proprio Provider ma, visto che è una di quelle richieste che difficilmente vengono esaudite, ho provveduto ad editarmi i file di installazione in modo che indipendentemente da quello che il Server ha o non ha mi dia l’ok per proseguire allo step successivo.

Il file da scaricare per la versione Gallery 2.2.6 è questo: SystemChecksSteps.

A suo tempo li feci anche per la versione Gallery 2.2.5. Eccoli qui:

SystemCheksStep – INSTALLATION 2.2.5

SystemCheksStep – UPGRADE 2.2.5

Va sostituito al posto dell’originale.

Per la versione Installation:

<cartella di gallery>/install/steps/SystemChecksSteps.class

Per la versione Upgrade (solo 2.2.5):

<cartella di gallery>/upgrade/steps/SystemChecksSteps.class

Una volta sostituito si può effettuare la normale installazione (o upgrade) senza problemi.

Tengo a precisare che, come già detto prima, tale file non risolve il problema ma, semplicemente, lo bypassa evitando di far eseguire qualsiasi check. Questo significa che se il Vostro Server non possiede i requisiti necessari per l’utilizzo di Gallery i problemi legati a tale incompatibilità persistono.