Menu

Skip to content
CryptkCoding

CryptkCoding

Ramblings of a Linux administrator

Setting up a git server with xinetd, gitolite and cgit (the right way)

Posted on September 4, 2011 by cryptk

So I need to set up a git server for one of the projects that I work with, so I figured I would document how to do it properly. Even though I am a huge fan of the web server nginx, this server in particular is already set up with apache2 so I will be serving cgit through apache2. Perhaps later I will add in an nginx config for cgit.

I am using a resh install of Ubuntu 10.04 LTS with all updates applies for my testbed while I write this, but the instructions should apply equally well to all versions of Ubuntu up to at least 11.10 (when it releases) and likely versions afterwards as well.

As usual, this is going to be a long one, so catch the rest after the linkeration..

Lets get started by installing some dependencies

sudo aptitude install git-core xinetd

This is going to pull in a few dependencies as well.  Next we need to configure xinetd to be able to run the git-daemon when someone connects to the server.  We will do this by placing the following in a file at /etc/xinetd.d/git-daemon

# default: off
# description: The git server offers access to git repositories
service git
{
    disable = no
    type            = UNLISTED
    port            = 9418
    socket_type     = stream
    wait            = no
    user            = nobody
    server          = /usr/bin/git daemon
    server_args     = --inetd --export-all --base-path=/pub/scm
    log_on_failure  += USERID
}

And then we will restart xinetd to get that new configuration file pulled in.  Normally we would want to tweak the –base-path setting to point to your repository locations, but we are going to be using gitolite to manage our git repositories, so it isn’t necessary…  Lets get gitolite set up now.

Before we start covering the gitolite install, I would like to take a moment to mention that for this part my instructions could become incorrect at some point in the future if the installation procedure for gitolite changes.  If at any point my directions differ from the official gitolite installation documentation, you should defer to the gitolite documentation unless I give a reason not to.  The official gitolite installation documentation can be found at this link.

The first thing we are going to need to do is generate an SSH public/private key pair.  If you already have one great! if you don’t here is how you make one.  On your local linux system, while logged in as yourself, run the following command.

ssh-keygen

It will prompt you for a location to save the key file in.  I recommend going with the default unless you have multiple keys, then specify an alternate location/filename.  It will also prompt you if you want to encrypt the private key with a password… This is a personal choice and you can press enter without supplying a password if you don’t want one… but I recommend setting one.

Wherever you told it to save your key, you will have two files id_rsa (this is your private key, never share it, never give it to anyone, only place it on systems that you have full control over) and id_rsa.pub (this is your public key, this is the other half of the key pair that you give out).  You will want to copy the file id_rsa.pub from your local machine to /tmp/YourUsername.pub on the server that you are setting up gitolite on.  Make sure that you name it with the username that you use on your LOCAL system, not the one that you use on the server.  This will be used during the gitolite setup to allow you access to the administration repository.

We are going to be installing gitolite using the root method… so first use sudo to become root (the proper way to do this is the command `sudo -i`).  Then change to a folder where you will want the source code at… I typically put things like this either in roots home folder or in a subfolder within roots home.

sudo -i
cd ~
git clone git://github.com/sitaramc/gitolite
cd gitolite
src/gl-system-install

Next we need to create a user for git to run with. We are going to use the username git because that is what most people use. You also need to decide where you want your repositories to be saved. This will be the home folder of the git user. I typically use /srv/repositories for this. It is also common for people to have the git user have a home folder in the normal home folder location of /home/git but if you want to know why I place mine in /srv/repositories check out the Linux Filesystem Hierarchy Standard.

adduser --home /srv/repositories --disabled-password git

We specified –disabled-password because with gitolite we will be using SSH keys to manage git access.  Next we need to swap to the git user that we just created and run the second half of the gitolite installation.

su - git
gl-setup /tmp/YourUsername.pub

It will prompt you to check the gitolite config file. We are going to make one adjustment so that cgit will work later.  Find the line:

$REPO_UMASK = 0077;

And change it to

$REPO_UMASK = 0022;

This will make it so that the owner (the git user) will have full control, which will allow git to work.  But it will also allow other users to have read-only access so that cgit will work.  Now back on your local system you should be able to run the following command to clone the administration repository.

git clone git@123.456.789.0:gitolite-admin

For creating repositories and access management I am going to defer to the gitolite documentation at this link.

Now we are going to set up cgit to give a nice way to view your repositories through a website!

The same disclaimer applies here as we applied to gitolite… if at any point my instructions differ from the cgit official docs at this link… follow the official docs unless I specify otherwise.

First swap back to the root account on your server and grab the cgit source code.

git clone git://hjemli.net/pub/git/cgit
cd cgit

Then we need to initialize the git submodule.  cgit is written in C and it uses many of the native git libraries to interact with your repositories, hence it needs the git source code to work.

git submodule init
git submodule update

At this point, we are going to remove the version of git that we installed earlier and we are going to update our server to the latest version of git.

aptitude purge git-core

Now before we can build the git source, lets install some dependencies so that we can have a fully functional git.  When I say fully functional, I mean fully functional with the exception of git-gui… as this is a server, we won’t be using a gui.  We will be installing the packages required to build and install the documentation though.

aptitude install build-essential libcurl4-openssl-dev autoconf libexpat-dev asciidoc

And now we are ready to build and install git

cd git
make configure
./configure --prefix=/usr --without-tcltk
make all doc
make install install-doc install-html

The `make all doc` will take a while… git has a lot of source code to compile… After you run the make install line, you should have git installed and if you run `git version` and get something like the following

git version 1.7.4

But perhaps you may have a newer version 😉

We are going to make one tiny change to the cgit source code.  because we are using git and gitolite we are going to adjust how cgit renders the clone URL’s so that they will be correct for our gitolite install (cgit is set up for gitosis clone URL’s, not gitolite ones).  Edit the file ui-summary.c and find the print_url function (currently it is the first function in the file) and find the following lines within it:

        if (suffix && *suffix)
                base = fmt("%s/%s", base, suffix);
        html("

And change them to

        if (suffix && *suffix)
                base = fmt("%s%s", base, suffix);
        html("

All we are doing here is changing the “%s/%s” to “%s%s” (no more /).

Now we can make and install cgit

make
make install

Now to serve cgit through apache (make sure the apache2 package is installed) we are going to use the following vhost configuration. This config assumes that you installed cgit to the standard locations, if you didn’t adjust the DocumentRoot, Directory, Alias and ScriptAlias directives accordingly. Make sure to use whatever URL you want to serve the cgit page through on the ServerName line and make sure you have a DNS entry pointing that URL to your server. This config also uses Apache’s mod-rewrite to give you nice pretty URL’s, if you don’t have mod-rewrite enabled use the command `a2enmod rewrite` to enable it.

Place this file in /etc/apache2/sites-available/cgit and then enable it with `a2ensite cgit`

<VirtualHost *:80>
    ServerAdmin admin@yourdomain.com
    ServerName git.yourdomain.com

    DocumentRoot /var/www/htdocs/cgit/

    <Directory /var/www/htdocs/cgit/>
        AllowOverride None
        Options +ExecCGI
        Order allow,deny
        Allow from all
    </Directory>

    Alias /cgit.png /var/www/htdocs/cgit/cgit.png
    Alias /cgit.css /var/www/htdocs/cgit/cgit.css
    ScriptAlias / "/var/www/htdocs/cgit/cgit.cgi/"
    RewriteRule ^$ / [R]
    RewriteRule ^/(.*)$ /cgit.cgi/$1 [PT]

    ErrorLog /var/log/apache2/cgit-error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/cgit-access.log combined
</VirtualHost>

Now if you go to the URL that you set up in DNS and on the ServerName line, you should see cgit, but it is reporting that there are no repositories found!  Lets adjust the cgit configuration to tell it where our repos are stored.  Edit the file /etc/cgitrc (which probably doesn’t exist yet) and give it the following contents:

remove-suffix=1
cache-size=0
clone-prefix=http://git.yourdomain.com/ git@git.yourdomain.com:
source-filter=/usr/lib/cgit/filters/syntax-highlighting.sh
readme=README
root-title=My CGIT
root-desc=My personal git repo
project-list=/srv/repositories/projects.list
scan-path=/srv/repositories/repositories
enable-index-links=1

This sets a few things up such as the repository location and syntax highlighting.  In order to make syntax highlighting work you also need the highlight package installed

aptitude install highlight

Now if you go to that URL again you should see your repositories assuming that you have made some and they have the proper owner = description lines for them in your gitolite.conf file in the gitolite-admin repository.

That’s it… you now have git running with xinetd, gitolite for access control and cgit for displaying your repositories on a web page!

Posted in Linux Nas-Admin | Tagged cgit git gitolite ubuntu xinetd | 4 Comments

4 thoughts on “<span>Setting up a git server with xinetd, gitolite and cgit (the right way)</span>”

  1. 12/2/11
    9:51 pm
    December 2, 2011
    9:51 pm

    ataraxic says:

    Thanks! It really helps me. I've looked for many posts on the web but this is the best one.

    There are only slight typos you've got here:

    1. Section

    AllowOverride None

    Options +ExecCGI

    Order allow,deny

    Allow from all

    should be enclosed in

    2. was not closed.

    Otherwise service apache2 reload command fails

    Thanks once more

    • 12/2/11
      9:56 pm
      December 2, 2011
      9:56 pm

      ataraxic says:

      oops… seems that words between the '' can not be displayed correctly

      so it should be

      and

      • 12/2/11
        10:01 pm
        December 2, 2011
        10:01 pm

        cryptk says:

        Turns out it was WordPress was interpreting them as HTML tags and since they weren't on the whitelist, it stripped them out. All fixed now, thanks for pointing it out! Glad it worked out for you, let me know if you want to see an article on anything else, I do this stuff for a living, so I enjoy helping others out 😉

  2. 7/16/13
    4:35 am
    July 16, 2013
    4:35 am

    windows vista help says:

    Hi, thanks for the information you have shared. I am doing cgit project and as a part of that particular project I had to set up a git server with xinted and to work with the settings related to it. I was totally confused, but your article helped me a lot to fix this issue.

Comments are closed.

Pages

  • Who Am I?

Blogroll

  • Failverse
  • major.io
  • SyntheticWorks

Archives

  • January 2015
  • February 2013
  • September 2012
  • August 2012
  • April 2012
  • March 2012
  • September 2011
  • August 2011
  • April 2011
Proudly powered by WordPress
Theme: Flint by Star Verte LLC