Manovrare X da remoto: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (verificata)
 
(19 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Jessie|Stretch|Buster}}
== Introduzione ==
== Introduzione ==
Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (''GUI'') non è parte del kernel ma gestita da un programma a parte: l' ''X window system'' o semplicemente server '''X''', di cui [[Xorg]] rappresenta l'implementazione attualmente più diffusa.


Questa guida � dedicata all'uso di Aptitude.
Le richieste dai client X di gestire le finestre avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul display manager (<code>xdm</code>, <code>gdm</code>, <code>kdm</code>, <code>lightdm</code>, ecc...) per accedere al server X locale attraverso ''XDMCP'' ('''''X''' '''D'''isplay '''M'''anager '''C'''ontrol '''P'''rotocol'').


Il completissimo '''manuale utente di Aptitude''' in formato html si pu� trovare installando il pacchetto <tt>aptitude-doc-en</tt>, in <tt>/usr/share/doc/aptitude/html/en/index.html</tt>. Purtroppo il manuale � solo in inglese.
Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente '''<code>xdm</code>'''.


{{Warningbox | Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. '''Questo rappresenta un <u>enorme rischio</u> per la sicurezza del sistema!'''


== Cos'� Aptitude ==
Se è possibile, si raccomanda caldamente invece di configurare una connessione [[SSH]] e di abilitare l'[[OpenSSH: X11 forwarding|X11 forwarding]] per avviare un'applicazione grafica o anche un'intera sessione.}}


Aptitude � un frontend per la gestione avanzata dei pacchetti di una distribuzione Debian, ma risulta valida per tutte le distribuzioni che supportano APT (http://www.debian.org/doc/manuals/apt-howto/ch-distros.it.html).
== Lato server ==
=== Installazione ===
Con [[privilegi di amministrazione]] è necessario installare <code>xdm</code>, oltre ovviamente al server [[Xorg]], se ancora non presente nella macchina che farà da server. Per esempio con [[apt]] basta:
<pre>
# apt install xdm xorg
</pre>


Aptitude � ormai lo strumento preferenziale per l'amministrazione dei pacchetti su Debian, in quanto non solo raggruppa in un unico semplice programma le funzionalit� di molti tool (apt-get, apt-cache ...) ma anche perch� permette di gestire in modo molto pi� facile (ed efficace) situazioni complesse (dipendenze, dipendenze inverse, rimozione pacchetti non utilizzati, ecc ...).
=== Configurazione di xdm ===
Sempre con [[privilegi di amministrazione]], è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio [[nano]]:
<pre>
# nano /etc/X11/xdm/xdm-config
</pre>


Aptitude � un frontend a dpkg esattamente come apt-get, che sembra essere destinato a sostituire integralmente lo stesso [[Introduzione_all%27_Apt_System | apt-get (e affini)]], tanto che nelle release notes di Sarge si legge:
In <code>/etc/X11/xdm/xdm-config</code> commenta:
<pre>
DisplayManager.requestPort:  0
</pre>
che diventa:
<pre>
!DisplayManager.requestPort:   0
</pre>


{{Box|Citazione:|Il metodo di aggiornamento raccomandato fra le release Debian GNU/Linux prevede l'utilizzo dello strumento di gestione dei pacchetti aptitude. Tale strumento rende le decisioni riguardanti le installazioni dei pacchetti pi� sicure che l'esecuzione diretta di apt-get.}}
Salva il file (con <code>nano</code> premi <code>Ctrl-o</code> e per uscire <code>Ctrl-x</code>).


e anche:
In modo analogo, apri il file <code>/etc/X11/xdm/Xaccess</code> e togli il comento a:
 
<pre>
{{Box|Citazione:|Test di aggiornamento hanno mostrato che la versione di sarge di aptitude � migliore sia di apt-get sia della versione di woody di aptitude nella risoluzione di dipendenze complesse durante un aggiornamento.}}
#*        #any host can get a login window
 
</pre>
Si pu� utilizzare Aptitude in due modi: da linea di comando, cio� come apt-get (la sintassi e le opzioni sono identiche, o quasi), oppure tramite l'interfaccia visuale basata sulle librerie ncurses.
che diventerà:
 
<pre> 
L'interfaccia visuale verr� trattata pi� diffusamente, perch� si ritiene che sia uno strumento fondamentale per la gestione dei pacchetti e soprattutto per la diagnostica e la risoluzione degli eventuali problemi riscontrati.
*        #any host can get a login window
 
</pre>
{{Box|Prima di iniziare|Prima di iniziare a mettere le mani sulla tastiera, notiamo che aptitude, a differenza della maggior parte delle opzioni di apt-get, si pu� lanciare anche con i diritti di utente comune.
 
Poich� per l'effettiva installazione o rimozione dei pacchetti � necessario possedere i diritti di root, � possibile e caldamente consigliato usare questa possibilit� per effettuare qualunque prova, visto che non si sar� in grado di modificare neanche una virgola del sistema prima di aver inserito la password di root.}}


 
Al posto di <code>*</code> è possibile anche specificare, uno a uno, gli [[host]] da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di <code>*</code>):
== Uso da linea di comando ==
 
Anche dalla linea di comando l'uso di aptitude � molto semplice e comodo. Si usa in genere la seguente forma:
 
aptitude azione [argomenti...]
 
''azione'' dice ad aptitude quale azione svolgere; i rimanenti argomenti dipendono dall'azione scelta e consistono tipicamente in una lista di nomi di pacchetti.
 
Le azioni pi� importanti sono:
 
; <tt>aptitude update</tt> : aggiorna la lista dei pacchetti (come premere ''''u'''' dall'interfaccia visuale o come <tt> apt-get update</tt>)
 
; <tt>aptitude upgrade</tt> : aggiorna tutti i pacchetti aggiornabili senza che nascano conflitti. Se l'aggiornamento di un pacchetto causa un conflitto il pacchetto non viene aggiornato (piuttosto che, ad esempio, rimuovere i pacchetti che generano il conflitto)
 
; <tt>aptitude dist-upgrade</tt> : anche questo comando aggiorna tutti i pacchetti, ma � pi� aggressivo nella risoluzione delle dipendenze: nouvi pacchetti saranno installati e altri rimossi, fino a quando tutte le dipendenze non saranno soddifatte. Questo comando potrebbe fare cose non desiderate (come, appunto, installare nuovi pacchetti o rimuoverne altri) quindi deve essere usato con cautela.
 
; <tt>aptitude [ install | remove | purge ] pkg1 [pkg2...]</tt>: questi comandi installano, rimuovono o fanno il ''purge'' (eliminazione anche dei file di configurazione) dei pacchetti specificati.
 
; <tt>aptitude search espressione1 [espressione2...]</tt>: mostra su terminale i pacchetti che contengono nel nome una delle espressioni fornite. Le espressioni possono essere semplici stringhe o anche espressioni pi� complesse ("Search Patterns").
 
; <tt>aptitude show pkg1 [pkg2...]</tt> : mostra su terminale le informazioni di ogni pacchetto specificato.
 
I comandi che installano, aggiornano o rimuovo pacchetti accettano tutti il parametro "-s" che st� per "simula". Quando viene passato "-s" nella linea di comando, aptitude svolge tutte le azioni che svolgerebbe normalmente, ma non scarica o installa/rimuove effettivamente nessun file.
 
 
==Interfaccia grafica==
 
La prima schermata che aptitude ci presenta, dopo che l'abbiamo lanciato da linea di comando, e dopo il caricamento delle informazioni attuali sui pacchetti ("caricamento della cache"), � divisa orizzontalmente in due parti.
 
Nella parte superiore troviamo una zona a sfondo blu con un men� che propone diverse opzioni, e una zona a sfondo nero in cui si vede l'albero dei pacchetti disponibili, classificati in base al loro stato (installati, non installati, ecc.).
 
Per vedere il contenuto di uno dei rami usiamo le frecce "su" e "giu" fino a selezionare la riga corrispondente e premiamo invio. Sotto al ramo in questione ora abbiamo dei sottorami, e premendo invio sui vari sottorami si accede allo stesso modo ai sotto-sottorami e cos� via, fino ad arrivare ai pacchetti.
 
La parte inferiore � invece dedicata alla descrizione del pacchetto attualmente selezionato. Alcuni pacchetti, per esempio k3b, hanno una descrizione molto lunga: premendo TAB e usando le frecce � possibile leggerla tutta.
 
Ogni riga che mostra il nome di un pacchetto riporta anche molte informazioni.  
Per esempio, riporto lo stato di alcuni pacchetti nel mio sistema (nota: il mio sistema � una sarge, ma ho installato diversi pacchetti da testing e anche alcuni da unstable. Per informazioni sul pinning vedere [[APT_uso_avanzato:_mixare_releases_diverse | APT uso avanzato: mixare releases diverse ]]):
<pre>
<pre>
stato    nome                vers. attuale    vers. aggiornata
192.168.0.*
 
i        aptitude            0.2.15.9-2      0.2.15.9-2
i        amule                2.0.3-3          2.0.3-4
i A      amule-common        2.0.3-3          2.0.3-4
c        hotplug              <nessuna>        0.0.200403
p        apmd                <nessuna>        3.2.2-3
</pre>
</pre>
per accettare connessioni dagli host appartenenti alla rete <code>192.168.0.0/24</code>, ossia tutti gli indirizzi compresi da <code>192.168.0.1</code> a <code>192.168.0.254</code>. Sono permessi anche [[hostname]], per esempio se definiti in <code>/etc/hosts</code>, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file.


Possiamo vedere che:
Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file <code>/etc/X11/xdm/Xservers</code>:
*aptitude � installato ed � alla versione pi� recente
*amule � installato ma � aggiornabile alla versione 2.0.3-4
*amule-common � installato per soddisfare una dipendenza (<tt>A</tt>), cio� solo a causa di un pacchetto che dipende da lui (amule). Anch'esso � aggiornabile
*hotplug non � installato, ma quando l'ho cancellato ho scelto di mantenere i file di configurazione (<tt>c</tt>)
*apmd non � installato (<tt>p</tt>), oppure � stato cancellato con l'opzione "purge" (comando: "_"): lo stato risultante � il medesimo
 
Tramite semplici comandi si possono visualizzare molte altre informazioni. I comandi principali sono:
; v: visualizza le versioni disponibili per il pacchetto
; d: visualizza le dipendenze del pacchetto
; r: visualizza i pacchetti che dipendono dal pacchetto selezionato (dipendenze inverse)
; C: scarica da internet e visualizza il changelog del pacchetto
; q: chiude la schermata attuale e passa a quella precedente
 
Per una lista completa vedere la guida online con "?".
 
Ora premiamo invio su di un pacchetto: ci appare la schermata relativa al pacchetto, con la descrizione completa e molte altre informazioni, organizzate ad albero come abbiamo gi� visto. Se ci interessa qualche informazione in pi� su uno dei pacchetti che troviamo in questa schermata, lo selezioniamo e premiamo invio: appaiono le versioni disponibili del pacchetto. Se selezioniamo una delle versioni e premiamo invio ci ritroviamo nella schermata informativa di quel pacchetto. Fate attenzione perch� in questo modo si pu� perdere facilmente l'orientamento.
Torniamo alla vista dell'albero dei pacchetti premendo "q" tante volte quanto serve (se vi sbagliate e lo premete una volta in pi�, aptitude vi chiede se volete uscire dal programma: per il momento dite di no ;-)).
 
 
==Aggiornare i pacchetti==
 
Per la descrizione dell'utilizzo di aptitude useremo come esempio una sessione reale, in cui vengono svolte alcune normali operazioni di aggiornamento e amministrazione dei pacchetti.
 
Per prima cosa, nella nostra sessione di amministrazione, aggiorniamo le informazioni sui pacchetti disponibili. Con apt-get avremmo digitato <tt>apt-get update</tt>, mentre in aptitude � sufficiente premere "u".
 
Fate attenzione perch� aptitude non chiede conferma dopo che avete impartito un comando, quindi non digitate nulla senza prima essere sicuri/e di cosa state per fare.
 
Dopo aver fatto l'update potremmo trovare una, due, o tre voci nuove nell'albero dei pacchetti: "Aggiornamenti di sicurezza", "Pacchetti aggiornabili", e "Pacchetti nuovi". Per fare scomparire le prime due � necessario aggiornare tutti i pacchetti contenuti nei rispettivi rami, mentre per far sparire la terza � sufficiente premere "f" (forget).
 
Una buona regola per l'amministratore � quella di far s� che alla fine dell'aggiornamento queste tre voci non siano presenti. Se ci sono dei pacchetti che risultano aggiornabili, ma che non volete aggiornare, probabilmente dovreste bloccarli alla versione desiderata con "=", oppure dovreste leggere la guida gi� citata sul pinning.
 
Ora torniamo ai pacchetti mostrati prima e supponiamo di voler aggiornare amule: lo selezioniamo e premiamo "+". Questo marcher� in verde, cio� per l'installazione, sia amule che amule-common.
 
Poi per� ci viene un'idea migliore, e decidiamo di aggiornare tutti i pacchetti aggiornabili, quindi digitiamo "^" per risalire al ramo superiore della vista, finch� arriviamo a <tt>Pacchetti installati</tt> poi usiamo la freccia in alto e se necessario risaliamo ancora ai rami superiori finch� non arriviamo a <tt>Pacchetti aggiornabili</tt> e qui premiamo "+". Questo marcher� per l'installazione tutti i pacchetti aggiornabili :-D
 
 
==Risolvere eventuali problemi con delle dipendenze==
 
Dopo aver marcato per l'installazione tutti i pacchetti aggiornabili, aptitude ci segnala nella zona blu che c'� un pacchetto "errato" cio� con problemi di dipendenze. Senza battere ciglio premiamo "b" e leggiamo:
<pre>
<pre>
iB      udev          0.070    0.074
:0 local /usr/bin/X :0 vt8 -nolisten tcp
</pre>
</pre>
dove "B" significa "con errori", e sotto si legge:
che diventerà:
<pre>
<pre>
Alcune dipendenze di udev non sono soddisfatte:
:0 local /usr/bin/X :0 vt8
 
  *udev � in conflitto con module-init-tools (< 3.2pre9-1)
</pre>
</pre>
premiamo invio su udev, e ci appare la schermata con tutte le informazioni su udev stesso, comprese le dipendenze: selezioniamo module-init-tools e premiamo invio. Ora ci appaiono tutte le versioni disponibili di module-init-tools, tra cui vediamo che � presente la 3.2pre9-1: non ci resta che selezionarla e marcarla per l'installazione :-D.
dove:
* '''<code>:0</code>''' è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (<code>:1</code>, <code>:2</code>, ecc...);
* '''vt8''' è il terminale virtuale da utilizzare, in questo caso <code>tty8</code> (accessibile con <code>Ctrl-Alt-F8</code>). Sceglierne uno qualsiasi libero (<code>vt9</code>, <code>vt10</code>, ecc...).


Quello che � successo � semplicemente che nel mio sistema udev � in testing, e fino alla versione 0.070 funzionava bene con module-init-tools-3.2pre1-2, che invece � in stable. Aggiornando tutto abbiamo marcato per l'installazione il nuovo udev, versione 0.074, che per� dipende da module-init-tools >= 3.2pre9-1. Poich� questo pacchetto � in testing, APT non ha potuto risolvere la dipendenza automaticamente: se un pacchetto � in una distribuzione (e APT � configurato nel modo giusto) non verr� mai passato ad un'altra, a meno che non siamo noi a farlo manualmente.
È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione '''<code>-nolisten tcp</code>''' su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza.


Si prega di notare che questo comportamento non � un bug, ma una cosa voluta: APT ha ricevuto un comando ambiguo e lo segnala generando un errore, proprio come noi ci aspettiamo da lui ;-).
{{Warningbox | Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è '''altamente sconsigliato''' al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati.}}


In effetti, i reali colpevoli della generazione dell'errore siamo noi. Infatti, per permettere ad APT di gestire correttamente delle dipendenze in testing, dobbiamo semplicemente usare "testing" come distribuzione predefinita.  
Per rendere effettive le modifiche, è necessario riavviare il display manager:
<pre>
# service xdm restart
</pre>
e questo conclude la configurazione lato server. <code>xdm</code> resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file <code>Xaccess</code>. Il server <code>Xorg</code> resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il ''magic cookie'' (per maggiori informazioni si rimanda alla lettura del manuale di <code>xauth</code>), comunicato da <code>xdm</code> per permettere l'autenticazione.


Ricordate che abbiamo lanciato aptitude semplicemente con il comando "aptitude"? e ricorderete anche che il mio sistema � una sarge (stable). Questo equivale a lanciare aptitude con il comando "aptitude -t stable", da cui il nostro problema.
== Lato client ==
=== Installazione ===
È necessario il solo pacchetto <code>xorg</code>, per cui se non fosse installato, con [[privilegi di amministrazione]]:
<pre>
# apt install xorg
</pre>


Se avessimo usato "aptitude -t testing" aptitude avrebbe risolto correttamente la dipendenza, ma attenzione: in questo modo diciamo ad aptitude che testing � la nostra release predefinita (che non � vero) e lui ci mostrer� come aggiornabili tutti i pacchetti che lo sono in testing, cio� anche tutti quelli in stable (come peraltro ci aspettiamo che faccia ;-)).
=== Utilizzo ===
Se l'indirizzo IP del server è <code>192.168.0.2</code>, dal client sarà sufficiente il comando:
<pre>
# X -query 192.168.0.2 :0 vt8
</pre>
per connettersi a <code>xdm</code> sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server.


Il fatto � che aptitude, per quanto avanzato, ancora non legge il pensiero dell'amministratore, e fa solo il suo mestiere: prende tutte le decisioni ovvie autonomamente, e genera un errore quando non sa cosa decidere.
In alternativa, se si è nella stessa rete locale del server, è anche possibile:
 
<pre>
 
# X -broadcast :0 vt8
==Cercare un pacchetto==
</pre>
 
per mandare il messaggio di richiesta in ''broadcast'' (ossia a tutti gli [[host]] della rete), per effettuare la connessione al server X del primo ''host'' che risponde.
Ora supponiamo di voler vedere se in debian c'� qualche programma per la gestione dei contenuti, e l'acronimo in inglese � "cms". Per fare questo possiamo usare le funzioni di ricerca di aptitude: per prima cosa digitiamo <tt>'''/'''</tt> per la ricerca della stringa "cms" nei nomi dei pacchetti.
 
Ora per� ci viene in mente che un cms non contiene necessariamente la stringa "cms" nel nome, quindi facciamo, con la stessa stringa, una ricerca nelle descrizioni dei pacchetti: digitiamo ancora <tt>'''/'''</tt> e inseriamo "<tt>~dcms</tt>". Aptitude ci mostra il primo risultato della ricerca, per vedere i risultati successivi premiamo <tt>'''n'''</tt>, e per tornare indietro nella lista <tt>'''\'''</tt>.
 
Diversamente possiamo usare il comando <tt>'''l'''</tt>, che si usa allo stesso modo di <tt>'''/'''</tt> ma mostra tutti e soli i pacchetti corrispondenti alla ricerca, organizzati ad albero nel modo che abbiamo gi� visto.


== Personalizzare la visualizzazione dei pacchetti ==
Si visualizzerà <code>xdm</code> in esecuzione sul server, che si potrà utilizzare per autenticarsi, utilizzando le credenziali di accesso di un utente che ha accesso alla macchina remota.


Con aptitude � possibile personalizzare sia i campi visualizzati nella lista dei pacchetti, sia il raggruppamento in sezioni e sotto-sezioni.
Si avrà così accesso a un'intera sessione grafica, anche se con qualche limitazione di performance. Si noti infatti che il protocollo X11 trasmetterà tutto lo schermo, comprese le aree non necessarie perché non cambiate: non c'è una cache né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".
 
=== Personalizzare il raggruppamento in sezioni ===
 
Le sezioni nelle quali sono raggruppati i pacchetti quando si avvia Aptitude (e non solo) sono generate dinamicamente da un insieme di regole separate da virgola. E' possibile vedere e modificare le regole che generano la vista attuale premendo ''''G''''.
 
Le regole vengono elaborate in sequenza dalla prima all'ultima
 
Vediamo alcune regole:
 
; <tt>filter(missing)</tt> : non visualizza i pacchetti che esistono solo nelle dipendenze di un altro pacchetto.
 
; <tt>status</tt> : Raggruppa i pacchetti in:
:* Installati
:* Non installati
:* Aggiornamenti della sicurezza
:* Aggiornabili
:* Obsoleti
:* Virtuali
 
; <tt>section[(''mode''[,passthrough])]</tt> : Raggruppa i pacchetti in base alla loro sezione. ''mode'' pu� assumere uno dei seguenti valori:
 
:; <tt>topdir</tt> : Raggruppa un base alla sezione dell'archivio debian (esempio: ''"main", "contrib", "non-free" ...'').
:; <tt>subdir</tt> : Raggruppa in base alla sezione logica (esempio: ''"adim", "base", "devel", "gnome", "kde", ecc ...'')
:; <tt>none</tt> : Raggruppa in base delle sezioni formate dalla somma delle  precedenti (esempio: ''"controb/admin", "contrib/devel", "non-free/admin", "non-free/devel").
:; <tt>task</tt> : Crea un albero dei pacchetti raggruppandoli per task.
 
: Se viene usato il secondo parametro opzionale <tt>passthrough</tt> i pacchetti che per qualche motivo non hanno una sezione vengono passati alla regola successiva senza essere inseriti in categorie.
 
All'avvio di aptitude, premendo ''''G'''' si pu� vedere che vengono usate le seguenti regole:
 
<pre>
filter(missing),task,status,section(subdir,passthruough),section(topdir,passthrough)
</pre>


In base a quanto detto la spiegazione di queste regole � semplice: ''visualizza solo i pacchetti reali, crea l'albero dei task, raggruppa i pacchetti per stato, per ogni stato raggruppa in sezioni logiche e all'interno di ogni sezione logica raggruppa in base alla sezione dell'archivio''.
== Link ==
<!-- link commentato: * [http://www.freesoftwaremagazine.com/articles/what_is_x/ What is X?]: interessante articolo che parte dalle basi del funzionamento fino agli utilizzi più avanzati del server X in remoto; -->
* [http://www.tldp.org/HOWTO/XDMCP-HOWTO Linux XDMCP HOWTO]


== Links ==
{{Autori
|Autore = [[Utente:HAL 9000|HAL 9000]] 17:50, 8 set 2019 (CEST) <br/>(guida originariamente scritta da [[Utente:MaXeR|MaXeR]])
|Estesa_da =
|Verificata_da =
|Numero_revisori = 0
}}


* [http://www.luv.asn.au/overheads/aptitude/aptitude-intro.html Aptitude Introduction]: ottima introduzione ad Aptitude (in inglese) che tratta (tra le altre cose) molte pi� opzioni della linea di comando rispetto alla presente guida.
[[Categoria:Xorg]][[Categoria:Altri servizi di rete]]

Versione attuale delle 15:50, 8 set 2019

Debian-swirl.png Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

Introduzione

Nelle distribuzioni GNU/Linux e in generale nei sistemi UNIX e Unix-like l'interfaccia grafica (GUI) non è parte del kernel ma gestita da un programma a parte: l' X window system o semplicemente server X, di cui Xorg rappresenta l'implementazione attualmente più diffusa.

Le richieste dai client X di gestire le finestre avvengono di solito localmente, ma nulla impedisce di gestire le finestre attraverso la rete, permettendo a utenti remoti di effettuare il login sul display manager (xdm, gdm, kdm, lightdm, ecc...) per accedere al server X locale attraverso XDMCP (X Display Manager Control Protocol).

Per semplicità di configurazione, e per la stabilità dimostrata attraverso i passaggi di versione di Debian, in questa guida si considera unicamente xdm.

Warning.png ATTENZIONE
Ogni comunicazione da e verso il server X avverrebbe in chiaro, e sarebbe pertanto manipolabile e/o ascoltabile sulla rete. Questo rappresenta un enorme rischio per la sicurezza del sistema!

Se è possibile, si raccomanda caldamente invece di configurare una connessione SSH e di abilitare l'X11 forwarding per avviare un'applicazione grafica o anche un'intera sessione.


Lato server

Installazione

Con privilegi di amministrazione è necessario installare xdm, oltre ovviamente al server Xorg, se ancora non presente nella macchina che farà da server. Per esempio con apt basta: 

# apt install xdm xorg

Configurazione di xdm

Sempre con privilegi di amministrazione, è sufficiente modificare i file di configurazione indicati in questa sezione con un editor di testo, per esempio nano: 

# nano /etc/X11/xdm/xdm-config

In /etc/X11/xdm/xdm-config commenta: 

DisplayManager.requestPort:   0

che diventa: 

!DisplayManager.requestPort:   0

Salva il file (con nano premi Ctrl-o e per uscire Ctrl-x).

In modo analogo, apri il file /etc/X11/xdm/Xaccess e togli il comento a: 

#*         #any host can get a login window

che diventerà: 

  
*         #any host can get a login window

Al posto di * è possibile anche specificare, uno a uno, gli host da cui si intende accettare la connessione, anche con uso di pattern. Per esempio basta scrivere (al posto di *): 

192.168.0.*

per accettare connessioni dagli host appartenenti alla rete 192.168.0.0/24, ossia tutti gli indirizzi compresi da 192.168.0.1 a 192.168.0.254. Sono permessi anche hostname, per esempio se definiti in /etc/hosts, e l'uso di indirizzi multicast a cui limitare l'ascolto. Per maggiori informazioni si consultino gli esempi scritti nel file.

Per finire è necessario specificare di restare in ascolto sulla porta TCP, modificando il file /etc/X11/xdm/Xservers: 

:0 local /usr/bin/X :0 vt8 -nolisten tcp

che diventerà: 

:0 local /usr/bin/X :0 vt8

dove:

  • :0 è l'identificativo del server X che sarà avviato e dev'essere libero; se ce n'è già uno in esecuzione, utilizzarne un altro (:1, :2, ecc...);
  • vt8 è il terminale virtuale da utilizzare, in questo caso tty8 (accessibile con Ctrl-Alt-F8). Sceglierne uno qualsiasi libero (vt9, vt10, ecc...).

È possibile anche specificare più linee, se si intendono avviare più server X simultaneamente. In tal caso è consigliabile lasciare l'opzione -nolisten tcp su quelli per cui non è previsto l'accesso remoto, come misura di sicurezza.

Warning.png ATTENZIONE
Si ricorda nuovamente che, anche se l'accesso deve essere autenticato, la comunicazione non è criptata. Per cui chiunque nella rete potrebbe ascoltare le credenziali di accesso e il suo uso è altamente sconsigliato al di fuori della LAN, e anche in questo caso esclusivamente se tutti gli host e gli utenti connessi alla LAN possono sempre essere considerati fidati.


Per rendere effettive le modifiche, è necessario riavviare il display manager: 

# service xdm restart

e questo conclude la configurazione lato server. xdm resterà in ascolto sulla porta 177 del protocollo UDP per ricevere richieste di autenticazione, secondo il protocollo XDMCP, dagli host specificati nel file Xaccess. Il server Xorg resta invece in ascolto sulla porta 6000 del protocollo TCP e successive, in base al display utilizzato, e permetterà l'accesso soltanto previa autenticazione, di default in base alla conoscenza di una sequenza casuale generata in precedenza: il magic cookie (per maggiori informazioni si rimanda alla lettura del manuale di xauth), comunicato da xdm per permettere l'autenticazione.

Lato client

Installazione

È necessario il solo pacchetto xorg, per cui se non fosse installato, con privilegi di amministrazione: 

# apt install xorg

Utilizzo

Se l'indirizzo IP del server è 192.168.0.2, dal client sarà sufficiente il comando: 

# X -query 192.168.0.2 :0 vt8

per connettersi a xdm sulla macchina server. Si noti che il display e il terminale virtuale non devono combaciare per forza con quelli scelti sul server, l'unica cosa importante è che siano entrambi liberi sul client, in maniera analoga a quanto visto in precedenza per il server.

In alternativa, se si è nella stessa rete locale del server, è anche possibile: 

# X -broadcast :0 vt8

per mandare il messaggio di richiesta in broadcast (ossia a tutti gli host della rete), per effettuare la connessione al server X del primo host che risponde.

Si visualizzerà xdm in esecuzione sul server, che si potrà utilizzare per autenticarsi, utilizzando le credenziali di accesso di un utente che ha accesso alla macchina remota.

Si avrà così accesso a un'intera sessione grafica, anche se con qualche limitazione di performance. Si noti infatti che il protocollo X11 trasmetterà tutto lo schermo, comprese le aree non necessarie perché non cambiate: non c'è una cache né alcun tipo di funzionalità "trasmetto solo cosa è cambiato".

Link



Guida scritta da: HAL 9000 17:50, 8 set 2019 (CEST)
(guida originariamente scritta da MaXeR) 		Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Manovrare_X_da_remoto&oldid=43187"