클라이언트 오류 해결#

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

2.4.2 이전 버전의 Git LFS를 사용하는 경우 문제가 발생할 수 있습니다. 이 인증 이슈에 설명된 대로, 보조 사이트에서 기본 사이트로 리디렉션된 요청은 Authorization 헤더를 제대로 전송하지 않습니다. 이로 인해 Authorization <-> Redirect 무한 루프가 발생하거나 인증 오류 메시지가 표시될 수 있습니다.

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으로 표시되고 'Request failed with status code 401' 이 발생#

로드 밸런서를 사용하는 경우 로드 밸런서 뒤에 있는 노드의 /etc/gitlab/gitlab.rb에 로드 밸런서의 URL 이 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로 설정합니다.

• 기본 사이트에 고유합니다.
• 모든 보조 사이트에서 접근할 수 있습니다.

1. 기본 사이트에 접속합니다.
2. 내부 URL을 설정합니다.

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

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

이 문제를 해결하려면 다음을 수행합니다.

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

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

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

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

이 문제를 해결하려면 설치 유형에 맞게 action_cable_allowed_origins를 구성합니다.

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