0.0 2008-09 GDM è il display manager di GNOME, un programma per accessi grafici. MartinK. Petersen

mkp@mkp.net

GeorgeLebl

jirka@5z.com

JonMcCann

mccann@jhu.edu

RayStrode

rstrode@redhat.com

BrianCameron

Brian.Cameron@Oracle.COM

1998 1999 Martin K. Petersen 2001 2003 2004 George Lebl 2003 2007 2008 Red Hat, Inc. 2003 2011 Oracle e/o sue affiliate. Tutti i diritti riservati. Questo manuale descrive la versione 2.26.0 di GNOME Display Manager. È stato aggiornato l'ultima volta il 10/02/2009. Luca Ferretti elle.uca@libero.it 2008 Luca Ferretti Questo manuale descrive la versione 2.26.0 di GNOME Display Manager. È stato aggiornato l'ultima volta il 10/02/2009. Chooser - Un programma usato per selezionare un host remoto per gestire un display da remoto sul display attaccato (gdm-host-chooser). FreeDesktop - L'organizzazione che fornisce standard per l'ambiente grafico, come la specifica Desktop Entry usata da GDM. http://www.freedesktop.org. GDM - GNOME Display Manager. Usato per descrivere il pacchetto software nella sua interezza. Greeter - La finestra di accesso grafico (fornita da gnome-shell). PAM - Pluggable Authentication Mechanism XDMCP - X Display Manager Control Protocol Xserver - Un'implementazione di X Window System. Per esempio l'Xserver Xorg fornito dalla X.org Foundation http://www.x.org. I percorsi che cominciano con una parola tra parentesi angolari sono relativi al prefisso di installazione. Per esempio <share>/pixmaps/ fa riferimento a /usr/share/pixmaps se GDM è stato configurato con --prefix=/usr. GNOME Display Manager (GDM) è un display manager che implementa tutte le funzioni significative richieste per la gestione di display collegati e remoti. GDM è stato scritto da zero e non contiene alcun codice derivato da XDM o X Consortium. Notare che GDM è configurabile e molte impostazioni di configurazione hanno un impatto sulla sicurezza. In questo documento, le problematiche di cui è bene essere a conoscenza sono messe in evidenza. Notare che alcuni sistemi operativi configurano GDM per comportarsi diversamente dai valori predefiniti descritti in questo documento. Se GDM non dovesse comportarsi come qui documentato, controllare che ogni configurazione relativa non sia differente da quanto qui descritto. Per maggiori informazioni su GDM, fare riferimento al sito web del progetto all'indirizzo http://wiki.gnome.org/Projects/GDM. Per discussioni o domande su GDM, fare riferimento al forum di discussione all'indirizzo https://discourse.gnome.org/tag/gdm. Anche gli archivi della precedente mailing list sono una buona risorsa per cercare risposte a domande comuni. La lista fu archiviata all'indirizzo https://mail.gnome.org/archives/gdm-list/ e dispone di una funzione di ricerca per trovare messaggi tramite parole chiave. Inviare le segnalazioni di bug o le richieste di miglioramenti a https://gitlab.gnome.org/GNOME/gdm/-/issues/. GDM 2.20 e precedenti supportavano interfacce di configurazione stabili. Tuttavia, la base di codice è stata completamente riscritta per GDM 2.22 e non è completamente retrocompatibile con le versioni precedenti. Ciò è dovuto in parte al fatto che le cose funzionano in modo diverso, quindi alcune opzioni non hanno più senso, in parte perché alcune opzioni non ne hanno mai avuto, e in parte perché alcune funzionalità non sono ancora state reimplementate. Le interfacce che continuano ad essere supportate in modo stabile includono gli script Init, PreSession, PostSession, PostLogin e Xsession. Alcune opzioni di configurazione del demone nel file <etc>/gdm/custom.conf continuano ad essere supportate. Sono infine ancora supportati il file ~/.dmrc e le posizioni delle immagini del browser di volti. GDM 2.20 e precedenti supportavano la possibilità di gestire display multipli con schede grafiche separate, come in uso in ambienti server terminal, l'accesso in una finestra per mezzo di programmi come Xnest o Xephyr, il programma gdmsetup, i temi per il greeter basati su XML e la possibilità di eseguire il chooser XDMCP dalla schermata di accesso. Tali funzionalità non sono state reintrodotte durante la riscrittura della versione 2.22. GDM è responsabile della gestione dei display sul sistema. Ciò include l'autenticazione degli utenti, l'avvio di sessioni utente e la terminazione di sessioni utente. GDM è configurabile nei modi descritti nella sezione «Configurazione di GDM» di questo documento. GDM risulta inoltre accessibile per utenti con disabilità. GDM fornisce la possibilità di gestire il display della console principale e i display lanciati attraverso VT. Ciò risulta integrato con altri programmi, come l'applet «Cambia utente» (FUSA) e gnome-screensaver per poter gestire display multipli sulla console attraverso l'interfaccia Xserver Virtual Terminal (VT). È anche possibile gestire i display XDMCP. Indipendentemente dal tipo di display, GDM esegue quanto di seguito indicato quando gestisce il display: avvia un processo Xserver, poi avvia lo script Init come utente root, infine avvia il programma greeter sul display. Il programma greeter viene eseguito come l'utente/gruppo senza privilegi «gdm». Questi utente e gruppo sono descritti nella sezione «Sicurezza» di questo documento. Le funzioni principali del programma greeter sono fornire un meccanismo per selezionare un account per l'accesso e guidare il dialogo tra l'utente e il sistema durante l'autenticazione di tale account. Il processo di autenticazione è gestito dai Pluggable Authentication Modules (PAM). I moduli PAM determinano quali richieste (se presenti) vengono mostrate all'utente per l'autenticazione. Su un sistema medio, il programma greeter richiederà un nome utente e una password per l'autenticazione. Tuttavia, alcuni sistemi possono essere configurati per utilizzare meccanismi supplementari come lettori di impronte digitali o di SmartCard. GDM può essere configurato per supportare queste alternative in parallelo con le estensioni di accesso del greeter e l'opzione --enable-split-authentication di ./configure, oppure una alla volta tramite la configurazione PAM di sistema. L'estensione per le smartcard può essere abilitata o disabilitata tramite la chiave gsettings org.gnome.display-manager.extensions.smartcard.active. Allo stesso modo, l'estensione per le impronte digitali può essere abilitata o disabilitata tramite la chiave gsettings org.gnome.display-manager.extensions.fingerprint.active. GDM e PAM possono essere configurati per non richiedere alcun input; in questo modo GDM effettuerà l'accesso automaticamente e avvierà semplicemente una sessione, il che può essere utile in alcuni ambienti, come sistemi per utente singolo o chioschi. In aggiunta all'autenticazione, il programma greeter consente all'utente di selezionare quale sessione avviare e quale lingua usare. Le sessioni sono definite da file che terminano con il suffisso .desktop; maggiori informazioni su questi file sono presenti nella sezione «Configurazione della sessione utente e della lingua di GDM» di questo documento. Per impostazione predefinita, GDM è configurato per mostrare un browser di volti in modo che l'utente possa selezionare il proprio account facendo clic su un'immagine invece di dover digitare il proprio nome utente. GDM tiene traccia della sessione e della lingua predefinite dell'utente nel file ~/.dmrc e usa queste impostazioni predefinite se l'utente non ha scelto una sessione o una lingua nell'interfaccia di accesso. Dopo aver autenticato un utente, il demone esegue lo script PostLogin come root, quindi lo script PreSession come root. Dopo l'esecuzione di questi script viene avviata la sessione utente. Quando l'utente termina la propria sessione, viene eseguito lo script PostSession come root. Tali script sono forniti come agganci per le distribuzioni e gli utenti finali al fine di personalizzare la gestione delle sessioni. Per esempio, usando tali agganci è possibile impostare una macchina in modo da creare al volo la directory $HOME dell'utente e di eliminarla al termine della sessione. La differenza tra gli script PostLogin e PreSession risiede nel fatto che PostLogin è eseguito prima della chiamata pam_open_session, rendendolo così il posto adatto per ogni azione che debba essere eseguita prima dell'inizializzazione della sessione utente. Lo script PreSession è chiamato dopo l'inizializzazione della sessione. Il programma greeter di GDM mostra un pannello agganciato alla parte inferiore dello schermo che fornisce diverse funzionalità. Quando è selezionato un utente, il pannello consente all'utente di selezionare quale sessione, lingua e disposizione di tastiera usare dopo l'accesso. Il selettore di disposizione della tastiera cambia anche la disposizione usata quando si digita la propria password. Il pannello contiene anche un'area in cui i servizi di accesso possono inserire le proprie icone di stato. Alcuni esempi di icone di stato includono un'icona della batteria che indica lo stato di carica e un'icona per abilitare le funzioni di accesso universale. Il programma greeter fornisce inoltre pulsanti che consentono all'utente di spegnere o riavviare il sistema. È possibile configurare GDM in modo da non fornire tali pulsanti, se desiderato. GDM infine può essere configurato attraverso PolicyKit (o tramite RBAC su Oracle Solaris) in modo da richiedere che l'utente abbia l'autorizzazione appropriata prima di accettare le richieste di spegnimento e riavvio. Notare che le funzionalità relative alla disposizione della tastiera sono disponibili solo sui sistemi che supportano libxklavier. GDM supporta l'«Accesso facilitato», consentendo agli utenti di accedere alla propria sessione desktop anche se non possono usare facilmente schermo, mouse o tastiera nel modo consueto. Sono disponibili funzioni di tecnologia assistiva (AT) come una tastiera a schermo, un lettore di schermo, una lente d'ingrandimento e le funzioni di accessibilità della tastiera AccessX del server X. È anche possibile abilitare il testo grande o le icone e i controlli a contrasto elevato, se necessario. Fare riferimento alla sezione «Configurazione dell'accessibilità» di questo documento per maggiori informazioni su come configurare le varie funzioni di accessibilità. Su alcuni sistemi operativi, è necessario assicurarsi che l'utente GDM sia un membro del gruppo «audio» affinché i programmi di tecnologia assistiva che richiedono un'uscita audio (come la sintesi vocale) possano funzionare. Il browser di volti è l'interfaccia che permette agli utenti di selezionare il proprio nome utente facendo clic su un'immagine. Questa funzione può essere abilitata o disabilitata tramite la chiave GSettings org.gnome.login-screen disable-user-list ed è attiva per impostazione predefinita. Quando è disabilitata, gli utenti devono digitare per intero il proprio nome utente. Quando è abilitata, mostra tutti gli utenti locali disponibili per l'accesso sul sistema (tutti gli account utente definiti nel file /etc/passwd con una shell valida e un UID sufficientemente alto) e gli utenti remoti che hanno effettuato l'accesso di recente. Il browser di volti in GDM 2.20 e precedenti tentava di mostrare tutti gli utenti remoti, causando problemi di prestazioni in grandi installazioni aziendali. Il browser di volti è configurato per mostrare in cima alla lista gli utenti che effettuano l'accesso più di frequente. Questo aiuta a garantire che gli utenti abituali possano trovare rapidamente la loro immagine di accesso. Il browser di volti supporta la «ricerca durante la digitazione», che sposta dinamicamente la selezione del volto al nome utente corrispondente nella lista man mano che l'utente digita. Ciò significa che un utente con un nome utente lungo dovrà digitare solo i primi caratteri prima che venga selezionata la voce corretta nell'elenco. Le icone usate da GDM possono essere installate globalmente dall'amministratore di sistema o possono trovarsi nelle directory home degli utenti. Se installate globalmente, dovrebbero trovarsi nella directory <share>/pixmaps/faces/ e il nome del file dovrebbe essere il nome dell'utente. I file delle immagini dei volti dovrebbero essere in un formato immagine standard che GTK+ può leggere, come PNG o JPEG. Le icone dei volti posizionate nella directory globale dei volti devono essere leggibili dall'utente GDM. Se non esiste un'icona globale per l'utente, GDM cercherà il file immagine nella directory $HOME dell'utente. GDM cercherà prima l'immagine del volto dell'utente in ~/.face. Se non la trova, proverà ~/.face.icon. Se ancora non la trova, userà il valore definito per «face/picture=» nel file ~/.gnome2/gdm. Se un utente non ha un'immagine del volto definita, GDM userà l'icona «stock_person» definita nel tema GTK+ corrente. Se tale immagine non è definita, ripiegherà su un'immagine di volto generica. Si noti che il caricamento e il ridimensionamento delle icone dei volti situate in directory home di utenti remoti può essere un'operazione molto dispendiosa in termini di tempo. Poiché non è pratico caricare immagini tramite NIS o NFS, GDM non tenta di caricare immagini di volti da directory home remote. Quando il browser è attivo, i nomi utente validi sul computer sono visibili a tutti. Se XDMCP è abilitato, i nomi utente sono visibili anche agli utenti remoti. Questo, naturalmente, limita in qualche modo la sicurezza, poiché un utente malintenzionato non ha bisogno di indovinare nomi utente validi. In alcuni ambienti molto restrittivi, il browser di volti potrebbe non essere appropriato. Il demone GDM può essere configurato per ascoltare e gestire le richieste X Display Manager Control Protocol (XDMCP) da display remoti. Per impostazione predefinita, il supporto XDMCP è disattivato, ma può essere abilitato se lo si desidera. Se GDM è compilato con il supporto a TCP Wrapper, il demone garantirà l'accesso solo agli host specificati nella sezione del servizio GDM nel file di configurazione di TCP Wrappers. GDM include diverse misure che lo rendono più resistente agli attacchi di tipo denial of service sul servizio XDMCP. Molti dei parametri del protocollo, i timeout di handshaking, ecc. possono essere ottimizzati. La configurazione predefinita dovrebbe funzionare ragionevolmente sulla maggior parte dei sistemi. GDM per impostazione predefinita ascolta le richieste XDMCP sulla normale porta UDP usata per XDMCP, la porta 177, e risponderà alle richieste QUERY e BROADCAST_QUERY inviando un pacchetto WILLING all'originatore. GDM può anche essere configurato per onorare le richieste INDIRECT e presentare un selettore di host al display remoto. GDM ricorderà la scelta dell'utente e inoltrerà le richieste successive al gestore scelto. GDM supporta anche un'estensione del protocollo che gli farà dimenticare il reindirizzamento una volta che la connessione dell'utente ha successo. Questa estensione è supportata solo se entrambi i demoni sono GDM. È trasparente e sarà ignorata da XDM o da altri demoni che implementano XDMCP. Se XDMCP sembra non funzionare, assicurarsi che tutte le macchine siano specificate in /etc/hosts. Fare riferimento alla sezione «Sicurezza» per informazioni sulle preoccupazioni di sicurezza relative all'uso di XDMCP. GDM usa syslog per registrare errori e stato. Può anche registrare informazioni di debug, utili per individuare problemi se GDM non funziona correttamente. L'output di debug può essere abilitato impostando la chiave debug/Enable a «true» nel file <etc>/gdm/custom.conf. L'output dei vari Xserver è memorizzato nella directory di log di GDM, che normalmente è <var>/log/gdm/. Qualsiasi messaggio dell'Xserver viene salvato in un file associato al valore del display, <display>.log. L'output della sessione viene inviato tramite il demone GDM al file ~/$XDG_CACHE_HOME/gdm/session.log, che di solito si espande in ~/.cache/gdm/session.log. Il file viene sovrascritto ad ogni accesso, quindi disconnettersi e riconnettersi con lo stesso utente tramite GDM causerà la perdita di tutti i messaggi della sessione precedente. Notare che se GDM non può creare questo file per qualche motivo, verrà creato un file di ripiego chiamato ~/$XDG_CACHE_HOME/gdm/session.log.XXXXXXXX dove XXXXXXXX sono alcuni caratteri casuali. GDM permette a più utenti di essere connessi contemporaneamente. Dopo che un utente ha effettuato l'accesso, altri utenti possono accedere tramite il Cambia utente nel pannello di GNOME, o dal pulsante «Cambia utente» nella finestra di blocco schermo di GNOME Screensaver. La sessione attiva può essere cambiata avanti e indietro usando lo stesso meccanismo. Notare che alcune distribuzioni potrebbero non aggiungere il Cambia utente alla configurazione predefinita del pannello. Può essere aggiunto usando il menu contestuale del pannello. Notare che questa funzionalità è disponibile su sistemi che supportano i terminali virtuali. Questa funzionalità non sarà operativa se i terminali virtuali non sono disponibili. Per ragioni di sicurezza, si raccomanda l'uso di un utente e un gruppo dedicati per un corretto funzionamento. Questo utente e gruppo sono normalmente «gdm» sulla maggior parte dei sistemi, ma possono essere configurati con qualsiasi utente o gruppo. Tutti i programmi GUI di GDM vengono eseguiti come questo utente, in modo che i programmi che interagiscono con l'utente siano eseguiti in una sandbox. Questo utente e gruppo dovrebbero avere privilegi limitati. L'unico privilegio speciale richiesto dall'utente «gdm» è la capacità di leggere e scrivere i file Xauth nella directory <var>/run/gdm. La directory <var>/run/gdm dovrebbe avere proprietario root:gdm e permessi 1777. Non si dovrebbe, in nessuna circostanza, configurare l'utente/gruppo GDM con un utente a cui si possa accedere facilmente, come l'utente nobody. Qualsiasi utente che ottenga accesso a una chiave Xauth può spiare e controllare i programmi GUI in esecuzione nella sessione associata o eseguire un attacco denial-of-service contro di essa. È importante assicurarsi che il sistema sia configurato correttamente in modo che solo l'utente «gdm» abbia accesso a questi file e che non sia facile accedere a questo account. Per esempio, l'account dovrebbe essere impostato senza password e non dovrebbe permettere agli utenti non-root di accedervi. La configurazione del greeter di GDM è memorizzata in GConf. Per consentire all'utente GDM di scrivere la configurazione, è necessario che l'utente «gdm» abbia una directory $HOME scrivibile. Gli utenti possono configurare la configurazione GConf predefinita come desiderato per evitare la necessità di fornire all'utente «gdm» una directory $HOME scrivibile. Tuttavia, alcune funzionalità di GDM potrebbero essere disabilitate se non è in grado di scrivere informazioni di stato nella configurazione GConf. GDM usa PAM per l'autenticazione all'accesso. PAM sta per Pluggable Authentication Module, ed è usato dalla maggior parte dei programmi che richiedono l'autenticazione sul computer. Permette all'amministratore di configurare un comportamento di autenticazione specifico per diversi programmi di accesso (come ssh, GUI di accesso, salvaschermo, ecc.) PAM è complicato e altamente configurabile, e questa documentazione non intende spiegarlo in dettaglio. Invece, intende fornire una panoramica di come la configurazione PAM si relazioni con GDM, come PAM sia comunemente configurato con GDM, e i problemi noti. Si presume che una persona che ha bisogno di configurare PAM debba leggere ulteriormente la documentazione di PAM per capire come configurarlo e per comprendere i termini usati in questa sezione. La configurazione PAM ha interfacce diverse, ma simili, su diversi sistemi operativi, quindi controlla le pagine di manuale pam.d o pam.conf per i dettagli. Assicurati di leggere la documentazione PAM e di essere a tuo agio con le implicazioni di sicurezza di qualsiasi modifica che intendi apportare alla tua configurazione. Notare che, per impostazione predefinita, GDM usa il nome del servizio PAM «gdm» per l'accesso normale e il nome del servizio PAM «gdm-autologin» per l'accesso automatico. Questi servizi potrebbero non essere definiti nel tuo file di configurazione pam.d o pam.conf. Se non c'è una voce, GDM userà il comportamento PAM predefinito. Sulla maggior parte dei sistemi questo dovrebbe funzionare bene. Tuttavia, la funzione di accesso automatico potrebbe non funzionare se il servizio gdm-autologin non è definito. Lo script PostLogin viene eseguito prima della chiamata a pam_open_session, e lo script PreSession viene chiamato dopo. Questo permette all'amministratore di sistema di aggiungere qualsiasi script al processo di accesso, sia prima che dopo l'inizializzazione della sessione da parte di PAM. Se si desidera far funzionare GDM con altri tipi di meccanismi di autenticazione (come un lettore di impronte digitali o di SmartCard), si dovrebbe implementare ciò usando un modulo di servizio PAM per il tipo di autenticazione desiderato, piuttosto che cercare di modificare direttamente il codice di GDM. Fare riferimento alla documentazione PAM sul proprio sistema. PAM ha alcune limitazioni riguardo alla capacità di funzionare con più tipi di autenticazione contemporaneamente, come supportare la capacità di accettare sia una SmartCard sia la possibilità di digitare nome utente e password nel programma di accesso. Esistono tecniche usate per far funzionare questo, ed è meglio ricercare come questo problema viene comunemente risolto quando si imposta una tale configurazione. Se l'accesso automatico non funziona su un sistema, controlla se lo stack PAM «gdm-autologin» è definito nella configurazione PAM. Affinché funzioni, è necessario usare un modulo PAM che semplicemente non esegua alcuna autenticazione, o che restituisca semplicemente PAM_SUCCESS da tutte le sue interfacce pubbliche. Supponendo che il tuo sistema abbia un modulo PAM pam_allow.so che fa questo, una configurazione PAM per abilitare «gdm-autologin» assomiglierebbe a questo: gdm-autologin auth required pam_unix_cred.so.1 gdm-autologin auth sufficient pam_allow.so.1 gdm-autologin account sufficient pam_allow.so.1 gdm-autologin session sufficient pam_allow.so.1 gdm-autologin password sufficient pam_allow.so.1 La configurazione sopra non genererà alcuna voce in lastlog. Se si desidera una voce in lastlog, usare quanto segue per la sessione: gdm-autologin session required pam_unix_session.so.1 Se il computer è usato da più persone, il che rende l'accesso automatico inadatto, si potrebbe voler permettere ad alcuni utenti di accedere senza inserire la password. Questa funzione può essere abilitata come opzione per utente nello strumento users-admin da gnome-system-tools; si ottiene controllando che l'utente sia membro di un gruppo Unix chiamato «nopasswdlogin» prima di chiedere la password. Affinché funzioni, il file di configurazione PAM per il servizio «gdm» deve includere una riga come: gdm auth sufficient pam_succeed_if.so user ingroup nopasswdlogin GDM genera voci nel database di contabilità utente utmp e wtmp all'accesso e alla disconnessione della sessione. Il database utmp contiene informazioni sull'accesso e la contabilità degli utenti a cui si accede con comandi come finger, last, login e who. Il database wtmp contiene la cronologia dell'accesso degli utenti e le informazioni di contabilità per il database utmp. Fare riferimento alle pagine di manuale utmp e wtmp sul proprio sistema per maggiori informazioni. I file di autorizzazione dell'Xserver sono memorizzati in una sottodirectory appena creata di <var>/run/gdm all'avvio. Questi file sono usati per memorizzare e condividere una «password» tra i client X e l'Xserver. Questa «password» è unica per ogni sessione connessa, quindi gli utenti di una sessione non possono spiare gli utenti di un'altra. GDM supporta solo lo schema di autenticazione Xserver MIT-MAGIC-COOKIE-1. Normalmente si guadagna poco dagli altri schemi, e finora non è stato fatto alcuno sforzo per implementarli. Fate particolare attenzione all'uso di XDMCP perché il cookie di autenticazione dell'Xserver passa sulla rete in testo in chiaro. Se è possibile lo spionaggio (snooping), un aggressore potrebbe semplicemente spiare la vostra password di autenticazione mentre accedete, indipendentemente dallo schema di autenticazione utilizzato. Se lo spionaggio è possibile e indesiderato, dovreste usare ssh per il tunneling di una connessione X piuttosto che usare XDMCP. Potete pensare a XDMCP come a una sorta di telnet grafico, con gli stessi problemi di sicurezza. Nella maggior parte dei casi, ssh -Y dovrebbe essere preferito alle funzionalità XDMCP di GDM. Anche se il vostro display è protetto da cookie, gli XEvents e quindi le sequenze di tasti digitate durante l'inserimento delle password passeranno comunque sulla rete in testo in chiaro. È banale catturarli. XDMCP è principalmente utile per l'esecuzione di thin client, come nei laboratori terminal. Quei thin client avranno bisogno solo della rete per accedere al server, e quindi sembra che la migliore politica di sicurezza sia avere quei thin client su una rete separata a cui non si può accedere dall'esterno, e che può connettersi solo al server. L'unico punto da cui è necessario accedere all'esterno è il server. Questo tipo di configurazione non dovrebbe mai usare un hub non gestito o un'altra rete intercettabile. Il controllo degli accessi XDMCP viene effettuato tramite TCP wrappers. È possibile compilare GDM senza il supporto a TCP wrapper, quindi questa funzionalità potrebbe non essere supportata su alcuni sistemi operativi. Dovreste usare il nome del demone gdm nei file <etc>/hosts.allow e <etc>/hosts.deny. Per esempio, per negare l'accesso ai computer da .evil.domain, aggiungete gdm: .evil.domain a <etc>/hosts.deny. Potrebbe anche essere necessario aggiungere gdm: .your.domain al vostro file <etc>/hosts.allow se normalmente negate tutti i servizi da tutti gli host. Vedere la pagina di manuale hosts.allow(5) per i dettagli. Anche se GDM cerca di superare in astuzia i potenziali aggressori che tentano di sfruttare XDMCP, si consiglia comunque di bloccare la porta XDMCP (normalmente la porta UDP 177) sul firewall, a meno che non sia realmente necessaria. GDM protegge dagli attacchi denial of service, ma il protocollo X è ancora intrinsecamente insicuro e dovrebbe essere usato solo in ambienti controllati. Inoltre, ogni connessione remota consuma molte risorse, quindi è molto più facile eseguire un attacco denial of service tramite XDMCP che attaccare un server web. È anche saggio bloccare tutte le porte dell'Xserver. Queste sono le porte TCP 6000+ (una per ogni numero di display) sul vostro firewall. Notare che GDM userà i numeri di display 20 e superiori per server flessibili su richiesta. X non è un protocollo molto sicuro quando lo si usa su Internet, e XDMCP è ancora meno sicuro. GDM può essere configurato per usare PolicyKit per permettere all'amministratore di sistema di controllare se la schermata di accesso debba fornire i pulsanti di spegnimento e riavvio. Questi pulsanti sono controllati rispettivamente dalle azioni org.freedesktop.consolekit.system.stop-multiple-users e org.freedesktop.consolekit.system.restart-multiple-users. Le politiche per queste azioni possono essere impostate usando lo strumento polkit-gnome-authorization, o il programma a riga di comando polkit-auth. GDM può essere configurato per usare RBAC invece di PolicyKit. In questo caso, la configurazione RBAC è usata per controllare se la schermata di accesso debba fornire i pulsanti di spegnimento e riavvio. Per esempio, su Oracle Solaris, l'autorizzazione «solaris.system.shutdown» è usata per controllare questo. È sufficiente modificare il file /etc/user_attr in modo che l'utente «gdm» abbia questa autorizzazione. GDM include il supporto per la pubblicazione delle informazioni di accesso degli utenti con il framework di contabilità degli utenti e delle sessioni di accesso noto come ConsoleKit. ConsoleKit è in grado di tenere traccia di tutti gli utenti attualmente connessi. Sotto questo aspetto, può essere usato come sostituto dei file utmp o utmpx disponibili sulla maggior parte dei sistemi operativi Unix-like. Quando GDM sta per creare un nuovo processo di accesso per un utente, chiamerà un metodo privilegiato di ConsoleKit per aprire una nuova sessione per questo utente. In questo momento, GDM fornisce anche a ConsoleKit informazioni su questa sessione utente, come: l'ID utente, il nome del display X11 che sarà associato alla sessione, il nome dell'host da cui proviene la sessione (utile nel caso di una sessione XDMCP), se questa sessione è collegata o meno, ecc. In quanto entità che avvia il processo utente, GDM si trova in una posizione unica per conoscere la sessione utente e per essere considerato affidabile nel fornire queste informazioni. L'uso di questo metodo privilegiato è limitato dall'uso della politica di sicurezza del bus di messaggi di sistema D-Bus. Nel caso in cui un utente con una sessione esistente si sia autenticato in GDM e richieda di riprendere quella sessione, GDM chiama un metodo privilegiato di ConsoleKit per sbloccare quella sessione. I dettagli esatti di ciò che accade quando la sessione riceve questo segnale di sblocco non sono definiti e sono specifici della sessione. Tuttavia, la maggior parte delle sessioni sbloccherà un salvaschermo in risposta. Quando l'utente sceglie di disconnettersi, o se GDM o la sessione si chiudono inaspettatamente, la sessione utente verrà deregistrata da ConsoleKit. GDM ha diverse interfacce di configurazione. Queste includono punti di integrazione per script, configurazione del demone, configurazione del greeter, impostazioni generali della sessione, integrazione con la configurazione di gnome-settings-daemon e configurazione della sessione. Questi tipi di integrazione sono descritti in dettaglio di seguito. I punti di integrazione per script di GDM si trovano nella directory <etc>/gdm/: Xsession Init/ PostLogin/ PreSession/ PostSession/ Gli script Init, PostLogin, PreSession e PostSession funzionano tutti come descritto di seguito. Per ogni tipo di script, quello predefinito che verrà eseguito si chiama «Default» ed è memorizzato in una directory associata al tipo di script. Quindi lo script Init predefinito è <etc>/gdm/Init/Default. Può essere fornito uno script per display, e se esiste verrà eseguito al posto dello script predefinito. Tali script sono memorizzati nella stessa directory dello script predefinito e hanno lo stesso nome del valore DISPLAY dell'Xserver per quel display. Per esempio, se esiste lo script <Init>/:0, verrà eseguito per DISPLAY «:0». Tutti questi script vengono eseguiti con privilegi di root e restituiscono 0 se eseguiti con successo, e un codice di ritorno diverso da zero se c'è stato un errore che dovrebbe causare l'interruzione della sessione di accesso. Notare anche che GDM si bloccherà fino al termine degli script, quindi se uno di questi script si blocca, causerà anche il blocco del processo di accesso. Quando l'Xserver per la GUI di accesso è stato avviato con successo, ma prima che la GUI di accesso venga effettivamente visualizzata, GDM eseguirà lo script Init. Questo script è utile per avviare programmi che dovrebbero essere eseguiti mentre viene mostrata la schermata di accesso, o per eseguire qualsiasi inizializzazione speciale se richiesta. Dopo che l'utente è stato autenticato con successo, GDM eseguirà lo script PostLogin. Questo viene fatto prima che sia stata eseguita qualsiasi impostazione della sessione, inclusa la chiamata a pam_open_session. Questo script è utile per eseguire qualsiasi inizializzazione della sessione che deve avvenire prima dell'avvio della sessione. Per esempio, si potrebbe impostare la directory $HOME dell'utente, se necessario. Dopo che la sessione utente è stata inizializzata, GDM eseguirà lo script PreSession. Questo script è utile per eseguire qualsiasi inizializzazione della sessione che deve avvenire dopo che la sessione è stata inizializzata. Può essere usato per la gestione della sessione o la contabilità, per esempio. Quando un utente termina la propria sessione, GDM eseguirà lo script PostSession. Notare che l'Xserver sarà stato fermato quando questo script viene eseguito, quindi non dovrebbe essere accessibile. Notare che lo script PostSession verrà eseguito anche quando il display non risponde a causa di un errore di I/O o simile. Pertanto, non c'è garanzia che le applicazioni X funzionino durante l'esecuzione dello script. Tutti gli script sopra menzionati imposteranno la variabile d'ambiente $RUNNING_UNDER_GDM a yes. Se gli script sono condivisi anche con altri display manager, questo permette di identificare quando GDM sta chiamando questi script, in modo da poter eseguire codice specifico quando viene usato GDM. La directory <share>/gdm/autostart/LoginWindow contiene file nel formato specificato dalla «FreeDesktop.org Desktop Application Autostart Specification». Le funzionalità standard della specifica possono essere usate per indicare programmi che dovrebbero riavviarsi automaticamente o essere avviati solo se è impostato un valore di configurazione GConf, ecc. Qualsiasi file .desktop in questa directory causerà l'avvio automatico del programma associato con il greeter della GUI di accesso. Per impostazione predefinita, GDM viene fornito con file che avvieranno automaticamente il greeter della GUI di accesso gdm-simple-greeter stesso, l'applicazione gnome-power-manager, il gnome-settings-daemon e il window manager metacity. Questi programmi sono necessari per il funzionamento del programma greeter. Inoltre, vengono forniti file desktop per avviare vari programmi di tecnologia assistiva se sono impostati i valori di configurazione specificati nella sezione Configurazione dell'accessibilità di seguito. Esiste anche uno script Xsession situato in <etc>/gdm/Xsession che viene chiamato tra gli script PreSession e PostSession. Questo script non supporta la configurazione per display come gli altri script. Questo script è usato per avviare effettivamente la sessione utente. Questo script viene eseguito come utente, e avvierà qualsiasi sessione specificata dal file di sessione Desktop che l'utente ha scelto di avviare. Il demone GDM è configurato usando il file <etc>/gdm/custom.conf. I valori predefiniti sono memorizzati in GConf nel file gdm.schemas. Si raccomanda agli utenti finali di modificare il file <etc>/gdm/custom.conf perché il file degli schemi potrebbe essere sovrascritto quando l'utente aggiorna il proprio sistema a una versione più recente di GDM. Notare che le versioni più vecchie di GDM supportavano opzioni di configurazione aggiuntive che non sono più supportate nelle ultime versioni di GDM. Il file <etc>/gdm/custom.conf è in formato keyfile. Le parole chiave tra parentesi definiscono le sezioni dei gruppi, le stringhe prima del segno di uguale (=) sono le chiavi e i dati dopo il segno di uguale rappresentano il loro valore. Le righe vuote o le righe che iniziano con il cancelletto (#) vengono ignorate. Il file <etc>/gdm/custom.conf supporta le sezioni di gruppo «[daemon]», «[security]» e «[xdmcp]». All'interno di ogni gruppo, ci sono particolari coppie chiave/valore che possono essere specificate per modificare il comportamento di GDM. Per esempio, per abilitare l'accesso temporizzato e specificare che l'utente per l'accesso temporizzato sia un utente di nome «you», si dovrebbe modificare il file in modo che contenga le seguenti righe: [daemon] TimedLoginEnable=true TimedLogin=you Segue un elenco completo delle chiavi di configurazione supportate: Multicast Multicast=false Se true e IPv6 è abilitato, il chooser invierà una query multicast alla rete locale e raccoglierà le risposte dagli host che si sono uniti al gruppo multicast. MulticastAddr MulticastAddr=ff02::1 Questo è l'indirizzo multicast Link-local. TimedLoginEnable TimedLoginEnable=false Indica se l'utente specificato in TimedLogin deve accedere dopo un numero di secondi (impostato con TimedLoginDelay) di inattività sulla schermata di accesso. Questo è utile per terminali ad accesso pubblico o forse anche per uso domestico. Se l'utente usa la tastiera o naviga nei menu, il timeout verrà reimpostato a TimedLoginDelay o 30 secondi, a seconda di quale sia il valore più alto. Se l'utente non inserisce un nome utente ma preme solo il tasto INVIO mentre il programma di accesso richiede il nome utente, GDM presumerà che l'utente voglia accedere immediatamente come utente temporizzato. Notare che non verrà richiesta alcuna password per questo utente, quindi si dovrebbe fare attenzione, anche se usando PAM può essere configurato per richiedere l'inserimento della password prima di consentire l'accesso. Fare riferimento alla sezione «Sicurezza->PAM» del manuale per maggiori informazioni, o per aiuto se questa funzione non sembra funzionare. TimedLogin TimedLogin= Questo è l'utente che dovrebbe accedere dopo un numero specificato di secondi di inattività. Se il valore termina con una barra verticale | (il simbolo della pipe), GDM eseguirà il programma specificato e userà come utente qualsiasi valore restituito sullo standard output dal programma. Il programma viene eseguito con la variabile d'ambiente DISPLAY impostata in modo che sia possibile specificare l'utente per display. Per esempio, se il valore è «/usr/bin/getloginuser|», il programma «/usr/bin/getloginuser» verrà eseguito per ottenere il valore dell'utente. TimedLoginDelay TimedLoginDelay=30 Ritardo in secondi prima che l'utente TimedLogin acceda. AutomaticLoginEnable AutomaticLoginEnable=false Se true, l'utente specificato in AutomaticLogin dovrebbe accedere immediatamente. Questa funzione è come l'accesso temporizzato con un ritardo di 0 secondi. AutomaticLogin AutomaticLogin= Questo è l'utente che dovrebbe accedere immediatamente se AutomaticLoginEnable è true. Se il valore termina con una barra verticale | (il simbolo della pipe), GDM eseguirà il programma specificato e userà come utente qualsiasi valore restituito sullo standard output dal programma. Il programma viene eseguito con la variabile d'ambiente DISPLAY impostata in modo che sia possibile specificare l'utente per display. Per esempio, se il valore è «/usr/bin/getloginuser|», il programma «/usr/bin/getloginuser» verrà eseguito per ottenere il valore dell'utente. User User=gdm Il nome utente con cui vengono eseguiti il greeter e altri programmi GUI. Fare riferimento alla chiave di configurazione User e alla sezione «Sicurezza->L'utente e il gruppo GDM» di questo documento per maggiori informazioni. Group Group=gdm Il nome del gruppo con cui vengono eseguiti il greeter e altri programmi GUI. Fare riferimento alla chiave di configurazione Group e alla sezione «Sicurezza->L'utente e il gruppo GDM» di questo documento per maggiori informazioni. Enable Enable=false Per abilitare il debug, impostare la chiave debug/Enable a «true» nel file <etc>/gdm/custom.conf e riavviare GDM. L'output di debug verrà inviato al file di log di sistema (<var>/log/messages o <var>/adm/messages a seconda del sistema operativo). DisallowTCP DisallowTCP=true Se true, aggiunge sempre -nolisten tcp alla riga di comando all'avvio degli Xserver collegati, disabilitando così la connessione TCP. Questa è una configurazione più sicura se non si utilizzano connessioni remote. DisplaysPerHost DisplaysPerHost=1 Per evitare che gli aggressori riempiano la coda delle richieste in attesa, GDM consentirà solo una connessione per ogni computer remoto. Se si vogliono fornire servizi di visualizzazione a computer con più di uno schermo, è necessario aumentare questo valore. Notare che il numero di DISPLAY collegati consentiti non è limitato. Solo le connessioni remote tramite XDMCP sono limitate da questa opzione di configurazione. Enable Enable=false Impostando questo valore a true si abilita il supporto XDMCP, consentendo la gestione di display/terminali X remoti da parte di GDM. gdm ascolta le richieste sulla porta UDP 177. Vedere l'opzione Port per maggiori informazioni. Se GDM è compilato per supportarlo, l'accesso dai display remoti può essere controllato usando la libreria TCP Wrappers. Il nome del servizio è gdm. Dovreste aggiungere gdm:.my.domain al vostro file <etc>/hosts.allow, a seconda della vostra configurazione di TCP Wrappers. Vedere la pagina di manuale hosts.allow per i dettagli. Si prega di notare che XDMCP non è un protocollo particolarmente sicuro e che è una buona idea bloccare la porta UDP 177 sul vostro firewall a meno che non sia realmente necessaria. HonorIndirect HonorIndirect=true Abilita la scelta XDMCP INDIRECT (cioè l'esecuzione remota di gdmchooser) per i terminali X che non forniscono un proprio browser di display. MaxPending MaxPending=4 Per evitare attacchi denial of service, GDM ha una coda di dimensione fissa per le connessioni in attesa. Solo MaxPending display possono avviarsi contemporaneamente. Si prega di notare che questo parametro non limita il numero di display remoti che possono essere gestiti. Limita solo il numero di display che avviano una connessione contemporaneamente. MaxSessions MaxSessions=16 Determina il numero massimo di connessioni di display remoti che saranno gestite simultaneamente. Cioè il numero totale di display remoti che possono usare il vostro host. MaxWait MaxWait=30 Quando GDM è pronto a gestire un display, gli viene inviato un pacchetto ACCEPT contenente un ID di sessione unico che sarà usato nelle future conversazioni XDMCP. GDM inserirà quindi l'ID di sessione nella coda in attesa che il display risponda con una richiesta MANAGE. Se non viene ricevuta alcuna risposta entro MaxWait secondi, GDM dichiarerà il display morto e lo cancellerà dalla coda in attesa, liberando lo slot per altri display. MaxWaitIndirect MaxWaitIndirect=30 Il parametro MaxWaitIndirect determina il numero massimo di secondi tra il momento in cui un utente sceglie un host e la successiva query indiretta in cui l'utente viene connesso all'host. Quando il timeout viene superato, le informazioni sull'host scelto vengono dimenticate e lo slot indiretto viene liberato per altri display. Le informazioni possono essere dimenticate prima se ci sono più host che cercano di inviare query indirette di MaxPendingIndirect. Port Port=177 Il numero di porta UDP a cui gdm dovrebbe ascoltare per le richieste XDMCP. Non cambiarlo a meno che tu non sappia cosa stai facendo. Willing Willing=<etc>/gdm/Xwilling Quando la macchina invia un pacchetto WILLING in risposta a una QUERY, invia una stringa che fornisce lo stato corrente di questo server. Il messaggio predefinito è l'ID di sistema, ma è possibile creare uno script che visualizza un messaggio personalizzato. Se questo script non esiste o questa chiave è vuota, viene inviato il messaggio predefinito. Se questo script ha successo e produce un output, viene inviata la prima riga del suo output (e solo la prima riga). Viene eseguito al massimo una volta ogni 3 secondi per prevenire possibili attacchi denial of service inondando la macchina di pacchetti QUERY. Il greeter predefinito di GDM è chiamato greeter semplice ed è configurato tramite GConf. I valori predefiniti sono memorizzati in GConf nel file gdm-simple-greeter.schemas. Questi valori predefiniti possono essere sovrascritti se l'utente «gdm» ha una directory $HOME scrivibile per memorizzare le impostazioni GConf. Questi valori possono essere modificati usando i programmi gconftool-2 o gconf-editor. Sono supportate le seguenti opzioni di configurazione: /apps/gdm/simple-greeter/banner_message_enable false (booleano) Controlla se viene visualizzato il testo del messaggio banner. /apps/gdm/simple-greeter/banner_message_text NULL (stringa) Specifica il messaggio di testo del banner da mostrare nella finestra del greeter. /apps/gdm/simple-greeter/disable_restart_buttons false (booleano) Controlla se mostrare i pulsanti di riavvio nella finestra di accesso. /apps/gdm/simple-greeter/disable_user_list false (booleano) Se true, il browser di volti con gli utenti noti non viene mostrato nella finestra di accesso. /apps/gdm/simple-greeter/logo_icon_name computer (stringa) Imposta il nome dell'icona del tema da usare per il logo del greeter. /apps/gdm/simple-greeter/recent-languages [] (lista di stringhe) Imposta un elenco di lingue da mostrare per impostazione predefinita nella finestra di accesso. Il valore predefinito è «[]». Con l'impostazione predefinita viene mostrata solo la lingua predefinita del sistema e l'opzione «Altro...» che apre una finestra di dialogo che mostra un elenco completo delle lingue disponibili che l'utente può selezionare. Gli utenti non dovrebbero modificare questa impostazione manualmente. Invece GDM tiene traccia di tutte le lingue selezionate in questa chiave di configurazione e le mostrerà nel menu a discesa delle lingue insieme alla scelta «Altro...». In questo modo, le lingue selezionate comunemente sono più facili da selezionare. /apps/gdm/simple-greeter/recent-layouts [] (lista di stringhe) Imposta un elenco di layout di tastiera da mostrare per impostazione predefinita nel pannello di accesso. Il valore predefinito è «[]». Con l'impostazione predefinita viene mostrato solo il layout di tastiera predefinito del sistema e l'opzione «Altro...» che apre una finestra di dialogo che mostra un elenco completo dei layout di tastiera disponibili che l'utente può selezionare. Gli utenti non dovrebbero modificare questa impostazione manualmente. Invece GDM tiene traccia di tutti i layout di tastiera selezionati in questa chiave di configurazione e li mostrerà nel menu a discesa dei layout di tastiera insieme alla scelta «Altro…». In questo modo, i layout di tastiera selezionati comunemente sono più facili da selezionare. /apps/gdm/simple-greeter/wm_use_compiz false (booleano) Controlla se compiz viene usato come window manager al posto di metacity. Questa sezione descrive le opzioni di configurazione dell'accessibilità disponibili in GDM. Il pannello del greeter di GDM nella schermata di accesso visualizza un'icona di accessibilità. Facendo clic su tale icona si apre la finestra di dialogo dell'accessibilità di GDM. In questa finestra, c'è un elenco di caselle di controllo, in modo che l'utente possa abilitare o disabilitare gli strumenti di assistenza associati. Le caselle di controllo che corrispondono agli strumenti di assistenza tastiera a schermo, lente d'ingrandimento e lettore di schermo agiscono sulle tre chiavi GConf descritte nella prossima sezione di questo documento. Abilitando o disabilitando queste caselle di controllo, la chiave GConf associata viene impostata su «true» o «false». Quando la chiave GConf è impostata su true, gli strumenti di assistenza collegati a questa chiave GConf vengono avviati. Quando la chiave GConf è impostata su «false», qualsiasi strumento di assistenza in esecuzione collegato a questa chiave GConf viene terminato. Queste chiavi GConf non vengono ripristinate automaticamente a uno stato predefinito dopo che l'utente ha effettuato l'accesso. Di conseguenza, gli strumenti di assistenza che erano in esecuzione durante l'ultima sessione di accesso GDM verranno avviati automaticamente alla successiva sessione di accesso GDM. Le altre caselle di controllo nella finestra di dialogo dell'accessibilità di GDM non hanno chiavi GConf corrispondenti perché non viene avviato alcun programma aggiuntivo per fornire le funzioni di accessibilità che offrono. Queste altre opzioni corrispondono a funzioni di accessibilità fornite dall'Xserver, che è sempre in esecuzione durante la sessione GDM. GDM offre le seguenti chiavi GConf per controllare le sue funzioni di accessibilità: /desktop/gnome/interface/accessibility false (booleano) Controlla se l'infrastruttura di accessibilità verrà avviata con la GUI di GDM. Questo è necessario per il funzionamento di molti programmi di tecnologia assistiva. /desktop/gnome/applications/at/screen_magnifier_enabled false (booleano) Se impostato, gli strumenti di assistenza collegati a questa chiave GConf verranno avviati con il programma GUI di GDM. Per impostazione predefinita, si tratta di un'applicazione di ingrandimento dello schermo. /desktop/gnome/applications/at/screen_keyboard_enabled false (booleano) Se impostato, gli strumenti di assistenza collegati a questa chiave GConf verranno avviati con il programma GUI di GDM. Per impostazione predefinita, si tratta di un'applicazione di tastiera a schermo. /desktop/gnome/applications/at/screen_reader_enabled false (booleano) Se impostato, gli strumenti di assistenza collegati a questa chiave GConf verranno avviati con il programma GUI di GDM. Per impostazione predefinita, si tratta di un'applicazione di lettura dello schermo. Per le chiavi GConf screen_magnifier_enabled, screen_keyboard_enabled e screen_reader_enabled, lo strumento di assistenza che viene avviato dipende dai file desktop situati nella directory di avvio automatico di GDM, come descritto nella sezione «Configurazione dell'avvio automatico» di questo manuale. Qualsiasi file desktop nella directory di avvio automatico di GDM può essere collegato a queste chiavi GConf specificando tale chiave GConf nel valore AutostartCondition nel file desktop. Quindi la riga AutostartCondition esatta nel file desktop potrebbe essere una delle seguenti: AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled AutostartCondition=GNOME /desktop/gnome/applications/at/screen_magnifier_enabled AutostartCondition=GNOME /desktop/gnome/applications/at/screen_reader_enabled Quando una chiave di accessibilità è true, qualsiasi programma collegato a tale chiave in un file desktop di avvio automatico di GDM verrà avviato (a meno che la chiave Hidden non sia impostata su true in quel file desktop). Una singola chiave GConf può anche avviare più strumenti di assistenza se ci sono più file desktop con questa AutostartCondition nella directory di avvio automatico di GDM. Per esempio, se GNOME è distribuito con GOK come tastiera a schermo predefinita, questa potrebbe essere sostituita con un programma diverso, se lo si desidera. Per sostituire GOK con l'applicazione di tastiera a schermo «onboard» e attivare inoltre lo strumento di assistenza «mousetweaks» per il supporto alla sosta (dwelling), è necessaria la seguente configurazione. Create un file desktop per onboard e un secondo per mousetweaks; per esempio, onboard.desktop e mousetweaks.desktop. Questi file devono essere inseriti nella directory di avvio automatico di GDM e devono essere nel formato spiegato nella sezione «Configurazione dell'avvio automatico» di questo documento. Di seguito un esempio di file onboard.desktop: [Desktop Entry] Encoding=UTF-8 Name=Tastiera a schermo Onboard Comment=Usa una tastiera a schermo TryExec=onboard Exec=onboard --size 500x180 -x 20 -y 10 Terminal=false Type=Application StartupNotify=true Categories=GNOME;GTK;Accessibility; AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled Di seguito un esempio di file mousetweaks.desktop: [Desktop Entry] Encoding=UTF-8 Name=Clic software del mouse Comment=Esegui clic sostando con il puntatore TryExec=mousetweaks Exec=mousetweaks --enable-dwell -m window -c -x 20 -y 240 Terminal=false Type=Application StartupNotify=true Categories=GNOME;GTK;Accessibility; AutostartCondition=GNOME /desktop/gnome/applications/at/screen_keyboard_enabled Notare la riga con AutostartCondition che collega entrambi i file desktop alla chiave GConf per la tastiera a schermo. Per disabilitare l'avvio di GOK, il file desktop per la tastiera a schermo GOK deve essere rimosso o disattivato. Altrimenti onboard e GOK verrebbero avviati simultaneamente. Questo può essere fatto rimuovendo il file gok.desktop dalla directory di avvio automatico di GDM, o aggiungendo l'impostazione «Hidden=true» al file gok.desktop. Dopo aver apportato queste modifiche, GOK non verrà più avviato quando l'utente attiverà la tastiera a schermo nella sessione GDM; ma verranno invece avviati onboard e mousetweaks. Il greeter di GDM usa parte dello stesso framework che userà la vostra sessione desktop. E quindi, è influenzato da una serie delle stesse impostazioni GConf. Per ciascuna di queste impostazioni, il greeter userà il valore predefinito a meno che non sia specificamente sovrascritto da a) la politica obbligatoria installata da GDM b) la politica obbligatoria di sistema. GDM installa la propria politica obbligatoria per bloccare alcune impostazioni per motivi di sicurezza. GDM abilita i seguenti plugin di gnome-settings-daemon: a11y-keyboard, background, sound, xsettings. Questi sono responsabili di cose come l'immagine di sfondo, le impostazioni dei caratteri e del tema, gli eventi sonori, ecc. I plugin possono anche essere disabilitati usando GConf. Per esempio, se si vuole disabilitare il plugin del suono, deselezionare la seguente chiave: /apps/gdm/simple-greeter/settings-manager-plugins/sound/active. Le sessioni GDM sono specificate usando la FreeDesktop.org Desktop Entry Specification, che può essere consultata al seguente URL: http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec. Per impostazione predefinita, GDM installerà i file desktop nella directory <share>/xsessions. GDM cercherà i file desktop nelle seguenti directory in questo ordine: <etc>/X11/sessions/, <dmconfdir>/Sessions, <share>/gdm/BuiltInSessions e <share>/xsessions. Per impostazione predefinita, <dmconfdir> è impostato su <etc>/dm/ a meno che GDM non sia configurato per usare una directory diversa tramite l'opzione «--with-dmconfdir». Una sessione può essere disabilitata modificando il file desktop e aggiungendo una riga come segue: Hidden=true. I file desktop di GDM supportano un'estensione specifica di GDM, una chiave chiamata «X-GDM-BypassXsession». Se la chiave non è specificata in un file desktop, il valore predefinito è «false». Se questa chiave è specificata come «true» in un file desktop, GDM avvierà direttamente il programma specificato dalla chiave «Exec» del file desktop all'avvio della sessione utente. Non eseguirà il programma tramite lo script <etc>/gdm/Xsession, che è il comportamento normale. Poiché bypassare lo script <etc>/gdm/Xsession evita di impostare la sessione utente con le normali impostazioni di sistema e utente, le sessioni avviate in questo modo possono essere utili per il debug di problemi negli script di sistema o utente che potrebbero impedire a un utente di avviare una sessione. Le scelte predefinite di sessione e lingua dell'utente sono memorizzate nel file ~/.dmrc. Quando un utente accede per la prima volta, questo file viene creato con le scelte iniziali dell'utente. L'utente può modificare questi valori predefiniti semplicemente passando a un valore diverso durante l'accesso. GDM ricorderà questa modifica per gli accessi successivi. Il file ~/.dmrc è nel formato standard INI. Ha una sezione chiamata [Desktop] che ha due chiavi: Session e Language. La chiave Session specifica il nome di base del file .desktop della sessione che l'utente desidera usare normalmente, senza l'estensione .desktop. La chiave Language specifica la lingua che l'utente desidera usare per impostazione predefinita. Se una di queste chiavi manca, viene usata l'impostazione predefinita del sistema. Il file apparirebbe normalmente come segue: [Desktop] Session=gnome Language=it_IT.UTF-8 Il pacchetto GDM fornisce i seguenti comandi in sbindir destinati a essere eseguiti dall'utente root: gdm è il demone principale che imposta l'ambiente di accesso grafico e avvia gli helper necessari. -?, --help Fornisce una breve panoramica delle opzioni della riga di comando. --fatal-warnings Fa sì che tutti gli avvisi causino l'uscita di GDM. --timed-exit Esce dopo 30 secondi. Utile per il debug. --version Stampa la versione del demone GDM. gdm-restart arresta e riavvia GDM inviando al demone GDM un segnale HUP. Questo comando terminerà immediatamente tutte le sessioni e disconnetterà gli utenti attualmente connessi con GDM. gdm-safe-restart arresta e riavvia GDM inviando al demone GDM un segnale USR1. GDM verrà riavviato non appena tutti gli utenti si disconnetteranno. gdm-stop arresta GDM inviando al demone GDM un segnale TERM. Questa sezione discute suggerimenti utili per far funzionare GDM. In generale, se si ha un problema con GDM, si può inviare un bug o un'email alla mailing list gdm-list. Le informazioni su come farlo si trovano nella sezione Introduzione del documento. Se GDM non funziona correttamente, è sempre una buona idea includere le informazioni di debug. Per abilitare il debug, impostare la chiave debug/Enable a «true» nel file <etc>/gdm/custom.conf e riavviare GDM. Quindi usare GDM fino al punto in cui si verifica l'errore; l'output di debug verrà inviato al file di log di sistema (<var>/log/messages o <var>/adm/messages a seconda del sistema operativo). Se si condivide questo output con la comunità di GDM tramite una segnalazione di bug o un'email, si prega di includere solo le informazioni di debug relative a GDM e non l'intero file, poiché può essere di grandi dimensioni. Se non si vede alcun output di GDM in syslog, potrebbe essere necessario configurare syslog (fare riferimento alla pagina di manuale syslog). Ci sono molti problemi che possono impedire l'avvio di GDM, ma questa sezione discuterà alcuni problemi comuni e come affrontare la ricerca di un problema con l'avvio di GDM. Alcuni problemi causeranno una risposta di GDM con un messaggio di errore o una finestra di dialogo quando tenta di avviarsi, ma può essere difficile individuare i problemi quando GDM fallisce silenziosamente. Innanzitutto, assicurarsi che l'Xserver sia configurato correttamente. Il file di configurazione di GDM contiene un comando nella sezione [server-Standard] che viene usato per avviare l'Xserver. Verificare che questo comando funzioni sul proprio sistema. L'esecuzione di questo comando dalla console dovrebbe avviare l'Xserver. Se fallisce, il problema è probabilmente nella configurazione dell'Xserver. Fare riferimento al log degli errori dell'Xserver per avere un'idea di quale possa essere il problema. Il problema potrebbe anche essere che l'Xserver richieda opzioni diverse dalla riga di comando. In tal caso, modificare il comando dell'Xserver nel file di configurazione di GDM in modo che sia corretto per il proprio sistema. Assicurarsi anche che la directory /tmp abbia proprietà e permessi ragionevoli, e che il file system della macchina non sia pieno. Questi problemi causeranno il fallimento dell'avvio di GDM. Questo programma è software libero; è possibile ridistribuirlo e/o modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation; sia la versione 2 della licenza, sia (a propria discrezione) una versione successiva. Questo programma è distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA; senza nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ A UN PARTICOLARE SCOPO. Vedere la GNU General Public License per maggiori dettagli. Una copia della GNU General Public License è inclusa come appendice alla Guida utente di GNOME. È anche possibile ottenere una copia della GNU General Public License dalla Free Software Foundation visitando il loro sito web o scrivendo a

Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor Boston, MA 02110-1301 USA