Design
Configuration for the whole infrastructure is stored in an LDAP directory. Each participant has write access to their portion of the configuration tree. They can choose to run a number of components, which will provide services to other participants, and request services from others by creating entries in their configuration.
Implementation
The implementation is done in many pieces :
- a modular LDAP schema will be defined;
- a set of configuration file templates and helper scripts will be developped on top of cfgf, implementing the schema (initially) on Debian systems;
- we will develop some tools, such as rpt, to automate the maintainance of patnet hosts.
Services (random ideas)
- backups, depends on the least stuff so that it's not easily broken and is actually accessible to most people.
- LDAP (service providers would replicate the configuration tree)
- DNS, all masters, the contents of zones are automatically created from the configuration information. Some records are automatically created which list servers for a particular component or service request.
- Kerberos, one realm and KDC per participant (or configurable realm mapping).
- AFS (shared filesystem), uses Kerberos or is read-only. (NB: AFS, its ACLs, and its reliance on Kerberos might not be the easiest path for the lost souls, and might be a portability nightmare; but let's torment webmasters a bit... ;-) )
- shell access, w/ AFS for shared home directories, authenticated w/ Kerberos, and with a minimal specification for a common enviroment across hosts.
- HTTP, uses AFS: service requests map domain names or URIs to directories in AFS. CGIs can be supported by servers provided they get a principal for accessing files/services they need, which is available to all servers providing the service. Backends different from AFS would be conceivable, such as mirroring from a master HTTP server or pulling out of a version control repository.