Omnibus GitLabインストールのトラブルシューティング

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

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

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

詳しくはPackagecloudのJoe Damatoのコメントと 彼のブログ記事をご覧ください。

別の回避策は、CE packagesまたはEE packagesリポジトリから正しいパッケージを選択して手動でダウンロードすることです：

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 プラットフォームへのインストールで不明なキー署名に関する警告が表示されます。

Omnibus GitLab パッケージは、パッケージリポジトリが署名付きメタデータを提供することに加えて、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の既知のバグであり、zypperはリポジトリ設定ファイル内のgpgkey キーワードを無視します。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 8.17から利用可能なコマンド)を使うか、最新のgitlab.rb.templateをチェックすることで、利用可能な最新の設定を確認することができます。

GitLab にブラウザからアクセスできません。

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

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"
note
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 のセキュリティ・コンテキストを設定します。

GitLab 10.0では、semanage を使ってコンテキストを恒久的に設定することで、この挙動が改善されました。RHELベースのオペレーティングシステム用のRPMパッケージには、semanage コマンドを確実に利用できるようにするために、実行時の依存関係policycoreutils-python が追加されています。

SELinuxの問題の診断と解決

Omnibus GitLabは/etc/gitlab/gitlab.rb 、デフォルトパスの変更を検出し、正しいファイルコンテキストを適用する必要があります。カスタムのデータパス設定を使用するインストールでは、管理者は手動でSELinuxの問題を解決する必要があるかもしれません。

データパスはgitlab.rb を介して変更することができますが、一般的なシナリオではsymlink パスを symlink使用せざるを得ません。Gitalyデータパスのようなすべてのシナリオでパスがサポートされているsymlink わけではないので、管理者は注意する必要が symlinkあります。

例えば、/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ユーザーがブロックされていないことを確認してください。

PostgreSQL エラー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 を実行してください。

PostgreSQL エラー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 を実行してください。

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

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

この問題を解決するには、2つの選択肢があります：

  • 最大接続数を増やすか：

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

      postgresql['max_connections'] = 600

    2. GitLab を再設定します：

      sudo gitlab-ctl reconfigure

  • あるいは、PostgreSQL用のコネクションプーラーであるPgBouncerを使うこともできます。

Reconfigureは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)

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

ReconfigureでGitユーザーの作成に失敗します。

これは、Gitユーザーとしてsudo gitlab-ctl reconfigure 。別のユーザーに切り替えてください。

さらに重要なことは、GitユーザーやOmnibus GitLabが使用する他のユーザーに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 に次のように追加した後、reconfigure は3回失敗します：

kernel.shmall = 4194304
kernel.sem = 250 32000 32 262
net.core.somaxconn = 1024
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

root権限なしでOmnibus GitLabをインストールできません。

時々、root権限なしでGitLabをインストールできるかどうか尋ねられることがあります。これにはいくつかの理由があります。

.deb や .rpm のインストール

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

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

GitLabをデプロイする最も一般的な方法は、GitLabと同じサーバー上でWebサーバー（NGINX/Apache）を動作させ、Webサーバーが特権的な（1024以下の）TCPポートをリッスンすることです。Omnibus GitLabでは、ポート80と443を開くためにrootとしてマスタープロセスを実行する必要があるNGINXサービスを自動的に設定することで、この利便性を提供します。

もしこれが問題であれば、GitLabをインストールする管理者はバンドルされたNGINXサービスを無効にすることができますが、これはアプリケーションのアップデート中にNGINXの設定をGitLabと同調させ続ける負担を管理者に負わせることになります。

Omnibusサービス間の分離

Omnibus GitLab のバンドルサービス (GitLab 本体、NGINX、PostgreSQL、Redis、Mattermost) は、Unix ユーザーアカウントを使って互いに隔離されています。これらのユーザーアカウントの作成と管理には root アクセスが必要です。デフォルトでは、Omnibus GitLab はgitlab-ctl reconfigure 中に必要な Unix アカウントを作成しますが、この動作を無効にすることもできます。

それぞれのアプリケーションに独自のrunit (runvdir)、PostgreSQL、Redisプロセスを与えれば、原理的にはOmnibus GitLabは2つのユーザーアカウント（GitLab用とMattermost用）だけで済みます。しかし、これはgitlab-ctl reconfigure Chefコードの大きな変更となり、既存のGitLabインストールすべてに大きなアップグレードの痛みをもたらすでしょう。(私たちはおそらく/var/opt/gitlab の下のディレクトリ構造を再配置しなければならないでしょう)。

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

gitlab-ctl reconfigure の間に、PostgreSQLの性能を向上させ、接続制限を増やすために、いくつかのsysctlの調整を設定しインストールします。これはroot権限でのみ行うことができます。

gitlab-rake assets:precompile 権限が拒否されました。

一部のユーザーはgitlab-rake assets:precompile を実行しても Omnibus パッケージでは動作しないと報告しています。このコマンドはGitLabをソースからインストールする場合のみです。

GitLabのWebインターフェースは、Ruby on Rails用語で’assets’と呼ばれるCSSとJavaScriptファイルを使っています。アップストリームのGitLabリポジトリでは、これらのファイルは開発者が読みやすく編集しやすい方法で保存されています。GitLabの普通のユーザーであれば、これらのファイルを開発者向けの形式にはしたくありません。そのため、GitLabのセットアッププロセスの一環として、アセットを開発者フレンドリーなフォーマットからエンドユーザーフレンドリーな（コンパクトで高速な）フォーマットに変換する必要があります。rake assets:precompile スクリプトはそのためのものです。

GitLabをソースからインストールする場合（Omnibusパッケージができる前はこれが唯一の方法でした）、GitLabを更新するたびにGitLabサーバー上のアセットを変換する必要があります。以前はこのステップを見過ごす人が多く、インターネット上では今でもユーザー同士がrake assets:precompile （現在はgitlab:assets:compile に改名されました）の実行を推奨する投稿やコメント、メールが出回っています。オムニバスパッケージでは事情が異なります。パッケージをビルドするときに、アセットをコンパイルします。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

DBの読み込みが短いかOOM」エラー

古いRedisセッションをクリーニングしてみてください。

Aptエラー ‘要求されたURLがエラーを返しました：403’

apt repo を使って 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 config に追加します（例：/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：で失敗しました：「.NET/http: 応答ヘッダー待ちのタイムアウト”

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

リクエストがタイムアウトする理由は様々で、ユーザーが非常に大きなdiffを読み込んでいる場合などが考えられます。

/etc/gitlab/gitlab.rb で値を設定することで、デフォルトのタイムアウト値を増やすことができます：

gitlab_workhorse['proxy_headers_timeout'] = "2m0s"

ファイルを保存し、変更を有効にするためにGitLab を再設定してください。

希望した変更が却下されました

おそらく、GitLabの前にプロキシがある環境でGitLabをセットアップしており、デフォルトでパッケージに設定されているプロキシヘッダーがあなたの環境に合っていないのでしょう。

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

CSRF トークンの真正性を検証できません。

おそらく、GitLabの前にプロキシがある環境でGitLabをセットアップしており、デフォルトでパッケージに設定されているプロキシヘッダーがあなたの環境に合っていないのでしょう。

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

pg_trgm が見つからない拡張機能

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

しかし、外部の（パッケージ化されていない）データベースを使用している場合は、手動で拡張機能を有効にする必要があります。その理由は、外部データベース付きのOmnibus GitLabパッケージには拡張機能が存在するかどうかを確認する手段がなく、また拡張機能を有効にする手段もないからです。

このイシューを解決するには、まず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: バックアップまたはアップグレード中にメモリを割り当てられません。

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 モードで設定している場合に発生する可能性があります。Reconfigure はディレクトリの所有者を適切に設定できません。NFS サーバー上の NFS エクスポートでno_root_squash を使用するように切り替えるか、ストレージディレクトリ管理を無効にして権限を自分で管理する必要があります。

gitlab-runsvdir 起動しない

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

GitLab 11.2以降では、basic.target の代わりにmulti-user.target の間にgitlab-runsvdir が起動します。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 &

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: アドレスファミリがプロトコルでサポートされていません - 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アドレスに解決することで解決できます。

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

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 エラーで失敗します。

reconfigure の実行時に以下のエラーでパッケージのアップグレードに失敗する場合は、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 の再インストール時に Reconfigure がスタックします。

既知のイシューのため、GitLabをアンインストールした後に再度インストールしようとすると、reconfigureプロセスがruby_block[wait for logrotate service socket] action run 。この問題は、GitLabのアンインストール時にsystemctl コマンドの一つが実行されなかった場合に発生します。

このイシューを解決するには、以下の手順に従ってください：

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

Pulp や Red Hat Satellite を使った GitLabyum リポジトリのミラーリングに失敗します。

https://packages.gitlab.com/gitlab/ にある Omnibus GitLabyum リポジトリをPulpまたは RedHat 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は成功するようですが、リポジトリのメタデータのみが同期されます。

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

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

詳細はイシュー2766を参照してください。

イシューの回避策

イシューを回避するには

  1. reposync やcreaterepo のような別の RPM リポジトリミラーリングツールを使って、GitLabyum 公式リポジトリの内部コピーを作成してください。これらのツールは、リポジトリのメタデータをローカルのデータに再作成します。これには、完全に入力されたfilelists.xml.gz ファイルを作成することも含まれます。
  2. Pulp または Satellite をローカルミラーに向けます。

ローカルミラーの例

以下はローカルミラーリングの例です。この例では

  • リポジトリ用のウェブサーバーとしてApacheを使用します。
  • reposync とcreaterepo を使って GitLab リポジトリをローカルミラーに同期します。このローカルミラーは、Pulp や RedHat Satellite のソースとして使うことができます。Cobbler のような他のツールも使えます。

この例では:

  • ローカルミラーはRHEL 8,Rocky 8,AlmaLinux 8 システム上で動作しています。
  • ウェブサーバのホスト名はmirror.example.com です。
  • パルプ3はローカルミラーから同期します。
  • ミラーリングはGitLab Enterprise Edition のリポジトリから行います。

Apache サーバーの作成と設定

以下の例では、1つ以上の Yum リポジトリミラーをホストするために、基本的な Apache 2 サーバーをインストールして設定する方法を示します。ウェブサーバーの設定とセキュリティの詳細については、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を取得する必要があります。これを行う一つの方法は、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. Pulprepository と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/ を参照してください。