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에서 gpgkey 키워드를 무시하는 zypper의 알려진 버그입니다. Packagecloud의 최신 버전에서는 이에 대한 개선점이 있을 수 있지만 현재 사용자는 패키지 설치에 매뉴얼으로 동의해야 합니다.

따라서 openSUSE 또는 SLES 시스템에서 이러한 경고가 표시되면 설치를 계속해도 안전합니다.

apt/yum에서 GPG 서명에 대한 경고

이미 GitLab 리포지터리가 구성되어 있고, apt-get update, apt-get install 또는 yum install을 실행하고 다음과 같은 오류 메시지를 보았다면: 

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

또는 

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

이는 2020년 4월에 GitLab이 apt 및 yum 리포지터리의 메타데이터에 사용된 GPG 키를 변경한 결과입니다. 이 오류를 보게 된다면, 일반적으로 현재 사용 중인 키링에 리포지터리 메타데이터를 서명한 현재 사용 중인 공개 키가 없음을 의미합니다. 이 오류를 해결하려면 2020년 4월 6일 이후의 새 키를 가져오는 단계를 따르십시오.

재구성 실행 시 오류 표시: 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에 액세스할 수 없음

GitLab의 외부 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"
note
external_url과 값 사이에 등호(=)를 추가하지 마십시오.

이메일이 전달되지 않음

이메일 전송을 테스트하려면 기존에 사용 중인 이메일이 아닌 이메일을 사용하여 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를 사용하여 보안 컨텍스트를 영구적으로 설정할 수 있습니다. RPM 기반 운영 체제용의 RPM 패키지에 policycoreutils-python 런타임 의존성이 추가되어 semanage 명령이 사용 가능한지 확인합니다.

SELinux 문제 진단 및 해결

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

note
GitLab 16.10부터 관리자는 SELinux 문제를 자동으로 해결하기 위해 gitlab-ctl apply-sepolicy를 시도할 수 있습니다. 런타임 옵션은 gitlab-ctl apply-sepolicy --help을 참조하십시오.

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

데이터 경로는 gitlab.rb를 통해 변경될 수 있지만 일반적인 시나리오에서는 symlink 경로를 사용해야 하는 경우가 있습니다. Gitaly 데이터 경로와 같이 모든 시나리오에서 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.

매뉴얼으로 PostgreSQL이 할당하려는 공유 메모리 양을 /etc/gitlab/gitlab.rb에서 낮출 수 있습니다. 

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 인스턴스가 동시 연결 수의 제한을 초과하려고 한 것입니다.

이 문제를 해결하기 위해 두 가지 옵션이 있습니다:

  • 최대 연결 수 값을 늘리는 것:

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

      postgresql['max_connections'] = 600

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

      sudo gitlab-ctl reconfigure

  • 또는 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)

이것은 설치한 Omnibus GitLab 패키지가 서버의 운영 체제와 다른 버전으로 빌드된 경우 발생할 수 있습니다. 시스템의 운영 체제에 맞는 올바른 Omnibus GitLab 패키지를 다운로드하고 설치했는지 다시 한번 확인하십시오.

Reconfigure가 Git 사용자를 만들지 못하면

sudo gitlab-ctl reconfigure를 Git 사용자로 실행하면 발생할 수 있습니다. 다른 사용자로 전환하십시오.

특히, Git 사용자나 Omnibus GitLab에서 사용하는 다른 사용자에게 sudo 권한을 부여하지 마십시오. 시스템 사용자에게 불필요한 권한을 부여하면 시스템의 보안이 약화될 수 있습니다.

sysctl로 커널 매개변수를 수정하지 못한 경우

sysctl이 커널 매개변수를 수정하지 못하면 다음과 같은 스택 트레이스 오류가 발생할 수 있습니다.

이것은 가상화되지 않은 머신에서 발생할 가능성이 낮지만, OpenVZ 같은 가상화된 VPS에서는 필요한 모듈이 활성화되어 있지 않을 수 있거나 컨테이너가 커널 매개변수에 액세스할 수 없는 경우에 발생할 수 있습니다.

sysctl이 오류를 반환한 모듈을 활성화하는 것을 시도해 보십시오.

이 문제에 대한 보고된 해결책이 있으며, 이것은 실패를 무시하는 스위치를 제공하여 GitLab의 내부 레시피를 편집하는 것을 필요로 합니다. 오류를 무시하면 GitLab 서버의 성능에 예기치 않은 부작용이 발생할 수 있으므로 권장되지 않습니다.

이 오류의 다른 변형은 파일 시스템이 읽기 전용이며 다음과 같은 스택 트레이스를 보여주는 경우도 있습니다.

이 오류는 가상 머신에서만 발생하며, 권장하는 해결책은 호스트에서 값을 설정하는 것입니다. 가상 머신의 파일 /opt/gitlab/embedded/etc/90-omnibus-gitlab.conf 안에 GitLab에 필요한 값들을 찾을 수 있습니다. 이러한 값을 호스트 OS의 /etc/sysctl.conf 파일에 설정한 후 호스트에서 cat /etc/sysctl.conf /etc/sysctl.d/*.conf | sysctl -e -p -를 실행한 다음 가상 머신 내에서 gitlab-ctl reconfigure를 실행해 보십시오. GitLab은 이미 필요한 설정으로 커널이 실행 중인 것으로 감지할 것이며 오류를 발생시키지 않을 것입니다.

다른 줄에서 이 프로세스를 반복해야 할 수 있습니다. 예를 들어, 오류가 발생한 각각의 파일에 다음과 같은 내용을 추가한 후 /etc/sysctl.conf에 다음과 같은 내용을 추가한 후 3번의 실패 후 같은 오류 세트가 있는 경우, 파일보다는 쉽게 Chef 출력에서 행을 찾는 것이 좋을 것입니다. 

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

루트 액세스 없이 Omnibus GitLab을 설치할 수 없음

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

.deb 또는 .rpm 설치

우리의 알기로는 데비안이나 RPM 패키지를 특권 없는 사용자로 설치하는 깨끗한 방법은 없습니다. Omnibus GitLab RPM은 Omnibus 빌드 프로세스가 소스 RPM을 생성하지 않기 때문에 설치할 수 없습니다.

80 및 443 포트에서의 무료 호스팅

GitLab을 배포하는 가장 일반적인 방법은 웹 서버(NGINX/Apache)를 GitLab과 동일한 서버에서 실행하고, 웹 서버를 특권있는(1024 미만) TCP 포트에서 수신하도록 설정하는 것입니다. Omnibus GitLab에서는 이 편의성을 제공하기 위해 자동으로 구성된 NGINX 서비스를 번들로 제공하여 root로 마스터 프로세스를 실행하여 포트 80과 443을 열어야 합니다.

이것이 문제가 되면 GitLab을 설치하는 관리자는 번들된 NGINX 서비스를 비활성화할 수 있지만, 이는 GitLab 업데이트 동안 NGINX 구성을 GitLab과 일치시키는 부담을 지게 합니다.

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 스크립트가 개발자 친화적인 형식에서 최종 사용자 친화적인(간결하고 빠른) 형식으로 assets를 변환하는 GitLab 설치 프로세스의 일부인 이유입니다.

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

gitlab-rake assets:precompile이 권한 오류로 실패하는 경우 보안 측면에서 해당 assets을 쉽게 다시 작성할 수 없는 사실은 공격자가 당신의 GitLab 서버를 사용하여 방문자에게 악의적인 JavaScript 코드를 제공하기 어렵게 만듭니다.

만약 커스텀 JavaScript 또는 CSS 코드로 GitLab을 실행하려면 아마도 GitLab을 소스에서 실행하거나 자체 패키지를 빌드하는 것이 좋을 것입니다.

만약 정말로 무엇을 하고 있는지 이해하고 있다면, 다음과 같이 gitlab-rake gitlab:assets:compile을 실행할 수 있습니다. shell 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 세션을 정리해보세요.

CSRF 토큰 진위성을 확인할 수 없음 완료됨 422 불가처리됨

아마도 당신이 GitLab를 프록시가 앞에 있는 환경에서 설정한 것으로 생각됩니다. 기본적으로 패키지에 설정된 프록시 헤더가 당신의 환경에 대해 올바르지 않을 수 있습니다.

자세한 내용은 NGINX 문서의 기본 프록시 헤더 섹션을 변경하려면 참조하세요.

확장 프로그램이 누락된 pg_trgm

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

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

  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’가 chown할 수 없는 Reconfigure 실패

이는 NFS로 마운트된 디렉터리가 root_squash 모드로 구성된 경우 발생할 수 있습니다. Reconfigure는 디렉터리의 소유권을 제대로 설정할 수 없습니다. NFS 서버에서 no_root_squash 모드로 다시 내보내거나 리포지터리 디렉터리 관리 비활성화를 해야 합니다.

gitlab-runsvdir가 시작되지 않음

이것은 systemd를 사용하는 운영 체제(e.g. 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 파일의 존재 여부를 감지하여 초기화 시스템을 자동으로 탐지하지만, 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 유닛 파일은 기본적으로 After 및 WantedBy 필드 모두에 대해 multi-user.target를 사용합니다. 이는 서비스가 remote-fs와 network 타겟 이후에 실행되도록 하기 위한 것입니다. 그리고 따라서 GitLab이 올바르게 기능하도록 합니다.

그러나 이것은 AWS Cloudformation에서 사용되는 cloud-init의 자체 유닛 순서 지정과 나쁜 상호 작용을 합니다.

이를 해결하려면 사용자는 package['systemd_wanted_by'] 및 package['systemd_after'] 설정을 gitlab.rb에서 사용하여 올바른 순서를 지정하고 sudo gitlab-ctl reconfigure을 실행해야 합니다. reconfigure이 완료되면 변경 사항이 적용되도록 gitlab-runsvdir 서비스를 다시 시작해야 합니다. 

sudo systemctl restart gitlab-runsvdir

Errno::EAFNOSUPPORT: 프로토콜에서 지원하지 않는 주소 체계입니다 - 소켓(2)

GitLab을 시작할 때 다음과 유사한 오류가 발생하는 경우: 

FATAL: Errno::EAFNOSUPPORT: 프로토콜에서 지원하지 않는 주소 체계입니다 - 소켓(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에서 다음과 같은 문제가 발생할 수 있습니다:

  • 프로젝트의 설정 > CI/CD 페이지를 열 수 없음.
  • Runner가 작업을 가져가지 않고 오류 500으로 실패함.

이 경우, production.log에 다음과 같은 오류가 포함됩니다: 

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

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

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

이 문제를 해결하려면 external_url에서 밑줄 사용을 피하십시오. 이에 대한 오픈 이슈가 있습니다: 밑줄을 포함하는 external_url 설정은 GitLab CI/CD 기능이 손상됨.

timeout: run: /opt/gitlab/service/gitaly 오류로 업그레이드 실패

패키지 업그레이드가 다음과 같은 오류로 실패하는 경우, 모든 Gitaly 프로세스가 중지되었는지 확인하고 sudo gitlab-ctl reconfigure를 다시 실행하십시오. 

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

자세한 내용은 이슈 341573를 참조하십시오.

GitLab 재설치 시 재구성이 멈추는 문제

알려진 문제로, GitLab을 제거한 후 다시 설치하려고 시도하면 ruby_block[wait for logrotate service socket] action run에서 재구성 프로세스가 멈추는 것을 볼 수 있습니다. 이 문제는 GitLab을 제거할 때 systemctl 명령 중 하나가 실행되지 않았을 때 발생합니다.

이 문제를 해결하기 위해:

  • GitLab을 제거할 때 모든 단계를 따랐는지 확인하고 필요한 경우에는 해당 단계를 수행하십시오.
  • 이슈 7776에 있는 해결책을 따르십시오.

Pulp 또는 Red Hat Satellite로 GitLab yum 리포지터리를 미러링하는 경우 실패

Pulp 또는 Red Hat Satellite을 사용하여 https://packages.gitlab.com/gitlab/에 위치한 Omnibus GitLab yum 리포지터리를 미러링할 때, 동기화할 때 실패합니다. 서로 다른 소프트웨어로 인해 다른 오류가 발생합니다:

  • Pulp 2 또는 Satellite < 6.10에서 "Malformed repository: metadata is specified for different set of packages in filelists.xml and in other.xml" 오류가 발생합니다.
  • Satellite 6.10에서 "pkgid" 오류가 발생합니다.
  • Pulp 3 또는 Satellite > 6.10에서는 보고자 하는 것으로 보이지만 리포지터리 메타데이터만 동기화됩니다.

이러한 동기화 실패는 GitLab yum 미러 리포지터리의 메타데이터 문제로 인해 발생합니다. 이 메타데이터에는 보통 리포지터리의 모든 RPM에 대한 파일 디렉터리을 포함하는 filelists.xml.gz 파일이 포함되어 있습니다. GitLab yum 리포지터리는 이 파일을 대부분 비워 두어 리포지터리의 모든 RPM에 대한 방대한 파일 디렉터리이 큰 filelists.xml.gz 파일이 생성될 경우 발생할 수 있는 크기 문제를 해결합니다.

각 GitLab RPM에는 많은 파일이 포함되어 있으며, 리포지터리의 많은 RPM으로 곱해지면 거대한 filelists.xml.gz 파일이 생성됩니다. 저장 및 빌드 제한으로 인해 이 파일을 작성하지 않고 그대로 둡니다. 빈 파일은 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은 로컬 미러에서 동기화합니다.

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 버전이 릴리스될 때 새로운 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. Pulp repository 및 remote를 생성합니다: 

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

  2. 리포지터리를 동기화합니다: 

    pulp rpm repository sync --name gitlab-ee

    이 명령은 GitLab 리포지터리의 변경 사항을 로컬 미러에 업데이트하기 위해 주기적으로 실행되어야 합니다.

리포지터리가 동기화된 후 게시 및 배포를 만들어 사용할 수 있습니다. 세부 정보는 https://docs.pulpproject.org/pulp_rpm/을 참조하십시오.

오류: E: connection refused to d20rj4el6vkp4c.cloudfront.net 443

packages.gitlab.com에서 제공되는 패키지 리포지터리에 호스팅된 패키지를 설치할 때 클라이언트는 CloudFront 주소 d20rj4el6vkp4c.cloudfront.net로의 리디렉션을 받고 따릅니다. 공기가락 환경의 서버는 다음과 같은 오류를 받을 수 있습니다: 

E: connection refused to d20rj4el6vkp4c.cloudfront.net 443

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

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

  • 도메인을 허용할 수 있는 경우 방화벽 설정에 엔드포인트 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

이 값이 증가되어야 하며, 이를 위해 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 명령을 다시 시도합니다.