Changes

== Intention ==

== Intention ==

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.

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.

* Common project within Sugar Labs to keep core development process in one place;

* 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;

* 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:

** 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,

** 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 deployments might decide to use different GNU/Linux distributions.

* 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;

* It is not only about supporting XO laptops, but about any Sugar based environments;

* Up to 1000 students per server.

* Support 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 the components described here. It is just the global picture from Sugar Server point of view.

This is all about how improved functionality of servers at schools might look, 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 a 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 them.

=== Black box model ===

=== Black box model ===

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 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, which is not simple, is configured automatically

* The rest of school server functionality (which is not simple) is configured automatically.

* interaction only happens 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 (also, the way to trigger some configuration changes), should be rare and a batch process

*# 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

*# Incoming data flow for sugar related stuff like leases, activities, or content.

** outgoing data flow to monitor servers

*# Outgoing data flow to monitor servers.

=== One package model ===

=== One package model ===

The key points:

The key points:

* servers at schools are 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 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 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)

* 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 the most obvious way, download its sources.

=== Core packages ===

=== Core packages ===

** enabled/disabled

** enabled/disabled

** added new services, e.g., variants of existing services that are 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 the 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.

Core packages are per-[[#Components|component]] and might be reused as-is in downstream, in a way that is most practical for them.

Core packages are per-[[#Components|component]] and might be reused as-is in downstream, in a way that is most practical for them.

The only relationship between them are:

The only relationship between them are:

* sugar-server might be configured from sugar-server-base

* sugar-server might be configured from sugar-server-base.

* sugar-server-base makes sense only after processing its content by mace

* sugar-server-base makes sense only after processing its content by mace.

These are building blocks for the final solutions in downstream deployments. Components are optional, meaning that

These are building blocks for the final solutions in downstream deployments. Components are optional, meaning that