Windows 2003 on Zwindler's Reflection

Problème de pointeur souris sur la console dans OracleVM 3.4

Thu, 09 Feb 2017 13:00:44 +0000

OracleVM, quelques faiblesses sur la console, comme les autres…

Dans la série des articles sur OracleVM avant que je n’en reparle plus (le PoC est ~~terminé~~ enterré chez nous), voici un petit retour sur un des problèmes que j’ai pu rencontrer.

Comme beaucoup de technologies de visualisation d’écrans consoles pas totalement maîtrisées (ça vaut pour les vieux ILO en Java ou autres : que de bons souvenirs), le pointeur de la souris fait littéralement n’importe quoi. Généralement c’est décalé mais pas de manière linéaire sur tout l’écran pour bien qu’on se marre.

Crédits : GameDev.net

Le problème vient du client web VNC proposé par Oracle VM Manager et est un problème archi-connu mais pour autant pas totalement résolu.

Accéder directement au flux VNC

Comme je l’explique juste avant, il arrive couramment que les technologies de virtualisations intégrées vers l’écran (virtuel) de la machine virtuelle soient mal calibrées. Mais c’est encore plus courant lorsque ce déport d’écran est réalisé avec un connexion VNC elle même affichée dans une console HTTP.

Un moyen de contourner le problème de ce type de clients VNC web (et ça vaut pour d’autres outils qui utilisent les mêmes techniques) est de simplement se « brancher » sur le flux VNC sans passer par la console web. A priori sur les versions précédentes de OVMM, il était possible de se brancher directement sur le flux VNC, tout simplement parce que le serveur VNC était en écoute sur l’interface LAN.

Au delà du fait que ce soit du bidouillage, cette technique n’est aujourd’hui plus permise depuis OVMM 3 et il faut donc … bidouiller encore plus ! Voici ce que propose le support d’Oracle :

You can redirect the remote port to local using the ssh(1) command. For example, the VM guest vnc port is 5900 on Oracle VM Server and listening on localhost:

# xm list -l 2|grep 59
(location 127.0.0.1:5900)

Then you can run this to redirect the port to your desktop:

$ ssh -L 12345:localhost:5900 root@OVS

The « 5900 » port will be redirected to « 12345 » of your local desktop, so that you can run the following command to connect the guest console:

$ vncviewer localhost:12345

En gros, ce qu’il faut en comprendre, c’est que le serveur VNC n’est maintenant plus disponible depuis autre part que localhost et qu’on peut contourner la limitation en faisant un tunnel SSH. Rien de bien sorcier, mais est ce qu’il n’y a pas un peu plus simple ?

La vraie solution

En fait si.

Au début, je n’ai même pas cherché à appliquer cette solution car elle ne s’applique normalement que pour les machines virtuelles Windows.

Si vous avez un problème du type de celui que je décris sur une VM Windows, on vous conseille chez Oracle d’ajouter un paramètre à la machine virtuelle qui permet de mieux suivre les mouvements de la souris.

Add below your config to force the device model to use absolute (tablet) coordinates:

usbdevice=’tablet’

Mais sur le papier, la solution est bien indiquée « For Windows virtual machines (guests) ». Mon problème moi, c’était sur les machines virtuelles CentOS, indiquées comme pas impactées par ce genre de problèmes.

Bon j’ai bien compris ou tu veux en venir. Comment on modifie ce paramètre ?

En fait, c’est TRES mal indiqué dans la documentation. Il s’agit de la configuration de la machine virtuelle, VM éteinte, mais où faire la modification ? Ahah ! Mystère !

La documentation fait elle état d’un fichier de configuration de la machine virtuelle mais je n’ai pas su trouver ce fichier. Cependant, et ce n’était pas dit dans la documentation on peut modifier ce paramètre directement depuis la GUI de Oracle VM Manager !

Dans les paramètres de la machine virtuelle, dans l’onglet Configuration, on trouve le paramètre Mouse Device Type. Sur les machines Windows, comme le problème est connu, il me semble d’ailleurs que le paramètre est passé à « tablet » par défaut.

Une fois validé, on peut vérifier que cette configuration a effectivement été modifiée en affichant ce fameux VM Config File que je ne sais pas où trouver :

A partir de là, la souris ne devrait plus vous faire de blagues. Même si avec Oracle VM, on ne sait jamais trop ;-) #Troll

Source

[Tutoriel] Installation de deux clients NSClient++ sur le même serveur

Sat, 17 Oct 2015 10:30:00 +0000

Le problème

Je suis tombé sur un problème amusant l’autre jour. Un serveur sur lequel deux entités se partageaient l’administration voulaient toutes les deux superviser le serveur avec NSClient++, mais chacune avec leur propre configuration et leurs propres plugins.

En théorie, il n’est pas possible d’installer deux fois le client sur le même serveur Windows. En fait, si on relance l’installeur une seconde fois, il nous proposera simplement de modifier l’installation existante.

Retour aux sources

Cependant, on peut s’en sortir avec les sources. Je pars du principe que le premier client a été installé simplement à partir du MSI. Et pour pouvoir installer le deuxième client, il faut récupérer une archive .zip sur le site (Source).

www.nsclient.org/download

On peut ensuite le déposer dans C:\Program Files\, en prenant soin de lui donner un autre nom que celui du client installé via le fichier .msi (C:\Program Files\NSclient++\ par défaut).

Pour l’exemple, j’ai pris C:\Program Files\NSClientNew\.

Configurer le second NSClient

Modifiez ensuite le fichier de configuration C:\Program Files\NSClientNew\NSC.ini pour que les ports ne soient pas identiques aux ports du premier client.

[NSClient]
port=12481
[NRPE]
port=56661
...

Dans un prompt administrateur, lancer la commande suivante pour créer un service Windows spécifique pour le second client.

PS C:\Program Files\NSClientNew> sc.exe create NSClientNew binPath= 'C:\Program Files\NSClientNew\NSClient++.exe' start=  auto DisplayName= 'NSClient++ New'
[SC] CreateService réussite(s)

NSClient++ devrait maintenant apparaître dans la liste

Si tout se passe bien, on peut maintenant démarrer le service et les ports en écoute doivent apparaître. Le log C:\Program Files\NSClientNew\nsclient.log doit afficher la ligne suivante

2015-07-16 15:51:26: message:modules\FileLogger\FileLogger.cpp:86: Starting to log for: NSClient++ - 0.3.9.330 2011-09-02

Si on a l’entrée suivante, c’est que les ports ont été mal configurés et qu’il y a conflit

2015-07-16 15:49:35: error:include\Socket.h:691: bind failed: 10048: Une seule utilisation de chaque adresse de socket (protocole/adresse réseau/port) est habituellement autorisée.

Une fois que c’est bon, vous pouvez tester vos deux clients depuis votre serveur Nagios via un check_nrpe sans arguments

[root@nagios libexec]# ./check_nrpe -H 192.168.20.10 -p 5666
I (0.3.9.328 2011-08-16) seem to be doing fine...
[root@nagios libexec]# ./check_nrpe -H 192.168.20.10 -p 56661
I (0.3.9.330 2011-09-02) seem to be doing fine...

Bonus track : supprimer le service NSClientNew une fois qu’on en veut plus

Si jamais l’envie vous prend de supprimer ce que vous venez de faire, il faudra supprimer à la main le service de la façon suivante, puis supprimer le dossier. Exécutez la commande suivante dans un cmd/powershell en tant qu’administrateur

C:\Windows\system32>sc delete NSClientNew
[SC] DeleteService réussite(s)