Platform Team/Server Kit/Architecture

Common purposes

  • Having common project(s) and friendly support customization on purpose in downstream products:
    • Modularizing when components might be included on purpose to fulfill local needs,
    • Not patching in downstream but supplementing the upstream, e.g., install upstream packages and just add additional packages with local customization without patching upstream code/configuration,
    • Provide useful API for any new components;
  • Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server and, e.g., installing Server from the ISO but it makes sense if downstream organizations ship their products based on the Server and having particular GNU/Linux distribution is important;
  • It is not only about supporting XO laptops but about any Sugar based environments;
  • Up to 1000 students per server.

Components

Component Provides Description
sugar-server Required services:
  • Student identification

Optional services:

The core component.
The singular program with only python, and obvious ones like coreutils, dependency required to let its all services function properly.
sugar-server-base Optional services:
  • Jabber
  • Web cache
  • Content filter
  • SSH
  • NTP
  • DNS
  • DHCP
Handling configuration of basic external services that need to be installed and configured on bare servers at school.

sugar-server

The Server provides basic services to support sugar based, and XO laptops in particular, infrastructure at schools. There is only one CLI tool to manage Server related functionality, sugar-server utility.

sugar-server-base

Thats an important part of the Server, since it should configure core services that need to be provided by a server at school. The configuration happens in GNU/Linux agnostic manner, basing on mace utility.

Distribution

The ways how upstream project might be obtained:

  • Sources
  • Third party repositories with binary packages for particular GNU/Linux distribution

The downstream organizations can choose the most practical way, eg, by using upstream repositories and adding new binary packages to tune upstream configuration.

Public API