Le site des administrateurs systèmes sous Mac OS X
  Il existe toujours de nombreuses manières de faire : la bonne et les autres.



Accueil du site > Dossiers > Utiliser le shell de ESXi
Utiliser le shell de ESXi

mardi 17 mars 2015, par Jayce Piel

J’ai parlé dans un article précédent de l’installation de VMware ESXi sur nos Mac. L’article d’aujourd’hui n’est pas ciblé uniquement pour les Macs, mais d’une 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 n’ont pas accès à toutes les fonctionnalités de vSphere, mais pas que…


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.

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.

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

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 :


#!/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

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

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 :


#!/bin/sh

DISKSTOTEST="/path/To/Test/1 /path/To/Test/2"

. /mosx/sendMail.sh

EMAIL=myMail@mail.com

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


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 :


#!/bin/sh

MAILHOST=my.mailsrv.org
MAILPORT=25
SENDER=me@mailsrv.org

FWRes=$( esxcli network firewall ruleset list | grep "SMTPout" )
[ "$FWRes" == "" ] && {
 chmod 644 /etc/vmware/firewall/service.xml                                                        
 chmod +t /etc/vmware/firewall/service.xml
 
 FWRule="<service id='9999'>\n
 <id>SMTPout</id>\n
 <rule id='0000'>\n
 <direction>outbound</direction>\n
 <protocol>tcp</protocol>\n
 <porttype>dst</porttype>\n
 <port>"$MAILPORT"</port>\n
 </rule>\n                                                                                        
 <enabled>true</enabled>\n                                                                        
 <required>false</required>\n                                                                      
 </service>\n                                                                                      
 </ConfigRoot>"
 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" >>  /tmp/sendMail.$$
 echo -ne "RCPT TO: ${1}\r\n" >>  /tmp/sendMail.$$
 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.$$
 echo -ne "QUIT\r\n" >>  /tmp/sendMail.$$

 /usr/bin/nc -v -i 1 ${MAILHOST} ${MAILPORT} < /tmp/sendMail.$$ >/dev/null 2>/dev/null
}


[ Haut ] Enregistrer au format PDF

Creative Commons License

Cette création est mise à disposition sous un contrat Creative Commons.




Recommandez ce site à un ami :

Votre Prénom : E-mail de votre ami :

Valid XHTML 1.0 Transitional

FORUM DE L'ARTICLE :