• GitLab の外部 URL の設定
  • インストール時の外部URLの指定
• GitLab の相対 URL の設定
• 非 root ユーザーからの外部設定ファイルの読み込み
• ファイルからの証明書の読み取り
• Git データを別のディレクトリに保存
• Git ユーザーやグループの名前を変更します。
• ユーザーとグループの識別子を数値で指定します。
• ユーザーとグループのアカウント管理を無効にします。
• ユーザーのホームディレクトリの移動
• ストレージディレクトリの管理を無効に
  • /etc/gitlab ディレクトリ管理を無効にします。
  • /var/opt/gitlab ディレクトリ管理を無効にします。
• 指定したファイルシステムがマウントされた後にのみLinuxパッケージインストールサービスを開始
• ランタイムディレクトリの設定
• 認証失敗の禁止設定
• インストール中の自動キャッシュクリーニングを無効にします。
• Sentryを使ったエラーレポートとロギング
• コンテンツ・デリバリー・ネットワークのURLの設定
• コンテンツセキュリティポリシーの設定
• インストール時の root パスワードの初期設定
• ホストヘッダ攻撃を防ぐための許可ホストの設定
• 関連するトピック
• トラブルシューティング
  • 相対URLのトラブルシューティング
  • Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]

Linuxパッケージインストールの設定オプション

GitLab を設定するには、/etc/gitlab/gitlab.rb ファイルで関連するオプションを設定します。

gitlab.rb.template 利用可能なオプションの完全なリストがあります。新規インストールでは、デフォルトで/etc/gitlab/gitlab.rb にリストされているテンプレートのすべてのオプションが設定されています。

/etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb を編集するときに提供される例は、インスタンスのデフォルト設定を必ずしも反映していないかもしれません。

デフォルト設定のリストはパッケージのデフォルトを参照してください。

GitLab の外部 URL の設定

ユーザーに正しいリポジトリクローンリンクを表示するには、ユーザーがリポジトリにアクセスするための URL を GitLab に提供する必要があります。サーバーの IP を使うこともできますが、完全修飾ドメイン名（Fully Qualified Domain Name）(FQDN) 。セルフマネージド GitLab インスタンスでの DNS の使用についての詳細は、DNS ドキュメントをご覧ください。

外部 URL を変更するには

1. オプション。外部URLを変更する前に、カスタムホームページURLまたはサインアウト後のパスを以前に定義しているかどうかを確認してください。これらの設定は両方とも、新しい外部URLを設定した後に意図しないリダイレクトを引き起こす可能性があります。URLを定義している場合は、完全に削除してください。

2. /etc/gitlab/gitlab.rb を編集し、external_url をお好みのURLに変更します：

   external_url "http://gitlab.example.com"
   

   または、サーバーのIPアドレスを使用することもできます：

   external_url "http://10.0.0.1"
   

   これまでの例では、プレーンHTTPを使用しています。HTTPSを使用したい場合は、SSLの設定方法を参照してください。

3. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

4. オプションです。GitLabをしばらく使っていた場合は、外部URLを変更した後、Markdownキャッシュも無効にしてください。

インストール時の外部URLの指定

Linuxパッケージを使う場合、EXTERNAL_URL 環境変数を使うことで、最小限のコマンド数でGitLabインスタンスをセットアップできます。この変数が設定されている場合、自動的に検出され、その値はgitlab.rb ファイルにexternal_url として書き込まれます。

EXTERNAL_URL 環境変数はパッケージのインストールとアップグレードにのみ影響します。通常の reconfigure の実行には、/etc/gitlab/gitlab.rb の値が使われます。

パッケージアップデートの一環として、EXTERNAL_URL 環境変数を不用意に設定すると、警告なしに/etc/gitlab/gitlab.rb の既存の値が置き換えられます。そのため、この変数をグローバルに設定するのではなく、インストールコマン ドに特別に渡すことをお勧めします：

sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

GitLab の相対 URL の設定

私たちはGitLabを独自の（サブ）ドメインにインストールすることを推奨していますが、不可能な場合もあります。その場合、GitLabは相対URLの下にインストールすることもできます。例えば、https://example.com/gitlab.

URL を変更すると、すべてのリモート URL も変更されるので、GitLab インスタンスを指すローカルリポジトリでは手動で編集する必要があります。

GitLab で相対 URL を有効にするには：

1. /etc/gitlab/gitlab.rb でexternal_url を設定します：

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

   この例では、GitLab が提供される相対 URL は/gitlab です。お好みで変更してください。

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

何かイシューがあれば、トラブルシューティングのセクションをご覧ください。

非 root ユーザーからの外部設定ファイルの読み込み

Linux パッケージのインストールでは、すべての設定を/etc/gitlab/gitlab.rb ファイルから読み込みます。このファイルは厳格なファイル権限を持っており、root ユーザーが所有しています。厳格な権限と所有権を持つ理由は、/etc/gitlab/gitlab.rb がgitlab-ctl reconfigure の間にroot ユーザーによって Ruby コードとして実行されるためです。つまり、/etc/gitlab/gitlab.rb への書き込み権限を持つユーザーは、rootによってコードとして実行される設定を追加することができます。

特定の組織では、設定ファイルへのアクセスは許可されていますが、rootユーザーとしては許可されていません。ファイルへのパスを指定することで、/etc/gitlab/gitlab.rb 内部で外部設定ファイルをインクルードできます：

from_file "/home/admin/external_gitlab.rb"

from_file を使用して/etc/gitlab/gitlab.rb にインクルードしたコードは、sudo gitlab-ctl reconfigure を実行するときにroot 権限で実行されます。from_file がインクルードされた後に/etc/gitlab/gitlab.rb で設定された設定は、インクルードされたファイルの設定よりも優先されます。

ファイルからの証明書の読み取り

証明書は別のファイルとして保存し、sudo gitlab-ctl reconfigure を実行する際にメモリにロードすることができます。証明書を含むファイルはプレーンテキストでなければなりません。

この例では、PostgreSQLサーバの証明書は、gitlab.rb に直接コピー&ペーストするのではなく、ファイルから直接読み込んでいます。

postgresql['internal_certificate'] = File.read('/path/to/server.crt')

Git データを別のディレクトリに保存

デフォルトでは、Linux パッケージのインストールは Git リポジトリのデータを/var/opt/gitlab/git-data の下に保存します。リポジトリはrepositories というサブフォルダーに保存されます。

git-data の親ディレクトリの場所を変更するには：

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

   git_data_dirs({ "default" => { "path" => "/mnt/nas/git-data" } })
   

   複数のGitデータ・ディレクトリを追加することもできます：

   git_data_dirs({
     "default" => { "path" => "/var/opt/gitlab/git-data" },
     "alternative" => { "path" => "/mnt/nas/git-data" }
   })
   

   対象のディレクトリとそのサブパスは、シンボリックリンクであってはなりません。

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

3. オプション。/var/opt/gitlab/git-data に既に Git リポジトリがある場合は、新しい場所に移動することができます：

   1. リポジトリを移動する間、ユーザーがリポジトリに書き込めないようにします：

      sudo gitlab-ctl stop
      

   2. リポジトリを新しい場所に同期します。repositories の後ろにはスラッシュが_ありませんが_、git-dataの後ろにはスラッシュが_ある_ことに注意してください：

      sudo rsync -av --delete /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/
      

   3. 再構成して必要なプロセスを開始し、間違った権限を修正します：

      sudo gitlab-ctl reconfigure
      

   4. /mnt/nas/git-data/ のディレクトリレイアウトを再確認してください。期待される出力はrepositories のはずです：

      sudo ls /mnt/nas/git-data/
      

   5. GitLab を起動し、ウェブインターフェイスでリポジトリをブラウズできることを確認します：

      sudo gitlab-ctl start
      

Gitalyを別のサーバーで実行している場合は、各Gitデータ・ディレクトリのgitaly_address 。Gitalyの設定に関するドキュメントを参照してください。

すべてのリポジトリを移動するのではなく、既存のリポジトリ・ストレージ間で特定のプロジェクトを移動したい場合は、Edit Project APIエンドポイントを使用し、repository_storage 属性を指定してください。

Git ユーザーやグループの名前を変更します。

デフォルトでは、Linuxパッケージのインストールでは、git GitLab Shellのログイン、Gitデータ自体の所有権、ウェブインターフェイスでのSSH URL生成に gitユーザー名を使用します。git 同様に git、グループはGitデータのグループ所有権に使われます。

ユーザーとグループを変更するには：

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

   user['username'] = "gitlab"
   user['group'] = "gitlab"
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

既存のインストールのユーザー名を変更する場合は、reconfigure を実行してもネストしたディレクトリの所有者は変更されないので、手動で変更する必要があります。新しいユーザーがrepositories とuploads ディレクトリにアクセスできることを確認してください。

ユーザーとグループの識別子を数値で指定します。

Linuxパッケージのインストールでは、GitLab、PostgreSQL、Redis、NGINXなどのユーザーが作成されます。これらのユーザーの識別子を数値で指定します：

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

   user['uid'] = 1234
   user['gid'] = 1234
   postgresql['uid'] = 1235
   postgresql['gid'] = 1235
   redis['uid'] = 1236
   redis['gid'] = 1236
   web_server['uid'] = 1237
   web_server['gid'] = 1237
   registry['uid'] = 1238
   registry['gid'] = 1238
   mattermost['uid'] = 1239
   mattermost['gid'] = 1239
   prometheus['uid'] = 1240
   prometheus['gid'] = 1240
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

3. オプションです。user['uid'] とuser['gid'] を変更する場合は、Linux パッケージによって直接管理されていないファイル、例えばログの uid/guid を更新してください：

find /var/log/gitlab -uid <old_uid> | xargs -I:: chown git ::
find /var/log/gitlab -gid <old_uid> | xargs -I:: chgrp git ::
find /var/opt/gitlab -uid <old_uid> | xargs -I:: chown git ::
find /var/opt/gitlab -gid <old_uid> | xargs -I:: chgrp git ::

ユーザーとグループのアカウント管理を無効にします。

デフォルトでは、Linux パッケージインストールはシステムユーザーとグループアカウントを作成し、情報を更新します。これらのシステムアカウントはパッケージの様々なコンポーネントを実行します。ほとんどのユーザは、この動作を変更する必要はありません。しかし、システムアカウントを他のソフトウェア、例えばLDAPなどで管理している場合は、GitLabパッケージが行うアカウント管理を無効にする必要があるかもしれません。

デフォルトでは、Linuxパッケージのインストールは以下のユーザーとグループが存在することを想定しています：

ユーザーとグループのアカウント管理を無効にします：

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

   manage_accounts['enable'] = false
   

2. オプション。異なるユーザー/グループ名を使用することもできますが、その場合はユーザー/グループの詳細を指定する必要があります：

   # GitLab
   user['username'] = "custom-gitlab"
   user['group'] = "custom-gitlab"
   user['shell'] = "/bin/sh"
   user['home'] = "/var/opt/custom-gitlab"
      
   # Web server
   web_server['username'] = 'webserver-gitlab'
   web_server['group'] = 'webserver-gitlab'
   web_server['shell'] = '/bin/false'
   web_server['home'] = '/var/opt/gitlab/webserver'
      
   # Postgresql (not needed when using external Postgresql)
   postgresql['username'] = "postgres-gitlab"
   postgresql['group'] = "postgres-gitlab"
   postgresql['shell'] = "/bin/sh"
   postgresql['home'] = "/var/opt/postgres-gitlab"
      
   # Redis (not needed when using external Redis)
   redis['username'] = "redis-gitlab"
   redis['group'] = "redis-gitlab"
   redis['shell'] = "/bin/false"
   redis['home'] = "/var/opt/redis-gitlab"
      
   # And so on for users/groups for GitLab Mattermost
   

3. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

ユーザーのホームディレクトリの移動

GitLabユーザーには、ホームディレクトリをNFSのような共有ストレージではなく、ローカルディスクに設定することを推奨します。NFSに設定すると、GitリクエストはGit設定を読み込むために別のネットワークリクエストを行わなければならず、これはGitオペレーションにおけるレイテンシを増加させます。

既存のホームディレクトリを移動するには、GitLabサービスを停止する必要があり、多少のダウンタイムが必要です：

1. GitLab を停止します：

   gitlab-ctl stop
   

2. runitサーバーを停止します：

   sudo systemctl stop gitlab-runsvdir
   

3. ホームディレクトリを変更します：

   usermod -d /path/to/home <username>
   

   既存のデータがある場合は、手動で新しい場所にコピー/同期する必要があります：

4. 編集/etc/gitlab/gitlab.rb ：

   user['home'] = "/var/opt/custom-gitlab"
   

5. runitサーバを起動します：

   sudo systemctl start gitlab-runsvdir
   

6. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

ストレージディレクトリの管理を無効に

Linux パッケージは、正しい所有者と権限で必要なディレクトリをすべて作成し、これを更新し続けます。

ディレクトリの中には大容量のデータを保持するものもあるため、特定のセットアップでは、これらのディレクトリは NFS (またはその他の) 共有にマウントされることがほとんどです。

マウントの種類によっては、rootユーザー(初期設定のデフォルトユーザー)によるディレクトリの自動作成が許可されないものがあります。例えば、共有上でroot_squash が有効になっているNFSなどです。これを回避するために、Linux パッケージはディレクトリのオーナーユーザーを使ってディレクトリの作成を試みます。

/etc/gitlab ディレクトリ管理を無効にします。

/etc/gitlab ディレクトリをマウントしている場合、そのディレクトリの管理をオフにすることができます：

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

   manage_storage_directories['manage_etc'] = false
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

/var/opt/gitlab ディレクトリ管理を無効にします。

すべてのGitLabストレージディレクトリをそれぞれ別マウントしている場合は、ストレージディレクトリの管理を完全に無効にしてください。

Linuxパッケージのインストールでは、これらのディレクトリがファイルシステム上に存在することを期待します。この設定がされている場合、正しい権限を作成して設定するのはあなた次第です。

この設定を有効にすると、以下のディレクトリが作成されなくなります：

ストレージディレクトリの管理を無効にするには

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

   manage_storage_directories['enable'] = false
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

指定したファイルシステムがマウントされた後にのみLinuxパッケージインストールサービスを開始

Linuxパッケージインストールサービス（NGINX、Redis、Pumaなど）を、指定したファイルシステムがマウントされる前に開始しないようにします：

1. 編集/etc/gitlab/gitlab.rb ：

   # wait for /var/opt/gitlab to be mounted
   high_availability['mountpoint'] = '/var/opt/gitlab'
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

ランタイムディレクトリの設定

Prometheusモニタリングが有効になっている場合、GitLab Exporterは各Pumaプロセスの測定（メトリクス）を行います。すべてのPumaプロセスは、コントローラのリクエストごとにメトリクスファイルを一時的な場所に書き込む必要があります。そしてPrometheusはこれらのファイルをすべて収集し、その値を処理します。

ディスクI/Oの作成を避けるため、Linuxパッケージではランタイムディレクトリを使用します。

reconfigure の間、パッケージは/run がtmpfs マウントであるかどうかをチェックします。マウントされていない場合、以下の警告が表示され、Railsメトリクスは無効になります：

Runtime directory '/run' is not a tmpfs mount.

Railsメトリクスを再度有効にするには、次の手順に従います：

1. /etc/gitlab/gitlab.rb を編集してtmpfs マウントを作成します（設定に= がないことに注意してください）：

   runtime_dir '/path/to/tmpfs'
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

認証失敗の禁止設定

Git やコンテナレジストリに対して認証失敗の禁止を設定することができます：

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

   gitlab_rails['rack_attack_git_basic_auth'] = {
     'enabled' => true,
     'ip_whitelist' => ["127.0.0.1"],
     'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
     'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
     'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
   }
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

以下の設定が可能です：

• enabled:デフォルトでは、false に設定されています。 ラックアタックを有効にするには、true に設定します。
• ip_whitelist:ブロックしないIP。Ruby配列の文字列としてフォーマットする必要があります。CIDR表記はGitLab 12.1以降でサポートされています。例えば、["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"].
• maxretry:指定時間内にリクエスト可能な最大回数。
• findtime:拒否リストに追加される前に、失敗したリクエストが IP に対してカウントできる最大時間 (秒単位)。
• bantime:IP がブロックされる合計時間 (秒)。

インストール中の自動キャッシュクリーニングを無効にします。

GitLabのインストール規模が大きい場合、rake cache:clear タスクの実行に時間がかかることがあるので、実行したくないかもしれません。デフォルトでは、キャッシュクリアタスクは再設定中に自動的に実行されます。

インストール中の自動キャッシュ・クリーニングを無効にするには、次のようにします：

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

   # This is an advanced feature used by large gitlab deployments where loading
   # whole RAILS env takes a lot of time.
   gitlab_rails['rake_cache_clear'] = false
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

Sentryを使ったエラーレポートとロギング

Sentryは、SaaSまたはオンプレミスとして使用できるエラーレポートとロギングツールです。オープンソースであり、ソースコードリポジトリを閲覧することができます。

Sentryを設定するには：

1. 編集/etc/gitlab/gitlab.rb ：

   gitlab_rails['sentry_enabled'] = true
   gitlab_rails['sentry_dsn'] = 'https://<key>@sentry.io/<project>'
   gitlab_rails['sentry_clientside_dsn'] = 'https://<key>@sentry.io/<project>'
   gitlab_rails['sentry_environment'] = 'production'
   

   Sentry環境は、ラボ、開発者、ステージング、本番環境など、複数のデプロイされたGitLab環境にわたってエラーやイシューを追跡するために使うことができます。

2. オプションです。特定のサーバーから送信されるすべてのイベントにカスタムSentry タグを設定するには、GITLAB_SENTRY_EXTRA_TAGS an 環境変数を設定します。この変数は JSON エンコードされたハッシュで、そのサーバーからのすべての例外に対して Sentry に渡すべきタグを表します。

   インスタンスンス：

   gitlab_rails['env'] = {
     'GITLAB_SENTRY_EXTRA_TAGS' => '{"stage": "main"}'
   }
   

   を設定すると、main の値でstage タグが追加されます。

3. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

コンテンツ・デリバリー・ネットワークのURLの設定

gitlab_rails['cdn_host'] を使用して、Content Delivery Network(CDN) またはアセットホストで静的アセットをサービスします。これでRailsアセットホストが設定されます。

CDN/アセットホストを設定するには：

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

   gitlab_rails['cdn_host'] = 'https://mycdnsubdomain.fictional-cdn.com'
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

一般的なサービスをアセットホストとして設定するための追加ドキュメントは、このイシューで追跡されています。

コンテンツセキュリティポリシーの設定

コンテンツセキュリティポリシー(CSP) を設定することで、JavaScript のクロスサイトスクリプティング(XSS) 攻撃を阻止することができます。詳しくはCSP に関する Mozilla のドキュメントをご覧ください。

GitLab 12.2では、インラインJavaScriptによるCSPとnonce-sourceのサポートが追加されました。デフォルトではまだ設定されていません。

CSPを追加するには

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

   gitlab_rails['content_security_policy'] = {
       enabled: true,
       report_only: false
   }
   

   GitLabは自動的にCSPのセキュアなデフォルト値を提供します。ディレクティブに明示的に<default_value> の値を設定することは、値を設定しないことと同じであり、デフォルト値が使用されます。

   カスタムCSPを追加するには

   gitlab_rails['content_security_policy'] = {
       enabled: true,
       report_only: false,
       directives: {
         default_src: "'none'",
         script_src: "https://example.com"
       }
   }
   

   GitLab 14.9以降では、明示的に設定されていないディレクティブにはセキュアなデフォルト値が使用されます。

   CSPディレクティブの設定を解除するには、false 。

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

インストール時の root パスワードの初期設定

管理者ユーザーroot の初期パスワードは、インストール時に設定できます。詳細については、初期パスワードの設定を参照してください。

ホストヘッダ攻撃を防ぐための許可ホストの設定

GitLabが意図した以外のホストヘッダを受け取らないようにします：

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

   gitlab_rails['allowed_hosts'] = ['gitlab.example.com']
   

2. GitLab を再設定します：

   sudo gitlab-ctl reconfigure
   

allowed_hosts を設定しないことによるGitLabのセキュリティ上の既知のイシューはありませんが、潜在的なHTTP Hostヘッダー攻撃に対する深層防御のために推奨されます。

Apacheのようなカスタム外部プロキシを使用している場合は、localhostのアドレスや名前（localhost または127.0.0.1 ）を追加する必要があるかもしれません。プロキシから Workhorse に渡される潜在的な HTTP Host ヘッダ攻撃を軽減するために、外部プロキシにフィルタを追加する必要があります。

gitlab_rails['allowed_hosts'] = ['gitlab.example.com', '127.0.0.1', 'localhost']

関連するトピック

• なりすましの無効化
• LDAPサインインの設定
• スマートカード認証
• NGINXを以下のように設定します：
  • HTTPSの設定
  • HTTP リクエストを以下にリダイレクトします。HTTPS
  • デフォルトのポートと SSL 証明書の場所を変更
  • NGINXのリスンアドレスまたはアドレスの設定
  • カスタム NGINX 設定を GitLab サーバーブロックに挿入します。
  • NGINX設定にカスタム設定を挿入します
  • 有効にするnginx_status
• パッケージ化されていないウェブサーバーを使用
• パッケージ化されていないPostgreSQLデータベース管理サーバーの使用
• パッケージ化されていないRedisインスタンスの使用
• GitLab実行環境にENV varsを追加します。
• gitlab.yml とapplication.yml の設定の変更
• SMTP経由でアプリケーションメールを送信
• OmniAuthの設定（Google、Twitter、GitHubログイン）
• Pumaの設定を調整

トラブルシューティング

相対URLのトラブルシューティング

相対URL設定に移行した後、GitLabのアセットが壊れたように見える問題（画像がない、コンポーネントが反応しないなど）に気づいたら、GitLabで Frontend ラベルを付けてイシューを提起してください。

Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]

ユーザーのホームディレクトリを移動する際、runitサービスが停止しておらず、ホームディレクトリが手動で移動されていない場合、GitLabは再設定中にエラーになります：

account[GitLab user and group] (gitlab::users line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/account.rb line 51) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '8'
---- Begin output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
STDOUT:
STDERR: usermod: user git is currently used by process 1234
---- End output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
Ran ["usermod", "-d", "/var/opt/gitlab", "git"] returned 8

ホームディレクトリを移動する前に必ずrunit を停止してください。