Let us suppose: we need our own private Git repository running on our remote server. It might be our own hardware in our own office, servers room or it can be a Virtual Private Server(s) running on side of our hosting provider, Cloud Servers or whatever you want. That even could be a dedicated or shared hosting, it doesn’t sucks! No matter, what Server(s) (except one simple and intuitive rule: NO Windows inside! It sucks!) or hosting provider we use, a task is still the same: our own private Git repository. As an additional feature, we want to run with some modern Git Web View. The first question here – why just not use GitHub as a service for our private and public repositories?! Possible answer here – I’m particularly using GitHub for public repositories, however, what if we want to have an unlimited number of collaborators and repositories??!! From this point look at the GitHub pricing now. Maybe we just do NOT want to pay for our private repositories and also, want to keep it in top secret. Yes, I’m a paranoid.

Technology Stack

A brief overview of what we’ll use in this installation:

• Obviously a Git;
• Gitosis – for access control to our repositories;
• Connection through SSH. In many cases OpenSSH software on the server end. It should to be installed already. If not, do it yourself (if, for some mysterious reasons, you don’t know how to do that – do NOT ask me how and stop reading this). I’ll not explain how to configure authentication with WebDav here – Google it!;
• For the Git Web View we will use Warehouse 2, that is actually a complete rewrite of original Warehouse for SVN that is build for Git;
• Ruby and Ruby on Rails. If you’re running under shared hosting and of course, have not root access, check out if your provider supports Ruby and Rails installed on your server. If not, this is sad, because in such case you can install Ruby into user’s home directory, however, Rails installation will be very difficult or even impossible, because you’ll need at least Passenger installed and configured. Whatsoever, in many cases you will notice availability of Ruby on your server. But, if you’re using sharing hosting plan and hosting provider do NOT providing Rails support, I cannot help you. Pick another provider instead or switch to the Virtual Private Server(s), Cloud Sever(s), whatever;
• The Python 2.5 and Python setuptools package.

That’s all what we need. Although, none of these steps are difficult, the number of steps themself, can be intimidating. Don’t let it get to you. If you make a mistake, wipe it clean and start over. Okay, lets go!

Git with Gitosis

Git by itself, out of the box, provides no method of access control. If you know URL for a git repository, you can clone it. Without some mechanism of access control, you can commit to it as well. Gitosis is a wrapper that provides fine grained access control to your publicly visible git repositories.

You can configure Gitosis such that each user has different authentication and authorization levels for each repository in the set of repositories contained in the directories of a user account.

As first step, create a user account, in this example githuber, with shell access. This account will be used for the git repositories and nothing else. Note, that after successfully installing Gitosis, you will NOT be able to login to this account. You can login to a different user account and su to this account if you need shell access.

If you are not already using SSH generated public and private keys, you will need to have SSH on your desktop computer. After installing SSH, you will need to generate the public/private key pair. Well, you need to get your desktop user public ssh key onto the remote server:

 [local]$ ssh-keygen -t rsa
 [local]$ scp ~/.ssh/id_rsa.pub githuber@example.com:~

If you already have a public/private key pair, then the first command will let you know and don’t bother over-writing it. NOTE: do NOT add your RSA public key to the Gitosis user’s .ssh/authorized_keys. If you do this, you can still access this new account after installation, but Gitosis will not able to let you push new repository, and you need to type full path when cloning gitosis-admin.conf later. Instead, use password to login this new account.

Installing Git

Many hosting providers have Git already installed. Of course, a more recent release is suggested. However, if your server indicates its running 1.7, so just skip this step. Check out your Git version like this:

 [server]$ which git
 /usr/bin/git
 [server]$ git --version
 git version 1.7.1

If there is no Git installed or version on your server 1.6 (or even less), then install Git following by these steps:

 [server]$ cd
 [server]$ mkdir src; cd src
 [server]$ wget http://kernel.org/pub/software/scm/git/git-1.7.4.tar.gz
 [server]$ tar xzf git-1.7.4.tar.gz
 [server]$ cd git-1.7.4
 [server]$ ./configure -prefix=$HOME NO_MMAP=1
 [server]$ make && make install

These steps will install Git into your home directory. Hence, if you have root access, install Git into the system instead, with appropriate changes to the commands above (use sudo or type almost the same being a super user). Also note: we’re using compilation flag NO_MMAP=1 only from installation into user’s home directory to prevent procwatch service to kill your Git daemon. Since Git while pushing process unpacking an objects and accommodating a lot of space, procwatch service may kill Git daemon without an error and you will not understand why. It’s very hard to catch. Just use this flag with installation as a non-privileged user.

For more information about Git configuration look at this.

Installing Python

Gitosis requires Python at version 2.4 or higher. If your server reports an appropriate version of Python, so again skip this step. If you’re unlucky in this way just follow steps below to install Python into user’s home directory (for super user just change commands as appropriate):

 [server]$ cd ~/src
 [server]$ wget http://www.python.org/ftp/python/2.5.5/Python-2.5.5.tgz
 [server]$ tar xzf Python-2.5.5.tgz
 [server]$ cd Python-2.5.5
 [server]$ ./configure --prefix=$HOME
 [server]$ make && make install

Installing Python Install Tools

Gitosis is implemented in python and is packaged as a python package. The python install tools are required to install Gitosis. You need the install tools matching the release of python you are using.

 [server]$ mkdir -p $HOME/lib/python2.5/site-packages
 [server]$ export PYTHONPATH=$HOME/lib/python2.5/site-packages
 [server]$ cd ~/src
 [server]$ wget http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c11-py2.5.egg
 [server]$ sh setuptools-0.6c11-py2.5.egg --prefix=$HOME

Installing Gitosis

You will clone the Gitosis repository and install from that repository. Also, you will set some persistent environment variables on your user account, that will cause the correct instances of git and python to be invoked.

 [server]$ git clone git://eagain.net/gitosis.git
 [server]$ cd ~/src/gitosis/; export PATH=$HOME/bin:$PATH
 [server]$ python setup.py install --prefix=$HOME; cd
 [server]$ echo "export PYTHONPATH=$HOME/lib/python2.5/site-packages/" >> .bashrc
 [server]$ echo "export PYTHONPATH=$HOME/lib/python2.5/site-packages/" >> .bash_profile
 [server]$ echo "export PATH=$HOME/bin:$PATH" >> .bashrc
 [server]$ echo "export PATH=$HOME/bin:$PATH" >> .bash_profile
 [server]$ . ~/.bash_profile; gitosis-init < id_rsa.pub
 [server]$ chmod 750 $HOME/repositories/gitosis-admin.git/hooks/post-update

Don’t ask. It’s magic.

Using Gitosis

Administering Gitosis uses Gitosis itself. Your public key gives you access to a repository called gitosis-admin.git. The gitosis-admin.git repository was created when you initialized Gitosis in the previous step. To get access to this repository and its files, you will clone that repository from your server user account to your desktop computer.

 [local]$ mkdir ~/projects; cd ~/projects
 [local]$ git clone githuber@example.com:gitosis-admin.git
 [local]$ cd gitosis-admin

NOTE: IF the above didn’t work for you, you have to change the ‘git clone …‘ line to:

 [local]$ git clone githuber@example.com:~/repositories/gitosis-admin.git

You now have the Gitosis configuration files on your desktop computer. Using these files you will add users and repositories to your remote host repositories.

Adding a Repository and (optional) User

To add a repository to your remote host, edit the gitosis.conf file in the gitosis-admin repository. After adding the repository to the Gitosis controls, you will create the repository and push it to the remote host.

 [local]$ cat ~/projects/gitosis-admin/gitosis.conf
 [gitosis]

 [repo JavaPixelazier]
 description = The stub of sample applications with primary goal on Java Desktop
 owner = alex@apleben.com

 [group devs]
 members = alex@apleben.com

 [group admins]
 members = alex@apleben.com

 [group gitosis-admin]
 writable = gitosis-admin
 members = @admins

 [group myteam]
 writable = JavaPixelazier
 members = @devs

Where:

• myteam: is the name of a group (not the repository);
• JavaPixelazier: is the name of the new repository;
• members : is a space delimited list of users who can commit to this project (SSH public key identification).

When you are adding new users, you will have to copy their public key into the directory ~/projects/gitosis-admin/keydir. Follow the admonitions about spurious newline characters in SSH public keys. Push the gitosis-admin repository back to the remote host:

 [local]$ git commit -a -m"Add repository: JavaPixelazier, writable by Alex"
 [local]$ git push

Now create the project on your local desktop…

 [local]$ cd ~/projects # or where ever you keep stuff
 [local]$ mkdir JavaPixelazier; cd JavaPixelazier
 [local]$ git init
 [local]$ git remote add origin githuber@example.com:JavaPixelazier.git
 # do some work, git add and commit files
 [local]$ git push origin master:refs/heads/master

Subsequent push to the remote repository does NOT require anything more than just “push”. Your repository is now on your account at remote server!

We left all hard work behind. The last step is easy and not so challenged.

Git with Warehouse

The last step is – Warehouse installation, configuration (that doesn’t hurts) and synchronization with your Git repositories. As mentioned previously, Warehouse requires Ruby and Ruby on Rails installed on our Server. If and only if, you’re sharing hosting customer, whose very unlucky to do not have Rails or even Ruby installed on your particular server, thats it – end of the game for you. It is very hard or even not possible to install Rails in such situation, because you need at least Passenger installed and configured on the server. The answer here could be only one – re-think your Hosting Provider. If you’re the lucky one with Rails already installed, I’ll explain only one thing here: how to properly configure locally installed Gems for usage. This is usable in situation there you have not root access, otherwise install Gems into the system instead. Nonetheless, if you have root access and don’t know how to install Ruby and Rails – the Search Engine is your best friend ever.

Using Gems Installed in Your Home Directory

You may install gems which is not pre-installed on the servers in your home directory. Assuming you use bash, do the following:

 [server]$ mkdir ~/.gems
 [server]$ cat >> ~/.bash_profile
 export GEM_HOME=$HOME/.gems
 export GEM_PATH=$GEM_HOME:/usr/lib/ruby/gems/1.8

Then press CTRL+D to exit cat and return to the command prompt. You may then install gems in the usual way (e.g. gem install gem_name). The .bash_profile method above resulted in the following error: Could not find RubyGem sources (> 0.0.0) when I tried installing a gem, but the instructions on altering your .gemrc file below worked perfectly. HOWEVER, without altering the .bash_profile rake kept complaining about not seeing my locally installed gems even when I passed it GEM_HOME and GEM_PATH manually. So, you may need both.

An alternative to setting the GEM_PATH environment is to create a ~/.gemrc file with the following contents:

 gemhome: /home/<YOUR USER NAME HERE>/.gems
 gempath:
 - /home/<YOUR USER NAME HERE>/.gems
 - /usr/lib/ruby/gems/1.8

Installing Warehouse in Production

Installation for production use is almost the same like for the development environment. Be aware, that domain has been configured with Passenger or Mongrell support (FastCGI is strongly NOT recommended).

If you’re running Warehouse on your server under some domain, first go inside the directory, where application will be installed. In most cases directory will have the name of the domain:

 [server]$ cd ~/subdomain.yourdomain.com/

Then, clone the project:

 [server]$ git clone git://github.com/drcapulet/warehouse.git
 [server]$ mv warehouse/* ~/subdomain.yourdomain.com/
 [server]$ rm -rf warehouse

Install dependencies:

 [server]$ gem install bundler && bundle install

Check out if you have the Pygments library installed. This library are necessary for source code highlighting.
In production you probably do not want to use sqlite, instead MySQL is preferable. To use MySQL type this inside the RAILS_ROOT directory:

 [server]$ rm config/database.yml
 [server]$ cp config/database.mysql_sample.yml config/database.yml

Then, make sure you have the database created and loaded in the schema. Again, from the RAILS_ROOT directory:

 [server]$ RAILS_ENV=production rake db:schema:load

Before starting the server make sure you properly configured your domain name in the RAILS_ROOT/config/warehouse.yml, otherwise application just will not start.
Find the section and configure it properly:

 production:
 host: http://subdomain.yourdomain.com/

Add in a new repository, and run:

 [server]$ RAILS_ENV=production rake warehouse:sync

Apparently, you’ll cause an exception with the repository sync error. Don’t worry, start the server and go to your domain in the browser window. Register new user, login and add new repository, where path to the repository will be something like this: /home/USERNAME/repositories/super_secret_project. After that, go back to the console prompt and type:

 [server]$ RAILS_ENV=production rake warehouse:sync[/home/USERNAME/repositories/super_secret_project]

Your initial repository should to be synchronized properly now. Login to warehouse and enjoy!

Conclusion

After all these steps you will have an ability to create your own private Git repositories with authorization controlled by Gitosis and modern Git Web View provided by Warehouse for Git to us. Maybe this short article will be helpful for somebody else, build by my own experience on it. Also, take a look at some screenshots below

Tags: featured, Git, rails, Ruby, server, warehouse