semi-autonomous mirroring setup example

This document describes one way to do this. Gitolite is powerful so you can probably find other ways to suit you.

overview of problem

The example is from real life, with the following characteristics:

multiple servers (hosts)
multiple "products", each product has one or more git repos
different products are "native to" (mastered on) different hosts
a product may be mirrored to zero or more other hosts (mirrored to zero hosts means it is local to the host)

The admin requirements are:

the overall system will have one or more master admins; they manage the main config file, for instance.
each host will have one or more host admins
these host admins should be allowed to create any repos they need (within one of a set of directory names allocated to them), and assign access to whomever they please
they should not be able to "step on each other" -- setup access rules for repos not in their control

The following can only be done by the master admins:

authentication (ssh keys) are centrally managed and distributed. Host admins should not be allowed to do this.
mirroring setup -- who's the master and who're the slaves for any repo
allowing redirected pushes from slaves

overview of setup

We will use p1 as the product, with sam as the master and frodo as a slave. Assume equivalent text/code for other product/master/slave combos.

This setup imposes the condition that all repos should be under some directory name; either a product name or, for local repos, a hostname. In our example, these directory names would be p1 or sam on the host sam, and frodo on the host frodo.

gitolite feature recap

We use delegation, to ensure that admins for sam can only write files whose names start with master/sam/. The actual files they will write are master/sam/p1.conf etc., one for each product that is mastered on their server.

We use subconf. When you say subconf "path/to/foo.conf, then within that file (and anything included from it), access can only be defined for repos that regex-match one of the elements of @foo.

pre-requisites

First, install mirroring on all servers according to the main mirroring document. Set it up so that the gitolite-admin repo is mastered at one server and everyone else slaves it.

Also, after (or during) the normal mirroring install, edit ~/.gitolite.rc on all servers and set $GL_WILDREPOS to 1 (from its default of 0).

quick setup

edit your gitolite.conf file as given in step 1 below
- ignore all the comments, even the ones that tell you to do something :-)
- change only the names of the admin users, and the names of the servers in the config lines. Everything else stays the same
now copy mirror-conf-helper from the contrib directory to your home or some easy to type place, and run it to setup your hosts, products, and slaves

A typical sequence with that script is:

# cd to your gitolite-admin clone

# create a new host
~/mirror-conf-helper newhost sam sam-admin

# create the actual repository and access rules.  This is done by the host
# admin for the host on which it is mastered (or you can do it yourself).
# See step 3 below for details.
mkdir -p conf/master/sam
vim      conf/master/sam/p1.conf
    # now add in some "repo p1/..." and "RW ..." lines for the repos in
    # product p1 and save

# add product p1 to the list of repos sam is allowed to control
~/mirror-conf-helper newprod sam p1

# add a slave
~/mirror-conf-helper newslave sam p1 frodo

You can then treat the detailed steps described below as extra information or "background reading" ;-)

step by step: Link

next steps

Once you've done the initial setup, here's what ongoing additions will require.

any new repos that are created for the same product require only step 3
a new product will require steps A1, 3, 4 and 5
a new host will require additions in all the steps, including adding the hostname in the slaves list for the admin repo (this is in the main gitolite.conf file)