Turn off encryption from client to server?

Gavin McCullagh gmccullagh at gmail.com
Wed Aug 15 09:23:25 BST 2007


On Wed, 15 Aug 2007, Philipp Hanselmann wrote:

> I tried that (LDM_DIRECTX=True), but I am not sure if is really working
> under Feisty:
> On a thin client I noticed that ssh is still running with encryption!
> # ps aux | grep ssh
> ssh -v -c blowfish-cbc,aes128-cbc,3des-cbc -M -S /tmp/.ltspfs-socket user11 at /bin/bash --login -c ' env  LTSP_CLIENT="demo" PULSE_SERVER=tcp: ESPEAKER= DISPLAY= /etc/X11/Xsession && ltspfsmounter all cleanup ' ; kill -1 $PPID

ssh will be using encryption, as it should.  However, the X conversation
will be had in the clear.  You can verify this by typing:


in a session on a thin client.  If the X data is being encrypted, you'll
get an answer like "localhost:12.0", whereas if LDM_DIRECTX is working
you'll get "" or whatever's in the "DISPLAY=" above.

> Independently, to bypass the encryption, I tried to active XDMCP like this:

I would suggest going back and making LDM_DIRECTX work.  It will, for
example, stop people from sniffing logins passwords off the wire which
XDMCP allows.  It's also better tested and more commonly used.  Once you
are no longer encrypting X traffic, the load caused by the ssh session will
be minimal.

> SchoolNet has about 300 customers with a thin client solutions provided 
> from us. All this costumers have between 5 to 20 clients (400 MHz, 96- 
> 128 MB) connected on a server (Pentium 4, 3GHz, 2 - 4 Gbyte). The 
> testing which we have done up to know with Edubuntu Feisty, shows that 
> with our actual hardware (Pentium 4,3GHz, 2 - 4 Gbyte) , Edubuntu Feisty 
> can't support not more than 10 thin clients.

You need to establish what bottleneck you're hitting here.  It could be:

 - running out of RAM (and then swapping)
 - disk access bottlenecks
 - cpu overload (ssh encryption could contribute to this)

If you have a Pentium 4, this may not be server hardware which means the
machine and in particular the disks may be desktop-oriented IDE or S-ATA.
Disk access might very well be a bottleneck in this configuration.

> I assume we can reach again 20 thin clients, if the encryption is 
> switched off! Like our server is protected by a firewall (Shorewall) we 
> don't need the encryption!

When you say "reach again 20 thin clients", you apparently had 20 before?
What sort of setup was this?  Were you using edubuntu dapper or K12LTSP or
something else?

You can't assume LDM_DIRECTX will fix the problem unless you know X
encryption is the problem but you can try it out of course.  You need to
find out more directly what the problem is.

Try looking at performance monitoring tools to diagnose what is slowing the
machine down.  You can start off by

1. Looking at "top".  Are there rogue processes using up the CPU?  There's
   only one CPU so it doesn't take much to cause problems.  You can press
   'M' to sort processes by memory usage.

2. Looking at the load average
	gavinmc at boing:~$ uptime
	 09:08:45 up 11 days, 19:43,  2 users,  load average: 0.21, 0.21, 0.08

3. Looking at the output of free
	gavinmc at boing:~$ free
             total       used       free     shared    buffers     cached
	Mem:       2059656    2014164      45492          0     383708    1053664
	-/+ buffers/cache:     576792    1482864
	Swap:      1951888        548    1951340
   paying particular attention to the amount of swap used (548 in this
   case).  If that's large, you're running out of memory and swapping.

4. Set up a proper monitoring tool like munin to get more detailed
   information on your system performance.

> In our actual solution (getopenlab) we using a KDE desktop, so I think 
> Gnome should have a slightly better performance! I hope I am note forced 
> to implement a other light weight desktop, like XFCE for example.

I don't think GNOME is known to be any lighter than KDE.  Probably the
opposite in fact.  If you're really running out of RAM (which seems
unlikely with 10 people), it's possible GNOME is a contributor.

It's possible you're uncovering some bug here which could be fixed.


More information about the edubuntu-users mailing list