> Tech > Soumettre VNC à  un test

Soumettre VNC à  un test

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Pour développer mon environnement de test, j'ai commencé par installer sur Win2K Server, NT Server 4.0, Solaris de Sun Microsystems, et Red Hat Linux. Comme le logiciel client VNC représente moins de 150 Ko et tient facilement sur un disque de 3,5 pouces, j'ai d'abord essayé d'utiliser le disque individuellement

Soumettre VNC à  un test

sur les divers ordinateurs
de mon réseau sans installer le client,
juste pour voir ce que je pourrais découvrir.
J’ai constaté que je n’avais pas
besoin d’installer le client localement
pour conduire une session à  distance –
exécuter VNC à  partir d’un disque 3,5
pouces a bien fonctionné.

J’utilise Terminal Services pour gérer
les serveurs Win2K dans mon réseau
à  partir de mon desktop XP Pro.
J’ai fait cela à  l’origine pour des raisons
d’espace : pour que les écrans et les
claviers soient attachés à  une demidouzaine
de systèmes serveur, il faut
beaucoup de place. J’ai commencé à 
améliorer la situation en ajoutant un
commutateur KVM (keyboard/video/
mouse) afin que tous mes serveurs
soient rattachés à  une console, mais j’ai
dû permuter les ordinateurs pour utiliser
la console. Puis j’ai commencé à  utiliser
Terminal Services et j’ai constaté
sa remarquable facilité d’utilisation.
Mais, pour accéder à  mes deux boîtes
UNIX, je devais soit les atteindre par
Telnet, soit utiliser la console. L’une
des fonctions intéressantes que VNC
propose avec les serveurs UNIX est que je n’ai pas besoin de garder VNC
actif en permanence. Je peux faire
Telnet dans un système UNIX et lancer
VNC, puis mettre en action le client
VNC et utiliser la GUI de la machine
UNIX pour obtenir une interface plein
écran.

L’une des astuces intéressantes
que j’ai découverte bénéficie du fait
que VNC est sans état – c’est-à -dire que
le client ne stocke aucune information
d’état. Vous pourriez passer d’une machine
client à  une autre, activer la
même session au même endroit (c’està –
dire, dans une application d’administration
ouverte) sur la seconde machine
et continuer à  travailler dans
l’application à  partir du point quitté
sur la première machine. Cette possibilité
a fait merveille lors d’une coupure
de courant alors que je travaillais à  partir
de l’ordinateur sans UPS (uninterruptible
power system). J’ai pu porter
la session VNC de l’ordinateur sur un
ordinateur différent (avec un UPS) et
continuer le travail que j’effectuais sur
le serveur cible. Et, pendant que je testais
Samba (pour autre chose), j’ai pu
voir le serveur UNIX utiliser VNC pour
ouvrir une session de console et aussi
voir le serveur Win2K utiliser le client
RDP Terminal Services.

VNC a fonctionné correctement
quand je l’ai exécuté dans une session
serveur VMware. J’utilise VMware à  des
fins de test et le fait de pouvoir utiliser
VNC avec VMware a été un avantage
supplémentaire parce que l’application
VNC a simplifié le suivi des diverses
sessions virtuelles qui s’exécutaient
sur différents ordinateurs.

Téléchargez cette ressource

État des lieux de la sécurité cloud-native

État des lieux de la sécurité cloud-native

L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT