Omnibus GitLab 설치 문제 해결

Tier: Free, Premium, Ultimate Offering: Self-Managed

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

더 많은 컨텍스트를 보려면 Joe Damato의 Packagecloud 댓글 및 그의 블로그 기사를 참조하세요.

다른 해결책으로는 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 플랫폼에서의 설치 시 알 수 없는 키 서명 경고

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은 apt 및 yum 리포지토리의 메타데이터를 서명하는 데 사용되는 GPG 키를 변경했습니다. 이러한 오류가 발생하면 일반적으로 리포지토리 메타데이터에 사용되는 현재 공개 키가 키링에 없기 때문입니다. 이 오류를 해결하려면 2020년 04월 06일 이후의 새 키를 가져오는 단계를 따르세요.

Reconfigure에서 오류가 표시됨: NoMethodError - undefined method '[]=' for nil:NilClass

sudo gitlab-ctl reconfigure를 실행했거나 패키지 업그레이드로 인해 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에 연결할 수 없음

GitLab, 또는 기타 번들된 서비스 (Registry 및 Mattermost)를 위해 /etc/gitlab/gitlab.rb에서 external_url을 지정하는 것을 시도하세요. 또한 방화벽 설정을 확인하세요. GitLab 서버의 포트 80(HTTP) 또는 443(HTTPS)가 닫혀 있을 수 있습니다.

GitLab, 혹은 다른 번들된 서비스 (Registry 및 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 계정을 만들 수 있습니다.

필요한 경우 /etc/gitlab/gitlab.rb의 다음 설정으로 GitLab에서 보내는 이메일의 ‘보낸이’ 필드를 수정할 수 있습니다. 

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 문제 진단 및 해결

Omnibus GitLab는 /etc/gitlab/gitlab.rb에서의 기본 경로 변경을 감지하고 올바른 파일 컨텍스트를 적용해야합니다.

참고: GitLab 16.10 버전 이상에서 관리자는 SELinux 문제를 자동으로 해결하도록 gitlab-ctl apply-sepolicy을 시도할 수 있습니다. 런타임 옵션에 대해서는 gitlab-ctl apply-sepolicy --help을 참고하십시오.

사용자 지정 데이터 경로 구성을 사용하는 설치의 경우, 관리자는 SELinux 문제를 수동으로 해결해야 할 수 있습니다.

데이터 경로는 gitlab.rb를 통해 변경될 수 있지만, 일반적인 상황에서는 symlink 경로를 사용하기 때문에 주의가 필요합니다. symlink 경로는 Gitaly 데이터 경로와 같은 모든 시나리오에서 지원되지 않기 때문에 관리자는 주의해야 합니다.

예를 들어, 기본 데이터 디렉토리로 /var/opt/gitlab 대신에 /data/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”가 활성화되지 않은 경우에도, 오픈SSH 데몬은 SSH 키로 식별했을 때 Git 사용자의 인증을 방지합니다. 안전한 대안은 /etc/shadow에서 '!'를 '*'로 대체하여 암호를 잠금 해제하는 것입니다. 그러나 Git 사용자는 현재 사용자의 비밀번호를 입력해야 하는 제한된 셸에서 실행되기 때문에 암호를 변경할 수 없습니다. 사용자가 '*'와 일치하는 암호를 입력할 수 없기 때문에 계정에 아직 암호가 없는 상태입니다.

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.

수동으로 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에서 이러한 오류가 발생할 수 있습니다. 이를 해결하려면 /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 인스턴스가 동시 연결의 제한을 초과하려고 시도하고 있다는 것을 의미합니다.

이 문제를 해결하려면 다음 두 가지 옵션이 있습니다:

  • 최대 연결 수 값을 증가시키기:

    1. /etc/gitlab/gitlab.rb를 편집하십시오. 

      postgresql['max_connections'] = 600

    2. GitLab을 재구성하십시오. 

      sudo gitlab-ctl reconfigure

  • 또는 PgBouncer를 사용해볼 수 있습니다. PgBouncer는 PostgreSQL을 위한 커넥션 풀러입니다.

GLIBC 버전에 대한 Reconfigure 오류 

$ 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)

서버의 OS 릴리스가 설치한 Omnibus 패키지와 다른 경우 발생할 수 있습니다. 사용 중인 운영 체제에 맞는 Omnibus GitLab 패키지를 다운로드하고 설치했는지 다시 확인하세요.

Reconfigure에서 Git 사용자 생성 실패

sudo gitlab-ctl reconfigure를 Git 사용자로 실행한 경우 발생할 수 있습니다. 다른 사용자로 전환하세요.

중요한 점은 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'

이는 비가상화된 기계에서는 발생하기 힘들지만, 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'

이 오류는 가상 머신에서만 발생하며 권장되는 해결 방법은 호스트에서 값을 설정하는 것입니다. 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가 세 번 실패합니다: 

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

root 액세스 없이 Omnibus GitLab를 설치할 수 없음

가끔 사람들이 root 액세스 없이 GitLab을 설치할 수 있는지 묻습니다. 이는 여러 가지 이유로 문제가 됩니다.

.deb 또는 .rpm 설치

우리의 지식으로는 Debian이나 RPM 패키지를 권한이 없는 사용자로 설치하는 깔끔한 방법이 없습니다. Omnibus GitLab RPM을 설치할 수 없습니다. Omnibus 빌드 프로세스는 소스 RPM을 생성하지 않기 때문입니다.

80 및 443 포트에서의 번거로움 없는 호스팅

GitLab을 배포하는 가장 일반적인 방법은 GitLab과 동일한 서버에서 웹 서버(NGINX/Apache)를 실행하여 웹 서버가 특권이 필요한(1024번 미만) TCP 포트에 대해 수신 대기하도록 하는 것입니다. Omnibus GitLab에서는 이를 편리하게 제공하기 위해 특권 프로세스로 master 프로세스를 실행해야 하는 자동 구성된 NGINX 서비스를 번들로 제공합니다.

이것이 문제가 되는 경우 GitLab을 설치하는 관리자는 번들된 NGINX 서비스를 비활성화할 수 있지만, 이는 응용 프로그램 업데이트 중에 NGINX 구성에 대한 부담이 생기게 되므로 이에 대한 책임이 감소합니다.

Omnibus 서비스 간 격리

Omnibus GitLab에 포함된 서비스(GitLab 자체, NGINX, PostgreSQL, Redis, Mattermost)는 Unix 사용자 계정을 사용하여 서로 격리됩니다. 이러한 사용자 계정을 만들고 관리하려면 루트 액세스가 필요합니다. 기본적으로 Omnibus GitLab은 gitlab-ctl reconfigure 중에 필요한 Unix 계정을 생성하지만, 이 동작은 비활성화할 수 있습니다.

원칙적으로 Omnibus GitLab은 각 응용 프로그램에 고유한 runit(runsvdir), PostgreSQL 및 Redis 프로세스를 할당한다면 GitLab과 Mattermost를 위해 단 2개의 사용자 계정으로 충분할 수 있습니다. 하지만 이러한 변경은 gitlab-ctl reconfigure Chef 코드에 중대한 변화를 일으키며, 기존의 Omnibus GitLab 설치에 중대한 업그레이드 고통을 일으킬 수 있습니다. (아마도 /var/opt/gitlab 디렉토리 구조를 재배열해야 할 것입니다.)

성능 향상을 위한 운영 체제 조정

gitlab-ctl reconfigure 중에는 PostgreSQL 성능을 개선하고 연결 제한을 늘리기 위해 여러 sysctl 조정을 설정하고 설치합니다. 이는 루트 액세스 권한이 필요합니다.

gitlab-rake assets:precompile이 ‘Permission denied’로 실패하는 경우

일부 사용자가 omnibus 패키지에서 gitlab-rake assets:precompile을 실행할 수 없다고 보고했습니다. 이에 대한 간결한 해답은 다음과 같습니다: 해당 명령을 실행하지 마십시오. 이것은 소스에서 GitLab을 설치하는 경우에만 해당하는 명령입니다.

GitLab 웹 인터페이스는 CSS 및 JavaScript 파일, Ruby on Rails 용어로는 ‘assets’라고 불리는 파일을 사용합니다. 이 파일들은 상위 GitLab 리포지토리에서 개발자 친화적인 방식으로 저장됩니다. 하지만 GitLab 사용자는 GitLab이 느려지지 않기를 원하기 때문에 일반적으로 이러한 파일들을 개발자 친화적인 형식으로 유지하고 싶어하지 않을 것입니다. 이것이 rake assets:precompile 스크립트가 필요한 이유입니다.

당신이 Omnibus 패키지를 사용하여 GitLab을 설치하는 경우, 변환된 에셋은 이미 존재하기 때문에 rake assets:precompile을 실행할 필요가 없습니다.

gitlab-rake assets:precompile이 권한 오류로 실패하는 경우, 이것은 보안 측면에서 정당한 이유로 실패한 것입니다. 에셋을 쉽게 다시 쓸 수 없게 되면, 공격자가 당신의 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
# 사용자 및 경로는 gitlab.rb의 user['username'], user['group'], gitlab_rails['dir'] 기본 설정을 변경했다면 다를 수 있습니다.
sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

‘Short read or OOM loading DB’ 오류

이전 Redis 세션을 정리해 보세요.

Apt 오류 ‘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이 해당 인증서에 액세스할 수 있는지 확인하십시오. 이를 하지 않으면 GitLab이 내부 서비스(예: GitLab Shell)에 연결할 때 다음과 같은 오류가 발생할 수 있습니다: 

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

이러한 오류를 수정하려면 Custom Public Certificates 설치 섹션을 참조하십시오.

error: 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이 프록시를 사용하는 환경에서 GitLab 설정을 했고, 패키지에 의해 기본 프록시 헤더가 환경에 맞지 않게 설정되어 있는 것으로 보입니다.

자세한 내용은 NGINX 문서의 기본 프록시 헤더 섹션을 변경하여 기본 헤더를 재정의하는 방법을 참조하십시오.

CSRF 토큰 신뢰성을 확인할 수 없음 422 Unprocessable 완료

아마도 GitLab이 프록시를 사용하는 환경에서 GitLab 설정을 했고, 패키지에 의해 기본 프록시 헤더가 환경에 맞지 않게 설정되어 있는 것으로 보입니다.

자세한 내용은 NGINX 문서의 기본 프록시 헤더 섹션을 변경하여 기본 헤더를 재정의하는 방법을 참조하십시오.

확장 프로그램이 없음 pg_trgm

GitLab에서는 PostgreSQL 확장 프로그램 ‘pg_trgm’을 필요로 합니다. 번들된 데이터베이스를 사용하는 옴니버스 GitLab 패키지를 사용하는 경우, 확장 프로그램은 업그레이드할 때 자동으로 활성화될 것입니다.

그러나 외부(패키지되지 않은) 데이터베이스를 사용하는 경우, 확장 프로그램을 수동으로 활성화해야 합니다. 옴니버스 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

도커를 사용하는 경우, 먼저 컨테이너에 액세스한 다음 위의 명령을 실행한 후 컨테이너를 다시 시작해야 합니다.

  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에서 버킷 크기를 두 배로 늘려야 합니다. 

nginx['server_names_hash_bucket_size'] = 128

변경 사항이 적용되도록 sudo gitlab-ctl reconfigure를 실행하십시오.

NFS root_squash로 인해 ‘root’는 chown을 할 수 없어서 Reconfigure에 실패함 

$ 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 서버에서 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 시스템의 자동 감지를 건너뜁니다. 그러나 non-Docker 컨테이너(containerd, cri-o 등)에서는 해당 파일이 존재하지 않으며 패키지는 sysvinit으로 되돌아가며 이는 설치에 문제를 일으킬 수 있습니다. 이를 방지하기 위해 사용자는 gitlab.rb 파일에 다음 설정을 추가하여 명시적으로 init 데몬 감지를 비활성화할 수 있습니다. 

package['detect_init'] = false

이 구성을 사용하는 경우, runsvdir-start 명령을 사용하여 gitlab-ctl reconfigure를 실행하기 전에 runit 서비스를 시작해야 합니다. 

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

AWS Cloudformation 사용 시 gitlab-ctl reconfigure가 중단되는 문제

기본적으로 GitLab systemd 유닛 파일은 multi-user.target을 After 및 WantedBy 필드 양쪽에 사용합니다. 이는 서비스가 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
# 예시 IPv4 출력: 192.168.1.1 gitlab.example.com
# 예시 IPv6 출력: 2002:c0a8:0101::c0a8:0101 gitlab.example.com

getent hosts localhost
# 예시 IPv4 출력: 127.0.0.1 localhost
# 예시 IPv6 출력: ::1 localhost

만약 IPv6 주소 형식이 반환된다면, 네트워크 인터페이스에서 IPv6 프로토콜 지원(키워드 ipv6)이 활성화되어 있는지 확인하십시오. 

ip addr # 이전의 운영 체제에서는 'ifconfig'을 사용

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에서 다음과 같은 문제가 발생할 수 있습니다:

  • 프로젝트의 Settings > CI/CD 페이지를 열 수 없음.
  • 러너가 작업을 수행하지 않으며 오류 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 리포지토리를 미러링하는 것에 실패함

Pulp 또는 Red Hat Satellite을 사용하여 GitLab Omnibus의 yum 리포지토리를 직접 미러링하려고 하면 동기화하지 못합니다. 다양한 소프트웨어에 따라 다른 오류가 발생합니다.

  • Pulp 2 또는 Satellite 6.10 미만에서 "잘못된 리포지토리: filelists.xml과 다른.xml에 포함된 패키지 집합이 다르게 지정되어 있음" 오류가 발생합니다.
  • Satellite 6.10에서 "pkgid" 오류가 발생합니다.
  • Pulp 3 또는 Satellite 6.10 이상에서는 리포지토리 메타데이터만 동기화되는 것으로 보입니다.

이 동기화 오류는 GitLab yum 미러 리포지토리의 메타데이터에 문제가 있어 발생합니다. 이 메타데이터에는 보통 리포지토리의 각 RPM 파일에 대한 파일 목록을 포함하는 filelists.xml.gz 파일이 포함됩니다. 그러나 GitLab yum 미러 리포지토리는 크기 문제를 해결하기 위해 이 파일을 대부분 비워 둡니다.

각 GitLab RPM에는 방대한 수의 파일이 포함되어 있으며, 이를 리포지토리의 많은 RPM과 곱한다면 파일 크기가 매우 커질 것입니다. 저장 및 빌드 제한 때문에 파일을 생성하지만 채우지는 않습니다. 이 빈 파일로 인해 Pulp 및 RedHat Satellite(사용하는 것이 Pulp)의 리포지토리 미러링이 실패합니다.

자세한 내용은 이슈 2766을 참조하세요.

문제 해결 방법

이 문제를 해결하려면 다음을 수행하세요:

  1. reposync 또는 createrepo와 같은 대안적 RPM 리포지토리 미러링 도구를 사용하여 공식 GitLab yum 리포지토리의 로컬 복사본을 만드세요. 이러한 도구를 사용하면 로컬 데이터에서 리포지토리 메타데이터를 다시 생성하게 되며, 완전히 채워진 filelists.xml.gz 파일도 만들어집니다.
  2. Pulp 또는 Satellite를 로컬 미러에 맞추세요.

로컬 미러 예시

다음은 로컬 미러링하는 방법의 예시입니다:

  • Apache를 리포지토리용 웹 서버로 사용합니다.
  • reposync 및 createrepo를 사용하여 GitLab 리포지토리를 로컬 미러에 동기화합니다. 그 후 이 로컬 미러는 Pulp 또는 RedHat Satellite의 소스로 사용할 수 있습니다. Cobbler와 같은 다른 도구를 사용할 수도 있습니다.

이 예시에서:

  • 로컬 미러는 RHEL 8, Rocky 8, 또는 AlmaLinux 8 시스템에서 실행됩니다.
  • 웹 서버의 호스트 이름은 mirror.example.com입니다.
  • Pulp 3는 로컬 미러에서 동기화됩니다.
  • 미러링은 GitLab Enterprise Edition 리포지토리입니다.

Apache 서버 생성 및 구성

다음 예시는 기본 Apache 2 서버를 설치하고 구성하여 하나 이상의 Yum 리포지토리 미러를 호스트하는 방법을 보여줍니다. 웹 서버의 구성 및 보안에 대한 자세한 내용은 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(약 1GB씩)이 다운로드됩니다.

  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 버전이 출시될 때마다 로컬 미러를 정기적으로 업데이트해야 합니다. 이를 위한 한 가지 방법은 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 리포지토리와 원격 생성: 

    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의 패키지 리포지토리에서 패키지를 설치하는 경우 클라이언트는 d20rj4el6vk...cloudfront.net로의 리디렉션을 수신하고 이를 따를 것입니다. 공기차단 환경의 서버는 다음과 같은 오류를 받을 수 있습니다: 

E: connection refused to d20rj4el6vkp4c.cloudfront.net 443

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

이 문제를 해결하려면 세 가지 옵션이 있습니다:

  • 도메인으로 화이트리스트를 지정할 수 있는 경우 방화벽 설정에 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 SSH를 사용하여 풀이나 푸시하는 경우 다음과 같은 오류가 발생할 수 있습니다:

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

git 사용자의 프로세스 수가 제한을 초과하면 이러한 오류가 발생할 수 있습니다.

이 문제를 해결하려면 다음을 수행합니다:

  1. /etc/security/limits.conf 파일에서 git 사용자의 nproc 설정을 증가시킵니다. 일반적으로 gitlab-shell은 GitLab Rails 노드에서 실행됩니다.
  2. 풀이나 푸시 Git 명령을 다시 시도합니다.

SSH 연결 손실 후 설치가 중단되는 경우

원격 가상 머신에 GitLab을 설치하고 SSH 연결이 끊기면 설치가 좀비 dpkg 프로세스로 중단될 수 있습니다. 이 경우 다음을 수행하여 설치를 재개합니다:

  1. 연관된 apt 프로세스의 프로세스 ID를 찾기 위해 top을 실행합니다. 이 프로세스는 dpkg 프로세스의 부모입니다.
  2. sudo kill <PROCESS_ID> 명령을 사용하여 apt 프로세스를 종료합니다.
  3. 새로 설치하는 경우에만 sudo gitlab-ctl cleanse를 실행합니다. 이 단계는 기존 데이터를 지우므로 업그레이드에서는 사용하면 안 됩니다.
  4. sudo dpkg configure -a를 실행합니다.
  5. 외부 URL 및 없는 구성을 포함하여 gitlab.rb 파일을 편집합니다.
  6. sudo gitlab-ctl reconfigure를 실행합니다.

GitLab을 다시 구성할 때 발생하는 Redis 관련 오류

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가 redis-cli로 연결을 시도하는 동안 재시작되거나 종료된 경우가 있을 수 있다는 것을 나타냅니다. 이 오류를 방지하려면 다음 명령을 실행합니다: 

sudo gitlab-ctl reconfigure

실패하는 경우 gitlab-ctl tail redis의 출력을 확인하고 redis-cli를 실행해 봅니다.