Hidden Console on Zwindler's Reflection

Changer le nom du vCenter 6 (vCSA)

Tue, 27 Dec 2016 12:55:00 +0000

Changer le nom du vCenter, facile ?

La version 6 de l’appliance vCSA est sortie depuis un moment déjà (début 2015). Et pas mal de choses ont changés depuis les premières versions que j’ai pu tester ! Au début, c’était moins léché, peu efficace (un SUSE très gourmand en RAM et avec moins de fonctionnalités). Et puis au fur et à mesure des versions, ça s’est amélioré.

Si vous souhaitez un tutoriel sur l’installation du vCSA 6, je vous conseille d’aller voir le très bon vladan.

Dans les versions précédentes, j’ai souvent du me connecter sur le shell du Linux pour modifier des paramètres qui ne pouvaient pas être modifiés autrement, comme le layout du clavier (Qwerty par défaut !) ou la quantité de RAM allouée à chaque composants du vCSA pour réduire son empreinte mémoire.

Dans cette nouvelle version, une surcouche a été ajoutée en console, ce qui change drastiquement l’administration ! Pour les non linuxiens, c’est certainement plus simple.

Je me suis donc demandé comment changer le hostname du vCenter que je venais d’installer. Et la première chose que j’ai tentée a été de retrouver un bash, pour rester dans ce que je connaissais.

Bash 2 en 1

Voilà à quoi ressemble la console lorsqu’on s’y connecte.

VMware vCenter Server Appliance 6.0.0.10000
Type: vCenter Server with an embedded Platform Services Controller
Using keyboard-interactive authentication.
Password:
Last login: xxx from xxx
Connected to service
* List APIs: "help api list"
* List Plugins: "help pi list"
* Enable BASH access: "shell.set --enabled True"
* Launch BASH: "shell"

A première vue, on peut toujours lancer un bash. Chouette !

Command> shell
Shell is disabled.

Ok…

Command> shell.set --enabled True
Command> shell
---------- !!!! WARNING WARNING WARNING !!!! ----------
Your use of "pi shell" has been logged!
The "pi shell" is intended for advanced troubleshooting operations and while
supported in this release, is a deprecated interface, and may be removed in a
future version of the product. For alternative commands, exit the "pi shell"
and run the "help" command.
The "pi shell" command launches a root bash shell. Commands within the shell
are not audited, and improper use of this command can severely harm the
system.

C’est donc clair. Le shell est encore là, pour l’instant. Mais il faut explicitement l’activer pour l’utiliser et il est clairement indiqué que ce n’est pas comme cela qu’il faut administrer votre vCSA car cette possibilité (dépréciée) sera probablement retirée à l’avenir.

La nouvelle façon d’administrer la console

Du coup, retour en mode non-bash pour jeter un œil aux possibilités offertes par la nouvelle méthode d’administrer en CLI le vCSA.

Command> help api list
Supported API calls by this server:
com.vmware.appliance.version1.access.consolecli.get
com.vmware.appliance.version1.access.consolecli.set
com.vmware.appliance.version1.access.dcui.get
com.vmware.appliance.version1.access.dcui.set
com.vmware.appliance.version1.access.shell.get
com.vmware.appliance.version1.access.shell.set
com.vmware.appliance.version1.access.ssh.get
com.vmware.appliance.version1.access.ssh.set
com.vmware.appliance.version1.localaccounts.user.add
com.vmware.appliance.version1.localaccounts.user.delete
[...]
com.vmware.appliance.version1.services.list
com.vmware.appliance.version1.services.restart
com.vmware.appliance.version1.services.status.get
com.vmware.appliance.version1.services.stop
com.vmware.appliance.version1.system.update.get
com.vmware.appliance.version1.system.update.set
com.vmware.appliance.version1.system.version.get
com.vmware.appliance.version1.timesync.get
com.vmware.appliance.version1.timesync.set

On voit qu’il existe un nombre relativement important de commandes. En réalité, à bien regarder, cela correspond finalement à l’ensemble des opérations que l’on peut réaliser directement depuis l’interface graphique web.

Cela n’a donc rien à voir avec l’accès direct qu’on peut avoir sur un Linux en shell, ce qui d’expérience est pourtant utile. Une fois de plus, VMware nous enferme dans le mode boite noire, ce qui aura le don d’agacer les habitués du monde Linux/Unix.

Je ne vais pas tout traiter dans ce tutoriel et juste me concentrer sur l’exemple que je cite en début d’article. Pour autant, vous avez l’accès à l’ensemble de la documentation sur le site de VMware (lien mort comme tout chez VMware).

Les commandes sont assez explicites et assez simples, avec une commande « get » et « set » et des « –help » à chaque fois.

Command> com.vmware.appliance.version1.networking.dns.hostname.get
Name: toto01
Command> com.vmware.appliance.version1.networking.dns.hostname.set --help
Usage:
com.vmware.appliance.version1.networking.dns.hostname.set
[--help/-h] --name STR
Description:
Set the Fully Qualified Domain Name.
Input Arguments:
--name STR
FQDN.
Command> com.vmware.appliance.version1.networking.dns.hostname.set --name vcenter.zwindler.fr
Command> com.vmware.appliance.version1.networking.dns.hostname.get
Name: vcenter01.zwindler.fr

Conclusion

Au final, c’est assez simple à utiliser, même si assez limité !

On ne peut pas dire que ce soit étonnant de la part de VMware : leur but, c’est bien entendu de faire un produit simple d’utilisation et éviter aux gens d’aller bidouiller.

Ainsi, il permettent au plus grand nombre d’administrer un vCenter sous Linux sans pour autant avoir des connaissances dans le domaine.
Personnellement, ça me rappelle la « hidden console » des ESXi lors des premières releases, qu’on ne pouvait accéder qu’après une combinaison de touches.

A vos shells limités ! ;-)

ESXi 4.0 : Explorons l’Hidden Console Part 3

Fri, 10 Sep 2010 08:11:49 +0000

Il y a un moment, j’avais promis une dernière partie sur l’hidden console, qui n’est jamais venue parce que j’ai zappé. Du coup maintenant ce n’est plus très frais dans mon esprit. Je vais quand même faire un effort pour me souvenir de l’essentiel dans cette partie où j’aborderai surtout la création d’utilisateurs supplémentaires (plutôt que de n’avoir que root).

Enfin, j’essayerai d’écrire un dernier article qui parlera de l’application de patchs à l’aide des bundles, le tout en local (ou via SSH).
Quelques autres infos que je ne sais pas vraiment où mettre : depuis la 4.1, il est possible d’activer depuis le menu gris/jaune l’hidden console, qui n’est plus vraiment cachée, du coup. Cette « toute nouvelle fonctionnalité » s’appelle le Tech Support Mode, et vous permet de faire … la même chose qu’avant! En gros, accès en direct à la console, mais aussi support d’accès à distance via SSH. Ça évite la petite gymnastique VIesque, ce qui peut rassurer certains.
Mais revenons à nos moutons virtuels…

Accéder en SSH sur votre ESXi, c’est bien, mais si vous êtes obligés de le faire en temps qu’utilisateur root à chaque fois, des considérations quant à la sécurité relative de la chose vont peut être vous faire tiquer, et vous aurez bien raison. Du coup, la première idée qui vous vient à l’esprit est « je n’ai qu’à créer un nouvel utilisteur », et vous aurez la encore totalement raison. Ca ne sera peut être pas forcément très sécurisé, mais c’est toujours mieux que de devoir passer votre mot de passe root à chaque fois.

Dans un vieux tuto du net, j’ai lu qu’il n’était pas possible d’avoir un autre utilisateur que root pour faire du SSH avec ESXi. Ce n’est pas tout à fait vrai…

Déjà, il faut savoir qu’il est possible de créer des utilisateurs directement depuis le client vSphere. Ok, cela demande un petit effort car dans la version 4.0 U1 (celle dont je dispose, mais c’est probablement pareil depuis au moins VMware Infrastructure) du client, l’opération fonctionne très bien. Ce genre d’utilisateurs peuvent être utilisés pour donner accès à une machine spécifique à un utilisateur, ou bien, comme dans l’exemple qui va suivre, créer un compte possédant des droit read-only pour servir de compte de monitoring dans Nagios (avec check_esx3, par exemple).

Dans la console vSphere, cliquer sur votre serveur, sélectionnez l’onglet groupes et utilisateurs. Dans la partie utilisateurs, faites un clic droit, puis ajouter. Une fenêtre apparait, entre toutes les informations nécessaires, c’est à dire au moins un login, un password, et ajoutez le au groupe user.

Une fois créé, il est possible d’accorder des permission dans l’onglet permissions du serveur. Clic droit dans le tableau qui s’affiche, ajouter permission, une fenêtre s’ouvre. Dans cette fenêtre, il faut ajouter un utilisateur, puis lui appliquer le privilège qui convient. Dans l’exemple, je lui attribue Read-only. Validez, et hop, c’est fait, nous disposons d’un utilisateur non privilégié qui nous servira pour nos sondes nagios.

Mais si on essaye de se connecter, effectivement, on se rend compte que cet utilisateur read_only_guy n’a pas accès à SSH. Pourquoi? Tout simplement parce qu’il n’a pas accès à la console tout court. Pour des raisons de sécurité, les utilisateurs créés dans le client vSphere ne peuvent pas se loguer sur la console. Ça parait logique : un utilisateur à qui vous avez donné les droits sur une VM n’a aucune raison d’aller se balader sur votre serveur (encore moins quand on est dans la pensée VMware qui est que seuls les techniciens VMware ont le droit d’utiliser la console)…

« Comment fonctionne cette limitation? ». Vous allez rire, mais c’est tout simplement que le shell utilisé lors de la connexion de l’utilisateur est un programme qui refuse tout accès.

Sous Unix, quand on veux créer un utilisateur pour un service (apache par exemple) mais qu’on ne veux pas que quelqu’un utilise se compte pour se connecter. Au lieu d’attribuer un shell /bin/sh (ou /bin/ash dans ESXi 4) au compte, on lui attribue /bin/false, qui renvoie toujours « faux ». Plus récemment, pour être plus explicite, on spécifie que le compte se connecte avec un shell /sbin/nologin, même si c’est strictement la même chose.

Pour pouvoir disposer d’un compte SSH non-root sur votre ESXi, vous avez donc deux solutions :

Soit vous créez un compte ssh_guy depuis vSphere, et vous allez vous connecter en root, le temps d’éditer le fichier /etc/passwd pour remplacer**/bin/false** par /bin/ash dans la ligne correspondant à votre utilisateur. Enfin, il faut impérativement lui créer un dossier home, sans quoi il pourra se loguer mais aucun prompt n’apparaitra.

# mkdir /home
# mkdir /home/ssh_guy

Soit vous créez directement le compte avec le shell qui vous convient depuis votre accès root, de la façon suivante :

# mkdir /home
# useradd ssh_guy-s /bin/ash
# passwd ssh_guy
[entrer le mot de passe pour ssh_guy]

Dans un soucis de sécurisation de la connexion SSH, vous pouvez donc imaginer un scénario où le login root pour SSH est interdit, et de passer par un utilisateur ssh_guy qui passe root si nécessaire grâce à su - , ce qui évite de devoir faire circuler le mot de passe root partout sur le réseau.

Pour interdire le login root via SSH, il suffit de modifier votre inetd.conf en ajoutant un -w à la fin de la ligne correspondant à l’accès SSH. Moyennant un redémarrage du démon inetd, il ne devrait plus être possible de se loguer directement root via SSH sur votre ESXi.

ESXi 4.0 : Explorons l’Hidden Console Part 2

Fri, 30 Apr 2010 13:49:03 +0000

Dans la partie 1, j’introduisais la console cachée de l’ESXi (aussi bien valable pour la version 3.5 que la version 4.0) et vous donnais LA tips hyper répandue pour y accéder. Allons voir un peu plus loin.

La console de l’ESXi ressemble beaucoup à un environnement en ligne de commande du même type qu’un système Unix. Et pour cause! Il s’agit en fait d’une version simplifiée appelée Busybox. La plupart des commandes Unix incontournables et l’arborescence typiques sont donc de la partie:

ls : lister le contenu du dossier courant
cd [destination]: changer de répertoire courant
cp [destination] : copier des fichiers
mv [destination] : déplacer des fichiers
cat [fichier] : afficher à l'écran le contenu d'un fichier, mais aussi utilisé pour écrire dans des fichier en redirigeant les flux vers les entrées/sorties standards
more [fichier] : afficher à l'écran le contenu d'un fichier
vi : l'Editeur de texte (avec un grand E)
ps : lister les processus
grep : recherches dans un texte
kill : envoyer des signaux aux processus, notamment pour les arrêter de façon peu orthodoxe (hin hin hin!)
/ la racine
/etc pour l'aspect configuration du système et des démons/programmes
dev pour accéder aux périphériques, dont les partitions du disque
...

J’en passe… A ces classiques s’ajoutent les commandes spécifiques à VMWare, qui permettent la configuration de l’ESXi telle que nous la connaissons :

esxtop : l'équivalent de top sous Unix pour voir la charge prise du serveur
esxcfg-* : liste de commandes pour modifier des paramètres de l'ESXi. Ces commandes sont les équivalents des commandes vicfg-* utilisée par le vCli. Je citerai notamment *esxcfg-swscsi* qui permet de gérer l'émulation logicielle du support du scsi par l'ESX(i), qui m'a notamment permit de débugger un ESX qui ne voyait pas des LUN sur le réseau (et mon vCenter était HS).
esxupdate : la commande qui permet de mettre à jour le système ESX(i)
vim-cmd : commande permettant d'accéder à des informations concernant les machines virtuelles, et effectuer certains opérations de bases sur celle ci (du même genre qu'avec la GUI).

Le détail de ces commandes peut se trouver dans le document décrivant l’utilisation du VCLI sous vSphere 4 (lien cassé, j’utilise Internet Archive).

A partir de là, un des trucs funs et simples à faire est l’activation du ssh. Et oui, là encore, VMWare nous mens, car ESXi est tout à fait capable de communiquer en SSH, il suffit de configurer le démon inetd correctement pour qu’il gère ssh (il n’y a pas de sshd dédié).

Ouvrir la configuration du démon inetd à l’aide de vi /etc/inetd.conf (pour les neophytes de vi, accrochez vous, et lisez quelques tutos sur le net, sous peine de vous arracher les cheveux)
Supprimer le # devant la ligne qui commence par « ssh » (le # sert à commenter la ligne)
Entrer ps aux | grep inetd et récupérer le pid ID du processus inetd actif
Entrer kill -HUP [ID]. On tue le processus inetd pour éviter des soucis lors du redémarrage des services
Entrer services.sh restart pour redémarrer les agents de management

Une fois activé, le SSH permet(par exemple) d’effectuer des transferts depuis un client connecté sur le même réseau vers notre ESXi. Par exemple, on peut utiliser un client WinSCP pour se connecter sur le serveur à l’aide du protocole SCP.

Dernier point sur lequel je vais revenir encore et toujours : Le SSH sur l’ESXi n’est pas une fonctionnalité prévue. En conséquence, son utilisation peut provoquer des dysfonctionnements de votre système. Je vous déconseille donc de l’utiliser, sauf si vous n’avez vraiment pas d’autres choix. De plus, d’éminents blogueurs ont l’air de penser que le SSH de notre Busybox n’étant pas vraiment configuré, l’utilisation de celui ci puisse présenter une faille en terme de sécurité. N’y connaissant pas grand chose en sécurité du protocole SSH s’il est mal configuré, je m’en remet à leur expertise et prône le principe de précaution!

Prochaine partie: Mettre à jour l’ESXi depuis l’hidden console, et autres subtilités en vrac sortant de mon REX

HF !

ESXi 4.0 : Explorons l’Hidden Console Part 1

Wed, 28 Apr 2010 08:32:20 +0000

Je ne vous apprendrai probablement rien si vous connaissez un peu le mécanisme de la console cachée sur l’ESXi, mais j’aimerai apporter quelques précisions pour ceux qui ne connaissent pas.

Donc, pour ceux qui débutent, ESXi, la version non soumise à licence (comprennez « gratuite ») du paravirtualiseur de VMWare est une version allégée, et n’a donc pas de console en ligne de commande à la Unix comme celle de l’ESX, selon les specs fournies par VMWare. Idem pour le SSH. Qu’ils sont vilains menteurs sur VMWare. Elle existe, elle est juste caché, non supportée, et utilisé par l’assistance technique.

Sur le net, j’ai trouvé une multitude de blog offrant LA solution pour accéder à cette « hidden console » et activer par la même occasion le SSH. Cependant, la plupart du temps, la méthode était juste un copier coller d’un autre blog (ce qui n’est pas très gentil) et méritait quelques précisions supplémentaires.

Pour ouvrir la console cachée, la première étape consiste à lancer ESXi jusqu’à arrive à l’écran d’accueil de l’interface de configuration locale. Une fois fait, il est possible d’accéder à la console depuis n’importe quel écran de l’interface. Il faut effectuer les étapes suivantes:

Appuyer [Alt] + [F1], un écran noir avec quelques lignes indiquant la version de l’ESXi doit s’afficher
Entrer le mot « unsupported » au clavier, puis [Entrée]. Ce mot ne s’affiche pas à l’écran, mais s’il a bien été tapé, le mot « password » doit s’afficher à l’écran
Entrer le mot de passe du compte administrateur de l’ESXi, puis valider avec [Entrée]. Attention à bien le taper, vous avez 3 essais. Si vous vous trompez 3 fois de suite parce que vous êtes pressé/stressé, vous vous retrouverez comme moi, avec l’hidden console bloquée jusqu’au reboot de la machine.
Quelques lignes vous avertissant que ce mode n’est pas supporté blablabla doivent s’afficher, suivit d’un prompt. Félicitations

Une petite précision que je n’ai pas souvent trouvé dans les articles des blogs qui parlaient de cette méthode pour activer l’hidden console était le moyen d’en sortir. Pour vous éviter le besoin de devoir bruteforcer les touches du clavier, il suffit d’appuyer sur [Alt] + [F2] pour revenir à l’écran de configuration normal :-)

*Disclaimer : Je ne le dirai jamais assez, ce mode est censé être réservé au support technique VMWare. Toute utilisation hasardeuse pourrait résulter à l’instabilité du système, et l’assistance VMWare se fera un plaisir de vous envoyer balader. Ne venez pas me dire que vous n’avez pas été prévenus, ou que c’est de ma faute, ou . Vous êtes grands, assumez vos bêtises wink.

La suite bientôt (promis)