WikiStart-en

Version 7 (schmelzs, 01/19/2009 03:35 pm)

1 7 schmelzs
h1. OpenSLX: Linux Diskless Clients
2 6 dsuchod
3 1
4 6 dsuchod
Information zu "OpenSLX":http://www.openslx.org/trac/dxs in Deutsch.
5 1
6 1
7 6 dsuchod
h2. The Project
8 1
9 1
10 7 schmelzs
OpenSLX - the name is rather fresh - aims on the Linux desktop as a middleware solution to provide easy administration of large bunchs of computers. The project might be of interest in a wide field of utilization: schools , education, universities, grid clusters, corporations with a lot of office workplaces, ... 
11 6 dsuchod
12 7 schmelzs
An OpenSLX client is just a Linux workstation as you would expect, if you have installed just any distribution onto the local disk. The average user will not see any difference ...
13 6 dsuchod
14 6 dsuchod
For the administrator things change significantly: All software installation is done to a central server  (or servers for failover)  and provided via network in a way similar to the well known "LTSP":http://www.ltsp.org/. So our project  uses the same infrastructure of PXE/etherboot/gPXE, DHCP and TFTP for initial booting and then NFS, NBD, ... for the rootfilesystem of the clients. Different to LTSP the users logs in to the machine locally and not to a remote server (this is still all possible too, but not the main focus). So the local resources  of the machine are used and the user has easy access to all devices of his machine (USB, IEEE1394, CD/DVD(burner), floppy,...) Plus he is able to play any 3D game, watch videos and may connect audio devices like headset, microphone ...
15 1
16 7 schmelzs
Thus the roofilesystem is bigger than the one needed for average LTSP installation and  the bandwidth requirements may exceed the requirements of the LTSP pendant. A typical OpenSLX client requires up to 150MBytes until the GUI login is possible and then 40 -100MBytes until the KDE, Gnome GUI session is loaded. If using rootfilesystem ontop of  network block device (NBD) - squashfs (highly compressed readonly filesystem known from embedded devices) the required bandwidth falls by a factor of up to 3. We have implemented  a special caching blockdevice ("DNBD":http://http://www.openslx.org/trac/dnbd) which could be used in shared medium networks for  reducing the  total amount of packets the server has to sent for all clients in a subnet.
17 6 dsuchod
18 1
The system is bootup time optimized: In a simple environment (not many services to start, not much special hardware to detect) you are able to get a client in around 40secs (measured from PXE menu) presenting its login screen. In most cases it should not take much longer than a minute. Gigabit might speed up that up to 5 to 10secs.
19 1
20 7 schmelzs
There is no requirement for a big terminal server onto which all users in a typical LTSP client environment would login too. A good fileserver with a not to small amount of memory for block caching and fast disks will do. This OpenSLX server (running DHCP and TFTP when not already covered elsewhere) could serve easily more then 100 clients (depending on the network bandwidth and structure).
21 1
22 1
23 6 dsuchod
h2. Installation
24 1
25 1
26 7 schmelzs
In the near future there will be two ways of setting up an OpenSLX infrastructure: Cloning a running system (should be possible with every distribution) and installing a system (selected distributions) from scratch on the SLX server. At the moment *ld4-inst* deals with clone installations but is deprecated. A preview of the from-scratch-tool is available with *slxossetup* (both tools in shell, but will be perl in the first quarter of 2007).
27 1
28 7 schmelzs
On a server (distribution irrelevant, must be able to execute the installation scripts and tools) could be more than one system hosted: OpenSLX allows to install as many different distributions, flavours and versions of them as you like, as long your server has the disk capacity. Maintenance of the systems is done either by chrooting or cloning (using *rsync*) from a maintained source again. At least for chroot the server must be able to handle the code, e.g. x86_64 servers could host, both x86_64 and i386 client installations. A i386 server could only host i386 installations if you would like to use the from-scratch installation.
29 1
30 7 schmelzs
At the moment not much of services setup (DHCP, TFTP, NFS, (D)NBD, ...) is done by the tools. But if you have a running diskless Linux/client environment, it should not be to difficult to include OpenSLX too. Most probably both projects will share a common PXElinux setup. The *ld4-inst* produces an example file (_pxelinux.cfg/default_) which could be used for inspiration. Of course the nfsroot pathes of the different systems will be different, but OpenSLX has already in mind to allow more than one system (e.g. an Ubuntu8.04 and SUSE11) installed in parallel on one server.
31 5 dsuchod
32 5 dsuchod
33 6 dsuchod
h2. Hardware Requirements
34 6 dsuchod
35 6 dsuchod
36 7 schmelzs
The clients should support PXE booting (Etherboot is reported to work well too, but you have to generate your combined kernel+initramfs image by yourself using *mknbi* and alike). Any system running as a normal disk equipped workstation will do. You have a little bit more requirements regarding ram (if a disk is installed and has swap signature and/or an ID44 partition the local disk is used by OpenSLX for swapping and as _/tmp_ scratch space), because you (normally) cannot swap and use some 20MByte for writeable parts of your client filesystem.
37 6 dsuchod
38 6 dsuchod
39 6 dsuchod
h2. Development
40 6 dsuchod
41 6 dsuchod
42 6 dsuchod
Much information (in english) on ongoing developments could be found in "Timeline":http://www.openslx.org/trac/dxs/timeline and in code documentation "Code Browser":http://www.openslx.org/trac/dxs/browser.