Andr�s Ot�n Urbano wrote:

Hello,

I want to comment you a idea that I have had. I have thinked the next structure to a net thinclient (my english is very bad and so I explain it with graphics ;-)).
<graphics removed - only garbage when quoted>
M - ThinClient Diskless Terminal
N - Users


MricoKernel: This kernel have to be very small and the unique function is connect I/O (floppy, sound, USB, monitor, ...) with MicroKernel Server.

UML (User Model Linux): There are one UML by user on the system. When a user log into microkernel server, this server connect the current I/O ThinClient that is using this user with his correspondient UML.

These UML are complet. All have X, kde, openoffice owner. This have a advantage that advance users can control his linux by self. To novels users we can use root fs equals for alls without root privileges to users.

Please correct me if I am wrong.
- This model need more resources at server

Of course. You need n* versus 1* the following stuff (or even more):
- harddisk space for all programs
- running nfsd, xdm, netscape/openoffice.org/xtetris..., tftpd in RAM, CPU cycles
- IP addresses for the server (which usually is no problem with private IPs :-)


- This model is more secure: UML can hangs but not the server.

Better don't be to sure. The one crashing UML machine I had crashed the main server too. It was an old version, but nevertheless the risc still is there


- Users don't show the server only his UML machine

They only get the login screen of their own UML, that's right. This shouldn't hinder them accessing the server which is physically reachable from the thin client as well as the UML.


- Fast connect/disconnect. Using technics from Linux Kernel Monitor we can freeze UML when user log out and defreeze when log in.

This would be indeed a real cool feature.


- �UML can export process by all nodes of cluster? I think that yes.

That's a question I cannot answer. Have not been following UML for some months.


�is this is a paranoid idea?�is stupid? If this is a good idea I have thinked do it at my final studies project.

For a regular setup it is not the best idea, honestly. It is much more expensive in terms of disk space etc.
For a "linux teaching" or so, having all users in their own UMLs with root access, this could be a very good idea - one doesn't need to reinstall all the terminal boxes and keeps management stuff on the server. All users can do bad things in their boxes as they need... a reinstall would be matter of copying a "standard hd image" onto the users hd image file which takes a minute at most.


Some suggestions to this project:
- Have nfsd running on "real" server. Users shall not tamper with terminal client machines.
- You need to extend the LTSP initrd stuff a little bit as the host to connect to depends on the username that was entered. This could be done by asking the username in the initrd's linuxrc script, then asking a database which xdm to connect to. If you need help on this let me know.
- The client boxes in a "linux course" setup usually need to be changeable only in a few aspects, e.g. the /etc, /var, /tmp, /usr/local or so (for teaching), while some directories need not be modified and so can be mounted from the main server read-only (/usr/lib, /usr/X11, /opt - depends on what the users shall learn). This can save tons of diskspace.
- You'd need kind of daemon on the real server that detects when a connection attempt is made for one UML server (this can be trickled from the initrd /linuxrc script again) and awakens the UML, while on a periodical basis UMLs without X connection from a terminal should be sent to sleep.


I hope to give some helpful argument here.

Anselm



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
     https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to