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 키를 변경했기 때문입니다. 이 오류가 발생하면, 현재 키링에 저장소 메타데이터를 서명하는 데 사용되는 공개 키가 없다는 것을 의미합니다. 이 오류를 수정하려면 새 키를 가져오는 단계를 따르세요.

Reconfigure에서 오류 발생: NoMethodError - undefined method '[]=' for nil:NilClass

sudo gitlab-ctl reconfigure를 실행했거나 패키지 업그레이드로 인해 재구성이 트리거되어 비슷한 오류가 발생했습니다:

 ================================================================================
 Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
 ================================================================================

NoMethodError
-------------
undefined method '[]=' for nil:NilClass

Cookbook Trace:
---------------
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/config.rb:21:in 'from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:26:in 'from_file'

Relevant File Content:

이 오류는 /etc/gitlab/gitlab.rb 구성 파일에 유효하지 않거나 지원되지 않는 구성이 포함되어 있을 때 발생합니다. 오타가 없거나 구성 파일에 구식 구성이 포함되지 않았는지 다시 확인하세요.

sudo gitlab-ctl diff-config를 사용하여 최신 사용 가능한 구성을 확인하거나 최신 gitlab.rb.template를 확인할 수 있습니다.

브라우저에서 GitLab에 연결할 수 없음

/etc/gitlab/gitlab.rb에서 external_url을 지정해보세요. 방화벽 설정도 확인하세요; 포트 80(HTTP) 또는 443(HTTPS)이 GitLab 서버에서 닫혀 있을 수 있습니다.

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 인스턴스에서 사용되지 않는 이메일로 새 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를 사용하여 컨텍스트를 영구적으로 설정합니다. policycoreutils-python의 런타임 종속성이 RHEL 기반 운영 체제의 RPM 패키지에 추가되어 semanage 명령을 사용할 수 있도록 보장합니다.

SELinux 문제 진단 및 해결

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

note
GitLab 16.10 이후, 관리자는 gitlab-ctl apply-sepolicy를 사용하여 SELinux 문제를 자동으로 수정할 수 있습니다. 실행 옵션에 대해서는 gitlab-ctl apply-sepolicy --help를 참조하세요.

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

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

예를 들어, /data/gitlab가 기본 데이터 디렉터리로서 /var/opt/gitlab을 대체하는 경우, 다음은 보안 컨텍스트를 수정합니다:

sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/authorized_keys
sudo restorecon -Rv /data/gitlab/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-shell/config.yml
sudo restorecon -Rv /data/gitlab/gitlab-shell/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-rails/etc/gitlab_shell_secret
sudo restorecon -Rv /data/gitlab/gitlab-rails/
sudo semanage fcontext --list | grep /data/gitlab/

정책이 적용된 후, 환영 메시지를 받아 SSH 접근이 정상 작동하는지 확인할 수 있습니다:

ssh -T git@gitlab-hostname

모든 시스템

Git 사용자는 기본적으로 잠긴 비밀번호로 생성되며, 이는 /etc/shadow에서 '!'로 표시됩니다. “UsePam yes”가 활성화되지 않은 경우, OpenSSH 데몬은 SSH 키가 있더라도 Git 사용자 인증을 차단합니다. 대안 안전 솔루션은 /etc/shadow에서 '!'를 '*'로 변경하여 비밀번호를 해제하는 것입니다. Git 사용자는 제한된 셸에서 실행되므로 비밀번호를 변경할 수 없습니다. 비슈퍼유저의 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 인스턴스가 동시 연결 수의 한도를 초과하려고 시도하고 있다는 의미입니다.

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

  • 최대 연결 수 값을 늘립니다:

    1. /etc/gitlab/gitlab.rb를 편집합니다:

      postgresql['max_connections'] = 600

    2. GitLab을 재구성합니다:

      sudo gitlab-ctl reconfigure

  • 또는 PostgreSQL용 연결 풀러인 PgBouncer를 사용할 것을 고려할 수 있습니다.

재구성이 GLIBC 버전에 대해 불평합니다 

$ gitlab-ctl reconfigure

/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)
/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)

이 오류는 설치한 omnibus 패키지가 서버의 OS 릴리스와 다른 경우 발생할 수 있습니다. 올바른 Omnibus GitLab 패키지를 다운로드하고 설치했는지 다시 확인하세요.

재구성이 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'
---- 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에 다음과 같은 내용을 추가한 후 재구성이 실패할 수 있습니다:

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

Chef 출력에서 문제를 더 쉽게 찾을 수 있습니다. 파일(각 오류마다 다를 수 있음)보다 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

루트 접근 없이 Omnibus GitLab을 설치할 수 없습니다

가끔 사람들은 GitLab을 루트 접근 없이 설치할 수 있는지 질문합니다.

이것은 여러 가지 이유로 문제가 됩니다.

.deb 또는 .rpm 설치하기

우리가 아는 한, 비특권 사용자로 Debian 또는 RPM 패키지를 설치하는 깔끔한 방법은 없습니다. Omnibus GitLab RPM을 설치할 수 없으며, 그 이유는 Omnibus 빌드 프로세스가 소스 RPM을 생성하지 않기 때문입니다.

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

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

이것이 문제라면 GitLab을 설치하는 관리자는 번들 NGINX 서비스를 비활성화할 수 있지만, 이는 애플리케이션 업데이트 동안 GitLab과 함께 NGINX 구성을 유지할 책임이 그들에게 가게 됩니다.

Omnibus 서비스 간의 분리

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

원칙적으로 Omnibus GitLab은 GitLab과 Mattermost 각각에 대해 2개의 사용자 계정만 있으면 되지만, 각 애플리케이션에 자신의 runit(지속 작업 관리자), PostgreSQL 및 Redis 프로세스를 제공해야 합니다. 그러나 이는 gitlab-ctl reconfigure Chef 코드에서 주요 변경 사항이 필요하며, 모든 기존 Omnibus GitLab 설치에 중대한 업그레이드 문제를 일으킬 수 있습니다. (아마도 /var/opt/gitlab 아래의 디렉토리 구조를 재배열해야 할 것입니다.)

더 나은 성능을 위한 운영 체제 조정

gitlab-ctl reconfigure 중에 PostgreSQL 성능을 개선하고 연결 제한을 늘리기 위해 여러 sysctl 조정을 설정하고 설치합니다. 이는 루트 접근으로만 수행할 수 있습니다.

gitlab-rake assets:precompile이 ‘Permission denied’로 실패합니다

일부 사용자는 gitlab-rake assets:precompile를 실행하면 omnibus 패키지에서 작동하지 않는다고 보고합니다. 이에 대한 간단한 대답은: 해당 명령을 실행하지 마세요, 이는 소스에서 GitLab을 설치할 때만 필요합니다.

GitLab 웹 인터페이스는 Ruby on Rails에서 ‘자산’이라고 불리는 CSS 및 JavaScript 파일을 사용합니다. 업스트림 GitLab 저장소에서 이 파일들은 개발자가 읽고 편집하기 쉬운 방식으로 저장됩니다. GitLab의 일반 사용자로서 이러한 파일이 개발자 친화적인 형식으로 존재하는 것을 원하지 않습니다. 이는 GitLab을 느리게 만들기 때문입니다. 따라서 GitLab 설정 프로세스의 일환으로 자산을 개발자 친화적인 형식에서 최종 사용자 친화적인(압축된, 빠른) 형식으로 변환하는 것이 필요합니다; 이 것이 rake assets:precompile 스크립트의 용도입니다.

소스에서 GitLab을 설치할 때(이전에는 omnibus 패키지 없이 설치하는 유일한 방법이었습니다) GitLab을 업데이트할 때마다 GitLab 서버에서 자산을 변환해야 합니다. 사람들은 종종 이 단계를 간과했으며, 여전히 인터넷에는 사용자들이 서로 rake assets:precompile을 실행하라고 권장하는 게시물, 댓글 및 이메일이 존재합니다(현재 gitlab:assets:compile로 이름이 변경되었습니다). omnibus 패키지를 통해 설치할 경우 상황이 다릅니다: 패키지를 빌드할 때 자산을 이미 컴파일합니다. Omnibus 패키지로 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
# 사용자 및 경로는 gitlab.rb에서 user['username'], user['group'] 및 gitlab_rails['dir']의 기본값을 변경했다면 다를 수 있습니다.
sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

‘짧은 읽기 또는 OOM 로딩 DB’ 오류

오래된 Redis 세션 정리하기.

Apt 오류 ‘요청한 URL이 오류를 반환했습니다: 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)

이 변경이 필요한 이유에 대한 자세한 내용은 패키지 클라우드 블로그를 참조하세요.

자체 서명된 인증서 또는 사용자 지정 인증 기관 사용

사용자 지정 인증 기관이 있는 격리된 네트워크에서 GitLab을 설치하는 경우 또는 자체 서명된 인증서를 사용하는 경우, GitLab에서 인증서에 접근할 수 있는지 확인하세요. 그렇지 않으면 다음과 같은 오류가 발생합니다:

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

GitLab이 GitLab Shell과 같은 내부 서비스에 연결하려고 할 때 발생합니다.

이러한 오류를 수정하려면 사용자 지정 공개 인증서 설치 섹션을 참조하세요.

오류: proxyRoundTripper: XXX 실패: “net/http: 응답 헤더 대기 중 시간 초과”

GitLab Workhorse가 1분(기본값) 이내에 GitLab으로부터 응답을 받지 못하면 502 페이지를 제공하게 됩니다.

요청이 시간 초과될 수 있는 여러 가지 이유가 있으며, 예를 들어 사용자가 매우 큰 차이를 로딩하고 있을 수 있습니다.

/etc/gitlab/gitlab.rb 파일에서 값을 설정하여 기본 시간 초과 값을 늘릴 수 있습니다:

gitlab_workhorse['proxy_headers_timeout'] = "2m0s"

파일을 저장하고 GitLab 재구성을 통해 변경 사항을 적용하세요.

원하던 변경이 거부되었습니다

대부분의 경우, GitLab이 프록시 환경에서 설정되어 있으며 패키지에서 기본적으로 설정된 프록시 헤더가 환경에 맞지 않은 것입니다.

자세한 내용은 NGINX 문서의 기본 프록시 헤더 변경 섹션을 참조하여 기본 헤더를 오버라이드하는 방법을 알아보세요.

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

Docker를 사용하는 경우, 먼저 컨테이너에 접근한 후 위의 명령을 실행하고 마지막으로 컨테이너를 재시작해야 합니다.

  1. 컨테이너 접근하기:

    docker exec -it gitlab bash

  2. 위의 명령 실행하기

  3. 컨테이너 재시작하기:

    docker restart gitlab

Errno::ENOMEM: 백업 또는 업그레이드 중 메모리 할당 실패

GitLab은 오류 없이 실행하기 위해 2GB의 사용 가능한 메모리를 필요로 합니다. 2GB의 메모리를 설치하는 것만으로는 서버에서 다른 프로세스의 리소스 사용량에 따라 충분하지 않을 수 있습니다.

GitLab이 업그레이드나 백업을 실행하지 않을 때 정상적으로 실행된다면, 추가 스왑을 추가하면 문제를 해결할 수 있습니다. 정상 사용 중 스왑을 사용하는 서버를 보면 성능 향상을 위해 RAM을 추가할 수 있습니다.

NGINX 오류: ‘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’ cannot chown”으로 재구성 실패 

$ gitlab-ctl reconfigure

================================================================================
리소스 'ruby_block[directory resource: /gitlab-data/git-data]'에서 `run` 작업 실행 중 오류
================================================================================

Errno::EPERM
------------
'root'가 /gitlab-data/git-data의 소유권을 변경할 수 없습니다. NFS 마운트를 사용하는 경우 'no_root_squash' 모드에서 다시 내보내야 합니다.
허용되지 않는 작업 @ chown_internal - /gitlab-data/git-data

이는 root_squash 모드로 설정된 NFS를 사용하여 마운트된 디렉토리가 있는 경우 발생할 수 있습니다. 재구성이 디렉토리의 소유권을 제대로 설정할 수 없습니다. NFS 서버의 NFS 내보내기에서 no_root_squash를 사용하도록 전환해야 하거나 스토리지 디렉토리 관리 비활성화하여 권한을 직접 관리해야 합니다.

gitlab-runsvdir 시작 실패

이것은 systemd를 사용하는 운영 체제에 적용됩니다(예: Ubuntu 18.04+, CentOS 등).

gitlab-runsvdir는 basic.target이 아닌 multi-user.target에서 시작됩니다. GitLab을 업그레이드한 후 이 서비스를 시작하는 데 문제가 발생하면, 시스템이 multi-user.target에 필요한 모든 서비스를 제대로 부팅했는지 확인해야 합니다. 명령어는 다음과 같습니다:

systemctl -t target

모든 것이 제대로 작동한다면, 출력은 다음과 비슷하게 보여야 합니다:

UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
basic.target           loaded active active Basic System
cloud-config.target    loaded active active Cloud-config availability
cloud-init.target      loaded active active Cloud-init target
cryptsetup.target      loaded active active Encrypted Volumes
getty.target           loaded active active Login Prompts
graphical.target       loaded active active Graphical Interface
local-fs-pre.target    loaded active active Local File Systems (Pre)
local-fs.target        loaded active active Local File Systems
multi-user.target      loaded active active Multi-User System
network-online.target  loaded active active Network is Online
network-pre.target     loaded active active Network (Pre)
network.target         loaded active active Network
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target           loaded active active Paths
remote-fs-pre.target   loaded active active Remote File Systems (Pre)
remote-fs.target       loaded active active Remote File Systems
slices.target          loaded active active Slices
sockets.target         loaded active active Sockets
swap.target            loaded active active Swap
sysinit.target         loaded active active System Initialization
time-sync.target       loaded active active System Time Synchronized
timers.target          loaded active active Timers

LOAD   = 유닛 정의가 제대로 로드되었는지 여부를 나타냅니다.
ACTIVE = 고수준 유닛 활성화 상태, 즉 SUB의 일반화입니다.
SUB    = 저수준 유닛 활성화 상태, 값은 유닛 유형에 따라 다릅니다.

22개의 로드된 유닛이 나열되었습니다. --all을 전달하여 비활성화된 유닛도 확인하세요.
모든 설치된 유닛 파일을 보려면 'systemctl list-unit-files'를 사용하세요.

모든 줄은 loaded active active를 보여야 합니다. 다음의 줄과 같이 inactive dead가 보이면, 문제가 있을 수 있습니다:

multi-user.target      loaded inactive dead   start Multi-User System

systemd에 의해 대기 중인 작업을 확인하려면 다음을 실행하세요:

systemctl list-jobs

running 작업이 보이면, 서비스가 막혀 GitLab이 시작되는 것을 차단할 수 있습니다. 예를 들어, 일부 사용자는 Plymouth의 시작에 문제가 발생했습니다:

  1 graphical.target                     start waiting
107 plymouth-quit-wait.service           start running
  2 multi-user.target                    start waiting
169 ureadahead-stop.timer                start waiting
121 gitlab-runsvdir.service              start waiting
151 system-getty.slice                   start waiting
 31 setvtrgb.service                     start waiting
122 systemd-update-utmp-runlevel.service start waiting

이 경우 Plymouth를 제거하는 것을 고려하세요.

비-Docker 컨테이너에서의 init 데몬 감지

Docker 컨테이너에서는 GitLab 패키지가 /.dockerenv 파일의 존재를 감지하고
init 시스템의 자동 감지를 건너뜁니다. 그러나 비-Docker 컨테이너(예: containerd, cri-o 등)에서는
해당 파일이 존재하지 않으며, 패키지가 sysvinit로 되돌아가게 되어 설치에 문제가 발생할 수 있습니다.
이를 방지하기 위해 사용자는 gitlab.rb 파일에 다음 설정을 추가하여
init 데몬 감지를 명시적으로 비활성화할 수 있습니다:

package['detect_init'] = false

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

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

AWS Cloudformation 사용 시 gitlab-ctl reconfigure가 중단됨

기본적으로 GitLab systemd 유닛 파일은 After 및 WantedBy 필드에 대해 multi-user.target을 사용합니다.
이는 서비스가 remote-fs와 network 타겟 이후에 실행되도록 하여 GitLab이 정상적으로 작동하게 하기 위함입니다.

그러나 이것은 AWS Cloudformation에서 사용되는 cloud-init‘의
자체 유닛 순서와 잘 상호작용하지 않습니다.

이를 해결하기 위해 사용자는 gitlab.rb에서 package['systemd_wanted_by']와
package['systemd_after'] 설정을 사용하여 적절한 순서를 위한 값을 지정할 수 있으며,
sudo gitlab-ctl reconfigure를 실행해야 합니다. 재구성이 완료된 후에는
변경 사항이 적용되도록 gitlab-runsvdir 서비스를 재시작해야 합니다.

sudo systemctl restart gitlab-runsvdir

Errno::EAFNOSUPPORT: 프로토콜에서 지원하지 않는 주소 패밀리 - 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) 호스트를 IPv4 주소로
확인되도록 해결할 수 있습니다.

external_url에 밑줄이 포함된 경우 URI::InvalidComponentError (bad component(expected host component: my_url.tld) 발생

external_url에 밑줄이 있는 경우(예: https://my_company.example.com),
CI/CD와 관련하여 다음과 같은 문제가 발생할 수 있습니다:

  • 프로젝트의 설정 > 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에 밑줄을 사용하지 마세요.
이와 관련된 열린 문제는 다음과 같습니다: 밑줄이 포함된 external_url 설정으로 GitLab CI/CD 기능이 손상됨.

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

패키지 업그레이드가 다음 오류로 인해 reconfigure 실행 시 실패하면,

모든 Gitaly 프로세스가 중지되었는지 확인한 후 sudo gitlab-ctl reconfigure를 다시 실행하십시오.

---- /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly의 출력 시작 ----
STDOUT: timeout: run: /opt/gitlab/service/gitaly: (pid 4886) 15030s, got TERM
STDERR:
---- /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly의 출력 종료 ----
/opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly를 실행한 결과 1 반환

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

GitLab 재설치 시 reconfigure가 멈춤

알려진 문제로 인해,

GitLab을 제거한 후 다시 설치하려 할 때 ruby_block[wait for logrotate service socket] action run에서 reconfigure 프로세스가 멈출 수 있습니다. 이 문제는 GitLab을 제거할 때 systemctl 명령 중 하나가 실행되지 않을 때 발생합니다.

이 문제를 해결하려면:

  • GitLab을 제거할 때 모든 단계를 따랐는지 확인하고, 필요하다면 다시 수행하십시오.
  • 이슈 7776에 있는 우회 방법을 따르십시오.

Pulp 또는 Red Hat Satellite로 GitLab yum 저장소 미러링 실패

https://packages.gitlab.com/gitlab/에 위치한 Omnibus GitLab yum 저장소를 Pulp 또는 Red Hat Satellite로 직접 미러링하는 데 실패합니다.

동기화 시 다양한 오류가 발생하며, 이는 서로 다른 소프트웨어로 인한 것입니다:

  • Pulp 2 또는 Satellite < 6.10은 "Malformed repository: metadata is specified for different set of packages in filelists.xml and in other.xml" 오류로 실패합니다.
  • Satellite 6.10은 "pkgid" 오류로 실패합니다.
  • Pulp 3 또는 Satellite > 6.10은 성공하는 것처럼 보이지만, 저장소 메타데이터만 동기화됩니다.

이러한 동기화 실패는 GitLab yum 미러 저장소의 메타데이터 문제로 인해 발생합니다. 이 메타데이터에는 일반적으로 저장소의 모든 RPM에 대한 파일 목록을 포함하는 filelists.xml.gz 파일이 포함됩니다.

GitLab yum 저장소는 이 파일을 대부분 비워 둠으로써 파일이 전체적으로 채워졌을 때 발생할 수 있는 크기 문제를 피합니다.

각 GitLab RPM에는 방대한 수의 파일이 포함되어 있으며, 저장소의 많은 RPM 수와 곱해지면, 완전히 채워졌을 경우 엄청난 filelists.xml.gz 파일이 생성됩니다. 저장소 및 빌드 제약으로 인해 파일을 생성하지만, 내용을 채우지는 않습니다. 빈 파일로 인해 Pulp 및 RedHat Satellite(여기서 Pulp를 사용함) 저장소 미러링이 실패합니다.

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

문제 해결 방법

문제를 해결하기 위해:

  1. reposync 또는 createrepo와 같은 대체 RPM 리포지토리 미러링 도구를 사용하여 공식 GitLab yum 리포지토리의 로컬 복사본을 만듭니다. 이러한 도구는 로컬 데이터에서 리포지토리 메타데이터를 재생성하며, 여기에는 완전히 채워진 filelists.xml.gz 파일을 만드는 것이 포함됩니다.

  2. Pulp 또는 Satellite를 로컬 미러에 지정합니다.

로컬 미러 예시

다음은 로컬 미러링을 수행하는 방법의 예입니다. 이 예시는 다음을 사용합니다:

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

이 예시에서:

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

Apache 서버 생성 및 구성

다음 예시는 하나 이상의 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(약 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

시간 초과나 HTTP 502 오류가 발생할 수 있으며, gitlab.rb에서 puma['somaxconn'] 변수를 업데이트하여 이 값을 증가시키는 것이 권장됩니다.

exec request failed on channel 0 또는 shell request failed on channel 0 오류

SSH를 통해 Git을 사용하여 푸시 또는 풀을 할 때 다음과 같은 오류가 발생할 수 있습니다:

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

이러한 오류는 git 사용자의 프로세스 수가 한계를 초과할 경우 발생할 수 있습니다.

이 문제를 해결하려면:

  1. /etc/security/limits.conf 파일에서 git 사용자의 nproc 설정을 증가시킵니다. 이는 gitlab-shell이 실행되는 노드에서 수행해야 합니다.
    일반적으로 gitlab-shell은 GitLab Rails 노드에서 실행됩니다.

  2. Git 명령어로 풀 또는 푸시를 다시 시도합니다.

SSH 연결 손실 후 설치 중단

원격 가상 머신에 GitLab을 설치하는 동안 SSH 연결이 끊기면,
설치가 좀비 dpkg 프로세스와 함께 중단될 수 있습니다. 설치를 다시 시작하려면:

  1. top을 실행하여 관련 apt 프로세스의 프로세스 ID를 찾습니다. 이는 dpkg 프로세스의 부모입니다.

  2. apt 프로세스를 종료하려면 sudo kill <PROCESS_ID>를 실행합니다.

  3. 처음 설치하는 경우에만 sudo gitlab-ctl cleanse를 실행합니다. 이 단계는 기존 데이터를 지우므로 업그레이드에는 사용해서는 안 됩니다.

  4. sudo dpkg configure -a를 실행합니다.

  5. gitlab.rb 파일을 편집하여 원하는 외부 URL 및 누락된 다른 구성을 포함시킵니다.

  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와 연결을 시도하는 동안 다시 시작되었거나 종료되었음을 나타냅니다. 레시피는
gitlab-ctl restart redis를 실행하고 즉시 버전을 확인하려고 하므로, 이로 인해 오류가 발생할 수 있는 경합 조건이 존재할 수 있습니다.

이 문제를 해결하려면 다음 명령을 실행하십시오:

sudo gitlab-ctl reconfigure

이 명령이 실패하면 gitlab-ctl tail redis의 출력을 확인하고 redis-cli를 실행해 보십시오.