Étiquette : w32tm

Pas de commentaire

Harmonisation de la synchronisation du temps sur Debian et Windows

  de

Aujourd’hui j’ai pris un peu le temps de mettre à plat ma configuration concernant les horloges et la synchronisation de celles-ci sur les différents serveurs que je fais fonctionner sur mon environnement personnel. Les horloges étant disparates sur les systèmes, j’ai donc défini la configuration suivante :

  • L’hyperviseur ESXi se synchronisant sur des serveurs NTP publics : http://www.pool.ntp.org/ ;
  • Mes deux contrôleurs de domaine Windows se synchronisant sur ces mêmes serveurs NTP ;
  • Toutes mes autres machines se synchronisant sur mes contrôleurs de domaine.

Sur Windows, j’ai développé un script Powershell – qu’il m’aurait été possible d’appliquer via GPO – qui s’occupe de modifier la configuration dans la base de registre afin que le serveur utilise comme source les contrôleurs de domaine. Ce script (disponible sur mon miroir de téléchargement) nécessite évidemment des droits d’administration sur le serveur pour être exécuté – on s’assurera de remplacer time-srvX par le nom du serveur de temps, en conservant bien ,0x1 et en séparant les noms de serveurs par un espace :

Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Config -name « AnnounceFlags » -value « 5 »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Parameters -name « Type » -value « NTP »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\TimeProviders\NtpServer -name « Enabled » -value « 1 »
Set-ItemProperty -Path HKLM:\System\CurrentControlSet\Services\w32time\Parameters -name « NtpServer » -value « time-srv1,0x1 time-srv2,0x1 »

A noter qu’en fonction de la politique d’exécution des scripts sur la machine, il est possible que le script ne s’exécute pas, on va donc l’autoriser si cette politique n’est pas gérée au niveau du domaine.

Set-ExecutionPolicy Unrestricted

Une fois ces instructions interprétées par Powershell, on redémarre le service de temps :

net stop w32time
net start w32time

Puis, on peut s’assurer que la source est correcte et faire une synchronisation grâce aux commandes suivantes – l’interrogation de la source devrait renvoyer l’un des serveurs spécifiés plus haut :

w32tm /query /source
w32tm /resync

Ensuite, sur mes machines Debian, grâce au paquet ntpdate, il est possible de spécifier au système l’adresse d’un serveur sur lequel synchroniser l’horloge.

apt-get install ntpdate

On modifie le fichier de configuration :

nano /etc/default/ntpdate

Afin de forcer ntpdate a bien utiliser ce fichier de configuration, on passe le paramètre NTPDATE_USE_NTP_CONF à no, puis on modifie NTPSERVERS pour y intégrer les serveurs de temps, ce qui donne ceci :

NTPDATE_USE_NTP_CONF=no
NTPSERVERS= »time-srv1 time-srv2″

Et enfin, pour synchroniser la machine avec les serveurs tout juste renseignés :

ntpdate-debian

Pas de commentaire

Les VM d’un hôte ESXi ne sont plus à l’heure

  de

Je me suis aperçu d’un dysfonctionnement aujourd’hui alors que j’étais connecté sur deux de mes machines virtuelles sur mon hyperviseur ESXi. En effet, l’heure des deux machines Windows et GNU/Linux étaient en avance de 9 minutes par rapport à l’heure réelle.

Mes machines Windows prennent le temps sur le contrôleur de domaine qui lui même prend le temps sur l’ESX, et mes machines GNU/Linux prennent leur temps sur l’ESX. Etant donné que j’avais le même décalage et qu’une interrogation de w32tm sur ma machine Windows me donnait un retour satisfaisant quant à la synchronisation de l’horloge par rapport à l’un de mes DC, j’en ai déduit que le problème était localisé côté ESX.

En effet, pour une raison inconnue, mes paramètres NTP avaient sauté, et le service était arrêté. J’ai donc ajouté des serveurs NTP sur lesquels se synchroniser, puis j’ai activé le démarrage automatique du service ainsi que le service lui-même :

Mais toujours rien, quelques minutes plus tard je n’obtiens toujours pas d’horloge correcte et le décalage est toujours présent. Je m’interroge donc sur le bon fonctionnement de mes serveurs NTP. J’interroge donc avec watch ntpq mes serveurs de temps, mais cela ne semble pas fonctionner :

En réalité, mon ESXi est incapable de résoudre les noms, ce qui fait que les noms des serveurs NTP ne peuvent être traduits en IP, d’où le dysfonctionnement actuel quant à mes requêtes NTP sur le pool que j’ai choisi. Un coup d’oeil rapide à la liste des règles du firewall me confirme mon impression : le client DNS est bloqué. Une fois le client activé, la résolution DNS se fait bien dans la console.

Une fois la résolution fonctionnelle, je relance par précaution le service NTP avec /etc/init.d/ntpd restart, puis une actualisation dans l’interface web vSphere me confirme que tout est revenu à la normale.

Concernant l’origine de ce dysfonctionnement, j’ai procédé au blocage de quelques règles pare-feu il y a quelques temps, et il est fort probable que je me sois aperçu de la désynchronisation de l’horloge qu’aujourd’hui.