Olpc-configure

From OLPC
Revision as of 20:33, 28 October 2012 by DanielDrake (talk | contribs) (Created page with '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. == Overview == olpc-c…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

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.

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

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.