This page needs to rewritten in spec form. It is currently a dump of my notes linked to from the server-karmic-confconsole blueprint for discussion purposes.
I wrote the notes in October 2008, so they might be a little out of date.
If you have any ideas/comments, either edit this page or contact me at: email@example.com
Getting a project like this off the ground is not realistic with the below vaguely sketched out architecture.
A project like this would have a much better chance of becoming a reality if I first:
- Defined the architecture much more carefully in terms of the constituent components - their precise names, definitions, logical boundaries.
- Implemented a proof-of-concept: A minimal piece of working software that implemented the architectural definition in its most basic form (e.g., one of each architectural element)
The proof of concept implementation might go something like this:
- A handful of simple read-only modules (e.g., name of system, memory usage, cpu load). Ideas:
- Leverage Net-SNMP
- A couple of control modules (e.g., reboot, time, network interface configuration). Ideas:
- Back-end components (maybe connected via Dbus - local interface)
- Wrap a secure network transport layer around Dbus that allows it to be accessed by a remote "master" machine (strongly authenticated and encrypted)
- Gut an existing web management interface (e.g., Webmin/Ebox) and hack it to use our proof of concept back-ends instead of its native implementation
- Make the user interface work with both a local transport (direct Dbus, or the remote transport) - this will demonstrate that the basic framework for more sophisticated remote management tools is in place...
What needs to happen to get this going
Touching back with reality for a moment, there is quite a bit of work involved at multiple levels:
- Setting up the infrastructure for collaboration (e.g., website, wiki, mailing lists, git repository...). Ideas:
- Skip "website" - wiki only
- Github for git hosting (until launchpad will support git)
- Create a mailing list
- First draft of the architecture (terminology, definitions, interfaces...)
- Proof-of-concept implementation
It all started with the search for a web adminstration interface for TurnKey Linux appliances.
- Functional requirements
- Display system status information, eg.
- Network settings
- Service status
- Memory, disk space, other basic system info (nice to have)
- Interface to perform common administrative tasks, eg.
- Start/stop/restart services
- Review logs
- Package updates (nice to have)
- Interface to perform basic configuration
- Network interface settings
- Web/DB/Mail/Firewall settings
- Display system status information, eg.
- Design requirements
- Get out of the way of sysadmins who like to edit config files themselves
- DPM compliant
Researched over 20 possible candidates
- Thought it would be a simple 'pick the best' candidate, maybe do some tweaking as needed
- To my suprise, I couldn't find any *really* good candidates that meet the requirements, yet alone the design I imagined
There has been lots of discussion on this issue https://lists.ubuntu.com/archives/ubuntu-server/2008-June/
- Ubuntu server GUI - continued in July...
- RFC: Centralized management console
- More discussion: GUI, blogs and pizza
From what I understand, Ubuntu feel the same way
- Going with ebox for now, and are trying to influence/improve their development (augues)
Planning on writing their own lightweight services console - UbuntuCentralizedServiceAdministrator
- The scope is for a curses console
- Design not very fleshed out, and not scalable...
Lets face it
- Hardcore sysadmins don't use GUI tools (when I want to tweak a configuration, I want to do it myself)
- Most of us just want a simple interface to administer and monitor the common stuff, and perform common tasks.
- And if we admin multiple systems, have an admin system in place that scales
While researching what was available, I began imagining the ultimate system, and thought I would sketch out a quick spec describing it.
Any and all thoughts are welcome
What its not
- Not everything for everybody
- Not an all-in-one tool
- Not a gui file configurator
What it is
- Simple interface for most popular stuff (information and configuration)
- Easy things should be easy, hard things should be possible
- No unrelated dependencies (postgresql, mysql, apache...)
- Why install 80MB of database and web server dependencies to administer a mail server?
Safely manipulate configuration files (augues)
- Allow manual configuration changes aswell
Modular and extendable architecture (down to the bone)
- Pluggable component support (administration, configuration, execution, logging)
- Frontends (cli, console, gui, web)
- VERY well defined API so frontends can be created by contributing developers without mandatory core developers envolvement
Support remote administration to scale (soap / xmlrpc / ssh)
- Maybe leverage func + puppet
- Support push and pull - configurable (depending on situation)
Essentially, different projects all building ontop of the core
guiapp / webapp / agent
net (twisted xmlrpc rest/soap)
backend python api
augeas lenses + pluggable modules
Layered implementation / Development phases
Single server managment (locally, but remotely accessable)
- Backend api with cli
- Console frontend (python-dialog, curses)
- WebUI frontend (django, rubyrails)
Single server management (remotely)
- Twisted / soap+xmlrpc / ssh
Install webUI on a different server, configured to manage <IP>
- Central configuration
- Multi-server administration
- configuration administration management
- confcon confman confmin confsole
- panorama (good name for the scale up interface)
- magi (magistrate)
- based on python
webmin -> pymin
- pynorama / pymax - scale