-
-
Notifications
You must be signed in to change notification settings - Fork 187
Configuration
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 for your special configuration files.
The most basic part of build time configuration is about hardware support. Most of it is included in a machine profile suitable for your thin client hardware.
The applications included in the boot image are defined in a file called 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 the boot image to make changes effective.
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.
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).
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.
There are three ways of fetching the config files:
- Over TFTP: By default boot images request configuration files from a subdirectory
ts5.4of the TFTP root directory. (Settings:NET_FILE_METHOD=tftpinthinstation.conf.buildtimeandparam basepath ts5.4inbuild.conf) - Over HTTP: This is recommended because HTTP has better performance than the other two protocols. After setting
NET_FILE_METHOD=wgetinthinstation.conf.buildtimeboot images request configuration files from a URL specified byparam baseurlandparam basepathinbuild.conf.
Example: To request file from http://server/conf set param baseurl http://server and param basepath conf.
- Over SCP: This can only be used if the
sshpackage is included inbuild.conf. After settingNET_FILE_METHOD=scpboot images request configuration files from a directory (specified inparam basepathinbuild.conf) on the TFTP server (orNET_FILE_ALTERNATEif defined) as userNET_FILE_USER. Note that allNET_directives need to be set inthinstation.conf.buildtime.
You can address several sets of devices:
-
The whole network. A file named
thinstation.conf.networkwill be read by all ThinStation clients. In a file namedthinstation.hostsyou 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-groupnamefiles (in the order the groups appear inthinstation.hosts). Example:thinstation.conf.group-terminalserver1 -
A certain hostname. A file named
thinstation.conf-hostnamewill only be read by the thin client with the exact same hostname, set either via DHCP orthinstation.hosts. Example:thinstation.conf-client1 -
A certain IP adress. A file named
thinstation.conf-IPaddresswill only be read by the thin client with the exact same IP address. Example:thinstation.conf-192.168.0.55 -
A certain MAC address. A file named
thinstation.conf-MACaddresswill only be read by the thin client with the exact same MAC address. Example:thinstation.conf-005004AABBCC
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, 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.
The following are a set of usage scenarios for a ThinStation workstation
with examples of parameters for your thinstation.conf file.
These settings can go in any of the thinstation.conf files,
except where noted. (Please see above or here
for the order in which thinstation.conf* files are used).
ThinStation includes a number of Microsoft Windows connectivity options. (rdesktop, Citrix ICA, NX, ThinLinc)
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.
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>
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.
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.