Sugar Labs

School Server/RIT

< School Server
Revision as of 11:16, 22 October 2009 by Fapryce (talk | contribs)

For RIT Honors Seminar project.

School Server Fall 2009 Seminar Project

(Draft, please contribute)

Purpose

  1. Provide a school server test and development environment for the Honors Seminar participants,
  2. Develop School Server systems administration skills,
    1. Backup registered XOs or Sugar Sticks
    2. Host Moodle content developed in class
  3. Test and Debug OLPC - Sugar Labs School Server software
  4. Develop a School Server SysAdmin training curriculum for volunteers who want to support an OLPC or Sugar deployment

Resources

  1. RIT LTL or other hardware
  2. OLPC XS development builds, http://wiki.laptop.org/go/School_server
  3. http://lists.laptop.org/listinfo/server-devel and the list archives, archive with search
  4. OLPC projects/xs repository, http://dev.laptop.org/git/?q=projects%2Fxs
  5. Martin Langhoff's git repository, http://dev.laptop.org/git/users/martin/

schoolserver.rit.edu

Note: Admin log is located on the server at /var/log/adminlog.log


Project Ideas

  • Fix Ejabber
  • Configure Moodle to our needs
    • Create an Activity(Application) for RIT XOs so students can easily access Moodle
  • Moodle xo python api
  • XO Backup/Restore
  • XO Security [1]
  • Deployment "whitebook"
  • Provide a service that allows teachers/volunteers (who don't speak English) in actual deployments to communicate via email with technical support volunteers by using the translating service Pootle. Incoming and outgoing "tagged" emails would be translated in and out of the server on arrival / departure of the XS.
  • Library /Book Reader. Thousands of books stored on the XS which children are able to pull over the network either as whole book or bit by bit as they read them on their XO's.
    • Additionally, they can "check out" books and bring them home on their laptops to read at home, or while not connected to the XS.
    • This may prove to be more economical than the proposal of distributing text via SDcards as it would allow for a wider range of content per available Gigabyte. One 40 gig hard disk library would hold 10 times as much content as ten, 4-GB SDcards replicated with identical content.
    • Run said books through Pootle, so children have access to books not in their native tongue.
    • Essentially, a backend to the read activity.
  • In class quizzing. Teachers ask questions, students respond using their XO, quiz results stored on XS. (Think the I>clicker) I believe similar concepts were proposed by Alex Jones
    • Possibility of parsing of information, possible graphical heuristics.
    • Is this already a feature of Moodle? (quiz module) / Possible integration or extension of idea with Moodle.

Reading Library

Some resources:

Proposed Design Goals

  1. Hold copies of ebooks for learners with no Internet access
  2. Compatible with existing Sugar ebook readers
  3. Teacher/administrator interface for loading books from a variety of Internet book archives and portable USB or CD/DVD storage media.

In the end, we want to have instructions and some supporting scripts to modify the standard OLPC School Server to support a reading library and our campus environment as independent features.

File Distribution System

An alternative to extending e-book readers - a file distribution system for the server and a client for the XO.

  1. We initially tried to set up an nfs mount however, this did not work.
  2. The file distribution system will be in two parts:
    1. Some server code that will keep a database of files and metadata about each file; the server will be viewed from a standard web browser as well as have an api that will allow our client to download files over HTTP.
      • Some optional features could be to allow each person to have a public file store that others can browse.
    2. The client side will be written in python; this app will ask the server for the file list and metadata, which will allows users to browse the files and any file they want they can click on and download - the downloaded file will show up in their journal.
      • This app would allow them to search for files or browse them in a more organized wat than the journal system and they will be able to download the files they want
  3. The front end would be a simple python activity for the XO
  4. There are three options for the back end:
    1. PHP driven webpage using apache and some sort of SQL
      • + Using existing server and database technology
      • + Doesn't require app, can use browser to get files as well
      • - Requires Apache + SQL + PHP support
      • + Would be installed if they have Moodle anyways
      • + Uses HTTP protocol, easy to implement in client
    2. Python server application
      • - We would have to implement our own server (and protocol if we do not use HTTP)
      • - Could potentially not have a website style interface
      • + Does not require Apache
      • - Always running on server even when not in use
    3. FTP System
      • - This would be the least desirable system as it would not support metadata
  5. We believe a file distribution system will be more valuable to the community as it could be used to distribute activities (the distribute client can be downloaded with the browse activity from its web-front end and then they can use the downloaded activity)
  6. It can also be used to download e-books from a PDF system
  7. The client could also make a file wish list so the next time they are online it automatically downloads the requested files; or the teacher can mark a file to be automatically downloaded

Necessary Tasks

Nice to have

For future development

Completed Tasks

Network configuration

The School Server, XS, as received is designed and configured for 2 Ethernet adapters,

  • eth0 - connected to the wide area network (WAN) or the campus Internet connection,
  • eth1 - connected to an access point (AP) which the XOs connect to.

For robustness in unreliable power supply environments, there are scripts that reconfigure features on a frequent basis. This design has frustrated anyone wanting to deviate from the default configuration.

We will have to understand the design, carefully document our adjustments for our environment, and make preparations to restore one or more configurations once we upgrade to a new version of the server that may likely restore some of the default configurations.

Collaboration Server

  • This bug report, http://dev.laptop.org/ticket/9242, covers the missing collaborator icons in the Neighborhood view (after first connection and before reboot or reconnection to the access point)
  • /etc/idmgr.conf edited line BIND_DOMAIN=172.18.0.1 to BIND_DOMAIN=129.21.47.159 in order to try to enable the registration service. Ran service idmgr restart.
    But, on trying to register my XO, it stalls for a minute or two and then reports that it failed to connect to the schoolserver (it was connected to the ejabberd service). --FGrose 00:35, 17 October 2009 (UTC)

Subpages

Retrieved from "https://wiki.sugarlabs.org/index.php?title=School_Server/RIT&oldid=39420"