Internal, corporate, shared hosting solutions

Hi list,

I'm struggling. There's been a recent adoption of git here by our development staff, which is great. However, from an administrative point of view, I'm having trouble finding a solution to provide some kind of easy, shared, secure and accessible hosting solution to our developers.

So that these repositories can be centrally tracked and backed up, we require a central git host for all of our projects from all our development teams.

We have some pretty basic requirements:
	- authentication and authorisation; some repos are only readable/ 
writable by specific people
	- accessible; many dev servers are on private subnets, ideally we  
need to be able to proxy git access
	- not too much messing with unix user accounts on the central git  
host (because they're tied to LDAP, for example)

Accessibility is easily addressed by providing access to the git repositories via WebDAV with which we can proxy HTTP traffic. Similarly, HTTP gives us great authentication and authorisation; fantastic, problem solved. Not so fast. We need git built with USE_CURL_MULTI to support push over HTTP, which requires curl >= 7.16.0. The most recent RedHat Enterprise Linux has 7.15.5 so we'd need to build many custom packages and compatibility packages for any servers needing git access and this is plainly not acceptable from an administrative standpoint. Additionally, git over WebDAV is incredibly slow. Pushing git's git repostory to a new, empty repository over gigabit ethernet was ridiculously slow (I didn't bother to do it again and time it).

Looking at the git native protocol or git-over-ssh, then. We can tunnel these if need be, so forget about the accessibility issue. Authentication becomes a problem here; the git daemon doesn't have enough security controls to grant groupA r/w access to repoX, read access to repoY and no access to anything else. Is SSH a solution for my problems? Can we provide shared repositories to certain groups of people, while limiting access to others and is this going to require accounts for each developer on the server (the git-shell seems to not be flexible enough for this)?

Am I thinking about this conceptually wrong or am I missing something simple?

Thanks, Tom

-- Tom Lanyon