ConfigurationInfrastructure

Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2005-10-15 12:54:36
Size: 2801
Editor: p5494F2A3
Comment:
Revision 5 as of 2005-11-05 15:02:31
Size: 3955
Editor: 209
Comment: ClusterInstallation -> NetbootManagement; typo fixes
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
 * Interested:
 * Status: UbzSpecification, BrainDump (then DraftSpecification then EditedSpecification then ApprovedSpecification), DistroSpecification
 * Branch:
 * Malone bug:
 * Packages affected:
 * Depends:
 * Dependents:
 [[FullSearch()]]
 * 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, AndrewMitchell
 * '''Packages affected''':
Line 19: Line 10:
Provide Infrastructure for managing system configuration in ClusterInstallation. This specification discusses the management of pools of mass installations installed e.g. by NetbootManagement.
Line 23: 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 NetbootManagement enables the admin to mass install Ubuntu unattended on computers in his pool. We need some infrastructure to manage configuration of his network.
Line 25: 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 NetbootManagement.

  * Peter needs a homebrewed script executed on all the computers in his pool installing a custom application.
  
Line 27: Line 26:
 * Needs integration with AuthenticationInfrastructure
 * Handles installation and updating of software packages using apt-get
 * 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 32: 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 34: 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 NetbootManagement).
Line 42: 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 44: 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 46: 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 NetbootManagement. 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 NetbootManagement spec.
Line 48: 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 50: Line 51:
No GUI needed for this spec! 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 52: Line 53:
=== Extensions === === Fun stuff implementable with this ===
Line 54: Line 55:
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.
 * Distributing /etc/pkgsync/{must,may,maynot}have files and firing 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 59: Line 59:
=== Data preservation and migration === == Extensions ===
Line 61: Line 61:
== Outstanding issues == 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 63: Line 63:
== BoF agenda and discussion ==

Summary

This specification discusses the management of pools of mass installations installed e.g. by NetbootManagement.

Rationale

NetbootManagement 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 NetbootManagement.

  • 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 NetbootManagement).

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 NetbootManagement. 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 NetbootManagement 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 firing 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)