NEXO - Build System
NEXO is based on the official OLPC OS releases. We clone the build tools and packages used by OLPC (_pilgrim_) and use it to make our own customized build.
This is installed on the pilgrim system, clearly labelled as such and currently found in the upstairs section of the office near Abhishek. It has IP address *192.168.5.233* but is not powered on all of the time.
The main components of the system are:
- The _pilgrim_ git repo at /home/Deployment/progs/pilgrim on the fileserver.
- This is a fork of OLPC pilgrim, with the changes needed to customize our own image.
- The RPM trees found in the NEXO subdirectory of the Deployment SMB share on the filserver
- These are the RPMs that compose the OLPC OS release which we base NEXO on top of
- The _activities_ directory found in the NEXO subdirectory of the Deployment SMB share on the filserver
- These are the activities that we distribute to the school servers and include in the OS build
This only needs to be done if having to reconstruct the build system.
Packages and users
As root:Install some required packages:
yum install mtd-utils createrepo mkisofs hg git make gcc wget patch
Create a standard user account named "pilgrim" and put it in the wheel group.
Use @ssh-keygen@ to generate a SSH keypair for the pilgrim user, and use the public key to allow passwordess login on the fileserver.
Configure /etc/sudoers to allow wheel to have root access without a password.
Install build system
As pilgrim user:
Check out pilgrim git repo from fileserver, in your home directory:
# git clone fileserver:/home/Deployment/progs/pilgrim
Perform first-time pilgrim setup:
# cd pilgrim # make # sudo make install
The NEXO directory on the Deployment SMB share on the fileserver contains a few collections of RPMs used in the build. The @RPMS-8.2@ and @RPMS-8.2.1@ represent the collection of RPMs that originated from OLPC, and @RPMS-ne@ represents customizations to the package set formed by us.
Each of these collections is turned into an equally-weighted RPM repository before being used in the build system, therefore if you want to replace an official OLPC OS package with a custom version, you just have to make one with a higher version number available in RPMS-ne.
The NEXO/activities directory on the Deployment SMB share on the fileserver contains the activities to be installed in the image. Note that such activities must also be listed in the pilgrim configuration, detailed below.
It's OK to have multiple versions of activities present in this directory - the latest will be used. However, *you should make efforts to keep this directory small.* Its contents are synchronized to all the school servers, sometimes over slow network links.
Pilgrim: how it works
make-nexo.sh is the script that ties it all together:
- Downloads RPMs and activities collections from fileserver
- Uses @createrepo@ to turn the RPM collections into repositories
- Invokes pilgrim
This script must be run as the _pilgrim_ user, because it uses the ssh keys to access the fileserver.
pilgrim basically constructs filesystem images from the collection of RPMs and activities, as well as including some other OLPC-specific hacks needed for the XO. At the end, it outputs the images and various checksums.
OLE Nepal customizations
As mentioned above, some RPMs from the RPMS-ne collection are used to customize the build a little. Some of them are replacements (newer versions) of components already found in the official OLPC OS, and others are new packages. In order to be installed, new packages must be added to an appropriate list inside @streams.d/olpc-development.stream@ e.g. @OLPC_CORE_PACKAGES@.
The activities to be installed are listed in the *OLPC_CORE_ACTIVITIES* variable inside @streams.d/olpc-development.stream@. The activity bundles themselves are stored on the fileserver and synchronized onto the build computer by @make-nexo.sh@.
The most flexible way of customizing the image is handled by the shell code in @streams.d/olpc-ne-customization.stream-module@. We use this script to make miscellaneous changes to the image. It relies on a series of files that can be found in the @nexo-hacks@ directory. This is where we do the bulk of the customization (flash player, Sugar changes, etc).
A note on build customization
Once upon a time, we used nexo-hacks to install a script to run on first boot to make some further modifications to the system (e.g. installing language pack). This kind of system will largely degrade the behaviour of olpc-update (which we plan to use in future, for fast/incremental/automated backup) since the contents of the root filesystem will no longer be consistent with the _contents manifest_ which is generated at the very end of the build/customization process.
So, even if it's a bit harder, it's very important that OLE Nepal customizations are done at build time, *not* at boot time. This way, the contents manifest is generated after the customizations have been applied.
Pilgrim outputs the builds in /home/pilgrim/xo-1 and data needed for an olpc-update server (currently not used) in /home/pilgrim/xo-update.