Neither this author nor the project contributors are in any way responsible for physical, financial, moral or any other type of damage incurred by following the suggestions in this text or using the programs. Both this document and the Thinstation program and supporting programs are presented "as is" without any warranty concerning functionality or security.
Any trademark belongs to the respective owners.
What is Thinstation
Thinstation is a basic and small yet very powerful Open Source "thin client" operating system and some programs which make it possible to connect to servers via a network. Thinstation is mainly intended for office, company or department use. Being a private individual with just one PC you will have little use for Thinstation.
Thinstation is based on Linux, but users may actually never see Linux at all if you decide to connect directly to a Microsoft Windows server, a Citrix server or a Unix server. The user will feel he/she connects directly to the server. But if you want to, you can have a Linux interface - a openbox or icewm window manager to be exact.
Thinstation also supports a MS Windows-only environment and REQUIRES NO UNIX/Linux KNOWLEDGE (but it doesn't harm :-).
Thinstation runs on ordinary PC hardware (x86) and is based on Linux, which itself is Open Source and free. You may either reuse older computers or save a lot of time on workstation administration. Or both! An old Pentium-II with 64 MB RAM or better will be a perfectly useful workstation. And you don't need a hard disk - you can boot off the network and even have a fairly silent workstation. Actually this is the typical use case.
But even with brand new hardware Thinstation is advantageous, saving a lot of administration time (I personally did assamble a new small mini-itx PC from its individual boxed components AND connected to Word on a Windows server within 19 minutes!). You can save money too, as you can just buy entry level computers and still have fast program execution (as your server permits). With a new diskless PC without CPU and PSU fans you may have a powerful and completely silent workstation (and cool too, if you have to think about air conditioning expenses).
Thinstation is able to connect to
- Citrix servers using the ICA protocol
- Microsoft Windows Servers using the RDP protocol by rdesktop, freeRDP or nxclient (Windows NT4TSE, W2k Server, W2k3 Server, W2k8, even XP or 7 as single user only)
- Tarantella servers
- Unix servers running X or NX (NX highly recommended)
- VNC servers
- Telnet and SSH (Secure SHell) servers
You just need a decent server for the users. An ordinary quality PC with a ~2 GHz/"2000+" cpu and 1-1.5 GB ram will easily support ~20 users on a Windows server with e-mail and Word/Excel or any similar typical applications. A couple of cores doesn't harm nor does more RAM. However, Thinstation will not work well with Auto-CAD/3D Studio Max or other heavy duty graphical or multimedia programs.
- Linux kernel 3.4 (this is a moving target so this info may already be outdated)
- XOrg 7.6 (moving target too).
- Boot media: etherboot, pxe, CD, hard disk, compact flash
- Small image size - typically 30-50 MB or larger with client side web browsers
- Support of a lot of locales (national languages)
- Client side web browsers - Dillo, Mozilla Firefox, Chrome.
- Network booting using DHCP and TFTP (for etherboot and pxe)
- Samba and NFS file access
- Automatic mount of client floppies, HDs, CD/DVDs, USB storage
- Sound on clients (if supported by the server) and client side connected printers (LPT and USB) - as well as server and network printers
- PS/2 and USB keyboards and serial, PS/2 and USB mice
- Scroll wheel mice
- Support for syslog server (to monitor the clients). Remote or local.
- Enhanced Shell with command line editing and history
- Telnet, web and VNC access to clients so the admin can login and check logs in /var/logs and if necessary reboot the workstation remotely. Or kill processes.
- Debug package. This stops the inittab entry from working so you start in a console mode regardless what packages you choose, adds strace which is useful for seeing where a program fails. When in debug mode, you can start the session manually by going start-session 0
- i686 class CPU with 64 MB RAM or better.
- NIC: Anything supported by the current Linux kernel.
- VGA: VESA. Who needs more for a terminal anyway? OK then - anything supported by the current X.org version (and that's a lot).
Where does Thinstation come from
Thinstation was founded by Miles Roper as a fork from Francisco Castro's Netstation project. With Thinstation 2.0 not much original code resides, but the concept does. Trevor Batley took over from Miles and from TS-5.x Don Cupp Jr. is lead. If this project interests you, so might PXES (another Netstation fork) and Diet PC by Paul Whittaker.
Where to get Thinstation and more information
Thinstation is hosted by www.sourceforge.net as thinstation.sourceforge.net. You'll find two mailing lists there. You may download both precompiled images (for use in MS Windows-only environments), a fully configurable Linux version and the entire source for all Open Source parts.
How to install Thinstation
Thinstation offers prebuilt images or a fully configurable setup over the web (via the TS-O-Matics) for use in a MS Windows-only environment, or a build environment on your own Linux box (any current distribution will do).
If you build on your own Linux box, you will need to be an administrator or have similar knowledge (or plenty of time!).
The prebuilt MS Windows solution allow you to connect Thinstation clients to one or more MS Windows server (NT4TSE, win2k, win2k3, win2k8) without the need of any UNIX/Linux knowledge, but still get all the client-server benefits.
What to do next depends on how you want to boot Thinstation:
(NOTE: thinstation.conf is a generic term - the is no file just named thinstation.conf. See the details in the section Configuring Thinstation).
boot without a network:
If you want to boot a workstation running Thinstation without a network or possibly without the dhcp and/or tftp servers (for network configuration files), please see the Network Related example configuration items.
But the quick way is:
in the build.conf file include
param haltonerror false
and in your thinstation.conf.buildtime file
network boot with a NIC with a boot ROM:
A boot ROM is a small chip on your NIC.
If your boot ROM suppports the Intel PXE standard (most do) then use one of the following options
- using PXELINUX (recommended)
- Copy the files and directories in boot-images/pxe to your TFTPD root directory.
- Edit the thinstation.conf to match your terminal configuration.
- Add <TFTPD root dir>pxelinux.0 as the boot file to your DHCP server's configuration (eg. filename=pxelinux.o in dhcpd.conf).
- using etherboot
- Copy everything from boot-images/etherboot and a thinstation.conf to your TFTPD root directory.
- Edit the thinstation.conf to match your terminal's configuration.
- Add <TFTPD root dir>thinstation.nbi as the boot file to your DHCP server's configuration.
network boot with a NIC w/o a boot ROM using a boot floppy:
Outdated - left for reference.
- You may compensate for the lack of a boot ROM on the NIC by making a bootable floppy.
- Prepare everything as described above.
- Go to www.rom-o-matic.net and make the bootable floppy as explained at that site.
- ... or get Paolo Silvan's contributed Universal network boot floppy if your NIC is among the 30 most popular.
network boot with a NIC w/o a boot ROM using a harddisk:
Outdated - left for reference.
You may also boot using a harddisk instead of a floppy via (etherboot).
See Alexander Heinz's excellent guide on http://etherboot.anadex.de/.
boot from local storage media (hard disk, CD, Disk-on-Chip/CF...)
Booting off local media gives you the choice of methods:
- from a CD (isolinux)
- from your hard drive, usb stick or cf card (syslinux)
- from your Windows/DOS system (loadlin)
Please note you do still need a TFTP/SCP/HTTP server to deliver the thinstation.conf file unless you have adapted the thinstation.conf.buildtime correctly and
- make an unique image for each computer, or
- use the STORAGE_CONFIG# option in thinstation.conf.buildtime and have a local thinstation.conf.user directly on the media as $STORAGE_CONFIG#/thinstation.profile/thinstation.conf.user.
Burn the file boot-images/iso/thinstation.iso as an image (NOT a file!) with your favorite tool (cdrecord thinstation.iso under Linux is one suggestion...).
Copy the files in boot-images/syslinux to the storage media and run
Outdated - left for reference.
Copy the files in boot-images/loadlin to your Windows/DOS media (only FAT supported) and run
More on loadlin
PKGs are plain Thinstation packages in tgz format that is added after boot of the core system. This allows you to keep the image size small and only load packages when you need them (controlled by the thinstation.conf<something> files. You may load PKGs both from the TFTPD and from local media. Most packages may be PKGs. The environment variable PKG_PATH in build.conf will let you set a subdirectory to store the.pkg files.
All client configuration is done in a thinstation.conf<something> file.
This section describes how and in what order the various configuration files are used.
Also see descriptions and settings of runtime parameters.
After building, you end up with the initial thinstation.conf.sample file, that is unique for the selections made in build.conf. This file should be edited to your likings and renamed (copying is actually smarter :-) according to the following:
It is possible to have multiple thinstation.conf.<something> - 'conf' files are looked for in this order:
- thinstation.conf.buildtime (ONLY used at build time - puts config directives in the boot image). If you edit thinstation.conf.buildtime you must rerun the build script: ./build --buildtime thinstation.conf.buildtime. This step is done automatically for TS-O-Matic users.
- thinstation.conf.network (default or global config, pulled from tftp server)
- thinstation.hosts (contains host, MAC, and group mappings). This file is optional, but may be useful for management.
If thinstation.hosts exists, the following file(s) are looked for (careful! Note where to use "." and where to use "-"):
- thinstation.conf.group-<groupname> (there can be multiples of these)
Next - or if no thinstation.hosts was found - these files are requested:
- thinstation.conf-<hostname> (e.g. thinstation.conf-my_pc)
- thinstation.conf-<IP ADDRESS> (e.g. thinstation.conf-192.168.1.2)
- thinstation.conf-<MAC ADDRESS> (e.g. thinstation.conf-112233445566)
- thinstation.conf.user (locally stored configuration, placed as STORAGE_CONFIG#/thinstation.profile/thinstation.conf.user. # being a number)
Each file that is found is downloaded, and then the client looks for the next file in the list. So a client will start with whatever you had defined in thinstation.conf.buildtime when you built the image. Then it checks the TFTP server (if this has been activated in thinstation.conf.buildtime): the first thing is looks for is thinstation.conf.network (which typically exists), and it reads in all of its settings. Then the client requests thinstation.hosts. If there is a thinstation.hosts on the TFTP server, the client will read in all available group config files (one at a time) that are found on the line matching the host's name and MAC address; Otherwise (or next, if thinstation.hosts was found), it will check for a hostname-specific conf file; then an IP-specific conf file; and finally a MAC address-specific conf file. A few notes about this process:
- conf files are NOT mutually exclusive. All valid conf files that are read during the boot process are used. So you can, for example, define some sessions in thinstation.conf.network, some special application for certain users in thinstation.conf.group-specialapp, and add additional video driver parameters for the one user with a super-high-resolution video cards in thinstation.conf-hirezmachine. Things only start to get tricky when you realize that you can have the same configuration directive(s) in any or all of the conf files the client reads; then you need to know the order in which they were read to figure out which one's directives will take precedence (which will be the last one read).
- All conf files EXCEPT thinstation.conf.buildtime and thinstation.conf.user are stored on the network:
- thinstation.conf.buildtime is part of the Thinstation distribution; it only gets read when the boot image is first created. The directives in this file, if included, become the defaults for Thinstation, but will likely be overridden by any of the other conf files.
- thinstaion.conf.user is stored on local media (e.g., the hard drive of the client computer with the path STORAGE_CONFIG#/thinstation.profile/thinstation.conf.user), and its configuration directives override ALL other conf files. The client will only know to look for this file if thinstation.conf.buildtime is properly configured with the STORAGE_CONFIG# setting.
- you can change where on the TFTP server the other files are kept by changing the basepath value in build.conf, and you can even change the names of all of these files from thinstation.conf* to somethingelse.conf* by changing the basename value in build.conf.
- Creating a thinstation.hosts file is necessary in order to take advantage of using conf files for machines specified by name or groups. If all of your clients are exactly the same and your users have the same needs, you can probably just create a single thinstation.conf.network and put all the configuration settings in there, and you're done. Most users, however, will probably want the thinstation.hosts file. Take a look at thinstation.hosts.example; you'll notice that you can have multiple groups associated with each host. The groups' conf files are read in the order they are listed on that line, so the 'later' on the line the group is, the more significance it has.
- Beware you can't add features in a thinstation.conf<something> not already build into the image (pre-built or defined by your own build by build.conf)! (ie, defining an ICA session in a config file won't help you if you didn't include the ICA package in build.conf).
DHCP and TFTP Server configuration
Thinstation normally needs (at least) three servers to work: a DHCP, a TFTP server and one or more application server(s). These may very well be the very same computer hardware. But if you boot from local media you can avoid the DHCP and/or TFTP server.
However, if you have many clients you would probably prefere both a DHCP and a TFPT server to make your life easier.
DO NOT INSTALL ANY SERVERS ON YOUR NETWORK UNLESS YOU ARE ALLOWED TO DO SO! They may conflict with existing servers on your network making you very unpopular...
A DHCP server (or "daemon" in the unix/Linux world) hands out an ip number for your client upon request and names the TFTP server as well as the name of the download directory and the client image on the TFTP server.
Windows 2000/2003 DHCP servers works fine, but if you use a Windows NT4 server you need Service Pack 4+ (you should have SP6 anyway).
Any current Linux DHCP daemon is fine AFAIK, but you would probably choose DHCP3 by isc.org.
Paul Whittaker has a great piece on Windows 2000 and DHCP here.
And there is a fine Linux guide at www.Linux.org.
The TFTP server manages the download of the boot image to the client.
The TFTP server must support the "tsize" option when using PXE boot.
Stolen directly from Paul Whittaker's http://diet-pc.sourceforge.net/setup.html#tftp (May 2003):
If you are using a network boot loader, you must install and activate a TFTP service on your designated boot server. Most operating systems come with a TFTP server package, but it is usually not installed by default.
In the case of Windows 2000 Server or Windows 2003 Server, the TFTP server is an integral part of the Remote Installation Services (RIS) package, and is difficult to use in isolation (see the Windows 2000 Etherboot HowTo for details). Morgan Simonsen has constructed a standalone TFTP server package based on the native W2K/W2K3 server, which is a much simpler alternative to installing RIS. Earlier versions of Windows lack a TFTP server; in such cases a third-party product such as tftpd32 is needed.
If you intend to use PXELinux, you must use a TFTP server that supports the tsize option. For any PXE boot method, a TFTP server that supports the blksize option is highly desirable, as PXE boot loaders can make use of larger blocksizes for faster booting. I recommend using either the native Windows 2000/2003 TFTP server or tftpd32 on Windows, and tftp-hpa (usually the default TFTP server in recent Linux distributions) on UNIX platforms.
To activate the TFTP server in Linux, you would typically install the TFTP server package (RPM, DEB, etc), set "disable=no" and "server_args=-s /tftpboot" in /etc/xinetd.d/tftp and restart xinetd using "sh /etc/init.d/xinetd restart" or similar.
Set "umask 022" to ensure world-readability.
The MS Windows servers come with a build-in TFTP server called "Remote Installation Service". However, it needs a domain controller to work, unless you use a hack by Morgan Simonsen (mind you - you still need a valid MS Windows server license).
An other possibility to get a small and simple combined DHCP and TFTP server for MS Windows is http://tftpd32.jounin.net/ (supports "tsize" for PXE boot). To run it automatically as a service, use FireDaemon (free for non-commercial purposes).
Check out Zack Forsyth's excellent guide Running a non-RIS TFTP server as a service in MS Windows server concerning this.
OK, you have a problem and you have read the FAQ & FAQ + and can't seem to see what is wrong.
So how do we find out what has happened and really discover the problem (and hopefully the fix)?
Due to the number of different software packages involved in Thinstation, this is a topic that requires it's own Section.