Drupal 5.x su Hosting condiviso di Aruba

Di nuovo su Aruba.it

Dopo un po di tempo (forse un anno... o più..) torno ad usare il servizio hosting condiviso offerto da aruba.it.
Per cui, l'occasione che mi si presenta e' vedere come reagisce l'hosting di aruba.it allo stress di un sito fatto con Drupal con discreto traffico mensile (40.000 visite al mese di media).

Per ospitare questo sito ho scelto un hosting condiviso linux con DB Mysql posta elettronica , antispam, antivirus, etc, etc. Il tutto per meno di 40 Euro circa all'anno... non e' male.

I nostri soliti difetti

La cosa che principalmente mi ha un po' sorpreso e' vedere come aruba non permetta di acquistare uno spazio hosting senza effettuare l'operazione di cambio maintainer.
Perche' non posso usare l'hosting (web e mail) di aruba.it ed avere il mio dominio su un maintainer diverso da aruba.it?
Questa e' chiaramente una scelta aziendale che eventualmente andrebbe discussa a parte.

Una delle differenze rispetto alle altre compagnie di hosting d'oltreoceano sono i tempi di attivazione.
Gli americani lavorano molto sull'immediato. Paghi ed hai i servizi acquistati nell'arco di pochi i minuti.
Nel nostro caso, aruba.it, ti fa attendere piu' o meno un paio di giorni. Che poi sono gli stessi necesari alla lavorazione della LAR (ad oggi ancora inviata via fax... che noia...) da parte dei signori di Pisa [http://www.nic.it]
Per cui, inviato il fax al NIC il lunedi', mi trovo al mercoledì mattina a poter iniziare a lavorare sul mio nuovo spazio web di aruba.
L'attivazione si concretizza con il ricevimento di diverse mail ad aruba.it che notificano l'attivzione dei vari servizio acquistati (una mail per la posta elettronica, una mail per il servizio antispam, una mail per il trasferimento del sito, un'altra mail per il Mysql....)

In questo momento del processo di trasferimento i primi server DNS iniziano ad aggiornarsi con le informazioni relative al nuovo mantainer.
Questo vuol dire che fino alla fine del mio lavoro di setup and tuning del nuovo hosting abbiamo inevitabilmente un disservizio (confermato anche dal servizio telefonico di aruba.it).
Questa non e' veramente una bella cosa!

Non solo per gli utenti che in quelle ore ricevono i piu' strani messaggi di errore dal loro browser.
Dato che i siti web da me gestiti vengono monitorati, indicizzati, etc etc su base giornaliera, per diversi giorni gli strumenti di monitoraggio continueranno a darmi errori su errori.

E - vedendo quei messaggi di errore tipo “robots.txt not found” o “sitemap non found” - mi ricordero' dei signori di aruba.it che non mi hanno permesso di lavorare sul mio spazio web prima del cambio maintainer.

Al lavoro...

Comunque, dopo chiacchiere, pezzi di carta, ed attese, iniziamo finalmente a lavorare:

A) trasferimento ftp.
Prendo il mio backup aggiornato del sito da trasferire e lo mando su con il filezilla. Fatto! velocemente e senza dolore. Bene.

B) import del DB.
all'attivazione del servizio aruba.it ti fornisce server, nome utente, password e 5 db gia' creati da loro. E' sempre curioso vedere come ogni provider gestisca l'interfaccia al mysql in maniera diversa. Il mio sql dump e' di molto superiore ai pochi mega accettati dal form del phpmyadmin.
Per cui apro un ticket di assistenza per esporre il problema e chiedere come fare. Pochi minuti dopo (forse 10, non di piu') ho gia' la risposta dell'assistenza tecnica che si dice disponibile a caricare il mio dump precedentemente caricato tramite ftp sul mio spazio. Eccellente. Devo riconoscere che ero un po prevenuto... L'ultima volta che avevo contattato aruba.it tramite ticket ricordo che bisognava aspettare delle belle mezze giornate per avere una risposta. E non augurarti di scrivere un ticket il venerdì pomeriggio. In quel caso dovevi attendere il lunedì, quando gli operatori entravano in ufficio e si trovavano probabilmente una lunga coda di ticket da evadere... quelli ricevuti durante il week-end. Chissà se oggi rispondono durante il week-end? Sarebbe bello... Comunque, in questo caso, sono stati perfetti.

Una volta caricati i file, caricato il DB, aggiornata la stringa di connessione al DB con i parametri forniti dal provider, possiamo provare il sito.

Inizia il solito debug

Senza sorprendermi troppo, trovo il temuto Errore 500...

E qui inizia ufficialmente il debug.....

Inizio ora a studiarmi gli strumenti di gestione che offre aruba. Anche se divisi in gruppi apparentemente non omogenei, i comandi principali sembra ci siano tutti.

In particolare, un paio di cose mi sorprendono piacevolmente...
Si puo' scegliere fra 2 versioni diverse di php ( 5.3 e 5.2.10 ) e - attenzione attenzione – si puo' scegliere da una lunga lista diverse configurazioni di php.ini, fra cui non manca “php.ini optimised for Drupal”

Avere la possibilita' di scegliere entrambi le scelte sembra molto interessante. Pero' va detto che non riesco a sceglierne nemmeno una delle due senza con completa sicurezza di fare la scelta giusta.

Per cui, prova a realizzare un nuovo .htaccess personallizzato per aruba partendo dal core drupal.

Questi sono i passi necessari per far girare il drupal 5.x sull'hosting standard di aruba:

• all'indirizzo http://webx143.aruba.it/CP/index.php?ak=php_override seleziona 5.2.10
• all'indirizzo http://webx143.aruba.it/CP/index.php?ak=phpini_override seleziona "php.ini optimised for Drupal". Prova ad aprire la tua home page. Nel mio caso, ho ancora l'errore 500
  elimina ogni riga dal /.htaccess (.htaccess della tuo web root).
• salva il tuo .htaccess
• RI-prova ad aprire la tua home page. Nel mio caso, la home page si carica correttamente. Questo conferma che stiamo modificando il .htaccess giusto....
• inizia a reincollare riga per riga dal .htaccess del tuo drupal core al .htaccess in uso. Per ogni riga re incollata:
  • salva
  • ricarica la tua pagina (home page)

Arriverai ad una riga che dara' alla home page lo stesso errore iniziale (Error 500).
A questo punto hai isolato la riga da verificare. Indaga sul motivo della riga in questione ed eventualmente disabilitala.

Nell'hosting aruba occorrera' quindi disabilitare:

• Le direttive Options.
  Come suggerito la tempistiva assistenza tecnica aruba.it (“... commentare le righe con la direttiva "Options" dell'.htaccess che non è utilizzabile presso le nostre soluzioni in Hosting Condiviso. ...”)
• DirectoryIndex index.php.
  Questa impostazione e' gia' definita nell'httpd.conf dei loro apaches.

Fatto! A questo punto il mio sito in Drupal 5.x gira che e' una bellezza sull'hosting condiviso di aruba.it

Note:

• Testare con attenzione i moduli che dipendono da un buon .htaccess, fra i quali:
  • Imagecache http://drupal.org/project/imagecache
  • Path http://drupal.org/project/path