I realize this question is a few years old, but I've been playing with a similar setup recently (but without the ISPConfig installation). Throwing in my 2 cents for others who may run across this (this is my first time answering, so take it easy on me).
NOTE The op has not specified the version of GitLab being used. More recent versions of GitLab are probably using newer versions of gitlab.rb so I'm not sure if that will make a difference.
NOTE 2 I have found great information directly from GitLab at this site: https://docs.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server. This is basically a copy and paste, but I'm throwing in my own notes to help out where I had issues as a complete n00b.
- Disable bundled Nginx
In /etc/gitlab/gitlab.rb set:
nginx['enable'] = false
- Set the username of the non-bundled web-server user
By default, omnibus-gitlab has no default setting for the external
webserver user, you have to specify it in the configuration. For
Debian/Ubuntu the default user is www-data for both Apache/Nginx
whereas for RHEL/CentOS the Nginx user is nginx.
Note: Make sure you have first installed Apache/Nginx so the webserver
user is created, otherwise omnibus will fail while reconfiguring.
Let's say for example that the webserver user is www-data. In
/etc/gitlab/gitlab.rb set:
web_server['external_users'] = ['www-data']
Note: This setting is an array so you can specify more than one user
to be added to gitlab-www group. Personal Note: Please pay
close attention to the single-quotes and the array here. While
developing, I've rebuild my gitlab server multiple times and entered
in JUST a string or JUST an array and both will fail. The Chef script
will use this value to set up file permissions for its internal
directories, so Apache will not be able to write to files if this is
not correct.
Run sudo gitlab-ctl reconfigure for the change to take effect.
Note: if you are using SELinux and your web server runs under a
restricted SELinux profile you may have to loosen the restrictions on
your web server.
*Note: make sure that the webserver user has the correct permissions on all directories used by external web-server, otherwise you will
receive failed (XX: Permission denied) while reading upstream errors.
- Add the non-bundled web-server to the list of trusted proxies (OPTIONAL: This is only required if your web server is on a
different machine from your gitlab instance)
Normally, omnibus-gitlab defaults the list of trusted proxies to the
what was configured in the real_ip module for the bundled NGINX.
For non-bundled web-servers the list needs to be configured directly,
and should include the IP address of your web-server if it not on the
same machine as GitLab. Otherwise users will be shown as being signed
in from your web-server's IP address.
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
- (Optional) Set the right gitlab-workhorse settings if using Apache PERSONAL NOTE: I believe this is the missing config from the op's question.
Note: The values below were added in GitLab 8.2, make sure you have
the latest version installed.
Apache cannot connect to a UNIX socket but instead needs to connect to
a TCP Port. To allow gitlab-workhorse to listen on TCP (by default
port 8181) edit /etc/gitlab/gitlab.rb:
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
Run sudo gitlab-ctl reconfigure for the change to take effect.
- Download the right web server configs
Go to GitLab recipes repository and look for the omnibus configs
in the webserver directory of your choice. Make sure you pick the
right configuration file depending whether you choose to serve GitLab
with SSL or not. The only thing you need to change is YOUR_SERVER_FQDN
with your own FQDN and if you use SSL, the location where your SSL
keys currently reside. You also might need to change the location of
your log files.
For the sake of completeness, here is an example of the Apache v2.4 config without the SSL configuration: READ THE COMMENTS: If you followed my above notes, in step 4 the gitlab_workhorse has already been configured to listen on tcp instead of a unix socket so that line may be ignored. DO NOT IGNORE the module dependencies! These are required for Apache to be able to proxy requests to your gitlab instance. On Ubuntu (I'm using Ubuntu Server 16.04.4, but I believe most other Ubuntu version react the same), these modules can be activated using sudo a2enmod rewrite proxy proxy_http.
# This configuration has been tested on GitLab 8.2
# Note this config assumes unicorn is listening on default port 8080 and
# gitlab-workhorse is listening on port 8181. To allow gitlab-workhorse to
# listen on port 8181, edit or create /etc/default/gitlab and change or add the following:
#
# gitlab_workhorse_options="-listenUmask 0 -listenNetwork tcp -listenAddr 127.0.0.1:8181 -authBackend http://127.0.0.1:8080"
#
#Module dependencies
# mod_rewrite
# mod_proxy
# mod_proxy_http
<VirtualHost *:80>
ServerName YOUR_SERVER_FQDN
ServerSignature Off
ProxyPreserveHost On
# Ensure that encoded slashes are not decoded but left in their encoded state.
# http://doc.gitlab.com/ce/api/projects.html#get-single-project
AllowEncodedSlashes NoDecode
<Location />
# New authorization commands for apache 2.4 and up
# http://httpd.apache.org/docs/2.4/upgrading.html#access
Require all granted
#Allow forwarding to gitlab-workhorse
ProxyPassReverse http://127.0.0.1:8181
ProxyPassReverse http://YOUR_SERVER_FQDN/
</Location>
# Apache equivalent of nginx try files
# http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
# http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
RewriteEngine on
#Forward all requests to gitlab-workhorse except existing files like error documents
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
# needed for downloading attachments
DocumentRoot /home/git/gitlab/public
#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 502 /502.html
ErrorDocument 503 /503.html
# It is assumed that the log directory is in /var/log/httpd.
# For Debian distributions you might want to change this to
# /var/log/apache2.
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
ErrorLog /var/log/httpd/logs/YOUR_SERVER_FQDN_error.log
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN_forwarded.log common_forwarded
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN_access.log combined env=!dontlog
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN.log combined
</VirtualHost>
This config file will not work with a simple copy and paste!
Find and replace "YOUR_SERVER_FQDN" with the Fully Qualified Domain Name of your gitlab instance. Per the op's question, this would be http://gitlab.example.ee, but should basically match the value of external_url from your gitlab.rb file.
Find and replace "httpd" with "apache". The config was not designed with a Ubuntu server in mind and the appropriate directory is called "apache". I would assume you could also use ${APACHE_LOG_DIR}, but I have not tested this myself.
For a basic setup, this should work fine. I would highly recommend looking into using the SSL setup (documentation can be found at the links provided). Even if you don't need a secure setup (maybe this is an internal server), other features in the omnibus, like Mattermost, are prone to throw errors without SSL enabled (and not with a self-signed certificate).
