Installare e configurare GitLab con Plesk 12 su CentOS 6
Fase 2 – GitLab
A questo punto, terminati i prerequisiti, è necessario aggiungere il server per il pacchetto GitLab CE (Community Edition) con:
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
e infine installare il pacchetto (circa 328 Mb di download, 904 Mb di installazione per la versione 8.0.4) con:
sudo yum install gitlab-ce
Ora abbiamo GitLab installato sul nostro server, nella directory /var/opt/gitlab/, che tuttavia va configurato in base alle nostre esigenze.
Supponiamo che vogliate che la vostra repository Git sia accessibile ad esempio dall’indirizzo http://git.nullalo.com. La prima cosa da fare è editare il file /etc/gitlab/gitlab.rb e modificare i seguenti valori (al di sopra dei quali ne abbiamo indicato il significato):
# URL al quale sarà consultabile la repository GitLab external_url 'http://git.nullalo.com' # Disabilita completamente Nginx di GitLab, in quanto andremo ad usare quello di Plesk nginx['enable'] = false # Imposta la porta SSH del server gitlab_rails['gitlab_shell_ssh_port'] = 22
Per utilizzare GitLab con protocollo SSL è necessario cambiare l’external_url ed aggiungere una direttiva come segue:
external_url 'https://git.nullalo.com' nginx['listen_https'] = false # to communicate with GitLab Nginx internally over HTTP, even if external_url is in HTTPS nginx['redirect_http_to_https'] = true # redirects all traffic to HTTPS
Per utilizzare una porta HTTPS diversa da quella standard(443), specificatelo come parte dell’external_url:
external_url 'https://git.nullalo.com:2443'
Se la vostra versione di GitLab è la 8.0.x o la 8.1.x, dovrete anche modificare i settaggi relativi al nuovo gitlab-git-http-server, dal momento che Apache non può connettersi ad un socket UNIX, ed è pertanto necessario utilizzare una porta TCP:
gitlab_git_http_server['listen_network'] = "tcp" gitlab_git_http_server['listen_addr'] = "localhost:8181"
A partire dalla versione 8.2 gitlab-git-http-server è stato rimpiazzato dalla nuova versione gitlab-workhorse, un daemon che gestisce anche i download. Per GitLab 8.2.x è pertanto necessario ignorare i settaggi di gitlab_git_http_server di cui sopra e inserire invece:
gitlab_workhorse['listen_network'] = "tcp" gitlab_workhorse['listen_addr'] = "localhost:8181"
Se desiderate far sì che GitLab possa inviarvi email, modificare nello stesso file anche i settaggi del server SMTP indicando il server (nell’esempio mail.nullalo.com), la porta (solitamente la 25, se non si usano SSL/TLS), username e password dell’account da utilizzare e tipo di autenticazione (“plain” nel nostro esempio):
gitlab_rails['gitlab_email_enabled'] = true gitlab_rails['gitlab_email_from'] = 'git@git.nullalo.com' gitlab_rails['gitlab_email_display_name'] = 'Nullalo Git Repository' gitlab_rails['gitlab_email_reply_to'] = 'noreply@git.nullalo.com' gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "mail.nullalo.com" gitlab_rails['smtp_port'] = 25 gitlab_rails['smtp_user_name'] = "info@nullalo.com" gitlab_rails['smtp_password'] = "lavostrapassword" gitlab_rails['smtp_domain'] = "mail.nullalo.com" gitlab_rails['smtp_authentication'] = "plain" gitlab_rails['smtp_enable_starttls_auto'] = true gitlab_rails['smtp_tls'] = false gitlab_rails['smtp_openssl_verify_mode'] = 'none'
Per spostare la cartella dati in quella del vostro virtual host:
git_data_dir "/var/www/vhosts/nullalo.com/git.nullalo.com/git-data"
Per spostare anche la cartella degli upload:
gitlab_rails['uploads_directory'] = "/var/www/vhosts/nullalo.com/git.nullalo.com/uploads"
Se desidera impostare la cartella di backup:
gitlab_rails['backup_path'] = "/var/www/vhosts/nullalo.com/git.nullalo.com/backups" gitlab_rails['backup_keep_time'] = 604800 # Limita la vita dei backup a 7 giorni (604800 secondi)
Ora riconfiguriamo e avviamo GitLab con le precedenti impostazioni grazie al comando:
sudo gitlab-ctl reconfigure
Prestate particolare attenzione allo spostamento delle cartelle di GitLab in quella del virtual host: se non vengono garantiti i giusti permessi, queste cartelle non saranno backuppabili da Plesk. Poiché è opportuno che GitLab lavori con utente e gruppo git, e forza 700 come permessi sia della cartella dati (/var/opt/gitlab/git-data/) che di quella di backup (/var/opt/gitlab/backups), la soluzione più rapida è quella di cambiare i permessi della cartella dopo ogni riconfigurazione di GitLab (gitlab-ctl reconfigure) in modo che Plesk possa effettuarne il backup. Ciò può essere fatto con il seguente comando:
chmod a+x -R /var/www/vhosts/nullalo.com/git.nullalo.com/git-data chmod a+x -R /var/www/vhosts/nullalo.com/git.nullalo.com/uploads chmod a+x -R /var/www/vhosts/nullalo.com/git.nullalo.com/backups
35 Commenti
Hello,
First let me thank you for this tutorial which helped me a lot installing gitlab on plesk 12.5.
Nevertheless I can’t download zip archive of projects, I am redirected to a page with json metadata using your configuration.
To resolve this problem I can set this block :
location @gitlab {
….
proxy_pass http://gitlab-git-http-server;
}
In this case archive links will work, but gitlab pages will show a message “Forbidden”.
Do you have this issue ? Did you manage to deal with it ?
Thanks
Hi Mika,
which version of GitLab did you install on your server?
I did an update yesterday and I currently have the 8.2.3
Having the same issue as Mika, using version Gitlab-ce 8.2.3
Downloading a zip redirects me to “projectname/repository/archive.zip?ref=master” and it shows a json page
Additionally, Plesk has an extension for Let’s Encrypt, in order to use this do the following:
sudo nano /etc/gitlab/gitlab.rb
Change the external_url to: external_url ‘https://git.yourdomain.com’
and add: nginx[‘listen_https’] = false
Now you have gitlab-ce with https enabled.
Mmm… in this case we’re using Plesk’s Nginx instance instead of GitLab one. In fact, we have the following line in /etc/gitlab/gitlab.rb
nginx[‘enable’] = false
So any further nginx option set in that section is meaningless, including:
nginx[‘listen_https’] = false
that is used to let GitLab communicate with bundled Nginx reverse proxy internally over HTTP, even if external_url uses HTTPS.
Did I miss your point?
Nvm. got it fixed. Just add the following to “Apache & nginx Settings”
location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-git-http-server;
}
location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-git-http-server;
}
location ~ ^/api/v3/projects/.*/repository/archive {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-git-http-server;
}
GitLab replaced in the last versions gitlab-git-http-server with gitlab-workhorse, a daemon that handles archive downloads too. I’m currently testing updated Apache & Nginx settings, and I will update the procedure described in this article (that was tested on version 8.0.5) once I’m sure everything’s ok with v8.2.3.
Hi,
I tried adding your configuration but still not working, I’m always having the json displayed.
Your problem is gitlab-git-http-server replaced by gitlab-workhorse, that now handles downloads and needs to use a TCP port instead of a UNIX socket. Please follow the updated tutorial and make sure you have these lines in your /etc/gitlab/gitlab.rb file:
gitlab_workhorse[‘listen_network’] = “tcp”
gitlab_workhorse[‘listen_addr’] = “localhost:8181”
Also double check /etc/nginx/conf.d/gitlab.conf file and Nginx & Apache settings for GitLab v8.2.3.
Ok guys, just updated the article, adding configuration for GitLab v8.2.3 and some additional configuration parameter (uploads folder, SSL, etc…). Everything’s working in my dev environment: I also tested avatars and documents upload, project zip download and so on. Let me know if you experience some issue, ok?
Thank you very much.
By the way I had to change to :
location @gitlab {
…
proxy_pass http://localhost:8080;
}
otherwise I get a 502 error.
Thanks again !
Same here, we’re using Plesk 17.5 and GitLab 9.1
Hi,
I have a 500 error when I want create users or repositories groups…
In GitLab production.log, I’ve got this line which appear when I try to create a user : “Errno::EACCES (Permission denied @ dir_s_mkdir – /var/www/vhosts/itsmyskills.com/lab.itsmyskills.com/git-data/repositories/Sylvain):”
The folder owners are the same for uploads, backups and git-data : git:root
Here the rights for those 3 folders : rwx r-x r-x (755)
Versions :
Ruby 2.1.1
git 1.7.1
gitlab 8.3.2
Somebody can help me ?
Thanks in advance !
Hi Sylvain,
try to run sudo gitlab-ctl reconfigure, it should fix folder permissions for you.
As double check, try to list that folder (/var/www/vhosts/itsmyskills.com/lab.itsmyskills.com/git-data/repositories/Sylvain) as git user (su git from terminal), maybe some upper-level folder does not have the right permissions.
Finally, if you can’t solve, just leave repository folder outside virtualhost directory (in /var/opt/gitlab/git-data).
Hey, thanks for this toutorial, it helped me a lot.
But I intalled Gitlab 8.3.4 there I didn’t find the worhorse option. Does they change this back ?
And my gitlab subdomain shows up a 502 error with the message:
Whoops, GitLab is taking too much time to respond.
My System ist Ubuntu 14.04 with plesk 12.5.
Maybe you have an idea what I am doing wrong?
Thanks
Hi Dominic,
GitLab v8.4.0 is out, and it still uses gitlab-workhorse.
Make sure these lines are included in your /etc/nginx/conf.d/gitlab.conf:
upstream gitlab-workhorse {
server localhost:8181;
}
Regarding your 502 error, it could be anything: you should check GitLab logs located in /var/log/gitlab to gather further details.
So I did a full reinstall of GitLab v8.4.1
So gitlab-ctl tail puts out:
==> /var/log/gitlab/sidekiq/current /var/log/gitlab/unicorn/current <==
2016-01-26_16:35:06.79546 failed to start a new unicorn master
2016-01-26_16:35:06.80558 starting new unicorn master
2016-01-26_16:35:07.10485 Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
2016-01-26_16:35:07.11661 bundler: command not found: unicorn
2016-01-26_16:35:07.12170 Install missing gem executables with `bundle install`
But I have no Idea what to do with this error ?
Ruby: 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
Gem: 1.8.23
Bundler: 1.11.2
Any help would be nice 😉
I think you’d better upgrade your Ruby and Gem packages since, as described in the article, GitLab was designed for Ruby v2.0+.
I can tell you GitLab v8.4.1 will surely run with the following packages (tested on CentOS v6.7):
Ruby: 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
Gem: 2.4.8
Bundler: 1.11.0 (older than yours)
Let me know 😉
Hey,
the update remove some of the errors.
Now I get a few new one 😀
First I get: find: `/var/log/gitlab/logrotate’: Permission denied
But I don’t know who needs the permission. Then this is very simple.
The second error maybe is a little bit complicated.
fatal: Not a git repository (or any of the parent directories): .git
Thanks for your support. 😉
Hi Dominic,
as already written for Sylvain’s issues, try to run sudo gitlab-ctl reconfigure, it should fix folders permissions for you.
As double check, try to open /var/log/gitlab/logrotate as git user (su git from terminal): if you can’t, you’ll probably need to chown that file.
“Not a git repository error” seems to be a permission error too: try to list the data folder as git user and, if you can’t solve, just leave repository folder in the default location (/var/opt/gitlab/git-data).
Thank you for this tutorial it got me on the right path. I am running Plesk 12 on Ubuntu 14.04 with the latest gitlab omnibus and could not for the life of me get the permissions right on the gitlab folders within my vhosts domain so I’m using the default instead.
Is there any great benefit to keeping uplaods and data within the do!aims folders?
Hi Ryan,
a benefit could be the ability to include GitLab data in Plesk virtual host scheduled backup, without having to backup your repository’s data separately.
Maybe you should think about moving just backup folder into your vhost folder and keep data and uploads in the default ones.
Of course, if you don’t use a remote device (NAS, other server via FTP, etc…) for backup, there’s really no difference between Plesk backup and GitLab one, since both will stay on the same server that holds the data.
Hi first let me say nice tutorial.
But I have a problem getting it to work, each time I try to connect I get this in the v_host proxy error log:
[crit] 3001#0: *5223 connect() to unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket failed (13: Permission denied) while connecting to upstream, client: ****, server:****, request: “GET / HTTP/1.1”, upstream: “http://unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket:/”, host: “****”
Which tells me that the process can’t access the socket.
I already tried to add niginx/www-data to the git and the gitlab-www group as well as setting this in the config:
web_server[‘external_users’] = [‘www-data’]
But nothing helps.
I’m trying this on Debian 7.9 and gitlab version 8.6
Any idea what I can do to fix this problem?
Ok feeling a bit silly now, cause it suddenly works but I don’t know why (didn’t change anything)
Hi all, when I execute the following:
[root@localhost]# yum install gcc zlib zlib-devel openssl-devel
[root@localhost]# mkdir /tmp/ruby && cd /tmp/ruby
[root@localhost ruby]# curl –progress ftp://ftp.ruby-lang.org/pub/ruby/2.1/ruby-2.1.9.tar.gz | tar xz
[root@localhost ruby]# cd ruby-2.1.9/ext/openssl/
[root@localhost openssl]# ruby extconf.rb
I got this:
checking for t_open() in -lnsl… no
checking for socket() in -lsocket… no
checking for assert.h… yes
checking for openssl/ssl.h… yes
checking for openssl/conf_api.h… yes
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.
Provided configuration options:
–with-opt-dir
–without-opt-dir
–with-opt-include
–without-opt-include=${opt-dir}/include
–with-opt-lib
–without-opt-lib=${opt-dir}/lib
–with-make-prog
–without-make-prog
–srcdir=.
–curdir
–ruby=/usr/bin/ruby
–with-openssl-dir
–without-openssl-dir
–with-openssl-include
–without-openssl-include=${openssl-dir}/include
–with-openssl-lib
–without-openssl-lib=${openssl-dir}/lib
–with-kerberos-dir
–without-kerberos-dir
–with-kerberos-include
–without-kerberos-include=${kerberos-dir}/include
–with-kerberos-lib
–without-kerberos-lib=${kerberos-dir}/lib
–with-debug
–without-debug
–enable-debug
–disable-debug
–with-nsllib
–without-nsllib
–with-socketlib
–without-socketlib
–with-openssl-config
–without-openssl-config
–with-pkg-config
–without-pkg-config
–with-broken-apple-openssl
–without-broken-apple-openssl
/tmp/ruby/ruby-2.1.9/ext/openssl/deprecation.rb:8:in `deprecated_warning_flag’: undefined method `<<' for nil:NilClass (NoMethodError)
from /tmp/ruby/ruby-2.1.9/ext/openssl/deprecation.rb:18:in `check_func'
from extconf.rb:61
[root@localhost openssl]#
What I'm missing?
Any help would be appreciated
I run into 403 forbidden from external call.
If I call from shell wget localhost:8181 i receive the index.html from gitlab => /users/sign_in/index.html
It’s a permission issue, like i can see in the error.log
”’
directory index of “/var/www/vhosts/myserver.com/gitlab.myserver.com/” is forbidden
”’
I tried so many things but I don’t get it.
System:
Debian 8,6
Plesk Onyx 17.0.17 Nr.17
Gitlab latest from Omnibus
Configuration:
/etc/gitlab/gitlab.rb
nginx[‘enable’] = false
nginx[‘redirect_http_to_https’] = true
nginx[‘listen_https’] = false # override only if your reverse proxy internally communicates over HTTP: https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl
# web_server[‘external_users’] = [‘www-data’] ## tried with and without
external_url ‘https://gitlab.myserver.com’
gitlab_rails[‘gitlab_email_enabled’] = true
gitlab_rails[‘gitlab_email_from’] = ‘gitlab@myserver.com’
gitlab_rails[‘gitlab_email_display_name’] = ‘GitLab’
gitlab_rails[‘gitlab_email_reply_to’] = ‘gitlab@myserver.com’
gitlab_rails[‘backup_path’] = “/var/www/vhosts/myserver.com/gitlab.myserver.com/backups”
gitlab_rails[‘backup_keep_time’] = 604800
git_data_dir “/var/www/vhosts/myserver.com/gitlab.myserver.com/git-data”
gitlab_rails[‘uploads_directory’] = “/var/www/vhosts/myserver.com/gitlab.myserver.com/uploads”
gitlab_rails[‘smtp_enable’] = true
gitlab_rails[‘smtp_address’] = “mail.myserver.com”
gitlab_rails[‘smtp_port’] = 25
gitlab_rails[‘smtp_user_name’] = “gitlab@myserver.com”
gitlab_rails[‘smtp_password’] = “123456789”
gitlab_rails[‘smtp_domain’] = “mail.myserver.com”
gitlab_rails[‘smtp_authentication’] = “login”
gitlab_rails[‘smtp_enable_starttls_auto’] = true
gitlab_rails[‘smtp_tls’] = false
gitlab_rails[‘smtp_openssl_verify_mode’] = ‘none’
gitlab_workhorse[‘listen_network’] = “tcp”
gitlab_workhorse[‘listen_addr’] = “localhost:8181”
/etc/nginx/conf.d/gitlab.conf
upstream gitlab {
server unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket fail_timeout=0;
}
upstream gitlab-workhorse {
server localhost:8181;
}
Plesk Nginx Additional-Settings
location /uploads/ {
## If you use HTTPS make sure you disable gzip compression
## to be safe against BREACH attack.
# gzip off;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_pass http://gitlab;
}
location @gitlab {
## If you use HTTPS make sure you disable gzip compression
## to be safe against BREACH attack.
# gzip off;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Frame-Options SAMEORIGIN;
proxy_pass http://gitlab;
}
location ~ ^/[\w\.-]+/[\w\.-]+/gitlab-lfs/objects {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/api/v3/projects/.*/repository/archive {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ /ci/api/v1/builds/[0-9]+/artifacts {
client_max_body_size 0;
error_page 418 = @gitlab-workhorse;
return 418;
}
location @gitlab-workhorse {
client_max_body_size 0;
## If you use HTTPS make sure you disable gzip compression
## to be safe against BREACH attack.
# gzip off;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_buffering off;
# The following settings only work with NGINX 1.7.11 or newer
#
# # Pass chunked request bodies to gitlab-workhorse as-is
# proxy_request_buffering off;
# proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://gitlab-workhorse;
}
location ~ ^/(assets)/ {
root /opt/gitlab/embedded/service/gitlab-rails/public;
gzip_static on; # to serve pre-gzipped version
expires max;
add_header Cache-Control public;
}
location ~ / {
root /opt/gitlab/embedded/service/gitlab-rails/public;
try_files $uri $uri/index.html $uri.html @gitlab;
}
error_page 502 /502.html;
Are there any ideas? Thanks a lot for your help.
Hi Stefan,
Yes, it seems to be a permission issue on /var/www/vhosts/myserver.com/gitlab.myserver.com/ folder.
The git user of git group cannot list that folder.
You can try with:
chown -R git.git /var/www/vhosts/myserver.com/gitlab.myserver.com/
or, when everything else fails, with (not recommended):
chmod -R 777 /var/www/vhosts/myserver.com/gitlab.myserver.com/
If this solves your problem, then you can further investigate on how to use a different user for GitLab instead of the default one (git).
Hi Fulvio,
thanks for your help.
It doesn’t work. I tried this before, but I tried again. Without solving the issue.
The error ist still the same:
directory index of “/var/www/vhosts/myserver.com/gitlab.myserver.com/” is forbidden, client: XXX.XXX.XXX.XXX, server: gitlab.myserver.com, request: “GET / HTTP/1.1”, host: “gitlab.myserver.com”
Any other ideas?
Same problem here. I tried everything and I can not solve the issue.
Any ideas?
Hi Stefan and Ibai,
another thing you should try is try to reach the path set in the configuration with the user that is supposed to use it.
For example, if your GitLab instance uses “git” user, you can try:
su git
cd /var/www/vhosts/myserver.com/gitlab.myserver.com/
If you got (as I think) permission denied, you can try a level at the time (/var/, then /var/www/ and so on) to see which is the first unreachable path due to permissions.
If you don’t really need GitLab folders to be under your domain path, you can easily create them at the top level and then change their owner, i.e. something like:
mkdir /gitlab/data
mkdir /gitlab/backup
chown -R git.git /gitlab
I really hope you can finally manage this issue 🙂
Hi Fulvio,
I had to renew my plesk, so I started from 0.
Got the same error, but found someone who fix it by switching the proxy_pass in the plesk nginx-setting
# proxy_pass http://gitlab;
proxy_pass http://127.0.0.1:8181;
this worked for me.
But I found a new issue. Don’t know, if it belongs together?!
If I try to update my User-Profile, nothing is updated and after refresh there are still the same values.
Hi Stefan,
you may have a permission issue on uploads folder.
Check your GitLab health status with the following command:
gitlab-rake gitlab:app:check
Hi Fulvio,
I helped myself today by the comments of your readers. With Apache, Gitlab showed no CSS / JS on the root server with Plesk. Now after I found your article, I wanted to try it with “nginx”.
It worked wonderfully well and I wanted to thank you very much. I searched in Google for “plesk gitlab install”.
Hello,
Thanks for your tutorial…
I can’t even start. Each time I run ‘gitlab-ctl reconfigure’ there are errors with services, it’s not allways the same error, so I can’t even debug it….