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 blog.redlax.technology 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,
Daniel
Tuesday, April 8, 2014
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?
Debugging:
Running
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 https://github.com/ClusterLabs/resource-agents/issues/330 mentioning that
Looking up the file /usr/lib64/heartbeat/heartbeat showed: yes, here it was. Adding a symlink to /usr/libexec/heartbeat/heartbeat like suggested at https://github.com/ClusterLabs/resource-agents/pull/285:
ln -s /usr/lib64/heartbeat/heartbeat \
/usr/libexec/heartbeat/heartbeat
Fortunately this fixed the issue and my heartbeat cluster is up and running since then.
Special thanks to
http://www.howtoforge.com/high_availability_heartbeat_centos
@kskmori and @joelgriffiths on GitHub
service heartbeat start
did not return anything. Exit code was 0 and not a single line of output. Weird?
Debugging:
Running
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 https://github.com/ClusterLabs/resource-agents/issues/330 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 https://github.com/ClusterLabs/resource-agents/pull/285:
ln -s /usr/lib64/heartbeat/heartbeat \
/usr/libexec/heartbeat/heartbeat
Fortunately this fixed the issue and my heartbeat cluster is up and running since then.
Special thanks to
http://www.howtoforge.com/high_availability_heartbeat_centos
@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');}; xhr.open('get', 'http://localhost:8989/', true); xhr.send(); var xhr2 = new XMLHttpRequest(); xhr2.onreadystatechange=function() {console.log('xhr2-change');}; xhr2.open('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...
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');}; xhr.open('get', 'http://localhost:8989/', true); xhr.send(); var xhr2 = new XMLHttpRequest(); xhr2.onreadystatechange=function() {console.log('xhr2-change');}; xhr2.open('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
Why?
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: https://gist.github.com/2994885
Part 2: https://gist.github.com/2995541
Let me know if it worked for you!
Part 1: https://gist.github.com/2994885
Part 2: https://gist.github.com/2995541
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.
First of all we need to add the epel repo to yum to get all the packages we want.
Then we install all required packages:
Up next: Downloading and extracting ruby:
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.
Now install ruby:
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)
Now we have to install all the gems GitLab needs to run:
Now everything is set up and we can start to configure the environment for GitLab. First we create a user, that will run GitLab:
Because this user will be the Admin of the repos on the server, we need to have a RSA key pair to authenticate:
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.
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:
Now we need to initialize 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:
Because the gitlab user will need a password later on, we configure it right now, so we are finished with all the user stuff.
As next step we need to introduce GitLab to gitolite (that is, we let them change their SSH-keys)
... 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:
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:
Add gitlab ALL=(ALL) ALL after root ALL=(ALL) ALL so it looks like this:
Do not edit anything else!!!
After another two gems we are finished with the gem stuff:
We now switch to our gitlab user and we won't use our root account anymore:
Get the GitLab software:
We're nearly done. Next we bundle our application.
GitLab will use a MySQL database (in our case), which we need to install and start:
To configure the MySQL server easily we use:
Remember the password you type in for root!
We now connect to our database server to create a user for GitLab:
We now have a mysql shell. Mind the trailing ;!
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:
Enter the password you created for the gitlab user and hit CTRL+Z. Then type
The service is now running in background.
We now configure GitLab by copying the configurion files from example to real:
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:
To start the server we use
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
user: admin@local.host
pass: 5iveL!fe
Why?
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.
Preperation.
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 http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
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 http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p0.tar.gz
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
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
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/id_rsa.pub /home/git/gitlab.pub
Now we need to initialize gitolite:
1: su git
2: gl-setup ~/gitlab.pub # 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 http://python-distribute.org/distribute_setup.py | 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://github.com/gitlabhq/gitlabhq.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 ;!
1: mysql> CREATE DATABASE gitlab CHARACTER SET UTF8;
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
user: admin@local.host
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!
Thanks to the team of gitlab and @premist!
Subscribe to:
Posts (Atom)