[plug] laptop screen/keyboard/mouse 2 control the server?

Leon Brooks leon at brooks.fdns.net
Fri Jun 25 09:28:35 WST 2004


On Wed, 23 Jun 2004 16:17, somewhereintime wrote:
> Say my server is up and running, and decided that the monitor/keyboard
> or mouse there takes too much space and i want to free it up

ssh username at servername

You can then run whatever programs you like from that shell (e.g. 
"konqueror &" to fire up a web browser but leave the shell free).

Alternately, you can fire up a complete graphic session "on" the server 
by telling your display manager that it's allowed to listen to other 
than the loopback interface and typing something like this into the 
text mode on your laptop:

    startx -- -query servername

If you want a KVM-like effect, you can do this as a separate X session 
(Mandrake has a menu entry for doing this under most window managers, 
notably KDE) and flip between them using (typically) Ctrl-Alt-F7 and 
Ctrl-Alt-F8. From the keyboard, with a normal session already running, 
this works for me:

    startx -- :1 -query servername

You can also run a graphic screen "on" the server and display it in a 
laptop window using Xnest:

    startx -- :1 -query servername

As a kind of glossary, the X server is the piece of software which 
actually writes the pixels into the display hardware. Programs send 
instructions like "draw a rectangle here, paint this bitmap there" to 
the X server, which then carries them out.

A window manager stands between programs and the X server to do stuff 
like provide the frames and controls like minimise or close. If a 
window needs to be moved around, the program might never find out about 
it unless is specifically needs to know (for example, it needs to 
redraw a part which was previously covered or off screen) since the 
conversation which achieves this is between the X server and the WM.

A display manager is a piece of software which manages (notionally 
login) sessions on one or more displays. Typically, a display manager 
will do the login prompt bit (maybe arcing up an X server to do this if 
none's running), then fire up a window manager to handle the rest.

All of these pieces are conceptually and potentially physically 
separate. For example, you could be running a program on server A, 
which is fed through a window manager running on server B and displayed 
on workstation C which was logged in by a display manager running on 
server D. More typically, you will be SecureSHelled into server A 
(which covers the login (or DM) aspect) from laptop E and feeding the 
program's X instructions through your compressed, encrypted connection 
to the laptop's WM and X server.

In MS-Windows, all of these separate functions are mashed together in a 
big sticky mess. While some of the layers can be peeled out and dealt 
with separately, their boundaries are not so well defined and certainly 
not network aware. As a consequence, effort is very rarely ever put 
into managing these by developers.

Another way of managing your server is with VNC. This is platform 
independent (so your laptop could be running MS-Windows or even 
MS-DOS), but much slower and less efficient than X over a LAN.

Cheers; Leon



More information about the plug mailing list