Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs KVM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Les VM des clients concernés (sauf si elles l'ont été entre temps) seront redemarrées le jeudi 19 novembre. Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.

Une faille de sécurité critique dans le logiciel de virtualisation Xen sera annoncée publiquement le jeudi 29 octobre. L'équipe de Xen nous a d'ores et déjà communiqué les correctifs.

Suite à cette annonce, nous avons déployé un correctif venu s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer les VMs Xen pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Pour permettre aux clients impactés de réagir ou d'anticiper le redémarrage de leurs services, nous allons les contacter directement par email. Les clients n'ayant pas reçu de communication ne sont pas concernés.

Nous conseillons vivement aux clients impactés de redémarrer eux-mêmes leurs serveurs afin de s'assurer que tous les services repartiront correctement. Les VM des clients concernés qui n'auront pas été redémarrées, le seront de façon automatique entre le jeudi 22 et le mercredi 28 octobre.
Une indisponibilité maximum de 30 minutes par VM impactée est à prévoir.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Tout serveur créé ou redémarré à partir d'aujourd'hui utilisera  une nouvelle version du kernel Linux, la version 3.12.45, à moins d'opter pour la version 3.18 ou un kernel personnalisé.

Nous prions tous les clients de noter que ces nouvelles versions du kernel ne supportent plus AUFS. Les utilisateurs de docker, notamment, pourront être impactés par ce changement puisque le "storage driver" par défaut était AUFS.

Pour se servir de docker avec ces nouvelles versions, les utilisateurs devront mettre à jour leur client docker et/ou leurs images pour utiliser un "storage driver" différent, comme btrfs ou overlayfs (disponible avec la version 3.18 du kernel uniquement) .

Pour choisir le kernel 3.18, vous pouvez utiliser la commande suivante avec Gandi CLI [4]

$ gandi disk update  --kernel "3.18-x86_64 (hvm)"

Vous pouvez également changer le kernel à partir de l'interface web en suivant ces instructions [3].

Après l'opération, veillez à redémarrer le serveur et bien mettre à jour vos logiciels et modules [1].

Les clients souhaitant utiliser un kernel personnalisé peuvent obtenir plus d'informations dans le wiki [2].

Et, pour plus d'informations sur l'historique des mises-à-jour du Kernel Linux, vous pouvez consulter notre Changelog.

[1] http://wiki.gandi.net/iaas/references/server/kernel_modules

[2] https://wiki.gandi.net/fr/iaas/references/server/hvm

[3] http://wiki.gandi.net/en/iaas/references/disk/advanced-boot

[4] http://cli.gandi.net

[5] https://wiki.gandi.net/fr/iaas/references/server/kernel_changelog?&#section312


Une faille de securité dans le logiciel de virtualisation QEMU a été annoncée en début de semaine dernière.

Baptisée Venom et identifiée par le code CVE-2015-3456, cette faille permettrait à un attaquant d'exploiter les hôtes vulnérables depuis une machine virtuelle.

Suite à cette annonce, nous avons immédiatement déployé un correctif qui venait s'ajouter à des mesures de sécurité mises en place préalablement. Nous avons continué à étudier la vulnérabilité et avons décidé de redémarrer certaines VM pour nous assurer que les vecteurs d'attaque sont correctement supprimés.

Ce redémarrage préventif n'impactera qu'une petite partie de nos clients. Seuls les clients concernés seront contactés directement par email pour leur permettre de réagir ou d'anticiper le redémarrage de leurs services.

Les VM des clients concernés (sauf si elles ont été redemarrées entre temps) seront redémarrées lundi 25 mai à 11:59pm PDT, soit mardi 26 mai à 07:59am UTC.

Si vous avez des questions à ce sujet ou rencontrez des difficultés, n'hésitez pas à contacter le support.


Suite à l'annonce de la faille de sécurité Ghost, nous vous recommandons vivement de procéder à la mise à jour de vos serveurs en installant les paquets mis à votre disposition par les éditeurs de votre distribution.

Cette faille, qui affecte depuis novembre 2000 la bibliothèque glibc utilisée sur la plupart des distributions Linux et d'autres variantes d'Unix, est très sérieuse, puisqu'elle permet l'exécution de code à distance.

Nous nous assurons de la mise à disposition des paquets correctifs au plus vite sur mirrors.gandi.net

Sont d'ores et déjà disponibles les correctifs suivants :

Nous tâcherons de mettre cette liste à jour au fur et à mesure que les différents éditeurs publieront leurs correctifs.

Si vous êtes client Simple Hosting, nous vous recommandons de redémarrer votre instance.


Nous avons commencé à unifier le service de SFTP de Simple Hosting au début du mois de Décembre.

Cette unification continue et nous avons de nouvelles maintenances prévues sur nos 3 datacenters pour la fin de l'année 2014 et la première semaine de janvier 2015.

Nous ne prévoyons pas d'impact pour la majorité de nos clients lors de cette maintenance, mais voici quelques informations pour vous aider à vous préparer et à résoudre d'éventuels problèmes.

 

Calendrier pour les changements d'IP des endpoints SFTP

| Datacenter | Endpoint | Date de migration |

-------------------------------------------------------------------------

| Baltimore | sftp.dc1.gpaas.net | 30 Décembre 2014 |

| Luxembourg | sftp.dc2.gpaas.net | 5 Janvier 2015 |

| Paris | sftp.dc0.gpaas.net | 6 Janvier 2015 |

 

Impacts possibles :

* Perte de connectivité

Il se peut que des liaisons SFTP perdent de la connectivité pendant la migration, mais il s'agira de cas très rares et qui n'auront pas de conséquences majeures : il suffira de relancer la connexion.

* Problèmes de DNS / Firewall

Puisque l'adresse IP de chaque endpoint va changer, il se peut que des problèmes de propagation DNS surgissent pour certains clients ; pensez à ce scénario si avez du mal à joindre le service. De même, vérifiez que vos parefeux ou autres outils de sécurité ne limitent pas l'accès en fonction de l'adresse IP.

N'hésitez pas à contacter le Support si vous rencontrez des difficultés.


Le service GandiSite, et plus spécifiquement les instances Basekit (les instances SiteMaker n'étant pas concernées), ont été impactées par deux incidents successifs dans la journée du 15 octobre, à savoir :

  • Un premier incident, en début d'après-midi, a rendu les sites indisponibles par intermittence.
  • Un second incident du même type a eu lieu dans la soirée.

Après investigation par nos équipes techniques, le problème a été identifié comme étant liée à la base de données. Des mesures vont être prises pour éviter qu'une telle situation ne se reproduise.

Nous vous prions d'accepter nos excuses pour la gène occasionnée.


Un incident est cours sur une de nos unités de stockage située dans notre centre de données parisien. Cela impacte le service Hosting sur Paris.

Merci de ne PAS lancer de nouvelles opérations sur vos serveurs : la situation va revenir à la normale une fois l'incident terminé.

 

UPDATE - 2:57 (UTC) : La situation devrait être revenu à la normale. N"hésitez toutefois pas à nous contacter si vous remarquez un comportement anormal.


Nous avons subi un incident sur un de nos équipements. Un processeur défaillant a provoqué l'arrêt d'une unité de stockage à 16h19 heure de Paris.

La communication de votre serveur avec le disque a été interrompue : les services et le système n'ont plus fonctionné correctement.

Le service a été rétabli à 16h57, les serveurs sont à nouveau fonctionnels.

Les opérations ont repris progressivement et à 17h25 l'incident a été déclaré résolu.

Nous vous prions de nous excuser pour cette interruption.


Nous avons été impactés par de graves incidents sur plusieurs unités de stockage en début de semaine. Ces incidents ont entraînée deux interruptions de service pour une petite partie de nos clients, tant sur des instances Simple Hosting que sur des serveurs IaaS. 

Cumulées, ces deux interruptions de service réprésentent notre plus gros incident de ces trois dernières années.

Les clients concernés ont été contactés et dédommagés. Nous souhaitons néanmoins, en toute transparence, revenir ici sur les circonstances de ces incidents.

 

  • Peu avant 20h00 CEST le 7 octobre, une unité de stockage de notre datacenter parisien, hébergeant des disques de serveurs IaaS et d'instances Simple Hosting, ne répond plus.
  • À 20h00, vérifications d'usage et décision de basculer sur l'unité de secours.
  • À 21h00, migration des données interrompue. Investigation des équipes et retour vers l'unité de stockage d'origine.
  • À 2h00 redémarrage de l'unité de stockage dont le disque de journal d'écriture défectueux a été changé.
  • À 3h00, sous la forte surchage liée à l'interruption de 6 heures, l'unité de stockage ne répond plus et les équipes sont contraintes d'étaler le démarrage des instances PAAS de 3h00 à 5h30.
  • À 8h30, l'ensemble des VMs et instances est fonctionnel après vérification. Certaines VMs ou instances seront à vérifier au cas par cas.
  • L'ensemble des unités de stockage utilisant le même modèle de disque est inspecté, et l'un d'entre eux est remplacé à titre préventif.
  • À 12h30, l'unité de stockage dont le disque a été remplacé présente une défaillance légère et nos équipes recherchent l'origine du problème.
  • À 15h50, 3 disques virtuels sont bloqués et une dizaine de VM impactée. Le bug est identifié, une mise à jour préventive est réalisée sur l'unité de stockage avant sa correction. Cette mise à jour entraîne un redémarrage automatique, causant une interruption de l'hébergement.
  • À 16h15, l'ensemble des instances Simple Hosting est fonctionnel. Les disques IaaS peinent à remonter. À 17h30, plus de 80% des disques sont accessibles, 100% à 17h45.

 

Pendant toute la durée de l'incident, soit de 16h00 à 18h00 environ, l'ensemble des opérations est interrompu, interdisant tout arrêt, création ou démarrage des serveurs. Les nombreuses opérations en attente de traitement sont traitées dans leur intégralité à 19h30.

Ces incidents en série ont impacté fortement la qualité de notre service, et nous le déplorons. Nous avons d'ores et déjà pris les mesures nécessaires pour réduire l'impact de tels incidents et les prévenir en amont.

En outre, un outil de suivi des incidents et des maintenances permettant à nos clients de connaître l'état de nos services en temps réel est en cours de développement et sera mis en production d'ici la semaine prochaine.

Nous renouvelons à nos clients impactés toutes nos excuses pour le désagrément occasionné et vous remercions de votre confiance.


Page 1 2 37 8 9
Change the news ticker size