OLPC Friends/Australia's first deployment

Australia's first trial included 3 locations and connected up specialist teachers in urban Australia with children in rural and remote communities that needed specialist education services including literacy and behavioural issues. As such we believe this is the first trial in the world that has really connected up classrooms and people between remote locations, which we are really proud of!

Below is the technical documentation and when we are able to make the further details public we will. This trial is being done in collaboration with both Government and Education partners.

Technical Documentation

Below is a breakdown of the general settings, and specialist configuration of the technologies used for this trial. If the technology was to be implemented in future schools, this documentation will greatly assist in creating consistency and rapid deployments, although more integration work would also simplify the process.

Breakdown of services, software and hardware

Each school site plus the Specialist Centre have an XS (a “schoolserver”) which is a normal PC with additional software, as well as a number of XO laptops. Below is a full breakdown of the software and hardware in this trial.

Hardware

</tbody>

Location	Server PCs	Active Antenna	XO Laptops	Notes
Specialist Centre	1	1	20	Teachers, counsellors and select children while onsite have access to XOs, main function is for teachers to connect with School 1 and School 2 children remotely
School 1	1	1	45	All 40 children in the K-6 primary school have laptops, as well as the teachers with 1 to 2 machines spare.
School 2	1	1	10	5 children from disadvantaged circumstances currently have XOs as well as several teachers. These children will communicate with the Specialist Centre teachers for special education.
Education Agency	0	0	5	The Education Agency have 5 machines for testing.

Software XS (schoolserver)

Each schoolserver (XS) has the 0.4 version of the XS software as released by OLPC. Instructions for 0.4 general configuration can be found here http://wiki.laptop.org/go/XS_Configuration_Management#Example_Configurations. Below are the default software options turned on for this deployment as per the OLPC XS defaults:

• ejabberd – default setup, provides messaging between laptops, basis for collaboration services, and for remote site collaboration (by connecting a teacher at the Specialist Centre to the ejabberd service address of the supported child's school).
• Apache – serves basic page, ejabberd management (http://schoolserver:5280/admin) and the http://schoolserver/ds-restore webpages.
• DS-Backup – a tool to present the backed up journals from the laptops
• IDMGR – a tool to manage the registered users on the server
• DHCP – for the laptops only. A 172.18.x.x range which doesn't conflict with the network
• DNS – in this implementation DNS is set up with forwarders to the DNS server for each site
• SSHD – sshd is enabled on all schoolservers so they can be remotely logged into for maintenance, upgrades, troubleshooting and more

Added:

• SQUID – turned on by typing /etc/sysconfig/olpc-scripts/TURN_SQUID_ON

Software XO (laptop)

Each laptop (XO) has the following software (including version details) for the final deployment:

• 8.2 OS image – specifically build 767 with firmware version Q2E18
• Collaboration
  • Chat-47 – Chat application – no limit on participants
  • VideoChat-7 – for video chatting between laptops, locally or remotely
  • Connect-21 – Connect Four – between two laptops
  • Distance-13 – for measuring distance between two laptops (within hearing range)
  • Maze-5 – Solve the maze and optionally play with friends
• Content applications
  • WikiBrowse-9 – Mini wikipedia on the laptop for local use
  • Browse-98 – A fast streamlined web and content browser for children
  • Record-57 – For making video, audio or photos
  • Firefox-6 – A more feature rich browser for older children
  • Memorize-27 – card flipping game for memory and math. Create your own
  • Help-8 – Provides comprehensive user documentation about how to use the XO
  • License-4 – To learn about content licensing (basic) to encourage sharing
  • Gnash - the Open Source free Flash player. Note: doesn't play swf files directly, although it plays them ** fine if they are embedded in an html page
• Games
  • BlockParty-7 – Tetris
  • Implode-5 – Getting rid of groups of balls
  • JigsawPuzzle-3 – Solving Jigsaw puzzles, users can draw their own or use photos
  • Simcity-4 – Just like the original
• Miscellaneous Tools
  • Clock-2 – Digital or analog clock, you can also set an alarm
  • Calculate-23 – Calculator – includes scientific options
  • Read-51 – for reading PDF ebooks
  • Ruler-2 – measuring devices including rulers, compass and other tools
  • StopWatchActivity-1 – for timing
• Literacy
  • Speak-9 – basic app that reads aloud what it is instructed
  • Write-59 – basic application for individual or collaborative writing and tables
• Science
  • Physics-0.2 – for playing with shapes and gravity
  • x2o-5 – great extension to Physics, which sets specific challenges for students
  • Measure-19 – For measuring sound waves, or anything plugged into the microphone which doubles as a basic voltage meter – great for science experiments
• Creativity
  • Colors-3 – For drawing, and recording how to draw for sharing
  • Paint-23 – Basic painting application
  • CartoonBuilder-RC-1.7 – Basic animation tool for young children
  • FlipSticks-RC-1.4 – For basic animation of a stick figure
  • JokeMachine-8 – To build jokes and share with friends
  • TamTamEdit-49 – Music editor
  • TamTamJam-50 – Music player
  • TamTamMini-48 – Music player
  • TamTamSynthLab-50 – Music sound creator
• Development – games, animation, software
  • Scratch-9 – Great drag and drop development of games, animation and more
  • Pippy-26 – Python based development environment for children
  • TurtleArt-10 – graphical logo – for creating art with turtle instructions
  • Etoys-94 – animation and games development – for older children
• System tools
  • Analyze-5
  • Log-16
  • Terminal-17

Network diagrams

To be added (after implementation)

Custom Configuration information

Below are all the changes made to the default 0.4 image for this deployment. These can easily be reimplemented with basic tweaks for future deployments using this image. It is recommended that deployments be kept up to date with the latest stable schoolserver releases of the XS from OLPC as new functionality is coming that will simplify and improve the schoolserver, particularly in the next version which is due out soon. Schoolservers can easily be upgraded from the command line

DNS Forwarding

This implementation has internal DNS servers that we have to forward to.

• We added forwarders to the named-xs.conf at /etc/named-xs/

DNS Resolution of Other Schoolservers

Because we had three sites that all needed to talk to each other (and the education specialists needed to connect to the jabber service on the schoolservers at each school) we had to manually add the DNS entries to the local zone on each server for the other two schoolservers.

Static Network Addressing

We needed a static IP address for each server so we could confidently remotely ssh into the schoolservers.

• You do this by editing /etc/sysconfig/network-scripts/ifcfg-eth0 (assuming that the network ethernet cable is plugged into the first network device). Then reboot the server for it to work and map everything correctly

Proxy caching and authentication

Our sites have existing Proxy services that also require per user authentication (yes, even the 5 year olds have a username and password). This doesn't work with transparent proxying, so we did the following.

• We had to change the squid-xs.conf (note, not the squid.conf) file and added the following line:

cache_peer <proxy server name> parent 8080 0 no-query no-digest login=PASS

Please note that transparent proxies (as this is set up by default) cannot do client-side authentication pass through, (the login=PASS bit doesn't work) so we had to:

Comment out the following line from squid-xs.conf:

#http_port 3128 transparent

Add http://schoolserver:3128 to all the clients Browse activity (via a config script that modified the js.all file) for them to get the authentication pop up.

If all clients were using the same username and password we could put it in the schoolserver settings, but as all students have their own username and password we've had to follow this route. Plans down the track would be for this username/password once prompted in Browse to then save the information to the http_proxy environmental variable for other apps (like Map) to use.

• We then had to remove the IPTables rules that forced all traffic on port 80 to 3128 by editing /etc/sysconfig/iptables, to look like this:

#  iptables for schoolserver firewall 
#  Trial1 version 
# 
#  OLPC, March 2007 
*nat 
:PREROUTING ACCEPT [0:0] 
:POSTROUTING ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
#-A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-ports 3128 
#-A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-ports 3128 
#-A PREROUTING -i br1 -p tcp --dport 80 -j REDIRECT --to-ports 3128 
#-A PREROUTING -i br2 -p tcp --dport 80 -j REDIRECT --to-ports 3128 
-A POSTROUTING -o eth0 -j MASQUERADE 
COMMIT 
*filter 
INPUT ACCEPT [0:0] 
:FORWARD ACCEPT [0:0] 
:OUTPUT ACCEPT [0:0] 
COMMIT 

(namely, comment out the 4 REDIRECT lines referencing dport 80) by adding # to the beginning of the line

• Restart iptables by typing service iptables restart
• We also added to the Squid configuration a definition of the local XO networks as local address ranges to ensure clients could browse to http://schoolserver

Remote logins to servers

We needed remote username/password logins to the XS boxes (for backup scripts and such) as well as some additional usernames with appropriate permissions on the servers.

• Changed the sshd config file /etc/ssh/sshd_config to allow remote authentication using a password (by changing the PasswordAuthentication to yes)
• We left root remote logins disabled, created some appropriate usernames/passwords (by using the adduser command. Then we edited /etc/sudoers and added our new users with appropriate permissions.

Limiting access from unknown XO laptops to school environment

While at school, a registered laptop connected to the server can talk to any other device that has been registered to the server. All laptops deployed as part of this trial were registered, and then registration turned off to avoid unknown laptops being able to register on the server, and as such to stop unknown laptops being able to interface with the known laptops at school. By default the XO laptops can talk to anyone when on a peer to peer mesh, which is what automatically happens when a laptop doesn't connect to the schoolserver. This is in itself a risk and in future trials we would consider a MAC address lockdown of all devices managed by the schoolserver and upstream management services.

• Idmgr was stopped in the services by typing /etc/init.d/idmgr stop
• Idmgr was removed from the start up services scripts by typing chkconfig –-del idmgr
• Idmgr can be reset to the original configuration by typing chkconfig –-level 35 idmgr on

f - Security on the ds-restore page

Secure access to backed up journals

By default the ds-restore page (which lists all backups and their details) is completely open, giving anyone on the network access to the children's data.

• We added a basic username and password such that only authenticated users could view the data.
• AuthAllow All – added to the /etc/httpd/conf.d/050-ds-backup and an .htaccess added to /var/www/ds-backup/ and .htpasswd added to /etc/httpd/.
• Importantly we also had to add to the .htaccess a file definition, as there are other files in the ds-backup directory that need to be universally accessible for the backups to work. Our .htaccess file is below:

Virtual Private Network between sites

As this implementation required VideoChat between stes, but they were double NATed (big WAN and then the laptops are NATed behind the XS), so when communicating between sites VideoChat didn't work as two laptops from two different sites a) the couldn't ping each other and b) when referring to a STUN server as fallback to direct access (as is normal in the application) both laptops have the same “public” address being part of the same network WAN. As such we created VPN networks between both schools and the Specialist Centre, which fixed the networking issue. In future we would likely add a STUN service internally for VideoChat between schools.

• Installed OpenVPN to each server, set up the Specialist Centre XS as the server and the two schools as clients. All routing and VPN settings are in the /etc/openvpn/ folder on each server.

Unique Addressing in Distributed Environment

Due to the Videochat addressing issue explained in the Virtual Private Network section above, we had to also ensure all laptops were given unique IP addresses by the schoolservers serving them. So we changed the dhcp configuration file to have each site have a 172.x.0.0/16 namespace (172.18.0.0, 172.20.0.0 & 172.22.0.0).