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.
Launchpad entry: https://blueprints.launchpad.net/ubuntu/+spec/remote-administration-server
Packages affected: none
Summary
This Spec outlines an approach for implementing a robust, extensible remote administration framework.
Rationale
Current administration of servers requires access to a shell, either local or remote, thus limiting the administration of servers to those who know how to use the command line properly and those who have extensive knowledge of all the configuration files required. This is a drawback for companies that can not afford decent professional support and as a result hinders the fixing of bug #1.
Use cases
- Bob wants to add a user to his server, but doesn't know how to use a command line.
- Alice, an admin in a large company, wants to enable the new trainee webmaster Jane to view apache logs, but does not want to give her shell access.
- John wants a remote version of synaptic.
Scope
Remote administration.
Design
Design requirements
Independent of other applications: Only libraries may be listed as dependancies (I don't think it is correct to force installation of a large program like apache in order to be able to add users).
UI abstraction: It must be possible for multiple clients on multiple platforms to interface with.
Secure: It must be secure enough to run over a insecure network (e.g. the internet).
Advanced access control: Access control must very fine, allowing users to be restricted to doing a very specific task (e.g. viewing a log file).
Generic: It must be generic enough to enable many very different tasks( e.g. add/remove programs, add/remove users, view log files and editing various configuration files).
Extensible: It must be easy to add functionality at a later date, as well as allow different deployments to have different features.
Proposed design
In order to satisfy the design requirements, a 3 tier approach is proposed:
- Authenticating/controller server
- Server modules
- Client
The server modules contain the configuration logic and an api to access it. They are registered with the controlling server and a client is used to call them.
The process is probably best illustrated with the following example:
User logs in: Client authenticates with server and requests a list of modules and api calls that the user has access to, then displays a corresponding GUI.
User changes something: Client calls the corresponding api on the server to perform the task.
Implementation
TODO
Suggestion is to implement using a secure python XMLRPC server for the controlling server and python for the modules. A pyGTK Client would also be nice.
Unresolved issues
BoF agenda and discussion
Please keep your comments to this section to avoid cluttering up the page, thank you.