- Git
- GitHub: sitaramc/gitolite
- EPEL: How can I install the packages from the EPEL software repository?
- Wikipedia: Git (software)
In this episode I wanted to talk about setting up a central Git sever and using Gitolite to manage user access. Git is so popular that it hardly needs an introduction, but briefly, Git was created by Linus Torvalds in 2005 to help manage the Linux kernel development. Over the last few years, usage of Git has exploded, mainly due to widespread adoption of GitHub, where developers can upload, collaborate, and share their code.
In this demo, we are going to look at installing Git onto a central server, say for example on an internal company network, where you and your colleagues and develop together. An additional piece of software, which we are going to install, is called, Gitolite, which will help us manage user access. Gitolite is great for things like, only allowing read access to certain accounts, managing user accounts per repository, or per branch.
As our starting point, we are going to use a minimal version of CentOS 6.4 64-bit. I have created two machines, a server called git-server, and a client machine called git-client. We will use these to test the interaction between our Git server and the Git client.
Alright, lets get started.
First, we are going to use our git-server machine, where we are logged in as root. We will be installing Git and Gitolite with Yum. Git is available in the stock yum repositories, but we need to install the Extra Packages for Enterprise Linux commonly referred to as EPEL to get access at Gitolite.
Lets jump over to fedoraproject.org, where it tells us how to install the EPEL repository. You can check out the episode notes below for the website link. Since CentOS 6.4 is a Redhat derivative, and it is version 6, we are going to install the EL6 rpm for the EPEL repository. We do this, just by copying this command, and then running it on our git-server machine, which downloads and installs the EPEL repo.
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Now that we have the EPEL repo installed, we can go ahead and install the Git server and Gitolite. Lets do that by running “yum install git-daemon gitolite3”. You can see there was a bunch of output, lets scroll up and take a look at what is happening. So, we are installing git-daemon and gitolite3, with gitolite coming from the epel repo. The rest of these packages are just dependencies. Looks good, lets move forward with the install. Okay, that was easy. Not to fast, we need to configure gitolite now.
yum install git-daemon gitolite3
After installing a new package, which I might not know too much about, I like to run “rpm –query –list gitolite3” and then pipe the output to less, just to make the output easier to parse, this command will tell us what files were installed for this particular package.
rpm --query --list gitolite3 | less
Looks like there is a gitolite command placed in /usr/bin/gitolite, along with what looks like documentation, a /usr/share/gitolite directory, some perl stuff, and then down here a gitolite home directory.
Gitolite adds a user to the system to help manage remote access. We can verify this by looking in the /etc/password file. You can see the home directory here. There was also a gitolite group added.
grep gitolite /etc/passwd grep gitolite /etc/group
Okay, now that we have installed git daemon gitolite, we need to configure a user on our git-client machine, which we can use as the administrator account. Lets jump over to our example client machine, where I am logged in as the user jw, on the machine git-client.
If you do not already have the Git client software installed, you can do this by running “sudo yum install git”, I already have it installed, but you can verify this by running git, and hopefully seeing a help page.
sudo yum install git
git
If this is a new install of the Git client, then you need to configure a couple things. We need to set the git user name and email. These will be communicated to the Git server when you do commits. We set this by running, git config –global user.name “Your Name”, and then we run git config –global user.email justin@example.com. These entries are stored in your home directory in the .gitconfig file.
git config --global user.name "Your Name"
git config --global user.email yourname@example.com
cat ~/.gitconfig
Remote access to our git server will be handled via the gitolite user over ssh, and gitolite validates remote access based on your ssh key. Basically what we are doing is establishing a ssh trust between our jw user on git-client and our gitolite user on the git-server. To do that we need to generate a ssh key, if it doesn’t already exist, and copy to over to the git-server.
Chances are that you already have a ssh key, but since this is a demo, I’m going to create a new one. We do this by running, ssh-keygen -t rsa -b 2048.
ssh-keygen -t rsa -b 2048
We are then asked a couple questions, like where should we store the key, and if you would like to enter a passphrase. I just hit enter and accepted the default on all of these. The ssh key we are looking is in, /home/jw/.ssh/id_rsa.pub file. Lets to take a look at it. It’s stored in the .ssh folder. Here it is, lets take a look at it.
Now we need to copy this id_rsa.pub file over to our git-server. We can do this by running “scp ~/.ssh/id_rsa.pub root@git-server:/tmp/jw.pub”. You’ll be prompted for the root password, and hopefully it transfers successfully. Okay, so we ran scp, copies our users ssh public key, over to our git-server in /tmp/jw.pub.
scp ~/.ssh/id_rsa.pub root@git-server:/tmp/jw.pub
Okay, now that we generated the ssh key, lets jump over to our git-server, where we can configure gitolite with this new key. First, lets change user accounts from root to gitolite3. We’re gonig to run “su - gitolite3”. Then we are going to run “gitolite setup –pubkey /tmp/jw.pub”. This will initialize our default repos, and establishes a ssh trust between our gitolite user, on the git-server, and our jw user, on the git-client, whos ssh key we copied over.
su - gitolite3 gitolite setup --pubkey /tmp/jw.pub
This gitolite admin repo is very special, in that we can remotely manage this git server through this repo. We can create new repos on the server and manage user access, all by manipulating the files in this repo.
Lets test this out by jumping back over to our git-client machine where we are logged in as the jw user. At this point you should be able to run “ssh gitolite3@git-server info”, so we are connecting as the gitolite3 user, to git-server, and running the info command. You’ll notice that we connected as the gitolite3 user but it still knows we are the jw account. Gitolite is pretty smart in that it knows know people are based off their ssh keys. Down here, gitolite give a listing of the repositories and our access right, in this instance, full read and write.
ssh gitolite3@git-server info
As I said earlier, we can remotely manage the git server by manipulating the gitolite-admin repo. Lets clone the repo and have a look. We are going to run “git clone gitolite3@git-server:gitolite-admin”. A directory called gitolite-admin was created, lets go in there and have a look. Inside gitolite-admin we have two directories, one stores the gitolite configuration file, and the other our gitolite user ssh keys.
git clone gitolite3@git-server:gitolite-admin
This basically concludes the git and gitolite setup. At this point we have a fully functional system, but lets try and add a repositories, and some users, just to give you some real world examples.
To add a new repository, lets open conf/gitolite.conf under the gitolite-admin repository, note that we are doing this on the client machine. The goal, it to create a new repository called foobar, so we just copy the existing syntax, “repo foobar”, and then just copy this access like, which, just says allow read and write access to the jw user.
I always like to run “git status”, just so I know what the current state, like if my changes were actually saved. Output says one file was modified, so I guess they were. Lets commit the changes, by running, “git commit -a -m “- added foorbar repo”. Lets run “git status” again. Now, lets push these changes out to our git server, by running “git push”.
So, you can see it says, initializing empty git repository foobar. Sweet, lets just run the “ssh gitolite3@git-server info” command again to verify we actually have access. Yup, looks like its working, pretty cool that we can remotely manage our git server all through this gitolite-admin repo.
vi conf/gitolite.conf
git status
git commit -a -m "- added foobar repo"
git status
ssh gitolite3@git-server info
In this next example, lets say we want to open this up for wider user. We let Bob, Alice, and Jeff, our colleagues, know about the new central git server. We ask them to copy their ssh public keys into the /tmp directory. In reality, they could provide them in any number of ways.
We add users to gitolite simply by adding their ssh key to the key directory. Lets copy those, actually, lets me just show you where I am in the directory structure, right now. We are on the git-client machine, in the gitolite admin repo, there are two directories, conf, and keydir. We are going to copy the ssh public keys in /tmp into key directory.
Now lets assign Alice, Bob, and Jeff to our foobar repo. Lets open up the conf/gitolite.conf file. Lets just add entries for Alice, Bob, and Jeff. We are going to give them basic read and write access, the plus sign beside RW mean we can do any type of push, and lets give Jeff only read access.
Lets run “git status”, so it says there are some untracked files, we can add these by running, “git add .”, then lets run “git status” again, now it knows about our new files and that we modified the gitolite.conf file. Lets commit the changes, something like added alice, bob, and jeff to the foobar repo. Then we will run “git push” to push the changes to our git server.
Okay, just to prove that this all works, lets login to each of these accounts to run the “ssh gitolite3@git-server info” command. Lets start with alice. So, you can see gitolite knows we are alice, and shows us two repositories, foobar and testing, you’ll note that gitolite-admin is missing, that’s because this is special and hidden from non admins.
Next, lets login using bob’s account, and we’ll run the same command. Again, gitolite knows we are bob, based off our ssh key, and it has the correct repos.
Next, lets login using Jeff’s account, and we’ll run the same command. Again, gitolite knows we are Jeff, based off our ssh key, and it has the correct repos. You’ll also note that gitolite picked up that Jeff only have read access.
Just to recap, lets have a look at the gitolite.conf files again. Here we defined the foobar repo, and you might be wondering why everyone has access to the testing repo, that’s because the @all mean all users have access, it’s a group.
Hopefully you find this information useful, if you are ever in need of a local git server, say for your projects, or internal office, this is a great solution!