8,288
edits
Changes
Jump to navigation
Jump to search
Line 2:
Line 2: − + − + − + − + − + Line 19:
Line 19: − + Line 26:
Line 26: − + − + − + − + − + Line 37:
Line 37: − + − + − + − + − + − + Line 55:
Line 55: − + − + − + Line 66:
Line 66: − + − Except just having binary packages, it should be possible to build downstream packages and final OS images on http://packages.sugarlabs.org using only its web UI. The resulted files will be accessible for download from http://download.sugarlabs.org. It is [https://build.opensuse.org/ Open Build Service] based service to build packages and images for rpm and deb based GNU/Linux distributions.+ − + Line 84:
Line 84: − + Line 92:
Line 92: − + Line 112:
Line 112: − +
Platform Team/Server Kit/Architecture (view source)
Revision as of 14:03, 9 June 2011
, 14:03, 9 June 2011no edit summary
* Common project within Sugar Labs to keep core development process in one place;
* Common project within Sugar Labs to keep core development process 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;
* 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:
* Friendly support of customization on purpose in downstream products:
** Modularizing, when components might be included on purpose to fulfill local needs,
** 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,
** 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;
** Provide useful API for components;
* Be a GNU/Linux distribution agnostic, different deployment might decide to use different GNU/Linux distributions.
* Be a 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;
* 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 ==
== 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.
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 the components described here. 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.
Two pure models might describe Sugar Server design, the final model might be an intermediate variant of both of them.
=== Black box model ===
=== Black box model ===
The model where server at school is entirely depended on Sugar Server design decisions. There are two types of machines:
The model where the server at school is entirely dependent on Sugar Server design decisions. There are two types of machines:
* servers at schools under Sugar Server control
* servers at schools under Sugar Server control
The key points:
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)
* 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.)
* the rest of school server functionality, that is not simple, is being configured automatically
* the rest of school server functionality, which is not simple, is configured automatically
* the only interaction happen via these flows (via internet if connectivity is good, and via sneakernet otherwise):
* interaction only happens 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 system updates flow (also, the way to trigger some configuration changes), should be rare and a batch process
** incoming data flow for sugar related stuff like leases, activities or content
** incoming data flow for sugar related stuff like leases, activities, or content
** outgoing data flow to monitor servers
** outgoing data flow to monitor servers
The model with minimal Sugar Server design influence:
The model with minimal Sugar Server design influence:
* existed and configured out of Sugar Server servers at schools
* existing and configured out of Sugar Server servers at schools
* the rest of environment Sugar Server is not aware about
* the remaining environment that Sugar Server is not aware of
The key points:
The key points:
* servers at schools are being supported out of Sugar Server
* servers at schools are supported out of Sugar Server
* admins install sugar-server package from upstream binary repositories and just launch it
* admins install 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 starts to serve all sugar boxes around providing only [[#sugar-server|basic sugar specific]] functionality
* sugar-server doesn't break the system configuration (it just touches nothing)
* sugar-server doesn't break the system configuration (it touches nothing)
== Distribution model ==
== Distribution model ==
How Sugar Server might be reused from downstream excluding most obvious way, download its sources.
How Sugar Server might be reused from downstream, excluding most obvious way, download its sources.
=== Core packages ===
=== Core packages ===
Sugar Server is designed to avoid patching its sources in downstream. Reusing upstream binary packages as-is from repositories on http://download.sugarlabs.org is how Sugar Server is being designed. Downstream might create new packages, that don't have file collisions with upstream packages, to have tweaks for local environment. It is being accomplished by:
Sugar Server is designed to avoid patching its sources in downstream. Reusing upstream binary packages as-is from repositories on http://download.sugarlabs.org is how Sugar Server is being designed. Downstream might create new packages, that don't have file collisions with upstream packages, to have tweaks for local environment. It is being accomplished by:
* sugar-server project has services formed as plugins, from downstream packages such services might be:
* sugar-server project has services formed as plugins, from downstream packages. Such services might be:
** enabled/disabled
** enabled/disabled
** added new services, e.g., variants of existed services highly tuned for local needs
** added new services, e.g., variants of existing services that are highly tuned for local needs
* [[The Server/Mace|mace]] tool that processes configuration from sugar-server-base packages is designed to have several configuration sources for the same service, so downstream configuration packages might change/hide/complement upstream configuration
* [[The Server/Mace|mace]] tool that processes configuration from sugar-server-base packages is designed to have several configuration sources for the same service, so downstream configuration packages might change/hide/complement upstream configuration.
There are three upstream packages:
There are three upstream packages:
* mace
* mace
These packages might be reused as-is in downstream in most practical, for downstream, way.
These packages might be reused downstream as-is, in a way that is most practical for downstream.
=== Full cycle solution ===
=== Full cycle solution ===
Besides just having binary packages, it should be possible to build downstream packages and the final OS images on http://packages.sugarlabs.org by using only its web UI. The resulting files will be accessible for download from http://download.sugarlabs.org. It is an [https://build.opensuse.org/ Open Build Service] based service to build packages and images for rpm and deb based GNU/Linux distributions.
== Deployment model ==
== Deployment model ==
It is entirely downstream decision how to deploy Sugar Server based solutions.
It is an entirely downstream decision as to how to deploy Sugar Server based solutions.
== Components ==
== Components ==
The core component.
The core component.
The singular program with only python, and obvious ones like coreutils, dependency required to let its all services function properly. It provide basic sugar related services and formed as one CLI tool to manage all its functionality.
The singular program requires only on python, and obvious dependencies like coreutils, to allow all its services function properly. It provides basic sugar related services, and is uses one CLI tool to manage all its functionality.
This component provides:
This component provides:
* Optional services:
* Optional services:
** XO anti-thief support
** XO anti-thief support
** Entirely Journal backup/restore
** Entire Journal backup/restore
** [[Features/Smart_Objects|Shared objects]]
** [[Features/Smart_Objects|Shared objects]]
=== mace ===
=== mace ===
Apply configuration templates to the final systems
Apply configuration templates to the final systems.
It is how external services configuration happen within Sugar Server based solutions. The core of this component is [[The Server/Mace|mace]] utility.
It is how external services configuration happen within Sugar Server based solutions. The core of this component is [[The Server/Mace|mace]] utility.