5,705
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − This project is an attempt to refocus the School Server paradigm from "only a School Server on a server at school" to "having tough and localized software components to use for a purpose". The core component, sugar-server, should just work after installing from packages if a school needs only basic functionality in an already set up environment. It works without close maintenance from skilled personal. But if a school or deployment needs more functionality, and they have spare servers, the additional components might be used to fulfill local needs.+ − * Be a community project within Sugar Labs to keep core development processes in one place;+ − * It is not about configuring and supporting the whole server at school from scratch, but about having a set of tough, local, doing its job well modules that might be included/excluded in downstream solutions; − * 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 smoothly) of upstream, − ** Provide useful API for components; − * Be GNU/Linux distribution agnostic, different deployments might decide to use different GNU/Linux distributions. − * It is not only about supporting XO laptops, but about any Sugar based environments; − * Support up to 1000 students per server. − == Functionality model ==+ − This is all about how improved functionality of servers at schools might look, at least, Sugar Server Kit is being designed and implemented in this direction. Sugar Server Kit is not intended to cover all the components described here. It is just the global picture from a Sugar Server Kit point of view.+ − Two pure models might describe Sugar Server Kit design, the final model might be an intermediate variant of them.+ − + + + + + + + + + − + − + − + − + − + − *# Incoming system updates flow (also, the way to trigger some configuration changes). This should be rare and a 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 Kit design influence:+ − * existing and configured out of Sugar Server Kit servers at schools+ − * the remaining environment that Sugar Server Kit is not aware of − The key points:+ + + − * Servers at schools are supported out of Sugar Server Kit.+ − * Admins install the sugar-server package from upstream binary repositories, and just launch it. − * sugar-server starts to serve all sugar boxes around, providing only [[#sugar-server|basic sugar specific]] functionality. − * sugar-server doesn't break the system configuration (it touches nothing).
Platform Team/Server Kit/Architecture (view source)
Revision as of 03:48, 6 November 2011
, 03:48, 6 November 2011no edit summary
== Intention ==
== The purpose ==
{{:Sugar_Server_Kit/Architecture/The_purpose}}
== Server functionality models ==
Sugar Server Kit components are being designed to accomplish different functionality models, when the particular model might include only limited number of ingredients. The following models might describe Sugar Server Kit design, the final model might be an intermediate variant of them.
=== Only sugar-server ===
The model with minimal Sugar Server Kit design influence.
=== Black box model ===
The key points:
* Existing and configured out of Sugar Server Kit servers at schools.
* School admins need to take care about setting up sugar-server specific [[Sugar_Server_Kit/sugar-server#Services|requirement configuration]] for external environment.
* School admins install the sugar-server package from upstream binary repository, and just launch it.
* sugar-server starts to serve all sugar boxes around, providing only [[#sugar-server|basic sugar specific]] functionality.
* sugar-server doesn't break the system configuration (it touches nothing).
=== Dumb school servers ===
The model where the server at school is entirely dependent on Sugar Server Kit design decisions. There are two types of machines:
The model where the server at school is entirely dependent on Sugar Server Kit design decisions. There are two types of machines:
* servers at schools under Sugar Server Kit control
* Dumb servers at schools under Sugar Server Kit control. The explicit intention is to minimize maintaining intervention as much as possible.
* optional mothership(s) to control school servers
* The Mothership to minimal control of school servers and handling the rest of functionality that people at schools need.
The key points:
The key points:
* Functionality of such servers is simple, only basic services. (Complex, thus not trivial for maintenance, services are on the mothership, where skilled personal can support them effectively.)
* Functionality of school servers is simple, only basic services.
* The rest of school server functionality (which is not simple) is configured automatically.
* Complex, thus not trivial for maintenance, services are on the mothership and singular, i.e., to minimize maintaining costs and let the minimal number of skilled personal support them effectively.
* Interaction only happens via these flows, via Internet if connectivity is good, and via sneakernet otherwise:
* A set of school server's services tends to be constant, at least it doesn't require regular intervention to add/remove services.
* All school serves have exactly the same set of services.
This functionality model involves Mace and sugar-server-templates components. The entirely content of school servers is:
* a set of packages, including the main one that contains:
** all services as dependencies,
** upstream Mace configuration as sugar-server-templates dependency,
** downstream Mace configuration;
* Mace environment file, e.g., the one from sugar-server-templates [http://git.sugarlabs.org/server/templates/blobs/master/etc/base.env.example examples];
* pure data, like leases and content black lists, to fetch as-is from the Mothership.
After installing the main package, it will provide possibility to fetch Mace environment file and pure data from the Mothersip, and finally running Mace to complete school server setup.
=== Highly maintained school servers ===
''TODO''
== Client functionality models ==
''TODO''
== Distribution model ==
== Distribution model ==