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

Mise en place de PlexPy, un outil de supervision de Plex Media Server

PlexPy est un outil de supervision et de monitoring pour un serveur Plex. Suite à un crash de mon serveur Plex aujourd’hui – qui deviennent de plus en plus fréquents (un par semaine…) sans que je comprenne trop pourquoi – je voulais trouver un moyen d’être averti par courriel lorsque le serveur ne répond plus correctement ou lorsque le streaming est impossible. PlexPy fonctionne comme son nom l’indique avec Python et offre une interface Web. Bien qu’il soit plutôt facile à installer, je vais en détailler le processus d’installation et de configuration sur une machine Debian. A noter qu’il n’est pas nécessaire d’installer PlexPy sur le serveur Plex en question.

Tout d’abord, on créé un utilisateur qui exécutera l’application :

adduser plexpy

Je pars du principe que Python et Git sont installés sur la machine.

cd /opt/
git clone https://github.com/JonnyWong16/plexpy.git
cd plexpy
python PlexPy.py

L’idée étant que PlexPy démarre tel un service au lancement du système afin d’éviter d’avoir à laisser la console ouverte ou à passer par screen, il va falloir quelques manipulations supplémentaires ; copier-coller le contenu du fichier .service présent sur le GitHub (ou bien récupérer la version déjà renommée sur mon Google Drive) puis l’enregistrer dans /lib/systemd/system (en le renommant plexpy.service si vous avez copié/collé). Ensuite, faire en sorte que ce service démarre avec le système :

systemctl daemon-reload
systemctl enable plexpy.service

Il démarre ensuite grâce à l’instruction systemctl start plexpy.service. Il ne faudra pas oublier de s’assurer que l’utilisateur plexpy qui a été créé plus tôt soit propriétaire du répertoire de l’application :

chown -R /opt/plexpy

Le fichier .service peut se modifier si jamais l’application n’a pas été installée dans le répertoire par défaut. Pour ma part, étant le seul administrateur de la machine Plex et le seul à y avoir un accès distant, j’ai laissé le fichier de configuration dans son emplacement par défaut.

Une fois l’application exécutée, un navigateur va s’ouvrir sur http://localhost:8181. Etant connecté en SSH, c’est w3m qui s’est ouvert.

Pour plus de facilité, j’ai contrôlé la pré-configuration de l’application via un navigateur installé sur une autre machine du réseau.

L’assistant divisé en plusieurs écrans est plutôt clair et permet de faire une configuration basique de l’outil. Par la suite, j’irai dans la configuration avancée pour modifier les notifications.

Une fois que tout est défini, on arrive sur la page d’accueil, qui présente diverses statistiques et informations par rapport au serveur Plex qui est écouté. Si l’on souhaite monitorer plusieurs serveurs Plex, alors il faut installer PlexPy autant de fois que nécessaire, sachant qu’il est possible de changer le port de l’interface web pour avoir plusieurs instances sur la même machine sans que cela ne pose problème.

Pour configurer ce qui m’intéresse, c’est-à-dire une alerte par courriel qui m’avertit d’un éventuel dysfonctionnement de Plex, il faut aller fouiner dans la configuration avancée, qui mérite de toutes façons le détour car c’est ici qu’on configure le degré d’alerte, le moyen de contact (il est possible de recevoir des notifications par une multitude de biais autre que le courriel, notamment Twitter ou autre outils de communication comme Telegraph…) et qu’on gère toute la partie technique (base de données, taille des logs, etc.).

Le design étant proche de celui de Plex, y retrouver ses petits est aisé. Tout d’abord, je vérifie que ma configuration est bien la bonne.

La section « Notifications » permet de paramétrer ce qui sera envoyé : titre, contenu, etc. Ce qui m’intéresse le plus cependant et là où je vais pouvoir mettre en place ce que je souhaite est dans la section « Notifications Agents ». Je choisis la ligne « E-mail » afin de la paramétrer. Il m’est donc naturellement demandé un serveur SMTP entre autres adresses émettrices et réceptrices.

Puis, une fois la configuration effectuée, un clic sur la cloche pour l’activer ; tout un panel de cases à cocher s’affiche, permettant de choisir exactement le moment où l’on souhaite être averti. J’ai donc choisi d’être averti par courriel lorsque le serveur est inaccessible et lorsqu’il revient en ligne.

Extension de partition sur Debian Jessie grâce à GParted

Comme évoqué dans mon précédent article, je me suis confronté à un problème d’espace disque sur ma machine virtuelle faisant fonctionner Plex Media Server. Je vais donc procéder à l’augmentation de la taille du disque virtuel pour élargir la partition /dev/sda1 qui a besoin de plus d’espace.

Première étape, l’extension de disque dans la console ESXi elle-même ; étant donné que je suis en 6.5 et que ma machine virtuelle est de version 12 – si mes souvenirs sont corrects – je suis obligé de passer par l’interface web, bien que je préfère très nettement le client lourd. Mon datastore composé de deux disques durs de 3 To en RAID 1 me le permettant très largement, je passe de 60 Go à 100 Go.

Etant donné qu’à l’installation de Debian, je n’ai pas séparé certains répertoires sur des partitions distinctes (/var, /home par exemple) – ce qui n’est pas très propre, j’en conviens, mais plus facile pour gérer l’espace libre lorsqu’on est pas aguerri sur Debian – je suis condamné à réaliser l’élargissement avec GParted en live CD.

Il faut donc démarrer sur le disque virtuel, en pressant échap dans la console VMware.

Puis on arrive sur cet écran :

On choisit la première option, vient par la suite la configuration du clavier, rien de difficile. Il faut ensuite confirmer la disposition de celui-ci.

Une fois l’initialisation terminée – ce qui peut prendre quelques minutes – on arrive sur l’écran principal de l’application GParted qui présente l’état du stockage.

Confirmation de la bonne extension du VMDK : on a 40 Go non alloués. Je ne peux étendre directement /dev/sda1, car comme cela est visible sur le graphique, mon espace non alloué est après la partition étendue et le swap. Je vais donc devoir supprimer le swap, la partition étendue, puis étendre /dev/sda1 et recréer une partition et le swap.

Une fois le disque étendu, on valide l’écriture sur le disque. Si tout s’est bien passé, /dev/sda1 a bien été étendue à environ 100 Go – car il ne faut pas oublier de laisser un peu de place pour le swap ! – puis on procède à la recréation de la partition étendue, puis du swap.

On écrit de nouveau les modifications sur le disque.

Une fois l’écriture terminée, on constate que tout semble s’être bien déroulé : /dev/sda1 a été agrandie, et le swap a bien repris sa place et son point de montage.

Un simple redémarrage plus tard – il y a un raccourci pour faire un redémarrage proprement sur le « bureau » du live CD, df nous indique bien que /dev/sda1 a grossi pour nous offrir quelques dizaines de Go supplémentaires.

Crash de Plex Media Server et googledrive-ocaml-fuse

Après quelques mois de fonctionnement sans problèmes particuliers de Plex en duo avec googledrive-ocaml-fuse dont l’installation à été expliquée dans ce billet, hier soir il m’a été impossible  d’accéder à Plex. Comme cela était déjà arrivé par le passé, le service plexmediaserver se met en carafe et il faut donc le relancer.

service plexmediaserver stop
service plexmediaserver start

Tout simplement… sauf qu’hier, le service n’a pas voulu se stopper, ni même se relancer. Le status m’indiquait que le service était en train de s’arrêter mais visiblement bloqué sur cet état d’arrêt. Je pensais alors qu’un petit ps -u plex afin de récupérer le PID du processus Plex Media Server suivi d’un kill <PID> suffirait pour tuer le service et pouvoir le relancer. Cependant, j’ai été un peu surpris lorsque j’ai exécuté le kill puis refait un ps -u plex pour m’assurer de la bonne exécution que le processus apparaissait en <defunct>.

Je me retrouvais donc avec un processus zombie qui ne voulait visiblement pas partir. Bien que je pense que le processus parent soit tout simplement init, je voulais en être sur, et un ps -ef –forest me l’a confirmé, car le parent avait pour PID 1. J’allais devoir lancer un telinit U pour relancer init et le forcer à dégager ce zombie.

Une fois cette instruction envoyée, j’ai pu relancer le service normalement et Plex semble avoir fonctionné quelques minutes, avant un nouveau crash. Cette fois-ci, avant de vouloir arrêter et relancer le processus, je demande à voir le statut. Malgré tout, il fonctionne, mais l’interface est inaccessible. Quelque chose que je n’avais pas vu au départ me saute aux yeux désormais : Plex ne peut fonctionner correctement car /dev/sda1 est plein. Surpris, je vérifie avec un df et en effet, son utilisation était à 100%.

En réalité, après trois mois d’utilisation et des centaines d’épisodes de série ou de films téléchargés sur le serveur depuis Google Drive, le cache de googledrive-ocaml-fuse était arrivé à saturer le disque dur. Surprenant, car j’avais configuré le cache pour qu’il utilise au maximum 10 Go – peut-être une mauvaise idée compte tenu de la taille du disque virtuel qui est de 40 Go. Cela signifie que le système et les applicatifs ont grossi d’eux-mêmes avec les mises à jour entre autres. J’ai donc nettoyé le cache de googledrive-ocaml-fuse.

eval `opam config env`
googledrive-ocaml-fuse -cc

Et, là :

J’ai pu relancer le service, et Plex respire et peut de nouveau streamer proprement.

Maintenant, afin d’éviter que cela se reproduise, deux solutions : soit réduire la taille du cache à 5 Go, soit augmenter la taille du disque virtuel. J’ai réalisé dans l’urgence une réduction de la taille du cache à 5 Go dans le fichier de configuration (voir cet article pour plus de détails) et je ferai ce week-end ou un peu plus tard une extension à 60 Go du disque virtuel de mon serveur Plex pour pouvoir rétablir le cache à 10 Go, ce qui devrait empêcher de futurs crashs.