Turn off encryption from client to server?

Wed Aug 15 17:55:55 BST 2007

Hi Gavin

Gavin McCullagh schrieb:
> Hi,
>
> 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 192.168.0.254 /bin/bash --login -c ' env  LTSP_CLIENT="demo" PULSE_SERVER=tcp:192.168.0.244:4713 ESPEAKER=192.168.0.244:16001 DISPLAY=192.168.0.244:6 /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:
>
> echo $DISPLAY
>
> 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 "192.168.0.244:6" or whatever's in the "DISPLAY=" above.
>
>   
I tried the same like I did yesterday on an other server and it was 
working this time without any issue.

Meanwhile it also working on the system, form Yesterday. We tested the 
system this afternoon with 11 thin clients ( 11 stundents) , and noticed 
that the performance issues are gone...

Great is working.
Thank for your help!

In 2 weeks we are going to test Edubuntu with 20 computers, lets hope 
its also manage this !
>> 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.
>
>   
Ok, I will deactivate XDMXP.

>> 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.
>   
Yes we have S-ATA drives, but some systems have IDE drives

> 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.
>   

I wasn't aware of the option M, I will try that out ...
> 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.
>
>   
With 10 users the system is using 1.1 MGyte of 2 gByte

> 4. Set up a proper monitoring tool like munin to get more detailed
>    information on your system performance.
> 	http://www.debianadmin.com/monitor-servers-and-clients-using-munin-in-ubuntu.html
>
>   
I will have on look on that, later on ...

>> 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.
>
>   
Now, up to know, everything is working!

Thanks a lot !

Philipp
> Gavin
>
>
>   