GeoクライアントとHTTPレスポンスコードのエラーのトラブルシューティング

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

クライアントエラーの修正

LFS HTTP(S)クライアントリクエストからの認可エラー

2.4.2より前のGit LFSのバージョンを実行している場合、問題が発生することがあります。この認証イシューに記載されているように、セカンダリサイトからプライマリサイトにリダイレクトされたリクエストは、認可ヘッダーを適切に送信しません。これにより、無限のAuthorization <-> Redirectループ、または認可エラーメッセージが発生する可能性があります。

エラー: GeoセカンダリでSSH経由でプッシュするときの`Net::ReadTimeout`タイムアウト

GeoセカンダリサイトでSSH経由で大きなリポジトリをプッシュすると、タイムアウトが発生する場合があります。これは、このGeoイシューで説明されているように、Railsがプッシュをプライマリにプロキシし、60秒のデフォルトタイムアウトがあるためです。

現在の回避策は次のとおりです:

Gitalyプロキシがプライマリへのリクエストをプロキシする（またはGeoプロキシが有効になっていない場合はプライマリにリダイレクトする）代わりに、HTTP経由でプッシュします。
プライマリに直接プッシュします。

ログの例（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コンソールセッションを開始し、次の手順を実行します:

影響を受けるノードを見つけるには、まず、所有しているすべてのGeoノードを一覧表示します:
```
GeoNode.all
```
影響を受けるGeoノードを修復するには、IDを指定します:
```
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"

この問題を解決するには、以下を実行します:

セカンダリサイトのすべてのWebノードの/etc/gitlab.rbでnginx['proxy_custom_buffer_size'] = '8k'を設定します。
sudo gitlab-ctl reconfigureを使用して、セカンダリを再構成します。

それでもこのエラーが発生する場合は、前の手順を繰り返して8kサイズを変更することで、バッファサイズをさらに大きくすることができます（たとえば、16kに倍増するなど）。

Geo管理者エリアに`Unknown`がヘルスステータスとして表示され、「リクエストがステータスコード401で失敗しました」と表示される

ロードバランサーを使用している場合は、ロードバランサーの背後にあるノードの/etc/gitlab/gitlab.rbで、ロードバランサーのURLがexternal_urlとして設定されていることを確認してください。

プライマリサイトで、管理者 > Geo > 設定に移動し、許可されているGeo IPフィールドを見つけます。セカンダリサイトのIPアドレスがリストされていることを確認してください。

プライマリサイトが`/admin/geo/replication/projects`へのアクセス時に500エラーを返す

プライマリGeoサイトの管理者 > 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を設定します。

セカンダリサイトが`Received HTTP code 403 from proxy after CONNECT`を返す

Linuxパッケージ（Omnibus）を使用してGitLabをインストールし、Gitalyのno_proxyカスタム環境変数を構成した場合、このイシューが発生する可能性があります。影響を受けるバージョン:

15.4.6
15.5.0-15.5.6
15.6.0-15.6.3
15.7.0-15.7.1

これは、Linuxパッケージ15.4.6以降に同梱されている、含まれているバージョンのcURLに導入されたバグが原因です。これが修正された、以降のバージョンにアップグレードする必要があります。

このバグにより、すべてのワイルドカードドメイン（.example.com）は、no_proxy環境変数リストの最後のドメインを除いて無視されます。したがって、何らかの理由でバージョンをアップグレードできない場合は、ワイルドカードドメインをリストの最後に移動することで、このイシューを回避できます:

/etc/gitlab/gitlab.rbを編集します:

gitaly['env'] = {
  "no_proxy" => "sever.yourdomain.org, .yourdomain.com",
}

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

no_proxyリストに含めることができるワイルドカードドメインは1つだけです。

Geo管理者エリアがセカンダリサイトの404エラーを返す

sudo gitlab-rake gitlab:geo:checkがセカンダリサイトのRailsノードが正常であることを示している場合でも、セカンダリサイトの404 Not Foundエラーメッセージが、Geo管理者エリアでプライマリサイトのWebインターフェースに返されます。