-
-
Notifications
You must be signed in to change notification settings - Fork 187
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.
- Linux kernel 5.3 (this is a moving target so this info may already be outdated)
- XOrg 7.7 (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. As of TS 6.1 only x86-64 CPUs will be supported.
- NIC: Anything supported by the current Linux kernel.
- VGA: VESA and anything supported by the current X.org version.
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.
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.
Please press Ctrl Alt F2.
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
NET_USE_DHCP=Off
NET_FILE_ENABLED=Off
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 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 thinstation.nbi as the boot file to your DHCP server's configuration.
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.
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/.
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.
CD:
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...).
syslinux:
Copy the files in boot-images/syslinux to the storage media and run
syslinux /dev/
More info on syslinux
Lars Karlslund has contributed a ThinStation Compact Flash card +
syslinux boot HOWTO
loadlin:
Outdated - left for reference.
Copy the files in boot-images/loadlin to your Windows/DOS media (only FAT supported) and run
ts.bat
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 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
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. - '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- (there can be multiples of these)
Next - or if no thinstation.hosts was found - these files are requested:
- thinstation.conf- (e.g. thinstation.conf-my_pc)
- thinstation.conf- (e.g. thinstation.conf-192.168.1.2)
- thinstation.conf- (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 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).
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.
- The kernel gets loaded.
- The kernel loads initrd and starts from it.
- Busybox init process gets started --
/etc/inittab - Runlevel scripts get started ->
rc2.drc5.dpackage scripts - Autologin on console with
TERMset toxinit -
/etc/profilestarts xinit for X GUI. - Window manager comes up.
Yes.
In your TFTP server's download directory you just create a configuration file named thinstation.conf- (e.g. thinstation.conf-192.168.1.2) or thinstation.conf- (e.g. thinstation.conf-12AB34CD56EF).
A file just named thinstation.conf.network will be the default configuration for all ThinStations.
If you have made a thinstation.hosts file (which maps MAC addresses to host names) you can name the configuration file thinstation.conf- (e.g. thinstation.conf-peter). Much easier to remember.
Easily - if you boot off a local media, but it is not so easy with network boot. Usually the DHCP server tells the client to ask the TFTP server for one specific image.
However, you can let the DHCP server detect the clients MAC address first and then hand out a specific ip address AND a unique image file name to the client. This way you lose some of the flexibility of using DHCP, but you get a more secure network, since you are in control of which NICs are acceptable to get net access.
Normally you should be able to make a comprehensive image which covers any clients and then use the conf file to select the needed modules for the individual client.
If you have an early PXE implementation, it might be buggy. See http://syslinux.zytor.com/wiki/index.php/Hardware_Compatibility. Version 2.0 or newer is preferable. Most NIC manufacturer make update to the PXE bios, which may be upgraded.
However, double check your DHCP/TFTPD setup and ensure that if you have changed the basepath or basename parameters in build.conf you have put your pxe files in the appropriate directory.
My NIC doesn't support PXE and making/buying a boot ROM for it is out of the question. Can't I just boot off a hard disk?
Sure. Make a small DOS (FAT12 or FAT16) partition and use loadlin or syslinux to boot (loadlin is simple, syslinux offers more candy). See How to install ThinStation.
8 to 20 megabytes if you can afford it (depending on what applications you load).
instead?
Yes - see Lars Karlslund's contributed Compact Flash card + syslinux boot HOWTO.
Yes. That's what the ThinStation boot CD does! You can use ThinStation without ever touching your PC's harddisk.
Yes, with a little help from a boot floppy: Smart Boot Manager.
Well, you can mimic etherboot with a floppy even if your NIC doesn't have a boot ROM. This mean you can use a floppy to connect to the DHCP and TFTP server and download the rest. Maybe a bit slow during boot, but it works well.
Goto http://www.rom-o-matic.net/ and download an image for your NIC. Follow the instructions on that site to make a net bootable floppy.
Yes, but it requires booting from local media.
If you don't need any reconfiguration of ThinStation once it is built, you just hardwire all configuration within thinstation.conf.buildtime (ensure that you have NET_FILE_ENABLED=Off to avoid looking for configs from the server).
If you want to use local configs, set STORAGE_CONFIG#=... correctly in thinstation.conf.buildtime and supply a thinstation.conf.user file with the path STORAGE_CONFIG#/thinstation.profile/thinstation.conf.user (# being a number between 1 and 8).
You must boot from a local media then.
Setup all the network parameters in thinstation.conf.buildtime and then build the image.
You can still get your configs from the tftp server if you want, but will have to define where to find it with NET_FILE_ALTERNATE= in your thinstation.conf.buildtime
For a traditional serial mouse (rhombic 9 pin connector) you probably need the MICROSOFT protocol. Mice with a PS/2 connector (small round one) needs ... PS/2 :-). However, wheel PS/2 and USB mice need the IMPS/2 variant. For unsual mice see http://www.faqs.org/docs/Linux-mini/XFree86-Second-Mouse.html#PROTOCOL
Assuming the server and the server software application supports the
scroll wheel, all you have to do is to change one line in the
thinstation.conf:
* From: X_MOUSE_PROTOCOL="PS/2"
- To: X_MOUSE_PROTOCOL="IMPS/2"
Remember to hard reboot your ThinStation afterwards
You will need to use X_MOUSE_DEVICE=/dev/input/mice in thinstation.conf to support a USB mouse, in addition to including the "usb-hid" in build.conf.
First make sure you have setup the mouse correctly. A misconfigured mouse can prevent X from starting! Go figure...
Next make sure you have built in the correct video driver in the image. Try the VESA driver alternatively (any video card should be VESA compatible). Make sure X_HORIZSYNC and X_VERTREFRESH in thinstation.conf has the correct values (or comment them out if you don't know). X servers can be very picky about this!
If you have trouble finding the right modes, have a look at http://www.ibiblio.org/pub/Linux/docs/HOWTO/XFree86-Video-Timings-HOWTO
My BFG9000-Pro mk. III-c (or whatever) graphics card ain't supported by ThinStation. But XOrg 6.9 supports it!
If there is a driver for for your video card and it is for the same XOrg version as ThinStation uses (currently 6.9) and if it is compiled with GCC 2.95 (this is becoming uncommon), then support it yourself :-)
Create the directory structure
`/packages/xorg6-``/lib/X11/modules/drivers/`Put the driver itself (.o) there and chmod it into -rwxr-xr-x.
Edit build.conf and add xorg6- as a module and rebuild. And done!
If there isn't any XOrg 6.9 support you still might still try the VESA
driver, though.
See the keyboard request guide. However, see also Faulty keyboard layout with MS Windows server using RDP (rdesktop)
By Robbo Aylett, ICT Services, Hobart College, Olinda Grove Mt. Nelson, Tasmania Australia. 7007. (robbo.aylett AT hobart.tased.edu.au) Edited by Mike Eriksen January 2004
Often you see thin client users confusing their local floppy and CD-ROM drive with the servers drives.
To get around this issue, you simply have to activate Samba support in ThinStation and add the following to the MS Windows server logon script:
net use a: \\%CLIENTNAME%\floppy net use d: \\%CLIENTNAME%\cdrom
This is referred to by some Windows Admins as a MAP BACK.
(EDIT: From the mailings lists, it has been suggested to use: net use x: \\%CLIENTNAME%\ "" /user: not to get problems with encrypted passwords. Mike)
(NOTE: If you can't or don't want to use the thinstation default share
names, you can change the defaults to anything you want. For example,
you might want to change them to a$ and cdrom$ by editing the
$SAMBA_FLOPPY and
However, before this will work, you have to disable the floppy drive on your terminal server and thus remove "A:\" so you can map it as a network device.
To do this, login to your MS Windows 2000/2003 terminal server(s) and open up the device manager (right click on My Computer and Select "Manage". In the new dialogue box, expand Device Manager by selecting it. In the device tree, look for "Floppy disk controllers" expand it. You should see 1 entry there, right click on it and select "disable". (Being in Windows, you may or may not need to reboot. You will need to if you decide to re-enable it, though) Only do this, if you have no need for a floppy disk when logged into the console session of your terminal server.
If you really want to map a thin client CD-ROM drive to "D:\" but the server's CD-ROM is already there, you can use Disk Management to re-assign the CD-ROM to drive "E:\" (or another letter or NTFS folder of your choice...) and then map the thin client CD-ROM drive to "D:\", like in the example above.
You may need to remove the Server CD-ROM, by disabling it in Device Manager, so users don't see 2 CD-ROM drives and get confused.
I hope this helps you with your floppy and CD-ROM access!
Make sure you use the right tcp port on the font server e.g. X_FONT_SERVER=192.168.1.2:7100 (at least Red Hat uses port 7100 but check with your distro) in thinstation.conf.
Make sure XDMCP is running on the server and accepts connections. There is a good step-by-step procedure at http://www.redhat.com/mirrors/LDP/HOWTO/XDMCP-HOWTO/procedure.html (not Red Hat specific).
NT4TSE and Windows 2000 Server only support 8 bit (256) colors. Windows 2003 Server support 24 bit color (16. millions) and XP 16 bit (65536) colors. Make sure to have a "-a 24" or "-a 16" as command line option in thinstation.conf.
However, make sure you run the ThinStation client at at least 16 bit color. You may get strange results if both the ThinStation client and the MS Windows server use 8 bit color maps (more info below).
Windows 2003 support sound redirect (if configured properly). Use the "-r sound" command line option.
This happens when both the ThinStation client and rdesktop is configured to use 8 bit color. The problem is that with that few colors (256), a palette is used to define the color scheme, and this has to be share among all applications. The solution is to run the ThinStation client in either 15, 16 or 24 bit color depth.
Rdesktop has a few problems with some non-US keyboards. Check out the rdesktop CVS to see which has already been fixed.
If you report a keyboard problem to the mailing lists, please follow this guide: keyboard guide.
See this knowledgbase entry. Easy in IE6, but requires a registry hack in 5.5. Thanks to Chris McKeever for this one.
Well, that would be illegal.
In order to connect with terminal services to your Windows server from ThinStation, each client must have:
A CAL (Client Access Licence - you get 5 or 10 CALs for "free" with the MS server licence).
A TS-CAL (Terminal Server CAL.)
(note the difference between CAL and TS-CAL. A TS-CAL is more expensive
than a CAL). Please read here for a more detailed and authoritative
answer:
http://www.microsoft.com/windows2000/server/howtobuy/pricing/tsfaq.asp
Also, Brian Madden has a good page on Windows 2003 licensing.
So, using ThinStation you save:
- The money for the client operating system itself (you just have to pay for the CAL and the TS-CAL)
- Really a LOT on client administration
Add param icaencryption true to build.conf and ICA_ENCRYPTION="RC5 (128 bit)" to a thinstation.conf.
Yes, but ThinStation is a minimal thinclient, so you will have very few tools and no compilers etc,.
The standard XWindows interfaces are icewm or blackbox.
To login in text mode you have to press Ctrl-Alt-F2 (even if you are in
rdesktop or ICA mode or what-ever).
Login as root.
The password is pleasechangeme as default (Change it!!! - see below).
YES! You really must change it! Why? Hmmm - only you, me and the rest of the internet know the default root password is pleasechangeme... And you shouldn't trust me :-)
The password is set in build.conf (param rootpassword)
Yes and no. There is no traditional editable hosts file, but you may tweak the ThinStation setup to support the same functionallity.
Edit the file packages/base/etc/init.d/network at line 283 (just before # Add Mac Address to .conf file) and add:
echo "192.168.1.2 my_server1" >> /etc/hosts echo "192.168.1.3 my_server2" >> /etc/hosts
(use your own relevant numbers and names). Note the double >>.
You can add as many as you need.
Rebuild.
As default they are named ts_. "ts_" is defined in thinstation.conf by the NET_HOSTNAME entry. You may change this, but if you use more than three characters the MAC address will be truncated.
However, you may make the file thinstation.hosts in the root directory (where the kernel and the image is) to link a name with the MAC-address. The syntax is:
# You can have any amount of spaces/tabs between names
# HOST MAC GROUPS COMMENTS
bigboss 000103014152 printer hires # On Miles Desk
daffy 0060082FCBE8 # Daffy's workstation
donald 00A02403B0BE printer # Donald's workstation
This will name the clients bigboss, daffy and donald.
Imagine you have a LOT of ThinStations. Some are old Pentium Classics, some are newer and have a printer attached and some have a good VGA and large, new monitors.
Instead of making individual config-files for all your ThinStations you can group them with thinstation.hosts and create a thinstation.conf.group- (e.g thinstation.conf.group-printer). A thinstation.conf.group- is just another thinstation.conf with a different name (as is thinstation.conf.buildtime).
Be careful with all these "thinstation.conf" variants: the latest read will overrule an earlier read. See Configuring ThinStation
Because you did not set NET_FILE_ENABLED=Off in thinstation.conf.buildtime!
We don't really document all the connectivity packages (ica, rdesktop...) since the developers behind them have more knowledge and do it much better than we can.
Search at the parent package's homepage and get better advice. We have links to some of them here.
Yes. It requires some Linux/programming skills, though.
Look at the Developer documentation Create your own package