ChiliProject ist ein webbasiertes Projektmanagement-System, inklusive Issue Tracker und Wiki. Hervorgegangen ist es als Fork aus Redmine.
Leider ist die Installation alles andere als simpel: Diverse Abhängigkeiten, u.a. von Ruby und mySQL, machen einem das Leben schwer. Die Installationsanleitung führt zwar alles Notwendige auf, lässt dem Admin aber oftmals die Wahl zwischen mehreren Wegen, ohne zu beschreiben, welche Folgen eine Entscheidung für eine Variante hat. Oftmals merkt man erst später, dass eine Installation so nicht möglich ist, und man darf nochmals von vorne beginnen.
Empfehlenswert ist, die Installation erst auf einem Testsystem (z.B. in einer virtuellen Maschine) einmal durchzuspielen, bevor man sie auf einem Produktivsystem angeht – ansonsten läuft man Gefahr, das Produktivsystem zu ruinieren.
Mit etwas Unterstützung von einem Profi ging die Installation auf einem aktuellen Debian „Squeeze“ Server (6.0.7 – zu ermitteln via cat /etc/debian_version) aber schließlich doch flott von der Hand. Als kleine Hilfe hier die (wenig kommentierte) Befehlsliste, die in meinem Falle zum Ziel geführt hat (mit „>“ eingerückte Zeilen sind in kontextabhängiger Form einzugeben bzw. auszuführen). „myDbRootPassword“, „myDbChiliPassword“ und „myhostname.mydomain.de“ sind natürlich Platzhalter und durch passende Daten zu ersetzen.
Los geht’s: Erstmal das System auf den aktuellen Stand bringen:
aptitude update aptitude full-upgrade
Nun einen User anlegen, unter dem später das ChiliProject läuft:
adduser --system --home /srv/www/chiliproject --group --shell /bin/sh --disabled-login chiliproject
Jetzt wird RVM, der Ruby Version Manager, heruntergeladen und installiert.
aptitude install build-essential curl libssl-dev zlib1g-dev libreadline5-dev libxml2-dev git curl -L get.rvm.io | bash -s stable source /etc/profile.d/rvm.sh rvm install 1.9.3 rvm use 1.9.3 rvm --default 1.9.3
Nun folgt der mySQL Server, den wir aus den Debian Paketquellen beziehen. Das Root Kennwort ist während der Installation einzugeben:
aptitude install mysql-server > myDbRootPassword aptitude install libmysqlclient-dev
Weiter geht’s mit der Installation der Ruby Komponente „bundler“:
gem install bundler
Jetzt erstellen wir einen Clone des ChiliProject Repositories und laden somit den aktuellen stabilen ChiliProject herunter:
cd /srv/www git clone -b stable git://github.com/chiliproject/chiliproject.git cd chiliproject
„Bundle“ lädt nun die für ChiliProject notwendigen Komponenten herunter und installiert diese. Nicht benötigte bzw. sogar nicht installierbare werden explizit ausgeschlossen:
bundle install --without=test development sqlite postgres mysql rmagick
Nun konfigurieren wir die Datenbank und erstellen einen speziellen mySQL Benutzer, mit dem später das ChiliProject auf die Datenbank zugreift:
mysql -u root -p > myDbRootPassword > create database chiliproject character set utf8; > create user 'chiliproject'@'localhost' identified by 'myDbChiliPassword'; > grant all privileges on chiliproject.* to 'chiliproject'@'localhost'; > flush privileges; > quit
Als nächstes passen wir die Konfigurationsdatei an, die dem ChiliProject mitteilt, wie es auf die Datenbank zugreifen muss:
cp config/database.yml.example config/database.yml vi config/database.yml > production: > adapter: mysql2 > database: chiliproject > host: localhost > username: chiliproject > password: myDbChiliPassword > encoding: utf8
Die allgemeine Konfigurationsdatei von ChiliProject lassen wir vorerst unbearbeitet:
cp config/configuration.yml.example config/configuration.yml
Leider bin ich kein Ruby-Experte – ich habe keine Ahnung, was die folgenden Befehle genau tun. Irgendwie scheinen sie die Datenbank zu initialisieren bzw. mit Defaultwerten zu füllen:
bundle exec rake generate_session_store RAILS_ENV=production bundle exec rake db:migrate RAILS_ENV=production bundle exec rake redmine:load_default_data > de
Dann noch ein paar Unterverzeichnisse anlegen und berechtigen:
mkdir -p tmp public/plugin_assets chown -R chiliproject:chiliproject files log tmp public/plugin_assets chmod -R 755 files log tmp public/plugin_assets
Nun ist es Zeit für einen ersten Test: Noch ohne Apache, sondern mit WEBrick, einem einfachen, integrierten Webserver. Für den Produktivbetrieb nicht geeignet!
bundle exec script/server -e production > Testen! http://ip.adr.es.se:3000 > Strg+C
Anschließend wird Apache2 um die notwendigen Module und Konfigurationsdateien ergänzt.
aptitude install apache2-mpm-prefork aptitude install apache2-prefork-dev libcurl4-openssl-dev gem install passenger passenger-install-apache2-module cat > /etc/apache2/mods-available/passenger.load <<EOF LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p392/gems/passenger-3.0.19/ext/apache2/mod_passenger.so EOF cat > /etc/apache2/mods-available/passenger.conf <<EOF <IfModule mod_passenger.c> PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p392/gems/passenger-3.0.19 PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby PassengerDefaultUser chiliproject </IfModule> EOF a2enmod passenger /etc/init.d/apache2 reload cat > /etc/apache2/sites-available/chiliproject <<EOF <VirtualHost *:80> ServerName myhostname.mydomain.de DocumentRoot /srv/www/chiliproject/public <Directory /srv/www/chiliproject/public> Options None AllowOverride None Order deny,allow Allow from all </Directory> </VirtualHost> EOF a2ensite chiliproject /etc/init.d/apache2 reload
Das war’s! ChiliProject sollte nun unter der gewünschten URL erreichbar sein. Falls nicht, kollidiert die Apache Konfiguration möglicherweise mit der Default Site, die sich wie folgt abschalten lässt:
a2dissite default /etc/init.d/apache2 reload