bug

Frequenti 404 sulle puntate: un post-mortem

“Finalmente” ho l’occasione di scrivere anch’io un post-mortem, quei post che le grandi aziende della tecnologia scrivono per spiegare i motivi di qualche problema che ha causato disagi agli utenti. Gli esempi sono molti. Premessa: da molti mesi a questa parte EasyPodcast si appoggia a due server: il principale, che esegue il CMS, ospita i file mp3 per il download e mille altre cose, e un secondario che è semplicemente un mirror dei file mp3, per aumentare la banda disponibile e distribuire il carico. I sintomi Dal giorno del lancio del nuovo CMS si sono verificati diversi errori 404 durante il download delle puntate dal server secondario. La cosa strana è che questi errori avvenivano sempre tra un’ora con minuto multiplo di 5 e il successivo minuto. Ad esempio dalle 9:35 alle 9:36, dalle 20:10 alle 20:11, ecc. Nei restanti minuti, nessun problema. Cosa è successo In occasione del passaggio al nuovo CMS, abbiamo cambiato il server principale, passando da un VPS presso OVH a un server dedicato presso Online.net. Il vecchio server era configurato per sincronizzare (tramite rsync) la cartella contenente gli mp3 sul server secondario ogni 5 minuti, mentre il nuovo è stato configurato per fare tale sincronizzazione ogni minuto. Questo è dovuto al fatto che il metodo di caricamento precedente delle puntate era basato su Dropbox (in esecuzione sul server) e incron (una sorta di Hazel per Linux), che appena riceveva un file da noi lo metteva nella cartella corretta e lo copiava sul server secondario, quindi non era necessario essere molto aggressivi con la sincronizzazione “di sicurezza” con rsync. Viceversa, con il nuovo CMS l’upload avviene direttamente tramite il CMS, che però non prevede la copia su server secondari: di quello si occupa rsync, da cui la necessità di eseguirlo molto più frequentemente. OVH, alla scadenza del server (che non ho esplicitamente cancellato, per lasciarmi il massimo tempo possibile in caso dovessi recuperare qualche file che avessi dimenticato), non l’ha spento e cancellato: ha semplicemente bloccato le connessioni in ingresso, ma non quelle in uscita: il risultato è stato che il server si connetteva regolarmente al secondario per copiare i file, e grazie all’opzione –delete che avevo abilitato andava a cancellare i file mancanti su di lui ma presenti sul secondario, tra cui chiaramente le nuove puntate, che non sono mai arrivate sul vecchio server. Quindi, ciclicamente ogni 5 minuti: Minuto 0: il server nuovo sincronizzava i file in un attimo: nulla da caricare. Un attimo dopo arrivava il vecchio server che cancellava i nuovi file. Minuto 1: il server nuovo sincronizzava i file cancellati dal vecchio il minuto precedente. Minuto 2: il server nuovo sincronizzava i file in un attimo: nulla da caricare. Minuto 3: il server nuovo sincronizzava i file in un attimo: nulla da caricare. Minuto 4: il server nuovo sincronizzava i file in un attimo: nulla da caricare. Le cause Riassumendo le cause del problema sono state tre: 1. Ho dimenticato in esecuzione rsync ogni 5 minuti sul server vecchio. 2. OVH non ha spento/cancellato il vecchio server, l’ha solo reso inaccessibile dall’esterno. 3. Ho dimenticato di rimuovere la chiave SSH del vecchio server dal server secondario, consentendo quindi a rsync di connettersi e di cancellare i file. Soluzione Ho rimosso la chiave del vecchio server da quelle autorizzate sul secondario. Ho contattato OVH e li ho informati del problema. Ho anche fatto una ulteriore verifica su entrambi i server, per assicurarmi che non ci fossero altre chiavi SSH dimenticate/inutili.

iTunes 10.5.1: addio sincronizzazioni infinite

Sia io, sia Luca, nelle ultime puntate vi avevamo parlato di un fastidiosissimo bug, che non permetteva ad iTunes di terminare correttamente il processo di sincronizzazione con i nostri iPhone 4. Finalmente possiamo annunciare che, per il momento, questo problema è stato risolto con l’ultimo aggiornamento di iTunes, che si è portato alla versione 10.5.1!

biteSMS mostra costantemente un messaggio non letto, come risolvere

Oggi ho avuto un problema con biteSMS (uso sempre l’ultima versione beta, quindi poteva accadere): rimaneva costantemente un messaggio non letto, anche se non appariva da nessuna parte. Sembrava essere in una conversazione con Federico (che è notoriamente causa di problemi), ma non appariva da nessuna parte. Ecco come risolvere. È necessario eseguire un semplice comando da terminale, quindi vi conviene avere MobileTerminal installato sul vostro dispositivo, oppure eseguire il comando via SSH (come utente mobile).  Di seguito trovate le due procedure da eseguire.