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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
