Gitlab, ein Git-Server, ist bestens dazu geeignet, SourceCode zu verwalten.
Da die Installation aber nicht gerade einfach ist, findet sich hier eine kurze Anleitung, wie diese bewerkstelligt werden kann.
Die folgende Anleitung findet sich im Original unter: http://dlaxar.blogspot.co.at/2012/06/installing-gitlab-with-gitolite-on.html
First of all we need to add the epel repo to yum to get all the packages we want.
rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
Then we install all required packages:
yum -y groupinstall 'Development Tools' 'Additional Development' 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:
curl -O http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p0.tar.gz tar xzvf ruby-1.9.3-p0.tar.gz 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
./configure --enable-shared --disable-pthread
2) Configure with binary suffix (for parallel installation of ruby versions)
./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:
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)
yum install qt-devel qtwebkit-devel export PATH=$PATH:/usr/lib64/qt4/bin
Now we have to install all the gems GitLab needs to run:
gem update --system gem update 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:
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:
su gitlab 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.
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:
# make sure you do this as root cp /home/gitlab/.ssh/id_rsa.pub /home/git/gitlab.pub
Now we need to initialize gitolite:
su git # this passes the admin key to gitolite gl-setup ~/gitlab.pub
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:
usermod -a -G git gitlab chmod -R g+rwX /home/git/repositories/ 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.
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)
su gitlab 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:
curl http://python-distribute.org/distribute_setup.py | python easy_install pip pip install pygments 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:
visudo
Add gitlab ALL=(ALL) ALL after root ALL=(ALL) ALL so it looks like this:
... root ALL=(ALL) ALL gitlab ALL=(ALL) ALL ...
Do not edit anything else!!!
After another two gems we are finished with the gem stuff:
gem install ruby-debug19 gem install charlock_holmes
We now switch to our gitlab user and we won’t use our root account anymore:
su gitlab
Get the GitLab software:
cd && git clone git://github.com/gitlabhq/gitlabhq.git cd gitlabhq
We’re nearly done. Next we bundle our application.
bundle install
GitLab will use a MySQL database (in our case), which we need to install and start:
yum -y install mysql-server /etc/init.d/mysqld start
To configure the MySQL server easily we use:
mysql_secure_installation
Remember the password you type in for root!
We now connect to our database server to create a user for GitLab:
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 ;!
mysql> CREATE DATABASE gitlab CHARACTER SET UTF8; mysql> GRANT ALL PRIVILEGES ON gitlab.* TO 'gitlabusr'@'localhost' IDENTIFIED BY 'supersecret' WITH GRANT OPTION; 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:
sudo nohup redis-server > /dev/null
Enter the password you created for the gitlab user and hit CTRL+Z. Then type
bg
The service is now running in background.
We now configure GitLab by copying the configurion files from example to real:
cp ~/gitlabhq/config/database.yml.example ~/gitlabhq/config/database.yml 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:
RAILS_ENV=production rake db:setup RAILS_ENV=production rake db:seed_fu
To start the server we use
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
Beim Aufbau der SSH-Verbindung (als Benutzer gitlab den Befehl „ssh git@localhost“ ausführen), muss man auf die Berechtigungen des Home-Verzeichnisses des git Benutzers achten.
Treten hier Probleme auf, dann findet man Fehlermeldungen in der Log-Datei „/var/log/secure.log“.
Eventuell muss man noch den folgenden Befehl ausführen:
Damit der Start von gitlab auch nach einem Server-Restart funktioniert gibt es mehrere Möglichkeiten.
Entweder erstellt man ein Init-Skript (bspw /etc/init.d/gitlab) und startet damit den von gitlab verwendeten unicorn server oder man bettet gitlab per passenger in Apache2 ein. Natürlich sind auch Kombinationen denkbar (bspw. auf den unicorn server per apache-proxy umzuleiten).
Am einfachsten ist aber sicherlich die Passenger-Integration.
Kurz zusammengefasst sieht die Installation dabei so aus:
Anlegen einer /etc/httpd/conf.d/gitlab.conf:
## For Gitlab using Apache2 Passenger ## Install by typing (as root): ## gem install passenger && passenger-install-apache2-module ## but only after running the install_and_configure_git.py script ## and creating a soft link to the rails gitlab /public directory like so: ## sudo ln -s /home/gitlabhq/gitlabhq/public /var/www/gitlab LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.18/ext/apache2/mod_passenger.so PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.18 PassengerRuby /usr/local/bin/ruby Alias /gitlab /var/www/html/gitlab ## Set the Rails Base URI RackBaseURI /gitlab RailsBaseURI /gitlab <Directory /var/www/html/gitlab> AllowOverride All RewriteEngine Off Options -MultiViews </Directory>Als gitlab-Benutzer in der „/home/gitlab/gitlabhq/config/environments/production.rb“ die config.assets.prefix Eigenschaft auf „gitlab/assets“ setzen und anschließend die assets mit folgendem Kommando vorkompilieren (in /home/gitlab/gitlabhq):
Jetzt setzt man noch einen symbolischen Link im /public-Verzeichnis von gitlab
Und abschließend noch den apache-Benutzer in die git und github Gruppen aufnehmen und die Berechtigungen für den Zugriff setzen
Damit in Gitlab die Resque-Worker funktionieren muss man den passenden Prozess starten.
Dazu legt man ein Skript „/etc/init.d/resque“ mit folgendem Inhalt an:
#! /bin/bash ### BEGIN INIT INFO # Provides: gitlab # Required-Start: $local_fs $remote_fs $network $syslog redis-server # Required-Stop: $local_fs $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: resque service for gitlab # Description: resque service for gitlab ### END INIT INFO NAME=resque DESC="resque service" RESQUE_PID=/home/gitlab/gitlabhq/tmp/pids/resque_worker.pid case "$1" in start) CD_TO_APP_DIR="cd /home/gitlab/gitlabhq" START_RESQUE_PROCESS="./resque.sh" echo -n "Starting $DESC: " if [ `whoami` = root ]; then $CD_TO_APP_DIR > /dev/null 2>&1 sudo -u gitlab sh -l -c $START_RESQUE_PROCESS else $CD_TO_APP_DIR > /dev/null 2>&1 && $START_RESQUE_PROCESS fi echo "$NAME." ;; stop) echo -n "Stopping $DESC: " kill -QUIT `cat $RESQUE_PID` echo "$NAME." ;; restart) echo -n "Restarting $DESC: " kill -USR2 `cat $RESQUE_PID` echo "$NAME." ;; reload) echo -n "Reloading $DESC configuration: " kill -HUP `cat $RESQUE_PID` echo "$NAME." ;; *) echo "Usage: $NAME {start|stop|restart|reload}" >&2 exit 1 ;; esac exit 0Jetzt macht man die Datei noch ausführbar und fügt den service den Startprozessen hinzu
Gibt es Probleme mit den SSH-Schlüsseln (zum Beispiel nach dem sich ein Schlüssel geändert hat), so sollte man in ~/.gitolite.rc den Wert $GL_GITCONFIG_KEYS = „.*“; setzen
Wie man in der offiziellen Installationsanleitung (hier zu finden) nachlesen kann, muss man noch einen sog. post-receive hook in /home/git/.gitolite einfügen.
Das macht man am Besten mit folgenden Befehlen (als root):
Anschließend kann man die Installation noch prüfen. Dazu wechselt man zum gitlab Benutzer und führt folgenden Befehl aus:
Auch SELinux kann man dazu überreden, mit GitLab zusammen zu arbeiten.
Dazu führt man nach erfolgtem (fehlerhaften) Zugriff auf Gitolite folgende Befehle (als root) aus:
Mittlerweile ist die Installation von Gitlab um einiges einfacher geworden. Dazu gibt es das so genannte „Omnibus“-Package, das mit einem Packetmanager wie yum oder apt-get installiert werden kann.
Im „Omnibus“ sind alle Abhängigkeiten, wie ruby oder PostgreSQL enthalten, was die Installation und in Besonderen Updates sehr einfach macht.