ConfigurationInfrastructure

Differences between revisions 3 and 4
Revision 3 as of 2005-10-27 21:15:55
Size: 2928
Editor: 204_220_103_66-WIFI_HOTSPOTS
Comment: added launchpad link and changed metadata to new LP system
Revision 4 as of 2005-11-03 21:49:59
Size: 3959
Editor: 209
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': JaneWeideman, ReinhardTartler  * '''Contributors''': JaneWeideman, ReinhardTartler, AndrewMitchell
Line 8: Line 8:
 
Line 11: Line 10:
Provide Infrastructure for managing system configuration in ClusterInstallation. This specs discuss the managment of pools of mass installations installed e.g. by ClusterInstallation.
Line 15: Line 14:
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 A ClusterInstallation enables the admin to mass install Ubuntu unattended on computers in his pool. We need some infrastructure to manage configuration of his network.
Line 17: Line 16:
== Use Cases ==

  * John runs a pool of computers, for which he needs some extra packages installed. He lists the extra packages into a configuration file on the server. ConfigurationInfrastructure is handling the actual installation and potential upgrades of his packages.
 
  * Cathlina needs to quickly change the root password of her pool of computers she installed using ClusterInstallation.

  * Peter needs a homebrewed script executed on all the computers in his pool installing a custom application.
  
Line 19: Line 26:
 * Needs integration with AuthenticationInfrastructure and/or NetworkAuthentication
 * Handles installation and updating of software packages using apt-get
 * Handles mounting shared network volumes (like home directories)
 * Distributing configuration files, including dpkg.cfg and debconf.conf
 * Remote execution of custom commands

== Security Considerations ==

We are targeting the admin who wants a really simple system to handle. Therefore we assume that he can control which machines are hooked up to his network.

The system could e.g. be compromised if the admin distributes confidential data such as passwords via this facility. If the administrator needs some means of authenticating clients a solution like cfengine needs to be used.
Line 25: Line 37:
This will be a Client/Server setup. The basic idea is to use sshd on the clients and let the server connect to them. The server maintains a list of clients which it can manage, by the clients advertising their presence on the network.
Line 27: Line 39:
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.
For grouping clients, we use the groups the administrator defined in nmt (refer to ClusterInstallation).
Line 35: Line 43:
There are several ways to implement that design. A quick but safe implementation could be using ssh. The clients are running avahi themselves to indicate that they want to be configured by ConfigurationInfrastructure. That way, the server side is able to know which computers are online and ready to be handled.
Line 37: Line 45:
The server side collects all data in config archives, which the clients fetch using ssh on boot time. The clients run sshd themselves. The approach for distributing files and executing commands is using sshd. The Server advertises his ssh public key via avahi to the clients, which they install it to /root/.ssh/authorized_keys.
Line 39: Line 47:
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. For supporting groups of computers to be handled, the registration of the clients includes optionally a "named group" as described in ClusterInstallation. If the given "named group" is not registered on the server, the clients end in the same group as if no group was specified at all. This "default" group shall be the "unknown" group as described in the ClusterInstallation spec.
Line 41: Line 49:
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. On the server side all files are to stored in /var/lib/cfi/<groupname>. The files are stored relative to root directory on the client, so a simple rsync can be used to distribute the files.
Line 43: Line 51:
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. Executing commands is trivial, since we have installed an ssh key install from the server. For easily executing commands on the client, we use dsh.
Line 45: Line 53:
No GUI needed for this spec! === Fun stuff implementable with this ===
Line 47: Line 55:
=== Extensions ===  * Distributing /etc/pkgsync/{must,may,maynot}have files and fireing up pkgsync in a cronjob on the sever. This would require a properly configured dpkg.cfg and debconf.conf on the clients, though
 
  * Distributing basic configuration and keys for bootstrapping cfengine and using those more advanced security and configuration features.
Line 49: Line 59:
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.
== Extensions ===
Line 54: Line 61:
=== Data preservation and migration === Since advertising via avahi is by no means reliable, some clients may be missed by the server. Therefore it could be advisable to maintain a list of clients on the server, which the server should try to contact even when they do not advertise their presence. We have to evaluate if this is actually an issue and extend the implementation so.
Line 56: Line 63:
== Outstanding issues ==

== BoF agenda and discussion ==

Summary

This specs discuss the managment of pools of mass installations installed e.g. by ClusterInstallation.

Rationale

A ClusterInstallation enables the admin to mass install Ubuntu unattended on computers in his pool. We need some infrastructure to manage configuration of his network.

Use Cases

  • John runs a pool of computers, for which he needs some extra packages installed. He lists the extra packages into a configuration file on the server. ConfigurationInfrastructure is handling the actual installation and potential upgrades of his packages.

  • Cathlina needs to quickly change the root password of her pool of computers she installed using ClusterInstallation.

  • Peter needs a homebrewed script executed on all the computers in his pool installing a custom application.

Scope

  • Distributing configuration files, including dpkg.cfg and debconf.conf
  • Remote execution of custom commands

Security Considerations

We are targeting the admin who wants a really simple system to handle. Therefore we assume that he can control which machines are hooked up to his network.

The system could e.g. be compromised if the admin distributes confidential data such as passwords via this facility. If the administrator needs some means of authenticating clients a solution like cfengine needs to be used.

Design

The basic idea is to use sshd on the clients and let the server connect to them. The server maintains a list of clients which it can manage, by the clients advertising their presence on the network.

For grouping clients, we use the groups the administrator defined in nmt (refer to ClusterInstallation).

Implementation

The clients are running avahi themselves to indicate that they want to be configured by ConfigurationInfrastructure. That way, the server side is able to know which computers are online and ready to be handled.

The approach for distributing files and executing commands is using sshd. The Server advertises his ssh public key via avahi to the clients, which they install it to /root/.ssh/authorized_keys.

For supporting groups of computers to be handled, the registration of the clients includes optionally a "named group" as described in ClusterInstallation. If the given "named group" is not registered on the server, the clients end in the same group as if no group was specified at all. This "default" group shall be the "unknown" group as described in the ClusterInstallation spec.

On the server side all files are to stored in /var/lib/cfi/<groupname>. The files are stored relative to root directory on the client, so a simple rsync can be used to distribute the files.

Executing commands is trivial, since we have installed an ssh key install from the server. For easily executing commands on the client, we use dsh.

Fun stuff implementable with this

  • Distributing /etc/pkgsync/{must,may,maynot}have files and fireing up pkgsync in a cronjob on the sever. This would require a properly configured dpkg.cfg and debconf.conf on the clients, though
    • Distributing basic configuration and keys for bootstrapping cfengine and using those more advanced security and configuration features.

== Extensions ===

Since advertising via avahi is by no means reliable, some clients may be missed by the server. Therefore it could be advisable to maintain a list of clients on the server, which the server should try to contact even when they do not advertise their presence. We have to evaluate if this is actually an issue and extend the implementation so.


CategorySpec

ConfigurationInfrastructure (last edited 2008-08-06 16:24:12 by localhost)