GitoLite: Your very own Git Server on Mac OS X Server
GitoLite is a simple Git server that can handle user authentication per project / branch. Even though I don’t mind too much to shell out $300 bucks for a simple business plan with GitHub I want to keep my code closer to my heart that anything else. Even though I don’t think that my server is tightly protected it is at least my fault when something goes wrong. Lately there have been reports of nasty security breaches on user data servers and even Dropbox had their account unprotected for a few hours.
The first thing I was surprised of was the fact that there is no out-of-the-box git server available as it is with Subversion. Then I tried Gitosis but ran into issues with Python and abandoned that. Later I heard about GitoLite which gave me some grief at the beginning but eventually I could make it work out. The trick was to make sure that I was focuses on the task and made sure only to proceed if the previous step worked out.
Update: I copied this documentation to my XWiki.
To install Gitolite you need to follow these steps and make sure that all work before go to the next. Unfortunately the error message are cryptic and so it is hard to figure out what is wrong.
The Rules:
- This installation is tested for Mac OS X Snow Leopard (10.6) Server
- Make sure that each step worked nicely
- I tested the installation on a Mac OS X server and on a workstation you need to create the user account yourself. Make sure that you can login as the given user.
- SSH can be nasty at times so I make sure that it works before going on. This means we need to undo a step later but it is worth while.
- I could not clone a repository on the server but that is because I forgot to add my SSH public key of the server as well.
- Gitolite needs your public SSH key file from the workstation where you initially are going to configure the server. This also means that this is the only computer from where you can access the git server until you added new public SSH key files.
- Keep in mind that for Gitolite a user is a combination of a user and a computer which is represented by the public SSH key. That means that you need to install a public SSH key for every user and every computer they want to access the Git server from. The positive side is that you don’t need to manage passwords because the user is authenticated by the SSH key pair.
Installation Step of GitoLit:
- Create a user named “git” on the server with a home directory (assuming “/Users/git”) using WorkGroup Manager
- Copy the public ssh key (for example id_rsa.pub) from your local workstation onto the server (use ‘ssh-keygen -t rsa’ to generate one inside the ‘~/.ssh’ directory. Make sure that permission is set to “700” on the “~/.ssh” directory.
- Add the content of your public key file on the server into this file (create one if needed): ‘/Users/git/.ssh/authorized_keys’ and also make sure that the permission on the .ssh directory is set to 700.
- On the workstation try to log in using:
ssh git@<my server>
If you can login without entering a password your are good to proceed. Otherwise you need to check the permissions as well as the content of the authorized_keys file that no character was dropped.
- Make sure “git” software is installed by executing “git” on the command line (should be there by default)
- There is one little problem left. For whatever reason the path to the “git” software was not setup on my server. So create or edit “/Users/git/.bashrc” and add the following lines:
#!/bin/bash export PATH=$PATH:/usr/local/git/bin/
- Check the path from your workstation with:
ssh git@<server name> echo $PATH
- It must contain ‘/usr/local/bin’ and ‘/usr/local/git/bin’
- Attention: the test on 7) must be done before installation Gitolite because afterwards we cannot login as git on the server using SSH (it will give you a list of repos instead)
- Login to your server and sudo (sudo -s) to become root
- Get the gitolite code:
git clone git://github.com/sitaramc/gitolite
- Change into the ‘gitolite’ directory and execute this:
src/gl-system-install
- Now become user “git” (IMPORTANT) using ‘su git’ (check with ‘whoami’)
- Change into the “gitolite/src” directory (from the code cloned above; if you followed the instruction you should already be inside the ‘gitolite’ directory)
- Change the name of the public ssh key because Gitolite will use that as name for the virtual user
- Execute the setup with:
gl-setup <path to the renamed public ssh key>
- Because Gitolite is also installing the same public ssh key we need to go back to ‘/Users/git/.ssh/authorized_keys’ and delete the line we originally added to test the passwordless login
- Now login into the server with SSH
ssh git@<server name>
should display this:
PTY allocation request failed on channel 0 hello schaefa, the gitolite version here is v2.0.2-6-gfda9f37 the gitolite config gives you the following access: R W gitolite-admin @R_ @W_ testing Connection to 192.168.0.2 closed
- On the workstation checkout ‘gitolite-admin’ with:
git clone git@<your server name>:gitolite-admin
Next Steps:
The Gitolite server is configured use the clone of the ‘gitolite-admin’ and your workstation and then pushed back to activate it. So for example to create a new repo:
- Go to the ‘gitolite-admin/conf’ directory
- Open ‘gitolite.conf’ file and add a new repo name together with the users allowed to access it
- Commit the changes:
git commit -a -m "Your Message here"
- Push the changes to the server
git push origin
- You can now clone the new repo using
git clone git@<server name>:<your new repo name>
- Because you checked out an empty repository there is no master branch there. Therefor when you push the repository to the origin for the first time it will complain about the missing branch. Then you need to push them together the branch name:
git push origin master
To add new users you need to do the following:
- Ask the users for a public SSH key (id-rsa.pub)
- Rename the file so that it names the user (maybe together with its computer)
- Copy that file to ‘gitolite-admin/keydir’ or any sub directory
- Gitolite will seach for these files recursively so you can organize them as you like
- Commit these changes to your local repo
- Push the changes to the server
Notes:
In case you have problems understanding how GIT works then you might want to check out the book Pragmatic Guide to GIT from the Pragmatic Bookshelf as it gives some ideas how to use it. Anyone coming from Subersion, as I did, will have quite some problems to understand how git works.
Comments are closed.
Excellent guide, quite helpful.
In step 7 if i echo $PATH then in the output I don’t have /usr/local/bin only usr/local/git/bin (and some other stuff)
however, if I echo just $PATH (remove ) then in the output I do have usr/local/bin
Am I doing something wrong? (.bashrc is as per)
The slash in “ssh git@ echo $PATH” is there to escape the $ sign. Normally in a shell a dollar sign means that you want to expand that environment variable. In this case you don’t want to echo your local PATH variable but the server’s PATH variable and therefore you need to escape it.
Keep in mind that you need the path “/usr/local/bin” set on the Git server in order to work otherwise some script inside Gitolite might not work. Also keep in mind that it might not be enough (at least it was for me) to login to the Git server and echo the PATH.
Hey, me again.
Under Next Steps, shouldn’t step 3 say “git commit -a -m ‘Message'”
and shouldn’t step 4 say “git push git@:gitolite-admin”
?
No.
Because you are inside a git repository Git knows what to do. The only thing is to tell Git where to push to. What you can do and I did not mention is that you can use:
git remote
and it will list any remote repositories. Because you cloned your gitolite-admin you should have a remote repository called “origin”. If you have this you can use:
git push origin
“origin” means the place where you cloned your repository from (git clone …).
That said if you want to push your repository to any server you can use:@
git push
which is was I suggested in 4).
very awesome. thank you for this comprehensive guide!
just a few additions:
ad 12.) there is a nasty typo in the command, which caused me to restart the whole process thrice: it needs to read “src/gl-system-install” instead of “src/gl-sytem-install”
ad 14.) at that point i was already in the gitolite directory, i.e. the required command was “cd src”, not “cd gitolite/src”
ad 19.) i ran into an error at this point. both the error and the fix (export GIT_EXEC_PATH=/opt/local/libexec/git-core — for me anyways) are explained in this article http://stackoverflow.com/questions/5041067. maybe you’d like to add a reference to that?
thanks again!
mario
Hi Mario
Thanks for the feedback. I fixed the typo. To point 14) this might or might not work this way depending on how you became user “git” (su -). That is why I said you should change to this directory rather saying “cd“.
Finally I did not run into your issue so I cannot comment on it. That said I added your notes and also mentioned this on my wiki page.
Hi Andreas,
I’m going through your tutorial and I’m finding it a little bit confusing around step 15. I do not understand what you mean by “Change the name of the public ssh key because Gitolite will use that as name for the virtual user”.
I created the ‘git’ user, but it doesn’t have an rsa_id file and my os x (10.6) won’t let me generate a key.
Reading ahead, could you also give an example of the path that would be used in step 16?
Thanks!
Any chance you could elaborate further on this?
Hi Chris
Git is the user of the Gitolite server but that said it is not the user of the Git version control tool. For example when you run Apache the user could be “www” but the user of wordpress is me.
Gitolite takes the name of the user (which is later used inside the “gitolite-admin” configuration to grant permission to read / write to Git. So if you take your “id_rsa.pub” and renamed is so that the file name is the user name (for example “andy_madplanet”) and keeping the extension “.pub” . After the installation Gitolite will have a user name “andy_madplanet”.
That said the user “git” on the server where gitolite is installed doesn’t need an SSH key because that user is and should not connect to other boxes. Under the cover your public SSH key will be added to the user git’s authorized_keys (under the .ssh directory) file so that you are allowed to connect to gitolite.
Hope this helps – Andy
Has anyone gotten Xcode 4 to connect to a gitolite server? I have gitolite working well from the command line and Flash Builder (Eclipse) but integrating with Xcode 4 has been problematic.
Thanks,
Brett
Hi Brett
I have no problem to us Gitolite server as long as the repository exists and I cloned it from Gitolite. This is what I normally do:
– Adding a new repository inside “gitolite-admin/conf/gitloite.conf
– Commit that change and push it back to the server (using “git push origin”)
– Clone the the repository using “git clone …”
– Create a project in Xcode and save it there
– Inside the Organizer’s Repositories tab you should see that repository automatically
Let me know if that helped you.
– Andy
Hi Andy,
Thanks for the prompt reply.
I renamed the id_rsa.pub to chris_wells.pub and that seemed to do the job!
Although when I SSH’d in to the server in step 18 it didn’t display what you said it should.
I removed the key from authorized_keys as in 17, so when I login to the server via git from my workstation I get asked for the password (to be expected), but no message as in 18 on login form workstation or directly on server.
Do you have any idea what could have gone wrong?
Cheers.
Hi Brett
Lately my configuration isn’t doing showing this anymore either and I am not sure why.
That said the important thing is that you can clone from the gitolite server and push to it.
Don’t take away the entries from the authorized_keys. I think that gitolite doesn’t let you log in that account (rather kicks you right out) to prevent people from using that account.
– Andy
Have a question regarding the installation server. I followed the same procedure for installation on Snow Leopard (not the server edition) and got to step 18 ok. At that stage I only got the first line of the server response “PTY allocation request failed on channel 0″
I went on to step 19 and the next steps sections. Step 4 failed in that section. So I could clone ok but when trying to push the changes to the server I get an error message saying
“fatal: ‘git@server-name does not appear to be a valid repository”
Thanks in advance
Suneet
Hi Suneet
Yeah, that doesn’t seem to be right. I will investigate and update the page. That said try the following: “git push origin” to push them to the place where you cloned from.
– Andy
Thanks Andy
tried that and got the following message
Everything up-to-date
And tried this before I read your post
http://www.dotkam.com/2010/08/22/gitolite-does-not-appear-to-be-a-git-repository/
http://www.howtogeek.com/wiki/Fixing_%22WARNING:_UNPROTECTED_PRIVATE_KEY_FILE!%22_on_Linux
Regards
Suneet
Hi Sinseet
Then you should be good. This means there were no changes between your local repository and the gitolite server.
If you want to be 100% sure then got to another directory, clone the repository and check if the changes are there. Then you know if it worked or not.
– Andy
Hi Andy.
Thanks for the prompt responses. I did what you suggested and the changes weren’t there.
Also checked the repositories folder on the server for the new repository, that I would expect to be created when I commited with git push origin and couldn’t find it. Only one repo was created when I followed the links I sent above.
Regards
Suneet
Try to do a “git status” and see if you committed your changes locally. Keep in mind that unlike in Subversion Git does not commit your changes until you added them or you use the “git commit -a -m “your message”.
– Andy
worked, thanks a tonne.
hello,
thanks for this post! but i ran into some glitches particularly #19.
had to search about this then i find that in #6, this line of code must be added.
export GIT_EXEC_PATH=/opt/local/libexec/git-core
hope this will help someone...
This could be depending on how you installed git. At least in my installation this wasn’t the case and so I don’t consider it a glitch. As with many Unix systems the packaging can be vary by the creator or the distribution. Anyhow for the tip to look if not found right away.
– Andy