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

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

Ho riscontrato che su alcuni Hosting (Aruba per esempio) quando si clicca su uno degli Eventi presenti alla voce “Prossimamente” va in errore mostrando una pagina simile alla seguente.

Errore nella visualizzazione Eventi di Gcalendar per Joomla

Andando a verificare la pagina segnalata nell’errore ossia

/components/com_gcalendar/hiddenviews/event/tmpl/default.php

si riscontra che la riga che genera l’errore è la seguente dove viene composto l’Url da richiamare per visualizzare in un iframe l’evento direttamente dal Google Calendar.

$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

Analizzando meglio il codice si riscontra che i due campi “scheme” e “host“, da come vengono utilizzati, dovrebbero essere presenti nell’”Array $p” ma, in realtà non esistono e di conseguenza l’Url che viene generato non è corretto.

Non ho potuto effettuare molti controlli ma effettuando una stampa dell’intero “Array $p” ho riscontrato che vi è un solo campo che, tra l’altro, non viene utilizzato all’interno della pagina. Per fare una verifica approfondita andrebbe verificato il popolamento dell’Array che avviene alla riga 12 dello stesso file tramite la seguente riga:

$p= parse_url($this->gcalendar);

Dato che, come detto, non ho avuto la possibilità di effettuare controlli approfonditi ho risolto il problema a monte commentando la riga 14 dove si generava l’errore e aggiungendone una in cui l’Url viene generato “manualmente”. Ecco il codice:

#$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

$url = ‘http://www.google.com’.'/calendar/event?eid=’ . $this->eventID . $this->timezone;

Così facendo il problema, ovviamente, si è risolto.

Sicuramente non è il metodo migliore per “fixare” il problema in quanto si tratta di un accorgimento piuttosto grezzo ma, temporaneamente, funzionante.

Eccovi il file già fixato:

Joomla Gcalendar Components – RAW FIX EVENT VIEW

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.