May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor


News Recommended Links X Windows system Protocol X display manager Configuration Fonts in X windows IPTables
Enabling XDMCP in Solaris 10 Troubleshooting XDMCP Connections to UNIX and Linux Hosts - Tech Note 1229          
Exporting_display vnc Xdefaults X11 security X11 forwaring over ssh Humor Etc

The X Display Manager Control Protocol (XDMCP) is used by X terminals (and X servers in general) to set up an X session with a remote system over the network. A display manager can run on the same computer where the user sits or on a remote one. In the first case, the display manager starts one or more X servers, displaying the login screen at the beginning and (optionally) every time the user logs out. In the second case, the display manager works according to the XDMCP protocol.

The XDMCP protocol mandates that the X server starts autonomously and connects to the display manager. In the X Window System paradigm, the server runs on the computer providing the display and input devices. A server can connect, using the XDMCP protocol, to a display manager running on another computer, requesting it to start the session. In this case, the X server acts as a graphical telnet client while the display manager acts like a telnet server: users start programs from the computer running the display manager, while their input and output take place on the computer where the server (and the user) sits.

There are two distinct methods of using XDMCP:

On Unix systems, the XDMCP service is usually provided by the xdm  daemon, which runs continuously. It often also provides a login service to the X server running on the same machine.  xdm's provision of display management to the world is controlled by the Xaccess  file, found in /var/X11/xdm, /etc/X11/xdm  or XROOT/lib/X11/xdm. If this contains no lines that aren't blank or comments, xdm  will refuse to manage any remote display. For other configurations, look at the "XDMCP ACCESS CONTROL" section of xdm(1).

On systems using the Common Desktop Environment (CDE), including recent Digital Unix, Solaris and HP-UX systems, the XDMCP service is provided by dtlogin. It uses the same format of Xaccess  file as xdm, but stores it in both /usr/dt/config  and /etc/dt/config. You should copy it from the former to the latter before editing it, unless it's there already.

An administrator can configure an X server running on the computer or terminal of the user either to connect to a specific display manager, or to display a list of suitable hosts running potential X display managers. An XDMCP Chooser program allows the user to select a host from among those the terminal can connect to:

  1. a predefined list of hosts and their respective network addresses;
  2. a list of hosts (on the local TCP/IP subnet) that the XDMCP server in turn obtains by a network broadcast

The XDMCP server will often present itself in this list. When the user selects a host from the list, the X server running on the local machine will connect to the selected remote computer's X display manager.

Enabling XDMCP on Red Hat Linux

In RHEL by default X11 is enabled only for localhost. To be able to connections from the external box you need to edit the file /etc/gdm/custom.conf. The default setting for RHEL is


which should be changed to "false"

To enable XDMCP that some users need you need to enable it.


After that restart X11 server using command

init 3 && init 5

If in addition you want to provide ability to log as root you need security section as following


If firewall is enabled you need to open several ports

Top Visited
Past week
Past month


Old News ;-)

[Oct 11, 2012] What Ports Need to be Opened for XDMCP StarNet

X-Win32 can connect to linux hosts even behind a firewall.

Open up TCP port 6000-6005 (plus X-Win32's base display number) in both directions
Open up UDP port 177 to accept incomming connections from any port.

If you are using Gnome open up TCP ports 16001 and TCP 35091 in both directions.

If you are behind a router using NAT, map those ports to the IP address of your local computer on your LAN. The only other thing is make sure on the Network tab under the X-Config menu, that your display is the correct IP address. This is the address you are telling the host to send the session back to.

If you are using SuSE linux firewall, edit /etc/sysconfig/SuSEfirewall2 changing the default options to the following

FW_SERVICES_EXT_UDP="177 bootpc"

[Oct 11, 2012] Troubleshooting XDMCP Connections to UNIX and Linux Hosts - Tech Note 1229

There are several reasons why an XDMCP connection might fail. The most common reasons are:

To determine the cause of the problem and resolve it, start with section A. XDMCP Error Codes, and proceed through each subsequent section as directed.

Note: The troubleshooting steps in this note help you ensure that the XDM daemon is running and that Reflection X can successfully connect and run sessions using this daemon. An alternate workaround for starting sessions is to manually start X sessions. This procedure is described below under "To manually start an X session without using the XDM Daemon."

[Oct 11, 2012] XLaunch - XDMCP settings

XDMCP remote settings

A quick guide to setting insecure XDMCP mode on a remote machine running kdm, gdm, xdm or wdm...

On the remote Linux/Unix machine edit the following files and then restart the appropriate X Display Manager (which must not be run with the -nolisten tcp option, or similar...this maybe the default setting in your distro!)

If you have problems: use Wireshark or equivalent to monitor UDP traffic on the remote host and look for a protocol sequence, e.g. Query 177/UDP, Willing x/UDP, Request 177/UDP, Accept x/UDP, Manage 177/UDP, and see where it stops. If it gets through a sequence: test with local and remote xeyes in multiwindow mode, because the Display Manager acts just like an X client from then on in to provide its login window.

[Aug 30, 2012] How to enable remote login for root via XDMCP on Red Hat Enterprise Linux 5

Red Hat Customer Portal

Restart gdm to make changes effective

[root@localhost ~]# gdm-restart

[Aug 30, 2012] Enable XDMCP in Linux

Jan 5, 2011 | RHEL Tech

Need to enable the xdmcp protocol in the Linux server for getting remote using XBrowser.


In RHEL Server:

1) Install the gdm package
# yum install gdm

2) Enable the xdmcp protocol by adding the below entries in the custom.conf file.
# vi /etc/gdm/custom.conf


Note: Here "AllowRemoteRoot=true" used to allow root access.

3) Restart the gdm service
# gdm-restart

4) Check weather xdmcp port is opened or not, using netstat command
# netstat –an | grep 177
udp 0 0*

In SUSE Server:

5) Install the required 2 packages
# yum install gdm xorg-x11

6) Set the default display manager by editing the displaymanager file
# vi /etc/sysconfig/displaymanager

7) Enable the xdmcp protocol by editing the gdm.conf file

# vi /etc/opt/gnome/gdm/gdm.conf


8) To make xdmcp listening on xdm by edit the xdm-config file
# vi /etc/X11/xdm/xdm-config
!DisplayManager.requestPort: 0

Note: Comment out this line for xdmcp listen on xdm

9) Restart the service and check with netstat
# rcxdm restart
# netstat –an | grep 177
udp 0 0*

10) Verify from the Windows client using Xbrowser as root.

[Aug 30, 2012] Configuring XDMCP and GDM on Red Hat Linux

by Jeff Hunter, Sr. Database Administrator

Most users installing Linux today choose to install and configure the X Windows System. This allows those users to access their Linux environment using a graphic (GUI) console connected to the workstation or server. An X Windows environment provides users to run X programs like xterm, OpenOffice, Mozilla Firefox and a host of other useful graphical software packages.

There are times, however, when users need to log in to a Linux machine using the graphical X Windows System from a remote computer, like a Windows PC for example. The remote Windows PC would first need to have an X Windows Server installed like Xming, Exceed Hummingbird, or my personal favorite X-Win 32.

When installing Red Hat Enterprise Linux, the system defaults to a secure configuration which does not allow remote graphical logins or remote desktop access. This article explains the configuration changes required to allow remote access to a Red Hat Enterprise Linux system (RHEL) using the X Display Manager Control Protocol (XDMCP) or GDM (GUI login).

Configure Linux to use GUI Logins
One of the first steps is to make certain the Red Hat Linux environment is configured to use a graphical (GUI) login. A Linux environment allows for either a text login or a graphical (GUI) login. This option is specified in the init script configuration file /etc/inittab. In order to allow remote graphical (GUI) logins, the environment itself must be configured for a X11 GUI login. Make certain the system is configured with the correct X11 runlevel (which in this case is runlevel 5):

# /etc/inittab

..... <SNIP> .....

# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)

..... <SNIP> .....

Granting Remote Access to the Login Manager
The next step is to grant MS Windows users remote GUI access to the Red Hat Linux system. More specifically, we need to grant access to the RHEL Login Manager. Use the GDM Login Manager for RHEL 5 or higher while using the XDM Login Manager for RHEL 3 and RHEL 4.

GDM Login Manager
Users running Red Hat Enterprise Linux 5, CentOS 5, or Oracle Linux Release 5 will need to use the GDM login manager as XDM is no longer supported.

First, edit the file /etc/gdm/custom.conf and add the following two entries:



Next, restart X Windows:

[root@racnode1 ~]# init 3
[root@racnode1 ~]# init 5

The final step is to configure the GDM login manager using the gdmsetup utility:

[root@racnode1 ~]# gdmsetup

After starting the gdmsetup utility, click the Remote tab. Under the Remote tab, change the Style pull-down menu selection from 'Remote login disabled' to 'Same as Local':

How to use Cygwin to work with a Linux Server

  1. Connect and log in.
    1. This is the easy part. In a Cygwin window, type X -broadcast and you will be presented with the login for your server. Log in and enjoy.
    2. It's well worth reading the Cygwin documentation for other cool things you can do with it. You might want to start with the Cygwin/XFree86 FAQ.

Complete XDM Working Example


XDM manages (via CHOOSER) those systems either in the Xservers file or those that identify themselves over the network as being willing to be managed by XDM. All of XDM's configuration files (XFree86 v4.3.0) are in the directory /usr/X11R6/lib/X11/xdm.


At the bottom of xdm-config, the lines read:
  ! SECURITY: do not listen for XDMCP or Chooser requests
  ! Comment out this line if you want to manage X terminals with xdm
  DisplayManager.requestPort:     0
Therefore, change the last line to:
  !DisplayManager.requestPort:     0


The comments in Xaccess are pretty clear. The two lines shown have been un-commented:
  *                        #any host can get a login window
  *   CHOOSER BROADCAST    #any indirect host can get a chooser


XDM, as configured, will provide a nice graphical login screen on the local system. It will not, however, present the CHOOSER menu to allow logging into other systems. This is because the contents of the Xservers file directs XDM to manage the local display. Comment out the line:
  :0 local /usr/X11R6/bin/X
  #:0 local /usr/X11R6/bin/X

X Resources and other Chooser Setup

Configuring the chooser through X resources and scripts:

Well, now that we've got everything basically working, all that we have left is to clean up the configuration of the chooser so it is a little more useable and visually pleasing.

The chooser can be configured using X resources. By changing these resources we can do things such as change the chooser fonts, the layout of the list, and the colors. These resources are set in /etc/X11/xdm/Xresources (or a similar location on non-Debian machines).

On our systems, we wanted to do the following:

To accomplish this, we edited /etc/X11/xdm/Xresources to insert the following:
Chooser*geometry:               810x500+300+225
Chooser*allowShellResize:       false
Chooser*ShapeStyle:             Oval
Chooser*viewport.forceBars:     true
Chooser*label.font:             *-new century schoolbook-bold-i-normal-*-240-*
Chooser*label.label:            Available MEnet Hosts
!Chooser*list.font:             -*-*-medium-r-normal-*-*-230-*-*-c-*-iso8859-1
Chooser*list.font:              -misc-fixed-medium-r-semicondensed--13-120-75-75
Chooser*Command.font:           *-new century schoolbook-bold-r-normal-*-180-*
#ifdef COLOR
Chooser*Form.background:              gray80
Chooser*label.foreground:               white
Chooser*label.background:               midnightblue
Chooser*Command.background:            gray80
Chooser*list.columnSpacing:         25
Chooser*list.defaultColumns:         2
Chooser*list.forceColumns:         true
Chooser*list.verticalList:              true
Chooser*internalBorderColor:            black
Chooser*Command.font:           -adobe-helvetica-bold-r-*-*-12-*
Chooser*viewport.useRight:      true

Finally, we wanted to get rid of the default X11 "thatch" pattern on the root window, since it gives a horrid moire effect on small monitors. To do this, we tell xdm to use a shell script, called "chooser.script" instead of the normal "chooser". This script simply sets the background to "skyblue4" and runs the normal chooser. We set this in /etc/X11/xdm/xdm-config, adding the line

DisplayManager*chooser:         /usr/lib/X11/xdm/chooser.script
where "chooser.script" is
xsetroot -solid skyblue4
/usr/lib/X11/xdm/chooser $*
The final result looks like:

customized chooser
[click for a larger image]

Much nicer, no?

A lot more customization is possible, through both X resources and the XDM configuration scripts. Consult the xdm man page for more details.


5. XDMCP and GDM (Gnome Display Manager)

The following is taken from the Gnome Display Manager Reference Manual:

GDM also supports the X Display Manager Protocol (XDMCP) for managing remote displays. GDM listens to UDP port 177 and 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 only supports the MIT-MAGIC-COOKIE-1 authentication system. Little is gained from the other schemes, and no effort has been made to implement them so far. 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.

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. 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.

Linux login with a Windows box and XDMCP

Technology & Life Integration: Fiction or Future

There are many different ways to login to a Linux computer. Most of them are text based and other graphical ones are slow and create lots of network traffic. To the windows click and pointy types the text based login's are a real pain and the other graphical types are murder over a slow connection. What a lot of people have probably forgotten is that the Linux graphical system, XWindows, is a client server application and is as equally at home across the network as it is on a local machine.

It also doesn't care what platform it is talking to. As long as the machines it communicates with, talk the talk, it is a happy camper. So to graphically log into a Linux computer remotely and see your special, lovingly customised desktop appear wherever you happen to be you don't need any other program than XWindows itself. For linux computers that generally comes part and parcel with the distribution and just needs to be enabled. For windows computers there is a free and open source program that gives you the ability to, talk the talk, to the Linux XWindows client server architecture.

While there are many such programs for Windows, some are commercial, some are free. I have used many of them but the latest one I have used and I find is the easiest to set up is the XMing program found on sourceforge and can be downloaded here. There are a few parts to it but for our purposes all we need is the server part and possibly the fonts. I never used the fonts though.

Installing is a no brainer and follows the standard "next,next,next" installation pattern of many windows programs. Once it is installed and if you made the right choices there will be two icons on your desktop. One for Xming and one for Xlaunch. I will get back to them later.

Generally for security reasons your linux distribution is not set up as an xdmcp server so we need to enable it. In this post I am not going to worry about securing it. I am just going to get it to a working stage. For this purpose I am going to use Kubuntu edgy and we are going to (shock, horror!!) manually edit two text files. These two files are in "/etc/kde3/kdm" so in konqueror we need to navigate to that directory. The two files which concern us are "kdmrc" and "Xaccess".

First right click on "kdmrc" and choose "Edit as root" under the "Actions" menu item. A text editor will then open up and we can make the first of our changes. Find the section starting with "[Xdmcp]". In that section there is "Enable=false" which should be "Enable=true". Next make sure that the "Xaccess=/etc/kde3/kdm/Xaccess" and "Willing=/etc/kde3/kdm/Xwilling" lines are as shown with no comment '#'s in front of them. Save your changes and close the file.

Second right click on "Xaccess" and choose "Edit as root" under the "Actions" menu item. The two lines that concern us are
"#* #any host can get a login window"
"#* CHOOSER BROADCAST #any indirect host can get a chooser".
They just need the comment '#' thingy to be removed from the start of the lines and the file saved and closed.

Finally the "kdm" login manager needs to be restarted by sending a sighup signal to it. To do that the command "sudo killall -s HUP kdm" is entered in a terminal window.

Once all that painfull text file manipulation is done wii come back to the Xlaunch icon on our windows desktop. Clicking on that brings up a dialog box where you can choose anything except "Multiple windows" and click on next. Choose the "Open session via XDMCP" selection and again click on next. Select the "Search for hosts (broadcast)" and click on next until the final screen. Here, if you choose, you can save your settings to your preferred location for easy one click access later. Clicking on the final button will then present you with a wonderful sight. A Linux login screen.

Re [gdm-list] remote manager (XDMCP) on Suse

Thanks. I have the extra menu option now but when I select xdmcp, I get an
Xrefresh (cursor becomes clock and large X) then the screen goes back to
the original login.

In /var/log/gdm, I see an entry implying that the X command is incorrect
Unrecognized options: 0
use ... (output from X --help)

In /var/log/messages, I see the command was
/usr/X11R6/in/X :0 0 -auth /var/gdm:0.Xauth
   Note the extra 0 ^
Where else could the X command be defined besides gdm.conf?

Here's my gdm.conf

# GDM Configuration file.  You can use gdmsetup program to graphically
# edit this, or you can optionally just edit this file by hand.  Note that
# gdmsetup does not tweak every option here, just the ones most users
# would care about.  Rest is for special setups and distro specific
# tweaks.  If you edit this file, you should send the HUP or USR1 signal to
# the daemon so that it restarts: (Assuming you have not changed PidFile)
#   kill -USR1 `cat /var/run/`
# (HUP will make gdm restart immediately while USR1 will make gdm not kill
# existing sessions and will only restart gdm after all users log out)
# You can also use the gdm-restart and gdm-safe-restart scripts which just
# do the above for you.
# For full reference documentation see the gnome help browser under
# GNOME|System category.  You can also find the docs in HTML form
# on
# NOTE: Some of these are commented out but still show their default values.
# If you wish to change them you must remove the '#' from the beginning of
# the line.  The commented out lines are lines where the default might
# change in the future, so set them one way or another if you feel
# strongly about it.
# Have fun! - George

# Automatic login, if true the first local screen will automatically logged
# in as user as set with AutomaticLogin key.

# Timed login, useful for kiosks.  Log in a certain user after a certain
# amount of time

# The gdm configuration program that is run from the login screen, you should
# probably leave this alone
Configurator=/usr/bin/gdmsetup --disable-sound --disable-crash-dialog
# The chooser program.  Must output the chosen host on stdout, probably you
# should leave this alone
# Greeter for local (non-xdmcp) logins.  Change gdmlogin to gdmgreeter to
# get the new graphical greeter.
# Greeter for xdmcp logins, usually you want a less graphically intensive
# greeter here so it's better to leave this with gdmlogin
# Launch the greeter with an additional list of colon seperated gtk
# modules. This is useful for enabling additional feature support
# e.g. gnome accessibility framework. Only "trusted" modules should
# be allowed to minimise security holes
# By default these are the accessibility modules

# Default path to set.  The profile scripts will likely override this
# Default path for root.  The profile scripts will likely override this

# If you are having trouble with using a single server for a long time and
# want gdm to kill/restart the server, turn this on

# User and group that gdm should run as.  Probably should be gdm and gdm and
# you should create these user and group.  Anyone found running this as
# someone too privilaged will get a kick in the ass.  This should have
# access to only the gdm directories and files.
# To try to kill all clients started at greeter time or in the Init script.
# doesn't always work, only if those clients have a window of their own
# You should probably never change this value unless you have a weird setup
# Note that a post login script is run before a PreSession script.
# It is run after the login is successful and before any setup is
# run on behalf of the user
# Distributions:  If you have some script that runs an X server in say
# VGA mode, allowing a login, could you please send it to me?
# if X keeps crashing on us we run this script.  The default one does a bunch
# of cool stuff to figure out what to tell the user and such and can
# run an X configuration program.
# Reboot, Halt and suspend commands, you can add different commands
# separated by a semicolon and gdm will use the first one it can find
# Probably should not touch the below this is the standard setup
# This is our standard startup script.  A bit different from a normal
# X session, but it shares a lot of stuff with that.  See the provided
# default for more information.
# This is a directory where .desktop files describing the sessions live
# It is really a PATH style variable since to allow actual
# interoperability with KDM
# This is the default .desktop session.  One of the ones in SessionDesktopDir
# Better leave this blank and HOME will be used.  You can use syntax ~/ below
# to indicate home directory of the user.  You can also set this to something
# like /tmp if you don't want the authorizations to be in home directories.
# This is useful if you have NFS mounted home directories.  Note that if this
# is the home directory the UserAuthFBDir will still be used in case the home
# directory is NFS, see security/NeverPlaceCookiesOnNFS to override
this behaviour.
# Fallback if home directory not writable
# The X server to use if we can't figure out what else to run.
# The maximum number of flexible X servers to run.
# the X nest command
Xnest=/usr/X11R6/bin/Xnest -audit 0 -name Xnest
# Automatic VT allocation.  Right now only works on Linux.  This way
# we force X to use specific vts.  turn VTAllocation to false if this
# is causing problems.
# Should double login be treated with a warning (and possibility to change
# vts on linux systems for console logins)

# If any distributions ship with this one off, they should be shot
# this is only local, so it's only for say kiosk use, when you
# want to minimize possibility of breakin
# If you want to be paranoid, turn this one off
# This will allow remote timed login
# 0 is the most anal, 1 allows group write permissions, 2 allows all write
# permissions
# Number of seconds to wait after a bad login
# Maximum size of a file we wish to read.  This makes it hard for a user to DoS
# us by using a large file.
# If true this will basically append -nolisten tcp to every X command line,
# a good default to have (why is this a "negative" setting? because if
# it is false, you could still not allow it by setting command line of
# any particular server).  It's probably better to ship with this on
# since most users will not need this and it's more of a security risk
# then anything else.
# Note: Anytime we find a -query or -indirect on the command line we do
# not add a "-nolisten tcp", as then the query just wouldn't work, so
# this setting only affects truly local sessions.
# By default never place cookies if we "detect" NFS.  We detect NFS
# by detecting "root-squashing".  It seems bad practice to place
# cookies on things that go over the network by default and thus we
# don't do it by default.  Sometimes you can however use safe remote
# filesystems where this is OK and you may want to have the cookie in your
# home directory.

# XDMCP is the protocol that allows remote login.  If you want to log into
# gdm remotely (I'd never turn this on on open network, use ssh for such
# remote usage that).  You can then run X with -query <thishost> to log in,
# or -indirect <thishost> to run a chooser.  Look for the 'Terminal' server
# type at the bottom of this config file.
# Distributions: Ship with this off.  It is never a safe thing to leave
# out on the net.  Setting up /etc/hosts.allow and /etc/hosts.deny to only
# allow local access is another alternative but not the safest.
# Firewalling port 177 is the safest if you wish to have xdmcp on.
# Read the manual for more notes on the security of XDMCP.
# Honour indirect queries, we run a chooser for these, and then redirect
# the user to the chosen host.  Otherwise we just log the user in locally.
# Maximum pending requests
# Maximum open XDMCP sessions at any point in time
# Maximum wait times
# How many times can a person log in from a single host.  Usually better to
# keep low to fend off DoS attacks by running many logins from a single
# host.  This is now set at 2 since if the server crashes then gdm doesn't
# know for some time and wouldn't allow another session.
# The number of seconds after which a non-responsive session is logged off.
# Better keep this low.
# The port.  177 is the standard port so better keep it that way
# Willing script, none is shipped and by default we'll send
# hostname system id.  But if you supply something here, the
# output of this script will be sent as status of this host so that
# the chooser can display it.  You could for example send load,
# or mail details for some user, or some such.

# The 'theme'.  By default we're using the default gtk theme
# Of course assuming that gtk got installed in the same prefix,
# if not change this.
# NOTE - the next line is modified by the specfile.src in
# src/pkg/gdm for suse/jds. Know what you are doing before changing.
# Maximum size of an icon, larger icons are scaled down

# Greeter has a nice title bar that the user can move
# Configuration is available from the system menu of the greeter
# Face browser is enabled.  This only works currently for the
# standard greeter as it is not yet enabled in the graphical greeter.
# The default picture in the browser
# These are things excluded from the face browser, not from logging in
# As an alternative to the above this is the minimum uid to show
# If user or user.png exists in this dir it will be used as his picture
# File which contains the locale we show to the user.  Likely you want to use
# the one shipped with gdm and edit it.  It is not a standard locale.alias file,
# although gdm will be able to read a standard locale.alias file as well.
# Logo shown in the standard greeter
# The standard greeter should shake if a user entered the wrong username or
# password.  Kind of cool looking
# The Actions menu (formerly system menu) is shown in the greeter, this is the
# menu that contains reboot, shutdown, suspend, config and chooser.  None of
# these is available if this is off.  They can be turned off individually
# however
# Should the chooser button be shown.  If this is shown, GDM can drop into
# chooser mode which will run the xdmcp chooser locally and allow the user
# to connect to some remote host.  Local XDMCP does not need to be enabled
# however
# Note to distributors, if you wish to have a different Welcome string
# and wish to have this translated you can have entries such as
# Welcome[cs]=Vitejte na %n
# Just make sure the string is in utf-8
# Welcome is for all console logins and RemoteWelcome is for remote logins
# (through XDMCP).
# The default entries that are shipped are translated inside genius and
# are as follows:
Welcome=Hi there
RemoteWelcome=Welcome to Remote host %n
# Don't allow user to move the standard greeter window.  Only makes sense
# if TitleBar is on
# Set a position rather then just centering the window.  If you enter
# negative values for the position it is taken as an offset from the
# right or bottom edge.
# Xinerama screen we use to display the greeter on.  Not for true
# multihead, currently only works for Xinerama.
# Background settings for the standard greeter:
# Type can be 0=None, 1=Image, 2=Color
# XDMCP session should only get a color, this is the sanest setting since
# you don't want to take up too much bandwidth
# Program to run to draw the background in the standard greeter.  Perhaps
# something like an xscreensaver hack or some such.
# if this is true then the background program is run always, otherwise
# it is only run when the BackgroundType is 0 (None)
# Show the Failsafe sessions.  These are much MUCH nicer (focus for xterm for
# example) and more failsafe then those supplied by scripts so distros should
# use this rather then just running an xterm from a script.
# Normally there is a session type called 'Last' that is shown which refers to
# the last session the user used.  If off, we will be in 'switchdesk' mode where
# the session saving stuff is disabled in GDM
# Always use 24 hour clock no matter what the locale.
# Use circles in the password field.  Looks kind of cool actually,
# but only works with certain fonts.
# These two keys are for the new greeter.  Circles is the standard
# shipped theme

# The chooser is what's displayed when a user wants an indirect XDMCP
# session, or selects Run XDMCP chooser from the system menu
# Default image for hosts
# Directory with host images, they are named by the hosts: host or host.png
# Time we scan for hosts (well only the time we tell the user we are
# scanning actually, we continue to listen even after this has
# expired)
# A comma separated lists of hosts to automatically add (if they answer to
# a query of course).  You can use this to reach hosts that broadcast cannot
# reach.
# Broadcast a query to get all hosts on the current network that answer
# Allow adding random hosts to the list by typing in their names

# This will enable debugging into the syslog, usually not neccessary
# and it creates a LOT of spew of random stuff to the syslog.  However it
# can be useful in determining when something is going very wrong.

# These are the standard servers.  You can add as many you want here
# and they will always be started.  Each line must start with a unique
# number and that will be the display number of that server.  Usually just
# the 0 server is used.
# Note the VTAllocation and FirstVT keys on linux.  Don't add any vt<number>
# arguments if VTAllocation is on, and set FirstVT to be the first vt
# available that your gettys don't grab (gettys are usually dumb and grab
# even a vt that has already been taken).  Using 7 will work pretty much for
# all linux distributions.  VTAllocation is not currently implemented on
# anything but linux since I don't own any non-linux systems.  Feel free to
# send patches.  X servers will just not get any extra arguments then.
# If you want to run an X terminal you could add an X server such as this
#0=Terminal -query serverhostname
# or for a chooser (optionally serverhostname could be localhost)
#0=Terminal -indirect serverhostname
# If you wish to run the XDMCP chooser on the local display use the following
# line

## Note:
# is your X server not listening to TCP requests?  Perhaps you should look
# at the security/DisallowTCP setting!

# Definition of the standard X server.
name=Standard server
command=/usr/X11R6/bin/X -audit 0

# Standard Server with forced vt allocation
name=Standard server with VTAllocation
command=/usr/X11R6/bin/X -audit 0 vt7

# To use this server type you should add -query host or -indirect host
# to the command line
name=Terminal server
# Add -terminate to make things behave more nicely
command=/usr/X11R6/bin/X -audit 0 -terminate
# Make this not appear in the flexible servers (we need extra params
# anyway, and terminate would be bad for xdmcp choosing).  You can
# make a terminal server flexible, but not with an indirect query.
# If you need flexible indirect query server, then you must get rid
# of the -terminate and the only way to kill the flexible server will
# then be by Ctrl-Alt-Backspace
# Not local, we do not handle the logins for this X server

# To use this server type you should add -query host or -indirect host
# to the command line
name=Chooser server
command=/usr/X11R6/bin/X -audit 0
# Make this not appear in the flexible servers for now, but if you
# wish to allow a chooser server then make this true.  This is the
# only way to make a flexible chooser server that behaves nicely.
# Run the chooser instead of the greeter.  When the user chooses a
# machine they will get this same server but run with
# "-terminate -query hostname"

On Sun, May 18, 2008 at 5:12 PM, Brian Cameron <Brian Cameron sun com> wrote:
> Dave:
> If you have turned on SystemMenu=true and ChooserButton=true in your
> GDM configuration, then you should be able to use the "Options" button
> to start the gdmchooser program, which will allow you to XMDCP to
> other machines.
> Some GDM themes may not support the Options button, or a button to
> run the XDMCP chooser.  You can hit the F10 key to see a menu which
> will show all the options.  If you are using a theme that doesn't
> support showing the XDMCP chooser via a more direct method than
> the "F10" key, then you might consider using a better theme, or
> enhancing your theme to support the Options button or a button to
> launch the chooser.
> Brian
>> I have a Suse 9 SP3 host I've installed gdm via sunray server. The
>> default WM is KDE.
>> What I'd like the login screen to allow is a remote login to any
>> machine broadcasting
>> via XDMCP without first logging in to this host.
>> Under CDE, this would be found under options-->remote host.
>> I've already modified gdm.conf with
>> Enable=True
>> Browser=true
>> ChooserButton=true
>> I've restarted X11 but see no difference. On this host I can xnest to
>> get a remote login
>> display from the various target hosts so I know they're running XDMCP.
>> What other steps do I need to take?
>> TIA
>> _______________________________________________
>> gdm-list mailing list
>> gdm-list gnome org

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles


XDMCP with a chooser

xdm Command

Basic Xterminal Setup and Configuration

Ubuntu Manpage xdm - X Display Manager with support for XDMCP, host chooser

XDM(1) manual page

X display manager - Wikipedia, the free encyclopedia


Linux login with a Windows box and XDMCP

Linux-Based X Terminals with XDMCP

Remote Sessions via XDMCP

X Server XDMCP Options


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September 12, 2017