UbuntuCentralizedServiceAdministrator

Differences between revisions 3 and 4
Revision 3 as of 2008-06-04 00:40:52
Size: 2418
Editor: 200
Comment:
Revision 4 as of 2008-06-04 00:47:46
Size: 3082
Editor: 200
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
'''Release Target''': Ibex '''Release Target''': Ubuntu 10.04
Line 32: Line 32:
The tool will have backends for every service and, if present, will use metadata from the services provided by the package. The metadata could be defined by the packager (or maintainer) or upstream. These backends will be used by the interface, which will be developed as modules so they can be called by the Frame application for centralized management, also those interfaces could be used separete from the tool, but won't present a curses (or graphical) interface.

The interfaces, or formularies, will be defined in XML files and interpreted by the frame to present them to the user, this xml should be generated using the metadata in the module.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Release Target: Ubuntu 10.04

Name: ucsa (Ubuntu Centralized Service Administrator)

Create a tool for centralized server administration, maintenance and configuration. This tool should provide an easy, but powerful user interface based on curses and have support for dynamic module inclusion to add support for new services or packages.

Release Note

Rationale

Ubuntu has the goal to be 'Linux for human beings', on the desktop the goal has been reached, but on the server side there is no easy and unique way to administrate, configure or maintain the services. Also the current recommended tools are web based (e.g. eBox), which involves running a web server and can be a security issue, or are GUI based, which are not adapted for the servers environments. Also the current tools are very limited and most of them make some non standard configurations files, which make difficult for sysadmins to tune their services.

Use Cases

Alice has a small business and wants to add some network services but she has no idea how to configure them. Alice can use the ucsa UI to help her do the job.

Bob installs a file server for his small business, he want to use a common configuration with some tunning at the end. Bob can use ucsa to do the base configuration and then edit the config files by hand to do the tuning.

Assumptions

The tool will allow users to manage configurations and to administrate the services. However, to fully integrate with the system, packages (services?) should provide meta-data regarding information about configuration files and managment of the services for easily maintaince of the tool. The tool will still be useful during the transition when packages are not providing this information.

Design

The tool will have backends for every service and, if present, will use metadata from the services provided by the package. The metadata could be defined by the packager (or maintainer) or upstream. These backends will be used by the interface, which will be developed as modules so they can be called by the Frame application for centralized management, also those interfaces could be used separete from the tool, but won't present a curses (or graphical) interface.

The interfaces, or formularies, will be defined in XML files and interpreted by the frame to present them to the user, this xml should be generated using the metadata in the module.

Migration

Implementation

Rollout

Status

Test/Demo Plan

Outstanding Issues

BoF agenda and discussion

Meeting Notes 2008/05/??

Comments


CategorySpec

UbuntuCentralizedServiceAdministrator (last edited 2009-03-06 19:37:22 by ldng)