Nepal:School Server Specification: Difference between revisions
No edit summary |
(add deprecated header) |
||
(41 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{Deprecated |See [[OLPC Nepal]]}} |
|||
== XS Server Specification for Nepal Deployment == |
== XS Server Specification for Nepal Deployment == |
||
The [[School_server|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 |
The [[School_server|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: <br> http://www.ibm.com/developerworks/blogs/page/InsideSystemStorage?entry=understanding_lamp_platform_for_web |
|||
<br> |
|||
Links to XS configurations are available here: |
|||
== School server specifications: == |
|||
*[[XS Configuration Management]] |
|||
Main school server page is here: |
|||
The [[School_Server_Specification#Hardware|School Server Hardware Specification]] currently is out-of-date |
|||
*[[School server]] |
|||
Instructions for downloading and building School Server software is here: |
|||
Here is what we intend to use in Nepal for the school server hardware |
|||
*[[XS Server Software]] |
|||
Nepal test setup diagram is here:<br> |
|||
Server: |
|||
http://wiki.laptop.org/go/User:Az990tony/nepal <br> |
|||
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? |
|||
(topology diagrams and details of Nepal project) <br> |
|||
Nepal example install scripts are here: <br> |
|||
2 - Active Antennas [One for each mesh] |
|||
http://wiki.laptop.org/go/User:Az990tony/scripts <br> |
|||
(scripts under MIT license)<br> |
|||
Example install scripts from Uruguay are posted here: |
|||
3 - Internet connection needs a router (wireless can add access for normal laptops), and is provided through Wifi or VSAT. |
|||
http://dev.laptop.org/git?p=projects/ceibal-scripts;a=tree |
|||
== Nepal School server specifications: == |
|||
4 - Network Cables (cat5, cat6 with RJ45 connectors, and 5m USB cable for active antenna (the antenna comes with the cable attached). |
|||
See [[XS_Server_Specification#XSX_Specifications|XSX Server Hardware Specification]] |
|||
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?] |
|||
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#Network_Router|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: == |
== Network Modules: == |
||
Line 30: | Line 130: | ||
# Network Cables (cat5, cat6 with RJ45 connectors, and 5m USB cable for active antenna (the antenna comes with the cable attached). |
# Network Cables (cat5, cat6 with RJ45 connectors, and 5m USB cable for active antenna (the antenna comes with the cable attached). |
||
# 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?) |
# 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: == |
== Core Software: == |
||
OS and base image:XS server build OLPC_XS_150.iso on Fedora 7 |
OS and base image: XS server build OLPC_XS_150.iso on Fedora 7 |
||
# Apache |
# Apache v2 |
||
# DNS |
# DNS |
||
# DHCP |
# DHCP |
||
# Moodle 1.8.4 |
# Moodle 1.8.4 |
||
# PHP |
# PHP v5 |
||
# MySQL |
# MySQL 5.0 |
||
# Squid 2.6 (HTTP Cache) |
|||
# HTTP Cache – squid? |
|||
# Content Filtering - http://dansguardian.org/ |
# Content Filtering - http://dansguardian.org/ |
||
# Nepali Language eToys actvities - http://www.olenepal.org/activities_download.html |
|||
## Animal Identification |
|||
## Alphabet Puzzle |
|||
## Addition, numeric |
|||
## Addition, word problem |
|||
## Addition upto 10, game |
|||
## Counting Sheep |
|||
## Largest Number |
|||
## Make Bar-graph |
|||
## Matching |
|||
## Numeric Puzzle |
|||
== Requirements and Specifications for core software == |
|||
=== 1 Apache === |
|||
Suggested directory structure for single school server <br> |
|||
/var/www/html/ <--- this is the high level directory. <br> |
|||
/var/www/html/index.php <--- this is the default home page. <br> |
|||
/var/www/html/moodle <--- this is moodles directory <br> |
|||
/var/www/html/moodle/index.php <-- this is the Moodle home page <br> |
|||
Two school server directory and web site design: |
|||
XS2 server for 2nd graders <br> |
|||
XS6 server for 6th graders <br> |
|||
(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 <br> |
|||
/var/www/html/index2.php --- unique to second graders like "Welcome to 2nd Grade OLPC class" <br> |
|||
/var/www/html/moodle2 --- directory for moodle 2nd grade class lesson plans <br> |
|||
/var/www/html/moodle6 --- backup directory for moodle 6th grade class lesson plans (not used unless XS6 is down) <br> |
|||
cron -- send moodle2 files over to XS6 machine |
|||
On XS6 server <br> |
|||
/var/www/html/index6.php --- unique to second graders like "Welcome to 6th Grade OLPC class" <br> |
|||
/var/www/html/moodle2 --- backup directory for moodle 2nd grade class lesson plans (not used unless XS2 is down) <br> |
|||
/var/www/html/moodle6 --- directory for moodle 6th grade class lesson plans <br> |
|||
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 <br> |
|||
== Requirements for core software == |
|||
http ://XS6.school.pinewood.net/moodle6 <br> |
|||
We can make /moodle point to the correct one on each machine. |
|||
1 Apache |
|||
Only hosts moodle or other web pages? What is the domain name? |
|||
2 DNS |
=== 2 DNS === |
||
Local with forwarders set to resolve any unknown ip/domain name. |
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 |
=== 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. |
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 |
=== 4 Moodle 1.8.4 === |
||
Moodle main class page |
Moodle main class page |
||
Includes learning objectives for next six months. Includes links to each activity and lesson plan main page. |
Includes learning objectives for next six months. Includes links to each activity and lesson plan main page. |
||
Moodle home page for each activity. |
Moodle home page for each activity.<br> |
||
• Each lesson plan has its own home page in moodle. |
• Each lesson plan has its own home page in moodle.<br> |
||
• 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 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). |
||
<br> |
|||
• Teacher can publish link to lesson plan so it shows up on all XOs in the class. |
• Teacher can publish link to lesson plan so it shows up on all XOs in the class.<br> |
||
• Students open lesson plan with one click - Should we update the base OLPC home page to have a link to Moodle? |
• Students open lesson plan with one click - Should we update the base OLPC home page to have a link to Moodle?<br> |
||
• Students see one version of the lesson plan home page. Teachers see different version. |
• 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. |
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. |
Acceptable to have teacher URL and student URL. <br> |
||
(* 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 |
• All Moodle and activity content resides on XS <br> |
||
• Launch of actvity must use local copy if unchange. If changed should get latest copy from XS. |
• Launch of actvity must use local copy if unchange. If changed should get latest copy from XS. |
||
<br>(* never go out over WAN for updates? *) |
|||
Teacher or admin can easily post updated activities to XS |
Teacher or admin can easily post updated activities to XS |
||
Line 96: | Line 248: | ||
See also Moodle write up at: |
See also Moodle write up at: |
||
http://blog.olenepal.org/index.php/archives/124 |
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 |
GS - I think there is another Moodle write up by Martin L., need URL |
||
5 PHP |
=== 5 PHP === |
||
Used only for Moodle until other web site are built. |
|||
6 MySQL |
=== 6 MySQL === |
||
Used only for Moodle, especially Authentication until other web sites or uses defined. |
|||
7 HTTP Cache – squid? |
=== 7 HTTP Cache – squid? === |
||
- Custom values for library server URLs. That is, must flush library server content last when cache runs out of space. |
- Custom values for library server URLs. That is, must flush library server content last when cache runs out of space. <br> |
||
- Has to cache any XO activities |
- Has to cache any XO activities <br> |
||
- 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. |
- 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. <br> |
||
8 Content Filtering - http://dansguardian.org/ |
=== 8 Content Filtering - http://dansguardian.org/ === |
||
- Blocks inappropriate sites and updates block list automaticaly on a regular basis. |
- Blocks inappropriate sites and updates block list automaticaly on a regular basis.<br> |
||
- Allows manual addition of blocked URLs by domain name including sub-domains. |
- Allows manual addition of blocked URLs by domain name including sub-domains. <br> |
||
- Allow admin intervention to apply white list (AKA only those sites on the list are allowed) on the fly at any time. |
- Allow admin intervention to apply white list (AKA only those sites on the list are allowed) on the fly at any time. <br> |
||
- 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. |
- 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.<br> |
||
9 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. |
- 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. |
- 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. |
||
== Requirements |
== Other Requirements == |
||
=== XO Backup Requirements === |
|||
Must have a process to reflash XO laptops remotely. |
Must have a process to reflash XO laptops remotely. |
||
Line 141: | Line 297: | ||
Teacher and Nepal admin can easily add actvities or updated versions of existing activities to XS |
Teacher and Nepal admin can easily add actvities or updated versions of existing activities to XS |
||
Design suggestion: |
|||
2 – Localization |
|||
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. |
- 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). |
- 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. |
- Authentication: Use auto-login so that students dont have to remember their login info and/or how to get to the course page. <br> |
||
- Integrate with Moodle (see Moodle requirements above) |
- Integrate with Moodle (see Moodle requirements above)<br> |
||
- Allow backup and restore of user generated data (see requirements above) |
- Allow backup and restore of user generated data (see requirements above)<br> |
||
- For each XO, it could determine the default username, based on the XO serial number/UUID, browser cookies, or whatever.<br> |
|||
- 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 <br> |
|||
- 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.<br> |
|||
One suggestion for SSO solution: |
One suggestion for SSO solution: |
||
Line 175: | Line 340: | ||
A second idea: |
A second idea: |
||
Use DHCP manual configuration to staticaly map IP addresses to MAC addresses. |
Use DHCP manual configuration to staticaly map IP addresses to MAC addresses.<br> |
||
http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Servers/DHCP?highlight=%28dhcp%29 |
|||
<br> 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. |
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: |
Open questions on this: <br> |
||
Does available DHCP server support manual mapping? |
Does available DHCP server support manual mapping? <br> |
||
Does Moodle/MySQL support user identity based on IP address? |
Does Moodle/MySQL support user identity based on IP address? <br> |
||
Other SSO and SSO - Moodle comments |
Other SSO and SSO - Moodle comments<br> |
||
- Simplify the UI. Take out modules that are not needed for a particular group.<br |
- Simplify the UI. Take out modules that are not needed for a particular group. <br> |
||
- 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.<br /> |
- 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.<br /> |
||
- 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. <br /> |
- 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. <br /> |
||
- 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.<br /> |
- 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.<br /> |
||
=== XS Network Access === |
|||
- XS sever should have static IP address routable from the Internet. |
- XS sever should have static IP address routable from the Internet. |
||
''Suggested in school network design'' <br> |
|||
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 <br> |
|||
(ISP)---(hub)----eth0 [XS w/NAT]eth1 ----- (WiFi)----[ XO ] <br> |
|||
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: == |
== Things that needs to be solved: == |
||
Line 252: | Line 462: | ||
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. |
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 Files == |
== Networking School Server Related Files == |
||
Line 265: | Line 477: | ||
note: will extract and add to new Wiki page soon ** |
note: will extract and add to new Wiki page soon ** |
||
[[category:Countries|Nepal]] |
|||
[[Category:SchoolServer]] |
[[Category:SchoolServer]] |
||
[[category:Nepal]] |
|||
[[Category:OLPC Nepal]] |
Latest revision as of 13:58, 2 May 2008
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 |