In case it wasn’t already obvious, I am a huge fan of git, and often prefer it over sliced bread. Recently to help a small team of programmers collaborate, I decided to setup a private git server for them to use. By no claim of mine is the following tutorial unique, however I am writing this to aid those who had trouble following other online tutorials.
Goal:
Setup a central git server for private or public source sharing, without having to give everyone a separate shell account.
Step 1:
Install git, gitosis, and gitweb by the method of your choosing. Most distributions probably have packages for all of these.
Step 2:
Create a user account named “git”, “gitosis”, or something sensible if it hasn’t already been done by some packagers install script. The shell command to do this yourself looks something like:
sudo adduser --system
--shell /bin/sh
--gecos 'git version control'
--group
--disabled-password
--home /srv/gitosis
gitosis
In my particular case, I edited the /etc/passwd file to change the automatically added account, however running sudo dpkg-reconfigure gitosis is probably an easier way to do this.
Step 3:
Authentication is done by public ssh key, and gitosis takes care of the magic relationships between a users key and the read/write access per repository. As such, gitosis needs initialization, and it needs the public key of the administrator. If you aren’t familiar with ssh public key authentication, go learn about this now.
To initialize gitosis most tutorials alledge that you should run something like:
sudo -H -u gitosis gitosis-init < SSH_KEY.pub
In my case, this didn’t work (likely due to environment variable problems, but try it first anyways) so I cut to the chase and ran:
sudo su - gitosis
gitosis-init < /tmp/SSH_KEY.pub
which worked perfectly right away. Note that you have to copy your public key to a publicly readable location like /tmp/ first.
Step 4:
Now it’s time to change the gitosis configuration file to your liking. Instead of editing the file directly on the server, the model employed is quite clever: git-clone a special repository, edit what’s necessary and commit, then push the changes back up. Once this is done, git runs a special commit-hook that generates special files needed for correct operation. The code:
git clone gitosis@SERVER:gitosis-admin.git
Step 5:
To add a new repository, and its users, into the machine, the obvious bits are done by making changes in the recently cloned git directory. Once a user has access, setup the new remote, and push.
git remote add origin gitosis@SERVER:the_repository_name.git
git push origin master:refs/heads/master
Subsequent pushes don’t need the master:refs/heads/master part, and everything else should function as normal.
Gitweb:
I still don’t have a happy gitweb+gitosis installation. I’m using apache as a webserver, and I wanted to leave the main /etc/gitweb.conf as unchanged as possible. The gitweb package that I installed, comes with an: /etc/apache2/conf.d/gitweb and all I added was:
SetEnv GITWEB_CONFIG /srv/gitosis/.gitweb.conf
between the <directory> braces. I used the template gitweb configuration file as provided by gitosis.
Gitosis:
The last small change that I needed for perfection is to store the gitweb configuration in the gitosis-admin.git directory. To do this, I added a symlink to /srv/gitosis/repositories/gitosis-admin.git/gitweb.conf from the above gitweb config location. The problem is that the file isn’t in the git repo. This would require patching gitosis to recognize it as a special file, and since the author doesn’t respond to patch offers, and since the gitweb config is usually completely static, I didn’t bother taking this any further.
Gitolite:
It seems there is a well maintained and more fine grained alternative to gitosis called gitolite. The author was very friendly and responsive, and it seems his software provides finer grained control than gitosis. If I hadn’t already setup gitosis, I would have surely investiaged this first.
Etckeeper:
If you haven’t yet used this tool, then go have a look. It can be quite useful, and I only have one addition to propose. It should keep a configurable mapping (as an etckeeper config file) with commands to run based on what gets updated. For example, if I update /etc/apache2/httpd.conf, then run /etc/init.d/apache2 reload.
Happy hacking!
