more findings about the gitolite architecture authored by anarcat's avatar anarcat
...@@ -696,10 +696,11 @@ syncing everything. ...@@ -696,10 +696,11 @@ syncing everything.
## Design ## Design
git-rw runs on `cupani.torproject.org` and runs as the git user. Users in the `git-rw.torproject.org`, the writable git repository hosting, runs on
gitolite (gid 1504) group can become the git user. The gitolite installation `cupani.torproject.org` as the git user. Users in the gitolite (gid
is contained inside `/srv/git.torproject.org` with the repositories being found 1504) group can become the git user. The gitolite installation is
in the `repositories` folder there. 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 The gitolite installation itself is *not* from Debian packages. It's a
manual install, in `/srv/git.torproject.org/gitolite/src`, of an 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 ...@@ -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 users with a valid LDAP account get their SSH key added to the list
and only gitolite configuration restricts further access. 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 Access to push to this repository is controlled by the
`gitolite-admin` repository entry in the gitolite configuration file, `gitolite-admin` repository entry in the gitolite configuration file,
and not by LDAP groups. 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 ## GitLab migration
As mentioned in the lead, the gitolite/gitweb infrastructure is, as of As mentioned in the lead, the gitolite/gitweb infrastructure is, as of
... ...
......