nginx + uwsgi + supervisord + git
@ wrote... (9 years, 9 months ago)

This is a quick and dirty config guide to setup git-http-backend with uwsgi from supervisord on nginx. I did this on Fedora 20 so on a different distro some paths will likely be different.

I've also ignored security in this post as I have ssl termination handled elsewhere. This will send your password in the clear if you don't have ssl setup correctly! Don't forget to setup git permissions as well. This config allows any authorized user (somebody who can login) to push.

Toofishes.net was very helpful.

This will setup your git repos under http://example.com/git/. The git repos physically live at /srv/git.

Your nginx.conf should look something like this, either including git.conf or having the contents of git.conf directly in the server section.

# /etc/nginx/nginx.conf
...
server {
  server_name example.com;
  ...
  include apps/*.conf;
  ...
}

# /etc/nginx/apps/git.conf
location ~ /git(/.*) {
    alias /srv/git;
    try_files $uri @git;
}

location @git {
    auth_basic "git";
    auth_basic_user_file /srv/git/gitusers;

    include uwsgi_params;

    # export all repositories under GIT_PROJECT_ROOT
    uwsgi_param GIT_HTTP_EXPORT_ALL "";
    uwsgi_param GIT_PROJECT_ROOT    /srv/git;
    uwsgi_param PATH_INFO           $1;
    # required for pusing to repo
    uwsgi_param REMOTE_USER         $remote_user;

    uwsgi_modifier1 9;
    uwsgi_pass 127.0.0.1:8021;
}

Use supervisord to start the uwsgi process.

# /etc/supervisord.d/git.conf
[program:git]
command=/sbin/uwsgi --ini /srv/git/git.ini
directory=/srv/git
autostart=true
autorestart=true
stopwaitsecs=2
user=apache

And finally, use uwsgi to start git-http-backend.

# /srv/git/git.ini
[uwsgi]
socket         = 127.0.0.1:8021
plugin         = cgi
cgi            = /usr/libexec/git-core/git-http-backend

chdir = %d

post-buffering               = 8192

# start up to 4 but try to stay at 1
processes                    = 4
cheaper                      = 1

# lots more customizations possible

Create /srv/git/gitusers with htpasswd -c /srv/git/gitusers <username>

Hope that helps.

Category: tech, Tags: git, linux, nginx
Comments: 13
Comments
1.
username @ February 28, 2015 wrote... (8 years, 9 months ago)

Hi.ould you please take a look at Q here:

http://unix.stackexchange.com/questions/187354/git-http-backend-uwsgi-unavailable-modifier-requested

2.
Kurt @ February 28, 2015 wrote... (8 years, 9 months ago)

You've deleted the page, but I suspect you need to change fastcgi_* to uwsgi_*. I also doubt you need any *_param.

3.
Simon @ March 8, 2015 wrote... (8 years, 9 months ago)

This looks like a really handy guide but it's not quite working for me.

I get:-

unavailable modifier requested: 9

in the uwsgi log when I try and clone the repo. I think this is because I need to install the CGI plugin for uwsgi but I don't really know how to go about that. Any ideas?

4.
Kurt @ March 8, 2015 wrote... (8 years, 9 months ago)

On fedora, /usr/lib64/uwsgi/cgi_plugin.so is owned by package uwsgi-plugin-common your distro will probably have a similar name.

You may want to try and comment out the cgi line in uwsgi ini file and see what happens.

5.
Simon @ March 9, 2015 wrote... (8 years, 9 months ago)

I'm using centos but can't find any information about how to install cgi_plugin.so.

Commenting out the cgi line gives me the same error as before, which is odd.

6.
Eli @ February 10, 2016 wrote... (7 years, 10 months ago)

Can you confirm that pull/fetch/clone work with your setup?

I've had mine configured similarly for a while and didn't realize that I couldn't clone my repos anew (or fetch objects into a new empty repo). On my server, uwsgi will run git-upload-pack, and it just hangs without doing anything (0% cpu, unchanging mem-usage, no disk i/o) until any of curl/nginx/uwsgi decides time is up. Increasing these timeouts to unreasonable values also doesn't seem to improve the outcome.

7.
Kurt @ February 10, 2016 wrote... (7 years, 10 months ago)

I just did and it works.

I do now use basic auth via:

location ~ /git(/.*) {
    auth_basic "git";
    auth_basic_user_file /srv/git/gitusers;

    root /srv;
    try_files $uri @git;
}

Try turning on debug logs in nginx (warning: you get a lot of output) and see if you can find something useful.

# in server section
error_log   /var/log/nginx/www.debug.log debug;

also, I increased buffer sizes:

http {
...
client_max_body_size 50M;
client_body_buffer_size 1M;
}

Having said all that I've switched to using gitolite which is ssh based. When I get some free time I'm going to install GitLab, I use it at work and it's pretty awesome.

8.
gtmanfred @ April 25, 2017 wrote... (6 years, 7 months ago)

For whoever runs across this later, you can add 

cgi-close-stdin-on-eof = 1

To your uwsgi setup if you are on a newer version of git that is hanging on git upload-pack . and it will work

9.
gtmanfred @ April 25, 2017 wrote... (6 years, 7 months ago)

This is the mailing list post where I found the solution.

10.
gtmanfred @ April 25, 2017 wrote... (6 years, 7 months ago)

http://lists.unbit.it/pipermail/uwsgi/2016-May/008450.html

This mailing list.

apparently I cannot paste

11.
gtmanfred @ April 25, 2017 wrote... (6 years, 7 months ago)

Ok, last comment, this requires uwsgi >= 2.0.13 for that option to be added.

12.
Erik @ April 25, 2017 wrote... (6 years, 7 months ago)

Also, gtmanfred did a bisect earlier and found that this was introduced in https://github.com/git/git/commit/6bc0cb5176a5e42ca4a74e3558e8f0790ed09bb1 and affects git >= 2.4.4. We were troubleshooting this earlier and noticed that it worked on CentOS 7 (git 1.8.3.1) but hung on Ubuntu 16.04 (git 2.7.4).

So, in summary, this affects git >= 2.4.4 and can be mitigated (with that option gtmanfred posted earlier) so long as you are running uwsgi >= 2.0.13.

13.
Kurt @ April 26, 2017 wrote... (6 years, 7 months ago)

Thanks a lot for updating this older post with new information!

Click here to add a comment