Dopo le pulizie fatte sul sito di Mozilla Italia e il cambio di tema sul blog inglese (per un misto di pigrizia e curiosità ho scelto di utilizzare direttamente Twenty Eleven, il tema predefinito di WordPress, con alcune mie fotografie come header), stamattina era il turno di questo blog:

• nuova immagine di testata con fotografia fresca di giornata. Nota di costume: per chi non l’avesse mai notato, il gecko tribale comparso in alto a destra verso la metà del 2010 è in realtà un tatuaggio;
• drastica riduzione del numero di immagini, passando da 39 (225 KB) a 9 (115 KB) grazie all’utilizzo di sprite CSS;
• rimozione dal CSS delle regole obsolete (per capirci, girava ancora roba con nome “blogbabel”…);
• sostituito il badge di flickr utilizzato in home page con un widget (plugin FlickrPress);
• installato un plugin per la condivisione (SexyBookmarks), così gli orsi di passaggio non possono più lamentarsi.

Sul fronte Hosting & Apache, ne ho approfittato per attivare mod_expires (per oscuri motivi ne avevo sempre ignorato l’esistenza).

Sempre il solito server di posta (Debian 6+Postfix+Dovecot+MySql) con ClamAV e SpamAssassin (integrato adattando quest’altra guida).

Premessa:

• da sempre utilizzo una casella @gmail.com come catch-all/archivio. Tutte le mie caselle di posta inoltrano una copia del messaggio alla casella in questione, in questo modo ho costantemente sotto controllo tutti gli indirizzi (una decina) in un unico punto via browser o cellulare Android. Inoltre utilizzando questa soluzione non devo preoccuparmi di limiti e tempi del servizio di recupero messaggi via POP3 messo a disposizione da Gmail;
• lo spam non viene cancellato direttamente, viene archiviato tramite Sieve in una cartella «Spam». Periodicamente controllo la cartella in questione via WebMail alla ricerca di falsi positivi e la svuoto.

Per inoltrare una copia dei messaggi utilizzo direttamente la tabella Forwardings:

• source: indirizzo_originale
• destination: indirizzo_originale, indirizzo_gmail

Problema: la casella e-mail di questo blog riceve un po’ troppa rumenta per i miei gusti, per cui la cartella Spam di Gmail è costantemente piena (le e-mail vengono inoltrate prima dell’applicazione dei filtri). Dovendo tenerla sotto controllo per evitare falsi positivi, la cosa non è piacevole.

La soluzione è inoltrare la posta a livello di Sieve, quantomeno per le caselle più problematiche. Per farlo bisogna modificare la sezione plugin del file /etc/dovecot/dovecot.conf aggiungendo la riga

sieve = /home/vmail/%d/%n/.dovecot.sieve

%d verrà sostituito dal dominio, %n dall’utente (la parte prima della @), per cui il file verrà cercato in un percorso del tipo /home/vmail/example.com/info/.dovecot.sieve per info(at)example.com

Nel file .dovecot.sieve (ricordarsi di assegnare come proprietario l’utente vmail) inserire

require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
  fileinto "INBOX.Spam";
}
else {
  redirect "indirizzo_gmail";
  keep;
}

Nuovo post della serie “appunti per tecnici anziani”.

Una volta configurato il simpatico server utilizzando questa guida come base (Debian 6 con Postfix, Dovecot e MySql per registrare utenti e virtual domain), sorge il dubbio: e adesso come ci accedo via WebMail?

Dopo qualche ricerca ho deciso di provare RoundCube, anche considerando che la nuova versione stabile è stata rilasciata il 14 dicembre 2011 (segno che il progetto è attivo).

Lasciando perdere la versione obsoleta nei repository, configuro il virtual domain per Apache (webmail.example.com) e ci decomprimo i file rimuovendo direttamente la cartella INSTALL. A questo punto bisogna procedere con la configurazione.

Creazione database MySql

Bisogna creare un nuovo database (e volendo un nuovo utente) per gestire sessioni e compagnia bella. Da console di MySql:

CREATE DATABASE roundcubemail;
GRANT ALL PRIVILEGES ON roundcubemail.* TO utente IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
USE roundcubemail;
SOURCE percorsowww/SQL/mysql.initial.sql;

Sostituire username, password e percorsowww con i dati corretti. L’ultima riga esegue un file .sql per creare le tabelle necessarie nel database roundcubemail.

File di configurazione

A questo punto bisogna rinominare (o meglio copiare) i file db.inc.php.dist e main.inc.php.dist in /config rimuovendo il .dist e apportare alcune modifiche.

db.inc.php (stringa di connessione al database MySql)

$rcmail_config['db_dsnw'] = 'mysql://utente:password@localhost/roundcubemail';

main.inc.php

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['smtp_server'] = 'localhost';
$rcmail_config['create_default_folders'] = true;
$rcmail_config['junk_mbox'] = 'Spam';

Spiegazione ultima riga: tramite regole Sieve sposto lo SPAM filtrato da SpamAssassin in una cartella “Spam”, non “Junk” come previsto dal file di configurazione standard.

Plugin per la modifica delle password

Ok, funziona tutto. Ma se un utente non ha accesso al database MySql come può modificare la propria password? Semplice: basta attivare il plugin “Password” cambiando questa riga in main.inc.php

$rcmail_config['plugins'] = array('password');

Anche in questo caso il plugin ha un file di configurazione da sistemare (rinominare o copiare senza .dist il file /plugins/password/config.inc.php.dist).

$rcmail_config['password_confirm_current'] = true;
$rcmail_config['password_db_dsn'] = 'mysql://mailadminutente:mailadminpassword@localhost/maildb';
$rcmail_config['password_query'] = 'UPDATE users SET password=ENCRYPT(%p) WHERE email=%u LIMIT 1';

Nel mio caso l’utente MySql di RoundCube è diverso da quello utilizzato per gestire gli utenti di posta, per cui devo modificare la stringa di connessione specificando user, password e database corretti. Anche la stringa SQL deve essere adeguata in base alla struttura del database.

Permettere al browser di memorizzare utente e password
Anche in questo caso bisogna mettere mano al file di configurazione principale main.inc.php.

// Allow browser-autocompletion on login form.
// 0 - disabled, 1 - username and host only, 2 - username, host, password
$rcmail_config['login_autocomplete'] = 2;

Look

Questo è l’aspetto con il tema default di RoundCube 0.7

Questo invece è il nuovo tema “Larry” su trunk (0.8 via svn)

Benvenuti nella nuova casa

Se state leggendo questo post significa che i DNS hanno terminato la loro magica e incomprensibile danza e il dominio punta al nuovo server. Per i più curiosi, il server scelto è l’EX4 (Intel® Core™ i7-2600 Quad-Core, 16 GB DDR3 RAM, 2×3 TB SATA 6 Gb/s HDD). Inizialmente avevo puntato l’EQ4, ma i soldi risparmiati evitando la licenza di Plesk (7,90 €/mese) li ho girati sul maggior costo di setup iniziale.

Un ringraziamento a Giovanni per avermi fatto scoprire Hetzner a suo tempo e Gianluca per il supporto morale (e quello pratico che dovrà darmi non appena esplode qualcosa).

Molti avranno letto l’articolo sui requisiti di sistema di WordPress 3.2 e, spero, si saranno posti il problema «Posso aggiornare?».

Log in to your hosting account, and check to make sure you have at least  PHP 5.2.4 and MySQL 5.0.

Se non sapete come verificare la versione in uso di PHP e MySQL, installate il plugin health check come suggerito nell’articolo. Se state utilizzando una versione troppo vecchia di PHP vedrete solo un avviso di questo tipo:

Warning: Your server is running PHP version 4.4.9. WordPress 3.2 will require PHP version 5.2.4.

Once your host has upgraded your server you can re-activate the plugin to check again.

Se siete su hosting Aruba, dovete verificare in particolare la versione di PHP: su tutti i domini che ho verificato la versione installata era inferiore a quella minima richiesta.

Per modificare la versione di PHP dovete accedere al pannello di controllo del vostro dominio:

• aprire la sezione Pannello gestione Hosting Linux;
• nella nuova finestra selezionare (in alto) Strumenti e Impostazioni;
• aprire la sezione Scelta della versione di PHP e selezionare la versione 5.3.x.

Il pannello di controllo non è particolarmente informativo – non si capisce neppure se la richiesta di cambio sia stata accettata – ma il cambio di versione avviene immediatamente. Personalmente trovo abbastanza assurdo che questa procedura non sia descritta nella Knowledge Base (o quantomeno io non sono stato in grado di trovarla).

Vi consiglio di seguire questo account twitter (ipotizzando che sia ufficiale) se avete siti ospitati presso Aruba. A quanto pare si è verificato un principio di incendio nella zona UPS, per cui si sta procedendo alla messa in sicurezza della zona e al ripristino dei servizi.

Considerazione a margine: confesso di non aver mai capito a fondo quelli che si lamentano di Aruba (parlo del servizio di hosting, non di dedicati o housing). Il mio sito personale e la mia posta elettronica sono ospitati presso di loro da una decina d’anni, e non mi è mai passato per la testa di cambiare servizio (i down “consistenti” si contano sulle dita di una mano). Ovviamente quando ho bisogno di soluzioni più affidabili per l’hosting mi appoggio ad altri fornitori (es. DreamHost, per la disponibilità di alcune funzioni come l’accesso ssh ma soprattutto per il servizio clienti), ma per la maggior parte delle situazioni e dei clienti Aruba è più che sufficiente.

Per Aruba avrei un’unica contestazione: possibile che serva un incendio e il down di tutta la struttura per scoprire l’utilità di un canale di comunicazione alternativo (es. Twitter)?

Certe volte mi stupisco di quanto sia corta la memoria della rete. Quello che sta succedendo oggi pare la fotocopia di quello che succedeva tre anni fa.

Fonte Adnkronos

Roma, 7 lug.- (Adnkronos) – A quanto apprende l’ADNKRONOS, la magistratura romana sarebbe in procinto di oscurare il sito, registrato alle Antille, che ha pubblicato il testo di una falsa telefonata tra Silvio Berlusconi e Fedele Confalonieri.

Vi prego, ditemi che non avete letto Aruba nei dati del Whois e avete pensato alle Antille Olandesi…

Qualcun altro vuole aggiungere ignoranza alla discussione? Direi che c’è solo l’imbarazzo della scelta, ad esempio potremmo parlare di “oscuramento” ignorando il fatto che il sito si trova su un hosting condiviso di Aruba (e quindi su una macchina insieme a centinaia di altri siti, e chi amministra il server ha tutto il diritto di segare un sito che cannibalizza le risorse).

Dal momento che al sottoscritto questa cosa era sfuggita, con questo post spero di essere utile ad altri utenti DreamHost: dalle quattro offerte di hosting originali – questo blog era ospitato sul terzo livello, Code monster – si è passati a un solo piano da 10,95$ al mese.

Attraverso la gestione del pannello di controllo (billing->manage account) è possibile scegliere di passare all’offerta attuale (credo si chiami Happy hosting). In questo modo:

• DreamHost rimborsa i mesi rimanenti (nel mio caso 2 mesi a 19,95$);
• l’addebito riparte dal mese in cui si richiede il cambio di piano (10,95$/mese);
• il cambio di tariffa non comporta disservizi o discontinuità nel servizio;
• rinnovando per più anni è possibile avere sconti sul costo mensile: ad esempio ho scelto di rinnovare per 3 anni con uno sconto del 27%, per cui pagherò meno di 8$ al mese.

Considerando il cambio attuale euro/dollaro, vale la pena farci un pensierino.;-)

Se non siete ancora clienti Dreamhost, potete usare questi codici sconto.

Vengo meno alla promessa di non occuparmi ulteriormente di TopHost su questo blog ma non riesco a ignorare questo commento al post di Stefano Bellasio su HostingTalk:

Intanto una prima cosa: il comunicato non è per nulla frutto di “emotività” e non è assolutamente uno “sfogo” ma scaturusce da un lungo brainstorming estivo sulla pianificazione della nostra campagna di comunicazione autunnale in questo assistiti da alcuni tra i massimi esperti a livello internazionale del settore. Ovviamente in questa sede non posso darvi dettagli ma vi terremo compagnia nei prossimi giorni con altre attività.

Mi astengo dal commentare ulteriormente, ci tenevo solo a fissare nella memoria queste frasi.

Se non l’avete già fatto vi consiglio la lettura di questo post di Stefano Epifani; se invece vi abbonda del tempo, potete anche dare un’occhiata alla miriade di post scritti sull’argomento.

Come previsto: gli ultimi aggiornamenti (6 maggio) sul blog di Casper parlavano di intervento presso ICANN per risolvere il contenzioso.

6 Maggio – Inoltrata protesta formale a InterNIC per l’inserimento da parte di Wide.it di informazioni false relative a indirizzo email e numero telefonico del contatto amministrativo del dominio nel Whois Record, ostruzionismo e condotta censurabile secondo le policies ICANN. Inviato rapporto a ICANN attraverso il canale ufficiale di segnalazione delle dispute in corso per i trasferimenti di dominio.

Se state cercando un hosting, lasciate perdere Wide.it (volutamente senza link). Tanto vale investire il vostro tempo libero nel Texas Hold’em su Partypoker.

Per evitare che un malaugurato incidente tecnico rimuova l’ultimo messaggio di Casper, lo riporto in toto su questo blog.

Benvenuto.

Caro visitatore, prima di passare oltre, potrebbero interessarti un paio di cosette stuzzicanti che stanno accadendo su questo dominio.

Devi sapere che il 25 Aprile scorso, del tutto casualmente il giorno della Liberazione, ho chiesto all’attuale provider Wide.it di rimuovere il Registrar Lock in vista di un trasloco di Casperize.com sui server di Aruba. Mi dirai, niente di più facile.

Sbagliato.

Wide ha rimosso il Registrar Lock, ma c’è un ma: questo di per sè non è sufficiente. Il contatto email registrato nel Whois Record deve poi rispondere ad una email standard del nuovo maintainer, confermando in questo modo il trasferimento. Se questo contatto email è un indirizzo del provider attuale, come si da il caso che sia, il successo dell’intera procedura dipende dall’onestà e trasparenza di gente che sa di essere sul punto di perdere un cliente. Se per puro caso le istruzioni contenute nel messagio del nuovo provider vengono ignorate, dopo alcuni giorni di attesa il trasferimento fallisce.

E naturalmente è fallito.

Il 29 Aprile ho richiesto la rimozione del Registrar Lock anche per le estensioni .net e .org di questo dominio, disponendo nel contempo il trasferimento anche dell’estensione .it: insomma, una transumanza totale. Indovina il risultato: richiesta ignorata, silenzio di tomba.

A questo punto, le opzioni possibili sono sostanzialmente quattro: 1) fare buon viso a cattivo gioco e rinunciare al trasferimento; 2) continuare a scrivere a Wide per chiedere che rispettino le procedure internazionali senza fare i furbi; 3) dare retta a ICANN e chiedere l’assistenza del nuovo provider affinchè risolva l’impasse; 4) incazzarsi come una iena, far visita alla Guardia di Finanza e sporgere denuncia.

Considerato che Casperize.com sarebbe un blog, ho deciso di fare di necessità virtù e di provare a seguire passo-passo tutte le procedure previste, alla lettera, documentandole per i posteri. L’opzione scelta è quindi la terza: obbedire a ICANN, morsicarsi la lingua e invocare l’intervento del nuovo provider. Già, perchè la prassi di “assistenza” di Wide non prevede nè comunicazioni email nè numeri di telefono da contattare per risolvere i problemi: si compila un modulo online e si aspetta. Se risulta una richiesta senza risposta, semplicemente non è permesso inoltrare ulteriori solleciti. Come dicevo, si aspetta. Che cosa, non è dato sapere: probabilmente, nient’altro che i loro comodi.

E dunque sediamo sulla riva del fiume e aspettiamo, finchè la procedura non sarà completa, allorchè passeremo puntualmente dall’ICANN alle materne mani della Procura della Repubblica.

Sempre che questa pagina non sparisca improvvisamente per qualche malaugurato incidente tecnico, caro visitatore, ti terrò puntualmente informato del calvario. Quando Casperize.com tornerà finalmente online sui server di Aruba (e tornerà online, puoi giocarci le tue mutande migliori), queste righe diventeranno un post che sarà un piacere e un onore tenere in massima evidenza per fare un po di pubblicità gratuita a Wide, che se la merita senza riserve. Nel frattempo, se per tua disgrazia sei cliente di questa gente, fossi in te comincerei a preoccuparmi. Se stavi considerando la possibilità di sottoscrivere uno qualsiasi dei loro “servizi”, fossi in te ci ripenserei.

Benvenuto in Italia, la più evoluta colonia dell’Africa Nera. Terra di santi, navigatori, eroi, dottori, commendatori, mafiosi, buffoni, cacciaballe e professionisti della domenica. Là dove tutti fanno ciò che cazzo vogliono, che tanto la si passa liscia alla grande. Torna a trovarmi, che c’è da divertirsi.

E se magari sei anche un blogger, hai un vuoto di creatività e ti manca lo spunto per il post del giorno, che ne diresti di due righe di incoraggiamento in pubblico per gli amici di Wide e il loro eccellente servizio? Quel genere di pubblicità che toglie la pelle di dosso, per intenderci. Quella che si riserva solo ai migliori. Sono certo che la apprezzeranno.

Se vuoi contattarmi, non fare complimenti

Aggiornamenti:

3 Maggio – Richiesto intervento del nuovo provider come previsto dalla policy ICANN

Della serie un tranquillo sabato pomeriggio

Ore 14: un SMS sul cellulare e una e-mail mi avvisano di problemi sul forum di eXtenZilla. Questa è la triste immagine che mi trovo di fronte

Mi viene il dubbio che, per qualche strano motivo, sia stata ripristinata una versione molto vecchia del database. Prima di procedere con il ripristino dell’ultimo backup disponibile (risale ad appena 3 ore prima, Dio salvi DreamHost e i backup automatici), decido di provare la strada suggerita dal maledetto messaggio di errore: scarico un pacchetto di update di SMF, carico sul server il file upgrade.php e lo eseguo.
Risultato: una scarica di errori e forum ancora down.

In realtà la situazione è leggermente peggiorata: il file upgrade.php imposta la modalità di manutenzione del forum SMF al livello più alto e non è più possibile accedere al pannello di amministrazione. Per rendere nuovamente visibile il forum bisogna modificare il file settings.php e impostare la variabile

$maintenance = 1;

A questo punto decido per il ripristino del backup: fortunatamente con DreamHost è possibile scegliere un ripristino non distruttivo (nel mio caso ho scelto la busta numero 3)

Backup ripristinato, il forum continua a mantenere quello schifoso messaggio di errore.

Provo ad accedere al database con phpMyAdmin e mi ritrovo davanti lo stesso errore nell’accedere alla struttura delle tabelle (il contenuto viene visualizzato correttamente): Got error 28 from storage engine.

A questo punto comincio a dubitare del server MySQL e, grazie a Google, scopro che questo errore è dovuto a problemi di spazio esaurito sul server (/tmp piena).
Per prima cosa contatto l’assistenza DreamHost e segnalo il problema, poi provvedo a rinominare le tabelle aggiornate: purtroppo in phpMyAdmin non è possibile farlo direttamente e tocca lavorare di SQL

RENAME TABLE nome_tabella TO nuovo_nome_tabella

Nel giro di una mezz’ora il forum è tornato visibile.

Sorry about that, it appears that someone filled up /tmp directory on the database server, this was a result of a bad query that had been made.

Sarà perché ho usato questa priorità nella richiesta di assistenza?

Provate a leggere quanto scritto da Camaran sul suo forum (scoperto stamattina attraverso il blog di oRi0n). In passato ho ampiamente criticato l’atteggiamento di Camaran su ProZone durante il down di febbraio e la sua scelta di diventare moderatore del forum di Excom (e continuo a pensarla nello stesso modo); ciononostante ritengo che questo cambiamento di rotta, sebbene tardivo, sia decisamente apprezzabile.

La “struttura tecnica” (foto e galleria completa)

I servizi della Extreme communications sono erogati attraverso PC compatibili da 1Ghz di processore con, al massimo, 1 GB di RAM.
Tutti i PC sono ormai saturi al 100% e andrebbero aggiornati con nuove macchine per continuare a garantire il servizio in modo corretto e funzionale, basti pensare che il PC di posta elettronica con 120 e-mail in coda si blocca e va riavviato ogni 5 minuti.
I PC che erogano i servizi Windows 2003 hanno tutti il sistema operativo craccato e non concesso in licenza e sugli stessi vengono attivati i virtual server linux su un istanza di Microsoft Virtual PC.

La vera spiegazione del down di febbraio, simile a quella ricevuta a suo tempo da altre fonti

Il lungo down di febbraio sembra essere stato causato dal fatto che i PC erano collegati alla rete di Retelit abusivamente in quanto alla Extreme era affidata esclusivamente la gestione del tetto per il controllo di alcune antenne Wi-Fi che dovevano servire per un progetto nel viterbese.
Retelit quando si è accorta della situazione, anche grazie al cambio del CDA che non l’ha più tollerata, ha da prima ridotto la banda disponibile e poi staccato direttamente i PC chiedendo anche il risarcimento di 32000 EUR per il traffico generato in modo abusivo.
Proprio per questo i PC sono rimasti nel datacenter per qualche giorno senza essere recuperabili dalla extreme che ora risulta in un piano di rientro per il pagamento di queste fatture.

Con questo post saluto definitivamente Excom, visto che anche il secondo dei miei domini ha traslocato oltreoceano; ho già avuto modo di scrivere ampiamente sulla mia storia personale con Excom, per cui questo sarà un post dedicato a riflessioni e consigli.

Nei 10 mesi trascorsi sull’hosting di Excom, con 2 piani Advanced Linux Server, ho avuto modo di sperimentare:

• un numero imprecisato di down, di lunghezza e durata assortita, e qualche piccola disfunzione (tipicamente spazio su disco finito con conseguente blog a pallino)
• la morte del mail server con perdita dell’archivio messaggi e configurazione degli account
• problemi di prestazioni con il server mySql (risolte inizialmente passando mySql su un server stand-alone)
• un blackout totale di un paio di settimane
• il crash&down del server mySql con danneggiamento dei dati (nel caso di eXtenZilla molto limitato)

L’unica cosa che ha sempre funzionato bene (nel mio caso) è stata l’assistenza via trouble ticket.

Come promesso passo alle riflessioni.

ESPERIENZA: siete un’azienda giovane, forse troppo (ma questo l’ho scoperto tardi, mea culpa): un minimo di esperienza avrebbe suggerito di correre ai ripari (in gergo tecnico “pararsi il culo”) subito dopo il problema con il mail server (backup, mirror hardware o software, un esorcista), invece è evidente che il primo danno non ha insegnato nulla.

SITO WEB: alcune informazioni presenti sul sito Internet non rispondono a verità. Potrei sbagliarmi ma il servizio di backup giornaliero non ha mai funzionato (quantomeno durante il mio periodo di permanenza su Excom): visto il costo dell’hosting non è una vergogna non offrire un servizio di backup, lo è attirare clienti pubblicizzando un servizio inesistente.

FORUM: durante il periodo di buio avevo già dato a Gianluca Varisco il mio consiglio personale: chiudete il forum e limitate l’assistenza ai ticket, così com’è il forum è un inutile punto di ritrovo di ragazzini idioti. Evidentemente era un consiglio del cavolo, visto che avete deciso di ristrutturare il forum; non contenti avete deciso di aprirlo agli off-topic e trovare dei moderatori.
Ora… io non ho esperienza in materia di hosting ma in materia di forum e moderazione qualcosina la so: i moderatori si scelgono per tutta una serie di capacità, tecniche ed umane, non perché ne fanno richiesta. Attualmente avete sul forum almeno due moderatori: uno si è fatto portavoce dell’azienda durante il periodo di down in un modo che io non condivido (usando un eufemismo), l’altro è spuntato fuori dal nulla ed inserisce simili post intelligenti.
Altra cosa che non è chiara è se questi moderatori stiano lavorando per la gloria: non sono fatti miei per cui non pretendo una risposta, ma visto che Excom è un’azienda e non un ente caritatevole sarei curioso di saperlo.
In ogni caso: contenti voi, contenti tutti

TRASPARENZA: questo è il vero punto dolente di tutta la storia. Passi che vi stiate facendo esperienza sulle ossa dei clienti, ma non è bello essere pure presi per il deretano. Allo stato attuale io (cliente pagante) non so cosa sia successo nel vecchio datacenter per costingervi a spostare i server in fretta e furia, nè tantomeno cosa sia successo al server mySql: mi spiace scriverlo ma i due comunicati ufficiali lasciano il tempo che trovano.

Prendiamo il caso del server mySql: il server andava, con qualche calo di prestazione ma nessun problema sui dati (non ho letto nulla in proposito sul forum prima del down); stavate facendo un intervento di manutenzione programmata ed il disco (a quanto pare il solo disco) decide di saltare, corrompe dati che fino ad un quarto d’ora prima erano buoni e vi costringe a ricorrere ad una ditta esterna di recupero dati? Ripeto: non mi occupo di hosting, ma mi sembra una spiegazione al limite dell’inverosimile.

In seguito ai tre episodi più gravi (mail server, mega blackout, mySql server) avete offerto ai clienti esistenti nuovi piani di hosting o il rinnovo del piano esistente. Gentilmente, mi spiegate cosa me ne faccio di un altro anno oppure di un altro sito su un hosting che mi fa vivere con il patema d’animo? Forse è il caso di intervenire alla radice e risolvere i problemi, non fare offerte riparatrici ai clienti.