- 패키지 다운로드 시 해시 합 불일치
- openSUSE 및 SLES 플랫폼에서의 설치 시 알 수 없는 키 서명 경고
- apt/yum에서 GPG 서명에 대한 경고
- 재구성 실행 시 오류 표시:
NoMethodError - undefined method '[]=' for nil:NilClass
- 내 브라우저에서 GitLab에 액세스할 수 없음
- 이메일이 전달되지 않음
- GitLab 서비스용 TCP 포트가 이미 사용 중임
- Git 사용자가 SSH 액세스를 할 수 없음
- PostgreSQL 오류
FATAL: could not create shared memory segment: Cannot allocate memory
- PostgreSQL 오류
FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied
- PostgreSQL 오류
FATAL: remaining connection slots are reserved for non-replication superuser connections
- GLIBC 버전으로 인해 Reconfigure가 실패하는 경우
- Reconfigure가 Git 사용자를 만들지 못하면
- sysctl로 커널 매개변수를 수정하지 못한 경우
- 루트 액세스 없이 Omnibus GitLab을 설치할 수 없음
gitlab-rake assets:precompile
이 ‘Permission denied’로 실패함- ‘Short read or OOM loading DB’ 오류
- CSRF 토큰 진위성을 확인할 수 없음 완료됨 422 불가처리됨
- 확장 프로그램이 누락된 pg_trgm
- 백업 또는 업그레이드 중 메모리 할당이 불가능한 Errno::ENOMEM
- NGINX 오류: ‘could not build server_names_hash, you should increase server_names_hash_bucket_size’
- NFS root_squash로 인해 ‘root’가 chown할 수 없는 Reconfigure 실패
gitlab-runsvdir
가 시작되지 않음- 비-Docker 컨테이너에서 Init 데몬 탐지
- AWS Cloudformation을 사용하는 동안
gitlab-ctl reconfigure
가 중단되는 문제 - Errno::EAFNOSUPPORT: 프로토콜에서 지원하지 않는 주소 체계입니다 - 소켓(2)
URI::InvalidComponentError (bad component(expected host component: my_url.tld)
에서external_url
에 밑줄이 포함되어 있는 경우timeout: run: /opt/gitlab/service/gitaly
오류로 업그레이드 실패- GitLab 재설치 시 재구성이 멈추는 문제
-
Pulp 또는 Red Hat Satellite로 GitLab
yum
리포지터리를 미러링하는 경우 실패 - 오류:
E: connection refused to d20rj4el6vkp4c.cloudfront.net 443
net.core.somaxconn
을 증가해야 하나요?exec request failed on channel 0
또는shell request failed on channel 0
오류
Omnibus GitLab 설치 문제 해결
Omnibus GitLab 패키지를 설치하는 동안 사용자가 마주칠 수 있는 일반적인 문제에 대해 알아보는 페이지입니다.
패키지 다운로드 시 해시 합 불일치
apt-get install
이 다음과 같은 내용을 출력하는 경우:
E: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/pool/trusty/main/g/gitlab-ce/gitlab-ce_8.1.0-ce.0_amd64.deb Hash Sum mismatch
다음을 실행하여 이 문제를 해결합니다:
sudo rm -rf /var/lib/apt/lists/partial/*
sudo apt-get update
sudo apt-get clean
자세한 내용은 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"
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
에서의 기본 경로 변경을 감지하고 올바른 파일 컨텍스트를 적용해야 합니다.
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 인스턴스가 동시 연결 수의 제한을 초과하려고 한 것입니다.
이 문제를 해결하기 위해 두 가지 옵션이 있습니다:
-
최대 연결 수 값을 늘리는 것:
-
/etc/gitlab/gitlab.rb
를 편집하십시오.postgresql['max_connections'] = 600
-
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
에 액세스하여 확장 프로그램을 활성화하세요.
-
슈퍼 사용자로
psql
에 액세스:sudo gitlab-psql -d gitlabhq_production
-
확장 프로그램을 활성화:
CREATE EXTENSION pg_trgm; \q
-
이제 마이그레이션을 다시 실행하세요:
sudo gitlab-rake db:migrate
도커를 사용하는 경우 먼저 컨테이너에 액세스한 다음 위의 명령을 실행하고 컨테이너를 다시 시작해야 합니다.
-
컨테이너에 액세스:
docker exec -it gitlab bash
-
위의 명령을 실행하세요
-
컨테이너를 다시 시작하세요:
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를 참조하십시오.
문제 해결 방법
다음과 같은 방법으로 이 문제를 해결할 수 있습니다:
-
reposync
또는createrepo
와 같은 대체 RPM 리포지터리 미러링 도구를 사용하여 공식 GitLabyum
리포지터리의 로컬 복사본을 만듭니다. 이러한 도구들은 로컬 데이터에 리포지터리 메타데이터를 다시 만들고 완전히 채워진filelists.xml.gz
파일을 생성합니다. - 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 설명서를 참조하십시오.
-
httpd
를 설치합니다:sudo dnf install httpd
-
/etc/httpd/conf/httpd.conf
에Directory
스탠자를 추가합니다:<Directory “/var/www/html/repos“> Options All Indexes FollowSymLinks Require all granted </Directory>
-
httpd
구성을 완료합니다:sudo rm -f /etc/httpd/conf.d/welcome.conf sudo mkdir /var/www/html/repos sudo systemctl enable httpd --now
미러링된 Yum 리포지터리 URL 가져오기
-
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
-
리포지터리 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
.
로컬 미러 생성
-
createrepo
패키지를 설치합니다:sudo dnf install createrepo
-
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씩)이 다운로드됩니다. -
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을 로컬 미러에서 삭제합니다.
로컬 미러 사용
-
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
-
리포지터리를 동기화합니다:
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
사용자의 프로세스 수가 제한을 초과하면 이러한 오류가 발생할 수 있습니다.
이 문제를 해결하려면:
-
/etc/security/limits.conf
파일에서git
사용자의nproc
설정을 늘립니다. 일반적으로gitlab-shell
은 GitLab Rails 노드에서 실행됩니다. - 푸시 또는 풀 Git 명령을 다시 시도합니다.