Platform Team/Server Kit/Architecture: Difference between revisions

Revision as of 07:43, 2 June 2011

Common purposes

Having common project(s) and friendly support 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 additional packages with local customization without patching upstream code/configuration,
- Provide useful API for any new components;
Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server and, e.g., installing Server from the ISO but it makes sense 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 infrastructures.

Components

Component	Provides	Description
sugar-server	Required modules: Student identification Optional services: XO anti-thief support Entirely Journal backup/restore Shared objects	The core component.
sugar-server-base	Optional services: Jabber Web cache Content filter SSH NTP DNS DHCP	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.

@@ Line 1: / Line 1: @@
-== External services ==
+== Common purposes ==
-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 {{Code|mace}} utility.
+* Having common project(s) and friendly support 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 additional packages with local customization without patching upstream code/configuration,
+** Provide useful API for any new components;
+* Be a GNU/Linux distribution agnostic. It doesn't make much sense in case of having only Server on a school server and, e.g., installing Server from the ISO but it makes sense 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 infrastructures.
-=== Mace ===
+== Components ==
-The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Sources for {{Code|mace}} are stored in GNU/Linx distribution agnostic manner in form of:
+{| class="wikitable" border="1"
+|-
+! scope="col" | '''Component'''
+! scope="col" | '''Provides'''
+! scope="col" | '''Description'''
+|-
+| [[#sugar-server|sugar-server]]
+| Required modules:
+* Student identification
+Optional services:
+* XO anti-thief support
+* Entirely Journal backup/restore
+* [[Features/Smart_Objects|Shared objects]]
+| The core component.
+|-
+| [[#sugar-server-base|sugar-server-base]]
+| Optional services:
+* Jabber
+* Web cache
+* Content filter
+* SSH
+* NTP
+* DNS
+* DHCP
+| Handling configuration of basic external services that need to be installed and configured on bare servers at school.
+|}
- [<arbitrary-path>]/<service-name>.d/[<service-confile>]/<configuration-file>.conf
+== sugar-server ==
-The {{Code|service-confile}} is optional and makes sense only if configured service has several of them, e.g., Bind. The {{Code|configuration-file}} are configuration files in particular service configuration syntax. All {{Code|configuration-file}} files will be merged to the singular {{Code|service-confile}} file and placed to the specific directory, depending on particular GNU/Linux distribution, by mace.
+The Server provides basic services to support [[The_Server/Overview#Sugar_related|sugar based]], and [[The_Server/Overview#XO_specific|XO laptops]] in particular, infrastructure at schools. There is only one CLI tool to manage Server related functionality, {{Code|sugar-server}} utility.
-The purpose to have {{Code|arbitrary-path}} is that there might be several directories with the same {{Code|service-name}}s to make configuration more flexible, i.e., it lets having several high-level configuration components in a project that configure the same service. Subsequent configuration might:
+== sugar-server-base ==
-* supplement previous configuration by adding new {{Code|configuration-file}}s,
+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.
-* override previous configuration by having the same {{Code|configuration-file}} name with new content,
-* hide previous configuration by having empty files with the same {{Code|arbitrary-path}} or {{Code|service-name}} name.
-Such rules will be applied while walking within the root configuration directories tree when directory and file names are sorted alphabetically. The following example demonstrates virtual tree of upstream configuration with several high-level components and how downstream tunes them:
+== Distribution ==
- <dir>    +upstrem
+The ways how upstream project might be obtained:
- <dir>    |  +0100.base
- <dir>    |  |  +iptables.d
- <config> |  |     +0100.conf
- <dir>    |  +0300.proxy
- <dir>    |     +iptables.d
- <config> |     |  +0300.squid.conf
- <dir>    |     +squid.d
- <dir>    +downstream
- <dir>       +0100.base
- <dir>       |  +iptables.d
- <config>    |     +0110.addons.conf
- <empty>     +0300.proxy
-== Internal services ==
+* Sources
+* Third party repositories with binary packages for particular GNU/Linux distribution
-The Server provides basic services to support [[The_Server/Overview#Sugar_related|sugar based]], and [[The_Server/Overview#XO_specific|XO laptops]] in particular, infrastructure at schools. There is only one CLI tool to manage Server related functionality, {{Code|sugar-server}} utility.
+The downstream organizations can choose the most practical way, eg, by using upstream repositories and adding new binary packages to tune upstream configuration.
 == Public API ==