E
Eric Hansen
Guest
Setting up a simple Git server is very easy to do; shoot, all it takes is to install Git itself and you have it for both client and server purposes. But what about when you want something more than a simple code versioning system?
For me, I needed something more. I needed something that permitted read-only access to repositories for most users, and I would have liked to have more fine-grained control over the repositories in general. Luckily, I didn’t have to look hard (but boy did it take me a while!).
If you do a lot of research on this topic, anything pre-2008 (and perhaps a little after) talk all about Gitosis, which has everything I need but hasn’t been worked on in a very long time. Thankfully there’s another solution that’s derived from Gitosis called Gitolite. This has everything Gitosis has plus a lot more. For example, you can restrict access not only per user, but per user’s IP, restrict number of files in a commit, etc…
What we’ll be doing is setting up Git, Gitolite and Gitweb (which lets you browse the repositories from the web). This part will cover Git. Even though it is a simple program to install (one line), we’ll set up our system piece by piece instead of jumping around as much as possible. Also, there are some things I’d like to make note of involving Git that I feel would be easier being in a guide by itself.
Prerequisites
Here we assume that you’re using Ubuntu. A vast majority of this should translate well between distros but it’ll be up to you to translate it. Just like most of my other guides this will be CLI heavy as well, so you should be able to work your way around that at least a bit.
Preparations
Most of this work will be done on the server that will house the git repositories, with very minimal work being done on your local machine. So, unless the guide says otherwise we’ll be working on the server.
Installing Git
Doing a simple apt-get install works wonders for this:
We install gitweb now instead of later just since it involves git. gitolite will be installed differently, however. highlight is a simple package that allows syntax highlighting, which makes things even cooler.
Create git User
We could always give git complete control over the system, but we want to be secure, right? So, we’ll set up a user specific for our git-leasure.
One switch you don’t see a lot is “gecos” which basically provides a note about the user (in this case just storing in /etc/passwd that the account is for git usage). We also make this a system account and disable the password so logging in directly is impossible (we have to su git when we want to switch to the account). However, when as git we still need a viable shell so we set it to /bin/bash.
There is git-shell, that mimics bash but enforces a lot of restrictions on the account. The reason we don’t use this, however, is that as the git user we’ll need to use some binaries in /usr/bin and such which git-shell restricts.
Edit git's .bashrc
This one will do two things:
1. Set us up for basically the rest of this guide (being git user)
2. Modify the PATH environment so that we can run gitolite binaries
This switches us to git (su = switch user), and we allow finding binaries in ~/bin instead of having to manually type the path (and potentially break scripts), then we just reload our enviornment.
The next step will be getting gitolite set up and running. After we get gitolite and gitweb set up and going then the real ACL/permissions talk will start, and it will be one heck of a journey!
For me, I needed something more. I needed something that permitted read-only access to repositories for most users, and I would have liked to have more fine-grained control over the repositories in general. Luckily, I didn’t have to look hard (but boy did it take me a while!).
If you do a lot of research on this topic, anything pre-2008 (and perhaps a little after) talk all about Gitosis, which has everything I need but hasn’t been worked on in a very long time. Thankfully there’s another solution that’s derived from Gitosis called Gitolite. This has everything Gitosis has plus a lot more. For example, you can restrict access not only per user, but per user’s IP, restrict number of files in a commit, etc…
What we’ll be doing is setting up Git, Gitolite and Gitweb (which lets you browse the repositories from the web). This part will cover Git. Even though it is a simple program to install (one line), we’ll set up our system piece by piece instead of jumping around as much as possible. Also, there are some things I’d like to make note of involving Git that I feel would be easier being in a guide by itself.
Prerequisites
Here we assume that you’re using Ubuntu. A vast majority of this should translate well between distros but it’ll be up to you to translate it. Just like most of my other guides this will be CLI heavy as well, so you should be able to work your way around that at least a bit.
Preparations
Most of this work will be done on the server that will house the git repositories, with very minimal work being done on your local machine. So, unless the guide says otherwise we’ll be working on the server.
Installing Git
Doing a simple apt-get install works wonders for this:
Code:
sudo apt-get install git gitweb highlight -yWe install gitweb now instead of later just since it involves git. gitolite will be installed differently, however. highlight is a simple package that allows syntax highlighting, which makes things even cooler.
Create git User
We could always give git complete control over the system, but we want to be secure, right? So, we’ll set up a user specific for our git-leasure.
Code:
adduser --gecos “git version control” --system --shell /bin/bash --group --disabled-password --home /home/git gitOne switch you don’t see a lot is “gecos” which basically provides a note about the user (in this case just storing in /etc/passwd that the account is for git usage). We also make this a system account and disable the password so logging in directly is impossible (we have to su git when we want to switch to the account). However, when as git we still need a viable shell so we set it to /bin/bash.
There is git-shell, that mimics bash but enforces a lot of restrictions on the account. The reason we don’t use this, however, is that as the git user we’ll need to use some binaries in /usr/bin and such which git-shell restricts.
Edit git's .bashrc
This one will do two things:
1. Set us up for basically the rest of this guide (being git user)
2. Modify the PATH environment so that we can run gitolite binaries
Code:
su git
echo “PATH=$HOME/bin:$PATH” >> ~/.bashrc
source ~/.bashrcThis switches us to git (su = switch user), and we allow finding binaries in ~/bin instead of having to manually type the path (and potentially break scripts), then we just reload our enviornment.
The next step will be getting gitolite set up and running. After we get gitolite and gitweb set up and going then the real ACL/permissions talk will start, and it will be one heck of a journey!
