gitlab-git-http-server not working when GitLab uses sockets only

When GitLab (or unicorn) is only listening on an UNIX socket, gitlab-git-http-server fails to send authentication requests to GitLab as it uses http://localhost:8080/ as authBackend. As a result, GitLab runners will not be able to clone the project and run tests etc. Also, cloning repositories over HTTPS is not possible.

I am not sure, if this is a bug or not. For me, it costed two hours of figuring out where in the installation/upgrade docs something with port 8080 is described. So maybe you should add this to the docs or whereever :-)

My fix was to uncomment config/unicorn.rb.example#L39

Have same issue on my server; but the hotfix from marcel din't fix the issue for me ):

@MakerTim Have you taken a look at the log file? It is located at /home/git/gitlab/log/gitlab-git-http-server.log ;-) Also, did you restart gitlab after uncommenting line 39?

I'm having the same problem @MakerTim has. Line 39 was already uncommented in unicorn.rb and will uncomment itself even after comment it out myself. The log file only prints out this:

2015-09-22_15:23:35.00678 2015/09/22 17:23:35 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_15:24:20.67152 2015/09/22 17:24:20 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_17:42:20.73581 2015/09/22 19:42:20 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_21:21:15.18486 2015/09/22 23:21:15 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_21:59:34.15629 2015/09/22 23:59:34 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_22:01:03.90930 2015/09/23 00:01:03 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_22:01:49.34266 2015/09/23 00:01:49 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_22:02:17.93141 2015/09/23 00:02:17 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_22:09:17.57478 2015/09/23 00:09:17 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-22_22:10:22.58942 2015/09/23 00:10:22 repoRoot: /var/opt/gitlab/git-data/repositories
2015-09-23_06:55:06.53590 2015/09/23 08:55:06 repoRoot: /var/opt/gitlab/git-data/repositories

Cloning using Http gives no error, but it does return an empty repository (SSH still works)

Same for me. Cloning any project end up with "empty repository" info. If I already had project with https://git... repo it ends with: error: Cannot access URL https://git.../repo.git/, return code 22 fatal: git-http-push failed error: failed to push some refs to 'https://git.../repo.git' I was using GitLab 7.11 (worked fine) and I updated to newest 8.0.1 (not working git over https anymore).

I'm using Omnibus installer.

I've found reason and problem for me. Im using my custom nginx installation. When they started using gitlab-git-http-server they added new section to nginx configuration file for upstream gitlab-git-http-server. Take a look at https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb

I have this problem too, i found a solution in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md#troubleshooting.

I'm running GitLab through Nginx + UWSGI (unix socket), so there is no Unicorn. I had to create additional vhost in Nginx on another port to use it as an authBackend, it only proxy_passes requests to UWSGI. Original vhost proxy_passes git requests to gitlab-git-http-server.

@Mikanoshi can you provide a complete example please?

mentioned in issue #3089 (closed)

If using omnibus gitlab installer, and having an external nginx+passenger, I had to add this lines to make auth work on uwsgi (sockets) only

LOCAL HTTP AUTH

server {
  listen 127.0.0.1:8080;
  server_tokens off; ## Don't show the nginx version number, a security best practice
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  client_max_body_size 250m;

  access_log  /var/log/gitlab/nginx/gitlab_w_access.log;
  error_log   /var/log/gitlab/nginx/gitlab_w_error.log;

  # Ensure Passenger uses the bundled Ruby version
  passenger_ruby /opt/gitlab/embedded/bin/ruby;

  # Correct the $PATH variable to included packaged executables
  passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

  # Make sure Passenger runs as the correct user and group to
  # prevent permission issues
  passenger_user git;
  passenger_group git;

  # Enable Passenger & keep at least one instance running at all times
  passenger_enabled on;
  passenger_min_instances 1;

  error_page 502 /502.html;
}

e.g. all requests to port 8080 go straight to passenger instance, while those who come to port 80 / 443 are filtered as usual.

I'm attaching full nginx vhost config file, it was merged from omnibus install manual ( https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#using-an-existing-passengernginx-installation ) and ssl part from ce gitlab-ssl nginx configuration example

This fix can have some side effects, as it represents to instances of gitlab running, and i'm not sure if this is correct. I think we can actually redirect all requests from HTTPS host, other than sent to gitlab-git-http-server to this "local" instance, removing this issue.

I have had a similar problem. - I just solved it. This instance for me was an upgrade from Gitlab 7 to 8. In Gitlab 8, gitlab-git-http-server has been depreciated. So, in my custom nginx config file, I replaced the socket connection to goto /var/opt/gitlab/gitlab-workhorse/socket instead of the gitlab-git-http-server location. Rebooted nginx, and then I was able to push and pull without error ;)

gitlab-workhorse still requires some tricky configuration if you don't use Unicorn.

Wrote a guide how to setup GitLab on FreeBSD with Nginx + uWSGI + gitlab-workhorse:

http://en.mikanoshi.name/gitlab-uwsgi-nginx-on-freebsd/

Moved to gitlab-workhorse#48

mentioned in merge request !14785