ConfigurationInfrastructure

Differences between revisions 4 and 9 (spanning 5 versions)
Revision 4 as of 2005-11-03 21:49:59
Size: 3959
Editor: 209
Comment:
Revision 9 as of 2008-08-06 16:24:12
Size: 3952
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * '''Created''': [[Date(2005-10-27T21:15:55Z)]] by JaneWeideman  * '''Created''': <<Date(2005-10-27T21:15:55Z)>> by JaneWeideman
Line 10: Line 10:
This specs discuss the managment of pools of mass installations installed e.g. by ClusterInstallation. This specification discusses the management of pools of mass installations installed e.g. by NetbootManagement.
Line 14: Line 14:
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. 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 20: Line 20:
  * Cathlina needs to quickly change the root password of her pool of computers she installed using ClusterInstallation.   * Cathlina needs to quickly change the root password of her pool of computers she installed using NetbootManagement.
Line 39: Line 39:
For grouping clients, we use the groups the administrator defined in nmt (refer to ClusterInstallation). For grouping clients, we use the groups the administrator defined in nmt (refer to NetbootManagement).
Line 47: Line 47:
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. 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 49: Line 49:
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. On the server side all files are 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 55: Line 55:
 * 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 /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
Line 57: Line 57:
  * Distributing basic configuration and keys for bootstrapping cfengine and using those more advanced security and configuration features.  * Distributing basic configuration and keys for bootstrapping cfengine and using those more advanced security and configuration features.
Line 59: Line 59:
== Extensions === === Extensions ===

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 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)