spirald
spirald

Reputation: 39

Gitolite fails to access repositories stored in subdirectories

After successfully organizing a large number of repositories in a deep subdirectory tree for years, somewhere between Gitolite 3.6.6 and 3.6.11 for RHEL/Centos 7 I lost the ability to access repositories stored in subdirectories.

Attempts to fetch or push fail with a "Denied by fallthrough", while repositories in top level directories can be accessed successfully.

Gitolite config is as follows

@supergroup = spirald

@foogroup = spirald
@foogroup = johnny

repo gitolite-admin
    RW+     =   @supergroup

repo testing
    RW+     =   @all

repo foo/bar/baz
    RW+     =   @foogroup

repo footest
    RW+     =   @foogroup

Gitolite logs as follows:

2020-04-22.11:04:24     27731   ssh     ARGV=spirald       SOC=git-upload-pack 'foo/bar/baz'      FROM=111.222.333.444
2020-04-22.11:04:24     27731   die     R any foo/bar/baz spirald DENIED by fallthru<<newline>>(or you mis-spelled the reponame)

ssh info shows the following

hello spirald, this is git@aserver running gitolite3 3.6.11-1.el7 on git 1.8.3.1

 R W    footest
 R W    gitolite-admin
 R W    testing

In the git account, gitolite access -s foo/bar/baz spirald W any returns

FATAL: this should not happen! W any foo/bar/baz spirald DENIED by fallthru at /usr/share/gitolite3/commands/access line 101, <DATA> line 1. 

While: gitolite access -s footest spirald W any returns

legend:
    d => skipped deny rule due to ref unknown or 'any',
    r => skipped due to refex not matching,
    p => skipped due to perm (W, +, etc) not matching,
    D => explicitly denied,
    A => explicitly allowed,
    F => fallthru; access denied for normal refs, allowed for VREFs

  A        gitolite.conf:23         RW+     =   @foogroup

refs/.*

gitolite list-* commands show the repo and the memberships properly

Does anyone have insight into this issue or some kind of workaround that doesn't involve changing a whole lot of URLs?

Upvotes: 0

Views: 369

Answers (1)

spirald
spirald

Reputation: 39

Solved!

In the git account on my server I used

gitolite setup --hooks-only

Looks like a recent gitolite release caused an issue if this was never done with a repo. I just dropped an existing repo into the repositories dir managed by gitolite so I never did this initially.

Upvotes: 3

Related Questions