Platform Team/Server Kit/Architecture
Intention
- Having common project(s) and friendly support of 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 new packages with local customization or overrides (but not overriding installed files to let PMS work smooth) of upstream,
- Provide useful API for components;
- Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server installed from an iso but it makes sense sugar-serve will be installed in already configured and maintained environment or 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.
Functionality model
This is all about how real functionality of servers at schools might looks like, at least Sugar Server is being designed and implemented in this direction. Sugar Server is not intended to cover all, described here, components. It is just the global picture from Sugar Server point of view.
Two pure models might describe Sugar Server design, the final model might be an intermediate variant of both of them.
Black box model
The model where server at school is entirely depended on Sugar Server design decisions. There are two types of machines:
- servers at schools under Sugar Server control
- optional mothership(s) to control school servers
The key points:
- functionality of such servers is simple, only basic services (complex, thus not trivial for maintenance, services are on mothership where skilled personal can support them effectively)
- the rest of school server functionality, that is not simple, is being configured automatically
- the only interaction happen via these flows (via internet if connectivity is good, and via sneakernet otherwise):
- incoming system updates flow (the way to trigger some configuration changes as well), should be rare and batch process
- incoming data flow for sugar related stuff like leases, activities or content
- outgoing data flow to monitor servers
One package model
The model with minimal Sugar Server design influence:
- existed and configured out of Sugar Server servers at schools
- the rest of environment Sugar Server is not aware about
The key points:
- servers at schools are being supported out of Sugar Server
- admins install sugar-server package from upstream binary repositories and just launch it
- sugar-server starts to serve all sugar boxes around providing only basic sugar specific functionality
- sugar-server doesn't break the system configuration (it just touches nothing)
Distribution model
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, adding new binary packages and creating final installation images.
Components
| Component | Provides | Description |
|---|---|---|
| sugar-server | Required services:
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:
|
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.