[GRLUG] GRLug Meetings - volunteers?

[Godwin]

Dave, that command ("set | grep DISPLAY") doesn't *do* anything, but
show you that the server to which a command would send the graphics to
be rendered is LOCAL.  You can set the DISPLAY environment variable to
any box running an Xserver to which you have permission to *write* (or
send graphics).

Alternatively, the "ssh -X" is what tells the (remote) ssh daemon to
pull the graphics (displaying job) back to the client (your local
box).  You can "ssh -X" from Box1 to Box2 then Box3, then launch
'xterm' on Box3 and it will travel all the way back to Box1 - albeit
sloooooow as heck if the boxes are on slow connections or over wifi.
Pretty cool stuff.  There's a proggy called "xrdp" which (supposedly)
allows you to login to an X session on a *nix box using the <gulp>
Windows Remote Desktop Client.

Not easy to setup, but Justin got some use out of it where we work.
Kudos to him too. ;-)

G-



On 2/13/07, David Pembrook <david at pembrook.net> wrote:
>
>  any reason why I shouldn't put the "set | grep DISPLAY" line in my .bashrc
> on the remote box?
>
>  Dave
>
>  Greg Folkert wrote:
>  On Tue, 2007-02-13 at 16:27 -0500, john-thomas richards wrote:
>
>
>  On Tue, Feb 13, 2007 at 04:05:24PM -0500, Greg Folkert wrote:
>
>
>  On Tue, 2007-02-13 at 15:28 -0500, Szymon Machajewski wrote:
>
>
>  This sounds good Mike.
>
> Let's make the March 1 meeting at GRCC in 214ATC.
>
> As the first point of discussion we will take X11 forwarding over SSH.
>
>  ssh -X -A somenode.somedomain.dom
>
> Once there:
>
> set | grep DISPLAY
>
> The run your X proggy. Example follows.
>
>  greg at prince:~$ ssh -X -A duke
>  Last login: Tue Feb 13 15:54:38 2007 from prince
>  greg at duke:~$ set | grep DISPLAY
>  DISPLAY=localhost:10.0
>  greg at duke:~$ sudo synaptic &
>  [1] 12720
>  greg at duke:~$ jobs
>  [1]+ Running sudo synaptic &
>
> I have full GUI from the remote machine.
>
> Cheers.
>
>  Everything is intuitive once you know how to do it. :-)
>
>  Or as I like to say:
>
>  I knew it as soon as you said it.
>
>
>
>  A few questions:
>
> Why would I start an app from a command line?
>
>  Mainly because most typically only single application running at a time
> from a remote host. Also, that is why I backgrounded it, so I could run
> another app.
>
>
>
>  Is the command line via ssh or is it from within an xterm?
>
>  You could in theory run the whole thing from an icon with the proper
> options in the command being run by the icon.
>
> But I typically have about 20 X-terms (gnome-terminal actually) open at
> any one time while working.
>
>
>
>  Does this automatically start a window manager?
>
>  Why would you want *ANOTHER* window manager running, since you already
> have one local?
>
> In any case TRY running a Window Manager before an app a second, you'll
> discover something fairly basic, when you fully understand "X"
>
>
>
>  What do I use as an X server?
>
>  You only have to use you LOCAL X-server. Remember, X is opposite of what
> you would think. The Graphics are being rendered locally on your machine
> in front of you. So *THAT* is why it is called an *X-Server*. The actual
> machine the program is executing on (the traditional server) is actually
> a *X Client* to your *X Server*. It sends the info that needs to be
> rendered to you local machine.
>
>
>
>  VNC?
>
>  (or VINO or any of the other ones like it)
> Yes you could use it, but then you are forcing the REMOTE machine to
> execute the program *AND* render it AND then SEND 100% of the screen
> updates. More work on the remote end AND typically more network traffic.
> There are some features the VNC and the like have over straight X stuff.
>
>
>
>  Something else?
>
>  You've basically covered the 2 methods I have used with any luck. There
> are other methods out there, but most are sorely lacking.
>
>
>
>  Can I disconnect/reconnect a la screen?
>
>  VNC and those kind, do in fact allow this. The straight X stuff does not
> (well it can but not without a TON of work that is not work worth
> doing.)
>
> Another thing, VNC typically is not encrypted. Unless you have the
> "commercial version" or you setup forwarding through ssh. Which if yo
> are going to that length you should use... err well more in a bit,
> below.
>
>
>
>  Does this provide me a full-fledged desktop environment of my
> choice (dr16)?
>
>  Okay, you already have your choice of local desktop, why duplicate the
> work being done on you local machine. *IF* you really want a Full
> desktop support from the remote machine, you should enable XDMCP on the
> remote machine. The then create an ssh-tunnel (using forwarding to
> specific ports) and then use an Xnest flexiserver session to query and
> login to you remote machine through the tunnel.
>
> To be honest, if you have a local X-Display... Why would you want to do
> that? If you are trying to circumvent $EMPLOYER's Anal-Retentive network
> admins, there are far better ways to do it, than this way.
>
>
>
>  Good thing we will have an entire presentation. Bad thing that it starts at
> 4:00PM.
>
>  Ok, have at it in the presentation.
>
> One last note. Personally, I don't get why people have such a hard time
> understanding "X". Once it has been explained as the "X Server" is at
> the machine driving the monitor and that it can be managed either
> locally with metacity, beryl, compiz, sawfish (formerly sawmill),
> Enlightenment, icewm, blackbox... etc. or remotely managed with the same
> window managers or even remotely with commercial window managers like
> CDE.
>
> Remember this, Display Managers are local, Window Managers can be either
> local or remote. Applications can be remote or local regardless of the
> Window manager being remote or local. Heck, I can even make a local
> application bounce back to the remote machine and then display locally.
>
> What it really depends on, is understanding the methods and restrictions
> X sets upon you. (hint: I've pretty much already explained them to you)
>
> Cheers.
>
>  ________________________________
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>


-- 

Ubber::Geek
http://grlug.org/