Le Cloud GirofleCette semaine, le lundi 03/02/2025 et mercredi 05/02/2025, nous avons eu des coupures de mails.
Lundi entre 14h10 et 15h00, et mercredi entre 14h30 et 15h40. Les mails envoyés sur cette période sont bien partis, et les mails reçus sont arrivés avec un peu de retard.
Cela est dû à une augmentation soudaine de l’utilisation des processeurs sur notre serveur, mais nous n’avons toujours pas trouvé la cause du problème.
Nous sommes désolés pour ce souci.
Aujourd’hui (30/01/2025), nous avons eu une coupure de mails, entre 9h15 et 10h15. Les mails envoyés sur cette période sont bien partis, et les mails reçus devraient arriver aujourd’hui au plus tard.
Nous sommes désolés pour ce souci.
Hello hello,
Depuis un mois, l’équipe du Cloud Girofle réalise une transition de serveur de mail : nous reconfigurons tous les services qui envoient des mails, et mettons en place une nouvelle porte de sortie. Cela nécessite de reparamétrer des dizaines de services et de logiciels.
Dans cette opération, à deux reprises, le 23/12 et le 27/12, nous avons fait une erreur de configuration, et pendant quelques heures, l’envoi d’emails ne fonctionnait pas. Chaque mail recevait un message d’erreur :
SASL authentication failed; server chif.fr[2001:41d0:1:769d::1] said: 535 5.7.8 Error: authentication failed:
Nous avons corrigé le souci. Les messages qui ont reçu cette erreur n’ont pas été envoyés, vous devez les renvoyer.
[Ajout du 4/01/2025] Dans l’opération, nous avons fait une erreur de configuration du serveur qui héberge les forums Discourse et Mattermost : les notifications par mail n’ont pas été envoyées pendant plusieurs jours (entre le 24/12 et le 3/01, dix jours)
Nous sommes désolés pour ce souci.
Le 9 et 10 juillet derniers, nous avons souffert de 2 pannes consécutives du service mail. Le 9/07 le service a été ininterrompu pendant 4h, et le 10/07 pendant 1h.
Dans les deux cas, nous avons constaté une hausse soudaine de l’usage du CPU. Le 09/07, la charge CPU a baissé au bout d’une heure, mais le service n’est revenu que lorsque nous sommes intervenus. Le 10/07 nous sommes intervenu plus rapidement mais le problème était le même.
Après recherche dans les journaux d’erreurs (merci à Korsani et Max), nous avons pu trouver une corrélation entre des erreurs de DNS et les montées en charge. Nous en avons conclu qu’une indisponibilité des DNS que nous utilisons provoquait en chaîne des erreurs sur les conteneurs Mailcow.
Nous avons donc changé les DNS que nous utilisons afin que cela ne se reproduise plus, et nous avons mis en place un planning d’astreinte afin de s’assurer d’avoir au moins une personne présente sur les horaires de bureau.
Nous en avons profité pour améliorer notre documentation et écrit une page sur notre gestion du DNS au Cloud Girofle.
Début août nous avons mis en place une nouvelle version d’Onlyoffice (l’outil que nous utilisons pour l’édition collaborative). Nous avons tardé à mettre cette nouvelle version en place car n’inclue pas l’édition collaborative via mobile (limitation liée à la licence gratuite que nous utilisons).
Malheureusement, et nous ne savons toujours pas pourquoi, cela à entraîné la perte de service sur notre Onlyoffice existant, que nous n’avons pas réussi à remettre sur pied rapidement. Nous avons donc décidé de basculer tous les Nextcloud sur ce nouvel Onlyoffice. Nous avons mis plusieurs jours à nous rendre compte de la panne (grâce à vos retours) mais tout est finalement rentré dans l’ordre. Nous sommes désolés de la gêne que cela a pu créer.
Début août (le 8), suite à une insomnie et des moustiques, nous avions une plage horaire calme pour faire des maintenances sur nos serveurs. La cible fut le serveur nommé mutu3, qui héberge plusieurs Nextclouds, notre Onlyoffice et un Mattermost. Mutu3 n’avais pas été redémarré depuis 33 semaines (ce qui est une mauvaise pratique) et son Swap était utilisé à 100%. Nous l’avons donc redémarré, et profiter de l’occasion pour tenter de chiffrer sa partition principale (root). La manipulation a malheureusement été un échec (et nous n’avons pas d’accès IPMI sur ce serveur, donc pas de visibilié au démarrage), et nous avons dû redémarrer sur l’ancien système de fichier (non chiffré). Cette opération a pris plusieurs heures.
Résultat : mutu3 (et les services associés) était HS le 08/08 de 6h25 à 9h07 du matin.
N’hésitez pas à passer une tête notre espace de discussion Mattermost si vous souhaitez plus de détails 👍
Comme d’habitude, vous avez été très patient.e.s et tolérant.e.s et nous vous en remercions.
Même souci qu’il y a 3 semaines, la coupure a eu lieu jeudi 30/05/2024, de 0h30 à 10h00 (09h30 de coupure).
Nous sommes désolés pour la gêne occasionnée.
Même souci qu’il y a 3 semaines, la coupure a eu lieu dimanche 26/05/2024, de 0h30 à 10h20 (10h de coupure).
Nous sommes désolés pour la gêne occasionnée.
Hello hello,
Le 14 mai, Nous avons eu un souci avec des répondeurs automatiques qui ont décidé de taper la conversation à des adresses inexistantes, le tout en boucle et échangeant des centaines de messages par heure) ; bavards les robots 🤖.
Ce souci de configuration a déclenché un bannissement temporaire de notre serveur car il envoyait trop de mails. Ce bannissement a été réalisé par un de nos serveurs « relai ». Cela a bloqué l’envoi des mails entre 18h et minuit ce jour là.
Lorsque le souci nous a été remonté, nous avons supprimé le bannissement et envoyé ~300 mails qui étaient retenus. Vous pouvez avoir reçu un message d’erreur, si celui-ci indique que le mail a été rejeté, vous pouvez ré-envoyer votre message.
Nous sommes désolés pour le désagrément.
Version courte : suite à un problème d’espace disque sur un de nos serveurs (mutu2 qu’on l’appelle), la plupart des espaces Nextcloud que nous hébergeons ont été indisponibles aujourd’hui lundi 6 mai 2024, de 4h37 du matin à environ midi, soit environ 8h d’indisponibilité. Nous sommes vraiment désolé⋅es pour les soucis que cela a pu poser.
Version plus longue : un de nos serveurs historique, mutu2, qui héberge près de 90% de nos instances Nextcloud, a depuis plusieurs mois, assez peu d’espace disque libre, il ne lui restait que quelques dizaines de giga-octets disponible.
Nous avons des alertes lorsque l’espace disque devient faible, et nous en avons régulièrement discuté ces dernières semaines… Sauf que…
Quelques dizaines de giga-octets, c’est peu, mais c’est largement assez pour fonctionner, et nous n’avons pas programmé d’intervention d’urgence (à part veiller régulièrement à libérer un peu d’espace en routine).
Nous avons depuis l’été un plan pour libérer plusieurs centaines de giga-octets, que nous devons migrer sur un autre serveur, mais la mise en place du serveur a pris pas mal de temps, son redimensionnement aussi, son paramétrage aussi, la reconfiguration aussi.
Bref, la dernière brique de configuration a été mise en place hier dimanche. Il ne nous restait qu’à faire la migration pour libérer l’espace promis… Et le serveur est arrivé à court d’espace disque quelques jours trop tôt.
Hello hello,
Depuis quelques semaines, les forums Discourse étaient devenus très lents, avec notamment un message de type « erreurs 502 » ou « mises à jour en cours » qui s’affichait régulièrement.
Nous avons mis du temps à le corriger car nous avons dû déplacer un logiciel que nous pensions héberger sur la même machine que les forums.
En effet, la machine qui héberge les forums est traditionnellement assez calme et peu chargée, nous avions donc décidé d’y installer un serveur d’objets S3 : un module de stockage de données que nous utilisons pour certains espaces Nextcloud.
Nous n’avions pas anticipé que ce module occasionnerait énormément d’accès disques, qui ralentiraient énormément l’intégralité des services.
Une fois le souci diagnostiqué, il nous a fallu trouver de la place sur une machine capable d’héberger ces données, ce qui nous a pris pas mal de temps.
Le service est normalement revenu à la normale, nous sommes vraiment désolé⋅es pour les difficultés à y accéder.
Bonjour tout le monde. Avec un peu de retard, nous souhaitions communiquer sur des difficultés que nous avons eues durant le mois de janvier :
Tout a commencé au mois de décembre 2023. Nous remarquons une alerte sur un de nos serveurs, chif.fr. Cette alerte nous indique que le disque dur principal subit des erreurs de lecture.
Ce genre d’alerte est d’habitude un signe de « pre-fail » : aucune donnée n’est perdue pour l’instant, mais cela suggère que le disque est en fin de vie. chif.fr est le premier serveur que nous avions loué lorsque nous avions lancé le Cloud Girofle, en 2018. Six ans plus tard, il n’est pas absurde qu’un disque sollicité 24h/24 donne des signes de faiblesse.
Nous tentons d’en savoir plus sur l’erreur. Sur les quelques jours d’observation, le système d’alerte nous enverra une ou deux alertes supplémentaires, mais nous ne réussirons pas à la confirmer ou la préciser avec les outils d’analyse traditionnels. Nous nous demandons si c’est un faux-positf ou non.
chif.fr est le premier serveur que nous avons loué. Il a traversé notre inexpérience, nos expérimentations, et nos déboires. C’est aussi le serveur qui accumule le plus de dette technique, et qui nous demande le plus de maintenance. Nous avons également identifié depuis plus d’un an qu’il constitue un « SPOF », un single-point of failure (un élément critique du système) pour plusieurs services :
Ainsi, en cas de panne du disque, tous ces services se seraient retrouvés impactés. Par ailleurs, le disque n’étant pas redondé (pas de RAID), nous nous trouvons contraints de réaliser un changement de disque avec une interruption de service. Enfin, la machine étant hébergée chez notre prestataire Kimsufi, nous ne pouvons ni réaliser le changement de disque nous-même, ni un clone du disque, nous devrons repartir depuis nos sauvegardes. Kimsufi nous informe que le changement de disque peut être anticipé à une heure précise, et que l’opération prend une demi-heure environ.
Après prise en compte de tous ces éléments, du risque de pertes de données et de service, et malgré le fait que nous n’arrivons pas à isoler l’erreur du disque ou à confirmer qu’il ne s’agit pas d’un faux-positif, nous décidons de programmer le remplacement du disque.
Tout d’abord, nous listons les services qui seront impactés par le changement de disque, et la réinstallation qui va s’en suivre. Pour pouvoir minimiser les effets sur les utilisateur⋅ices. Nous choisissons de profiter de ce changement de disque pour réduire la concentration des services sur cette machine, ou pour les déplacer (semi)-temporairement :
Ensuite, nous nous assurons que nous disposons de sauvegardes intégrales du serveur (d’habitude, nous sauvegardons seulement les données, ce qui oblige à tout réinstaller si nous perdons le serveur). Nous rajoutons la sauvegarde de la racine « / » du serveur à nos backups.
L’opération démarre le samedi 13/01 au matin. Au début, tout se passe bien, Kimsufi a remplacé le disque à 1h du matin, nous attaquons la restauration à 9h. Nous pouvons accéder à la console de secours, et commencer la restauration.
Le partitionnement se déroule bien. L’objectif étant de remonter le service le plus rapidement possible, on avait décidé de garder le même partitionnement que sur le précédent disque. Les partitions sont simples, sans LVM ni RAID.
Une fois le partitionnement en place, il nous faut remonter le système. Pour cela, on se base sur une archive Borg de tout le système (toute la racine /, sauf les dossiers /sys/, /proc/, /tmp/, /dev/ et /run/ ) que nous avions lancé la veille.
Le système maintenant en place, on peut quitter la console de secours et redémarrer le serveur. C’est là que les choses se compliquent: le système ne semble pas démarrer. Sur ce serveur, il n’y a pas malheureusement pas de console IPMI, il nous est donc impossible de diagnostiquer la panne. Après plusieurs longues tentatives de redémarrage/console de secours, nous changeons le fusil d’épaule et décidons de repartir sur l’installation d’un Debian via l’installateur Kimsufi 😿
A partir de là, on arrive bien à démarrer le système et à s’y connecter, mais c’est un système vierge, sans nos services et outils. Nous retournons donc sur la console de secours, et nous tentons de remplacer les dossiers du système par ceux de l’archive Borg. Le système démarre ensuite correctement mais nous avons rapidement des messages d’alertes nous indiquant que tout n’est pas opérationnel. Certain fichiers n’ont pas été restaurés correctement (les liens symboliques n’ont pas été restaurés). Cette erreur aurait pu être évitée en testant des restaurations au préalable, chose que nous n’avions pas fait par manque de temps.
Nous avons finalement réussi à remettre en route les services « à la mano » un à un, sur plusieurs jours, jusqu’au mardi 16/01, en priorisant les services les plus critiques.
Au final, les utilisateur⋅ices ont été impactés de la manière suivante :
Nous sommes capables d’effectuer des interventions en cas de problème matériel, sans perte de données.
Nous avons encore des progrès à faire dans l’anticipation de toutes les étapes, et à l’avenir nous nous assurerons que deux administrateur⋅ices « racine » sont bien présents pour la migration.
Pour en savoir plus : nous essayons de rédiger un rapport technique (parfois succinct) pour chaque intervention majeure sur nos serveurs. Celle liée au changement de disque est disponible sur notre wiki technique.
En parallèle des soucis de disques, vous avez été nombreureuse à nous signaler une panne sur l’ouverture des documents collaboratifs. En effet, sur certaines instances Nextcloud, lors de l’ouverture d’un fichier Office (Word, Excel, etc…) il était proposé de télécharger le fichier, alors qu’il devait simplement s’ouvrir dans le navigateur.
Nous pensons que cette panne est liée à une nouvelle fonctionnalité introduite en 2023 qui vient vérifier périodiquement si le service Onlyoffice (l’outil d’édition collaborative que nous utilisons) est bien joignable depuis chaque Nextcloud. Nous avons pour l’instant désactivé cette fonctionnalité car nous disposons déjà d’outils de suivi de notre instance Onlyoffice.
Faites nous signe si vous rencontrez à nouveau ce problème 🙏
Nos services sont gérés par des bénévoles, sur leur temps libre. Nous faisons de notre mieux pour vous fournir des services performants et disponibles mais nous ne pouvons pas garantir une présence constante de nos équipes de support. Nous vous remercions donc de votre compréhension, patience et soutient 🥰