Thanks to everyone who responded, here's the original request + a bunch of
correct replies.
Simon
------------------------------------------------------------
Running xdm pretty much out-of-the-box, and I'm having problems with eXceed, a
PC X server. Using XDMdirect mode, I get an offer of management from the
alpha, but then if I choose it I get 'Fatal error: XDM session declined'.
Other departments here have seen similar problems with this where previously
there was no problem (eg OSF V1.3 and V2.0). They also claimed problems with X
terminals.
EXceed is an X11R5 server which supports MIT-MAGIC-COOKIE-1 at least, maybe
also XDM-AUTHORIZATION-1.
I did get a Sun running stock X11R5 to make an xdm connection. I can also get
that same Sun to manage the PC X server (as will our HP's running vuelogin).
Anyone know of any xdm anomolies with OSF V3 and above?
Simon Greaves
censjg_at_caledonia.hw.ac.uk
DDI: +44 (0)131 451 3265 Fax: +44 (0)131 451 3261
ps I tried running debugging from the PC X server, it looks like there's some
XDMCP negotiation regarding XDM-AUTHORIZATION, then the server declines
service.
-------
From: c.i.dalton_at_clss1.bangor.ac.uk (C I Dalton)
Yep. I believe the changed behaviour occurred between version T3.0-1 and
version 3.0 of osf/1.
I suspect it has something to do with the following extract from the
release notes for 3.0:
"Other Changes: Support for XDM-AUTHORIZATION-1 X Client authorization
mechanism."
By default, eXceed sends a XDMCP authorization key of "xdmkey". If you delete
this
via the Protocol Settings option of Xconfig under eXceed then you
should return to normal behaviour. I think before version 3.0, xdm on the alpha
ignored this "xdmkey" string - now it doesn't and expects a "proper" key
or no key at all.
Of course, if you have a lot of PCs running eXceed then this may not be viable
to alter the configs of all the PCs. I haven't had time to find a better
solution.
The xdm behaviour of 3.0 is also found in version 3.2.
-----------------------------------------
From: cannell_at_ed8200.ped.pto.ford.com
Set your xdm-key to null. With it set to something it is attempting to use
xdm-authentication. XDM under 3.0 DEC Unix will honor xdm-authentication.
-----------------------------------------
From: luchini_at_tolosa.ups-tlse.fr (Marco Luchini)
}SUMMARY: XDM session declined
}
}Jonathan.J.B.Buchanan_at_Oda-3.CS.CSH.COM
}Fri, 16 Dec 1994 15:23:01 +0100
}
} Messages sorted by: [ date ][ thread ][ subject ][ author ]
} Next message: William Gianopoulos {84718}: "Problems with long alias lists
} under DC OSF1 3.0"
} Previous message: Sheila Hollenbaugh: "Partial SUMMARY NFS directory
} corruption"
}
}I wrote:
}
}> I just upgraded a load of machines from OSF/1 2.1 to 3.0. We
}> have a community of PC users (running Pathworks, Chameleon,
}> Exceed... I think) who start an X display using an XDMCP
}> query to the OSF/1 machines.
}>
}> Under OSF/1 2.1 they always got the pretty DIGITAL X display
}> login screen. Now they get the message
}>
}> <STOP> Fatal error: XDM session declined
}>
}> I've checked /usr/lib/X11/Xaccess, which is unchanged from
}> before. I also tried adding open wildcard access, and
}> listing node names explicitly, all without success. Security
}> on the PCs is turned off altogether!
}
}The solution came from Keith McCabe (Keith.McCabe_at_ranplc.co.uk)
}who wrote:
}
}******************************************************************************
**
}
}The latest version of osf/1 (v3.0) has the ability to use XDM-AUTHORISATION-1
}(something I'm a little confused about because I thought this used DES
encryption
}which us guys outside of the US don't get exported to us) for the Xserver
process to
}authenticate clients.
}
}Note the following two lines in /usr/lib/X11/xdm/xdm-config:
}
}DisplayManager._0.authorize: true
}DisplayManager._0.authName: XDM-AUTHORIZATION-1
}MIT-MAGIC-COOKIE-1
}
}The Xserver will try to use XDM-AUTHORIZATION-1 authentication if the
}client supports
}it. Your Exceed clients are able to use this protocol and so they attempt to
}verify each other in this way. However, you will also see the line:
}
}DisplayManager.keyFile: /usr/var/X11/xdm/xdm-keys
}
}in xdm-config.
}
}This is the file in which the Xserver tries to look up the unique xdm-key for
}your clients.
}
}As your clients have no entries in this file (indeed the file doesn't even
exist!)
}the authentication fails and your clients are rejected.
}
}Solutions:
}
}1) make the entries for your clients in this file. You can find the xdm-key
from
}the PC application in one of the menus and enter it in this file along with
the
}client id.
}
}2) turn off XDM-AUTHORIZATION-1 in your clients (this is what we did). If
}security
}is not such an issue for you then you may disable XDM-AUTHORIZATION-1 and
}the
}Xserver will not attempt to use this verification with your clients. You may
notice
}that older Xterminals work fine with your Xserver as they don't know about
}XDM-AUTHORIZATION-1 anyway.
}
}******************************************************************************
**
}
}In our case, we use Exceed v3 and need to go to the XConfig
}Protocols setup to sort out the PC configuration.
-----------------------------------------
Thanks also to: Hellebo Knut <bgk1142_at_bggfu2.nho.hydro.com>
joe_at_resptk.bhp.com.au
Received on Tue May 09 1995 - 09:01:22 NZST