Nepal:School Server Specification

XS Server Specification for Nepal Deployment

The School Server is still under development and it is unlikely that all of the planned features will be ready by Nepal's OLPC pilot, to start in early April 2008. This below specification represents what we hope to implement given the functionality currently stable in the school server.

General installation instructions are available here:
http://www.ibm.com/developerworks/blogs/page/InsideSystemStorage?entry=understanding_lamp_platform_for_web

School server specifications:

See XSX Server Hardware Specification

Right now, we using this term to refer to any hardware platform meeting the following criteria:

• 1GHz+ x86 processor
• 1 GB main memory
• Four to six USB interfaces, with power for three Marvell Wifi nodes and an external disk drive.
• One 300GB+ 3.5in SATA drive (500 GB makes more sense right now)
• Power and space for a second disk drive
• Two 100baseT network interfaces (one will do in some cases)
• Minimal fans

System should either "boot from USB" or have a CD-ROM/Burner drive that can be used to boot from CD.

---

/****************** Greg, I left this in so that you can edit or keep as appropriate
Here is what we intend to use in Nepal for the school server hardware

1 - Server: Intel or AMD at least 2 g, at least 300gb hard rive,  (how many?) USB ports, 
 DVD or  CD ROM drive. Do we want a CD/DVD burner?

2 - Active Antennas [One for each mesh]

3 - Internet connection needs a router (wireless can add access for normal laptops), and is
provided  through Wifi or VSAT.

4 - Network Cables (cat5, cat6 with RJ45 connectors, and 5m USB cable for active antenna (the
antenna comes with the cable attached).

5 - Power adapters. [ A detailed specification needs to written on power solution for the XS,
especially in a school environment, and the classroom environment, (district level?)--get help
from Joshua?]
******************************************************/

---

The Nepal implementation will include two school servers in the same building (Sulochan or Bryan to confirm). The plan is to have two XSX servers: XS2 for second graders, and XS6 for sixth graders.

Network Topology

A local Nepali Internet Service Provider will provide internet connectivity, terminated at cable modem or VSAT connection. The school servers will not have a static IP address. The school servers will not be accessible from the outside internet.

Zone Configuration

The Network topology is divided into three parts:

 =====(Modem)-------(Hub1)-------(XS2/XS6)-------(Mesh)-- XOs
 WAN ---> <-- red zone - - - - - - - > <- - - - - green zone ->

• WAN - Wide Area Network provided by ISP to access outside internet

The library server(s) for Nepal will be in a central location on the WAN.

• Red Zone - Access to teachers and administrators via Hub1 (Wired School Network)

Hub1 can be a 4-port Ethernet Hub (with or without WiFi). This subnet would have static addresses for XS2, XS6, perhaps a network printer, and any guest or admin with their own laptop or PC. Connection to the red zone provides unfiltered full access to the internet, and is intended only for adults: teachers, administrators, and so on.

Students will not have access to the red zone.

A WEP-enabled WiFi would allow visiting adult guests with laptops to have access to the red zone, and allow teachers to access red zone via their XO laptop. These can be DHCP assigned by the Hub1 device.

• Green Zone - Access to students via XO over Mesh Antenna

XS2 will have three active antennas: Mesh 1, Mesh 6, and Mesh 11 XS6 will have three active antennas: Mesh 1, Mesh 6, and Mesh 11

The green zone represents cached, filtered content. It will include access to Moodle, shared files, cached Library server content, and filtered access to the rest of the internet.

Server Configuration

There are two ways to configure XS2 and XS6.

• The first way is to have XS2 be the primary server, and XS6 be the alternate server

See diagram XS Server Services. This makes the primary server the single point of failure for the entire school. In the event XS2 fails, someone could reconfigure XS6 to be the primary, but this would involve changing cables around as needed.

• A second way is to have both XS2 and XS6 on the red zone, both connected to Hub1

This provides direct access to the ISP Modem for external access to the internet. In this configuration, if either XS2 or XS6 are down, the other remains unimpacted. XS2 can send critical files as backups to XS6, and XS6 could send its critical files to XS2. In the event either fails, access to all files would be a matter of changing a few files around, no changes to cabling required.

Students would not have access to the red zone. Instead, they will have access via green zone, which has cached and filtered content age-appropriate for their grade level.

Network Modules:

1. Domain Name Service (DNS)
2. Dynamic Host Configuration Protocol (DHCP) (the ip range should not overlap if there is more than one XS.)
3. Mesh Network specification. (How many mesh ports? How many XO's are designated for each mesh?)
4. Active Antennas (One for each mesh)
5. Internet connection needs a router (wireless can add access for normal laptops), and is provided through Wifi or VSAT.
6. Network Cables (cat5, cat6 with RJ45 connectors, and 5m USB cable for active antenna (the antenna comes with the cable attached).
7. Power adapters. ( A detailed specification needs to written on power solution for the XS, especially in a school environment, and the classroom environment, (district level?)--get help from Joshua?)

Core Software:

OS and base image: XS server build OLPC_XS_150.iso on Fedora 7

1. Apache v2
2. DNS
3. DHCP
4. Moodle 1.8.4
5. PHP v5
6. MySQL 5.0
7. Squid 2.6 (HTTP Cache)
8. Content Filtering - http://dansguardian.org/
9. Nepali Language eToys actvities - http://www.olenepal.org/activities_download.html
   1. Animal Identification
   2. Alphabet Puzzle
   3. Addition, numeric
   4. Addition, word problem
   5. Addition upto 10, game
   6. Counting Sheep
   7. Largest Number
   8. Make Bar-graph
   9. Matching
   10. Numeric Puzzle

Requirements and Specifications for core software

1 Apache

Suggested directory structure for single school server
/var/www/html/ <--- this is the high level directory.
/var/www/html/index.php <--- this is the default home page.
/var/www/html/moodle <--- this is moodles directory
/var/www/html/moodle/index.php <-- this is the Moodle home page

Two school server directory and web site design:

XS2 server for 2nd graders
XS6 server for 6th graders

(a) this has the advantage of running different library caches, different guardian-lists, etc. that are age-appropriate. (b) if one XS fails, only one grade is affected. That grade can then do "offline" activities with their XO. Teachers will still be able to do their work using the other XS, and if any student needs to update an activity, could be done on an exception basis connecting to the other XS server.

Suggested directory structure for two (or more) school servers

On XS2 server
/var/www/html/index2.php --- unique to second graders like "Welcome to 2nd Grade OLPC class"
/var/www/html/moodle2 --- directory for moodle 2nd grade class lesson plans
/var/www/html/moodle6 --- backup directory for moodle 6th grade class lesson plans (not used unless XS6 is down)

cron -- send moodle2 files over to XS6 machine

On XS6 server
/var/www/html/index6.php --- unique to second graders like "Welcome to 6th Grade OLPC class"
/var/www/html/moodle2 --- backup directory for moodle 2nd grade class lesson plans (not used unless XS2 is down)
/var/www/html/moodle6 --- directory for moodle 6th grade class lesson plans

cron -- send moodle6 files over to XS2 machine

cron jobs could be used to SCP data between the two servers to backup each others lesson plans.

Teachers can access moodle directories as follows (change pinewood.net to local domain):

http ://XS2.school.pinewood.net/moodle2
http ://XS6.school.pinewood.net/moodle6

We can make /moodle point to the correct one on each machine.

2 DNS

Local with forwarders set to resolve any unknown ip/domain name. Will school servers use global DNS? If so what is the root name and where is the DNS resolver for that? If not, we can setup a local DNS resolution so that web sites still resolve if the school is disconnected from the internet.

3 DHCP

Used only to assign IPs to Xos and enable routing to XS, library server and internet. [the ip range should not overlap if there is more than one XS.]. See also single sign on work around below.

4 Moodle 1.8.4

Moodle main class page Includes learning objectives for next six months. Includes links to each activity and lesson plan main page.

Moodle home page for each activity.
• Each lesson plan has its own home page in moodle.

• Teacher places days activity in easy to access location so that all students can launch “lesson plan” home page. Preferred, lesson home page in moodle visible, from main actvity panel at bottom of screen. Acceptable that Activity launch page shows up on browse activity but must be easy to launch (aka no typing in URLs).
• Teacher can publish link to lesson plan so it shows up on all XOs in the class.
• Students open lesson plan with one click - Should we update the base OLPC home page to have a link to Moodle?
• Students see one version of the lesson plan home page. Teachers see different version. Preferred to have single URL for both and identity knows which client (XO) is teacher and which is student and displays appropriate page without user name/pass or other prompt. Acceptable to have teacher URL and student URL.
(* how does teacher learn special URL? Type in to browser, same as student but with standard additional text? *)

• All Moodle and activity content resides on XS
• Launch of actvity must use local copy if unchange. If changed should get latest copy from XS.
(* never go out over WAN for updates? *)

Teacher or admin can easily post updated activities to XS

Must have search page on school server which checks for content in library. (* school specific or Nepal wide? Checks library only or library and internet or library and OLPC wiki and internet? *)

Must have a browse content link to walk through the library content by subject.

No e-mail required.

Other Moodle requirements not related to a specific course - Moodle web site top level will have a page for the whole school - Each class will have a class page - Each class and the whole school will have a "group" concept. Relevant students will be assigned to each group by XS administrator. - Each group will have a blog and a forum. - Each group will have a place where files can be shared. - Any member of the group will be able to upload files to the shared space - Teacher will have a special place to put their files

Other ideas for Moodle server:

1. Understand the use of Moodle in a (Nepali) teaching-learning process. How to use it? Is going to add a sense of burden for teachers? If so how do we integrate it to the existing philosophy of pedagogy of the teacher?
2. How to make it simple enough for students so that they feel comfortable using it?
3. Implementation?

See also Moodle write up at: http://blog.olenepal.org/index.php/archives/124

See also SSO open issues below.

GS - I think there is another Moodle write up by Martin L., need URL

5 PHP

Used only for Moodle until other web site are built.

6 MySQL

Used only for Moodle, especially Authentication until other web sites or uses defined.

7 HTTP Cache – squid?

- Custom values for library server URLs. That is, must flush library server content last when cache runs out of space.
- Has to cache any XO activities
- XO needs to be able to tell if .xo already installed when clicked from a hyperlink in Moodle. If activity already downloaded to the Journal, XO doesn't download it a new.

8 Content Filtering - http://dansguardian.org/

- Blocks inappropriate sites and updates block list automaticaly on a regular basis.
- Allows manual addition of blocked URLs by domain name including sub-domains.
- Allow admin intervention to apply white list (AKA only those sites on the list are allowed) on the fly at any time.
- Blocks access to actvities as well. Including ways to block to certain activities, like Doom --- Must have a white list and black list for activities.

9 Activities

- Kids should be able to change activity (e.g. eToys) and upload changed activity for access by others. Should have way to know which activities is different from original just by looking at it (e.g. icon on screen) for easy troubleshooting by teachers.

- Need way to automatically change version of an activity once kid, or anyone else modifies it. We want kids to be able to change their activities and break them, but it must be very easy to go back to the original version.

Other Requirements

XS Backup Requirements

Must have a process to reflash XO laptops remotely.

XS must backup all of students work. There should be a simple process to re-image a students XO from XS with all student created content preserved.

No content specific to a particular student (e.g. content they created, their place in the lesson, IP address, journal histroy, XO backup) should reside outside the schools own XS, unless specifically posted by student/teacher.

XS access allowed from internet or only Nepal WAN? Only SSH port open on school server. Run port scan/ linux security tool (which one?)

XS should have clean XO image which can be copied to a USB drive. Need instructions for re-imaging XO from XS image and/or from USB drive. All re-imaging can be done from USB intially. Nice to have process to re-image XO over mesh. After clean image is loaded user specific content can be easily loaded (no login, user name?)

XS must have copies of all XO activities. Updated activities get pushed to XS and automaticaly updated on Xos on next launch. Teacher and Nepal admin can easily add actvities or updated versions of existing activities to XS

Localization

- A set of learning activities will be developed in Nepali. - Its desired that GUI interfaces in Moodle Nepali but that can be targeted for a future phase. Hindi script may work for the characters (to be confirmed).

Single Sign On and Authentication

- Authentication: Use auto-login so that students dont have to remember their login info and/or how to get to the course page.
- Integrate with Moodle (see Moodle requirements above)
- Allow backup and restore of user generated data (see requirements above)
- For each XO, it could determine the default username, based on the XO serial number/UUID, browser cookies, or whatever.
- Allow an override, so that if another student's laptop is down, they could enter their username/password onto a fellow student's laptop, and access their files that way
- In the event a broken laptop is replaced with a new laptop, there are administration ways to indicate that this is now the default username for this laptop, and to re-attach or re-assign the folders/files accordingly.

One suggestion for SSO solution:

Use auto-login so that students dont have to remember their login info and/or how to get to the course page.

I am using a simple HTML to do that:

<*html><head></head><body>

<form action= "http://www.sugaroffice.ole/moodle/login/index.php" method="post">

<input type="hidden" name="username" id="username" value="olenepal" />

<input type="hidden" name="password" id="password" value="olenepal" />

<input type="submit" value="Login" />

</form> </body>

</html>
This HTML page will be added to the sugar-interface of the XO. When clicked by user: olenepal, it will take him to the group course page that he belongs to. Security is not a concern here (I think) because student wont have a personal page. It will be use more like a community forum, and all students within a group will have the same login. Separate groups will have separate login. Drawback of doing so: This HTML file has to be manually added to all the XO's.

A second idea: Use DHCP manual configuration to staticaly map IP addresses to MAC addresses.
http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Servers/DHCP?highlight=%28dhcp%29
That ensures that a laptop always comes back with the same IP address. Downside is that someone has to create MAC - IP map in DHCP server and may need to add a student name to that table too. Open questions on this:
Does available DHCP server support manual mapping?
Does Moodle/MySQL support user identity based on IP address?

Other SSO and SSO - Moodle comments
- Simplify the UI. Take out modules that are not needed for a particular group.
- For authentication use a mysql database. Account will be manually created by Moodle administrator prior to student using this feature. Teachers have the “role” of a editing teacher in Moodle. Self registration to Moodle, and into courses (for those have login) is disabled.
- The teacher-training package being developed by OLE Nepal team will not include for the first phase of training. Will be deployed a month later.
- SSO and Id manager can greatly improve the overall auth feature. We can then use the id given by the Id manager to login to moodle as well as others.

XS Network Access

- XS sever should have static IP address routable from the Internet.

Suggested in school network design

A--I suggest instead (modem)--(WiFi)--(XS)--(Mesh) A simple four-port hub could support 4 direct-connect items (an XS server, a Library server, a printer, etc.) and over 200 Wireless.

B--For normal operations, a WEP key can prevent any XO laptop from using the Wireless directly. Instead, they use the XS server, which has all the squid cache, library server cache, etc. The WEP key can be provided to teachers to access the system directly via WiFi from their laptops.

C--In the even the XS is down, or the Mesh Active Antenna is down, a teacher can turn off WEP (by accessing the Wifi hub from their laptop), and open the WiFi up to all XO laptops. This would also mean no content filtering, squid caching, etc.

D--Alternatively, leave the WEP key in place, and if a student needs to update an activity during the time the XS server is down, the teacher can either download the XO file on their behalf and send it to them via mesh, or enter the WEP key on the student's XO for that exception. In this mode, everyone just uses their XO and meshes with each other, but has no access to the outside internet, moodle or the library cache.

A step up from this would be: (modem)--(Wifi 1)--(XS)--(Wifi 2 + Mesh)

This configuration above was recommended by John W. for deployments above 150 XOs
(ISP)---(hub)----eth0 [XS w/NAT]eth1 ----- (WiFi)----[ XO ]

In this environment, WiFi 1 would be WEP-protected, teachers only. WiFi 2 would be open, and complement the Mesh of the XS. In the event that the Mesh Active Antenna failed, students could use WiFi2 without any significant changes. In the event XS fails, Wifi2 could be cabled to Wifi 1, allowing all students to access the internet, unfiltered, uncached.

This approach has the advantage that if we don't know how many XO laptops each antenna can handle, the WiFi 2 can certainly handle 200 or more IP addresses. Kind of like an insurance policy to ensure success.

Things that needs to be solved:

1. Get Id manager to work (Contact Ivan Krstic) for the authentication (SSO) to manage all network logins.
2. Test the range of XO-XO, and XO-XS wireless range? (Some report up to 1 Km range, James Cameron <quozl@laptop.org>, in rural Nepali village setting this might go down to 500m.)
3. Understand the school setting. We need to know where to physically place the active antennas as this might affect the range. Outside the building (see how guys in Peru did it) inside the class room, the exact location etc.
4. How do we provide internet access to the XS (or school)?
5. Test squid with school server.

Strategy for Redundancy

See this link for a set of requirements and design suggestions for reliability.

Possible Test Plans

1 - Test the process of an admin adding an activity. (XO and XS) - Activity should be downloadable on each XO (from Browse activity link?) - Note in relevant Moodle groups and forums should appear anouncing activity. - Student should be able to load activity from link in Moodle. - Test that any moodle link should pull from cache on school server.

2 - Test each core activity (build list) on at least a few samples Xos. (XO only)

3 - Set of tests on each XO for initial delivery. (XO only) - Should be a script which as automated as possible. - Run battery diagnostic - Run keyboard diagnostic. - Run connectivity check

4 - Moodle test plan (XO and XS) - Click on all links - test teacher page

5 – Test what happens when a student modifies an activity - Kids should be able to change activity (e.g. eToys) and upload changed activity for access by others. Should have way to know which activities is different from original just by looking at it (e.g. icon on screen) for easy troubleshooting by teachers. Kids should be able to

6 – Test re-image of XO via USB and then restore of all student specific work.

7 - XS Bootup and Initial Test - Boot up and login via SSH on console connection - Login ove network.

8 - Network access tests XO-XS connectivity through a wireless (Belkin) router works. DNS works. Apache web services works. Moodle works (more work on moodle). DHCP through the server needs testing. Need active antennas to test mesh. XO-XO communication works, testing needs to be done for range.

Test the range of XO-XO, and XO-XS wireless range? [Some report up to 1 Km range, James Cameron, in rural Nepali village setting this might go down to 500m.]

Test internet access from XS

9 - Test squid with school server.

Test Results:

• XO-XS connectivity through a wireless (Belkin) router works.
• DNS works.
• Apache web services works.
• Moodle works (more work on moodle).
• DHCP through the server needs testing. Need active antennas to test mesh.
• XO-XO communication works, testing needs to be done for range.

School Server Use Cases

Teachers will use the activities in the classes to aid in the teaching-learning process. Since our activities follow the curriculum, the students will be using the same application at the same time. In a typical class, the teacher will start a class with the lesson, and then ask the children to do the activities in the laptop after introducing the concept. Kids can also try out the activities later after school from home or elsewhere. Since the activities will be in the server, it is essential that the network is robust and well-tested. The last thing we want is for kids and teachers to be frustrated by slow and under-performing network.

We have had a number of discussions here about the use of Moodle for manage the activities. The key here is to keep it simple and less cumbersome for teachers and students. In addition to the regular activities that we have on the server, we need to have an easy mechanism for students to store and share their own creations; however, we are thinking that it might be a good idea to wait few months before adding this feature to give time for the kids to get used to the moodle environment.

Networking School Server Related Files

See Files: /home/sulo/xs_networking_local.doc
/home/sulo/xs_networking_regional.doc
/home/sulo/doe_wireless_plan.doc

Teachers Training for the Pilot: See Files: /root/Desktop/Teacher_Training_Course_Outline_improved_Jan_08.doc
note: will extract and add to new Wiki page soon **