XS LiveCD: Difference between revisions
No edit summary |
|||
Line 12: | Line 12: | ||
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. |
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 |
The XS Live CD is built by the Fedora [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. 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 <tt>http://dev.laptop.org/git/projects/ git://dev.laptop.org/projects/]</tt>, and Live CD Images are available at <tt>[http://xs-dev.laptop.org/xs/]</tt>. |
||
The basic live CD contains the following components: |
The basic live CD contains the following components: |
||
Line 23: | Line 23: | ||
===Package Configuration ("Alternative Defaults")=== |
===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 [http://fedora.laptop.org/olpc-local/i386/ here]. There are |
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 [http://fedora.laptop.org/olpc-local/i386/ here]. There are some scripts to help analyze and build configuration trees available in the [http://dev.laptop.org/git/projects/xs-config/ xs-config git repositories]. |
||
===OLPC Packages=== |
===OLPC Packages=== |
||
Some of the School server functionality is the product of OLPC development and, as such, has its own packaging. These packages are installed just like any other, by the |
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 [http://dev.laptop.org/projects/idmgr git://dev.laptop.org/projects/idmgr] , and the binary package is available in [[XS_Software_Repositories|our RPM repositories]]. |
||
===Site-Specific Configuration=== |
===Site-Specific Configuration=== |
Revision as of 04:48, 29 January 2008
This page describes the Live CD component build and distribution mechanism used by the School server software. There are separate instructions for downloading and installing from the Live CD.
LiveCD
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/projects/ git://dev.laptop.org/projects/], and Live CD Images are available at [1].
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 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.