Récupérer l’accès root sur NSX-T

Que des misères, ma bonne dame ! Nous avons la scoumoune, Murphy a les yeux braqués sur nous en ce moment, les planètes IT doivent être désalignées, nous nous sommes trop approchés du soleil … Je ne vois que cela. Il faudrait qu’on se fasse exorciser, peut-être. Après un incident de production sérieux fin Août, il semble que notre cluster de management NSX-T 2.4.1 n’arrive pas à se remettre de ce douloureux exercice de tolérances aux pannes. Notamment, un des multiples soucis rencontrés concerne l’accès root aux différents managers…

Petit récit des événements : nous somme victimes, il y a quelques semaines, d’un incident de production touchant notre réseau datacenter. Le problème se règle assez vite, mais comme toujours, les conséquences se voient petit à petit. D’une manière générale, tous les transport nodes et nos edges ont très bien réagi. Par contre, le cluster de management, qui contient tout de même les manager ET les controleurs (sensible donc), ne fonctionne pas bien depuis. Au bout de quelques jours de diagnostic, décision est prise de procéder à une restauration de l’environnement (et oui, notre backup fonctionne à nouveau depuis début Juillet ^^, voir ici pour plus d’info).

Las ! Malgré la restauration, nous traînons, depuis lors, pas mal de soucis, dont, très récemment, l’impossibilité de se connecter sous root … embêtant quand le support VMware souhaite investiguer. Nous ouvrons donc un nouveau SR pour ce dysfonctionnement précis, qu’il faut régler en premier avant de s’attaquer aux autres. Je vous fait grâce des détails depuis le début de cette semaine et l’ouverture d’un nouveau SR sur un nième souci du manager, mais au final, j’ai pris le taureau par les cornes et j’ai trouvé le moyen de nous en sortir, au moins pour ce sujet précis de l’accès root.

Voila en détail le problème auquel nous faisions face :
– impossible de se logguer en ssh sour root (même si nous l’avions autorisé lors du déploiement des appliances NSX-T)
– impossible d’utiliser la commande “st e”, commande non documentée mais connue qui permet de lancer une session bash “sous le compte root”
– impossible de booter en mode “single” sur le Linux embarqué, car le boot manager GRUB est bloqué …. par un mot de passe, sans doute celui de root au départ, mais qui ne fonctionne pas plus.

Heureusement, il nous restait une session root connectée sur la console d’un des nodes du cluster de management. Du coup, voici ce que j’ai fait :

Récupérer l’accès au mode “edition” du bootmanager

J’ai commenté les deux lignes dans le fichier /etc/default/grub et modifié le GRUB_TIMEOUT pour me donner un minimum de temps pour prendre la main :

J’ai également commenté les deux lignes verrouillant par password le menu de grub, dans fichier /etc/grub.d/40_custom :

Enfin, j’ai lancé la regénération de la configuration de grub :

Reboot et application de la procédure officielle de reset de mot de passe

Enfin, le moment tant attendu : le reboot ! J’avais enfin accès à GRUB pour démarrer en mode single, comme l’indique la procédure, à consulter ici. J’ai suivi l’ensemble des indications, tout en utilisant un raccourci vis à vis de la création du fichier “/config/vmware/nsx-node-api/reset_cluster_credentials”, qui évite de galérer avec un live-CD ubuntu, et qui consiste à créer le créer ledit fichier dès que la machine a booté, sans attendre que les services NSX-T démarrent (voir ce billet intéressant dont je me suis en partie inspiré).

Après quelques minutes, le cluster dans son ensemble revenait en nominal et j’ai enfin récupéré le précieux sésame !

Alors, certes, ma manipulation n’est valable que si vous avez encore un accès à une session root en cours. Dans le cas contraire, il faut passer plus radicalement par un live-CD, monter le filesystem root et bidouiller directement les fichiers /etc/password et /etc/shadow. C’est un peu plus complexe, mais ça reste utilisable …. tant que votre filesystem root n’est pas chiffré ^^.

Enfin, comme nous avons été pas échaudé par cette affaire de mot de passe, nous avons pris “la liberté” de poser des clefs publiques SSH sur le compte root, histoire, même en cas de perte de problème quelconque sur les credentials systèmes, de conserver un accès technique hors “user/password”.

Il nous reste maintenant à traiter les autres sujets plus “fonctionnels” de nos managers NSX-T. Je vous en reparlerai sans doute dans un prochain billet.