[K12OSN] one more time

[Les Mikesell]

On Wed, 2005-02-23 at 12:50, Sharon Betts wrote:

>  I want to implement a Linux terminal server to serve GIMP, some TUX
> stuff, Scribus, Kino, etc.   The users need to be able to access the apps
> on the windows terminal server as well  and print to network printers and
> save/load from their folders (on the Windows file server).  These are
> elementary students and teachers -- things must be pretty seamless for
> success.  This is my pilot school -- I have 4 others presently running
> purely WIndows networks (except for one standalone LTSP project with thin
> clients).

> Best scenario --At each school, my windows authentication and file servers
> remain, and I add both WIndows and a LInux terminal servers and get away
> from all those locally installed apps.  Obviously adding Windows terminal
> servers is no problem, its the linux....

If your clients already boot to a point where they can run X locally
(and Windows Cygwin X is OK), then you don't really need the ltsp
part of k12ltsp.  You have several options in the way you run X
remotely, though:

If you want the whole desktop, start X with:
  X -query server
or for cygwin it is Xwin -query server.
This should give you a graphical login box, followed by displaying a
complete desktop.  On windows/cygwin, this will appear to be a single
near fullscreen size window that you can still minimize and move if
you have other windows open.

If you just want one remote program to run in a local window there are
also a couple of ways to do that.  X has it's own concept of remote
windows controlled by the $DISPLAY environment variable. If you telnet
to a remote box, export DISPLAY=localbox:0 and run an X application, the
window will open back on your local desktop. This method is insecure and
generally blocked by default but can still be used with some setup work.
The more common way these days is to ssh to the remote server and let
ssh tunnel the connection back.  You may need to specify -X (or in
recent versions -Y) to the ssh command to activate X tunneling.
With Windows/Cygwin, you would use 'Xwin -multiwindow' mode to let each
remote app run in what appears to be its own MS-managed window.

After you decide which of these modes you want to support, you can
do some infrastructure work to make it more transparent, like mounting
the same home directories in all the servers and clients, setting up
up ssh keys for passwordless access, and attaching ssh or rsh commands
to menus or icons to start the remote programs.  You may also have
to deal with firewalling issues since X reverses the expected
'direction' of the connection. That is, the program connects to the
display, but ssh forwarding eliminates some of those problems.


-- 
  Les Mikesell
   les at futuresource.com