Nepal:School Server Specification
XS Server Specification for Nepal DeploymentThe 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 and set of requirements represents what we hope to implement in phase 2 (after April) in the school server. General Linux installation instructions are available here: Links to XS configurations are available here: Main school server page is here: Instructions for downloading and building School Server software is here: Nepal test setup diagram is here: Nepal example install scripts are here: Example install scripts from Uruguay are posted here: http://dev.laptop.org/git?p=projects/ceibal-scripts;a=tree Nepal School server specifications:See XSX Server Hardware Specification Right now, we using this term to refer to any hardware platform meeting the following criteria:
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 TopologyA 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 ConfigurationThe Network topology is divided into three parts: =====(Modem)-------(Hub1)-------(XS2/XS6)-------(Mesh)-- XOs WAN ---> <-- red zone - - - - - - - > <- - - - - green zone ->
The library server(s) for Nepal will be in a central location on the WAN.
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.
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 ConfigurationThere are two ways to configure XS2 and XS6.
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.
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:
Core Software:OS and base image: XS server build OLPC_XS_150.iso on Fedora 7
Requirements and Specifications for core software1 ApacheSuggested directory structure for single school server Two school server directory and web site design: XS2 server for 2nd 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 cron -- send moodle2 files over to XS6 machine On XS6 server 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 We can make /moodle point to the correct one on each machine. 2 DNSLocal 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 DHCPUsed 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.4Moodle 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. • 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).
• All Moodle and activity content resides on XS 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:
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 PHPUsed only for Moodle until other web site are built. 6 MySQLUsed 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. 8 Content Filtering - http://dansguardian.org/- Blocks inappropriate sites and updates block list automaticaly on a regular basis. 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 RequirementsXO Backup RequirementsMust 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 Design suggestion: As for backing up the /home directory from the XO to the XS, I was envisioning a PHP page on the server that the student could navigate to, and this would perform the file upload. It would require the students to take action to cause this to happen. It sounds like an automated solution would be better, but how did you want this to be kicked off, once per day? One suggestion on timing is to allow teacher or admin to trigger backup when they know XOs are inactive. 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. 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>
A second idea:
Use DHCP manual configuration to staticaly map IP addresses to MAC addresses. Other SSO and SSO - Moodle comments 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 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:
Strategy for RedundancySee this link for a set of requirements and design suggestions for reliability. Possible Test Plans1 - 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:
School Server Use CasesTeachers 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. Power is only on for 14 hours a day in Nepal. So XS should boot directly to the correct running configuration from a cold start with no login ot intervention. Also need to be sure that it recovers completely from any cut off of power. Networking School Server Related FilesSee Files:
/home/sulo/xs_networking_local.doc |
