[K12OSN] K12OSN Digest, Vol 74, Issue 15

[Almquist Burke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On May 1, 2010, at 1:42 AM, Mathieu Pelletier wrote:

> With respect, Peter, I think you have not understood my post.  I  
> fully understand that ltsp client applications are run on the  
> server.  This is not my problem.  Perhaps restating my problem may  
> clarify the issue.
>
	It's not just the client applications that run on the server by  
default, the whole session (once you are logged in) is taking place  
on the server.

> I have a server running F13 with the LTSP server setup.  My chroot  
> environment is a F12 installation.  I managed this by adjusting the  
> build client script so that it used F12 instead of F13 which is  
> still in beta.
>
>  Anyway, this created my chroot environment in /opt/ltsp/i386 as  
> per usual.  I can chroot into /opt/ltsp/i386 and run updates for  
> F12 and install applications and the like.  In fact, when my client  
> boots the initial image it gets this information from /opt/ltsp/ 
> i386.  I know this because I changed the LDM theme by replacing / 
> opt/ltsp/i386/usr/share/ldm/themes with my own custom graphics.  So  
> now, instead of the K12Linux login screen I have our college logo  
> and graphics.
>
> Now, when my client logs in, the environment that loads is not the  
> chroot F12 environment, but rather the server kernel and everything  
> else.  This should be loaded from /opt/ltsp/i386, NOT the root  
> directory.  Otherwise there is little point in the chroot  
> environment.  I have seen a few responses from people that "this is  
> the way it is supposed to work."  But with due respect this does  
> not make sense considering that the ltsp-build-client downloads an  
> entirely new (chroot) environment in /opt/ltsp/i386 (or other  
> architecture).  Some of the applications are meant to actually run  
> using client CPU and memory, this is the purpose of a given  
> architecture.  In fact you can even use an old PowerPC as a client,  
> provided you have installed the appropriate client architecture  
> (see the documentation).

	LTSP only loads a minimal operating system onto it's clients. Just  
enough to open  something akin to an RDP session on windows. Once you  
get logged in, you are looking at a session that is running entirely  
on the server. The only thing your client does is send keyboard,  
mouse, and other hardware input (like locally attached storage) to  
the server, and display the images and sound being fed to it by the  
server.
	DRBL use network booting to acquire a full OS at boot time. They  
don't use a remote session. All apps run locally. Setups like this  
reduce administrative costs, since there is no locally installed  
software on the client (it loads its OS from a central server each  
time), but requires more powerful CPU & RAM on the clients.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkveEsIACgkQxWV7OPa/g5EwrQCdHWsFmiNtkMLpITHR4A5A6VIe
bsIAnRnJT1sRHjair4YpQbnIIz9n23jR
=7suB
-----END PGP SIGNATURE-----