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