Internal, corporate, shared hosting solutions

Internal, corporate, shared hosting solutions

[Tom Lanyon]

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

Re: Internal, corporate, shared hosting solutions

[Shawn O. Pearce]

Tom Lanyon <tom@netspot.com.au> wrote:
> 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)

Use git over ssh, but use gitosis on the server side:

  http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Have each developer supply their own SSH public key, install it
into the gitosis database, and they can only read/write repos
they have access to in the admin database.

Secure, fast, yea, you can actually pick two out of two.  :)

-- 
Shawn.

Re: Internal, corporate, shared hosting solutions

[Johan Herland]

On Friday 26 September 2008, Tom Lanyon wrote:
> 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.
>
> [...]

I'm pretty much in the exact same situation at $dayjob, and I'm 
researching some alternatives as well. So far there seems to be a 
couple of options:

1. Gitosis [1]. This is a fairly thin layer of Python scripts running as 
a non-privileged "git" user on the server. All users authenticate by 
registering their SSH key with Gitosis, and then access repos using 
this one "git" user over SSH. Further access control (i.e. read/write 
access to each repo) is done by Gitosis itself, and administered by 
cloning a gitosis-admin repo, changing some configuration files and 
pushing the result back to the server.

2. Gitorious [2]. Don't confuse this with the repo hosting service at 
gitorious.org. You can clone the software that runs gitorious.org and 
set it up on your own server. This is a much more heavy-weight 
Ruby-on-Rails application that provides a nice web interface for 
publishing and interacting with repositories. However, it is based on 
the same underlying principle of registering your SSH-keys with 
Gitorious, and running everything as a non-privileged "git" user.

3. repo.or.cz. I don't know much about how this work, and if it's easily 
deployed on an in-house server. However, the repo.or.cz admin (Petr 
Baudis, CCed) is active on this list, and can probably fill in the 
details.


Feel free to keep me updated on your progress.


Have fun! :)

...Johan


[1]: Gitosis: 
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Get it at http://eagain.net/gitweb/?p=gitosis.git;a=summary

[2]: Gitorious: http://gitorious.org/
Get it at http://gitorious.org/projects/gitorious

-- 
Johan Herland, <johan@herland.net>
www.herland.net