|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
Con le distribuzioni GNU normali, dopo la configurazione del servente X, dovrebbe essere sufficiente avviare lo script startx, senza argomenti, per vedere funzionare questo ambiente grafico.
$ startx[Invio]
Avendo avviato il servente X, vale la pena di provare a cambiare la risoluzione di visualizzazione attraverso la combinazione [Ctrl Alt +] («control», «alt», «+ del tastierino numerico») e [Ctrl Alt -] («control», «alt», «- del tastierino numerico»).
Per passare dal servente X a una console virtuale, è sufficiente utilizzare la combinazione [Ctrl Alt F1], oppure [Ctrl Alt F2],... invece del solito [Alt Fn] che non potrebbe funzionare. Il servente X occupa normalmente la posizione della prima console virtuale libera, che solitamente è la settima; per cui si raggiunge con la combinazione [Ctrl Alt F7].
Per concludere l'esecuzione del servente X ci sono due modi:
interrompere il servente attraverso la combinazione [Ctrl Alt Backspace];
concludere l'esecuzione del gestore di finestre o di altro programma analogo.
L'interruzione dell'esecuzione del servente X con la combinazione [Ctrl Alt Backspace] è il modo più brutale, ma può essere opportuno quando non si vede più nulla, specie quando si è avviato X dopo una configurazione sbagliata.
Nelle sezioni precedenti si è accennato al modo con cui è possibile avviare e concludere il funzionamento del servente X. Dovrebbe essere chiaro che per avviare X si utilizza normalmente lo script startx (anche se non è l'unico modo possibile), dal quale si sviluppa una struttura piuttosto articolata che è opportuno conoscere.
Quando sono disponibili diversi serventi grafici distinti a seconda del tipo di adattatore grafico, si crea un collegamento simbolico in modo da poter avviare il servente giusto utilizzando semplicemente il nome X. In pratica, dovrebbe essere il programma di configurazione stesso che provvede a sistemare questa cosa.
Se si avvia semplicemente il servente, utilizzando il nome X oppure quello specifico di un adattatore grafico particolare, si ottiene solo una superficie grafica su cui fare scorrere il mouse. Per poter fare qualcosa, occorre almeno avere in funzione un programma che consenta di avviarne altri. Occorrono cioè dei clienti.(1)
Per risolvere questo problema si deve utilizzare il programma xinit, attraverso il quale si possono definire alcuni clienti di partenza (per esempio un gestore di finestre), il tipo di servente da utilizzare e le sue opzioni eventuali.
Il programma xinit viene usato per avviare il servente X e un primo programma cliente. Quando questo programma cliente termina la sua esecuzione, xinit invia un segnale di interruzione al servente X e quindi, a sua volta, termina la sua esecuzione.
xinit [[cliente] opzioni] [ -- [servente] [stazione_grafica] opzioni] |
Se non viene indicato un programma cliente specifico, xinit tenta di avviare il file ~/.xinitrc, che di solito dovrebbe corrispondere a uno script; se questo manca, tenta di avviare il programma xterm nel modo seguente:
xterm -geometry +1+1 -n -login -display :0 |
Se non viene indicato un programma servente specifico, xinit tenta di avviare il file ~/.xserverrc; se questo manca, tenta di avviare il programma X nel modo seguente:
X :0 |
Quando si vuole fare in modo che il servente X venga avviato inizialmente con un gruppetto di programmi clienti, si fa in modo che xinit utilizzi per questo uno script. Di solito si tratta proprio del file ~/.xinitrc, quello che verrebbe avviato in modo predefinito. All'interno di questo script, i programmi dovrebbero essere avviati sullo sfondo, con la possibile eccezione di quelli che terminano immediatamente la loro funzione. L'ultimo di questi programmi deve funzionare in primo piano (foreground), in modo che la sua conclusione corrisponda con quella dello script stesso.
Di solito, xinit viene avviato senza l'indicazione esplicita di cliente e servente. Se si intende utilizzare questa possibilità, i nomi di cliente e servente devono comprendere il percorso per raggiungerli: devono cioè iniziare con un punto (.) oppure con una barra obliqua (/). Diversamente non verrebbero riconosciuti come tali, ma come opzioni per il programma cliente o per il programma servente, a seconda che si trovino a sinistra o a destra dei due trattini di separazione (--). Segue la descrizione di alcuni esempi.
$ xinit &[Invio]
Avvia xinit con i valori predefiniti (sullo sfondo). In questo modo xinit tenta di avviare il servente X utilizzando il programma o lo script ~/.xinitrc come cliente, oppure il programma xterm in sua mancanza.
$ xinit -- /usr/bin/X11/X &[Invio]
Si richiede a xinit di avviare il servente /usr/bin/X11/X (probabilmente è un programma con privilegi speciali che a sua volta avvia /usr/bin/X11/Xorg). Per quanto riguarda il cliente, si utilizzano i valori predefiniti.
$ xinit -- -depth 16[Invio]
xinit avvia il servente X predefinito, con l'argomento -depth 16, attraverso cui si richiede una profondità di colori di 16 bit/pixel (216 = 65 535). Per quanto riguarda il cliente, si utilizzano i valori predefiniti.
Il modo migliore per verificare cosa accade quando si avvia xinit è quello di verificare l'interdipendenza tra i processi attraverso pstree. Supponendo di avere avviato xinit senza argomenti si dovrebbe ottenere uno schema simile a quello seguente:
|
In questo caso si può osservare che xinit avvia il terminale grafico xterm, che a sua volta avvia una shell.
Nella sezione precedente si è visto che è possibile avviare il servente X attraverso xinit. Questo modo potrebbe però risultare scomodo quando si ha la necessità di utilizzare sistematicamente determinati attributi. Il sistema grafico dovrebbe essere avviato attraverso lo script startx, che è predisposto per xinit nel modo più adatto alle esigenze particolari del proprio sistema.
Di solito le distribuzioni GNU forniscono uno script adattato alla loro impostazione, oppure, lo stesso programma di configurazione di X potrebbe predisporre da solo questo file. In ogni caso, l'amministratore del sistema dovrebbe rivedere questo script ed eventualmente ritoccarlo.
La sintassi di startx, quando si tratta di una versione aderente all'impostazione originale di X, è praticamente uguale a quella di xinit.
startx [[cliente] opzioni] [ -- [servente] opzioni] |
Lo script startx offre però la possibilità di predisporre delle opzioni predefinite per cliente e servente.
|
Nell'esempio appena visto, sarebbe sufficiente modificare le prime righe per definire delle opzioni predefinite, attribuendo un valore alle variabili clientargs e serverargs. La prima si riferisce alle opzioni per il cliente, la seconda per quelle del servente.
Per esempio, volendo avviare il servente, attraverso startx, con una risoluzione di 16 bit/pixel, basterebbe modificare le prime righe come nell'esempio seguente, in modo da fornire al servente l'opzione -depth 16.
|
Tuttavia, si scorge facilmente la possibilità di usare dei file di configurazione generali per tutto il sistema:
|
Pertanto, la possibilità di modificare direttamente lo script è da considerare solo come ultima risorsa.
Se il funzionamento dello script indicato come esempio non dovesse risultare chiaro, ecco in breve la descrizione delle varie fasi in esso contenute.
Vengono definite delle variabili per le impostazioni predefinite.
Si determina quale script utilizzare per l'avvio dei programmi clienti e quale per l'avvio del servente.
Nel ciclo while, vengono scanditi gli eventuali argomenti utilizzati per avviare startx; se ne vengono trovati, questi prendono il sopravvento su quelli predefiniti.
Se ci sono argomenti vengono utilizzati, altrimenti si fa riferimento al contenuto dei file di configurazione.
Se non è definita la variabile di ambiente XAUTHORITY, questa viene creata inserendovi il contenuto del file ~/.Xauthority.
Definisce l'autorizzazione all'accesso alla stazione grafica (display) attraverso una stringa generata in modo casuale, con il programma mcookie.
Avvia xinit con gli argomenti determinati in base all'elaborazione precedente.
Al termine del funzionamento di xinit, elimina l'autorizzazione concessa precedentemente.
Infine, viene liberata la memoria usata per l'utilizzo della console virtuale in cui prima si collocava il sistema grafico.
Da quanto visto finora, si può intuire l'importanza dello script ~/.xinitrc. È il mezzo attraverso cui avviare più programmi clienti, ma non solo: esistono programmi che hanno lo scopo di configurare alcune impostazioni del servente X e questo è l'unico posto comodo per metterli in esecuzione in modo automatico. Un esempio di questi programmi è xset.
Supponendo di avere avviato startx senza argomenti, si dovrebbe ottenere uno schema simile a quello seguente:
|
Come si può osservare, rispetto allo stesso esempio visto nella sezione precedente, si ha startx che avvia xinit, il quale poi provvede al resto.
Questo script è quello predefinito per l'avvio dei primi programmi clienti di un servente X avviato attraverso il programma xinit.
Per preparare il proprio script personalizzato si può partire da quello predefinito della distribuzione GNU che dovrebbe trovarsi all'interno di /usr/lib/X11/xinit/ (oppure /etc/X11/xinit/). Basta copiarlo nella propria directory personale e cambiargli nome facendolo diventare ~/.xinitrc.
La preparazione di questo script è molto importante, se non altro perché permette di definire il tipo di gestore di finestre che si vuole utilizzare.
Un tempo, il file predefinito era piuttosto complesso, includendo la procedura di autorizzazione all'accesso per la stazione grafica. Recentemente le cose sono cambiate e il problema di questa autorizzazione è stato spostato nello script startx. Pertanto, se verso la fine del file si incontra un commento del tipo # start some nice programs, si possono aggiungere dei comandi solo dopo quel punto; diversamente, se il file non contiene nulla di particolare, lo si può semplicemente scrivere da zero. L'esempio seguente si riferisce a un'impostazione recente, in cui il file ~/.xinitrc può limitarsi a contenere solo ciò che serve direttamente all'utente finale:
|
Il programma xsetroot definisce lo sfondo, in questo caso solo un colore, quindi termina immediatamente l'esecuzione. Il programma twm è il gestore di finestre (window manager) da avviare; in particolare si usa il comando exec allo scopo di rimpiazzare la shell. Eventualmente, prima di avviare il gestore di finestre si possono indicare altri programmi che si vuole siano già pronti in esecuzione quando si avvia il servente. Per esempio, volendo avviare xclock basterebbe modificare le ultime righe come segue:
|
In questo caso, xclock viene avviato sullo sfondo perché altrimenti, a differenza di xsetroot, rimarrebbe in funzione fino al ricevimento di un segnale di interruzione, impedendo così l'avvio del gestore di finestre fino al termine del suo funzionamento.(2)
|
Si deve ricordare che si tratta di uno script, pertanto occorre che gli siano attribuiti i permessi necessari di esecuzione. |
Quando si vuole fare in modo che si possa mettere in funzione il sistema grafico X senza costringere gli utenti a predisporre la loro personalizzazione tramite il file ~/.xinitrc, si deve essere in grado di risalire alla configurazione generale. In questo senso, ogni distribuzione GNU potrebbe avere una propria politica e questo rischia di complicare le cose. Qui viene proposta una situazione, ma in pratica ognuno deve rifare una propria ricerca.
Si parte dallo script startx per determinare la collocazione dei file di configurazione predefiniti:
|
In questo caso, si intende intuitivamente che:
lo script da usare per avviare i programmi clienti, secondo le impostazioni degli utenti, è ~/.xinitrc, mentre quello che stabilisce quale sia il programma servente è ~/.xserverrc;
in mancanza degli script degli utenti, si usano /usr/lib/X11/xinit/xinitrc e /usr/lib/X11/xinit/xserverrc rispettivamente;
in mancanza anche di questi file, si avvia semplicemente il programma xterm come cliente e il programma X come servente.
Tuttavia, dal momento che gli script /usr/lib/X11/xinit/xinitrc e /usr/lib/X11/xinit/xserverrc servono in pratica alla configurazione del sistema grafico, è normale che la loro collocazione reale sia invece nella directory /etc/X11/xinit/, dove i nomi di origine corrispondono soltanto a dei collegamenti simbolici. Nello stesso modo, il file /usr/bin/X11/X che rappresenta il servente predefinito, dovrebbe essere un programma che si limita ad avviare a sua volta il file /etc/X11/X, che a sua volta dovrebbe essere un altro collegamento simbolico che punta all'eseguibile corretto (di solito /usr/bin/X11/Xorg).
Giunti a questo punto conviene dare un'occhiata ai file /usr/lib/X11/xinit/xinitrc e /usr/lib/X11/xinit/xserverrc, ovvero a /etc/X11/xinit/xinitrc e /etc/X11/xinit/xserverrc. Il file xinitrc potrebbe presentarsi così:
|
In questo caso, si vede che viene letto il contenuto del file /etc/X11/Xsession e trattato come una prosecuzione dello script stesso. Attraverso questo script ulteriore, si fanno poi una serie di altre operazioni, con cui si configura in pratica ciò che viene così definito come sessione.
Senza entrare nel dettaglio dello script Xsession, vale la pena di annotare che questo, se lo trova, utilizza anche il file ~/.Xsession, nel caso un utente volesse definire l'utilizzo di un gestori di sessione diverso da quello predefinito.
Volendo dare un'occhiata allo script xserverrc, si potrebbe trovare un contenuto simile a quello seguente:
|
In pratica, si avvia il file /usr/bin/X11/X (/usr/bin/X11/X), che, come già descritto, dovrebbe corrispondere in pratica a un collegamento simbolico riferito a /etc/X11/X, il quale, a sua volta, dovrebbe essere un collegamento che punta al servente adatto per il proprio elaboratore.
|
In questo caso particolare, si vede che, per motivi di sicurezza, sono inibite espressamente le comunicazioni di rete attraverso il protocollo TCP/IP, con l'opzione -nolisten tcp. Pertanto, un utente che volesse abilitarle, dovrebbe scrivere il proprio file |
Esiste un particolare importante a proposito del funzionamento di un servente: per poter svolgere il suo compito deve poter accedere a certe risorse disponendo di privilegi adeguati. Perché ciò avvenga e sia consentito l'uso da parte di utenti comuni, è necessario che l'eseguibile che lo rappresenta abbia i permessi necessari a renderlo capace di questo. In pratica deve appartenere all'utente root e avere il bit SUID attivo (SUID-root). Generalmente, il file /usr/bin/X11/X è un programma che ottiene tali privilegi e si occupa di avviare il collegamento /etc/X11/X. L'esempio seguente mostra i permessi di questo file:
$ ls -l /usr/bin/X11/X[Invio]
-rwsr-sr-x 1 root root 7400 gen 29 18:35 /usr/bin/X11/X |
In questo modo, l'utente comune non può avviare direttamente l'eseguibile del servente grafico che preferisce, ma deve limitarsi a usare X.
X può gestire più di una stazione grafica virtuale simultaneamente, con una modalità d'uso simile a quella delle console virtuali di un sistema GNU/Linux. In pratica, è possibile avviare diversi serventi X a cui si abbina un numero di stazione grafica differente. Dal momento che si tratta sempre della stessa macchina fisica, la configurazione non cambia.
Come è stato descritto nelle sezioni precedenti, il sistema grafico viene avviato generalmente attraverso lo script startx, o eventualmente richiamando direttamente il programma xinit. Quando non si specificano opzioni particolari, si intende voler avviare il servente X utilizzando la stazione grafica :0. In un sistema GNU/Linux, ciò si traduce in pratica nell'utilizzo della posizione corrispondente alla prima console virtuale disponibile, che di solito è la settima.
Se si vogliono avviare altri serventi X, occorre specificare un diverso numero di stazione grafica, cosa che serve solo a distinguerle. Così, ogni nuovo servente avviato va a utilizzare una posizione corrispondente alla prima console virtuale rimasta libera. In pratica, [Ctrl Alt F7] dovrebbe permettere di raggiungere la prima di queste stazioni grafiche virtuali, [Ctrl Alt F8] la successiva e così di seguito.
Semplificando quanto mostrato nelle sezioni precedenti, a proposito di xinit e di startx, si può fare riferimento alla sintassi seguente per avviare un servente X.
xinit -- [stazione_grafica] [opzioni] |
startx -- [stazione_grafica] [opzioni] |
Dopo i due trattini di separazione della parte cliente da quella servente, è possibile indicare il numero della stazione grafica, e subito dopo si possono indicare altre opzioni.
Di solito, si avvia startx (e meno frequentemente si avvia direttamente xinit) senza indicare alcuna stazione grafica, facendo riferimento implicitamente al numero :0. Dopo averne avviato uno con questo numero, non ne possono essere avviati altri con lo stesso, quindi, se si vogliono gestire più serventi contemporaneamente, occorre definire la stazione grafica.
$ startx -- :1[Invio]
L'esempio mostrato avvia una copia del servente X utilizzando la stazione grafica :1.
Ci possono essere dei motivi per avviare diversi serventi X simultaneamente; per esempio per avere due o più sessioni funzionanti in qualità di utenti differenti, oppure per poter confrontare il funzionamento in presenza di diverse opzioni del servente, come nel caso seguente, dove si specifica una profondità di colori di 16 bit.
$ startx -- :2 -depth 16[Invio]
È importante tenere a mente che le opzioni del servente, che nell'esempio sono costituite solo da -depth 16, vanno poste dopo l'indicazione della stazione grafica.
Per l'utilizzo normale che si può fare di X non è necessario doversi rendere conto che ogni programma cliente deve specificare lo schermo su cui vuole apparire. Infatti, viene definita automaticamente la variabile di ambiente DISPLAY contenente le coordinate dello schermo predefinito. Modificando eventualmente il contenuto di questa variabile, si cambia l'indicazione dello schermo predefinito per i programmi che vengono avviati ricevendo quel valore.
Generalmente è possibile informare un programma dello schermo su cui questo deve apparire attraverso un argomento standard, -display, descritto nel capitolo 160.
Quando si esegue una sessione TELNET, o qualunque altra cosa che permetta di accedere a un sistema remoto, si avvia una procedura di accesso su un altro elaboratore, utilizzando il proprio come terminale o console remota. Quando si utilizza un servente X è possibile condividere lo schermo del proprio monitor. Per farlo occorre autorizzare l'utilizzo del proprio schermo all'elaboratore remoto. Si osservi il comando seguente:
tizio@dinkel.brot.dg:~$ xterm -display :0 &[Invio]
Si tratta dell'utente tizio, che dall'elaboratore dinkel.brot.dg intende avviare il programma xterm utilizzando lo schermo :0 presso il suo stesso elaboratore locale. Si osservi anche che se l'utente in questione avvia questo comando da una finestra di terminale che si trova già a funzionare sullo schermo :0, il comando seguente significherebbe la stessa cosa, in quanto l'informazione sullo schermo verrebbe ottenuta dalla variabile di ambiente DISPLAY, senza bisogno di utilizzare l'opzione -display:
tizio@dinkel.brot.dg:~$ xterm &[Invio]
Questo comando avvia xterm, il quale tenta di connettersi con il servente X che gestisce lo schermo locale :0.0 (abbreviato con :0), allo scopo di poterlo utilizzare: se il servente X si rifiuta, xterm deve rinunciare.
L'autorizzazione all'utilizzo del proprio schermo grafico da parte di programmi in esecuzione su altri elaboratori connessi in rete può avvenire semplicemente in base a un elenco di indirizzi autorizzati, oppure attraverso altre forme di riconoscimento. Qui vengono spiegati solo i modi più semplici e meno sicuri; per avere una visione completa delle possibilità si devono consultare le pagine di manuale X(1), xauth(1) e Xsecurity(1).
Il metodo più semplice in assoluto per concedere l'accesso al servente X è quello di stabilire attraverso il comando xhost quali sono gli elaboratori che possono accedere. Questo significa implicitamente che tutti gli utenti di questi elaboratori possono accedere. Volendo distinguere tra gli utenti, occorre utilizzare almeno il metodo delle chiavi in chiaro (MIT-MAGIC-COOKIE-1).
Per attuare in pratica questo secondo meccanismo, viene utilizzato un file di configurazione personale, ~/.Xauthority, nel quale sono elencati degli indirizzi di serventi X e le chiavi di accesso relative. Questo file non è leggibile direttamente; tuttavia, a titolo di esempio, potrebbe contenere le informazioni seguenti, che si riferiscono all'utente tizio presso il solito elaboratore dinkel.brot.dg:
|
Questo contenuto determina che il servente X, avviato dall'utente a cui appartiene questo file, accetta connessioni locali (attraverso un socket di dominio Unix) e connessioni remote, attraverso la tecnica del MIT-MAGIC-COOKIE-1, quando chi accede fornisce la chiave di riconoscimento 0f207ef0f71e2490b0648c26ed4f3e41. In questo caso, la chiave è la stessa, sia per le connessioni locali, sia per quelle attraverso la rete, ma potrebbero essere diverse; ciò che conta è che il cliente sia in grado di fornire la chiave giusta in base al tipo di connessione che effettua con il servente.
Per fare in modo che il cliente sappia quale chiave utilizzare, occorre che l'utente che tenta di accedere al servente X abbia un file ~/.Xauthority contenente un record adatto. In pratica, se l'utente caio vuole accedere, deve avere il record seguente nel caso questo avvenga nell'ambito dello stesso elaboratore locale:
|
Oppure, gli serve il record successivo nel caso debba accedere da un altro elaboratore:
|
|
Lo stesso utente che ha avviato il servente X deve essere autorizzato, attraverso il proprio file |
Si può comprendere meglio il meccanismo della chiave di riconoscimento MIT-MAGIC-COOKIE-1, solo se si pensa allo scopo che ha: una persona può avere la possibilità di accedere a più elaboratori di una stessa rete locale, ma le utenze relative potrebbero anche corrispondere a nominativi-utente distinti, a seconda dell'elaboratore. Questa persona può avere la necessità di accedere a uno di questi elaboratori, attraverso la rete, avviando lì un programma che però deve apparire presso la stazione da cui sta operando. In altri termini, quando c'è la necessità di avviare un programma che deve apparire sullo schermo di un altro elaboratore, di solito si tratta di utenze che appartengono alla stessa persona fisica; in questo senso non c'è nulla di strano se tutte queste utenze condividono la stessa chiave.
Dal momento che il file ~/.Xauthority non è un file di testo normale, per accedervi, si utilizza generalmente il programma xauth.
Il programma xauth è necessario per poter accedere alle informazioni contenute nei file di autorizzazione, normalmente ~/.Xauthority, per poterle modificare. Per la maggior parte delle situazioni, xauth non ha bisogno di contattare il servente X.
xauth [opzioni] [comando argomento...] |
Il programma xauth interviene in base a dei comandi, che gli possono essere impartiti come argomenti della stessa riga di comando, nella parte finale, oppure in modo interattivo, attraverso l'invito seguente:
xauth>
Spesso, i comandi richiedono l'indicazione di un file. In quella occasione, se si utilizza un trattino singolo (-), questo viene inteso come lo standard input, oppure lo standard output, a seconda del contesto.
|
Tabella 149.15. Alcune opzioni. |
|
Tabella 149.16. Alcuni comandi. I comandi di xauth possono essere impartiti in modo interattivo, oppure possono essere indicati come argomenti finali della riga di comando di xauth. |
Segue la descrizione di alcuni esempi.
tizio@dinkel.brot.dg:~$ xauth add :0 . 12345678[Invio]
L'utente aggiunge, o modifica, il record di autorizzazione riferito all'accesso locale, specificando per questo il protocollo MIT-MAGIC-COOKIE-1 in modo predefinito, attraverso il punto, indicando una stringa esadecimale molto semplice: 1234567816.
tizio@dinkel.brot.dg:~$ extract /tmp/prova :0[Invio]
Estrae una copia del record di autorizzazione all'accesso locale e la salva nel file /tmp/prova.
caio@dinkel.brot.dg:~$ merge /tmp/prova :0[Invio]
Un altro utente, si appropria dei record contenuti nel file /etc/prova.
tizio@roggen.brot.dg:~$ xauth extract - $DISPLAY; | \
\rsh dinkel.brot.dg xauth merge -[Invio]
L'utente tizio che sta utilizzando l'elaboratore roggen.brot.dg ottiene attraverso rsh di aggiungere al proprio file di autorizzazione remoto, quello presso la sua utenza corrispondente nell'elaboratore dinkel.brot.dg, il record riferito al servente X che sta utilizzando in quel momento. In altri termini, fa in modo di poter avviare dei programmi presso l'elaboratore remoto, utilizzando la stazione grafica su cui si trova. Si osservi l'uso della variabile di ambiente DISPLAY per ottenere l'indicazione precisa dello schermo che sta utilizzando e anche l'uso del trattino per collegare i due programmi attraverso i flussi standard.
Il programma mcookie ha lo scopo di generare un numero esadecimale, più o meno casuale, convertito in stringa, che viene emesso attraverso lo standard output:
mcookie |
La sua utilità sta solo nel facilitare la generazione di chiavi per il sistema di autorizzazione. La situazione più comune in cui viene utilizzato è il comando seguente, dove in pratica ci si risparmia di decidere la chiave:
$ xauth add :0 . `mcookie`[Invio]
Il file di autorizzazione è composto da record contenenti tre informazioni: la stazione grafica (senza il dettaglio dello schermo); il nome di un protocollo di autenticazione; una chiave, il cui significato varia a seconda del tipo di protocollo utilizzato.
È importante sottolineare che può esistere un solo record per stazione grafica, per cui, ogni volta che si aggiunge un record per una certa stazione, questo va a sostituire un altro record eventuale riferito alla stessa stazione.
In generale, si distingue tra la stazione grafica locale, a cui si accede senza passare per la rete, e le stazioni grafiche remote, che contengono anche l'indicazione del nome del nodo. Tra le stazioni remote ci può essere anche quella locale, indicata secondo il punto di vista della rete.
Perché possa avvenire una connessione tra un programma cliente e un servente X, è necessario che il record di autorizzazione a cui può accedere il cliente, riferito al servente X in questione, sia identico a quello corrispondente del servente X.
Il sistema di autorizzazione di X sembra fatto perché le chiavi siano cambiate spesso. In generale, si cerca di sistemare l'autorizzazione sempre solo nel momento in cui ne esiste il bisogno, ma subito dopo sarebbe bene cambiare la chiave di autorizzazione.
Il programma xhost permette di aggiungere o togliere nomi dalla lista di elaboratori e utenti a cui è concesso di utilizzare lo schermo grafico, senza la richiesta di altre forme di autenticazione:
xhost [[+|-]nome...] |
xhost [+|-] |
Se non vengono utilizzati argomenti, xhost emette un messaggio informando sullo stato attuale del controllo degli accessi. I nomi indicati nella sintassi di xhost hanno una struttura particolare:
famiglia:indirizzo |
In pratica, per le connessioni su reti IPv4 si utilizza la famiglia inet.
Le funzionalità di X non sono sempre presenti su tutte le piattaforme. In questo caso particolare, potrebbe darsi che non sia possibile regolare gli accessi ai singoli utenti.
Se si vuole concedere sistematicamente l'accesso a qualche nodo, conviene inserire i comandi necessari all'interno del file ~/.xinitrc in modo che siano eseguiti ogni volta all'avvio del servente X.
|
Tabella 149.17. Alcune opzioni.
|
Segue la descrizione di alcuni esempi.
$ xhost +[Invio]
Autorizza chiunque ad accedere.
$ xhost -[Invio]
Limita la possibilità di accesso ai soli nomi inseriti nell'elenco di elaboratori e utenti autorizzati.
$ xhost +inet:roggen.brot.dg[Invio]
Consente all'elaboratore roggen.brot.dg di accedere al servente grafico.
$ xhost -inet:roggen.brot.dg[Invio]
Elimina l'elaboratore roggen.brot.dg dalla lista di quelli a cui è consentito accedere.
xon esegue un comando in un elaboratore remoto attraverso rsh, facendo in modo che venga utilizzato il servente X locale:
xon nodo_remoto [opzioni] [comando] |
Si tratta in pratica di un modo abbreviato per eseguire un'applicazione remota senza la necessità di utilizzare la solita opzione -display.(3)
Se attraverso gli attributi non viene indicato alcun comando da eseguire, xon tenta di avviare xterm -ls, in pratica una sessione xterm di login.
|
xon è in grado di funzionare solo quando l'elaboratore remoto è configurato in modo da consentire le connessioni remote attraverso rsh senza richiedere alcun tipo di riconoscimento. Sotto questo aspetto, xon è limitato all'utilizzo nelle reti chiuse in cui esiste un serio rapporto di fiducia tra le persone che vi accedono. |
|
Tabella 149.18. Alcune opzioni. |
L'esempio seguente mostra l'avvio del programma xcalc nell'elaboratore roggen.brot.dg, utilizzando il servente X locale. Prima di farlo, xon avvia xhost per consentire all'elaboratore remoto di accedere al proprio servente X.
$ xon roggen.brot.dg -access /usr/bin/X11/xcalc[Invio]
Secure Shell (capitolo 279) facilita le connessioni remote, gestendo in modo automatico tutto il procedimento di autorizzazione all'accesso al proprio schermo. Per arrivare a questo risultato, è comunque necessario abilitare tale funzionalità nella configurazione: sia dalla parte del servente, sia dalla parte del cliente.
Nel file di configurazione del servente Secure Shell, è necessario trovare queste direttive:
|
Nel file di configurazione del cliente Secure Shell, è necessario trovare queste direttive:
|
Così facendo, una volta aperta una finestra di terminale, ci si può collegare all'elaboratore remoto usando il cliente Secure Shell, come nell'esempio seguente:
tizio$dinkel.brot.dg:~$ ssh caio@roggen.brot.dg[Invio]
Dopo la fase di autenticazione, che potrebbe consistere nella richiesta della parola d'ordine, è possibile verificare che la variabile di ambiente DISPLAY risulta impostata in modo da fare riferimento al proprio elaboratore locale, utilizzando uno schermo particolare, come definito nella direttiva X11DisplayOffset:
caio$roggen.brot.dg:~$ echo $DISPLAY[Invio]
dinkel.brot.dg:10.0 |
A questo punto, è sufficiente avviare un programma grafico qualunque nell'elaboratore remoto, senza bisogno di altro: si ottiene di farlo funzionare sul proprio schermo grafico.
caio$roggen.brot.dg:~$ xclock[Invio]
In base a quanto indicato nel file di configurazione /etc/XF86Config nella sezione Files, i tipi di carattere utilizzati da X sono collocati nelle directory successive a /usr/lib/X11/fonts/. All'interno di queste directory si trovano una serie di file contenenti le informazioni sui vari tipi di carattere tipografico e i loro nomi sono contenuti negli elenchi fonts.dir.
Il nome di un carattere tipografico è strutturato in un modo altamente descrittivo. Segue un esempio che viene scomposto.(4)
|
b&h è la «fonderia», ovvero il produttore;
lucidatypewriter definisce la famiglia;
medium è lo spessore;
r è il tipo -- «r» sta per roman (tondo), «i» indicherebbe italic (corsivo) e «o» oblique (obliquo);
normal è l'ampiezza orizzontale;
sans è una particolarità dello stile, in questo caso indica l'assenza di grazie o serif, cioè dei terminali che facilitano la lettura;
80 indica la dimensione in decimi di punto tipografici (precisamente si tratta di 722,7 per pollice, pari a circa 0,035 mm);
100 è la risoluzione orizzontale, espressa in punti per pollice, per la quale è stato progettato il tipo di carattere;
100 è la risoluzione verticale, espressa in punti per pollice, per la quale è stato progettato il tipo di carattere;
m è la larghezza, in questo caso monospaced, ovvero a larghezza fissa, mentre l'alternativa sarebbe «p», cioè proportional;
50 è lo spessore medio espresso in decimi di punto (in questo caso si tratta di cinque punti normali);
iso8859-1 è l'insieme di caratteri, in questo caso, il codice iso8859-1 corrisponde al noto ISO Latin 1.
L'utilizzo del sistema grafico senza mouse, o senza un dispositivo equivalente, può essere importante in condizioni di emergenza, o comunque quando il tipo di mouse che si ha a disposizione potrebbe risultare più scomodo che altro.
I serventi grafici di X offrono queste funzionalità attraverso il tastierino numerico, dopo aver attivato le estensioni della tastiera. Perché ciò sia possibile è necessario che nel file di configurazione sia commentata l'istruzione che si in questo esempio, oppure che sia assente del tutto:
|
Per abilitare l'uso del tastierino numerico in modo che possa sostituirsi al mouse occorre utilizzare la combinazione [Ctrl Maiuscole BlocNum] («control», «maiuscole», «blocco-numeri»). Se la combinazione riesce si ottiene una segnalazione sonora (se si ripete la combinazione si disabilita l'uso del tastierino).
Da quel momento, si possono utilizzare i tasti [4], [8], [6] e [2], per spostare il puntatore rispettivamente verso sinistra, in alto, a destra e in basso. Inoltre, si possono usare anche i tasti [7], [9], [3] e [1], per ottenere degli spostamenti obliqui. Questi spostamenti potrebbero essere piuttosto lenti in condizioni normali; per accelerarli, mentre si tiene premuto il tasto che si riferisce alla direzione scelta, si può premere e rilasciare immediatamente un altro tasto, scegliendolo in modo tale che in quel momento non abbia un significato particolare; probabilmente la cosa migliore è usare per questo il tasto delle maiuscole.
Per emulare i tasti del mouse si utilizzano gli altri tasti del tastierino numerico: [5] corrisponde a un clic; [+] corrisponde a un clic doppio; [0] rappresenta la pressione di un tasto senza rilasciarlo; [.] rilascia il tasto del mouse. In condizioni normali, ciò corrisponde al primo tasto del mouse, ma si può specificare precisamente il tasto attraverso una combinazione con i tasti [/], [*] e [-], che rappresentano rispettivamente il primo, il secondo (quello centrale) e il terzo tasto del mouse. Per esempio, [* 5] corrisponde a un clic con il tasto centrale del mouse.
|
Tabella 149.24. Comandi per l'emulazione del mouse con X.
|
|
|
X, dopo un po' di tempo in cui non si utilizza più il tastierino numerico in sostituzione del mouse, ne disabilita l'emulazione in modo automatico. |
The XFree86 Project, Inc.
X.Org foundation
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) Se si vuole provare a vedere cos'è un servente X senza clienti basta avviare X. Come già spiegato in precedenza, è sempre possibile uscire con la combinazione [Ctrl Alt Backspace].
2) In questo caso, dal momento che twm viene avviato rimpiazzando la shell, risulta che il processo di xclock dipende proprio da twm.
3) Prima di utilizzare xon è indispensabile sapere gestire rsh.
4) I caratteri tipografici di X servono solo per la rappresentazione di testo sullo schermo. In pratica, non sono utili per la stampa vera e propria.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome x_funzionamento_e_accesso.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
