toofishes.net

Git smart HTTP transport on nginx

Posted Dec. 8, 2010 at 7:31 p.m.

Nine months ago, I set up the git smart HTTP transport on lighttpd and wrote a blog post about it because I didn't see any documentation for non-Apache webservers. Turns out the same holds for nginx, which I switched to on my server due to some not so cool memory issues lighttpd has, especially on a memory-constrained VPS environment. More about that in another post.

I've figured out the magic needed to run git-http-backend behind nginx. It is trimmed down a bit from what I am actually running (e.g. no SSL, access_log stuff, etc.), but anything essential for the CGI service is still there.

Requirements

There is one additional requirement lighttpd did not have: you will need to install and have fcgiwrap installed and running. On Arch Linux, this just required a pacman -S fcgiwrap and then starting the service via the provided initscript.

The sample config assumes fcgiwrap is listening on localhost:9001 and your git repositories are rooted at /srv/git; adjust as necessary. The git repos will then be available at http://git.mydomain.com/git/myrepository.git.

Sample Configuration

http {
    ...
    server {
        listen       80;
        server_name  git.mydomain.com;

        location ~ /git(/.*) {
            # fcgiwrap is set up to listen on this host:port
            fastcgi_pass  localhost:9001;
            include       fastcgi_params;
            fastcgi_param SCRIPT_FILENAME     /usr/lib/git-core/git-http-backend;
            # export all repositories under GIT_PROJECT_ROOT
            fastcgi_param GIT_HTTP_EXPORT_ALL "";
            fastcgi_param GIT_PROJECT_ROOT    /srv/git;
            fastcgi_param PATH_INFO           $1;
        }
    }
}

Results and Testing

Obviously the above works for me or I would have nothing to write about. One thing that had me stumped for a little bit was the PATH_INFO bit- ensure the leading slash is present in the passed data, or you will get a 500 error with no error message to help you solve it. Originally I had the slash outside of the regex capture group, /git/(.*), instead of the correct /git(/.*).

The smart HTTP serving should be in place at a location like http://my.domain.com/git/myrepository.git. An easy way to check is to do a git clone on the HTTP URL of one of your repositories; if you see messages like remote: Counting objects: 722, done. then you have successfully set it up.

Comments (9)

Drew on Jan. 11, 2011 at 3:51 p.m.:

Can you explain a bit on your 500 error?

"ensure the leading slash is present in the passed data"

I don't see the leading slash in the code block above.

Dan McGee on Jan. 11, 2011 at 4:06 p.m.:

Ahh, I wasn't very clear about this. Look at the location regex: "/git(/.*)". I originally had something like "/git/(.*)" with the slash outside of the parenthesis and that did not work, since the $1 for PATH_INFO comes from the capture in that regex.

Drew on Jan. 11, 2011 at 4:20 p.m.:

@Dan:
Thanks for the fast response. I'm still getting HTTP 500 errors. Was wondering something real fast. Is it surely required that I use fcgiwrap? I'm using PHP which is utilizing the FPM module, which is basically a PHP FastCGI built directly into PHP, and it runs on port 9000. I've pointed the fastcgi_pass to this, but was wondering if it was required that I run both?

Regards,
Drew

Tekronis on Feb. 5, 2011 at 4:42 p.m.:

Dan, not sure why you're trying to use PHP FastCGI where the intent here is to connect the git-http-backend to nginx.

The following helped me though, and may help you:

-----
location ~ /git(/.*) {

fastcgi_split_path_info ^(.*/git)(/.*)$;

fastcgi_param DOCUMENT_ROOT /usr/lib/git-core/;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend;

fastcgi_param GIT_HTTP_EXPORT_ALL "";
fastcgi_param GIT_PROJECT_ROOT /srv/git/default/;

include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
}
-------

The key here being fascgi_split_path_info; it will split the URI based on the specified regex, and once that's done, you get the param needed to set PATH_INFO, which I've noticed doesn't get set otherwise. As far as I can tell, numerous applications, including those written in PHP need PATH_INFO to function correctly. fcgiwrap will do the job, but you may need to strace (and its spawned children) to get to the root of whatever issue you're having.

Tekronis on Feb. 5, 2011 at 5:03 p.m.:

Disregard what I mentioned about PHP FPM, I see what you are trying to achieve. All the same, give fcgiwrap another shot.

Also, my configuration uses the socket, instead of port 9000 as was specified in the original example. You'll want to make sure your nginx process has write access to it.

Dan McGee on Feb. 5, 2011 at 5:08 p.m.:

I don't think you are seeing what I was trying to achieve, given that I never mentioned PHP in the original post and I am using fcgiwrap...

Tekronis on Feb. 5, 2011 at 5:18 p.m.:

Dan, I was referring to Drew, who was trying to use the PHP FCM module as an alternative to fcgiwrap.

fcgiwrap was not working for him, and he was considering whether it could be replaced with an equivalent found within PHP to do the same thing.

Pascal on Feb. 10, 2011 at 1:32 p.m.:

NIce writeup, thanks!

One little oddity; I was trying to change the repositories urls to https://git.example.com/repo.git. But somehow it wouldn't work. I was able to clone a repo but I wasn't able to push to it. In the nginx error log I found this:

2011/02/10 08:24:06 [error] 22266#0: *20 no user/password was provided for basic authentication, client: 193.173.194.164, server: git.example.com, request: "GET /git/repo.git/info/refs?service=git-upload-pack HTTP/1.1", host: "git.example.com"

My nginx config was this:

auth_basic "Restricted";
auth_basic_user_file /etc/nginx/auth/git;

location ~ \.git {
fastcgi_pass 127.0.0.1:9001;
include /etc/nginx/fastcgi_params;

fastcgi_param SCRIPT_FILENAME /usr/local/libexec/git-core/git-http-backend;
fastcgi_param GIT_HTTP_EXPORT_ALL "";
fastcgi_param GIT_PROJECT_ROOT /var/git/;
fastcgi_param PATH_INFO $uri;

fastcgi_param REMOTE_USER $remote_user;
}

Passing the request_uri to PATH_INFO should in this case be exactly the same as passing $1 as you did. Any idea?

Fiodar Kupchyk (by) on Aug. 2, 2011 at 8:34 a.m.:

Pascal, I've into the same issue with this config and solved it by moving auth_basic instruction inside the location directive.
Hope it helps.

Cheers =)