See bug #76929 in particular PAM.
Trying a Wyse Winterm with XDMCP direct. I see the login widget then it
dies. (The Wyse Winterm then starts up and can then RDP login to xrdp
package I have running on system. Really should do X to a Linux box.
Wyse Winterm can not do ssh -X due to a problem with it. This like RDP
carries an unnecessary overhead for properly managed LAN. The X
client-server model is far superior.)
Looks like quite a few more files now need to be changed before xdm
will work. Would be nice if it just worked.
/var/log/xdm.log: --
Should I really need to put DHCP pool in the DNS? This is a test
machine and some one else looks up reverse for 10.in-addr.arpa.
not use xdm for local display.
Xaccess (had to uncomment these): --
* #any host can get a login window
* CHOOSER BROADCAST #any host can get a chooser
These were originally commented out on my install.
xdm-config (had to comment this out): --
!DisplayManager.requestPort: 0
This was not originally commented out on my install.
Xservers (commented this out as not needed): --
#:0 local /usr/bin/X :0 vt7 -nolisten tcp
Then tried patching /etc/security/pam_env.conf too: --
REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST}
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
These were originally commented out on my install.
Now get login, but don't get session. Goes back to login.
The remote display is 10.253.0.20.
Does xrdb conflict with this package!?
~/.xsession-errors: --
/var/log/xdm.log: --
Remote display is actually 10.253.0.200 00:80:64:32:01:70 (Wyse Technology) The ps command just displayed: --
Hello, Please find the solution to the bug contained into XDM. You recently wrote: Looks like xdm is working just fine, but your session is exiting after 1s. Check out ~/.xsession-errors maybe? Closing as not our bug. Cheers, Julien------------------- The proposed solution is unfortunately not leading to any hints/clues of what is going on. ~/.xsession-errors contains normal lines. However, a solution is as follows to solve the bug issue of xdm. It is simply due to the fact that xdm stores into its configuration wrong inputs. I have been tried all kind of ways, and in order to make xdm work again to overcome the bug, one must follow the following steps. (1) You login as root, and you enter the following to rebuild the xdm: On machine that have no kdm (problem between xdm and kdm), you must type (killall kdm) is not necessary. (2) /etc/init.d/xdm stop; killall kdm; /etc/init.d/xdm start Stopping X display manager: xdm. kdm: no process found Starting X display manager: xdm. If you have had previously kdm, on the linux machine, you'd better kill kdm. (3) it should now work Alternatively: If for all the users that cannot login and that complain about your installation, you simply have to tell them that the xdm is reloaded/restarted and that they have to be patient. This bug issue will be fixed soon or later, and if it does not work again, they can type as user (not root): cd ; rm .Xauthority and this will solve the problem related to the xdm process. This solution worked on 3 machines where this issue has been reported since some time. Maybe an upgrade (i.e. : apt-get update ; apt-get upgrade) ? I hope that this solution will help some users using xdm to make it work and in order to solve this bug of xdm. Best regards / Happy New Year. Y.
Don't abuse other people's reports. Cheers, Julien
notfound 630778 1:1.1.10-3
thanks
On Fri, 17 Jun 2011 17:34:27 +0800 Andrew Buckeridge <andrewb@bgc.com.au> wrote:
> Package: xdm
> Version: 1:1.1.10-3
>
> See bug #76929 in particular PAM.
>
> Trying a Wyse Winterm with XDMCP direct. I see the login widget then it
> dies. (The Wyse Winterm then starts up and can then RDP login to xrdp
> package I have running on system. Really should do X to a Linux box.
> Wyse Winterm can not do ssh -X due to a problem with it. This like RDP
> carries an unnecessary overhead for properly managed LAN. The X
> client-server model is far superior.)
>
> Looks like quite a few more files now need to be changed before xdm
> will work. Would be nice if it just worked.
>
> /var/log/xdm.log: --
> > Fri Jun 17 10:23:58 2011 xdm info (pid 2232): Starting
> > Fri Jun 17 16:23:37 2011 xdm error (pid 2232): Cannot convert Internet address 10.253.0.200 to host name
> > Fri Jun 17 16:23:40 2011 xdm info (pid 2232): Starting X server on 10.253.0.200:2
>
> Should I really need to put DHCP pool in the DNS? This is a test
> machine and some one else looks up reverse for 10.in-addr.arpa.
>
> > 0 items in XFree86_VT property!
> > Fri Jun 17 16:23:40 2011 xdm info (pid 3901): sourcing /etc/X11/xdm/Xsetup
>
> My config files were patched similar to original post, but I also do
> not use xdm for local display.
>
> Xaccess (had to uncomment these): --
> * #any host can get a login window
> * CHOOSER BROADCAST #any host can get a chooser
>
> These were originally commented out on my install.
>
> xdm-config (had to comment this out): --
> !DisplayManager.requestPort: 0
>
> This was not originally commented out on my install.
>
> Xservers (commented this out as not needed): --
> #:0 local /usr/bin/X :0 vt7 -nolisten tcp
>
> Then tried patching /etc/security/pam_env.conf too: --
> REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST}
> DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
>
> These were originally commented out on my install.
>
> Now get login, but don't get session. Goes back to login.
>
> The remote display is 10.253.0.20.
>
> Does xrdb conflict with this package!?
>
> ~/.xsession-errors: --
> > Xsession: X session started for andrewb at Fri Jun 17 16:49:49 GMT-8 2011
> > Client is not authorized to connect to Serverxrdb: Resource temporarily unavailable
> > xrdb: Can't open display '10.253.0.200:0.0'
> > Client is not authorized to connect to Serverxrdb: Resource temporarily unavailable
Hi,
Looking at the logs you sent, xdm was managing the display 10.253.0.200:2, but
all clients in ~/.xsession-errors tried to open 10.253.0.200:0.0. That value comes
from the line you added to /etc/security/pam_env.conf
(DISPLAY DEFAULT=${REMOTEHOST}:0.0): xdm passes the PAM environment
to the session after setting DISPLAY itself, so that line overrode the
correct value. Please remove the DISPLAY/REMOTEHOST lines from
pam_env.conf; xdm sets DISPLAY correctly for XDMCP displays on its own.
The other changes you made (enabling the Xaccess entries and
commenting out DisplayManager.requestPort) are the documented way to
enable XDMCP. It is disabled by default purposely, since XDMCP is
unencrypted and lets any host on the network ask for a login screen;
that default won't change due to security reasons.
I'm now closing this report. If XDMCP sessions still fail with a current
xdm (1:1.1.17) with an unmodified pam_env.conf, please reopen with
/var/log/xdm.log and ~/.xsession-errors.
Thanks,
Boyuan Yang