threads / discuss / 15683

Internal, corporate, shared hosting solutions

Subject: Internal, corporate, shared hosting solutions

## tl;dr

3 messages between Sep 26, 2008 and Sep 26, 2008.

replies: 2people: 3as markdown or json

Tom Lanyon· Sep 26, 2008, 15:13 UTC · lore
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

Shawn O. Pearce· Sep 26, 2008, 15:39 UTC · re: Tom Lanyon · lore

Re: Internal, corporate, shared hosting solutions

Tom Lanyon <tom@netspot.com.au> wrote:
Show 7 quoted lines
> 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.
Johan Herland· Sep 26, 2008, 18:17 UTC · re: Tom Lanyon · lore

Re: Internal, corporate, shared hosting solutions

On Friday 26 September 2008, Tom Lanyon wrote:
Show 9 quoted lines
> 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

← back to recent threads