XS Server Software
Overview
This page is the top level description of the core software for the XS implementation of the School server core software. The school server also contains application software, content bundles, and a School library.
Particular details of the core XS server software are described in greater detail in other pages:
- Our Software Repositories
- Building the software
- Obtaining and Installing the server software
- Configuration Management
- An overview of School server services, and a detailed description
- An earlier version of this software (Trial1)
Target Platforms
The target platforms for the server software are:
- An XO laptop (AMD Geode)
- A conventional desktop machine (Intel or AMD 586+)
- XSX, a dozen early prototypes
- XS, a low power server (hardware design 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. This process is described more fully in the server Live CD page.
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.
Configuration Management
We are currently exploring the possible configuration management options.
The current approach is based on a package managed by the normal update system, which uses contains copies of the default configuration files and scripts. These are linked into place by a reasonable post-install script, which avoids overwriting local changes to configuration files.
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
The proposed methodology is to develop on a current build of the server software, submitting the changes to the source repository when ready to test. After inclusion into a testing build and successful testing, the changes will be moved into the stable repository.