Me and my business partners needed to set up our own GIT server to keep our source code repositories on. We considered putting the repositories at some home machine and allow the others to access it via internet, but after some considerations we decided to put it on a neutral place on-line instead. A good virtual server should be more reliable than our home networks and internet connections.
Our code is not open source, and we do not want to put it on GitHub. GitHub offer private closed hosting, but in the light of the recent problems with the Chinese government and their anti-campaign and DDOS attacks, we'd prefer to stay away.
We decided to set up our own Digital Ocean virtual machine for the purpose. They are cheap, seem reliable (we got friends using it and loving it) and they also offer backup of the virtual machine so we don't have to bother with that ourselves.
Registering an account and creating the virtual machine, called Droplets by DO, was pretty easy. You need to verify your mail and register a credit card or alternatively pre-pay with PayPal.
We chose the smallest sized virtual machine for $ 5 (USD) per month, and an additional $ 1 for adding scheduled backups of the machine. The smallest machine has 20GB storage, 512MB RAM and allows 1TB data traffic per month. This will be more than enough to host a small GIT server. You can always upgrade to more disk, RAM or bandwidth any time later.
We chose Ubuntu 14.04 64 bit as Linux distribution, and placed the server on a location in Europe (to stay away from NSA). Installing was extremely easy, you just have to select distribution, size, a name for the machine, the location and some settings if you require IPv6 etc. You can upload a SSH public key to be used for logging in as root when the machine is finished. It is also possible to get a root user password instead, and it is mailed to the contact address.
After a few minutes the machine was up and running. SSH was not accessible directly unfortunately. The standard installation only enables the SSH key authentication method, but I chose to get a password. Luckily there is a web based console interface where you can log on into your new machine and set things up.
First thing I did was to enable ssh password authentication. To do that you need to generate host keys for sshd. I made an ECDSA key first, but I had problems logging in from an older machine, so I also added an old school RSA host key as well at a later time. Anyway, I ran these commands (as root):
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key service ssh restart
After this you may log into the machine using the password you got by mail. The virtual Ubuntu machine is pretty slimmed down by default, and netstat only reports port 22/SSH as listening. You need to do some standard sysadmin stuff, like change the root password, create a normal user for you and maybe others etc. I added my personal account to the sudo group, enabling the sudo command.
To get going with GIT and Gitolite you should install these software packages. Do this (as root or with sudo as here):
sudo apt-get install git gitolite
You need to add a user for Gitolite. The user name "git" seems to be used by many for this, so I took that as well
sudo adduser git
Just set some name or press enter on the questions and set a password. You can disable the password as it will never be used directly with:
sudo passwd -d git
You also need to prepare a SSH key pair that is used for administration of GIT with Gitolite. Use your existing .ssh/id_rsa.pub or create some new key for this purpose. The public part of the key needs to be uploaded to the server and put where the new git user can access it. You can for example upload and put it in /tmp/. Scp and sftp can be used as you have SSH running. The key file should be named as the user name you want for the admin user in Gitolite. You can only add one key initially for administration, but you can easily add more administrator keys later. I made a local key only to be used for administration of Gitolite, but you can use any public key you like. I named mine: /tmp/moggen-local.pub
Log in into the git account with:
sudo su - git
Make sure you can access the initial admin SSH key (in my case /tmp/moggen-local.pub), and run this:
This will create some directories and files and create the admin database. Gitolite is actually using a special GIT repository for managing. You clone this GIT using SSH and that key you just installed the public part of, change files, commit and push. Gitolite uses GIT triggers to react to the changes, updating users, keys, access rights, adding new repositories, deleting and so on. Very clever.
I used my local account on the virtual machine itself to clone the admin GIT repository, but the procedure is the same for external accounts. You need the matching private SSH key identity on that machine and the account you are using. Clone using a command line like this:
git clone ssh://firstname.lastname@example.org/gitolite-admin
You need of course to add the machine IP number to your domain name if you want to use that. You can always go directly on the IP otherwise. The important things are that the user name is "git" (the git@ part of the URI), the name of the repository and that the SSH key authentication is working properly.
If all is well you will be able to clone the admin git. It is very simple initially and only contains two directories with one file in each. conf/gitolite.conf is the main configuration file. keydir/ contains the initial ssh public key for admin. In my case moggen-local.pub
The initial Gitolite config contains this
repo gitolite-admin RW+ = moggen-local repo testing RW+ = @all
This says that the user (users are in essence SSH key files) moggen-local may read and write to the admin repository. There is also a playground repository called "testing" that all users have access.
To add users, add their public SSH key named as "username".pub in keydir/ Add the new user to a repository or add a new "repo" definition. That will create the GIT repository. Example of gitolite.conf when adding my home workstation SSH key and my friend Jakov to a repository called fungame.git, and allowing the user "build" to have read-only access:
repo gitolite-admin RW+ = moggen-local repo testing RW+ = @all repo fungame.git RW+ = moggen jakov R = build
To make things actually happening, add the new .pub key files and the changes to the gitolite.conf, commit the changes into GIT and do a "git push". The triggers in the admin git repo will pick up the changes and perform the necessary modification. If something goes bad, it will refuse to accept the commit when pushing. Find the error, commit, and re-push.
The newly created empty GIT repository can be checked out right away:
git clone ssh://email@example.com/fungame.git
Me and Jakov may push commits to this repository, but our automated build machine is prevented from pushing changes.
All GIT repositories created by Gitolite are equipped with special GIT triggers that check that users are allowed to access or push data. As long as Gitolite is used for creating, all will be good. But be careful if you manually add existing repositories directly to the file system in the git user directories. You need to initialize them so that the security triggers are created and the access control is enabled!! Please see the documentations about this.
There are lots of tricks you can do with Gitolite. Please see the home page for more information.
As an extra bonus, I also changed the port number on the GIT server so that SSH is not on the standard TCP port 22 but some other high port to avoid lame DOS attacks etc. This affects how you log in with SSH and the GIT clone URIs. To use for example port 12345:
git clone ssh://firstname.lastname@example.org:12345/fungame.git