3 MAJ à réaliser avec reboot obligatoire.
Tous les serveurs infogérés seront traités cette nuit.
3 MAJ à réaliser avec reboot obligatoire.
Tous les serveurs infogérés seront traités cette nuit.
Bonjour,
Suite à un jour de coupure d’Internet et de tous nos services en date du 30/05/2023, nous nous devions de venir faire un point.
Un incident de climatisation du site a eu lieu entre le 30/05/2023 à 20h42 et le 31/05/2023 à 11h15
suite à une perte de pression du réseau d’eau glacée alimentant les unités de climatisation des
salles informatiques.
Suite à une succession de trois fuites d’eau sur le réseau secondaire d’eau glacée (boucle
d’alimentation des unités de climatisation des salles informatiques) et à la perte de pression dans
la boucle d’eau glacée qui en a résulté, une montée en température importante dans les salles
informatiques du site a eu lieu.
La prise en compte des défauts et des alarmes remontées au niveau des logiciels de supervision
a été défaillante en début d’incident et a occasionné un délai dans la prise en compte de l’incident
et dans le déclenchement des opérations de remédiation. Ce sujet est au cœur des analyses sous
le pilotage direct de la Direction Générale de l’entreprise.
Les équipes d’exploitation ont été contraintes de couper progressivement l’alimentation électrique
des salles informatiques dans le but de protéger les équipements des clients, conserver l’intégrité
des infrastructures et éviter un départ de feu éventuel suite à un emballement thermique. Pendant
cette période nous avons néanmoins maintenu nos infrastructures essentielles et le backbone
réseau opérationnels.
Les équipes d’interventions présentes sur site se sont réparties sur les 3 actions correctives
suivantes :
la coupure électrique a provoqué la casse de :
Après le remplacement de tous les switches réseau, nous avons pu commencer à vérifier l’état matériel de notre réseau, notre cloud et les serveurs physiques.
A 22h le 31 mai, nous avons attaqué le remplacement des switches BGP (tête de pont réseau), à 3h45 le 01 juin tout le réseau était de nouveau accessible.
Entre le 31 mai et le 1er juin, nous avons relancé tous les serveurs virtuels sans perte de données aucune, la réplication ayant fonctionné pour certaines VM qui avaient subi une altération lors de l’arrêt brusque de courant (principalement les serveurs Linux).
Certaines parties du réseau comportaient des dysfonctionnements, nous avons pu isoler chaque route défectueuse et remplacer ou corriger les switches qui posaient souci. la sécurité employée à travers nos fireWalls physiques et les vlan clients imposent des règles très strictes à tout point de vue du réseau et demande beaucoup de précision lors de toute intervention réseau.
Malgré cette panne fort gênante pour l’activité de nos clients il faut retenir quelques point positifs :
D’ici quelques semaines on vous présentera certains points que nous sommes en train d’améliorer …
Bien sincèrement,
l’équipe de RD medias
Souci rencontré sous Windows 2012 : plus aucune modification possible, disque plein alors qu’il reste de l’espace, …
Il manque une information capitale, lorsque vous démarrez d’un media virtuel ou d’un support usb, car windows change la lettre des lecteurs; donc commandes à faire avant de lancer chkdsk :
1 2 3 |
diskpart list volume |
Récupérez la lettre où le système doit se trouver et ensuite lancez chdsk :
1 |
chkdsk [lettre trouvée]: /R |
Par exemple pour moi il avait déplacé le disque système sur D, et le disque de données sur C (lettres inversées). Cela a donné :
1 |
chkdsk D:/R |
A partir de là j’ai pu lancer la commande ICACLS qui change les droits sur les répertoires mais via la nouvelle lettre :
1 |
ICACLS D:\\windows\winxs |
Puis j’ai pu relancer la commande CHDSK sans plus aucune d’erreur de protection, machine sauvée !
Lors d’une migration de serveur ou cas très rare, il se peut que le cache du Webmail ne se mette pas à jour.
Il y a quelques temps de cela, la simple suppression du fichier cache.db suffisait, ou pour ceux qui utilisent SQLlite la procédure est toujours de vigueur.
Bon nous on a tout fait bien comme dans la doc, avec un mySQL 64 bits de dernière génération et là il faut envoyer de la requête …
Premièrement il nous faut trouver la base en question : GroupWare > Client Web > onglet Général > Base de données.
Quand on connaît la base de données, direction : Système > Outils > Gestionnaire SQL et sélectionner la base détectée dans la première étape, vous pouvez également passer par php myadmin par exemple.
Les commandes :
1 2 3 4 |
// commande 1 DELETE i FROM item AS i INNER JOIN folder on i.folder_id = folder.folder_id WHERE folder.account_id = 'email' // commande 2 DELETE FROM folder WHERE folder.account_id = 'email' |
Un petit Count permet de voir que tout est bien à 0 :
1 2 3 4 |
// vérif commande 1 SELECT count(*) FROM item AS i INNER JOIN folder on i.folder_id = folder.folder_id WHERE folder.account_id = 'email' // vérif commande 2 SELECT count(*) FROM folder WHERE folder.account_id = 'email' |
! Avant toute intervention au niveau du cache il faut fermer les sessions au Webmail via Session > Groupware.
3 MAJ à réaliser avec reboot obligatoire.
Tous les serveurs infogérés seront traités cette nuit.
DELL Idrac ou OMSA sous Windows 2008 par exemple.
Impossible d’accéder à un iDrac ou Server Administrator utilisant un ssl tls 1.1 ou 1.2, astuce :
PS : ne pas reproduire cette manipulation pour de la consultation Internet !!!
3 MAJ dont une urgente à réaliser avec reboot obligatoire.
Tous les serveurs infogérés ont été traités cette nuit.
Alerte Cyber : Faille de sécurité Microsoft Windows et Windows Server
Tous les serveurs infogérés ont été mis à jour.
2 MAJ avec reboot obligatoire.
Les serveurs infogérés sont traités cette nuit.
3 MAJ avec reboot obligatoire.
Les serveurs infogérés sont traités cette nuit.