- This page refers to obsolete versions of the XS (v0.4 and earlier). Please use newer versions of the XS software.
- For building XS images, see XS Builder.
 Warning: 'Run from Image' is an INSTALL/Format
For those used to an installer with partitioning tool like the vanilla Fedora install process, this Live/Install CD requires 1 Gig RAM? memory to run from memory (i.e. Live mode, thin client but fat server) and the 'Run from Image' FORMATS your entire hard drive without pause for selecting partitions, configuration, nor sharing the disk (except keeping a useless Winblows...) as it appears to assume a production environment instead of learning/testing/development.
Notes on the next version says it will even AUTOSTART the Install...
[Learned the hard way in a rush to demo(lish) at FOSE, and sharing the warning so you don't have to lose an entire drive's data as well...]
 Live-Installer CD
A Live CD contains an operating system and is capable of booting that system into memory independent of a hard drive. An Installer CD contains an operating system to be installed onto a hard drive. Therefore a Live-Installer CD can boot an OS for testing and evaluation and then install it on the running computer even if it had no OS installed initially.
The XS Live CD is built by the Fedora 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. These are usually built using the XS Software Repositories. The source code for configuration and services which aren't obtained directly from Fedora are located in a git repository at http://dev.laptop.org/git/ git://dev.laptop.org/projects/], and Live CD Images are available at http://xs-dev.laptop.org/xs/.
The basic live CD contains the following components:
Additional RPM packages of relevance to the XS are specified under the %packages header in the kickstart script, but mostly in the git://dev.laptop.org/projects/xs-pkgs/]. 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 a prehistorical school server, the original schoolserver.laptop.org and needs pruning.
 OLPC Configuration
Beyond Fedora 7's defaults, the Live CD requires additional configurations to function as a real XS 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 some scripts to help analyze and build configuration trees available in the xs-config git repositories.
 OLPC Packages
Some of the School server functionality is the product of OLPC development and, as such, has its own packaging. Others are the work of third parties, but we have compiled up a specific version and packaged it for use with the XS school server. These packages are installed just like any other, by the Live CD kickstart script. An example of such a package is the School Identity Manager. The project source is in a git repository at git://dev.laptop.org/projects/idmgr , and the binary package is available in our RPM repositories.
 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.