CentOSProgrammazione

Installare e configurare GitLab con Plesk 12 su CentOS 6

Iniziamo col capire di cosa stiamo parlando: Git è un sistema software di version control distribuito (DVCS – Distributed Version Control System), creato nel 2005 da Linus Torvalds, programmatore finlandese noto in quanto autore della prima versione del kernel Linux.

In breve, esso consente di tenere traccia delle modifiche apportate al codice sorgente di un software (commit) e delle sue versioni (tag), lavorare parallelamente su un altro “ramo” dello stesso software (branch) e unire le proprie modifiche a quelle degli altri sviluppatori (merge).

Il tutto viene gestito mediante una repository, la più famosa delle quali è GitHub, che tuttavia è una repository online.

Questo tutorial è rivolto a tutti quelli che vogliono disporre invece di una repository Git personale (ed eventualmente privata) sul proprio server, nel caso particolare in cui su quest’ultimo sia installato CentOS con Parallels Plesk e si usi GitLab come piattaforma per la repository.

In tal caso, infatti, la coesistenza tra GitLab, Nginx e i virtual host di Plesk può diventare difficile da gestire: se siete arrivati qui, avrete sicuramente notato che in rete esistono informazioni frammentate su come procedere senza avere problemi, da cui il motivo di questo tutorial.

Iniziamo dunque: assumiamo che abbiate un server Linux CentOS v6.5 con Plesk installato (abbiamo utilizzato la versione 12.5.30 come riferimento, ma la procedura è stata testata anche sulla versione 12.0.18).

Fase 1 – Prerequisiti

Assumiamo ovviamente che siate root sul server o che il vostro utente sia almeno nella lista dei sudoers, così da avere diritti sufficienti ad installare i pacchetti. La prima cosa da fare è installare l’ultima versione di Git (al momento la 1.8.3.1) dalla PUIAS Computational repository:

wget -O /etc/yum.repos.d/PUIAS_6_computational.repo https://gitlab.com/gitlab-org/gitlab-recipes/raw/master/install/centos/PUIAS_6_computational.repo
wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-puias http://springdale.math.ias.edu/data/puias/6/x86_64/os/RPM-GPG-KEY-puias
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-puias
sudo yum install git

o, per l’ultima versione (attualmente la 2.6.1):

yum install gettext-devel expat-devel curl-devel zlib-devel openssl-devel
cd /tmp
wget https://www.kernel.org/pub/software/scm/git/git-2.6.1.tar.gz
tar xzvf git-2.6.1.tar.gz
cd git-2.6.1
make prefix=/opt/git all
make prefix=/opt/git install
export PATH="/opt/git/bin:$PATH"
ln -s /opt/git/bin/git /usr/bin/git

Verificatene l’installazione con:

git --version

Avremo quindi bisogno di installare Ruby, in quanto GitLab nasce per Ruby v2.0+, sebbene possa funzionare anche con versioni inferiori come quella disponibile nella repository CentOS. Per un’installazione rapida della versione più vecchia (attualmente la 1.8.7.374) lanciate:

yum install ruby

Se invece volete che la versione sia quella ultima (2.1.2 al momento), vi basterà lanciare i seguenti comandi per installare i prerequisiti, l’estensione OpenSSL e Ruby:

yum install gcc zlib zlib-devel openssl-devel
mkdir /tmp/ruby && cd /tmp/ruby
curl --progress ftp://ftp.ruby-lang.org/pub/ruby/2.1/ruby-2.1.2.tar.gz | tar xz
cd ruby-2.1.2/ext/openssl/
ruby extconf.rb
make top_srcdir="../../"
sudo make install top_srcdir="../../"
cd ../../
./configure --disable-install-rdoc
make
sudo make prefix=/usr/local install

Ora utilizzate il comando gem per installare Bundler, un gestore di dipendenze per Ruby:

gem install bundler --no-doc
Articolo precedente

Aggiornare a Windows 10 senza icona di aggiornamento

Articolo successivo

Microsoft Visual Studio 2015 installer offline

Fulvio Sicurezza

Fulvio Sicurezza

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

Lascia un commento

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