Configuration d'un serveur VNC

Il existe différentes méthodes de lancer un serveur VNC

On supposera ici que le produit vnc-server est déja installé sur la machine. Le seul paquet necessaire est :

  • vnc-server.i386

En fait, la commande vncserver incluse dans le paquetage est un script Perl qui va lancer le serveur VNC lui même : Xvnc

Les ports utilisés

Le serveur VNC utilise par défaut le port dédié 5900.

En pratique, on peut avoir plusieures instances VNC lancées sur la même machine. Les ports devraient commencer à 5900 puis 5901, 5902 ... etc, en fonction du numéro d'instance passé en paramètre au lancement.

Lancement d'une instance en ligne de commande

[toto@machine_a_toto ~]$ vncserver
You will require a password to access your desktops.
Password: xxxxxxxx
Verify: xxxxxxxx
New 'machine_a_toto:1 (toto)' desktop is machine_a_toto:1
Starting applications specified in /home/toto/.vnc/xstartup
Log file is /home/toto/.vnc/machine_a_toto:1.log
Que s'est il passé ? :
  • vncserver a vérifié si le fichier ~/.vnc/passwd existait. Ne l'ayant pas trouvé évidement lors du premier lancement, il execute le binaire vncpasswd pour associer un mot de passe à la connexion. Ceci aura pour effet de créer le dossier ~/.vnc et le fichier passwd.
  • Le script vérifie si des instances VNC sont déja en fonctionnement sur les ports dédiés et utilisera le "suivant".
  • Un fichier ~/.vnc/xstartup que l'on examinera plus tard a aussi été créé lors du premier lancement.
  • Les ports ouverts sont certainement 5901 et 5801 dans notre cas, on verra plus loin pourquoi.
  • Le serveur Xvnc a été lancé par l'utilisateur toto. C'est donc une session associée à son compte qui sera accessible par VNC.
Tiens ... pourquoi :1 et pas :0 ?

Eh oui, on peut penser que dans le cas du lancement sans arguments, Xvnc utilise le premier port disponible: 5900 Deux choses peuvent le géner dans l'utilisation de ce port :

  • Si vous utilisez Gnome, un composant est peut être déja activé. Il sagit du partage de bureau à distance : vino-server qui utilise le port 5900.
  • Deuxieme cas, vous avez déja une session graphique lancée sur le serveur. Lors du demarrage, vncserver va associer l'indice du port avec celui du display. Evidement si on a deja une session graphique, le display :0 sera déja utilisé d'ou le saut à l'indice suivant.

On aurait pu lancer le serveur de la manière suivante pour choisir son port/instance :

vncserver :1
Les options de lancement :

Pour spécifier la taille du bureau. (La valeur par défaut est 1024x768)

-geometry widthxheight

Chaque instance peut avoir son nom propre. Par défaut il est fixé à : "host:display# (username)".

-name desktop-name

Pour indiquer à Xvnc de ne pas lancer la mini instance http (port 580x) utilisable avec un applet Java VNC.

-nohttpd
Arrêter une instance

La commande suivante va stopper le serveur VNC de l'instance 1 (port 5901)

vncserver -kill :1

Lancement d'un serveur en tant que service :

Il va faloir cette fois être root ou avoir droit à un sudo pour lancer le service

[root@machine_a_toto ~]# service vncserver start
Démarrage de Serveur VNC :no displays configured           [ÉCHOUÉ]

Rien ne se passe sans un minimum de configuration.

Editer le fichier : /etc/sysconfig/vncservers Voici un exemple de configuration pour lancer deux instances Xvnc.

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.  
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# .
#
# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.
#
# Use "-nohttpd" to prevent web-based VNC clients connecting.
#
# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.
#
# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"
#
VNCSERVERS="1:toto 2:titi"
VNCSERVERARGS[1]="-geometry 800x600 -nolisten tcp -nohttpd"
VNCSERVERARGS[2]="-geometry 1024x768 -nolisten tcp -nohttpd -localhost"
On a nos deux instances :

La première sur le port 5901 avec l'utilisateur toto, sans serveur HTTP avec une taille de fenêtre de 800x600 pixels.

La 2eme pour l'utilisateur titi sur le port 5902. Une autre taille de fenêtre et un accès possible seulement depuis localhost.

C'est un peu idiot de restreindre localement l'accès VNC non ? Puisque l'utilisateur pourrait aussi bien lancer une session graphique ordinaire sur la machine.

Pas tant que ca, cette technique sera documentée dans un autre article mettant en oeuvre ssh pour faire passer le flux VNC dans un tunnel chiffré.

Alors, ca fonctionne cette fois ?

Non ce n'est pas encore suffisant, si j'essaye a nouveau de lancer le service, il ne démmarre toujours pas et ne m'insulte pas plus que ca. (Si quelqu'un trouve des logs à ce sujet d'ailleurs ? un niveau de debug à positionner ?).

[root@machine_a_toto ~]# service vncserver start
Démarrage de Serveur VNC :1:jc                             [ÉCHOUÉ]

En effet avec cette méthode de de lancement, vncpasswd n'est pas appelé et le répertoire ~/.vnc n'a même pas été créé.

Positionnons les mots de passe pour ces deux utilisateurs. Ce qui donne pour toto :

[root@machine_a_toto ~]# /bin/su - toto
[toto@machine_a_toto ~]$ vncpasswd
Password: xxxx
Password must be at least 6 characters - try again   (6 caractères minimum)
Password: xxxxxx
Verify: xxxxxx

On peut maintenant démmarrer le service :

[root@machine_a_toto ~]# service vncserver start
Démarrage de Serveur VNC :1:toto
New 'machine_a_toto:1 (toto)' desktop is machine_a_toto:1

Creating default startup script /home/toto/.vnc/xstartup
Starting applications specified in /home/toto/.vnc/xstartup
Log file is /home/toto/.vnc/machine_a_toto:1.log

2:titi xauth:  creating new authority file /home/mud/.Xauthority

New 'machine_a_toto:2 (titi)' desktop is machine_a_toto:2

Creating default startup script /home/titi/.vnc/xstartup
Starting applications specified in /home/titi/.vnc/xstartup
Log file is /home/titi/.vnc/machine_a_toto:2.log                                                             [  OK  ]
C'est très joli comme ca !

Avant de voir la 3eme méthode de lancement, si on essayait d'avoir un joli bureau.

A ce stade, voici ce qu'on obtient sur le poste client après s'être connecté par VNC.

vu du client

Même pas de quoi fouetter une sardine. Un simple gestionnaire de fenêtres et un terminal xterm.

Pour obtenir un beau bureau avec gnome, il suffit d'éditer le fichier créé lors du premier lancement de Xvnc. ~/.vnc/xstartup

#!/bin/sh
#
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
#
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

Enlever les commentaires des 2 lignes en rouge, relancer le serveur VNC et réjouissez vous !

3eme méthode : Lancement du serveur par xinetd pour accéder à la fenêtre de login

Il y a un peu plus de travail, commençons dans l'ordre :

Intégration du lancement par xinetd

Créer le fichier : /etc/xinet.d/vnc Voici en exemple la conf. que j'utilise.

service vncserver
{
        disable = no
        socket_type = stream
        protocol = tcp
        wait = no
        user = root
        server = /usr/bin/Xvnc
        server_args = -inetd -query localhost -once -geometry 1024x768 -nevershared -ac securitytypes=none
}

Recharger la configuration de xinetd

service xinetd reload

Ca ne peut toujours pas fonctionner correctement, xinetd refuse d'ouvrir le port. Si on regarde les logs de relance : /var/log/messages

Mar 23 09:52:15 machine_a_toto xinetd[2975]: Port not specified and can't find service: vncserver with getservbyname

Il faut renseigner le fichier /etc/services avec le nouveau nom de service que l'on vient de créer.

vncserver       5900/tcp                        # Xvnc
vncserver       5900/ucp                        # Xvnc

Re-chargement de xinetd

service xinetd reload

Un peu d'analyse

Ici, on peut voir le port 5900 en écoute par xinetd et deux clients connectés au serveur VNC (170.203.10.22). Remarquez qu'on utilise qu'un seul port (5900) pour l'ensemble des instances Xvnc.

[root@machine_a_toto ~]# netstat -an|fgrep 5900
tcp        0      0 170.203.10.22:5900          170.203.8.7:3819            ESTABLISHED 
tcp        0      0 170.203.10.22:5900          170.203.10.30:1338          ESTABLISHED 
tcp        0      0 :::5900                     :::*                        LISTEN

La structure de xinetd et ses fils ainsi que les PID pour la suite.

[root@machine_a_toto ~]# ps auxf|fgrep inetd
root      2975  0.0  0.0   2564   860 ?        Ss   09:35   0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
root      4845  0.2  0.5  18064 11580 ?        Ss   14:14   0:07  \_ Xvnc -inetd -query localhost -once -geometry 1024x768 -nevershared -ac securitytypes=none
root      5209  0.2  0.3  14320  7588 ?        Ss   14:52   0:00  \_ Xvnc -inetd -query localhost -once -geometry 1024x768 -nevershared -ac securitytypes=none

On voit ici les deux displays sur les ports 6001 et 6002.

[root@machine_a_toto ~]# lsof -p 5209
...
Xvnc    4845 root    1u  IPv4     140947              TCP *:6001 (LISTEN)
...
[root@machine_a_toto ~]# lsof -p 4845
...
Xvnc    5209 root    1u  IPv4     179449              TCP *:6002 (LISTEN)
...

Pour se connecter avec un client VNC, il suffira dans ce cas de spécifier l'adresse IP du serveur uniquement, la requete s'effectuant par défaut sur le port 5900.

Ca ne fonctionne toujours pas ?

Mon affichage est tout gris :

Tout gris

On a besoin d'obtenir une invite de session pour s'authentifier et accéder à une session Gnome.

Dans certains cas, tout dépend de la distribution, de son age et de son niveau de sécurité, il faudra activer XDMCP.

Editer le fichier /etc/gdm/custom.conf et ajoutez simplement dans la bonne section :

[xdmcp]
Enable=true

Votre serveur VNC se comportera en serveur XDMCP pour fournir des session X à votre client distant qui executera lui même son serveur X ... facile :o) Vérifiez aussi si votre serveur est bien en niveau d'execution 5. Si ce n'est pas le cas, un simple "init 5" réglera le problème.

Et le client ?

Les paquets nécéssaires sont : - vnc.i386 - vnc-libs.i386

vncviewer hostname(:port|:id)