Harmonisation de la synchronisation du temps sur Debian et Windows

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

Montage d'un NAS sur une machine virtuelle Debian distante

J'ai franchi le pas récemment en achetant un NAS pour sauvegarder à la maison mes documents personnels et du contenu multimédia en tout genre. En plus d'utiliser Google Drive avec Plex (voir cet article), j'ai décidé de monter un troisième serveur Plex sous Debian Stretch pour y décoder le multimédia qui provient de mon NAS directement. Afin que le NAS à la maison soit accessible sur mon Plex qui est une machine virtuelle située en dehors de mon réseau local, je vais utiliser Samba - intégré à mon NAS - et faire un peu de routage sur ma Livebox.

Tout d'abord, satisfaire les prérequis en termes de paquets sur la machine :

adduser <sambaplex>
apt-get install cifs-utils

Je me servirai du dossier home de l'utilisateur sambaplex pour y monter mon NAS afin de le séparer du répertoire de l'utilisateur courant. Etant donné que sur le serveur nous n'allons pas héberger un partage mais seulement en monter un, il n'y a pas besoin d'installer tous les paquets de samba.

Ensuite, il faut paramétrer la box qui fait office de routeur à la maison. Dans mon cas, ayant une IP dynamique, j'ai dû faire appel à un service externe nommé No-IP qui permet de souscrire gratuitement (avec une offre payante) à un nom de domaine que je prolongerai tous les mois ; ce service est géré par ma box grâce à l'API, ce qui signifie que dès que mon IP change, l'adresse que renvoie mon nom de domaine change aussi. Cela évite d'avoir à remonter le partage sur le serveur dès que l'IP change et de pouvoir communiquer avec un nom, ce qui est plus pratique.

Je configure ici mon service de DNS dynamique ; sur la Livebox plusieurs prestataires sont disponibles

Ensuite, il est nécessaire de procéder à l'ouverture des ports dans le pare-feu, et également de NATer ceux-ci afin que le trafic puisse rentrer et sortir proprement. 5 ports sont nécessaires pour que toutes les fonctionnalités soient accessibles :

Je route les ports 135, 137 et 445 en TCP/UDP, 138 en UDP et 139 en TCP vers le NAS

Par précaution, j'ai également procédé à la création d'un bail DHCP permanent pour le NAS afin qu'il ne change pas d'adresse IP locale en cas de redémarrage ou de perte de connexion. Une fois que tout est prêt côté "maison", il ne reste plus qu'à monter le partage samba du NAS sur le serveur distant grâce à cette commande exécutée en root :

mount -t cifs //<nas.domain>/<share> /home/sambaplex -o username=<nasuser>

Il sera alors demandé le mot de passe du compte nasuser qui devra avoir les droits en lecture sur le share que l'on souhaite monter.

Si l'on souhaite démonter le share, rien de plus simple :

umount /home/sambaplex

Désormais je peux ajouter mon contenu sur ce serveur Plex comme si il était localement sur la machine virtuelle, chaque appel aux fichiers passant par Samba - et nécessitant de ce fait, une bonne bande passante étant donné que tout transite du NAS à la maison vers la machine virtuelle.

Charge CPU bloquée à 100% sur le serveur hébergeant les Office WebApps pour SharePoint 2013

Toujours dans la lignée de mon travail sur les serveurs WAC (Office WebApps pour SharePoint, voir ce précédent billet), j'ai été confronté à un problème de consommation CPU sur un des deux serveurs WAC ; le CPU était en charge maximale en permanence, même sans aucun appel des Office WebApps de la part des utilisateurs, un arrêt/relance des services et un redémarrage de la plateforme n'ayant rien changé.

svchost.exe consomme 100% du CPU

Le journal d'événements ne présentant aucune erreur particulière, je n'avais pas de piste à creuser, et le système semblait en bonne santé. Je décide alors de couper le service Windows Update qui n'a aucun impact sur le service rendu en production, et miracle :

La charge CPU retombe à des niveaux très faibles, ce qui est normal lorsque le WAC n'est pas sollicité. Dans mon environnement, laisser le service Windows Update désactivé n'est pas problématique car nous gérons à la main le patching des serveurs via des campagnes - il suffira de réactiver le service au moment de mettre à jour la machine et de le désactiver après si la consommation de CPU reste bloquée à 100%.

Erreur 1069 sur cluster Hyper-V 2008 R2

Aujourd'hui, j'ai été confronté à une prolifération d'erreurs 1069 dans le journal d'événements d'une machine Hyper-V sous Windows 2008 R2.

Cette erreur indique qu'un élément présent dans le cluster n'est pas joignable.

Un petit tour dans la console FailOver Cluster Management et je constate qu'en effet, certaines ressources sont indisponibles tandis que les disques attachés le sont toujours.

Etat d'une ressource du cluster

Après une petite recherche, il s'est avéré que les machines en question ont été éteintes dans le cadre d'un projet de démantèlement et que le cluster n'avait pas été nettoyé ; il ne m'a resté qu'à sélectionner chaque machine éteinte et démantelée et à la supprimer du cluster afin qu'il ne reste plus aucune référence.