Unicoda a brûlé !

Amis lecteurs bonsoir !

Étrange journée que cette journée du 10 mars 2021, car, s’il y a bien un risque qu’on envisage pas immédiatement pour son serveur, lorsqu’on fait la liste des périls qui le guettent, c’est celui de l’incendie. Eh oui, en ce mercredi 10 mars 2021, Unicoda, où plutôt son serveur de résidence, est parti en fumée avec le reste des serveurs et des sites hébergés dans le datacenter SBG2 d’OVH à Strasbourg.

Pour Unicoda, plus de peur que de mal, puisque si vous lisez ces lignes, c’est que nous sommes (déjà) de retour. C’est bien sûr un événement dont tout le monde se passerait. J’ai pu voir quelques annonces de données irrémédiablement perdues, par exemple, du côté des serveurs du jeu Rust. Un événement qui démontre encore une fois, l’importance des sauvegardes, et que, même en environnement contrôlé, personne n’est à l’abri.

Voici donc un petit retour pour décrire la façon dont nous avons réagi à cet incident.

Tout commence ce matin vers 10h, lorsque mon frère Mathieu m’appelle au téléphone, en me demandant où est hébergé Unicoda dans les infrastructures OVH. Il continue en m’annonçant qu’il vient de lire qu’un incendie s’est déclaré dans le datacenter SBG2, que tout SBG est à l’arrêt et que Unicoda ne répond plus. Je lui confirme qu’Unicoda est bien hébergé à Strasbourg dans SBG2 et vérifie rapidement la connexion au serveur (en échec bien sûr). Vérification dans mes mails, pas de rapport journalier de sauvegarde ce matin, le feu s’étant déclaré peu avant le processus de sauvegarde automatique.

Je prends ensuite un peu de temps pour réfléchir. Je suis à 80% sûr qu’Unicoda était hébergé dans SBG2, rien dans la console d’administration d’OVH ne permet de valider l’information, rien sur les factures. Le rapport de sauvegarde du 9 mars indique qu’il s’est terminé avec succès. Enfin, SBG est à l’arrêt pour plusieurs jours, voir semaine, il faut donc préparer le redéploiement d’Unicoda sur un nouveau serveur. Profitant d’une pause dans ma matinée de travail, je commande donc un nouveau VPS OVH dans le datacenter de Gravelines.

Arrive le temps de la pause méridienne. Le VPS n’étant toujours pas disponible, je commande un VPS chez Hetzner en Allemagne, VPS facturé à l’heure avec un plafond mensuel, extrêmement pratique pour effectuer des tests de courtes durées. Livraison en moins d’une minute. J’ouvre le dépôt contenant mon script de déploiement automatisé ansible, change les DNS pour pointer vers la nouvelle machine et démarre l’exécution. Quelques erreurs du fait d’une réorganisation récente de l’ensemble de mes rôles ansible (et dont les tests devaient avoir lieu dans les prochains mois) interrompront deux fois la réinstallation. Au troisième essai, après quelques dizaines de minutes, Unicoda est à nouveau accessible.

Quels enseignements retenir de cet incident ?

Comme énoncé déjà ici: sauvegarder, sauvegarder et sauvegarder !! Je suis une nouvelle fois très satisfait par la solution de sauvegarde et de déploiement automatique que j’ai mise en place pour Unicoda et qui est le résultat de plusieurs années d’améliorations. Néanmoins, il serait bon d’ajouter un deuxième emplacement distant de stockage des sauvegardes. En effet, si par un hasard extraordinaire, un problème similaire était arrivé au datacenter stockant la sauvegarde chiffrée, c’eût été retour à la sauvegarde enregistrée sur mon poste local et pouvant parfois remonter à plusieurs semaines. Un emplacement distant pour les sauvegardes, c’est bien, deux, c’est mieux.

Deuxième point à noter, en cas de réorganisation complexe des scripts de déploiement automatique, il aurait été utile de conserver une copie du dépôt avant réorganisation, lorsque les scripts fonctionnaient sans erreurs et avait été testé. Ainsi, on s’évite quelques corrections en état de stress et pressé par le temps. Cela est bien entendu variable en fonction du service affecté, dans le cas d’Unicoda, je ne suis pas à la minute près, bien que j’apprécie d’avoir le moins de temps d’indisponibilité possible.

Enfin, j’ai apporté des modifications sur le Time To Live (TLL) du champ A des DNS d’Unicoda, entrée DNS responsable de la redirection vers le serveur. J’avais jusqu’à présent laissé ce champ à la valeur par défaut dans l’interface à savoir 86400 secondes soit 1 jour. Si cela ne pose guère de problèmes dans le cas d’une migration programmée, où l’ancien serveur continue de fonctionner quelques jours, c’est plus embêtant dans le cas d’un incident comme celui d’aujourd’hui, où on voudra que la modification DNS soit propagée le plus rapidement possible une fois le serveur de remplacement opérationnel. J’ai donc choisi une valeur de 7200 secondes (2 heures) de TTL, ce qui me semble être un bon compromis.

En conclusion, Unicoda s’en sort bien, plus de peur que de mal. On a beau avoir un processus de sauvegarde, des scripts de déploiement automatique, un léger doute subsiste toujours. Cet incident a permis de vérifier, en dehors d’un événement programmé, que les processus mis en place fonctionnent: une très bonne chose. Il me reste à vérifier dans les prochains jours que la sauvegarde s’effectue correctement sur ce nouveau serveur et, dans les prochaines semaines, à migrer une nouvelle fois Unicoda pour un retour chez OVH. A tous mes camarades informaticiens ayant perdu un serveur dans cet incendie: courage !

P.S. Pour suivre l’avancement de la remise en service, voici les tickets liés à l’incident:

Si nut ne détecte pas l’onduleur

En redémarrant mon Pi connecté à l’onduleur, après avoir éteint l’onduleur et le Pi, débranché câbles et alimentations, et déplacé les deux appareils, j’ai constaté à plusieurs reprises que l’onduleur n’était pas détecté après un redémarrage du système.

Je n’ai pour l’instant pas trouvé de meilleur solution que de redémarrer manuellement les services nut-monitor et nut-server, ce qui suffit à résoudre le problème.

$ sudo service nut-monitor status
$ sudo service nut-monitor restart
$ sudo service nut-server status
$ sudo service nut-server start

Par ailleurs, en écrivant ces lignes, je me rends compte que cela pourrait provenir de l’ordre de branchement des câbles, avec un branchement du câble de connexion à l’onduleur, qui arriverait après la tentative d’initialisation des services, car généralement, l’extinction de la machine liée à l’onduleur s’accompagne d’un déplacement de cette dernière et donc d’un débranchement de tous les câbles connectés.

En tous cas, si vous avez trouvé une solution à un problème similaire, n’hésitez pas à la partager, sinon, la solution manuelle est placée ci-dessus pour référence.

Note: Suite à une migration récente, nut-monitor n’est pas installé et tout semble fonctionner. Redémarrer nut-server devrait donc suffire, ou à défaut, nut-client dans le cas d’une machine cliente.

Réalisation d’une vidéo promotionnelle pour mon jeu Bulldozer

Bande annonce du jeu Bulldozer sur lequel je travaille sur mon temps libre depuis maintenant 2 ans

Aujourd’hui je vous partage ma dernière réalisation. C’est une vidéo d’une minute qui présente le jeu Bulldozer sur lequel je travaille depuis maintenant 2 ans. J’aime apprendre de nouvelles choses et essayer d’aller toujours plus loin dans mes réalisations. J’ai donc consacré pas moins de deux mois à la réalisation de cette vidéo, mettant entre parenthèse toutes mes autres activités (tutoriels, articles, et même un peu l’activité physique).

Le premier mois j’ai suivi la formation « Blender Launch Pad » de Zach Reinhardt sur le site CGBoost, dont vous retrouverez les codes dans ma propre réalisation. Cette formation m’a permis de revoir les bases de Blender et découvrir de petite choses que je ne savais pas encore. La formation m’a aussi permis de me mettre à l’animation, domaine que je n’avais jamais trop creusé non par envie mais parce que je n’avais pas de machine assez puissante pour en réaliser jusqu’à présent.

Lors du second mois j’ai du faire le rendu étape par étape ainsi que le montage de la vidéo et la réalisation de la bande son. Ma première idée était de créer le son par moi même… mais comme je n’ai pas de connaissances spécifiques dans le domaine ça a été un cuisant échec.

Je me suis alors posé la question de faire appel à un professionnel, le rémunérer en échange d’une bande son qui collerait à mes besoins. Mais après avoir parcourus des plateformes de mise en relation avec des indépendants je me suis vite remotivé. L’équation a été vite posée, entre le temps que je passais à chercher un profil qui me conviendrait et l’argent que je devrais dépenser alors que mon projet reste amateur j’ai eu mieux fait de me consacrer à la recherche d’une alternative gratuite et facile d’utilisation pour la réalisation de la bande son.

C’est à ce moment là que j’ai découvert BandLab, une alternative en ligne et gratuite pour créer et partager de la musique et qui possède une bibliothèque de sons suffisamment intéressante pour arriver à mes fins. Après quelques grosses soirées à faire, défaire et refaire ma bande son j’y suis arrivé ! Le seul point que j’améliorerais à BandLab dans ma situation serait de pouvoir ajouter un flux vidéo qui pourrait se jouer de manière synchronisée avec la musique pour pouvoir voir le résultat sans avoir à faire des aller-retours avec mon logiciel de montage vidéo.

Voilà pour la petite histoire, je vous laisse apprécier, commenter, aimer, partager ma vidéo, la voir et la revoir.

Et pour ceux qui veulent jouer au jeu c’est sur le Google Play : Bulldozer

Supprimer le dépôt vscode de Microsoft du Raspberry Pi

Début février, un nouveau dépôt est arrivé automatiquement dans l’OS du Raspberry Pi. A chaque déclenchement d’une vérification des mises à jour, une requête part donc vers les serveurs de Microsoft. Tout cela, pour être en mesure d’installer vscode sur votre Pi. Je ne m’étendrai pas sur le sujet du binaire non libre distribué pour un vscode dit « open source », ou encore de la télémétrie activée par défaut.

Allons à l’essentiel, si comme moi, vos Raspberry Pi fonctionnent en mode serveur et que vous souhaitez vous débarrasser de cet ajout inopportun, voici les commandes à exécuter:

sudo rm /etc/apt/sources.list.d/vscode.list
sudo rm /etc/apt/trusted.gpg.d/microsoft.gpg
sudo apt update

Source: Is Microsoft Spying on your Raspberry Pi?