Re: GDM man pages
- From: George <jirka 5z com>
- To: Brian Cameron <Brian Cameron Sun COM>
- Cc: gdm sunsite dk
- Subject: Re: GDM man pages
- Date: Wed, 4 Aug 2004 17:46:20 -0700
On Wed, Aug 04, 2004 at 04:24:30PM -0500, Brian Cameron wrote:
>
> Brian
Wow, that's pretty long. Are you sure all this needs to be in the man pages?
I mean large part is duplicating the main docs, perhaps the man page should
just give the very basic overview info and refer to the main docs. This way
the information does not get out of sync.
> NAME
> gdm-restart
> gdm-safe-restart
> gdm-stop
>
> SYNOPSIS
>
> gdm-restart
> gdm-safe-restart
> gdm-stop
>
> DESCRIPTION
>
> gdm-restart 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
>
> gdm-safe-restart stops and restarts GDM by sending the GDM daemon
> a USR1 signal. This command will do nothing if there are users
> currently logged in with GDM.
This should say: GDM will be restarted as soon as all users log out.
> gdm-stop stops GDM by sending the GDM daemon a TERM signal.
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmXnestchooser(1), gdmflexiserver(1),
> gdmphotosetup(1), gdmsetup(1), gdmthemetester(1), gdmconfig(1M)
>
> AUTHOR
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
> NAME
> gdm - GNOME Display Manager
>
> SYNOPSIS
> gdm, gdm-binary [ -nodaemon ] [ --no-console ] [ --preserve-ld-vars ]
> [ --version ] [ --wait-for-go ] [ --monte-carlo-sqrt2 ]
>
> gdmlogin, gdmgreeter [ gnome-std-options]
>
> gdmchooser [ -xdmaddress=SOCKET ] [ -clientaddress=ADDRESS ]
> [ -connectionType=TYPE ] [ gnome-std-options]
>
> DESCRIPTION
> GDM is the GNOME Display Manager, a program used for login session
> management. When no user is logged in the console, it displays a
> graphical user interface allowing the user to enter their username
> and password. GDM supports XDMCP and supports flexible or on-demand
> servers via the gdmflexiserver(1) command.
>
> The gdm program is a wrapper script that launches gdm-binary
> passing along any options. Before launching gdm-binary, the
> gdm wrapper script will source the /etc/profile 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.
>
> Upon startup the GDM daemon parses its config file gdm.conf. For each
> of the local displays gdm-binary forks an Xserver and a slave
> process. The main gdm-binary 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 gdmflexiserver(1) command.
>
> The GDM slave process opens the display and starts either the Graphical
> Greeter or the Standard Greeter. This is set by the "Greeter" parameter
> in gdm.conf for console login and the "RemoteGreeter" parameter for
> XDMCP logins. This parameter should be set to "gdmgreeter" to use the
> Graphical Greeter or "gdmlogin" to use the Standard Greeter. The
> Standard Greeter is lower-bandwidth, so it tends to be more appropriate
> for remote logins. The GDM daemon communicates asynchronously with
> the slave process through a pipe.
>
> From either the Graphical Greeter or the Standard Greeter it is
> possible to launch the Chooser program gdmchooser in order to start
> remote XDMCP login sessions. Although disabled by default, it is
> also possible to launch the Setup program gdmsetup(1) in order to
> edit the configuration choices in gdm.conf. The root password
> must be entered in order to launch the Setup program. The ability
> to launch the Setup program is disabled by default since it does
> run with root permissions and allows gdm to be configured in ways
> that affect security.
>
> GDM relies on of PAM, Pluggable Authentication Modules for
> password authentication, but supports regular crypt() and shadow
> passwords on legacy systems. On Solaris, logindevperm(4) is used by
> GDM to set proper device permissions for the user on login.
>
> All operations on user files are done with the effective user id of
> the user. If the sanity check fails on the user's .Xauthority file,
> a fallback cookie is created in /tmp.
>
> STANDARD GREETER
> 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 cooresponds to the executable gdmlogin.
>
> The text entry field is used for entering logins, passwords,
> passphrases etc. It 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.
>
> The menu bar in the top of the greeter enables the user to select the
> requested session type/desktop environment, change the GTK+ theme (if
> enabled) 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.
>
> 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 <share>/faces/ directory (though
> this can be configured with the GlobalFaceDir configuration option)
> and the filename should be the name of the user, optionally with a
> .png appended.
>
> The users can place their icons in a file called ~/.face, and they can
> use the program gdmphotosetup(1) to graphically configure this.
>
> 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.
>
> 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.
>
> To filter out unwanted user names in the browser, the "Exclude" parameter
> in gdm.conf can be set with a list of usernames separated by commas. The
> greeter will automatically ignore usernames listed, and furthermore
> exclude users whose UIDs are lower then the "MinimalUID" parameter, 100
> by default.
>
> 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.
>
> 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 it must be readable to the GDM user.
>
> GRAPHICAL GREETER
> The Graphical Greeter is a greeter interface that takes up the whole
> screen and is themable. The Standard Greeter cooresponds to the
> executable gdmlogin.
>
> Themes can be selected and new themes can be installed by the gdmsetup(1)
> program or by setting the "GraphicalTheme" parameter in gdm.conf. The
> location of themes is specified by the "GraphicalThemeDir" parameter.
>
> 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.
>
> 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
> wish to do some action.
>
> CHOOSER
> The Chooser displays a list of local machines that will accept XDMCP
> connections. The user can also specify a machine by entering its name
> directly. Once a machine is selected, a remote XDMCP session can be
> started. The Chooser can be launched on the console directly from
> the Standard or Graphical Greeter. The chooser corresponds to the
> executable gdmchooser.
>
> XDMCP
> GDM can be configured to enable XDMCP so that users can log in
> remotely and will launch a graphical chooser that allows a remote
> login session to be started. Refer to the [xdmcp] section of the
> gdm.conf file.
>
> GDM 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.
>
> 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.
>
> By default GDM listens to UDP port 177, although this can be
> configured. It will respond to QUERY and BROADCAST_QUERY requests
> by sending a WILLING packet to the originator.
>
> 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 only supports the MIT-MAGIC-COOKIE-1 authentication system.
> 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.
>
> CONTROLLING GDM
> 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.
>
> Commands
>
> To stop GDM, you can either send the TERM signal to the main daemon or
> run the gdm-stop(1M) command which is in the /sbin directory. To restart
> GDM, you can either send the HUP signal to the main daemon or run the
> gdm-restart(1M) command which is also in the /sbin 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 gdm-safe-restart(1M)
> command which is in the /sbin directory as well.
>
> The gdmflexiserver(1) command can be used to communicate with the GDM
> daemon and to start new flexible (on demand) servers.
>
> CONFIGURATION
> The gdm.conf file contains comments that explain each configuration
> parameter.
>
> SECURITY
> GDM is best used with a dedicated user id and a group id which it
> uses for its graphical interfaces such as gdmgreeter, gdmlogin, and
> gdmchooser. You can choose the name of this user and group in the
> [daemon] section of the gdm.conf file.
>
> The GDM user, and group, which are normally just GDM 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.
>
> 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 (specified by the
> ServAuthDir parameter in gdm.conf), 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
> nobody.
>
> The server authorization directory (the ServAuthDir) 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 root:gdm 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.
>
> 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.
>
> ACCESSIBILITY
> 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".
>
> 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.
>
> 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".
>
> To restrict user changes to the visual appearance to a subset of
> available themes, the "GtkThemesToAllow" parameter in gdm.con can
> be set to a list of acceptable themes separated by commas. For example:
>
> GtkThemesToAllow=blueprint,HighContrast,HighContrastInverse
>
> 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 to
> "gail:atk-bridge:dwellmouselistener:keymouselistener".
>
> 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.
>
> 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 files.
>
> The AccessKeyMouseEvents file controlls the keymouselistener
> Gestuer 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.
>
> The DwellKeyMouseEvents file controlls 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.
>
> 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.
>
> 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
>
> LOGGING
> GDM itself will use syslog to log errors or status. It can also log
> debugging information, if enabled in the gdm.conf file.
>
> Output from the various X servers is stored in the GDM log directory,
> which is configurable, but is usually <var>/log/gdm/. The output from
> the session can be found in a file called <display>.log. Four older
> files are also stored with .1 through .4 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.
>
> The output from the user session is redirected to ~/.xsession-errors
> before even the PreSession 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.
>
> You can suppress the 10 second warning by returning code 66 from the
> Xsessionscript or from your session binary (the default Xsession
> 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.
>
> The session output is piped through the GDM daemon and so the
> ~/.xsession-errors 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.
>
> Note that some distributors seem to override the ~/.xsession-errors
> redirection and do it themselves in their own Xsession script (set by
> the BaseXsession configuration key) which means that GDM will not be
> able to trap the output and cap this file. You also lose output from the
> PreSession 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 BaseXsession configuration key for more
> information, especially on how to handle multiple display managers
> using the same script.
>
> 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
> /tmp directory named /tmp/xses-<user>.XXXXXX where the XXXXXX are some
> random characters.
>
> If you run a system with quotas set, it would be good to delete the
> ~/.xsession-errors in the PostSession script. Such that this log file
> doesn't unneccesairly stay around.
>
> OPTIONS
> The gdm and gdm-binary commands take the following options:
>
> --help
> Gives a brief overview of the command line options.
>
> -nodaemon
> 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.
>
> --no-console
> Tell the daemon that it should not run anything on the console.
> This means that none of the local servers from the [servers]
> section of the gdm.conf configuration file will be run, and the
> console will not be used for communicating errors to the user.
> An empty [servers] section automatically implies this option.
>
> --preserve-ld-vars
> When clearing the environment internally, preserve all variables
> starting with LD_. This is mostly for debugging purposes.
>
> --version
> Print the version of the GDM daemon.
>
> --wait-for-go
> 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.
>
> --monte-carlo-sqrt2
Dude, this is an easter egg, it should not be documented :)
>
> The gdmchooser command accepts the following options:
>
> -xdmaddress=SOCKET
> Socket for xdm communication
>
> -clientaddress=ADDRESS
> Client address to return in response to xdm
>
> -connectionType=TYPE
> Connection type to return in response to xdm
It should be noted that these options are purely for running gdmchooser with
xdm. They are not used within gdm. That is, it just makes it command line
compatible with xdm's chooser.
> The gdmlogin, gdmgreeter, and gdmchooser programs accept the
> standard GTK+ options, refer to gnome-std-options(5). These programs
> are launched by the GDM daemon and should not be run directly by the
> user.
>
> RETURN VALUE
> Exit values are:
>
> 0 Successful completion.
>
> !0 Error condition occurred.
>
> FILES
> The sysadmin can specify the maximum file size GDM should accept in the
> gdm.conf file, 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.
>
> 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 in the gdm.conf file determines whether
> GDM should accept files writable by the user's group or others.
> These are ignored by default.
>
> 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 set
> the "UserAuthDir" parameter in the gdm.conf file to some local directory
> such as /tmp. 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 UserAuthFBDir defined in
> the gdm.conf file, which is usually /tmp. This can be changed by
> setting the "NeverPlaceCookiesOnNFS" parameter in the [security]
> section of the gdm.conf file to false.
>
> GDM Login Scripts and Session Files:
>
> /etc/X11/gdm/Init/<hostname>
> /etc/X11/gdm/Init/Default
> /etc/X11/gdm/Init/XDMCP
> /etc/X11/gdm/PostLogin/<hostname>
> /etc/X11/gdm/PostLogin/XDMCP
> /etc/X11/gdm/PostLogin/Default
> /etc/X11/gdm/PreSession/<hostname>
> /etc/X11/gdm/PreSession/XDMCP
> /etc/X11/gdm/PreSession/Default
> /etc/X11/gdm/Xsession
> /etc/X11/gdm/PostSession/<hostname>
> /etc/X11/gdm/PostSession/XDMCP
> /etc/X11/gdm/PostSession/Default
> GDM Login Scripts, described below
>
> /usr/share/xsessions/*.desktop
> Session files
>
> ~/.dmrc
> Default user session
>
> When the X server has been successfully started, GDM will try to run
> the script called Init/<displayname>. I.e. Init/:0 for the first local
> display. If this file is not found, GDM will attempt to to run
> Init/<hostname>. I.e. Init/somehost. If this still is not found, GDM
> will try Init/XDMCP for all XDMCP logins or Init/Flexi for all on
> demand flexible servers. If none of the above were found, GDM will run Init/Default. The script will be run as root and GDM blocks until it
> terminates. Use the Init/* 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.
>
> 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 "KillInitClients" parameter in gdm.conf.
>
> When the user has been successfully authenticated GDM tries the
> scripts in the PostLogin directory in the same manner as for the Init
> 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 pam_mount module if you can for
> this). You have the $USER and $DISPLAY 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.
>
> After the user session has been setup from the GDM side of things,
> GDM will run the scripts in the PreSession directory, again in the
> same manner as the Init directory. Use this script for local session
> management or accounting stuff. The $USER environment variable
> contains the login of the authenticated user and $DISPLAY 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 $X_SERVERS
> environmental variable is set and this points to a fake generated X
> servers file for use with the sessreg accounting program.
>
> After this the users session is started. The available session
> executables are taken from the Exec= line in the .desktop files in
> the path specified by SessionDesktopDir. The user picks from these
> sessions at login time and GDM will read the file ~/.dmrc for the
> user's default. The default GNOME session uses the Xsession script.
> The script is run as the user, and really this is the user session.
>
> This script should really load the users profile and generally do all
> that is needed to launch a session. Since many systems reset the
> language selections done by GDM, GDM will also set the $GDM_LANG
> 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 $GDM_LANG is not
> set.
>
> When the user terminates his session, the PostSession script will be
> run. Again operation is similar to Init, PostLogin and PreSession.
> Again the script will be run with root privileges, the slave daemon
> will block and the $USER environment variable will contain the name
> of the user who just logged out and $DISPLAY 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 $X_SERVERS environmental variable is set and this points to a
> fake generated x servers file for use with the sessreg accounting
> program.
>
> Note that the PostSession 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.
>
> Except for the Xsession script all of these scripts will also have
> the environment variable $RUNNING_UNDER_GDM set to yes, so that you
> could perhaps use similar scripts for different display managers. The
> Xsession will always have the $GDMSESSION set to the basename of the
> session that the user chose to run without the .desktop extension. In
> addition $DESKTOP_SESSION is also set to the same value and in fact
> this will also be set by KDM in future versions.
>
> Neither of the Init, PostLogin, PreSession or PostSession scripts are
> necessary and can be left out. The Xsession script is however
> required as well as at least one session .desktop file.
>
> Configuration Files:
>
> /etc/X11/gdm/gdm.conf
> Contains GDM configuration and documentation.
>
> Themes:
>
> /usr/share/gdm/themes
> This can by configured with the GraphicalThemeDir parameter in
> gdm.conf.
>
> Face Browser:
>
> ~/.face
> User-defined icon to be used by GDM face browser.
>
> Gesture Listener Files:
>
> /etc/X11/gdm/modules/AccessDwellMouseEvents
> Configuration for the dwellmouselistner
>
> /etc/X11/gdm/modules/AccessKeyMouseEvents
> Configuration for the keymouselistner
>
> Logging:
>
> /var/log/gdm/<display>.log
> Output from Xserver for each session. This can be configured with
> the LogDir parameter in gdm.conf.
>
> ~/.xsession-errors
> Output from user's session.
>
> /tmp/xsess-<user>.XXXXXXo
> Output from session in failsafe mode or if ~/.xsession-errors can
> not be written.
>
> Sockets:
>
> /tmp/.gdm_socket
> Temporary file used for GDM socket communications.
>
> Process-ID:
>
> /var/run/gdm.pid
> Stores the ProcessID for the running GDM daemon. This can be
> configured with the PidFile parameter in gdm.conf.
>
> Xserver authentication directory:
> /var/lib/gdm
> Stores Xserver authentication files. This can be configured with the
> ServAuthDir parameter in gdm.conf
>
> ATTRIBUTES
> See attributes(5) for descriptions of the following attributes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> SEE ALSO
> gdmXnestchooser(1), gdmflexiserver(1), gdmphotosetup(1), gdmsetup(1),
> gdmthemetester(1), gdm-restart(1M), gdm-safe-restart(1M),
> gdm-stop(1M), gdmconfig(1M), gnome-std-options(5), Xserver(1),
> pam(3PAM), logindevperm(4)
>
> AUTHOR
> Martin K. Petersen <mkp mkp net>
> George Lebl <jirka 5z com>
> Brian Cameron <Brian Cameron Sun COM>
> Bill Haneman <Bill Haneman Sun COM>
>
> Copyright (c) 1998, 1999 by Martin K. Petersen
> Copyright (c) 2001, 2003, 2004 by George Lebl
> Copyright (c) 2003 by Red Hat, Inc.
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
>
> NAME
> gdmXnestchooser, gdmXnest
>
> SYNOPSIS
>
> gdmXnestchooser [ --help ] [ --usage ]
> [ -x, --xnest=STRING ]
> [ -o, --xnest-extra-options=OPTIONS]
> [ -n, --no-query ]
> [ -d, --direct ] [-B, --broadcast ]
> [ -b, --background ] [ --no-gdm-check ]
> hostname
>
> DESCRIPTION
> This command automatically gets the correct display number, sets up
> access, and runs Xnest 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
> gdmXnestchooser somehost will run the XDMCP chooser from host somehost
> inside an Xnest.
>
> gdmXnest is a symbolic link to gdmXnestchooser.
Running gdmXnest is the same as using the --no-query and --no-gdm-check
options. It's useful for running Xnest without actually connecting somewhere
> OPTIONS
> -?, --help, --usage
> Gives a brief overview of the command line options.
>
> -x, --xnest=STRING
> Xnest command line, default is "Xnest"
>
> -o, --xnest-extra-options=OPTIONS
> Extra options for Xnest, default is no options.
>
> -n, --no-query
> Just run Xnest, no query (no chooser)
>
> -d, --direct
> Do direct query instead of indirect (chooser)
>
> -B, --broadcast
> Run broadcast instead of indirect (chooser)
>
> -b, --background
> Run in background
>
> --no-gdm-check
> Don't check for running GDM
>
> EXAMPLES
>
> To run the XDMCP chooser from host somehost inside an Xnest:
> gdmXnestchooser somehost
>
> To connect to somehost directly run:
> gdmXnestchooser -d somehost
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmflexiserver(1), gdmphotosetup(1), gdmsetup(1),
> gdmthemetester(1), gdm-restart(1M), gdm-safe-restart(1M),
> gdm-stop(1M), gdmconfig(1M), gnome-std-options(5)
>
> AUTHOR
> Martin K. Petersen <mkp mkp net>
> George Lebl <jirka 5z com>
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 1998, 1999 by Martin K. Petersen
> Copyright (c) 2001, 2003, 2004 by George Lebl
> Copyright (c) 2003 by Red Hat, Inc.
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
> NAME
> gdmflexiserver - desc
>
> SYNOPSIS
>
> gdmflexiserver [ -c, --command=COMMAND ] [-n, --xnest ]
> [ -l, --no-lock ] [ -d, --debug ]
> [ -a, --authenticate ] [ --monte-carlo-pi ]
>
> DESCRIPTION
> The gdmflexiserver command which runs flexible (on demand) X servers.
>
> gdmflexiserver 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 gdmflexiserver.
>
> If there is more than one server defined with flexible=true, then the
> user is given a dialog with those choices upon running gdmflexiserver
>
> The gdmflexiserver command option provides a way to send arbitrary
> commands to GDM and can be used to debug problems or in scripts,
> although gdmflexiserver does require X to be running.
>
> COMMANDS
> gdmflexiserver accepts the following commands with the --command option:
> VERSION
> 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
>
> These are described in detail below, including required arguments, response
> format, and return codes.
>
> 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
>
> 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
>
>
> 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
>
> FLEXI_XNEXT: Start a new flexible Xnest server
> Supported since: 2.3.90.4
> 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.
> 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
>
> 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
>
> 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
>
> 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. The keys that are currently supported are:
> 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
>
> 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
>
> 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
>
> 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
>
> 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
> immedeately.
> 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
>
> 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
>
> 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
>
> CLOSE Answers: None
> Supported since: 2.2.4.0
>
> OPTIONS
> --help
> Print a usage summary.
>
> -c, --command=COMMAND
> Send the specified protocol command to gdm
>
> -n, --xnest
> Xnest mode
>
> -l, --no-lock
> Do not lock current screen
>
> -d, --debug
> Debugging output
>
> -a, --authenticate
> Authenticate before running --command
>
> --monte-carlo-pi
same as before :)
>
> EXAMPLES
>
> To see console GDM version:
>
> $ gdmflexiserver --command=VERSION
> GDM 2.6.0.2
>
> To see all servers:
>
> $ gdmflexiserver --command=ALL_SERVERS
> OK :0,username
>
> To see console servers:
>
> $ gdmflexiserver --command=CONSOLE_SERVERS
> OK :0,username,-1
The --command is mostly used for debugging rather then real use. The primary
use for gdmflexiserver is to run new flexi sessions. The only reason for
having the --command there is that I needed to test the protocol and
gdmflexiserver already has all the code to run it :)
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmXnestchooser(1), gdmphotosetup(1), gdmsetup(1),
> gdmthemetester(1), gdm-restart(1M), gdm-safe-restart(1M),
> gdm-stop(1M), gdmconfig(1M), gnome-std-options(5)
>
>
> AUTHOR
> Martin K. Petersen <mkp mkp net>
> George Lebl <jirka 5z com>
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 1998, 1999 by Martin K. Petersen
> Copyright (c) 2001, 2003, 2004 by George Lebl
> Copyright (c) 2003 by Red Hat, Inc.
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
> NAME
> gdmphotosetup - GDM Photo Setup
>
> SYNOPSIS
>
> gdmphotosetup [ gnome-std-options ]
>
> DESCRIPTION
> 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.
>
> OPTIONS
> gdmphotosetup supports the standard GTK+ options, refer to
> gnome-std-options(5)
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> FILES
>
> ~/.face
> The user's GDM face browser image.
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmXnestchooser(1), gdmflexiserver(1), gdmsetup(1),
> gdmthemetester(1), gdm-restart(1M), gdm-safe-restart(1M),
> gdm-stop(1M), gdmconfig(1M), gnome-std-options(5)
>
>
> AUTHOR
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
> NAME
> gdmsetup, gdmconfig - GDM Configuration Tool
>
> SYNOPSIS
>
> gdmsetup, gdmconfig [ gnome-std-options ]
>
> DESCRIPTION
> gdmconfig is a wrapper script for running gdmsetup for binary
> name compatibility.
>
> gdmsetup runs a graphical program for modifying the GDM
> configuration file, gdm.conf. This tool may only be run as root.
>
> The configuration tool has 6 tabs: General, Standard greeter,
> Graphical greeter, Security, Accessibility, and XDMCP.
>
> The following configuration options may be edited with the tool.
> The gdm.conf section - key affected is listed in parens.
>
> General:
> + Whether the local greeter program is the Graphical or Standard
> greeter (daemon - Greeter)
> + Whether the remote greeter program is the Graphical or Standard
> greeter (daemon - RemoteGreeter)
> + Whether to use the 24 hour clock format (greeter - Use24Clock)
> + Welcome string (greeter - Welcome)
> + Remote Welcome string (greeter - RemoteWelcome)
> + Automatic Login selection (daemon - AutomaticLoginEnable)
> + Automatic Login username (daemon - AutomaticLogin)
> + Timed Login Selection (daemon - TimedLoginEnable)
> + Timed Login username (daemon - TimedLogin)
> + Timed Login delay (daemon - TimedLoginDelay)
>
> Standard Greeter:
> + Background image selection as none, image, or color (greeter -
> BackgroundType)
> + Background image (greeter - BackgroundImage)
> + Scale background image to fit (greeter - BackgroundScaleToFit)
> + Background color (greeter - BackgroundColor)
> + Only background color on remote displays (greeter -
> BackgroundRemoteOnlyColor)
> + Logo image (greeter - Logo)
> + Show chooseable user images or face browser (greeter - Browser)
>
> Graphical Greeter:
> + Theme selection (greeter - GraphicalTheme)
> + Install new theme
> + Delete theme
>
> Security:
> + Allow root to login with GDM (security - AllowRoot)
> + Allow root to login remotely with GDM (security - AllowRemoteRoot)
> + Allow remote timed logins (security - AllowRemoteAutoLogin)
> + Show actions menu (greeter - SystemMenu)
> + Allow configuration from the login screen (greeter - ConfigAvailable)
> + Allow running XDMCP chooser from the logins creen (greeter - ChooserButton)
> + Always disallow TCP connections to Xserver (security - DisallowTCP)
>
> Accessibility:
> + Enable accessibility modules (daemon - AddGtkModules)
> + Make a sound when login window is ready (greeter - SoundOnLogin)
> + Sound file selection (greeter - SoundOnLogin)
>
> XDMCP
> + Enable XDMCP (xdmcp - Enable)
> + Honour indirect requests (xdmcp - HonorIndirect)
> + Listen on UDP port (xdmcp - Port)
> + Maximum pending requests (xdmcp - MaxPending)
> + Maximum pending indirect requests (xdmcp - MaxPendingIndirect)
> + Maximum remote sessions (xdmcp - MaxSessions)
> + Maximum wait time (xdmcp - MaxWait)
> + Maximum indirect wait time (xdmcp - MaxWaitIndirect)
> + Displays per host (xdmcp - DisplaysPerHost)
> + Ping interval in seconds (xdmcp - PingIntervalSeconds)
>
> OPTIONS
> --help
> Print a usage summary.
>
> gdmsetup also supports the standard GTK+ options, refer to
> gnome-std-options(5)
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> FILES
>
> /etc/X11/gdm/gdm.conf
> Contains GDM configuration and documentation. It can be modified by
> running gdmsetup or gdmconfig.
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmXnestchooser(1), gdmflexiserver(1),
> gdmphotosetup(1), gdmthemetester(1), gdm-restart(1M),
> gdm-safe-restart(1M), gdm-stop(1M), gnome-std-options(5)
>
> AUTHOR
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
> NAME
> gdmthemetester - GDM Theme Test Utility
>
> SYNOPSIS
>
> gdmthemetester environment theme
>
> DESCRIPTION
> A tool for viewing a theme outside of GDM. Useful for testing or
> viewing themes. gdmthemetester requires that the system support
> gdmXnest.
>
> Note that themes can display differently depending on the theme's
> "Show mode". gdmthemetester allows viewing the themes in different
> modes by specifying the environment option. Valid values and their
> meanings follow:
>
> 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.
>
> OPTIONS
> environment
> Can be one of: console, console-timed, flexi, remote-flexi,
> xdmcp
>
> theme
> Either the path name or the name of a theme to view.
>
> ENVIRONMENT
>
> XNESTSIZE
> Can be set to <width>x<height> (e.g. 800x600) to test the
> theme at a specific resolution.
>
> ATTRIBUTES
>
> See attributes(5) for descriptions of the following attri-
> butes:
>
> ---------------------------------------------------------------------------
> | ATTRIBUTE TYPE | ATTRIBUTE NAME |
> ---------------------------------------------------------------------------
> | Availability | SUNWgnome-display-mgr |
> ---------------------------------------------------------------------------
> | Interface stability | External |
> ---------------------------------------------------------------------------
>
> SEE ALSO
> gdm(1), gdm-binary(1), gdmXnestchooser(1), gdmflexiserver(1),
> gdmphotosetup(1), gdmsetup(1), gdm-restart(1M), gdm-safe-restart(1M),
> gdm-stop(1M), gdmconfig(1M), gnome-std-options(5)
>
> AUTHOR
> Martin K. Petersen <mkp mkp net>
> George Lebl <jirka 5z com>
> Brian Cameron <Brian Cameron Sun COM>
>
> Copyright (c) 1998, 1999 by Martin K. Petersen
> Copyright (c) 2001, 2003, 2004 by George Lebl
> Copyright (c) 2003 by Red Hat, Inc.
> Copyright (c) 2003 by Sun Microsystems, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gdm-unsubscribe sunsite dk
> For additional commands, e-mail: gdm-help sunsite dk
--
George <jirka 5z com>
A man's ethical behavior should be based effectually on sympathy, education,
and social ties; no religious basis is necessary. Man would indeed be in a
poor way if he had to be restrained by fear of punishment and hope of reward
after death.
-- Albert Einstein
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
