git, gitosis, gitweb and friends...

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

SetEnv GITWEB_CONFIG /srv/gitosis/.gitweb.conf

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!

You can follow James on Mastodon for more frequent updates and other random thoughts.
You can follow James on Twitter for more frequent updates and other random thoughts.
You can support James on GitHub if you'd like to help sustain this kind of content.
You can support James on Patreon if you'd like to help sustain this kind of content.

August 19, 2010
748 words

• technical