link之家
链接快照平台
- 输入网页链接，自动生成快照
- 标签化管理网页链接
NoMethodError - undefined method '[]=' for nil:NilClass
FATAL: could not create shared memory segment: Cannot allocate memory
FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied
FATAL: remaining connection slots are reserved for non-replication superuser connections
gitlab-rake assets:precompile
fails with ‘Permission denied’
gitlab-runsvdir
not starting
gitlab-ctl reconfigure
hangs while using AWS Cloudformation
URI::InvalidComponentError (bad component(expected host component: my_url.tld)
when
external_url
contains underscores
timeout: run: /opt/gitlab/service/gitaly
error
yum
repository with Pulp or Red Hat Satellite fails
Troubleshooting Omnibus GitLab installation issues
Hash Sum mismatch when downloading packages
apt-get install
outputs something like:
Run the following to fix this:
See Joe Damato’s from Packagecloud comment and his blog article for more context.
Another workaround is to download the package manually by selecting the correct package from the CE packages or EE packages repository:
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
Installation on openSUSE and SLES platforms warns about unknown key signature
Omnibus GitLab packages are signed with GPG keys in addition to the package repositories providing signed metadata. This ensures authenticity and integrity of the packages that are distributed to the users. However, the package manager used in openSUSE and SLES operating systems may sometime raise false warnings with these signatures, similar to
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
This is a known bug with zypper where zypper ignores the
gpgkey
keyword in the
repository configuration file. With later versions of Packagecloud, there may be
improvements regarding this, but currently users have to manually agree to
package installation.
So, in openSUSE or SLES systems, if such a warning is displayed, it is safe to continue installation.
apt/yum complains about GPG signatures
This is because on April 2020, GitLab changed the GPG keys used to sign metadata of the apt and yum repositories available through the Packagecloud instance . If you see this error, it generally means you do not have the public keys currently used to sign repository metadata in your keyring. To fix this error, follow the steps to fetch the new key .
Reconfigure shows an error:
NoMethodError - undefined method '[]=' for nil:NilClass
You can check the latest available configuration by using
sudo gitlab-ctl diff-config
(Command available starting with GitLab 8.17) or check the latest
gitlab.rb.template
.
GitLab is unreachable in my browser
Try
specifying
an
external_url
in
/etc/gitlab/gitlab.rb
. Also check your firewall settings; port 80 (HTTP) or
443 (HTTPS) might be closed on your GitLab server.
Note that specifying the
external_url
for GitLab, or any other bundled service (Registry and
Mattermost) doesn’t follow the
key=value
format that other parts of
gitlab.rb
follow. Make sure
that you have them set in the following format:
external_url "https://gitlab.example.com"
registry_external_url "https://registry.example.com"
mattermost_external_url "https://mattermost.example.com"
Don’t add the equal sign (=) between external_url and the value.
Emails are not being delivered
Run
sudo gitlab-ctl reconfigure
for the change to take effect.
TCP ports for GitLab services are already taken
The ports for Redis, PostgreSQL and Puma can be overridden in
/etc/gitlab/gitlab.rb
as follows:
For NGINX port changes please see
Setting the NGINX listen port
.
Git user does not have SSH access
SELinux-enabled systems
Diagnose and resolve SELinux issues
Data paths may be altered via
gitlab.rb
, however, a common scenario forces the
use of
symlink
paths. Administrators should be cautious, because
symlink
paths are
not supported for all scenarios, such as
Gitaly data paths
.
For example, if
/data/gitlab
replaced
/var/opt/gitlab
as the base data directory, the following fixes the security context:
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/
After the policies are applied, you can verify the SSH access is working
by getting the welcome message:
ssh -T git@gitlab-hostname
All systems
PostgreSQL error
FATAL: could not create shared memory segment: Cannot allocate memory
FATAL: could not create shared memory segment: Cannot allocate memory
Run
sudo gitlab-ctl reconfigure
for the change to take effect.
PostgreSQL error
FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied
FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied
Run
sudo gitlab-ctl reconfigure
for the change to take effect.
PostgreSQL error
FATAL: remaining connection slots are reserved for non-replication superuser connections
FATAL: remaining connection slots are reserved for non-replication superuser connections
To fix this problem, you have two options:
Either increase the max connections value:
Edit
/etc/gitlab/gitlab.rb
:
postgresql['max_connections'] = 600
Reconfigure GitLab:
sudo gitlab-ctl reconfigure
Or, you can consider using PgBouncer which is a connection pooler for PostgreSQL.
Reconfigure complains about the GLIBC version
Reconfigure complains about the GLIBC version
Reconfigure fails to create the Git user
Reconfigure fails to create the Git user
This can happen if you run
sudo gitlab-ctl reconfigure
as the Git user.
Switch to another user.
Failed to modify kernel parameters with sysctl
Failed to modify kernel parameters with sysctl
Try
enabling the module
on which sysctl errored out.
There is a reported workaround described in
this issue
which requires editing the GitLab’ internal recipe by supplying the switch which ignores failures. Ignoring errors can have unexpected side effects on the performance of your GitLab server, so it isn’t recommended to do so.
Another variation of this error reports the file system is read-only and shows following stack trace:
* 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
This error is also reported to occur in virtual machines only, and the recommended workaround is to set the values in the host. The values needed for GitLab can be found inside the file
/opt/gitlab/embedded/etc/90-omnibus-gitlab.conf
in the virtual machine. After setting these values in
/etc/sysctl.conf
file in the host OS, run
cat /etc/sysctl.conf /etc/sysctl.d/*.conf | sysctl -e -p -
on the host. Then try running
gitlab-ctl reconfigure
inside the virtual machine. It should detect that the kernel is already running with the necessary settings, and not raise any errors.
You may have to repeat this process for other lines. For example, reconfigure fails three times, after having added something like this to
/etc/sysctl.conf
:
kernel.shmall = 4194304
kernel.sem = 250 32000 32 262
net.core.somaxconn = 1024
kernel.shmmax = 17179869184
You may find it easier to look at the line in the Chef output than to find the file (since the file
is different for each error). See the last line of this snippet.
* 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
I am unable to install Omnibus GitLab without root access
I am unable to install Omnibus GitLab without root access
Installing the .deb or .rpm
Installing the .deb or .rpm
Hassle-free hosting on port 80 and 443
Hassle-free hosting on port 80 and 443
Isolation between Omnibus services
Isolation between Omnibus services
Bundled services in Omnibus GitLab (GitLab itself, NGINX, PostgreSQL,
Redis, Mattermost) are isolated from each other using Unix user
accounts. Creating and managing these user accounts requires root
access. By default, Omnibus GitLab will create the required Unix
accounts during
gitlab-ctl reconfigure
but that behavior can be
disabled
.
In principle Omnibus GitLab could do with only 2 user accounts (one
for GitLab and one for Mattermost) if we give each application its own
runit (runsvdir), PostgreSQL and Redis process. But this would be a
major change in the
gitlab-ctl reconfigure
Chef code and it would
probably create major upgrade pain for all existing Omnibus GitLab
installations. (We would probably have to rearrange the directory
structure under
/var/opt/gitlab
.)
Tweaking the operating system for better performance
Tweaking the operating system for better performance
gitlab-rake assets:precompile
fails with ‘Permission denied’
gitlab-rake assets:precompile
fails with ‘Permission denied’
The GitLab web interface uses CSS and JavaScript files, called ‘assets’ in Ruby
on Rails-speak. In the
upstream GitLab repository
these files are stored in a developer-friendly way: easy to read and edit. When
you are a normal user of GitLab, you do not want these files to be in the
developer friendly format however because that makes GitLab slow. This is why
part of the GitLab setup process is to convert the assets from a
developer-friendly format to an end-user friendly (compact, fast) format; that
is what the
rake assets:precompile
script is for.
When you install GitLab from source (which was the only way to do it before we
had omnibus packages) you need to convert the assets on your GitLab server
every time you update GitLab. People used to overlook this step and there are
still posts, comments and mails out there on the internet where users recommend
each other to run
rake assets:precompile
(which has now been renamed
gitlab:assets:compile
). With the omnibus packages things are different: when
we build the package
we compile the assets for you
.
When you install GitLab with an omnibus package, the converted assets are
already there! That is why you do not need to run
rake assets:precompile
when
you install GitLab from a package.
When
gitlab-rake assets:precompile
fails with a permission error it fails for
a good reason from a security standpoint: the fact that the assets cannot
easily be rewritten makes it harder for an attacker to use your GitLab server
to serve evil JavaScript code to the visitors of your GitLab server.
If you want to run GitLab with custom JavaScript or CSS code you are probably
better off running GitLab from source, or building your own packages.
If you really know what you are doing,
you can execute
gitlab-rake gitlab:assets:compile
like this:
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’ error
‘Short read or OOM loading DB’ error
Try
cleaning the old Redis session
.
Apt error ‘The requested URL returned error: 403’
Apt error ‘The requested URL returned error: 403’
When trying to install GitLab using the apt repo if you receive an error similar to:
check if there is a repository cacher in front of your server, like for example
apt-cacher-ng
.
Add the following line to apt-cacher-ng config(eg. in
/etc/apt-cacher-ng/acng.conf
):
Read more about
apt-cacher-ng
and the reasons why this change is needed
on the packagecloud blog
.
Using self signed certificate or custom certificate authorities
Using self signed certificate or custom certificate authorities
when GitLab tries to connect with the internal services like GitLab Shell.
To fix these errors, see the
Install Custom Public Certificates
section.
error: proxyRoundTripper: XXX failed with: “net/http: timeout awaiting response headers”
error: proxyRoundTripper: XXX failed with: “net/http: timeout awaiting response headers”
You can increase the default timeout value by setting the value in
/etc/gitlab/gitlab.rb
:
Save the file and
reconfigure GitLab
for the changes to take effect.
The change you wanted was rejected
The change you wanted was rejected
See
Change the default proxy headers section of NGINX doc
for details on
how to override the default headers.
Can’t verify CSRF token authenticity Completed 422 Unprocessable
Can’t verify CSRF token authenticity Completed 422 Unprocessable
See
Change the default proxy headers section of NGINX doc
for details on
how to override the default headers.
Extension missing pg_trgm
Extension missing pg_trgm
Starting from GitLab 8.6,
GitLab requires
the PostgreSQL extension
pg_trgm
.
If you are using Omnibus GitLab package with the bundled database, the extension
should be automatically enabled when you upgrade.
If you however, are using an external (non-packaged) database, you will need to
enable the extension manually. The reason for this is that Omnibus GitLab
package with external database has no way of confirming if the extension exists,
and it also doesn’t have a way of enabling the extension.
To fix this issue, you’ll need to first install the
pg_trgm
extension.
The extension is located in the
postgresql-contrib
package. For Debian:
sudo apt-get install postgresql-contrib
Once the extension is installed, access the
psql
as superuser and enable the
extension.
-
Restart the container:
docker restart gitlab - Pulp 2 or Satellite < 6.10 fails with
"Malformed repository: metadata is specified for different set of packages in filelists.xml and in other.xml"error. - Satellite 6.10 fails with
"pkgid"error. - Pulp 3 or Satellite > 6.10 seems to succeed, but only the repository metadata is synced.
-
reposyncandcreaterepoto sync the GitLab repository to the local mirror. This local mirror can then be used as a source for Pulp or RedHat Satellite. You can use other tools like Cobbler as well. - The local mirror is running on a
RHEL 8,Rocky 8, orAlmaLinux 8system. - The host name used for the web-server is
mirror.example.com. - Pulp 3 syncs from the local mirror.
- Mirroring is of the GitLab Enterprise Edition repository.
Access
psql
as superuser:
sudo gitlab-psql -d gitlabhq_production
Enable the extension:
CREATE EXTENSION pg_trgm;
Now run migrations again:
sudo gitlab-rake db:migrate
If using Docker, you first need to access your container, then run the commands
above, and finally restart the container.
Access the container:
docker exec -it gitlab bash
Run the commands above
Errno::ENOMEM: Cannot allocate memory during backup or upgrade
GitLab requires
2GB of available memory to run without errors. Having 2GB of memory installed may
not be enough depending on the resource usage of other processes on your server.
If GitLab runs fine when not upgrading or running a backup, then adding more swap
should solve your problem. If you see the server using swap during normal usage,
you can add more RAM to improve performance.
NGINX error: ‘could not build server_names_hash, you should increase server_names_hash_bucket_size’
Run sudo gitlab-ctl reconfigure for the change to take effect.
Reconfigure fails due to “‘root’ cannot chown” with NFS root_squash
This can happen if you have directories mounted using NFS and configured in root_squash
mode. Reconfigure is not able to properly set the ownership of your directories. You
will need to switch to using no_root_squash in your NFS exports on the NFS server, or
disable storage directory management
and manage the permissions yourself.
gitlab-runsvdir not starting
This applies to operating systems using systemd (e.g. Ubuntu 18.04+, CentOS, etc.).
If everything is working properly, the output should show look something like this:
To examine which jobs may be queued by systemd, run:
In this case, consider uninstalling Plymouth.
Init daemon detection in non-Docker container
/opt/gitlab/embedded/bin/runsvdir-start &
gitlab-ctl reconfigure hangs while using AWS Cloudformation
The GitLab systemd unit file by default uses multi-user.target for both After
and WantedBy fields. This is done to ensure service runs after remote-fs and
network targets, and thus GitLab will function properly.
However, this interacts poorly with cloud-init’s
own unit ordering, which is used by AWS Cloudformation.
To fix this, users can make use of package['systemd_wanted_by'] and
package['systemd_after'] settings in gitlab.rb to specify values needed for
proper ordering and run sudo gitlab-ctl reconfigure. After reconfigure has
completed, restart gitlab-runsvdir service for changes to take effect.
sudo systemctl restart gitlab-runsvdir
Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)
When starting up GitLab, if an error similar to the following is observed:
Check if the hostnames in use are resolvable and IPv4
addresses are returned:
URI::InvalidComponentError (bad component(expected host component: my_url.tld) when external_url contains underscores
If that’s the case, production.log will contain the following error:
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'
As a workaround, avoid using underscores in external_url. There is an open issue about it: Setting external_url with underscore results in a broken GitLab CI/CD functionality.
Upgrade fails with timeout: run: /opt/gitlab/service/gitaly error
Refer to issue 341573 for more details.
Mirroring the GitLab yum repository with Pulp or Red Hat Satellite fails
Direct mirroring of the Omnibus GitLab yum repositories located at https://packages.gitlab.com/gitlab/ with Pulp or
Red Hat Satellite fails
when syncing. Different errors are caused by different software:
These sync failures are caused by issues with the metadata in the GitLab yum
mirror repository. This metadata includes a filelists.xml.gz file that
normally includes a list of files for every RPM in the repository. The GitLab
yum repository leaves this file mostly empty to work around a size issue that
would be caused if the file was fully populated.
Each GitLab RPM contains an enormous number of files, which when multiplied by
the large number of RPMs in the repository, would result in a huge
filelists.xml.gz file if it was fully populated. Because of storage and build
constraints, we create the file but do not populate it. The empty file causes
Pulp and RedHat Satellite (which uses Pulp) repository mirroring of the file to
fail.
Refer to issue 2766 for details.
Work around the issue
Local mirror example
The following is an example of how to do local mirroring. The example uses:
Apache as the web server for the repository.
In this example:
Create and configure an Apache server
The following example shows how to install and configure a basic Apache 2
server to host one or more Yum repository mirrors.
Consult the Apache documentation for details on
configuring and securing your web server.
Install httpd:
sudo dnf install httpd
Add a Directory stanza to /etc/httpd/conf/httpd.conf:
<Directory “/var/www/html/repos“>
Options All Indexes FollowSymLinks
Require all granted
</Directory>
Complete the httpd configuration:
sudo rm -f /etc/httpd/conf.d/welcome.conf
sudo mkdir /var/www/html/repos
sudo systemctl enable httpd --now
Get the mirrored Yum repository URL
Install the GitLab repository yum configuration file:
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
Get the repository URL:
sudo dnf config-manager --dump gitlab_gitlab-ee | grep baseurl
baseurl = https://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64
You use the contents of baseurl as the source of the local mirror. For example,
https://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64.
Create the local mirror
Install the
createrepo
package:
sudo dnf install createrepo
Run reposync to copy RPMs to the local mirror:
sudo dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only
The --newest-only option only downloads the latest RPM. If you omit this
option, all RPMs in the repo (approximately 1 GB each) are downloaded.
Run createrepo to recreate the repository metadata:
sudo createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee
The local mirror repository should now be available at
http://mirror.example.com/repos/gitlab_gitlab-ee/.
Update the local mirror
Create /etc/cron.daily/sync-gitlab-mirror with the following contents:
Using the local mirror
Create the Pulp repository and 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
Sync the repository:
pulp rpm repository sync --name gitlab-ee
This command must be run periodically to update the local mirror with changes
to the GitLab repository.
After the repository is synced, you can create a publication and distribution to
make it available. See https://docs.pulpproject.org/pulp_rpm/ for details.
Help & feedback
Docs
Edit this page
to fix an error or add an improvement in a merge request.
Create an issue
to suggest an improvement to this page.
Product
Create an issue
if there's something you don't like about this feature.
Propose functionality
by submitting a feature request.
Join First Look
to help shape new features.
Feature availability and product trials
View pricing
to see all GitLab tiers and features, or to upgrade.
Try GitLab for free
with access to all features for 30 days.
Get Help
If you didn't find what you were looking for,
search the docs
.
If you want help with something specific and could use community support,
post on the GitLab forum
.
For problems setting up or using this feature (depending on your GitLab
subscription).
Request support
Create the local mirror
Install the
createrepo
package:
sudo dnf install createrepo
Run reposync to copy RPMs to the local mirror:
sudo dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only
The --newest-only option only downloads the latest RPM. If you omit this
option, all RPMs in the repo (approximately 1 GB each) are downloaded.
Run createrepo to recreate the repository metadata:
sudo createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee
The local mirror repository should now be available at
http://mirror.example.com/repos/gitlab_gitlab-ee/.
Update the local mirror
Create /etc/cron.daily/sync-gitlab-mirror with the following contents:
Using the local mirror
Create the Pulp repository and 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
Sync the repository:
pulp rpm repository sync --name gitlab-ee
This command must be run periodically to update the local mirror with changes
to the GitLab repository.
After the repository is synced, you can create a publication and distribution to
make it available. See https://docs.pulpproject.org/pulp_rpm/ for details.
Help & feedback
Docs
Edit this page
to fix an error or add an improvement in a merge request.
Create an issue
to suggest an improvement to this page.
Product
Create an issue
if there's something you don't like about this feature.
Propose functionality
by submitting a feature request.
Join First Look
to help shape new features.
Feature availability and product trials
View pricing
to see all GitLab tiers and features, or to upgrade.
Try GitLab for free
with access to all features for 30 days.
Get Help
If you didn't find what you were looking for,
search the docs
.
If you want help with something specific and could use community support,
post on the GitLab forum
.
For problems setting up or using this feature (depending on your GitLab
subscription).
Request support
推荐文章
|
卖萌的登山鞋 · iTerm2 配置和美化 - 少数派 3 年前 |