Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/configuration-infrastructure
Created: 2005-10-27 by JaneWeideman
Contributors: JaneWeideman, ReinhardTartler, AndrewMitchell
Packages affected:
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.