Outline for a Distributed Admin Tool
This page describes how the distributed admin tool could work and what it should do.
This could be used for centralized administration of one or more machines for one or more services, both for Debian or other distributions. Especially key-turn-solutions like DebianEdu and large scale deployments could profit from this.
What is it?
It will be an advanced replacement for Webmin, which provides admin capabilities for numerous services on a local server. This tool would be able to do more: it would be able to do network wide changes in a coordinated fashion, provide different user interfaces (commandline, webinterface, X and perhaps even Windows?) and find controllable services on it's own with zeroconfig. These would insert themselves into the whole network like plugins. Security within the domain would need to be provided by Kerberos.
Because a lightweight, extensible interface like XML-RPC between the central part and the distributed plugins, the many different distributed parts could be written in programming languages of choice by whoever is interested in having such a plugin.
How does it work?
Every service that should be administrated gets a small daemon installed on the same machine on which the specific service runs on. It communicates via XML-RPC with the centralized admin daemon. That provides both a user interface to the different distributed services on the network and routes the
Example Use Cases
An Admin creates a user account on all machines in a cluster
prerequisites: The cluster uses LDAP as a directory service and distributes home directories via a network file system.
On the LDAP server there is an "account handler" plugin and on the fileserver a "storage handler" plugin. Both plugins have already communicated their capabilities to the centralized admin daemon. The needed capabilities to create a user account are "provide account entry to network", "create new account entry" (from the account handler plugin on the LDAP server) and a "create new home directory" and "provide home directory to network" (from the storage handler plugin). The centralized admin daemon in turn concluded that because of these capabilities it is able to provide the functionality of "Add New User Account" to the user interface. So the Admin gets presented with the option of adding user accounts. The Admin enters valid names, location of $HOME, passwords etc and the centralized admin daemon dispatches orders to the ldap and network filesystem plugin to create the required entries/directories. If it gets success messages back from both ends, it hands back an OK to the User. Should it get errors from one or more of the plugins it needs to initiate a rollback for this operation on the nodes and displays an error message on the user interface.