Ubuntu Wiki

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: alon@turnkeylinux.org

Retrospective thoughts

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:
  • Leverage Augeas for file editing
  • Leverage HAL over dbus for interfacing with hardware

  • Leverage PolicyKit / ConsoleKit to manage permissions?

• 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

Background

• 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
• Design requirements
  • Lightweight
  • 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

Design goals

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

Lightweight

• 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)

• Core
• 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)

Architecture

Essentially, different projects all building ontop of the core

• 			guiapp / webapp / agent
  cli	console	webapp	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>

Scale up

• Central configuration
• Multi-server administration
• Monitoring

Names

• configuration administration management
• confcon confman confmin confsole
• contour
• panorama (good name for the scale up interface)
• scope
• provost
• magi (magistrate)
• pymin
  • short
  • based on python

  • webmin -> pymin

  • pynorama / pymax - scale