We are running a self-hosted GitLab CE 8.15.2, installed with Omnibus. Latest as of today.
It’s hosted on a private server which is normally not exposed to outer world, and while all of the team were working on site, we had no problems.
Now, though, I have moved out of the office and am working from home. We have exposed HTTP/SSH to outer world and the main features are working with no problems.
The problematic thing is LFS…
First off, with default configuration, it used SSH authentication and received a href in return from the server. Apparently, the href contained the private url (192.168.x.x), which made Git LFS to make a request there, though, it’s obviously not reachable.
Then, I set up the lfs.url configuration entry - to the public one.
Apparently, that didn’t help either:
$ GIT_TRACE=1 git push
23:47:54.158316 git.c:349 trace: built-in: git 'push'
23:47:54.160316 run-command.c:336 trace: run_command: 'ssh' 'git@159.148.39.249' 'git-receive-pack '\''rymec0de/remote-lfs-tests.git'\'''
23:47:55.154373 run-command.c:336 trace: run_command: '.git/hooks/pre-push' 'origin' 'git@159.148.39.249:rymec0de/remote-lfs-tests.git'
23:47:55.264379 git.c:563 trace: exec: 'git-lfs' 'pre-push' 'origin' 'git@159.148.39.249:rymec0de/remote-lfs-tests.git'
23:47:55.264379 run-command.c:336 trace: run_command: 'git-lfs' 'pre-push' 'origin' 'git@159.148.39.249:rymec0de/remote-lfs-tests.git'
trace git-lfs: run_command: 'git' version
trace git-lfs: run_command: git rev-list --objects f6c98fb3a0d411e9f4742df62fda270c6042a234 --not --remotes=origin --
trace git-lfs: run_command: git cat-file --batch-check
trace git-lfs: run_command: git cat-file --batch
trace git-lfs: run_command: 'git' config -l
trace git-lfs: tq: running as batched queue, batch size of 100
trace git-lfs: tq: sending batch of size 2
trace git-lfs: api: batch 2 files
trace git-lfs: Filled credentials for http://159.148.39.249:27014/rymec0de/remote-lfs-tests.git/info/lfs/
trace git-lfs: HTTP: POST http://159.148.39.249:27014/rymec0de/remote-lfs-tests.git/info/lfs/objects/batch
trace git-lfs: HTTP: 200
trace git-lfs: HTTP: {"objects":[{"oid":"69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2","size":218111,"actions":{"upload":{"href":"http://192.168.0.222/rymec0de/remote-lfs-tests.git/gitlab-lfs/objects/69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2/218111","header":{"Authorization":"Basic cnltZWMwZGU6d3Jha3V0NXVwUjNwIQ=="}}}},{"oid":"9b34c7e02a5afdce66df316018383c54839b16ec42d00aa9a817ca2c2660f70c","size":1600463,"actions":{"upload":{"href":"http://192.168.0.222/rymec0de/remote-lfs-tests.git/
trace git-lfs: HTTP: gitlab-lfs/objects/9b34c7e02a5afdce66df316018383c54839b16ec42d00aa9a817ca2c2660f70c/1600463","header":{"Authorization":"Basic cnltZWMwZGU6d3Jha3V0NXVwUjNwIQ=="}}}}]}
trace git-lfs: HTTP:
trace git-lfs: tq: starting transfer adapter "basic"
trace git-lfs: xfer: adapter "basic" Begin() with 3 workers
trace git-lfs: xfer: adapter "basic" started
trace git-lfs: xfer: adapter "basic" Add() for "69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2"
trace git-lfs: xfer: adapter "basic" Add() for "9b34c7e02a5afdce66df316018383c54839b16ec42d00aa9a817ca2c2660f70c"
trace git-lfs: xfer: adapter "basic" worker 1 starting
trace git-lfs: xfer: adapter "basic" worker 1 waiting for Auth
trace git-lfs: xfer: adapter "basic" worker 2 starting
trace git-lfs: xfer: adapter "basic" worker 2 waiting for Auth
trace git-lfs: xfer: adapter "basic" worker 0 starting
trace git-lfs: xfer: adapter "basic" worker 0 processing job for "69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2"
Git LFS: (0 of 2 files) 0 B / 1.73 MB
trace git-lfs: HTTP: PUT http://192.168.0.222/rymec0de/remote-lfs-tests.git/gitlab-lfs/objects/69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2/218111
It did connect to the designated URL, yes, asked for HTTP auth - filled in, passed. As can be seen in the trace, it followed the routine, though, apparently, it again got private url (192.168.x.x) in return and failed to PUT the record afterwards.
This happens for every file, it then goes to repeat this multiple times for each of the files and ultimately just dies with:
http: Put http://192.168.0.222/rymec0de/remote-lfs-tests.git/gitlab-lfs/objects/69c6785c52d4592048fda93d5ebd97a5813c32ae5f4bb682305de2190dd0c0c2/218111: dial tcp 192.168.0.222:80: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
http: Put http://192.168.0.222/rymec0de/remote-lfs-tests.git/gitlab-lfs/objects/9b34c7e02a5afdce66df316018383c54839b16ec42d00aa9a817ca2c2660f70c/1600463: dial tcp 192.168.0.222:80: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
error: failed to push some refs to 'git@159.148.39.249:rymec0de/remote-lfs-tests.git'
I’m not entirely sure if this is a bug, because we are not using GitLab as it should be used here. Anyways… any way around this?
Though, a second thought makes me feel like it is a bug. The system could simply respond with the requested host not based solely on config file.