Re: Thin-X-Client-Laptop
> > I've also found the vncserver/vncviewer combo to be very useful
> > in this context: even the window manager runs on the server,
> > so the laptop load is very thin indeed.
> Why is that better than using the X protocol to run the window
> manager on the remote/fast machine, like both sets of instructions
> already posted would accomplish? If your WM is a resource hog, you
> definitely want to run it on the fast machine. I suggested running it
> locally for better performance, but running DISPLAY=laptop:0 start-kde
> (or whatever the command is) on the fast machine will do all the work
> except drawing on the screen using the fast machine.
Sure.
> > And it protects you
> > from laptop glitches (have to reboot that old laptop, no
> > problem; just reconnect to the vnc session after.
> Ok, that's a small advantage.
Not so small for me. My whole desktop is on the rock solid
duron box with 256MB and a 30GB hard drive, not the eBay
laptop or the touchy win32 box or any other workstation du jour.
> > The other
> > day I started an email (in mutt) in a vnc session on my
> > fiance's computer, then had to go eat, then came back and
> > continued it on my laptop in my7 living room, and finished
> > it off the next day from the office. That's cool.
> And is also easy, no matter what you're using. Just save the message
> and exit the editor, and tell mutt you don't want to send it. It will
> ask you if you want to keep it, and if you say yes, it will ask you
> later if you want to recall saved messages. Almost all mailers
> support resuming composition later.
You don't get it. My whole desktop never goes away. I don't
have to close my email program, much less save my work in each
app. If I have ten konqueror windows open at different
websites, they come along too.
My terminal environment is unstable (office, living room, other
office, maybe wireless some day) but my X server is rock solid.
It's not just the one app that comes along, its all the open apps.
I don't have to remember how to save my state in this app,
and that app and the other. I just leave it all running and
hook up to it at the next place I sit down. I sit down at the
workstation du jour and my desktop comes to me. In the state I left it.
All open apps are still open. Anything in progress
is still in progress. I start a compile at breakfast and its
done by the time I get to work (and I have the xterm in
front of me when I get to the office). Truly a thing of beauty.
Damn, I'm sounding like a True Beleiver. Should we move to
an "advocacy" forum ;)
> > And one of the machines was a Windoze box!
> PuTTY is all you need on the 'doze side, at least if you are used to
> the command line. (Without a handy 'nix machine, you need cygwin, and
> maybe XFree86-win32 (see sourceware.redhat.com. I haven't tried it, but
> it would be great if it was nicer than the demo versions of some
> commercial X servers.)).
VNC vs XFree86-win32:
VNC is way more foolproof than trying to make a windoze box
into an X server. Maybe X under win32 is solid now.
Personally, I'm not going to take the chance, when I already
have a solid, working and more functional choice.
When last I tried this, the commercial stuff made
you learn all kinds of weird config and launcher programs
(Hummingbird) or was vapor or trialware or buggy. I ran
Hummingbird for a year and it drove me nuts.
VNC vs. Putty: Why restrict yourself to text apps?
> > > > In textmode I am able to ping and telnet the server.
> > >
> Let me add: disable telnet access to all your computers. There is
> no reason to ever use telnet.
I agree.
> There are reasons to keep
> using FTP, since it is more convenient in some cases.
Trash the FPT server. I use FTP client but never ftp server.
My box has one port and one port only open to the net: ssh.
> (BTW, netcat
> does a better job than the telnet client for random poking around at
> TCP ports that aren't using the telnet protocol, so you can trash it
> too.)
> Err, ok, I thought of one. My local library allows telnet access to
> the catalog and some services. They probably service a lot of
> connections at once, so all that encrypting might take up some CPU
> time. Also, requiring people to get ssh when they could use the
> telnet client that came with their system would make things less
> convenient for the casual user.
>
Trash the server (telnetd), but not the client (telnet).
Use telnet only where security is not really an issue. Use
ssh where you'll be doing anything using a real password.
> ... BTW, you should put Cipher blowfish in
> /etc/ssh/ssh_config, so you don't have to type it all the time.
Well, I use other opts too with ssh (e.g. with -C compression for
interactive but without compression I'm tunneling something that's
already compressed like rsync'ing .gz files or vnc with tight
encoding so I'm usually using ssh inside an alias or script
anyway.
> > And I transfer files with
> > rsync -e ssh instead of ftp.
> Or just scp, for single files. It has a -r option. If you're used
> to rsync, then there's no need to learn to use scp, I guess.
> > > > What do I have to do now? - as I am a beginner in Linux please send me 'foolproof`' instructions and hints.
> >
> > Easier said than done ;)
>
> ... If you're not up to understanding it, or you don't have time, you can
> probably find yourself a cookbook solution for yourself. One of
> Unix's problems is that cookbook solutions are terribly non-obvious
> and don't make much sense to those using them.
Unix solutions are built from parts. Solid and versatile
part. Once you understand the solution you understand a bunch
of parts that can later be used in other solutions. So there's
a learning curve but you really are learning useful stuff.
(Tho it's not always obvious at the time ;) )
> ...Besides that, they are
> prone to breakage under conditions that only someone who understands
> the whole system could predict.
> great examples of this:
> http://catalog.com/hopkins/unix-haters/handbook.html
Oh, I'd say Windows does a much better job at this. Hell, in
Windows even MS trained and certified consultants often have to
resort to "Uh, I guess we'll have to reinstall it". In Unix
you soon get past that.
> If you find that X is giving you grief, maybe you can take comfort in
> knowing that you're not alone, and that at least you're not trying to
> run it on a Unix workstation with less power than your 486 laptop:
> http://catalog.com/hopkins/unix-haters/x-windows/disaster.html
> There are a couple good rants in there about xauth, etc.
> We are fortunate that the Free software world has settled on XFree86,
> so common extensions are used by lots of programs without trouble,
> unlike during the time when th X disaster page was written. Anyway, X
> is still very far from perfect.
Oooh. Oooh! May I plug VNC again? You get it working, and
then you don't have to worry about your X to X network
authorization and communication stuff, which is a whole can
of worms. And security issues. VNC tunnels very neatly
under ssh and X tunnels very neatly under VNC. Of course X
also tunnels very neatly under ssh with VNC but then you
don't get the whole resuming a session thing, nor the whole
resuming the session on another terminal thing.
> > Uh, I don't think this will work. You need some kind of X magic
> > authorization cookie or something. IIRC you can maybe
> > transfer the ~/.Xauthority file or use xauth so the other
> > machine/user has permission to use your X display. Suggest
> > you check man xauth and/or XFree86-HOWTO and/or Thinclient-HOWTO .
>
> It depends on how you started the X server. If you ran X on the
> console, xauth stuff won't be on. In that case, I forgot to mention
> that you will have to use xhost +fast-machine to allow X connections
> from it.
<voice personality="Jon Lubbox">Yeah. That's the ticket.</voice>
That's what I meant. xauth or xhost or somthing like that. Yeah.
'xhost +(machine)' is still open to IP spoofing attacks but it is
more secure than the very easy and dangerous 'xhost +' which
leaves you open to any machine using your X display (for example,
to capture keystrokes!). I vote for ssh tunneling! ssh -X
on Debian.
> Sorry for the omission. If you used startx, then it will
> have set up xauth, so you should locally (on the laptop) run xauth
> list, then paste the laptop:0 line onto the end of an xauth add on
> the fast machine.
I've used 'xhost +' in this context too. I think you can
get through either by
1. weakening the servers security (xhost + or xhost+machine)
or
2. giving the client the authorization cookie ('xauth' in an
xterm on the X display-server machine (laptop), and
'xauth add <pasted stuff>' on the commandline you want to give
access to the X machine.
Been there, done that, too many hoops to jump through,
sticking to (guest what, drum roll please) VNC. It really is
much easier.
In VNC it takes two steps.
On myserverbox I run 'vncserver :1 -geometry 1024x768 -depth 16'
On my laptop on the LAN I run vncviewer myserverbox:1
Going through the big bad cloud, I run 'vncviewer -tunnel
myserverbox:1' instead so it goes through ssh.
> #define X(x,y) x##y
Been there, done that too.
Now I use C++ templates, except when I have to fall back to
rpcgen compatibility :(
--
Tony
Reply to: