5,705
edits
Changes
Jump to navigation
Jump to search
Line 8:
Line 8: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 45:
Line 91: − − == 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.
Platform Team/Server Kit/Architecture (view source)
Revision as of 11:33, 9 June 2011
, 11:33, 9 June 2011no edit summary
* It is not only about supporting XO laptops but about any Sugar based environments;
* It is not only about supporting XO laptops but about any Sugar based environments;
* Up to 1000 students per server.
* 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 start to server all sugar boxes around providing only sugar specific functionality
== 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 ==
== Components ==
Thats an important part of the Server, since it should configure [[The_Server/Overview#Core|core services]] that need to be provided by a server at school. The configuration happens in GNU/Linux agnostic manner, basing on [[The Server/Mace|mace]] utility.
Thats an important part of the Server, since it should configure [[The_Server/Overview#Core|core services]] that need to be provided by a server at school. The configuration happens in GNU/Linux agnostic manner, basing on [[The Server/Mace|mace]] utility.
== Public API ==
== Public API ==