mirrors/thinstation-ng
1
0
Fork 0
mirror of https://github.com/Thinstation/thinstation-ng.git synced 2025-04-25 20:30:43 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

new file: 1.png 

new file:   10.png
	new file:   2.png
	new file:   3.png
	new file:   4.png
	new file:   5.png
	new file:   6.png
	new file:   7.png
	new file:   8.png
	new file:   9.png
	new file:   Ani.gif
	new file:   Booting-Modes-and-Compression.md
	new file:   Building-ThinStation-for-booting-off-SSD-(Goal:-Terminal-Server-Thin-Clients).md
	new file:   Certificates.md
	new file:   Configuration.md
	new file:   Custom-Kernel.md
	new file:   Debugging.md
	new file:   Deployment.md
	new file:   DevStation-Setup.md
	new file:   Errors-Running-mkmbrdrv.md
	new file:   Examples.md
	new file:   FAQ.md
	new file:   Fastboot.md
	new file:   Fools-Tools.md
	new file:   Getting-Started-with-ThinStation.md
	modified:   Home.md
	new file:   Installing-ThinLinc-Server-for-a-thin-client-environment.md
	new file:   Machine-profiles.md
	new file:   Making-bootable-media-on-Windows.md
	new file:   News-and-History.md
	new file:   Packaging.md
	new file:   Persistence.md
	new file:   Ports-and-Packages.md
	new file:   Printer-configuration.md
	new file:   Secureboot.md
	new file:   Smart-Cards.md
	new file:   Timesync-and-NTP.md
	new file:   Update-a-Port.md
	new file:   Update-a-package.md
	new file:   Updating-your-repository.md
	new file:   Using-Git.md
	new file:   Using-the-hdupdate-package.md
	new file:   VMWare-View-&-Citrix-ICA.md
	new file:   _Sidebar.md
	new file:   build.conf.md
	new file:   r1.png
	new file:   r10.png
	new file:   r11.png
	new file:   r12.png
	new file:   r13.png
	new file:   r14.png
	new file:   r2.png
	new file:   r3.png
	new file:   r4.png
	new file:   r5.png
	new file:   r6.png
	new file:   r7.png
	new file:   r8.png
	new file:   r9.png
	new file:   thinstation.conf.md
Donald A. Cupp Jr. 2024-12-10 15:56:23 -06:00
parent 6b7fa9a970
commit c04e04b899
60 changed files with 3173 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

BIN
1.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.4 KiB

BIN
10.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.8 KiB

BIN
2.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.8 KiB

BIN
3.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.9 KiB

BIN
4.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 5 KiB

BIN
5.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 5.8 KiB

BIN
6.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.2 KiB

BIN
7.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 77 KiB

BIN
8.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.2 KiB

BIN
9.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.1 KiB

BIN
Ani.gif Normal file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 12 KiB

73
Booting-Modes-and-Compression.md Normal file

@ -0,0 +1,73 @@
# ThinStation Boot Modes Overview
ThinStation supports several booting modes, each with unique characteristics and use cases.
## LiveCD Mode
**Description:** LiveCD mode operates similarly to many other projects. It involves an `initrd` file encapsulated in a `squashfs` archive, loaded into memory at boot. An early boot process involves creating a temporary file system (`tmpfs`) which merges with the read-only (RO) filesystem to create a read-write (RW) filesystem. The system then transitions to this new union filesystem to continue operations.
**Pros:**
- Simple to create.
- Disk-independent operation.
**Cons:**
- Filesystem lookup overhead.
- Moderate boot times.
- Moderate memory usage.
- Squash lag on application launch.
**How to Use:**
1. In `build.conf`, ensure the `overlayfs` package is included.
2. Set `initrdcmd` to `squashfs`.
## Initrd Mode
**Description:** This mode uses a simple `initrd` approach where the entire filesystem is compressed during build and then decompressed during booting.
**Pros:**
- Simple to create.
- Disk-independent.
- Very fast application launching.
**Cons:**
- High memory usage during boot.
- Longer boot times.
**How to Use:**
1. In `build.conf`, ensure `overlayfs` is 'not' included.
2. Set `initrdcmd` to `gzip`, `bzip2`, or `xz`.
## Fastboot Mode
**Description:** Exclusive to ThinStation, Fastboot mode splits the filesystem into essential early-boot components and additional components loaded later. It includes two sub-modes: standard and `lotsofmem`.
### Standard Sub-mode
- **Process:** Critical libraries and binaries are relocated to the `fastboot` subdirectory, with their original locations linked until `/lib` contains only links. This modified filesystem is then compressed into an `initrd`. Additional OS requirements are compressed into a `squashfs` archive.
- **Boot Process:** The `initrd` decompresses into memory, starting execution. The `squashfs` archive is mounted from boot media at `/lib` early during initialization.
**Pros:**
- Lowest memory usage.
- Fastest booting.
**Cons:**
- OS dependency on external `squashfs` archive location.
- Some filesystem parts remain read-only.
- Squash lag on application launch.
**How to Use:**
1. In `build.conf`, set `initrdcmd` to `gzip`, `bzip2`, or `xz` and enable `fastboot true`.
2. Optionally include the overlay package.
3. In `thinstation.conf.buildtime`, configure a mount entry for booting from removable media or internal storage that targets a volume label at `/boot`.
### Lotsofmem Sub-mode
- **Process:** Similar to standard mode, but the `squashfs` archive is decompressed into memory rather than mounted, enhancing performance and accessibility.
**Pros:**
- Rapid booting and application launching.
- Full filesystem read-write capability.
**Cons:**
- High memory consumption.
- OS dependency on external `squashfs` archive location.
**How to Use:**
1. In `build.conf`, ensure `overlayfs` is 'not' included.
2. Set `initrdcmd` to `gzip`, `bzip2`, or `xz` and enable `fastboot lotsofmem` in `build.conf`.
3. Configure a mount entry in `thinstation.conf.buildtime` as in standard mode.

175
Building-ThinStation-for-booting-off-SSD-(Goal:-Terminal-Server-Thin-Clients).md Normal file

@ -0,0 +1,175 @@
_These are my notes of the process, sans the dead-ends that I went down before figuring out my mistakes._
### Environment:
* Small school with ~ 35 aging computers, about 10 of those are for staff.
* Currently trying to keep up with updates and normal hiccups on a Windows environment.
* Server: Dell r710, 64G RAM, RAID, XCP-NG host; managed over Xen Orchestra
### Target:
* A VM running Linux Mint Cinnamon 20.4 and ThinLinc Terminal Server. Notes about the server [here](https://github.com/Thinstation/thinstation/wiki/Installing-ThinLinc-Server-for-a-thin-client-environment).
* Clients (aforementioned aging computers) booting ThinStation from a small SSD, with all ThinLinc Client options baked in, leaving no options except choosing another boot device at BIOS.
### Steps:
* Cloned thinstation.git per 'Getting Started.' onto my ThinkPad W53H0 (16G RAM, Core i7, OS and home on an SSD, put the Thinstation build environment on an HDD...it was a little slow. My OS is Linux Mint 19.2) [Note: as of v6.2 this takes 11.7 GB of space.]
`git clone --depth 1 git://github.com/Thinstation/thinstation.git`
`cd thinstation`
`sudo ./setup-chroot`
(NOTE: if you reboot or otherwise leave the build environment, you will need to run the setup again.)
Went with the default config for the first round:
`cd /build`
`./build --savedir --allmodules` [added _--allmodules_ since this will be used on [real hardware](https://github.com/Thinstation/thinstation/wiki/Examples), not VM's
Per the '[Deployment Page](https://github.com/Thinstation/thinstation/wiki/Deployment#booting-with-syslinux)',
`fdisk -l |grep -e "Disk /"` (my USB thumb drive is on /dev/sdc)
`mkmbrdrv -o /build/boot-images/syslinux -p d:0:boot /dev/sdc`
I tried this on a ThinkPad W500, and...success! Next step: try trimming out unnecessary packages, and adding the NoMachine NX client.
If you like Nano for text editing, do this in the chroot building environment; I like Neovim, so I did this from another terminal window:
`cd <path-to-environment>`
`sudo nvim build.conf` [sudo isn't needed in the chroot environment]
Removed (commented out):
* VMWare, Virtualbox-4.1, and qemu lines (Machine module list)
* module CIFS
* all language packages except English-US
* package freerdp
* package chrome
* package cups
Added (uncommented):
* package networkmanager (for wifi)
* package thinlinc
* package custom-idle
Ran the build again:
`./build --savedir --allmodules`
### ThinLinc package won't install
The version of the client had changed, so I got an error in the build process. As was noted [here](https://github.com/Thinstation/thinstation/issues/570), the file name comes from /build/build.urls, so I updated the _param thinlincurl_ to match the link of the client download (tar.gz package), and all worked as it should.
### Fine-Tuning the Configuration
Now for the details. I want users to get to their desktop sessions with as few clicks as possible, setting as few options as possible. So I want to pass on these parameters:
* Wifi SSID and key; some of the clients will use wifi
Per [ThinLinc Documentation](https://www.cendio.com/resources/docs/tag-devel/html/thinstation.html), I added these first to the thinstation.conf.network, only to discover that these are only valid for boot time configuration. So I added them to the bottom of thinstation.conf.buildtime:
`SESSION_0_TYPE=thinlinc`
`SESSION_0_THINLINC_SERVER=pc.pilgrimcs.org`
`SESSION_0_THINLINC_CONFIG_NFS_SERVER_ENABLED=0`
`SESSION_0_THINLINC_CONFIG_NFS_EXPORTS=/mnt/usbdevice,rw,/mnt/cdrom,ro`
`SESSION_0_THINLINC_CONFIG_NFS_SERVER_ENABLED=1`
`SESSION_0_THINLINC_CONFIG_SOUND_ENABLED=1`
`SESSION_0_THINLINC_CONFIG_NFS_ROOT_WARNING=0`
and commented out
* ThinLinc client launches on startup, no option to close it, no access to desktop environment ([possibly this](https://github.com/Thinstation/thinstation/blob/master/ts/build/packages/xdesktop-kiosk/build/conf/50openbox)?)
* Server IP; there will only be one target server
* [Update TS on client boot](https://github.com/Thinstation/thinstation/blob/master/ts/build/Documentation/README.local-install) OR ([HDUPDATE](https://github.com/Thinstation/thinstation/wiki/Using-the-hdupdate-package) (not sure which is preferable?); we may migrate to actual thin client hardware (maybe [Chromeboxes](link to chromebox hack script)?) depending on the difference in power consumption over time, but for now, I plan to acquire small (16G or less) SSD's. For our accounting class (which uses QuickBooks), I may need to leave some clients dual-booting into Windows, so I'll set a short BIOS time-out to let users choose the Windows drive if they need a desktop version of QB. NOTE: this will also make it trivial to hand out multiple TS images (e.g, one for staff and one for students), if that becomes helpful.
* Custom-idle; we have trouble getting our student computers turned off at the end of the day. However, I don't want to turn teachers' computers off automatically, unless at a certain time of the day (night), because they may be away from their machines for longer than the time-out I want to set for the student computers.
---
The documentation is detailed, but it took a bit to wrap my brain around the configuration file structure.
I believe I want to edit the thinstation.conf.buildtime, so I saved a copy as .orig, and will edit this one.
### Local-Install
(From [here](https://github.com/Thinstation/thinstation/blob/master/ts/build/Documentation/README.local-install)
Back in build.conf, I added (uncommented):
* package local-install
* package netfiles
I set these parameters to match our situation:
param basepath prod
param baseurl http://192.168.10.38
param basename thinstation
I tested the server (which is an NGINX server that I was able to get files onto via rsync, and off of via wget), but ran into issues. I'm holding off on this until I know for sure it isn't a LAN settings issue.
### xdesktop-kiosk
Back in build.conf, I added
* package xdesktop-kiosk
I couldn't find much help on configuration options, but from [this page](https://github.com/Thinstation/thinstation/blob/master/ts/build/packages/xdesktop-kiosk/build/conf/50openbox), I tried
remove from build.conf:
* #package xfwm4
#package xfwm4-extra
#package xfce4-power-manager
#package terminal # Terminal emulator for xfwm4 -- Pulls in xfwm4
#package thunar # File Manager for xfwm4 -- Pulls in xfwm4
Add:
package openbox # A spartin clean/fast window manager.
package xdesktop-kiosk # A locked down desktop kiosk using the openbox wm (See packages/xdesktop-kiosk/build/conf for # more help.
removing (commenting) these lines from thinstation.conf.buildtime:
* #SESSION_0_TYPE=xfwm4
* #SESSION_0_AUTOSTART=on
...and adding these lines to thinstation.conf.buildtime (make sure to uncomment the relevant lines):
> # Setup for a "desktop kiosk" e.g. a desktop without any system menus
> # SESSION_0 and SESSION_1 is MANDATORY. More sessions may be added.
> #ICONMODE=MANUAL
> MENU_SHOWABOUT=true # Have an about box or not
>
> SESSION_0_TITLE="openbox"
> SESSION_0_TYPE=openbox
> SESSION_0_AUTOSTART=On
>
> SESSION_1_TITLE="Exit"
> SESSION_1_TYPE=poff
> SESSION_1_AUTOSTART=Off
> SESSION_1_ICON=On
>
> # Add any additional package you may want, but keep AUTOSTART=Off and
> # ICON=On for each session
>
> #SESSION_2_TITLE="NX"
> #SESSION_2_TYPE=nx
> #SESSION_2_NX_GENERAL_SERVER_HOST=192.168.10.10
> #SESSION_2_AUTOSTART=Off
> #SESSION_2_ICON=On
>
> # End of desktop kiosk setup
the options set here are those that go in the [.nxs file](https://knowledgebase.nomachine.com/DT11R00186#3)
I may be starting to figure this out: I found the nxclient.cfg in the build environment right [where it should have been](https://github.com/Thinstation/thinstation/blob/master/ts/build/packages/nx/etc/nx/nxclient.cfg). I'm assuming that this is like other /etc files in that it provides a template if none exists. So probably there should be a place to create a customized version of this, but I don't know where it goes.
In recent NoMachine Enterprise Client installs, this corresponds with [player.cfg](https://www.nomachine.com/pdf/The_most_frequently_asked_options_for_pre-configuring_the_client_and_the_session_behavior.pdf). There are decent explanations in this doc.
Also in this doc are instructions about the connection file, which is a config file saved for every connection you set up in the client. In Linux, these are stored at ~/Documents/NoMachine/. Again, this is easy to find, if you know [where](https://github.com/Thinstation/thinstation/blob/master/ts/build/packages/nx/build/conf/50nx) to look. Probably the best way to get the right options set here is to run the client from your desktop, set up a session like you want it (In my case, the connection is called "PCS Terminal Server."), then open the connection file (~/Documents/NoMachine/PCS Terminal Server.nxs), and adapt the configuration (or at least the relevant lines/sections) to 50nx in the build environment. This isn't a straightforward copy/paste, because the format in 50nx is different, but the instructions are clear. For example, in my connection file (PCS Terminal Server.nxs), I have this line in the <group name="General" > section:
> <option key="Server host" value="192.168.10.10" />
The format in 50nx looks like this:
> SESSION_#_NX_GENERAL_SERVER_HOST="192.168.10.10"
Questions: what is the
### Attempts at Leaning the Build
From build.conf
* package gnome-control-center
* package volumeicon
* package xorg7-vmware

22
Certificates.md Normal file

@ -0,0 +1,22 @@
## How to add a certificate to a build
Your certificates will need to be base64(PEM) encoded and suffixed as either .crt or .pem
You will need to create a folder in /build/packages that contains a certs folder, and
within the certs folder, we can make a folder called ca to hold Certificate Authority certs.
mkdir -p /build/packages/my-certificates/certs/ca
Next create a dependencies file that pulls in ca-bundle
echo ca-bundle > /build/packages/my-certificates/dependencies
We now need to include our new package in the build configuration
echo "package my-certificates" >> /build/build.conf
You can drop any CA certificates you want in the /build/packages/my-certificates/certs/ca, and then run build. This should link your cert into all the right places.
Additionally, if you want to specifically trust a host certificate without a CA chain, you can create the 'trusted' folder as a location to place Peer certificates.
mkdir -p /build/packages/my-certificates/certs/trusted

126
Configuration.md Normal file

@ -0,0 +1,126 @@
## Introduction
ThinStation can be tailored to a variety of use cases. To allow for a certain degree of flexibility, ThinStation can be configured at build time *and optionally* later at boot time. Sometimes you will also want to [[create a new package|Packaging]] for your special configuration files.
## Build time configuration
The most basic part of build time configuration is about **hardware support**. Most of it is included in a **[[machine profile|Machine-profiles]]** suitable for your thin client hardware.
The **applications** included in the boot image are defined in a file called [[build.conf|build.conf]].
ThinStation is typically used to drive a mass of thin clients that share some configuration details. To increase fault tolerance and minimize individual configuration these **common runtime settings** can be **made default at build time** in a file called `thinstation.conf.buildtime` (by default, the name is set in `param defaultconfig`).
**A word of advice:** Use a sensible `thinstation.conf.buildtime`. If ThinStation somehow fails to find any other config file, all it has to fall back onto is `thinstation.conf.buildtime`, so it better make sense. Make it as simple as possible in the beginning, and then fine tune it and make it more complete once it basically works.
All files mentioned above need to be located in your `build` directory. You also need to [[rebuild|Getting-Started-with-ThinStation#building-a-boot-image]] the boot image to make changes effective.
## Boot time configuration
To speed up booting for systems and networks that don’t require it, ThinStation clients stick to the default build time configuration (see above) by default.
### Enabling
Nevertheless the *default* configuration can be overwritten at *boot* time to allow for a specialized behaviour for each thin client. These settings are delivered through the network (for exception see [[here|Configuration#Notes]]).
To allow boot time configuration, enable the `ts-classic` package and disable `networkmanager` and `udisks-glue` packages in your `build.conf`, set `NET_FILE_ENABLED=On` in your `thinstation.conf.buildtime` and rebuild your boot image.
### How and where to fetch the files
There are three ways of fetching the config files:
1. Over **TFTP**: By default boot images request configuration files from a subdirectory `ts5.4` of the TFTP root directory. (Settings: `NET_FILE_METHOD=tftp` in `thinstation.conf.buildtime` and `param basepath ts5.4` in `build.conf`)
2. Over **HTTP**: This is recommended because HTTP has better performance than the other two protocols. After setting `NET_FILE_METHOD=wget` in `thinstation.conf.buildtime` boot images request configuration files from a URL specified by `param baseurl` and `param basepath` in `build.conf`.
**Example:** To request file from `http://server/conf` set `param baseurl http://server` and `param basepath conf`.
3. Over **SCP**: This can only be used if the `ssh` package is included in `build.conf`. After setting `NET_FILE_METHOD=scp` boot images request configuration files from a directory (specified in `param basepath` in `build.conf`) on the TFTP server (or `NET_FILE_ALTERNATE` if defined) as user `NET_FILE_USER`. Note that all `NET_` directives need to be set in `thinstation.conf.buildtime`.
### Configuration files and their scope
You can address several sets of devices:
- **The whole network.** A file named `thinstation.conf.network` will be read by all ThinStation clients. In a file named `thinstation.hosts` you can define a mapping from MAC adresses to hostnames and **groups**.
- **A certain group of devices.** All devices that are part of a certain group (see above) will read their matching `thinstation.conf.group-groupname` files (in the order the groups appear in `thinstation.hosts`). Example: `thinstation.conf.group-terminalserver1`
- **A certain hostname.** A file named `thinstation.conf-hostname` will only be read by the thin client with the exact same hostname, set either via DHCP or `thinstation.hosts`. Example: `thinstation.conf-client1`
- **A certain IP adress.** A file named `thinstation.conf-IPaddress` will only be read by the thin client with the exact same IP address. Example: `thinstation.conf-192.168.0.55`
- **A certain [MAC address](https://en.wikipedia.org/wiki/MAC_address).** A file named `thinstation.conf-MACaddress` will only be read by the thin client with the exact same MAC address. Example: `thinstation.conf-005004AABBCC`
### Notes
**All client configuration is done in `thinstation.conf.*` files** (unless you change `param basename` to something else than `thinstation`). It is possible to have multiple such files, that are all downloaded and read in the order of mention [[above|Configuration#configuration-files-and-their-scope]], except for `thinstation.conf.buildtime`, which is built into the image and read first. So a client will start with whatever (defaults) you had defined in `thinstation.conf.buildtime` when you built the image. During boot it will look for `thinstation.conf.network`, then `thinstation.hosts`, and so on down the list above. Values read from any matching conf files will be retained if they are not overwritten by values from subsequent conf files.
You have a final (and thus overruling) option to store a configuration file on some local device. If you correctly configure the `STORAGE_PATH` setting then your boot image will look for `thinstation.profile/thinstation.conf.user` below that path.
**Not all settings can be defined in *downloadable* .conf files.** Specifically, the network and storage configurations. These will need to be defined in .buildtime. It's a chicken and egg problem. How do you access the network, when the config is on the network? Storage is required very early as well, because most of the image file loading can be deferred until later, but it must be accessible during system bring-up.
Last but not least: Configuration options will not take effect unless the corresponding package/option is built into the image. For example, defining an ICA session (`SESSION_#_TYPE=ica`) in a config file won’t help you if you didn’t include the ICA package in `build.conf`.
## Examples
The following are a set of usage scenarios for a ThinStation workstation
with examples of parameters for your thinstation.conf<whatever> file.
These settings can go in any of the thinstation.conf<whatever> files,
except where noted. (Please see above or [[here|FAQ#configuring-thinstation]]
for the order in which `thinstation.conf*` files are used).
### Windows Connectivity
ThinStation includes a number of Microsoft Windows connectivity
options. (rdesktop, Citrix ICA, NX, ThinLinc)
#### Automatic - Single Session on Microsoft Server via RDP
First of all uncomment this line in **build.conf** file:
`package rdesktop # X RDP Client for Windows Terminal Services`
**Scenario:** You have a workstation that should automatically connect
into your Terminal Services server.
Add this lines to file **thinstation.conf.buildtime** :
RECONNECT_PROMPT=On
SESSION_0_TYPE=rdesktop
SESSION_0_AUTOSTART=On
SESSION_0_RDESKTOP_SERVER=<ip of terminal services server>
If you want to add some default options you need to include them in the
OPTIONS parameters, eg.
SESSION_0_RDESKTOP_OPTIONS='-u `<user>` -p " " -d `<domain>`'
This will pre-populate the user and domain at the Windows logon screen and blank the password.
For information on all the available rdesktop parameters see the
[rdesktop man page](http://linux.die.net/man/1/rdesktop).
### Network Related
#### No DHCP server
**Scenario:** You have a workstation on the network and your network
does *not* have a DHCP server.
These parameters can go in any `thinstation.conf*` file as the
network on the workstation is restarted after reading all
`thinstation.conf*` files. If you have `NET_FILE_ENABLED=Off`
you *must* have these in **thinstation.conf.buildtime** or
**thinstation.conf.user** (as network based files won’t get read).
NET_USE_DHCP=Off
NET_HOSTNAME=<your hostname>
NET_IP_ADDRESS=<ip address>
NET_MASK=<ip mask eg. 255.255.255.0>\
NET_DNS1=<ip address of your first DNS server>\
NET_DNS2=<ip address of your second DNS server>\
NET_DNS_SEARCH=<default domain to search in, eg. mydomain.com>\
NET_GATEWAY=<ip address of your gateway>
#### No TFTP or HTTP server for network based configuration files
**Scenario:** You have a workstation on the network and your network
does *not* have a TFTP/HTTP server (for supplying `thinstation.conf*` files).
Include `NET_FILE_ENABLED=Off` in your `thinstation.conf.buildtime` file.
The workstation will still be able to read a
`thinstation.conf.user` if it exists.
#### No network card (or not connected)
If your workstation does *not* have a network card at all (or you are not
connecting to a network), you will need to have the settings for the two preceding sections and built your thinstation image with
`param haltonerror false`
in the `build.conf` file to ensure that the startup of ThinStation
does not stop unexpectedly.

54
Custom-Kernel.md Normal file

@ -0,0 +1,54 @@
While I do endeavor to make a kernel that works pretty much anywhere, sometimes people need something special, so here is how to make a custom kernel.
Make sure you are in the chroot.
`cd /ts/ports/kernel-modules/kernel-TS`
This will download the kernel source, unpack it and place it in
/ts/ports/kernel-modules/kernel-TS/work/src/linux-\<version\>
`pkgmk -d -f -eo`
Now we can
`cd work/src/linux-<version>`
This will copy the current kernel configuration into the place that the kernel source expects.
`cp ../ts.config .config`
You can now make any changes that you want to the kernel configuration using the kernel menu configuration system.
`make menuconfig`
Save your changes when you are done, and exit the utility.
We now need to copy the new config to somewhere the port system will understand, so
`cp .config ../../../ts.config`
Now go back to /ts/ports/kernel-modules/kernel-TS
`cd /ts/ports/kernel-modules/kernel-TS`
We need to update the md5sum for the new ts.config, so
`pkgmk -um`
You can now run
`rebuild-kernels`
That's it. The following commands will take you through a more manual process for the rest of the building process.
To actually build the kernel with the new configuration, we run
`pkgmk -u`
It is very likely that this operation will produce a footprint mismatch, so after the build completes, you will likely have to run
`pkgmk -uf`
Finally, we install the custom kernel with
`pkgmk -u`

186
Debugging.md Normal file

@ -0,0 +1,186 @@
ThinStation is a linux distribution with a large number of application packages, so the task of identifying problems when they occur can be a complex process.
Googling and searching the mailing lists is the first point of call. You'd be surprised how many questions have been asked & answered before.
But, if you can't seem to find the answer, we will try to help you narrow down where a problem occurs and help you to find out what caused it. Information gathered by this process will help you, even if it doesn't 'find the answer', in that your peers on the mailing lists will need some of this information to work with. Once you have gathered some information, don't be afraid to ask for help.
But, some good advice on [how to ask smart questions](http://www.catb.org/~esr/faqs/smart-questions.html) before
you post. We will growl, but only when people don't try to help themselves... :-)
Questions on installation & setup (including which drivers to use or settings for applications), should be directed to the ['General' mailing list](http://sourceforge.net/mailarchive/forum.php?forum_name=thinstation-general).
Throughout this section, you may be asked to look at various log files. If you are unable to start your desktop (or don't use one), you won't be able to use any gui tools, so you will need to [get to a console](Console).
## Common Symptoms
This is a list of common symptoms that people encounter. It may help you work out what to do, if not you will need to look at [ThinStation doesn't start, so how can I see the debug information?](Debugging).
### DHCP server not found! Network not initialized
This error has probably occurred because you haven't got the correct module loaded for your network card
If the workstation can't recognise your network card of find your network (maybe you aren't using one), your workstation will stop with
`DHCP server not found! Network not initialized.`
`This error has probably occurred because you haven't got the correct module loaded for your network card.`
`Debug not enabled, boot halted`
As the messages indicate, **ThinStation** stops. Thee easiest fix is to make sure that you included the correct module for your network card, but you may not find it that easy to determine.
To try to work out the module/driver for your network card,
- google for 'linux driver <my network card>', if you know the model
number, or
- include all of the network cards in your image and if it boots OK,
find which module was used by
`cat /var/log/messages | grep eth0`
it should show the module name of the driver loaded. Include just that one in your next build.
If none of this helps, then you may need to
- [Include the debug
package](Debugging)
and then investigate the issue
- [Stop ThinStation from halting too
early](Debugging)
- Setup you **ThinStation** for [non-network
operation](FAQ)
or any combination of the above :-)
### DevStation installer crashes with cpucheck
Change processor type to [qemu64] for the guest.
### A blank screen with an X on it
Another of the most common issues is when the X Window system seems to start, but your program doesn't (ie. you see a blank screen with an X in the middle).
### My screen is blank, but blinks every few seconds
You have been trying to start an application that uses the X Window system and this has been unable to start.
As you have AUTOSTART=On, it tries to restart it, so firstly you will need to turn off autostart. In your thinstation.conf<whatever> file set
`AUTOSTART=Off`
`SESSION_x_AUTOSTART=Off`
then continue as per the next topic...
### I select my application, the screen blinks and I return to the menu
You have been trying to start an application that uses the X Window system and this has been unable to start.
Press Ctrl+Alt+F2 to get a console and look at the var/log/boot.log file.
### USB drives not auto mounting
The first thing to check is your build.conf, make sure these two lines are uncommented
`module autofs4`
`package automount`
Boot this newly created image and run the `df` command, you should see something like:
`/dev/sda1 32523532 33467722 3322 1% /mnt/mnt/usbdevice/<label of your usb device>`
If you still do not see your USB devices showing up, remove the USB and reinsert it, and run the command `dmesg | tail -20` look for any error messages, you may be missing the necessary driver.
If you need USB to work with xfreerdp, add the following to your thinstation.conf.buildtime:
`SESSION_X_FREERDP_OPTIONS="<existing options> /drive:USB,\/mnt\/mnt\/usbdevice"`
This will pass through any USB devices that show up in /mnt/mnt/usbdevice/ dynamically, and will show up as a System Folder:
![USB through xfreerdp](http://i.imgur.com/olJtxkN.png)
## ThinStation doesn't start, so how can I see the debug information?
By default, ThinStation will halt if you have a major error (and it doesn't know what to do). When halted you can't look at anything... :-(
So, there are a couple of things that you can do to help it continue to a stage where you are able to gather the information that you need to find out what the problem is.
### Turn off the bootsplash
Press F2 whilst the bootsplash is showing and it will disappear.
But, if you want to turn off the bootsplash entirely, so that you can see ALL the messages, and you are using syslinux or pxe booting. On the kernel line of your syslinux.cfg or pxelinux.cfg you will find the parameters
`vga=791 splash=silent`
Please remove the splash=silent parameter.
If you also have
`console=ttyS3`
please change this to
`console=tty0`
and then the kernel messages will be displayed on your console (rather than the bootsplash).
If you are building a new image set
`param bootlogo false`
will do the same (and this works for the CD/iso image as well).
### Display more information
Rebuild your image with
`param bootverbosity 63`
or play with the setting to get the level of detail you want.
`0 no verbose messages`\
`1 boot`\
`2 network`\
`4 init`\
`8 kernel`\
`16 modules`\
`32 packages`\
`64 email bootlog file to SMTP server & user set in thinstation.conf file. This will only work if networking is working.`
Combinations can be used eg. 12 (8+4) does Kernel and Init messages
### Stop ThinStation from halting too early
Rebuild your image with
`param haltonerror false` in your build.conf
and
`NO_SESSION=/bin/sh`
`NO_XORG_CMD=/bin/sh` in your thinstation.conf.buildtime
This is particularly useful when there are network problems and will allow the workstation to start even when the network doesn't.
### Include the debug package
Rebuild your image with
`package debug`
**Note:** with debug included your startup will ALWAYS stop after system initiation, so that you can either look at debug information or press enter to continue into the sessions. Remove the debug package when you
have finished.
## Where to find information
The main log files for ThinStation are found in the `/var/log` directory.
- `/var/log/boot.log` contains the ThinStation specific debug
messages
- `/var/log/messages` contains the kernel information & degug
messages (and can be quite big)
- `/var/log/XOrg.0.log` contains the X Window system log, if you
have already started a graphical system. eg. rdesktop, icewm, etc.
(also quite big)
What has been picked up from the various thinstation.con<files> can be found in:
- `/etc/thinstation.defaults` contains the contents of
thinstation.conf.buildtime
- `/thinstation.buildtime` contains the contents of
thinstation.conf.buildtime when built via a TSoM
- `/etc/thinstation.network` contains the contents of
thinstation.conf.network (and other associated network files)
- `/etc/thinstation.user` contains the contents of
thinstation.conf.user
- `/etc/thinstation.runtime` contains the TS calculated settings
To look at these files you will need to [get to a console](Console) or use a filemanager.
`more /var/log/boot.log`
space gives the next page, q exits.

124
Deployment.md Normal file

@ -0,0 +1,124 @@
## Introduction
You have to decide which **medium** a thin client will use to load the ThinStation boot image (“deployment”). You have three options:
Note - All bootloaders besides grub have been deprecated. While many of the concepts written here are still applicable, the only available bootloader is grub, and it supports all booting modes.
1. [[CD/DVD|Deployment#booting-from-cd]] with [GRUB][]
2. [[Removable media or internal storage|Deployment#booting-from-removable-media-or-internal-storage]] with [GRUB][]
3. [[Network|Deployment#booting-from-network-via-pxe]] with [GRUB][]
4. [[Network|Deployment#booting-from-network-via-ipxe]] with [IPXE][]
[IPXE]: https://ipxe.org/
A comparison:
Medium | CD/DVD | removable media | internal storage devices | network
:-------|:---------|:--------------------------|:-----------------|:----
**Initial setup effort** | very low | low | medium | (very) high
**effort of boot image update** | medium | medium | high (low [[Using-the-hdupdate-package]]) | low
**massive parallel booting** | no problem | no problem | no problem | network bottleneck
No matter which way you deploy ThinStation you can always [[fetch configuration files|Configuration#boot-time-configuration]] through the network.
## Booting from CD
A very easy way to boot ThinStation is from CD or DVD.
### Pros and Cons
**Pro:** little setup required; reliable boot process
**Con:** tedious process of (erasing and) writing an optical medium; does not scale (work well) for lots of thin clients (lots of CDs have to be written)
### How to
Fetch the [ISO](https://en.wikipedia.org/wiki/ISO_9660) image file `thinstation-efi.iso` from the subdirectory `build/boot-images/grub` of you build environment and write it onto a CD or a DVD using any available CD/DVD writing application. Now put this CD/DVD into the thin client optical drive and boot from it.
## Booting from removable media or internal storage
If you plan to boot from either removable media or internal storage devices you will probably be using the same bootloader: [GRUB][].
[GRUB]: http://www.gnu.org/software/grub/
### Pros and Cons
**Pro:** little setup required (only BIOS/UEFI); reliable boot process; scales (works) well for lots of thin clients if you have a stable boot image in place
**Con:** tediuous process of writing the boot image to the drive (USB stick, Compact Flash card, SD card, hard disk) – To avoid this [[use hdupdate|Using-the-hdupdate-package]].
### How to
1. Is your drive *physically* attached to your development system?
- **Yes**: From inside the chroot environment identify the drive that you want to be bootable.
`fdisk -l |grep -e "Disk /"`
will list all block devices attached to the system (e.g. `/dev/sdb`).
Then run
`mkmbrdrv -o /build/boot-images/grub/efi-source -p d:0:boot <drive ex. /dev/sdb>`\
or\
`flash <device ex. sdb>`
- **No**: Maybe use this [[ CD to USB|Making-bootable-media-on-Windows]]
2. Put your drive (back) in the thin client and boot from it.
When doing a remote install, consider the local-install package or the installer package for an interactive deployment.
## Booting from network via PXE
The easiest and most common method of booting ThinStation from network is by using [PXE](https://en.wikipedia.org/wiki/Preboot_Execution_Environment). PXE is implemented in virtually every modern networking card (including onboard devices on mainboards). Thus it is very likely that your thin client supports PXE booting.
### Pros and Cons
**Pro:** on the client side almost no setup (only BIOS/UEFI) and no storage device is required
**Con:** in your network a set of services (DHCP, TFTP) is required that is not trivial to set up; does not scale (work well) for lots of thin clients (the delivering server is a bottleneck)
### Prerequisites
#### DHCP
PXE requires you to have a working [DHCP] service for assigning IP adresses to thin clients. In addition to that you have to configure two so called DHCP options for requesting thin clients:
1. To tell a thin client where to boot from you have to set option number 66 to the hostname or the IP address of the TFTP file server (serving the boot loader).
2. Each thin client has to know which file to request as a boot loader from the TFTP server. You have to set option number 67 to the exact file name of the PXE boot loader on the server.\
This is `boot/grub/pxeboot.img` for BIOS mode.\
This is `EFI/boot/grubx64.efi` for EFI mode.
[DHCP]: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
[TFTP]: https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
#### TFTP
You also need to set up a [TFTP][] file service to deliver
1. the PXE boot loader file (mandatory),
2. the PXE boot loader configuration files (optional but *very common*),
3. the Linux kernel (optional but *very common*),
4. the initial ramdisk ([initrd](https://en.wikipedia.org/wiki/Initrd)) for system boot up (optional but *very common*) and
5. [[boot time configuration|Configuration#boot-time-configuration]] files for ThinStation thin clients (optional but *common*).
Numbers 3 and 4 from above can be delivered by HTTP or FTP servers too. This needs special configuration of GRUB that is not covered here.
All of the above files need to reside in the TFTP server root directory (“TFTP root”) tree that is served to thin clients.
### How to
1. Copy all files from the following subdirectory `build/boot-images/grub/efi-source` of you build environment into your TFTP root directory.
2. Boot your thin client via PXE.
By default all devices booting via PXE will now load your most recent ThinStation boot image.
## Booting from network via iPXE
### Pros and Cons
**Pro:** Faster then PXE when you use HTTP instead of TFTP
**Con:** in your network a set of services (DHCP, HTTP) is required that is not trivial to set up; does not scale (work well) for lots of thin clients (the delivering server is a bottleneck)
### Prerequisites
#### DHCP Server
#### HTTP Server (Webserver)
### How to
1. Build ThinStation.
2. Copy the following files from the subdirectory `build/boot-images/grub/efi-source/boot` of you build environment into your HTTP root directory:
- `vmlinuz` (Linux kernel)
- `initrd` (initial ramdisk).
3. Create boot entry in your ipxe menu
4. If you have fastboot enabled
- Copy `lib.squash` somewhere accessible over http (can be along side `vmlinuz`),
- You might also need to set `FASTBOOT_URL=` in `thinstation.conf.buildtime` to point to the directory that contains this file.
`#!ipxe`<br>
`kernel ${boot-url}/thin/boot/vmlinuz splash=silent,theme:default console=tty1 LM=3`<br>
`initrd ${boot-url}/thin/boot/initrd`<br>
`boot `

65
DevStation-Setup.md Normal file

@ -0,0 +1,65 @@
## What is DevStation?
DevStation is the name of a pre-configured Linux system primarily used for building ThinStation boot images. DevStation is not required in order to use the ThinStation build system, but it's a nice place to start because it helps establish the work flow for building boot images.
[Watch the video.](https://youtu.be/9R5eKjE618s)
## Where to get it
You can obtain DevStation by downloading the installer disc ISO image at <http://sourceforge.net/projects/thinstation/files/latest/download>.
## Installing DevStation
Allthough it is possible to install the DevStation image onto real hardware, most find it considerably faster to develop on a workstation capable of hosting multiple virtual machines (servers, clients and other network appliances).
[Watch the video.](https://youtu.be/9R5eKjE618s)
### Specifications for creating a new virtual machine
Option | Value
-------|------
Type: | Custom
Compatibility: | Default
Installer disc: | dowloaded ISO image file (see above)
Guest OS: | Linux
Version: | Other Linux 2.6.x kernel 64-bit
Name: | DevStation
Location: | Default
Processors: | 1
Cores: | **minimal value 2** 8vCPU recommended
Memory: | **minimal value 4 GiB** 16 GiB recommended
Video Memory: | **minimal value 64 MB**
Network Connection: | Bridged
SCSI Controller: | Default
Disk: | Default
Disk Type: | Default
Maximum disk size: | 30 GB for a shallow single branch checkout. Over 60 GB for deep history and branch comparison.
Disk File: | Default
### Installation steps
1. Power on virtual machine.
2. Select “Installer for DevStation” menu option. GRUB will load a little over 100 MB into memory.
3. Read all notes shown after startup. Select OK.
4. Select Disk to use for installation. Select OK.
5. Select native resolution of the display. Select OK.
6. Select your time zone. Select OK.
7. Select your locale (language, symbols and keyboard layout). Select OK.
8. Confirm all warnings. The installer will download a bootable OS image and several GB via Git.
9. Read all notes shown after installation. Select OK, to acknowledge each one. Remove the CD when instructed to do so. Click OK to reboot.
## Usage
### Booting
Upon rebooting the system should automaticly boot the “Standard” image within a 15 second timeout. A “Backup” image is available in the case that a web update is defective or a local build of the DevStation image does not behave as expected.
### Building Your First Image
Click *Start › DevStation › Build Image*. This will build a default image that is bootable in a virtual machine. The image will include:
* XFWM4 (Window manager)
* Chromium (Web browser)
* NetworkManager (Networking stack)
* Gnome media packages and plugins
* Xorg drivers for most vendors **(Not the kernel modules though!)**
* FreeRDP (Remote access application)
* Open VM Tools (copy & paste)
* Terminal (shell utility)
* Thunar (file manager)
* Samba (SMB client)
* CUPS (printing system)
* All available time zones
* All available locales
## What’s next?
Please read on [[here|Getting-Started-with-ThinStation#whats-next]].

33
Errors-Running-mkmbrdrv.md Normal file

@ -0,0 +1,33 @@
_This is a page for errors that I encountered enroute to my NoMachine Terminal Server setup as documented [here](https://github.com/Thinstation/thinstation/wiki/Building-ThinStation-for-booting-off-SSD-(Goal:-NoMachine-Thin-Clients))._
### NoMachine package won't install
Encountered [this error](https://github.com/Thinstation/thinstation/issues/644); apparently the download link structure at NoMachine has changed.
Per Doncuppjr's suggestion, I downloaded the NX client manually, and copied it into /thinstation/downloads (I couldn't use wget for the very reason that the build script failed: no link). The problem package was in there, so I knew I was in the right place.
This time the script didn't try to download with wget, but I still got the same error message. I thought it might be still trying to unzip the (original) problem file, so I deleted that one.
`Saving to: './wget_tmp/nomachine-enterprise-client_6.11.2_1_x86_64.tar.gz`
Apparently the NX client version is hard coded in the script? After looking at /ts/build/packages/nx/build/install, and not seeing how to redirect it to the file I downloaded, I renamed the new download to match the failed download:
`sudo cp nomachine-enterprise-client_7.6.2_4_x86_64.tar.gz nomachine-enterprise-client_6.11.2_1_x86_64.tar.gz`
This time, success!
As was noted [here](https://github.com/Thinstation/thinstation/issues/570), the file name comes from /build/build.urls, so I could edit the _param nxurl_, but since I can't feed it the correct download url anyway, it's just as simple to rename the manually downloaded file as I did above.
I got a number of errors running the `mkmbrdrv` command, including...
`blockdev: ioctl error on BLKRRPART: Device or resource busy`
`mount: /tmp/mkmbrdrv.yH4: special device /dev/sdc1 does not exist.`
In most cases, removing the USB drive, and reinserting it in a different slot did the trick. I did have one bad USB drive, so make sure you have several on hand. I don't know what caused the 'mount' error, because running the fdisk command again gave the same output. Below is the output after a successful write to the USB drive.
---
### Local-Install

15
Examples.md Normal file

@ -0,0 +1,15 @@
## Here are a few examples.
The default build. Should work on all VM's, build --allmodules for real hardware
[default](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/build/conf/default)
This is the profile I use for the LiveCD that is distributed from sourceforge. Build with --allmodules
[The LiveCD](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/build/conf/LiveCD)
This is the profile I use for the DevStation image. You can use it to rebuild your DevStation with a new hard coded password. Build with --allmodules
[DevStation](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/build/conf/devstation)
A minimalist build with IceWM and VMView. Use with a machine profile.
[VMWare View](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/build/conf/vmview)
A minimalist build with FreeRDP, no WM. Use with a machine profile.
[FreeRDP](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/build/conf/freerdp)

813
FAQ.md Normal file

@ -0,0 +1,813 @@
### Disclaimer
> 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.
### ThinStation features
- Linux kernel 6.1 (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
### Hardware requirements
- 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.
### 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.
### 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 do I change to the console?
Please press Ctrl Alt F2.
### 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](Conf_Example#Network_Related "wikilink") 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`
### 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](http://syslinux.zytor.com/wiki/index.php/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](http://www.etherboot.org/)*
- 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](http://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](http://sourceforge.net/project/showfiles.php?group_id=80408&package_id=97496&release_id=190646)
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](http://www.etherboot.org/)).
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.
***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/`<device>
More info on [syslinux](http://syslinux.zytor.com/faq.php)\
Lars Karlslund has contributed a ThinStation [Compact Flash card +
syslinux boot HOWTO](http://thinstation.sourceforge.net/CF-HOWTO.html)
***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](http://en.wikipedia.org/wiki/Loadlin)
### PKG packages
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.
Configuring ThinStation
-----------------------
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](thinstation:Conf "wikilink").
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...
### DHCP
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](http://isc.org/products/DHCP/dhcp-v3.html) by
[isc.org](http://isc.org/).\
Paul Whittaker has a great piece on Windows 2000 and DHCP
[here](http://diet-pc.sourceforge.net/windows/etherboot-w2k.html).\
And there is a fine Linux guide at
[www.Linux.org](http://www.linux.org/docs/ldp/howto/mini/DHCP/).
### TFTP
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):\
<quote>\
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](http://diet-pc.sourceforge.net/windows/etherboot-w2k.html#tftp)
for details). Morgan Simonsen has constructed a [standalone TFTP
server](http://www.simonsen.bz/w2k_standalone_tftp_dameon.htm) 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](http://tftpd32.jounin.net/) 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](http://tftpd32.jounin.net/) on Windows, and
[tftp-hpa](http://www.kernel.org/pub/software/network/tftp/) (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.\
</quote>
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](http://www.simonsen.bz/w2k_standalone_tftp_dameon.htm) 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](http://www.firedaemon.com/) (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](http://thinstation.sourceforge.net/tftpd-service.html)
concerning this.
## Debugging
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|Debugging]].
## How does a thinstation thinclient get booted?
1. The kernel gets loaded.
2. The kernel loads initrd and starts from it.
3. Busybox init process gets started -- `/etc/inittab`
4. Runlevel scripts get started -> `rc2.d` `rc5.d` package scripts
5. Autologin on console with `TERM` set to `xinit`
6. `/etc/profile` starts xinit for X GUI.
7. Window manager comes up.
## Booting ThinStation
### Can I have individual configuration files for different clients?
Yes.
In your TFTP server's download directory you just create a configuration
file named *thinstation.conf-<ip address>* (e.g.
*thinstation.conf-192.168.1.2*) or *thinstation.conf-<MAC address>*
(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-<host name>* (e.g. *thinstation.conf-peter*). Much
easier to remember.
### Can I have individual image files for different clients?
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.
### My NIC does support PXE but PXE boot doesn't work
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](http://syslinux.zytor.com/) to boot (loadlin is simple,
syslinux offers more candy). See [How to install
ThinStation](FAQ#How_to_install_ThinStation "wikilink").
#### How much disk space do I need then?
8 to 20 megabytes if you can afford it (depending on what applications
you load).
#### So little!? Couldn't I use a USB keyring or a Compact Flash Card
instead?
Yes - see Lars Karlslund's contributed [Compact Flash card + syslinux
boot HOWTO](http://thinstation.sourceforge.net/CF-HOWTO.html).
### Can I boot off a CD (KNOPPIX style)?
Yes. That's what the ThinStation boot CD does! You can use ThinStation
without ever touching your PC's harddisk.
### Can I boot off a CD if my BIOS/CD doesn't support boot?
Yes, with a little help from a boot floppy: [Smart Boot
Manager](http://btmgr.sourceforge.net/).
### Can I boot off just a floppy?
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.
### Can I avoid the TFTP server?
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).
### Can't I avoid the DHCP server?
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=<IP of TFTP server> in your
*thinstation.conf.buildtime*
## Peripheral Questions (NIC, Video, Mouse etc.)
### Which mouse protocol to use ?
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>
### How do I get the scroll wheel on my mouse to work?
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
### How do I get my USB mouse to work?
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*.
### The ThinStation X server doesn't start - it keeps on trying and trying.
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
<base>`/packages/xorg6-`<name>`/lib/X11/modules/drivers/`
Put the driver itself (<name>.o) there and chmod it into -rwxr-xr-x.\
Edit build.conf and add xorg6-<name> 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.
### My keyboard layout isn't supported or is broken
See the [keyboard request
guide](http://thinstation.sourceforge.net/keyboard-guide.html). However,
see also [Faulty keyboard layout with MS Windows server using
RDP](#Faulty_keyboard_layout_with_MS_Windows_server_using_RDP "wikilink")
(rdesktop)
### Seamless Integration of Client Side Floppies and CD-ROMs with MS Windows Terminal Servers
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%\\<device> "" /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 \$SAMBA\_CDROM entries in
packages/samba-base/lib/smb.conf.tpl before building thinstation-2.0.
(the trailing \$-signs makes the drives hidden from My Network
Places-browsing - you may want this if you haven't complete physical
control over your network). If you do change the defaults, make sure to
change your logon scripts too!
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!
## UNIX Servers
### The X font server doesn't work
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*.
### I can't connect to a unix server using X (just black screen and mouse pointer)
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).
## Microsoft Windows / Citrix Servers
### Poor colors and no sound connecting to a MS Windows server with RDP (rdesktop)
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](#Psychadelic "wikilink")).
Windows 2003 support sound redirect (if configured properly). Use the
"-r sound" command line option.
### Psychadelic colors when using 8 bit colors with RDP (rdesktop)
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.
### Faulty keyboard layout with MS Windows server using RDP (rdesktop)
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](http://thinstation.sf.net/keyboard-guide.html).
### Flickering display with animated content in MSIE
See this [knowledgbase
entry](http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q271/2/46.ASP&NoWebContent=1).
Easy in IE6, but requires a registry hack in 5.5. Thanks to Chris
McKeever for this one.
### Cool! I just run MS Windows on a server and save all the licence money!
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](http://www.brianmadden.com/content/content.asp?id=154).
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
### How do I use 128 bit encryption with ICA?
Add `param icaencryption true` to *build.conf* and `ICA_ENCRYPTION="RC5 (128 bit)"` to a *thinstation.conf*.
## ThinStation as a Workstation
### Can ThinStation be a light Linux workstation - or how do I get root access?
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).
### How do I change the root password - and should I change it?
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)
### Can the clients have a /etc/hosts file the usual unix style?
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.
### How are the clients named networkwise when using DHCP?
As default they are named ts\_<MAC address>. "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.
### What is the group configs about?
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-<group name>* (e.g
*thinstation.conf.group-printer*). A
*thinstation.conf.group-<group name>* 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](FAQ#Configuring_ThinStation "wikilink")
## Miscellaneous
### Why does TS try to download the config file from a TFTP server when I boot from a local media?
Because you did not set NET\_FILE\_ENABLED=Off in
thinstation.conf.buildtime!
### Do you have more docs on ICA, rdesktop, tarantella, blackbox...
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](http://sourceforge.net/apps/mediawiki/thinstation/index.php?title=Application_Links).
### Can I add my own package to ThinStation?
Yes. It requires some Linux/programming skills, though.
Look at the Developer documentation [Create your own
package](Developer:Create_your_own_package "wikilink")

29
Fastboot.md Normal file

@ -0,0 +1,29 @@
# Fastboot - What does it do? How does it help?
Simply put, fastboot attempts to defer as much of the file-system as it can during the initial kernel and initrd loading.
This is a multi-step process.
1. During build. The final desired file-system is divided in two. The first part is all the essential bins, libs and configuration information that is needed to bring the system up to a point where it can load the remainder of the file-system from the original source medium, such as the network, CD or HD. The second part is a mangled(truly) pile of remainder called lib.squash. It contains all the high level user bins and libs for applications, gui's, Xorg and assets galore.
2. During booting, The remainder of the file-system is transferred from a network location, or loaded into memory from local storage. It is then mounted at /lib.
The main benefit of this approach, is that coming out of the BIOS bootloader, or EFI startup, can be a very slow process. Every byte takes a lot of time to download, or load from disk. Conversely, once the kernel starts, we have a lot of options, and DMA to enable very fast loading from both local and network mediums.
It's a little ugly under the covers, but were dealing with embedded here. Having a file-system that is coherent to a human would be a penalty. If we let go of that requirement, we get to play with some fun new ideas.
### Caveats: The base file-system must have enough modules, firmware and configuration to get to the remainder.
If your having difficulties getting a stable system, or init fails to complete in the way you expect, try setting
param fastboot disabled
in build.conf
The system needs to know how it was booted, so that it can make the right choices in the most direct way to find the remainder of the file-system to load. This is done with the parameter "LM=[2-4]" on the kernel command line.
2. Try and continue from a hard drive or thumbdrive. The drive should have an entry in thinstation.conf.buildtime listed as MOUNT_[0-9], that will be mounted at /boot. For example
MOUNT_0="LABEL=boot /boot auto x-mount.mkdir,defaults 0 0"
3. Try and continue from the network. You will likely need to use the autonet package instead of network manager. If your kernel and initrd were loaded from http, then lib.squash will also load from http, alternatively, you can set
FASTBOOT_URL="http://[dir containing lib.squash]"
If your kernel and initrd were loaded by tftp, you may need to set
SERVER_IP="[IP of Server]"
4. Try and continue from a CD. The CD needs to have a label equal to $CDVOLNAME. CDVOLNAME is "ThinStation" by default.
While it is possible to mix starting and continuation methods, that would be silly. Also, trying to move files from one type of medium to another, like making a thumbdrive out of an ISO is problematic, but not impossible.

3
Fools-Tools.md Normal file

@ -0,0 +1,3 @@
## Some of my scripts. Rough......
[Fools Tools](https://github.com/Thinstation/thinstation/tree/6.2-Stable/ts/bin)

40
Getting-Started-with-ThinStation.md Normal file

@ -0,0 +1,40 @@
## Choosing a build environment
First of all you have to set up a **[ThinStation](https://thinstation.org/) build environment** for boot images. You can choose between either
* a pre-configured, dedicated Linux installation called **[[“DevStation”|DevStation setup]]** or
* a **standard Linux installation** of your choice. Read on for further instructions.
[Watch the video.](https://youtu.be/9R5eKjE618s)
## Cloning the ThinStation Git repository
Let’s assume you chose the second option from above. Then you need a reasonably modern Linux installation with [Git](https://git-scm.com/) installed.
Start up a shell window and run:
git clone --depth 1 https://github.com/Thinstation/thinstation.git
This will clone the current stable ThinStation branch into a newly created directory `thinstation`.
## Building a boot image
Enter the [chroot](https://en.wikipedia.org/wiki/Chroot) building environment as _root_ (use **sudo** on Ubuntu):
```
cd thinstation
./setup-chroot
```
You'll always launch this before creating a new build or iso.
This will take a few seconds. You will end up reading the file [`README.md`](https://github.com/Thinstation/thinstation/blob/6.2-Stable/README.md). Leave the pager application by pressing `q`.
Let’s move on with building your first ThinStation boot image (always as _root_ in chroot environment):
```
cd /build
./build --savedir
```
This will again take some time (up to a few minutes, depending on your system). Afterwards in the subdirectory `boot-images`, multiple flavors of boot images will be available. You could now go and [[boot|Deployment]] any of these images, but they probably will be of no real use to you, as the default config is very generic. Most people getting into ThinStation usually need a very specific result, so we need to edit the configs to make something tailored to your environment.
## What’s next?
After having seen how to build ThinStation boot images, it is time for you to adapt the configuration to your requirements. This involves
* deciding how to **[[deploy|Deployment]]** ThinStation (how to boot up your thin clients),
* analyzing the **target hardware** (where your boot image is intended to be run on),
* choosing the **applications** (or protocols) to be used by the end user and
* for each application defining the **parameters** (details on how it should operate). See [[here|Configuration]] for further instructions.
From time to time you will want to [[update your repository|Updating-your-repository]].

18
Home.md

@ -1 +1,17 @@
Welcome to the thinstation-ng wiki!
Welcome to the ThinStation wiki!
Please have a look at the [ThinStation homepage](http://thinstation.org/) and then review [[Getting Started with ThinStation|Getting Started with ThinStation]].
The outline on the right side is just a selection of topics. For all wiki pages click on “Pages”.
ThinStation is a basic and small, yet very powerful, Open Source [thin client](http://en.wikipedia.org/wiki/Thin_client) operating system supporting all major connectivity protocols: [Citrix](http://citrix.com/) ICA, [Redhat](http://www.spice-space.org/) Spice, [NoMachine](http://nomachine.com/) NX, [2X](http://2x.com/) ThinClient, [Microsoft](http://microsoft.com/) Windows terminal services (RDP, via RDesktop/FreeRDP), [VMWare](http://www.vmware.com/products/horizon-view) Horizon View, [Cendio](http://cendio.com/) ThinLinc, [Tarantella](http://en.wikipedia.org/wiki/Tarantella,_Inc), [X](http://xorg.freedesktop.org/wiki/), [telnet](http://en.wikipedia.org/wiki/Telnet), [tn5250](http://en.wikipedia.org/wiki/Tn5250), [VMS](http://en.wikipedia.org/wiki/OpenVMS) terminal and [SSH](http://en.wikipedia.org/wiki/Secure_Shell) (No special configuration of the application servers is needed to use ThinStation).
ThinStation is mainly intended for schoolroom, office, company or department use, but can be used at home (eg. for a silent PC in the bedroom that 'runs' XP on your workstation in the back room).
While ThinStation is based on Linux, users may actually never see Linux at all. If you decide to connect directly to a Microsoft Windows, Citrix or Unix server, the user will feel that they are running directly on the server. But, you can also have a local Desktop interface (with a local Browser & other tools).
ThinStation supports a Microsoft Windows-only environment and REQUIRES NO UNIX/Linux KNOWLEDGE.
ThinStation runs on ordinary PC hardware (64 bit i686 class). You may either reuse older computers or save a lot of time on workstation administration. Or both! An old Core2Duo with 2GB of RAM or better can be a perfectly useful workstation. And you don't need a hard disk - you can boot off the network and even have a silent workstation. Workstation devices (floppy/HD/CD/USB) and printers (LPT/USB) are supported.
ThinStation can be booted from network (e.g. diskless) using Etherboot/PXE or from a local floppy/CD/HD/flash-disk, and prebuilt images and a Live CD are available. The thin client configuration can be local or centralized to simplify management.

27
Installing-ThinLinc-Server-for-a-thin-client-environment.md Normal file

@ -0,0 +1,27 @@
This is a sub-page of [my experience](https://github.com/Thinstation/thinstation/wiki/Building-ThinStation-for-booting-off-SSD-(Goal:-Terminal-Server-Thin-Clients)) setting up a terminal server with ThinStation clients.
I experimented with NoMachine Enterprise Server, which was a good product, but pricey. I found ThinLinc, which had a feature that made me move that direction: the ability to customize (via a web configuration page) the menus users see and the apps they have access to.
First glitch was that the server installation halted with an error message. In the terminal, I discovered that it couldn't install pythonGTK, because it couldn't find Python-gtk2. ThinLinc [knows about this](https://www.cendio.com/bugzilla/show_bug.cgi?id=7508), and this thread has a link [here](https://askubuntu.com/questions/1235271/pygtk-not-available-on-focal-fossa-20-04) that got me past that hurdle.
>cd ~/Downloads
>wget http://archive.ubuntu.com/ubuntu/pool/universe/p/pygtk/python-gtk2_2.24.0-5.1ubuntu2_amd64.deb
>sudo apt-get install ./python-gtk2_2.24.0-5.1ubuntu2_amd64.deb
This will give more errors, but following the apt-get suggestion (apt --fix-broken install) should fix it.
At this point, the installer GUI pulled up, the server installation completed, and I clicked through to begin the server setup. Here I hit a glitch with python-ldap. I found [these notes](http://geobib.fr/blog/2020-08-28-python-ldap-ubuntu-20), and after [installing pip](https://linuxhint.com/installing_pip_linux_mint/), I ran these commands to install python-ldap:
>sudo apt install python-dev libldap2-dev libsasl2-dev gcc
>pip install python-ldap
I reran the ThinLinc Setup, but for some reason, it still didn't work. Since I'm not planning to use LDAP, I let it go for now. (*NOTE:* you need to uncheck the option to install this package so that the setup will finish.)
Installing VirtualGL made a significant difference. Make sure to follow the directions explicitly, especially about when to install proprietary drivers.
1. Uninstall (or wait to install) nVidia proprietary drivers.
2. Install the VirtualGL package.
3. Install nVidia drivers.
4. Configure VirtualGL (vglserver_config). We said 'No' to all 3 restriction questions because we weren't concerned about the security risks in our situation, and we didn't know for sure that saying 'Yes' would work for us.
Next problem: VirtualGL doesn't play nicely with KTouch.

43
Machine-profiles.md Normal file

@ -0,0 +1,43 @@
## Introduction
Running Linux 4.x and X.org 7.x in 64 MB diskless is not trivial. ThinStation is a minimalist Linux distribution, so it takes more interaction from you than a typical fat “include-everything-and-the-kitchen-sink” type of distribution (like e.g. RedHat).
In order to keep the boot image small, you have to define which hardware will be supported by it. ThinStation uses **machine profiles** to represent hardware configurations. There are a couple of [predefined machine profiles](https://github.com/Thinstation/thinstation/tree/master/ts/build/machine), but you probably have to create your own.
## What is a machine profile and how do I use it?
Technically spoken, a machine profile is a subdirectory of `build/machine` containing the files `module.list`, `firmware.list` (optional), `vbe_modes.list` or `package.list` (optional).
A machine profile is used with the `machine` directive in `build.conf`. For example:
```
machine myPC
```
It’s supposed to satisfy firmware, kernel module and X.org driver dependencies for a particular hardware platform in one go. You can have several machines defined in `build.conf` to create a boot image that runs on multiple types of hardware.
The `machine` directive abstracts `firmware`, `module` and even `package` directives. It complements `module`, `package` and `param` directives.
## How do I create a new machine profile?
**Short summary:** Create a “fat” boot image, boot it and note which kernel modules were loaded.
1. Uncomment (or add) `package extensions` and `package extensions-x` in `build.conf`, as well as any potential X.org targets (`package xorg7-*`) that may be used by a platform.
2. Build using the command `./build --allmodules`. This generates a rather big image (> 200 MiB) with everything driverwise.
3. [[Boot|Deployment]] the client with this image (see note below if you have problems) and run `/bin/hwlister.sh`. This will generate one, two or three files:
- `module.list` (always),
- `vbe_modes.list` (probably) and
- `firmware.list` (maybe).
4. If you are running a TFTP server with writable root, they’ll automatically get uploaded. Otherwise they’ll be in `/` on the ThinStation client and you’ll have to transfer them manually by a USB stick or network.
5. On your build computer, go to the `thinstation/build/machine` directory, create a new subdirectory (e.g. `myPC`) and put the above files there.
6. If you want to include a certain X.org driver in your machine profile, you have to create a `package.list` file containing the appropriate `package` line in your new machine profile directory (see 5.).
You probably will want to edit `build.conf` and deactivate `package extensions` afterwards. Remember to omit `--allmodules` on your next build.
## Special case: Systems with less than 512 MiB of RAM
Since the above image includes X it requires your thin client to have at least 512 MiB of RAM. If your thin clients have less RAM (but at least 128 MiB) you can still use an image *without* X. Replace step 1 from above with:
cd /build
cp conf/hwlister/* .
Be aware of the fact that some kernel modules necessary for running X (e.g. `i915` for Intel graphics devices) will not be loaded if X is not currently running (like in this case). So if you create a machine profile in text only mode you will have to add such modules to the newly created machine profile manually. Otherwise you will not be able to run X properly with this profile. Use this method at your own risk!
## Advanced usage
If you create a directory `etc` in your machine profile directory and put arbitrary files in it, these files will be copied into the initial ramdisk under `/etc`. This mechanism can be used as a shortcut for configuration so that you don’t have to create a new package just for a few config files in `/etc`. See machine profile `NT-A3500` for an example.

52
Making-bootable-media-on-Windows.md Normal file

@ -0,0 +1,52 @@
## You can use the [Rufus][] utility by Pete Batard
[Rufus]: https://rufus.ie
### Please note that due to artificial restrictions in the official release of Rufus, you must use the modified version that is downloaded during install.
Before running build in the development environment, make sure the rufus port is installed with the following command.
`prt-get install rufus`
Afterwards, any efi iso will include the utility with your build. On a windows machine you can run the utility to convert an ISO to a bootable thumb drive.
Once the ISO has been transfered to a Windows machine, Double click the iso, and Windows will automatically mount it as a virtual CD-ROM drive.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r1.png)
Select the new CD-ROM drive on the left, and you should see it's contents on the right.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r2.png)
Double click the rufus folder
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r3.png)
Double click the portable rufus utility executable.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r4.png)
Rufus will only show removable media on your system. If you don't see anything at this point, please insert your media.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r5.png)
Confirm that the media you want to make bootable is selected, or use the drop down to browse for the correct drive.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r6.png)
Click `SELECT` to browse for the ISO we mounted earlier
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r7.png)
Browse for the ISO, and select it.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r8.png)
Confirm the settings circled in blue, then click `START`
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r10.png)
The ISO can be written in either mode, but ISO image mode is recommended, click `OK`
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r11.png)
Confirm the destruction of the drive contents by clicking `OK`
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r12.png)
You can monitor the progress, but Rufus should be quick with any modern removable drive.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r13.png)
# Considerations for Fastboot
If you are using fastboot, you will need to make sure you put a mount definition in for a removable drive. Before making your build, make sure you have a line like the following in your thinstation.conf.buildtime. It doesn't need to be zero, but that is the safest.
MOUNT_0="LABEL=THINSTATION /boot auto x-mount.mkdir,defaults 0 0"
Notice that even though Rufus displays the Volume Label it is going to write as `ThinStation` and afterwards displays `ThinStation` as the Volume Label of the new drive, Windows uses all capitals in it's display. This is important, because Linux will also reference the drive by all capitals.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/r14.png)

324
News-and-History.md Normal file

@ -0,0 +1,324 @@
## News
### Dec 2019
**ThinStation 6.2.3 released**
This should be a stable base for 64 bit systems.
### Jun 2016
**ThinStation 5.5 released**
### 4 August 2014
**ThinStation 5.2.3 released**
As usual you get it from here:
[<http://sourceforge.net/projects/thinstation/files/thinstation/thinstation-5/>](http://sourceforge.net/projects/thinstation/files/thinstation/thinstation-5/)
or from git.
## History
### 6 May 2012
**ThinStation 5.1 released**
Donald Cupp Jr has been busy and has ironed out kinks and polishing the
beautiful vehicle ThinStation, and he proudly presents ThinStation-5.1.
### 10 February 2012
**ThinStation 5.0 released**
After about a year of development ThinStation 5.0 - the successor to
ThinStation 2.2.2 - has been released today. During its development
program ThinStation 5.0 has been known as version 2.5, but as the entire
code base is new, the developers wanted to part from the 2.x series
branding. So we decided to stick to the the "5" in "2.5" and here is
version 5.0.
ThinStation 5.0 is based on Crux Linux 2.7 code, but the user front end
is very much the same as previously, i.e. it still uses build.conf and
thinstation.conf\*. There are of course some new things to learn (2.2.x
is more than five years old) but the soul and spirit is all the same.
However, this is new times and there are new requirements: A simple
build requires 64 MB RAM and an i686 class processor is required. This
is 16 year old technology, any CPU post 2003 works and almost any post
1996 does.
For package developers ThinStation 5.0 is great news. It is so easy now
to add own packages or modify existing ones thanks to the standardized
Crux code base.
The number of packages updated are \*way\* to extensive to mention, but
on most bases we have 2011/2012 versions of everything, including Linux
kernel 3.2 and xorg7.
So, have fun and enjoy **ThinStation 5.0**.
The ThinStation crew.
### 11 January 2012
The TS-2.2.2 series has served us well since late 2008 and now it is
time for the final minor revision, TS-2.2.2i. The future belongs to
TS-2.5 which is well into its RC-series by now.
### 18 October, 2011
Now we are at beta4 and "soon" there will some RCs. So it's **now** we
need feedback. The build procedure in TS-2.5 is slightly different from
TS-2.2.2 series.
### 28 September, 2011
Exciting news! **ThinStation-2-5 beta1** is out. It's a complete rewrite
of TS but still true to the TS core values and most administrating parts
are the same. A new thing is that you get the source together with the
distro, so it's a 390 MB download (the final version will be the distro
only and the source optionally). Unpack the bz2 file, run
./setup-chroot. Actually you have to run ./setup-chroot twice, but you
are instructed. Next go to ts/2.5 and things will look more or less
familiar.
Have fun and supply feedback! Feedback is very important.
### 28 June, 2011
**ThinStation 2.2.2h** has been released. A minor bugfix release of the
2.2.2 series.
Among the highligths: rdesktop 1.7.0 and Firefox 5.0.
### 10 May, 2011
LiveCD versions of **ThinStation 2.2.2g** available now.
### 3 March, 2011
**ThinStation 2.2.2g** has been released. As you can guess from the
version number, it's minor maintenance release where updated RDP clients
(SVN version of rdesktop and FreeRDP 0.8.2) is the highlight:
### 7 November, 2010
**ThinStation 2.2.2f** has been released. Well, the release of
ThinStation-2.2.2e triggered an interesting sequence of contributions
that we have found so interesting, that we kill off 2.2.2e and release
2.2.2f.
Most important is that now the keyboard is fully working with
international keyboards and FreeRDP! That's worth a release by itself.
But also other important fixes and updates are included: snd-hda-intel
seems to work for the first time, a bug for z-org6-intel ironed out,
Windows codepage 1252 added for ICA etc.
### 1 November, 2010
**ThinStation 2.2.2e** has been released. As you may guess from the
version number this is only a small update and bug fix release. Nothing
major. But as for any star a face lift is needed once in a while :-)
### 16 August, 2010
New VMware LiveCDs based on ThinStation-2.2.2d and **Open View
4.5.0b2.1** available as torrents on the usual page:
[<http://thinstation.org/LiveCD/>](http://thinstation.org/LiveCD/)
### 11 April, 2010
**ThinStation-2.2.2d** has been released. A few bugs has been ironed out
and a few minor features added.
### 2 March, 2010
**ThinStation-2.2.2b** has been released. Version 2.2.2b is a
maintenance release of 2.2.2, which means it is ver. 2.2.2 plus patches
and bug fixes. Besides this a few additions have been made mainly to
cosmetics.*' Update:*' A glitch has bumbed the version to 2.2.2c.
### 19 January, 2010
A **New Canadian TS-O-Matic site** has become alive thanks to
redeemer.ca. Now the TS-O-Matic build farm consists of:
- [Denmark](http://thinstation.org/TSoM/)
- [Canada](http://tsom.redeemer.ca/)
- [Germany](http://tsom.paepke.net/)
- [Netherlands](http://tsom.gelix.org/)
- [Russia](http://www.it-advisor.ru/TSoM/)
- [United Kingdom](http://tsomatic.agarwal-associates.com/)
TS-O-Matic is the unique ThinStation way of making a custom binary image
of ThinStation without having a Linux installation yourself.
### 11 May, 2009
**Francis Souyri** has put together a package for Firefox 3 under
ThinStation 2.2x (& 2.3).
It includes updates to a number of packages and libraries and is bundled
as one package. Individual packages for GTK-2.0, atk, cairo, pango &
pixman will also be made available.
### 24 March, 2009
Well, we have been doing things, but not putting much here.....
Those who have been watching the lists will know that
[2.4alpha1](thinstation:v2.4 "wikilink") has been released with major
upgrades to the platform, but it's still got a long way to go. So come
along and help...
Updating the wiki is progressing and I'm adding some of the longtime
missing developer documentation. We could really do with some help on
defining 'Usage Scenarios' and the associated working configurations
(see the [Configuration Examples pages](Conf_Example "wikilink")).
### 28 October,2008
We have finally put the ThinStation WIKI back up.
There are still quite a few items missing, but we have a number of older
documents available and will extract anything of use that we can.
In the meantime, feel free to populate the Community Portal with
anything you think is useful to other ThinStation users. (I haven't
worked out how to allow anonymous updates yet, so you probably need to
have a sourceforge login and ask to be given edit permissions......)
We have lost a bit of the news as well.....
![](Example.jpg "fig:Example.jpg")
### 13-Oct-2007
**Marcos Amorim** has produced an [snmp client
package](http://downloads.sourceforge.net/thinstation/snmp_TS2.x.tar.gz)
for ThinStation. It's available from the sourceforge download site under
ThinStation packages contrib for ThinStation 2.2 (but also works for
2.2.1).
### 3-Oct-2007
A note from **Technical gs** to the developers list that we thought we'd
like to share with you... DEAR DEVELOPERS AND ALL THE CONTRIBUTORY TO
THIN STATION...... ITS ABOUT TWO YEARS SINCE OUR SCHOOL NETWORK IS
RUNNING ON THIN CLIENT TECHNOLOGY BY THINSTATION CONSISTING OF ABOUT 150
TERMINALS. ITS LINUX PLATFORM - UBUNTU LINUX SERVER ON SERVER SIDE -
WORKING ALL 24 HOURS \* 365 DAYS. ON BEHALF OF ALL STUDENTS, TEACHERS I
CONGRATULATE EVERYONE FOR THEIR SUCCESSFUL EFFORTS WITHOUT WHICH OUR
SCHOOL COULD NOT HAVE GIVEN THE VITAL IT EDUCATION ( ITS FREE OF CHARGE
) TO ALL THE STUDENTS. AS A IMPLEMENTOR OF THINSTATION, I ALSO HAVE NOT
CHARGED ANYTHING. LONG LIVE THINSTATION.
### 23-Sep-2007
Firefox 2.0.0.6 is now available for ThinStation as a contributed
package for the 2.2 series. Just look in thinstation package contribs \>
thinstation packages 2.2 on the sourceforge download site.
### 5-Sep-2007
Sick and tired of the original OS in **IGEL Winestra 416** thin clients?
Well, here is [how to change it to
ThinStation](http://lkenhagen.de/projekt_igel) (In German).
Oh, you want to run ThinStation on your **Netvista**. [No
problem](http://www.eazytek.com/netvista/thinstation.php) (In English).
### 23-Aug-2007
The Swedish IDG magazine
[Techworld](http://techworld.idg.se/2.2524/1.111171) recently had a
review of ThinStation (in Swedish). They were fairly happy about
ThinStation and thought TS-O-Matic was "almost painfully simple", if my
Swedish understanding is correct ;-) Final rating: PRO: "Easy
installation, great flexibility". CON: "Nothing in particular".
### 18-Aug-2007
The poll "Which SESSION\_0 type is most important for you? " is closed.
See the [results](http://thinstation.net/poll/poll-august2007.xhtml).
### 3-Jun-2007
The TS-O-Matics now speak French and Portuguese too.
### 15-Apr-2007
ThinStation has gotten an IRC channel. Come visit us at
***\#thinstation*** on **irc.freenode.net**. Please character encode
into iso-8859-15. As this is a new service, don't expect a lot of trafic
- before you create it yourself! :-)
### 7-Feb-2007
The highly regarded German computer magazine **C't** has a very
comprehensive presentation of ThinStation in its third issue 2007, page
202. It's four full, ad-free pages in color, and a very careful
walk-through on setting up ThinStation.
### 6-Dec-2006
More contribs! This time **Patrick Rock** has contributed the **elinks**
text web browser for both ThinStation 2.1.3 and ThinStation 2.2. Get it
from the download page.
### 2-Dec-2006
A little something to make time until Christmas pass... **Mike** has
contributed **conky**, a system and performance monitor for ThinStation
2.2. Not very useful, but nice to look at. A picture says more than a
1000 words, so look for yourself:
[image](http://thinstation.sf.net/images/conky.jpg)
### 4-Nov-2006
**Ludo Kleinholte** has written a new document on [Building ThinStation
under coLinux on your Windows
box](http://thinstation.sourceforge.net/Thinstation_and_CoLinux.pdf).
### 3-Nov-2006
The prebuilts of ThinStation ver. 2.2 are here. A LiveCD and and a
netboot prebuilt is ready for your download pleasure (see the download
section). Thanks to Paolo for the effort!
### 19-Oct-2006
New TS-O-Matic mirror: **Gerrie Brokke**, The Netherlands, has opened a
new TS-O-Matic mirror for the pleasure for all of you. Go visit it at
[<http://tsom.retail-ict.nl/>](http://tsom.retail-ict.nl/). We could
still use a mirror in Asia and in North America...
### 17-Oct-2006
Our sponsor 2X has good news again:
Up until now, investing in an application publishing solution such as
Citrix was too costly for most companies. The release of 2X
ApplicationServer v.4 is set to change this by providing a Citrix
alternative at a fraction of the price.
2X ApplicationServer v.4, allows seamless publishing of Windows
applications on remote desktops, significantly reducing administration
overheads and security risks. The new version adds integrated load
balancing, Linux & Mac client support, support for server farms, SSL
tunneling and more.// Read more about ApplicationServer on [2X's home
page](http://www.2x.com/applicationserver/). Naturally ThinStation 2.2
has a 2X client as we support any major application!
### 16-Oct-2006
*YAHOOO! Hold your horses. ThinStation 2.2 is here!*
Finally, ThinStation 2.2 was released today. It took a while since ver.
2.1.3 as Miles decided (actually his wife did ;-) to get a baby in the
middle of the process! Now the second baby is here: Linux kernel
2.6.16.5 (the kernel of the real, first baby is custom), X.org 6.9.0,
Firefox 1.5, ICA client ver. 9, rdesktop client ver. 1.5, unionFS,
NoMachine NX client, Cendio Thinlinc client, 2X ApplicationServer
client, USB support, client side sound, printing, storage... the lot!
Grap it on the download page. Expect the TS-O-Matics to catch up during
the week. [Original
announcement](http://sourceforge.net/mailarchive/forum.php?thread_id=30757497&forum_id=43674).

156
Packaging.md Normal file

@ -0,0 +1,156 @@
## Motivation
Let’s assume you want to include a new application or a set of special configuration files into ThinStation. For this purpose it is better to create a new package than patching an existing one (already included in ThinStation).
Your newly created package – let’s call it `mypackage` – can be used like an existing one: Simply insert
package mypackage
into `build.conf`.
**For the impatient:** There is a package called `template` serving as a template for creating your own packages.
## What is a package?
Technically speaking, a package is a subdirectory of `/build/packages` containing a set of files and directories.
- `dependencies` file containing a list of other required packages **Required**
- `.dna` file containing meta data relationships to Ports System **Required**
- `build/conf` for ThinStation build configuration examples,
- `build/finalize` to perform package specific shell commands that will be applied towards the end of build,
- `build/pip3.freeze` to download and install python packages,
- `bin` for all standard executables and symlinks,
- `sbin` for secure executables and symlinks,
- `etc` for your application’s global configuration,
- `etc/cmd` for session or menu startup scripts,
- `etc/init.d` for initialization scripts,
- `etc/systemd/system` for a service file that starts the later,
- `etc/systemd/system/multi-user.target.wants` for a symlink to the service file,
- `lib` for library files,
- `lib/menu` for menu entries,
- `lib/icons/hicolor/scalable/apps` for scalable svg icons.
To see where to put your new files read on.
## Dependencies
In the root of your package directory `/build/packages/<mypackage>`, should be a file called `dependencies`. This file should always exist even if empty, but I'm sure you will at least depend on `base`. You should also define any other packages you depend on, one per line.
## Compiling
If you need to compile your application please refer to [`README.md`](https://github.com/Thinstation/thinstation/blob/master/README.md) and [[Ports and Packages|Ports and Packages]].
## Configuration - Optional
If you need to add new configuration variables for your package, please add a file `build/conf/99mypackage`. Define the variables in it and comment them verbosely.
This file will be part of the `thinstation.conf.sample` file. Replace 99 with a lower number if you want your variables to appear earlier in `thinstation.conf.sample`.
## Finalize - Optional
If you need specific shell commands to run during the build process as opposed to during boot, you can add a finalize file `build/finalize` with a header like `##mypackage 78` and then add shell commands to make specific changes to the filesystem during build. The number at the end is a metric that tries to order the finalize scripts.
## Python - Optional
We don't include any package managers in the final build image, that includes pip. However, during build we can call pip within build and feed it a freeze file `build/pip3.freeze` and it will install those packages into the image. The format is the same as the output of `pip freeze` would produce. You can remove the version numbers if you want pip to always grab the latest version, or leave them in to make sure a specific version is installed.
## Initialization - Optional
This can generate configuration files for a service or application based on variables in the conf files. To initialize your package (e.g. a service) at boot time you have to put a shell script in `etc/init.d` that is named exactly as your package plus a `.init` suffix, for our example we use `mypackage.init`. You can use any variables defined in `thinstation.conf.*` files in this script.
Example:
```shell
#! /bin/sh
. `dirname $0`/common
case "$1" in
init)
# run during boot (if started by systemd)
if ! pkg_initialized $PACKAGE; then
# Your startup instructions go here
pkg_set_init_flag $PACKAGE
fi
;;
console)
;;
window)
;;
fullscreen)
;;
help)
echo "Usage: $0 init"
;;
*)
exit 1
;;
esac
exit 0
```
Your script needs to be started with a systemd unit file placed in `etc/systemd/system`
Example: mypackage.service
```
[Unit]
Description=ThinStation mypackage
After=profile-setup.service pkg.service
Before=display-manager.service
ConditionPathIsReadWrite=/etc
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/thinstation.env
ExecStart=/etc/init.d/mypackage.init init
SyslogIdentifier=mypackage
[Install]
WantedBy=multi-user.target
```
Finally, create a symlink to the service file in `etc/systemd/system/multi-user.target.wants/` like
ln -sf ../mypackage.service etc/systemd/system/multi-user.target.wants/mypackage.service
If you don’t need to do any *special* initialization for your application, and you plan to launch your application as a session or a menu entry, just create a symlink to `/etc/thinstation.packages` (for GUI applications) or `/etc/thinstation.console` (for textmode applications) like this:
cd mypackage/etc/init.d
ln -s /etc/thinstation.packages mypackage # or alternatively
ln -s /etc/thinstation.console mypackage
## Startup
If you use a symlink for initialization (see previous section) then it is necessary to define the exact command for starting your application. This is done in form of shell variable definitions. There can be several files in `etc/cmd`:
- `mypackage.global` This is the *default* file if no others are supplied and is **always required**.
CMD_GLOBAL="application"
- `mypackage.console` (Optional) Define how to start your application from the console.
- `mypackage.fullscreen` (Optional) Define how to start your application fullscreen.
CMD_FULLSCREEN="application --FULLSCREEN"
- `mypackage.window` (Optional) Define how to start your application in an ordinary window.
CMD_WINDOW="application"
## Console (text mode) applications
If your application runs in text mode, then you should create an empty file in `etc/console`:
touch etc/console/mypackage
## Libraries
go into `lib`.
## Menu entries
for Openbox, IceWM and XFWM menu entries can be defined in the file `lib/menu/mypackage` like this:
package="mypackage"; needs="x11"; title="Example application"; command="pkg window mypackage"
package="mypackage"; needs="x11"; title="Example application (fullscreen)"; command="pkg fullscreen mypackage"
That will go through the various thinstation functions and run commands that you have defined in /etc/cmd/mypackage.* files.
For simple menu entries, you can just call the command directly without `pkg window` or `pkg fullscreen` but they must be valid executables in the path.
## Icons
If you have an icon that you want displayed in menus, it should be an svg file, and placed at mypackage/lib/icons/hicolor/scalable/apps/mypackage.svg.
You can then run `icon-gen mypackage`, and any pixmaps should get placed as well.

93
Persistence.md Normal file

@ -0,0 +1,93 @@
#### Persistent Files and Mount Points
Version 7.0 introduces a new **persistent-files** service, enhancing how configurations and data persist across boots. This addition requires a dedicated mount point for `/var/prstnt`, alongside traditional mount points such as `/boot` and `/home`. Below, we outline the differences between earlier versions and 7.0, and provide clear instructions for setting up persistent storage.
---
### Differences Between Versions
#### Prior to Version 7.0:
- **Mount Points**:
- The typical setup included mount points for `/boot` and `/home`.
- These mount points functioned as expected, but there was no service to specifically manage persistence for individual files.
- **Persistence**:
- Files persisted implicitly based on the contents of the `/home` directory or other user-defined partitions.
#### New in Version 7.0:
- **Persistent-Files Service**:
- Introduces fine-grained control over file persistence. Specific files must be explicitly listed in configuration files under `/etc/persistent-files.d/`.
- Files not explicitly listed are not retained across boots, even if they reside in `/var/prstnt` or other monitored directories.
- **New Mount Point for `/var/prstnt`**:
- A dedicated EXT4 partition mounted at `/var/prstnt` is required to store persistent files managed by the `persistent-files` service.
- Existing mount points for `/boot` and `/home` remain unchanged.
---
### Step 1: Setting up Mount Points
To configure the required mount points, update your `thinstation.conf.buildtime` file as follows:
```bash
MOUNT_0="LABEL=boot /boot auto x-mount.mkdir,defaults 0 0"
MOUNT_1="LABEL=home /home auto x-mount.mkdir,defaults 0 0"
MOUNT_2="LABEL=prstnt /var/prstnt auto x-mount.mkdir,defaults 0 0"
```
- **Explanation**:
- `LABEL=boot`: For the boot partition (FAT32). Needed if booting from flash or hd
- `LABEL=home`: For the home partition (EXT4). Needed if you want user settings to persist
- `LABEL=prstnt`: A new EXT4 partition dedicated to the persistent-files service.
#### Partitioning the Drive
- Example, create three partitions:
1. **FAT32** labeled `boot`.
2. **EXT4** labeled `home`.
3. **EXT4** labeled `prstnt`.
- The `/ts/bin/flash` script can automate this process if the drive is installed in the build system.
---
### Step 2: Configuring the Persistent-Files Service
1. **File-Based Persistence**:
- The `persistent-files` service requires explicit definitions of files to persist.
- Create configuration files under `/build/packages/mypackage/etc/persistent-files.d/`, naming them descriptively (e.g., `mypackage.conf`).
Example: `/build/packages/mypackage/etc/persistent-files.d/mypackage.conf`
```plaintext
/etc/myapp/config.ini
```
2. **Granular File Control**:
- Persistence is determined by file paths listed in the configuration files.
- Directory monitoring does not persist all contents by default; only the explicitly listed files will persist.
3. **Verify Setup**:
- After setup, ensure `/var/prstnt` is mounted and files specified in `/etc/persistent-files.d/` persist across reboots.
---
### Step 3: Testing the Configuration
1. **Mount Points**:
- Confirm `/var/prstnt`, `/boot`, and `/home` are correctly mounted using the `mount` command or inspecting `/etc/fstab`.
2. **File Persistence**:
- Reboot the system and verify that only the files listed in `/etc/persistent-files.d/` are retained across boots.
---
### Notes and Recommendations
- **Backward Compatibility**:
- For systems upgraded from earlier versions, ensure that a `/var/prstnt` partition is created and configured.
- Without this mount point, the `persistent-files` service will not function correctly in version 7.0.
- **Advanced Mount Points**:
- Additional partitions can be defined using the same syntax in `thinstation.conf.buildtime`.
- **Legacy Behavior**:
- Mount points like `/boot` and `/home` still operate as they did in prior versions, but persistence for specific files now depends on the `persistent-files` service.
With these instructions, you can seamlessly transition from earlier versions to 7.0 while taking advantage of the enhanced persistent file management system.

24
Ports-and-Packages.md Normal file

@ -0,0 +1,24 @@
## Ports
<p>A normal Linux distribution tries to only expose the user to one package management system. Ubuntu provides apt, Redhat rpm, Fedora dnf. These help to modularize the distribution into something that is universally manageable by *any user. Under the covers, there are still several package managers that must be satisfied, jpm - perl - python - ruby - etc.</p>
<p>In the ThinStation world, we are generating static images of file systems, and may need to work with two distinct package formats. The first one is a port. It behaves a lot like a typical desktop package, plus it handles source compilation, a feature greatly needed when going embedded. There is a central database, so you can track files, query dependencies, add and remove the package from the active filesystem. You can update the package and test the changes on an active, persistent filesystem.</p>
<p>We do not remain on the tip of any other disto. For better or worse, we are forked. The only versions of any packages, are the ones in the ThinStation git repo. You can update the version number and (fingers crossed)rebuild the port on your own, or bribe me to do it.</p>
<p>When updating or adding new ports, you should try and make them as complete as possible. Include all the help, the examples, the configuration and init files you can find. They will be a good reference later, when we need to go thin; and compiling can take a while, so the less times we do that, the better. You should *not attempt to break a port into pieces like samba, and samba-devel. That paradigm is an over-complication required decades ago when computers where slow and space was pricey. Most projects do not lend themselves to such formatting, it increases development time, takes longer to compile, drops valuable reference material, reduces access to newcomers...yada, yada, yada, bad plan.
Here are some good links to research ports.
The package management utilities.
[https://crux.nu/Wiki/FaqPkgUtils](https://crux.nu/Wiki/FaqPkgUtils)
You can search the crux port database here.
[https://crux.nu/portdb](https://crux.nu/portdb)
The Archlinux ports system is also an excellent reference, but they have different goals and values.
[https://www.archlinux.org](https://www.archlinux.org)</p>
## Packages
<p>The next phase is actually called a package, but it does not behave like a typical package. Here the goal is different. We want to reduce a regular port down to it's bare functional essentials for a purpose. No help, no includes, no examples and drop anything not essential to the task for which the package was made. Convert as much of the init process into static files as possible. Drop any files or functions that will attempt to change the filesystem after we have rendered it. Even the package manager itself must not be present in the final product.</p>
<p>Perhaps one of the more challenging parts to understand is the relationship between these two formats, and how to use them to extend the ThinStation environment.</p>
A good starting place is to run `mkrepackge <port>`, and most of the common tasks will be scripted for you and a package will be created at `/build/packages/<port>`. It will create among other things, a file called `install` at `/build/packages/<port>/build/install`. This can be customized to further reduce unnecessary files for your desired task.

76
Printer-configuration.md Normal file

@ -0,0 +1,76 @@
This page describes how to add printers:
- option A: custom package (network printer)
- option B: config on boot (network printer, usb printer and lpt)
### Prerequisites (option A and B)
***
- required `build.conf` packages
- `package lprng`
- `package hpijs`
- `package cups`
- `package ghostscript`
- FileDevice Yes in cupsd.conf (only option B, by default in thinstation included)
### Configuration option A (custom package)
***
1. Create a [custom package](https://github.com/Thinstation/thinstation/wiki/Creating-a-Custom-Package). The only files needed are `etc/init.d/your_start_up_script` and the corresponding systemd service file.
1. Change the name of `your_start_up_script` to something appropriate (`printers`?).
1. Add the following line to the `init)` case:
lpadmin -p "<printer_name>" -v socket://<printer_ip> -m <printer_driver> -L "<printer_location>" -E
**\<printer_name\>**
- What do you want to call your printer?
**\<printer_ip\>**
- The IP address your printer resides at. If you include `package terminal` in `build.conf`, you can see what devices are available on the client by running the following in the terminal: `lpinfo -v`
**\<printer_driver\>**
- The print driver to install with the printer. If you include `package terminal` in `build.conf`, you can view available drivers for your printer on the client by running the following in the terminal: `lpinfo --make-and-model '<printer_make_and_model>' -m`, where \<printer_make_and_model\> is something like "LaserJet 4240". This will print a list of drivers like the following:
$ lpinfo --make-and-model "LaserJet 4240" -m
gutenprint.5.2://hp-lj_4240/expert HP LaserJet 4240 - CUPS+Gutenprint v5.2.9
foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/HP-LaserJet_4240-Postscript.ppd HP LaserJet 4240 Foomatic/Postscript
drv:///hpcups.drv/hp-laserjet_4240-pcl3.ppd HP LaserJet 4240 pcl3, hpcups 3.13.9
postscript-hp:0/ppd/hplip/HP/hp-laserjet_4240-ps.ppd HP LaserJet 4240 Postscript (recommended)
postscript-hp:1/ppd/hplip/HP/hp-laserjet_4240-ps.ppd HP LaserJet 4240 Postscript (recommended)
The driver is the portion of the line before the first space. E.g. `gutenprint.5.2://hp-lj_4240/expert` or `postscript-hp:0/ppd/hplip/HP/hp-laserjet_4240-ps.ppd`.
**\<printer_location\>**
- Where is the printer located?
####Notes
- If you include `package terminal` in `build.conf`, you can test the lpadmin command prior to adding it to your config file by running the command in the terminal on the thinstation client.
- This is not the only way to add a network printer. Another possible method includes (on the thinstation client) adding a printer using the CUPS GUI (<http://localhost:631>) and creating a package from `/etc/cups`. This method does not require boot-time conf files.
### Configuration option B (config on boot)
***
1. Only define in thinstation.conf.buildtime or any config group:
##### Example network printer
- CUPS_PRINTER_0_NAME="sample_network_printer_0"
- CUPS_PRINTER_0_DEVICEURI="socket://ip_address"
- CUPS_PRINTER_0_DRIVER="drv:///sample.drv/generpcl.ppd"
##### Example usb printer
- CUPS_PRINTER_1_NAME="sample_usb_printer_1"
- CUPS_PRINTER_1_DEVICEURI="file:///dev/usb/lp0"
- CUPS_PRINTER_1_DRIVER="drv:///sample.drv/generpcl.ppd"
##### Example lpt printer
- CUPS_PRINTER_2_NAME="sample_lpt_printer_2"
- CUPS_PRINTER_2_DEVICEURI="file:///dev/lp0"
- CUPS_PRINTER_2_DRIVER="drv:///sample.drv/generpcl.ppd"
Driver used "drv:///sample.drv/generpcl.ppd" is a generic pcl driver useful for laser printers, it can be modified with any other driver.

35
Secureboot.md Normal file

@ -0,0 +1,35 @@
## ThinStation supports booting via EFI, and SecureBoot
In the event that you are booting on a secureboot system, it may be necessary for you to enroll some of the components of ThinStation into your systems security catalog. This is a fairly easy process and it looks much like the following screens. You may want to print out https://www.thinstation.us for reference when going through this process.
The first screen should come up by default when booting ThinStation on a Secureboot system for the first time. Select `"OK"`, and press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/1.png)
This screen will timeout, so it's important to hit any key before it does. Press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/2.png)
Now we want to start the key enrollment process. Select `"Enroll key from disk"` and then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/3.png)
Depending on your machine,`"EFI"` may already be selected. If it is not present, also look for `"THINSTATION"`, then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/4.png)
Select the `"ThinStation-SB-UEFI-CA.cer"` certificate, then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/5.png)
We want to verify the key, so select `"View key 0"`, then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/6.png)
It's important to make sure you have recovered the fingerprint for the certificate over a secure connection. After confirming the locked status for the www.thinstation.us site, and after a visual verification that the `[Fingerprint]` is the same between the one shown on-screen and the one you recovered from thinstation.us, press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/7.png)
Select `"Continue"`, then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/8.png)
If everything is correct, and the key was successfully verified by you, select `"Yes"` and then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/9.png)
Finally, select `"Reboot"` and then press the `Enter` key.
![](https://raw.githubusercontent.com/wiki/Thinstation/thinstation/10.png)
That's it. The system should boot ThinStation without issue.

163
Smart-Cards.md Normal file

@ -0,0 +1,163 @@
### Gemalto Smartcards
A brief guide to get smart cards working with thinstation running rdesktop
connected to a microsoft terminal server. It is theoretically possible to get
ThinStation working with a variety of cards and readers.
This guide focuses only on the following:
gemalto v2 .net smartcards:\
gemalto .net smart cards run a streamlined version of the .net framework
and provide seamless integration with microsoft operating systems.\
<http://tinyurl.com/26o6htc>
gemalto pc twin usb smart card reader:\
simple usb smart card reader.\
<http://tinyurl.com/33qjsyg>
you will need:\
\* a microsoft terminal server
- an active directory domain controller
- a linux box with a build environment
- any test computer
- a gemalto pc twin usb smart card reader
- a gemalto .net smartcard
#### step 1:
first, get a working smart card environment set up. make sure you can
log on locally to a machine with your smart card and reader, and also
make sure you can connect and logon to a terminal server with the smart
card over rdp.
the following links should help:\
you will need to install the following update on xp or 2003 machines to
enable logon via gemalto .net smartcard: <http://tinyurl.com/yhdwrzc>
the windows machine that the smart card reader is plugged in to should
be able to find the drivers automatically, but just in case they can be
found here: <http://support.gemalto.com/?id=46>
the gemalto documentation detailing the set up required to enable smart
card logon to active directory, as well as installing certificates
(users) on the cards themselves: <http://tinyurl.com/2fpyuwn>
#### step 2:
once you have a working smart card setup, download and setup thinstation. it is a good idea to familiarize yourself with the thinstation documentation to assist in later steps. use the latest version.
There are also multiple ways you can boot into thinstation, this guide should work for all of them. for reference,
I use the pxe boot method, as no media is required to boot a machine into thinstation. Verify that you can boot a client machine into thinstation and connect to a terminal server using rdesktop.
#### step 3:
the gemalto pc twin usb smart card reader uses the linux ccid drivers.
connections to the readers and driver management is provided by the pcsc
lite resource manager daemon, or pcscd. both of these are available
packages in a thinstation os, but ccid needs to be configured for a
particular reader before thinstation is compiled, and the pcscd package
has a bug that also requires some configuration before the thinstation
image is compiled. luckily though, there is a fix for the pcscd package
written by phuong83@hotmail.com on the sourceforge thinstation
development email list. so, we need to download the thinstation source,
patch the pcscd package, configure the ccid package to work with the
gemalto pc twin usb smart card reader, and then compile the boot images.
**3a:**\
Set up a linux machine with a current build environment. DevStation is excellent for this, but you can use any distro you want.
**3c:**\
download patched version of pcscd and update thinstation source:
`wget `[`http://dl.dropbox.com/u/2334614/pcscd.tar.bz2`](http://dl.dropbox.com/u/2334614/pcscd.tar.bz2)\
`mkdir pcscd`\
`mv pcscd.tar.bz2 pcscd`\
`cd pcscd`\
`tar xfj pcscd.tar.bz2`\
`cd ..`\
`mv Thinstation-2.2.2d/packages/pcscd/ ./oldpcscd`\
`mv pcscd/ Thinstation-2.2.2d/packages/`
**3d:**\
in order to edit the ccid configuration to work with the gemalto pc twin
usb smart card reader, we need the vendor id and the product id of the
reader. these can be found here:\
<http://pcsclite.alioth.debian.org/readers/GemPCTwin.txt> \>br\> the
vendor id is 0x08E6 and the product id is 0x3437. now, edit the file\
Thinstation-2.2.2d/packages/ccidreader/usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
and change the following lines:
<string>`TARGET.VERSION`</string>\
`TO`\
<string>`libccid.so.1.0.1`</string>\
\
<key>`ifdVendorID`</key>\
<array>\
`   MAGIC_VENDOR`\
</array>\
`TO`\
<key>`ifdVendorID`</key>\
<string>`0x08E6`</string>\
\
<key>`ifdProductID`</key>\
<array>\
`   MAGIC_PRODUCT`\
</array>\
`TO`\
<key>`ifdProductID`</key>\
<string>`0x3437`</string>\
\
<key>`ifdFriendlyName`</key>\
<array>\
`   MAGIC_FRIENDLYNAME`\
</array>\
`TO`\
<key>`ifdFriendlyName`</key>\
<string>`gemalto pc twin usb smart card reader`</string>
**3e:**\
following the thinstation documentation, edit the
Thinstation-2.2.2d/build.conf file to match your enviornment.\
build the thinstation images:\
cd Thinstation-2.2.2d
`./build`
**3f:**\
if it was a success, copy the necessary boot images from
Thinstation-2.2.2d/boot-images to your thinstation setup. for example, i
boot thinstation via a custom pxe setup, so i copy
Thinstation-2.2.2d/boot-images/pxe/initrd and
Thinstation-2.2.2d/boot-images/pxe/vmlinuz to my tftpdroot directory.
**3g:**\
configure your thinstation.conf.network file with the following (see
thinstation documentation for more info):\
USB\_ENABLED=ON
`PCSCD_USBFIX=ON`\
`PCSCD_CARDREADER_TYPE="USB"`\
`SESSION_0_RDESKTOP_OPTIONS="[WHATEVER RDESKTOP FLAGS YOU NEED] -r scard:'gemalto pc twin usb smart card reader 00 00'='USB Smart Card Reader 0;Gemalto'" `
**3h:**\
make sure your reader is plugged in, then boot into thinstation. verify
that the led on the reader is blinking. after rdesktop loads and you are
at the terminal server logon screen, insert your card. you should see
the led turn solid and the terminal server should prompt for the card
pin.
#### other notes:
if you want an enviornment that supports multiple smart cards, you can
download the ccid package also modified by phuong83@hotmail.com on the
sourceforge thinstation development email list. a link can be here:\
<http://dl.dropbox.com/u/2334614/ccidreader.tar.bz2>
if you are having problems, you can debug by booting in to thinstation
and pressing ctrl-alt-f2, which should bring you to a terminal prompt.
from here you can verify the Info.plist file, debug pcscd, etc. a useful
switch to pcscd is -f, that will force it to run in the foreground and
send all output to stdout.
`` kill `pidof pcscd` ``\
`pcscd -f`

10
Timesync-and-NTP.md Normal file

@ -0,0 +1,10 @@
We recently changed the way NTP (Network Time Protocol) is supported in thinstation. Historically, we were calling an NTP utility (called ntpdate) with a cron job to sync the server time to the network time server, and the server was configured in buildtime.conf.
NTP now has a proper daemon within systemd as “systemd-timesyncd” alongside a new revision in ntpd. The original NTP utility method is still supported, but we added support for both systemd-timesyncd and ntpd in your builds.
If you’re wondering which is worth using:
- systemd-timesyncd is lightweight and simple, and more importantly built into systemd which is included in all images. Therefore you wouldn’t need any new packages, you can just remove NTP from build.conf if your build is using it.
- ntpd has more features and can provide more precision when syncing the clock. If you want to use ntpd, you can add that package instead of NTP to your build.conf.
- If NTP was what you were already using and that works fine for your purposes, you aren’t required to change anything, ThinStation still supports it and everything should still work as it did before.
Additionally, all configurations for NTP in your buildtime.conf will work for ntpd and systemd-timesyncd, so you would only need to change that file if you want to use new options (which you can find in their respective conf files).

99
Update-a-Port.md Normal file

@ -0,0 +1,99 @@
# Update GCC and libstdc++ in the Environment
This documentation guides you through the process of updating GCC (with an example using GCC 12.2). As part of this update, `libstdc++.so.6` will also be updated.
## Prerequisites:
1. **Verify GLIBC Versions**:
```bash
strings /usr/lib/libstdc++.so.6 | grep GLIBC
```
2. **Fresh Environment**: To ensure a smooth process, it's recommended to start with a fresh environment.
## Steps:
1. **Clone the Repository**:
- Clone the Thinstation repository.
```bash
git clone --depth 1 https://github.com/Thinstation/thinstation.git
```
- This creates a folder named `thinstation`.
2. **Initialize Base Environment**:
- Navigate to the cloned directory and run the setup.
```bash
cd thinstation
./setup-chroot
```
3. **Navigate to GCC Port**:
```bash
cd /ts/ports/core/gcc
```
4. **Edit the Pkgfile**:
- Modify the `Pkgfile` to update the GCC and ISL version. Ensure their versions are compatible. Also, verify the download links.
```bash
name=gcc
version=12.2.0
_version=7
_islver=0.24
release=1
_commit=c2103c17
checkdepends=('dejagnu' 'inetutils')
options=('!emptydirs')
source=(ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-${_islver}.tar.bz2
ftp://gcc.gnu.org/pub/gcc/releases/gcc-$_version/$_name-$_version.tar.xz)
```
5. **Modify `pkgmk` Tool**:
```bash
vi /usr/bin/pkgmk
```
- Comment out the line:
```bash
#export LC_ALL=POSIX
```
6. **Set the Locale**:
- This is required to prevent `bsdtar` failures.
```bash
localedef -c -f UTF-8 -i en_US en_US.UTF-8
export LC_ALL=en_US.UTF-8
```
7. **Initiate Package Download**:
```bash
pkgmk -i -d
```
- **Note**: If the MD5 checksum of the downloaded file doesn't match the locally stored one, reset the MD5 checksum using:
```bash
pkgmk -um
```
8. **Build the Package**:
- Start the build process. This might take a few hours.
```bash
pkgmk -i -u
```
- If you encounter an error:
```bash
ERROR: Building '/ts/ports/core/gcc/gcc#12.2.0-1.pkg.tar.xz' failed.
```
- Reset the footprint using:
```bash
pkgmk -uf
```
9. **Reattempt the Build**:
```bash
pkgmk -i -u
```
10. **Compress the Build**:
- For this you need memory, 16GB seems to be minimum
```bash
shrink gcc
```
11. **Completion**:
- At the end of this process, the new GCC version is installed in the build environment. A new port file will also be generated. You can use this file, along with the `Pkgfile`, to set up a new build environment, saving compilation time and bypassing the steps mentioned above.

18
Update-a-package.md Normal file

@ -0,0 +1,18 @@
Example update a thinstation packages, tested with ccid, pcsc-lite, ocinventory, freerdp or rdesktop, and tigervnc
0. ./setup-chroot
1. Update pkfile with new version number and url (if needed), for example /ts/ports/contrib/rdesktop/PkgFile
2. cd /ts/ports/contrib/packagename for example cd /ts/ports/contrib/rdesktop
3. pkgmk -u -d -um
4. pkgmk -u
5. pkgmk -uf
6. pkgmk -u
7. update packagename, for example update rdesktop, or update vncviewer
8. Delete source packages of new version
9. Delete old source related with old version
10. Rebuild thinstation image with new packages versions
11. Test and upload to Thinstation master branch
During update package ccid, is required to use update ccidreader

34
Updating-your-repository.md Normal file

@ -0,0 +1,34 @@
After some time you will certainly want to update your clone of the ThinStation repository to include the latest bugfixes. **Before you start** with this, you should save a copy of your `build.conf` and `thinstation.conf.*` files (or any other files you changed by intention) to a place outside the repository.
It is **highly advisable to [[use Git|Using-Git]] for managing your local changes** (e.g. on config files) instead of copying config files around.
## Staying within the original branch
Let’s assume you want to stay within the [ThinStation branch](https://github.com/Thinstation/thinstation/branches) you initially [[cloned|Getting-Started-with-ThinStation#cloning-the-thinstation-git-repository]].
Then enter these lines:
cd thinstation
./setup-chroot
clean_chroot
exit
git pull
This could take some time, depending on your internet connection and the activity of ThinStation development since your last update. After Git has finished you are free to reenter the chroot environment (`./setup-chroot`), restore your config files and continue development.
## Changing to a newer branch
From time to time, a new [ThinStation branch](https://github.com/Thinstation/thinstation/branches) (e.g. `6.3-Stable`) emerges. If you want to jump to a branch that was not a part of your [[original clone|Getting-Started-with-ThinStation#cloning-the-thinstation-git-repository]], you can use the following commands to do so.
git fetch origin <Branch Name>:<Branch Name>
git branch --set-upstream-to=origin/<Branch Name> <Branch Name>
git checkout <Branch Name>
For example
git fetch origin 5.5-Stable:5.5-Stable
git branch --set-upstream-to=origin/5.5-Stable 5.5-Stable
git checkout 5.5-Stable
You might also need to make sure your working area is compatible with a “factory reset”. Make sure all your changes are backed-up, then nuke your checkout like this.
cd /thinstation
rm -rf *
git checkout -f

126
Using-Git.md Normal file

@ -0,0 +1,126 @@
*Disclaimer: This is not a general Git introdution. Instead this page is geared towards people who only need Git in combination with ThinStation.*
## Introduction
[Git](https://git-scm.com/) is the version control system used to develop ThinStation. It also allows you to switch to a different version of ThinStation with ease.
You can use Git to efficiently “save” your ThinStation [[configuration files|Configuration]]. This gives you the opportunity to return to a known working state if your development is stuck. It also allows you to elegantly migrate your personal configuration to a new version of ThinStation.
## Git related terms and concepts
### Linear development
When you initially cloned ThinStation you created a **“working directory”**. It contains all ThinStation related files and is under Git’s control, i.e. Git watches over all files.
If you changed (files in) the working directory and want to save certain changes, it’s time to create a **“commit”**. That’s a *recursive* snapshot of all *tracked* files in the working directory. Only carefully chosen changes (compared to the previous snapshot) will be a part of the snapshot.
Example: To persist changes in the files `build.conf` and `thinstation.conf.buildtime` type
git add build.conf thinstation.conf.buildtime
git commit
If you continue development you will create more commits.
git add …
git commit
git add …
git commit
This leads to a linear line of development:
o--o--o (a series of commits “o”)
-> direction of development ->
### Branched development
The above is a simple example for a **branch**. Each branch has a *unique* name refering to the newest commit in a series. In ThinStation branches are used for example to develop different major versions of the framework. That’s why you cloned a certain branch from the ThinStation repository (e.g. `5.5-Stable`). Let’s call these branches “**system branches**” for clarity’s sake.
o--o--o 5.5-Stable (a system branch)
In addition to system branches you can create personal branches to store tuned configuration files. We will call them “**config branches**” here. A config branch starts at a certain well defined commit, typically the newest in a system branch. This reflects the fact that you based your work on top of ThinStation.
git checkout -b mybranch
git add …
git commit
git add …
git commit
leads to
o--o--o 5.5-Stable
\
o--o mybranch (a config branch)
Note that your own “local” branching does not affect system branches at all. “Official” ThinStation development goes on, i.e. system branches continuously grow by new commits. To locally see the latest changes to ThinStation you have to “fetch” them:
git fetch
o--o--o--o--o--o--o 5.5-Stable
\
o--o mybranch
In such a situation you will want to update your config branch to be based on the latest system branch commit. Git calles this a **rebase**:
git checkout mybranch
git rebase 5.5-Stable
o--o--o--o--o--o--o 5.5-Stable
  \
o--o mybranch
To avoid problems afterwards, it is best to reset the build environment
./setup-chroot # entering
clean_chroot # cleaning
exit
before you start with the rebase.
Sometimes you want to tranfer a commit from one branch to another without merging the two branches. Enter (checkout) the destination branch first. Then
git cherry-pick commit-ID
This is called **“cherry picking”** and will create a new commit by default.
## Example use of config branches
Let’s assume you have a powerful development workstation but pretty slow thin clients. For this reason you may *prefer developping and testing your software configuration within a virtual machine*. Only after everything is working as expected in the virtual machine you switch to using real hardware (thin clients).
This could be achieved like this:
1. Start by creating a new config branch (e.g. called `vbox`) on top of the latest ThinStation stable system branch.
o--o--o 5.5-Stable
\
vbox
2. Depending on your desktop virtualization software (VMware or VirtualBox) tune to the appropriate machine profile and make a first commit. Then develop until you are satisfied with the user facing software configuration. Make commits whenever appropriate.
o--o--o 5.5-Stable
\
o--o--o--o vbox
3. Now create a second config branch (e.g. called `myclient`). Switch the machine profile and test. If necessary fix remaining issues. Then commit your changed files.
o--o--o 5.5-Stable
\
o--o--o--o vbox
\
o--o myclient
Which is equivalent to:
o--o--o 5.5-Stable
\
o--o--o--o--o--o myclient
\
vbox
4. If you need to change your software configuration, switch to the branch `vbox` before developing.
git checkout vbox # note the missing -b
git add …
git commit
o--o--o 5.5-Stable
\
o--o--o--o--o--o myclient
\
o vbox
5. Finally cherry-pick (i.e. transfer) the most recent commit into myclient:
git checkout myclient
git cherry-pick vbox

32
Using-the-hdupdate-package.md Normal file

@ -0,0 +1,32 @@
If you [[use GRUB to boot ThinStation|Deployment#booting-from-removable-media-or-internal-storage]] it is possible to make thin clients automatically update themselves via network.
In order to do so you have to identify each release of boot files with a version number. If the number on the server is newer than on a client, it will upgrade itself on bootup.
## Prerequesites
You need a HTTP (or TFTP or SCP) server for serving the kernel `vmlinuz` and the initial ramdisk file `initrd`.
Naturally *one initial* version of ThinStation **including hdupdate** needs to be installed on the thin client *before* automatic updates (carried out by hdupdate) can take place.
## How to
1. Uncomment `package hdupdate` in `buid.conf`. Set the familiy of `HDUPDATE` variables in `thinstation.conf.buildtime` according to your configuration. For example:
HDUPDATE_ENABLED=Y
HDUPDATE_SERVER=172.16.0.98
HDUPDATE_SERVER_TYPE=wget
HDUPDATE_PATH=/update
HDUPDATE_WS_VERSION=1
HDUPDATE_TEMP=RAM
HDUPDATE_FORCE=N
2. Build ThinStation and install this version on each client that should be updated through hdupdate.
3. Add at least the following variables to a [[network configuration file|Configuration#boot-time-configuration]] read by all clients in question:
HDUPDATE_SERVER_VERSION=1
HDUPDATE_FILES="initrd"
4. If a new release of your ThinStation boot files (`initrd` or even the kernel `vmlinuz`) is due to be rolled out, you have to:
1. Change `HDUPDATE_WS_VERSION` to a higher number and build ThinStation.
2. Copy all necessary files (usually only `initrd`; `vmlinuz` only if you switched to a newer ThinStation release/branch) to the HTTP/TFTP/SCP (depending on `HDUPDATE_SERVER_TYPE`) servers directory. Put the files in the subdirectory `HDUPDATE_PATH`.
3. Increase `HDUPDATE_SERVER_VERSION` to the same value as the latest `HDUPDATE_WS_VERSION`. If a new kernel is to be delivered, change `HDUPDATE_FILES` to `"initrd vmlinuz"`.
4. Boot up all affected thin clients and check the update process. **Note:** The client will *not reboot* after a sucessful update but start up the previous version for the last time.

3
VMWare-View-&-Citrix-ICA.md Normal file

@ -0,0 +1,3 @@
## Proprietary Applications
We try and make it easy for you to integrate these kinds of applications into your builds, but we can only go so far. You will need to go to the owner of the application like VMWare for Horizon View or Citrix for ICA, and agree to their terms and conditions of use before downloading the software package necessary for integration. Once downloaded, place the bundle in /downloads of your TS build env. You might need to update `/build/build.urls` with the filename.

25
_Sidebar.md Normal file

@ -0,0 +1,25 @@
# Basics
- [[Getting Started|Getting-Started-with-ThinStation]]
- [[Configuration]]
- [[build.conf|build.conf]]
- [[thinstation.conf|thinstation.conf]]
- [[Examples|Examples]]
- [[Booting Modes and Compression|Booting-Modes-and-Compression]]
- [[VMWare View & Citrix ICA]]
- [[Certificates]]
- [[Secureboot]]
- [[Deployment]]
- [[Packaging]]
- [[Machine profiles|Machine-profiles]]
- [[CD to USB disk|Making bootable media on Windows]]
- [[Persistence]]
- [[Updating ThinStation|Updating-your-repository]]
- [[Debugging]]
- [[FAQ]]
# Using …
- [[Git with ThinStation|Using-Git]]
- [[hdupdate|Using-the-hdupdate-package]]
- [[Printers|Printer-configuration]]
- [[Smartcards|Smart-Cards]]
- [[Update a Port|Update-a-Port]]

43
build.conf.md Normal file

@ -0,0 +1,43 @@
## General description
`build.conf` is ThinStation’s basic setup file in which you define which hardware drivers, programs and features will be included in boot images (generated by running `./build`).
Initially `build.conf` is a symbolic link to [`build.conf.example`](https://github.com/Thinstation/thinstation/blob/5.4-Stable/ts/build/build.conf.example). Thus we recommend
```
rm build.conf
cp build.conf.example build.conf
```
before you start.
The file itself is *verbosely* commented so **don’t hesitate to directly dive into the source *before* reading this page**.
## Syntax
Anything *after* a `#` is a comment. You “deactivate” whole lines by putting a `#` in front of them and “reactivate” them by removing the `#` again. Empty lines are also allowed.
Apart from the above `build.conf` consists of lines containing exactly one of the following keywords (“directives”)
- `machine`
- `firmware`
- `module`
- `package`
followed by (any amount of) whitespace and a keyword specific string (value). The `param` keyword is also valid, but it needs to be followed by a key value pair of strings.
## Content
Although you can reorder all lines arbitrarily it is advisable to stick to the given order of topics:
1. machine profiles
2. support for wireless communication
3. filesystem support
4. system level software
5. X.org drivers
6. localization
7. user facing applications
8. window managers and utilities
9. miscellaneous services
10. fonts and icons
11. parameters
ThinStation uses and incorporates many [OSS](http://en.wikipedia.org/wiki/Open_source_software) applications and even includes installers for some proprietary applications. Make sure not to include too many fonts in your build. Also Firefox and Java are extremely RAM demanding.

BIN
r1.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 104 KiB

BIN
r10.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 74 KiB

BIN
r11.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
r12.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
r13.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 72 KiB

BIN
r14.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 288 KiB

BIN
r2.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 112 KiB

BIN
r3.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 111 KiB

BIN
r4.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 105 KiB

BIN
r5.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
r6.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 57 KiB

BIN
r7.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
r8.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 62 KiB

BIN
r9.png Executable file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 62 KiB

15
thinstation.conf.md Normal file

@ -0,0 +1,15 @@
ThinStation attempts to parameterize many of the major functions available in those applications, but only covers a small percentage of what each application uses. Other parameters can be passed via the `SESSION_n_<package>_OPTIONS` parameter.
For a list of all parameters supported by an application and the general usage of those applications, please refer to the documentation for those parameters and applications on their respective websites. The list below
will help find some of the major applications/packages used by ThinStation.
- [Blackbox](http://blackboxwm.sourceforge.net/) as the Window Manager (desktop)
- [BootSplash](http://bootsplash.org) [FAQ](http://bootsplash.org/FAQ) for the bootsplash whilst loading
- [BusyBox](http://busybox.net) as the major command line tool
- [Citrix Receiver (ICA Client)](http://support.citrix.com/product/ica/unix/)
- [IceWM](http://www.icewm.org/) as the Window Manager (desktop)
- [xtdesk](http://garuda.newmail.ru/xtdesk_e.dhtml) for icons etc. on the desktop (\< v2.4)
- [idesk](http://idesk.sourceforge.net/) for icons etc. on the desktop (v 2.4 \>)
- [NoMachine NX](http://www.nomachine.com/)
- [Cendio ThinLinc](http://www.cendio.com/products/thinlinc/)
- [RDesktoP](http://www.rdesktop.org), [man page](http://linux.die.net/man/1/rdesktop)