正式なドキュメントは英語版であり、この日本語訳は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

別の回避策として、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の既知のバグによるものです。ユーザーは、プロンプトが表示されたときにパッケージのインストールを手動で承認する必要があります。

したがって、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

このエラーは通常、キーストアにリポジトリのメタデータに署名するために現在使用されている公開キーがないことを意味します。GitLabは、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またはその他のレジストリなどのバンドルされたサービスのexternal_urlを指定しても、gitlab.rbの他の部分が従うkey=value形式には従いません。次の形式で設定されていることを確認してください:

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

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

メールが配信されない

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

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

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を使用してコンテキストを永続的に設定しています。RHELベースのオペレーティングシステムのRPMパッケージには、semanageコマンドを利用できるように、ランタイム依存関係の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データパスなどのすべてのシナリオでサポートされているわけではないため、管理者は注意する必要があります。

たとえば、/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ユーザーは制限付きShellで実行されており、スーパーユーザー以外の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.

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

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には、データベースサーバーへの同時接続の最大数に関する設定があります。デフォルトの制限は400です。このエラーが表示された場合、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つは、最大接続数の値を増やす方法です:

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

      postgresql['max_connections'] = 600

    2. GitLabを再設定します:

      sudo gitlab-ctl reconfigure

    3. GitLabを再起動します:

      sudo gitlab-ctl restart

  • または、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を実行した場合に発生することがあります。別のユーザーに切り替えてください。

さらに重要な点として、GitユーザーやLinuxパッケージで使用されるその他のユーザーに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をデプロイする最も一般的な方法は、Webサーバー（NGINX/Apache）をGitLabと同じサーバー上で実行し、Webサーバーが特権TCPポート（1024未満）でリッスンする構成にすることです。Linuxパッケージでは、自動的に設定されたNGINXサービスをバンドルすることで、この利便性を実現しています。このサービスは、ポート80および443を開くために、ルートとしてマスタープロセスを実行する必要があります。

これが問題となる場合、GitLabをインストールする管理者はバンドルされたNGINXサービスを無効にすることができます。ただしその場合、アプリケーションの更新中もNGINXの設定をGitLabと適合した状態に保つという責任が管理者に生じます。

サービス間の分離

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

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

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サーバーを使用して、そのGitLabサーバーの訪問者に悪意のあるJavaScriptコードを配信することが難しくなるからです。

カスタム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)

このパススルールールが必要な理由と設定方法の詳細については、HTTPS/TLSリポジトリのapt-cacher-ngドキュメントを参照してください。

apt-mirrorを使用して複数のディストリビューション向けにパッケージをミラーリングすると失敗する

GitLab CEとGitLab EEのdebパッケージは、ディストリビューション間で同じバージョン文字列を共有していますが、内容は異なります。Debianリポジトリ形式では、これらは重複パッケージとして扱われます。そのため、1つのdebリポジトリで複数のディストリビューションを安全に配信することはできません。その理由は、あるディストリビューションのパッケージメタデータが別のディストリビューションのものを上書きする可能性があるからです。

各ディストリビューションは専用のパスで公開しています。ただし、https://packages.gitlab.com/gitlab/gitlab-ce/<operating_system> URLへのリクエストは、ホストが使用しているディストリビューションに応じて正しいディストリビューションURLであるhttps://packages.gitlab.com/gitlab/gitlab-ce/<operating_system>/<distribution>にリダイレクトするよう設定されています。このため、ユーザーは異なるディストリビューションでも同じURLを使い続けることができます。

しかし、この方法は、apt-mirrorのようなミラーリングツールを使用して同じホストから複数のディストリビューションをミラーリングする場合には機能しません。そのため、誤ったディストリビューションのメタデータやパッケージをフェッチする可能性があります。

URLパスにディストリビューションを追加して、明示的に指定してください。たとえば、Jammyの場合は次のようになります:

deb https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy jammy main
deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/jammy jammy main
deb https://packages.gitlab.com/gitlab/gitlab-fips/ubuntu/jammy jammy main

この形式では、主な場所は次のとおりです:

  • InReleaseはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/dists/jammy/InReleaseにあります。
  • Packages.gzはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/dists/jammy/main/binary-amd64/Packages.gzにあります。
  • パッケージファイルはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/pool/main/g/gitlab-ce/gitlab-ce_18.5.0-ce.0_amd64.debにあります。

gitlab-runner

gitlab-runnerパッケージの設定は、同じパッケージが複数のディストリビューションで使用されるため、異なります。URLはhttps://packages.gitlab.com/runner/gitlab-runnerのままでかまいません。

自己署名証明書またはカスタム認証局を使用する

カスタム認証局を使用した隔離ネットワーク内で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を再設定します。

The change you wanted was rejected

ほとんどの場合、GitLabの前段にプロキシがあり、パッケージでデフォルトで設定されているプロキシヘッダーがその環境に適していません。

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

Can’t verify CSRF token authenticity Completed 422 Unprocessable

ほとんどの場合、GitLabの前段にプロキシがあり、パッケージでデフォルトで設定されているプロキシヘッダーがその環境に適していません。

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

pg_trgm拡張機能がない

GitLabにはPostgreSQL拡張機能pg_trgmが必要です。バンドルされたデータベースを含む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に必要なメモリ量は2 GBです。2 GBのメモリが搭載されていても、サーバー上の他のプロセスのリソース使用状況によっては十分でない可能性があります。アップグレードやバックアップの実行時以外では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は、basic.targetではなくmulti-user.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

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

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

AWS Cloudformationの使用中にgitlab-ctl reconfigureがハングする

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ネットワークプロトコルのサポートがないか無効になっているが、DNS設定がホスト名をIPv6アドレスとして解決する場合、GitLabサービスはネットワーク接続を確立できません。

この問題は、DNS設定（または/etc/hosts）を修正し、ホストをIPv6アドレスではなくIPv4アドレスに解決するように設定することで解決できます。

エラー: external_urlにアンダースコアが含まれている場合の... 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ではアンダースコアの使用を避けてください。これに関連する未解決のイシューがあります: Setting external_url with underscore results in a broken GitLab CI/CD functionality.

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コマンドのいずれかが実行されなかった場合に発生します。

この問題を解決するには:

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

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

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

  • 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ミラーリポジトリ内のメタデータに関する問題が原因です。このメタデータにはfilelists.xml.gzファイルが含まれており、通常はリポジトリ内のすべてのRPMのファイルリストが含まれます。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の参照先をそのローカルミラーにしてください。

ローカルミラーの例

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

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

この例では:

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

Apacheサーバーを作成して設定する

次の例は、1つ以上のYumリポジトリミラーをホストするために、基本的なApache 2サーバーをインストールしてから設定する方法を示しています。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://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アドレス範囲をファイアウォール設定に追加します。このリストは変更される可能性があるため、ファイアウォール設定と同期した状態を常に維持する必要があります。
  • パッケージファイルをパッケージを手動でダウンロードして、サーバーにアップロードします。

パッケージストレージ操作時のエラー: 503 Service Unavailable

一部のパッケージストレージコンポーネントは、Google Cloud Storage（GCS）を介して提供されます。これらのコンポーネントは、パブリックAPTリポジトリエンドポイントに加えて、GCSエンドポイントへの送信HTTPSアクセスを必要とします。apt updateが503 Service Unavailableエラーで失敗した場合、storage.googleapis.com/packages-opsへのアクセスがブロックされています。

このエラーを解決するには、ファイアウォールルールで、次のエンドポイントへの送信HTTPS（ポート443）接続が許可されていることを確認してください:

  • packages.gitlab.com
  • storage.googleapis.com
  • Google Cloud Storageのpackages-opsバケット

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を実行してみてください。