more findings about the gitolite architecture authored by anarcat's avatar anarcat
......@@ -696,10 +696,11 @@ syncing everything.
## Design
git-rw runs on `cupani.torproject.org` and runs as the git user. Users in the
gitolite (gid 1504) group can become the git user. The gitolite installation
is contained inside `/srv/git.torproject.org` with the repositories being found
in the `repositories` folder there.
`git-rw.torproject.org`, the writable git repository hosting, runs on
`cupani.torproject.org` as the git user. Users in the gitolite (gid
1504) group can become the git user. The gitolite installation is
contained inside `/srv/git.torproject.org` with the repositories being
found in the `repositories` folder there.
The gitolite installation itself is *not* from Debian packages. It's a
manual install, in `/srv/git.torproject.org/gitolite/src`, of an
......@@ -724,10 +725,29 @@ because `exportOptions` is set to `GITOLITE` on the `cupani` host. All
users with a valid LDAP account get their SSH key added to the list
and only gitolite configuration restricts further access.
When a repository is pushed to, it gets synchronised to the gitweb
host on a `post-receive` hook
(`/srv/git.torproject.org/git-helpers/post-receive.d/00-sync-to-mirror`),
which calls `.../git-helpers/tools/sync-repository` which just
`rsync`'s the repository over, if and only if the
`git-daemon-export-ok` flag file is present. If it isn't, an *empty*
repository (`/srv/git.torproject.org/empty-repository`) is
synchronized over, deleting the repository from the gitweb mirror.
Access to push to this repository is controlled by the
`gitolite-admin` repository entry in the gitolite configuration file,
and not by LDAP groups.
Note that there is a `/srv/git.torproject.org/projects.list` file that
contains a list of repositories. That file is defined in
`/srv/git.torproject.org/etc/gitolite.rc` and is, in theory, the
entire list of projects managed by gitolite. In practice, it's not:
some (private?) projects are missing in there, but it's not clear why
exactly (for example, `admin/trac/TracAccountManager` is not in there
even though it's got the `git-daemon-export-ok` flag and is listed in
the `gitolite.conf` file). This *might* be because of access controls
specifications in the `gitolite.conf` file.
## GitLab migration
As mentioned in the lead, the gitolite/gitweb infrastructure is, as of
......
......