Figura 227.1. Comunicazione tra il servente e il cliente VNC.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
Con un terminale a caratteri è possibile gestire una sessione di lavoro trasferibile successivamente in un altro terminale, attraverso il programma Screen (sezione 116.3); in modo simile, è possibile agire per quanto riguarda la sessione di lavoro con un servente X, attraverso VNC, (1) ovvero Virtual network computing.
È bene ricordare che X offre già la possibilità di eseguire un programma in un elaboratore, mostrandone le finestre nel servente di un altro (sezione 217.5). Diversamente da questa modalità comune di utilizzo di X, VNC consente di controllare tutto il servente grafico e il gestore di finestre (o anche il gestore di sessione) relativo. Inoltre, VNC consente anche un accesso simultaneo da parte di più terminali remoti, solitamente per permettere la visualizzazione di ciò che avviene.
VNC si compone essenzialmente di un programma servente, con le funzionalità grafiche di X, il quale non si collega a una stazione grafica e viene usato attraverso un programma cliente apposito. Questo servente comunica nel modo consueto, come un servente X normale (connessioni TCP alle porte 6 000+n) a cui si aggiunge la comunicazione necessaria al controllo attraverso il proprio cliente specifico, con le porte 5 900+n.
|
Figura 227.1. Comunicazione tra il servente e il cliente VNC.
|
La figura mostra una situazione comune, in cui un elaboratore ospita un servente VNC, dinkel.brot.dg, che offre la stazione grafica virtuale :1. In tal modo, la comunicazione con il servente avviene alla porta 5 901 (ovvero 5 900 più il numero corrispondente alla stazione grafica virtuale).
Nell'elaboratore che ospita il servente VNC, l'interazione con questo non risulta apparente, a meno di avviare nello stesso un cliente VNC.
Il cliente VNC, a sua volta, potrebbe essere autonomo, oppure richiedere un servente X normale per poter funzionare. Il programma mostrato in figura è un esempio di cliente che richiede X per poter funzionare.
Un servente VNC può essere utilizzato da un solo cliente, oppure può essere consentito un accesso simultaneo da parte di più clienti; in tal caso, probabilmente, viene concesso a uno solo di interagire, mentre agli altri è permesso solo osservare. Pertanto, le situazioni più comuni di utilizzo di un sistema grafico basato su VNC sono due: l'esigenza di mantenere in funzione una sessione di lavoro grafica, a cui poter accedere da un terminale remoto, sospendendo e riprendendo la connessione anche da altre posizioni; oppure l'esigenza di fare un lavoro che altri utenti possono visualizzare, senza bisogno di un proiettore.
L'accesso a un servente VNC è controllato esclusivamente attraverso il confronto di una parola d'ordine, definita in modo indipendente dal meccanismo di riconoscimento degli utenti del sistema operativo.
Il funzionamento del servente VNC dipende dalla configurazione del servente X: se X non funziona correttamente a causa di un difetto di configurazione, anche il servente VNC non può funzionare. Pertanto, di solito si avvia un servente VNC da una sessione X già attiva, probabilmente da una finestra di terminale:
vncserver [:n_stazione_grafica] [opzioni] |
Il programma vncserver è in realtà un involucro per controllare l'avvio di Xvnc, Xrealvnc o Xtightvnc (dipende dall'edizione e ci possono essere anche altri nomi), che è invece il vero servente VNC.
Generalmente, l'avvio del servente VNC avviene sulla stazione grafica :1, anche quando la stazione grafica :0 non risulta impegnata, salvo che sia indicato diversamente con le opzioni della riga di comando.
Quando un utente avvia per la prima volta un servente VNC nel modo descritto, questo crea la directory ~/.vnc/, in cui vengono annotate le informazioni sulle sessioni di lavoro relative, oltre a un file contenente una parola d'ordine cifrata, che serve per consentire l'accesso successivo. In ogni caso, la prima volta provvede vncserver a preparare tutto; l'esempio seguente si riferisce all'utente tizio presso l'elaboratore dinkel.brot.dg:
$ vncserver[Invio]
You will require a password to access your desktops. |
Password: digitazione_all'oscuro[Invio]
Verify: digitazione_all'oscuro[Invio]
New 'X' desktop is dinkel:1 Starting applications specified in /etc/X11/Xsession Log file is /home/tizio/.vnc/dinkel:1.log |
Come si può intendere, viene richiesta l'indicazione e la conferma di una parola d'ordine, che non può essere troppo breve, la quale viene conservata nel file ~/.vnc/passwd in forma cifrata. Quando l'utente dovesse avviare nuovamente un servente VNC, disponendo già di questo file, non verrebbe più chiesta la parola d'ordine, rimanendo la stessa già stabilita in precedenza.
Superata questa fase, viene avviato effettivamente il servente VNC. Nell'esempio risulta avviato sulla stazione grafica virtuale :1; pertanto, per poterlo raggiungere, si deve usare un indirizzo del tipo dinkel.brot.dg:1 (in generale conviene evitare la forma abbreviata che viene suggerita da vncserver).
Al termine, vncserver ricorda dove si può trovare il file in cui sono annotate le informazioni specifiche sull'avvio del servente VNC, che diventa molto utile quando questo non si avvia come si desidera, per scoprire l'origine del problema. In generale, questo file ha la forma: ~/.vnc/nodo:n_stazione_grafica.log.
|
Non sono da escludere problemi di configurazione di XFree86, che XFree86 stesso è in grado di superare, mentre il servente VNC non può. |
Inizialmente, il contenuto di questo file può essere simile al testo seguente:
|
Eventualmente, se sono stati installati i componenti necessari di VNC, vncserver avvia il servente VNC in modo da offrire anche un accesso HTTP alla porta 5 800+n, per mezzo del quale, con un navigatore in grado di mettere in funzione programmi Java, è possibile accedere in mancanza di un programma cliente migliore. In tal caso, si può osservare questo fatto nello stesso file appena mostrato:
|
In questo caso, l'indirizzo per accedere è preferibilmente http://dinkel.brot.dg:5801.
Se si vuole avviare il servente VNC senza avviare prima X, le cose si complicano un po'. Infatti, quando ciò è possibile, X determina da solo alcune informazioni sul funzionamento dell'adattatore grafico e sulle capacità dello schermo reale; pertanto, quando si avvia il servente VNC da una sessione di X già attiva, le stesse informazioni vengono utilizzate da VNC, mentre in mancanza di queste, il funzionamento di VNC dipenderebbe da parametri predefiniti, spesso non gradevoli. Per esempio, avviando un servente VNC senza l'appoggio di un servente XFree86 preesistente, si ottiene una stazione grafica impostata sostanzialmente per un adattatore di tipo VGA standard (640×480 punti grafici e una profondità di colori modesta). L'esempio seguente mostra l'avvio di un servente VNC, attraverso vncserver, al di fuori di una sessione di lavoro con X, dove si specifica la dimensione della superficie grafica (1 024×768 punti grafici) e la profondità di colori (16 bit):
$ vncserver -depth 16 -geometry 1024x768[Invio]
Per concludere il funzionamento del servente VNC, presso l'elaboratore locale, si può usare vncserver con l'opzione -kill:
vncserver -kill :n_stazione_grafica |
Al termine della descrizione dell'avvio di un servente VNC, è bene chiarire che, quando accede un cliente VNC, se già esiste un altro programma cliente collegato, generalmente questo (quello preesistente) termina di funzionare. In pratica, in condizioni normali, si suppone che l'utente che accede a un servente VNC sia l'unico autorizzato a farlo, pertanto, se è rimasta una sessione aperta, ciò è dovuto probabilmente a una dimenticanza dello stesso. Per consentire degli accessi simultanei al servente VNC, è necessaria l'opzione -alwaysshared, come descritto nella tabella seguente, che riepiloga alcune opzioni per l'avvio dell'involucro vncserver.
|
Tabella 227.6. Alcune opzioni della riga di comando di vncserver. |
L'impostazione effettiva di un servente X in una distribuzione GNU, può essere molto complessa. In altri termini, il funzionamento di xinit e di startx, non è perfettamente uniforme da una distribuzione all'altra, spesso per la necessità di arginare dei problemi di sicurezza. Pertanto, qualsiasi sia la ragione, può succedere che un servente VNC non si comporti come ci si aspetterebbe; si può arrivare anche a vedere funzionare il servente, ma senza un gestore di finestre o un gestore di sessione.
Di fronte a problemi di questo tipo, può essere più conveniente avviare direttamente il servente VNC senza l'aiuto dell'involucro vncserver, predisponendo uno script adatto alle proprie esigenze. Vengono mostrati qui due script: uno per controllare Xvnc, ovvero l'eseguibile del servente VNC, l'altro per controllare l'avvio di un gestore di finestre, chiamato all'interno del primo. A fianco di questi esempi, ne vengono mostrati comunque anche di equivalenti in cui si utilizza vncserver, ma in modo da ottenere lo stesso risultato, perché alle volte può essere vero il contrario, ovvero che senza vncserver non si riesca ad avviare VNC.
|
|
Il primo di questi due script, denominato qui vncs1024, definisce inizialmente una variabile di ambiente, contenente l'elenco delle directory dei caratteri di X (questa informazione può essere tratta eventualmente dal file di configurazione di X: /etc/X11/XF86Config*, /etc/X11/xorg.conf, ecc.). Successivamente elimina i processi avviati con il nome Xvnc, Xrealvnc o Xtightvnc, ammesso che ce ne siano, poi elimina anche il contenuto della directory ~/.vnc/; quindi chiede di definire una parola d'ordine nuova, con l'aiuto di vncpasswd.
Quando tutto è pronto, si avvia l'eseguibile Xvnc, utilizzando la stazione grafica :1 (come fa normalmente vncserver), con un elenco piuttosto lungo di opzioni, come si può vedere dall'esempio. In particolare, in questo caso, si specifica una dimensione della superficie grafica di 1 024×768 punti grafici, inviando il flusso dello standard error nel file ~/.vnc/log, per poter sapere ciò che accade. Si osservi inoltre che Xvnc viene avviato sullo sfondo in modo esplicito.
Infine si avvia uno script vncwm, il cui scopo è quello di avviare un gestore di finestre e di chiudere il funzionamento di Xvnc, Xrealvnc o Xtightvnc, al termine del funzionamento di questo. Infatti, come si vede, lo script carica un fondale e avvia Fvwm: al termine del funzionamento di Fvwm elimina tutti i processi con il nome Xvnc, Xrealvnc e Xtightvnc.
|
Naturalmente, in questo modo si può avviare un solo servente VNC alla volta. |
Da quanto visto si intuisce la sintassi per l'avvio dell'eseguibile Xvnc:
Xvnc [:n_stazione_grafica] [opzioni] |
Segue la descrizione di alcune opzioni della riga di comando.
|
Tabella 227.9. Alcune opzioni della riga di comando di Xvnc. Si osservi che a seconda della realizzazione di VNC, alcune opzioni potrebbero non funzionare. |
In alternativa all'avvio diretto di Xvnc, il comando di avvio potrebbe essere sostituito così:
|
Si può osservare la comparsa dell'opzione -startup, con la quale si vuole evitare che vncserver avvii autonomamente un gestore di sessione o altro, che comunque viene già controllato all'interno del proprio script.
Non esiste una configurazione vera e propria del servente VNC; esiste piuttosto una configurazione di vncserver, che di solito si lascia commentata completamente. In ogni caso, si tratta del file /etc/vnc.conf ed eventualmente di ~/.vncrc.
L'utilizzo di questi file diventa utile, quindi, solo se si avvia il servente VNC attraverso vncserver e si sono manifestati dei problemi a cui si pone rimedio solo con la configurazione.
Una situazione in cui è necessario intervenire nella configurazione è la presenza di direttive FontPath nel file di configurazione di X (/etc/X11/XF86Config*, /etc/X11/xorg.conf, ecc.), che fanno riferimento a caratteri tipografici non esistenti; per esempio quando queste informazioni sono fornite da un servente di caratteri che in quel momento non risulta rispondere. In tal caso, si può specificare nella configurazione quali percorsi sono sicuri, tralasciando il superfluo.
Si può accedere a un servente VNC con diversi programmi, ma in un sistema GNU dovrebbe essere preferibile farlo attraverso xvncviewer. Come lascia intuire il nome, si tratta di un programma che richiede l'uso di un servente X già attivo, che mostra poi la stazione grafica remota in una finestra di quella locale.
Di solito è necessario avviare xvncviewer da una finestra di terminale, per poter specificare a quale nodo e a quale stazione grafica collegarsi. Si utilizza la sintassi seguente:
xvncviewer [opzioni] nodo:n_stazione_grafica |
Se nella riga di comando non viene specificata l'opzione -passwd (con la quale si indica un file contenente una parola d'ordine cifrata), è necessario inserire la parola d'ordine per l'accesso al servente VNC:
$ xvncviewer dinkel.brot.dg:1[Invio]
VNC viewer version 3.3.5 - built Nov 22 2002 09:31:25 Copyright (C) 2002 RealVNC Ltd. Copyright (C) 1994-2000 AT&T Laboratories Cambridge. See http://www.realvnc.com for information on VNC. VNC server supports protocol version 3.3 (viewer 3.3) |
Password: digitazione_all'oscuro[Invio]
Successivamente vengono visualizzate altre informazioni, quindi appare la finestra relativa alla comunicazione con il servente VNC.
Quando si vuole visualizzare semplicemente ciò che accade in un servente VNC, senza poter interferire, mentre un altro cliente VNC sta interagendo, si può usare l'opzione -viewonly, assieme a -shared. Eventualmente, dalla parte del servente si può usare l'opzione -alwaysshared per garantire che sia consentito l'accesso simultaneo da parte di più clienti (questa opzione vale sia per l'avvio diretto di Xvnc, sia per l'involucro vncserver):
$ xvncviewer -viewonly dinkel.brot.dg:1[Invio]
Segue la descrizione di alcune opzioni.
|
Tabella 227.12. Alcune opzioni della riga di comando di xvncviewer. |
Se il proprio sistema GNU/Linux dispone della libreria SVGAlib (capitolo 215) configurata correttamente, è possibile usare il programma svncviewer (2) per accedere a un servente VNC senza bisogno di X:
svncviewer [opzioni] nodo:n_stazione_grafica |
Come ogni programma che richieda di accedere direttamente all'adattatore grafico, anche questo deve essere avviato con i privilegi dell'utente root, pertanto, può essere necessario attribuirgli il permesso SUID associato all'utente root (SUID-root).
Le opzioni principali e gli argomenti per l'uso di questo programma sono abbastanza simili a quelle di xvncviewer, come annotato nella tabella successiva.
|
Tabella 227.13. Alcune opzioni della riga di comando di svncviewer. |
La situazione in cui è più comune l'utilizzo di VNC è quella dell'utente che si trova lontano dal proprio elaboratore, al quale può comunque accedere attraverso la rete. In generale, in questo elaboratore remoto non è già in funzione alcun servente VNC, pertanto conviene avviare X nell'elaboratore di cui si dispone temporaneamente; quindi, da lì, con una finestra di terminale, si può contattare l'elaboratore remoto e avviare il servente VNC. Se tutto funziona correttamente, il servente VNC viene avviato con caratteristiche compatibili alla grafica di cui si dispone effettivamente; quindi ci si può collegare con un cliente VNC.
elaboratore_locale$ ssh tizio@dinkel.brot.dg[Invio]
In questo modo ci si collega all'elaboratore dinkel.brot.dg utilizzando l'utenza tizio. Successivamente si avvia il servente VNC presso l'elaboratore remoto:
elaboratore_remoto$ vncserver[Invio]
Quindi, se tutto ha funzionato correttamente ci si collega con un cliente VNC:
elaboratore_remoto$ exit[Invio]
elaboratore_locale$ xvncviewer dinkel.brot.dg:1[Invio]
Attraverso Secure Shell (capitolo 400) è possibile creare un tunnel cifrato, per utilizzare con più tranquillità l'accesso a un servente VNC. Viene riproposto l'esempio di utilizzo comune, utilizzando un tunnel del genere:
elaboratore_locale$ ssh tizio@dinkel.brot.dg[Invio]
In questo modo ci si collega all'elaboratore dinkel.brot.dg utilizzando l'utenza tizio. Successivamente si avvia il servente VNC presso l'elaboratore remoto:
elaboratore_remoto$ vncserver[Invio]
Dall'elaboratore locale ci si collega nuovamente con l'elaboratore remoto per creare un tunnel cifrato:
elaboratore_remoto$ exit[Invio]
elaboratore_locale$ ssh -N -L 5901:dinkel.brot.dg:5901[Invio]
A questo punto, invece di contattare direttamente l'elaboratore remoto dinkel.brot.dg, è invece sufficiente collegarsi a quello locale; prima però, conviene mettere il programma ssh sullo sfondo:
[Ctrl z]
elaboratore_locale$ bg[Invio]
elaboratore_locale$ xvncviewer localhost:1[Invio]
È possibile realizzare uno script con cui si avvia un servente VNC e subito dopo X con un cliente VNC, a tutto schermo, che punta esattamente al servente locale, senza interferire con l'utente. Questo tipo di tecnica può servire in un laboratorio didattico in due casi: quando l'insegnante vuole avviare una sessione di lavoro grafica, pronta subito perché gli studenti vi si possano collegare, evitando così di utilizzare una lavagna luminosa; quando si vuole fare avviare agli studenti la sessione di lavoro grafica in modo che l'insegnante abbia la possibilità di intervenire sul loro lavoro, senza doversi spostare fisicamente dalla sua postazione.
|
Come si può osservare, questo esempio è molto simile a quanto già visto in una sezione precedente, dove la novità sta nell'avviare, dopo lo script vncwm, xinit specificando l'avvio di xvncviewer al posto del solito gestore di finestre. Naturalmente, lo script vncwm rimane tale e quale a prima:
|
Come si può intuire, lo script che qui è stato chiamato vncsc1024 è adatto per l'insegnante (o il relatore) che vuole consentire l'accesso ai suoi studenti, a cui deve comunicare anche la parola d'ordine per accedere, che come si vede viene sostituita ogni volta. Diversamente, se si vuole realizzare uno script da fare usare agli studenti al posto del solito startx, si deve fare in modo che il file della parola d'ordine sia già stato preparato e sia «standard»; l'estratto seguente mostra solo le istruzioni salienti da modificare:
|
Anche qui è possibile utilizzare vncserver con l'aggiunta dell'opzione -startup:
|
I due filoni principali dello sviluppo di VNC sono rappresentati da RealVNC e da TightVNC. In generale, questi lavori sono abbastanza compatibili tra di loro, comunque vale la pena di conoscere i nomi con cui potrebbero essere distinti i programmi e gli script che li riguardano:
La distribuzione nanoLinux (volume XXVI) includeva uno script, denominato vncrc (oggi incorporato in nanorc), con lo scopo di facilitare l'uso di VNC (RealVNC o TightVNC), nelle situazioni più comuni. Viene proposta qui una versione semplificata di quello script, che potrebbe essere utile anche al di fuori del contesto particolare di nanoLinux. Una copia dovrebbe essere disponibile anche qui: <allegati/a2/vncrc>).
|
VNC è un lavoro che ha prodotto diversi filoni di sviluppo, per esigenze differenti. Oltre a quanto descritto in questo capitolo esistono diversi altri programmi che possono essere di un certo interesse. Di tale disponibilità è bene tenerne conto, per sapere che può essere utile una ricerca approfondita prima di organizzare il proprio lavoro in modo sistematico con VNC.
RealVNC
TightVNC
Karl Runge, x11vnc: a VNC server for real X displays
Giuseppe De Marco, Cripting delle sessioni VNC, articolo contenuto nella rivista Linux magazine, edizioni Master, ISSN 1592-8152, anno III, numero 25, dicembre 2002
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
2) Svncviewer GNU GPL
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome x_accesso_remoto_alla_sessione_di_lavoro.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
