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:

  1. 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.
  2. Minuto 1: il server nuovo sincronizzava i file cancellati dal vecchio il minuto precedente.
  3. Minuto 2: il server nuovo sincronizzava i file in un attimo: nulla da caricare.
  4. Minuto 3: il server nuovo sincronizzava i file in un attimo: nulla da caricare.
  5. 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

  1. Ho rimosso la chiave del vecchio server da quelle autorizzate sul secondario.
  2. 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.