How to upgrade Gitlab 5.0 to 5.1 on CentOS 6 or RHEL6

Last modified: [last-modified]

These are instructions on how to upgrade Gitlab 5.0 to 5.1 on CentOS 6.

This guide assumes you already followed my How to install Gitlab 5.0 on CentOS 6 or RHEL6 post.

  1. As the root user stop the Gitlab service
    [[email protected] ~] service gitlab stop
    # Wait a few moments before continuing. Shutting down Gitlab took 30sec-1min on my system.


  2. Switch to the ‘sa_gitlab’ user account and move into your gitlab directory
    [[email protected] ~] su - sa_gitlab
    [[email protected]~] cd gitlab


  3. Update Gitlab source from 5.0 to 5.1
    [[email protected]~] git fetch
    [[email protected]~] git checkout 5-1-stable


  4. Configure Puma which is replacing Unicorn
    [[email protected]~] cp config/puma.rb.example config/puma.rb
    [[email protected]~] vim config/puma.rb
    # -------- Make the following edits --------
      application_path = '/data/apps/sa_gitlab/gitlab'
      bind 'tcp://'
    # -------- Save and close the file --------


  5. Redeploy Gitlab (I think that’s what this does anyway)
    # You may not need to do this. I ran into some errors during my upgrade but my ISP was having problems at the time. It won't hurt to run these commands either way.
    [[email protected]~] gem install sanitize -v '2.0.3'
    [[email protected]~] gem install jquery-rails -v '2.1.3'
    # These commands you DO need to run
    [[email protected]~] bundle install --without development test postgres --deployment
    [[email protected]~] bundle exec rake db:migrate RAILS_ENV=production
    [[email protected]~] bundle exec rake migrate_merge_requests RAILS_ENV=production
    # When prompted choose 'Yes'


  6. Switch back to root and update the Gitlab start-up script
    [[email protected]~] exit
    [[email protected] ~] mv /etc/init.d/gitlab /etc/init.d/gitlab.50
    [[email protected] ~] curl --output /etc/init.d/gitlab
    [[email protected] ~] vim /etc/init.d/gitlab
    # -------- Make the following edits --------
    # The lines with a + are lines you need to add to the script
    + APP_USER="sa_gitlab"
    # Search/Replace "sudo -u git" with "sudo -u $APP_USER"
    # -------- Save and close the file --------
    [[email protected] ~] chmod +x /etc/init.d/gitlab


  7. Start up Gitlab and then restart Apache if your using mod_proxy
    [[email protected] ~] service gitlab start
    [[email protected] ~] service httpd restart


  8. Update Gitlab Shell
    [[email protected] ~] su - sa_gitlab
    [[email protected]~] cd gitlab-shell
    [[email protected]~] git pull
    [[email protected]~] bin/install
    [[email protected]~] bin/check

All done! Hopefully this went slightly more smoothly for you then it did me. I noticed the first time loading Gitlab after the upgrade as a bit slow but things were nice and quick after that.

Updated April 26th, 2013 – Added instructions for updating Gitlab shell.

Updated May 22nd, 2013 – Wrote an article on How to go from 5.1 to 5.2

How to update Gitlab 5.0 in place

Last modified: [last-modified]

It’s been a few days since I deployed Gitlab following an earlier article I posted. Now I want to check for updates and apply them. It’s actually pretty straight forward.

This article assumes you followed my earlier one in how to setup Gitlab 5.0 on CentOS 6. It also only performs updates within the 5.0 branch of Gitlab. It will not get you to say 5.1 when that gets released.

  1. Stop Gitlab
    # As ROOT
    [[email protected]~] service gitlab stop
  2. Switch to the Gitlab user and update Gitlab and Gitlab-shell
    [[email protected]~] su - sa_gitlab
    [[email protected]~] cd ~/gitlab
    [[email protected]~] git pull
    [[email protected]~] bundle install
    [[email protected]~] cd ~/gitlab-shell
    [[email protected]~] git pull
  3. Switch back to root and restart Gitlab
    # As ROOT
    [[email protected]~] service gitlab start

How to install Gitlab 5.0 on CentOS 6 or RHEL6

Last modified: [last-modified]

I’ve been eagerly waiting for Gitlab 5.0 to be released so that Gitolite dependency would go away. Well a few days ago I got my wish. I followed the documentation provided by the Gitlab guys at  and as expected it didn’t quite match up with what needs to be done to deploy on CentOS 6. It is after all written for Ubuntu. These instructions should also work for Redhat Enterprise 6 and are meant for a fresh installation. Not an upgrade.

Using the official document as a guide I managed to get things deployed on my system and now I’m going to share it with you.

I installed Gitlab 5.0 on CentOS 6.4 64-bit and used MySQL as my database back end and configured my existing Apache deployment to proxy connections to Gitlab. I also installed it under a custom user account and not the default ‘git’ account that the Gitlab documentation tells you to use.

I’m going to assume you already have a CentOS server up and running, SELinux is disabled, you aren’t using a firewall (iptables), the default CentOS Python 2.6 packages installed and Sendmail or Postfix up and running.

If you are running a Minimal Install of CentOS 6 see Olav’s comment below.

Unfortunately the version of Ruby that comes with CentOS 6 is to old for Gitlab so we need to compile that from source. The method I use will install the latest version of Ruby. If you have the CentOS Ruby packages installed it shouldn’t matter. These instructions should allow you to run both versions.

  1. Install the development tools necessary to compile applications from source
    [[email protected] ~] yum -y groupinstall "Development Tools"
    [[email protected] ~] yum install perl-ExtUtils-MakeMaker postgresql-devel


  2. Install missing dependencies  I believe this is all of them. If anything is missing drop me a comment and I’ll update this guide.
    [[email protected] ~] yum install libxslt-devel libyaml-devel libxml2-devel gdbm-devel libffi-devel zlib zlib-devel openssl-devel libyaml-devel readline readline-devel curl-devel openssl-devel pcre-devel git memcached-devel valgrind-devel mysql-devel ImageMagick-devel ImageMagick libicu libicu-devel libffi-devel make bzip2 autoconf automake libtool bison iconv-devel redis


  3. Start redis and enable it on boot
    [[email protected]~] service redis start
    [[email protected]~] chkconfig --levels 35 redis on


  4. Create a new user account that we’ll run Gitlab under. I’m going to use ‘sa_gitlab’. Gitlab will be deployed in it’s home directory. On my server I want that to be in ‘/data/apps’ instead of ‘/home’
    [[email protected]~] adduser sa_gitlab --home-dir=/data/apps/sa_gitlab
    # If you want users to be able to use public/private key pairs you need to set a password for the sa_gitlab account. Make sure you use a strong password. This is neccessary to allow SSH access with public/private keys.
    [[email protected]~] passwd sa_gitlab


  5. Become the ‘sa_gitlab’ user and setup the ‘authorized_keys’ list and generate Gitlabs private key
    [[email protected]~] su - sa_gitlab
    [[email protected]~] mkdir -p /data/apps/sa_gitlab/.ssh
    [[email protected]~] chmod -R 700 /data/apps/sa_gitlab/.ssh
    [[email protected]~] echo "" > /data/apps/sa_gitlab/.ssh/authorized_keys
    [[email protected]~] chmod -R 600 /data/apps/sa_gitlab/.ssh/authorized_keys
    # This generates a 2048 bit key pair see below if you're paranoid :)
    [[email protected]~] ssh-keygen -q -N '' -t rsa -f /data/apps/sa_gitlab/.ssh/id_rsa
    # This generates a 4096 bit key pair
    [[email protected]~] ssh-keygen -q -b 4096 -N '' -t rsa -f /data/apps/sa_gitlab/.ssh/id_rsa
    [[email protected]~] cat /data/apps/sa_gitlab/.ssh/ >> /data/apps/sa_gitlab/.ssh/authorized_keys


  6. Create a ‘temp’ dir for us to work with and a ‘ruby’ dir for Ruby to be installed into. Then download, configured and install Ruby 1.9.3
    [[email protected]~] mkdir temp
    [[email protected]~] mkdir ruby
    [[email protected]~] cd temp
    [[email protected]~] wget -c ""
    [[email protected]~] tar -xf ruby-1.9.3-p392.tar.gz
    [[email protected]~] cd ruby-1.9.3-p392
    [[email protected]~] ./configure --prefix=/data/apps/sa_gitlab/ruby
    [[email protected]~] make
    [[email protected]~] make install


  7. Download, compile and install the latest version of git
    [[email protected]~] cd ~/temp
    [[email protected]~] wget -c
    [[email protected]~] tar -xf git-
    [[email protected]~] cd git-
    [[email protected]~] ./configure --prefix=/data/apps/sa_gitlab/git
    [[email protected]~] make
    [[email protected]~] make install


  8. Add the new installation of Ruby to the ‘sa_gitlab’ users PATH so you can use our complied version of Ruby. Also my CentOS came with an old version of bundle installed by default which is to old. We’ll create an alias in the sa_gitlab users bash profile to reference our compiled version of ‘bundle’
    [[email protected]~] vim ~/.bash_profile
    # -------- Make the following edits --------
    # Change the PATH line to look like this:
    # -------- Save and close the file --------
    [[email protected]~] vim ~/.bashrc
    # -------- Make the following edits --------
    # Add this to the bottom. I know it's redundant but it solves a problem when gitlab calls /usr/bin/env
    # -------- Save and close the file --------
    # Re-export your PATH
    [[email protected]~] PATH=$HOME/git/bin:$HOME/ruby/bin:$PATH:$HOME/bin;
    # Verify your using the right version of Ruby now
    [[email protected]~] which ruby
    [[email protected]~] ruby --version
    ruby 1.9.3p392 (2013-02-22) [x86_64-linux]
    [[email protected]~] which git
    [[email protected] ~] git --version
    git version


  9. Install bundler
    [[email protected]~] gem install bundler


  10. Download gitlab-shell
    [[email protected]~] cd ~/
    [[email protected]~] mkdir gitlab-shell
    [[email protected]~] git clone gitlab-shell/


  11. Configure gitlab-shell and install it
    [[email protected]~] cd gitlab-shell/
    [[email protected]~] cp config.yml.example config.yml
    [[email protected]~] vim config.yml
    # -------- Make the following edits --------
    	user: sa_gitlab
    	gitlab_url: ""
    	repos_path: "/data/apps/sa_gitlab/repositories"
    	auth_file: "/data/apps/sa_gitlab/.ssh/authorized_keys"
    # -------- Save and close the file --------
    [[email protected]~] ./bin/install


  12. Create yourself a MySQL database on your server and a dedicated user account with full access to it.
  13. Download Gitlab 5.0
    [[email protected]~] cd ~/
    [[email protected]~] mkdir gitlab
    [[email protected]~] git clone gitlab
    [[email protected]~] cd gitlab
    [[email protected]~] git checkout 5-0-stable


  14. Edit the Gitlab configuration file
    [[email protected]~] cp config/gitlab.yml.example config/gitlab.yml
    [[email protected]~] vim config/gitlab.yml
    # -------- Make the following edits --------
    	port: 80
    	https: false
    	user: sa_gitlab
    	email_from: [email protected]
    	support_email: [email protected]
          # Relative paths are relative to Rails.root (default: tmp/repo_satellites/)
          path: /data/apps/sa_gitlab/gitlab-satellites/
          repos_path: /data/apps/sa_gitlab/repositories/
          hooks_path: /data/apps/sa_gitlab/gitlab-shell/hooks/
          bin_path: /data/apps/sa_gitlab/git/bin/git
    # -------- Save and close the file --------


  15. Fix up some permissions
    [[email protected]~] chown -R sa_gitlab log/
    [[email protected]~] chown -R sa_gitlab tmp/
    [[email protected]~] chmod -R u+rwX  log/
    [[email protected]~] chmod -R u+rwX  tmp/


  16. Create the satellites directory and configure the database
    [[email protected]~] mkdir /data/apps/sa_gitlab/gitlab-satellites/
    [[email protected]~] mkdir tmp/pids/
    [[email protected]~] chmod -R u+rwX  tmp/pids/
    [[email protected]~] cp config/unicorn.rb.example config/unicorn.rb
    [[email protected]~] vim config/unicorn.rb
    # -------- Make the following edits --------
    # You can change the port that Gitlab will run on to anything. If you don't want to proxy connections to Gitlab via Apache and don't have a web-server running you can set this to 80 or 443. I also commented out the gitlab.socket line because I think it overrides listening on a port
        #listen "#{app_dir}/tmp/sockets/gitlab.socket"
        listen ""  # listen to port 8080 on the loopback interface
    # -------- Save and close the file --------
    [[email protected]~] cp config/database.yml.mysql config/database.yml
    # -------- Make the following edits --------
    vim config/database.yml
    	database: [DATABASE NAME]
    	username: [DATABASE USER]
    	password: "[DATABASE USER PASSWORD]"
    	host: localhost
    # -------- Save and close the file --------


  17. Install charlocks_holmes
    [[email protected]~] cd ~/gitlab
    [[email protected]~] gem install charlock_holmes --version '0.6.9'


  18. Setup the database structure, setup Gitlab and populate the database with default data. Yes one of the commands below says ‘postgres’ instead of ‘mysql’. Note the ‘–without’ in front of it
    [[email protected]~] /data/apps/sa_gitlab/ruby/bin/bundle install --deployment --without development test postgres
    [[email protected]~] /data/apps/sa_gitlab/ruby/bin/bundle exec rake gitlab:setup RAILS_ENV=production
    [[email protected]~] /data/apps/sa_gitlab/ruby/bin/bundle exec rake db:seed_fu RAILS_ENV=production


  19. Setup the Gitlab Init script. THis file requires a little bit of tweaking because I chose not to use the ‘git’ user. We also have to tell the script where to find our new version of bundle otherwise it will try to use the old version that comes with CentOS. The following is done as root
    [[email protected]~] curl --output /etc/init.d/gitlab
    [[email protected]~] chmod +x /etc/init.d/gitlab
    [[email protected]~] vim /etc/init.d/gitlab
    # -------- Make the following edits --------
    # The lines with a + are lines you need to add to the script
    +   APP_USER="sa_gitlab"
    # Search and replace "sudo -u git -H bash" with "sudo -u $APP_USER -H bash
    # -------- Save and close the file --------
    [[email protected]~] /etc/init.d/gitlab start
    [[email protected]~] /etc/init.d/gitlab status
    Gitlab service / Unicorn with PID 19988 is running.
    Gitlab service / Sidekiq with PID 20031 is running.
    [[email protected]~] chkconfig --add gitlab
    [[email protected]~] chkconfig --levels 35 gitlab on


  20. Switch back to the Gitlab user and check if anything has gone wrong
    [[email protected]~] su - sa_gitlab
    [[email protected]~] cd gitlab
    [[email protected]~] git config --global  "GitLab"
    [[email protected]~] git config --global "[email protected]"
    [[email protected]~] bundle exec rake gitlab:env:info RAILS_ENV=production
    # Check for errors
    [[email protected]~] bundle exec rake gitlab:check RAILS_ENV=production
    # Check for errors


  21. Finally if everything above worked out for you then Gitlab should be waiting for you at<PORT> where <PORT> is what we set back in step 14. If you’re happy with this then you’re done. Login with the default username and password ([email protected] / 5iveL!fe) for Gitlab and start using it. If you’re already running a web server and couldn’t run Gitlab on standard web ports add the following to your Apache config to proxy connections from Apache to Gitlab
    [[email protected]~] vim /etc/httpd/conf/httpd.conf
    # -------- Make the following edits --------
    	<VirtualHost *:80>
    			DocumentRoot /data/apps/sa_gitlab/gitlab/public
    			CustomLog logs/ combined
    			ErrorLog logs/
    			ProxyPass /
    			ProxyPassReverse /
    			ProxyPreserveHost On
    # -------- Save and close the file --------
    [[email protected]~] service httpd graceful


Once you’ve confirmed everything is working for you follow these instructions to run the whole thing over SSL. I’m going to assume you already have SSL certificates and mod_rewrite installed in Apache.

  1. Change the git-shell configuration to use https:// as the sa_gitlab user
    [[email protected]~] vim ~/gitlab-shell/config.yml
    # -------- Make the following edits --------
    # Add a 's' to the URL
    gitlab_url: ""
    # -------- Save and close the file --------
    [[email protected]~] vim ~/gitlab/config/gitlab.yml
    # -------- Make the following edits --------
        port: 443
        https: true
    # -------- Save and close the file --------

  2. Alter your Apache config with these virtual hosts
    [[email protected]~] vim /etc/httpd/conf/httpd.conf
    # -------- Make the following edits --------
    <VirtualHost *:80>
            DocumentRoot /data/apps/sa_gitlab/gitlab/public
            CustomLog logs/ combined
            ErrorLog logs/
            ProxyPass /
            ProxyPassReverse /
            ProxyPreserveHost On
            RewriteEngine On
            RewriteCond %{SERVER_PORT} 80
            RewriteRule ^(.*)$$1 [R,L]
    <VirtualHost *:443>
            DocumentRoot /data/apps/sa_gitlab/gitlab/public
            CustomLog logs/ combined
            ErrorLog logs/
            ProxyPass /
            ProxyPassReverse /
            ProxyPreserveHost On
            SSLEngine on
            SSLProtocol all -SSLv2
            SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
            SSLCertificateFile /etc/httpd/conf/certs/
            SSLCertificateKeyFile /etc/httpd/conf/certs/
            SSLCertificateChainFile /etc/httpd/conf/certs/ca-bundle.pem
    # -------- Save and close the file --------
    [[email protected]~] service gitlab restart
    [[email protected]~] service httpd restart


That’s it! I hope I haven’t missed anything but if I have drop me a comment and I’ll update this post.

Update March 31st, 2013 – I’ve written an article on how to update Gitlab once you’ve gotten it installed. You can find it here.

Update April 23rd, 2013 – Gitlab 5.1 is out! If you’ve followed the above instructions you should have a functioning Gitlab 5.0 instance. To upgrade to Gitlab 5.1 head over to this article: How to upgrade Gitlab 5.0 to 5.1 on CentOS 6 or RHEL6

Update April 26th, 2013 – Fixed an error in step 16. I said to run ‘cd ~/’ and it should be ‘cd ~/gitlab’. Thank you Ronald for pointing that out.

Update April 28th, 2013 – There was an error with my curl command to grab the gitlab init script. I was getting it from the master branch instead of the 5.0 branch. In the latest master Gitlab has changed their init script in a way that it will not work with 5.0 deployments because they moved from unicorn to puma. I updated the URL so it grabs the 5.0 init script.

Update May 21st, 2013 – Added steps for downloading, compiling and installing the latest version of git for use with Gitlab. Resolves a bug I came across when using my original deployment instructions and the default version of git that comes with CentOS 6.

Update May 22nd, 2013 – Added step to modify gitlab/config/gitlab.yml to use the new version of git. I had assumed Gitlab got the location of the git binary from the PATH environmental variable.




Replace MySQL with MiriaDB on CentOS 6

Last modified: [last-modified]

I’m running CentOS 6.3 64-bit and have been for a little while. I decided I wanted to swap out MySQL 5.1.x with MiriaDB 5.3.x.

Why? Because I can. Plus I’ve read a bit and it sounds like MiriaDB is better optimized than MySQL. Also Oracle is evil.

These instructions are based off my history file. I didn’t think to write this down as I did it. That means there may be a mistake in the following process but with some Googling you should be able to fix any problems you come across.

One thing to know before proceeding  If you’re using PHP 5.3.3 that comes with CentOS 6 you will get a header miss-match error when PHP uses the ‘php-mysql’ package to access MySQL. I believe you can safely ignore this. I did for a few hours and nothing seemed broken. I’ll include steps on fixing this problem in another post as it requires completely replacing PHP in CentOS with PHP from another repository. If you’ve compiled your own PHP then you’ll just want to re-compile it with the MySQL Native Driver (mysqlnd).

  1. Stop your webserver and any other applications that may be trying to access your MySQL Database
  2. Take a full backup of your MySQL database just in case
    mysqldump --add-drop-database --add-drop-table --allow-keywords --all-databases --complete-insert --quick --user=root --password=<ROOT PASSWORD> > fullDataset.sql
    service stop mysqld
    cp -Ra <Path to MySQL DB> <Path to MySQL DB>.bak
  3. Next find out what MySQL RPMs you have installed and remove them. This will automatically create a backup of your existing ‘/etc/my.cnf’ file.
    rpm -qa |grep mysql
    # --- Command output start ---
    # --- Command output end ---
    rpm -e --nodeps mysql-5.1.67-1.el6_3.x86_64 mysql-server-5.1.67-1.el6_3.x86_64 mysql-devel-5.1.67-1.el6_3.x86_64 mysql-libs-5.1.67-1.el6_3.x86_64
  4. Alright now you’ve got no MySQL on your system. Lets drop MiriaDB in.
    vim /etc/yum.repos.d/MariaDB.repo
    #--- Add the content below to the file ---
      name = MariaDB
      baseurl =
    #--- Save and close the file ---
    yum install MariaDB-client.x86_64 MariaDB-devel.x86_64 MariaDB-server.x86_64 MariaDB-shared.x86_64
  5. You should now have MariaDB 5.3.x installed. Next we want to put the old configuration file back.
    cp /etc/my.cnf.rpmsave /etc/my.cnf
  6. Fire up MiriaDB, verify the version and upgrade the databases
    /etc/init.d/mysql start
    mysql --version
    # --- Command output start ---
    mysql  Ver 15.1 Distrib 5.3.10-MariaDB, for unknown-linux-gnu (x86_64) using readline 5.1
    # --- Command output end ---
    # Upgrade the database
    mysql_upgrade -u root -p
  7. Configure MiriaDB to start on boot
    chkconfig --add mysql
    chkconfig --levels 35 mysql on

That’s it! You should now be running the latest stable version of MariaDB 5.3.x which you will be able to keep up to date with the ‘yum’ command.

How to remove old NICs in CentOS 5 or 6

I did a V2V conversion of a CentOS 6 machine from Hyper-V to vSphere.

After the migration I was left with a legacy NIC that would throw up a warning when ever I tried to vMotion the CentOS 6 VM. It didn’t prevent me from moving the machine around our cluster but it was an annoyance.

To solve this problem I did the following:

1. From vCenter I added a new VMXNET 3 NIC to the VM and removed the legacy NIC

2. I then logged in to the virtual machine using the vCenter console and deleted the following:
/etc/udev/rules.d/70-persistent-net.rules (CentOS 6 only)

3. I reboot the VM and then connected back into it using the vCenter console and ran ‘system-config-network’ and created a new eth0 device, assigned the proper IP to it and saved my changes

4. A quick ‘service network restart’ and the system was back up with just the new NIC