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.

Overview

olpc-configure (part of olpc-utils) 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.

Possible improvements

• Remove usb_customizations stuff, Customization stick is buggy and on the way out
• Remove rainbow-related stuff, it doesn't seem like its coming back
• Make read_config bail immediately if it has already been run; allows for simplifying logic in other places
• rebuild_library_index probably doesn't need to be run from configure_home - it only needs to be run on first boot and upgrades. Then the "only run once" logic could be simplified too.
• clean_previews is broken; need to see if this is still relevant, could it be moved into Sugar?
• The "rm xorg.conf" check in configure_root should be safe to delete. root comes up pristine after upgrades...
• update_home_permissions_to_v6 probably only needs to run on upgrades where we had already recorded a home version. No need to run on clean installs. Same for clean_previews?
• set_home_permissions could be simplified for no rainbow, then merged into configure_home
• Xorg configuration stuff could hopefully be removed in future as video adapter hotplug support improves in X