CentOSProgrammazione

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
Articolo precedente

Aggiornare a Windows 10 senza icona di aggiornamento

Articolo successivo

Microsoft Visual Studio 2015 installer offline

Fulvio Sicurezza

Fulvio Sicurezza

35 Commenti

  1. Mika
    14 dicembre 2015 at 01:05 — Rispondi

    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

  2. Fulvio Sicurezza
    14 dicembre 2015 at 19:13 — Rispondi

    Hi Mika,

    which version of GitLab did you install on your server?

  3. Mika
    14 dicembre 2015 at 22:55 — Rispondi

    I did an update yesterday and I currently have the 8.2.3

  4. Oizo
    14 dicembre 2015 at 23:53 — Rispondi

    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

    • Oizo
      15 dicembre 2015 at 00:12 — Rispondi

      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.

      • Fulvio Sicurezza
        17 dicembre 2015 at 11:49 — Rispondi

        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?

  5. Oizo
    15 dicembre 2015 at 16:02 — Rispondi

    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;
    }

  6. Fulvio Sicurezza
    16 dicembre 2015 at 11:44 — Rispondi

    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.

  7. Mika
    16 dicembre 2015 at 20:06 — Rispondi

    Hi,

    I tried adding your configuration but still not working, I’m always having the json displayed.

    • Fulvio Sicurezza
      17 dicembre 2015 at 11:42 — Rispondi

      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.

  8. Fulvio Sicurezza
    17 dicembre 2015 at 11:39 — Rispondi

    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?

  9. Mika
    20 dicembre 2015 at 15:32 — Rispondi

    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 !

    • Chris
      6 maggio 2017 at 11:58 — Rispondi

      Same here, we’re using Plesk 17.5 and GitLab 9.1

  10. Sylvain Marty
    9 gennaio 2016 at 14:52 — Rispondi

    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 !

    • Fulvio Sicurezza
      23 gennaio 2016 at 10:00 — Rispondi

      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).

  11. Dominic
    20 gennaio 2016 at 08:56 — Rispondi

    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

    • Fulvio Sicurezza
      23 gennaio 2016 at 10:19 — Rispondi

      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.

      • Dominic Warzok
        26 gennaio 2016 at 17:38 — Rispondi

        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 😉

        • Fulvio Sicurezza
          27 gennaio 2016 at 11:51 — Rispondi

          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 😉

          • Dominic
            31 gennaio 2016 at 16:05

            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. 😉

          • Fulvio Sicurezza
            8 febbraio 2016 at 08:28

            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).

  12. Ryan
    8 febbraio 2016 at 04:03 — Rispondi

    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?

    • Fulvio Sicurezza
      8 febbraio 2016 at 08:22 — Rispondi

      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.

  13. Kai
    7 aprile 2016 at 11:50 — Rispondi

    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?

    • Kai
      7 aprile 2016 at 12:15 — Rispondi

      Ok feeling a bit silly now, cause it suddenly works but I don’t know why (didn’t change anything)

  14. Alain Sanchez
    19 agosto 2016 at 18:24 — Rispondi

    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

  15. Stefan
    7 marzo 2017 at 11:56 — Rispondi

    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.

    • Fulvio Sicurezza
      7 marzo 2017 at 14:12 — Rispondi

      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).

      • Stefan
        14 marzo 2017 at 08:30 — Rispondi

        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?

        • Ibai
          16 marzo 2017 at 10:56 — Rispondi

          Same problem here. I tried everything and I can not solve the issue.
          Any ideas?

        • Fulvio Sicurezza
          20 marzo 2017 at 08:56 — Rispondi

          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 🙂

          • Stefan
            21 marzo 2017 at 10:05

            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.

          • Fulvio Sicurezza
            20 aprile 2017 at 08:51

            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

  16. 24 ottobre 2017 at 18:09 — Rispondi

    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”.

  17. santi
    7 agosto 2019 at 22:38 — Rispondi

    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….

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *