diff options
| author | Brian Cameron <brian.cameron@sun.com> | 2004-08-26 21:00:21 +0000 |
|---|---|---|
| committer | Brian Cameron <bcameron@src.gnome.org> | 2004-08-26 21:00:21 +0000 |
| commit | c1ffb6191da44ab8456f6949855e4b07bd9bfb08 (patch) | |
| tree | fe39e0b59bd0a9f63746625138401ef19fedc79c /docs | |
| parent | 6baac65ad616408ed91fc3e83f29a2f24d4a6b95 (diff) | |
| download | gdm-c1ffb6191da44ab8456f6949855e4b07bd9bfb08.tar.gz | |
Updated docs to include gdmflexiserver command options, arguments for all
Thu Aug 26 15:55:00 2004 Brian Cameron <brian.cameron@sun.com>
* docs/C/gdm.xml: Updated docs to include gdmflexiserver command
options, arguments for all GDM programs aside from gdm-binary
(which was already there), added accessibility section, and
cleaned up the XML so it is more readible. Also added a
comment that gdmlogin now lets you change the theme from the
menu.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/C/gdm.xml | 7276 |
1 files changed, 4000 insertions, 3276 deletions
diff --git a/docs/C/gdm.xml b/docs/C/gdm.xml index 7f673b01..fb82a18e 100644 --- a/docs/C/gdm.xml +++ b/docs/C/gdm.xml @@ -11,7 +11,8 @@ <title>Gnome Display Manager Reference Manual</title> <authorgroup> <author> - <firstname>Martin</firstname><othername>K.</othername><surname>Petersen</surname> + <firstname>Martin</firstname><othername>K.</othername> + <surname>Petersen</surname> <affiliation> <address><email>mkp@mkp.net</email></address> </affiliation> @@ -28,25 +29,32 @@ <address><email>Brian.Cameron@Sun.COM</email></address> </affiliation> </author> + <author> + <firstname>Bill</firstname><surname>Haneman</surname> + <affiliation> + <address><email>Bill.Haneman@Sun.COM</email></address> + </affiliation> + </author> </authorgroup> <copyright> - <year>1998</year> <year>1999</year> <holder>Martin K. Petersen</holder> + <year>1998</year><year>1999</year><holder>Martin K. Petersen</holder> </copyright> <copyright> - <year>2001</year> <year>2003</year> <year>2004</year> <holder>George Lebl</holder> + <year>2001</year><year>2003</year><year>2004</year> + <holder>George Lebl</holder> </copyright> <copyright> <year>2003</year> <holder>Red Hat, Inc.</holder> </copyright> <copyright> - <year>2003</year> <holder>Sun Microsystems, Inc.</holder> + <year>2003</year><year>2004</year><holder>Sun Microsystems, Inc.</holder> </copyright> &legal; <releaseinfo> - This manual describes version &version; of the GNOME Display Manager. It was - last updated on &date;. + This manual describes version &version; of the GNOME Display Manager. + It was last updated on &date;. </releaseinfo> </articleinfo> @@ -55,13 +63,13 @@ <title>Terms and Conventions Used in This Manual</title> <para> - This manual describes version &version; of the GNOME Display Manager. It was - last updated on &date;. + This manual describes version &version; of the GNOME Display Manager. + It was last updated on &date;. </para> <para> - GDM - Gnome Display Manager. Used to describe the software - package as a whole. Sometimes also referred to as GDM2. + GDM - Gnome Display Manager. Used to describe the software package as a + whole. Sometimes also referred to as GDM2. </para> <para> @@ -74,11 +82,13 @@ </para> <para> - Standard Greeter - The standard login window (<filename>gdmlogin</filename>). + Standard Greeter - The standard login window ( + <filename>gdmlogin</filename>). </para> <para> - Graphical Greeter - The themable login window (<filename>gdmgreeter</filename>). + Graphical Greeter - The themable login window ( + <filename>gdmgreeter</filename>). </para> <para> @@ -91,16 +101,17 @@ </para> <para> - Paths that start with a word in angle brackets are relative to the installation - prefix. I.e. <filename><share>/pixmaps/</filename> refers to - <filename>/usr/share/pixmaps</filename> if GDM was configured + Paths that start with a word in angle brackets are relative to the + installation prefix. I.e. <filename><share>/pixmaps/</filename> + refers to <filename>/usr/share/pixmaps</filename> if GDM was configured with <filename>--prefix=/usr</filename>. Normally also note that GDM is installed with <filename>--sysconfigdir=/etc/X11</filename>, meaning any path to which we refer to as <filename><etc>/gdm/PreSession</filename> usually means - <filename>/etc/X11/gdm/PreSession</filename>. Note that for interoperability - it is recommended that you use a prefix of <filename>/usr</filename> - and a sysconfdir of <filename>/etc/X11</filename>. + <filename>/etc/X11/gdm/PreSession</filename>. Note that for + interoperability it is recommended that you use a prefix of + <filename>/usr</filename> and a sysconfdir of + <filename>/etc/X11</filename>. </para> </sect1> @@ -110,19 +121,19 @@ <sect2 id="introduction"> <title> - Introduction + Introduction </title> <para> - GDM is a replacement for XDM, the X Display Manager. Unlike its - competitors (X3DM, KDM, WDM) GDM was written from scratch and - does not contain any original XDM / X Consortium code. + GDM is a replacement for XDM, the X Display Manager. Unlike its + competitors (X3DM, KDM, WDM) GDM was written from scratch and does not + contain any original XDM / X Consortium code. </para> <para> - For further information about GDM, see the - <ulink type="http" url="http://www.jirka.org/gdm.html"> - the GDM website</ulink>. + For further information about GDM, see the + <ulink type="http" url="http://www.jirka.org/gdm.html"> + the GDM website</ulink>. </para> </sect2> @@ -131,111 +142,107 @@ <title>The GDM Daemon</title> <para> - GDM was written with simplicity and security in mind. The - overall design concept is this: + GDM was written with simplicity and security in mind. The overall + design concept is this: </para> <para> - Upon startup the <filename>gdm</filename> daemon parses its config file - <filename>gdm.conf</filename>. For each of the local displays <filename>gdm</filename> - forks an Xserver and a slave process. The main <filename>gdm</filename> process - will then listen to XDMCP requests, if so configured, from remote displays and - monitor the local display sessions. The main daemon process will also allow - starting of on new local Xservers on demand using the <filename>gdmflexiserver</filename> - command. + Upon startup the <filename>gdm</filename> daemon parses its config file + <filename>gdm.conf</filename>. For each of the local displays + <filename>gdm</filename> forks an Xserver and a slave process. The + main <filename>gdm</filename> process will then listen to XDMCP + requests, if so configured, from remote displays and monitor the local + display sessions. The main daemon process will also allow starting of + on new local Xservers on demand using the + <filename>gdmflexiserver</filename> command. </para> <para> - The <filename>gdm</filename> slave process opens the display and starts - <filename>gdmlogin</filename>, the graphical login - program. <filename>gdmlogin</filename> runs as a dedicated - user and communicates asynchronously with the slave process - through a pipe. Alternatively <filename>gdmgreeter</filename> command - can be used which is the same as <filename>gdmlogin</filename> but - allows greater themability. <filename>gdmgreeter</filename> - is referred to as the Graphical Greeter, while - <filename>gdmlogin</filename> is refereed to as the Standard - Greeter. + The <filename>gdm</filename> slave process opens the display and starts + <filename>gdmlogin</filename>, the graphical login program. + <filename>gdmlogin</filename> runs as a dedicated user and communicates + asynchronously with the slave process through a pipe. Alternatively + <filename>gdmgreeter</filename> command can be used which is the same + as <filename>gdmlogin</filename> but allows greater themability. + <filename>gdmgreeter</filename> is referred to as the Graphical + Greeter, while <filename>gdmlogin</filename> is refereed to as the + Standard Greeter. </para> <para> - GDM relies heavily on the presence of PAM, Pluggable - Authentication Modules, but supports regular crypt() - and shadow passwords on legacy systems. + GDM relies heavily on the presence of PAM, Pluggable Authentication + Modules, but supports regular crypt() and shadow passwords on legacy + systems. </para> <para> - Remote displays can connect to the XDMCP port on the GDM - host. <filename>gdm</filename> will grant access to hosts specified in - the gdm service section in your TCP Wrappers configuration - file. GDM does not support remote display access control on - systems without TCP Wrappers. XDMCP support can be turned off - completely, however. + Remote displays can connect to the XDMCP port on the GDM host. + <filename>gdm</filename> will grant access to hosts specified in the + gdm service section in your TCP Wrappers configuration file. GDM does + not support remote display access control on systems without TCP + Wrappers. XDMCP support can be turned off completely, however. </para> <para> - GDM includes several measures making it more resistant to - denial of service attacks on the XDMCP service. A lot of the - protocol parameters, handshaking timeouts etc. can be fine - tuned. The defaults should work for most systems, however. - Don't change them unless you know what you're doing. + GDM includes several measures making it more resistant to denial of + service attacks on the XDMCP service. A lot of the protocol parameters, + handshaking timeouts etc. can be fine tuned. The defaults should work + for most systems, however. Don't change them unless you know what + you are doing. </para> <para> - In general GDM is very reluctant regarding reading/writing of - user files. For instance it refuses to touch anything but - regular files. Links, sockets and devices are ignored. The - value of the RelaxPermissions parameter determines whether GDM - should accept files writable by the user's group or others. - These are ignored by default. + In general GDM is very reluctant regarding reading/writing of user + files. For instance it refuses to touch anything but regular files. + Links, sockets and devices are ignored. The value of the + RelaxPermissions parameter determines whether GDM should accept files + writable by the user's group or others. These are ignored by default. </para> <para> - All operations on user files are done with the effective - user id of the user. If the sanity check fails on the user's - <filename>.Xauthority</filename> file, a fallback cookie is created in - <filename>/tmp</filename>. + All operations on user files are done with the effective user id of the + user. If the sanity check fails on the user's + <filename>.Xauthority</filename> file, a fallback cookie is created in + <filename>/tmp</filename>. </para> <para> - Note that normally it is assumed that the home directory - is only readable by the user. However NFS traffic really - goes "over the wire" and thus can be snooped. For setups - with NFS directories you should really use the - <filename>UserAuthDir</filename> and set it to some local - directory such as <filename>/tmp</filename>. GDM will try - to open the normal authorization file for reading as root, and - if it fails, then - it will conclude that it is on an NFS mount and it will - automatically use <filename>UserAuthFBDir</filename>, - which is usually <filename>/tmp</filename>. - This can be changed by setting <filename>NeverPlaceCookiesOnNFS</filename> - in the <filename>[security]</filename> section to false. + Note that normally it is assumed that the home directory is only + readable by the user. However NFS traffic really goes "over the wire" + and thus can be snooped. For setups with NFS directories you should + really use the <filename>UserAuthDir</filename> and set it to some + local directory such as <filename>/tmp</filename>. GDM will try to + open the normal authorization file for reading as root, and if it + fails, then it will conclude that it is on an NFS mount and it will + automatically use <filename>UserAuthFBDir</filename>, which is usually + <filename>/tmp</filename>. This can be changed by setting + <filename>NeverPlaceCookiesOnNFS</filename> in the + <filename>[security]</filename> section to false. </para> <para> - GDM implements only the MIT-MAGIC-COOKIE-1 authorization scheme, - see the XDMCP section for more information about this, especially - relating to using X over the network. + GDM implements only the MIT-MAGIC-COOKIE-1 authorization scheme, see + the XDMCP section for more information about this, especially relating + to using X over the network. </para> <para> - Finally, the sysadmin can specify the maximum file size GDM - should accept, and, if the face browser is enabled, a tunable - maximum icon size is also enforced. On large systems it is - still advised to turn off the face browser for performance - reasons. Looking up icons in homedirs, scaling and rendering - face icons can take quite a long time. YMMV. + Finally, the sysadmin can specify the maximum file size GDM should + accept, and, if the face browser is enabled, a tunable maximum icon + size is also enforced. On large systems it is still advised to turn + off the face browser for performance reasons. Looking up icons in + homedirs, scaling and rendering face icons can take quite a long time. + YMMV. </para> <para> - GDM also has a unix domain socket which can be used to control - certain aspects of behavior, or to query information about running - servers or logged in users. This is the <filename>/tmp/.gdm_socket</filename> - and the protocol is described in the sources in the - <filename>daemon/gdm.h</filename> header file. The - <filename>gdmflexiserver</filename> command uses this for example to - launch on demand X servers for the user. + GDM also has a unix domain socket which can be used to control + certain aspects of behavior, or to query information about running + servers or logged in users. This is the + <filename>/tmp/.gdm_socket</filename> and the protocol is described + in the sources in the <filename>daemon/gdm.h</filename> header file. + The <filename>gdmflexiserver</filename> command uses this for example + to launch on demand X servers for the user. </para> </sect2> @@ -244,183 +251,171 @@ <title>Different Display Types</title> <para> - GDM allows 3 different display types. First local static X servers. These - are always run, and when they die or are killed, they are restarted. GDM - can run as many of these as needed. GDM can also manage servers on which it - does not manage a login itself, thus allowing GDM to be used when building - X terminals. + GDM allows 3 different display types. First local static X servers. + These are always run, and when they die or are killed, they are + restarted. GDM can run as many of these as needed. GDM can also + manage servers on which it does not manage a login itself, thus + allowing GDM to be used when building X terminals. </para> <para> - Next GDM supports flexible or on demand servers. These are run by - requesting one using the socket protocol. There is a command, - <filename>gdmflexiserver</filename>, which can do this for the user. - For standard X servers the user must be logged in from a console, on - one of the servers that GDM has run. This command can however also - launch nested <filename>Xnest</filename> servers which can be started - even from non-console logins. This is generally done by running - <filename>gdmflexiserver -n</filename>. These servers - are not restarted when the user session ends. - <filename>gdmflexiserver</filename> normally also locks the users - screen before running a new server with xscreensaver. + Next GDM supports flexible or on demand servers. These are run by + requesting one using the socket protocol. There is a command, + <filename>gdmflexiserver</filename>, which can do this for the user. + For standard X servers the user must be logged in from a console, on + one of the servers that GDM has run. This command can however also + launch nested <filename>Xnest</filename> servers which can be started + even from non-console logins. This is generally done by running + <filename>gdmflexiserver -n</filename>. These servers + are not restarted when the user session ends. + <filename>gdmflexiserver</filename> normally also locks the users + screen before running a new server with xscreensaver. </para> <para> - Last display type is the XDMCP remote displays that are described - in the next section. Remote hosts can connect to GDM and present - the login screen if this is enabled. Some things may be different - for these sessions, such as the Actions menu which allows you to - shut down, reboot, or configure GDM will not be shown. + Last display type is the XDMCP remote displays that are described in + the next section. Remote hosts can connect to GDM and present the + login screen if this is enabled. Some things may be different for + these sessions, such as the Actions menu which allows you to shut down, + reboot, or configure GDM will not be shown. </para> </sect2> <sect2 id="xdmcp"> <title> - XDMCP + XDMCP </title> <para> - GDM also supports the X Display Manager Protocol (XDMCP) for - managing remote displays. + GDM also supports the X Display Manager Protocol (XDMCP) for managing + remote displays. </para> <para> - GDM listens to UDP port 177 and will respond to QUERY and - BROADCAST_QUERY requests by sending a WILLING packet to the - originator. + GDM listens to UDP port 177 and will respond to QUERY and + BROADCAST_QUERY requests by sending a WILLING packet to the originator. </para> <para> - GDM can also be configured to honor INDIRECT queries and - present a host chooser to the remote display. GDM will - remember the user's choice and forward subsequent requests to - the chosen manager. GDM also supports an extension to the - protocol which will make it forget the redirection once - the user's connection succeeds. This extension is only - supported if both daemons are GDM. It is transparent and - will be ignored by XDM or other daemons that implement - XDMCP. + GDM can also be configured to honor INDIRECT queries and present a + host chooser to the remote display. GDM will remember the user's + choice and forward subsequent requests to the chosen manager. GDM + also supports an extension to the protocol which will make it forget + the redirection once the user's connection succeeds. This extension + is only supported if both daemons are GDM. It is transparent and + will be ignored by XDM or other daemons that implement XDMCP. </para> <para> - GDM only supports the MIT-MAGIC-COOKIE-1 authentication - system. Normally little is gained from the other schemes, - and no effort has been made to implement them so far. - Because of this the cookies go over the wire as - clear text, and thus you should be careful about what - network you use this on. That is, you should be careful - about through where your XDMCP connection is going. - Note that obviously if snooping is possible, then the - attacker could just snoop your password as you log in, - so a better XDMCP authentication wouldn't help you much - anyway. - If snooping is possible - and undesirable, then you had better use ssh for tunneling - an X connection anyway rather then using GDM's XDMCP. - You could think of XDMCP as a sort of graphical telnet, - having the same security issues. + GDM only supports the MIT-MAGIC-COOKIE-1 authentication system. + Normally little is gained from the other schemes, and no effort has + been made to implement them so far. Because of this the cookies go + over the wire as clear text, and thus you should be careful about what + network you use this on. That is, you should be careful about through + where your XDMCP connection is going. Note that obviously if snooping + is possible, then the attacker could just snoop your password as you + log in, so a better XDMCP authentication wouldn't help you much anyway. + If snooping is possible and undesirable, then you had better use ssh + for tunneling an X connection anyway rather then using GDM's XDMCP. + You could think of XDMCP as a sort of graphical telnet, having the + same security issues. </para> <para> - On the upside, GDM's random number generation is very - anal and GDM goes - to extraordinary measures to truly get a 128 bit random number, - using hardware random number generators if available, plus the - current time (in microsecond precision), a 20 byte array of pseudorandom - numbers, process pid's, plus other random information (possibly using - <filename>/dev/audio</filename> or <filename>/dev/mem</filename> - if hardware random generators are not available) - to create a large buffer and then run MD5 digest on this. - Obviously, all this work is wasted if you send this cookie over - an open network or store it on an NFS directory (see - <filename>UserAuthDir</filename> configuration key). So be careful - about where you use remote X display. + On the upside, GDM's random number generation is very anal and GDM + goes to extraordinary measures to truly get a 128 bit random number, + using hardware random number generators if available, plus the current + time (in microsecond precision), a 20 byte array of pseudorandom + numbers, process pid's, plus other random information (possibly using + <filename>/dev/audio</filename> or <filename>/dev/mem</filename> if + hardware random generators are not available) to create a large buffer + and then run MD5 digest on this. Obviously, all this work is wasted if + you send this cookie over an open network or store it on an NFS + directory (see <filename>UserAuthDir</filename> configuration key). So + be careful about where you use remote X display. </para> <para> - Since it is fairly easy to do denial of service attacks on the - XDMCP service, GDM incorporates a few features to guard - against attacks. Please read the XDMCP reference section below - for more information. + Since it is fairly easy to do denial of service attacks on the XDMCP + service, GDM incorporates a few features to guard against attacks. + Please read the XDMCP reference section below for more information. </para> <para> - Even though GDM tries to outsmart potential attackers, it is - still advised that you block UDP port 177 on your firewall - unless you really need it. GDM guards against DoS attacks, but - the X protocol is still inherently insecure and should only be - used in controlled environments. Also each remote connection - takes up lots of resources, so it is much easier to to DoS - an XDMCP server then say a webserver. + Even though GDM tries to outsmart potential attackers, it is still + advised that you block UDP port 177 on your firewall unless you really + need it. GDM guards against DoS attacks, but the X protocol is still + inherently insecure and should only be used in controlled environments. + Also each remote connection takes up lots of resources, so it is much + easier to to DoS an XDMCP server then say a webserver. </para> <para> - In addition to UDP port 177, you should also block all the - X server ports (TCP ports 6000 + display number) on the firewall - as well. Do note that various places in GDM will use display - numbers 20 and higher (for example the on demand server stuff). - X is not a very safe protocol for leaving on the net, and XDMCP - is even less safe. + In addition to UDP port 177, you should also block all the X server + ports (TCP ports 6000 + display number) on the firewall as well. Do + note that various places in GDM will use display numbers 20 and higher + (for example the on demand server stuff). X is not a very safe + protocol for leaving on the net, and XDMCP is even less safe. </para> <para> - Even though your display is protected by cookies the XEvents - and thus the keystrokes typed when entering passwords will - still go over the wire in clear text. It is trivial to capture - these. You should also be aware that cookies, if placed on an - NFS mounted directory, are prone to eavesdropping too. - In case of NFS home directories you should really use the - <filename>UserAuthDir</filename> and set it to some local - temporary directory. + Even though your display is protected by cookies the XEvents and thus + the keystrokes typed when entering passwords will still go over the + wire in clear text. It is trivial to capture these. You should also be + aware that cookies, if placed on an NFS mounted directory, are prone to + eavesdropping too. In case of NFS home directories you should really + use the <filename>UserAuthDir</filename> and set it to some local + temporary directory. </para> <para> - XDMCP is primarily useful for running thin clients such - as in terminal labs. Those thin - clients will only ever need the network to access the server, and - so it seems - like the best policy securitywise to have those thin clients on - a separate network that cannot be accessed by the outside world, - and can only connect to the server. The only point from which you - need to access outside is the server. + XDMCP is primarily useful for running thin clients such as in terminal + labs. Those thin clients will only ever need the network to access + the server, and so it seems like the best policy securitywise to have + those thin clients on a separate network that cannot be accessed by + the outside world, and can only connect to the server. The only point + from which you need to access outside is the server. </para> </sect2> <sect2 id="xdmcpaccess"> <title> - XDMCP Access Control + XDMCP Access Control </title> <para> - XDMCP access control is done using TCP wrappers. It is possible - to compile GDM without TCP wrappers however, so you should test - your configuration to see if they work. + XDMCP access control is done using TCP wrappers. It is possible to + compile GDM without TCP wrappers however, so you should test your + configuration to see if they work. </para> <para> - You should use the daemon name <filename>gdm</filename> in the - <filename>/etc/hosts.allow</filename> and - <filename>/etc/hosts.deny</filename> files. For example to - deny computers from <filename>.evil.domain</filename> from logging in, then - add - <screen> - gdm: .evil.domain</screen> - to <filename>/etc/hosts.deny</filename>. You may also need - to add - <screen> - gdm: .your.domain</screen> - to your <filename>/etc/hosts.allow</filename> if you normally - disallow all services from all hosts. See the - <ulink type="help" url="man:hosts.allow">hosts.allow(5)</ulink> man page for details. + You should use the daemon name <filename>gdm</filename> in the + <filename>/etc/hosts.allow</filename> and + <filename>/etc/hosts.deny</filename> files. For example to + deny computers from <filename>.evil.domain</filename> from logging in, + then add + </para> + <screen>gdm: .evil.domain</screen> + <para> + to <filename>/etc/hosts.deny</filename>. You may also need + to add + </para> + <screen>gdm: .your.domain</screen> + <para> + to your <filename>/etc/hosts.allow</filename> if you normally disallow + all services from all hosts. See the + <ulink type="help" url="man:hosts.allow">hosts.allow(5)</ulink> man + page for details. </para> <para> - Even though GDM now tries - very hard to ignore things coming from banned hosts you should - not rely on the TCP Wrappers for complete protection. It is really - best to block UDP port 177 (and all the X ports which are TCP ports - 6000 + the display number of course) on your firewall. + Even though GDM now tries very hard to ignore things coming from + banned hosts you should not rely on the TCP Wrappers for complete + protection. It is really best to block UDP port 177 (and all the X + ports which are TCP ports 6000 + the display number of course) on your + firewall. </para> </sect2> @@ -428,66 +423,63 @@ <title>The Standard Greeter</title> <para> - The Standard Greeter is the default graphical user interface that - is presented to the user. The greeter contains a menu at the top, an - optional face browser, an optional logo and a text entry - widget. + The Standard Greeter is the default graphical user interface that is + presented to the user. The greeter contains a menu at the top, an + optional face browser, an optional logo and a text entry + widget. </para> <para> The text entry field is used for entering logins, passwords, passphrases etc. <filename>gdmlogin</filename> is controlled by the - underlying daemon and is basically stateless. The daemon - controls the greeter through a simple protocol where it can - ask the greeter for a text string with echo turned on or - off. Similarly, the daemon can change the label above the - text entry widget to correspond to the value the - authentication system wants the user to enter. + underlying daemon and is basically stateless. The daemon controls the + greeter through a simple protocol where it can ask the greeter for a + text string with echo turned on or off. Similarly, the daemon can + change the label above the text entry widget to correspond to the + value the authentication system wants the user to enter. </para> <para> - The menu bar in the top of the greeter enables the user to - select the requested session type/desktop environment, - select an appropriate locale/language and optionally - shutdown/reboot/suspend the machine, configure GDM (given the user - knows the root password) or start an XDMCP chooser. + The menu bar in the top of the greeter enables the user to select the + requested session type/desktop environment, select an appropriate + locale/language and optionally shutdown/reboot/suspend the machine, + configure GDM (given the user knows the root password), change + the GTK+ theme, or start an XDMCP chooser. </para> <para> - Optionally the greeter can provide a face browser containing - icons for all the users on a system. The icons can be installed globally - by the sysadmin or in the users' home directories. If installed - globally they should be in the <filename><share>/faces/</filename> + Optionally the greeter can provide a face browser containing icons for + all the users on a system. The icons can be installed globally by the + sysadmin or in the users' home directories. If installed globally + they should be in the <filename><share>/faces/</filename> directory (though this can be configured with the <filename>GlobalFaceDir</filename> - configuration option) and the filename should be the name of - the user, optionally with a <filename>.png</filename> appended. + configuration option) and the filename should be the name of the user, + optionally with a <filename>.png</filename> appended. </para> <para> - The users can place their icons in a file called <filename>~/.face</filename>, - and they can use the program <filename>gdmphotosetup</filename> to - graphically configure this. + The users can place their icons in a file called + <filename>~/.face</filename>, and they can use the program + <filename>gdmphotosetup</filename> to graphically configure this. </para> - + <para> - Face icons placed in the global face directory - must be readable to the gdm user. However, the daemon, proxies - user pictures to the greeter and thus those don't have be be - readable by the gdm user, but root. + Face icons placed in the global face directory must be readable to + the gdm user. However, the daemon, proxies user pictures to the + greeter and thus those don't have be be readable by the gdm user, but + root. </para> <para> - Please note that loading and scaling face icons located in - user home directories can be a very time consuming task. - Especially on large systems or systems running NIS. The - browser feature is only intended for systems with relatively - few users. Also if home directories are on an on demand - mounted filesystem like AFS, then GDM may mount all the - home directories just to check for pictures if the face - browser is on. GDM will try to give up after 5 seconds of activity - however and only display the users whoose pictures it - has gotten so far. + Please note that loading and scaling face icons located in user home + directories can be a very time consuming task. Especially on large + systems or systems running NIS. The browser feature is only intended + for systems with relatively few users. Also if home directories are + on an on demand mounted filesystem like AFS, then GDM may mount all + the home directories just to check for pictures if the face browser is + on. GDM will try to give up after 5 seconds of activity however and + only display the users whoose pictures it has gotten so far. </para> <para> @@ -495,24 +487,23 @@ option is implemented. The greeter will automatically ignore usernames listed in the <filename>Exclude</filename> statement in the config file, and furthermore exclude users whose UIDs are lower - then <filename>MinimalUID</filename>. + then <filename>MinimalUID</filename>. </para> <para> - When the browser is turned on, valid usernames on the - machine are inherently exposed to a potential intruder. - This may be a bad idea if you don't know who can get to a login - screen. This is especially true if you run XDMCP. However - you should never run XDMCP on an open network anyway. + When the browser is turned on, valid usernames on the machine are + inherently exposed to a potential intruder. This may be a bad idea if + you don't know who can get to a login screen. This is especially true + if you run XDMCP. However you should never run XDMCP on an open + network anyway. </para> <para> - The greeter can optionally display a logo in the login - window. The image must be in a format readable to the gdk-pixbuf - library (GIF, JPG, PNG, TIFF, XPM and possibly others), and - it must be readable to the gdm user. See the - <filename>Logo</filename> option in the reference section below - for details. + The greeter can optionally display a logo in the login window. The + image must be in a format readable to the gdk-pixbuf library (GIF, + JPG, PNG, TIFF, XPM and possibly others), and it must be readable to + the gdm user. See the <filename>Logo</filename> option in the + reference section below for details. </para> </sect2> @@ -521,23 +512,23 @@ <title>The Graphical Greeter</title> <para> - The Graphical Greeter is a greeter interface that takes up the whole - screen and is very themable. Themes can be selected and new themes - can be installed by the Configuration program or by setting the - <filename>GraphicalTheme</filename> configuration key. + The Graphical Greeter is a greeter interface that takes up the whole + screen and is very themable. Themes can be selected and new themes + can be installed by the Configuration program or by setting the + <filename>GraphicalTheme</filename> configuration key. </para> <para> - The look and feel of this greeter is really controlled by the theme and - so the user interface elements that are present may be different. The - only thing that must always be present is the text entry field as described - above in the Standard Greeter. + The look and feel of this greeter is really controlled by the theme and + so the user interface elements that are present may be different. The + only thing that must always be present is the text entry field as + described above in the Standard Greeter. </para> <para> - You can always get a menu of available actions by pressing the F10 key. - This can be useful if the theme doesn't provide certain buttons when you - really wish to do some action. + You can always get a menu of available actions by pressing the F10 key. + This can be useful if the theme doesn't provide certain buttons when + you really wish to do some action. </para> </sect2> @@ -546,85 +537,86 @@ <title>Logging</title> <para> - GDM itself will use syslog to log errors or status. It can also - log debugging information, but this is not generally useful unless - something is very wrong, and this must be enabled in the configuration - file. + GDM itself will use syslog to log errors or status. It can also log + debugging information, but this is not generally useful unless + something is very wrong, and this must be enabled in the configuration + file. </para> <para> - Output from the various X servers is stored in the GDM log directory, - which is configurable, but is usually <filename><var>/log/gdm/</filename>. - The output from the session can be found in a file called - <filename><display>.log</filename>. Four older files are - also stored with <filename>.1</filename> through - <filename>.4</filename> appended. These will be rotated as new - sessions on that display are started. You can use these logs - to view what the X server said when it started up. + Output from the various X servers is stored in the GDM log directory, + which is configurable, but is usually + <filename><var>/log/gdm/</filename>. The output from the + session can be found in a file called + <filename><display>.log</filename>. Four older files are also + stored with <filename>.1</filename> through + <filename>.4</filename> appended. These will be rotated as new + sessions on that display are started. You can use these logs to view + what the X server said when it started up. </para> <para> - The output from the user session is redirected to - <filename>~/.xsession-errors</filename> - before even the <filename>PreSession</filename> script is started. So - it is not really necessary to redirect this again in the session setup - script. As is usually done. If the user session lasted less then - 10 seconds, GDM assumes that the session crashed and allows the user to - view this file in a dialog before returning to the login screen. - This way the user can view the session errors from - the last session and correct the problem this way. + The output from the user session is redirected to + <filename>~/.xsession-errors</filename> + before even the <filename>PreSession</filename> script is started. So + it is not really necessary to redirect this again in the session setup + script. As is usually done. If the user session lasted less then + 10 seconds, GDM assumes that the session crashed and allows the user to + view this file in a dialog before returning to the login screen. + This way the user can view the session errors from the last session + and correct the problem this way. </para> <para> - You can suppress the 10 second warning by returning code 66 - from the <filename>Xsession</filename>script or from your session - binary (the default <filename>Xsession</filename> script - propagates those codes back). This is useful if you have some sort of - special logins for which it is not an error to return less then 10 - seconds later, or if you setup the session to already display some - error message and the gdm message would be confusing and redundant. + You can suppress the 10 second warning by returning code 66 from the + <filename>Xsession</filename>script or from your session binary (the + default <filename>Xsession</filename> script propagates those codes + back). This is useful if you have some sort of special logins for + which it is not an error to return less then 10 seconds later, or if + you setup the session to already display some error message and the + gdm message would be confusing and redundant. </para> <para> - The session output is piped through the GDM daemon and so the - <filename>~/.xsession-errors</filename> file is capped at about - 200 kilobytes by GDM to prevent a possible denial of service attack - on the session. An app could perhaps on reading some wrong data print out - warnings or errors on the stderr or stdout. This could perhaps - fill up the users home directory who would then have to log out and - log back in to clear this. This could be especially nasty if quotas - are set. GDM also correctly traps the XFSZ signal and stops writing - the file, which would lead to killed sessions if the file was - redirected in the old fashioned way from the script. + The session output is piped through the GDM daemon and so the + <filename>~/.xsession-errors</filename> file is capped at about + 200 kilobytes by GDM to prevent a possible denial of service attack + on the session. An app could perhaps on reading some wrong data print + out warnings or errors on the stderr or stdout. This could perhaps + fill up the users home directory who would then have to log out and + log back in to clear this. This could be especially nasty if quotas + are set. GDM also correctly traps the XFSZ signal and stops writing + the file, which would lead to killed sessions if the file was + redirected in the old fashioned way from the script. </para> <para> - Note that some distributors seem to - override the <filename>~/.xsession-errors</filename> redirection and - do it themselves in their own Xsession script (set by the - <filename>BaseXsession</filename> configuration key) which means that - GDM will not be able to trap the output and cap this file. You also - lose output from the <filename>PreSession</filename> script which can - make debugging things harder to figure out as perhaps useful output - of what is wrong will not be printed out. See the description of the - <filename>BaseXsession</filename> configuration key for more - information, especially on how to handle multiple display managers - using the same script. + Note that some distributors seem to override the + <filename>~/.xsession-errors</filename> redirection and do it + themselves in their own Xsession script (set by the + <filename>BaseXsession</filename> configuration key) which means that + GDM will not be able to trap the output and cap this file. You also + lose output from the <filename>PreSession</filename> script which can + make debugging things harder to figure out as perhaps useful output + of what is wrong will not be printed out. See the description of the + <filename>BaseXsession</filename> configuration key for more + information, especially on how to handle multiple display managers + using the same script. </para> <para> - Note that if the session is a failsafe session, or if GDM can't open - this file for some reason, then a fallback file will be created in the - <filename>/tmp</filename> directory named - <filename>/tmp/xses-<user>.XXXXXX</filename> where the - <filename>XXXXXX</filename> are some random characters. + Note that if the session is a failsafe session, or if GDM can't open + this file for some reason, then a fallback file will be created in the + <filename>/tmp</filename> directory named + <filename>/tmp/xses-<user>.XXXXXX</filename> where the + <filename>XXXXXX</filename> are some random characters. </para> <para> - If you run a system with quotas set, it would be good to delete the - <filename>~/.xsession-errors</filename> in the - <filename>PostSession</filename> script. Such that this log file - doesn't unneccesairly stay around. + If you run a system with quotas set, it would be good to delete the + <filename>~/.xsession-errors</filename> in the + <filename>PostSession</filename> script. Such that this log file + doesn't unnecessarily stay around. </para> </sect2> @@ -633,84 +625,76 @@ <title>Security and the GDM User</title> <para> - The GDM daemon normally runs as root, as does the slave. - However GDM should also have a dedicated user id and a group - id which it uses for its graphical interfaces such - as <filename>gdmgreeter</filename> and <filename>gdmlogin</filename>. - You can choose the name of this user and group in the - <filename>[daemon]</filename> section of the configuration - file. + The GDM daemon normally runs as root, as does the slave. However GDM + should also have a dedicated user id and a group id which it uses for + its graphical interfaces such as <filename>gdmgreeter</filename> and + <filename>gdmlogin</filename>. You can choose the name of this user + and group in the <filename>[daemon]</filename> section of the + configuration file. </para> <para> - The GDM user, and group, which are normally just - <filename>gdm</filename> should not be user or group of - any particular privilage. The reason for using them is - to have the user interface run as a user without privilages - so that in the unlikely case that someone finds a weakness - in the GUI, they cannot access root on the machine. + The GDM user, and group, which are normally just + <filename>gdm</filename> should not be user or group of any particular + privilage. The reason for using them is to have the user interface + run as a user without privilages so that in the unlikely case that + someone finds a weakness in the GUI, they cannot access root on the + machine. </para> <para> - It should however be noted that the GDM user and - group have some privilages that make them somewhat - dangerous. For one they have access to the server - authorization directory (the <filename>ServAuthDir</filename>), - which contains all the X server authorization files - and other private information. This means that - someone who gains the GDM user/group privilages - can then connect to any session. So you should - not, under any circumstances, make this some user/group - which may be easy to get access to, such as the - user <filename>nobody</filename>. + It should however be noted that the GDM user and group have some + privilages that make them somewhat dangerous. For one they have + access to the server authorization directory (the + <filename>ServAuthDir</filename>), which contains all the X server + authorization files and other private information. This means that + someone who gains the GDM user/group privilages can then connect to + any session. So you should not, under any circumstances, make this + some user/group which may be easy to get access to, such as the + user <filename>nobody</filename>. </para> <para> - The server authorization directory - (the <filename>ServAuthDir</filename>) is used for - a host of random internal data in addition to the - X server authorization files, and the naming is really - a relic of history. GDM daemon enforces this dirctory - to be owned by <filename>root.gdm</filename> with - the permissions of 1770. This way, only root and - the GDM group have write access to this directory, - but the GDM group cannot remove the root owned files - from this directory, such as the X server authorization - files. + The server authorization directory (the + <filename>ServAuthDir</filename>) is used for a host of random + internal data in addition to the X server authorization files, and the + naming is really a relic of history. GDM daemon enforces this + directory to be owned by <filename>root.gdm</filename> with the + permissions of 1770. This way, only root and the GDM group have write + access to this directory, but the GDM group cannot remove the root + owned files from this directory, such as the X server authorization + files. </para> <para> - GDM by default doesn't trust the server authorization - directory and treats it in the same way as the temporary - directory with respect to creating files. This way - someone breaking the GDM user cannot mount attacks by - creating links in this directory. Similarly the X server - log directory is treated safely, but that directory should - really be owned and writable only by root. + GDM by default doesn't trust the server authorization directory and + treats it in the same way as the temporary directory with respect to + creating files. This way someone breaking the GDM user cannot mount + attacks by creating links in this directory. Similarly the X server + log directory is treated safely, but that directory should really be + owned and writable only by root. </para> <para> - Anybody found not using a dedicated user for GDM - should be whacked over the head with a large, blunt, - heavy and rusty object, although the rusty requirement - may be dropped if there is not enough time to have the - object develop rust. + Anybody found not using a dedicated user for GDM should be whacked over + the head with a large, blunt, heavy and rusty object, although the + rusty requirement may be dropped if there is not enough time to have + the object develop rust. </para> </sect2> - + </sect1> <sect1 id="configuration"> <title>Configuration</title> <para> - This section will cover the configuration of GDM - and the format of the configuration file. However you - can use the <filename>gdmsetup</filename> binary to configure - GDM from a graphical environment. The configuration program - does not however let you configure every aspect of GDM however, - so if the setup program does not cover your needs - you may find information in this section. + This section will cover the configuration of GDM and the format of the + configuration file. However you can use the + <filename>gdmsetup</filename> binary to configure GDM from a graphical + environment. The configuration program does not however let you + configure every aspect of GDM however, so if the setup program does not + cover your needs you may find information in this section. </para> <para> @@ -720,18 +704,17 @@ </para> <para> - Some keys in the configuration file as shipped are commented out - while others are set. This is done so that defaults can be easily - changed in the future for some keys. If you wish to set such a key - you must first remove the leading hash mark that marks it as a - comment. + Some keys in the configuration file as shipped are commented out while + others are set. This is done so that defaults can be easily changed in + the future for some keys. If you wish to set such a key you must first + remove the leading hash mark that marks it as a comment. </para> <para> The configuration files for GDM are located in the - <filename><etc>/gdm/</filename> directory. And some which - can be shared among other display managers are - located in the <filename><etc>/dm/</filename> directory. + <filename><etc>/gdm/</filename> directory. And some which can be + shared among other display managers are located in the + <filename><etc>/dm/</filename> directory. </para> <para> @@ -739,31 +722,32 @@ </para> <screen> - Init/ - PostLogin/ - PostSession/ - PreSession/ - modules/ - gdm.conf - factory-gdm.conf - locale.alias - Xsession - XKeepsCrashing -</screen> +Init/ +PostLogin/ +PostSession/ +PreSession/ +modules/ +gdm.conf +factory-gdm.conf +locale.alias +Xsession +XKeepsCrashing + </screen> <para> <filename>gdm.conf</filename> is the main GDM configuration file. The options will be described later in this section. - <filename>factory-gdm.conf</filename> is the configuration file as shipped - with the daemon. This can be useful if you wish to revert to the default - configuration. + <filename>factory-gdm.conf</filename> is the configuration file as + shipped with the daemon. This can be useful if you wish to revert to + the default configuration. </para> <para> <filename>locale.alias</filename> is a file which looks much like the - system locale alias but in fact it is not the same. These are the languages - that are available on your system. All the languages are still tested to - see if they actually exist before presenting them to the user. + system locale alias but in fact it is not the same. These are the + languages that are available on your system. All the languages are + still tested to see if they actually exist before presenting them to the + user. </para> <para> @@ -773,15 +757,17 @@ <para> <filename>XKeepsCrashing</filename> is a script which gets run when the - X server keeps crashing and we cannot recover. The shipped default script - will work with most Linux distributions and can run the X configuration - program provided the person on the console knows the root password. + X server keeps crashing and we cannot recover. The shipped default + script will work with most Linux distributions and can run the X + configuration program provided the person on the console knows the root + password. </para> <para> - <filename>gdm.conf</filename> is configuration file for both <filename> - gdm</filename>, <filename>gdmgreeter</filename>, <filename>gdmlogin</filename>, - and <filename>gdmchooser</filename> since a lot of parameters overlap. + <filename>gdm.conf</filename> is configuration file for both + <filename>gdm</filename>, <filename>gdmgreeter</filename>, + <filename>gdmlogin</filename>, and <filename>gdmchooser</filename> + since a lot of parameters overlap. </para> <para> @@ -798,171 +784,161 @@ subdirectories of the <filename><etc>/gdm/</filename> folder or dropping <filename>.desktop</filename>-style files in <filename>/etc/X11/sessions/</filename>. The latter is also - read by KDM for common configuration. - Next the directory + read by KDM for common configuration. Next the directory <filename><share>/gdm/BuiltInSessions/</filename> is read for GDM specific built in sessions (KDM hardcodes these at time of this - writing). - Also the default setup will also read <filename><share>/xsessions/</filename> - (which should be <filename>/usr/share/xsessions/</filename> if you really - wish to cooperate with KDM) - where desktop packages can install their session files. The directories - under the <filename>/etc</filename> should be reserved for configuration. - This approach makes it easy for package management systems to install - window managers and different session types without requiring - the sysadmin to edit files. See the <filename>SessionDesktopDir</filename> - configuration key for changing the paths. - It used to be that GDM stored - its built in sessions in <filename><etc>/dm/Sessions/</filename> - but this is now deprecated as of 2.5.90.0. - Note that prior to version - 2.4.4.2 only the <filename><etc>/dm/Sessions/</filename> was being read. + writing). Also the default setup will also read + <filename><share>/xsessions/</filename> (which should be + <filename>/usr/share/xsessions/</filename> if you really wish to + cooperate with KDM) where desktop packages can install their session + files. The directories under the <filename>/etc</filename> should be + reserved for configuration. This approach makes it easy for package + management systems to install window managers and different session + types without requiring the sysadmin to edit files. See the + <filename>SessionDesktopDir</filename> configuration key for + changing the paths. It used to be that GDM stored its built in + sessions in <filename><etc>/dm/Sessions/</filename> but this is + now deprecated as of 2.5.90.0. Note that prior to version + 2.4.4.2 only the <filename><etc>/dm/Sessions/</filename> was + being read. </para> <para> A session can be disabled (if it was installed in - <filename>/usr/share/xsessions/</filename>) by adding an identically named - <filename>.desktop</filename> to one of the directories earlier in the path - (likely <filename>/etc/X11/sessions</filename>) and using <filename>Hidden=true</filename> - in that file. + <filename>/usr/share/xsessions/</filename>) by adding an identically + named <filename>.desktop</filename> to one of the directories earlier in + the path (likely <filename>/etc/X11/sessions</filename>) and using + <filename>Hidden=true</filename> in that file. </para> <sect2 id="scriptdirs"> <title>The Script Directories</title> <para> - In this section we will explain the <filename>Init</filename>, - <filename>PostLogin</filename>, - <filename>PreSession</filename> and <filename>PostSession</filename> directories as - they are very similar. + In this section we will explain the <filename>Init</filename>, + <filename>PostLogin</filename>, <filename>PreSession</filename> and + <filename>PostSession</filename> directories as they are very similar. </para> <para> - When the X server has been successfully started, GDM will try - to run the script called - <filename>Init/<displayname></filename>. I.e. <filename>Init/:0</filename> - for the first local display. If this file is not found, GDM - will attempt to to run - <filename>Init/<hostname></filename>. I.e. <filename>Init/somehost</filename>. - If this still is not found, GDM will try - <filename>Init/XDMCP</filename> for all XDMCP logins or - <filename>Init/Flexi</filename> for all on demand flexible - servers. If none of the above were found, GDM will run - <filename>Init/Default</filename>. The - script will be run as root and GDM blocks until it - terminates. Use the <filename>Init/*</filename> script for - programs that are supposed to run alongside with the GDM login - window. xconsole for instance. Commands to set the background - etc. goes in this file too. + When the X server has been successfully started, GDM will try to run + the script called <filename>Init/<displayname></filename>. I.e. + <filename>Init/:0</filename> for the first local display. If this file + is not found, GDM will attempt to to run + <filename>Init/<hostname></filename>. I.e. + <filename>Init/somehost</filename>. + If this still is not found, GDM will try + <filename>Init/XDMCP</filename> for all XDMCP logins or + <filename>Init/Flexi</filename> for all on demand flexible + servers. If none of the above were found, GDM will run + <filename>Init/Default</filename>. The script will be run as root and + GDM blocks until it terminates. Use the <filename>Init/*</filename> + script for programs that are supposed to run alongside with the GDM + login window. xconsole for instance. Commands to set the background + etc. goes in this file too. </para> <para> - It is up to the sysadmin to decide whether clients started by - the Init script should be killed before starting the user - session. This is controlled with the <filename>KillInitClients</filename> - option in <filename>gdm.conf</filename>. + It is up to the sysadmin to decide whether clients started by the Init + script should be killed before starting the user session. This is + controlled with the <filename>KillInitClients</filename> option in + <filename>gdm.conf</filename>. </para> <para> - When the user has been successfully authenticated GDM tries the - scripts in the <filename>PostLogin</filename> directory in the - same manner as for the <filename>Init</filename> directory. - This is done before any session setup is done, and so this - would be the script where you might setup the home directory - if you need to (though you should use the - <filename>pam_mount</filename> module if you can for this). - You have the <filename>$USER</filename> and <filename>$DISPLAY</filename> - environment variables set for this script, - and again it is run as root. The script should return 0 on success - as otherwise the user won't be logged in. This is not true for - failsafe session however. + When the user has been successfully authenticated GDM tries the + scripts in the <filename>PostLogin</filename> directory in the same + manner as for the <filename>Init</filename> directory. This is done + before any session setup is done, and so this would be the script where + you might setup the home directory if you need to (though you should + use the <filename>pam_mount</filename> module if you can for this). + You have the <filename>$USER</filename> and + <filename>$DISPLAY</filename> environment variables set for this + script, and again it is run as root. The script should return 0 on + success as otherwise the user won't be logged in. This is not true for + failsafe session however. </para> <para> - After the user session has been setup from the GDM side of - things, GDM will run the scripts in the <filename>PreSession</filename> - directory, again in the same manner as the <filename>Init</filename> - directory. Use this - script for local session management or accounting stuff. The - <filename>$USER</filename> environment variable contains the login of the - authenticated user and <filename>$DISPLAY</filename> is set to the current display. - The script should return 0 on success. Any - other value will cause GDM to terminate the current login - process. This is not true for failsafe sessions however. - Also <filename>$X_SERVERS</filename> environmental variable is set and this points - to a fake generated x servers file for use with the - sessreg accounting program. + After the user session has been setup from the GDM side of things, GDM + will run the scripts in the <filename>PreSession</filename> directory, + again in the same manner as the <filename>Init</filename> directory. + Use this script for local session management or accounting stuff. The + <filename>$USER</filename> environment variable contains the login of + the authenticated user and <filename>$DISPLAY</filename> is set to the + current display. The script should return 0 on success. Any other + value will cause GDM to terminate the current login process. This is + not true for failsafe sessions however. Also + <filename>$X_SERVERS</filename> environmental variable is set and this + points to a fake generated x servers file for use with the sessreg + accounting program. </para> <para> - After this the base <filename>Xsession</filename> script is - run with the selected session executable as the first argument. - This is run as the user, and really this is the user session. - The available session executables are taken from the - <filename>Exec=</filename> line in the - <filename>.desktop</filename> files in the path - specified by <filename>SessionDesktopDir</filename>. - Usually this path is - <filename>/etc/X11/sessions/:<etc>/dm/Sessions:/usr/share/xsessions/</filename>. - The first found file is used. - The user either picks from these sessions or GDM will look inside - the file <filename>~/.dmrc</filename> for the stored - preference. + After this the base <filename>Xsession</filename> script is run with + the selected session executable as the first argument. This is run as + the user, and really this is the user session. The available session + executables are taken from the <filename>Exec=</filename> line in the + <filename>.desktop</filename> files in the path specified by + <filename>SessionDesktopDir</filename>. Usually this path is + <filename>/etc/X11/sessions/:<etc>/dm/Sessions:/usr/share/xsessions/</filename>. + The first found file is used. The user either picks from these + sessions or GDM will look inside the file <filename>~/.dmrc</filename> + for the stored preference. </para> <para> - This script should really load the users profile and generally - do all the voodoo that is needed to launch a session. Since - many systems reset the language selections done by GDM, GDM - will also set the <filename>$GDM_LANG</filename> variable to the selected language. - You can use this to reset the language environmental - variables after you run the users profile. If the user - elected to use the system language, then <filename>$GDM_LANG</filename> - is not set. + This script should really load the users profile and generally do all + the voodoo that is needed to launch a session. Since many systems + reset the language selections done by GDM, GDM will also set the + <filename>$GDM_LANG</filename> variable to the selected language. You + can use this to reset the language environmental variables after you + run the users profile. If the user elected to use the system language, + then <filename>$GDM_LANG</filename> is not set. </para> <para> - When the user terminates his session, the <filename>PostSession</filename> script - will be run. Again operation is similar to <filename>Init</filename>, - <filename>PostLogin</filename> and - <filename>PreSession</filename>. - Again the script will be run with root - privileges, the slave daemon will block and the <filename>$USER</filename> - environment variable will contain the name of the user who - just logged out and <filename>$DISPLAY</filename> will be set to the display - the user used, however note that the X server for this display - may already be dead and so you shouldn't try to access it. - Also <filename>$X_SERVERS</filename> environmental variable is set and this points - to a fake generated x servers file for use with the - sessreg accounting program. + When the user terminates his session, the + <filename>PostSession</filename> script will be run. Again operation + is similar to <filename>Init</filename>, <filename>PostLogin</filename> + and <filename>PreSession</filename>. Again the script will be run with + root privileges, the slave daemon will block and the + <filename>$USER</filename> environment variable will contain the name + of the user who just logged out and <filename>$DISPLAY</filename> will + be set to the display the user used, however note that the X server for + this display may already be dead and so you shouldn't try to access it. + Also <filename>$X_SERVERS</filename> environmental variable is set and + this points to a fake generated x servers file for use with the sessreg + accounting program. </para> <para> - Note that the <filename>PostSession</filename> script will be run even when the - display fails to respond due to an I/O error or similar. Thus, - there is no guarantee that X applications will work during - script execution. + Note that the <filename>PostSession</filename> script will be run + even when the display fails to respond due to an I/O error or + similar. Thus, there is no guarantee that X applications will work + during script execution. </para> <para> - Except for the <filename>Xsession</filename> script all of these - scripts will also have the environment variable - <filename>$RUNNING_UNDER_GDM</filename> set to <filename>yes</filename>, - so that you could perhaps use similar scripts for different display managers. - The <filename>Xsession</filename> will always have the - <filename>$GDMSESSION</filename> set to the basename of the - session that the user chose to run without the <filename>.desktop</filename> - extension. In addition <filename>$DESKTOP_SESSION</filename> is also set - to the same value and in fact this will also be set by KDM in future - versions. + Except for the <filename>Xsession</filename> script all of these + scripts will also have the environment variable + <filename>$RUNNING_UNDER_GDM</filename> set to + <filename>yes</filename>, so that you could perhaps use similar + scripts for different display managers. The + <filename>Xsession</filename> will always have the + <filename>$GDMSESSION</filename> set to the basename of the + session that the user chose to run without the + <filename>.desktop</filename> extension. In addition + <filename>$DESKTOP_SESSION</filename> is also set to the same value + and in fact this will also be set by KDM in future versions. </para> <para> - Neither of the <filename>Init</filename>, <filename>PostLogin</filename>, - <filename>PreSession</filename> or <filename>PostSession</filename> scripts are - necessary and can be left out. The <filename>Xsession</filename> script - is however required as well as at least one session <filename>.desktop</filename> - file. + Neither of the <filename>Init</filename>, + <filename>PostLogin</filename>, <filename>PreSession</filename> or + <filename>PostSession</filename> scripts are necessary and can be left + out. The <filename>Xsession</filename> script is however required as + well as at least one session <filename>.desktop</filename> file. </para> </sect2> @@ -971,96 +947,94 @@ <title>The Configuration File - <filename>gdm.conf</filename></title> <para> - The daemon and the accompanying utilities share a common - configuration file: <filename><etc>/gdm/gdm.conf</filename>. + The daemon and the accompanying utilities share a common + configuration file: <filename><etc>/gdm/gdm.conf</filename>. </para> <para> - The configuration file is divided into sections each - containing variables that define the behavior for a specific - part of the GDM suite. The file is fairly well commented - as well. + The configuration file is divided into sections each containing + variables that define the behavior for a specific part of the GDM + suite. The file is fairly well commented as well. </para> <para> - <filename>gdm.conf</filename> follows the standard <filename>.ini</filename> - style configuration - file syntax. Keywords in brackets define sections, strings - before an equal sign (=) are variables and the data after - equal sign represents their value. Empty lines or lines - starting with the hash mark (#) are ignored. The - graphical configurator will try to preserve both comments - (lines with a hash mark) and the overall structure of the - file so you can intermix using the GUI or hand editting the - configuration file. + <filename>gdm.conf</filename> follows the standard + <filename>.ini</filename> style configuration file syntax. Keywords + in brackets define sections, strings before an equal sign (=) are + variables and the data after equal sign represents their value. Empty + lines or lines starting with the hash mark (#) are ignored. The + graphical configurator will try to preserve both comments (lines with + a hash mark) and the overall structure of the file so you can intermix + using the GUI or hand editing the configuration file. </para> <sect3 id="daemonsection"> - <title>Daemon Configuration</title> - - <variablelist> - <title>[daemon]</title> - - <varlistentry> - <term>AddGtkModules</term> - <listitem> - <synopsis>AddGtkModules=false</synopsis> - <para> - If true, then enables gdmgreeter/gdmlogin to be launched with - additional Gtk+ modules. This is useful when extra features are - required such as accessible login. Note that only "trusted" - modules should be used to minimize security issues. - </para> - <para> - Usually this is used for accessibility modules. The modules - which are loaded are specified with the - <filename>GtkModulesList</filename> key. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AlwaysRestartServer</term> - <listitem> - <synopsis>AlwaysRestartServer=false</synopsis> - <para> - If true, then gdm never tries to reuse existing X servers by - reinitializing them. It will just kill the existing server and - start over. Normally, just reinitializing is a nicer way to go - but if the X server memory usage keeps growing this may be - a safer option. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AutomaticLoginEnable</term> - <listitem> - <synopsis>AutomaticLoginEnable=false</synopsis> - <para> - If the user given in AutomaticLogin should be logged in upon - first bootup. No password will be asked. This is useful - for single user workstations where local console security - is not an issue. Also could be useful for public terminals, - although there see <filename>TimedLogin</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AutomaticLogin</term> - <listitem> - <synopsis>AutomaticLogin=</synopsis> - <para> - This user should be automatically logged in on first bootup. - AutomaticLoginEnable must be true and this must be - a valid user for this to happen. "root" can never be - autologged in however and gdm will just refuse to do it even - if you set it up. - </para> - - <para> - The following control chars are recognized within the specified name: + <title>Daemon Configuration</title> + + <variablelist> + <title>[daemon]</title> + + <varlistentry> + <term>AddGtkModules</term> + <listitem> + <synopsis>AddGtkModules=false</synopsis> + <para> + If true, then enables gdmgreeter/gdmlogin to be launched with + additional Gtk+ modules. This is useful when extra features + are required such as accessible login. Note that only + "trusted" modules should be used to minimize security issues. + </para> + <para> + Usually this is used for accessibility modules. The modules + which are loaded are specified with the + <filename>GtkModulesList</filename> key. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>AlwaysRestartServer</term> + <listitem> + <synopsis>AlwaysRestartServer=false</synopsis> + <para> + If true, then gdm never tries to reuse existing X servers by + reinitializing them. It will just kill the existing server and + start over. Normally, just reinitializing is a nicer way to go + but if the X server memory usage keeps growing this may be + a safer option. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>AutomaticLoginEnable</term> + <listitem> + <synopsis>AutomaticLoginEnable=false</synopsis> + <para> + If the user given in AutomaticLogin should be logged in upon + first bootup. No password will be asked. This is useful + for single user workstations where local console security + is not an issue. Also could be useful for public terminals, + although there see <filename>TimedLogin</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>AutomaticLogin</term> + <listitem> + <synopsis>AutomaticLogin=</synopsis> + <para> + This user should be automatically logged in on first bootup. + AutomaticLoginEnable must be true and this must be + a valid user for this to happen. "root" can never be + autologged in however and gdm will just refuse to do it even + if you set it up. + </para> + + <para> + The following control chars are recognized within the + specified name: </para> <para> @@ -1076,1979 +1050,1978 @@ </para> <para> - Alternatively, the name may end with a vertical bar |, the pipe symbol. - The name is then used as a program to execute which returns the desired - username on standard output. If an empty or otherwise invalid username - is returned, automatic login is not performed. This feature is typically - used when several remote displays are used as internet kiosks, with a + Alternatively, the name may end with a vertical bar |, the + pipe symbol. The name is then used as a program to execute + which returns the desired username on standard output. If an + empty or otherwise invalid username is returned, automatic + login is not performed. This feature is typically used when + several remote displays are used as internet kiosks, with a specific user to automatically login for each display. </para> </listitem> </varlistentry> - <varlistentry> - <term>BaseXsession</term> - <listitem> - <synopsis>BaseXsession=<etc>/gdm/Xsession</synopsis> - <para> - This is the base X session file. When a user logs in, this script - will be run with the selected session as the first argument. The - selected session will be the <filename>Exec=</filename> from - the <filename>.desktop</filename> file of the session. - </para> - - <para> - If you wish to use the same script for several different display - managers, and wish to have some of the script run only for GDM, then - you can check the presence of the <filename>GDMSESSION</filename> - environmental variable. This will always be set to the basename of - <filename>.desktop</filename> (without the extension) file that is - being used for this - session, and will only be set for GDM sessions. Previously some - scripts were checking for <filename>GDM_LANG</filename>, but that - is only set when the user picks a non-system default language. - </para> - - <para> - This script should take care of doing the "login" for the user - and so it should source the <filename>/etc/profile</filename> - and friends. The standard script shipped with GDM sources - the files in this order: <filename>/etc/profile</filename> - then <filename>~/.profile</filename> then - <filename>/etc/xprofile</filename> and finally - <filename>~/.xprofile</filename>. Note that different distributions - may change this however. Sometimes users personal setup will - be in <filename>~/.bash_profile</filename>, however broken - that is. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Chooser</term> - <listitem> - <synopsis>Chooser=<bin>/gdmchooser</synopsis> - <para> - Full path and name of the chooser executable followed by optional arguments. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Configurator</term> - <listitem> - <synopsis>Configurator=<bin>/gdmsetup --disable-sound --disable-crash-dialog</synopsis> - <para> - The pathname to the configurator binary. If the greeter - <filename>ConfigAvailable</filename> option is set to true then run this binary - when somebody chooses Configuration from the Actions menu. - Of course GDM will first ask for root password however. - And it will never allow this to happen from a remote display. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ConsoleCannotHandle</term> - <listitem> - <synopsis>ConsoleCannotHandle=am,ar,az,bn,el,fa,gu,hi,ja,ko,ml,mr,pa,ta,zh</synopsis> - <para> - These are the languages that the console cannot handle because - of font issues. Here we mean the text console, not X. This - is only used when there are errors to report and we cannot - start X. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DefaultPath</term> - <listitem> - <synopsis>DefaultPath=/bin:/usr/bin:/usr/bin/X11:/usr/local/bin</synopsis> - <para> - Specifies the path which will be set in the user's session. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DefaultSession</term> - <listitem> - <synopsis>DefaultSession=gnome.desktop</synopsis> - <para> - The session that is used by default if the user does not have - a saved preference and has picked 'Last' from the list of - sessions. Note that 'Last' need not be displayed, see - the <filename>ShowLastSession</filename> key. - </para> - </listitem> - </varlistentry> - - - <varlistentry> - <term>DisplayInitDir</term> - <listitem> - <synopsis>DisplayInitDir=<etc>/gdm/Init</synopsis> - <para> - Directory containing the display init scripts. See the - ``The Script Directories'' section for more info. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DisplayLastLogin</term> - <listitem> - <synopsis>DisplayLastLogin=true</synopsis> - <para> - If true then the last login information is printed to the user - before being prompted for password. While this gives away some - info on what users are on a system, it on the other hand should - give the user an idea of when they logged in and if it doesn't - seem kosher to them, they can just abort the login and contact - the sysadmin (avoids running malicious startup scripts). - This was added in version 2.5.90.0. - </para> - <para> - This is for making GDM conformant to CSC-STD-002-85, although - that is purely theoretical now. Someone should read that spec - and ensure that this actually conforms (in addition to other - places in GDM). See - <filename>http://www.radium.ncsc.mil/tpep/library/rainbow/CSC-STD-002-85.html</filename> for more info. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DoubleLoginWarning</term> - <listitem> - <synopsis>DoubleLoginWarning=true</synopsis> - <para> - If true, GDM will warn the user if they are already logged in on - another virtual terminal. On systems where GDM supports checking - the X virtual terminals, GDM will let the user switch to the - previous login virtual terminal instead of logging in. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>FailsafeXServer</term> - <listitem> - <synopsis>FailsafeXServer=</synopsis> - <para> - An X command line in case we can't start the normal X server. - should probably be some sort of a script that runs an - appropriate low resolution server that will just work. - This is tried before the <filename>XKeepsCrashing</filename> script is run. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>FirstVT</term> - <listitem> - <synopsis>FirstVT=7</synopsis> - <para> - On systems where GDM supports automatic VT (virtual terminal) - allocation, this is the first vt to try. Usually standard text - logins are run on the lower vts. See also <filename>VTAllocation</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>FlexibleXServers</term> - <listitem> - <synopsis>FlexibleXServers=5</synopsis> - <para> - The maximum number of allowed flexible servers. These are - servers that can be run using the - <filename>/tmp/.gdm_socket</filename> socket - connection. This is used for both full servers and for - Xnest servers. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>FlexiReapDelayMinutes</term> - <listitem> - <synopsis>FlexiReapDelayMinutes=5</synopsis> - <para> - After how many minutes of inactivity at the login screen - should a flexi server be reaped. This is only in effect before - a user logs in. Also it does not affect the Xnest - flexiservers. To turn off this behaviour set this value to 0. - This was added in version 2.5.90.0. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Greeter</term> - <listitem> - <synopsis>Greeter=<bin>/gdmlogin</synopsis> - <para> - Full path and name of the greeter executable followed by optional arguments. - This is the greeter used for all servers except for the XDMCP remote servers. - See also <filename>RemoteGreeter</filename> - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Group</term> - <listitem> - <synopsis>Group=gdm</synopsis> - <para> - The group name under which <filename>gdmlogin</filename>, - <filename>gdmgreeter</filename>, - <filename>gdmchooser</filename> and the internal - failsafe GTK+ dialogs are run. Also see <filename>User</filename>. - This user will have access to all the X authorization files, - and perhaps to other internal GDM data and it should not - therefore be a user such as nobody, but rather a dedicated - user. The <filename>ServAuthDir</filename> is owned by this - group. The ownership and permissions of <filename>ServAuthDir</filename> - should be <filename>root.gdm</filename> and 1770. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GtkModulesList</term> - <listitem> - <synopsis>GtkModulesList=module-1:module-2:...</synopsis> - <para> - A colon separated list of Gtk+ modules that gdmgreeter/gdmlogin - will be invoked with if <filename>AddGtkModules</filename> is true. The format is the - same as the standard Gtk+ module interface. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>HaltCommand</term> - <listitem> - <synopsis>HaltCommand=/sbin/shutdown -h now</synopsis> - <para> - Full path and arguments to command to be executed when - user selects Shutdown from the Actions menu. This can be a ';' - separated list of commands to try. - If a value is missing, the shutdown command is not available. - Note that the default for this value is not empty so to - disable shutdown you must set this explicitly to an empty - value. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>KillInitClients</term> - <listitem> - <synopsis>KillInitClients=true</synopsis> - <para> - Determines whether GDM should kill X clients started by - the init scripts when the user logs in. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>LogDir</term> - <listitem> - <synopsis>LogDir=<var>/log/gdm</synopsis> - <para> - Directory containing the log files for the individual - displays. By default this is the same as the - ServAuthDir. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PidFile</term> - <listitem> - <synopsis>PidFile=<var>/run/gdm.pid</synopsis> - <para> - Name of the file containing the <filename>gdm</filename> - process id. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PostLoginScriptDir</term> - <listitem> - <synopsis>PostLoginScriptDir=<etc>/gdm/PostLogin</synopsis> - <para> - Directory containing the scripts run right after the - user logs in, but before any session setup is done. - See the ``The Script Directories'' section for more info. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PostSessionScriptDir</term> - <listitem> - <synopsis>PostSessionScriptDir=<etc>/gdm/PostSession</synopsis> - <para> - Directory containing the scripts run after the user logs - out. See the ``The Script Directories'' section for more - info. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PreSessionScriptDir</term> - <listitem> - <synopsis>PreSessionScriptDir=<etc>/gdm/PreSession</synopsis> - <para> - Directory containing the scripts run before the user - logs in. See the ``The Script Directories'' section for - more info. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RebootCommand</term> - <listitem> - <synopsis>RebootCommand=/sbin/shutdown -r now</synopsis> - <para> - Full path and optional arguments to the program to be - executed when user selects Reboot from the Actions menu. - This can be a ';' separated list of commands to try. - If missing, the reboot command is not available. - Note that the default for this value is not empty so to - disable reboot you must set this explicitly to an empty - value. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RemoteGreeter</term> - <listitem> - <synopsis>RemoteGreeter=<bin>/gdmlogin</synopsis> - <para> - Full path and name of the greeter executable followed by optional arguments. This - is used for all remote XDMCP sessions. It is useful to have the less - graphically demanding greeter here if you use the Graphical Greeter for your main - greeter. - See also the <filename>Greeter</filename> key. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RootPath</term> - <listitem> - <synopsis>RootPath=/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/local/bin</synopsis> - <para> - Specifies the path which will be set in the root's - session and the {Init,PostLogin,PreSession,PostSession} scripts - executed by GDM. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ServAuthDir</term> - <listitem> - <synopsis>ServAuthDir=<var>/gdm</synopsis> - <para> - Directory containing the X authentication files for the - individual displays. Should be owned by - <filename>root.gdm</filename> with permissions 1770, - where <filename>gdm</filename> is the GDM group as defined - by the <filename>Group</filename> option. - That is should be owned by root, with <filename>gdm</filename> group having - full write permissions and the directory should be - sticky and others should have no permission to the directory. - This way the gdm user can't remove files owned - by root in that directory, while still being able to - write its own files there. GDM will attempt to change - permissions for you when it's first run if the permissions - are not the above. - This directory is also used for other private files that - the daemon needs to store. Other users should not - have any way to get into this directory and read/change - it's contents. Anybody who can read this directory can - connect to any display on this machine. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SessionDesktopDir</term> - <listitem> - <synopsis>SessionDesktopDir=/etc/X11/sessions/:<etc>/dm/Sessions/:/usr/share/xsessions/</synopsis> - <para> - Directory containing the <filename>.desktop</filename> - files which are the available sessions on the system. - Since 2.4.4.2 this is treated like a PATH type variable - and the first file found is used. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SoundProgram</term> - <listitem> - <synopsis>SoundProgram=/usr/bin/play</synopsis> - <para> - Program to use when playing a sound. Currently used for - playing the login sound, see - the <filename>SoundOnLoginFile</filename> key. - Supported since 2.5.90.0. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>StandardXServer</term> - <listitem> - <synopsis>StandardXServer=/usr/X11R6/bin/X</synopsis> - <para> - Full path and arguments to the standard X server command. - This is used when gdm cannot find any other definition, - and it's used as the default and failsafe fallback in a - number of places. This should be able to run some sort - of X server. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SuspendCommand</term> - <listitem> - <synopsis>SuspendCommand=</synopsis> - <para> - Full path and arguments to command to be executed when - user selects Suspend from the Actions menu. If empty - there is no such menu item. - Note that the default for this value is not empty so to - disable suspend you must set this explicitly to an empty - value. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TimedLoginEnable</term> - <listitem> - <synopsis>TimedLoginEnable=false</synopsis> - <para> - If the user given in <filename>TimedLogin</filename> should be logged in after - a number of seconds (set with <filename>TimedLoginDelay</filename>) of inactivity - on the login screen. This is useful for public access - terminals or perhaps even home use. If the user uses the - keyboard or browses the menus, the timeout will be reset to - <filename>TimedLoginDelay</filename> or 30 seconds, whichever is higher. Note that - no password will be asked for this user so you should be - careful. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TimedLogin</term> - <listitem> - <synopsis>TimedLogin=</synopsis> - <para> - This is the user that should be logged in after a specified - number of seconds of inactivity. This can never be "root" - and gdm will refuse to log in root this way. - The same features as for <filename>AutomaticLogin</filename> - are supported. The same control chars and piping to a - program are supported. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TimedLoginDelay</term> - <listitem> - <synopsis>TimedLoginDelay=30</synopsis> - <para> - This is the delay before the <filename>TimedLogin</filename> user will be logged - in. It must be greater then or equal to 10. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>User</term> - <listitem> - <synopsis>User=gdm</synopsis> - <para> - The username under which <filename>gdmlogin</filename>, - <filename>gdmgreeter</filename>, - <filename>gdmchooser</filename> and the internal - failsafe GTK+ dialogs are run. Also see <filename>Group</filename>. - This user will have access to all the X authorization files, - and perhaps to other internal GDM data and it should not - therefore be a user such as nobody, but rather a dedicated - user. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>UserAuthDir</term> - <listitem> - <synopsis>UserAuthDir=</synopsis> - <para> - The directory where user's - <filename>.Xauthority</filename> file should be - saved. When nothing is specified the user's home - directory is used. This is tilde expanded so you - can set it to things like: <filename>~/authdir/</filename>. - </para> - - <para> - If you do not use the tilde expansion, then - the filename created will be random, like in - <filename>UserAuthFBDir</filename>. This way many - users can have the same authentication directory. - For example you might want to set this to - <filename>/tmp</filename> when - user has the home directory on NFS, since you really don't - want cookie files to go over the wire. The users should - really have write privilages to this directory, and this - directory should really be sticky and all that, just like - the <filename>/tmp</filename> directory. - </para> - - <para> - Normally if this is the users home directory GDM will still + <varlistentry> + <term>BaseXsession</term> + <listitem> + <synopsis>BaseXsession=<etc>/gdm/Xsession</synopsis> + <para> + This is the base X session file. When a user logs in, this + script will be run with the selected session as the first + argument. The selected session will be the + <filename>Exec=</filename> from the + <filename>.desktop</filename> file of the session. + </para> + + <para> + If you wish to use the same script for several different + display managers, and wish to have some of the script run only + for GDM, then you can check the presence of the + <filename>GDMSESSION</filename> environmental variable. This + will always be set to the basename of + <filename>.desktop</filename> (without the extension) file that + is being used for this session, and will only be set for GDM + sessions. Previously some scripts were checking for + <filename>GDM_LANG</filename>, but that is only set when the + user picks a non-system default language. + </para> + + <para> + This script should take care of doing the "login" for the user + and so it should source the <filename>/etc/profile</filename> + and friends. The standard script shipped with GDM sources + the files in this order: <filename>/etc/profile</filename> + then <filename>~/.profile</filename> then + <filename>/etc/xprofile</filename> and finally + <filename>~/.xprofile</filename>. Note that different + distributions may change this however. Sometimes users + personal setup will be in <filename>~/.bash_profile</filename>, + however broken that is. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Chooser</term> + <listitem> + <synopsis>Chooser=<bin>/gdmchooser</synopsis> + <para> + Full path and name of the chooser executable followed by + optional arguments. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Configurator</term> + <listitem> + <synopsis>Configurator=<bin>/gdmsetup --disable-sound --disable-crash-dialog</synopsis> + <para> + The pathname to the configurator binary. If the greeter + <filename>ConfigAvailable</filename> option is set to true then + run this binary when somebody chooses Configuration from the + Actions menu. Of course GDM will first ask for root password + however. And it will never allow this to happen from a remote + display. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ConsoleCannotHandle</term> + <listitem> + <synopsis>ConsoleCannotHandle=am,ar,az,bn,el,fa,gu,hi,ja,ko,ml,mr,pa,ta,zh</synopsis> + <para> + These are the languages that the console cannot handle because + of font issues. Here we mean the text console, not X. This + is only used when there are errors to report and we cannot + start X. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DefaultPath</term> + <listitem> + <synopsis>DefaultPath=/bin:/usr/bin:/usr/bin/X11:/usr/local/bin</synopsis> + <para> + Specifies the path which will be set in the user's session. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DefaultSession</term> + <listitem> + <synopsis>DefaultSession=gnome.desktop</synopsis> + <para> + The session that is used by default if the user does not have + a saved preference and has picked 'Last' from the list of + sessions. Note that 'Last' need not be displayed, see + the <filename>ShowLastSession</filename> key. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term>DisplayInitDir</term> + <listitem> + <synopsis>DisplayInitDir=<etc>/gdm/Init</synopsis> + <para> + Directory containing the display init scripts. See the + ``The Script Directories'' section for more info. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DisplayLastLogin</term> + <listitem> + <synopsis>DisplayLastLogin=true</synopsis> + <para> + If true then the last login information is printed to the user + before being prompted for password. While this gives away some + info on what users are on a system, it on the other hand should + give the user an idea of when they logged in and if it doesn't + seem kosher to them, they can just abort the login and contact + the sysadmin (avoids running malicious startup scripts). + This was added in version 2.5.90.0. + </para> + <para> + This is for making GDM conformant to CSC-STD-002-85, although + that is purely theoretical now. Someone should read that spec + and ensure that this actually conforms (in addition to other + places in GDM). See + <filename>http://www.radium.ncsc.mil/tpep/library/rainbow/CSC-STD-002-85.html</filename> + for more info. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DoubleLoginWarning</term> + <listitem> + <synopsis>DoubleLoginWarning=true</synopsis> + <para> + If true, GDM will warn the user if they are already logged in + on another virtual terminal. On systems where GDM supports + checking the X virtual terminals, GDM will let the user switch + to the previous login virtual terminal instead of logging in. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>FailsafeXServer</term> + <listitem> + <synopsis>FailsafeXServer=</synopsis> + <para> + An X command line in case we can't start the normal X server. + should probably be some sort of a script that runs an + appropriate low resolution server that will just work. + This is tried before the <filename>XKeepsCrashing</filename> + script is run. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>FirstVT</term> + <listitem> + <synopsis>FirstVT=7</synopsis> + <para> + On systems where GDM supports automatic VT (virtual terminal) + allocation, this is the first vt to try. Usually standard text + logins are run on the lower vts. See also + <filename>VTAllocation</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>FlexibleXServers</term> + <listitem> + <synopsis>FlexibleXServers=5</synopsis> + <para> + The maximum number of allowed flexible servers. These are + servers that can be run using the + <filename>/tmp/.gdm_socket</filename> socket connection. + This is used for both full servers and for Xnest servers. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>FlexiReapDelayMinutes</term> + <listitem> + <synopsis>FlexiReapDelayMinutes=5</synopsis> + <para> + After how many minutes of inactivity at the login screen + should a flexi server be reaped. This is only in effect before + a user logs in. Also it does not affect the Xnest + flexiservers. To turn off this behaviour set this value to 0. + This was added in version 2.5.90.0. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Greeter</term> + <listitem> + <synopsis>Greeter=<bin>/gdmlogin</synopsis> + <para> + Full path and name of the greeter executable followed by + optional arguments. This is the greeter used for all servers + except for the XDMCP remote servers. See also + <filename>RemoteGreeter</filename> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Group</term> + <listitem> + <synopsis>Group=gdm</synopsis> + <para> + The group name under which <filename>gdmlogin</filename>, + <filename>gdmgreeter</filename>, + <filename>gdmchooser</filename> and the internal + failsafe GTK+ dialogs are run. Also see + <filename>User</filename>. This user will have access to all + the X authorization files, and perhaps to other internal GDM + data and it should not therefore be a user such as nobody, but + rather a dedicated user. The <filename>ServAuthDir</filename> + is owned by this group. The ownership and permissions of + <filename>ServAuthDir</filename> should be + <filename>root.gdm</filename> and 1770. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GtkModulesList</term> + <listitem> + <synopsis>GtkModulesList=module-1:module-2:...</synopsis> + <para> + A colon separated list of Gtk+ modules that gdmgreeter/gdmlogin + will be invoked with if <filename>AddGtkModules</filename> is + true. The format is the same as the standard Gtk+ module + interface. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>HaltCommand</term> + <listitem> + <synopsis>HaltCommand=/sbin/shutdown -h now</synopsis> + <para> + Full path and arguments to command to be executed when user + selects Shutdown from the Actions menu. This can be a ';' + separated list of commands to try. If a value is missing, the + shutdown command is not available. Note that the default for + this value is not empty so to disable shutdown you must set + this explicitly to an empty value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>KillInitClients</term> + <listitem> + <synopsis>KillInitClients=true</synopsis> + <para> + Determines whether GDM should kill X clients started by the + init scripts when the user logs in. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>LogDir</term> + <listitem> + <synopsis>LogDir=<var>/log/gdm</synopsis> + <para> + Directory containing the log files for the individual displays. + By default this is the same as the ServAuthDir. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PidFile</term> + <listitem> + <synopsis>PidFile=<var>/run/gdm.pid</synopsis> + <para> + Name of the file containing the <filename>gdm</filename> + process id. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PostLoginScriptDir</term> + <listitem> + <synopsis>PostLoginScriptDir=<etc>/gdm/PostLogin</synopsis> + <para> + Directory containing the scripts run right after the user logs + in, but before any session setup is done. See the + ``The Script Directories'' section for more info. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PostSessionScriptDir</term> + <listitem> + <synopsis>PostSessionScriptDir=<etc>/gdm/PostSession</synopsis> + <para> + Directory containing the scripts run after the user logs out. + See the ``The Script Directories'' section for more info. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PreSessionScriptDir</term> + <listitem> + <synopsis>PreSessionScriptDir=<etc>/gdm/PreSession</synopsis> + <para> + Directory containing the scripts run before the user logs in. + See the ``The Script Directories'' section for more info. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RebootCommand</term> + <listitem> + <synopsis>RebootCommand=/sbin/shutdown -r now</synopsis> + <para> + Full path and optional arguments to the program to be + executed when user selects Reboot from the Actions menu. This + can be a ';' separated list of commands to try. If missing, + the reboot command is not available. Note that the default for + this value is not empty so to disable reboot you must set this + explicitly to an empty value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RemoteGreeter</term> + <listitem> + <synopsis>RemoteGreeter=<bin>/gdmlogin</synopsis> + <para> + Full path and name of the greeter executable followed by + optional arguments. This is used for all remote XDMCP + sessions. It is useful to have the less graphically demanding + greeter here if you use the Graphical Greeter for your main + greeter. See also the <filename>Greeter</filename> key. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RootPath</term> + <listitem> + <synopsis>RootPath=/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/local/bin</synopsis> + <para> + Specifies the path which will be set in the root's + session and the {Init,PostLogin,PreSession,PostSession} scripts + executed by GDM. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ServAuthDir</term> + <listitem> + <synopsis>ServAuthDir=<var>/gdm</synopsis> + <para> + Directory containing the X authentication files for the + individual displays. Should be owned by + <filename>root.gdm</filename> with permissions 1770, where + <filename>gdm</filename> is the GDM group as defined by the + <filename>Group</filename> option. That is should be owned by + root, with <filename>gdm</filename> group having full write + permissions and the directory should be sticky and others + should have no permission to the directory. This way the gdm + user can't remove files owned by root in that directory, while + still being able to write its own files there. GDM will + attempt to change permissions for you when it's first run if + the permissions are not the above. This directory is also used + for other private files that the daemon needs to store. Other + users should not have any way to get into this directory and + read/change it's contents. Anybody who can read this directory + can connect to any display on this machine. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SessionDesktopDir</term> + <listitem> + <synopsis>SessionDesktopDir=/etc/X11/sessions/:<etc>/dm/Sessions/:/usr/share/xsessions/</synopsis> + <para> + Directory containing the <filename>.desktop</filename> files + which are the available sessions on the system. Since 2.4.4.2 + this is treated like a PATH type variable and the first file + found is used. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SoundProgram</term> + <listitem> + <synopsis>SoundProgram=/usr/bin/play</synopsis> + <para> + Program to use when playing a sound. Currently used for + playing the login sound, see the + <filename>SoundOnLoginFile</filename> key. Supported since + 2.5.90.0. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>StandardXServer</term> + <listitem> + <synopsis>StandardXServer=/usr/X11R6/bin/X</synopsis> + <para> + Full path and arguments to the standard X server command. + This is used when gdm cannot find any other definition, + and it's used as the default and failsafe fallback in a + number of places. This should be able to run some sort + of X server. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SuspendCommand</term> + <listitem> + <synopsis>SuspendCommand=</synopsis> + <para> + Full path and arguments to command to be executed when + user selects Suspend from the Actions menu. If empty + there is no such menu item. Note that the default for this + value is not empty so to disable suspend you must set this + explicitly to an empty value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>TimedLoginEnable</term> + <listitem> + <synopsis>TimedLoginEnable=false</synopsis> + <para> + If the user given in <filename>TimedLogin</filename> should be + logged in after a number of seconds (set with + <filename>TimedLoginDelay</filename>) of inactivity on the + login screen. This is useful for public access terminals or + perhaps even home use. If the user uses the keyboard or + browses the menus, the timeout will be reset to + <filename>TimedLoginDelay</filename> or 30 seconds, whichever + is higher. Note that no password will be asked for this user + so you should be careful. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>TimedLogin</term> + <listitem> + <synopsis>TimedLogin=</synopsis> + <para> + This is the user that should be logged in after a specified + number of seconds of inactivity. This can never be "root" + and gdm will refuse to log in root this way. + The same features as for <filename>AutomaticLogin</filename> + are supported. The same control chars and piping to a + program are supported. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>TimedLoginDelay</term> + <listitem> + <synopsis>TimedLoginDelay=30</synopsis> + <para> + This is the delay before the <filename>TimedLogin</filename> + user will be logged in. It must be greater then or equal to 10. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>User</term> + <listitem> + <synopsis>User=gdm</synopsis> + <para> + The username under which <filename>gdmlogin</filename>, + <filename>gdmgreeter</filename>, + <filename>gdmchooser</filename> and the internal + failsafe GTK+ dialogs are run. Also see + <filename>Group</filename>. This user will have access to all + the X authorization files, and perhaps to other internal GDM + data and it should not therefore be a user such as nobody, but + rather a dedicated user. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UserAuthDir</term> + <listitem> + <synopsis>UserAuthDir=</synopsis> + <para> + The directory where user's <filename>.Xauthority</filename> + file should be saved. When nothing is specified the user's + home directory is used. This is tilde expanded so you + can set it to things like: <filename>~/authdir/</filename>. + </para> + + <para> + If you do not use the tilde expansion, then the filename + created will be random, like in + <filename>UserAuthFBDir</filename>. This way many users can + have the same authentication directory. For example you might + want to set this to <filename>/tmp</filename> when user has the + home directory on NFS, since you really don't want cookie files + to go over the wire. The users should really have write + privilages to this directory, and this directory should really + be sticky and all that, just like the <filename>/tmp</filename> + directory. + </para> + + <para> + Normally if this is the users home directory GDM will still refuse to put cookies there if it thinks it is NFS (by testing - root-squashing). - This can be changed by setting <filename>NeverPlaceCookiesOnNFS</filename> - in the <filename>[security]</filename> section to false. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>UserAuthFBDir</term> - <listitem> - <synopsis>UserAuthFBDir=/tmp</synopsis> - <para> - If GDM fails to update the user's - <filename>.Xauthority</filename> file a - fallback cookie is created in this directory. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>UserAuthFile</term> - <listitem> - <synopsis>UserAuthFile=.Xauthority</synopsis> - <para> - Name of the file used for storing user cookies. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>VTAllocation</term> - <listitem> - <synopsis>VTAllocation=true</synopsis> - <para> - On systems where GDM supports automatic VT (virtual terminal) - allocation (currently Linux and FreeBSD only), - you can have GDM automatically append the vt argument - to the X server executable. This way races that come up from - each X - server managing it's own vt allocation can be avoided. - See also <filename>FirstVT</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>XKeepsCrashing</term> - <listitem> - <synopsis>XKeepsCrashing=<etc>/gdm/XKeepsCrashing</synopsis> - <para> - A script to run in case X keeps crashing. This is for running - An X configuration or whatever else to make the X configuration - work. See the script that came with the distribution for an - example. The distributed <filename>XKeepsCrashing</filename> script is tested - on Red Hat, but may work elsewhere. Your system integrator should - make sure this script is up to date for your particular system. - </para> - <para> - In case <filename>FailsafeXServer</filename> is setup, that will be tried first. - and this only used as a backup if even that server keeps - crashing. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Xnest</term> - <listitem> - <synopsis>Xnest=/usr/bin/X11/Xnest</synopsis> - <para> - The full path and arguments to the Xnest command. This is used - for the flexible Xnest servers. This way the user can start new - login screens in a nested window. Of course you must have the Xnest - server from your X server packages installed for this to work. - </para> - </listitem> - </varlistentry> - </variablelist> - + root-squashing). This can be changed by setting + <filename>NeverPlaceCookiesOnNFS</filename> in the + <filename>[security]</filename> section to false. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UserAuthFBDir</term> + <listitem> + <synopsis>UserAuthFBDir=/tmp</synopsis> + <para> + If GDM fails to update the user's + <filename>.Xauthority</filename> file a fallback cookie is + created in this directory. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UserAuthFile</term> + <listitem> + <synopsis>UserAuthFile=.Xauthority</synopsis> + <para> + Name of the file used for storing user cookies. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>VTAllocation</term> + <listitem> + <synopsis>VTAllocation=true</synopsis> + <para> + On systems where GDM supports automatic VT (virtual terminal) + allocation (currently Linux and FreeBSD only), you can have + GDM automatically append the vt argument to the X server + executable. This way races that come up from each X server + managing it's own vt allocation can be avoided. See also + <filename>FirstVT</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>XKeepsCrashing</term> + <listitem> + <synopsis>XKeepsCrashing=<etc>/gdm/XKeepsCrashing</synopsis> + <para> + A script to run in case X keeps crashing. This is for running + An X configuration or whatever else to make the X configuration + work. See the script that came with the distribution for an + example. The distributed <filename>XKeepsCrashing</filename> + script is tested on Red Hat, but may work elsewhere. Your + system integrator should make sure this script is up to date + for your particular system. + </para> + <para> + In case <filename>FailsafeXServer</filename> is setup, that + will be tried first. and this only used as a backup if even + that server keeps crashing. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Xnest</term> + <listitem> + <synopsis>Xnest=/usr/bin/X11/Xnest</synopsis> + <para> + The full path and arguments to the Xnest command. This is used + for the flexible Xnest servers. This way the user can start + new login screens in a nested window. Of course you must have + the Xnest server from your X server packages installed for this + to work. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect3> <sect3 id="securitysection"> - <title>Security Options</title> - - <variablelist> - <title>[security]</title> - - <varlistentry> - <term>AllowRoot</term> - <listitem> - <synopsis>AllowRoot=true</synopsis> - <para> - Allow root (privileged user) to log in through GDM. Set - this to false if you want to disallow such logins. - </para> - <para> - On systems that support PAM, this parameter is - not as useful as you can use PAM to do the same thing, - and in fact do even more. However it is still followed, - so you should probably leave it true for PAM systems. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AllowRemoteRoot</term> - <listitem> - <synopsis>AllowRemoteRoot=true</synopsis> - <para> - Allow root (privileged user) to log in remotely through GDM. - Set this to false if you want to disallow such logins. Remote - logins are any logins that come in through the xdmcp. - </para> - <para> - On systems that support PAM, this parameter is - not as useful as you can use PAM to do the same thing, - and in fact do even more. However it is still followed, - so you should probably leave it true for PAM systems. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>AllowRemoteAutoLogin</term> - <listitem> - <synopsis>AllowRemoteAutoLogin=false</synopsis> - <para> - Allow the timed login to work remotely. That is, remote - connections through XDMCP will be allowed to log into the - "TimedLogin" user by letting the login window time out, just - like the local user on the first console. - </para> - <para> - Note that this can make a system quite insecure, and thus is - off by default. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>CheckDirOwner</term> - <listitem> - <synopsis>CheckDirOwner=true</synopsis> - <para> - By default GDM checks the ownership of the home directories - before writing to them, this prevents security issues in case - of bad setup. However in some instances home directories will - be owned by a different user and in this case it is necessary - to turn this option on. You will also most likely have to - turn the <filename>RelaxPermissions</filename> key to at least - value 1 since in such a scenario home directories are likely - to be group writable. Supported since 2.6.0.4. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DisallowTCP</term> - <listitem> - <synopsis>DisallowTCP=true</synopsis> - <para> - If true, then always append <filename>-nolisten tcp</filename> - to the command line - of local X servers, thus disallowing TCP connection. This is - useful if you do not care for allowing remote connections, since - the X protocol could really be potentially a security hazard to - leave open, even though no known security problems exist. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>NeverPlaceCookiesOnNFS</term> - <listitem> - <synopsis>NeverPlaceCookiesOnNFS=true</synopsis> - <para> - Normally if this is true (which is by default), GDM will not place - cookies into the users home directory if this directory is on NFS. - Well, GDM will consider any filesystem with root-squashing an NFS - filesystem. Sometimes however the remote file system can have - root squashing and be safe (perhaps by using encryption). In this - case set this to 'false'. Note that this option appeared in - version 2.4.4.4 and is ignored in previous versions. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RelaxPermissions</term> - <listitem> - <synopsis>RelaxPermissions=0</synopsis> - <para> - By default GDM ignores files and directories writable to - other users than the owner. - </para> - - <para> - Changing the value of RelaxPermissions makes it - possible to alter this behavior: - </para> - - <para> - 0 - Paranoia option. Only accepts user owned files and directories. - </para> - <para> - 1 - Allow group writable files and directories. - </para> - <para> - 2 - Allow world writable files and directories. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RetryDelay</term> - <listitem> - <synopsis>RetryDelay=1</synopsis> - <para> - The number of seconds GDM should wait before - reactivating the entry field after a failed login. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>UserMaxFile</term> - <listitem> - <synopsis>UserMaxFile=65536</synopsis> - <para> - GDM will refuse to read/write files bigger than this number - (specified in bytes). - </para> - - <para> - In addition to the size check GDM is extremely picky - about accessing files in user directories. It will not - follow symlinks and can optionally refuse to - read files and directories writable by other than the - owner. See the <filename>RelaxPermissions</filename> - option for more info. - </para> - </listitem> - </varlistentry> - </variablelist> - + <title>Security Options</title> + + <variablelist> + <title>[security]</title> + + <varlistentry> + <term>AllowRoot</term> + <listitem> + <synopsis>AllowRoot=true</synopsis> + <para> + Allow root (privileged user) to log in through GDM. Set this + to false if you want to disallow such logins. + </para> + <para> + On systems that support PAM, this parameter is not as useful + as you can use PAM to do the same thing, and in fact do even + more. However it is still followed, so you should probably + leave it true for PAM systems. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>AllowRemoteRoot</term> + <listitem> + <synopsis>AllowRemoteRoot=true</synopsis> + <para> + Allow root (privileged user) to log in remotely through GDM. + Set this to false if you want to disallow such logins. Remote + logins are any logins that come in through the xdmcp. + </para> + <para> + On systems that support PAM, this parameter is not as useful + as you can use PAM to do the same thing, and in fact do even + more. However it is still followed, so you should probably + leave it true for PAM systems. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>AllowRemoteAutoLogin</term> + <listitem> + <synopsis>AllowRemoteAutoLogin=false</synopsis> + <para> + Allow the timed login to work remotely. That is, remote + connections through XDMCP will be allowed to log into the + "TimedLogin" user by letting the login window time out, just + like the local user on the first console. + </para> + <para> + Note that this can make a system quite insecure, and thus is + off by default. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>CheckDirOwner</term> + <listitem> + <synopsis>CheckDirOwner=true</synopsis> + <para> + By default GDM checks the ownership of the home directories + before writing to them, this prevents security issues in case + of bad setup. However in some instances home directories will + be owned by a different user and in this case it is necessary + to turn this option on. You will also most likely have to + turn the <filename>RelaxPermissions</filename> key to at least + value 1 since in such a scenario home directories are likely + to be group writable. Supported since 2.6.0.4. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DisallowTCP</term> + <listitem> + <synopsis>DisallowTCP=true</synopsis> + <para> + If true, then always append <filename>-nolisten tcp</filename> + to the command line + of local X servers, thus disallowing TCP connection. This is + useful if you do not care for allowing remote connections, + since the X protocol could really be potentially a security + hazard to leave open, even though no known security problems + exist. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>NeverPlaceCookiesOnNFS</term> + <listitem> + <synopsis>NeverPlaceCookiesOnNFS=true</synopsis> + <para> + Normally if this is true (which is by default), GDM will not + place cookies into the users home directory if this directory + is on NFS. Well, GDM will consider any filesystem with + root-squashing an NFS filesystem. Sometimes however the remote + file system can have root squashing and be safe (perhaps by + using encryption). In this case set this to 'false'. Note + that this option appeared in version 2.4.4.4 and is ignored in + previous versions. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RelaxPermissions</term> + <listitem> + <synopsis>RelaxPermissions=0</synopsis> + <para> + By default GDM ignores files and directories writable to + other users than the owner. + </para> + + <para> + Changing the value of RelaxPermissions makes it possible to + alter this behavior: + </para> + + <para> + 0 - Paranoia option. Only accepts user owned files and + directories. + </para> + <para> + 1 - Allow group writable files and directories. + </para> + <para> + 2 - Allow world writable files and directories. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RetryDelay</term> + <listitem> + <synopsis>RetryDelay=1</synopsis> + <para> + The number of seconds GDM should wait before reactivating the + entry field after a failed login. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UserMaxFile</term> + <listitem> + <synopsis>UserMaxFile=65536</synopsis> + <para> + GDM will refuse to read/write files bigger than this number + (specified in bytes). + </para> + + <para> + In addition to the size check GDM is extremely picky about + accessing files in user directories. It will not follow + symlinks and can optionally refuse to read files and + directories writable by other than the owner. See the + <filename>RelaxPermissions</filename> option for more info. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect3> <sect3 id="xdmcpsection"> - <title>XDCMP Support</title> - - <variablelist> - <title>[xdmcp]</title> - - <varlistentry> - <term>DisplaysPerHost</term> - <listitem> - <synopsis>DisplaysPerHost=1</synopsis> - <para> - To prevent attackers from filling up the pending - queue, GDM will only allow one connection for each - remote machine. If you want to provide display - services to machines with more than one screen, you - should increase the <filename>DisplaysPerHost</filename> - value accordingly. - </para> - - <para> - Note that the number of connections from the local - machine is unlimited. Only remote connections - are limited by this number. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Enable</term> - <listitem> - <synopsis>Enable=false</synopsis> - <para> - Setting this to true enables XDMCP support allowing remote displays/X - terminals to be managed by GDM. - </para> - - <para> - <filename>gdm</filename> listens for requests on UDP - port 177. See the Port option for more information. - </para> - - <para> - If GDM is compiled to support it, access from remote displays - can be controlled using the TCP Wrappers library. The service name is - <filename>gdm</filename> - </para> - - <para> - You should add - <screen> - gdm: .my.domain -</screen> - to your <filename>/etc/hosts.allow</filename>, depending on your - TCP Wrappers configuration. See the - <ulink type="help" url="man:hosts.allow">hosts.allow(5)</ulink> man page for details. - </para> - - <para> - Please note that XDMCP is not a particularly secure protocol - and that it is a good idea to block UDP port 177 on your - firewall unless you really need it. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>HonorIndirect</term> - <listitem> - <synopsis>HonorIndirect=true</synopsis> - <para> - Enables XDMCP INDIRECT choosing (i.e. remote execution - of <filename>gdmchooser</filename>) for X-terminals - which don't supply their own display browser. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxPending</term> - <listitem> - <synopsis>MaxPending=4</synopsis> - <para> - To avoid denial of service attacks, GDM has fixed size - queue of pending connections. Only MaxPending displays - can start at the same time. - </para> - - <para> - Please note that this parameter does *not* limit the - number of remote displays which can be managed. It only - limits the number of displays initiating a connection - simultaneously. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxPendingIndirect</term> - <listitem> - <synopsis>MaxPendingIndirect=4</synopsis> - <para> - GDM will only provide <filename>MaxPendingIndirect</filename> - displays with host choosers simultaneously. If more queries - from different hosts come in, the oldest ones will be forgotten. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxSessions</term> - <listitem> - <synopsis>MaxSessions=16</synopsis> - <para> - Determines the maximum number of remote display - connections which will be managed - simultaneously. I.e. the total number of remote displays - that can use your host. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxWait</term> - <listitem> - <synopsis>MaxWait=30</synopsis> - <para> - When GDM is ready to manage a display an ACCEPT packet - is sent to it containing a unique session id which will - be used in future XDMCP conversations. - </para> - - <para> - GDM will then place the session id in the pending queue - waiting for the display to respond with a MANAGE request. - </para> - - <para> - If no response is received within MaxWait seconds, GDM - will declare the display dead and erase it from the pending - queue freeing up the slot for other displays. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxWaitIndirect</term> - <listitem> - <synopsis>MaxWaitIndirect=30</synopsis> - <para> - The MaxWaitIndirect parameter determines the maximum - number of seconds between the time where a user chooses - a host and the subsequent indirect query where the user is - connected to the host. When the timeout is exceeded, the - information about the chosen host is forgotten and the indirect - slot freed up for other displays. The information may be - forgotten earlier if there are more hosts trying to - send indirect queries then <filename>MaxPendingIndirect</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Port</term> - <listitem> - <synopsis>Port=177</synopsis> - <para> - The UDP port number <filename>gdm</filename> should - listen to for XDMCP requests. Don't change this unless - you know what you're doing. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PingIntervalSeconds</term> - <listitem> - <synopsis>PingIntervalSeconds=15</synopsis> - <para> - Interval in which to ping the X server in seconds. If the - X server doesn't return before the next time we ping it, - the connection is stopped and the session ended. This is - a combination of the XDM PingInterval and PingTimeout, - but in seconds. - </para> - - <para> - Note that GDM in the past used to have a <filename>PingInterval</filename> - configuration key which was also in minutes. For most purposes - you'd want this setting to be lower then one minute however since - in most cases where XDMCP would be used (such as terminal labs), - a lag of more then 15 or so seconds would really mean that the - terminal was turned off or rebooted and you would want to end - the session. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Willing</term> - <listitem> - <synopsis>Willing=<etc>/gdm/Xwilling</synopsis> - <para> - When the server sends a WILLING packet back after a QUERY - it sends a string that gives the current status of this - server. The default message is the system ID, but it is - possible to create a script that displays customized - message. If this script doesn't exist or this key is - empty the default message is sent. If this script succeeds - and produces some output, the first line of it's output - is sent (and only the first line). It runs at most once - every 3 seconds to prevent possible denial of service - by flooding the server with QUERY packets. - </para> - </listitem> - </varlistentry> - </variablelist> - + <title>XDCMP Support</title> + + <variablelist> + <title>[xdmcp]</title> + + <varlistentry> + <term>DisplaysPerHost</term> + <listitem> + <synopsis>DisplaysPerHost=1</synopsis> + <para> + To prevent attackers from filling up the pending queue, GDM + will only allow one connection for each remote machine. If + you want to provide display services to machines with more + than one screen, you should increase the + <filename>DisplaysPerHost</filename> value accordingly. + </para> + + <para> + Note that the number of connections from the local machine is + unlimited. Only remote connections are limited by this number. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Enable</term> + <listitem> + <synopsis>Enable=false</synopsis> + <para> + Setting this to true enables XDMCP support allowing remote + displays/X terminals to be managed by GDM. + </para> + + <para> + <filename>gdm</filename> listens for requests on UDP port 177. + See the Port option for more information. + </para> + + <para> + If GDM is compiled to support it, access from remote displays + can be controlled using the TCP Wrappers library. The service + name is <filename>gdm</filename> + </para> + + <para> + You should add + <screen>gdm:.my.domain</screen> + to your <filename>/etc/hosts.allow</filename>, depending on your + TCP Wrappers configuration. See the + <ulink type="help" url="man:hosts.allow">hosts.allow(5)</ulink> + man page for details. + </para> + + <para> + Please note that XDMCP is not a particularly secure protocol + and that it is a good idea to block UDP port 177 on your + firewall unless you really need it. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>HonorIndirect</term> + <listitem> + <synopsis>HonorIndirect=true</synopsis> + <para> + Enables XDMCP INDIRECT choosing (i.e. remote execution of + <filename>gdmchooser</filename>) for X-terminals which don't + supply their own display browser. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxPending</term> + <listitem> + <synopsis>MaxPending=4</synopsis> + <para> + To avoid denial of service attacks, GDM has fixed size queue + of pending connections. Only MaxPending displays can start at + the same time. + </para> + + <para> + Please note that this parameter does *not* limit the number of + remote displays which can be managed. It only limits the number + of displays initiating a connection simultaneously. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxPendingIndirect</term> + <listitem> + <synopsis>MaxPendingIndirect=4</synopsis> + <para> + GDM will only provide <filename>MaxPendingIndirect</filename> + displays with host choosers simultaneously. If more queries + from different hosts come in, the oldest ones will be + forgotten. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxSessions</term> + <listitem> + <synopsis>MaxSessions=16</synopsis> + <para> + Determines the maximum number of remote display connections + which will be managed simultaneously. I.e. the total number of + remote displays that can use your host. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxWait</term> + <listitem> + <synopsis>MaxWait=30</synopsis> + <para> + When GDM is ready to manage a display an ACCEPT packet is sent + to it containing a unique session id which will be used in + future XDMCP conversations. + </para> + + <para> + GDM will then place the session id in the pending queue + waiting for the display to respond with a MANAGE request. + </para> + + <para> + If no response is received within MaxWait seconds, GDM will + declare the display dead and erase it from the pending queue + freeing up the slot for other displays. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxWaitIndirect</term> + <listitem> + <synopsis>MaxWaitIndirect=30</synopsis> + <para> + The MaxWaitIndirect parameter determines the maximum number of + seconds between the time where a user chooses a host and the + subsequent indirect query where the user is connected to the + host. When the timeout is exceeded, the information about the + chosen host is forgotten and the indirect slot freed up for + other displays. The information may be forgotten earlier if + there are more hosts trying to send indirect queries then + <filename>MaxPendingIndirect</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Port</term> + <listitem> + <synopsis>Port=177</synopsis> + <para> + The UDP port number <filename>gdm</filename> should listen to + for XDMCP requests. Don't change this unless you know what + you are doing. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PingIntervalSeconds</term> + <listitem> + <synopsis>PingIntervalSeconds=15</synopsis> + <para> + Interval in which to ping the X server in seconds. If the X + server doesn't return before the next time we ping it, the + connection is stopped and the session ended. This is a + combination of the XDM PingInterval and PingTimeout, but in + seconds. + </para> + + <para> + Note that GDM in the past used to have a + <filename>PingInterval</filename> configuration key which was + also in minutes. For most purposes you'd want this setting + to be lower then one minute however since in most cases where + XDMCP would be used (such as terminal labs), a lag of more + than 15 or so seconds would really mean that the terminal was + turned off or rebooted and you would want to end the session. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Willing</term> + <listitem> + <synopsis>Willing=<etc>/gdm/Xwilling</synopsis> + <para> + When the server sends a WILLING packet back after a QUERY it + sends a string that gives the current status of this server. + The default message is the system ID, but it is possible to + create a script that displays customized message. If this + script doesn't exist or this key is empty the default message + is sent. If this script succeeds and produces some output, + the first line of it's output is sent (and only the first + line). It runs at most once every 3 seconds to prevent + possible denial of service by flooding the server with QUERY + packets. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect3> <sect3 id="commonguioptions"> - <title>Common GUI Configuration Options</title> - - <variablelist> - <title>[gui]</title> - - <varlistentry> - <term>AllowGtkThemeChange</term> - <listitem> - <synopsis>AllowGtkThemeChange=true</synopsis> - <para> - If to allow changing the GTK+ (widget) theme from the greeter. - Currently this only affects the standard greeter as the - graphical greeter does not yet have this ability. - The theme will stay in effect on this display until changed - and will affect all the other windows that are put up by GDM. - Supported since 2.5.90.2. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GtkRC</term> - <listitem> - <synopsis>GtkRC=</synopsis> - <para> - Path to a <filename>gtkrc</filename> to read when GDM - puts up a window. You should really now use the - <filename>GtkTheme</filename> key for just setting a - theme. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GtkTheme</term> - <listitem> - <synopsis>GtkTheme=Default</synopsis> - <para> - A name of an installed theme to use by default. - It will be used in the greeter, chooser and all other GUI - windows put up by GDM. - Supported since 2.5.90.2. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GtkThemesToAllow</term> - <listitem> - <synopsis>GtkThemesToAllow=all</synopsis> - <para> - Comma separated list of themes to allow. These must be the names - of the themes installed in the standard locations for gtk themes. - You can also specify 'all' to allow all installed themes. - This is related to the <filename>AllowGtkThemeChange</filename> - key. - Supported since 2.5.90.2. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxIconWidth</term> - <listitem> - <synopsis>MaxIconWidth=128</synopsis> - <para> - Specifies the maximum icon width (in pixels) that the - face browser will display. Icons larger than this will - be scaled. This also affects icons in the XDMCP chooser. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MaxIconHeight</term> - <listitem> - <synopsis>MaxIconHeight=128</synopsis> - <para> - Specifies the maximum icon height (in pixels) that the - face browser will display. Icons larger than this will - be scaled. This also affects icons in the XDMCP chooser. - </para> - </listitem> - </varlistentry> - </variablelist> - + <title>Common GUI Configuration Options</title> + + <variablelist> + <title>[gui]</title> + + <varlistentry> + <term>AllowGtkThemeChange</term> + <listitem> + <synopsis>AllowGtkThemeChange=true</synopsis> + <para> + If to allow changing the GTK+ (widget) theme from the greeter. + Currently this only affects the standard greeter as the + graphical greeter does not yet have this ability. + The theme will stay in effect on this display until changed + and will affect all the other windows that are put up by GDM. + Supported since 2.5.90.2. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GtkRC</term> + <listitem> + <synopsis>GtkRC=</synopsis> + <para> + Path to a <filename>gtkrc</filename> to read when GDM puts up + a window. You should really now use the + <filename>GtkTheme</filename> key for just setting a theme. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GtkTheme</term> + <listitem> + <synopsis>GtkTheme=Default</synopsis> + <para> + A name of an installed theme to use by default. It will be + used in the greeter, chooser and all other GUI windows put up + by GDM. Supported since 2.5.90.2. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GtkThemesToAllow</term> + <listitem> + <synopsis>GtkThemesToAllow=all</synopsis> + <para> + Comma separated list of themes to allow. These must be the + names of the themes installed in the standard locations for + gtk themes. You can also specify 'all' to allow all installed + themes. This is related to the + <filename>AllowGtkThemeChange</filename> key. Supported since + 2.5.90.2. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxIconWidth</term> + <listitem> + <synopsis>MaxIconWidth=128</synopsis> + <para> + Specifies the maximum icon width (in pixels) that the face + browser will display. Icons larger than this will be scaled. + This also affects icons in the XDMCP chooser. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MaxIconHeight</term> + <listitem> + <synopsis>MaxIconHeight=128</synopsis> + <para> + Specifies the maximum icon height (in pixels) that the face + browser will display. Icons larger than this will be scaled. + This also affects icons in the XDMCP chooser. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect3> - + <sect3 id="greetersection"> - <title>Greeter Configuration</title> - - <variablelist> - <title>[greeter]</title> - - <varlistentry> - <term>BackgroundColor</term> - <listitem> - <synopsis>BackgroundColor=#007777</synopsis> - <para> - If the BackgroundType is 2, use this color in the background - of the greeter. Also use it as the back of transparent images - set on the background and if the BackgroundRemoteOnlyColor - is set and this is a remote display. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>BackgroundImage</term> - <listitem> - <synopsis>BackgroundImage=somefile.png</synopsis> - <para> - If the BackgroundType is 1, then display this file as the - background in the greeter. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>BackgroundProgram</term> - <listitem> - <synopsis>BackgroundProgram=/usr/bin/xeyes</synopsis> - <para> - If set this program will be run in the background while + <title>Greeter Configuration</title> + + <variablelist> + <title>[greeter]</title> + + <varlistentry> + <term>BackgroundColor</term> + <listitem> + <synopsis>BackgroundColor=#007777</synopsis> + <para> + If the BackgroundType is 2, use this color in the background + of the greeter. Also use it as the back of transparent images + set on the background and if the BackgroundRemoteOnlyColor + is set and this is a remote display. + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>BackgroundImage</term> + <listitem> + <synopsis>BackgroundImage=somefile.png</synopsis> + <para> + If the BackgroundType is 1, then display this file as the + background in the greeter. This only affects the Standard + Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>BackgroundProgram</term> + <listitem> + <synopsis>BackgroundProgram=/usr/bin/xeyes</synopsis> + <para> + If set this program will be run in the background while the login window is being displayed. Note that not all - programs will run this way, since gdm does not usually have - a home directory. You could set up home directory for the - gdm user if you wish to run applications which require it. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>BackgroundRemoteOnlyColor</term> - <listitem> - <synopsis>BackgroundRemoteOnlyColor=true</synopsis> - <para> - On remote displays only set the color background. This is - to make network load lighter. The <filename>BackgroundProgram</filename> is also - not run. This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>BackgroundScaleToFit</term> - <listitem> - <synopsis>BackgroundScaleToFit=true</synopsis> - <para> - Scale background image to fit the screen. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>BackgroundType</term> - <listitem> - <synopsis>BackgroundType=2</synopsis> - <para> - The type of background to set. 0 is none, 1 is image and 2 - is color. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Browser</term> - <listitem> - <synopsis>Browser=true</synopsis> - <para> - Set to true to enable the face browser. See the ``The Standard Greeter'' - section for more information on the face browser. This option only - works for the Standard Greeter. For the Graphical Greeter, - the face browser is enabled by choosing a theme which includes a - face browser - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ChooserButton</term> - <listitem> - <synopsis>ChooserButton=true</synopsis> - <para> - If true, add a chooser button to the Actions menu that will - restart the current server with a chooser. XDMCP does not need - to be enabled on the local machine for this to work. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ConfigAvailable</term> - <listitem> - <synopsis>ConfigAvailable=true</synopsis> - <para> - Allow the configurator to be run from the greeter. Note that - the user will need to type in the root password before the - configurator is run however. See the <filename>Configurator</filename> option - in the daemon section. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DefaultFace</term> - <listitem> - <synopsis>DefaultFace=<share>/pixmaps/nophoto.png</synopsis> - <para> - Default icon file for users without a personal picture - in <filename>~/gnome/photo</filename>. The image must be - in an gdk-pixbuf supported format and the file must be - readable for the gdm user. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Exclude</term> - <listitem> - <synopsis>Exclude=bin,daemon,adm,lp,sync,shutdown,halt,mail,...</synopsis> - <para> - Comma-separated list of usernames to exclude from the - face browser. The excluded users will still be able to - log in. See also <filename>MinimalUID</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GlobalFaceDir</term> - <listitem> - <synopsis>GlobalFaceDir=<share>/faces/</synopsis> - <para> - Systemwide directory for face files. The sysadmin can - place icons for users here without touching their - homedirs. Faces are named after their users' logins. - </para> - - <para> - I.e. <filename><GlobalFaceDir>/johndoe</filename> - would contain the face icon for the user ``johndoe''. No - image format extension should be specified. - </para> - - <para> - The face images must be stored in gdk-pixbuf supported formats and - they must be readable for the GDM user. - </para> - - <para> - A user's own icon file will always take precedence over the sysadmin - provided one. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GraphicalTheme</term> - <listitem> - <synopsis>GraphicalTheme=circles</synopsis> - <para> - The graphical theme that the Graphical Greeter should use. - it should refer to a directory in the theme directory - set by <filename>GraphicalThemeDir</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>GraphicalThemeDir</term> - <listitem> - <synopsis>GraphicalThemeDir=<share>/gdm/themes/</synopsis> - <para> - The directory where themes for the Graphical Greeter are - installed. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>InfoMsgFile</term> - <listitem> - <synopsis>InfoMsgFile=/path/to/infofile</synopsis> - <para> - If present and /path/to/infofile specifies an existing and - readable text file (e.g. /etc/infomsg.txt) the contents of the - file will be displayed in a modal dialog box before the user - is allowed to login. - This works both with the standard and the themable greeters. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>InfoMsgFont</term> - <listitem> - <synopsis>InfoMsgFont=fontspec</synopsis> - <para> - If present and InfoMsgFile (see above) is used, this specifies - the font to use when displaying the contents of the InfoMsgFile - text file. For example fontspec could be Sans 24 to get a - sans serif font of size 24 points. - This works both with the standard and the themable greeters. - </para> - </listitem> - </varlistentry> - - - <varlistentry> - <term>LocaleFile</term> - <listitem> - <synopsis>LocaleFile=<etc>/gdm/locale.alias</synopsis> - <para> - File in format similar to the GNU locale format with entries - for all supported languages on the system. The format is - described above or in a comment inside that file. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>LockPosition</term> - <listitem> - <synopsis>LockPosition=true</synopsis> - <para> - If true the position of the login window of the Standard Greeter - cannot be changed even if the title bar is turned on. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Logo</term> - <listitem> - <synopsis>Logo=<share>/pixmaps/gnome-logo-large.png</synopsis> - <para> - Image file to display in the logo box. The file must be - in an gdk-pixbuf supported format and it must be readable by - the GDM user. If no file is specified the logo feature - is disabled. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MinimalUID</term> - <listitem> - <synopsis>MinimalUID=100</synopsis> - <para> - The minimal UID that gdm should consider a user. All - users with a lower UID will be excluded from the face browser. - See also <filename>Exclude</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PositionX</term> - <listitem> - <synopsis>PositionX=200</synopsis> - <para> - The horizontal position of the login window of the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>PositionY</term> - <listitem> - <synopsis>PositionY=100</synopsis> - <para> - The vertical position of the login window of the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Quiver</term> - <listitem> - <synopsis>Quiver=true</synopsis> - <para> - Controls whether <filename>gdmlogin</filename> should - shake the display when an incorrect username/password is - entered. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RemoteWelcome</term> - <listitem> - <synopsis>RemoteWelcome=Welcome to %n</synopsis> - <para> - Controls which text to display next to the logo image in the - greeter for remote XDMCP sessions. The same expansion is - done here as in the <filename>Welcome</filename> string. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>RunBackgroundProgramAlways</term> - <listitem> - <synopsis>RunBackgroundProgramAlways=false</synopsis> - <para> - If this is true then the background program is run always, otherwise - it is only run when the <filename>BackgroundType</filename> is 0 (None) - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SetPosition</term> - <listitem> - <synopsis>SetPosition=true</synopsis> - <para> - If true the position of the login window of the Standard Greeter - is determined by <filename>PositionX</filename> - / <filename>PositionY</filename>. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ShowGnomeFailsafeSession</term> - <listitem> - <synopsis>ShowGnomeFailsafeSession=true</synopsis> - <para> - Should the greeter show the Gnome Failsafe session - in the sessions list. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ShowLastSession</term> - <listitem> - <synopsis>ShowLastSession=true</synopsis> - <para> - Should the greeter show the 'Last' session in the - session list. If this is off, then GDM is in the - so called 'switchdesk' mode which for example - Red Hat uses. That is, the users can't pick - the last session and will just then get the default - session (see <filename>DefaultSession</filename>) - unless then pick something else for this session - only. So if this is off, this really circumvents - saving of the last session. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ShowXtermFailsafeSession</term> - <listitem> - <synopsis>ShowXtermFailsafeSession=true</synopsis> - <para> - Should the greeter show the Xterm Failsafe session - in the sessions list. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SoundOnLogin</term> - <listitem> - <synopsis>SoundOnLogin=true</synopsis> - <para> - If true, the greeter will play a sound or beep when - it is ready for a login. See also the - <filename>SoundOnLoginFile</filename> key. - Supported since 2.5.90.0. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SoundOnLoginFile</term> - <listitem> - <synopsis>SoundOnLogin=/path/to/sound.wav</synopsis> - <para> - The file that will be played using the specified - sound program (by default that is - <filename>/usr/bin/play</filename>) instead of a beep - when the greeter is ready for a login. - See also the - <filename>SoundOnLogin</filename> key and the - <filename>SoundProgram</filename> key. - Supported since 2.5.90.0. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>SystemMenu</term> - <listitem> - <synopsis>SystemMenu=true</synopsis> - <para> - Turns the Actions menu (which used to be called System menu) on - or off. If this is off then one of the - actions will be available anywhere. These actions include - Shutdown, Reboot, Configure, XDMCP chooser and such. All of - those can however be turned off individually. Shutdown, Reboot - and Suspend can be turned off by just setting the corresponding - keys to empty. Note that the - actions menu is only shown on local logins as it would not be - safe or even desirable on remote logins, so you don't have to - worry about remote users having any sort of console privilages. - </para> - - <para> - Note that if this is off none of the actions will be available - even if a theme for a graphical greeter mistakenly shows them. - Also note that sometimes a graphical theme may not show all - the available actions as buttons and you may have to press - F10 to see the menu. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>TitleBar</term> - <listitem> - <synopsis>TitleBar=true</synopsis> - <para> - Display the title bar in the greeter. - This only affects the Standard Greeter. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Use24Clock</term> - <listitem> - <synopsis>Use24Clock=false</synopsis> - <para> - Force the use of 24 hour clock even if the locale would default - to a 12 hour clock. In some locales that normally use 24 hour - format (like czech, that is <filename>cs_CZ</filename>) this - setting has no effect. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>UseCirclesInEntry</term> - <listitem> - <synopsis>UseCirclesInEntry=false</synopsis> - <para> - Use circles instead of asterisks in the password entry. - This may not work with all fonts however. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Welcome</term> - <listitem> - <synopsis>Welcome=Welcome</synopsis> - <para> - Controls which text to display next to the logo image in the - standard greeter. The following control chars are supported: - </para> - - <para> - %% — the `%' character - </para> - - <para> - %d — display's hostname - </para> - - <para> - %h — Fully qualified hostname - </para> - - <para> - %m — machine (processor type) - </para> - - <para> - %n — Nodename (i.e. hostname without .domain) - </para> - - <para> - %r — release (OS version) - </para> - - <para> - %s — sysname (i.e. OS) - </para> - - <para> - This string is only used for local logins. For remote XDMCP - logins we use <filename>RemoteWelcome</filename>. - </para> - - <para> - In the Graphical Greeter the location of this text depends on - the theme. Unless the theme uses the stock welcome string - somewhere this string will not be displayed at all. - </para> - - </listitem> - </varlistentry> - - <varlistentry> - <term>XineramaScreen</term> - <listitem> - <synopsis>XineramaScreen=0</synopsis> - <para> - If the Xinerama extension is active the login window - will be centered on this physical screen (use 0 for - the first screen, 1 for the second..). - </para> - </listitem> - </varlistentry> - - </variablelist> + programs will run this way, since gdm does not usually have + a home directory. You could set up home directory for the + gdm user if you wish to run applications which require it. + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>BackgroundRemoteOnlyColor</term> + <listitem> + <synopsis>BackgroundRemoteOnlyColor=true</synopsis> + <para> + On remote displays only set the color background. This is to + make network load lighter. The + <filename>BackgroundProgram</filename> is also not run. This + only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>BackgroundScaleToFit</term> + <listitem> + <synopsis>BackgroundScaleToFit=true</synopsis> + <para> + Scale background image to fit the screen. This only affects + the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>BackgroundType</term> + <listitem> + <synopsis>BackgroundType=2</synopsis> + <para> + The type of background to set. 0 is none, 1 is image and 2 + is color. This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Browser</term> + <listitem> + <synopsis>Browser=true</synopsis> + <para> + Set to true to enable the face browser. See the + ``The Standard Greeter'' section for more information on the + face browser. This option only works for the Standard Greeter. + For the Graphical Greeter, the face browser is enabled by + choosing a theme which includes a face browser + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ChooserButton</term> + <listitem> + <synopsis>ChooserButton=true</synopsis> + <para> + If true, add a chooser button to the Actions menu that will + restart the current server with a chooser. XDMCP does not need + to be enabled on the local machine for this to work. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ConfigAvailable</term> + <listitem> + <synopsis>ConfigAvailable=true</synopsis> + <para> + Allow the configurator to be run from the greeter. Note that + the user will need to type in the root password before the + configurator is run however. See the + <filename>Configurator</filename> option in the daemon section. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DefaultFace</term> + <listitem> + <synopsis>DefaultFace=<share>/pixmaps/nophoto.png</synopsis> + <para> + Default icon file for users without a personal picture + in <filename>~/gnome/photo</filename>. The image must be + in an gdk-pixbuf supported format and the file must be + readable for the gdm user. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Exclude</term> + <listitem> + <synopsis>Exclude=bin,daemon,adm,lp,sync,shutdown,halt,mail,...</synopsis> + <para> + Comma-separated list of usernames to exclude from the + face browser. The excluded users will still be able to + log in. See also <filename>MinimalUID</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GlobalFaceDir</term> + <listitem> + <synopsis>GlobalFaceDir=<share>/faces/</synopsis> + <para> + Systemwide directory for face files. The sysadmin can place + icons for users here without touching their homedirs. Faces are + named after their users' logins. + </para> + + <para> + I.e. <filename><GlobalFaceDir>/johndoe</filename> would + contain the face icon for the user ``johndoe''. No image format + extension should be specified. + </para> + + <para> + The face images must be stored in gdk-pixbuf supported formats + and they must be readable for the GDM user. + </para> + + <para> + A user's own icon file will always take precedence over the + sysadmin provided one. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GraphicalTheme</term> + <listitem> + <synopsis>GraphicalTheme=circles</synopsis> + <para> + The graphical theme that the Graphical Greeter should use. it + should refer to a directory in the theme directory set by + <filename>GraphicalThemeDir</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>GraphicalThemeDir</term> + <listitem> + <synopsis>GraphicalThemeDir=<share>/gdm/themes/</synopsis> + <para> + The directory where themes for the Graphical Greeter are + installed. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>InfoMsgFile</term> + <listitem> + <synopsis>InfoMsgFile=/path/to/infofile</synopsis> + <para> + If present and /path/to/infofile specifies an existing and + readable text file (e.g. /etc/infomsg.txt) the contents of the + file will be displayed in a modal dialog box before the user + is allowed to login. + This works both with the standard and the themable greeters. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>InfoMsgFont</term> + <listitem> + <synopsis>InfoMsgFont=fontspec</synopsis> + <para> + If present and InfoMsgFile (see above) is used, this specifies + the font to use when displaying the contents of the InfoMsgFile + text file. For example fontspec could be Sans 24 to get a + sans serif font of size 24 points. + This works both with the standard and the themable greeters. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term>LocaleFile</term> + <listitem> + <synopsis>LocaleFile=<etc>/gdm/locale.alias</synopsis> + <para> + File in format similar to the GNU locale format with entries + for all supported languages on the system. The format is + described above or in a comment inside that file. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>LockPosition</term> + <listitem> + <synopsis>LockPosition=true</synopsis> + <para> + If true the position of the login window of the Standard + Greeter cannot be changed even if the title bar is turned on. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Logo</term> + <listitem> + <synopsis>Logo=<share>/pixmaps/gnome-logo-large.png</synopsis> + <para> + Image file to display in the logo box. The file must be + in an gdk-pixbuf supported format and it must be readable by + the GDM user. If no file is specified the logo feature + is disabled. + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MinimalUID</term> + <listitem> + <synopsis>MinimalUID=100</synopsis> + <para> + The minimal UID that gdm should consider a user. All + users with a lower UID will be excluded from the face browser. + See also <filename>Exclude</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PositionX</term> + <listitem> + <synopsis>PositionX=200</synopsis> + <para> + The horizontal position of the login window of the Standard + Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>PositionY</term> + <listitem> + <synopsis>PositionY=100</synopsis> + <para> + The vertical position of the login window of the Standard + Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Quiver</term> + <listitem> + <synopsis>Quiver=true</synopsis> + <para> + Controls whether <filename>gdmlogin</filename> should + shake the display when an incorrect username/password is + entered. + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RemoteWelcome</term> + <listitem> + <synopsis>RemoteWelcome=Welcome to %n</synopsis> + <para> + Controls which text to display next to the logo image in the + greeter for remote XDMCP sessions. The same expansion is + done here as in the <filename>Welcome</filename> string. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>RunBackgroundProgramAlways</term> + <listitem> + <synopsis>RunBackgroundProgramAlways=false</synopsis> + <para> + If this is true then the background program is run always, + otherwise it is only run when the + <filename>BackgroundType</filename> is 0 (None) + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SetPosition</term> + <listitem> + <synopsis>SetPosition=true</synopsis> + <para> + If true the position of the login window of the Standard Greeter + is determined by <filename>PositionX</filename> + / <filename>PositionY</filename>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ShowGnomeFailsafeSession</term> + <listitem> + <synopsis>ShowGnomeFailsafeSession=true</synopsis> + <para> + Should the greeter show the Gnome Failsafe session in th + sessions list. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ShowLastSession</term> + <listitem> + <synopsis>ShowLastSession=true</synopsis> + <para> + Should the greeter show the 'Last' session in the session list. + If this is off, then GDM is in the so called 'switchdesk' mode + which for example Red Hat uses. That is, the users can't pick + the last session and will just then get the default session + (see <filename>DefaultSession</filename>) unless then pick + something else for this session only. So if this is off, this + really circumvents saving of the last session. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ShowXtermFailsafeSession</term> + <listitem> + <synopsis>ShowXtermFailsafeSession=true</synopsis> + <para> + Should the greeter show the Xterm Failsafe session in the + sessions list. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SoundOnLogin</term> + <listitem> + <synopsis>SoundOnLogin=true</synopsis> + <para> + If true, the greeter will play a sound or beep when it is + ready for a login. See also the + <filename>SoundOnLoginFile</filename> key. + Supported since 2.5.90.0. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SoundOnLoginFile</term> + <listitem> + <synopsis>SoundOnLogin=/path/to/sound.wav</synopsis> + <para> + The file that will be played using the specified sound program + (by default that is <filename>/usr/bin/play</filename>) instead + of a beep when the greeter is ready for a login. See also the + <filename>SoundOnLogin</filename> key and the + <filename>SoundProgram</filename> key. + Supported since 2.5.90.0. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>SystemMenu</term> + <listitem> + <synopsis>SystemMenu=true</synopsis> + <para> + Turns the Actions menu (which used to be called System menu) on + or off. If this is off then one of the actions will be + available anywhere. These actions include Shutdown, Reboot, + Configure, XDMCP chooser and such. All of those can however + be turned off individually. Shutdown, Reboot and Suspend can + be turned off by just setting the corresponding keys to empty. + Note that the actions menu is only shown on local logins as it + would not be safe or even desirable on remote logins, so you + don't have to worry about remote users having any sort of + console privilages. + </para> + + <para> + Note that if this is off none of the actions will be available + even if a theme for a graphical greeter mistakenly shows them. + Also note that sometimes a graphical theme may not show all + the available actions as buttons and you may have to press + F10 to see the menu. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>TitleBar</term> + <listitem> + <synopsis>TitleBar=true</synopsis> + <para> + Display the title bar in the greeter. + This only affects the Standard Greeter. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Use24Clock</term> + <listitem> + <synopsis>Use24Clock=false</synopsis> + <para> + Force the use of 24 hour clock even if the locale would default + to a 12 hour clock. In some locales that normally use 24 hour + format (like czech, that is <filename>cs_CZ</filename>) this + setting has no effect. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>UseCirclesInEntry</term> + <listitem> + <synopsis>UseCirclesInEntry=false</synopsis> + <para> + Use circles instead of asterisks in the password entry. + This may not work with all fonts however. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Welcome</term> + <listitem> + <synopsis>Welcome=Welcome</synopsis> + <para> + Controls which text to display next to the logo image in the + standard greeter. The following control chars are supported: + </para> + + <para> + %% — the `%' character + </para> + + <para> + %d — display's hostname + </para> + + <para> + %h — Fully qualified hostname + </para> + + <para> + %m — machine (processor type) + </para> + + <para> + %n — Nodename (i.e. hostname without .domain) + </para> + + <para> + %r — release (OS version) + </para> + + <para> + %s — sysname (i.e. OS) + </para> + + <para> + This string is only used for local logins. For remote XDMCP + logins we use <filename>RemoteWelcome</filename>. + </para> + + <para> + In the Graphical Greeter the location of this text depends on + the theme. Unless the theme uses the stock welcome string + somewhere this string will not be displayed at all. + </para> + + </listitem> + </varlistentry> + + <varlistentry> + <term>XineramaScreen</term> + <listitem> + <synopsis>XineramaScreen=0</synopsis> + <para> + If the Xinerama extension is active the login window will be + centered on this physical screen (use 0 for the first screen, + 1 for the second...). + </para> + </listitem> + </varlistentry> + + </variablelist> </sect3> <sect3 id="choosersection"> - <title>XDCMP Chooser Options</title> - - <variablelist> - <title>[chooser]</title> - - <varlistentry> - <term>AllowAdd</term> - <listitem> - <synopsis>AllowAdd=true</synopsis> - <para> - If true, allow the user to add arbitrary hosts to the - chooser. This way the user could connect to any host - that responds to XDMCP queries from the chooser. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Broadcast</term> - <listitem> - <synopsis>Broadcast=true</synopsis> - <para> - If true, the chooser will broadcast a query to the local - network and collect responses. This way the chooser will - always show all available managers on the network. If you - need to add some hosts not local to this network, or if you - don't want to use a broadcast, you can list them explicitly - in the <filename>Hosts</filename> key. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>Multicast</term> - <listitem> - <synopsis>Multicast=true</synopsis> - <para> - If true and IPv6 is enabled, the chooser will send a multicast - query to the local network and collect responses from the hosts - who have joined multicast group. If you don't want to send a - multicast, you can specify IPv6 address in the <filename>Hosts - </filename> key. The host will respond if it is listening to - XDMCP requests and IPv6 is enabled there. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>MulticastAddr</term> - <listitem> - <synopsis>MulticastAddr=ff02::1</synopsis> - <para> - This is the Link-local Multicast address and is hardcoded here. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>DefaultHostImage</term> - <listitem> - <synopsis>DefaultHostImage=<share>/pixmaps/nohost.png</synopsis> - <para> - File name for the default host icon. This image will be - displayed if no icon is specified for a given host. The - file must be in an gdk-pixbuf supported format and it must be - readable for the GDM user. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>HostImageDir</term> - <listitem> - <synopsis>HostImageDir=<share>/hosts</synopsis> - <para> - Repository for host icon files. The sysadmin can place - icons for remote hosts here and they will appear in - <filename>gdmchooser</filename>. - </para> - - <para> - The file name must match the fully qualified name (FQDN) for - the host. The icons must be stored in gdk-pixbuf supported formats - and they must be readable to the gdm user. - </para> - - </listitem> - </varlistentry> - - <varlistentry> - <term>Hosts</term> - <listitem> - <synopsis>Hosts=host1,host2</synopsis> - <para> - The hosts which should be listed in the chooser. The chooser - will only list them if they respond. This is done in addition - to broadcast (if <filename>Broadcast</filename> is set), so you need not list - hosts on the local network. This is useful if your - networking setup doesn't allow all hosts to be reachable - by a broadcast packet. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>ScanTime</term> - <listitem> - <synopsis>ScanTime=4</synopsis> - <para> - Specifies how many seconds the chooser should wait for - replies to its BROADCAST_QUERY. Really this is only the time - in which we expect a reply. We will still add hosts to the list - even if they reply after this time. - </para> - </listitem> - </varlistentry> - </variablelist> - + <title>XDCMP Chooser Options</title> + + <variablelist> + <title>[chooser]</title> + + <varlistentry> + <term>AllowAdd</term> + <listitem> + <synopsis>AllowAdd=true</synopsis> + <para> + If true, allow the user to add arbitrary hosts to the chooser. + This way the user could connect to any host that responds to + XDMCP queries from the chooser. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Broadcast</term> + <listitem> + <synopsis>Broadcast=true</synopsis> + <para> + If true, the chooser will broadcast a query to the local + network and collect responses. This way the chooser will + always show all available managers on the network. If you + need to add some hosts not local to this network, or if you + don't want to use a broadcast, you can list them explicitly + in the <filename>Hosts</filename> key. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>Multicast</term> + <listitem> + <synopsis>Multicast=true</synopsis> + <para> + If true and IPv6 is enabled, the chooser will send a multicast + query to the local network and collect responses from the hosts + who have joined multicast group. If you don't want to send a + multicast, you can specify IPv6 address in the <filename>Hosts + </filename> key. The host will respond if it is listening to + XDMCP requests and IPv6 is enabled there. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>MulticastAddr</term> + <listitem> + <synopsis>MulticastAddr=ff02::1</synopsis> + <para> + This is the Link-local Multicast address and is hardcoded here. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>DefaultHostImage</term> + <listitem> + <synopsis>DefaultHostImage=<share>/pixmaps/nohost.png</synopsis> + <para> + File name for the default host icon. This image will be + displayed if no icon is specified for a given host. The + file must be in an gdk-pixbuf supported format and it must be + readable for the GDM user. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>HostImageDir</term> + <listitem> + <synopsis>HostImageDir=<share>/hosts</synopsis> + <para> + Repository for host icon files. The sysadmin can place icons + for remote hosts here and they will appear in + <filename>gdmchooser</filename>. + </para> + + <para> + The file name must match the fully qualified name (FQDN) for + the host. The icons must be stored in gdk-pixbuf supported + formats and they must be readable to the gdm user. + </para> + + </listitem> + </varlistentry> + + <varlistentry> + <term>Hosts</term> + <listitem> + <synopsis>Hosts=host1,host2</synopsis> + <para> + The hosts which should be listed in the chooser. The chooser + will only list them if they respond. This is done in addition + to broadcast (if <filename>Broadcast</filename> is set), so you + need not list hosts on the local network. This is useful if + your networking setup doesn't allow all hosts to be reachable + by a broadcast packet. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>ScanTime</term> + <listitem> + <synopsis>ScanTime=4</synopsis> + <para> + Specifies how many seconds the chooser should wait for + replies to its BROADCAST_QUERY. Really this is only the time + in which we expect a reply. We will still add hosts to the + list even if they reply after this time. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect3> <sect3 id="serverdefs"> - <title>X Server definitions</title> - - <para> - To set up X servers, you need to provide gdm with - information about the installed X servers. You can - have as many different definitions as you wish, each - identified with a unique name. The name - <filename>Standard</filename> - is required. If you do not specify this server, gdm - will assume default values for a 'Standard' server - and the path given by <filename>daemon/StandardXServer</filename>. - <filename>Standard</filename> is used as the default, - in situations when no other server has been defined. - </para> - - <para> - Servers are defined by sections named <filename>server-</filename> - followed by the identifier of this server. This should be a - simple ASCII string with no spaces. If you use the GUI - configurator, it will use random words for these. These will - not be user visible, they are just needed to uniquely identify the - server. - </para> - - <variablelist> - <title>[server-Standard]</title> - - <varlistentry> - <term>name</term> - <listitem> - <synopsis>name=Standard server</synopsis> - <para> - The name that will be displayed to the user. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>command</term> - <listitem> - <synopsis>command=/usr/bin/X11/X</synopsis> - <para> - The command to execute, with full path to the binary - of the X server, and any extra arguments needed. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>flexible</term> - <listitem> - <synopsis>flexible=true</synopsis> - <para> - Indicates if this server is available as a choice when a - user wishes to run a flexible, on demand server. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>handled</term> - <listitem> - <synopsis>handled=true</synopsis> - <para> - Indicates that GDM should run the login window on this server - and allow a user to log in. If set to false, then GDM will just - run this server and wait for it to terminate. This can be useful - to run an X terminal using GDM. When this is done you should - normally also add <filename>-terminate</filename> to the command - line of the server to make the server terminate after each session. - otherwise the control of the slave will never come back to GDM - and for example soft restarts won't work, since GDM assumes there - is a login in progress for the entire time this server is - active. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>chooser</term> - <listitem> - <synopsis>chooser=false</synopsis> - <para> - Indicates that GDM should instead of a login window run a chooser on - this window and allow the user to choose which server to log into. - </para> - </listitem> - </varlistentry> - - </variablelist> + <title>X Server definitions</title> + + <para> + To set up X servers, you need to provide gdm with information about + the installed X servers. You can have as many different definitions + as you wish, each identified with a unique name. The name + <filename>Standard</filename> is required. If you do not specify + this server, gdm will assume default values for a 'Standard' server + and the path given by <filename>daemon/StandardXServer</filename>. + <filename>Standard</filename> is used as the default, + in situations when no other server has been defined. + </para> + + <para> + Servers are defined by sections named <filename>server-</filename> + followed by the identifier of this server. This should be a simple + ASCII string with no spaces. If you use the GUI configurator, it + will use random words for these. These will not be user visible, + they are just needed to uniquely identify the server. + </para> + + <variablelist> + <title>[server-Standard]</title> + + <varlistentry> + <term>name</term> + <listitem> + <synopsis>name=Standard server</synopsis> + <para> + The name that will be displayed to the user. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>command</term> + <listitem> + <synopsis>command=/usr/bin/X11/X</synopsis> + <para> + The command to execute, with full path to the binary of the X + server, and any extra arguments needed. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>flexible</term> + <listitem> + <synopsis>flexible=true</synopsis> + <para> + Indicates if this server is available as a choice when a + user wishes to run a flexible, on demand server. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>handled</term> + <listitem> + <synopsis>handled=true</synopsis> + <para> + Indicates that GDM should run the login window on this server + and allow a user to log in. If set to false, then GDM will + just run this server and wait for it to terminate. This can be + useful to run an X terminal using GDM. When this is done you + should normally also add <filename>-terminate</filename> to the + command line of the server to make the server terminate after + each session. otherwise the control of the slave will never + come back to GDM and for example soft restarts won't work, + since GDM assumes there is a login in progress for the entire + time this server is active. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>chooser</term> + <listitem> + <synopsis>chooser=false</synopsis> + <para> + Indicates that GDM should instead of a login window run a + chooser on this window and allow the user to choose which + server to log into. + </para> + </listitem> + </varlistentry> + + </variablelist> </sect3> <sect3 id="localservers"> - <title>Local Static X Server Configuration</title> - - <para> - The static X servers are servers that are always running, when the server - ever dies, it is restarted. You can have as many local static servers as - you wish. Each key in the <filename>[servers]</filename> section corresponds - to the display number of the server to run. For example normally there - is only one key, which is the key <filename>0</filename>, which corresponds - to the display <filename>:0</filename>. - </para> - - <variablelist> - <title>[servers]</title> - - <varlistentry> - <term><display number></term> - <listitem> - <synopsis>0=Standard</synopsis> - <para> - Control section for local X servers. Each line indicates - the local display number and the command that needs to - be run to start the X server(s). - </para> - - <para> - The command can either be a path to an X executable, or - a name of one of the server definitions. This can be - followed by some arguments that should be passed to the - X server when executed. - </para> - - <para> - The gdm daemon doesn't enforce the numbers to be in - order or for them to be "packed". However when you use - the GUI configurator, the servers will always start from - 0 and go up by 1. That is, leaving no holes. - </para> - - <para> - GDM will splice "<filename>-auth - <ServAuthDir>/:n.Xauth :n</filename>", where n is - the display number. Inside the command line before all - other arguments before running the server. - </para> - - <para> - On some systems it is necessary for gdm to know on which - virtual consoles to run the X server. In this case, - (if running XFree86) add "vt7" to the command line for example - to run on virtual console 7. However on Linux and - FreeBSD this is normally - done automatically if <filename>VTAllocation</filename> key - is set. - </para> - - <para> - Normally you do not need to add a <filename>-nolisten tcp</filename> - flag as this is added automatically for local servers when - the <filename>DisallowTCP</filename> option is set. - </para> - </listitem> - </varlistentry> - - </variablelist> + <title>Local Static X Server Configuration</title> + + <para> + The static X servers are servers that are always running, when the + server ever dies, it is restarted. You can have as many local static + servers as you wish. Each key in the <filename>[servers]</filename> + section corresponds to the display number of the server to run. For + example normally there is only one key, which is the key + <filename>0</filename>, which corresponds to the display + <filename>:0</filename>. + </para> + + <variablelist> + <title>[servers]</title> + + <varlistentry> + <term><display number></term> + <listitem> + <synopsis>0=Standard</synopsis> + <para> + Control section for local X servers. Each line indicates + the local display number and the command that needs to + be run to start the X server(s). + </para> + + <para> + The command can either be a path to an X executable, or a name + of one of the server definitions. This can be followed by some + arguments that should be passed to the X server when executed. + </para> + + <para> + The gdm daemon doesn't enforce the numbers to be in + order or for them to be "packed". However when you use + the GUI configurator, the servers will always start from + 0 and go up by 1. That is, leaving no holes. + </para> + + <para> + GDM will splice "<filename>-auth + <ServAuthDir>/:n.Xauth :n</filename>", where n is + the display number. Inside the command line before all + other arguments before running the server. + </para> + + <para> + On some systems it is necessary for gdm to know on which + virtual consoles to run the X server. In this case, + (if running XFree86) add "vt7" to the command line for example + to run on virtual console 7. However on Linux and + FreeBSD this is normally + done automatically if <filename>VTAllocation</filename> key + is set. + </para> + + <para> + Normally you do not need to add a + <filename>-nolisten tcp</filename> flag as this is added + automatically for local servers when the + <filename>DisallowTCP</filename> option is set. + </para> + </listitem> + </varlistentry> + + </variablelist> </sect3> - + </sect2> <sect2 id="userconfig"> <title>Per User Configuration</title> <para> - There are some per user configuration settings that control how GDM behaves. - Firstly there is the <filename>~/.dmrc</filename> file. In theory this - file should be shared between GDM and KDM, so users only have to configure - things once. This is a standard <filename>.ini</filename> style configuration - file. It has one section called <filename>[Desktop]</filename> and can have - two keys, <filename>Session</filename>, which is the basename of the session - <filename>.desktop</filename> file that the user wishes to normally use - (but without the <filename>.desktop</filename> extension) - and a <filename>Language</filename> key that is the language that the user - wishes to use. If either of these keys is missing, the system default is - used. The file would normally look as follows: + There are some per user configuration settings that control how GDM + behaves. Firstly there is the <filename>~/.dmrc</filename> file. In + theory this file should be shared between GDM and KDM, so users only + have to configure things once. This is a standard + <filename>.ini</filename> style configuration file. It has one section + called <filename>[Desktop]</filename> and can have two keys, + <filename>Session</filename>, which is the basename of the session + <filename>.desktop</filename> file that the user wishes to normally use + (but without the <filename>.desktop</filename> extension) + and a <filename>Language</filename> key that is the language that the + user wishes to use. If either of these keys is missing, the system + default is used. The file would normally look as follows: </para> <screen> - [Desktop] - Session=gnome - Language=cs_CZ.UTF-8 -</screen> +[Desktop] +Session=gnome +Language=cs_CZ.UTF-8 + </screen> <para> - The user can also configure a face image for the face browser. This is - done by copying an image into a file called <filename>~/.face</filename>. - This should be a standard image that GTK+ can read, such as PNG. + The user can also configure a face image for the face browser. This is + done by copying an image into a file called + <filename>~/.face</filename>. This should be a standard image that + GTK+ can read, such as PNG. </para> <para> - Face images can also be placed in the global face directory, which is - normally <filename><share>/faces/</filename> - (though this can be configured with the <filename>GlobalFaceDir</filename> - configuration option) and the filename should be the name of - the user, optionally with a <filename>.png</filename> appended. + Face images can also be placed in the global face directory, which is + normally <filename><share>/faces/</filename> + (though this can be configured with the + <filename>GlobalFaceDir</filename> configuration option) and the + filename should be the name of the user, optionally with a + <filename>.png</filename> appended. </para> </sect2> @@ -3058,239 +3031,892 @@ <title>Controlling GDM</title> <para> - You can control GDM behavior during runtime in several different ways. You can - either run certain commands, or you can talk to GDM using either a unix socket - protocol, or a FIFO protocol. + You can control GDM behavior during runtime in several different ways. + You can either run certain commands, or you can talk to GDM using either + a unix socket protocol, or a FIFO protocol. </para> <sect2 id="commands"> <title>Commands</title> <para> - To stop GDM, you can either send the TERM signal to the main daemon or run - the <filename>gdm-stop</filename> command which is in the <filename><sbin>/</filename> - directory. To restart GDM, you can either send the HUP signal to the main daemon or run - the <filename>gdm-restart</filename> command which is also in the <filename><sbin>/</filename> - directory. - To restart GDM but only after all the users have logged out, you can either send - the USR1 signal to the main daemon or run - the <filename>gdm-safe-restart</filename> command which is in the <filename><sbin>/</filename> - directory as well. + To stop GDM, you can either send the TERM signal to the main daemon or + run the <filename>gdm-stop</filename> command which is in the + <filename><sbin>/</filename> directory. To restart GDM, you can + either send the HUP signal to the main daemon or run the + <filename>gdm-restart</filename> command which is also in the + <filename><sbin>/</filename> directory. To restart GDM but only + after all the users have logged out, you can either send the USR1 + signal to the main daemon or run the + <filename>gdm-safe-restart</filename> command which is in the + <filename><sbin>/</filename> directory as well. </para> <para> - The <filename>gdmflexiserver</filename> command can be used to start new flexible (on demand) - servers. Run <filename>gdmflexiserver --help</filename> to get a listing of possible - options. This command will also lock the current screen with xscreensaver so that - the user can safely walk away from the machine and let someone else log in. XFree86 will - automatically switch back to the same virtual terminal (if your operating system supports it), - after the new session has ended, so this should work quite transparently to the users. + The <filename>gdmflexiserver</filename> command can be used to start + new flexible (on demand) servers. Run + <filename>gdmflexiserver --help</filename> to get a listing of possible + options. This command will also lock the current screen with + xscreensaver so that the user can safely walk away from the machine and + let someone else log in. XFree86 will automatically switch back to the + same virtual terminal (if your operating system supports it), after the + new session has ended, so this should work quite transparently to the + users. </para> - </sect2> - <sect2 id="socketprot"> - <title>Socket Protocol</title> + <sect2 id="fifoprot"> + <title>The FIFO protocol</title> <para> - GDM provides a unix domain socket for communication at <filename>/tmp/.gdm_socket</filename>. - Using this you can check if GDM is running, the version of the daemon, the current - servers that are running and who is logged in on them, and if GDM supports it on your - operating system, also the virtual terminals of all the console logins. You can also request - new flexible servers to be run with this protocol, but this is best done with the - <filename>gdmflexiserver</filename> command. + GDM also provides a FIFO called <filename>.gdmfifo</filename> in the + <filename>ServAuthDir</filename> directory + (usually <filename><var>/gdm/.gdmfifo</filename>). You must be + root to use this protocol, and it is mostly used for internal GDM + chatter. It is a very simple protocol where you just echo a command on + a single line to this file. It can be used to tell GDM things such as + restart, suspend the machine, or restart all X servers next time it has + a chance (which would be useful from an X configuration program). </para> <para> - Full and up to date documentation of the commands and their use is contained in the - GDM source tree in the file <filename>daemon/gdm.h</filename>. Look for the - defines starting with <filename>GDM_SUP_</filename>. + Full and up to date documentation of the commands and their use is + contained in the GDM source tree in the file + <filename>daemon/gdm.h</filename>. Look for the defines starting with + <filename>GDM_SOP_</filename>. The commands which require the + pid of the slave as an argument are the ones that are really used for + internal communication of the slave with the master and should not be + used. </para> - </sect2> - <sect2 id="fifoprot"> - <title>The FIFO protocol</title> + <sect2 id="socketprot"> + <title>Socket Protocol</title> + + <para> + GDM provides a unix domain socket for communication at + <filename>/tmp/.gdm_socket</filename>. Using this you can check if + GDM is running, the version of the daemon, the current servers that are + running and who is logged in on them, and if GDM supports it on your + operating system, also the virtual terminals of all the console logins. + You can also request new flexible servers to be run with this protocol, + but this is best done with the + <filename>gdmflexiserver</filename> command. + </para> <para> - GDM also provides a FIFO called <filename>.gdmfifo</filename> in the - <filename>ServAuthDir</filename> directory - (usually <filename><var>/gdm/.gdmfifo</filename>). You must be root to use this protocol, - and it is mostly used for internal GDM chatter. It is a very simple protocol where - you just echo a command on a single line to this file. It can be used to tell - GDM things such as restart, suspend the machine, or restart all X servers next - time it has a chance (which would be useful from an X configuration program). + gdmflexiserver accepts the following commands with the --command + option: </para> + <screen> +VERSION +AUTH_LOCAL +FLEXI_XSERVER +FLEXI_XNEST +CONSOLE_SERVERS +ALL_SERVERS +UPDATE_CONFIG +GREETERPIDS +QUERY_LOGOUT_ACTION +SET_LOGOUT_ACTION +SET_SAFE_LOGOUT_ACTION +QUERY_VT +SET_VT +CLOSE + </screen> + <para> - Full and up to date documentation of the commands and their use is contained in the - GDM source tree in the file <filename>daemon/gdm.h</filename>. Look for the - defines starting with <filename>GDM_SOP_</filename>. The commands which require the - pid of the slave as an argument are the ones that are really used for internal - communication of the slave with the master and should not be used. + These are described in detail below, including required arguments, + response format, and return codes. </para> + <sect3 id="queryversion"> + <title>VERSION</title> + <screen> +VERSION: Query version +Supported since: 2.2.4.0 +Arguments: None +Answers: + GDM <gdm version> + ERROR <err number> <english error description> + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="authlocal"> + <title>AUTH_LOCAL</title> + <screen> +AUTH_LOCAL: Setup this connection as authenticated for + FLEXI_SERVER Because all full blown (non-Xnest) + servers can be started only from users logged in + locally, and here gdm assumes only users logged + in from gdm. They must pass the xauth + MIT-MAGIC-COOKIE-1 that they were passed before + the connection is authenticated. +Note: The AUTH LOCAL command requires the + --authenticate option, although only + FLEXI XSERVER uses this currently. +Supported since: 2.2.4.0 +Arguments: <xauth cookie> + <xauth cookie> is in hex form with no 0x prefix +Answers: + OK + ERROR <err number> <english error description> + 0 = Not implemented + 100 = Not authenticated + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="flexixserver"> + <title>FLEXI_XSERVER</title> + <screen> +FLEXI_XSERVER: Start a new X flexible server +Only supported on connection that passed AUTH_LOCAL +Supported since: 2.2.4.0 +Arguments: <xserver type> + If no arguments, starts the standard x server +Answers: + OK <display> + ERROR <err number> <english error description> + 0 = Not implemented + 1 = No more flexi servers + 2 = Startup errors + 3 = X failed + 4 = X too busy + 6 = No server binary + 100 = Not authenticated + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="flexixnest"> + <title>FLEXI_XNEST</title> + <screen> +FLEXI_XNEXT: Start a new flexible Xnest server +Note: Supported an older version from 2.2.4.0, later + 2.2.4.2, but since 2.3.90.4 you must supply 4 + arguments or ERROR 100 will be returned. This + will start Xnest using the XAUTHORITY file + supplied and as the uid same as the owner of + that file (and same as you supply). You must + also supply the cookie as the third argument + for this display, to prove that you indeed are + this user. Also this file must be readable + ONLY by this user, that is have a mode of 0600. + If this all is not met, ERROR 100 is returned. +Note: The cookie should be the MIT-MAGIC-COOKIE-1, + the first one gdm can find in the XAUTHORITY + file for this display. If that's not what you + use you should generate one first. The cookie + should be in hex form. +Supported since: 2.3.90.4 +Arguments: <display to run on> <uid of requesting user> + <xauth cookie for the display> <xauth file> +Answers: + OK <display> + ERROR <err number> <english error description> + 0 = Not implemented + 1 = No more flexi servers + 2 = Startup errors + 3 = X failed + 4 = X too busy + 5 = Xnest can't connect + 6 = No server binary + 100 = Not authenticated + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="consoleservers"> + <title>CONSOLE_SERVERS</title> + <screen> +CONSOLE_SERVERS: List all console servers, useful for linux + mostly. Doesn't list xdmcp and xnest + non-console servers +Supported since: 2.2.4.0 +Arguments: None +Answers: + OK <server>;<server>;... + + <server> is <display>,<logged in user>,<vt or xnest display> + + <logged in user> can be empty in case no one logged + in yet, and <vt> can be -1 if it's not known or not + supported (on non-linux for example). If the display is an + xnest display and is a console one (that is, it is an xnest + inside another console display) it is listed and instead of + vt, it lists the parent display in standard form. + + ERROR <err number> <english error description> + 1 = Not implemented + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="allservers"> + <title>ALL_SERVERS</title> + <screen> +ALL_SERVERS: List all servers, including console, remote, xnest. + This can, for example, be useful to figure out if + the server you are on is managed by the gdm daemon, + by seeing if it is in the list. It is also somewhat + like the 'w' command but for graphical sessions. +Supported since: 2.4.2.96 +Arguments: None +Answers: + OK <server>;<server>;... + + <server> is <display>,<logged in user> + + <logged in user> can be empty in case no one logged in yet + + ERROR <err number> <english error description> + 0 = Not implemented + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="updateconfig"> + <title>UPDATE_CONFIG</title> + <screen> +UPDATE_CONFIG: Tell the daemon to update config of some key. + Any user can really request that values are + re-read but the daemon caches the last date + of the config file so a user can't actually + change any values unless they can write the + config file. +Supported keys: + security/AllowRoot (2.3.90.2) + security/AllowRemoteRoot (2.3.90.2) + security/AllowRemoteAutoLogin (2.3.90.2) + security/RetryDelay (2.3.90.2) + security/DisallowTCP (2.4.2.0) + daemon/Greeter (2.3.90.2) + daemon/RemoteGreeter (2.3.90.2) + xdmcp/Enable (2.3.90.2) + xdmcp/Port (2.3.90.2) + xdmcp/PARAMETERS (2.3.90.2) (pseudokey, all the parameters) + xdmcp/MaxPending + xdmcp/MaxSessions + xdmcp/MaxWait + xdmcp/DisplaysPerHost + xdmcp/HonorIndirect + xdmcp/MaxPendingIndirect + xdmcp/MaxWaitIndirect + xdmcp/PingIntervalSeconds (only affects new connections) + daemon/TimedLogin (2.3.90.3) + daemon/TimedLoginEnable (2.3.90.3) + daemon/TimedLoginDelay (2.3.90.3) + greeter/SystemMenu (2.3.90.3) + greeter/ConfigAvailable (2.3.90.3) + greeter/ChooserButton (2.4.2.0) + greeter/SoundOnLoginFile (2.5.90.0) + daemon/AddGtkModules (2.5.90.0) + daemon/GtkModulesList (2.5.90.0) +Supported since: 2.3.90.2 +Arguments: <key> + <key> is just the base part of the key such as + "security/AllowRemoteRoot" +Answers: + OK + ERROR <err number> <english error description> + 0 = Not implemented + 50 = Unsupported key + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="greeterpids"> + <title>GREETERPIDS</title> + <screen> +GREETERPIDS: List all greeter pids so that one can send HUP + to them for config rereading. Of course one + must be root to do that. +Supported since: 2.3.90.2 +Arguments: None +Answers: + OK <pid>;<pid>;... + ERROR <err number> <english error description> + 0 = Not implemented + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="querylogoutaction"> + <title>QUERY_LOGOUT_ACTION</title> + <screen> +QUERY_LOGOUT_ACTION: Query which logout actions are possible +Only supported on connections that passed AUTH_LOCAL. +Supported since: 2.5.90.0 +Answers: + OK <action>;<action>;... + Where action is one of HALT, REBOOT or SUSPEND. An + empty list can also be returned if no action is possible. + A '!' is appended to an action if it was already set with + SET_LOGOUT_ACTION or SET_SAFE_LOGOUT_ACTION. Note that + SET_LOGOUT_ACTION has precedence over + SET_SAFE_LOGOUT_ACTION. + ERROR <err number> <english error description> + 0 = Not implemented + 100 = Not authenticanted + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="setlogoutaction"> + <title>SET_LOGOUT_ACTION</title> + <screen> +SET_LOGOUT_ACTION: Tell the daemon to halt/reboot/suspend + after slave process exits. +Only supported on connections that passed AUTH_LOCAL. +Supported since: 2.5.90.0 +Arguments: <action> + NONE Set exit action to 'none' + HALT Set exit action to 'halt' + REBOOT Set exit action to 'reboot' + SUSPEND Set exit action to 'suspend' + +Answers: + OK + ERROR <err number> <english error description> + 0 = Not implemented + 7 = Unknown logout action, or not available + 100 = Not authenticanted + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="setsafelogoutaction"> + <title>SET_SAFE_LOGOUT_ACTION</title> + <screen> +SET_SAFE_LOGOUT_ACTION: Tell the daemon to halt/reboot/suspend + after everybody logs out. If only + one person logs out, then this is + obviously the same as the + SET_LOGOUT_ACTION. Note that + SET_LOGOUT_ACTION has precendence over + SET_SAFE_LOGOUT_ACTION if it is set to + something other then NONE. If no one + is logged in, then the action takes + effect immediately. +Only supported on connections that passed AUTH_LOCAL. +Supported since: 2.5.90.0 +Arguments: <action> + NONE Set exit action to 'none' + HALT Set exit action to 'halt' + REBOOT Set exit action to 'reboot' + SUSPEND Set exit action to 'suspend' + +Answers: + OK + ERROR <err number> <english error description> + 0 = Not implemented + 7 = Unknown logout action, or not available + 100 = Not authenticanted + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="queryvt"> + <title>QUERY_VT</title> + <screen> +QUERY_VT: Ask the daemon about which VT we are currently on. + This is useful for logins which don't own + /dev/console but are still console logins. Only + supported on Linux currently, other places will + just get ERROR 8. This is also the way to query + if VT support is available in the daemon in the + first place. +Only supported on connections that passed AUTH_LOCAL. +Supported since: 2.5.90.0 +Arguments: None +Answers: + OK <vt number> + ERROR <err number> <english error description> + 0 = Not implemented + 8 = Virtual terminals not supported + 100 = Not authenticanted + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="setvt"> + <title>SET_VT</title> + <screen> +SET_VT: Change to the specified virtual terminal. + This is useful for logins which don't own /dev/console + but are still console logins. Only supported on Linux + currently, other places will just get ERROR 8. +Only supported on connections that passed AUTH_LOCAL. +Supported since: 2.5.90.0 +Arguments: <vt> +Answers: + OK + ERROR <err number> <english error description> + 0 = Not implemented + 8 = Virtual terminals not supported + 9 = Invalid virtual terminal number + 100 = Not authenticanted + 200 = Too many messages + 999 = Unknown error + </screen> + </sect3> + + <sect3 id="close"> + <title>CLOSE</title> + <screen> +CLOSE Answers: None +Supported since: 2.2.4.0 + </screen> + </sect3> </sect2> </sect1> <sect1 id="binaries"> - <title>GDM and Related Commands</title> + <title>GDM Commands</title> <para> - The GDM package provides quite a few different commands. + The GDM package provides quite a few different commands. </para> <sect2 id="gdmcommandline"> - <title>GDM Command Line Options</title> + <title><filename>gdm</filename> and <filename>gdm-binary</filename> + Command Line Options</title> <para> - First command is the <filename>gdm</filename> command which is really just a script - which runs the <filename>gdm-binary</filename>. If you really need to set - some environment before launching GDM, you can do it in this file. This command - accepts several command line parameters. + The <filename>gdm</filename> command is really just a script which + runs the <filename>gdm-binary</filename>, passing along any options. + Before launching gdm-binary, the gdm wrapper script will source the + <filename>/etc/profile</filename> file to set the standard system + environment variables. In order to better support + internationalization, it will also set the LC_MESSAGES environment + variable to LANG if neither LC_MESSAGES or LC_ALL are set. If you + really need to set some additional environment before launching GDM, + you can do so in this file. </para> <variablelist> - <title><filename>gdm</filename> Command Line Options</title> + <title><filename>gdm</filename> and <filename>gdm-binary</filename> + Command Line Options</title> - <varlistentry> - <term>--help</term> - <listitem> - <para> + <varlistentry> + <term>--help</term> + <listitem> + <para> Gives a brief overview of the command line options. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>-nodaemon</term> - <listitem> - <para> - If this option is specified, then gdm does not fork into the background when - run. You can use just a single dash with this option to preserve compatibility - with XDM. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--no-console</term> - <listitem> - <para> - Tell the daemon that it should not run anything on the console. This means that - none of the local servers from the <filename>[servers]</filename> section will - be run, and the console will not be used for communicating errors to the user. - An empty <filename>[servers]</filename> section automatically implies this - option. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--preserve-ld-vars</term> - <listitem> - <para> - When clearing the environment internally, preserve all variables starting with - LD_. This is mostly for debugging purposes. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--version</term> - <listitem> - <para> - Print the version of the GDM daemon. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>--wait-for-go</term> - <listitem> - <para> - If started with this option, gdm will init, but only start the - first local display and then wait for a GO message in the fifo - protocol. No greeter will be shown until the GO message is - sent. Also flexiserver requests will be denied and XDMCP will - not be started until GO is given. This is useful for - initialization scripts which wish to start X early, but where - you don't yet want the user to start logging in. So the script - would send the GO to the fifo once it is ready and GDM will - then continue. This functionality was added in version 2.5.90.0. - </para> - </listitem> - </varlistentry> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-nodaemon</term> + <listitem> + <para> + If this option is specified, then gdm does not fork into the + background when run. You can use just a single dash with this + option to preserve compatibility with XDM. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--no-console</term> + <listitem> + <para> + Tell the daemon that it should not run anything on the console. + This means that none of the local servers from the + <filename>[servers]</filename> section will be run, and the + console will not be used for communicating errors to the user. + An empty <filename>[servers]</filename> section automatically + implies this option. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--preserve-ld-vars</term> + <listitem> + <para> + When clearing the environment internally, preserve all variables + starting with LD_. This is mostly for debugging purposes. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--version</term> + <listitem> + <para> + Print the version of the GDM daemon. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--wait-for-go</term> + <listitem> + <para> + If started with this option, gdm will init, but only start the + first local display and then wait for a GO message in the fifo + protocol. No greeter will be shown until the GO message is + sent. Also flexiserver requests will be denied and XDMCP will + not be started until GO is given. This is useful for + initialization scripts which wish to start X early, but where + you don't yet want the user to start logging in. So the script + would send the GO to the fifo once it is ready and GDM will + then continue. This functionality was added in version 2.5.90.0. + </para> + </listitem> + </varlistentry> </variablelist> + </sect2> + <sect2 id="gdmgreeterlogincommandline"> + <title><filename>gdmchooser</filename> and <filename>gdmlogin</filename> + Command Line Options</title> + + <para> + The <filename>gdmgreeter</filename> and <filename>gdmlogin</filename> + are two different login programs, either can be used by GDM. + <filename>gdmgreeter</filename> is themeable with GDM themes while + <filename>gdmlogin</filename> is themable with GTK+ themes. These + programs are normally executed by the GDM daemon. Both programs + support standard GNOME options. + </para> </sect2> - <sect2 id="mainbinaries"> - <title>Other Main GDM Commands</title> + <sect2 id="gdmchoosercommandline"> + <title><filename>gdmchooser</filename> Command Line Options</title> <para> - Next are the two greeters, <filename>gdmlogin</filename> which is the - Standard Greeter, and <filename>gdmgreeter</filename> which is the - Graphical Greeter. There is also the <filename>gdmchooser</filename> - which is the XDMCP chooser application. These should all be run - only from GDM and not by itself, although <filename>gdmchooser</filename> - could theoretically be run as a standalone application which prints - the chosen host on the standard output. + The <filename>gdmchooser</filename> is the XDMCP chooser application. + The <filename>gdmchooser</filename> is normally executed by the GDM + daemon. It supports the following options for XDM compatibility. + This program supports standard GNOME options. </para> + <variablelist> + <title><filename>gdmchooser</filename> Command Line Options</title> + + <varlistentry> + <term>-xdmaddress=SOCKET</term> + <listitem> + <para> + Socket for XDM communication. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--clientaddress=ADDRESS</term> + <listitem> + <para> + Client address to return in response to XDM. This option is for + running gdmchooser with XDM, and is not used within GDM. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-connectionType=TYPE</term> + <listitem> + <para> + Connection type to return in response to XDM. This option is for + running gdmchooser with XDM, and is not used within GDM. + </para> + </listitem> + </varlistentry> + </variablelist> + </sect2> + + <sect2 id="gdmsetupcommandline"> + <title><filename>gdmconfig</filename> and + <filename>gdmsetup</filename> Command Line Options</title> + <para> - There is also the setup program which is the <filename>gdmsetup</filename> - command. Normally on systems that support the PAM userhelper, this - is setup such that when you run <filename>gdmsetup</filename> as - an ordinary user, it will first ask you for your root password. + <filename>gdmconfig</filename> is a wrapper script for running + <filename>gdmsetup</filename> for binary name compatibility. + <filename>gdmconfig</filename> is installed to the + <filename><sbin>/</filename> directory. </para> <para> - There is also the user picture setup program, <filename>gdmphotosetup</filename>. - This is run by users to setup their face browser picture. + gdmsetup runs a graphical program for modifying the GDM + configuration file, gdm.conf. Normally on systems that support the + PAM userhelper, this is setup such that when you run + <filename>gdmsetup</filename> as an ordinary user, it will first + ask you for your root password before starting. Otherwise, this + program may only be run as root. This program supports standard + GNOME options. </para> + </sect2> + + <sect2 id="gdmxnestchoosercommandline"> + <title><filename>gdmXnestchooser</filename> and + <filename>gdmXnest</filename> Command Line Options</title> <para> - There are also the commands <filename>gdm-stop</filename>, <filename>gdm-restart</filename> - and <filename>gdm-safe-restart</filename> which stop, restart, or restart the - GDM daemon after all users have logged out, respectively. These are - installed in the <filename><sbin>/</filename> directory. + The <filename>gdmXnestchooser</filename> command automatically gets + the correct display number, sets up access, and runs + <filename>Xnest</filename> with -indirect localhost. This way you + get an XDMCP chooser provided by your machine. You can also supply + as an argument the hostname whose chooser should be displayed, so + <filename>gdmXnestchooser somehost</filename> will run the XDMCP + chooser from host <filename>somehost</filename> inside an Xnest + session. You can make this command do a direct query instead by + passing the <filename>-d</filename> option as well. In addition to + the following options, this program also supports standard GNOME + options. </para> <para> - Finally there is the <filename>gdmflexiserver</filename> command which runs - flexible (on demand) X servers. + <filename>gdmXnest</filename> is a symbolic link to + <filename>gdmXnestchooser</filename> and is the same as using the + --no-query and --no-gdm-check options with + <filename>gdmXnestchooser</filename>. It is useful for running + <filename>Xnest</filename> without actually connecting somewhere. It + will print out the display setting on standard output that you can use + to connect to this server. This is useful mostly for developers who + perhaps wish to test their apps running on a completely separate server. </para> + <variablelist> + <title><filename>gdmXnestchooser</filename> and + <filename>gdmXnest</filename> Command Line Options</title> + + <varlistentry> + <term>-x, --xnest=STRING</term> + <listitem> + <para> + Xnest command line, default is "Xnest" + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-o, --xnest-extra-options=OPTIONS</term> + <listitem> + <para> + Extra options for Xnest, default is no options. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-n, --no-query</term> + <listitem> + <para> + Just run Xnest, no query (no chooser) + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-d, --direct</term> + <listitem> + <para> + Do direct query instead of indirect (chooser) + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-B, --broadcast</term> + <listitem> + <para> + Run broadcast instead of indirect (chooser) + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-b, --background</term> + <listitem> + <para> + Run in background + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>--no-gdm-check</term> + <listitem> + <para> + Don't check for running GDM + </para> + </listitem> + </varlistentry> + </variablelist> </sect2> - <sect2 id="extrabins"> - <title>Extra GDM Commands</title> + <sect2 id="gdmflexichoosercommandline"> + <title><filename>gdmflexichooser</filename> Command Line Options</title> <para> - There are some extra commands provided as well. First is the <filename>gdmXnestchooser</filename> - command. This command can run Xnest with all the right options and automatically getting - the correct display number and setting up access, and runs the server as an indirect query - to the local host by default. This way you get an XDMCP chooser provided by your machine. - You can also supply as an argument the hostname whose chooser should be displayed, so - <filename>gdmXnestchooser somehost</filename> will run the XDMCP chooser from host - <filename>somehost</filename> inside an Xnest. You can make this command do a direct query - instead by passing the <filename>-d</filename> option as well. + The <filename>gdmflexiserver</filename> command which runs flexible + (on demand) X servers. </para> <para> - Also useful is the <filename>gdmXnest</filename> command which is just for more - easily running Xnest on your machine. It will print out the display setting on standard - output that you can use to connect to this server. This is useful mostly for developers - who perhaps wish to test their apps running on a completely separate server. + <filename>gdmflexiserver</filename> lets a user log in once and then + quits. This is, for example useful if you are logged in as user A, + and user B wants to log in quickly but user A does not wish to log out. + The X server takes care of the virtual terminal switching so it works + transparently. There is also a flexi server as an Xnest, that is an + X server in a window. This is requested by running + <filename>gdmflexiserver</filename>. </para> <para> - For Graphical Greeter theme developers, there is the <filename>gdmthemetester</filename> - command which can run the Graphical Greeter in a simulated debug environment for any - selected theme. Run the command with no options to get help. + If there is more than one server defined with flexible=true, then the + user is given a dialog with those choices upon running gdmflexiserver </para> + <para> + The <filename>gdmflexiserver</filename> command option provides a way + to send arbitrary commands to GDM and can be used to debug problems or + in scripts, although <filename>gdmflexiserver</filename> does require + X to be running. + </para> + + <para> + In addition to the following options, + <filename>gdmflexiserver</filename> also supports standard GNOME + options. + </para> + + <variablelist> + <title><filename>gdmflexichooser</filename> Command Line Options</title> + + <varlistentry> + <term>-c, --command=COMMAND</term> + <listitem> + <para> + Send the specified protocol command to gdm + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-n, --xnest</term> + <listitem> + <para> + Xnest mode + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-l, --no-lock</term> + <listitem> + <para> + Do not lock current screen + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-d, --debug</term> + <listitem> + <para> + Debugging output + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>-a, --authenticate</term> + <listitem> + <para> + Authenticate before running --command + </para> + </listitem> + </varlistentry> + </variablelist> + </sect2> + + <sect2 id="gdmphotosetupcommandline"> + <title><filename>gdmphotosetup</filename> Command Line Options</title> + + <para> + Allows the user to select an image that will be used as the user's + photo by GDM's face browser, if enabled by GDM. The selected file + is stored as ~/.face. This program accepts standard GNOME options. + </para> + </sect2> + + <sect2 id="gdmthemetestercommandline"> + <title><filename>gdmthemetester</filename> Command Line Options</title> + + <para> + <filename>gdmthemetester</filename> takes two parameters. The first + parameter specifies the environment and the second parameter + specifies the path name or the name of a theme to view. + + This is a tool for viewing a theme outside of GDM. It is useful for + testing or viewing themes. <filename>gdmthemetester</filename> requires + that the system support <filename>gdmXnest</filename>. + + Note that themes can display differently depending on the theme's + "Show mode". <filename>gdmthemetester</filename> allows viewing the + themes in different modes via the environment option. Valid + environment values and their meanings follow: + + <screen> +console - In console mode. +console-timed - In console non-flexi mode. +flexi - In flexi mode. +xdmcp - In remote (XDMCP) mode. +remote-flexi - In remote (XDMCP) & flexi mode. + </screen> + </para> + </sect2> + + <sect2 id="gdmrestartcommandline"> + <title><filename>gdm-restart</filename> Command Line Options</title> + + <para> + <filename>gdm-restart</filename> stops and restarts GDM by sending + the GDM daemon a HUP signal. This command will immediately terminate + all sessions and log out users currently logged in with GDM. + <filename>gdm-restart</filename> is installed to the + <filename><sbin>/</filename> directory. + </para> + </sect2> + + <sect2 id="gdmsaferestartcommandline"> + <title><filename>gdm-safe-restart</filename> Command Line Options</title> + + <para> + <filename>gdm-safe-restart</filename> stops and restarts GDM by + sending the GDM daemon a USR1 signal. GDM will be restarted as soon + as all users log out. <filename>gdm-safe-restart</filename> is + installed to the <filename><sbin>/</filename> directory. + </para> + </sect2> + + <sect2 id="gdmstopcommandline"> + <title><filename>gdm-stop</filename> Command Line Options</title> + + <para> + <filename>gdm-stop</filename> stops GDM by sending the GDM daemon + a TERM signal. <filename>gdm-stop</filename> is installed to the + <filename><sbin>/</filename> directory. + </para> </sect2> </sect1> @@ -3313,62 +3939,69 @@ <para> GDM Themes can be created by creating an XML file that follows the specification in gui/greeter/greeter.dtd. Theme files are stored - in the directory <filename><share>/gdm/themes/<theme_name></filename>. - Usually this would be under <filename>/usr/share</filename>. The theme directory should contain a - file called <filename>GdmGreeterTheme.desktop</filename> which has similar format to other - .desktop files and looks like: + in the directory + <filename><share>/gdm/themes/<theme_name></filename>. + Usually this would be under <filename>/usr/share</filename>. The theme + directory should contain a file called + <filename>GdmGreeterTheme.desktop</filename> which has similar format + to other .desktop files and looks like: </para> <screen> - [GdmGreeterTheme] - Encoding=UTF-8 - Greeter=circles.xml - Name=Circles - Description=Theme with blue circles - Author=Bond, James Bond - Copyright=(c) 2002 Bond, James Bond - Screenshot=screenshot.png -</screen> +[GdmGreeterTheme] +Encoding=UTF-8 +Greeter=circles.xml +Name=Circles +Description=Theme with blue circles +Author=Bond, James Bond +Copyright=(c) 2002 Bond, James Bond +Screenshot=screenshot.png + </screen> + + <para> + The Name, Description, Author and Copyright fields can be translated + just like the other <filename>.desktop</filename>files. All the files + that are mentioned should be in the theme directory itself. The + Screenshot field points to a file which should be a 200x150 screenshot + of the theme in action (it is OK not to have one, but it makes it nicer + for user). The Greeter field points to an XML file that contains the + description of the theme. The description will be given later. + </para> <para> - The Name, Description, Author and Copyright fields can be translated just - like the other <filename>.desktop</filename>files. All the files that are mentioned should - be in the theme directory itself. The Screenshot field points to a file - which should be a 200x150 screenshot of the theme in action (it is OK - not to have one, but it makes it nicer for user). The Greeter field points - to an XML file that contains the description of the theme. The description - will be given later. + Once you have theme ready and installed you can test it with the + installed <filename>gdmthemetester</filename> script. This script + assumes that you also have installed the Xnest X server. It takes two + arguments, first the environment that should be used. This is one of + console, console-timed, flexi, remote-flexi, xdmcp. Where console is a + standard console login, console-timed is a console login with a timed + login going on, flexi is for any local flexible server, remote-flexi is + for flexi server that is not local (such as an Xnest flexiserver run + from a remote display) and xdmcp is for remote xdmcp connections. The + second argument is the theme name. So for example to test how things + look in the xdmcp mode with the circles theme you would run: </para> + <screen>gdmthemetester xdmcp circles</screen> + <para> - Once you have theme ready and installed you can test it with the installed - <filename>gdmthemetester</filename> script. This script assumes that you also have installed - the Xnest X server. It takes two arguments, first the environment that - should be used. This is one of console, console-timed, flexi, remote-flexi, - xdmcp. Where console is a standard console login, console-timed is a - console login with a timed login going on, flexi is for any local - flexible server, remote-flexi is for flexi server that is not local (such - as an Xnest flexiserver run from a remote display) and xdmcp is for remote - xdmcp connections. The second argument is the theme name. So for example - to test how things look in the xdmcp mode with the circles theme you would - run: - <screen>gdmthemetester xdmcp circles</screen> - Be sure to test all the environments with your theme, and make sure to test - how the caps lock warning looks by pressing caps lock. This is also a good - way to take screenshots, just take a screenshot of the Xnest window. This - can be done in GNOME by focusing the Xnest window and pressing - Alt-PrintScreen. + Be sure to test all the environments with your theme, and make sure to + test how the caps lock warning looks by pressing caps lock. This is + also a good way to take screenshots, just take a screenshot of the + Xnest window. This can be done in GNOME by focusing the Xnest window + and pressing Alt-PrintScreen. </para> <para> - Once you have all this done, then make a tarball that contains the directory - name (so that you could just untar it in the <filename>/usr/share/gdm/themes</filename> directory). - And this is the tarball you distribute and people can install from the - graphical setup program. You can do this with the commands: + Once you have all this done, then make a tarball that contains the + directory name (so that you could just untar it in the + <filename>/usr/share/gdm/themes</filename> directory). And this is the + tarball you distribute and people can install from the graphical setup + program. You can do this with the commands: <screen> - cd /usr/share/gdm/themes - tar czvf <theme_name>.tar.gz <theme_name>/ -</screen> +cd /usr/share/gdm/themes +tar czvf <theme_name>.tar.gz <theme_name>/ + </screen> </para> </sect2> @@ -3383,44 +4016,41 @@ Box nodes are container nodes for item nodes. Box nodes are specified as follows: <screen> - <box orientation="alignment" min-width="num" xpadding="num" - ypadding="num" spacing="num" homogeneous="bool"> -</screen> - Where "num" means number and bool means either "true" - or "false". The alignment value can be either "horizontal" or "vertical". - If you leave any property off it will default to - zero or "false" in case of "homogeneous", and "vertical" for - the orientation. +<box orientation="alignment" min-width="num" xpadding="num" +ypadding="num" spacing="num" homogeneous="bool"> + </screen> + Where "num" means number and bool means either "true" or "false". + The alignment value can be either "horizontal" or "vertical". + If you leave any property off it will default to zero or "false" in + case of "homogeneous", and "vertical" for the orientation. </para> - <para> - If the box is homogeneous then the children are allocated equal - amount of space. - </para> + <para> + If the box is homogeneous then the children are allocated equal + amount of space. + </para> - <para> - The "min-width" must be specified in pixels. Obviously there is - also a corresponding "min-height" property as well. - </para> + <para> + The "min-width" must be specified in pixels. Obviously there is + also a corresponding "min-height" property as well. + </para> </sect3> <sect3 id="fixednodes"> <title>Fixed Nodes</title> <para> - Fixed is a container that just has it's children scattered about - layed out with precise coordinates. The size of this container - is the biggest rectangle that contains all the children. Fixed - has no extra properties and so you just use: - <screen> - <fixed> -</screen> - Then you put other items with proper position nodes inside this. + Fixed is a container that has its children scattered about + laid out with precise coordinates. The size of this container + is the biggest rectangle that contains all the children. Fixed + has no extra properties and so you just use: + <screen><fixed></screen> + Then you put other items with proper position nodes inside this. </para> - <para> - The "toplevel" node is really just like a fixed node. - </para> + <para> + The "toplevel" node is really just like a fixed node. + </para> </sect3> <sect3 id="itemnodes"> @@ -3431,108 +4061,106 @@ nodes. Item nodes can have the following value for "type": </para> - <variablelist> - <varlistentry> - <term>entry</term> - <listitem> - <para> - Text entry field. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>list</term> - <listitem> - <para> - A list widget. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>label</term> - <listitem> - <para> - A text label. Must have a "text" node to specify the text. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>pixmap</term> - <listitem> - <para> - An pixmap image in a format that gdk-pixbuf supports like - PNG, JPEG, Tiff, etc...) - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>rect</term> - <listitem> - <para> - Rectangle. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>svg</term> - <listitem> - <para> - Scaled Vector Graphic image. - </para> - </listitem> - </varlistentry> - </variablelist> + <variablelist> + <varlistentry> + <term>entry</term> + <listitem> + <para> + Text entry field. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>list</term> + <listitem> + <para> + A list widget. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>label</term> + <listitem> + <para> + A text label. Must have a "text" node to specify the text. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>pixmap</term> + <listitem> + <para> + An pixmap image in a format that gdk-pixbuf supports like + PNG, JPEG, Tiff, etc...) + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>rect</term> + <listitem> + <para> + Rectangle. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>svg</term> + <listitem> + <para> + Scaled Vector Graphic image. + </para> + </listitem> + </varlistentry> + </variablelist> <para> For example: - <screen> - <item type="label"> -</screen> - Items can specify ID values which gives them a specific look - and feel or formatting. Furthermore you can customize the login - process by adding custom widgets with custom id's for some items - (currently only the list item) + <screen><item type="label"></screen> + Items can specify ID values which gives them a specific look and feel + or formatting. Furthermore you can customize the login process by + adding custom widgets with custom id's for some items (currently only + the list item) </para> <para> Entry items can have id values as follows: </para> - <variablelist> - <varlistentry> - <term>user-pw-entry</term> - <listitem> - <para> - Entry field for userid and password entry. This is - the field used for responses for the PAM/GDM questions - (Username, Password, etc..). - </para> - </listitem> - </varlistentry> - </variablelist> + <variablelist> + <varlistentry> + <term>user-pw-entry</term> + <listitem> + <para> + Entry field for userid and password entry. This is the field + used for responses for the PAM/GDM questions (Username, + Password, etc..). + </para> + </listitem> + </varlistentry> + </variablelist> <para> List items can have id values as follows: </para> - <variablelist> - <varlistentry> - <term>userlist</term> - <listitem> - <para> + <variablelist> + <varlistentry> + <term>userlist</term> + <listitem> + <para> A user browser list, so that users can pick their username by clicking on this instead of typing. - </para> - </listitem> - </varlistentry> - </variablelist> + </para> + </listitem> + </varlistentry> + </variablelist> <para> Furthermore, you can have an arbitrary id (I'd recommend starting @@ -3545,175 +4173,171 @@ Label items can have id values as follows: </para> - <variablelist> - <varlistentry> - <term>clock</term> - <listitem> - <para> + <variablelist> + <varlistentry> + <term>clock</term> + <listitem> + <para> Label the displays the date and time. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>pam-prompt</term> - <listitem> - <para> - Label the displays PAM prompt. This is the prompt that - PAM uses to ask for username, password, etc... - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>pam-error</term> - <listitem> - <para> - Label the displays PAM/GDM error messages. Such as when - user can't log in. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>pam-message</term> - <listitem> - <para> - Label the displays PAM message. These are messages that - PAM/GDM gives about state of the account, help about the - prompts and other information. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>timed-label</term> - <listitem> - <para> - Label that displays timed login information. - </para> - </listitem> - </varlistentry> - </variablelist> + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>pam-prompt</term> + <listitem> + <para> + Label the displays PAM prompt. This is the prompt that PAM + uses to ask for username, password, etc... + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>pam-error</term> + <listitem> + <para> + Label the displays PAM/GDM error messages. Such as when user + can't log in. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>pam-message</term> + <listitem> + <para> + Label the displays PAM message. These are messages that + PAM/GDM gives about state of the account, help about the + prompts and other information. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>timed-label</term> + <listitem> + <para> + Label that displays timed login information. + </para> + </listitem> + </varlistentry> + </variablelist> <para> Rectangles can have id values as follows: </para> - <variablelist> - <varlistentry> - <term>caps-lock-warning</term> - <listitem> - <para> - Displays an icon that shows if the - CAPS LOCK key is depressed. This rectangle - will be hidden/shown appropriately - </para> - </listitem> - </varlistentry> - </variablelist> + <variablelist> + <varlistentry> + <term>caps-lock-warning</term> + <listitem> + <para> + Displays an icon that shows if the + CAPS LOCK key is depressed. This rectangle + will be hidden/shown appropriately + </para> + </listitem> + </varlistentry> + </variablelist> <para> If an item is of type rect, the item can be a button. Buttons must also include a "button" value as follows: - <screen> - <item type="rect" id="disconnect_button" button="true">. -</screen> + <screen><item type="rect" id="disconnect_button" button="true">.</screen> </para> <para> Possible values for button ids are as follows: </para> - <variablelist> - <varlistentry> - <term>chooser_button</term> - <listitem> - <para> - Runs the XDMCP chooser. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>config_button</term> - <listitem> - <para> - Runs the GDM Setup program. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>disconnect_button</term> - <listitem> - <para> - Disconnect from remote session. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>language_button</term> - <listitem> - <para> - Displays the language selection dialog. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>halt_button</term> - <listitem> - <para> - Halt (shuts down) the system. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>reboot_button</term> - <listitem> - <para> - Reboot the system. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>session_button</term> - <listitem> - <para> - List and select from available sessions. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>suspend_button</term> - <listitem> - <para> - Suspend the system. - </para> - </listitem> - </varlistentry> - - <varlistentry> - <term>system_button</term> - <listitem> - <para> - Perform halt/reboot/suspend/etc. options - (if allowed by gdm configuration). Also - allows user to run configurator if user - enters root password (again if allowed - by gdm configuration). This is usually - now labeled Actions, and referred to as - the Actions menu. - </para> - </listitem> - </varlistentry> - - </variablelist> + <variablelist> + <varlistentry> + <term>chooser_button</term> + <listitem> + <para> + Runs the XDMCP chooser. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>config_button</term> + <listitem> + <para> + Runs the GDM Setup program. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>disconnect_button</term> + <listitem> + <para> + Disconnect from remote session. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>language_button</term> + <listitem> + <para> + Displays the language selection dialog. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>halt_button</term> + <listitem> + <para> + Halt (shuts down) the system. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>reboot_button</term> + <listitem> + <para> + Reboot the system. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>session_button</term> + <listitem> + <para> + List and select from available sessions. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>suspend_button</term> + <listitem> + <para> + Suspend the system. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term>system_button</term> + <listitem> + <para> + Perform halt/reboot/suspend/etc. options (if allowed by gdm + configuration). Also allows user to run configurator if user + enters root password (again if allowed by gdm configuration). + This is usually now labeled Actions, and referred to as the + Actions menu. + </para> + </listitem> + </varlistentry> + + </variablelist> </sect3> <sect3 id="positionnodes"> @@ -3722,57 +4346,52 @@ <para> Each item can specify its position and size via the "pos" node. For example: - <screen> - <pos x="0" y="4" width="100%" height="100%"/> -</screen> + <screen><pos x="0" y="4" width="100%" height="100%"/></screen> </para> - <para> - Both position and size can be given in percent and it will be taken - as the percentage of the size of the current container. For toplevel - items it's the percentage of the whole screen. - </para> - - <para> - For x and y, you can also specify a negative position which means position - from the right or bottom edge. But this only applies with absolute - coordinates. With percentage you can specify negative position and - it will be still from the same edge. - </para> - - <para> - The position also specifies the anchor of the item, this can be - "n", "ne", "e", "se", "s", "sw", "w" and "nw" or "center" which stand - for the different edges/corners or "center" for center. For example: - <screen> - <pos x="10%" y="50%" anchor="w" width="80%" height="95"/> -</screen> - </para> - - <para> - If the item contains a box, you can specify width and height to be - "box" to mean that they are supposed to be the width and height - of the box, that is the items in the box plus the padding. - </para> - - <para> - You can also specify an "expand" property to either be "true" - or false. If true then the child will be expanded in the box - as much as possible (that is it will be given more space if available). - </para> - - <para> - There are two extra properties you can specify (as of 2.4.4.3) for - labels (and labels only). The first - is "max-width" which will specify the maximum width of the label in - pixels. And the second is "max-screen-percent-width" which specifies - the maximum percentage of the screen width that the label can occupy. - By default no label will occupy more then 90% of the screen by width. - An example may be: - <screen> - <item type="label"> - <pos x="10%" max-screen-percent-width="50%"/> -</screen> + <para> + Both position and size can be given in percent and it will be taken + as the percentage of the size of the current container. For toplevel + items it's the percentage of the whole screen. + </para> + + <para> + For x and y, you can also specify a negative position which means + position from the right or bottom edge. But this only applies with + absolute coordinates. With percentage you can specify negative + position and it will be still from the same edge. + </para> + + <para> + The position also specifies the anchor of the item, this can be + "n", "ne", "e", "se", "s", "sw", "w" and "nw" or "center" which stand + for the different edges/corners or "center" for center. For example: + <screen><pos x="10%" y="50%" anchor="w" width="80%" height="95"/></screen> + </para> + + <para> + If the item contains a box, you can specify width and height to be + "box" to mean that they are supposed to be the width and height of + the box, that is the items in the box plus the padding. + </para> + + <para> + You can also specify an "expand" property to either be "true" or + false. If true then the child will be expanded in the box as much + as possible (that is it will be given more space if available). + </para> + + <para> + There are two extra properties you can specify (as of 2.4.4.3) for + labels (and labels only). The first is "max-width" which will + specify the maximum width of the label in pixels. And the second is + "max-screen-percent-width" which specifies the maximum percentage of + the screen width that the label can occupy. By default no label will + occupy more then 90% of the screen by width. An example may be: + <screen> +<item type="label"> +<pos x="10%" max-screen-percent-width="50%"/> + </screen> </para> </sect3> @@ -3784,82 +4403,86 @@ Some items may only display in certain modes, like when doing a remote display. Multiple values can be specified and must be separated with commas. The following values are possible: - </para> + </para> - <para> + <para> <filename>console</filename> - In console mode. - </para> - <para> + </para> + <para> <filename>console-fixed</filename> - In console non-flexi mode. - </para> - <para> + </para> + <para> <filename>console-flexi</filename> - In console & flexi mode. - </para> - <para> + </para> + <para> <filename>flexi</filename> - In flexi mode. - </para> - <para> + </para> + <para> <filename>remote</filename> - In remote mode. - </para> - <para> + </para> + <para> <filename>remote-flexi</filename> - In remote & flexi mode. - </para> + </para> - <para> - For example: - <screen> - <show modes="flexi,remote"/> -</screen> - </para> + <para> + For example: + <screen><show modes="flexi,remote"/></screen> + </para> + + <para> + You can also specify the "type" value to indicate that certain items + should only be displayed if the type is true. Valid values include + the following: + </para> + + <para> + <filename>chooser</filename>, if ChooserButton is set to "true" in + <filename>gdm.conf</filename> file. + </para> + <para> + <filename>config</filename>, if ConfigAvailable is set to "true" in + <filename>gdm.conf</filename> file. + </para> + <para> + <filename>halt</filename>, if HaltDaemon is specified in + <filename>gdm.conf</filename> file. + </para> + <para> + <filename>reboot</filename>, if RebootCommand is specified in + <filename>gdm.conf</filename> file. + </para> + <para> + <filename>suspend</filename>, if SuspendCommand is specified in + <filename>gdm.conf</filename> file. + </para> + <para> + <filename>system</filename>, if SystemMenu is specified in + <filename>gdm.conf</filename> file + </para> + <para> + <filename>timed</filename>, if TimedLoginEnabled is set to "true" in + <filename>gdm.conf</filename> file. + </para> <para> - You can also specify the "type" value to indicate that certain - items should only be displayed if the type is true. Valid values - include the following: - </para> - - <para> - <filename>chooser</filename>, if ChooserButton is set to "true" in <filename>gdm.conf</filename> file. - </para> - <para> - <filename>config</filename>, if ConfigAvailable is set to "true" in <filename>gdm.conf</filename> file. - </para> - <para> - <filename>halt</filename>, if HaltDaemon is specified in <filename>gdm.conf</filename> file. - </para> - <para> - <filename>reboot</filename>, if RebootCommand is specified in <filename>gdm.conf</filename> file. - </para> - <para> - <filename>suspend</filename>, if SuspendCommand is specified in <filename>gdm.conf</filename> file. - </para> - <para> - <filename>system</filename>, if SystemMenu is specified in <filename>gdm.conf</filename> file - </para> - <para> - <filename>timed</filename>, if TimedLoginEnabled is set to "true" in <filename>gdm.conf</filename> file. - </para> - - <para> For example: - <screen> - <show modes="console" type="system"/> -</screen> - </para> - - <para> - Note that if SystemMenu is off then all of halt, reboot, suspend, chooser - and config will not show, so this is a global toggle for them all. - See some of the standard themes for how the show modes are used. - </para> + <screen><show modes="console" type="system"/></screen> + </para> + + <para> + Note that if SystemMenu is off then all of halt, reboot, suspend, + chooser and config will not show, so this is a global toggle for them + all. See some of the standard themes for how the show modes + are used. + </para> </sect3> <sect3 id="noractprenodes"> <title>Normal/Active/Prelight Nodes</title> <para> - Depending on the item type, it can specify its color, font, or - image via the following tags: + Depending on the item type, it can specify its color, font, or + image via the following tags: </para> <para> @@ -3869,35 +4492,30 @@ <filename>active</filename> - when the item has active focus. </para> <para> - <filename>prelight</filename> - when the mouse is hovering over the item. + <filename>prelight</filename> - when the mouse is hovering over the + item. </para> <para> - When item is "rect" (alpha can be omitted and defaults to 0.0): - <screen> - <normal color="#ffffff" alpha="0.0"> -</screen> + When item is "rect" (alpha can be omitted and defaults to 0.0): + <screen><normal color="#ffffff" alpha="0.0"></screen> </para> <para> - When item is "label": - <screen> - <normal color="#ffffff" font="Sans 14"/> -</screen> + When item is "label": + <screen><normal color="#ffffff" font="Sans 14"/></screen> </para> <para> - When the item type is "pixmap" or "SVG", then the normal, active, - and prelight tags specify the images to use as follows: - <screen> - <normal file="picture.png" tint="#dddddd"/> -</screen> + When the item type is "pixmap" or "SVG", then the normal, active, + and prelight tags specify the images to use as follows: + <screen><normal file="picture.png" tint="#dddddd"/></screen> </para> <para> - Note that relative pathnames are assumed to be in the same - directory as the theme <filename>.xml</filename> file in - <filename><share>/gdm/themes/<theme_name></filename>. + Note that relative pathnames are assumed to be in the same + directory as the theme <filename>.xml</filename> file in + <filename><share>/gdm/themes/<theme_name></filename>. </para> </sect3> @@ -3905,22 +4523,18 @@ <title>Text Node</title> <para> - Text tags are used by labels. They can be used to display - localized text as follows (if the "xml:lang" attribute is - omitted, the C locale is assumed): - <screen> - <text xml:lang="fr">Option</text> -</screen> + Text tags are used by labels. They can be used to display + localized text as follows (if the "xml:lang" attribute is + omitted, the C locale is assumed): + <screen><text xml:lang="fr">Option</text></screen> </para> - <para> - You can include pango markup in the text nodes for labels, however - you must encode it. So for example to have the label of - "foo<sup>bar</sup>", you must type: - <screen> - <text">foo&lt;sup&gt;bar&lt;/sup&gt;</text> -</screen> - </para> + <para> + You can include pango markup in the text nodes for labels, however + you must encode it. So for example to have the label of + "foo<sup>bar</sup>", you must type: + <screen><text">foo&lt;sup&gt;bar&lt;/sup&gt;</text></screen> + </para> </sect3> @@ -3928,14 +4542,14 @@ <title>Stock</title> <para> - Certain common localized labels can be specified via the stock - tags. The "text" tag is ignored if the "stock" tag is used. You - should really use the stock labels rather then just putting all - the translations into the themes. This gives faster load times - and likely better translations. The following values are valid: + Certain common localized labels can be specified via the stock + tags. The "text" tag is ignored if the "stock" tag is used. You + should really use the stock labels rather then just putting all + the translations into the themes. This gives faster load times + and likely better translations. The following values are valid: </para> - <para> + <para> <filename>caps-lock-warning</filename>, _("You've got capslock on!") </para> <para> @@ -3966,7 +4580,8 @@ <filename>system</filename>, _("_Actions") (Formerly "S_ystem") </para> <para> - <filename>timed-label</filename>, _("User %s will login in %d seconds") + <filename>timed-label</filename>, + _("User %s will login in %d seconds") </para> <para> <filename>username-label</filename>, _("Username:") @@ -3976,58 +4591,163 @@ </para> <para> - For example: - <screen> - <stock type="welcome-label"/> -</screen> + For example: + <screen><stock type="welcome-label"/></screen> </para> - </sect3> <sect3 id="customwidgetry"> <title>Custom Widgetry</title> <para> - Currently there is one item which can be customizable and this is - the list item. If you need to ask the user extra things, such as - to pick from a list of places to log into, or set of custom login - sessions you can setup the list item and add listitem children that - describe the choices. Each listitem must have an id and a text child. - The choice will be recorded in the file - <filename><ServAuthDir>/<display>.GreeterInfo</filename> - as <filename><list id>=<listitem id></filename>. + Currently there is one item which can be customizable and this is + the list item. If you need to ask the user extra things, such as + to pick from a list of places to log into, or set of custom login + sessions you can setup the list item and add listitem children that + describe the choices. Each listitem must have an id and a text + child. The choice will be recorded in the file + <filename><ServAuthDir>/<display>.GreeterInfo</filename> + as <filename><list id>=<listitem id></filename>. </para> <para> - For example suppose we are on display :0, <filename>ServAuthDir</filename> - is <filename>/var/gdm</filename> - and we have the following in the theme: + For example suppose we are on display :0, + <filename>ServAuthDir</filename> is <filename>/var/gdm</filename> + and we have the following in the theme: </para> - <screen> - <item type="list" id="custom-config"> - <pos anchor="nw" x="1" y="1" height="200" width="100"/> - <listitem id="foo"> - <text>Foo</text> - </listitem> - <listitem id="bar"> - <text>Bar</text> - </listitem> - </item> -</screen> + <screen> +<item type="list" id="custom-config"> +<pos anchor="nw" x="1" y="1" height="200" width="100"/> +<listitem id="foo"> +<text>Foo</text> +</listitem> +<listitem id="bar"> +<text>Bar</text> +</listitem> +</item> + </screen> <para> - Then if the user chooses 'Foo' then <filename>/var/gdm/:0.GreeterInfo</filename> will - contain: - <screen> - custom-config=foo -</screen> + Then if the user chooses 'Foo' then + <filename>/var/gdm/:0.GreeterInfo</filename> will contain: + <screen>custom-config=foo</screen> </para> - </sect3> </sect2> </sect1> + <sect1 id="accessibility"> + <title>Accessibility</title> + <para> + GDM supports "Accessible Login" to allow users to log in to their + desktop session even if they cannot easily use the screen, mouse, + or keyboard in the usual way. This feature allows the user to launch + assistive technologies at login time by means of special "gestures" + from the standard keyboard and from a keyboard, pointing device, or + switch device attached to the USB or PS/2 mouse port. It also + allows the user to change the visual appearance of the login UI + before logging in, for instance to use a higher-contrast color + scheme for better visibility. GDM only supports accessibility with + the Standard Greeter, so the "Greeter" parameter in gdm.conf must be + set to the Standard Greeter "gdmlogin". + </para> + + <sect2 id="accessibilityconfig"> + <title>Accessibility Configuration</title> + <para> + In order to enable Accessible Login, the system administrator must + make some changes to the default login configuration by manually + modifying three human-readable configuration files, stored in + gdm.conf, AccessKeyMouseEvents and AccessDwellMouseEvents. + </para> + + <para> + In order to allow users to change the color and contrast scheme of + the login dialog, make sure the "AllowThemeChange" parameter in + gdm.conf is set to "true". + </para> + + <para> + To restrict user changes to the visual appearance to a subset of + available themes, the "GtkThemesToAllow" parameter in gdm.conf can + be set to a list of acceptable themes separated by commas. For + example: + </para> + + <screen>GtkThemesToAllow=HighContrast,HighContrastInverse</screen> + + <para> + To enable the use of assistive technologies such as the Onscreen + Keyboard, Screen Reader, or Magnifier, the "AddGtkModules" + parameter in gdm.conf must be uncommented and set to "true". Also + the "GtkModulesList" parameter must be uncommented and set as + follows: + </para> + + <screen>GtkModulesList=gail:atk-bridge:dwellmouselistener:keymouselistener</screen> + + <para> + System administrators may wish to load only the minimum subset of + these modules which is required to support their user base. + Depending on the end-user needs, not all of the above GtkModules + may need to be loaded. If your end-users need the integrated + Screen Reader and Magnifier, you must include "gail" and + "atk-bridge". If your end-users will be using a pointing device + without buttons or switches, include "dwellmouselistener". If + some of your users will use pointing devices with switches, + alternative physical keyboards, or switch/button devices, include + "keymouselistener". Including all four is suitable for most + system configurations. The Onscreen Keyboard can operate without + gail and atk-bridge, but with a reduced feature set; for optimum + accessibility we recommend including gail and atk-bridge. + </para> + + <para> + Once "keymouselistener" and/or "dwellmouselistener" have been + added to the GtkModules loaded by GDM, you can assign end-user + actions with the launching of specific assistive technologies. + These gesture associations are contained in files + AccessKeyMouseEvents and AccessDwellMouseEvents, respectively. + The gesture format is described in the two configuration files. + </para> + + <para> + The AccessKeyMouseEvents file controls the keymouselistener + Gesture Listener and is used to define key-press, mouse button, + or XInput device sequences that can be used to launch programs + needed for accessibility. In order to reduce the likelihood of + unintentional launch, these 'gestures' may be associated with + multiple switch presses and/or minimum durations. + </para> + + <para> + The DwellKeyMouseEvents file controls the dwellmouselistner and + supports gestures that involve only motion of a pointing device + such as the system mouse of an alternative pointing device such + as a head pointer or trackball may also be defined. All gestures + are specified by the same syntax; that is, there is no distinction + between a 'core mouse' gesture and motion from an alternate input + device. + </para> + + <para> + Motion gestures are defined as "crossing events" into and out of + the login dialog window. If the 'dwellmouselistener' GtkModule + is loaded, alternative pointing devices are temporarily "latched" + to the core pointer, such that motion from alternative devices + results in movement of the onscreen pointer. + </para> + + <para> + In order to use text-to-speech services at login time (for + instance, when using the Screen Reader in speech mode) on some + operating systems, the gdm user must be made a member of the + "audio" group + </para> + </sect2> + </sect1> + <sect1 id="exampleconf"> <title>Example Configurations</title> @@ -4040,45 +4760,46 @@ <title>Terminal Lab With One Server</title> <para> - Suppose you want to make a lab full of X terminals that all connect - to one main server. So let's call one X terminal <filename>xterminal</filename> - and lets call the server <filename>appserver</filename>. You install - GDM on both. + Suppose you want to make a lab full of X terminals that all connect + to one main server. So let's call one X terminal + <filename>xterminal</filename> and lets call the server + <filename>appserver</filename>. You install GDM on both. </para> <para> - On <filename>appserver</filename> you enable XDMCP, so you have + On <filename>appserver</filename> you enable XDMCP, so you have <screen> - [xdmcp] - Enable=true -</screen> - If you want no local screens here, you can then - make the <filename>[servers]</filename> section empty. +[xdmcp] +Enable=true + </screen> + If you want no local screens here, you can then + make the <filename>[servers]</filename> section empty. </para> <para> - On the <filename>xterminal</filename> you disable XDMCP (you don't - want anyone to connect to the xterminal really). You will add a server type - perhaps called <filename>Terminal</filename> as follows: - <screen> - [server-Terminal] - name=Terminal server - command=/usr/X11R6/bin/X -terminate - flexible=false - handled=false -</screen> - This definition should in fact be included in the standard configuration - file. Notice that we made the <filename>handled</filename> key false - since we don't want GDM to handle this server localy. Also note that - we have not yet added the <filename>-query</filename> argument, you can add - that here, or in the <filename>[servers]</filename> section. We'll define - our local servers as follows: - <screen> - [servers] - 0=Terminal -query appserver -</screen> - This will run a direct XDMCP query to the server named - <filename>appserver</filename>. + On the <filename>xterminal</filename> you disable XDMCP (you don't + want anyone to connect to the xterminal really). You will add a + server type perhaps called <filename>Terminal</filename> as follows: + <screen> +[server-Terminal] +name=Terminal server +command=/usr/X11R6/bin/X -terminate +flexible=false +handled=false + </screen> + This definition should in fact be included in the standard + configuration file. Notice that we made the + <filename>handled</filename> key false since we don't want GDM to + handle this server localy. Also note that we have not yet added the + <filename>-query</filename> argument, you can add that here, or in the + <filename>[servers]</filename> section. We'll define our local + servers as follows: + <screen> +[servers] +0=Terminal -query appserver + </screen> + This will run a direct XDMCP query to the server named + <filename>appserver</filename>. </para> </sect2> @@ -4086,62 +4807,65 @@ <title>Terminal Lab With Two Or More Servers</title> <para> - Suppose you want to make a lab full of X terminals that all connect - to some choice of servers. For now let's make it <filename>appserverone</filename> - and <filename>appservertwo</filename>. Again we'll call our example - X terminal machine <filename>xterminal</filename>. The setup on - both servers is the same as with the case of one server in the previous - section. You do not need to explicitly enable indirect queries on the - server since we'll run the choosers locally on the X terminals. + Suppose you want to make a lab full of X terminals that all connect + to some choice of servers. For now let's make it + <filename>appserverone</filename> and + <filename>appservertwo</filename>. Again we'll call our example X + terminal machine <filename>xterminal</filename>. The setup on both + servers is the same as with the case of one server in the previous + section. You do not need to explicitly enable indirect queries on the + server since we'll run the choosers locally on the X terminals. </para> <para> - So on the <filename>xterminal</filename> you again disable XDMCP. - You will add a server type perhaps called <filename>Chooser</filename> as follows: - <screen> - [server-Chooser] - name=Chooser server - command=/usr/X11R6/bin/X - flexible=false - chooser=true -</screen> - And again this definition should in fact be included in the standard configuration - file. Notice that we made the <filename>chooser</filename> key true here. - This will run the XDMCP chooser for this server, and when the user chooses - a host GDM will run a query for that host. Then we'll define - our local servers as follows: - <screen> - [servers] - 0=Chooser -</screen> + So on the <filename>xterminal</filename> you again disable XDMCP. + You will add a server type perhaps called <filename>Chooser</filename> + as follows: + <screen> +[server-Chooser] +name=Chooser server +command=/usr/X11R6/bin/X +flexible=false +chooser=true + </screen> + And again this definition should in fact be included in the standard + configuration file. Notice that we made the + <filename>chooser</filename> key true here. This will run the XDMCP + chooser for this server, and when the user chooses a host GDM will run + a query for that host. Then we'll define our local servers as follows: + <screen> +[servers] +0=Chooser + </screen> </para> <para> - The XDMCP chooser on the X terminal will normally give a broadcast query to - see which servers exist on the network. If the two servers are not reachable - by a broadcast query, you must add them by hand to the configuration file. - So in the <filename>[chooser]</filename> section you would have: - <screen> - Hosts=appserverone,appservertwo -</screen> - and any other servers you wish the users to be able to connect to. + The XDMCP chooser on the X terminal will normally give a broadcast + query to see which servers exist on the network. If the two servers + are not reachable by a broadcast query, you must add them by hand to + the configuration file. So in the <filename>[chooser]</filename> + section you would have: + <screen>Hosts=appserverone,appservertwo</screen> + and any other servers you wish the users to be able to connect to. </para> <para> - Sometimes you may want to run the chooser on the server side however. Then - what you want to do is to run a configuration similar to the previous - section about the one server configuration with XDMCP indirect queries - enabled on <filename>appserver</filename> and on the X terminals you'd have - <screen> - [servers] - 0=Terminal -indirect appserver -</screen> - This way for example you only have to maintain one <filename>Hosts</filename> - entry. However as a disadvantage then, the <filename>appserver</filename> - must then always be available. So it's not good for situations where - you want to have serveral servers and not all of them have to be on - all the time. You could also have one of the X terminals handle - indirect XDMCP queries and serve up the chooser to the other X terminals. + Sometimes you may want to run the chooser on the server side however. + Then what you want to do is to run a configuration similar to the + previous section about the one server configuration with XDMCP + indirect queries enabled on <filename>appserver</filename> and on the + X terminals you'd have + <screen> +[servers] +0=Terminal -indirect appserver + </screen> + This way for example you only have to maintain one + <filename>Hosts</filename> entry. However as a disadvantage then, + the <filename>appserver</filename> must then always be available. So + it's not good for situations where you want to have serveral servers + and not all of them have to be on all the time. You could also have + one of the X terminals handle indirect XDMCP queries and serve up the + chooser to the other X terminals. </para> </sect2> </sect1> |