Accade qualche volta che anche un professionista sbagli; accade qualche volta che anche un professionista non adotti il corretto modello per comprendere un evento empirico; accade qualche volta che la suggestione prenda e corrompa la lucidità e le capacità dello stesso professionista, portandolo sulla via sbagliata nella ricerca della soluzione ad un problema, e coinvolgendo in questo tutti i suoi colleghi, per la forza persuasiva della suggestione medesima.
Accade, ed è successo anche a noi.E’ successo che la necessità di utilizzare programmi x-window remotamente usando un Apple Power Book quale “server grafico” ci ha creato non qualche problema ed imbarazzo. Come sarebbe a dire?
Ti viene assegnato un compito. Ti dicono quale è l’host da contattare (rigorosamente solo attraverso protocollo telnet) e pure che il programma ‘pippo’ è x-window. Hai il tuo account ed il tuo fidato pbook. Che fai?
L’host da connettere è un IBM R6000 con sistema AIX: UNIX, tu sei un sistemista UNIX di lungo corso. Una volta attivato Apple X11 sul tuo pbook sei pronto all’avventura: solita procedura sbrigativa: [vedi inoltre il BLOG di Giampaolo]
Sulla finestra xterm locale del pbook digiti:
# xhost +
Ti connetti al server remoto:
# telnet <ip host-remoto>
e come da consuetudine imposti la variabile DISPLAY (a scanso di equivoci; ti disinteressi del fatto che la versione di telnet che usi possa provvedere autonomamente a questo):
# DISPLAY= <ip pbook>:0.0; export DISPLAY
Tutto è pronto per cominciare a lavorare; attiviamo il programma pippo:
# pippo Xlib: connection to "<ip pbook>:0.0" refused by server Xlib: No protocol specified
Connection refused
Forse è il programma; andiamo sul sicuro:
# xclock Xlib: connection to "<ip pbook>:0.0" refused by server Xlib: No protocol specified
Connection refused
Cosa?
Ah ! Forse è il firewall attivo che blocca le connessioni. Allora verifichiamo le impostazioni di sicurezza. Non è la strada giusta. Apple X11 se è installato ha posto le regole nel modo corretto. Non avendole toccare nessuno sono appostissimo.
Ma la frustrazione cresce vedendo che un collega con un client windoiz e un programma freeware riesce nella medesima attività di connessione e attivazione di programma x-window.
Escalation del problema
Dopo aver invano ritentato più volte si chiede ovviamente aiuto a colleghi fidati. Coinvolti assieme quindi nella ricerca della soluzione al problema si tenta di tutto. Ovviamente i colleghi fidati sono colleghi che lavorano da anni in ambito UNIX, e negli ultimi anni con particolare interesse nel mondo Linux. Quindi gli esperimenti per cercare di trovare soluzione al problema vengono eseguiti rigorosamente in ambito UNIX, ed in particolare con workstation Fedora Core 3 e 4, quindi con software molto aggiornato. Ogni suggerimento possibile sembrava vano. Anzi no. Peggio. Ad un certo punto, ponendosi nelle medesime condizioni sperimentali, ci si è accorti che anche postazioni di lavoro Fedora non erano in grado di comportarsi come server X per applicazioni remote. Quindi si aveva la certezza. Qualcosa di grave non va nel modo di operare, in quanto entrambi gli ambienti reagiscono nel medesimo modo.
Ricerche su Internet diventano sempre più frustranti quando confermano l’ovvio: il procedimento adottato è quello canonico.
Dopo qualche giorno di ricerca la frustrazione arriva a livelli insopportabili, anche e non solo considerando come il collega “windomorfo” avesse una interfaccia pienamente funzionante.
Capire quando è stato il momento esatto in cui il sospetto sia affiorato è difficile: ma fatto è che alla fine l’ottica del sistemista è uscita fuori prepotentemente; e allora con un semplice comando si è scoperto quale era il problema.
# netstat --tcp --listen | grep x11 #
Il comando non aveva prodotto nessuna risposta: questo significava che non esisteva alcun serve X11 attivo in ascolto sulla porta canonica del servizio (6000/tcp). Questo significava che il server rispondeva solo a connessioni in localhost attraverso socket in dominio UNIX: questo il motivo per il quale tutti i software grafici della workstation funzionavano.
Ma quale era il motivo della mancanza di ascolto della rete?
Le ricerche su Internet questa volta portano i loro frutti; la risposta ai nostri problemi sono: qualcosa è cambiato nella politica di configurazione iniziale dei server X, cambiamenti che attengono a Xfree86, Xorg in ambito Linux, ma anche, per ragioni opposte, a Apple X11.
Vediamo quali sono questi cambiamenti e quali soluzioni posso essere trovate, trattando un ambiente operativo alla volta.
Una occhiata al mondo UNIX/Linux
Il motivo per il quale l’X server è attivo ma non ascolta su porta tcp è gdm.
gdm è il rimpiazzo di xdm, responsabile dell’autenticazione (login grafica) e attivazione del server grafico vero e proprio (X). Ovviamente per creare un login grafico gdm (xdm) è un server grafico a sua volta, anche se non capace di interagire col mondo esterno, ma in cui si eseguono possono eseguire alcuni tools, ivi compreso il famigerato xclock, se ad esempio vogliamo vedere lo scorrere del tempo durante la visualizzazione della pagina di accesso alla sessione grafica. La configurazione base di gdm prevede di disattivare l’ascolto su porta x11/tcp per tutti i server grafici che deve attivare; è possibile contraddire questa configurazione attraverso una direttiva da porre nel file /etc/X11/gdm/gdm.conf, tipicamente presente ma commentata. La direttiva è in logica negativa (in quanto indica di disabilitare un qualcosa, quindi noi dobbiamo negare la direttiva quando vogliamo attivare), quindi dovremo avere:
DisallowTCP=false # il default è true, anche se non impostato
Quando impostata a true (o non impostata) verrà aggiunta l’opzione -nolisten tcp a qualsiasi linea di comando che invochi la partenza di un server X (esattamente l’applicativo X) presente nell’albero dei file di configurazione che discendono da gdm.
Quando venisse incontrata l’opzione -query o -indirect nelle medesime linee di comando allora l’opzione -nolisten NON verrebbe aggiunta.
Torniamo al mondo MacOSX. La soluzione del problema iniziale
[…] Panther aveva un pannello di controllo. Tiger no.
Nell’aggiornamento si perde la possibilità di esettare impostazioni che erano possibili in Panther.
Ma il pbook è nato Tiger… e allora???? L’ipotesi è che un software X abbia impostato di suo quel parametro.
Fatto è che le evidenze parlano chiaro: nel file ~/Library/Preferences/com.apple.X11.plist del pbook (è bastato usare defaults oppure Plist Editor per vedere) esiste una chiave di nome nolisten_tcp, di tipo booleano settata al valore YES. Quindi X11 viene attivato con l’esclusione dei client da network (come se il flag fosse rimosso nel pannello X11 Preferences: Security di Panther.
Oltre alla correzione apportata a mano occorreva una soluzione più elegante: un software che facesse questo fornendo una interfaccia grafica.
Il primo prototipo fu una applicazione Cocoa, X11TcpEnabler: poi venne il turno di un plugin per il Pannello di Controllo di sistema che replicasse la porzione di configurazione di sicurezza di X11 in Panther:
P.S. Il problema non si verifica se la connessione avviene attraverso protocollo secure-shell (ssh), in quanto il tunnelling che viene costruito per il trasporto cifrato delle connessioni X11 (X11Forwading) rende la connessione X11 attraverso il localhost (unix-domain socket), quindi non è una connessione TCP/UDP