[Server-devel] Building the School Server

[John Watlington]

On Jun 21, 2007, at 5:25 PM, Daniel Wyatt Margo wrote:

> In particular, I've been looking at configuration management and  
> Holger's
> FAI setup. One of the issues I have been thinking about is, what is  
> the
> best way to maintain and push out configuration updates without  
> clobbering
> or discouraging local customizations? Right now, configuration is
> performed directly by FAI's scripts, which Scott and I think could  
> be hard
> to maintain and raises other questions, such as the idempotence of the
> configuration scripts. I looked into .rpm configuration packages, but
> after talking with j5 he discouraged this,

I would be interested in hearing his reasoning (perhaps rpm's lack of
merge capability ?)

> and suggested that instead, we
> might pull important configuration files directly from a version  
> control
> system, even post-deployment. Rather than having FAI run configuration
> scripts, FAI's scripts could simply fetch configuration files from  
> version
> control. It's simple, and it might even give us some neat features,  
> like
> the ability to merge, or revert if we accidentally do clobber local
> settings.

Here's the system that David Woodhouse and I just outlined (all  
errors are
mine):

We use RPM to install/upgrade packages from the OLPC stable repository.
Packages from FC7 will be tested for compatibility before being  
upgrading
the stable repository.

OLPC specific configuration files should be separate from those  
provided with
the package whenever possible (FC7 largely supports this).

OLPC specific configuration files will be provided in a separate  
directory, /olpcconf,
and linked into place in the filesystem [1].   This directory will be  
a git repository.

An RPM package containing the git repository for /olpcconf will be  
provided in the
OLPC RPM repository [2].   If RPM updates this repository, we will  
trigger [3] a git pull of
/olpcconf.  This git pull will merge any school-specific  
configuration changes with
the files provided by OLPC [4].

Part of the backup procedure for a server will be a backup of this  
local /olpcconf
repository.

Notes:
[1] An alternative is to use /etc for the git repository, but there  
is some concern that git
is slowed by the number of files in its tree, even if they aren't  
indexed.

[2] Unless there has been a change to the OLPC common config files,  
git will not be
executed.   As we want to update frequently (daily ?), this will  
minimize overhead.

[3] There is some concern that this probably shouldn't be done as a  
post-install
script for the olpcconf RPM, as problems with git merge will affect  
RPM (although
maybe that isn't a bad thing ?)

[4] Provided that the locally modified files were commited, otherwise  
git will get upset...

Comments ?  Complaints ?  Improvements ?
wad