... | ... | @@ -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
|
... | ... | |