Talk:GitLab

From ArchWiki

Missing Section?

It might just be me, but it seems like a section is missing. In start and test it says visit your domain, however unless I am missing something pretty major that shouldn't work since neither apache nor nginx are ever setup / pointed to the webapp.--Theflyingfool (talk) 08:15, 8 April 2014 (UTC)Reply[reply]

I don't have neither of them on my server, Gitlab uses own one, Unicorn, to deal with webapp. Kosciak9 (talk) 12:17, 6 December 2015 (UTC)Reply[reply]

This has been explained, closing. -- Lahwaacz (talk) 19:43, 14 November 2017 (UTC)Reply[reply]
I just managed to install a working Gitlab. Without an nginx server, you get no assets from Unicorn. And the installation manual from the Gitlab website is quite explicit about it: you need a server like nginx. Mdhooge (talk) 09:26, 23 July 2018 (UTC)Reply[reply]

Using Sudo instead of su -

I don't have any root password on my pi, only my user password (for sudo). As the rest of the documentation uses sudo, it would be better to use sudo here too : https://wiki.archlinux.org/index.php?title=Gitlab&section=13

For some reason all sudo - commands fail for me, not sure why. ElectricPrism (talk) 08:10, 21 December 2015 (UTC)Reply[reply]

I'm also having issues without being root, unfortunately there are more issues, and I couldn't install (the latest version) at all.
Going to add Stub template, because more commands listed doesn't seem to work (correctly).
Beta990 (talk) 11:42, 21 December 2015 (UTC)Reply[reply]
Note: Regarding the `su - gitlab` users have gotten a update because they kept failing for me too.
From what I've seen online, the correct way of sudo'ing into the gitlab user would be `sudo -i -u gitlab /bin/sh` but that results in a `Only ssh allowed` error for me (which I think originates from gitab-shell).
You can always do `sudo su - gitlab -s /bin/sh`, that does work for me.
Gtarsia (talk) 18:23, 31 January 2019 (UTC)Reply[reply]

Very confusing

I went through the install, I didn't make it work yet but I have a few questions on confusing instructions:

-I want to use my already set-up nginx webserver. Should I still use reddis, and the gem/bundle install commands ?

Yes, you should proxy-pass nginx to unicorn. Redis is used for internal communication, gem/bundle for setup. You can find good explanations at the GitLab website. DenBrahe (talk) 21:43, 19 April 2016 (UTC)Reply[reply]

-What are the pros/cons to use the AUR package v. using the official package ?

AUR package is finetuned for Arch to work with systemd and linux conventions and things like that (don't know exactly). Basically if you're not an expert, you're better off with the AUR package. Wiki page should get an update though. DenBrahe (talk) 21:43, 19 April 2016 (UTC)Reply[reply]

-How can we uninstall the components installed by the gem/bundle install commands ?

-the su - gitlab command is not working but sudo -u gitlab works (as mentionned in this thread), is that ok ?

-I don't have any shell.yml file, which is mentionned only once for the HTTPS configuration, is it normal ?

-what is /dev/null in the nginx config ?

-how do I setup resque.timer ? I can't load it? ('unit resque.timer not found).


Mentatf (talk) 22:41, 7 April 2016 (UTC)Reply[reply]


I am adding my two cents to this section as well, because after trying for around 5 hours, I am giving up on the gitlab package and will try Gogs/Gitea instead. As I cannot say for sure what are actual problems and which are design choices made by the package maintainer that are just not well documented, someone else who has the necessary knowledge has to decide which changes are appropiate to make.

This is summary of the problems/confusion I faced:

  • The package depends on ruby2-3, which does not provide the bin 'ruby'. This throws off the environment check at the very least, yet no note is made of that.
  • Despite stating that the Arch package uses the user gitlab instead of git, the latter keeps getting mentioned in the article, sometimes even together with gitlab.
  • As described below, rvm seems to be neither necessary nor supported, yet the article implies that its usage is good practise.
  • All GitLab files seem to belong to root, leaving the gitlab with insufficient rights to save config files. As a result, at the very least the copy&paste solutions provided by the environment checks cannot be used because of that.
  • The article states that Unicorn is a HTTP server on its own, yet GitLab is shipped with nginx by default.
  • The article says that gitlab-workhorse is optional, yet at the very least the current Apache examples provided by GitLab all assume it to be configured. The package itself also depends on it.

Right now, it might be a better idea to intall GitLab from source, as the official documentation is more up-to-date and can be used with less adjustments. --Krukai (talk) 09:15, 8 September 2017 (UTC)Reply[reply]

Another small thing: the wiki page says we should enable gitlab-sidekiq and gitlab-unicorn services, but these are already part of gitlab.target, so I believe there is no need in enabling them separately. --Nplatis (talk) 06:04, 26 September 2017 (UTC)Reply[reply]

Package cleanup

I am trying to cleanup Arch Linux package, remove some obsolete workarounds and make the directory structure more Linux idiomatic.

I see that there are 2 ruby files under /etc/webapps/gitlab - application.rb and boot.rb. It looks more like an application code than a config file. Folks, do you really modify these files? If yes - why do you do this, what kind of changes do you have?

If these files are never modified by a user then I better move it back to the application code directory.

Anatolik (talk) 18:17, 27 May 2020 (UTC)Reply[reply]

I have only changes in puma.rb. -- Lahwaacz (talk) 20:09, 27 May 2020 (UTC)Reply[reply]

secrets.yml missing entries & permission/ownership properties

Almost completed installation, version 13.1.4-1. Following changes had to be done to the secrets.yml file:

# chown root:gitlab /etc/webapps/gitlab/secrets.yml
# chmod 640 /etc/webapps/gitlab/secrets.yml
/etc/webapps/gitlab/secrets.yml
production:
  secret_key_base: secret
  db_key_base: secret
  otp_key_base: secret
  openid_connect_signing_key: secret

4 different secrets were generated with hexdump as instructed in the wiki. Without these changes the command to initialize GitLab database failed:

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle exec rake gitlab:setup
Missing Rails.application.secrets.otp_key_base for production environment. The secret will be generated and stored in config/secrets.yml.
Missing Rails.application.secrets.openid_connect_signing_key for production environment. The secret will be generated and stored in config/secrets.yml.
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /usr/share/webapps/gitlab/config/secrets.yml

I did some small customisations to gitlab.yml and did the whole setup using Saltstack configuration management, so didn't edit the wiki instructions yet as I'm not sure if these changes only apply to my setup.

—This unsigned comment is by Tqre (talk) 15:09, 21 July 2020‎. Please sign your posts with ~~~~!

See also FS#67173. -- Lahwaacz (talk) 16:53, 21 July 2020 (UTC)Reply[reply]

I agree that this needs to be addressed. The permissions on /etc/webapps/gitlab/secrets.yml is wrong.

In my case, I let the gitlab:setup take care of generating otp_key_base and openid_connect_signing_key, there for I had to do:

# chown root:gitlab /etc/webapps/gitlab/secrets.yml
# chmod 660 /etc/webapps/gitlab/secrets.yml

But if you feel comfortable generating a RSA PRIVATE KEY and dump it in the right place/format, you could do chmod 640.

Torxed (talk) 08:57, 21 January 2021 (UTC)Reply[reply]

Gitlab as PostgreSQL superuser?

The GitLab#PostgreSQL Database section suggests creating the gitlab user as SUPERUSER, but to me it seems like a security risk...

The offical guide [1] suggests installing the extensions manually, is there a reason why making gitlab a SUPERUSER is suggested instead?

—This unsigned comment is by Steffo (talk) 17:35, 8 April 2021‎ (UTC). Please sign your posts with ~~~~!Reply[reply]

The motivation is mentioned in the note in GitLab#PostgreSQL database, but it might be outdated. -- Lahwaacz (talk) 08:52, 10 April 2021 (UTC)Reply[reply]

Bug on gitlab:backup:create task on gitlab 14.10

Since the last version, the backup failed. is it the same for you ? I report a bug on gitlab.

console
cd /usr/share/webapps/gitlab
sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:backup:create
2022-04-29 19:07:07 +0200 -- Dumping database ...
Dumping PostgreSQL database gitlab ... [DONE]
2022-04-29 19:07:09 +0200 -- Dumping database ... done
2022-04-29 19:07:09 +0200 -- Dumping repositories ...
flag provided but not defined: -layout
Usage of create:
  -locator string
    	determines how backup files are located. One of legacy, pointer. Note: The feature is not ready for production use. (default "legacy")
  -parallel int
    	maximum number of parallel backups (default 8)
  -parallel-storage -parallel
    	maximum number of parallel backups per storage. Note: actual parallelism when combined with -parallel depends on the order the repositories are received. (default 2)
  -path string
    	repository backup path
rake aborted!
Backup::Error: gitaly-backup exit status 2
/usr/share/webapps/gitlab/lib/backup/gitaly_backup.rb:58:in `finish!'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:21:in `ensure in dump'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:21:in `dump'
/usr/share/webapps/gitlab/lib/backup/manager.rb:82:in `run_create_task'
/usr/share/webapps/gitlab/lib/backup/manager.rb:46:in `block in create'
/usr/share/webapps/gitlab/lib/backup/manager.rb:45:in `each'
/usr/share/webapps/gitlab/lib/backup/manager.rb:45:in `create'
/usr/share/webapps/gitlab/lib/tasks/gitlab/backup.rake:12:in `block (3 levels) in <top (required)>'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/sentry-ruby-core-5.1.1/lib/sentry/rake.rb:26:in `execute'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'

Caused by:
Errno::EPIPE: Broken pipe
/usr/share/webapps/gitlab/lib/backup/gitaly_backup.rb:86:in `write'
/usr/share/webapps/gitlab/lib/backup/gitaly_backup.rb:86:in `puts'
/usr/share/webapps/gitlab/lib/backup/gitaly_backup.rb:86:in `schedule_backup_job'
/usr/share/webapps/gitlab/lib/backup/gitaly_backup.rb:66:in `enqueue'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:56:in `enqueue_project'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:47:in `block in enqueue_consecutive_projects'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:71:in `block (2 levels) in find_each'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:71:in `each'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:71:in `block in find_each'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:138:in `block in find_in_batches'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:245:in `block in in_batches'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:229:in `loop'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:229:in `in_batches'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:137:in `find_in_batches'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/activerecord-6.1.4.7/lib/active_record/relation/batches.rb:70:in `find_each'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:46:in `enqueue_consecutive_projects'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:41:in `enqueue_consecutive'
/usr/share/webapps/gitlab/lib/backup/repositories.rb:18:in `dump'
/usr/share/webapps/gitlab/lib/backup/manager.rb:82:in `run_create_task'
/usr/share/webapps/gitlab/lib/backup/manager.rb:46:in `block in create'
/usr/share/webapps/gitlab/lib/backup/manager.rb:45:in `each'
/usr/share/webapps/gitlab/lib/backup/manager.rb:45:in `create'
/usr/share/webapps/gitlab/lib/tasks/gitlab/backup.rake:12:in `block (3 levels) in <top (required)>'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/sentry-ruby-core-5.1.1/lib/sentry/rake.rb:26:in `execute'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
Tasks: TOP => gitlab:backup:create
(See full trace by running task with --trace)

--Celogeek (talk) 17:36, 29 April 2022 (UTC)Reply[reply]

gitlab:backup:create has been working fine in version 16, closing. — Lahwaacz (talk) 14:50, 11 November 2023 (UTC)Reply[reply]

Sideloaded git version since version 13.6?

There seem to be several issues with Gitlab instances running the vanilla git lately.

The most common I get on my Arch systems is this warning:

remote: warning: core.fsyncObjectFiles is deprecated; use core.fsync instead

But in some cases there may be more serious issues.

The official recommendation from Gitlab is to use the version of git provided by gitaly instead of the one provided by the system.

Has this been taken into account in the gitlab package and/or documented? Will the solution be to provide an e.g. git-gitlab package that e.g. installs the git executable under another prefix so it won't step on the system one? Sure, currently I can git clone whichever version of git they provide it, build it and install it under e.g. /usr/local. But then most of the people will simply forget to keep it up-to-date. And, even if we go down that route, we should probably document it in this page.

--Blacklight (talk) 22:33, 09 May 2022 (UTC)Reply[reply]

rake gitlab:setup fails with 'relation "feature_gates" does not exist'

After following this installation flow in a brand new server, during the "2.7 Initialize Gitlab database" the installation would stop and abort with the error:

# sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:setup GITLAB_ROOT_PASSWORD=[PWD] GITLAB_ROOT_EMAIL=mymail@mail.com
/usr/share/webapps/gitlab/lib/gitlab/instrumentation/redis.rb:9: warning: already initialized constant Gitlab::Instrumentation::Redis::ActionCable
/usr/share/webapps/gitlab/lib/gitlab/instrumentation/redis.rb:9: warning: previous definition of ActionCable was here
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR:  relation "feature_gates" does not exist
LINE 8:  WHERE a.attrelid = '"feature_gates"'::regclass
                            ^
[cut]

Caused by:
PG::UndefinedTable: ERROR:  relation "feature_gates" does not exist
LINE 8:  WHERE a.attrelid = '"feature_gates"'::regclass

With or without the variables the error will appear.

I opened a ticket with Gitlab to review the issue, because this is clearly something related with the database setup script provided. You can find the brief discussion here: Link to the issue

Then I thought that maybe if I just create the database by hand and retry, the result would be different.

So first I have created the database, as in 2.6, then populated it:

[root@new-server db]# sudo su - postgres
[postgres@new-server ~]$ cd /usr/share/webapps/gitlab/db
[postgres@new-server db]$ psql -d gitlabhq_production -f structure.sql
CREATE SCHEMA
COMMENT
CREATE SCHEMA
COMMENT
[.... CUT ...]

Then we can see the Database populated and we can follow up with the following:

# sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:setup GITLAB_ROOT_PASSWORD=[PWD] GITLAB_ROOT_EMAIL=mymail@mail.com DISABLE_DATABASE_ENVIRONMENT_CHECK=1

After this command, I still had a problem with REDIS as he was not creating the proper socket in the right location (/run/redis/redis.sock) after fixing that, the installation reached the end.

--Spectroman (talk) 21:00, 20 Apr 2023 (UTC)

I did gitlab:setup recently with gitlab-16.4.1-1 and did not notice this issue. The GitLab issue is also closed, so let's close this discussion too. — Lahwaacz (talk) 14:48, 11 November 2023 (UTC)Reply[reply]

Puma config introduced new non-existent directories for PID files and logs

In version 16.5.0-2 the puma.rb config file changed were PID files and logs are located. These directories ('/var/lib/gitlab/tmp/pids/' and '/var/lib/gitlab/log/') were not available in my system and not part of the package. This is why gitlab-workhorse could not connect to gitlab-puma and the instance was not available. Creating the directories owned by the gitlab user and restarting the services fixed the problem. Is there a problem with my configuration or a bug in the package?

—This unsigned comment is by Chrysaor (talk) 11:55, 3 November 2023. Please sign your posts with ~~~~!

This was fixed in [2], closing. — Lahwaacz (talk) 18:02, 11 November 2023 (UTC)Reply[reply]
Actually, it wasn't fixed: FS#80233. — Lahwaacz (talk) 18:26, 11 November 2023 (UTC)Reply[reply]