Documents do not mention on how to enable remote x, defaults to -nolisten tcp. Docs @. http://live.gnome.org/GDM/2.22/Configuration Or is there a way to get 2.20 back, 2.22 is not ready for people in a Unix environment.
Looked through the maillist. It's not possible. "That's correct we don't have a way to allow tcp connections to the x server at the moment. It is on our to-do list: http://live.gnome.org/GDM/ToDo" Thanks for putting a half working system in production.
Really keen to see this fixed too.
David, to get around it. Run or switch to run level 3, and then run x with startx. GDM also prevents a lot of other Gnome applications to run, specially from the CLI since DISPLAY is set to ip:0. This is a typical Microsoft Windows thing. Who ever got rid of tcp never worked or has seen a Unix shop.
This is a real pain. I worked around it (for the moment) by using kdm instead. in /etc/sysconfig/desktop DISPLAYMANAGER=KDE You can still use gnome. If, like me you have heaps of users, kdm presents them as a vertical list so you only see the first 10 or so. Not tested in a large environment either. In /etc/kde/kdm/kdmrc fix the relevent settings. UserList=false ServerArgsLocal=-br -nolisten tcp
Do I understand correctly that [security] DisallowTCP=false in /etc/gdm/custom.conf is ignored on purpose? At least it does not work for me using gdm-2.22.0-5.fc9.i386. If so, why? Is this one of those lets-remove-a-feature-for-the-hell-of-it GNOME things?
No, No. This is more lets get rid of as many features as we can. gdmsetup, no tcp (which brakes also apps started from cli which rely on DISPLAY set to ip) , no autologin, make the login screen look really amateur, just come to mind. Or who needs Unix/Linux features lets all be like Windows. As you can see I'm not to happy about it. Or Fedora 9. Linus was right ... again.
So, I think we should just toggle this on by default. I mean, 1) the default firewall rules already block tcp access so it's not like there's any added security in the default case 2) it's apparently causing real headaches for people 3) Turning it on by default won't slow down the typical case because we will still communicate over a local socket by default.
It was pointed out to me that a lot of users disable the system firewall at install time, so 1 above doesn't hold true. I'm going to add the old option back instead with it default to off.
gdm-2.22.0-6.fc9 has been submitted as an update for Fedora 9
I don't think that this is the problem here. the old version of GDM had an option to enable TCP. The new one does not. There is no capability at all to enable TCP. DisallowTCP=false does nothing. This means that you _cannot_ use gdm and expect DISPLAY=IP:0 to work _at all_ I have no problem with it defaulting to off but I would like to be able to turn it on.
Darryl, can you try gdm-2.22.0-6.fc9 and report whether it addresses your issue? The point of the update is to add back the DisallowTCP option.
gdm-2.22.0-6.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gdm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5719
gdm-2.22.0-6.fc9 works for me.
That fixes the -nolisten tcp. I still cannot connect to IP:0.0 without playing with xauth. I tried it as root. Log in to get a desktop as root. # xwininfo -root - works # xwininfo -root -display localhost:0 - works # xwininfo -root -display IP:0 - doesn't work (/var/log/Xorg.0.log shows the reject) # xhost + # xwininfo -root -display IP:0 - now works I assume that there is some strangeness with the cookie. Darryl
We don't allow clients to connect unauthenticated. They have to know the generated password (authentication cookie) for the server to allow them access.
That's true. But even root while logged into an xwindows session cannot open a window on that Xserver if the tcp connection is used, ie -display IPAddress:0.0 but -display localhost:0.0 and -display :0.0 works. This is a new behaviour. Authenticated X sessions used to be able to open windows using the IPAddress:0
My IP address is 192.168.12.100. I am logged onto the machine with an X session that is working fine. $ xhost access control enabled, only authorized clients can connect SI:localuser:me $ xterm -display 192.168.12.100:0 No protocol specified xterm Xt error: Can't open display: 192.168.12.100:0 $ xhost 192.168.12.100 192.168.12.100 being added to access control list $ xhost access control enabled, only authorized clients can connect INET:192.168.12.100 SI:localuser:me $ xterm -display 192.168.12.100:0.0 I suspect gdm is not setting the xhost or cookie correctly.
Aghhh, I found this http://www.nabble.com/Why-do-GDM-2.22.0-set-xauth-file-owner-as-login-user-td17371800.html. The behaviour has changed quite a lot. I wonder what is the correct way to use the new regime.
gdm-2.22.0-8.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
It still won't allow using tcp sockets due to xauth. Here is what my machine has using kdm $ xauth list 192.168.12.100:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc 172.31.100.254:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc 192.168.122.1:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc [fe80::21d:7dff:fee6:9b48]:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc [fe80::248:54ff:fe3f:5bed]:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc [fe80::c8ec:18ff:fe37:eb42]:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc [fe80::984e:e0ff:fe64:4dbd]:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc gold/unix:0 MIT-MAGIC-COOKIE-1 e69ee76b144631b1f0d2495c249447fc Using gdm, only the last line (ie unix sockets).
Hi Darryl, I've cloned this to bug 453775. Let's fix the auth entries up on that report (since this one is already closed)
*** Bug 449971 has been marked as a duplicate of this bug. ***