Ovvero:  i paroloni dell’IT demistificati.

Avete invitato a cena il/la ganzo/a, cucinato una teglia di splendide lasagne per prenderlo/a per la gola e pregustate una serata indimenticabile. Durante l’aperitivo vi accorgete che, per cause indipendenti dalla vostra volontà e fuori dal vostro controllo, le lasagne non sono più commestibili. Ad esempio le ha mangiate il gatto, o il forno si è rotto e le ha bruciate.

La vostra proverbiale sagacia vi viene in aiuto: tirate fuori dal frigo un pacco di spaghetti pronti congelati e  scongiurate il disastro. Il/la ganzo/a era già pronto/a ad andare a mangiare da un’altra parte, magari senza di voi. Avete ottenuto il vostro scopo, sebbene tramite risorse non ottimali.

Se voi foste un router, un controller o un cluster, quello che avete appena fatto si chiamerebbe failover.

Ma andiamo avanti. Appena iniziati gli spaghetti precotti, sentite suonare alla porta: è vostra madre che vi ha portato una teglia delle sue leggendarie lasagne. Con la velocità di un furetto congedate la genitrice e sfilate da sotto il naso del/la allibito/a ganzo/a il piatto industriale sostituendolo con il manicaretto. La cena è salva e siete ritornati al menu previsto, che vi assicura un proseguimento degno delle vostre aspettative.

Se voi foste sempre uno dei sistemi di cui sopra, avreste appena fatto un failback, anzi, un preempt and failback. Appena la risorsa originale e qualitativamente superiore è  stata nuovamente disponibile, ne avete approfittato per ripristinare lo stato ottimale senza aspettare che la risorsa sostitutiva si esaurisse.

I sistemi di failover si applicano solitamente a connessioni, servizi e storage e servono ad assicurare la alta affidabilità di sistemi critici. Tipici esempi possono essere: connessioni multiple collegate ad uno stesso firewall che gestisca il load balancing,  controller ridondanti per sistemi di storage SAN, per evitare di avere un “single point of failure”, diversi server collegati in un cluster che assicurano la continuità di un servizio anche in caso di caduta della macchina che lo eroga. Non necessariamente la risorsa che subentra è meno performante, nel caso della connettività spesso lo è per motivi di rapporto costi/benefici. Il concetto sfuma spesso nella ridondanza.

E’ più complicato di così, ma la metafora spiega il senso.

Il tutto è nato da un thread di FriendFeed finito in vacca.

Ho comprato il primo numero dell’edizione italiana di Wired, l’intervista a RLM di Giordano mi è piaciuta molto, ed il pezzo di Luca Sofri è gradevole, anche se non dice nulla di nuovo per coloro che bazzicano da queste parti da un po’.

Ma più di tutto mi ha fatto riflettere il fatto che sia il primo giornale di carta che compro da, boh, saranno 2 anni. Leggere riviste su carta è scomodo, sono troppo grosse per il letto e ormai il tempo in bagno lo uso per tenermi in pari con i feed. E poi mancano i link da cliccare.

L’unica cosa che valga ancora la pena leggere su carta sono i libri, e forse lo dico solo perché non ho ancora provato un ebook reader.

La penultima versione di WordPress è la prima in cui è stato possibile utilizzare la funzione di aggiornamento automatico. Gestisco un po’ di blog di amici che posso usare come piccolo campione statistico per farmi un’idea sulla affidabilità della procedura automatica.

Su 30 blog aggiornati il giochino ha funzionato 28 volte, ma ci sono delle differenze a seconda dell’hosting che ospita il blog.

Quello che mi ha dato meno problemi è sicuramente TopHost, l’aggiornamento funziona bene e il processo è molto veloce. Non è necessaria alcuna procedura preliminare.

Su Aruba le cose vanno benino, a patto di fare una modifica preventiva al file wp-config.php. In particolare vanno aggiunte queste due righe:

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

(fonte)

Se ci si dimentica, e a me è successo in un caso, il blog non funziona più e viene restituito un “Error 500″. E’ sufficiente rimettere a posto i permessi dei file, che devono essere 755;  si può usare sia FileZilla che il pannello di controllo di Aruba, che ha la funzione apposita.

Su Webperte è necessario impostare i permessi della directory wp-content e relative sottodirectory e file a 777, se non lo fate verrà creata una wp-content/upgrade con un proprietario diverso dall’utente FTP, e sarà necessario rimuoverla tramite il file manager del pannello di controllo di Webperte. Il processo è molto lungo, ed in alcuni casi non segnala il successo dell’operazione, ma restituisce una laconica pagina bianca. Sospetto che i due insuccessi che ho registrato siano dovuti alla mia impazienza. In alcuni casi l’aggiornamento ha impiegato anche 4/5 minuti. Magari è una mia impressione sbagliata, ma mi è sembrato che una visita alla dashboard durante l’aggiornamento (nuova tab!)  “stimoli” la conclusione del processo.

C’è da dire che questo primo “live update” non tocca il database, quindi è molto meno critico, secondo me. Non mi stupirei che fosse una mossa premeditata dal team di sviluppo, tanto per tastare il terreno.

Non ho trovato differenze tra le versioni inglese e italiana.

In tutto questo, non dimenticate di fare sempre un backup del database prima di aggiornare.  In questo caso particolare basta fare un Export, tanto per sicurezza, ma nel caso di aggiornamenti che tocchino la struttura del database, è sempre meglio fare più backup del db con metodi diversi, e salvare tutti i file via FTP.

In conclusione il bilancio è positivo. Il risparmio di tempo c’è, ma non è poi così grande, visto che il backup va fatto comunque; si risparma il tempo di cancellare i vecchi file e uploadare i nuovi. Ci vuole veramente poco per perfezionare la procedura: un sistema di esportazione del db e di copia dei files da sostituire non mi sembrano particolarmente difficili da realizzare e auspico vengano introdotti in futuro.

Ho riscontrato su CA Arcserve Backup versione 12 SP1 l”errore E8535 con EC=10054,  relativo alla mancata comunicazione del backup server con un server remoto su cui è installato il Client Agent per Windows. La riga completa nello scarno log del processo recita: “E8535 Impossibile ricevere i dati dall’agente client. INDIRIZZO=x.y.w.z, EC=10054, COMANDO=0.

Apparentemente l’error code 10054 è relativo ad un timeout, ma in questo caso può essere tranquillamente escluso. Molto probabilemente si tratta di un problema di mancata comunicazione tra il client ed il server relativa al licensing: l’unico server non elencato nella lista dei client licenziati sul backup server è proprio la macchina che presenta il problema.

Dopo aver tentato diverse strade senza successo (perfino Google ne sa poco), ci siamo decisi a chiamare il supporto Computer Associates. Dopo una mezz’ora di telefonata e di tentativi infruttuosi, la soluzione è stata la seguente:

sul client con l’agent installato, navigare il registro di configurazione fino a: HKLM--> Software --> Computer Associates --> Universal Client Agent --> Options --> 1000 e cambiare il valore della chiave Executable da 1 a 0. Al termine dell’operazione riavviare il servizio Arcserve Universal Agent.

Problema risolto.

Un plauso al supporto CA che ci ha richiamato mezz’ora dopo l’apertura del ticket. Dato che Google questa volta non mi è stato di aiuto, pubblico questo post sperando che questa informazione sia utile ad altri.

Alberto mi chiede di segnalarvi IASummit, a Forlì il 20 e 21 febbraio: un evento “focalizzato sull’architettura dell’informazione con particolare attenzione alla progettazione web”.

A Parma il 20 e 21 marzo, ParmaWorkCamp: un barcamp tematico su “il lavoro, visto in diverse accezioni e collegamenti col web.” Organizza quel bel donnino di Fran. Congiunzioni astrali permettendo, tento di patecipare. Iscrivetevicisici.