Chiliproject

Chiliproject Projektverwaltung

Kurze Einführung in Chiliprojekt

Chiliproject ist ein frischer Fork von Redmine und dient dazu Projekte zu verwalten. Genau wie Redmine besitzt auch Chili diverse Module, die den Entwickler bei der Entwerfung, Entwicklung und Betreuung unterstützten.

• Einige Module sind:
  • Wiki
  • Bugtracker
  • Gantt Diagramme
  • Versionsverwaltung - SCM (SVN/Git ...)
  • .. und noch einige mehr

Chiliproject (im folgenden nur noch Chili genannt) ist in der Sprache Ruby geschrieben und nutzt das Framework Ruby on Rails. Dank der Plugin Schnittstelle, ausgefeilten Benutzer- sowie Rollenfunktionen ist Chili für viele Projekte hervorragend geeignet. In diesem Fall benutzt der Autor (also ich ;-) ..) Chili als Projektverwaltung für die TU-Darmstadt im Fachbereich Informatik, da derzeit die Studenten SVN über SSH verwenden und dadurch einiges verkompliziert wird.

Um den Studenten mehr Auswahlmöglichkeiten zu bieten, wird am Ende der Installation auch Git neben SVN zur Wahl stehen.

Ziel der Anleitung

Am Ende der Anleitung können sich Studenten, welche per LDAP authentifiziert werden, einloggen und selbständig Unterprojekte anlegen und verwalten. Ein Eingriff seitens des Administrators ist auf ein absolutes Minimum reduziert worden, dank der Plugins von Felix Schäfer, einer der Entwickler von Chiliproject. Hier nochmal meinen Dank an dich, Felix!

Einen Teil dieser Anleitung basiert auf dem englischen Installation on Debian 6.0 (Squeeze)

Installation

Ich verwende als Grundlage ein Debian Squeeze 64Bit in einem Vmware Gast mit 6GB Ram. Die Grundinstallation sollte bereits abgeschlossen sein.

Pakete

Zuerst die Installation einiger Pakete:

# aptitude install vim apache2 apache2-mpm-prefork libapache-dbi-perl \ libapache2-mod-passenger libapache2-mod-perl2 libapache2-svn \ libapache2-webauth mysql-server svn git fail2ban acl curl postfix \ libauthen-simple-ldap-perl screen libio-socket-ssl-perl

Anmerkung: Debian verwendet als Standard MTA Exim, ich bevorzuge jedoch Postfix. Postfix wird als reiner "Satellite system" MTA betrieben. Das bedeutet: er nimmt die Mails vom Chili entgegen und reicht sie sofort an den eigentlichen Uni Mailserver weiter.

Dann Chilispezifischer Pakete:

# aptidute install ruby rubygems rake libi18n-ruby1.8 libdbi-ruby1.8 libmysql-ruby rails

Chili

Derzeit ist die Version 2.1.1 aktuell, also installieren wir diese nach /var/www/chili

# cd /var/www # wget https://www.chiliproject.org/attachments/download/158/chiliproject-2.1.1.tar.gz # tar xzf chiliproject-2.1.1.tar.gz # mv chiliproject-2.1.1 chili

Ähnlich für CPAN für Perl od. Pear für PHP, gibt es Gem für Ruby. Darüber lassen sich Module und Bibliotheken aus dem Netz nachinstallieren. Für Chili benötigen wir diese:

# cd /var/www/chili # gem install rake -v=0.8.7 # gem install bundler # ln -s /var/lib/gems/1.8/bin/bundle /usr/local/bin/ # bundle install --without=sqlite postgres rmagick

Rake 0.9.x von Debian und Gem arbeitet noch nicht korrekt mit Chili zusammen, daher installieren wir noch 0.8.7

Ob und welche Programme und Bibliotheken installiert sind, lässt sich einfach mit Gem überprüfen:

# gem list --local *** LOCAL GEMS *** actionmailer (2.3.12) actionpack (2.3.12) activerecord (2.3.12) activeresource (2.3.12) activesupport (2.3.12) bundler (1.0.17) coderay (0.9.8) columnize (0.3.4) edavis10-object_daddy (0.4.3) i18n (0.4.2) linecache (0.46) mocha (0.9.12) mysql (2.8.1) mysql2 (0.2.11) rack (1.1.2) rails (2.3.12) rake (0.8.7) rbx-require-relative (0.0.5) rdoc (3.9.1) ruby-debug (0.10.4) ruby-debug-base (0.10.4) ruby-openid (2.1.8) rubytree (0.5.3) shoulda (2.10.3)

Sollte noch irgendwo ein Rake 0.9.x installiert sein, dieses einfach mit folgendem Kommando deinstallieren.

# gem uninstall rake

Einfach dann die passende Version auswählen.

Damit Chili auch wirklich Rake 0.8.7 verwendet, muss derzeit die Gemfile im Chili Projekt Ordner noch angepasst werden. Dazu die Datei /var/www/chili/Gemfile öffnen und um folgende Zeile erweitern:

source :rubygems gem "rake", "0.8.7" [...]

Nun kann auch im Prinzip das /usr/bin/rake aufgerufen werden und Ruby wird das ausgewählte Rake 0.8.7 verwenden.

Dann erfolgt die Erzeugung eines Sitzungsschlüssel Speicher für Chilli

# rake generate_session_store

Sollte man dies vergessen haben, so wird das nachfolgende Kommando abgebrochen:

# /var/lib/gems/1.8/gems/rake-0.8.7/bin/rake db:migrate RAILS_ENV="production" --trace (in /var/www/chili) ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment rake aborted! A key is required to write a cookie containing the session data. Use config.action_controller.session = { :key => "_myapp_session", :secret => "some secret phrase" } in config/environment.rb [...]

Datenbank

Als Datenbank stehen diverse für Chili bereit. Ich verwende in diesem Beispiel MySQL. Im Verzeichnis /var/www/chili/config gibt es die Datei database.yml.example. Davon eine Kopie mit Namen database.yml erstellen. Der Inhalt sieht wie folgt aus:

production: adapter: mysql database: chiliproject host: localhost username: chiliproject password: sehr_geheim encoding: utf8

Es gibt hier nur im die Instanz production:. Alle anderen können so belassen werden und sind nicht relevant.

Dann legen wir die Datenbank mit einem passenden Benutzer an:

# mysql -p mysql> create database chiliproject character set utf8; mysql> create user 'chiliproject'@'localhost' identified by 'sehr_geheim'; mysql> grant all privileges on chiliproject.* to 'chiliproject'@'localhost'; mysql> quit

Ist das geschehen, kann die Datenbank befüllt werden {{shell|

# cd /var/www/chili
# rake db:migrate RAILS_ENV="production"

Grundlegende Konfiguration

Auch wieder im Verzeichnis /var/www/chili/config findet sich die Hauptkonfiguration von Chili, mit Namen configuration.yml.example, welche als Grundlage dient und nach configuration.yml kopiert wird.

Sie hat zB. folgenden Inhalt:

Dies gilt für z.B. die Instanz production production: email_delivery: delivery_method: :smtp smtp_settings: address: "mail.server.foo" port: 25 authentication: :plain domain: 'server.foo' user_name: 'myaccount' password: 'password' Das hier für alle anderen default: email_delivery: delivery_method: :smtp smtp_settings: address: mail.server.foo port: 25 domain: server.foo # Wo Werden die Dateien abgelegt, welche im Frontend hochgeladen werden können attachments_storage_path: /var/chili/files autologin_cookie_name: autologin_cookie_path: autologin_cookie_secure: scm_subversion_command: scm_mercurial_command: scm_git_command: scm_cvs_command: scm_bazaar_command: scm_darcs_command: database_cipher_key: production: development: test: email_delivery: delivery_method: test

Hinweis

Es ist unbedingt auf die Leerzeichen in der Beispieldatei zu achten, da es sonst ein Syntax Fehler ist (wie unter Python)

Dann gilt es schonmal die passende Verzeichniss zu erzeugen:

# mkdir -p /var/chili/{files,svn,git}

Grundsätzlicher Test

Ob die Installation bisher grundsätzlich funktioniert, kann mit dem eingebauten Webserver überprüft werden. Dieser ist zwar nicht für den produktiven Test gedacht, aber zum Testen der Installation sehr gut geeignet:

# cd /var/www/chili # ruby script/server webrick -e production

Nun lässt sich die webseite http://server.foo:3000 öffnen und per "admin" und Kennwort "admin" einloggen.

Apache Konfiguration

Es gibt die Möglichkeit, Chili über einen eingebauten Ruby Webserver laufen zu lassen, aber aufgrund der Performance und Flexibilität, nutzen wir den Apachen2, der der Ruby-Rails Code ausführen wird. Dazu nutzen wir das Apache Modul Passenger. Die Installation des Moduls sollte bereits weiter oben geschehen sein.

• Konfiguration des Moduls

Als nächstes müssen wir uns die Modul- Konfiguration anschauen und anpassen:

• /etc/apache2/mods-enabled/passenger.conf

<IfModule mod_passenger.c> PassengerRoot /usr PassengerRuby /usr/bin/ruby PassengerDefaultUser chiliproject </IfModule>

Wie zu sehen ist, soll der Passenger als unprivilegierter Benutzer chilli' laufen. Daher legen wir einen passenden Benutzer und Gruppe an:

# adduser --system --home /var/www/chiliproject --group --shell /bin/sh --disabled-login chiliproject

Apache Virtual Host Konfiguration

Ab diesem Punkt gibt es nun zwei Möglichkeiten. Entweder man verwendet die bereits bestehende VirtualHost Konfiguration von Debian 000-default, od. man setzt eine eigene Konfiguration auf. Wird letztes bevorzugt, so muss daran gedacht werden, dass beide VirtualHost Konfigurationen auf unterschiedliche Namen hören müssen. Andernfalls wird keine Chili Seite aufgerufen werden, da immer der StandardVirtual Host zum Einsatz kommt und nicht die von uns erstellte.

• Beispiel 1: Hier nun die selbst erstellte Konfiguration

• /etc/apache2/sites-available/chiliproject

<VirtualHost *:80> # TODO: Adapt the servername ServerName scm.server.foo ServerAlias chili.server.foo DocumentRoot /var/www/chili/public <Directory /var/www/chili/public> Options None AllowOverride None Order deny,allow Allow from all </Directory> <Location /sys> Order deny,allow # Where runs SVN Server Allow from 127.0.0.1 Allow from 1.2.3.4 Deny from all </Location> </VirtualHost>

Dann die Konfiguration aktivieren

# a2ensite chiliproject

• Beispiel 2: Die von Debian erweiterte Fassung:

• /etc/apache2/sites-enabled/000-default

<VirtualHost *:80> ServerAdmin webmaster@domain.foo ServerName chili.domain.foo ServerAlias scm.domain.foo DocumentRoot /var/www/chili/public <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/chili/public> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 </Directory> </VirtualHost>

Da für Redmine eine spezielle Datei für Passenger benötigt wird, muss diese in den Pfaden von Perl auftauchen. Diese Datei ist /var/www/chili/extra/svn/Redmine.pm. Daher verlinken wir sie in einen der Perl Pfade:

# ln -s /var/www/chili/extra/svn/Redmine.pm /usr/lib/perl5/Apache/

Danach kann man Apache mit /etc/init.d/apache restart neustarten und testen.

Apache Virtual Host SVN Konfiguration

Damit Studenten ihre Projekte per SVN einchecken können, müssen diese sich vorher am Apachen Authentifizieren. Der Apache selbst holt seinerseits die notwendigen Informationen von Chili. All diese Parameter legen wir sinnigerweise in eine eigene VirtualHost Konfiguration. Zuvor sollen allerdings die passenden Module vom Apache scharf geschaltet werden. Unter Umständen muss das Eine od. Andere noch nachinstalliert werden:

# a2enmod dav # a2enmod dav_svn

• /etc/apache2/sites-available/chili-svn

<VirtualHost *:80> ServerName svn.domain.foo ServerAdmin webmaster@domain.foo PerlLoadModule Apache::Redmine PerlLoadModule Authen::Simple::LDAP PerlLoadModule IO::Socket::SSL <Location /svn> DAV svn SVNParentPath "/var/chili/svn" SVNListParentPath on Deny from all Satisfy any PerlAccessHandler Apache::Authn::Redmine::access_handler PerlAuthenHandler Apache::Authn::Redmine::authen_handler AuthType Basic AuthName "RBG Chili SVN Repository" #read-only access <Limit GET PROPFIND OPTIONS REPORT> Require valid-user Allow from 127.0.0.1 Allow from 1.2.3.4 Satisfy any </Limit> # write access <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> ## for mysql RedmineDSN "DBI:mysql:database=chiliproject;host=localhost" RedmineDbUser "chiliproject" RedmineDbPass "sehr_geheim" #Cache the last 50 auth entries # RedmineCacheCredsMax 50 </Location> </VirtualHost>

Es ist darauf zu achten, dass keiner in diese Datei (außer Root) schauen kann.

Mit einem apache2ctl -t sollte überprüft werden, ob zumindest die Syntax stimmt. Unter Umständen können noch Fehlermeldungen über fehlende Perlmodule auftreten.

Damit der Apache später in das Verzeichnis, in dem die Repositories liegen, auch schreiben darf, verwenden wir eine ACL und ändern auch gleich noch den Eigentümer der Verzeichnisse:

# chown chiliproject:chiliproject -R /var/chili # setfacl -m u:www-data:rwx /var/chili/svn # setfacl -d -m u:www-data:rwx /var/chili/svn

Apache Virtual Host GIT Konfiguration

Die Alternative zu GIT wird ein wenig anders eingebunden. Zwar ließe sich Git auch über DAV verwenden, aber dadurch das HTTP Zustandlos ist, können im schlimmsten Fall die Repositories in einen undifinierten Zustand geraten. Des weiteren ist die Performance sehr schlecht. Daher nutzen wir ebenfalls das Passenger Modul vom Apachen, in Kombination mit dem Modul "Grack" von Ruby, um Git über HTTP laufen zu lassen.

• Dazu besorgen wir und Grack über Git:

# git clone http://github.com/schacon/grack.git /var/www/git # mkdir /var/www/git/{public,tmp} # chown chiliproject:chiliproject /var/www/git/{public,tmp}

... und passen die dort enthaltene config.ru an:

$LOAD_PATH.unshift File.expand_path(File.dirname(__FILE__) + '/lib') use Rack::ShowExceptions require 'git_http' config = {  :project_root => "/var/chili/git",  :git_path => '/usr/bin/git',  :upload_pack => true,  :receive_pack => true, } run GitHttp::App.new(config)

Dann muss diese Datei dem Benutzer chiliproject gehören:

# cd /var/www/git # chown chiliproject:chiliproject config.ru

Nun folgt die VirtualHost Konfiguration vom Apachen

• /etc/apache2/sites-available/chili-git

<VirtualHost *:80> ServerName git.server.foo ServerAdmin webmaster@server.foo DocumentRoot /var/www/git/public PerlLoadModule Apache::Redmine <Directory /var/www/git/public> Options None AllowOverride None Order deny,allow Allow from all </Directory> <Location "/"> AuthType Basic AuthName "RBG Git Repositories" Require valid-user PerlAccessHandler Apache::Authn::Redmine::access_handler PerlAuthenHandler Apache::Authn::Redmine::authen_handler ## for mysql RedmineDSN "DBI:mysql:database=chiliproject;host=localhost" RedmineDbUser "chiliproject" RedmineDbPass "sehr_geheim" #Cache the last 50 auth entries # RedmineCacheCredsMax 50 RedmineGitSmartHttp yes </Location> </VirtualHost>

Chili Plugin Redmine_scm

Damit SVN/GIT Projekte von Chili erstellt werden können, ohne auf eine Shell zurückgreifen zu müssen, bedienen wir uns des Redmine_scm Plugins. Dieses läuft auch unter Chili:

• Installieren

# cd /var/www/chili/vendor/plugins # svn co http://svn.s-andy.com/redmine-svn redmine_scm # cd redmine_scm

Dann muss die Konfigurationsdatei config/scm.yml nach /var/www/chili/config kopiert und angepasst werden:

production: auto_create: true deny_delete: false svn: path: /var/chili/svn svnadmin: /usr/bin/svnadmin url: svn git: path: /var/chili/git git: /usr/bin/git options: --bare url: http://git.server.foo update_server_info: true git_ext: true development:

Dann folgt die Einbindung in Chili, dabei in /var/www/chili bleiben:

# rake db:migrate:plugins RAILS_ENV=production

Nach einem /etc/init.d/apache2 restart kann man nun im Chili ein Projekt anlegen. Auf der Projektseite erscheint unten nun das Redmine_scm Plugin, welches einem die Wahlmöglichkeit zwischen Git und SVN lässt. Nach einem bestätigen taucht dieses Projekt nun in /var/chili/svn od. /var/chili/git auf.

Testen

Ob nun auch das Ein- bzw. Auschecken funktioniert, kann man dies folgendermaßen testen.

1. Man erstelle ein Projekt
2. Dieses Projekt muss einem registrierten Benutzer zugeordnet werden
3. Man prüfe via Git / SVN ob der Login Prozess funktioniert

• Beispiel für Git:

$ git clone http://foobar@git.domain.foo/myproject.git $ cd myproject $ echo "Test" > first_file.txt $ git add first_file $ git commit -am "Erste Datei" $ git push origin master

Dann wird im Chili unter "Projektarchiv" vom Projekt "myproject" ein entsprechender Eintrag erzeugt.

• Beispiel für SVN:

$ svn co http://foobar@svn.domain.foo/svn/myproject $ cd myproject $ echo "Test" > first_file.txt $ svn add first_file $ svn ci -m "Erster Eintrag"

Der Benutzername muss zum Auschecken nur dann verwendet werden, wenn es keine öffentliche Projekte sind. Wurde aber das Projekt öffentlich erstellt, so kann jeder Einblick in das Projekt nehmen.

Automatisches erstellen von Projekten

Einer der größten Nachteile bisher liegt darin, dass nur der Administrator ein Projekt anlegen kann, bzw. eine Person, die eine Rolle mit entsprechenden Rechte innehat, was wiederum ein Projekt bedingt.

Für den Betrieb an einer Universität mit hunderten und tausenden von Studenten, sicherlich keine Lösung. Daher hat Felix Schäfer von Chiliproject.org ein Plugin erstellt, welches dem Studenten/Benutzer beim erstmaligen Einloggen ein Projekt erstellt. Chili selbst wird dann diesem Benutzer eine Rolle zuweisen, sofern dies unter Administration -> Konfiguration -> Projekte | Rolle, die einem Nicht-Administrator ... konfiguriert wurde. In diesem Fall wurde eine weitere Rolle erstellt, die weitestgehend mit der Rolle "Manager" identisch ist, bis auf die Tatsache, dass der Punkt "Projektarchiv verwalten" und "Projektarchiv erstellen" entfernt wurde. Damit kann der Student nur noch Unterprojekte erzeugen, was in den meisten Fällen ausreichend sein wird.

Um das Plugin einzubinden, sind folgende Schritte notwendig:

# cd /var/www/chili/vendor/plugins # git clone https://github.com/thegcat/chiliproject_auto_project # cd /var/www/chili # rake db:migrate:plugins RAILS_ENV=production # /etc/init.d/apache2 restart

Sobald ein Benutzer sich zum ersten Mal eingeloggt hat, wird ein Projekt erstellt, welches dem Loginnamen entspricht. Dieses Projekt kann der Benutzer selbst verwalten. Es wird an dieser Stelle aber kein Repositorie erstellt und auch der Benutzer kann keins erstellen. Dieses Projekt dient einzig dazu, ihm eine Rolle mitzugeben. Für ein eigenes Repositorie muss der Benutzer ein Unterprojekt von seinem Projekt erstellen. Dort hat er wieder die Wahl zwischen Git und SVN.

Unterprojekt Hierarchie Plugin

Ein weiteres sehr nützliches Plugin - ebenfalls von Felix Schäfer - ist das chiliproject_ensure_project_hierarchy Plugin. Es gibt den Prefix des Unterprojekt vor z.B. foobar-projekt1 foobar-projekt2 ... . Auf diese Weise herrscht eine gewisse Ordnung auf im Chili und auf dem Dateisystem, da immer klar ist, wem welches Projekt gehört.

Zum Einbinden sind wieder folgende Schritte notwendig:

# cd /var/www/chili/vendor/plugins/ # git clone https://github.com/thegcat/chiliproject_ensure_project_hierarchy # cd ../../ # rake db:migrate:plugins RAILS_ENV=production # /etc/init.d/apache2 restart

Wenn nun ein Unterprojekt angelegt wird, wird dem Benutzer die Kennung vorgegeben, die er nur noch erweitern kann. Schreibt er eine neue Projektkennung rein, so erhält er eine Fehlermeldung.

Performance Tipps

Sobald länger als 5 Minuten (300 Sekunden) kein Besucher auf der Chiliproject Seite vorbeigeschaut hat, beendet das Apache Modul Passenger die nicht benötigten Prozesse. Dies kann dazu führen, dass die Reaktionszeit beim ersten erneuten Aufrufen sehr zu wünschen übrig lässt, denn dann sind 2-3 Sekunden Reaktionszeit eher der Standardfall, als die Ausnahme. Um das Beenden der Prozesse zu unterbinden, kann das Passenger Modul mit diversen Optionen konfiguriert werden:

• /etc/apache2/mods-enabled/passenger.conf

... PassengerPoolIdleTime 0 ...

Dieser Parameter sorgt dafür, dass die Prozessen nicht mehr beendet werden. Das ist allerdings nur dann wirklich sinnvoll, wenn auf dem Server sonst nichts weiter läuft. Des weiteren sollten alle Apache Module abgeschaltet werden, die nicht wirklich benötigt werden. Z.B. rewrite, status ....

Weitere sehr nützliche Möglichkeiten, bietet die Passenger Webseite

Hinweise

• Benutzer löschen

Das Löschen von Benutzern ist weder in Redmine noch in Chili vorgesehen. Das Problem ist, dass Abhängigkeiten zwischen Projekten, Tickets und Plugins etc. nicht sicher aufgelöst werden können. Das hätte dann zur Folge, dass Links od. Referenzen auf ein Objekt ( Benutzer ) zeigen, welches es nicht mehr gibt. Einen entsprechenden Thread findet man an dieser Stelle: http://www.redmine.org/boards/2/topics/114 . Möglicherweise kann dieses "Problem" erst in einiger Zukunft gelöst werden.

Um dennoch einen Benutzer zu löschen, begibt man sich am Besten auf die Konsole:

# cd /var/www/chili # export RAILS_ENV="production" # script/console >> [5,6,8,11].each { |u| User.find(u).destroy }

'script/console ist ein Werkzeug, um interaktiv auf seine Installation Einfluß zu nehmen. Der Nachfolgende Ruby Befehl sucht die Benutzer mit der id 5,6,8,11 heraus und für jeden gefundenen Eintrag wird der destroy Befehl ausgeführt.

Man sollte jedoch sehr vorsichtig damit umgehen um seine Datenintegrität nicht zu gefährden und vorher ein Datenbank Backup erstellen.

Quellen

• Remdine Seite http://www.redmine.org
• Chiliproject Seite: https://www.chiliproject.org
• installation unter Debian/Ubuntu: https://www.chiliproject.org/projects/chiliproject/wiki/Installation_on_Debian_Squeeze
• Redmine SCM Plugin Wiki: http://projects.andriylesyuk.com/projects/redmine-svn/wiki/Install
• Authentifizierung: http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
• Git Einbinden: http://www.redmine.org/projects/redmine/wiki/HowTo_configure_Redmine_for_advanced_git_integration
• Redmine Installation: http://www.redmine.org/projects/redmine/wiki/RedmineInstall
• Chili Logo: http://www.flickr.com/photos/thebrownhouse/4599233853/
• Apache Passenger Modul: http://modrails.com/documentation/Users%20guide%20Apache.html

ToDo

• SSL Einbinden

---