正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Linuxパッケージのインストールに関するトラブルシューティング

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

このページでは、ユーザーがLinuxパッケージのインストール時に遭遇する可能性のある一般的な問題について説明します。

パッケージダウンロード時のハッシュサムの不一致

apt-get installは次のような出力をします:

E: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/pool/trusty/main/g/gitlab-ce/gitlab-ce_8.1.0-ce.0_amd64.deb  Hash Sum mismatch

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

sudo rm -rf /var/lib/apt/lists/partial/*
sudo apt-get update
sudo apt-get clean

詳細については、Joe Damato’s from Packagecloud commentと彼のブログ記事を参照してください。

別の回避策として、CEパッケージまたはEEパッケージリポジトリから正しいパッケージを手動でダウンロードする方法があります:

curl -LJO "https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/trusty/gitlab-ce_8.1.0-ce.0_amd64.deb/download"
dpkg -i gitlab-ce_8.1.0-ce.0_amd64.deb

openSUSEおよびSLESプラットフォームでのインストール時に不明なキー署名について警告が表示される

Linuxパッケージは、署名されたメタデータを提供するパッケージリポジトリに加えて、GPGキーで署名されています。これにより、ユーザーに配布されるパッケージの信頼性と整合性が確保されます。ただし、openSUSEおよびSLESオペレーティングシステムで使用されているパッケージマネージャーは、次のような署名で誤った警告を表示する場合があります:

File 'repomd.xml' from repository 'gitlab_gitlab-ce' is signed with an unknown key '14219A96E15E78F4'. Continue? [yes/no] (no):
File 'repomd.xml' from repository 'gitlab_gitlab-ce' is signed with an unknown key '14219A96E15E78F4'. Continue? [yes/no] (no): yes

これは、zypperがリポジトリ設定ファイルのgpgkeyキーワードを無視するzypperの既知のバグです。Packagecloudの新しいバージョンではこれに関する改善があるかもしれませんが、現在、ユーザーは手動でパッケージのインストールに同意する必要があります。

そのため、openSUSEまたはSLESシステムでは、そのような警告が表示された場合でも、インストールを続行しても安全です。

apt/yumがGPG署名についてクエリを出す

GitLabリポジトリがすでに構成されており、apt-get update、apt-get install、またはyum installを実行したときに、次のエラーが表示されました:

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F

または

https://packages.gitlab.com/gitlab/gitlab-ee/el/7/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for gitlab-ee

これは、2020年4月に、GitLabがPackagecloudインスタンスを介して利用可能なaptおよびyumリポジトリのメタデータに署名するために使用されるGPGキーを変更したためです。このエラーが表示される場合、一般に、キーリング内のリポジトリメタデータに署名するために現在使用されている公開キーがないことを意味します。このエラーを修正するには、新しいキーをフェッチする手順に従ってください。

再設定でエラーが表示される: NoMethodError - undefined method '[]=' for nil:NilClass

sudo gitlab-ctl reconfigureを実行したか、パッケージのアップグレードがトリガーとなり、次のようなエラーが発生しました:

 ================================================================================
 Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
 ================================================================================

NoMethodError
-------------
undefined method '[]=' for nil:NilClass

Cookbook Trace:
---------------
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/config.rb:21:in 'from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:26:in 'from_file'

Relevant File Content:

このエラーは、/etc/gitlab/gitlab.rb設定ファイルに、無効またはサポートされていない設定が含まれている場合にスローされます。タイプミスがないか、または設定ファイルに廃止された設定が含まれていないことを再確認してください。

sudo gitlab-ctl diff-configを使用するか、最新のgitlab.rb.templateをチェックして、利用可能な最新の設定を確認できます。

ブラウザでGitLabにアクセスできない

/etc/gitlab/gitlab.rbでexternal_urlを指定してみてください。ファイアウォールの設定も確認してください。GitLabサーバーでポート80（HTTP）または443（HTTPS）が閉じられている可能性があります。

GitLabまたはその他のバンドルされたサービス（レジストリとMattermost）のexternal_urlを指定しても、gitlab.rbの他の部分が従うkey=value形式にはなりません。次の形式で設定されていることを確認してください:

external_url "https://gitlab.example.com"
registry_external_url "https://registry.example.com"
mattermost_external_url "https://mattermost.example.com"

external_urlと値の間に等号（=）を追加しないでください。

メールが配信されない

メールの配信をテストするには、GitLabインスタンスでまだ使用されていないメールの新しいGitLabアカウントを作成します。

必要に応じて、GitLabから送信されたメールの「From」フィールドを/etc/gitlab/gitlab.rbの次の設定で変更できます:

gitlab_rails['gitlab_email_from'] = 'gitlab@example.com'

変更を有効にするには、sudo gitlab-ctl reconfigureを実行します。

GitLabサービスのTCPポートがすでに使用されている

デフォルトでは、PumaはTCPアドレス127.0.0.1:8080でリッスンします。NGINXは、すべてのインターフェースで、ポート80（HTTP）または443（HTTPS）でリッスンします。

Redis、PostgreSQL、およびPumaのポートは、次のように/etc/gitlab/gitlab.rbでオーバーライドできます:

redis['port'] = 1234
postgresql['port'] = 2345
puma['port'] = 3456

NGINXのポートの変更については、NGINXリッスンポートの設定を参照してください。

GitユーザーにSSHアクセス権がない

SELinux対応システム

SELinux対応システムでは、Gitユーザーの.sshディレクトリまたはそのコンテンツのセキュリティコンテキストがめちゃくちゃになる可能性があります。これは、sudo gitlab-ctl reconfigureを実行することで修正できます。これにより、/var/opt/gitlab/.sshにgitlab_shell_tセキュリティコンテキストが設定されます。

この動作を改善するために、semanageを使用してコンテキストを永続的に設定します。semanageコマンドが利用可能であることを確認するために、RHELベースのオペレーティングシステムのRPMパッケージに、ランタイム依存であるpolicycoreutils-pythonが追加されました。

SELinuxの問題を診断して解決する

Linuxパッケージは/etc/gitlab/gitlab.rbのデフォルトのパス変更を検出し、正しいファイルコンテキストを適用する必要があります。

GitLab 16.10以降、管理者はgitlab-ctl apply-sepolicyを試して、SELinuxの問題を自動的に修正できます。ランタイムオプションについては、gitlab-ctl apply-sepolicy --helpを参照してください。

カスタムデータパス設定を使用するインストールの場合、管理者はSELinuxの問題を手動で解決する必要がある場合があります。

データパスはgitlab.rbを介して変更される可能性がありますが、一般的なシナリオではsymlinkパスの使用が強制されます。管理者は注意する必要があります。symlinkパスは、Gitalyデータパスなど、すべてのシナリオでサポートされているわけではないためですGitalyデータパス。

たとえば、/data/gitlabがベースデータディレクトリとして/var/opt/gitlabを置き換えた場合、以下を実行するとセキュリティコンテキストが修正されます:

sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/authorized_keys
sudo restorecon -Rv /data/gitlab/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-shell/config.yml
sudo restorecon -Rv /data/gitlab/gitlab-shell/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-rails/etc/gitlab_shell_secret
sudo restorecon -Rv /data/gitlab/gitlab-rails/
sudo semanage fcontext --list | grep /data/gitlab/

ポリシーが適用された後、ウェルカムメッセージを取得することで、SSHアクセスが機能していることを確認できます:

ssh -T git@gitlab-hostname

すべてのシステム

Gitユーザーは、デフォルトで、/etc/shadowの'!'で示されるロックされたパスワードで作成されます。「UsePam yes」が有効になっていない限り、OpenSSHデーモンは、SSHキーを使用している場合でも、Gitユーザーの認証を許可しません。別の安全なソリューションは、/etc/shadowの'!'を'*'に置き換えることでパスワードをロック解除することです。Gitユーザーは制限されたシェルで実行され、非スーパーユーザーのpasswdコマンドでは新しいパスワードの前に現在のパスワードを入力する必要があるため、パスワードを変更することはできません。ユーザーは'*'に一致するパスワードを入力できません。つまり、アカウントにはパスワードが引き続きありません。

Gitユーザーはシステムにアクセスできる必要があることに注意してください。したがって、/etc/security/access.confでセキュリティ設定を確認し、Gitユーザーがブロックされていないことを確認してください。

エラー: FATAL: could not create shared memory segment: Cannot allocate memory

パッケージ化されたPostgreSQLインスタンスは、共有メモリとして合計メモリの25％を割り当てようとします。一部のLinux（仮想マシン）サーバーでは、利用可能な共有メモリが少なく、PostgreSQLが起動しません。/var/log/gitlab/postgresql/currentで:

  1885  2014-08-08_16:28:43.71000 FATAL:  could not create shared memory segment: Cannot allocate memory
  1886  2014-08-08_16:28:43.71002 DETAIL:  Failed system call was shmget(key=5432001, size=1126563840, 03600).
  1887  2014-08-08_16:28:43.71003 HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMALL.  To reduce the request size (currently 1126563840 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
  1888  2014-08-08_16:28:43.71004       The PostgreSQL documentation contains more information about shared memory configuration.

PostgreSQLが割り当てようとする共有メモリの量を/etc/gitlab/gitlab.rbで手動で減らすことができます:

postgresql['shared_buffers'] = "100MB"

変更を有効にするには、sudo gitlab-ctl reconfigureを実行します。

エラー: FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied

デフォルトでは、PostgreSQLは使用する共有メモリタイプを検出しようとします。共有メモリが有効になっていない場合は、/var/log/gitlab/postgresql/currentにこのエラーが表示される場合があります。これを修正するには、PostgreSQLの共有メモリ検出を無効にできます。/etc/gitlab/gitlab.rbで次の値を設定します:

postgresql['dynamic_shared_memory_type'] = 'none'

変更を有効にするには、sudo gitlab-ctl reconfigureを実行します。

エラー: FATAL: remaining connection slots are reserved for non-replication superuser connections

PostgreSQLには、データベースサーバーへの同時接続の最大数を設定する設定があります。このエラーが表示される場合、GitLabインスタンスが同時接続数に関するこの制限を超えようとしていることを意味します。

最大接続数と利用可能な接続数を確認するには:

  1. PostgreSQLデータベースコンソールを開きます:

    sudo gitlab-psql

  2. データベースコンソールで次のクエリを実行します:

    SELECT
  (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_connections,
  COUNT(*) AS current_connections,
  COUNT(*) FILTER (WHERE state = 'active') AS active_connections,
  ((SELECT setting::int FROM pg_settings WHERE name = 'max_connections') - COUNT(*)) AS remaining_connections
FROM pg_stat_activity;

この問題を修正するには、2つのオプションがあります:

  • 最大接続値を増やすか、どちらかです:

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

      postgresql['max_connections'] = 600

    2. GitLabを再設定します:

      sudo gitlab-ctl reconfigure

  • または、PostgreSQL用の接続プーラーであるPgBouncerの使用を検討できます。

再構成でGLIBCバージョンについてクエリを出す

$ gitlab-ctl reconfigure

/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)
/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)

これは、インストールしたLinuxパッケージが、サーバー上のバージョンとは異なるOSリリース用にビルドされた場合に発生する可能性があります。オペレーティングシステムに対応する正しいLinuxパッケージをダウンロードしてインストールしたことを再確認してください。

再構成でGitユーザーの作成に失敗する

これは、Gitユーザーとしてsudo gitlab-ctl reconfigureを実行した場合に発生する可能性があります。別のユーザーに切り替えます。

さらに重要なこととして、Linuxパッケージで使用されるGitユーザーまたは他のユーザーにsudo権限を付与しないでください。システムユーザーに不要な権限を与えると、システムのセキュリティが弱まります。

sysctlでカーネルパラメータを変更できませんでした

sysctlがカーネルパラメータを変更できない場合、次のスタックトレースでエラーが発生する可能性があります:

 * execute[sysctl] action run
================================================================================
Error executing action `run` on resource 'execute[sysctl]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '255'
---- Begin output of /sbin/sysctl -p /etc/sysctl.conf ----

これは、仮想化されていないマシンでは発生する可能性は低いですが、openVZのような仮想化を備えたVPSでは、コンテナに必要なモジュールが有効になっていないか、コンテナがカーネルパラメータにアクセスできない可能性があります。

sysctlでエラーが発生したモジュールの有効化を試してください。

このイシューに記載されている回避策が報告されており、障害を無視するスイッチを提供することにより、GitLabの内部レシピを編集する必要があります。エラーを無視すると、GitLabサーバーのパフォーマンスに予期しない副作用が発生する可能性があるため、これを行うことはお勧めしません。

このエラーの別のバリエーションでは、ファイルシステムが読み取り専用であると報告され、次のスタックトレースが表示されます:

 * execute[load sysctl conf] action run
    [execute] sysctl: setting key "kernel.shmall": Read-only file system
              sysctl: setting key "kernel.shmmax": Read-only file system

    ================================================================================
    Error executing action `run` on resource 'execute[load sysctl conf]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '255'
    ---- Begin output of cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - ----
    STDOUT:
    STDERR: sysctl: setting key "kernel.shmall": Read-only file system
    sysctl: setting key "kernel.shmmax": Read-only file system
    ---- End output of cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - ----
    Ran cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - returned 255

このエラーは仮想マシンでのみ発生することも報告されており、推奨される回避策は、ホストに値を設定することです。GitLabに必要な値は、仮想マシンのファイル/opt/gitlab/embedded/etc/90-omnibus-gitlab.conf内にあります。ホストOSの/etc/sysctl.confファイルでこれらの値を設定した後、ホストでcat /etc/sysctl.conf /etc/sysctl.d/*.conf | sysctl -e -p -を実行します。次に、仮想マシン内でgitlab-ctl reconfigureを実行してみてください。カーネルが必要な設定ですでに実行されていることを検出し、エラーは発生しません。

他の行についてもこのプロセスを繰り返す必要がある場合があります。たとえば、/etc/sysctl.confに次のようなものを追加した後、再構成が3回失敗します:

kernel.shmall = 4194304
kernel.sem = 250 32000 32 262
net.core.somaxconn = 2048
kernel.shmmax = 17179869184

ファイルを見つけるよりも、Chef出力の行を見る方が簡単かもしれません（ファイルはエラーごとに異なるため）。このスニペットの最後の行を参照してください。

* file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf kernel.shmall] action create
  - create new file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf
  - update content in file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf from none to 6d765d
  --- /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf 2017-11-28 19:09:46.864364952 +0000
  +++ /opt/gitlab/embedded/etc/.chef-90-omnibus-gitlab-kernel.shmall.conf kernel.shmall20171128-13622-sduqoj 2017-11-28 19:09:46.864364952 +0000
  @@ -1 +1,2 @@
  +kernel.shmall = 4194304

ルートアクセスなしでGitLabをインストールできない

ルートアクセスなしでGitLabをインストールできるかどうかを尋ねる人が時々います。これはいくつかの理由で問題があります。

.debまたは.rpmのインストール

私たちの知る限りでは、特権のないユーザーとしてDebianまたはRPMパッケージをインストールするクリーンな方法はありません。ビルドプロセスでソースRPMが作成されないため、LinuxパッケージRPMをインストールできません。

ポート80と443での手間のかからないホスティング

GitLabをデプロイする最も一般的な方法は、GitLabと同じサーバー上でWebサーバー（NGINX/Apache）を実行し、特権（1024未満）のTCPポートでリッスンするようにWebサーバーを設定することです。Linuxパッケージでは、ポート80と443を開くためにルートとしてメインプロセスを実行する必要がある自動的に構成されたNGINXサービスをバンドルすることにより、この利便性を提供します。

これが問題になる場合、管理者がGitLabをインストールすると、バンドルされたNGINXサービスを無効にできますが、これにより、アプリケーションの更新中にNGINX設定をGitLabと一致させるという負担が生じます。

サービス間の分離

Linuxパッケージ（GitLab自体、NGINX、PostgreSQL、Redis、Mattermost）のバンドルされたサービスは、Unixユーザーアカウントを使用して相互に分離されています。これらのユーザーアカウントの作成と管理には、ルートアクセスが必要です。デフォルトでは、Linuxパッケージはgitlab-ctl reconfigure中に必要なUnixアカウントを作成しますが、その動作は無効にできます。

原則として、各アプリケーションに独自のrunit（runsvdir）、PostgreSQL、およびRedisプロセスを提供する場合、Linuxパッケージは、2つのユーザーアカウント（GitLab用とMattermost用）のみで実行できます。ただし、これはgitlab-ctl reconfigure Chefコードの大きな変更であり、既存のすべてのLinuxパッケージインストールに大きなアップグレードの苦痛をもたらす可能性があります。/var/opt/gitlabの下のディレクトリ構造を再配置する必要があるでしょう。

パフォーマンスを向上させるためのオペレーティングシステムの微調整

gitlab-ctl reconfigure中に、PostgreSQLのパフォーマンスを向上させ、接続制限を増やすために、いくつかのsysctl微調整を設定してインストールします。これは、ルートアクセスでのみ実行できます。

gitlab-rake assets:precompileがPermission deniedで失敗する

一部のユーザーから、gitlab-rake assets:precompileを実行すると、Linuxパッケージでは機能しないというレポートがあります。これに対する簡単な答えは、そのコマンドを実行しないことです。これは、ソースからのGitLabインストールのみを対象としています。

GitLab Webインターフェースでは、CSSファイルとJavaScriptファイルを使用します。これらは、Ruby on Railsの用語では「アセット」と呼ばれます。アップストリームGitLabリポジトリでは、これらのファイルは開発者にとって使いやすい方法で保存されています。読みやすく編集しやすいです。ただし、GitLabの通常のユーザーである場合、GitLabの動作が遅くなるため、これらのファイルを開発者にとって使いやすい形式にする必要はありません。これが、GitLab設定プロセスの一部が、アセットを開発者にとって使いやすい形式からエンドユーザーにとって使いやすい（コンパクトで高速な）形式に変換することである理由です。それがrake assets:precompileスクリプトの目的です。

ソースからGitLabをインストールする場合（Linuxパッケージが登場する前は、これが唯一の方法でした）、GitLabを更新するたびに、GitLabサーバー上のアセットを変換する必要があります。以前は、この手順を見落とされていましたが、インターネット上には、ユーザーがrake assets:precompileを実行することを互いに推奨する投稿、コメント、メールがまだあります（現在はgitlab:assets:compileに名前が変更されています）。Linuxパッケージでは、状況が異なります。パッケージをビルドするとき、アセットをコンパイルします。Linuxパッケージを使用してGitLabをインストールすると、変換されたアセットはすでにそこにあります！そのため、パッケージからGitLabをインストールするときにrake assets:precompileを実行する必要はありません。

gitlab-rake assets:precompileが権限エラーで失敗すると、セキュリティの観点から正当な理由で失敗します。アセットを簡単に書き換えることができないという事実は、攻撃者がGitLabサーバーを使用して悪意のあるJavaScriptコードをGitLabサーバーの訪問者に提供することを困難にします。

カスタムJavaScriptまたはCSSコードを使用してGitLabを実行する場合は、おそらくソースからGitLabを実行するか、独自のパッケージをビルドする方が良いでしょう。

実際に何をしているのかを理解している場合は、次のようにgitlab-rake gitlab:assets:compileを実行できます:

sudo NO_PRIVILEGE_DROP=true USE_DB=false gitlab-rake gitlab:assets:clean gitlab:assets:compile
# user and path might be different if you changed the defaults of
# user['username'], user['group'] and gitlab_rails['dir'] in gitlab.rb
sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

エラー: Short read or OOM loading DB

古いRedisセッションのクリーンを試してください。

エラー: The requested URL returned error: 403

aptリポジトリを使用してGitLabをインストールしようとしたときに、次のようなエラーが発生した場合:

W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/DISTRO/dists/CODENAME/main/source/Sources  The requested URL returned error: 403

たとえば、apt-cacher-ngのように、サーバーの前面にリポジトリキャッシャーがあるかどうかを確認します。

apt-cacher-ngの設定ファイル（/etc/apt-cacher-ng/acng.confなど）に次の行を追加します:

PassThroughPattern: (packages\.gitlab\.com|packages-gitlab-com\.s3\.amazonaws\.com|*\.cloudfront\.net)

apt-cacher-ngの詳細と、この変更が必要な理由については、packagecloudブログを参照してください。

自己署名認証局またはカスタム認証局の使用

カスタム認証局を使用する分離されたネットワークにGitLabをインストールする場合、または自己署名証明書を使用する場合は、GitLabが証明書に到達できることを確認してください。そうしないと、次のようなエラーが発生します:

Faraday::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)

GitLabがGitLab Shellなどの内部サービスと接続しようとした場合。

これらのエラーを修正するには、カスタムパブリック証明書のインストールセクションを参照してください。

エラー: proxyRoundTripper: XXX failed with: "net/http: timeout awaiting response headers"

GitLab Workhorseが1分以内（デフォルト）にGitLabから応答を受信しない場合、502ページを提供します。

リクエストがタイムアウトする理由はさまざまです。たとえば、ユーザーが非常に大きな差分を読み込んでいる可能性があります。

/etc/gitlab/gitlab.rbで値を設定することにより、デフォルトのタイムアウト値を大きくすることができます:

gitlab_workhorse['proxy_headers_timeout'] = "2m0s"

ファイルを保存して、GitLabを再設定し、変更を有効にします。

ご希望の変更は拒否されました

おそらく、GitLabの前面にプロキシがあり、Linuxパッケージでデフォルトで設定されたプロキシヘッダーがご使用の環境では正しくありません。

デフォルトのヘッダーをオーバーライドする方法の詳細については、NGINXドキュメントのデフォルトのプロキシヘッダーの変更セクションを参照してください。

CSRFトークンの信頼性を確認できません完了422処理できません

おそらく、GitLabの前面にプロキシがあり、Linuxパッケージでデフォルトで設定されたプロキシヘッダーがご使用の環境では正しくありません。

デフォルトのヘッダーをオーバーライドする方法の詳細については、NGINXドキュメントのデフォルトのプロキシヘッダーの変更セクションを参照してください。

拡張機能ミッシングpg_trgm

GitLabではPostgreSQL拡張機能pg_trgmが必要です。バンドルされたデータベースでLinuxパッケージを使用している場合は、アップグレード時に拡張機能が自動的に有効になるはずです。

ただし、外部（Linuxパッケージ化されていない）データベースを使用している場合は、拡張機能を手動で有効にする必要があります。これには、外部データベースを備えたLinuxパッケージインスタンスには、拡張機能が存在するかどうかを確認する方法がなく、拡張機能を有効にする方法もないためです。

このイシューを解決するには、最初にpg_trgm拡張機能をインストールする必要があります。拡張機能はpostgresql-contribパッケージにあります。Debianの場合:

sudo apt-get install postgresql-contrib

拡張機能をインストールしたら、スーパーユーザーとしてpsqlにアクセスし、拡張機能を有効にします。

  1. スーパーユーザーとしてpsqlにアクセスします:

    sudo gitlab-psql -d gitlabhq_production

  2. 拡張機能を有効にします:

    CREATE EXTENSION pg_trgm;
\q

  3. ここで、移行を再度実行します:

    sudo gitlab-rake db:migrate

Dockerを使用している場合は、最初にコンテナにアクセスしてから、上記のコマンドを実行し、最後にコンテナを再起動する必要があります。

  1. コンテナにアクセスします:

    docker exec -it gitlab bash

  2. 上記のコマンドを実行します。

  3. コンテナを再起動します:

    docker restart gitlab

エラー: Errno::ENOMEM: Cannot allocate memory during backup or upgrade

GitLabをエラーなしで実行するには、2GBの利用可能なメモリが必要です。2GBのメモリをインストールしても、サーバー上の他のプロセスのリソース使用量によっては十分でない場合があります。アップグレードまたはバックアップの実行時以外にGitLabが正常に動作する場合は、スワップを追加すると問題が解決されます。通常の使用中にサーバーがスワップを使用している場合は、RAMを追加してパフォーマンスを向上させることができます。

NGINXエラー: could not build server_names_hash, you should increase server_names_hash_bucket_size

GitLabの外部URLがデフォルトのバケットサイズ（64バイト）より長い場合、NGINXが動作を停止し、ログにこのエラーが表示されることがあります。より大きなサーバー名を許可するには、/etc/gitlab/gitlab.rbでバケットサイズを2倍にします:

nginx['server_names_hash_bucket_size'] = 128

変更を有効にするには、sudo gitlab-ctl reconfigureを実行します。

NFS root_squashにより'root' cannot chownが原因で再設定が失敗する:

$ gitlab-ctl reconfigure

================================================================================
Error executing action `run` on resource 'ruby_block[directory resource: /gitlab-data/git-data]'
================================================================================

Errno::EPERM
------------
'root' cannot chown /gitlab-data/git-data. If using NFS mounts you will need to re-export them in 'no_root_squash' mode and try again.
Operation not permitted @ chown_internal - /gitlab-data/git-data

NFSを使用してディレクトリをマウントし、root_squashモードで設定した場合に、これが発生する可能性があります。再構成では、ディレクトリの所有権を適切に設定できません。NFSサーバー上のNFSエクスポートでno_root_squashを使用するように切り替えるか、ストレージディレクトリの管理を無効にして、自分で権限を管理する必要があります。

gitlab-runsvdirが起動していません

これは、systemdを使用するオペレーティングシステム（Ubuntu 18.04以降、CentOSなど）に適用されます。

gitlab-runsvdirは、multi-user.targetではなく、basic.targetの間に開始されます。GitLabのアップグレード後にこのサービスの開始に問題がある場合は、コマンドを使用して、システムがmulti-user.targetに必要なすべてのサービスを正しく起動したことを確認する必要がある場合があります:

systemctl -t target

すべてが正常に機能している場合、出力はこのように表示されるはずです:

UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
basic.target           loaded active active Basic System
cloud-config.target    loaded active active Cloud-config availability
cloud-init.target      loaded active active Cloud-init target
cryptsetup.target      loaded active active Encrypted Volumes
getty.target           loaded active active Login Prompts
graphical.target       loaded active active Graphical Interface
local-fs-pre.target    loaded active active Local File Systems (Pre)
local-fs.target        loaded active active Local File Systems
multi-user.target      loaded active active Multi-User System
network-online.target  loaded active active Network is Online
network-pre.target     loaded active active Network (Pre)
network.target         loaded active active Network
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target           loaded active active Paths
remote-fs-pre.target   loaded active active Remote File Systems (Pre)
remote-fs.target       loaded active active Remote File Systems
slices.target          loaded active active Slices
sockets.target         loaded active active Sockets
swap.target            loaded active active Swap
sysinit.target         loaded active active System Initialization
time-sync.target       loaded active active System Time Synchronized
timers.target          loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

22 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

すべての行にloaded active activeが表示されるはずです。下の行に示すように、inactive deadが表示されている場合、何らかの問題がある可能性があります:

multi-user.target      loaded inactive dead   start Multi-User System

systemdによってキューに入れられているジョブを調べるには、次を実行します:

systemctl list-jobs

runningジョブが表示されている場合、サービスがスタックしている可能性があり、GitLabの起動がブロックされます。たとえば、一部のユーザーはPlymouthが起動しないという問題を抱えています:

  1 graphical.target                     start waiting
107 plymouth-quit-wait.service           start running
  2 multi-user.target                    start waiting
169 ureadahead-stop.timer                start waiting
121 gitlab-runsvdir.service              start waiting
151 system-getty.slice                   start waiting
 31 setvtrgb.service                     start waiting
122 systemd-update-utmp-runlevel.service start waiting

この場合、Plymouthのアンインストールを検討してください。

非DockerコンテナでのInitデーモンの検出

Dockerコンテナでは、GitLabパッケージは/.dockerenvファイルの存在を検出し、initシステムの自動検出をスキップします。ただし、非Dockerコンテナ（containerd、cri-oなど）では、そのファイルは存在せず、パッケージはsysvinitにフォールバックするため、インストールで問題が発生する可能性があります。これを防ぐために、ユーザーはgitlab.rbファイルで次の設定を追加することにより、initデーモンの検出を明示的に無効にできます:

package['detect_init'] = false

この設定を使用している場合、runsvdir-startコマンドを使用して、gitlab-ctl reconfigureを実行する前にrunitサービスを開始する必要があります:

/opt/gitlab/embedded/bin/runsvdir-start &

gitlab-ctl reconfigureは、AWS Cloudformationの使用中にハングします

GitLab systemdユニットファイルはデフォルトで、AfterフィールドとWantedByフィールドの両方にmulti-user.targetを使用します。これは、サービスがremote-fsターゲットとnetworkターゲットの後に実行されるようにするためであり、GitLabが適切に機能するためです。

ただし、これはAWS Cloudformationで使用されるcloud-init独自のユニット順序付けとうまく相互作用しません。

これを修正するには、ユーザーはgitlab.rbのpackage['systemd_wanted_by']設定とpackage['systemd_after']設定を使用して、適切な順序付けに必要な値を指定し、sudo gitlab-ctl reconfigureを実行できます。再構成が完了したら、変更を有効にするには、gitlab-runsvdirサービスを再起動します。

sudo systemctl restart gitlab-runsvdir

エラー: Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)

GitLabの起動時に、次のようなエラーが発生した場合:

FATAL: Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)

使用中のホスト名が解決可能であり、IPv4アドレスが返されるかどうかを確認します:

getent hosts gitlab.example.com
# Example IPv4 output: 192.168.1.1 gitlab.example.com
# Example IPv6 output: 2002:c0a8:0101::c0a8:0101 gitlab.example.com

getent hosts localhost
# Example IPv4 output: 127.0.0.1 localhost
# Example IPv6 output: ::1 localhost

IPv6アドレス形式が返された場合は、ネットワークインターフェースでIPv6プロトコルサポート（キーワードipv6）が有効になっているかどうかをさらに確認します:

ip addr # or 'ifconfig' on older operating systems

IPv6ネットワークプロトコルサポートが存在しないか無効になっているが、ドメイン名システム構成がホスト名をIPv6アドレスとして解決する場合、GitLabサービスはネットワーク接続を確立できません。

これは、（/etc/hosts）ドメイン名サービス構成を修正して、ホストをIPv4（IPv6）ではなくIPv6（IPv4）アドレスに解決することで解決できます。

external_urlにアンダースコアが含まれている場合にエラー: URI::InvalidComponentError (bad component(expected host component: my_url.tld)

external_urlにアンダースコア（たとえば、https://my_company.example.com）を設定している場合は、CI/CDで次の問題が発生する可能性があります:

  • プロジェクトの設定 > CI/CDページを開くことができなくなります。
  • Runnerはジョブを取得せず、エラー500で失敗します。

その場合、production.logには次のエラーが含まれます:

Completed 500 Internal Server Error in 50ms (ActiveRecord: 4.9ms | Elasticsearch: 0.0ms | Allocations: 17672)

URI::InvalidComponentError (bad component(expected host component): my_url.tld):

lib/api/helpers/related_resources_helpers.rb:29:in `expose_url'
ee/app/controllers/ee/projects/settings/ci_cd_controller.rb:19:in `show'
ee/lib/gitlab/ip_address_state.rb:10:in `with'
ee/app/controllers/ee/application_controller.rb:44:in `set_current_ip_address'
app/controllers/application_controller.rb:486:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:477:in `set_session_storage'
lib/gitlab/i18n.rb:73:in `with_locale'
lib/gitlab/i18n.rb:79:in `with_user_locale'

回避策として、external_urlでアンダースコアを使用しないでください。これに関する未解決のイシューがあります: アンダースコア付きのexternal_url設定は、GitLab CI/CD機能が破損する原因となります。

timeout: run: /opt/gitlab/service/gitalyエラーでアップグレードに失敗しました

次のエラーで再構成を実行するとパッケージのアップグレードが失敗する場合は、すべてのGitalyプロセスが停止していることを確認してから、 sudo gitlab-ctl reconfigureを再実行します。

---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly ----
STDOUT: timeout: run: /opt/gitlab/service/gitaly: (pid 4886) 15030s, got TERM
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly returned 1

詳細については、イシュー341573を参照してください。

GitLabの再インストール時に再構成がスタックする

既知の問題のため、GitLabをアンインストールして再度インストールしようとすると、再構成プロセスがruby_block[wait for logrotate service socket] action runでスタックすることがあります。この問題は、GitLabをアンインストールするときに、systemctlコマンドの1つが実行されない場合に発生します。

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

  • GitLabをアンインストールするときにすべての手順に従い、必要に応じて実行していることを確認してください。
  • 問題7776の回避策に従ってください。

PulpまたはRed Hat Satelliteを使用したGitLab yumリポジトリのミラーリングが失敗する

PulpまたはRed Hat Satelliteを使用したhttps://packages.gitlab.com/gitlab/にあるLinuxパッケージyumリポジトリの直接ミラーリングは、同期時に失敗します。エラーはソフトウェアによって異なります:

  • Pulp 2またはSatellite <6.10は、"Malformed repository: metadata is specified for different set of packages in filelists.xml and in other.xml"エラーで失敗します。
  • Satellite 6.10は、"pkgid"エラーで失敗します。
  • Pulp 3またはSatellite >6.10は成功したように見えますが、リポジトリメタデータのみが同期されます。

これらの同期の失敗は、GitLab yumミラーリポジトリのメタデータの問題が原因です。このメタデータには、通常、 リポジトリ内のすべてのRPMのファイルのリストが含まれるfilelists.xml.gzファイルが含まれています。 GitLab yumリポジトリは、ファイルが完全入力された場合の原因となるサイズの問題を回避するために、このファイルをほとんど空のままにします。

各GitLab RPMには膨大な数のファイルが含まれており、リポジトリ内の多数のRPMを掛けると、filelists.xml.gzファイルが完全入力された場合に巨大になります。ストレージとビルドの制約のため、ファイルを作成しますが、入力されたません。空のファイルにより、PulpおよびRedHat Satellite（Pulpを使用）リポジトリのファイルのミラーリングが失敗します。

詳細については、問題2766を参照してください。

イシューを回避する

イシューを回避するには:

  1. reposyncやcreaterepoなどの代替RPMリポジトリミラーリングツールを使用して、公式のGitLab yumリポジトリのローカルコピーを作成します。これらのツールは、完全に入力されたfilelists.xml.gzファイルの作成を含む、ローカルコピーにリポジトリメタデータを再作成します。
  2. PulpまたはSatelliteをローカルコピーミラーにポイントします。

ローカルコピーミラーの例

次に、ローカルコピーミラーリングを行う方法の例を示します。この例では、以下を使用します:

  • ApacheをリポジトリのWebサーバーとして使用します。
  • reposyncとcreaterepoを使用して、GitLabリポジトリをローカルコピーミラーに同期します。このローカルコピーミラーは、PulpまたはRedHat Satelliteのソースとして使用できます。Cobblerなどの他のツールも使用できます。

この例では:

  • ローカルコピーミラーは、RHEL 8、Rocky 8、またはAlmaLinux 8システムで実行されています。
  • Webサーバーに使用されるホスト名はmirror.example.comです。
  • Pulp 3はローカルコピーミラーから同期します。
  • GitLab Enterprise Editionリポジトリのミラーリングです。

Apacheサーバーを作成および構成する

次の例は、基本的なApache 2サーバーをインストールおよび構成して、1つ以上のYumリポジトリミラーをホストする方法を示しています。Webサーバーの構成とセキュリティ保護の詳細については、Apacheドキュメントを参照してください。

  1. httpdをインストールします:

    sudo dnf install httpd

  2. /etc/httpd/conf/httpd.confにDirectoryスタンザを追加します:

    <Directory "/var/www/html/repos">
Options All Indexes FollowSymLinks
Require all granted
</Directory>

  3. httpd構成を完了します:

    sudo rm -f /etc/httpd/conf.d/welcome.conf
sudo mkdir /var/www/html/repos
sudo systemctl enable httpd --now

ミラーリングされたYumリポジトリURLを取得する

  1. GitLabリポジトリのyum構成ファイルをインストールします:

    curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash
sudo dnf config-manager --disable gitlab_gitlab-ee gitlab_gitlab-ee-source

  2. リポジトリのURLを取得します:

    sudo dnf config-manager --dump gitlab_gitlab-ee | grep baseurl
baseurl = https://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64

    baseurlの内容をローカルコピーミラーのソースとして使用します。たとえばhttps://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64などです。

ローカルコピーミラーを作成する

  1. createrepoパッケージをインストールします:

    sudo dnf install createrepo

  2. reposyncを実行して、RPMをローカルコピーミラーにコピーします:

    sudo dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only

    --newest-onlyオプションは、最新のRPMのみをダウンロードします。このオプションを省略すると、リポジトリ内のすべてのRPM（それぞれ約1 GB）がダウンロードされます。

  3. createrepoを実行して、リポジトリメタデータを再作成します:

    sudo createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee

ローカルコピーミラーリポジトリがhttp://mirror.example.com/repos/gitlab_gitlab-ee/で使用可能になっているはずです。

ローカルコピーミラーを更新する

新しいGitLabバージョンがリリースされるときに新しいRPMを取得するには、ローカルコピーミラーを定期的に更新する必要があります。これを行う1つの方法は、cronを使用することです。

次の内容で/etc/cron.daily/sync-gitlab-mirrorを作成します:

#!/bin/sh

dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only --delete
createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee

dnf reposyncコマンドで使用される--deleteオプションは、対応するGitLabリポジトリに存在しなくなったローカルコピーミラー内のRPMを削除します。

ローカルコピーミラーの使用

  1. Pulpのrepositoryとremoteを作成します:

    pulp rpm repository create --retain-package-versions=1 --name "gitlab-ee"
pulp rpm remote create --name gitlab-ee --url "http://mirror.example.com/repos/gitlab_gitlab-ee/" --policy immediate
pulp rpm repository update --name gitlab-ee --remote gitlab-ee

  2. リポジトリを同期します:

    pulp rpm repository sync --name gitlab-ee

    このコマンドは、GitLabリポジトリへの変更でローカルコピーミラーを更新するために定期的に実行する必要があります。

リポジトリが同期されたら、公開と配信を作成して、使用できるようにすることができます。詳細については、https://docs.pulpproject.org/pulp_rpm/を参照してください。

エラー: E: connection refused to d20rj4el6vkp4c.cloudfront.net 443

packages.gitlab.comにあるパッケージリポジトリでホストされているパッケージをインストールすると、クライアントはCloudFrontアドレスd20rj4el6vkp4c.cloudfront.netにリダイレクトされて従います。エアギャップ環境のサーバーは、次のエラーを受信する可能性があります:

E: connection refused to d20rj4el6vkp4c.cloudfront.net 443
Failed to connect to d20rj4el6vkp4c.cloudfront.net port 443: Connection refused

この問題を解決するには、3つのオプションがあります:

  • ドメインで許可リストを許可できる場合は、エンドポイントd20rj4el6vkp4c.cloudfront.netをファイアウォール設定に追加します。
  • ドメインで許可リストを許可できない場合は、CloudFront IPアドレス範囲をファイアウォール設定に追加します。変更される可能性があるため、このリストをファイアウォール設定と同期させておく必要があります。
  • パッケージファイルを手動でダウンロードして、サーバーにアップロードします。

net.core.somaxconnが低すぎるかどうかを確認する

以下は、net.core.somaxconnの値が低すぎる場合に役立ちます:

$ netstat -ant | grep -c SYN_RECV
4

netstat -ant | grep -c SYN_RECVからの戻り値は、確立を待機している接続の数です。値がnet.core.somaxconnより大きい場合:

$ sysctl net.core.somaxconn
net.core.somaxconn = 1024

タイムアウトまたはHTTP 502エラーが発生する可能性があり、gitlab.rbのpuma['somaxconn']変数を更新して、この値を大きくすることをお勧めします。

エラー: exec request failed on channel 0またはshell request failed on channel 0

Git over SSHを使用してプルまたはプッシュすると、次のエラーが表示されることがあります:

  • exec request failed on channel 0
  • shell request failed on channel 0

これらのエラーは、gitユーザーからのプロセス数が制限を超えている場合に発生する可能性があります。

このイシューを解決するには、次の手順を実行してください:

  1. gitlab-shellが実行されているノードの/etc/security/limits.confファイルで、gitユーザーのnproc設定を増やします。通常、gitlab-shellはGitLab Railsノードで実行されます。
  2. Gitコマンドのプルまたはプッシュを再試行します。

SSH接続の切断後にインストールが停止する

リモート仮想マシンにGitLabをインストールしていて、SSH接続が失われた場合、インストールが停止し、ゾンビdpkgプロセスが発生する可能性があります。インストールを再開するには:

  1. topを実行して、関連するaptプロセスのプロセスIDを検索します。これはdpkgプロセスの親です。
  2. sudo kill <PROCESS_ID>を実行してaptプロセスを強制終了します。
  3. フレッシュインストールを実行する場合のみ、sudo gitlab-ctl cleanseを実行してください。このステップでは既存のデータが消去されるため、アップグレードには使用しないでください。
  4. sudo dpkg configure -aを実行します。
  5. gitlab.rbファイルを編集して、目的の外部URLと、他に不足している設定を含めます。
  6. sudo gitlab-ctl reconfigureを実行します。

GitLabの再設定時に、次のエラーが発生する可能性があります:

RuntimeError: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 77) had an error: RuntimeError: Execution of the command /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO failed with a non-zero exit code (1)

このエラーメッセージは、redis-cliとの接続を確立しようとしている間に、Redisが再起動またはシャットダウンされた可能性があることを示しています。このレシピはgitlab-ctl restart redisを実行し、すぐにバージョンを確認しようとするため、エラーの原因となる競合状態が発生する可能性があります。

この問題を解決するには、次のコマンドを実行します:

sudo gitlab-ctl reconfigure

それが失敗した場合は、gitlab-ctl tail redisの出力を確認し、redis-cliを実行してみてください。