Nous venons d'avoir des alertes suite l'ensemble de notre infrastructure sur lien Zeop au GHER à Saint-Benoit. Nous sommes en cours d'investigation. Cela touche tous les clients sur RUN1 et les serveurs dédiés dont l'IP commence par 185.161.10.
MAJ 16h50 (heure Réunion) : nous avons eu confirmation que l'incident se situe côté opérateur, nous attendons leur retour.
MAJ 17h10 (heure Réunion) : le data-center est aussi desservi par un autre opérateur, Canal+ Business, mais un incident touche aussi ce lien donc aucune bascule envisageable.
MAJ 18h10 (heure Réunion) : Zeop nous a confirmé une rupture de fibre en amont du GHER. Une intervention physique sera nécessaire pour réparer la fibre, intervention qui n'est pas autorisée tant que l'alerte rouge est enclenchée. Nous en saurons donc plus probablement demain matin selon la levée de l'alerte rouge. En parallèle, nous avons reçu confirmation que les équipements sont en sécurité.
MAJ 19h15 (heure Réunion) : Le préfet a annoncé la levée de l'alerte rouge à 10h demain matin, les équipes de Zeop interviendront dans la foulée pour réparer la fibre coupée, et nous vous tiendrons au courant au fur et à mesure de l'avancée.
MAJ samedi 08h05 (heure Réunion) : Nous avons eu confirmation de la part des deux opérateurs présents au GHER qu'ils vont intervenir dès la levée de l'alerte rouge ce matin.
MAJ samedi 09h30 (heure Réunion) : Nous aurons un point d'étape sur l'avancée des réparations vers 11h, suite à quoi nous vous communiquerons les dernières informations.
MAJ samedi 10h50 (heure Réunion) : Le réseau des deux opérateurs est endommagé dans l'Est, avec plusieurs NRO injoignables pour le moment, notamment à Sainte-Suzanne et Saint-Benoit. Les techniciens des opérateurs sont bien en route vers les sites concernés, mais l'accès est parfois difficile du fait de l'état du réseau routier. Nous aurons un nouveau point d'étape vers 12h30.
MAJ samedi 12h25 (heure Réunion) : Les opérateurs sont toujours en train de travailler à la résolution du problème. En attendant, pour les clients qui le souhaitent, nous pouvons étudier la restauration leurs services sur un autre data-center fonctionnel à partir des sauvegardes, mais cela impliquera la perte des données de vendredi (les sauvegardes sont faites dans la nuit). Il est donc très important de bien prendre en compte cette contrainte. Les clients intéressés peuvent contacter notre support technique qui confirmera la faisabilité de cette opération.
MAJ samedi 14h15 (heure Réunion) : Les équipes des opérateurs sur site au GHER ont trouvé la source du problème sur le lien Internet et travaillent activement au rétablissement de la partie réseau.
MAJ samedi 16h20 (heure Réunion) : Les équipes de Canal+ Business ont réussi à remonter un lien de secours au GHER. Nous pouvons basculer les clients en serveur dédié qui en feront la demande dessus, mais cela implique un changement d'adresse IP qui n'est pas neutre. Les clients intéressés peuvent contacter notre support technique pour procéder à l'opération. Selon l'évolution côté Zeop, nous verrons pour basculer le serveur mutualisé RUN1 dessus.
MAJ samedi 21h15 (heure Réunion) : Une intervention complémentaire est prévue par Zeop demain après dégagement par EDF d'une ligne à haute tension. Nous vous tiendrons informés dès que nous aurons de plus amples informations.
MAJ dimanche 11h30 (heure Réunion) : Le lien Zeop est revenu, il y a encore quelques instabilités à prévoir le temps que nous reconfigurions nos équipements.
MAJ dimanche 11h35 (heure Réunion) : Nous avons reconfiguré nos équipements, la situation est donc revenue à la normale. Nous continuons à superviser ceci dit.
MAJ dimanche 16h15 (heure Réunion) : Tous les clients qui avaient été basculés sur le lien de secours ou dont les sauvegardes avaient été restaurées sur un autre serveur sont revenus en situation nominale (càd avant cet incident). Les emails qui étaient stockés sur les serveurs de secours ont aussi été délivrés aux serveurs impactés. (voir mise à jour suivante)
MAJ lundi 3h05 (heure Réunion) : Nous venons de perdre la connexion Zeop au GHER, une investigation est en cours.
MAJ lundi 6h05 (heure Réunion) : Nous n'avons pas de retours côté Zeop, nous rebasculons sur le lien Canal+ Business ou sur le data-center secondaire les clients qui avaient été basculés précédemment. Merci de contacter notre support technique si vous désirez aussi être basculés.
MAJ lundi 7h30 (heure Réunion) : Les équipes de Zeop ont localisé l'incident (dans leur NRO à Bras Panon) et sont déjà sur place pour travailler à sa résolution. Nous n'avons pas d'heure estimée de retour à la normale pour le moment. Nous suivons de près l'évolution de la situation.
MAJ lundi 8h45 (heure Réunion) : Nous sommes en train d'étudier la possibilité de basculer tous les clients de RUN1 massivement sur le lien Canal+. Si vous gérez la zone DNS de votre côté, un changement d'IP sera à prévoir, nous vous communiquerons ici la nouvelle IP.
MAJ lundi 9h10 (heure Réunion) : La bascule est en cours et le service va revenir vers 9h30 (selon délai de propagation DNS). Voici la nouvelle IP si vous gérez votre zone DNS : 185.161.8.49.
MAJ lundi 9h40 (heure Réunion) : La bascule est terminée, si vous n'avez pas accès à vos services, il faudra attendre jusqu'à une heure que la nouvelle adresse IP soit bien propagée.
MAJ lundi 11h40 (heure Réunion) : Nous observons le retour à la normale de la connexion Zeop, nous attendons confirmation officielle de la fin de l'incident chez eux.
MAJ lundi 12h40 (heure Réunion) : Nous avons la confirmation de Zeop que l'incident est clos de leur côté. Nous restons sur les IP Canal+ cet après-midi puis rebasculerons sur les IP Zeop à 20h, en parallèle. Cela signifie que les adresses IP Canal+ continueront à répondre en même temps des adresses IP Zeop (pour éviter les délais de propagation DNS). Les adresses IP Canal+ seront retirées demain vers 9h. Si vous gériez votre zone DNS, merci de remettre 185.161.10.160.
MAJ lundi 20h30 (heure Réunion) : La rebascule vers les IP Zeop est terminée, les changements sur les zones DNS que nous gérons sont terminés.
MAJ mardi 10h15 (heure Réunion) : Les adresses IP Canal+ ont été retirées. Cet incident est désormais clos.
Nous tenons à remercier toutes les équipes impliquées dans la résolution de cet incident exceptionnel, et nous vous remercions pour votre compréhension.
Le serveur RUN2 sera redémarré le 03/03 vers 20:00 (heure Réunion) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
MAJ 20h07 : L'opération s'est déroulée correctement
La connexion de la Réunion vers le reste du monde via le câble sous-marin Metiss est coupée en raison d'un incident sur la station d'atterrissage à la Réunion. Cela risque de dégrader les accès vers la Réunion, même si nos opérateurs disposent de capacité sur d'autres câbles. Nous n'avons pas de délai de retour à la normale.
MAJ samedi 13h15 : la situation est revenue à la normale.
Suite au passage du cyclone Garance, nos lignes téléphoniques sont pour le moment interrompues suite à un problème majeur chez l'opérateur. Vous pouvez nous contacter sur [email protected] si besoin.
MAJ 08:10 : La situation est revenue à la normale.
Suite à des problèmes de performance sporadiques au niveau de PHP, nous allons passer l'essemble de nos serveurs web mutualisés de PHP-FPM à mod_lsapi.
MAJ 11:30 (heure Réunion) : nous avons basculé avec succès FDF1 en Martinique, et nous ferons les autres serveurs cette nuit (heure Réunion) pour éviter des perturbations en heures ouvrées.
MAJ 21:30 (heure Réunion) : nous avons basculé avec succès MRU1 à l'île Maurice.
MAJ 04:00 (heure Réunion) : nous avons basculé avec succès RUN1 et RUN2 à la Réunion.
MAJ 05:45 (heure Réunion) : nous avons basculé avec succès RNS1 en France hexagonale.
Tous les serveurs sont désormais sur mod_lsapi. Nous avons vérifié différents sites et ils chargent bien, mais si vous rencontriez des difficultés n'hésitez pas à contacter notre support technique. Nous supervisons les logs d'erreur pour vérifier si le changement n'a pas causé de problèmes.
Nous rencontrons un problème de connexion vers le WAF v6Protect, leurs ingénieurs sont en train de résoudre le problème.
MAJ 16:00 : Le problème est réglé.
Bonjour actuellement, nous faisons face à un problème sur notre serveur RUN2. La résolution de celui-ci est en cours et nous nous excusons pour le désagrément causé.
Nous avons une forte charge sur le serveur web, rendant l'accès à certains de vos services difficles. Nous sommes en train de régler cela et la situation devrait être de retour à la normale d'ici peu.
MAJ 12:44 (heure Réunion) : le problème est réglé
Notre supervision remonte un problème sur un de nos opérateurs à la Réunion qui impacte les clients dont les IP commencent par 80.69. Nous sommes en contact avec l'opérateur.
MAJ 09:40 (heure Réunion) : L'opérateur a confirmé l'incident dans son cœur de réseau et nous tient au courant du rétablissement.
MAJ 11:00 (heure Réunion) : L'incident est toujours en cours et toutes les équipes travaillent activement à sa résolution.
MAJ 11:30 (heure Réunion) : La cause première de l'anomalie a été localisée : il s'agit d'un problème d'accès au stockage, qui s'est mise en sécurité et qui rend l'accès aux données inaccessibles pour le moment.
MAJ 12:30 (heure Réunion) : Les opérations pour remettre le stockage en marche sont toujours en cours, l'intégrateur de la solution de stockage est sur site au data-center.
MAJ 14:00 (heure Réunion) : Nous avons eu confirmation que vos données ne sont pas en danger, mais l'accès à celles-ci sont encore impossibles. L'intégrateur est toujours sur site, en lien avec l'éditeur.
MAJ 15:00 (heure Réunion) : Les opérations sont toujours en cours. Pour information, la mise en sécurité s'est répliquée sur le data-center de secours, ce qui explique que nous ne pouvons pas basculer sur le data-center de secours.
MAJ 15:20 (heure Réunion) : Les équipes au data-center on trouvé une piste sur la partie stockage et si tout va bien les services devraient revenir en ligne d'ici une heure.
MAJ 15:50 (heure Réunion) : Le stockage est bien remonté, nous avons dû redémarrer certains serveurs qui n'étaient pas repartis correctement. Si votre serveur rencontre des problèmes, merci de contacter notre support technique pour que nous puissions le redémarrer. Nous communiquerons aux clients impactés un REX la semaine prochaine.
Nous avons un incident sur notre réseau en Bretagne rendant impossible à vos serveurs localisés sur cette zone. Nous sommes en cours d'investigation.
MAJ 8h28 (heure de Rennes) : La connexion a été rétablie, nous avons ouvert un ticket chez l'opérateur pour en savoir plus.
MAJ 9h30 (heure de Rennes) : Voici le retour de l'opérateur :
Nous avons rencontré un incident électrique lié à la maintenance : BLUE-2501ead8e6.
En effet, nous avons perdu un circuit sur une voie, impactant des serveurs hébergés. Nos équipes ont relancé manuellement le PDU concerné.
À 09h00, l'énergie était rétablie et les équipements impactés ont redémarré automatiquement.
MAJ 12h15 (heure de Rennes) : Nous venons d'avoir une nouvelle communication de l'opérateur :
Des actions de câblage sont planifiées en urgence aujourd’hui à partir de 13h00, avec une fin estimée à 14h00, afin d’éviter une surcharge sur un PDU. Ces actions n’auront normalement aucun impact sur vos services.
Nous avons une forte charge sur le serveur web, et nous sommes en train de régler cela. La situation devrait être de retour à la normale d'ici quelques heures.
MAJ 17h10 (heure Réunion) : la situation est revenue à la normale.
Nous avons repéré une hausse des emails en erreur et, après investigation, une solution utilisée par Microsoft - SpamHaus - a bloqué une adresse IP utilisée par SpamExperts. SpamExperts est la solution que nous utilisons pour sécuriser les envois d'email et notamment bloquer les spams et virus potentiels.
Les emails à destination de Outlook.com et Microsoft 365 peuvent donc ne pas arriver à destination, selon l'IP de sortie utilisée par SpamExperts.
Voici un exemple de message que vous avez pu avoir reçu si vous emails sont concernés :
550 5.7.1 Service unavailable, Client host [185.201.17.68] blocked using Spamhaus.
Nous sommes en échange SpamExperts qui travaille à la résolution de ce problème et nous vous tiendrons informés de l'évolution de la situation.
En attendant, nous vous demandons de ne pas renvoyer les emails pour lesquels vous avez reçu un message d'erreur. Ils n'ont pas été délivrés à vos correspondants.
MAJ 08:15 (heure Réunion) : Les équipes de SpamHaus sont en train de retirer l'adresse IP impactée pour qu'elle ne soit plus utilisée.
MAJ 08:58 (heure Réunion) : SpamExperts nous a indiqué que l'adresse IP impactée a été retirée et ne devrait donc plus utilisée pour envoyer vos emails. Nous continuons à surveiller la délivrabilité de vos emails.
MAJ 09:14 (heure Réunion) : Il semblerait que nous ayons encore quelques blocages avec une partie des emails qui continuent à partir depuis l'IP bloquée par Microsoft, une escalade est en cours chez SpamExperts. Environ 25% des messages utilisent l'adresse IP bloquée donc posent problème.
MAJ 11:30 (heure Réunion) : L'escalade pour contourner le blocage de Microsoft est toujours en cours chez SpamExperts, qui a pris contact en parallèle avec SpamHaus pour débloquer l'adresse IP concernée.
MAJ 14:00 (heure Réunion) : SpamExperts nous a indiqué que l'adresse IP impactée a été retirée sur tous leurs systèmes et ne devrait donc plus utilisée pour envoyer vos emails. Nous continuons à superviser la délivrabilité de vos emails.
MAJ 14:30 (heure Réunion) : Les emails partent désormais bien correctement. Nous vous invitons à renvoyer les emails pour lesquels vous avez reçu une erreur. Nous nous excusons pour la gêne occasionée, et nous tenons à vous rassurer que ce genre d'incident est extrêmement rare car - d'une manière générale - SpamExperts permet d'éviter le blocage des adresses IP de vos serveurs par des tiers grâce à leurs puissants filtres antispam et antivirus.
MAJ 23/01 : Suite à un échange avec le management chez SpamExperts, nous avons eu le retour sur pourquoi l'opération de 08h58 hier n'avait pas fonctionné. Pour des raisons de conformité RGPD, nous n'autorisons SpamExperts à ne filtrer qu'au sein de l'Union Européenne vos emails, et le retrait de 08:58 n'était effectif que sur le filtrage global et non sur le filtrage Union Européenne comme nous. Ils nous ont assuré avoir mis à jour leurs procédures internes pour éviter que ça se reproduise. Nous avons aussi pris note de cette information de notre côté pour bien leur signaler si jamais le problème devait se reproduire, et nous allons étudier l'impact conformité de passer en filtrage global en cas de problème de ce genre.
Un incident réseau est en cours au niveau de notre opérateur à Maurice et les accès à nos serveurs à Maurice sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 09:42 (heure Maurice) : l'incident est résolu.
Une opération de maintenance aura lieu sur la gestion des noms de domaines, rendant les opérations impossibles samedi 28/12 de 8h à 11h (heure de Paris). Aucune commande (création ou transfert) ne pourra être réalisée durant cette période, ni aucun changement (DNS, etc.). Nous nous excusons pour la gêne occasionnée.
Un incident réseau est en cours avec Emtel qui empêche l'accès à nos serveurs à Maurice. L'accès depuis les autres opérateurs est fonctionnel. Une investigation est en cours côté Emtel.
MAJ 26/12/2024 - Nous venons d’avoir la confirmation que le problème à été résolu peu après le déclenchement de l’incident.
Nous rencontrons actuellement un incident sur le serveur mru1.hodi.host. Nous sommes en train d'investiguer cela.
MAJ 12/12 à 19:10 : Le défaut est identifié et la résolution est en cours, le service devrait revenir à la normale d'ici 30 minutes.
MAJ 12/12 à 19:23 : Le service est revenu à la normale.
MAJ 13/12 à 15:50 : Le problème survient de nouveau, nous allons avancer l'opération de maintenance pour corriger ce défaut.
MAJ 13/12 à 16:08 : Le service est revenu à la normale, et nous allons désormais réaliser l'opération de maintenance. Il ne devrait pas y avoir d'impact en production.
Nous rencontrons actuellement un incident sur le serveur mru1.hodi.host. Nous sommes en train d'investiguer cela.
MAJ 15:05 : Le problème est réglé, il s'agissait d'un problème au niveau du serveur de base de données, nous vérifions sa configuration.
Nous avons eu un problème sur notre outil d'extinction des CPU qui a pu causer des ralentissements sporadiques. Le problème a été identifié et un correctif a été déployé. Nous surveillons la situation pour vérifier que vos sites fonctionnement bien.
Le serveur MRU1 sera redémarré le 7/11 vers 21:30 (heure Maurice) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
Pour éviter de perdre des emails, les emails à destination du serveur MRU1 seront redirigés vers un serveur secondaire le temps de l'opération, et ce serveur se chargera de les rediriger vers le serveur MRU1 une fois le redémarrage terminé.
MAJ : Le redémarrage a été effectué avec succès, aucune anomalie à signaler.
Un incident réseau est en cours au niveau de notre opérateur en Bretagne et les accès à nos serveurs en Bretagne sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 16h20 : Cet incident cause des indisponibilités sporadiques sur notre espace client vu la forte affluence. Nous avons apporté des modifications pour mieux gérer la charge.
MAJ 16h36 (heure de Paris) : Nous avons eu une communication officielle de la part de l'opérateur :
Notre équipe Infrastructure a identifié l'origine de l'incident en cours : une mauvaise configuration a été déployée vers nos automates, entraînant des indisponibilités de service.
Nous travaillons activement à résoudre ce problème pour rétablir les services dans les meilleurs délais.
MAJ 16h54 (heure de Paris) : La situation est revenue à la normale selon notre supervision, nous attendons la confirmation de l'opérateur.
MAJ 17h20 (heure de Paris) : Nous avons eu la confirmation de l'opérateur que la situation est revenue à la normale de leur côté.
Un incident réseau est en cours au niveau de notre opérateur à Maurice et les accès à nos serveurs à Maurice sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 13:58 : La situation est revenue à la normale.
Nous rencontrons actuellement un incident sur le serveur mru1.hodi.host. Nous sommes en train d'investiguer cela.
MAJ 10:50 : Nous avons redémarré le serveur car nous n'arrivions plus y accéder. Le service est revenu à la normale mais nous gardons le serveur sous surveillance.
Un incident réseau est en cours au niveau de notre opérateur à Maurice et les accès non locaux à nos serveurs à Maurice sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 20:30 : La situation commence à revenir progressivement à la normale pour les accès hors Maurice.
MAJ 20:45 : La situation est totalement revenue à la normale. Nous nous excusons pour la gêne occasionnée.
Nous avons repéré une hausse des emails en erreur et, après investigation, Microsoft a décidé de bloquer certains emails envoyés via SpamExperts. SpamExperts est la solution que nous utilisons pour sécuriser les envois d'email et notamment bloquer les spams et virus potentiels.
Certains mails à destination de Outlook.com ont pu être rejetés, Microsoft 365 n'a pas l'air impacté pour le moment.
Voici un exemple de message que vous avez pu avoir reçu :
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[email protected]
host hotmail-com.olc.protection.outlook.com [52.101.42.15]
SMTP error from remote mail server after pipelined sending data block:
550 5.7.1 Unfortunately, messages from [185.201.16.68] weren't sent.
Please contact your Internet service provider since part of their network is
on our block list (S3150). You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. [Name=Protocol Filter
Agent][AGT=PFA][MxId=11B9C0156AE00B4B]
[MWH0EPF000A6733.namprd04.prod.outlook.com 2024-09-30T07:26:25.085Z
08DCE00AB6504EAA]
Après consultation avec SpamExperts, ils travaillent à la résolution de ce problème et nous vous tiendrons informés de l'évolution de la situation.
MAJ 16:28 : Le problème a été résolu. Les emails pour lesquels vous avez eu un message d'erreur devront être renvoyés. Nous nous excusons pour la gêne occasionnée.
Dans le cadre de l'amélioration de nos services, nous allons opérer une modification de la configuration réseau du serveur RUN2 ce qui pourra occasionner quelques ralentissements voire coupures vers 21h (heure Réunion) ce jeudi 12 septembre.
MAJ 21:20 : L'opération est terminée et s'est déroulée avec succès.
MAJ 13/02 à 10:15 : Nous avons remarqués des difficultés depuis la modification à recevoir / envoyer des emails, nous sommes en train d'investiguer cela.
MAJ 13/02 à 11:00 : Le problème est réglé, les mails sont en train d'être délivrés.
Un incident réseau est en cours au niveau d'un de nos opérateurs à La Réunion et les accès à nos serveurs à La Réunion dont l'adresse IP commencent par 185.161 sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 00:55 : La situation est revenue à la normale.
Un incident réseau est en cours au niveau de notre opérateur à Maurice et les accès à nos serveurs à Maurice sont pour le moment impossibles. L'opérateur travaille à la résolution de cet incident.
MAJ 19:15 : La connexion est de retour localement et sur certaines localisations à l'étranger, l'opérateur continue à travailler à un retour complet à la normale. Il pourrait y avoir des indisponibilités sporadiques pendant la résolution.
MAJ 21:35 : La connexion est de nouveau opérationnelle de manière globale. Nous nous excusons pour la gêne occasionnée, et nous gardons la situation sous surveillance.
Un incident réseau est en cours auprès de notre opérateur à Maurice qui cause des indisponibilités sporadiques pour les accès à nos serveurs. L'opérateur travaille à la résolution de cet incident.
MAJ 4:30 : La connectivité locale est rétablie. La connectivité internationale est en cours de rétablissement.
MAJ 7:15 : La connectivité internationale est revenue sur certaines destinations, par exemple depuis la Réunion.
MAJ 9:10 : La connectivité internationale est revenue au complet. Les éventuels emails qui n'ont pu être délivrés pendant l'incident sont en cours de livraison.
Nous rencontrons actuellement un incident sur le serveur rns1.hodi.host. Nous sommes en train d'investiguer cela.
MAJ 13:40 (heure de Paris) : Nous avons redémarré le serveur car nous n'arrivions plus y accéder. Nous avons identifié la cause et nous allons procéder à une opération de maintenance corrective cette nuit pour prévenir ce genre d'incident.
Un incident réseau est en cours avec Mauritius Telecom qui empêche l'accès à nos serveurs à Maurice. L'accès depuis les autres opérateurs est fonctionnel. Une investigation est en cours côté Mauritius Telecom.
MAJ 16:00 : Les clients désirant être basculés sur la Réunion en attendant la résolution du problème peuvent contacter notre support technique.
MAJ 20:30 : La situation est revenue à la normale mais nous continuons à superviser la connexion.
Nous rencontrons actuellement un incident sur le serveur run2.hodi.host. Nous sommes en train d'investiguer cela.
MAJ 20:30 : Nous avons redémarré le serveur car nous n'arrivions plus y accéder. Le service est revenu à la normale mais nous gardons le serveur sous surveillance.
Suite à la découverte d'une faille importante sur OpenSSH, nos équipes sont en train de mettre à jour tous les serveurs dont nous avons la gestion. Nous contacterons individuellement les clients où la mise à jour n'est pas possible pour trouver des solutions de contournement. Aucune interruption de service n'est à prévoir.
MAJ 03/07 : L'ensemble des serveurs a été vérifié et ceux qui étaient impactés par la faille (environ 16%) ont été mis à jour. Nous n'avons repéré aucun signe de compromission.
Nous rencontrons des difficultés côté SFR Réunion où certains accès hors Réunion sont coupés. L'opérateur travaille à la résolution de cet incident. Les services impactés sont ceux dont les IP publiques commencent par 80.69.
MAJ 18:06 : Il s'agit d'une coupure sur le câble LION, la bascule automatique sur les autres câbles n'a pas bien fonctionné et l'opérateur travaille à une bascule manuelle.
MAJ 18:45 : La situation est revenue à la normale grâce à une bascule sur d'autres câbles. Nous aurons un rapport d'incident de l'opérateur demain, et nous vous ferons une communication de manière subséquente.
Nos opérateurs à la Réunion nous signalent des incidents sur les câbles sous-marins :
- LION : incident depuis le 4 décembre à 17h53 heure Réunion, avec rétablissement annoncé pour mi-juin
- SAFE/SAT-3 : maintenance programmée depuis le mercredi 8 mai prévue, avec retour à la normale annoncé pour le 18 mai
- Deuxième incident LION depuis ce vendredi 10 mai à 4h06 heure Réunion, retour à la normale assez rapidement comme la coupure est terrestre et identifiée
Nous nous excusons pour la gêne occasionnée, et nous ne manquerons pas de vous prévenir de l'évolution de la situation.
MAJ 13/05 : le deuxième incident sur LION est résolu depuis dimanche matin, l'impact des deux autres incidents est très limité.
Un incident réseau est en cours auprès de notre opérateur à Maurice qui cause des indisponibilités sporadiques pour les accès en dehors de Maurice à nos serveurs. L'opérateur travaille à la résolution de cet incident.
MAJ 18h : La situation est revenue à la normale.
MAJ 14/06 à 14:50 : Notre opérateur à Maurice rencontre de nouveau un problème causant des indisponibilités sporadiques pour les accès en dehors de Maurice, et travaille à la résolution de l'incident.
MAJ 14/06 à 15:03 : La situation est revenue à la normale, et l'opérateur nous informe que la situation devrait revenir à la normale dans quelques semaines. Les incidents sont liés à des difficultés sur les câbles sous-marins.
MAJ 24/06 à 11:30 : Notre opérateur nous informe que la situation est désormais revenue à la normale.
Nous avons repéré une hausse des emails en erreur et, après investigation, Microsoft et Yahoo ont décidé de réduire le nombre d'emails qu'ils acceptent depuis certaines IP de SpamExperts. SpamExperts est la solution que nous utilisons pour sécuriser les envois d'email et notamment bloquer les spams et virus potentiels.
Les mails à destination de Outlook.com, Yahoo et Microsoft 365 peuvent donc pour le moment être retardés. Vous n'avez pas besoin de renvoyer vos emails.
Voici un exemple de message que vous avez pu avoir reçu :
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on mx293.antispamcloud.com.
The message identifier is: 1sGZGi-00Cgbl-Ql
The subject of the message is: Test de message
The date of the message is: Tue, 11 Jun 2024 06:27:38 +0400
The address to which the message has not yet been delivered is:
[email protected]
host eur.olc.protection.outlook.com [104.47.30.97]
Delay reason: SMTP error from remote mail server after pipelined sending data block:
451 4.7.650 The mail server [185.201.16.35] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S775) [VI1EUR03FT012.eop-EUR03.prod.protection.outlook.com 2024-06-11T07:32:19.729Z 08DC89A86595C565]
No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.
Reporting-MTA: dns; mx293.antispamcloud.com
Après consultation avec SpamExperts, ils travaillent à la résolution de ce problème et nous vous tiendrons informés de l'évolution de la situation.
MAJ 13h27 : Les emails vers Microsoft 365 sont désormais bien délivrés, seuls les emails vers @outlook.com, @hotmail.com, @msn.com, @yahoo.fr et similaires peuvent pour le moment être retardés.
MAJ 14h41 : Les nouveaux emails vers @outlook.com, @hotmail.com, @msn.com et @yahoo.fr sont bien délivrés, les anciens mails sont en cours de livraison.
MAJ 16h19 : Tous les emails en attente ont bien été envoyés. Nous nous excusons pour la gêne occasionée.
Nous venons de détecter un incident sur la Réunion touchant RUN2 et les serveurs virtuels dont l'IP commence par 80.69, nous revenons vers vous rapidement dès que nous avons des informations de l'opérateur concerné.
MAJ 22:09 : L'incident est confirmé par l'opérateur, une équipe est en cours d'intervention sur le cœur de réseau pour résoudre le problème.
MAJ 22:33 : La bascule sur le data-center de secours a bien eu lieu, mais certains services ne repartent pas, nous investiguons pourquoi.
MAJ 23:39 : La situation est s'améliore : les services en erreur sont en train de repartir un à un.
MAJ 02:17 : Tous les services sont remontés, et nous avons validé manuellement le bon fonctionnement de tous les applicatifs hébergés. Nous nous excusons pour la gêne occasionnée.
Une opération de maintenance sur nos baies de stockage (remplacement des contrôleurs par des modèles plus récents et plus performants) sur le data-center de Rennes (RNS) est prévue du 16/04 à 18:30 au 17/04 à 01:00 (UTC+2) pour vous fournir une qualité de service toujours meilleure.
Du fait de la résilience de notre infrastructure, vos services resteront accessibles, mais un léger impact de performance pourrait être sporadiquement rencontré.
Nos opérateurs à la Réunion nous rapportent un incident en cours sur le câble sous-marin SAT-3, et les consortiums gérants les câbles rapportent que WACS, ACE, MainOne, Seacom, EIG) et AAE1 connaissent aussi des incidents.
Les connexions entre les îles de l'Océan indien et le reste du monde pourraient être perturbées de manière sporadiques. Les connexions internes ou inter-îles ne sont pas impactées.
Cela peut aussi affecter vos accès à votre espace client qui est hébergé dans l'UE continentale pour des questions de redondance.
Nous nous excusons pour la gêne occasionnée, et nous ne manquerons pas de vous prévenir de l'évolution de la situation.
MAJ 20/03 : Le câblier Léon Thévenin vient de quitter son port d'attache, Cape Town, pour mettre le cap sur le lieu identifié de l'incident du SAT-3 (au large de la Côte d'Ivoire). Son arrivée prévue sur site est à la fin du mois. Le retour à la normale est prévu vers le 4 avril.
MAJ 29/03 : Le câblier Léon Thévenin vient d'arriver à Abidjan et va mettre le cap sur le lieu précis de l'incident du SAT-3. Les opérations devraient durer jusqu'à mi-avril.
MAJ 15/04 : Le câblier Léon Thévenin a quitté la zone de l'incident pour retourner à Abidjan. Nous fermons donc cette remontée d'incident même si les autres câbles coupés seront réparés plus tard car les câbles concernant la Réunion sont désormais réparés.
cPanel a décidé de passer les certificats SSL de Sectigo à LetsEncrypt, mais le renouvellement du certificat du domaine principal (run1.hodi.host) ne se déroule pas comme prévu, ce qui a pu causer des difficultés d'accès à certains sites. Nous avons mis en place un correctif en attendant que le certificat se renouvelle comme attendu.
Le problème de renouvellement de certificat est actuellement escaladé chez cPanel.
Les accès à cPanel par l'espace client sont actuellement indisponibles du fait du non renouvellement du certificat, il vous faut utiliser l'accès direct.
Nous nous excusons pour la gêne occasionnée.
MAJ 9:35 : La situation est revenue à la normale pour les accès cPanel.
MAJ 13:35 : Nous avons, de manière préventive, déployé l'action corrective sur les autres serveurs de notre architecture.
15/02 10:56 : Nous n'arrivons plus à joindre ce serveur.
15/02 11:12 : La situation est revenue à la normale, nous gardons le serveur sous surveillance.
16/02 10:57 : Nous avons rencontré le même problème, la situation va revenir à la normale dans 5 à 10 minutes.
16/02 11:50 : Après des analyses plus poussées grâce à la surveillance rapprochée du serveur, le composant PHP X-Ray semble poser problème. Nous le retirons quelques jours pour vérifier cela.
17/02 10:57 : Nous avons de nouveau un incident, nous collectons davantage de traces, et nous allons redémarrer le serveur. La situation va revenir à la normale dans une dizaine de minutes.
18/02 10:57 : L'incident s'est reproduit, le service Apache semble la cause du dysfonctionnement avec une augmentation soudaine de sa consommation CPU. La situation va revenir à la normale dans une dizaine de minutes. Nous procéderons lundi au déplacement des sites qui le désirent sur un autre hébergement web le temps de stabiliser celui-ci.
18/02 11:37 : Nous sommes encore en train de collecter des informations pour mieux isoler la cause des dysfonctionnements.
18/02 16:45 : Nous sommes en train d’analyser les différentes traces collectées.
19/02 08:10 : Nous avons modifié la configuration du serveur suite à l'analyse d'hier, nous continuons l'analyse ce matin et gardons le serveur sous étroite surveillance.
19/02 11:45 : Aucun problème n'a été rencontré aujourd'hui sur le serveur RUN2 suite aux changements apportés. Nous poursuivrons ceci dit la surveillance demain.
22/02 15:30 : Après plusieurs jours de surveillance, la situation est revenue à la normale.
Fortinet a publié l'avis de sécurité concernant la vulnérabilité critique CVE-2024-21762 affectant le VPN SSL de FortiOS. Cette vulnérabilité permet à un attaquant non authentifié de provoquer une exécution de code arbitraire à distance. Fortinet indique que cette vulnérabilité serait potentiellement exploitée.
Une mise à jour de nos deux clusters de firewall Fortinet à la Réunion est planifiée ce lundi 12/02/24 à 21h : Passage de la version FortiOS 7.2.6 à FortiOS 7.2.7, ce qui causera une coupure de 10 à 15 minutes environ.
Plus d'informations : https://cert.ssi.gouv.fr/alerte/CERTFR-2024-ALE-004/
Un de nos opérateurs à la Réunion nous rapporte deux incidents qui sont en cours sur les câbles sous-marin :
- sur le câble EIG depuis le 3/01/24, au large de Djeddah (Arabie Saoudite) ; la réparation est annoncée entre le 25 février et le 6 mars 2024.
- sur le câble SAFE-SAT-3 depuis le 9/01, et les investigations sont en cours pour identifier la localisation exacte de la panne ; le démarrage de la réparation est annoncé pour le 17 janvier 2024.
Les connexions entre les îles de l'Océan indien et le reste du monde pourraient être perturbées de manière sporadiques. Les connexions internes ou inter-îles ne sont pas impactées.
Cela peut aussi affecter vos accès à votre espace client qui est hébergé dans l'UE continentale pour des questions de redondance.
Nous nous excusons pour la gêne occasionnée, et nous ne manquerons pas de vous prévenir de l'évolution de la situation.
A 4:50, nous avons reçu une notification de l'éditeur du logiciel que nous utilisons pour l'espace client qu'une vulnérabilité critique avait été découverte :
The issue pertains to a specific function that allowed customers to upload image files (PNG, JPG, SVG, and GIF) when logged into the WHMCS client area. This function used PHP MIME type checks to ensure only these image formats could be uploaded. However, we have discovered that the MIME function’s security measures are not entirely foolproof.
It has come to our attention that skilled hackers could exploit this function. They could bypass the intended restrictions by executing a particular URL, allowing them to upload a PHP file. This vulnerability poses a significant security risk.
We want to assure you that this function was never utilized in the Lagom Client Theme. As a precautionary measure, we have completely removed this function from the addon files to eliminate any potential risk.
Our team has conducted a thorough investigation of all addon files to search for any other vulnerabilities. We are pleased to report that no additional significant security issues have been found. However, as part of our commitment to continually enhance the security and integrity of our products, we plan to release further security improvements in the upcoming 2.2.4 version of our product, scheduled for release in February.
Nous avons vérifié l'espace client et aucun signe de téléversement de fichier malveillant n'a été détecté, et déployé le patch en production vers 7:15.
Le serveur RUN2 sera redémarré le 18/10 vers 21:00 (heure Réunion) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
Pour éviter de perdre des emails, les emails à destination du serveur RUN2 seront redirigés vers un serveur secondaire le temps de l'opération, et ce serveur se chargera de les rediriger vers le serveur RUN2 une fois le redémarrage terminé.
MAJ 21:15 : Les opérations se sont correctement déroulées et les services sont revenus à la normale.
En raison du passage du cyclone Belal sur la Réunion aujourd'hui, nous avons mis en place notre Plan de Continuité d'Activité qui nous permet de continuer nos services de support et d'infogérance, en gardant nos équipes en sécurité, qui travaillent depuis leur domicile.
Nous suivons de près la situation dans nos trois data-centers réunionnais et ne manquerons pas de vous indiquer si nous rencontrons des difficultés sur l'un d'eux. Soyez rassurez, ceci-dit, que vos données sont sauvegardées sur au moins deux autre data-centers, dont un en dehors de la Réunion, et que nous avons des réserves en carburant pour pallier des coupures d'alimentation électrique.
MAJ 17/01 à 9:30 : Nous n'avons eu aucun incident sur notre infrastructure, l'ensemble de nos services étaient opérationnels comme en temps normal.
La connexion en un clic entre l'espace client et cPanel a été interrompue mais un ingénieur est intervenu pour réparer le dysfonctionnement. Les accès directs à cPanel sans passer par l'espace client sont restés opérationnels pendant la durée de l'incident.
Le serveur RUN1 sera redémarré le 22/12 vers 21:00 (heure Réunion) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
Pour éviter de perdre des emails, les emails à destination du serveur RUN1 seront redirigés vers un serveur secondaire le temps de l'opération, et ce serveur se chargera de les rediriger vers le serveur RUN1 une fois le redémarrage terminé.
Un incident sur le serveur web RUN1 a été détecté causant une indisponibilité du service. Nous sommes en train d'intervenir.
MAJ 14h36 : La situation est revenue à la normale, mais nous gardons ce serveur sous surveillance rapprochée pour vérifier sa stabilité.
MAJ 21h : Nous avons réalisé une opération pour améliorer la stabilité. Nous gardons demain le serveur sous surveillance rapprochée.
MAJ 14/11 à 17h55 : Tous les signaux sont au vert, nous nous excusons pour la gêne occasionnée.
Le serveur RUN1 sera redémarré le 13/10 vers 22:00 (heure Réunion) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
Pour éviter de perdre des emails, les emails à destination du serveur RUN1 seront redirigés vers un serveur secondaire le temps de l'opération, et ce serveur se chargera de les rediriger vers le serveur RUN1 une fois le redémarrage terminé.
MAJ 22:15 : Les opérations se sont correctement déroulées et les services sont revenus à la normale.
Notre supervision a détecté une augmentation de la latence sur certains de nos serveurs (dont run1.hodi.host). Il n'y a pas de perte de paquets, mais les accès pourraient être ralentis. Nous avons ouvert un ticket chez l'opérateur concerné et reviendrons vers vous dès que nous aurons plus d'informations.
MAJ 13:00 : le problème est résolu.
Le firewall Fortinet de RUN2 a dû être mis à jour d'urgence en raison d'une vulnérabilité critique, mais la connexion réseau ne revient pas. L'administrateur réseau d'astreinte est en train de travailler sur le sujet.
MAJ 5:30 : Le problème est réglé.
Notre opérateur à la Réunion nous signale un incident technique sur le SAT-3 ce dimanche 6/08 et des travaux sur le câble LION-2 pouvant causer des ralentissements sur les accès hors Réunion / Océan Indien à vos serveurs à la Réunion. Les réparations sont en cours mais nous n'avons pas de délai de résolution pour le moment.
Cela peut aussi affecter vos accès à votre espace client qui est hébergé dans l'UE continentale pour des questions de redondance.
Nous nous excusons pour la gêne occasionnée, et nous ne manquerons pas de vous prévenir de l'évolution de la situation.
MAJ 8/08 : Le retour à la normale pour le câble LION-2 est prévu vers le 13/08, mais le retour à la normale pour le câble SAT-3 n'est pas encore prévu.
MAJ 10/08 : Le câblier Léon Thévenin doit d'abord finir les travaux sur le câble LION-2 avant de mettre le cap sur le lieu de l'incident du SAT-3 (entre le Congo et le Cameroun).
MAJ 11/08 15h15 : La maintenance sur le câble LION-2 est terminée, la situation n'est pas encore de retour à la normale mais les choses vont s'améliorer pour les connexions hors Réunion.
MAJ 15/08 - 15h : Notre supervision a repéré une forte perte de paquets (> 50%) vers l'Afrique du Sud depuis un peu moins d'une heure, nous avons escaladé auprès de l'opérateur car la latence vers l'Europe ne rencontre pas ce problème. Les accès vers/depuis des services hébergés en Afrique du Sud et dans la zone Océan Indien sont donc fortement pertubés pour le moment (hors Emtel à Maurice avec qui nous sommes connectés directement). 18h : La perte de paquet importante vers l'Afrique du Sud a causé des problèmes sur la résolution DNS au niveau du serveur pouvant causer des échecs sur des appels d'API ou des retards de livraison de mails vers l'extérieur, nous sommes donc passés sur un autre opérateur pour la résolution DNS.
MAJ 18/08 - 13h : Notre supervision a repéré une forte perte de paquets (> 75%) vers l'Afrique du Sud depuis un peu moins d'une heure comme le 15/08, nous avons escaladé auprès de l'opérateur. Les accès vers/depuis des services hébergés en Afrique du Sud et dans la zone Océan Indien sont donc fortement pertubés pour le moment (hors Emtel à Maurice avec qui nous sommes connectés directement), ceux vers le reste du monde sont aussi moyennement pertubés. 15h45 : Notre opérateur confirme l'incident situé sur la liaison terrestre en Afrique du Sud et indique un délai de retour à la normale "sous quelques jours". 16h30 : Du fait des instabilités, nous avons eu un problème de courte durée sur le serveur web en raison du nombre de requêtes en attentes, nous avons augmenté la capacité de traitement du serveur web. 16h35 : Notre supervision repère un retour à la normale, nous attendons la confirmation côté opérateur.
MAJ 24/08 - 16h50 : Le câblier qui doit réparer le câble SAT-3 vient de quitter son port d'attache (Cape Town) après avoir chargé du câble de rechange. Il est prévu d'arriver au large du Congo, région de l'incident, le 30/08 à 16h (heure Réunion). Les équipes à bord devront ensuite procéder à la réparation du câble lui même.
MAJ 28/08 - 14h15 : Des instabilités du fait de ces problèmes ont été rencontrées sur le serveur web vers 14h07, nous avons fait des modifications pour que le service revienne à la normale vers 14h12.
MAJ 4/09 - 8h15 : Le câblier est arrivé sur le site de la coupure du câble SAT-3. Nous n'avons pas eu de date de fin de travaux communiquée par notre opérateur mais Telecom Namibia impacté par le même incident a annoncé un retour à la normale le 8/09.
MAJ 7/09 - 13h00 : Nos outils de supervision et des mesures manuelles semblent indiquer un retour à la normale, mais nous attendons la confirmation côté opérateur.
Nous remarquons des ralentissements sporadiques sur run1.hodi.host pouvant causer des erreurs 503. Nous allons procéder à une opération de maintenance pour corriger cela vers 18h30, ce qui causera un redémarrage du serveur.
MAJ 7/09 12:50 : L'opération de redémarrage s'est déroulée avec succès, et la supervision montre que les problèmes de ralentissement sporadiques sont réglés.
Nous avons reçu une alerte de la saturation temporaire de l'espace disque temporaire (/tmp) sur ce serveur. Après analyse, il s'agit de fichiers temporaires utilisés par le WAF, fichiers présents en plus grand nombre que d'habitude en raison du problème sur le câble sous-marin. Nous avons d'abord purgé les fichiers temporaires mais comme le problème revenait de manière sporadique nous avons augmenté l'espace disque.
Le serveur RUN1 sera redémarré le 20/07 vers 22:00 (heure Réunion) pour procéder à une maintenance préventive. Le redémarrage prendra quelques minutes, pendant lesquelles vos services seront inaccessibles.
Pour éviter de perdre des emails, les emails à destination du serveur RUN1 seront redirigés vers un serveur secondaire le temps de l'opération, et ce serveur se chargera de les rediriger vers le serveur RUN1 une fois le redémarrage terminé.
MAJ 22:05 : Le serveur n'est pas reparti après la maintenance, nous avons donc annulé la modification réalisée et nous sommes en train d'investiguer sur la cause du non redémarrage.
MAJ 23:00 : Aucune cause évidente n'a été trouvée, nous allons travailler avec l'éditeur dans les jours qui viennent (nous avons récupéré les fichiers journaux et autres éléments) pour trouver la cause et replanifier cette maintenance. Nous nous excusons pour le contre-temps.
MAJ 21/07 11:50 : Nous avons eu une piste pour contourner le problème, nous allons retenter un redémarrage dans la nuit de lundi à mardi vers 22h.
MAJ 25/07 16:00 : Vu l'incident d'hier, nous avons reprogrammé la dernière étape de la maintenance préventive qui consiste en un redémarrage le 31/07 vers 22h. Le service sera interrompu quelques minutes.
MAJ 31/07 22:18 : Le redémarrage s'est déroulé avec succès, l'opération de maintenance préventive est désormais terminée.
Nous avons un incident en cours sur le serveur RUN1. Nos équipes sont en train d'intervenir pour le résoudre.
MAJ 11:35 : Nous sommes en train de restaurer une sauvegarde de la nuit dernière, nous vous tenons au courant d'ici midi dès que nous avons une heure prévue de retour à la normale.
MAJ 12:00 : Le stockage du serveur est corrompu, et la restauration complète est en cours et devrait se terminer vers 15h30. En parallèle, nous sommes en train de tenter des opérations pour réparer le stockage corrompu pour réduire le temps d'indisponibilité. Nous vous tenons au courant si cela donne quelque chose.
MAJ 14:00 : La restauration est toujours en cours au même rythme (fin prévue vers 15h30). Nous avons terminé des étapes d'analyse du stockage pour continuer les opérations de réparation en parallèle.
MAJ 15:25 : La restauration est terminée, nous faisons quelques tests rapides pour voir si grâce à cette restauration nous pouvons relancer le serveur actuel ou pas et dans le cas contraire nous relançons la sauvegarde.
MAJ 15:45 : La sauvegarde est redémarrée, mais certains services ont du mal à repartir. Nous vérifions cela.
MAJ 16:45 : Nous sommes toujours sur le sujet et nous restons mobilisés jusqu'à sa résolution. En parallèle, nous avons vérifié les données de la sauvegarde et tout est OK, il n'y a pas eu de corruption de données.
MAJ 17:15 : Nous avons apporté des modifications pour régler le problème, nous lançons un redémarrage.
MAJ 17:20 : Le service est revenu à la normale, nous supervisons que tout se passe bien. Si vous avez des problèmes, n'hésitez pas à quitter et relancer votre navigateur et/ou logiciel de messagerie. Les données créées/modifiées entre 22h hier (la sauvegarde) et 11h aujourd'hui (l'incident) ont été perdues pour le moment, mais nous continuons les opérations pour essayer de récupérer des données sur le stockage corrompu.
MAJ 25/07 17:35 : Nous travaillons toujours sur la récupération du stockage. Nous vous communiquerons aussi un rapport d'incident complet dans les prochains jours.
MAJ 27/07 09:40 : Nous sommes au regret de vous annoncer que malgré les différentes tentatives de récupération du stockage, aucune des données impactées n'ont pu être récupérées. Nous finalisons le rapport d'incident pour le début de semaine prochaine, mais nous tenons déjà à vous rassurer qu'il s'agit d'un incident exceptionnel et que nous avons mis en place des procédures de remédiation pour éviter que cela se reproduise.
Nous avons repéré une hausse des emails en erreur et, après investigation, il s'agit d'un prestataire (SpamHaus) qui a décidé de dégrader la réputation de certaines IP de SpamExperts que nous utilisons pour sécuriser l'envoi de vos emails.
SpamHaus est notamment utilisé par Microsoft 365 donc certains mails à destination de Microsoft 365 on pu ne pas arriver correctement à destination.
Si vous avez reçu un mail d'erreur ressemblant au message ci-dessous, vous devrez renvoyer votre mail :
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[email protected]
host exemple.mail.protection.outlook.com [104.47.17.74]
SMTP error from remote mail server after RCPT TO:<[email protected] >:
550 5.7.1 Service unavailable, Client host [185.201.16.35] blocked using Spamhaus. To request removal from this list see spamhaus.org/query/ip/185.201.16.35 AS(1440) [DB8EUR05FT058.eop-eur05.prod.protection.outlook.com 2023-06-05T08:07:52.587Z 08DB64E430EF8B14]
Après consultation avec SpamExperts, ils travaillent à la résolution de ce problème et nous vous tiendrons informés de l'évolution de la situation.
MAJ 12:15 : la situation est en train de revenir à la normale progressivement.
MAJ 13:30 : la situation est revenue à la normale, les emails sont désormais livrés correctement.
MAJ 6/06 11:45 : certains emails restent plus longtemps que la normale en liste d'attente donc vous pouvez recevoir des emails avec comme sujet "Warning: message 1q5wWt-0006kT-73 delayed 24 hours" ; en attendant que SpamExperts résolve la situation nous l'avons désactivé pour éviter des retards dans la livraison de vos emails.
MAJ 7/06 12:00 : SpamExperts nous a informé être en relation très étroite avec Spamhaus suite à cet incident pour éviter que ça se ne reproduise, et travailler à livrer les emails qui sont encore en file d'attente (ceux pour lesquels vous recevez un message avec un sujet comme "Warning: message 1q5wWt-0006kT-73 delayed 24 hours"). Nous vous tiendrons au courant dès que tous les messages auront bien été délivrés et nous maintenant la désactivation de SpamExperts pour éviter que vos nouveaux mails ne soient retardés.
MAJ 9/06 11:00 : Après différents communications avec SpamExperts et des tests que nous avons effectués sur notre infrastructure de pré-production, le problème est réglé et nous allons réactiver SpamExperts lundi prochain.
MAJ 12/06 16:50 : Nous avons bien réactivé SpamExperts et nous surveillons l'évolution de la situation.
MAJ 13/06 17:15 : Tous les voyants sont au vert et aucun problème de livraison n'est à constater. Nous nous excusons pour la gêne occasionnée sur cet incident qui était hélas hors de notre contrôle.
Un incident est en cours sur notre plateforme téléphonique et le fournisseur concerné travaille à la résolution.
Nous vous invitons à nous joindre par chat ou par email en attendant le retour à la normale. Nous nous excusons pour la gêne occasionnée.
Après différents tests, nous avons décidé de changer de système de sauvegarde pour passer de Acronis vers JetBackup progressivement. Ce système permet notamment des sauvegardes et des restaurations plus rapides, tout en gardant la flexibilité d'une restauration totale ou partielle selon vos besoins. Les sauvegardes JetBackup seront stockées dans l'Union Européenne.
Bien entendu, les sauvegardes Acronis resteront disponibles en parallèle le temps que JetBackup dispose de 30 jours d'historique de sauvegarde.
Nous mettrons à jour ce message une fois que tous les serveurs seront basculés avec succès vers JetBackup, et une fois que Acronis sera retiré 30 jours après la bascule.
MAJ 3/04 : environ 50% des clients ont été basculés avec succès ce weekend, le reste des clients sera basculé le weekend prochain.
MAJ 11/04 : tous les clients ont bien été basculés avec succès vers JetBackup. Les sauvegardes Acronis seront supprimées le 11/05/2023. Vous pouvez dores-et-déjà consulter notre FAQ pour restaurer les sauvegardes JetBackup.
Le serveur RUN1 sera redémarré le 25/04 vers 21:30 (heure Réunion) pour procéder à l'augmentation de ses capacités. Le redémarrage prendra quelques minutes.
MAJ 14:00 : Suite à l'incident et au redémarrage, les capacités ont été augmentées. Cette opération est donc annulée.
Un incident sur le serveur web RUN1 a été détecté causant des indisponibilités de vos sites web. Un ingénieur est en cours d'analyse.
MAJ 14:00 : L'incident est résolu après redémarrage du serveur, nous en avons donc profité pour réaliser l'opération d'augmentation des capacités initialement prévue à 21:30 aujourd'hui.
Notre opérateur à la Réunion nous signale un incident sur les câbles sous-marins pouvant causer des ralentissements sur les accès hors Réunion à vos serveurs à la Réunion. La date prévue pour le retour à la normale est le 30/04.
Cela peut aussi affecter vos accès à votre espace client qui est hébergé hors Réunion pour des questions de redondance.
Nous nous excusons pour la gêne occasionnée, et nous ne manquerons pas de vous prévenir de l'évolution de la situation.
MAJ 25/04 : La situation est revenue à la normale.
Cette nuit, certains domaines en cours de transfert ont été indiquées comme "terminés" de manière erronée et les clients concernés ont reçus des emails les informant, par erreur, que leur nom de domaine était bien transféré. Notre équipe analyse la situation et nous vous invitons à vérifier le statut de vos domaines sur votre espace client en cas de doute.
MAJ 17:25 : Nous avons trouver la cause du problème qui a été résolue.
Nous subissons une attaque par déni de service distribué (DDoS) sur notre site Internet et sur notre espace client. Nous sommes rapidement intervenus pour bloquer l'attaque mais nous surveillons la situation de près. L'accès à votre espace client pourrait être sporadiquement ralenti.
MAJ 15:15 : Tous les indicateurs sont au vert. Nous clôturons l'alerte.
10:20 : Un incident sur le serveur web RUN1 a été détecté. Une intervention est en cours.
MAJ 10:35 : L'incident a été réglé vers 10:30 et est lié à un pic de consommation anormal sur MySQL. Nous allons analyser pour voir comment réguler ce genre de consommation.
Le 13/03, nous allons rajouter un anti-spam sortant sur l'ensemble des serveurs mutualisés afin d'améliorer la sécurité générale de notre infrastructure et la délivrabilité de vos emails. Cela permet aussi d'éviter qu'un script mal configuré puisse envoyer des spams et donc réduire la réputation de vos noms de domaine. Cet anti-spam sortant est inclus sans coût supplémentaire sur votre hébergement.
Les tests sur nos environnements de test ont été concluants.
L'article 12 des nos Conditions Générales de Service a été mis à jour pour correspondre à cette nouvelle pratique.
MAJ 13/03 à 11:32 : La mise en service de l'anti-spam sortant a été réalisée avec succès vers 11:18 et la supervision des envois d'email n'a pas détecté de problème.
Une opération de maintenance est prévue le 8 mars entre 11h et 19h (heure Réunion) sur les serveurs de stockage FTP (cela ne concerne pas les hébergements mutualisés). Durant cette période, une coupure de quelques minutes sera à prévoir. Le service reviendra automatiquement à la normale et aucune donnée ne sera perdue.
Nous nous excusons pour la gêne occasionnée.
L'opération de maintenance est terminée depuis 17:17.
Un incident sur le serveur web RUN1 a été détecté causant des ralentissements de vos sites web, voire des indisponibilités sporadiques. Un ingénieur est rapidement intervenu pour stabiliser la situation une dizaine de minutes après le début de l'incident et les services sont revenus à la normale.
MAJ 19:30 : Après analyse, l'incident était lié à un dysfonctionnement sur MySQL qui a occasionné une augmentation anormale de l'utilisation des ressources sur le serveur. L'origine du problème a été corrigée vers 19:30 pour prévenir un futur dysfonctionnement. Nous nous excusons pour la gêne occasionnée.
Un incident est en cours au niveau des sauvegardes Acronis. Les sauvegardes ne sont actuellement plus réalisées, et il n'est pas possible de restaurer les anciennes sauvegardes.
Les sauvegardes Veeam continuent normalement et ne posent pas de problèmes : vos données sont donc en toute sécurité.
MAJ 10:12 : Les sauvegardes passées ne sont pas endommagées, c'est juste l'accès aux sauvegardes qui est impossible pour le moment (en lecture et en écriture).
MAJ 10/02 13:06 : Le problème est résolu. Nous allons lancer une sauvegarde manuelle vers 19h.
Nous rencontrons un incident sur le serveur web RUN1 qui cause des inaccessibilités à vos services. Un ingénieur est en train d'intervenir pour régler la situation.
MAJ 17:17 : La situation est revenue à la normale mais nous allons procéder dans quelques instants à un redémarrage du serveur pour augmenter ses performances.
MAJ 19:15 : Nous rencontrons un problème au redémarrage, et nous sommes en lien avec l'éditeur du composant logiciel qui pose problème.
MAJ 20:27 : Le problème est réglé et la situation est revenue à la normale. Nous nous excusons pour la gêne occasionnée.
Nous avons reçu une alerte de la saturation temporaire de l'espace disque temporaire (/tmp) sur ce serveur. Après analyse, il s'agit de fichiers laissés par le WAF, et nous ne remarquons pas ce problème sur nos autres serveurs. Un ticket a été ouvert chez le fournisseur du WAF pour analyse. Les fichiers temporaires ont, entre temps, été supprimés par l'administrateur d'astreinte.
MAJ 20/01 à 9:25 : Le fournisseur du WAF a bien pris en compte le problème et en train de regarder ce qui se passe.
MAJ 20/01 à 13:05 : Le fournisseur du WAF a déployé un correctif qui devrait régler la situation. Nous allons vérifier dans les prochains jours si le comportement est correct.
MAJ 23/01 à 08:25 : Le comportement est correct, le WAF ne laisse plus de fichiers temporaires superflus dans /tmp.
Un incident est en cours sur NBG1 et nos ingénieurs travaillent à sa résolution. Le service devrait revenir à la normale sous peu.
MAJ 16h10 : L'incident est résolu et la situation est revenue à la normale.
Un incident a été détecté sur NBG1 qui a causé une inaccessibilité temporaire des sites Internet qui y sont hébergés. Un ingénieur est intervenu rapidement pour relancer le service impacté vers 13h50. La cause première a été identifiée et un correctif est en cours de déploiement pour prévenir ce genre d'incidents à l'avenir.
MAJ 15:20 Le correctif a été débloyé.
Une opération de mise à jour sur notre infrastructure sur le data-center de Saint-Denis (Université) est prévue du 28/11 au 07/12 pour vous fournir une qualité de service toujours meilleure.
Du fait de la résilience de notre infrastructure, ces mises à jour n'auront pas d'impact sur l'accès ou les performances de vos services, et aucune interruption de service n'est prévue.
Nous venons d'ajouter nos différents routeurs sur la page de statut de notre infrastructure (https://status.hodi.host/) pour vous aider à savoir si un éventuel problème est uniquement sur votre service ou plus global.
Un incident sur les services web hébergés sur RUN1 a eu lieu vers 10:00 et un ingénieur est rapidement intervenu pour le résoudre moins de dix minutes plus tard. Nous nous excusons pour la gêne occasionnée.
Nous sommes en train d'investiguer la cause première de l'incident.
MAJ 10:50 : Il y a eu un pic sur l'utilisateur du CPU sur le serveur donc nous allons augmenter les ressources du serveur vers 21:00, ce qui occasionnera un reboot.
MAJ 22:00 : Les ressources ont bien été ajoutées et, après vérifications, tous les services sont bien repartis après le redémarrage.
Nous avons augmenté les capacités I/O de votre hébergement, sans coupure de service. Le seul impact est que les tâches I/O intensives que vous exécutiez seront désormais plus rapides à s'exécuter.
Un incident sur les services web hébergés sur NBG1 a eu lieu à 16:10 et un ingénieur est rapidement intervenu pour le résoudre une quinzaine de minute plus tard. Nous nous excusons pour la gêne occasionnée.
Un incident est en cours sur l'interface de restauration des sauvegardes dans cPanel qui vous empêche de restaurer vos sauvegardes.
Les sauvegardes sont correctement effectués, et notre support est à votre disposition pour restaurer manuellement des sauvegardes si besoin.
Nous sommes en contact avec Acronis pour la résolution de cet incident.
MAJ : La situation est revenue à la normale.
Le serveur RUN1 sera redémarré pour procéder à l'augmentation de ses capacités. Le redémarrage prendra quelques minutes.
MAJ : L'opération a été réalisée avec succès, et le redémarrage n'a pas été nécessaire.
Suite à maintenance de l'AFNIC qui gère les .RE et les .FR, la vérification de disponibilité indiquait par erreur que les domaines .RE et .FR étaient indisponibles même si ce n'était pas le cas. Le problème a été corrigé par nos équipes.
Un incident sur l'interface des restauration des sauvegardes (Acronis) est en cours et va nécessiter un redémarrage du serveur pour le résoudre. Ce redémarrage est prévu pour lundi matin à 7h. Les sauvegardes sont correctement effectués, il s'agit seulement de l'interface vous permettant de restaurer les sauvegardes qui ne fonctionne pas correctement.
MAJ 12 septembre à 8h30 : l'équipe d'astreinte a procédé au redémarrage et tout est revenu dans l'ordre.
Dans le cadre de l'amélioration de nos services, nous avons décidé de migrer RUN1 vers un nouveau data-center en plusieurs étapes pour limiter les impacts sur votre service. Ce nouveau data-center est bien entendu aussi à la Réunion. Cela nous permettra d'améliorer la qualité des services que nous vous proposons. Ce changement occasionnera un changement d'adresse IP pour votre hébergement : 185.161.10.160.
La recopie initiale des données est terminée et nos équipes ont vérifié que tout fonctionne normalement dans le nouveau data-center.
La bascule est prévue ce mercredi 7 septembre de 22h à 23h (heure Réunion). Les accès au serveur seront coupés le temps de la recopie des données modifiées depuis la dernière recopie, et seront redémarrés à la fin des opérations.
Aucun email ne sera perdu lors de la migration car ils seront reroutés vers un serveur secondaire le temps de la coupure, avant d'être redirigés vers votre serveur une fois que celui-ci sera accessible.
Nos équipes s'occuperont de modifier les entrées DNS de vos hébergements sauf si la zone DNS n'est pas hébergée sur nos serveurs. Si la zone DNS n'était pas hébergée sur nos serveurs, nous vous recommandons de modifier votre zone DNS pour utiliser un enregistrement CNAME vers run1.hodi.host.
Notre support technique se tient à votre disposition si besoin.
MAJ du 7 septembre à 9h47 : Les dernières étapes pré-bascules (changement TTL, recopie des données modifiées, reboot et vérification du bon lancement des services) ont été réalisées avec succès.
MAJ du 8 septembre à 00h42 : La dernière recopie a été réalisée avec succès, et l'ensemble des services est revenu à la normale. La supervision post-bascule n'a pas révélé de problèmes.
MAJ du 8 septembre à 11h25 : Nous constatons un dysfonctionnement où le serveur ne peut pas effectuer des appels HTTPS vers lui même, nous sommes en train d'investiguer le problème.
MAJ du 8 septembre à 11h49 : Nous avons une solution de contournement au dysfonctionnement de 11h25. Si vous êtes impactés par ce problème, il vous suffit de contacter notre support technique qui la mettra en place, en attendant la résolution définitive.
MAJ du 8 septembre à 15h32 : Le dysfonctionnement de 11h25 a été réglé de manière définitive.
MAJ du 9 septembre à 08h00 : Nous avons remarqué un dysfonctionnement nécessitant un redémarrage pour prévenir une interruption de service dans la journée, nous procédons au redémarrage qui prendra quelques minutes.
MAJ du 9 septembre à 09h15 : Nous considérons désormais la migration totalement terminée, les quelques ajustements nécessaires suite à cette migration ayant tous été traités. Les TTL ont été remis à 3600s. Merci pour votre compréhension !
Un incident sur le service d'envoi de mails hébergé sur RUN1 a eu lieu vers 15:25 pour les utilisateurs utilisant le port 587. L'équipe technique est intervenue rapidement pour régler la situation qui est revenue à la normale vers 15:45.
Si vous aviez toujours des difficultés, nous vous invitons à relancer votre logiciel de messagerie.
Un incident sur les services web hébergés sur NBG1 a eu lieu vers 3:50 causant certains certificats SSL comme étant invalides. L'équipe d'astreinte a rapidement mis en place un correctif pour contourner le problème mais avec une baisse possible des performances.
La résolution définitive est intervenue vers 9:05 avec la mise en place d'un autre correctif restaurant les performances nominales.
Si vous aviez toujours une erreur de certificat SSL, nous vous invitions à vider le cache de votre navigateur.
Un incident a été détecté par notre supervision vers 23:43 et après intervention notre équipe d'astreinte a vu qu'il s'agissait d'un problème réseau qui a été résolu vers 23:58. Nous nous excusons pour la gêne occasionnée.
Notre opérateur à la Réunion nous signale une opération de maintenance sur son infrastructure :
Dans le cadre de la maintenance et la mise à jour de notre infrastructure, une opération de mise à jour d'équipements réseau est prévue le mercredi 29 juin
2022 à partir de 22h00 à 00h00.Des perturbations du service Internet peuvent être ressenties durant cette opération.
Nous vous présentons toutes nos excuses pour la gêne éventuelle occasionnée
Nous vous remercions pour vote compréhension.
Cela peut causer des ralentissements voire des coupures sporadiques des accès vers vos serveurs sur la plage horaire indiquée.
MAJ 30/06 : L'opération est terminée et notre équipe d'astreinte n'a pas remarqué de problèmes sur lors de l'opération de maintenance.
Un incident sur les services web hébergés sur NBG1 a eu lieu à 05:49 et l'équipe d'astreinte est rapidement intervenue pour le résoudre une quinzaine de minute plus tard. Nous nous excusons pour la gêne occasionnée.
Une maintenance de routine est prévue sur votre espace client qui pourra le rendre inaccessible sporadiquement à partir de 22h. La maintenance est prévue pour terminer vers 22h30. Les autres services ne seront pas impactés.
Un incident sur les services web hébergés sur RUN1 a eu lieu à 06:56 et l'équipe d'astreinte est rapidement intervenue pour le résoudre une quinzaine de minute plus tard. Nous nous excusons pour la gêne occasionnée.
Notre opérateur en Europe nous signale un incident en cours sur son architecture, et travaille à la résolution de l'incident. Nous vous tenons informés dès que nous avons de nouvelles informations.
MAJ 11:45 : La situation est revenue à la normale. Nous nous excusons pour la gêne occassionée.
Le serveur NBG1 sera redémarré pour procéder à l'installation de nouveaux composants logiciels. Le redémarrage prendra quelques minutes.
Le serveur RUN1 sera redémarré pour procéder à l'installation de nouveaux composants logiciels. Le redémarrage prendra quelques minutes.
MAJ 29/04 à 16:43 : Notre opérateur nous informe que les réparations sont terminées.
Notre opérateur à la Réunion nous signale une alerte sur les câbles sous-marins :
A la suite de l'opération de maintenance d'hier, une casse sur le câble sous-marin a été localisée sur le continent africain.
Les réparations sont en cours chez note fournisseur. Nous n'avons, pour le moment, pas de délai de résolution à annoncer.
De fortes perturbations de service Internet pourront être ressenties.
Nous vous présentons toutes nos excuses pour la gêne éventuelle occasionnée
Cela peut causer des ralentissements voire des coupures pour les accès hors Réunion à votre serveur à la Réunion, ou depuis la Réunion vers votre serveur en Europe. Les accès de la Réunion vers la Réunion ne sont pas impactés.
MAJ : Suite à la maintenance, il semblerait que des ralentissements se poursuivent sur la journée, nous attendons plus d'éléments de la part de l'opérateur.
Notre opérateur à la Réunion nous signale une alerte sur les câbles sous-marins :
Une maintenance d'urgence aura lieu, sur nos câbles sous-marins, cette nuit, mercredi 20/04/2022 à 01h00 et prendra fin à 10h00.
De fortes perturbations de service Internet sot prévues durant cette tranche horaire.
Nous vous présentons toutes nos excuses pour la gêne éventuelle occasionnée
Nous vous remercions pour vote compréhension.
Cela peut causer des ralentissements voire des coupures pour les accès hors Réunion à votre serveur à la Réunion, ou depuis la Réunion vers votre serveur en Europe. Les accès de la Réunion vers la Réunion ne sont pas impactés.
Le serveur NBG1 sera redémarré pour augmenter ses capacités. Le redémarrage prendra quelques minutes.
