I highly doubt I've invented something new, but I did independently invent it, so I have that going for me, which is nice. Plus I'm stitching together lots of great open source pieces which we all have going for us.
Anyhow, this is kind of difficult to explain. And complicated… with lots of moving parts… but is super useful once you get it to work.
As high level as possible, when I do a git push, another machine
reloads new configuration files. And notifies me. All within a second.
While trying to proxy my main nginx instance to a GitLab docker container I wasted hours and hours and hours trying to fix the following error:
fatal: unable to access 'https://gitlab.burgundywall.com/kneufeld/myproject.git/': \
SSL read: error:00000000:lib(0):func(0):reason(0), errno 54
It turns out that nginx config option ssl_session_cache is super f'n important to not screw up. I'm not totally sure what the problem is, but in my main server clause i had
ssl_session_cache shared:SSL:1m;
and I didn't have any such option in my server gitlab stanza. So something something something I could not do any git commands via https.
And even with logging everything looked okay
GIT_CURL_VERBOSE=1 git clone https://gitlab.burgundywall.com/kneufeld/myproject.git
Cloning into 'myproject'...
* Couldn't find host gitlab.burgundywall.com in the .netrc file; using defaults
* Trying 192.168.5.6...
* Connected to gitlab.burgundywall.com (192.168.5.6) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /usr/local/etc/openssl/cert.pem
CApath: none
* NPN, negotiated HTTP1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=gitlab.burgundywall.com
* start date: Sep 3 16:53:00 2016 GMT
* expire date: Dec 2 16:53:00 2016 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET /kneufeld/myproject.git/info/refs?service=git-upload-pack HTTP/1.1
Host: gitlab.burgundywall.com
User-Agent: git/2.9.3
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 54
* Closing connection 0
fatal: unable to access 'https://gitlab.burgundywall.com/kneufeld/myproject.git/': SSL read: error:00000000:lib(0):func(0):reason(0), errno 54
except it didn't work.
Anyhow, when I finally figured out that ssl_session_cache was the issue and did some reading I just made sure that each ssl server has it's own cache.
ssl_session_cache shared:SSL-gitlab:1m;
Hours.
Gitolite uses a slightly funky url scheme that can wreck havoc with other tools. In particular I wanted to use Google Repo (worst name ever by the way, htf do you search for git and repo to find this?)
Anyway, here's how…
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.
This pattern which I thought up (but is likely not unique) can very nicely manage your service configurations, automatically reload/restart your service, and even give non-root users (if desired) the ability to modify system config files.
All through the magic of git hooks. This example tracks config files for Apache (httpd).