(sconsigliato per via della mia esperienza personale, che racconto, poi ognuno è ovviamente libero di postare la sua positiva.)
Riassuntino:
29 giugno 2006 fuzzy firewall a Masterweb, in cui discutiamo del servizio di monitoraggio dell’uptime che usavo allora e consiglio Masterweb solo per siti personali.
10 ottobre 2006 Del perché Masterweb/Aruba non è consigliabile, in cui dico perché non lo consiglio più nemmeno per siti personali.
23 ottobre 2006 mi ha chiamato Masterweb, in cui dico che mi hanno chiamato cercando di capire il mio malcontento.
Tanto per fugare subito ogni dubbio: no, dopo non mi hanno mai più chiamato, anzi io ho descritto un altro paio di volte i prosiegui delle vicende, senza riscontro.
Ora, con un po’ di documentazione raccolta, parliamo dei FATTI.
Il 20 Luglio Andrea Beggi mi avverte che il mio blog è irraggiungibile. Lo ringrazio ma ovviamente ne sono a conoscenza, poiché sono un felice utilizzatore di site24x7, da cui sono tratte le schermate che vederemo. Il blog in realtà è raggiungibile, non ritorna un 404, ma mostra una pagina bianca. Dopo due prove con file HTML e immagini, capisco che il problema è il php, quindi apro il ticket
IN DATA: 2007-07-20 14:16:09
TAMBUWEB SCRIVE:
il mio sottodominio pare abbia smesso di interpretare il php. restituisce pagine bianche a qualsiasi richiesta. l’unica pagina che funziona è la pagina di test e il redirect dalla root di tambuweb.it
non può essere un problema del CMS, poiché all’indirizzo http://www.tambuweb.it/drupal/ avevo installato più di un anno fa un altro CMS di prova, diverso, e non funziona nemmeno quello.
siccome il tempo passava e nessuno rispondeva ho anche telefonato. A loro sembrava tutto a posto, ma si riservavano ulteriori controlli. Appena arrivo a casa inizio a smanettare coi plugin, e trovo parziale soluzione disattivando WP-hashcash. Nel mentre mi chiamano al cellulare dicendo che effettivamente c’era un problema di limiti di qualche tipo e che l’hanno risolto. Faccio due googlate e arriviamo a questa situazione
TAMBUWEB SCRIVE:
magari interessa
http://bugs.php.net/bug.php?id=41932
TAMBUWEB SCRIVE:
ho risolto la situazione temporaneamente. se lasciate aperto questo ticket e mi fate fare un po’ di analisi, probabilmente vi dico dove è il bug in php
loro gentilmente mi lasciano aperto il ticket, e io proseguo nelle mie ricerche, senza frutto. Un po’ mi pare di capire, un po’ mi pare di essere fuori strada. Alcune cose che leggo in rete quadrano, altri comportamenti del blog mi sembrano inspiegabili. Intanto però Akismet smette di funzionare, perché non è in grado di verificare l’API key. Non so quanti di voi abbiano mai visto il messaggio
The key below was previously validated but a connection to akismet.com can not be established at this time. Please check your server configuration.
o il più inquietante
The key you entered could not be verified because a connection to akismet.com could not be established. Please check your server configuration.
(by the way la soluzione è scrivere direttamente la key dentro al file akismet.php, precisamente qui
// If you hardcode a WP.com API key here, all key config screens will be hidden
$wpcom_api_key = ”; )
Praticamente il server non era in grado di collegarsi all’esterno, al che scrivo
IN DATA: 2007-07-20 17:52:10
TAMBUWEB SCRIVE:
rilevo l’impossibilità da parte di php a collegarsi all’esterno.
IN DATA: 2007-07-20 18:33:20
TAMBUWEB SCRIVE:
ok, ora si collega.
la mia nota conclusiva è che non ne so abbastanza di php da capire. fsockopen a quanto pare è una pista sbagliata. il file che dà fastidio (ma che ha funzionato dalla settimana scorsa fino a oggi) è il php dentro a
/subdomains/blog/httpdocs/wp-content/plugins/wp-hashcash/
lo lascio lì se volete guardarlo, ma tanto non posso attivarlo. E’ però un file utile al sistema (è un antispam), se capiste mi fareste un grosso favore.
IN DATA: 2007-07-20 18:44:18
TAMBUWEB SCRIVE:
no, c’è sempre qualcosa che non va. anche un altro semplice plugin che fa uso di GDlib si schianta…
IN DATA: 2007-07-20 21:28:44
TAMBUWEB SCRIVE:
insomma, qua è un casino. E’ assolutamente evidente che qualcosa avete toccato voi, tra stamattina e il primo pomeriggio, perché prima tutto filava liscio come l’olio.
La mia richiesta è che ovviamente ripristiniate la situazione precedente.
IN DATA: 2007-07-21 21:45:03
TAMBUWEB SCRIVE:
il fattore comune, però, mi sembra sempre essere fsockopen(). Un altro plugin ancora mi dà “unable to open sock”.
In qualche modo però riesco a proseguire l’attività di blogging, sebbene qualsiasi operazione richieda un tempo abominevole. Anche i commenti dei lettori impiegano 2 minuti per essere inseriti, per non parlare del fatto che l’autosave dei post si schiantava con un errore tragico. Dopo due giorni chiedo
IN DATA: 2007-07-23 16:29:18
TAMBUWEB SCRIVE:
ci sono novità? la pubblicazione e la modifica di nuovi articoli o commenti è lentissima, per me la questione è ancora aperta.
e mi viene risposto che la macchina è a posto, che il problema dell’ulimit è stato corretto, che dai log di apache non risulta niente, che non ci sono carichi di lavoro eccessivi su cpu o ram. devo dettagliare meglio. Per me è un piacere dettagliare, se posso aiutare qualcuno a risolvere i MIEI problemi.
IN DATA: 2007-07-24 13:34:09
TAMBUWEB SCRIVE:
“The key you entered could not be verified because a connection to akismet.com could not be established. Please check your server configuration.”
questa connessione funzionava fino a venerdì mattina.
la pubblicazione o la modifica di nuovi contenuti richiede un tempo superiore ai 100 secondi, quando non due minuti. idem l’inserimento di commenti da parte di terzi.
in generale mi pare che qualsiasi connessione a siti esterni (a livello di php, quindi pingback, trackback, xml-rpc, sock, ecc) non funzioni
IN DATA: 2007-07-24 15:35:42
TAMBUWEB SCRIVE:
la funzione di autosave della composizione dei nuovi contenuti (presumo sia in wp-includesjsautosave.js) va quasi sempre in errore “undefined”
e la risposta è che la connessione ai siti esterni è chiaramente più lenta che in locale (ma in realtà qui non avviene affatto), che nessun altro si è lamentato (ma io che uso IPNeighbors per sapere con chi condivido il server immagino anche perché: sono quasi tutti siti in html) e di fornire istruzioni per ricreare il problema.
IN DATA: 2007-07-25 10:54:47
TAMBUWEB SCRIVE:
mi pare che siamo a uno stallo. io incolpo la macchina o la configurazione, forte del fatto che non ho toccato il codice ma la situazione è peggiorata, voi incolpate il codice forti del fatto che sono l’unico che si lamenta.
per riprodurre il problema dal lato admin dovrei fornirle la password, e non se ne parla. può comunque visitare il mio blog, magari qui
Mi ha chiamato Masterweb
e provare a lasciare un commento, rilevando la sconcertante lentezza ad effettuare l’inserimento, cosa che in situazione normale richiede non più di 3 o 4 secondi.
E il ticket si chiude qui, motivazione: “non collaboro” e il server è a posto.
Il server è a posto davvero, ora. Piano piano (si parla di settimane) le cose sono tornate a posto, akismet si ricollega, l’autosave funziona e voi potete commentare in un tempo ragionevole. Se lo hanno messo a posto loro, non mi hanno chiamato per dirmelo, se è andato a posto da solo è ancora più sconcertante, perché significa che non c’è il controllo totale sulle macchine. Comunque la configurazione sarebbe a posto, secondo Masterweb. Bene, dopo pochi giorni mi manda una mail Botty e mi avvisa che facendo una ricerca per “l’acqua” nel box di ricerca, il blog si schianta.
(notate l’url)
Perbacco! – mi dico – vuoi dire che wordpress è così newbie da non escapare l’apostrofo? o forse è colpa del tema? sai che faccio? taglio la testa al toro, tanto ho un dominio su Webperte dove avevo pensato, forse, di trasferire il blog. Ci copio tutto per prova e ritento. Detto fatto:
Problema assente. Quindi? quindi io che ne capisco poco, dico che è un problema della macchina. punto.
Ma parliamo anche un po’ di stellinorama.it, che ho provveduto a trasferire giust’appunto su Webperte il 31 luglio. Eccovi la lista imbarazzante dei down rilevati da site24x7.com nella settimana tra il 23 e il 30 luglio:
e la relativa torta di uptime, con tempi di risposta:
Il report intero di un altro nostro sito, sullo stesso server, in un’altra settimana a caso del mese di agosto. Questo sito è ancora lì:
E un report di disponibilità dal primo luglio al 31 agosto:
(questo è da cliccare)
in rosso i down. Che altro dire?
Oggi è il 24 agosto e questo post è drammaticamente postdatato, ma solo perché il