XS Server Software: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 5: Line 5:
=Overview=
=Overview=


This page is the top level description of the software for the [[School server]]. Other pages which describe particular aspects in greater detail are:
This page is the top level description of the core software for the XS [[School server]] (server software). The school server also contains [[XS_Application_Bundle|application software]], [[Content_Bundles|content bundles]], and a [[School library]].

Other pages which describe particular aspects of the core software in greater detail are:


*[[XS_Software_Repositories|Our Software Repositories]]
*[[XS_Software_Repositories|Our Software Repositories]]
*[[XS_Server_Services]]
*[[XS_Building_Software|Building the software]]
*[[XS_Building_Software|Building the software]]
*[[XS_Installing_Software|Obtaining and Installing the server software]]
*[[Trial1_Server_Software|An earlier version of this software (Trial1)]]
*[[Trial1_Server_Software|An earlier version of this software (Trial1)]]


=Target Platforms=
==Target Platforms==


The target platforms for this software are:
The target platforms for the server software are:


* An XO laptop (AMD Geode) -- [[Trial1 Server Image|An image to start with]]
* An XO laptop (AMD Geode) -- [[Trial1 Server Image|An image to start with]]
Line 20: Line 24:
* developer boards for processors under consideration
* developer boards for processors under consideration


At least 256 MB of memory (and a storage device capable of supporting virtual memory) is required. 512 MB or more is suggested.
At least 512 MB of memory (and a storage device capable of supporting virtual memory) is required.


The storage device may be attached using SATA, IDE (PATA), or USB.
The storage device may be attached using SATA, IDE (PATA), or USB.


The networking interfaces will be varied. Each server will support up to three Marvell wireless mesh networking modules connected via USB 2.0. In addition, at least two 100baseT network intefaces will be provided for connection to the WAN and LAN. These may also be connected via USB.
The networking interfaces will be varied. Each server will support up to three Marvell wireless mesh networking modules connected via USB 2.0. In addition, at least two 100baseT network interfaces should be provided for connection to the WAN and LAN. These may also be connected via USB.


No graphics capabilities are planned. If a server (such as a desktop machine) has an attached keyboard and display, they will used for a text console.
No graphics capabilities are planned. If a server (such as a desktop machine) has an attached keyboard and display, they will used for a text console.


=Software Development and Distribution=
=Live-Installer CD=

The server software is based on the Fedora Core 7 distribution of Linux, in order to provide support for a wide range of hardware platforms and peripherals. OLPC provides the server software as a Live CD image (a CD that not only contains the software for installation, it may be directly booted to run the software) representing the School server.

This Live CD may be installed onto a disk, which is then simply duplicated for mass production. Final customization of the server software occurs upon the first boot of the system, and an initial configuration (either web based or through a USB key) when deployed to a site.

Once deployed, the core software will be updated using the RedHat RPM mechanism, periodically pulling the latest software from country level repositories. These may be as simple as a mirror of the [[XS_Software_Repositories|OLPC repositories]] at first.

Each country has the option of taking the core server software and customizing releases for their needs, but it is recommended that most customization occur at the level of [[XS_Application_Bundle|application bundles]].

==Live-Installer CD==

The XS/XSX live CD is built by the Pilgrim-based [http://fedoraproject.org/wiki/FedoraLiveCD livecd-creator tool], which builds a kickstart script into a live CD image. This is the same tool used to build the Fedora 7 live-installer CD. Currently, there are two branches of kickstart development. Holger Levsen's work on automating the live install process, and FAI configuration management, is located in a git repository at git://dev.laptop.org/projects/fai-config/fedora/live-installer/ , and his live CD image is available [http://xs-dev.laptop.org/xs-live-installer/ here] (updates at 8AM BST daily). Because automating the live install has proved somewhat of a blocker, we currently maintain a second branch of build process, for development purposes. Scripts and data about this branch are located in a git repository at git://dev.laptop.org/projects/livecd-data , and a live CD image is available [http://xs-dev.laptop.org/xs/ here]. It is the latter process that is described below.
The XS/XSX live CD is built by the Pilgrim-based [http://fedoraproject.org/wiki/FedoraLiveCD livecd-creator tool], which builds a kickstart script into a live CD image. This is the same tool used to build the Fedora 7 live-installer CD. Currently, there are two branches of kickstart development. Holger Levsen's work on automating the live install process, and FAI configuration management, is located in a git repository at git://dev.laptop.org/projects/fai-config/fedora/live-installer/ , and his live CD image is available [http://xs-dev.laptop.org/xs-live-installer/ here] (updates at 8AM BST daily). Because automating the live install has proved somewhat of a blocker, we currently maintain a second branch of build process, for development purposes. Scripts and data about this branch are located in a git repository at git://dev.laptop.org/projects/livecd-data , and a live CD image is available [http://xs-dev.laptop.org/xs/ here]. It is the latter process that is described below.


The basic live CD contains the following components:
The basic live CD contains the following components:
==Fedora 7 "Mirror"==
The kernel and core packages of the XS/XSX are a "mirror" of Fedora 7. Right now, this is a literal mirror, but in the future it may branch. A local mirror of fc6/f7, with certain exclusions, is maintained at http://fedora.laptop.org/ (updates at 6AM BST daily). The configuration, crontab, and scripts that maintain the mirror are located in a git repository at git://dev.laptop.org/projects/fai-config/fedora/mirror/ .


==Packages==
==Packages==

Revision as of 04:57, 12 August 2007

  This page is monitored by the OLPC team.

Overview

This page is the top level description of the core software for the XS School server (server software). The school server also contains application software, content bundles, and a School library.

Other pages which describe particular aspects of the core software in greater detail are:

Target Platforms

The target platforms for the server software are:

  • An XO laptop (AMD Geode) -- An image to start with
  • A conventional desktop machine (Intel or AMD 586+)
  • XSX, a dozen early prototypes (hardware selection ongoing)
  • developer boards for processors under consideration

At least 512 MB of memory (and a storage device capable of supporting virtual memory) is required.

The storage device may be attached using SATA, IDE (PATA), or USB.

The networking interfaces will be varied. Each server will support up to three Marvell wireless mesh networking modules connected via USB 2.0. In addition, at least two 100baseT network interfaces should be provided for connection to the WAN and LAN. These may also be connected via USB.

No graphics capabilities are planned. If a server (such as a desktop machine) has an attached keyboard and display, they will used for a text console.

Software Development and Distribution

The server software is based on the Fedora Core 7 distribution of Linux, in order to provide support for a wide range of hardware platforms and peripherals. OLPC provides the server software as a Live CD image (a CD that not only contains the software for installation, it may be directly booted to run the software) representing the School server.

This Live CD may be installed onto a disk, which is then simply duplicated for mass production. Final customization of the server software occurs upon the first boot of the system, and an initial configuration (either web based or through a USB key) when deployed to a site.

Once deployed, the core software will be updated using the RedHat RPM mechanism, periodically pulling the latest software from country level repositories. These may be as simple as a mirror of the OLPC repositories at first.

Each country has the option of taking the core server software and customizing releases for their needs, but it is recommended that most customization occur at the level of application bundles.

Live-Installer CD

The XS/XSX live CD is built by the Pilgrim-based livecd-creator tool, which builds a kickstart script into a live CD image. This is the same tool used to build the Fedora 7 live-installer CD. Currently, there are two branches of kickstart development. Holger Levsen's work on automating the live install process, and FAI configuration management, is located in a git repository at git://dev.laptop.org/projects/fai-config/fedora/live-installer/ , and his live CD image is available here (updates at 8AM BST daily). Because automating the live install has proved somewhat of a blocker, we currently maintain a second branch of build process, for development purposes. Scripts and data about this branch are located in a git repository at git://dev.laptop.org/projects/livecd-data , and a live CD image is available here. It is the latter process that is described below.

The basic live CD contains the following components:


Packages

Additional RPM packages of relevance to the XS/XSX are specified under the %packages header in the kickstart script. In general, these packages should come from the OLPC stable repository, a collection of packages that have been tested for compatibility with the school server. The current live CD mirrors the packages of our existing school server, schoolserver.laptop.org .

OLPC Configuration

Beyond Fedora 7's defaults, the live CD requires additional configurations to function as a real XS/XSX school server. In general, these configurations fall into one of three categories:

Package Configuration ("Alternative Defaults")

Default Fedora 7 packages often require special, OLPC-specific configurations. The typical solution to this problem is to perform the configuration in live-install postscript (hard to maintain and verify), or to use a configuration manager such as FAI (Holger's work). We have created an alternate, blunt-but-easy-to-develop solution using an RPM configuration package. This package contains a tree (starting at root) of configuration files. Installing the package links those files into place at the root of the file system. RPM's database is used to protect user's configuration changes while bashing RPM's defaults. This project is located in a git repository at git:/dev.laptop.org/projects/xs-config, and the package itself is available in a repository here. There are many scripts to help analyze and build configuration trees, in the livecd-data and xs-config git repositories.

OLPC Packages

Some of the XS/XSX's functionality is the product of OLPC development and, as such, has its own packaging. These packages are installed just like any other, by the live CD kickstart script. An example of such a package is the XS callhome scripts. The project is in a git repository at git://dev.laptop.org/projects/xs-callhome , and the package itself is available in a repository here.

Site-Specific Configuration

Site-specific configuration can be done either at OLPC build time ("early"), or after the school server reaches the field ("late"). Early configuration will probably involve country-specific content and localization, and may be thought of as branches off the main configuration tree. Late configuration will probably be done via a web interface published by the school server. Once the school server is plugged in and turned on, local installation techs will use the web interface to configure connectivity (which interface(s) are connected to the outside world, and possibly static network information) as well as having the server "phone home" with its geographic location, IP address, and hostname. The "phone home" step should also serve to connect the school server to the Content Distribution Network.

It may be worthwhile to have all configuration either early or late. The benefits of late configuration are more apparent, but will require a potentially-lengthy initial download while country-specific content and packages are installed onto the new school server.

Configuration Management

Currently, our configuration management solution is FAI, a "fully"-automatic installer and maintainer, originally developed for Debian GNU/Linux. FAI uses a powerful class system (similar to cfengine) to maintain multiple, different package configurations among its clients. The configuration of these software packages is performed by various scripts handled by FAI. The configuration of FAI, and the scripts FAI handles, are maintained in a git repository at git://dev.laptop.org/projects/fai-config/ .

You can also update your configuration by installing a new version of the RPM configuration package, described above. This package tends to err on the side of preserving local configuration changes, so if you are experimenting with configurations watch the warning messages -- you may have to install a file or two by hand.

Development Environment

At the moment, our development methodology is "hack on a live school server at OLPC, then when things are working, update the RPM configuration package with your hacks." There are scripts and documentation in the livecd-data and xs-config git repositories to assist in this process. Cronjobs will be going up later.

In the future, if we intend to use FAI, we will have to hack at FAI to reflect our stable configurations.

In-field Upgrades

Our configuration management system must also be integrated with our in-field upgrade mechanism. Once the school servers are in the field, we will want to upgrade them to fix networking or security bugs, or to add additional content. We need a mechanism to preserve site-specific setup while upgrading the school server.