GitLab

Created by: ghost

Hi,

I just follow your Install instructions, and another readme to configure Apache2 with Gitlab. When I try to connect with my sub.domain.com I have this message

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /users/sign_in.

Reason: Error reading from remote server

Apache/2.2.16 (Debian) Server at sub.domain.com Port 80

With these configurations

<VirtualHost *:80>
        ServerName sub.domain.com

        DocumentRoot /home/gitlab/gitlab/public

        <Directory /home/gitlab/gitlab/public>
                AllowOverride All
                Options -MultiViews
        </Directory>

        ProxyPass / http://127.0.0.1:8080/
        ProxyPassReverse / http://127.0.0.1:8080/

        ErrorLog ${APACHE_LOG_DIR}/gitlab_error.log
        CustomLog ${APACHE_LOG_DIR}/gitlab_access.log combined
</VirtualHost>

mod_proxy and mod_proxy_http are enabled with this command a2enmod proxy proxy_http

root@ks351246:~# clear
#
# PRODUCTION
#
production:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_production
  pool: 5
  username: gitlab
  password: gitlab
  # host: localhost
  # socket: /tmp/mysql.sock

#
# Development specific
#
development:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_development
  pool: 5
  username: gitlab
  password: gitlab
  # socket: /tmp/mysql.sock

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test: &test
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: gitlabhq_test
  pool: 5
  username: root
  password:
  # socket: /tmp/mysql.sock

A user named gitlab has been created for the gitlabhq_production database.

app_dir = "/home/gitlab/gitlab/"
worker_processes 2
working_directory app_dir

# Load app into the master before forking workers for super-fast
# worker spawn times
preload_app true

# nuke workers after 30 seconds (60 is the default)
timeout 30

# listen on a Unix domain socket and/or a TCP port,

#listen 8080 # listen to port 8080 on all TCP interfaces
listen "127.0.0.1:8080"  # listen to port 8080 on the loopback interface
#listen "#{app_dir}/tmp/sockets/gitlab.socket"

pid "#{app_dir}/tmp/pids/unicorn.pid"
stderr_path "#{app_dir}/log/unicorn.stderr.log"
stdout_path "#{app_dir}/log/unicorn.stdout.log"

# http://www.rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
if GC.respond_to?(:copy_on_write_friendly=)
  GC.copy_on_write_friendly = true
end


before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect!

  ##
  # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
  # immediately start loading up a new version of itself (loaded with a new
  # version of our app). When this new Unicorn is completely loaded
  # it will begin spawning workers. The first worker spawned will check to
  # see if an .oldbin pidfile exists. If so, this means we've just booted up
  # a new Unicorn and need to tell the old one that it can now die. To do so
  # we send it a QUIT.
  #
  # Using this method we get 0 downtime deploys.

  old_pid = "#{server.config[:pid]}.oldbin"

  if File.exists?(old_pid) && server.pid != old_pid
    begin
      sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(sig, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
end

after_fork do |server, worker|
  # Unicorn master loads the app then forks off workers - because of the way
  # Unix forking works, we need to make sure we aren't using any of the parent's
  # sockets, e.g. db connection

  defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
  # Redis and Memcached would go here but their connections are established
  # on demand, so the master never opens a socket
end

Any idea ?

Thank you.