Changes
Page history
more findings about the gitolite architecture
authored
Apr 11, 2024
by
anarcat
Show whitespace changes
Inline
Side-by-side
howto/git.md
View page @
4a4fb34e
...
...
@@ -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
...
...
...
...