X -query xxx.xxx.xxx.xxx :1 fails

[sireasoning]

I tried to open a remote XDMCP connection through Knoppix (as root) but it always fails as follows:

AUDIT: Tue Jan 21 02:54:58 2003: 4157 X: client 1 rejected from IP 192.168.1.1 port 36014
Auth name: MIT-MAGIC-COOKIE-1 ID: -1
AUDIT: Tue Jan 21 02:55:13 2003: 4157 X: client 1 rejected from IP 192.168.1.1 port 36015
Auth name: MIT-MAGIC-COOKIE-1 ID: -1
AUDIT: Tue Jan 21 02:55:28 2003: 4157 X: client 1 rejected from IP 192.168.1.1 port 36017
Auth name: MIT-MAGIC-COOKIE-1 ID: -1
AUDIT: Tue Jan 21 02:55:43 2003: 4157 X: client 1 rejected from IP 192.168.1.1 port 36022
Auth name: MIT-MAGIC-COOKIE-1 ID: -1
AUDIT: Tue Jan 21 02:55:58 2003: 4157 X: client 1 rejected from IP 192.168.1.1 port 36046
Auth name: MIT-MAGIC-COOKIE-1 ID: -1

Fatal server error:
XDMCP fatal error: Session failed Session 312096010 failed for display 192.168.1.137:1: cannot open display

[sireasoning]

I wonder if this is an issue with the new XFree86. It seemed to work fine in a previous attempt I believe.

[A. Jorge Garcia]

I've been trying to get this to work forever in my school's lab for my students with no success....

Frustrated,

[sireasoning]

It has been a while...but I believe that you have to put the client ip and name in the XDMCP servers /etc/hosts.

[A. Jorge Garcia]

That's what I did origianlly, but it didn't work. I've tried the new steps I was given in one of these networking threads and still no joy....

Frustrated,

[sireasoning]

did you also put the XDMCP server in the client's /etc/hosts?

[A. Jorge Garcia]

I thought so, but that was a long time ago. I'll go in next week and resinstall a couple of PCs to start over from scratch. I've made so many modifications as advised on this forum that I can't keep track of what I did anymore!

Here's a sample of the advise I've gotten:

http://www.knoppix.net/forum/viewtopic.php?p=29677

http://www.knoppix.net/forum/viewtopic.php?t=5668

http://www.knoppix.net/forum/viewtopic.php?p=6873

and from http://linux-sxs.org

Purpose
Overview of creating a grapical login from one linux machine to another using XFree86 4.1.0 and kdm 2.2.1.

System
Server: Caldera OpenLinux Workstation 3.1
KDE 2.2.1, XFree86 4.1.0, kernel 2.4.9

AMD Athlon 950MHz 392MB RAM

Client: Mandrake 8.0
KDE 2.2.1, XFree86 4.1.0, stock kernel

AMD K6-2-450, 128MB RAM

Caveats
As with anything computer related, these steps are what worked for me, and to the best of my knowledge, they should work for everyone. However, not everone's system is configured the same way and you may need to configure something differently.

Steps
Server side
Step 1:
Verify which login manager you're using so you can edit the correct configureation files. I use kdm, replace kdm in these steps with your login manager (xdm, gdm, whatever).

Step 2:
Edit the Xaccess file to enable remote logins. My kdm Xaccess file is located in /etc/X11/kdm, that should be fairly standard. You can use 'locate Xaccess' if it's not there (assuming, of course, that your distro installed locate and it gets updated).

Here are the contents of mine:

# $XConsortium: Xaccess,v 1.5 91/08/26 11:52:51 rws Exp $
# Access control file for XDMCP connections
# To control Direct and Broadcast access:
#
# pattern
#
# To control Indirect queries:
#
# pattern list of hostnames and/or macros ...
#
# To use the chooser:
#
# pattern CHOOSER BROADCAST
#
# or
#
# pattern CHOOSER list of hostnames and/or macros ...
#
# To define macros:
#
#
# %name list of hosts ...
#
# The first form tells xdm which displays to respond to itself.
# The second form tells xdm to forward indirect queries from hosts matching
# the specified pattern to the indicated list of hosts.
# The third form tells xdm to handle indirect queries using the chooser;
# the chooser is directed to send its own queries out via the broadcast
# address and display the results on the terminal.
# The fourth form is similar to the third, except instead of using the
# broadcast address, it sends DirectQuerys to each of the hosts in the list
#
# In all cases, xdm uses the first entry which matches the terminal;
# for IndirectQuery messages only entries with right hand sides can
# match, for Direct and Broadcast Query messages, only entries without
# right hand sides can match.
#

Note: This is the important part:

# Add network logins 10/16/01
* #any host can get a login window

In the standard file, there is a # at the beginning of this line. Remove it to enable remote X logins

#
# To hardwire a specific terminal to a specific host, you can
# leave the terminal sending indirect queries to this host, and
# use an entry of the form:
#
#terminal-a host-a
#
# The nicest way to run the chooser is to just ask it to broadcast
# requests to the network - that way new hosts show up automatically.
# Sometimes, however, the chooser can't figure out how to broadcast,
# so this may not work in all environments.
#
#* CHOOSER BROADCAST #any indirect host can get a chooser
#
# If you'd prefer to configure the set of hosts each terminal sees,
# then just uncomment these lines (and comment the CHOOSER line above)
# and edit the %hostlist line as appropriate
#%hostlist host-a host-b
#* CHOOSER %hostlist

The CHOOSER stuff referenced in the file is for enabling a server chooser screen, as I understand it. I did not try anything fancy with this as I only have the one server and one workstation. This may be worth investigating if you have a larger network and want to be able to login to different servers.

Step 3:
Edit your xdm-config file to contain the following:
DisplayManager*chooser: /opt/kde2/bin/chooser
My xdm-config file was located in /etc/X11/kdm, yours should be in the same directory as your Xaccess file. Additionally, if the file contains a reference to "DisplayManager.requestPort: 0", make sure that the line is commented out with a bang (!) at the beginning.

Step 4:
Create an X0.hosts file that'll list the hosts that are allowed access to your server on display 0, and place it in /etc. Enter the hosts as hostnames (resolvable from your /etc/hosts file), or as IP addresses, one host per line. I also created an X1.hosts file which is just a symlink to X0.hosts, which gives the hosts allowed to connect to your server on display 1. (I think).

Step 5:
If using kdm in KDE 2.2.1, edit the kdmrc file, mine was located in /opt/kde2/share/config/kdm, so that Remote logins are enabled. There is a section titled [Xdmcp] at the end of the file where you do this:

[Xdmcp]
Enable=true
KeyFile=/etc/X11/kdm/xdm-keys
Willing=
Xaccess=/etc/X11/kdm/Xaccess


Step 6:
Restart your X server.

Logout of X
Ctrl-Alt-F1 to get to a console screen
login as root
telinit 3 (or /usr/sbin/init 3)
make sure X has shut down completely
telinit 5 (or /usr/sbin/init 5)

Client Side
From a console login (not a graphical login), execute the command
X :<display number> -query <server IP or hostname>
<display number> can be whatever display number you wish to connect on, I used 1. Your graphical login should now appear on your screen.

Resourses
LinuxDoc:

http://www.linuxdoc.org/HOWTO/mini/XDM-Xterm/index.html

http://www.caldera-benelux.com/ta_xdmcp_support.html

Caldera:

http://www.caldera-benelux.com/ta_xdmcp_support.html

Mailing lists:

Linux-users: http://linux-sxs.org/mailman/listinfo/linux-users

Caldera Users: http://www.caldera.com/support/foruns/users.html

XDM on Windows - nice little trick

From: "Sulis, Adam" SULISA@tc.gc.ca

Configuring XDM for remote usage

This is used when you want to view a Linux PC's X-session on another PC. The example here uses Labtam's XWINPRO 5.1 for Windows 95 connecting to Corel Linux 1.0 and possibly others.

Server-Side

- Edit /etc/X11/Xserver and change the second line from "Console" to "Anybody"
- Make the directory /old_rc4.d
- Copy /etc/rc4.d/S99kdm to it. Delete the original S99kdm.
- Copy /etc/init.d/kdm to old_kdm.
- Copy /etc/init.d/xdm to kdm
- Edit /etc/X11/xdm/Xaccess Locate the line that looks a bit like:
#* #any host can get a login window
- Remove the leading #
- Execute the commands:

/etc/init.d/xdm stop
/etc/init.d/xdm/start

Client-Side

- Download and install XWINPRO 5.1
- Run Xsettings
- Select "Use XDMCP". Enter the Settings screen
- Enter the IP address of the Linux PC.
- Select XDM Authentication
- exit out and launch Xsession

Thanx,

[Stephen]

I thought so, but that was a long time ago. I'll go in next week and resinstall a couple of PCs to start over from scratch. I've made so many modifications as advised on this forum that I can't keep track of what I did anymore!

Always write comments to yourself in the files that you change and when changing the options comment out the line you are changing and create a new line with the changes this way you can go back to the defaults and not have to remember what they were. And keep a changelog.txt file in your home directory on every machine you touch where you can document what you did to the machine and why.

[RockMumbles]

Have you tested your xdmcp setup on your server machine (as horo suggested), log in to a console as root and test your setup with this:

X *:1 *-query *localhost

that should start up a kdm, gdm, or xdm graphical login on vt8, if you get the login screen your configuration on your server is OK.

Question, are your machines on a windows 2k-pro or xp-pro dhcp network?

Maybe slightly off-topic, but... I have problems at school which I attribute to our win2k dhcp server, with both remote-X logins and PXE booting. In our teaching computer lab (about 25 machines) where we have a single network connection to the entire lab, I would put a linux firewall (freesco) between the lan connection and our main switch, freesco would then be the dhcp server for the lab, and both linux and windows would be able to work. At home behind a freesco firewall as the dhcp server, I've had no problems running clusterknoppix and PXE booting or with remote-X logins, but at school I can't get the PXE boot disks to work at all, and the remote-X logins are sporadic, sometimes it works, sometimes it doesn't.


~rock

[A. Jorge Garcia]

Always write comments to yourself in the files that you change and when changing the options comment out the line you are changing and create a new line with the changes this way you can go back to the defaults and not have to remember what they were. And keep a changelog.txt file in your home directory on every machine you touch where you can document what you did to the machine and why.

Stephen, you are SOOOOO right! I don't know why I didn't do that. I'll have to start doing so. This is great, my students already think I'm a bit cracked, now they're going to think I've lost entirely leaving notes to myself....

Thanx,