Differences between revisions 7 and 8
Revision 7 as of 2006-05-03 12:28:48
Size: 3295
Comment: related links
Revision 8 as of 2006-05-08 15:01:23
Size: 3306
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:
=== Related Things === === Related Work and Projects ===

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 controlable services on it's own with zeroconfig. These would insert themselfs into the whole network like plugins. Security within the domain would need to be provided by Kerberos.

Because a standarized, popular interface like SOAP 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 ommunicates via SOAP 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

prerequisits: 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 capibilities 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 strage 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.

Comments

ConfigurationHandling

DebConf

DebianControlCenter

Use CipUX RPC API

CipUX user administration tool provides a set of command line tools that provide a well defined API for RPC calls. This could be used for

  • native administration GUIs (Qt, Gtk)
  • Java Applets
  • Plugins for Moodle etc. (planned in France)

Thus, webmin dependencies could be solved.