Difference between revisions of "Deployment Platform/Sneakernet"

From Sugar Labs
Jump to navigation Jump to search
Line 13: Line 13:
 
* The only way to synchronize school servers with each other and with the master one, is a [[wikipedia:Sneakernet|sneakernet]].
 
* The only way to synchronize school servers with each other and with the master one, is a [[wikipedia:Sneakernet|sneakernet]].
  
=== Synchronization ===
+
The scenario assumes keeping Sugar Network node server launched on teacher's XO which provides Sugar Network access to students around. Teacher's and students' XO should be flashed with special Sugar with Sugar Network integration. It might be [[Deployment_Platform/XO_reference_distribution#Try_reference_implementation|one of reference images]] or final deployment ones like [http://pe.sugarlabs.org/go/Proyecto_Piloto_Hexoquinasa Hexoquinasa].
  
Due to offline nature of this scenario, there are specific routines to synchronize school servers content. The synchronization content includes all data that needs to be accessible from a school server to support complete life cycle of served clients. These are:
+
== Teacher's XO ==
  
* Base software updates to proceed unattended upgrade on server and client sides.
+
=== Sugar Network volume ===
* Unattended configuration for school server and clients.
 
* Optional upload to master server of [[Platform_Team/Usage_Statistics|usage statistics]].
 
* [[Sugar Network]] content, intended to cover all other needs.
 
  
=== Objects ===
+
To make process of choosing server XO more flexible, entire Sugar Network node data should be stored on separate removable device, SD card of USB stick. Any XO can be turned into Sugar Network node by plugging such volume.
  
What kind of objects involved to the process:
+
To make removable media capable to store Sugar Network data:
  
* '''Master server'''<br>Main Sugar Network server accessible via the Internet. Each Master server has public API url. This tutorial is using http://api-testing.network.sugarlabs.org to refer to testing Sugar Network Master launched on Sugar Labs server.
+
* Create {{Code|sugar-network}} directory in the root.
  
* '''Node servers'''<br>Local Sugar Network servers that are intended to be distributed versions of the Master. This tutorial assumes that Nodes don't have direct connection to the Master, and the only one way to synchronize data is the [[wikipedia:Sneakernet|Sneakernet]].
+
In order to make XO server capable:
  
* '''Clients'''<br>Users connected to one of Node server via Intranet, e.g., wireless Ad-hoc connection. In server-less environment, users restricted only to content they already downloaded from the server.
+
* Enable server mode checkbox in ''Sweets Distribution'' section in Sugar Control Panel, or, if this sections is disabled, populate {{Code|/etc/sweets.conf}} configuration file (it might be done on XO image creation stage):
  
* '''Database media'''<br>Node servers might store database on removable devices (makes sense if Nodes are XO laptops), in that case, such devices should have a magic file, named {{Code|.sugar-network}}, in the root directory on removable device. Having this magic file will let Node's software auto detect recently plugged removable device as a Database media to start behaving correspondingly.
+
[client]
 +
server-mode = True
  
* '''Synchronization media'''<br>Removable media device, e.g., USB stick or SD card that will be used to transfer Packets between servers. Synchronization media should have a magic file, named {{Code|.sugar-network-sync}}, in the root directory. Having this file will let Node's software start synchronization process automatically after plugging media.
+
* Initiate Ad-Hoc wireless session from Neighborhood View in the Sugar Shell to let students connect to Sugar Network server;
  
* '''Synchronization packets'''<br>Regular files that contain synchronization data placed to Synchronization media. Packet files are [[wikipedia:Tar_(file_format)|tarballs]] with {{Code|.packet}} file name suffix.
+
* Plug prepared Sugar Network volume.
  
== Recipes ==
+
=== Synchronization ===
 
 
A list of use-cases to follow in the field.
 
 
 
=== Clone Master ===
 
 
 
On a box with Internet available, plug Synchronization media. Its mount point will be referred as {{Code|MOUNTPOINT}} in text below.
 
 
 
If {{Code|sugar-network}} package is installed, run the following command:
 
 
 
sugar-network-sync MOUNTPOINT http://api-testing.network.sugarlabs.org/
 
 
 
Otherwise,
 
 
 
* using any regular Web downloader, e.g., {{Code|wget}} or {{Code|curl}}, fetch clone data using http://api-testing.network.sugarlabs.org/?cmd=pull url (the first try might return empty file, in that case, retry in a minute);
 
 
 
* place fetched data to {{Code|MOUNTPOINT}} with to a file with {{Code|.packet}} suffix;
 
 
 
* create empty file in {{Code|MOUNTPOINT}} named as {{Code|.sugar-network-sync}}.
 
 
 
=== Run Node server on Sugar box ===
 
 
 
This mode is useful when there is no dedicated hardware for school server. In that case, particular XO laptop might be a Node server, e.g., one that teacher has.
 
 
 
* Prepare Database media. Place the following files to the root of removable device that is intended to be a Database media:
 
** Empty {{Code|.sugar-network}} file;
 
** {{Code|master}} file with {{Code|api-testing.network.sugarlabs.org}} as a content, will be Master's GUID;
 
** {{Code|node}} file with arbitrary string as a content, will be Node's GUID.
 
 
 
* On a box that is intended to be a Node server; in ''Sweets Distribution'' Control Panel section, enable ''Behave as a Sugar Network server..'' checkbox (will require restarting Sugar Shell).
 
 
 
* Plug prepared Database media.
 
 
 
* Plug Synchronization media with [[#Clone Master|initial data]].
 
 
 
In current implementation, the initial process on Node side will take some time (30min on XO-1.5 laptop) to merge synchronization data.
 
 
 
=== Run clients ===
 
 
 
* Make sure that Node server and all clients are in the same local network, e.g., wireless Ad-hoc.
 
 
 
* Client Sugar boxes should enable ''Auto discover server in local network'' radio-box in ''Sweets Distribution'' Control Panel section.
 
 
 
* Client should see Node content as a ''Network'' content.
 
  
Current implementation is fragile in case of detecting local Node server, if Node content is not available on client side, try to restart Sugar.
+
Note that newly prepared Sugar Network volume will be empty, initial content should be fetched from the master node. Due to offline nature of this scenario, synchronization will happen via [[wikipedia:Sneakernet|sneakernet]], i.e., using synchronization files placed to regular removable volumes, e.g., USB sticks.
  
=== Synchronize Node on Sugar box ===
+
To make removable volume capable to handle synchronization files:
  
On a Node box,
+
* Create {{Code|sugar-network-sync}} directory in the root.
  
* plug Synchronization media to let Node read input and write output Synchronization packets;
+
The synchronization workflow looks like:
* wait until Sugar Shell will alert with ''Synchronization complete..'' message;
 
* unplug Synchronization media.
 
  
On a box that has Internet available,
+
# Plug prepared synchronization volume to server XO;
 +
# Wait for Sugar alert which says that synchronization is complete;
 +
# Unplug synchronization volume from server XO;
 +
# Plug synchronization volume to a machine which is connected to the Internet;
 +
# Run {{Code|sugar-network-sync}} shell script from synchronization volume (it will be created while synchronizing on server XO);
 +
# Wait until finishing script work, it will upload server XO files and download master server response;
 +
# Bring synchronization volume back to server XO and start from the 1st step.
  
* plug Synchronization media;
+
== Students' XO ==
* run {{Code|sugar-network-sync}} script (placed by Node while synchronizing) from its root and wait until it will finish uploading and downloading Synchronization packet files;
 
* then, repeat Node box steps.
 
  
== Reference distributions ==
+
In order to point students' XO to the teacher's one, enable auto server discover radio-box in ''Sweets Distribution'' section in Sugar Control Panel, or, if this sections is disabled, populate {{Code|/etc/sweets.conf}} configuration file (it might be done on XO image creation stage):
  
List of [[Deployment_Platform/Deployment#Reference_distributions|reference distributions]] that might be useful for this scenario:
+
[client]
 +
discover-server = True
  
* [[Deployment_Platform/XO_reference_distribution|XO distribution]].
+
Then, connect to wireless Ad-Hoc and in some time, F8 view will expose teacher's XO Sugar Network content.

Revision as of 08:51, 13 March 2013

Background

This is one of possible deployment scenarios of Deployment_Platform. This page is intended to describe procedures for school servers and end users in Internet-less environment. Using predefined recipes, it should be possible to fully support such deployments.

Targeting environment

The standard targeting environment, final environment might be similar, assumes:

  • Particular deployment, e.g., a school, without Internet access.
  • Lack of technical personal when in most cases only not IT skilled teachers have access to school servers.
  • Lack of dedicated hardware for school servers, server side software will be launched on teacher's XO laptop (XO-1.5 is preferred).
  • School server's client connected to school server XO using Ad-hoc wireless connection.
  • The only way to synchronize school servers with each other and with the master one, is a sneakernet.

The scenario assumes keeping Sugar Network node server launched on teacher's XO which provides Sugar Network access to students around. Teacher's and students' XO should be flashed with special Sugar with Sugar Network integration. It might be one of reference images or final deployment ones like Hexoquinasa.

Teacher's XO

Sugar Network volume

To make process of choosing server XO more flexible, entire Sugar Network node data should be stored on separate removable device, SD card of USB stick. Any XO can be turned into Sugar Network node by plugging such volume.

To make removable media capable to store Sugar Network data:

  • Create sugar-network directory in the root.

In order to make XO server capable:

  • Enable server mode checkbox in Sweets Distribution section in Sugar Control Panel, or, if this sections is disabled, populate /etc/sweets.conf configuration file (it might be done on XO image creation stage):
[client]
server-mode = True
  • Initiate Ad-Hoc wireless session from Neighborhood View in the Sugar Shell to let students connect to Sugar Network server;
  • Plug prepared Sugar Network volume.

Synchronization

Note that newly prepared Sugar Network volume will be empty, initial content should be fetched from the master node. Due to offline nature of this scenario, synchronization will happen via sneakernet, i.e., using synchronization files placed to regular removable volumes, e.g., USB sticks.

To make removable volume capable to handle synchronization files:

  • Create sugar-network-sync directory in the root.

The synchronization workflow looks like:

  1. Plug prepared synchronization volume to server XO;
  2. Wait for Sugar alert which says that synchronization is complete;
  3. Unplug synchronization volume from server XO;
  4. Plug synchronization volume to a machine which is connected to the Internet;
  5. Run sugar-network-sync shell script from synchronization volume (it will be created while synchronizing on server XO);
  6. Wait until finishing script work, it will upload server XO files and download master server response;
  7. Bring synchronization volume back to server XO and start from the 1st step.

Students' XO

In order to point students' XO to the teacher's one, enable auto server discover radio-box in Sweets Distribution section in Sugar Control Panel, or, if this sections is disabled, populate /etc/sweets.conf configuration file (it might be done on XO image creation stage):

[client]
discover-server = True

Then, connect to wireless Ad-Hoc and in some time, F8 view will expose teacher's XO Sugar Network content.