GuiGui's Show

ArubaOS (utilisé dans le produit Aruba Mobility Master v8.6) refuse de démarrer / booter dans une machine virtuelle KVM sur un hyperviseur Proxmox 6 car il manque les instructions CPU SSSE3.

On se dit qu'on va faire un qm set, mais, d'après la doc', les drapeaux activables sont limités, et il n'y a pas SSSE3.

Il y a qu'à choisir un modèle de CPU virtuel qui prend en charge SSSE3. Par défaut, le type de CPU émulé par Proxmox+KVM est kvm64, qui est un Pentium 4 avec des jeux d'instructions retirés.

Dans les propriétés de la VM, onglet « Hardware », « Processors », on peut choisir le modèle de CPU dans la liste déroulante « Type ». SSSE3 étant ancien (2004), n'importe quel modèle de CPU devrait faire l'affaire. Nous avons choisi IvyBridge, fin du problème.

On a souvent besoin d'autrui pour mener à bien / faire avancer un projet / combat. Parfois, les personnes que l'on sollicite car elles nous semblent être les plus à même d'aider (compétences, détention d'informations, situation / position, affinité, etc.) refusent d'apporter leur concours. Pire, certaines personnes se désistent et retroussent chemin après avoir engagé leur premier coup de papatte. Souvent pour des motifs vaseux comme une peur irrationnelle.

Dans ces moments-là, je me sens déçu par la personne voire trahi, et donc triste. Je fonctionne à l'affinité / l'affect (je choisis une personne pour un projet pour ses compétences, mais aussi parce que je sens bien cette personne-là, à ce moment-là, sur ce projet-là), donc, forcément, ça me fait mal. Surtout quand une personne affirme adhérer à fond à ma démarche et qu'elle m'a bien chauffé au préalable en mode "t'as trop raison, faut faire ça, vas-y mon poulain !".

On peut y voir de la lâcheté, voire de l'hypocrisie (afficher son soutien sans rien produire de concret). Oui, c'est vrai, mais…

Il y a plus de 5 ans maintenant, une amie m'a dit quelque chose. Je constate que le souvenir de ces paroles m'a apaisé à plusieurs reprises ces derniers mois dans des contextes comme celui exposé ci-dessus.

Il y a plein de façon de contribuer à un projet / combat, plein de manière de changer le monde. On n'est pas obligé de poser des bombes ni de saboter les moyens de production. On peut gérer la logistique (autour de la pose de la bombe ou du sabotage). On peut héberger les militants radicaux (comme les Résistants qui faisaient sauter les voies ferrées). On peut diffuser la propagande (afin d'expliquer l'utilisation de bombes / sabots). On peut fournir des informations (car, comme la personne est restée irréprochable, le système lui en filera). On peut mettre en relation des personnes. On peut soutenir moralement l'acteur principal. On peut lui remonter le moral. On peut dévier le coup de grâce que tentera s'asséner le système à l'actrice principale (en restant irréprochable aux yeux du système, une personne sera à même de peser de tout son poids dans la décision). On peut contribuer aux caisses de grève plutôt que d'aller se faire gazer par les flics ou perdre quelques précieux euros sur un salaire précaire. Etc. Bref, il faut accepter que tout le monde n'ait pas le même niveau d'engagement dans un projet / combat… Et ne pas insulter le futur.

Comme dit dans le film Fight Club, c'est à chaque personne de définir son niveau d'engagement. Comme d'hab', forcer les gens amène rien de positif (travail bâclé, dernier coup de main, mauvaise ambiance, etc.). Ma fierté de ces dernières années est de parvenir à commencer à faire la différence entre un refus de ma personne et un refus de l'une de mes idées, et d'accepter un refus de coup de main. Je progresse à petits pas.

Il est très rare qu'une caisse automatique d'un supermarché me refuse un article. Mais c'est arrivé. « Erreur somme de contrôle, êtes-vous sûr d'avoir déposé le bon article ? ».

La caissière m'explique que mon pack de binouzes est un assemblage de 4 bouteilles qui sont aussi vendues séparément. Donc il contient en réalité 5 codes-barres (un sur chaque bouteille + sur le carton). Il faut scanner le bon (celui sur le carton).

Depuis, je fais attention à masquer le code-barre des bouteilles aux yeux du scanner et tout se passe bien.

Si jamais ce tuyau peut te servir autant qu'à moi… :)

Vitrine d'un café fin 2020.

Des ours en peluche remplacent les humains par temps de covid.

• Original, mais glaçant ;
  
  
• Un aperçu du monde des bisounours ?

Bien sentie, cette photo. :)

Ça date de fin 2019.

Mignon, les mots de passe des pionniers de BSD / UNIX :

• Ken Thompson : p/q2-q4! (mouvement d'échec :O )
  
  
• Dennis Ritchie : dmac (le composé chimique ou un jeu avec ses initiales ?)
  
  
• Stephen R. Bourne : bourne (haha la faiblesse du mdp)
  
  
• Brian W. Kernighan : /.,/.,

Le mot de passe de Bill Joy (le ouf qui a codé la première implémentation de TCP/IP, sur BSD) n'a pas encore été retrouvé.

Sur FRnOG (liste de discussion par emails destinée aux opérateurs téléphoniques et Internet ainsi qu'aux curieux), on peut lire plusieurs témoignages du type "je téléphonais, et, soudainement, mon interlocuteur m'a redit les mêmes choses, au mot près, dans le même ordre". Une variante est d'entendre ce qu'on a soi-même dit quelques minutes auparavant. Certains nomment ça « effet matrix ». Il ne s'agit pas d'espionnage mais d'une fraude nommée Call Stretching. Je résume l'animation LinkedIn :

• Quand Alice téléphone à Bob, l'opérateur de Bob facture l'appel à l'opérateur d'Alice via les opérateurs intermédiaires qui transportent l'appel (c'est le cas pour des appels internationaux) ;
  
  
• Pour faire du bénéfice, l'opérateur intermédiaire (que l'on nomme « carrier ») applique une marge sur le prix demandé par l'opérateur de Bob, et ainsi de suite sur toute la chaîne ;
  
  
• Après quelques minutes de conversation, l'opérateur intermédiaire raccroche l'appel avant son terme mais uniquement d'un des deux côtés (Alice ou Bob). Une variante consiste à maintenir l'une des extrémités de l'appel après que l'autre ait raccroché. Dans les deux cas, l'opérateur diffuse soit un message pré-enregistré, soit un enregistrement de la conversation qui vient d'avoir lieu ;
  
  
• Alice (ou Bob) ne s'en rend pas forcément compte, car certaines conversations se prêtent bien à la répétition genre les démarchages commerciaux durant lesquels tu peux demander 3 fois la même info (genre le prix) sans que l'interlocuteur, qui veut vendre, s'en émeuve. Et même si l'un des interlocuteurs s'en rend compte, son comportement sera, en moyenne, de dire "allô ?", "il y a un problème technique, non ?" ou autres propos ;
  
  
• Pendant ce temps-là, le compteur de facturation tourne, et l'opérateur intermédiaire fait 100 % de marge : il sera payé par l'opérateur d'Alice, mais il ne redistribuera pas un kopeck à l'opérateur de Bob puisque, pour cet opérateur, l'appel est terminé (il ne le facture donc plus à l'opérateur intermédiaire fraudeur).

A priori, ça fait partie d'un groupe de fraudes plus vastes nommées False Answer Supervision (qui consistent à facturer avant l'établissement complet de l'appel ou après la fin de l'appel).

Je suis impressionné par ce que l'humain est capable de mettre en place pour faire chier son prochain tout en encaissant de l'argent de poche… Si ça ce n'est pas un abus du capitalisme (tirer profit d'une action inutile qui ne rend pas service)… À côté de ça, t'as évidemment des vendeurs de solutions à ce problème… Fabuleux…

J'ai un ordinateur portable Dell Latitude 5580. Depuis quelques jours, appuyer sur F2 ne me permet plus de renommer un fichier dans Caja (l'explorateur de fichiers de Mate) : cela baisse le volume sonore. C'est bien le rôle de F2 quand j'appuie sur la touche « Fn ». Mais là, je n'appuie pas, donc ça devrait générer un « F2 ».

Redémarrer le système est vain (mais dans le doute…). Soulever la touche « Fn » avec un objet fin (au cas où de la crasse bloque la touche) est vain.

Au final, il faut appuyer deux fois sur Fn+Échap (pourquoi deux fois ? Aucune idée). Le pictogramme montre un cadenas nommé « Fn », il s'agit donc du mode verrouillage des touches de fonction. Première fois que je vois ça, mais soit.

Pourquoi ce problème est apparu subitement ? Parce qu'il y a quelques jours, j'ai fait une présentation, donc j'ai appuyé sur Fn+F8 afin de partager mon écran. Cela a bien activé le mode bureau étendu, mais pas le mode clone (même image sur les deux écrans), donc j'ai appuyé partout, et probablement sur Fn+Échap.

Résumé : si t'utilises un Cisco ASA pour fournir un service de VPN TLS et que des utilisateurs GNU/Linux qui utilisent openconnect rencontrent l'erreur « Server certificate verify failed: signer not found », vérifie que ton ASA envoie bien le certificat x509 intermédiaire en sus de son certificat client / feuille au client lors de l'échange TLS.

Nous utilisons notre Cisco ASA pour fournir un VPN TLS. Il se présente auprès des clients VPN avec un certificat x509. Le nôtre expire dans 24 jours. Donc on le renouvelle. Sauf que ça ne fonctionne pas : impossible de charger ce certificat dans ASDM. Aucun message d'erreur explicite.

Nous achetons nos certificats x509 en passant par un groupement d'organisations. Ce dernier a fait le choix de changer d'autorité de certification. Le certificat x509 de la nouvelle autorité encapsule une clé RSA de 3072 bits (contre 2048 bits pour l'ancienne) et il est signé en utilisant la fonction de condensation SHA-384 (contre SHA-256 pour l'ancien). J'imagine que l'une de ces propriétés ne convient pas à notre Cisco ASA dont le logiciel n'est plus à jour (son remplacement est en cours, mais ça traîne au-delà de nos prévisions pessimistes qui nous ont conduit à ne plus renouveler le support de l'ASA).

Pour dépanner, nous décidons d'utiliser un certificat Let's Encrypt. Car, au niveau technique c'est ce qu'on a toujours eu : RSA 2048 bits + SHA-256. De plus, c'est la manière la plus simple et rapide (pas de procédure d'achat à déclencher, on tire un certificat, on teste et on voit direct le résultat). Notre ASA accepte le certificat. \o/ Victoire ?

Sur un système GNU/Linux, nous conseillons le client VPN openconnect, une implémentation libre pour plusieurs VPN TLS (Cisco, Juniper, etc.) qui s'intègre à GNOME network-manager. Depuis le changement de certificat x509, nos utilisateurs reçoivent une erreur :

$ sudo openconnect vpn.monorganisation.example
POST https://vpn.monorganisation.example/
Connected to 192.0.2.1:443
Négociation SSL avec vpn.monorganisation.example
Server certificate verify failed: signer not found

Certificate from VPN server "vpn.monorganisation.example" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
    --servercert pin-sha256:xAj8efLob9rYcspJ8p+2J+K9qTJlgsW1m300Ls+VyCs=
Enter 'oui' to accept, 'non' to abort; anything else to view: oui

Même erreur avec openconnect sur Android. Aucune erreur avec winwin + AnyConnect. Aucune erreur sur Apple (Mac OS, IOS), mais c'est normal : nous préconisons l'utilisation d'IPSec.

Qu'est-ce qui ne va pas ?

$ openssl s_client vpn.monorganisation.example:443
CONNECTED(00000003)
depth=0 CN = vpn.monorganisation.example
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = vpn.monorganisation.example
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = vpn.monorganisation.example
   i:C = US, O = Let's Encrypt, CN = R3
---

Hum. Le VPN envoie uniquement son certificat (dit aussi certificat client ou certificat feuille). Celui-ci est signé par un certificat intermédiaire (dans le cas de Let's Encrypt, et jusqu'en 2025, il se nomme « R3 ») qui n'est pas communiqué par le serveur. Or, un certificat intermédiaire est jamais livré dans un catalogue / magasin des autorités de certification, car ce n'est pas son rôle. Donc, la bibliothèque TLS (OpenSSL pour openssl s_client et GnuTLS pour openconnect) échoue sur la vérification du certificat feuille.

Pour que le VPN ASA envoie aussi le certificat intermédiaire, il suffit d'ajouter ce dernier dans ASDM => « Configuration » => « Device Management » => « Certificate Management => CA Certificates ».

Plus d'erreur. \o/

$ openssl s_client vpn.monorganisation.example:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = vpn.monorganisation.example
verify return:1
---
Certificate chain
 0 s:CN = vpn.monorganisation.example
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Pourquoi ça fonctionnait avec AnyConnect ? Peut-être que celui-ci désactive la vérification du pair lors de l'échange TLS ou qu'il est moins stricte, ce qui est une très mauvaise idée dans tous les cas.

Sur l'iDRAC d'un serveur Dell, je veux récupérer l'état d'un composant en utilisant le protocole SNMP. Dell complète les bases de données standardisées interrogeables en SNMP avec la sienne (ce qu'on nomme un module MIB, l'ensemble des bases de données agrégées sous forme arborescente est nommée MIB).

Première question : comment connaître l'OID (l'identifiant unique) d'un objet défini dans un module MIB afin de le consulter en SNMP ?

Généralement, chercher le nom de l'objet sur un moteur de recherche web suffit. Dans mon cas, chercher « systemStateIDSDMCardDeviceStatusList » conduit à des résultats fort bien présentés : oidref et observium.org. L'OID est 1.3.6.1.4.1.674.10892.5.4.200.10.1.61

Mais si l'on veut trouver par nous-même, au cas où une MIB ne soit pas aussi bien indexée ?

Le début d'un OID est normalisé : .1.3.6.1. .1.3.6.1.2.1 pour la très populaire MIB-II. .1.3.6.1.4.1 pour les sociétés commerciales privées. Mais la suite dépend de Dell (dans mon cas).

On peut télécharger la MIB et l'étudier avec un éditeur de texte. On cherche notre objet par son nom (« systemStateIDSDMCardDeviceStatusList » dans mon cas). On lit « ::= { systemStateTableEntry 61 } ». Cet objet a donc l'ID 61 relativement à l'objet « systemStateTableEntry ». On remonte l'arborescence : l'objet « systemStateTableEntry » a l'ID 1 relativement à l'objet « systemStateTable » qui, lui-même, a l'ID 10 relativement à l'objet « systemStateGroup » qui a l'ID 1.3.6.1.4.1.674.10892.5.4.200. L'OID absolu que nous cherchons est donc 1.3.6.1.4.1.674.10892.5.4.200 + .10.1.61 + .1 soit 1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1. Pourquoi j'ai ajouté un « 1 » à la fin ? Car c'est comme ça que l'on consulte la case d'un tableau en SNMP.

Et si l'on n'a pas envie de s'embêter avec ce que je viens de raconter ? On utilise le logiciel snmptranslate de la trousse à outils net-snmp (nom du paquet Debian : snmp). Tout est dans la documentation, mais je vais répéter :

• Trouver les endroits où sont stockées les modules MIB : snmptranslate -Dinit_mib .1.3 2>&1 | grep MIBDIR. Sous Debian, il y a des chemins dans /usr/share (si l'on dépose une MIB dedans, le dossier ne sera pas supprimé quand on supprimera le paquet snmp…) et ~/.snmp/mibs ;
  
  
• Créons donc ce deuxième dossier : mkdir -p ~/.snmp/mibs ;
  
  
• On télécharge la MIB IDRAC-MIB-SMIv2 et on la dépose dans le dossier créé à l'étape précédente ;
  
  
• Ce module MIB dépend d'autres modules MIB. Il faut donc les installer, sinon on aura les erreurs « Cannot find module (SNMPv2-SMI): At line 39 in /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib », « Cannot find module (SNMPv2-TC): At line 41 in /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib », « Undefined identifier: enterprises near line 146 of /home/guigui/.snmp/mibs/IDRAC-MIB-SMIv2.mib » et le bout de MIB de Dell ne sera pas chargé (« Unlinked OID in IDRAC-MIB-SMIv2: dell ::= { enterprises 674 } »). Pour récupérer les autres MIBs avec Debian, il faut installer le paquet non-free snmp-mibs-downloader car tous les modules MIB ne sont pas libres. Les MIBs seront téléchargées durant l'installation du paquet ;
  
  
• On peut enfin convertir un nom en OID : snmptranslate -IR -On IDRAC-MIB-SMIv2:systemStateIDSDMCardDeviceStatusList.

Deuxième question : comment charger / ajouter une MIB à snmpget / snmpwalk afin d'utiliser le nom d'un objet pour y accéder ?

Nous venons de faire cela pour répondre à la question précédente.

Nous pouvons récupérer la valeur d'un objet à partir de son nom : snmpget -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> IDRAC-MIB-SMIv2:systemStateIDSDMCardDeviceStatusList.1 (là non plus, on n'oublie pas le « .1 » final afin d'entrer dans la case du tableau).

On peut toujours récupérer la valeur de l'objet à partir de l'OID qu'on a trouvé ci-dessus : snmpget -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> 1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1.

Et si l'on veut que snmpget / snmpwalk résolvent le nom d'un OID pour nous ? snmpwalk -m +IDRAC-MIB-SMIv2 -v2c -c <COMMUNAUTÉ> <nom_DNS_iDRAC> 1.3.6.1.4.1.674.10892.5.4.200.10.1. Et si préciser « -m +IDRAC-MIB-SMIv2 » est trop pénible, tu remplaces la ligne « mibs : » par « mibs +IDRAC-MIB-SMIv2 » dans /etc/snmp/snmp.conf.

Résumé : présentation rapide de Dell IDSDM (système d'exploitation d'un serveur sur deux cartes SD redondées), du processus de résolution d'une banale panne de carte SD, des manières de superviser l'état des cartes SD et du module IDSDM en ligne de commande et à distance, et des limites de la techno (faux positif, remplacer une carte SD nécessite d'éteindre le serveur et de redémarrer iDRAC, logistique pour remplacer régulièrement les cartes SD, peu de documentation). Une petite anecdote mettant en exergue la démesure de la logistique de Dell sera narrée.

Notre supervision râle : l'un de nos hyperviseurs ne remonte plus d'info. Ping OK. Impossible d'établir une connexion SSH. Les machines virtuelles hébergées dessus fonctionnent toujours sans problème. Impossible de piloter les machines virtuelles (allumer/éteindre, console, migrer sur un autre nœud du cluster) depuis les autres hyperviseurs du même cluster.

Dans la salle serveurs (mais la console iDRAC aurait affiché la même chose), l'écran affiche une palanquée d'erreurs d'écriture puis de lecture sur dm-0 (probablement le device virtuel associé au conteneur LVM (LV) qui contient la racine du système).

iDRAC confirme : les deux cartes SD sont mortes. La première est morte le 13/12/2020, l'autre le 08/01/2021.

IDSDM

Ha, oui, on utilise la techno Dell Internal Dual SD Module (IDSDM). Un module (une carte électronique fille branchée sur la carte mère du serveur, voir la page 2 du whitepaper de Dell), deux cartes SD, les écritures se font sur les deux cartes SD et les lectures sur celle du premier slot tant qu'elle est opérationnelle (comme du RAID 1), et l'on installe un système d'exploitation dessus. Le système voit les cartes SD comme un disque dur SATA (/dev/sdX).

L'intérêt ? Séparer le système d'exploitation des VMs sans pour autant immobiliser 2 slots pour disques dur (afin de faire un RAID 1 pour le système), ce qui réduit l'espace de stockage disponible pour les machines virtuelles. Il y a 10 slots sur un serveur 1U donc 10 disques durs maximum dont 1 est perdu si l'on fait du RAID 5 (c'est comme ça que ça fonctionne) et encore 1 si l'on veut du hot spare (disque de secours qui remplacera, sans intervention humaine, un disque défectueux), alors si l'on retire encore deux disques pour le système… Cependant, deux PV LVM sur une même grappe RAID produiraient environ le même résultat de séparation sans immobiliser deux slots.

Évidemment, et c'est un tort, nous avons mis en place aucune optimisation afin de limiter les écritures sur les cartes SD : ni log2ram (qui stocke les journaux en RAM et les écrit, par paquet, à intervalle régulier sur le support de stockage), ni option de montage « noatime », rien.

On vérifie la santé des deux autres hyperviseurs du même cluster. Ho, une carte SD sur les deux est morte dans un autre hyperviseur depuis le 28/12/2020. Le troisième hyperviseur est sain.

La folie du monde

Appel téléphonique au support Dell. On nous dit que beaucoup de clients installent un système sur IDSDM (en même temps, quel vendeur dira que son produit est inutilisé ?!). Il y a rien d'anormal, qu'on nous dit, la durée de vie des cartes SD est de 2 ans et demi / 3 ans (pour info, nos serveurs sont en prod' depuis un peu moins de 2 ans). Lourde insistance du support pour remplacer les modules en sus des cartes SD… Soit.

Nous sommes vendredi midi. Nous sommes fermés le samedi. Nous avons contracté un support ProSupport H+4. Que va faire Dell ? Attendre que le manager revienne de la cafèt’ (sisi :D), trouver 2 modules et 3 cartes SD dans l'entrepôt situé dans la grande ville la plus proche de chez nous et une 4e carte SD dans l'entrepôt d'une autre grande ville. Deux camions de livraison sont partis de deux villes différentes pour nous livrer 4 cartes SD et deux bouts d'électronique en moins d'une après-midi ! Livraison à 18 h et 20 h. :O

Deux sentiments m'ont accompagné tout cet après-midi-là.

• D'un côté, la virtuosité de l'humain pour trouver des solutions. Connaître l'état des stocks en temps réel dans tous les entrepôts du monde. Gérer ce stock (et si t'as eu des cours d'éco/gestion, tu sais que c'est toute une histoire). Contractualiser avec des sociétés de livraison. Filer des ordres de livraison d'un claquement de doigts. T'imagine le système d'information de malade qu'il faut afin de faire tout ça ?! Et encore, j'oublie nombre de paramètres comme faire remuer des humains.
  
  
• D'un autre côté, la folie et la démesure de l'humain. Toute une chaîne humaine s'est activée et deux putain de camions ont fait 660 km (aller-retour) en une demi-journée parce que des gus ont pleuré dans les jupes d'une multinationale et ont payé le bon contrat. L'écologie, ça sera pour demain, promis.

La chance

Bon ben on part sur la réinstallation de Proxmox sur notre premier hyperviseur.

Avant ça, on sort les cartes SD et on les tripote entre nos doigts comme la puce d'une carte bancaire muette. Dans le doute…

On tente de démarrer sur l'une des cartes SD : échec. Avec un autre ordinateur, on parvient à ouvrir le VG LVM mais impossible de monter le système de fichiers ext4 : impossible de lire le superblock, input/output error.

En revanche, la deuxième carte SD fonctionne : le serveur démarre ! Tout fonctionne comme avant. Pas d'erreur apparente.

On installe une carte SD neuve dans le deuxième slot. Durant la phase POST du BIOS (tu sais, quand il vérifie la RAM, quand il initialise le contrôleur RAID, etc.), il nous est demandé « SD Card x has been replaced and needs to be rebuilt. […] Press to rebuild or to continue without rebuilding. ». Nous appuyons sur Y. Contrairement à ce que mentionne le whitepaper Dell sus-mentionné, un message nous informe que la reconstruction (la copie d'une SD sur une autre, quoi) se fera en tâche de fond et le démarrage continue.

Sur notre deuxième hyperviseur, il nous suffit de remplacer la SD défectueuse par une neuve et de valider la reconstruction lors du démarrage. Reconstruction qui, elle aussi, s'effectuera en tâche de fond.

On notera que nous avons fait le choix de ne pas remplacer les modules, car nous ne les pensons pas défectueux.

Nous avons également fait le choix de ne pas remplacer les cartes SD qui semblent être fonctionnelles afin que toutes les cartes SD ne tombent pas en panne en même temps.

Sur le premier hyperviseur, j'espère que nous n'avons pas recopié les erreurs d'une des vieilles cartes SD sur les neuves. Pour l'instant : RÀS.

Retour à la normale ?

Comment savoir quand la reconstruction d'une carte SD est terminée et que nous sommes revenus à l'état nominal ? D'après les documentations que l'on trouve sur le web, cela se passe dans le BIOS ou dans l'iDRAC, mais, pour que ce dernier mette à jour l'état des cartes SD, il faut le redémarrer… … …

Après 30 minutes, nous redémarrons iDRAC, et, en effet, tous les indicateurs présentés sont repassés au vert. Je parle du tableau de bord et de la section « Média amovible » dans le menu « Système » puis « Présentation générale » dans laquelle les items « SD » (ou « VFLASH SD »), « IDSDM SD1 » et « IDSDM SD2 » doivent être en « Status » OK et l'« État de la redondance » doit avoir la valeur « Total ». Note : sur l'item « SD » (ou « VFLASH SD »), la « Condition de la connexion » est toujours définie à « Absent », même sur un serveur tout neuf.

Limites d'IDSDM

Supervision

Les cartes SD sont des consommables qu'il faut changer régulièrement. Cela implique de les superviser. Dans notre supervision actuelle (on ne va pas aller manuellement consulter des interfaces web supplémentaires), ce qui implique des outils CLI (exit, donc, le lourdingue Dell OpenManage). Cette supervision s'effectue depuis iDRAC. C'est un peu chiant à trouver :

• Comme il ne s'agit pas d'un RAID, megacli, que l'on utilise déjà pour superviser notre RAID, est inutile ;
  
  

• En plus d'être toujours aussi pénible à installer, RACADM propose rien de spécifique. On peut toutefois remonter l'info si l'on cherche en analysant les journaux ;

• Si l'on active IPMI dans iDRAC (avec la version 9, cela se passe dans le menu « Paramètres de l'iDRAC » => « Connectivité » => « Paramètres IPMI » => « Activer IPMI sur le LAN ») :

  • ipmitool -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sensor get SD retourne rien d'exploitable (idem pour les capteurs « SD1 » et « SD2 ») ;
    
    
  • ipmitool -v -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sdr list | grep -A 5 ': SD' retourne un énigmatique « sensor reading : 0h » dont on ne trouve pas d'explication dans un quelconque document Dell, et comme il s'agit, a priori, d'une valeur spécifique à un constructeur, une extrapolation depuis d'autres documentations est risquée ;
    
    
  • ipmitool -I lanplus -H <nom_DNS_iDRAC> -U <identifiant> sensor | grep '^SD' affiche les valeurs « 0x0180 » (pour « SD1 » et « SD2 ») et « 0x0080 » (pour « SD ») dont quelques sites web obscurs nous assurent que ça veut dire que tout est OK… Cela se confirme vaguement en regardant l'état d'autres capteurs, mais rien est plus trompeur que l'auto-persuasion ;
• snmpget -v2c -c public <nom_DNS_iDRAC> .1.3.6.1.4.1.674.10892.5.4.200.10.1.61.1 retourne une valeur qui est documentée dans la MIB iDRAC-SMIv2 téléchargeable sur le site web de Dell (03 03 = les deux cartes SD sont OK, le premier octet étant la première carte SD, l'autre la deuxième). L'état du module IDSDM lui-même est disponible à l'OID .1.3.6.1.4.1.674.10892.5.4.200.10.1.59.1 (même codes retour). SNMP me semble être la moins mauvaise solution pour superviser IDSDM.

Autre

• Le module et les cartes SD sont situés à l'intérieur du serveur. Pour remplacer une carte SD défectueuse, il faut donc éteindre ledit serveur. Ce n'est pas la mort, on peut prévoir des créneaux de remplacement réguliers (nous avons des périodes d'inactivité planifiées chaque année). Mais rien dit qu'une carte SD ne tombera pas en panne en dehors de ces créneaux, et, là, on ne voudra très probablement pas attendre le prochain créneau. Alors, oui, avec la migration à chaud des machines virtuelles au sein d'un même cluster, on peut s'en sortir sans trop d'efforts, mais ça ne me convainc pas des masses : il reste la logistique (ouvrir un ticket chez Dell. Voudront-ils envoyer des SD tant qu'il n'y a pas de panne ? Réceptionner les cartes. Préparer la maintenance. Effectuer la maintenance). D'un autre côté, est-ce vraiment différent d'un RAID avec des disques durs, au fond ? Pas sûr ;
  
  
• IDSDM me semble être immature. Il nous a marqué une carte SD comme étant défectueuse alors qu'elle semble être saine (et qu'elle est toujours en production). J'aimerais ajouter que Dell, qui insiste pour remplacer les modules eux-mêmes, génère un doute sur la fiabilité du produit, mais, après réflexion, j'ai déjà vu, à plusieurs reprises, Dell changer des composants sans trop de rapport avec une panne juste parce qu'ils en ont les moyens et qu'ils veulent satisfaire la clientèle, donc on peut rien en déduire ;
  
  
• Pour identifier si le système est revenu à l'état nominal après le remplacement d'une carte SD, il faut redémarrer iDRAC à l'aveugle (redémarrer trop tôt : la copie d'une carte SD à l'autre ne sera pas terminée)… Bricolage détecté ;
  
  
• On trouve assez peu de documentation sur IDSDM : comment le superviser, le coup du redémarrage obligatoire de l'iDRAC, la présentation de l'état nominal dans iDRAC, etc.