Ich gehe im Folgenden von einer Lenny-Basisinstallation aus, d.h. es sind keine Pakete aus Fremdquellen oder ähnliches installiert. Der Server, auf dem Redmmine aufgesetzt wird, ist unter dem Namen redmine.example.com erreichbar und nimmt auf localhost:25 Mails ohne Authentifizierung entgegen. MySQL und Apache müssen noch nicht installiert sein.

Als erstes sollten Ruby, Rubygems und Rails installiert und eingerichtet werden, wie ich es in einem früheren Artikel beschrieben habe. Die Pfade in den weiteren Schritten beziehen sich auf diese Konfiguration.

MySQL

Als erstes werden die für MySQL benötigten Debian-Pakete installiert:

# aptitude install mysql-server build-essential ruby1.8-dev libmysqlclient15-dev

Als nächstes das gem für die Ruby-MySQL-Anbindung:

# gem install mysql

Redmine installieren

Das Verzeichnis für die Redmine-Dateien kann frei gewählt werden (ich verwende /srv/www/redmine). Die einzige Voraussetzung ist, dass der Webserver Leserechte für diesen Pfad besitzt.

Download und Installation

Die aktuelle Version von Redmine kann bei Rubyforge heruntergeladen werden. Die derzeit aktuelle Version ist 0.8.4.

# mkdir -p /srv/www/
# cd /srv/www/
# wget http://rubyforge.org/frs/download.php/56909/redmine-0.8.4.tar.gz
# tar xvzf redmine-0.8.4.tar.gz
# mv redmine-0.8.4 redmine
# cd redmine

Nun müssen die Zugriffsrechte gesetzt werden, so dass der Webserver (www-data) schreibend auf files/, log/, tmp/ und public/plugin_assets/ zugreifen kann:

# mkdir tmp public/plugin_assets
# chgrp -R www-data files log tmp public/plugin_assets
# chmod -R g+w files log tmp public/plugin_assets

Leere Datenbank einrichten

Als erstes wird eine leere Datenbank sowie ein User mit jeweils dem Namen ‘redmine’ angelegt. Dem neuen User werden volle Zugriffsrechte auf die Datenbank gegeben:

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

Anpassen der Konfiguration

Damit Redmine auf die Datenbank zugreifen kann, müssen die Zugangsdaten entsprechend eingetragen werden:

# cp config/database.yml.example config/database.yml

In der Datei config/database.yml muss der Abschnitt ‘production’ angepasst werden:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password
  encoding: utf8

Die anderen Abschnitte sind nur dann interessant, wenn man Redmine in einer anderen als der ‘production’-Umgebung betreiben möchte. Ansonsten können sie bleiben wie sie sind.

Die Datenbank befüllen

Nun kann Redmine auf die Datenbank zugreifen und das Schema kann per Rake-Task angelegt werden:

# rake db:migrate RAILS_ENV="production"

Es empfiehlt sich, die Default-Konfiguration ebenfalls zu laden, dies ist aber optional:

# rake redmine:load_default_data RAILS_ENV="production"

Testen der Installation

An dieser Stelle kann die Installation bereits mit dem WEBrick Webserver getestet werden:

# ruby script/server webrick -e production

Redmine sollte unter der Adresse redmine.example.com:3000 erreichbar sein und ein login (User: admin, Passwort: admin) sollte ebenfalls möglich sein. Hinweis: Damit der Login nicht fehlschlägt, müssen (Session-)Cookies akzeptiert werden.

Mit Ctrl-C wird der Webserver wieder beendet.

SMTP Konfiguration

Soll Redmine E-Mails versenden können, muss eine weitere Konfigurationsdatei angepasst werden:

# cp config/email.yml.example config/email.yml

Hier muss ebenfalls der Abschnitt ‘production’ bearbeitet werden:

production:
  delivery_method: :smtp
  smtp_settings:
    address: localhost
    port: 25
    domain: example.com
    authentication: :none

Apache installieren

Für diesen Teil der Installation musste ich recht lange herumprobieren, bis das Gespann aus Rails, mod_fcgid und Apache korrekt funktioniert hat. Bei diesem Zusammenspiel kann leider allzuviel schiefgehen.

Zunächst wird das CGI-Script an Ort und Stelle gebracht:

# cp public/dispatch.fcgi.example public/dispatch.fcgi

Eine weitere Anpassung ist nicht notwendig.

Es folgen die benötigten Debian-Pakete…

# aptitude install apache2 libapache2-mod-fcgid libfcgi-dev

… sowie ein weiteres gem:

# gem install fcgi

[Update 24.10.09: Als ich kürzlich auf Version 0.8.5 umgestellt habe, habe ich bemerkt, dass ich hier einen Schritt unterschlagen habe, den ich hiermit nachreichen möchte. Und zwar müssen in der public/.htaccess folgende Zeilen auskommentiert werden:

#<IfModule mod_cgi.c>
#       AddHandler cgi-script .cgi
#</IfModule>

und

#<IfModule mod_cgi.c>
#       RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#</IfModule>

Ansonsten schreibt Apache den Request bis zum Erreichen des Limits immer wieder um und produziert einen Internal Server Error.]

Zuletzt wird der Virtual Host redmine.example.com konfiguriert. Dazu wird die Datei /etc/apache2/sites-available/redmine mit folgendem Inhalt angelegt:

<VirtualHost *:80>
  ServerName redmine.example.com
  ServerAlias redmine

  ServerAdmin webmaster@localhost

  DocumentRoot /srv/www/redmine/public/

  <IfModule mod_fcgid.c>
    DefaultInitEnv RAILS_ENV production
    DefaultInitEnv GEM_HOME /var/local/lib/gems
    DefaultInitEnv RUBYLIB /usr/local/ruby/lib/
  </IfModule>

  <Directory /srv/www/redmine/public/>
    Options Indexes ExecCGI FollowSymLinks
    Order allow,deny
    Allow from all
    AllowOverride all
  </Directory>

  ErrorLog /var/log/apache2/redmine_error.log
  LogLevel warn
  CustomLog /var/log/apache2/redmine_access.log combined
</VirtualHost>

Nun muss nur noch die Konfiguration geladen und das Modul rewrite aktiviert werden:

# a2ensite redmine
# a2enmod rewrite
# /etc/init.d/apache2 restart

Wenn nichts schiefgegangen ist, steht Redmine jetzt unter redmine.example.com/ bereit. Für die weitere Konfiguration und die ersten Schritte lohnt sich ein Blick ins Redmine Manual.

Fangen wir mit den Paketen an, die direkt aus den Repositories bezogen werden können und die für die weitere Installation notwendig sind:

# aptitude install ruby libsqlite3-ruby libruby rdoc1.8 libopenssl-ruby

Die in Lenny enthaltene Version von rubygems ist leider zu alt, weswegen es manuell installiert werden muss:

# wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
# tar xzf rubygems-1.3.1.tgz
# cd rubygems-1.3.1
# export GEM_HOME=/var/local/lib/gems
# ruby setup.rb --prefix=/usr/local/ruby

Anm: Die aktuellste Version findet sich unter http://rubyforge.org/frs/?group_id=126.

Damit die installierten Dateien auch gefunden werden können, müssen die folgenden Zeilen in /etc/profile eingefügt werden (vor export $PATH):

if [ -d /usr/local/ruby/bin ]; then
  PATH="${PATH}:/usr/local/ruby/bin"
fi

if [ -d /usr/local/ruby/lib/ ]; then
  export RUBYLIB="${RUBYLIB}:/usr/local/ruby/lib/"
fi

if [ -d /var/local/lib/gems ]; then
  export GEM_HOME=/var/local/lib/gems

  if [ -d /var/local/lib/gems/bin ]; then
    PATH="${PATH}:/var/local/lib/gems/bin"
  fi
fi

Damit das veränderte environment zum Tragen kommt, muss man sich entweder aus- und wieder einloggen oder /etc/profile sourcen:

# . /etc/profile

Wenn man möchte, kann man noch einen Symlink für gem anlegen:

# cd /usr/local/ruby/bin/
# ln -s gem1.8 gem

Nun steht einer Installation von Rails mit Hilfe von rubygems nichts mehr im Wege:

# gem install rails

Ab hier kann man z.B. mit dem Ruby on Rails Tutorial Ruby on Rails Tutorial weitermachen.

Nach einigem googlen habe ich schließlich einen Link auf http://gears.google.com/terms.html?platform=linux gefunden, wo das Firefox/Iceweasel-Addon klaglos installiert werden kann.

Bin gespannt, was der »Turbo« so bringt…

Das GNOME-Environment bringt zwar schon eine entsprechende Funktion mit, die den eigenen Desktop für einen Zugriff von außen freigibt, diese basiert aber leider auf »reinem« VNC, d.h. die Daten der Verbindung werden unverschlüsselt übertragen. In einem LAN mag das gehen, für die Übertragung im Internet habe ich nach einer verschlüsselten Variante gesucht.

Letztlich habe ich mich dafür entschieden, eine VNC-Verbindung über ssh zu tunneln. NX habe ich mir zwar auch angesehen, der Client unterstützt aber leider keine Pubkey-Authentifizierung und war auch sonst in der Bedienung eher umständlich. Das System auf beiden Seiten ist jeweils Debian GNU/Linux »Etch« und so geht es:

1. ddclient

Zunächst muss dafür gesorgt werden, dass man den zu betreuenden Rechner auch erreichen kann. Sofern dieser keine statische IP-Adresse hat, muss man auf Dienste wie z.B. DynDNS oder easyDNS ausweichen.

Ist der betreffende Rechner direkt mit dem Internet (ohne Router) verbunden, gibt es hier keine Hürden:

# aptitude install ddclient

installiert ddclient, das sich mit einer ganzen Reihe von Diensten verwenden lässt. Debconf fragt direkt nach allen relevanten Konfigurationsparametern, die man später wie gewohnt durch den Aufruf von dpkg-reconfigure ddclient noch ändern kann. ddclient meldet dann die aktuelle IP-Adresse an den jeweiligen Dienst, sobald eine Internetverbindung hergestellt wird.

Ein wenig komplizierter wird es, wenn ein Router ins Spiel kommt. In diesem Fall muss sich nämlich dieser um das Update beim DNS-Dienst kümmern — ob der jeweilige Router dies kann, ist der entsprechenden Dokumentation zu entnehmen. Darüber hinaus muss noch ein Port Forwarding eingerichtet werden, d.h. alle Verbindungen auf einen Port am Router werden zu einem Port eines der angeschlossenen Rechner weitergeleitet. Auch hierfür sei auf die Dokumentation des Herstellers verwiesen.

2. ssh

Sofern noch nicht vorhanden, muss auf dem Zielrechner ein ssh-Server installiert werden:

# aptitude install openssh-server

Aus Sicherheitsgründen sollte auf jeden Fall der Login für root gesperrt und auch Passwort-Logins deaktiviert werden. Diese Zeilen müssen dafür in /etc/ssh/sshd_config stehen:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Als nächstes ist ein Schlüsselpaar zu erzeugen und dessen öffenlicher Teil den autorisierten Schlüsseln des zu betreuenden Benutzerkontos hinzuzufügen:

$ ssh-keygen -t dsa -f /path/to/id_file
# cat /path/to/id_file >> /home/username/.ssh/authorized_keys

Den geheimen Teil des Schlüssels sollte man auf keinen Fall auf dem PC des Anwenders zurücklassen! Die Gefahr, dass der Schlüssel und damit der Zugang zu dem Rechner in Hände gerät, in die er nicht gehört, ist groß. Am besten erzeugt man sich ein entsprechendes »Support«-Schlüsselpaar zu Hause und nimmt es auf einem USB-Stick mit.

3. VNC

Als letztes muss noch der VNC-Server installiert werden:

# aptitude install x11vnc

Als letztes muss noch ein Passwort für diesen vergeben werden. Dazu füht man im Kontext des zu betreuenden Nutzers folgenden Befehl aus:

$ x11vnc -storepasswd ~/.vnc/passwd

Das Passwort ist wichtig, da sonst ein Zugriff auf den VNC-Server durch andere Benutzer, die auf dem gleichen PC angemeldet sind, möglich wäre.

Damit ist die Konfiguration abgeschlossen und man kann sich mit dem Rechner verbinden.

4. Eine Verbindung aufbauen

Wir befinden uns jetzt wieder am eigenen PC und möchten den Desktop unseres Nutzers auf unseren Monitor holen. Dazu wird zunächst der VNC-Server auf dem entfernten Rechner gestartet und dessen Port (5900) auf (den eigenen) localhost umgeleitet:

$ ssh -C -i /path/to/id_file -L 5900:localhost:5900 USER@HOST "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd"

Zur Erklärung:

• -C komprimiert die übertragenen Daten
• /path/to/id_file muss ersetzt werden durch den Pfad zum privatekey
• -L 5900:localhost:5900 leitet Port 5900 des entfernten Rechners auf Port 5900 von localhost um
• USER und HOST sind durch den Benutzernamen und den (dynamischen) Hostnamen zu ersetzen
• Der Rest der Zeile ist das Kommando, das auf dem entfernten Rechner ausgeführt werden soll: starten des VNC-Servers und Bereitstellung des Displays :0 auf localhost

Das Ergebnis sollte eine Meldung sein, dass der VNC-Server erfolgreich gestartet wurde und auf Verbindungen wartet.

Nun kann man sich mit einem VNC-Client der Wahl (z.B. vncviewer) am Server anmelden:

$ vncviewer localhost

Nach Eingabe des Passwortes ist man nun mit dem Desktop des entfernten PCs verbunden.

Noch ein Hinweis

Ich möchte ausdrücklich darauf hinweisen, dass selbstverständlich das Einverständnis des jeweiligen Benutzers vorliegen muss, bevor man sich mit dessen Computer verbindet!