XS Server Software: Difference between revisions
No edit summary |
|||
Line 11: | Line 11: | ||
*[[XS_Software_Repositories|Our Software Repositories]] |
*[[XS_Software_Repositories|Our Software Repositories]] |
||
*[[XS_Server_Services]] |
*[[XS_Server_Services|Server Services]] |
||
*[[XS_Configuration_Management|Configuration Management]] |
*[[XS_Configuration_Management|Configuration Management]] |
||
*[[XS_Building_Software|Building the software]] |
*[[XS_Building_Software|Building the software]] |
Revision as of 07:07, 12 August 2007
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:
- Our Software Repositories
- Server Services
- Configuration Management
- Building the software
- Obtaining and Installing the server software
- An earlier version of this software (Trial1)
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. 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.
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
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.