When I needed a thin client for the company which I am working for, I firstly researched some existing products on the market. (wise, chipPc etc.) Actually, there were some good things but I needed a more customizable one. When the subject is about customization, I have got an unique address for solution: that's
linux. I wanted to create a simple, easy to setup and strong solution. I checked following criterias:
- I had to use a complete distrubution to start to work. Because, all distrubutions are ready for use. I didn't need to handle more to start.
- I had to create image file/files as OS. It should be open from image / images files every times. Therefore, It can keep ifself as strong.
- If I could supply the Boot On Lan feature on my pxeboot server, the clients would never get damaged in the future. Because all clients would run on only their RAM device. Altough they had been shutdown un-properly, they could stil read the original image file from the pxeboot server. I only needed keep the image file safe which is located on the pxeboot server.
I researched a few distros and than I selected the SLAX for my project. It's using squash FS (lzm files). It seemed the best choice for my requirements about the image.. SLAX distro is normally used on the usb devices. It's a kind of mobile version of Linux. You can use it in several hardwares.
However; I had to change something on standard SLAX. The history of my project begins.
In order to install Slax, download the USB image from site "http://www.slax.org/get_slax.php". After extracting it, it will generate two different directories: slax and boot. Firstly we need dir2lzm and lzm2dir scripts/commands to extract lzm files and to re-build the lzm file again. These are located in the directory /slax/tools/.
Slax has got a very nice structure. Making manipulations are very easy and controllable. For example, you can create a module file to create some changes from original slax and you can apply this changes by a single copy-paste operation. There is a director, with name modules, exists for this purpose. After starting to make changes in 001-core.lzm file located in base directory, I realized that this was not a good way.
Note: Your linux (also windows OS) has got a variable about default PATH to find predefined commands on your operating system. But your tools directory (located in Slax directory) is not included in the PATH variable. So if you try to execute lzm2dir command in somewhere, you will not be able to execute it. You can execute it with a full path or you can execute it with "./lzm2dir" command when you are located in tools directory or you can add your tools directory it to the PATH. Most useful way is adding the tools directory into the your PATH variable. Suppose that your Slax directory is located in the /home/User. We can get and set the PATH environment variable as shown below:
[user@hostn stdioe]# /home/User/slax
[user@hostn stdioe]# /home/User/slax/tools <- related commands located in here
[user@hostn stdioe]# echo $PATH <- to check existing value of your PATH variable
/usr/lib/mpi/gcc/openmpi/bin:/home/User/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
[user@hostn stdioe]# PATH=$PATH:/home/User/slax/tools <- to add slax-tools directory to in your PATH variable
Good, We can use that commands from everywhere by now. Let's extract the 001-core.lzm file to do some manipulations.
Note: Actually, that commands are just several simple shell scripts. The real commands are squash FS commands. If squash FS is not installed in your operaing system, you can not use the tools directory scripts. You have to have squashfs installed on your system. The squashfs is a read-only file system with efficient compression property. It's essential and base thing so, almost all distrubutions has got it in their package manager. You can install it using your package manager.
Let's extract the file 001-base.lzm and start to manipulation step; I created a stdioe directory and copied the file 001-core.lzm to the the directory stdioe. I created a directory called core_Dir to extract contents of the lzm to the directory core_Dir.
[user@hostn stdioe]# pwd
/root/stdioe
[user@hostn stdioe]# ls
001-core.lzm
[user@hostn stdioe]# mkdir core_Dir
[user@hostn stdioe]# lzm2dir 001-core.lzm core_Dir/
TIOCGWINZ ioctl failed, defaulting to 80 columns
[===========================================================-] 12069/12069 100%[root@ismldgn stdioe]#
[user@hostn stdioe]# ls
001-core.lzm core_Dir
[user@hostn stdioe]# cd core_Dir/
[user@hostn core_Dir]# ls
bin dev home media opt root srv tmp var
boot etc lib mnt proc sbin sys usr
[user@hostn core_Dir]#
core_Dir directory is a container for our thin client OS file structure. First of all, we have to focus on the file /etc/rc.d/rd.M. The file manager starts up the process.
We will create an image file which will then be used by our thinclients. So if we don't solve the problem of hostnames, all our thinclients will have got the exactly same hostnames. The main problem is, all of them connect to the same terminal server. The terminal server can not handle the connections properly. If you look from terminal server side, you can see a lot of clients are connected but all names are the same!
Normally rc.M assigns a hostname from contents of the file /etc/hosts. My offer is, we can create a new and different hostname for each client while booting progress. The mac address information already provides an unique information for this. We can use the mac to assign them different names! We can edit our commands after the line in which it is written "# Initialize the networking hardware.".
ls -aA1b /etc/dhcpc | egrep ".info\$" | while read INFOFILE; do
# the next line won't affect rc.M variables, because it's in >while read< loop
. /etc/dhcpc/$INFOFILE
echo "TPL`/sbin/ifconfig | /bin/grep "HWaddr" | /bin/gawk -F' ' '{print $5}' | gawk -F: '{print $1$2$3$4$5$6}'`."$DOMAIN >/etc/HOSTNAME
sed -i -r "s:127.0.0.1\tslax.*:127.0.0.1\tslax.$DOMAIN slax:" /etc/hosts
break
done
Well. Now, each client has got a different hostname. All hostnames start with a TPL prefix and continue the mac info without ":" and ".$DOMAIN" variable, respectively. If you don't need FQDN name, do not use the ".$DOMAIN" part.
This OS will be used as a thin client os. So the main goal is to "connect to the terminal server". We don't need advance graphical user interface. We need simple a simple solution. I selected fluxbox for this purpose. When the OS starts, the fluxbox should be opened automaticly. For this purpose, we have to add the content shown below with a ".xprofile" name in the "/root" directory. This configuration is to start the fluxbox GUI.
session=/usr/bin/startfluxbox
/usr/bin/setxkbmap tr
#/usr/bin/rdesktop terminalServerAddr -f -r printer:oki="Epson LX-80" -k language
The -k option is for defining the language. Please replace the proper language code for your language. The line marked with a '#' supplies a connection to the terminal server automaticly but I marked it to make it disabled, because user may want to do a different thing. So we have to create a menu file for fluxbox GUI. Let's create a lzm file again from the edited base package and create a new module file for other purposes.
[user@hostn stdioe]#
[user@hostn stdioe]#
[user@hostn stdioe]# ls stdioeBase/
bin boot dev etc home lib media mnt opt proc root sbin srv sys tmp unsped usr var
[user@hostn stdioe]# dir2lzm stdioeBase/ 001-base-edited.lzm
[=============- ] 2337/10544 22%
Right now, our base lzm file is ready. But normally we have to create a module file for our changes. We don't have to handle the original base file. because when we a new release is published, we will need to handle it again. But if we create a module file, the copy paste operation will probably be enough for this. Also the module mechanism is very useful feature. Let's create a module file for other requirements,
[user@hostn stdioe]# mkdir nameOfModule
[user@hostn stdioe]# mkdir nameOfModule/root
[user@hostn stdioe]# mkdir nameOfModule/sbin
[user@hostn stdioe]# cd nameOfModule/root
[user@hostn stdioe]# mkdir .fluxbox
[user@hostn stdioe]# cd .fluxbox
[user@hostn stdioe]# vim menu
Content of the menu file is shown below:
[begin] ('The Project Name' - MENU)
[encoding] {UTF-8}
[submenu] (Tools)
[exec] (Command Window) {xterm}
[exec] (Internet Browser) {kfmclient openProfile webbrowsing}
[exec] (Text Editor) {kwrite}
[restart] (KDE GUI) {startkde}
[end]
[submenu] (Remote Desktop : termSrv.dom)
[exec] (800x600) {termsrvDOMr1}
[exec] (1024x768) {termsrvDOMr2}
[exec] (Tam Ekran) {termsrvDOMrf}
[end]
[exec] (Shutdown Computer) {pcShutdown}
[endencoding]
[end]
Of course, some used commands are not default ones. These are user defined. We have to write them and set execution permissions and locate them into a proper directory as value of $PATH variable. That files are listed below.
pcshutdown:
Note: Our thin client os is already running on the RAM. So we can shutdown up-properly. "init 0" is the most rough way.
termsrvDOMr1:
#!/bin/bash
/usr/bin/rdesktop termsrv.DOM -g 800x600 -k tr -r printer:UGLpoki="Epson LX-80" -d DOMAINNAME -u ""
termsrvDOMr2:
#!/bin/bash
/usr/bin/rdesktop termsrv.DOM -g 1024x768 -k tr -r printer:UGLpoki="Epson LX-80" -d DOMAINNAME -u ""
termsrvDOMrf:
#!/bin/bash
/usr/bin/rdesktop termsrv.DOM -f -k tr -r printer:UGLpoki="Epson LX-80" -d DOMAINNAME -u ""
Finally set to execute permission and copy it to /sbin directory. After all, create lzm file of the module.
[user@hostn stdioe]# chmod +x pcshutdown termsrvDOMr1 termsrvDOMr2 termsrvDOMrf
[user@hostn stdioe]# cp pcshutdown termsrvDOMr1 termsrvDOMr2 termsrvDOMrf nameOfModule/sbin/
[user@hostn stdioe]# dir2lzm nameOfModule nameOfModule.lzm
[===================================================================|] 6/6 100% [user@hostn stdioe]#
[user@hostn stdioe]#
Right now, if we copy that lzm module file to modules directory, this module will be enabled when booting the OS automaticly. But we still don't create a module for printer driver and configuration. That file content is a little bit long so explaining how to create a printing module is not a good idea in this.. But you can use a usb version of Slax and open it with "Slax Graphics mode" option and install printer driver and configure it then shutdown properly. Then, if you check directory changes, you can find all changes about the printer installations and configurations. The problem is, existing files are not only about the print functionalty. You have to select printer related ones. I can create a download link in this page, but usually it is not a good idea to create a download link about any file. If some body want to download that file, I will send it.
Good. Our thinClient OS is ready. We prepare it from the usb version of Slax. And now, we will prepare a tftp server and http server to get the pxeboot server ready. TFTP server installation and web server intallation are not related to this article, so I don't explain it. But I have to say again, your http server should be a permitted directory and configured as indexing compatible with httpfs property. Because, when the boot process starts, our pxeboot server will send the boot parameters via tftp server and than starts to use the https service for loading big files. Because tftp is a UDP based service and http is a TCP based service. Nobody wants to use UDP based service to load big files. So UDP does not check the data whereas TCP uses a checking mechanism while data is transfering.
The boot directory should be located in the directory "tftproot" and Slax directory should be located in the http publishing root directory. (/var/www/html or /srv/www or something like that).
The last step is to configure the DHCP server for pxe booting. My project environment has got a Microsoft Windows 2003 Server for DHCP server. When you right click to scope option and select the configure option in this DHCP server, you can see a window. This window has got "066 Boot Server host Name" and "067 Boot File Name" options lines. You have to add the ip address of your pxeboot server to "066 Boot Server host Name" option and write "/boot/pxelinux.0" for "067 Boot File Name" option. Right now, if you set "boot on lan" option in a client computer bios, as a client computer starts, it will search a DHCP server, and it will learn pxe boot server address, file name info, the boot parameters from the tftp server and OS files from pxeboot server via httpfs service, respectively.
Content of the file /tftproot/boot/pxelinux.cfg/default is shown below:
PROMPT 0
LABEL linux
MENU LABEL Run linux over PXE
KERNEL /vmlinuz
IPAPPEND 1
APPEND vga=769 initrd=/initrd.gz ramdisk_size=6666 root=/dev/ram0 password=qwe123 rw autoexec=xconf;telinit~4
LABEL memtest86
MENU LABEL Run Memtest utility
KERNEL /mt86p
This project is suitable to be developed more.. I created more than one configuration files. When the boot process starts, it will be able to read mac address and get the configuration as its mac info. So we can make more than one groups. Each single member of the group can read different module files and configurations. For example, you can create two different groups and than you can include some mac addresses of that groups. Every group have got a single configuration file. Therefore, every client will use their own setting. By the way, I think the most powerfull feature of this OS is, It will never crash!. Because it will use the same lzm file for booting process. If you can create a usable OS, you will always be able to use it. Itwill never need "disk defragmentation" or something like this...
