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 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
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
/etc/gitweb.confas unchanged as possible. The gitweb package that I installed, comes with an:
/etc/apache2/conf.d/gitweband all I added was:
SetEnv GITWEB_CONFIG /srv/gitosis/.gitweb.conf
/srv/gitosis/repositories/gitosis-admin.git/gitweb.conffrom 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.
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
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.