added launchpad link and changed metadata to new LP system
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
| * Created: 15 Okt by ReinhardTartler
* Priority: NeedsPriority
* People: NeedsLead, NeedsSecond
* Contributors: ReinhardTartler
* Status: UbzSpecification, BrainDump (then DraftSpecification then EditedSpecification then ApprovedSpecification), DistroSpecification
* Malone bug:
* Packages affected:
* BoF sessions: none yet
| * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/configuration-infrastructure
* '''Created''': [[Date(2005-10-27T21:15:55Z)]] by JaneWeideman
* '''Contributors''': JaneWeideman, ReinhardTartler
* '''Packages affected''':
|Line 17:||Line 8:|
Provide Infrastructure for managing system configuration in ClusterInstallation.
A ClusterInstallation enables the admin to install ubuntu unattended on his computers in his pool. We need some Infrastructure to manage configuration of his network
- Handles installation and updating of software packages using apt-get
- Handles mounting shared network volumes (like home directories)
This will be a Client/Server setup.
On the server part, the infrastructure learns the local config of the AuthenticationInfrastructure. Furthermore, this part is handling a repository of packages, which shall be installed on the clients.
The client part needs to detect his configuration server, fetches current configuration and performs local config changes to AuthenticationInfrastructure and software updates.
This Spec assumes that the cluster will have a global config for all participating clients. Classes like in cfengine setups are not supported. There is at most one Configuration Server in one installation.
There are several ways to implement that design. A quick but safe implementation could be using ssh.
The server side collects all data in config archives, which the clients fetch using ssh on boot time. The clients run sshd themselves.
At install time of the client part, it asks the admin for the ip address and the admin password. With this information, it establishes an ssh connection to the config server and registers itself.
The registration of the clients include exchanging passwordless ssh keys, so that the client can fetch in future updated configs and package lists to install. Furthermore, the server can now connect passwordless to the clients and trigger software installation and updates.
If registered, the clients runs at boot time, fetching up-to-date configuration from the server and applying it. The server contacts his clients on changes to config, boot time, and admin request.
No GUI needed for this spec!
The following extensions to this specs are thinkable:
- Allowing the admin to define 'classes' of clients with different Authentication methods and/or package lists.
Manage other Configuration Details besides AuthenticationInfrastructure and software updates
- Integration with cfengine for more sophisticated setups.
Data preservation and migration