Blog Archive

Tuesday, April 8, 2014

I've moved on...

Hey there,

I'd like to thank all of you for your continuous support. As a matter of facts, I'm now part of the team at RedLax studios and will continue to improve the web.

Since I'm a part of this team now I will now continue to blog on and my latest two posts also moved there. Feel free to ping me whenever you have any questions or if I can help you with anything.

Keep being awesome,

Thursday, November 21, 2013

CentOS 6, 64bit, Heartbeat and a missing binary

While installing heartbeat on two virtual CentOS 6.4 64bit machines I ran across a weird error:

service heartbeat start

did not return anything. Exit code was 0 and not a single line of output. Weird?


bash -x /etc/init.d/heartbeat

showed that the script exited with code 0 after this line

[ -x /usr/libexec/heartbeat/heartbeat ]

Which turned out to be the following line in the script:

[-x $HA_BIN/heartbeat ] || exit 0

Looking up the file manually showed it wasn't there (which was weird again because I installed heartbeat using yum and I find yum to be rather reliable). So the heartbeat binary was missing. After googling for a few minutes I ran across this GitHub issue mentioning that

The heatbeat init script expects the heartbeat binary resides in $HA_BIN/heartbeat (/usr/lib64/heartbeat/heatbeat) but it now tries to look /usr/libexec/heartbeat/heartbeat and fails.

Looking up the file /usr/lib64/heartbeat/heartbeat showed: yes, here it was. Adding a symlink to /usr/libexec/heartbeat/heartbeat like suggested at

ln -s /usr/lib64/heartbeat/heartbeat \

Fortunately this fixed the issue and my heartbeat cluster is up and running since then.

Special thanks to
@kskmori and @joelgriffiths on GitHub
as well as the team of heartbeat and Linux HA, of course.

Tuesday, September 10, 2013

Chrome, Safari and duplicate XHR Requests

Today I ran across a really weird problem in an angular project I'm currently working on.

The page performed two XHR Requests (well, angular did but that doesn't matter) to the same URL only milliseconds appart.

Now this is what happens in Firefox (Nightly 23.0a1): Both requests go to the server and return the same result (an error but this makes no difference).

Now this is what happens in Chrome (31.0.1622.0) and Safari (6.0.5): Only one of the request hits the wire and therefore only one of the requests hits the server. But both requests trigger the xhr.onreadystatechange Events.

To try it out paste the following code into your console
var xhr = new XMLHttpRequest(); xhr.onreadystatechange=function() {console.log('xhr1-change');};'get', 'http://localhost:8989/', true); xhr.send(); var xhr2 = new XMLHttpRequest(); xhr2.onreadystatechange=function() {console.log('xhr2-change');};'get', 'http://localhost:8989/', true); xhr2.send();

To be honest: I have no idea why this happens. I assume it is some sort of caching but it is a really big gotcha when debugging... Hope this saves you some hours...

Thursday, August 16, 2012

Installing GitLab AND Redmine 2.0.3 on CentOS 6.2


I love Redmine to track bugs, but I needed to have a powerfull Frontend to manage the git repositories.

Getting ready.

This challenge took me a while because GitLab and Redmine require different ruby versions.

Let's go!

Because posting Code Snippets to Blogger is pretty tough (can anyone provide a very simple way?), you can find the snippets on GitHub's Gist Service:

Part 1:
Part 2:

Let me know if it worked for you!

Tuesday, June 19, 2012

Installing GitLab with gitolite on CentOS 6.2 and 6.3

Please leave a comment, to let me know what I can improve/if there are any problems.


Why would I want to install GitLab on a CentOS Server? Well... Why not? Many people fancy CentOS (me too) and why should't we use GitLab then? Also, many people don't like 
Ubuntu as a Server and CentOS is a pretty common Server OS.


It took me about seven times to get it right. The main problem with installing GitLab on CentOS is that - other than Ubuntu or Fedora - it doesn't have the ICU(lib) installed and
that's why ruby crashes/doesn't run around.

We will work as root most of the time, so make sure you have the permissions to do so. If we work as another user, I will try to point that out.

Let's go!

First of all we need to add the epel repo to yum to get all the packages we want.

1:  rpm -Uvh  

Then we install all required packages:

1:  yum -y groupinstall 'Development Tools' 'Additional Development'  
2:  yum -y install readline readline-devel ncurses-devel gdbm-devel glibc-devel tcl-devel openssl-devel curl-devel expat-devel db4-devel byacc gitolite sqlite-devel gcc-c++ libyaml libyaml-devel libffi libffi-devel libxml2 libxml2-devel libxslt libxslt-devel libicu libicu-devel system-config-firewall-tui python-devel redis  

Up next: Downloading and extracting ruby:

1:  curl -O  
2:  tar xzvf ruby-1.9.3-p0.tar.gz  
3:  cd ruby-1.9.3-p0  

Now here are two choices. For most of you number one will be perfectly fine. For those who want to have multiple ruby versions installed side-by-side please use number two.

1) Configure without binary suffix

1:  ./configure --enable-shared --disable-pthread  

2) Configure with binary suffix (for parallel installation of ruby versions)

1:  ./configure --enable-shared --disable-pthread --program-suffix _n  
When choosing this option, the binary ruby will be named ruby_n and gem gem_n. Also you will have to use rake_n.

Now install ruby:

1:  make && make install  

Some may need to install qt-devel qtwebkit-devel by running (Replace the 64 in the path with 32 if you're running on a 32 bit box)

1:  yum install qt-devel qtwebkit-devel
2:  export PATH=$PATH:/usr/lib64/qt4/bin

Now we have to install all the gems GitLab needs to run:

1:  gem update --system  
2:  gem update  
3:  gem install rails  

Now everything is set up and we can start to configure the environment for GitLab. First we create a user, that will run GitLab:

1:  adduser --shell /bin/bash --create-home --home-dir /home/gitlab gitlab  

Because this user will be the Admin of the repos on the server, we need to have a RSA key pair to authenticate:

1:  su gitlab  
2:  ssh-keygen -t rsa # as gitlab user  

Now switch back to your root account. Because GitLab is only a graphical user interface to manage repos, we need a powerfull backend. gitolite will do this for us. 
We also need a user for gitolite.

1:  adduser --system --shell /bin/sh --comment 'gitolite' --create-home --home-dir /home/git git  

Gitolite needs to know one key, that it knows as admin. We will pass the key of GitLab to gitolite. To do so we first copy the private key of our gitlab user to the home 
directory of our gitolite user:

1:  # make sure you do this as root  
2:  cp /home/gitlab/.ssh/ /home/git/  

Now we need to initialize gitolite:

1:  su git  
2:  gl-setup ~/ # this passes the admin key to gitolite  

When the prompt appears edit the provided file (it's in a vi-Editor) and set $REPO_UMASK to 0007

Switch back to your root user now.

We now need to give our management software (GitLab) access to the repos:

1:  usermod -a -G git gitlab  
2:  chmod -R g+rwX /home/git/repositories/  
3:  chmod 770 /home/git  

Because the gitlab user will need a password later on, we configure it right now, so we are finished with all the user stuff.

1:  passwd gitlab # please choose a good password :)  

As next step we need to introduce GitLab to gitolite (that is, we let them change their SSH-keys)

1:  su gitlab  
2:  ssh git@localhost  

... and back to the root user, so we don't need to care about permissions.

GitLab needs a few gems, we haven't installed yet:

1:  curl | python  
2:  easy_install pip  
3:  pip install pygments  
4:  gem install bundler  

As mentioned before, the gitlab user will have to do a bit of administration stuff, so we need to give him sudo rights. To do so, we edit the sudoers file with visudo:

1:  visudo  

Add gitlab ALL=(ALL) ALL after root ALL=(ALL) ALL so it looks like this:

1:  ...  
2:  root    ALL=(ALL)    ALL  
3:  gitlab    ALL=(ALL)    ALL  
4:  ...  

Do not edit anything else!!!

After another two gems we are finished with the gem stuff:

1:  gem install ruby-debug19  
2:  gem install charlock_holmes  

We now switch to our gitlab user and we won't use our root account anymore:

1:  su gitlab  

Get the GitLab software:

1:  cd && git clone git://  
2:  cd gitlabhq  

We're nearly done. Next we bundle our application.

1:  bundle install  

GitLab will use a MySQL database (in our case), which we need to install and start:

1:  yum -y install mysql-server  
2:  /etc/init.d/mysqld start  

To configure the MySQL server easily we use:

1:  mysql_secure_installation  

Remember the password you type in for root!

We now connect to our database server to create a user for GitLab:

1:  mysql -u root -p # when prompted enter the root password you've chosen in mysql_secure_installation  

We now have a mysql shell. Mind the trailing ;!

2:  mysql> GRANT ALL PRIVILEGES ON gitlab.* TO 'gitlabusr'@'localhost' IDENTIFIED BY 'supersecret' WITH GRANT OPTION;  
3:  mysql> quit  

Remember the password and username (here: gitlabusr and supersecret)!

To create the database a script is deployed with GitLab. However it needs an additional service to run:

1:  sudo nohup redis-server > /dev/null  

Enter the password you created for the gitlab user and hit CTRL+Z. Then type 

1:  bg  

The service is now running in background.

We now configure GitLab by copying the configurion files from example to real:

1:  cp ~/gitlabhq/config/database.yml.example ~/gitlabhq/config/database.yml  
2:  cp ~/gitlabhq/config/gitlab.yml.example ~/gitlabhq/config/gitlab.yml  

In database.yml you have to edit the production settings of your database (at the very top of the file). You have to change the database-name, username and password.

We will now create the database structure:

1:  RAILS_ENV=production rake db:setup  
2:  RAILS_ENV=production rake db:seed_fu  

To start the server we use

1:  bundle exec rails s -e production

That's it. We're done. All you have to do now, is set up your firewall and navigate to http://your-ip-or-domain:3000/ and log in with 

pass: 5iveL!fe

Known Issues!

Commit message says something like "unknown encoding"

Please see "HTTP 500-Error when viewing "Files" in a repository".

HTTP 500-Error when viewing "Files" in a repository

It's possible, that charlock_holmes didn't install correctly. If this happens, install qt4 and make sure the binary is in your PATH. Then reinstall charlock_holmes and restart GitLab.

What now?

GitLab is now running using Thin. Thin is a web server, that is not recommended to run in production. Therefore it is recommended to use a web server like nginx or Apache!


Thanks to the team of gitlab and @premist!