We have a Gitlab omnibus install on an arbitrary port being served by a Haproxy on 80/443 splitting traffic by subdomain. LFS was then enabled in Gitlab and stores on a network mount. Credentials are supplied by LDAP, including SSH key support. Our SSL certs are supplied by Letsencrypt.
Haproxy was initially configured to redirect http scheme to https.
Attempting to push lfs files would work for about 35 seconds (regardless of source or ping) and then fail, reporting File Already Closed for all remaining transfers. This was while using SSH with keys. I'm mildly aware that lfs uses an http(s) connection in the background when using SSH for git.
After fiddling with timeouts and cache sizes for a while, in both Haproxy and Gitlab's nginx implementation, I instead found that eliminating the http->https redirect in Haproxy solved our issue, and lfs was happy to move half a gig at once.
I'm mostly concerned that some credential handling isn't sticking to using https, or doesn't support it in the first place.
We have a Gitlab omnibus install on an arbitrary port being served by a Haproxy on 80/443 splitting traffic by subdomain. LFS was then enabled in Gitlab and stores on a network mount. Credentials are supplied by LDAP, including SSH key support. Our SSL certs are supplied by Letsencrypt.
Haproxy was initially configured to redirect http scheme to https.
Attempting to push lfs files would work for about 35 seconds (regardless of source or ping) and then fail, reporting File Already Closed for all remaining transfers. This was while using SSH with keys. I'm mildly aware that lfs uses an http(s) connection in the background when using SSH for git.
After fiddling with timeouts and cache sizes for a while, in both Haproxy and Gitlab's nginx implementation, I instead found that eliminating the http->https redirect in Haproxy solved our issue, and lfs was happy to move half a gig at once.
I'm mostly concerned that some credential handling isn't sticking to using https, or doesn't support it in the first place.