GDM setup

[Bob Arendt]

Matthias Clasen wrote:
> On Mon, 2008-05-19 at 10:35 -0700, Bob Arendt wrote:
>> Matthias Clasen wrote:
>>> On Mon, 2008-05-19 at 10:50 -0600, John.Mizell at tch.com wrote:
>>>> It seem that there is not an setup gui for GDM now in fedora 9. I also
>>>> checked to see the documentation at
>>>> http://live.gnome.org/GDM/2.22/Configuration but it it not clear on how to
>>>> enable remote x11 apps to display locally.
>>>> Is there a work around and will this be added in a gui setup later on?
>>> Just having remote X11 apps display locally does not really involve gdm
>>> and should work fine in F9. If you are talking about xdmcp, them yes,
>>> that does not currently work. The basic support for it is there, but it
>>> is not quite complete, afaik.
>>>
>> Actually, it does involve gdm.  When starting the Xserver, gdm tacks on
>> a "-nolisten tcp" argument, inhibiting direct display to the Xserver.
>> You can work around this using "ssh -X" to tunnel the X-display, but this
>> may break some existing work-flows.  There used to be a config param
>> in /etc/gdm/custom.conf to set DisallowTCP=false to acheive this.  An
>> equivalent setting doesn't show up in the new gdm schemas.
> 
> Yeah, I guess for me 'remote X' is synonymous to 'ssh -X' (or rather -Y
> nowadays). Really, the right thing to do is to update those existing
> work-flows. The default firewall configuration won't let straight X
> connections through, anyway.... 
> 
> Is there some specific reason why ssh tunneling does not work for you ?
> 
ssh tunnelling does work for me, today.  But a couple of places I work with
have a very non-hetrogeneous mix of server-display-to-client applications
delivered since ~1998.  They're running local, secure networks without
external connection, so security's taken care of.  Some fairly twitchy displays.
It would take someone a lot of work to hunt down and modify all the scripts
that have been dumped at these places over the years.  It would be one of
those "discovery by breakage" sort of things.  The extra processing overhead
of ssh encryption may or may not be a factor .. but it's not really required in
these deployments.  So while I heartily approve of applying "-nolisten tcp"
by default, having the capability to re-enable remote X11 saves a *lot* of
needless re-engineering.