Difference between revisions of "Platform Team/Server Kit/Architecture"
< Platform Team | Server Kit
Jump to navigation
Jump to search
m (→Intention) |
|||
| Line 1: | Line 1: | ||
== Intention == | == Intention == | ||
| − | * Having common project(s) and friendly support customization on purpose in downstream products: | + | * 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, | + | ** 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 | + | ** 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 | + | ** 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 | + | * 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; | * 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. | ||
Revision as of 08:07, 3 June 2011
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.
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.
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.