클라이언트 오류 수정#

LFS HTTP(S) 클라이언트 요청의 인증 오류#

2.4.2 이전 버전의 Git LFS를 실행하는 경우 문제가 발생할 수 있습니다. 이 인증 문제에서 언급된 것처럼, 보조 사이트에서 기본 사이트로 리디렉션된 요청이 Authorization 헤더를 올바르게 전송하지 않습니다. 이로 인해 무한 Authorization <-> Redirect 루프 또는 Authorization 오류 메시지가 발생할 수 있습니다.

Geo 보조 사이트에서 SSH를 통해 푸시할 때 Net::ReadTimeout 오류#

Geo 보조 사이트에서 SSH를 통해 대용량 리포지터리를 푸시할 때 타임아웃이 발생할 수 있습니다. 이는 Rails가 기본 사이트로 푸시를 프록시하며 이 Geo 문제에 설명된 것처럼 60초 기본 타임아웃이 있기 때문입니다.

현재 해결 방법은 다음과 같습니다:

• HTTP를 통해 푸시합니다. 이 경우 Workhorse가 기본 사이트로 요청을 프록시하거나 (Geo 프록시가 활성화되지 않은 경우) 기본 사이트로 리디렉션합니다.
• 기본 사이트로 직접 푸시합니다.

예시 로그 (gitlab-shell.log):

Failed to contact primary https://primary.domain.com/namespace/push_test.git\\nError: Net::ReadTimeout\",\"result\":null}" code=500 method=POST pid=5483 url="http://127.0.0.1:3000/api/v4/geo/proxy_git_push_ssh/push"

Geo 사이트 간 OAuth 인증 복구#

Geo 사이트를 업그레이드할 때 인증에 OAuth만 사용하는 보조 사이트에 로그인할 수 없을 수 있습니다. 그런 경우 기본 사이트에서 Rails 콘솔 세션을 시작하고 다음 단계를 수행합니다:

1. 영향을 받는 노드를 찾으려면 먼저 모든 Geo 노드를 나열합니다:

   GeoNode.all
   

2. ID를 지정하여 영향을 받는 Geo 노드를 복구합니다:

   GeoNode.find(<id>).repair
   

HTTP 응답 코드 오류#

Geo 프록시가 있는 보조 사이트에서 502 오류 반환#

보조 사이트를 위한 Geo 프록시가 활성화되어 있고 보조 사이트 사용자 인터페이스에서 502 오류가 반환되는 경우, 기본 사이트에서 프록시된 응답 헤더가 너무 클 수 있습니다.

다음 예시와 유사한 오류에 대해 NGINX 로그를 확인합니다:

2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 10.0.2.2, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"

이 문제를 해결하려면:

1. 보조 사이트의 모든 웹 노드의 /etc/gitlab.rb에 nginx['proxy_custom_buffer_size'] = '8k'를 설정합니다.
2. sudo gitlab-ctl reconfigure를 사용하여 보조 사이트를 재구성합니다.

여전히 이 오류가 발생하면, 이전 단계를 반복하고 예를 들어 8k를 16k로 두 배로 늘려 버퍼 크기를 더 크게 설정할 수 있습니다.

Geo 관리자 영역에 상태가 Unknown으로 표시되고 '상태 코드 401로 요청 실패'#

로드 밸런서를 사용하는 경우, 로드 밸런서 URL이 로드 밸런서 뒤에 있는 노드의 /etc/gitlab/gitlab.rb에서 external_url로 설정되었는지 확인합니다.

기본 사이트에서 Admin > Geo > Settings로 이동하여 Allowed Geo IP 필드를 찾습니다. 보조 사이트의 IP 주소가 나열되어 있는지 확인합니다.

기본 사이트에서 /admin/geo/replication/projects에 접근할 때 500 오류 반환#

기본 Geo 사이트에서 Admin > Geo > Replication (또는 /admin/geo/replication/projects)으로 이동하면 500 오류가 표시되지만, 보조 사이트의 동일한 링크에서는 정상적으로 작동합니다. 기본 사이트의 production.log에는 다음과 유사한 항목이 있습니다:

Geo::TrackingBase::SecondaryNotConfigured: Geo secondary database is not configured
  from ee/app/models/geo/tracking_base.rb:26:in `connection'
  [..]
  from ee/app/views/admin/geo/projects/_all.html.haml:1

Geo 기본 사이트에서 이 오류는 무시할 수 있습니다.

이는 GitLab이 기본 사이트에 존재하지 않는 Geo 추적 데이터베이스에서 레지스트리를 표시하려고 시도하기 때문입니다 (기본 사이트에는 원래 프로젝트만 존재하며, 복제된 프로젝트가 없으므로 추적 데이터베이스가 존재하지 않습니다).

보조 사이트에서 400 오류 Request header or cookie too large 반환#

이 오류는 기본 사이트의 내부 URL이 잘못된 경우 발생할 수 있습니다.

예를 들어 통합 URL을 사용하고 기본 사이트의 내부 URL이 외부 URL과 동일한 경우에 발생합니다. 이로 인해 보조 사이트가 기본 사이트의 내부 URL로 요청을 프록시할 때 루프가 발생합니다.

이 문제를 해결하려면 기본 사이트의 내부 URL을 다음과 같은 URL로 설정합니다:

• 기본 사이트에 고유한 URL.
• 모든 보조 사이트에서 접근 가능한 URL.

1. 기본 사이트를 방문합니다.
2. 내부 URL을 설정합니다.

Geo 관리자 영역에서 보조 사이트에 대해 404 오류 반환#

때로는 sudo gitlab-rake gitlab:geo:check가 보조 사이트의 Rails 노드가 정상적이라고 표시하지만, 기본 사이트의 웹 인터페이스에 있는 Geo 관리자 영역에서 보조 사이트에 대해 404 Not Found 오류 메시지가 반환됩니다.

이 문제를 해결하려면:

• sudo gitlab-ctl restart를 사용하여 보조 사이트의 각 Rails, Sidekiq 및 Gitaly 노드를 재시작합니다.
• Sidekiq 노드의 /var/log/gitlab/gitlab-rails/geo.log를 확인하여 보조 사이트가 IPv6을 사용하여 기본 사이트로 상태를 전송하는지 확인합니다. 그런 경우 /etc/hosts 파일에서 IPv4를 사용하여 기본 사이트에 항목을 추가합니다. 또는 기본 사이트에서 IPv6을 활성화해야 합니다.

Geo 보조 사이트에서 WebSocket 요청 실패#

WebSocket에 의존하는 기능(예: GitLab Duo Chat, 실시간 이슈 업데이트 또는 기타 실시간 기능)을 사용할 때 Geo 보조 사이트에서 404 오류로 연결이 실패할 수 있습니다.

이는 WebSocket 요청이 보조 사이트에서 기본 사이트로 프록시되기 때문입니다. 기본 사이트에서 ActionCable은 모든 Geo 사이트에서의 WebSocket 요청을 허용하도록 구성해야 합니다. 기본적으로 ActionCable은 로컬 사이트의 요청만 허용합니다.

이 문제를 해결하려면 설치 유형에 따라 action_cable_allowed_origins를 구성합니다:

• Linux 패키지용 Geo 문서
• Helm 차트용 Geo 문서