5 ms·

Code your own Multi-User Private Git Server

64 points by moomerman 15y ago

wccrawford 15y ago
Copying code into a file isn't 'coding'. And it took a lot more than 5 minutes to work all this out.
- moomerman 15y ago
  Sorry if you find the title misleading, it certainly wasn't intended that way. In fact, sometimes I find it harder to pick the right title than I do to write the blog post. My intentions were that you could read the article in 5 minutes and the code sample would give you a good starting point to code your own implementation.
chriseidhof 15y ago
I use gitosis, and it's very simple to set up and manage. It doesn't feel like overkill at all.
- balac 15y ago
  I like Gitolite, it has more fine grained permission control and is pretty simple to get up and running.
- Gonzih 15y ago
  I was using Gitosis, now i switch to Gitolite, it's better and simpler.
  - davvid 15y ago
    Gitolite is also well supported. Gitosis is basically an abandoned project. kernel.org's new git infrastructure will be using gitolite which means you can pretty much count on it being supported well into the future.
X-Istence 15y ago
This just seems to be a case of Not Invented Here syndrome. Using gitolite or gitosis would have done the job faster, gives you the ability to have acl's set up per user and all of it uses simple configuration files.
- ajross 15y ago
  Agreed. Or for small trusted teams any linux box with ssh access will do fine. This is a very well served product area, it really shouldn't be a problem that demands new software development. Edit: Hah! That's basically what it is, just dressed up with a tiny script and the two-factor trick from last week. Never mind then. This is sane. Just maybe oversold.
- moomerman 15y ago
  To be fair, the example I have given is simple and you could use something like gitosis or gitolite (I have used them in the past). The point of the article was supposed to be a starting point if you have something else you want to do. For example, I needed to have a fully distributed git backend system across multiple git storage nodes so I needed to learn how I would go about doing that. This post was supposed to give the reader the tools they need to roll their own solution if they want.
  - calloc 15y ago
    For what you are suggestion wouldn't it be simpler to start with a known code base such as gitolite and to then add the modifications you require?
- davvid 15y ago
  NIH or not, I enjoyed reading this post. It showed the simplicity of serving git repos and walked readers through the entire process top to bottom. Gitolite is a great project and it has many useful features such as branch-level access control. That might be what he meant by "overkill". He simply didn't need those features. I think there's much to be said for keeping things simple.
CodeMage 15y ago
Don't see why it was necessary to criticize the post so much. True, the title is a bit inadequate, but it's nice to find a combination of several tidbits, tips and tricks combined on one page.
- moomerman 15y ago
  Thanks, I don't understand the criticism either, the feedback via twitter has been quite positive so I will take both on board when writing any further posts.
aaronblohowiak 15y ago
So, most of this is based on the ability to specify the command that the user is forced to run in authorized_keys to be a wrapper command that you wrote. This wrapper command reads its arguments and then will execve git shell as appropriate. What's important to note is that this also talks about SSH_ORIGINAL_COMMAND, which is the environment variable set by sshd when invoking the forced command that is specified in authorized_keys. Clever hack.
Gonzih 15y ago
Nice education post.
deleted 15y ago
[deleted]
jln 15y ago
Isn't the point of the D in DVCS that this is supported out of the box? What's wrong with: root@server# apt-get install git-core git@server$ mkdir ~git/repo.git git@server$ git init $! user@client$ git remote add origin ssh://git@server/repo.git

64 points by moomerman 15y ago

wccrawford 15y ago

Copying code into a file isn't 'coding'. And it took a lot more than 5 minutes to work all this out.

moomerman 15y ago
Sorry if you find the title misleading, it certainly wasn't intended that way. In fact, sometimes I find it harder to pick the right title than I do to write the blog post. My intentions were that you could read the article in 5 minutes and the code sample would give you a good starting point to code your own implementation.

chriseidhof 15y ago

I use gitosis, and it's very simple to set up and manage. It doesn't feel like overkill at all.

balac 15y ago
I like Gitolite, it has more fine grained permission control and is pretty simple to get up and running.
Gonzih 15y ago
I was using Gitosis, now i switch to Gitolite, it's better and simpler.
- davvid 15y ago
  Gitolite is also well supported. Gitosis is basically an abandoned project. kernel.org's new git infrastructure will be using gitolite which means you can pretty much count on it being supported well into the future.

X-Istence 15y ago

This just seems to be a case of Not Invented Here syndrome. Using gitolite or gitosis would have done the job faster, gives you the ability to have acl's set up per user and all of it uses simple configuration files.

ajross 15y ago
Agreed. Or for small trusted teams any linux box with ssh access will do fine. This is a very well served product area, it really shouldn't be a problem that demands new software development. Edit: Hah! That's basically what it is, just dressed up with a tiny script and the two-factor trick from last week. Never mind then. This is sane. Just maybe oversold.
moomerman 15y ago
To be fair, the example I have given is simple and you could use something like gitosis or gitolite (I have used them in the past). The point of the article was supposed to be a starting point if you have something else you want to do. For example, I needed to have a fully distributed git backend system across multiple git storage nodes so I needed to learn how I would go about doing that. This post was supposed to give the reader the tools they need to roll their own solution if they want.
- calloc 15y ago
  For what you are suggestion wouldn't it be simpler to start with a known code base such as gitolite and to then add the modifications you require?
davvid 15y ago
NIH or not, I enjoyed reading this post. It showed the simplicity of serving git repos and walked readers through the entire process top to bottom. Gitolite is a great project and it has many useful features such as branch-level access control. That might be what he meant by "overkill". He simply didn't need those features. I think there's much to be said for keeping things simple.

CodeMage 15y ago

Don't see why it was necessary to criticize the post so much. True, the title is a bit inadequate, but it's nice to find a combination of several tidbits, tips and tricks combined on one page.

moomerman 15y ago
Thanks, I don't understand the criticism either, the feedback via twitter has been quite positive so I will take both on board when writing any further posts.

aaronblohowiak 15y ago

So, most of this is based on the ability to specify the command that the user is forced to run in authorized_keys to be a wrapper command that you wrote. This wrapper command reads its arguments and then will execve git shell as appropriate. What's important to note is that this also talks about SSH_ORIGINAL_COMMAND, which is the environment variable set by sshd when invoking the forced command that is specified in authorized_keys. Clever hack.

Gonzih 15y ago

Nice education post.

deleted 15y ago

[deleted]

jln 15y ago

Isn't the point of the D in DVCS that this is supported out of the box? What's wrong with: root@server# apt-get install git-core git@server$ mkdir ~git/repo.git git@server$ git init $! user@client$ git remote add origin ssh://git@server/repo.git