ServerAppliance

Contents

  1. Summary
  2. Rationale
  3. Use cases
    1. OLPC server
    2. Small business server
    3. Colocation server
    4. ISV platform
  4. Scope
  5. Design
    1. User/group management
    2. Power management
    3. Backup and restore
    4. Disk management
    5. Network management
    6. Date and time
    7. Updates
    8. Third-party software installation
    9. Build and delivery
    10. Installation
    11. Web-based interface
    12. Command-line interface
    13. Application adapters
  6. Implementation
    1. Web interface
    2. Command-line interface
    3. User/group management
    4. Wiki
    5. Email
    6. Samba
    7. Instant messaging
  7. Unresolved issues
  8. BoF agenda and discussion

Summary

This specification describes a plan to make it easy to use Ubuntu to construct a wide variety of server appliances. By server appliance, we mean an installation of Ubuntu that:

  • is used as a server
  • is tailored to a well-defined, usually fairly narrow role
  • exhibits appliance-like ease of use, in particular a non-technical user should not require training to be able to administer it

The vision could be summarized as servers for human beings, where not only the users but also the system administrators are considered as human beings.

A consumer ADSL router is a good example of the kind of user-experience we're looking for. (It's not one of our use cases because users' needs for an ADSL router appliance are already adequately served by available products.)

We want to give priority to the needs of the following:

  • small organizations: our priority is small organizations (certainly less than 1000 users, usually less than 100 users) not large enterprises; making it easy to manage large numbers of servers is not the main focus of this specification
  • non-technical users
  • heterogeneous environments: for many kinds of server appliance, clients are more likely to running Windows than Linux
  • developing countries

Rationale

A wide variety of software applications is best performed in a centralized role. This implies that they should run on, or as, a server. For smaller organizations in particular, the deployment cost of a server (in terms of time, money, and expertise) is often prohibitive. This is limiting the useful application of information technology on the users' side.

From the application developer's perspective, it is desirable to develop for systems that have been set up and are managed by capable trained staff--precisely what many of the users cannot afford. But the cost of developing autonomous, self-managed server applications may be hard to justify.

A robust, integrated, extensible framework for the construction of autonomous server appliances can help narrow this gap between supply and demand. Conventional application server frameworks could be of use, but they fail to solve the problem for several reasons:

  • Layercake: Commodity application server frameworks are in the wrong place to solve the problem. They run on top of a choice of operating systems. Consequently they do not manage the system as an integrated whole, and add to the complexity of installation and setup instead of reducing it.

  • Legacy: Most web-application frameworks and application servers are designed as extensible successors to the monolithic ERP applications of old, with business logic provided in the form of plugins, as it were, by custom application developers. This model is not very suitable for off-the-shelf software serving narrowly-defined server roles. Moreover, server appliances may be created or prototyped by selecting a combination of third-party applications and integrating them into a coherent whole. The existing frameworks do not lend themselves to this process.

  • Licensing: Many of the better application server frameworks are distributed under terms that are too onerous to make them useful to small or non-profit end-users or developers.

At the same time, from the developer's point of view, today's crop of commodity application servers has brought some undeniable benefits--notably the effective integration of middleware through open, well-defined standards such as LDAP and http. To take this one step further, these open standards may merit direct exposure as services to applications. Commodity application servers often hide these entirely under their own APIs. Where the open middleware standards may not be quite well-defined enough, as is the case with many SQL implementations, the current maturity of open-source middleware lends credibility to a supplementary "best-of-breed" policy: pick the most suitable alternative for a given component role, and accept at least some of its quirks as part of the product. A de facto standard can be a credible substitute for a de jure one provided it is sufficiently stable, open and well-documented, and supported by a lively community.

Use cases

OLPC server

Sueksa is a primary school in Thailand, which is rolling out an OLPC laptop to each of its students. It has an ADSL connection, but it's slow and unreliable. It has no dedicated IT staff.

It wants to deploy a server to support the use of the laptops by providing

  • a Web proxy for caching and filtering
  • Moodle
  • an update service for the laptops' system software
  • a backup service that students can use to backup the content of their laptops
  • a Web server for educational content (including multimedia content) that students can download to their laptops

Small business server

XYZ Co is a 10-person company. Each of the employees has a PC running Windows XP. They have a ethernet LAN and use Windows peer-to-peer networking. The LAN is connected to the Internet via an ADSL router, but their Internet connection is slow and unreliable. They don't have any server. None of their staff has an significant IT expertise. They can't afford to hire a dedicated IT person, and they can't afford to send their staff on any sort of IT training course. At the moment, each staff member has a hotmail account, and email and MSN messenger via these hotmail accounts is the main mechanism for communication between staff members. Thus a lot of important company data is held in personal hotmail accounts. Important files are also scattered between the individual PCs, which are not regularly backed up.

They would like to deploy a simple server within the company that can be used for collaboration between staff members. As well as providing email and IM, it would provide a wiki and Samba-based file-sharing. The server should use RAID and should be quick and easy to back up.

Colocation server

ISV platform

Scope

The scope of this specification is rather broad at this stage. It's more of a vision than a detailed specification. As things converge, it will be possible to identify various separable chunks of work. As these are identified, we will create separate, more detailed specifications.

There are a number of generic services typically needed by server appliances:

  • user/group management
  • power management (including UPS handling)
  • backup and restore
  • disk management
  • network management
  • date and time configuration
  • update management
  • third-party software installation

For each kind of generic service, a variety of implementations are possible. For example, an appliance which needs rich user/group management capabilities might use an LDAP-based user/group management service; at the other extreme, an appliance might support just a single fixed user name.

Appliances also need some sort of user-interface. The UI should be kept cleanly separated from the implementations of the services. Although the UI will often be web-based this may not always be the case. We want to promote reuse of the work here outside the server appliance use case. More sophisticated users might well prefer a CLI. A lot of functionality in the service implementations that is potentially shareable with the desktop environment, where a GTK-based implementation would be needed.

The meat of any particular appliance will be one or more applications which provide some user-accessible service. Each such application will probably need some sort of adapter to integrate it into the appliance. In some cases, when the appliance consists of a single main Web-based application, it may be desirable to implement the UI to the generic services as an extension to the application, so as to provide a more seamless user experience.

One of the keys to achieving the kind of user-experience that we're after is integration. The appliance should not appear to the user as a collection of independent services but as a coherent whole. For example, adding a new group might:

  • create a wiki page for the group
  • create an mailing list for the group
  • put a link to the mailing list on the group wiki
  • put a link in each user's home page to the group wiki
  • create a jabber chat-room for the group
  • create a directory exported via Samba for sharing files between members of the group

As another example consider changing the IP address. This might require:

  • stopping a number of daemons in a defined order
  • regenerating a number of config files from templates
  • restarting the daemons in a defined order

Another key to achieving the user-experience we're after is drastically to limit the flexibility of any particular appliance. The point at which we provide flexibility is when the appliance image is built.

The number of decisions made at installation time should be minimized. The only decision that inherently has to be made is where the disk space needed for the installation should come from. Everything else should have sensible defaults decided at appliance-build time. (If there's no sensible default for something, then the role of the appliance is probably insufficiently defined.) Anything that the user really needs to be able to change should configurable via the post-installation UI. If there are a number of things that the user is very likely to want to change after installation, then we can provide a setup wizard that makes it easy for the user to change them all.

The work needed to implement this specification includes:

  • one or more implementations of each of these generic services
  • a web-based user interface
  • a command-line interface
  • adapters for a number of higher-level appliance-specific applications
  • enough of a framework to allow the integration of all of the above
  • probably some work on the installer

Design

User/group management

Users have at least:

  • a symbolic username
  • a numeric uid (probably not exposed via the user interface)
  • a given and family name

The interface should support the following administrator-level operations:

  • add a user
  • delete a user
  • change a user's password
  • create a group
  • delete a group
  • add a user to a group
  • remove a user from a group

The interface should allow unprivileged users to perform the following operations:

  • change their password
  • provide various information about themselves (JPEG photo, nickname, phone number)

At appliance-build time it should be possible to enable a variety of workflows for adding users. One kind of workflow that is useful for an internal server is as follows:

  • an anonymous user can request an account specifying a username, given name, last name and password
  • a list of account requests is available to any administrator; the request doesn't need to show the password
  • an administrator can approve or deny each request
  • the administrator can configure the message that is shown to a user that requests an account (for example, the message might say "Bring your ID card to room 101 to get your account approved")

Another kind of workflow might be to do bulk creation of accounts by uploading a CSV file containing user data (including passwords).

Groups have at least:

  • a symbolic group name
  • a numeric group id (probably not exposed through the user interface)

At appliance-build time it should be possible to specify whether there should be a group that automagically contains all users, and if so, what it's called.

The permissions model should be specified at appliance-build time. The simplest permissions model is for possession of administrative privileges to be determined by membership of a particular group (eg "Administrators"). For some kinds of appliance, it would be appropriate to have more than two levels of privilege. For example, a school might want to provide three levels: admin, teacher and student.

One possible implementation for this interface would be LDAP-based, and would use LDAP to store everything including passwords.

Other features that have a strong interaction with user/group management are:

  • PKI certificate handling
  • disk quotas

Issues:

  • Should groups have a human-friendly display name?
  • Do we need a more sophisticated permissions model? Do we always want to tie permissions to groups? In particular, it would be nice for an administrator to be able to delegate administration of a particular group to a particular user.
  • What is the right way to support non-ASCII names?
  • What kind of support should be provided for users adding/removing themselves to/from groups?
  • What happens to a user's or group's data when that user or group is deleted?

Power management

Interface

Support for UPS is very important for developing countries, where electrical power supply especially in rural areas tends to be much less reliable than in developed countries. There's a vendor-independent standard for USB UPSs. It should be possible to make UPSs that support this (which includes low-end, cheap APC UPSs) "just work".

Backup and restore

Local disk (on the appliance)

To client over network

Disk management

Disk space

Quotas

RAID

Network management

DHCP client: dhclient, dhcdbd

DHCP server: dnsmasq

What about zeroconf?

Network roles

Date and time

NTP: pool.ntp.org

Time-zone

Updates

Third-party software installation

Build and delivery

Image formats:

  • CD image
  • Netboot via PXE
  • Virtual machine disk images (VMWare, qemu, Xen)

Installation

Main challenge is partitioning, in particular making RAID-1 super-easy.

Web-based interface

How do we get any notifications back to the user?

Command-line interface

Single command with subcommands (like bzr or svn).

Application adapters

We certainly need support for a web server and email. These are semi-generic in the sense that they provide functionality required by many higher level applications.

In addition the following are priorities:

  • Windows file server (ie Samba)
  • Wiki
  • Instant messaging (Jabber)

Issues:

  • How should we integrate with external email?

Implementation

D-Bus

Python

Web interface

Authentication done by Apache. mod_auth_tkt useful for simple scenarios.

SCGI rather than mod_python. After authentication, fork and do the most of the work with the uid of the authenticated user.

Command-line interface

Calls DBus.

User/group management

Should we use Kerberos? Kerberos would allow us to provide a Web single sign-on system such as cosign that supports n-tier authentication. This in turn would allow us to avoid having the user be asked to provide their password separately by different web applications. A user would sign in once with cosign. A web frontend (such as a web mail service) can then get a ticket from cosign that it can use to talk to a backend (eg an imap server) on behalf of the user. If we do support Kerberos, we should probably use Heimdal since Heimdal can store its passwords in OpenLDAP.

Wiki

Moin

Email

The main components here are:

  • postfix
  • dovecot
  • amavisd-new

  • SpamAssassin

  • ClamAV
  • Horde/IMP

  • MHonArc

Why MHonArc rather than mailman? There's a lot of functionality in mailman that manages membership of the mailing list. We don't need that (at least for certain kinds of appliance) because membership of the mailing list is determined by membership of the group. We just need something that takes email messages and stores them as HTML.

Samba

Need to ensure password synchronization

Instant messaging

Which Jabber server?

JWChat

Group integration

Unresolved issues

BoF agenda and discussion

CategorySpec

ServerAppliance (last edited 2008-08-06 16:24:17 by localhost)