2014-01-24

I have been setting up a Git server on AWS cloud using GitLab Opensource software. GitLab is an excellent application for Managing Git repositories over web and a replacement of paid GitHub service. This software does support both ssh and http communication.

I prefer CentOS for hosting it. The following link is an excellent and error free documentation for describing GitLab installation on CentOS. See the link here,

https://github.com/gitlabhq/gitlab-recipes/tree/master/install/centos

My installation was perfectly go through and did not met any errors during the setup time. I uses,

1. Apache as webserver

2. MySQL as backend.

As soon as I completed the installation, the GitLab web UI does not showing up due to an error. It’s showing proxy timed out error and gitlab logs (/home/git/gitlab/log) does not showing any error and also I see that ruby is taking lot on cpu cycles during the time.

Solution : Increase the timeout value to 300.

 [root@host01 ~]# grep  "timeout"  /home/git/gitlab/config/unicorn.rb

timeout 300

[root@host01 ~]#

If you want to see GitLab ruby application without a web server, just change the “listen” parameter to your server IP (listen “192.168.0.111:8080″) and you can access it over the port 8080



The second challenge I had faced was, when I use “http” protocol for Git communication and been tried to push some changes to remote repository, it shows the following errors on my TortoiseGit output windows.

git.exe push --progress  "origin" master:master

Counting objects: 7, done.

Delta compression using up to 2 threads.

Compressing objects: 100% (5/5), done.

Writing objects: 100% (5/5), 1.17 KiB, done.

Total 5 (delta 1), reused 0 (delta 0)

remote: /usr/local/lib/ruby/gems/2.1.0/gems/bundler-1.5.2/lib/bundler/shared_helpers.rb:2:in `require': no such file to load -- rubygems (LoadError)

remote:     from /usr/local/lib/ruby/gems/2.1.0/gems/bundler-1.5.2/lib/bundler/shared_helpers.rb:2

remote:     from /usr/local/lib/ruby/gems/2.1.0/gems/bundler-1.5.2/lib/bundler/setup.rb:1:in `require'

remote:     from /usr/local/lib/ruby/gems/2.1.0/gems/bundler-1.5.2/lib/bundler/setup.rb:1

remote: error: hook declined to update refs/heads/master

To http://github.mydomain.com/rcadmin/gitsample.git

! [remote rejected] master -> master (hook declined)

error: failed to push some refs to 'http://github.mydomain.com/rcadmin/gitsample.git'

git did not exit cleanly (exit code 1) (17332 ms @ 1/23/2014 11:12:23 AM)

I searched on Google again and again in a random order for more than 3 days, Nothing gonna be worked. Finally I’m comparing system ruby setup which rubygem uses,

[root@host01 ~]# gem env

RubyGems Environment:

  - RUBYGEMS VERSION: 2.1.0

  - RUBY VERSION: 2.1.0 (2013-12-25 patchlevel 0) [x86_64-linux]

  - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/2.1.0

  - RUBY EXECUTABLE: /usr/local/bin/ruby

  - EXECUTABLE DIRECTORY: /usr/local/bin

  - SPEC CACHE DIRECTORY: /root/.gem/specs

  - RUBYGEMS PLATFORMS:

    - ruby

    - x86_64-linux

  - GEM PATHS:

     - /usr/local/lib/ruby/gems/2.1.0

     - /root/.gem/ruby/2.1.0

  - GEM CONFIGURATION:

     - :update_sources => true

     - :verbose => true

     - :backtrace => false

     - :bulk_threshold => 1000

  - REMOTE SOURCES:

     - https://rubygems.org/

  - SHELL PATH:

     - /usr/local/sbin

     - /usr/local/bin

     - /sbin

     - /bin

     - /usr/sbin

     - /usr/bin

     - /opt/aws/bin

     - /root/bin

[root@host01 ~]#

Solution :

Now I found that there were some ruby system references which would have cause to broke this unicorn activity. So I’m going to find the ruby system package status.

[root@rc090 ~]# rpm -qa |grep "ruby"

ruby-libs-1.8.7.352-13.el6.i686

ruby-irb-1.8.7.352-13.el6.i686

ruby-1.8.7.352-13.el6.i686

[root@rc090 ~]# rpm -e ruby-libs-1.8.7.352-13.el6.i686  --nodeps

[root@rc090 ~]# rpm -e ruby-irb-1.8.7.352-13.el6.i686 --nodeps

[root@rc090 ~]# rpm -e ruby-1.8.7.352-13.el6.i686 --nodeps

The above installed packages caused the custom Ruby install what I did during the GitLab installation time.

Now reboot the server and you may see he Http communiction working fine after this. Everything would work as expected !! Sit back and relax !

Note: This installation saves the amount which they spend for GitHub services and hence the source codes are keeping on our own server.

Author: Liju Mathew
Visit Liju's Website - Email Liju
I'm Liju, one linux enthusiastic who have been playing with Linux for more than 7 years. I'm curious about to read blog, learning and implementing new technologies from my personal experience. Like to be play with burning head on busy schedule :-) This is a bookmark of all challenges that I'd faced which would be helpful to others sometimes as I'd learn it from the same way :-)

Nothing more, I have to go miles, before I sleep

Show more