Stateless thin client server?
One of the goals of the debian-edu project is to make as many of the
computer systems in a school field replacable. Both thin clients and
workstations are in theory field replacable. If one is broken,
replace it with a similar system and boot it to get it to work. There
are still some issues with NFS exporting and fixed IP address left to
solve, but no local configuration is needed on the thin clients or the
workstation, if the school is happy with the default installation. As
for the main server, it was never a goal to make it field replacable.
It (or the cluster of machines supplying its services) is the
information center in the debian-edu network, so it will need to have
local state.
One system which typically isn't field replacable is the thin client
server. If the thin clients need some special configuration (X
config, local devices, etc), the thin client server need to store this
information in its dhcpd.conf and lts.conf. A long time ago we
discussed how to move this configuration into the LDAP database, to
move it from the thin client server and into the main server, but we
never followed up on this work.
One issue we faced, was how to address the thin clients through the
thin client server, when we didn't want to identify the thin client
server in the configuration (remeber, it should be replacable, so we
do not want to identify one specific thin client server). We never
found a good solution for this.
Recently, I have realised that the problem is not really precent if we
store information about the thin client (and not linked to its thin
client server), and let the thin client server access this information
for its client. If we have a database of thin client MAC addresses,
mapping to thin client configuration (X config, etc), and let the thin
client server look up this information for all its thin clients, we
get thin clients servers without any local state.
This could be implemented by storing the config info in LDAP, and
having some scripts on the thin client server looking up the MAC
address of ever client trying to boot from it, and then generate the
needed configuration files on the fly.
Would this work?
Reply to: