User:Holt/XS Community Edition/0.1/Project Specifications: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Created page with 'School Server - Community Edition 0.1 Project Specifications Executive summary The school server is very similar in concept to a standard home wireless router. In everyday usag…')
 
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
School Server - Community Edition 0.1 Project Specifications
School Server - Community Edition 0.1 Project Specifications


Executive summary
==Executive summary==


The school server is very similar in concept to a standard home wireless router. In everyday usage it provides various services which extend capabilities of the connected laptops while being totally transparent to the user.
The school server is very similar in concept to a standard home wireless router. In everyday usage it provides various services which extend capabilities of the connected laptops while being totally transparent to the user.


These services can include:
These services can include:
<ul>
1. Security – XO related security services.
2. Network connection – various services similar to what you would find in a home router.
<li> Network connection – various services similar to what you would find in a home router.
3. Presence server – Augments sugar's native collaboration functionality.
<li> Presence server – Augments sugar's native collaboration functionality.
4. Web filtering – Enables schools to comply with local legal restrictions on internet access for children.
<li> Web filtering – Enables schools to comply with local legal restrictions on internet access for children.
<li> Security – XO related security services.
5. Content management -- ???
<li> Content management -- ???
</ul>


Reference User
==Reference User==


For the purposes of this document, I am taking OLPC-AU as the reference user. As a result this design might not apply in all situations in all deployments. This imposed limitation will make it is easier to design and develop a working reference implementation.
For the purposes of this document, I am taking OLPC-AU as the reference user. As a result this design might not apply in all situations in all deployments. This imposed limitation will make it is easier to design and develop a working reference implementation.
Line 18: Line 20:
If we use proper modularity it will be relatively straightforward to abstract the design and implementation to meet other use cases.
If we use proper modularity it will be relatively straightforward to abstract the design and implementation to meet other use cases.


Hardware
==Hardware==


To reduce inventory and maintenance costs, the target hardware for the school server will be recent XO laptop. Due to hardware limitations on early XO's, design and implementation of a fully functional server becomes difficult on them.
To reduce inventory and maintenance costs, the target hardware for the school server will be recent XO laptop. Due to hardware limitations on early XO's, design and implementation of a fully functional server becomes difficult on them.


In common usage, the XO may be augmented by two off the shelf USB devices:
In common usage, the XO may be augmented by two off the shelf USB devices:
<ul>
1. External hard drive – Allows the server to provide additional storage capabilities.
2. Network connectorAllow the server to offer internet access to connected XO's.
<li>External hard driveAllows the server to provide additional storage capabilities.
<li>Network connector – Allow the server to offer internet access to connected XO's.
</ul>


Using this strategy it is simple for a deployment to inventory and maintain school servers. A school can replace a school server by taking a standard XO and running a single server setup command.
Using this strategy it is simple for a deployment to inventory and maintain school servers. A school can replace a school server by taking a standard XO and running a single server setup command.
Line 30: Line 34:
NOTE: Limiting the hardware to XO simplifies the implement and testing process because their fewer possible configurations to deal with. Supporting multiple platform would be a good for a future release.
NOTE: Limiting the hardware to XO simplifies the implement and testing process because their fewer possible configurations to deal with. Supporting multiple platform would be a good for a future release.


Deliverable
==Deliverable==


The final deliverable from the community will be an image which can be flashed onto a laptop by deployment support staff.
The final deliverable from the community will be an image which can be flashed onto a laptop by deployment support staff.
Line 40: Line 44:
NOTE: Projects tend to emphasize packages while Products tend to emphasize images.
NOTE: Projects tend to emphasize packages while Products tend to emphasize images.


OS
==OS==


To keep things simple and consistent the school server will run the same OS as the classroom laptops. Both teachers and support staff will already be familiar with the system.
To keep things simple and consistent the school server will run the same OS as the classroom laptops. Both teachers and support staff will already be familiar with the system.
Line 46: Line 50:
NOTE: Limiting the deliverable to single OS variant meets the requirement to work on a XO while limiting complexity. Future releases can add additional Operating Systems.
NOTE: Limiting the deliverable to single OS variant meets the requirement to work on a XO while limiting complexity. Future releases can add additional Operating Systems.


User Interface
==User Interface==

Browser based GUI. – The primary configuration tool will be a browser based GUI. This technology is well understood by developers. Many end uses have familiarity with Browser based setup.

A browser based allow admin from three physical proximity distances:
1. On screen. Initial setup and admin of security sensitive services can be limited to on screen.
2. On site. Subsequent management of non security sensitive services can be done by a teacher or local admin logging in to the machine.
3. Remote. Deployment level support staff can log in and remotely maintain and monitor services.

Remote automation – There are several system such as CFEngine and puppet which enable remote management. While not immediately required by AU it is highly desirable by large deployment.


Command Line – Command line configuration should be discouraged at all levels. Target users are often not familiar with the linux system administration. Initial setup or fixing a problem with their server is not a good time to introduce system administration skill.
Command Line – Command line configuration should be discouraged at all levels. Target users are often not familiar with the linux system administration. Initial setup or fixing a problem with their server is not a good time to introduce system administration skill.
Line 61: Line 56:
NOTE: Is is possible or useful to create a Sugar base configuration tool?
NOTE: Is is possible or useful to create a Sugar base configuration tool?


Modular design
==Modular design==


One of the key design criteria of all successful community based projects is modularity. The original XS suffered because Wad and Martin took used monolithic design overcome hardware limitations on the XO-1. The improvements in the XO-1.75 and XO-4 allow for the potential inefficiencies of modularity.
One of the key design criteria of all successful community based projects is modularity. The original XS suffered because developers took used monolithic design overcome hardware limitations on the XO-1. The improvements in the XO-1.75 allow for the potential inefficiencies of modularity.


==Core Server==
The core server will contain 3 components:
1. Initial setup and configuration.
2. GUI framework.
3. Core services with GUI panels.
The core server will be extended via extended services.


The core server will contain 5 components which can be extended via extended services.
Initial Setup


Service: Network setup
Service: Network setup<br>
Purpose:
Purpose: <br>
Provider: xs-setup-network
Provider: xs-setup-network <br>


Service: Dynamic Host Configuration Protocol<br>
GUI Framework
Purpose: Schoolserver and clients need to be on same subnet.<br>

The GUI permits permits configuration of the network interfaces:
Already existing network and internet gateway
Choose fixed ip and gateway
use dhcp automatic assignment
Establish a gateway to the internet, setup WAN and LAN:
Use dhcp to setup WAN
Manually setup WAN address, gateway, dns
Use either of the above methods to set up LAN
It permits enabling and disabling of services -- supported and enabled for this release are dhcp, iptables/gateway, named, ejabberd.

Core Services

Service: Dynamic Host Configuration Protocol
Purpose: Schoolserver and clients need to be on same subnet.
Provider: dhcpd
Provider: dhcpd


Service: Iptables -- Network Address Translation (NAT)
Service: Iptables -- Network Address Translation (NAT)<br>
Purpose: Permits all XO’s to access the internet
Purpose: Permits all XO’s to access the internet.<br>
Provider: gateway
Provider: gateway


Service: Internet domain name server
Service: Internet domain name server<br>
Prupose:
Prupose: <br>
Provider: named
Provider: named <br>


Service:Jabber server (AnnaS)
Service:Jabber server <br>
Purpose: collaboration > 15 clients needs to work
Purpose: collaboration > 15 clients needs to work. <br>
Provider: ejabberd
Provider: ejabberd

Extended Services

Service: proxy server and web cache (XavierC)
Purpose: bandwidth, web-filtering, web-monitoring
Provider: squid

Service: Content filtering (TimM??)
Purpose: age-appropriate surfing, legal compliance, religious risks
Provider: dansguardian

Service: Backup of student work and restore (JerryV, SameerV, GeorgeH)
Purpose: also for stats/metrics, with incumbent surveillance risks
Provider: idmgr

Service: (JerryV, GeorgeH)
Purpose: Journal submissions to teacher, academic record (homework etc)
Provider: WebDAV

Service: (DSD, GeorgeH)
Purpose: remote upgrading/admin of XS servers (semi-automated)
Provider: Puppet

Service: (GeorgeH, GeraldA)
Purpose: local distribution/replication of Sugar Activities etc
Provider: pdsh

Service: Book server (SameerV, AlexK, GeorgeH struggling!)
Purpose: compete with Khan Academy?
Provider: pathagar

Latest revision as of 20:01, 8 February 2013

School Server - Community Edition 0.1 Project Specifications

Executive summary

The school server is very similar in concept to a standard home wireless router. In everyday usage it provides various services which extend capabilities of the connected laptops while being totally transparent to the user.

These services can include:

  • Network connection – various services similar to what you would find in a home router.
  • Presence server – Augments sugar's native collaboration functionality.
  • Web filtering – Enables schools to comply with local legal restrictions on internet access for children.
  • Security – XO related security services.
  • Content management -- ???

Reference User

For the purposes of this document, I am taking OLPC-AU as the reference user. As a result this design might not apply in all situations in all deployments. This imposed limitation will make it is easier to design and develop a working reference implementation.

If we use proper modularity it will be relatively straightforward to abstract the design and implementation to meet other use cases.

Hardware

To reduce inventory and maintenance costs, the target hardware for the school server will be recent XO laptop. Due to hardware limitations on early XO's, design and implementation of a fully functional server becomes difficult on them.

In common usage, the XO may be augmented by two off the shelf USB devices:

  • External hard drive – Allows the server to provide additional storage capabilities.
  • Network connector – Allow the server to offer internet access to connected XO's.

Using this strategy it is simple for a deployment to inventory and maintain school servers. A school can replace a school server by taking a standard XO and running a single server setup command.

NOTE: Limiting the hardware to XO simplifies the implement and testing process because their fewer possible configurations to deal with. Supporting multiple platform would be a good for a future release.

Deliverable

The final deliverable from the community will be an image which can be flashed onto a laptop by deployment support staff.

At initial server 'power on' the support staff or teacher will be greeted by a simple GUI to do initial configuration.

A single RPM or meta package necessary to convert a standard XO into a School Server should also be possible.

NOTE: Projects tend to emphasize packages while Products tend to emphasize images.

OS

To keep things simple and consistent the school server will run the same OS as the classroom laptops. Both teachers and support staff will already be familiar with the system.

NOTE: Limiting the deliverable to single OS variant meets the requirement to work on a XO while limiting complexity. Future releases can add additional Operating Systems.

User Interface

Command Line – Command line configuration should be discouraged at all levels. Target users are often not familiar with the linux system administration. Initial setup or fixing a problem with their server is not a good time to introduce system administration skill.

NOTE: Is is possible or useful to create a Sugar base configuration tool?

Modular design

One of the key design criteria of all successful community based projects is modularity. The original XS suffered because developers took used monolithic design overcome hardware limitations on the XO-1. The improvements in the XO-1.75 allow for the potential inefficiencies of modularity.

Core Server

The core server will contain 5 components which can be extended via extended services.

Service: Network setup
Purpose:
Provider: xs-setup-network

Service: Dynamic Host Configuration Protocol
Purpose: Schoolserver and clients need to be on same subnet.
Provider: dhcpd

Service: Iptables -- Network Address Translation (NAT)
Purpose: Permits all XO’s to access the internet.
Provider: gateway

Service: Internet domain name server
Prupose:
Provider: named

Service:Jabber server
Purpose: collaboration > 15 clients needs to work.
Provider: ejabberd