FreeBSD CGit

Posted on Wed 06 August 2014 in english

I copied this setup for a FreeBSD based git server with nginx and cgit from various sites and thus I should call it my Frankenstein jail...

First we must create a new jail, copy the resolv.conf, followed by the installation of various packages, namely:

# pkg install nginx fcgiwrap git cgit gitolite

GIT

Let's create a new user and a dedicated directory for storing our repositories now:

# pw groupadd -n git -g 9418
# pw useradd -n git -u 9418 -g git -c "Git User Account" -d /git \
    -s /usr/local/libexec/git-core/git-shell -h - 
#
# mkdir -p /git/base
#
# chown -R git:git /git
# chmod -R 0755 /git

As we want to clone via SSH we must copy our id_rsa.pub (public SSH key) to our server into $HOME/.ssh/authorized_keys.
Make sure it has the right permissions:

# cd /git
# mkdir .ssh
# mv KEYFILE.pub /git/.ssh/authorized_keys
# chmod 600 /git/.ssh/authorized_keys
# chown -R git:git /git/.ssh/

Everything should be fine now, so let's create our first repository:

$ mkdir /git/base/test.git
$ cd /git/base/test.git && git init --bare --shared

The last step to a clonable repo is configuring the SSH daemon:

# echo 'sshd_enable="YES"' >> /etc/rc.conf
# service sshd start

On the client try:

$ git clone git@IP_OF_YOUR_SERVER:base/test.git 
Cloning into 'test'...
Warning: Permanently added 'IP_OF_YOUR_SERVER' (ECDSA) to the list of known hosts.
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

Now you're able to pull and push from/to your own git server. Congratulations!

CGit and Nginx

Enable Nginx and its dependency fcgiwrap (for CGit) in rc.conf config file:

$ echo 'fcgiwrap_enable="YES"' >> /etc/rc.conf
$ echo 'fcgiwrap_user="www"' >> /etc/rc.conf
$ echo 'nginx_enable="YES"' >> /etc/rc.conf

CGit wants its config file in /usr/local/etc/cgitrc:

css=/cgit.css
logo=/cgit.png

robots=noindex, nofollow

virtual-root=/

root-title=Lechindianer's CGIT
root-desc=...and now for something completely different

clone-url=http://git.lan/$CGIT_REPO_URL git@git.lan:$CGIT_REPO_URL

enable-index-links=1
enable-log-filecount=1
enable-log-linecount=1
enable-commit-graph=1
enable-remote-branches=1

snapshots=tar.gz tar.bz
max-stats=quarter
root-readme=/usr/local/www/cgit/about.htm

repo.group=various
repo.url=test
repo.path=/git/base/test.git
repo.desc=This is my test git repository
repo.owner=Pascal Schmid
repo.clone-url=http://git.lan/test/

For all various kinds of knobs of cgit see. I wanted to have a copy of the 3-clause BSD license on my website, so I put it into the root-readme. The enable- lines should be self-explanatory. If you have an old webgit server and want to adopt values set "enable-git-config=1" so every value starting with gitweb. will get mapped to the corresponding cgit.* one.

And for our webserver /usr/local/etc/nginx/nginx.conf use something like this:

user  www;
worker_processes  4;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    error_log /var/log/nginx.error.log error;
    sendfile        on;
    keepalive_timeout  70;

    server {
        listen       443;
        server_name  git2;

        ssl on; 
        ssl_certificate      /path/to/your/SSL/SERVER.pem;
        ssl_certificate_key  /path/to/your/SSL/SERVER.key;  
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        #ssl_ciphers  EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:EECDH+RC4:RSA+RC4:!MD5;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSKULL:!MD5:!DSS;
        ssl_session_timeout 5m;
        ssl_prefer_server_ciphers on;

        index cgit.cgi;
        access_log  /var/log/git.access.log;
        root /usr/local/www/cgit;
        try_files       $uri @cgit;

        # Require auth for requests sent to cgit that originated in location /
        location @cgit {
            # $document_root is now set properly, and you don't need to override it
            index cgit.cgi;
            fastcgi_param   SCRIPT_FILENAME $document_root/cgit.cgi;
            fastcgi_param   GIT_HTTP_EXPORT_ALL "";
            fastcgi_param   PATH_INFO       $uri;
            fastcgi_param   QUERY_STRING    $args;
            fastcgi_param   HTTP_HOST       $server_name;
            fastcgi_pass    unix:/var/run/fcgiwrap/fcgiwrap.sock;
            include fastcgi_params;

            gzip off;
            #rewrite ^ https://$server_name$request_uri permanent;
            rewrite ^/([^/]+/.*)?$ /cgit.cgi?url=$1 break;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

Create SSL keys:

# cd /usr/local/etc/
# mkdir ssl
# cd ssl
# openssl req -new -x509 -days 365 -nodes -out /path/to/your/SSL/SERVER.pem -keyout /path/to/your/SSL/SERVER.key -newkey rsa:2048

Start the services:

# service fcgiwrap start && service nginx start

The worker_processes value should represent your available CPU cores as mentioned in the Linode Nginx SSL tutorial.

Regarding the SSL cipher suites - choose a source you put more trust in:

For the keepalive_timeout value see the official Nginx documentation.

Gitolite

The problem with managing several git repositories with the authorized_keys file is that every allowed commiter can write in every repo on your server. It's controlled by that one entry.
You don't want this presumably so we have to find another mechanism to handle your commiters permissions. This is where Gitolite comes in handy. It's the successor of the meanwhile discontinued Gitosis.

The workflow is the following: Create a repo with your public ssh key and in this repo you will manage the permissions of all your other repos.

Gitolite uses a modified version of git's $HOME/.ssh/authorized_keys - when you open it you can see:

command="/usr/local/libexec/gitolite/gitolite-shell $USER",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa [very long public key] $USER@$HOST

The git-shell gets wrapped in this specialized auth_keys, so the first step to set up your Gitosis config is to delete the old auth_keys file. Then copy your public key in a directory where you can reach it with your git user. You must change your git user's shell from git-shell to something like /bin/sh for gitolite to work. Don't worry - the user is only allowed to do git-ish things allowed by the command above.

# rm -rf /git/base /git/.ssh
# chpass -s /bin/sh git
# su - git
$ gitolite setup -pk KEYFILE.pub

Now you can clone your gitolite-admin repo and make changes to its REPO/conf/gitolite.conf. See for more info on creating repos and giving permissions.

IMPORTANT: Gitolite has given my directories the wrong permissions so cgit was unable to show its content. To fix this issue change the UMASK value in gitolite's '.gitolite.rc' from 0077 to 0022 as suggested in the Arch Linux Wiki (works only for new repositories).

I had to fire off the following 2 command too:

# find /git/repositories/ -type d -exec chmod og+rx {} \;
# find /git/repositories/ -type f -exec chmod og+r {} \;

VoilĂ 

cgit overview

test repo