Olpc-configure
This page aims to explain the key tasks of olpc-configure, why such configuration items are written at this time, and the intricacies related to upgrades.
Contents
Overview
olpc-configure is run early during boot: after filesystems are ready, but before other system services are ran (e.g. NetworkManager, X). olpc-configure has the role of applying essential system configuration which could not be done in the OS build process - e.g. setting the system hostname, applying the right X config, etc.
This is divided into a range of tasks, some which are done only on first boot and upgrades, and others which are applied on every boot.
olpc-configure also has the role of updating any configurations that need migrating/reworking on system upgrades.
"One-time" configuration
Versioning
olpc-configure effectively maintains two configurations under basic version control: home, and root. These are given a version number to record when configuration has already been done, and so that the need to upgrade the configuration can be detected. At the present time, the same version number is applied to both of these.
Once olpc-configure has been run at least once, the version number for the root is written to /.olpc-configured and the home version number is written to /home/olpc/.olpc-configured
When the version number stored on-disk differs from the version number stored in the olpc-configure script (including if the on-disk version is not found), configure_home and configure_root are run respectively.
Guidelines on tasks to be performed
Most tasks under these functions run unconditionally, since these functions are only called on first-boot or upgrades it doesn't matter if they aren't 100% efficient. However the more complicated or time-consuming tasks should generally check that the work they are going to do has not already been done.
In general, tasks should only be performed here if they could not be done in the build process. We don't want this too become too complex; putting one-time configuration in the build process where possible simplifies our work.
Root filesystem upgrade considerations
The writing of the root version number is somewhat redundant; it only really acts as a "I've already been configured" marker. This is because upgrades via olpc-update start from a new root, so this file will never exist after an upgrade, and yum upgrades are not really supported. A simplification could be applied here: rather than have the need to "version the root", we could just go for a bi-state "configured or not" approach, and yum users could be kept happy by having the rpm %post script remove /.olpc-configured if it exists.
Essential system configuration which must persist over upgrades is controlled by the fedora-readonly service, which is configured in /etc/statetab and /etc/statetab.d. This is why (e.g.) the system's SSH keys persist over upgrades.
