Erreur 2203 renvoyée par Windows Installer

En déployant deux serveurs avec une clef USB cause WDS ne fonctionnant pas sur les machines en question, une fois l’installation finie, j’ai eu à installer plusieurs paquets, notamment de drivers, en MSI, nécessitant donc Windows Installer.

J’ai été surpris de rencontrer une erreur 2203 lors de la tentative d’installation du paquet. Après un peu de recherches, cette erreur apparaît lorsque Windows Installer a besoin d’accéder au répertoire temporaire de l’utilisateur (variable d’environnement %TEMP%), mais qu’il ne peut pas, soit car celui-ci n’existe pas, où parce que les droits sont insuffisants.

En ouvrant un cmd, et en tapant cd %temp%, je tombe sur un répertoire inaccessible. Et pour cause : le script post-déploiement que j’ai utilisé pour terminer la configuration de la machine qui va fonctionner en workgroup initialise la valeur du répertoire temporaire de cet utilisateur sur le disque D:, disque qui était le support d’installation de Windows ; en effet, le script a été conçu pour des installation de serveurs standards utilisant deux disques, avec un disque D utilisable.

Les variables d’environnement à régler : TEMP et TMP

Dans mon cas, après avoir modifié la variable d’environnement, fermé et rouvert la session de l’utilisateur, j’ai pu installer correctement mon package MSI. Une erreur toute simple mais qui m’a fait perdre une dizaine de précieuses minutes.

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.

Contourner l’erreur 124 d’installation de Google Chrome

Je ne suis pas un grand fan de Google Chrome, mais il faut parfois bien l’installer et s’en servir pour réaliser du troubleshooting ou s’assurer de la compatibilité de certaines applications ou appels du navigateur par défaut. Et aujourd’hui, en essayant de réinstaller Chrome 64 bits sur un poste d’entreprise après être passé de la version 64 bits à la 32 bits, j’ai eu cette belle erreur, en étant administrateur local de mon poste de travail.

Après avoir trouvé un log portant le doux nom de chrome_installer.log dans le répertoire C:\Users\<mnémonyme\>AppData\Local\Temp, j’y ai trouvé des informations plus ou moins intéressantes :

[1031/165307.958:VERBOSE1:setup_main.cc(1350)]
Command Line: « C:\Program Files
(x86)\Google\Chrome\Application\62.0.3202.75\Installer\setup.exe »
–uninstall –msi –system-level –verbose-logging –force-uninstall
[1031/165307.959:VERBOSE1:setup_main.cc(1356)] system install is 1
[1031/165307.959:VERBOSE1:installer_state.cc(74)] Uninstall distribution: Google Chrome
[1031/165307.959:VERBOSE1:setup_main.cc(1364)] is_migrating_to_single is 0
[1031/165307.970:VERBOSE1:install_util.cc(217)] Windows NT 6.1.7601 SP1
[1031/165307.971:VERBOSE1:installer_state.cc(74)] Uninstall distribution: Google Chrome
[1031/165307.971:VERBOSE1:setup_main.cc(576)] version on the system: 62.0.3202.75
[1031/165307.971:VERBOSE1:uninstall.cc(810)] UninstallProduct: Google Chrome
Apparemment, le setup trouve toujours un Chrome installé sur le système ; un reboot n’y fera rien, pas plus que la suppression des clefs de registre liées à Google Chrome – par ailleurs, le fichier de log fait mention d’un bon nom de clefs que le programme d’installation a supprimé avant de tenter d’installer Chrome 64 bits, sans qu’il précise si c’est cette installation détectée qui fait avorter le processus d’installation, ni même si l’installation qu’il trouve est celle qu’il vient de tenter de réaliser.
Ne pouvant donc trouver la cause exacte de la non-réinstallation de Chrome 64 bits sur le poste – et soupçonnant une restriction liée à une GPO car j’ai eu le cas sur un autre poste de test sur le même domaine et en utilisant le même compte utilisateur -, j’ai donc dû ruser pour tout de même rétablir l’application.
Lorsque le setup télécharge les fichiers de Chrome avant de mentionner l’erreur, il créé un répertoire Google, dans le Program Files x86, avec deux répertoires : CrashReports et Update. Dans le répertoire Update, se trouve un autre répertoire Install, qui contient lui-même un répertoire portant un GUID. Dans ce tout dernier dossier, se trouve le setup complet de Chrome, pesant dans mon cas un peu plus de 44 Mo.
Un petit coup de 7-Zip sur cet exécutable nous donne un fichier chrome.7z, qu’il faudra lui-même décompresser pour obtenir enfin le dossier Chrome-bin qui contient chrome.exe et son dossier de ressources.

Présentation de mon « cloud » personnel

Je possède une plateforme en ligne me permettant entre autres d’assouvir ma curiosité IT mais également de répondre à plusieurs besoins – que je me suis moi-même créé, d’ailleurs. Après avoir eu pendant longtemps un serveur (généralement sous Debian), il y a quelques temps j’ai décidé de passer sur une plateforme virtualisée afin de séparer chaque fonctionnalité de mon nuage et de gérer les choses plus facilement. Initialement sous Proxmox VE, je suis passé sous VMware après l’avoir pratiqué dans un contexte professionnel. Le but de cet article est d’essayer de présenter ce nuage, ce que j’en fais, comment je l’ai pensé et comment il vit.

Tout d’abord, ce nuage est basé sur une seule machine physique. Il s’agit d’un serveur que je loue chez SoYouStart qui est le milieu de gamme de chez OVH (l’entrée de gamme étant assurée par Kimsufi et le haut de gamme par OVH lui-même). Sa configuration est la suivante :

  • CPU : AMD Opteron 4334 à 6 coeurs, 6 threads et 3.1 GHz
  • RAM : 32 Go DDR3 1333 MHz
  • HDD : 2 x 3 To SATA, configurés en RAID 1
Il s’agit de la configuration OP-SAT-1-32. Après plusieurs années sur un modèle moins puissant fonctionnant sous Proxmox VE, j’ai fait ce choix car les 32 Go de RAM sont le minimum dont j’ai besoin dans le cadre de la virtualisation afin de ne pas dimensionner un peu court les machines ; le processeur plutôt puissant suffit à toutes les tâches et ne peine pas face à de multiples décodages de vidéos en 1080p sur Plex ; les disques durs, bien que simples SATA en 7200rpm suffisent même si le confort des SSD que j’ai pu essayer manque à l’appel, en ayant en contrepartie un espace suffisant pour tout type de machine virtuelle.
La couche de virtualisation est un VMware ESXi 6.5u1. Elle héberge donc – entre autres, je ne vais présenter que les machines qui sont permanentes – :
  • 1 appliance pfSense, fonctionnant sous BSD ;
  • 2 contrôleurs de domaine sous Windows Server 2012 R2 ;
  • 1 serveur de fichiers sous Windows Server 2012 R2 ;
  • 1 serveur applicatif sous Windows Server 2012 R2 ;
  • 1 serveur RDP sous Windows Server 2012 ;
  • 2 serveurs multimédia Plex sous Debian ;
  • 1 serveur applicatif sous Debian ;
  • 1 serveur VPN sous Debian ;

L’appliance pfSense : 1 vCPU et 512 Mo de RAM

J’en ai déjà parlé dans ce billet. pfSense est un serveur BSD pouvant entre autres remplir le rôle de routeur/pare-feu. Etant donné qu’à la différence de Proxmox VE qui permet de faire du NAT nativement grâce à iptables, l’adoption de VMware m’a forcé à passer par une solution tierce pour mettre en réseau mes machines virtuelles derrière un pare-feu en n’utilisant qu’une seule IP publique. Mon serveur fonctionne donc avec deux adresses IP : l’une utilisée par la carte physique, l’autre en IP failover utilisée par l’interface virtuelle de pfSense et qui sert d’IP publique pour mes machines virtuelles et de base pour le routage des paquets vers les bons ports.

Les contrôleurs de domaine : 1 vCPU, 2 Go de RAM et 120 Go d’espace disque par DC

Je pourrais très bien fonctionner avec un seul contrôleur de domaine étant donné que je ne possède qu’un seul serveur pour héberger toutes mes machines et qu’il n’y a aucune notion de haute disponibilité. Cependant, ayant déjà eu le cas d’un contrôleur de domaine complètement planté suite à une mise à jour qui s’est mal déroulé sur une précédente infrastructure personnelle, je préfère en avoir deux fonctionnant de concert ce qui me permet de toujours avoir le domaine même si une mise à jour ou un plantage grave arrive sur l’un (corruption du fichier VMDK par exemple, ce qui m’est déjà arrivé).
Le premier porte tous les rôles (FSMO, PDC…), les deux ont le rôle DNS et ont été installés avec l’interface graphique. C’est un point que je souhaite changer prochainement et qui fera sans doute l’objet d’un billet. Ayant toutes les consoles d’administration sur une autre machine, je ne m’y connecte que très rarement et fonctionner uniquement en mode core pourrait limiter la consommation – déjà très faible – de ressources.

Le serveur de fichiers : 2 vCPU, 3 Go de RAM et 3 disques virtuels pour un total de 720 Go

Ce serveur fonctionnant sous 2012 R2 me sert pour stocker une partie de mon OneDrive, ainsi qu’héberger divers espaces partagés entre les machines (sources d’applications, scripts, téléchargements, bases de données…). J’y stocke également les sauvegardes des serveurs Windows que je réalise grâce à l’outil intégré. Afin d’avoir une compatibilité maximale avec les applications, ce serveur fait fonctionner un serveur FTP fonctionnant sous FileZilla.

Le serveur applicatif sous Windows : 2 vCPU, 3 Go de RAM et 2 disques virtuels de 120 Go

J’utilise cette VM pour faire fonctionner des applications qui ont besoin d’un environnement Windows (ou qui sont plus faciles à faire fonctionner ou configurer sous Windows). Je m’en sers principalement pour faire fonctionner un serveur Minecraft personnel ou d’autres serveurs de jeux, afin de ne pas avoir à conserver les fichiers et exécuter le serveur dédié sur mon propre PC personnel. Cela me permet également de donner accès à des personnes de ma famille qui sont en dehors de mon réseau personnel. 

Le serveur RDP : 2 vCPU, 2 Go de RAM et 120 Go d’espace disque

C’est ce serveur qui permet de rebondir sur le reste du réseau et le seul RDP à être ouvert sur l’extérieur. Plutôt que d’ouvrir les RDP ou les bureaux graphiques des autres machines, j’ai préféré tout fermer et ne laisser l’accès que depuis cette seule machine afin de limiter le nombre de ports à nater. Cette VM possède ensuite tous les clients nécessaires à la connexion aux services VMware de l’hyperviseur, aux bureaux graphiques des machines Linux, PuTTY pour le SSH, sans oublier les consoles d’administration pour les services répartis sur les serveurs. Plus qu’un serveur de rebond, il s’agit également d’un serveur d’administration et c’est sur cette machine que je réalise la majorité de mes scripts. Pour des questions de sécurité, la connexion à cette machine se fait avec un autre compte utilisateur que les autres machines Windows, ce compte n’ayant aucun autre droit sur le domaine (et mon compte utilisateur standard n’ayant aucun droit sur le serveur RDP, seul mon compte d’administration ayant des droits transverses).

Les 2 serveurs Plex : 4 vCPU, 4 Go de RAM et 50 Go d’espace disque pour le premier, 1 vCPU, 2 Go de RAM et 100 Go d’espace disque pour le second

Pourquoi deux serveurs Plex ? Car ils fonctionnent différemment.
Le premier serveur Plex, avec sa grosse configuration, est dédié à la diffusion de contenu vidéo. Films, séries, concerts, émissions TV… tout ce qui peut demander une bonne puissance de calcul en cas de diffusion sur un appareil qui ne peut décoder le flux directement (comme un iPad). Comme je l’ai expliqué dans ce billet, le contenu n’est pas stocké directement sur le serveur, mais en ligne, sur Google Drive. J’utilisais auparavant Amazon Drive mais le blocage complet de l’API suivi d’un changement des grilles tarifaires m’a fait résilier mon abonnement pour me diriger vers celui de Google, qui s’est avéré plus fiable, plus rapide pour pas beaucoup plus cher dans l’absolu (8 euros par mois contre 70 euros à l’année). Afin de supporter le streaming sur plusieurs appareils (généralement un seul, mais 3 devant être un nombre géré sans problème avec du 1080p), il a fallu dimensionner correctement la machine et 4 cœurs virtuels sont suffisants.
Le deuxième serveur Plex à la configuration bien plus modeste est dédié à la diffusion de contenu audio. La musique est stockée directement sur le disque de la machine virtuelle afin de ne pas avoir à faire des appels à l’API de Google Drive sans arrêt à chaque changement de piste, sans compter que 100 Go sont aisément disponibles sur l’hyperviseur.

Le serveur applicatif Debian : 2 vCPU et 2 Go de RAM pour 120 Go d’espace disque

Cette VM héberge un serveur web, un serveur de base de données MySQL, ainsi que quelques autres applicatifs web. L’usage est principalement local, certaines applications dont je me sers peuvent avoir besoin d’une base de données, par exemple. Grâce à des scripts conçus sous Webmin, les bases de données ainsi que certains fichiers sont sauvegardés sur le serveur de fichiers, qui lui-même les sauvegarde par la suite sur OneDrive, ce qui me permet de pouvoir restaurer à un instant T si besoin.

Le serveur VPN : 1 vCPU et 1 Go de RAM pour 10 Go d’espace disque

Afin de pouvoir profiter de réseaux Wi-Fi publics sans me sentir « nu », ce petit serveur VPN est idéal. Fonctionnant sur une base d’OpenVPN Access Server, l’installation et la configuration se font très facilement, et des clients existent aussi bien pour les ordinateurs que les appareils mobiles. Je m’en sers dès que je suis sur un réseau Wi-Fi qui n’est pas celui que j’utilise à la maison. 
Et c’est déjà pas mal ! J’ai également possédé pendant quelques temps un serveur de messagerie personnel, lié à mon nom de domaine, dont je me servais à des fins personnelles, connecté à mes clients de messagerie ou accessible via un webmail. Fonctionnant sous Debian avec Postfix et Dovecot, lorsque j’ai repensé intégralement l’architecture en adoptant VMware, j’ai décidé de ne pas conserver la messagerie personnelle. Trop peu d’utilité et de confort par rapport à mon usage : sauvegarde horaire de la boîte aux lettres, adresse considérée chez certains destinataires comme spam, difficulté de configuration… Concernant le dimensionnement des machines, il est plutôt large, et d’ailleurs, si toutes les machines devaient occuper 100% de leurs vCPU, cela saturerait l’hyperviseur ; cependant, très peu de risque que cela arrive. En moyenne, le CPU tourne entre 5 et 10% de ses capacités, avec une moyenne à 30% lors de la diffusion de médias via Plex. Actuellement, le serveur en est à 245,24 jours de fonctionnement… et ça n’est pas prêt de s’arrêter.