0

I have a CentOS 7 server with an existing website (say mywebsite.com) hosted with Apache. I would like GitLab to be managed by Apache and not nginx, and with a realtive url with respect to the one of my website (say mywebsite.com/gitlab). Is this feasible with the GitLab omnibus pacakge?

Edit: Some additional info about my configuration. Here is my apache main configuration file which should contain the information to resolve any request not matching any of the virtual hosts; I did not touch this file as far as GitLab installation is concerned.

/etc/httpd/conf/httpd.conf
pastebin link

The following is the configuration file I added in order to make apache resolve the virtual host (still trying to understand if a relative url virtual host is possible) with GitLab; I followed this guide for Apache 2.4 and GitLab Omnibus (the default recipe is this one).

/etc/httpd/conf.d/gitlab.conf

<VirtualHost *:80>
    ServerName mywebsite.com/gitlab
    ServerSignature Off

    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

    <Location />
        Require all granted
        ProxyPassReverse http://127.0.0.1:8181
        ProxyPassReverse http://mywebsite.com/gitlab
    </Location>

    RewriteEngine on

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
    RewriteCond %{REQUEST_URI} ^/uploads/.*
    RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

    DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public

    ErrorDocument 404 /404.html
    ErrorDocument 422 /422.html
    ErrorDocument 500 /500.html
    ErrorDocument 502 /502.html
    ErrorDocument 503 /503.html

    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
    ErrorLog /var/log/httpd/mywebsite_error.log
    CustomLog /var/log/httpd/mywebsite_forwarded.log common_forwarded
    CustomLog /var/log/httpd/mywebsite_access.log combined env=!dontlog
    CustomLog /var/log/httpd/mywebsite.log combined
</VirtualHost>

Finally, this is the configuration of GitLab Omnibus package; I changed the gitlab workhorse port, disabled nginx and set apache as external user for the web server. As far as the external user is concerned, I did not use www-data because no such user exists on my machine (gitlab-ctl reconfigure also gave errors if I tried to use www-data). I imagine apache is the correct one, due to the "User apache" directive in httpd.conf, but I am not absolutely sure about that.

/etc/gitlab/gitlab.rb

external_url 'http://mywebsite.com/gitlab'

gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

web_server['external_users'] = ['apache']
nginx['enable'] = false

With such configuration my website is not working: every page shows the 503 GitLab error "Whoops, GitLab is currently unavailable. Try refreshing the page, or going back and attempting the action again."; what could be the reason for that? Note that if I remove the gitlab.conf file and reload httpd, the normal website works fine. Also, if I disable apache and only run GitLab (with nginx) with default configuration on the relative url, everything works fine too; I just can't put the two things togeter, relative url and apache instead of nginx.

  • You seem to be looking for this bit of the documentation: docs.gitlab.com/omnibus/settings/… – Haxiel Apr 2 at 15:18
  • I tried to follow the documentation and everything seems to be fine, but when I browse the website, after having followed those steps, every page seems to "belong" to GitLab and shows a 503 error, including the relative url mywebsite.com/gitlab – user415115 Apr 2 at 20:56
  • Perhaps you can share your configuration here and point out what works and what doesn't. It's hard to debug an Apache problem without looking at the configuration file. – Haxiel Apr 3 at 3:46
  • You're totally right, sorry for that. I updated the post – user415115 Apr 4 at 7:59
  • Sorry for the delayed update. I think the problem here is that the new virtual host hijacks your existing server configuration, making all the URLs owned by GitLab. I believe you can instead confine your changes to the /gitlab URL using the Location directive. I'll try and reproduce this problem myself. – Haxiel Apr 5 at 16:08
1

This solution is working on a CentOS 7 web server with Apache 2.4.6 and GitLab 11.9.4 installed by means of GitLab Omnibus package. The server is running on http but it should be easily transferrable to https.

I suppose to start from a clean installation of Apache managing only one single host on the domain mywebsite.com (no virtual host). Clean installation of GitLab Omnibus package is also supposed (official guide). For the sake of completeness, here is the httpd.conf file, main configuration file of Apache. It contains the directives to listen to port 80 and direct all the requests to the main domain mywebsite.com to the directory specified by DocumentRoot directive, which is /var/www/html; in my case such directory contains a WordPress instance.

/etc/httpd/conf/httpd.conf
httpd.conf on Pastebin

Now, before editing GitLab configuration, be sure to stop all the related services with sudo gitlab-ctl stop. To enable GitLab to work on a relative URL, as a subdirectory of the main domain mywebsite.com, first thing first is to install GitLab on a relative URL; in particular, you have to modify the external_url directive of gitlab.rb setting 'http://mywebsite.com/gitlab' as argument. Then, nginx, which is the default web server bundled in GitLab Omnibus, has to be disabled; the external user for the web server has to be set to apache (external user for Apache is www-data in most distro, but apache for CentOS 7); GitLab workhorse has to be set to listen to tcp since Apache can only use http sockets; in the following it is supposed that GitLab workhorse listens to port 8181, which is also to be set. To keep the GitLab installation simple, I also disabled the CI/CD functionalities for pipeline (with the gitlab_rails directive), but this rather depends on your needs.
See the official GitLab Omnibus documentation to know more about configuring a relative URL and using a non-bundled web server. The resulting configuration file for GitLab should be something like the following.

/etc/gitlab/gitlab.rb

external_url 'http://mywebsite.com/gitlab'

gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

web_server['external_users'] = ['apache']
nginx['enable'] = false

gitlab_rails['gitlab_default_projects_features_builds'] = false

Now run a sudo gitlab-ctl reconfigure. Let's go back to Apache configuration: now GitLab is set-up, but we have to redirect all the requests to http://mywebsite.com/gitlab to the actual GitLab server. Most solutions I found suggest to use subfolder with virtual hosts, but this appears not to work with GitLab. The solution is to use the Location directive; you can either append such configuration in the main apache configuration file httpd.conf or create a new .conf file and place it in /etc/httpd/conf.d/, so that it will be included automatically (but be sure that your httpd.conf contains the directive IncludeOptional conf.d/*.conf). The configuration is the following.

/etc/httpd/conf.d/gitlab.conf

Header add Strict-Transport-Security: "max-age=15768000;includeSubdomains"

<Location /gitlab>
  Require all granted

  #Allow forwarding to gitlab-workhorse
  ProxyPassReverse http://127.0.0.1:8181
  ProxyPassReverse http://mywebsite.com/gitlab

  RewriteEngine on

  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
  RewriteCond %{REQUEST_URI} ^/uploads/.*
  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

  ErrorDocument 404 /404.html
  ErrorDocument 422 /422.html
  ErrorDocument 500 /500.html
  ErrorDocument 502 /502.html
  ErrorDocument 503 /503.html
</Location>
</VirtualHost>

Be sure to modify the argument of <Location /gitlab> basing on the relative URL on which you want GitLab to be reacheable.
The configuration is now complete, run systemctl reload httpd to reconfigure Apache and restart GitLab with sudo gitlab-ctl restart. One more thing: be sure to allow Apache to use the http sockets: sudo setsebool -P httpd_can_network_connect=1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.