Gitolite fails to access repositories stored in subdirectories

[Spirald]

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?

[Sitaram Chamarty]

1. check all (unix) permissions

2. make a backup of "~/.gitolite" on the gitolite hosting user,
then run "gitolite setup" and see if it it works now.

If it does, I'd be curious what the difference is between
the backed up ~/.gitolite and the current (working) one.

If neither of these work, we're in trouble. In particular, if
"gitolite setup", then something is seriously wrong with the
setup.

regard
sitaram

> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/7ab78a2d-a1f2-49fb-ae0b-fa947befa8e0%40googlegroups.com.

[Mike Toth]

Solved! 

I used 

  

  gitolite setup --hooks-only

and it started working again. 

My repo was imported from cvs using a cvstogit tool. Seems like gitolite worked fine if the repo was simple dropped into the repositories dir if you didn't need hooks, until a recent release.

Thanks for all the help!

[Sitaram Chamarty]

On Thu, Apr 23, 2020 at 02:44:50PM -0700, Mike Toth wrote:
> Solved!
>
> I used
>
> gitolite setup --hooks-only
>
> and it started working again.
>
> My repo was imported from cvs using a cvstogit tool. Seems like gitolite

You did not mention that this was a newly imported repo; I
assumed it was an existing repo that suddenly became
inaccessible.

> worked fine if the repo was simple dropped into the repositories dir if you
> didn't need hooks, until a recent release.

I don't even want to ask what "if you didn't need hooks" means.
Please resist the temptation to explain, my life is complicated
enough right now :-)

[Mike Toth]

It wasn't newly imported. I had been using the repo through gitolite for a few years successfully.

I updated gitolite as part of a Centos yum upgrade and it stopped working. I discovered that a recent change was made in gitolite to the effect of preventing a race condition when repositories were in the process of being put under control of gitolite. The comments on it mentioned "gitolite setup --hooks-only".

This particular repo on this particular server does not require running any custom code on push events, so it's not something I concerned myself with.

Thanks for your help.

[Sitaram Chamarty]

On Thu, Apr 23, 2020 at 09:07:40PM -0700, Mike Toth wrote:
> It wasn't newly imported. I had been using the repo through gitolite for a
> few years successfully.

Then the hooks should already have been there.

> I updated gitolite as part of a Centos yum upgrade and it stopped working.
> I discovered that a recent change was made in gitolite to the effect of
> preventing a race condition when repositories were in the process of being
> put under control of gitolite. The comments on it mentioned "gitolite setup
> --hooks-only".
>
> This particular repo on this particular server does not require running any
> custom code on push events, so it's not something I concerned myself with.

The whole **point** of gitolite is "custom code on push events"
(or a large part of the point anyway).

Are you saying you were running without an update hook before
this upgrade? That should not have been possible unless, when
you originally migrated it, you did not follow the instructions
(which at that time would have been to run "gitolite setup")

Anyway I think we are done here.

[Mike Toth]

Yes, it's possible I never ran gitolite setup and it still worked for years under gitolite. It was too long ago to remember. 

I've used it primarily to provide ssh key-based access to a central copy of repo for a small team and it does the job very well.

Thanks for your help and for creating this package.