Utiliser le shell de ESXi

Utiliser le shell de ESXi
Extrait du MosX.org
http://www.mosx.org
Utiliser le shell de ESXi
- Dossiers -
Date de mise en ligne : mardi 17 mars 2015
Description :
Jai parlé dans un article précédent de linstallation de VMware ESXi sur nos Mac. Larticle daujourdhui nest pas ciblé uniquement pour les Macs, mais dune
manière générale sur quelques notions à savoir pour la gestion des hôtes ESXi. Ce que je vais présenter ici est utile essentiellement pour les utilisateurs de la
version gratuite de ESXi qui nont pas accès à toutes les fonctionnalités de vSphere, mais pas que&
MosX.org
Copyright © MosX.org
Page 1/11
Utiliser le shell de ESXi
Introduction
Le pré-requis à ce dont je vais parler dans cet article est bien entendu d'avoir activé non seulement le shell , mais
aussi l'accès SSH sur votre serveur ESXi comme indiqué dans l'article sur l'installation de ESXi.
Il y a une chose à savoir à propos de l'hôte ESXi. Le système est démarré sur un disque virtuel, un petit volume créé
en mémoire à chaque démarrage. Cela améliore grandement les performances, mais cela complique également
beaucoup la gestion pour ceux qui ont l'habitude de mettre les mains dans le cambouis des fichiers système de leur
OS.
Je ne vais pas réécrire l'excellent article de virtuallyGhetto sur le sujet (je pourrais le traduire si la demande est faite
et si l'auteur est d'accord, mais je ne suis pas sûr de l'intérêt). Mais pour résumer :
•
•
•
tous les changements de configurations fait à partir des outils VMware (vSphere Client, vCenter, vSphere
toolkits, etc.) sont persistants.
lors de modifications manuelles des fichiers de configuration, la persistance des modifications dépend de ce qui
a été modifié
les fichiers ajoutés au disque de démarrage de ESXi sont par défaut non persistants.
En fait, ESXi fait une sauvegarde régulière de certains fichiers de configuration, vous pouvez obtenir la liste par la
commande suivante :
find /etc -follow -type f -name '.#*' 2>/dev/null | sed -e 's,.#\(.*\),\1,g'
Tous ces fichiers sont sauvegardés régulièrement (toutes les heures et à chaque arrêt du système) par le script
/sbin/auto-backup.sh
. Un système interne sauvegarde également l'état du système de fichier toutes les 10mn en cas d'arrêt inopiné du
système.
Faire des modifications persistantes
Si le fichier que vous modifiez est dans la liste des fichiers sauvegardés automatiquement, la seule chose à faire
pour être tranquille est de lancer le script
/sbin/auto-backup.sh
après vos modifications.
Copyright © MosX.org
Page 2/11
Utiliser le shell de ESXi
Si en revanche vous modifiez, par exemple, la crontab, ou que vous ajoutez des fichiers, il vous faudra alors ruser
pour que les changements restent après un démarrage.
En fait, ce n'est pas très compliqué, l'un des fichiers sauvegardés automatiquement est un script lancé à chaque
démarrage :
/etc/rc.local.d/local.sh
Il suffit donc de modifier ce script pour faire ce que l'on veut qu'il fasse. :)
Modification de la crontab
Pour modifier la crontab, tout se passe également dans le fichier local.sh, mais avec un point important à savoir. Ce
script est lancé après le démarrage de cron, il faut donc relancer cron après avoir modifié la crontab.
Voici donc un exemple d'ajout au fichier
local.sh
pour ajouter à la crontab le lancement d'un script testant la présence de mes différents datastore toutes les heures :
/bin/kill $(cat /var/run/crond.pid)
echo "0
*
*
*
*
/mosx/testDisks.sh" >>/var/spool/cron/crontabs/root
/usr/lib/vmware/busybox/bin/busybox crond
Je commence par tuer le processus cron, puis j'ajoute ma ligne dans la crontab, et enfin, je relance le daemon crond.
Attention ! Sur les hôtes ESXi, l'heure est en UTC/GMT ! vSphere Client adapte l'heure affichée selon les réglages
de la machines cliente. Il n'est pas possible de changer le fuseau horaire et il est donc plus simple de laisser l'hôte
en UTC et de faire les réglages de la crontab en fonction. Il faut juste se rappeler que l'heure se décale 2 fois par
an…
Changement de l'heure
Si vous souhaitez tout de même changer l'heure de votre système pour simplifier la surveillance des logs ou pour
quelque-soit-la-raison, il est alors préférable de changer à la fois l'heure système et l'heure matérielle . Cette
dernière est utilisée par les VMs comme heure par défaut, dans les BIOS par exemple.
Copyright © MosX.org
Page 3/11
Utiliser le shell de ESXi
Premier point, l'utilisation de la commande
date
comme sur les unix/linux ne marche pas pour définir la date et l'heure. Il faut passer par une commande spécifique
de ESXi :
esxcli
. Nous verrons dans un autre article quelques autres exemples d'utilisation de cette commande.
Pour définir la date au 16 mars 2015 10:45:35, vous pourrez écrire la commande suivante :
esxcli system time set -d 16 -H 10 -m 45 -M 03 -y 2015 -s 35
esxcli hardware clock set -d 16 -H 10 -m 45 -M 03 -y 2015 -s 35
Vous pouvez ne mettre qu'un des arguments si vous ne pouvez changer que l'heure, par exemple.
Gestion des scripts et des sauvegardes
J'ai fait une série de petits scripts plus ou moins utiles. Je n'aime personnellement pas lancer des scripts systèmes
depuis un datastore, ne serait-ce que parce que si je change de machine, le datastore change et donc, le chemin
vers le script change.
J'ai donc choisi de mettre l'ensemble de mes scripts dans un dossier nommé mosx à la racine du volume de
démarrage. Mais, comme indiqué plus haut, ce dossier disparaitra au prochain redémarrage de l'hôte ESXi, ce qui
est légèrement gênant… :)
Persistence des scripts à chaque démarrage
Je pourrais réécrire les scripts via le script local.sh à chaque démarrage, mais ce n'est pas très propre et ça rendrait
la maintenance, des scripts et du fichier local.sh un peu compliquée. J'ai donc décidé de faire une copie de ce
dossier régulièrement sur un des datastore. Ensuite, dans local.sh, je recopie simplement ce dossier.
J'ai donc simplement ajouté à
/etc/rc.local.d/local.sh
la ligne suivante :
cp -a /vmfs/volumes/SSDMini/mosx /mosx
Copyright © MosX.org
Page 4/11
Utiliser le shell de ESXi
Et… voilà. Rien de plus compliqué :)
Sauvegarde des scripts et paramètres
Il faut donc sauvegarder ce dossier sur le datastore pour pouvoir le restaurer à chaque démarrage. Mais avant de
sauvegarder le dossier, il peut être intéressant de sauvegarder quelques autres choses avec.
La config ESXi qui comprend les paramètres spécifiques de l'hôte ESXi (les datastores, l'adresse IP, etc.) peuvent
être utiles à conserver. Cela permettrait également un retour rapide à la normale en cas de réinstallation de l'hôte.
Pour cela, il existe une commande toute prête qui génère une archive de la configuration complète de l'hôte :
/bin/vim-cmd hostsvc/firmware/backup_config
.
Il est préférable de s'assurer que la config en mémoire est bien synchronisée avec les fichiers de préférence avec la
commande :
/bin/vim-cmd hostsvc/firmware/sync_config
Il faut ensuite déplacer l'archive dans le dossier /mosx pour qu'elle soit sauvegardée avec le reste.
Il est également utile de sauvegarder le fichier
/etc/rc.local.d/local.sh
qui est très important. Ainsi, en cas de réinstallation, nous n'aurons qu'à le recopier.
Enfin, copier le dossier à l'emplacement de sauvegarde.
Voici donc le script
backupConfig.sh
:
Copyright © MosX.org
Page 5/11
Utiliser le shell de ESXi
#!/bin/sh
#########################
# Copy of ESXi config : #
/bin/vim-cmd hostsvc/firmware/sync_config
BCKPATH=$(/bin/vim-cmd hostsvc/firmware/backup_config |grep Bundle |cut -d'/' -f5-)
CLEANPATH=$(echo $BCKPATH |cut -d'/' -f1)
cp /scratch/downloads/${BCKPATH} /mosx/configBundle.tgz
rm -rf /scratch/downloads/${CLEANPATH}
###########################
# Copy of rc.local file : #
cp -a /etc/rc.local.d/local.sh /mosx/local.sh
###############################
# Copy of /mosx dir on Disk : #
cp -a /mosx /vmfs/volumes/SSDMini
Copyright © MosX.org
Page 6/11
Utiliser le shell de ESXi
Restaurer les paramètres ESXi
Nous avons plus haut sauvegardé la config de l'hôte dans une archive configBundle.tgz au cas où nous aurions à
réinstaller l'hôte ESXi.
La restauration est un peu plus compliquée que la sauvegarde parce que dans l'archive, le système stocke
l'identifiant unique de l'hôte. Lors d'une réinstallation, cet identifiant a toutes les chances de changer, et la
restauration ne marchera pas. Ceci est pour éviter de restaurer une configuration sur un système qui n'est pas le
bon.
Dans notre cas, j'ai fait un script qui change l'UUID dans l'archive pour pouvoir la réimporter dans le système
courant, que l'UUID ait changé ou pas.
Voici le script restoreConfig.sh :
#!/bin/sh
cd /mosx
tar zxf /mosx/configBundle.tgz
RSTUUID=$(cat /mosx/Manifest.txt |grep "UUID=" |cut -d'=' -f2)
/bin/vim-cmd hostsvc/firmware/sync_config
BCKPATH=$(/bin/vim-cmd hostsvc/firmware/backup_config |grep Bundle |cut -d'/' -f5-)
CLEANPATH=$(echo $BCKPATH |cut -d'/' -f1)
cp /scratch/downloads/${BCKPATH} /tmp/configTmp.tgz
rm -rf /scratch/downloads/${CLEANPATH}
cd /tmp
tar zxf /mosx/configBundle.tgz Manifest.txt
CURUUID=$(cat /tmp/Manifest.txt |grep "UUID=" |cut -d'=' -f2)
rm /tmp/Manifest.txt
cd /mosx
cat Manifest.txt |sed "s/UUID\=\(.*\)/UUID\=${CURUUID}/" > Manif.txt
mv Manif.txt Manifest.txt
tar zcf /tmp/configBundle.tgz Manifest.txt state.tgz
/bin/vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz
N'oubliez pas de remplacer /mosx par le nom du dossier dans lequel vous placez vos scripts et archives.
Vérification du fichier local.sh
Copyright © MosX.org
Page 7/11
Utiliser le shell de ESXi
Voici à quoi ressemble mon fichier
/etc/rc.local.d/local.sh
. Vous noterez que par soucis de sécurité, j'ai rajouté une sauvegarde du dossier mosx sur un autre datastore :
cp -a /vmfs/volumes/SSDMini/mosx /mosx
/bin/kill $(cat /var/run/crond.pid)
echo "*/5
*
*
*
*
/mosx/backupConfig.sh" >>/var/spool/cron/crontabs/root
echo "1
0
*
*
*
cp -a /mosx /vmfs/volumes/ReadyNAS-NFSShare" >>/var/spool/cron/crontabs/root
echo "0
*
*
*
*
/mosx/testDisks.sh" >>/var/spool/cron/crontabs/root
/usr/lib/vmware/busybox/bin/busybox crond
exit 0
Voici un rappel de ce que je rajoute à la crontab : Je lance backupConfig.sh toutes les 5mn tous les jours. Je lance la
copie de mosx sur un autre datastore à 0:01 (UTC) tous les jours. Je teste les disques toutes les heures tous les
jours.
Tester et alerter en cas de problèmes disques
Au début de mes tests, j'ai eu un soucis avec mon boitier NAS, j'ai donc créé un script qui fait un touch sur les
disques voulus. En cas d'erreur lors du touch, j'envoi un courriel d'alerte :
Copyright © MosX.org
Page 8/11
Utiliser le shell de ESXi
#!/bin/sh
DISKSTOTEST="/path/To/Test/1 /path/To/Test/2"
. /mosx/sendMail.sh
[email protected]
for theDisk in $DISKSTOTEST
do
touch ${theDisk}/touch.log 2>/dev/null
[ $? -ne 0 ] && {
mySendMail ${EMAIL} "ALERTE DISQUES ESXi" "Le disque ${theDisk} n'est pas disponible !!!\r\n\r\n\r\n"
}
done
Copyright © MosX.org
Page 9/11
Utiliser le shell de ESXi
Envoyer des courriels
Vous l'avez sans doute remarqué dans le script précédent, j'ai fait un script qui permet d'envoyer des courriels voici
comment il marche. Je ne gère que l'envoi via un serveur sans authentification. Il existe des scripts (comme
xsibackup dont nous parlerons dans un autre article) qui permettent d'utiliser SMTP AUTH, je vous invite à les
consulter si vous en avez besoin.
La première chose à faire dans ce script est de vérifier que les règles de firewall de l'hôte ESXi autorisent à sortir sur
le port désiré, cela se fait avec la commande
esxcli network firewall ruleset list
. Si ce n'est pas le cas, il faut modifier le fichier /etc/vmware/firewall/service.xml pour rajouter la règle. Enfin, il faut
vérifier que la règle est bien activée.
Enfin, la fonction mySendMail(), appelée depuis les autres scripts avec le destinataire, le sujet et le corps du
message en paramètres, liste les commandes SMTP à envoyer et les place dans un fichier temporaire. Ce fichier
temporaire est enfin lu par la commande nc qui envoie les commandes au serveur spécifié.
Voici le script sendMail.sh :
Copyright © MosX.org
Page 10/11
Utiliser le shell de ESXi
#!/bin/sh
MAILHOST=my.mailsrv.org
MAILPORT=25
[email protected]
FWRes=$( esxcli network firewall ruleset list | grep "SMTPout" )
[ "$FWRes" == "" ] && {
chmod 644 /etc/vmware/firewall/service.xml
chmod +t /etc/vmware/firewall/service.xml
FWRule="\n
SMTPout\n
\n
outbound\n
tcp\n
dst\n
"$MAILPORT"\n
\n
true\n
false\n
\n
"
ADDT=`echo $FWRule |sed 's/$newline//g'`
sed -i 's,<\/ConfigRoot>,'"$ADDT"',g' "/etc/vmware/firewall/service.xml"
chmod 444 /etc/vmware/firewall/service.xml
esxcli network firewall refresh
}
esxcli network firewall ruleset set --ruleset-id=SMTPout --enabled=true
mySendMail() {
echo -ne "HELO ${MAILHOST}\r\n" > /tmp/sendMail.$$
echo -ne "MAIL FROM: <${SENDER}>\r\n" >>
echo -ne "RCPT TO: ${1}\r\n" >>
echo -ne "DATA\r\n" >>
/tmp/sendMail.$$
echo -ne "To: ${1}\r\n" >>
/tmp/sendMail.$$
echo -ne "Subject: ${2}\r\n" >>
/tmp/sendMail.$$
echo -ne "\r\n" >>
/tmp/sendMail.$$
echo -ne "${3}" >>
/tmp/sendMail.$$
echo -ne ".\r\n" >>
/tmp/sendMail.$$
/tmp/sendMail.$$
/tmp/sendMail.$$
echo -ne "QUIT\r\n" >>
/tmp/sendMail.$$
/usr/bin/nc -v -i 1 ${MAILHOST} ${MAILPORT} < /tmp/sendMail.$$ >/dev/null 2>/dev/null
}
Copyright © MosX.org
Page 11/11