Redmine ist ein wunderbares Projektmanagement-Tool. Ich setze es seit mehreren Jahren ein, sowohl privat als auch zeitweise im Unternehmensumfeld. Neben Projektverwaltung, Issue-Tracking-System, Diskussionsforum, Zugriff auf Versionsverwaltungssysteme bietet es auch pro Projekt ein Wiki, was bei meinem Einsatz letztlich eines der meist verwendeten Features darstellt. Daneben lässt es sich bereits im Auslieferungszustand vielfältig konfigurieren, es sind eigene Workflows möglich, das Berechtigungssystem erlaubt Mandantenfähigkeit und nicht zuletzt ist Redmine mit einer Vielzahl von Plugins erweiterbar, falls doch einmal die Standard-Funktionen nicht ausreichen sollten. Und dazu Open Source und frei verfügbar. Insofern – alles wunderbar, oder?
Leider nicht. Um es noch einmal zu wiederholen – Redmine ist ein wunderbares Tool. Sobald es denn einmal läuft. Dann läuft es rund – und die Installation möchte am besten gar nicht mehr angefasst werden.
Dabei ist die Installation an sich gar nicht besonders schwierig – nur dank Ruby on Rails ein wenig umständlicher als mal eben ein PHP-Skript in seinen Webspace zu kopieren. Das Schlimmste dabei sind jedoch die einfach nur schlechten Anleitungen, sowohl zur Installation als auch zum Upgrade. Fast wirkt es, als möchten die Entwickler gar nicht, dass man Redmine einsetzt und sogar irgendwie lieb gewinnt, denn dieser Ansammlung von kruden Hinweisen zu folgen, macht einfach keinen Spaß. Insofern ist es auch kein Wunder, dass es inzwischen einige Anbieter gibt, die gehostete Lösungen vermarkten oder fertig nutzbare Appliances bereit stellen. Leider sind die Preise bzw. deren Leistungen nicht wirklich adäquat zur privaten Nutzung, im Unternehmensumfeld würde ich hingegen jederzeit darauf zurück greifen. Googlen mit „Redmine Hosting“ hilft – da ich an dieser Stelle keine Anbieter empfehlen bzw. keine Werbung machen möchte.
Die Ausgangslage
Die alte Redmine-Installation bestand aus einer etwas angestaubten Version 2.4.x und befand sich auf einer ebenso älteren VM. Als Distribution wurde Ubuntu 14.04 LTS eingesetzt – zwar noch supported, aber alles andere als frisch. Ursprünglich lag sogar eine noch ältere Ubuntu-Fassung darunter, die auf 14.04 LTS hoch gezogen wurde. Bereits damals war der Aufwand nicht zu verachten, da alle Bundles neu installiert bzw. mit den richtigen Libraries gebaut werden mussten.
Redmine lief mit einer MySQL-/MariaDB-Datenbank, die ebenfalls auf der VM installiert war. Das Ziel war, alles autark auf einem System ohne weitere Abhängigkeiten zu haben. Auch lief auf dieser VM ausschließlich Redmine, ebenfalls war die MariaDB-Instanz nur für Redmine vorgesehen, es wurden keine anderen Datenbanken darauf gespeichert.
Redmine hatte ein etwas moderneres Theme bekommen, Plugins waren hingegen keine installiert. Bei einigen Wiki-Seiten wurden Dateien hinzugefügt, insofern mussten neben der Datenbank die Upload-Verzeichnisse migriert werden.
Der Migrationspfad
Der von mir zunächst geplante Migrationspfad sah wie folgt aus:
- Einrichtung einer neuen VM mit neuer Ubuntu-Distribution und ein wenig mehr Plattenplatz
- Auf der neuen VM Redmine einrichten (inkl. MariaDB)
- Backup vom alten System erstellen (Files und Datenbank)
- Altes System upgraden
- Daten vom alten System, was nun die neueste Redmine-Version besitzen sollte, auf das neue System kopieren
- hoffen…
Das war immerhin ein Plan. Der erste und zweite Punkt dürfte sich selbst erklären. Das bestehende System sollte nicht kompromittiert werden, zudem wäre es einfach, es bei Problemen weiterhin zu nutzen. Das Thema Backup darf natürlich nicht unterschätzt werden – die „Assets“ steckten ja gerade in Datenbank und den hochgeladenen Dateien, insofern steht ein Backup hier an erster Stelle.
Aber warum das alte System erst upgraden, dann die Daten auf das neue kopieren? Dieser Vorgehensweise ist eher klassisch. Meist lässt sich ein System leichter, d.h. mit weniger Problemen auf eine aktuelle Version bringen, wenn die (hoffentlich vorhandenen) Upgrade-Prozeduren verwendet werden. Nehmen wir z.B. eine Linux-Distribution, etwa Ubuntu. Der Aufwand, eine alte Distribution per „do-release-upgrade“ von einem Release auf das nächste zu heben, ist in den meisten Fällen geringer, als ein neues System aufzusetzen und dann mühsam, d.h. manuell alle Services des alten Systems umzuziehen.
Aber um es vorweg zu nehmen, dieser Migrationspfad war nicht in Stein gemeißelt, denn dabei kam ein zarter Lichtschein von Rails hervor – die Rails Migrations. Später dazu mehr.
Die Alternativen
Eine Alternative zu Redmine bzw. ein Tool, was sich letztlich daraus entwickelte, wäre OpenProject gewesen. Ich habe es kurz angesehen, dank Docker war die Installation zu Testzwecken eine Sache von nur wenigen Minuten. Bei OpenProject hätten die Daten aus Redmine übernommen werden können, für mein Szenario ein entscheidender Punkt.
Leider hat es mir nicht wirklich gefallen. Die UI sieht zwar moderner aus als die standardmäßige UI von Redmine, aber so richtig nutzerfreundlich erschien sie mir nicht, vor allem dann, wenn man nicht immer viel Platz auf dem Bildschirm hat. Ich verwende Redmine sowohl mit 27″-Display (und dann nicht im Vollbild), als auch mit 13″ auf dem Notebook, da fehlte mir einfach die Übersicht. Noch dazu ließ sich das Design nicht ändern. Darüber hinaus wurde in der freien Community-Version nahezu auf jeder Seite die Werbung für die Enterprise-Version angezeigt. Ich habe Verständnis für kommerzielle Unternehmen, aber die Verknüpfung zwischen „OpenProject Foundation e.V.“ und „OpenProject GmbH“ erscheint mir dann doch ein wenig zu eng.
Redmine selbst hätte ich durchaus gerne als Docker-Container installiert. Das hätte das Upgrade auf zukünftige Versionen voraussichtlich sehr erleichtert. Letztlich habe ich mich doch dagegen entschieden. Einerseits ist die Beschreibung des anscheinend offiziellen Docker-Images im Bereich von „geht so“. Darüber hinaus hatte ich diesbezüglich noch keine Erfahrung mit der Migration der Daten, und der Speicherort von lokalen Daten ist ja nach wie vor ein durchaus kritischer Punkt. Ein wesentlich umfassenderes Image war leider noch nicht auf dem neuesten Stand von Redmine, aber evtl. werde ich es mir in der nächsten Zeit noch einmal genauer ansehen.
Somit kam diesmal ausnahmsweise kein Docker zum Einsatz.
Einfach mal los laufen
Der erste Schritt sollte die Installation von Redmine & Co. auf der neuen VM sein – also einfach mal drauf los. Bei Ubuntu habe ich die momentan aktuelle Version 17.04 genutzt, wohlbekannt, dass es keine LTS-Variante ist, aber in dem Fall heißt es eben zeitnah zu updaten.
Zunächst MariaDB:
MariaDB macht es einem mit der Wahl der Repositories bzw. Installation sehr einfach. Ich habe den halb-manuellen Weg genommen, da ich es vorziehe, externe Repositories nicht in der zentralen sources.list-Datei zu speichern.
sudo apt-get install software-properties-common sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
Datei /etc/apt/sources.list.d/mariadb.list editieren:
# MariaDB 10.2 repository list - created 2017-07-02 20:31 UTC # http://downloads.mariadb.org/mariadb/repositories/ deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.2/ubuntu zesty main deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.2/ubuntu zesty main
Und wie üblich update und die eigentliche Installation des MariaDB-Servers:
sudo apt update sudo apt install mariadb-server
Während des Installationsschrittes muss ein neues Root-Passwort für MariaDB gewählt werden.
Weitere Abhängigkeiten
Damit liegt MariaDB bereits lauffähig vor. Immerhin war somit die erste Abhängigkeit von Redmine erfüllt. Die anderen – nun, eine gute Frage. Redmine nennt z.B. ImageMagick oder diverse Binaries von Versionskontrollsystemen. Oder Ruby-Versionen. Spannend, aber an der Stelle nicht besonders hilfreich.
Zunächst einmal habe ich es mit ImageMagick versucht:
sudo apt-get install imagemagick
Das lief zwar soweit durch, aber reicht das? Darüber lässt sich die Installationsanleitung nicht aus. (Spoiler: Es reicht nicht.)
Schritt für Schritt – oder auch nicht
Anschließend soll – laut Schritt 1 – der Quellcode von Redmine herunter geladen werden. Ich habe mich für das neueste Release entschieden -getreu der Empfehlung der Entwickler.
Somit befand sich die Datei redmine-3.4.0.tar.gz nun bei mir im Home. Jedoch war an dieser Stelle nichts davon zu lesen, wo man die Redmine-Installation möglicherweise platzieren sollte. Das Kuriose dabei – die Anleitung bezieht sich auf den Download, danach folgt die Einrichtung der Datenbank, und im nächsten Schritt sollen die Datenbank-Konfigurations-Parameter eingerichtet werden. Diese befinden sich natürlich in einer Datei, die sich im vormals herunter geladenen Quellcode befindet. Schritt-für-Schritt-Anleitung? Mitnichten!
Daher habe ich die Installation analog zur bisherigen vollzogen. D.h. Redmine soll in /vol/www/redmine liegen, die Git-Repositories in /vol/repositories. Warum nicht in /var/www o.ä.? Einfach aus praktischen Gründen, ein Backup von /vol/ reicht, um alle relevanten Dateien zu erwischen.
Aber zunächst zur Datenbank, man logge sich als User root mit dem zuvor gewählten Passwort ein:
mysql -u root -p <Passworteingabe> MariaDB [(none)]> CREATE DATABASE redmine CHARACTER SET utf8; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'XXXXXXXXX'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost'; Query OK, 0 rows affected (0.00 sec)
Danach hieß es somit, erst einige Verzeichnisse anzulegen und den Quellcode dort hinein zu platzieren. Im Folgenden weiche ich auch teilweise vom Vorgehen, was in der Installationsanleitung genannt wird, ab. Beispielsweise wird darin kein User für Redmine angelegt, was ich aber durchaus bevorzuge.
$ sudo mkdir -p /vol/www $ cd /vol/www/ $ sudo tar xvfz /home/geschke/redmine-3.4.0.tar.gz $ sudo mv redmine-3.4.0 redmine $ sudo groupadd redmine $ sudo useradd -d /vol/www/redmine -g redmine -M redmine $ sudo chown -R redmine:redmine redmine/
Nun die Datenbank-Config – Datei umkopieren und die eigenen Daten eintragen:
$ cd /vol/www/redmine/config $ sudo cp database.yml.example database.yml
Datei in den Editor und im Bereich „production“ ändern:
production: adapter: mysql2 database: redmine host: localhost username: redmine password: XXXXXXXXX encoding: utf8
Dasselbe mit der E-Mail-Config:
$ sudo cp configuration.yml.example configuration.yml
Die bei mir verwendeten Werte lauten:
default:
# Outgoing emails configuration
# See the examples below and the Rails guide for more configuration options:
# http://guides.rubyonrails.org/action_mailer_basics.html#action-mailer-configuration
email_delivery:
delivery_method: :smtp
smtp_settings:
address: mailout.geschke.net
port: 25
domain: geschke.net
Dabei ist „mailout.geschke.net“ ein nur intern erreichbarer Mailausgangs-Server, der die Weiterleitung übernimmt. Somit der einfachste Weg, weitere Konfigurationsbeispiele finden sich in der Datei.
Danach bin ich vom oben beschriebenen Migrationspfad abgewichen. Was wäre denn, wenn von vornherein die bestehenden Daten genutzt werden könnten? Immerhin beschreibt die Anleitung zur Upgrade auch den Weg von einer Redmine Version 2.4.x zur momentan aktuellen Fassung. Natürlich unter Zuhilfenahme eines Backups, und genau dann wäre es auch irrelevant, ob das Backup auf einer neuen Installation auf einem neuen Server eingespielt wird, oder nur auf einer neuen Installation auf demselben Server. Vor allem würde ich die Lauffähigkeit der bestehenden Installation somit überhaupt nicht gefährden und könnte diese bei Problemen einfach weiter verwenden.
Gedacht, getan, zunächst also einen Dump der alten Datenbank gezogen (per mysqldump), danach die hochgeladenen Files gepackt und kopiert. Das Ergebnis wurde dann auf den neuen Server kopiert.
Datenbank-Dump: redmine_20170702.dump
Files: redminefiles-20170702.tar.gz
Die Files wurden entsprechend am gewünschten Ort entpackt:
$ cd /vol/www/redmine $ sudo tar xvfz /home/geschke/redminefiles-20170702.tar.gz
Dann noch ein paar Verzeichnisse anlegen und Rechte setzen:
$ cd /vol/www/redmine $ mkdir -p tmp tmp/pdf public/plugin_assets $ sudo chown -R redmine:redmine files log tmp public/plugin_assets $ sudo chmod -R 755 files log tmp public/plugin_assets
Ein Blick auf die standardmässig bei Ubuntu installierte Ruby-Version besagte, dass die Version 2.3.3 installiert werden würde. Das sollte reichen, insofern – wenn die Distribution schon aktuell genug ist, warum dann nicht einfach nutzen? Somit:
$ sudo apt install ruby bundler
Bundler musste mit genommen werden, subjektiv gefühlt wurden damit auch so gut wie alle Entwicklungs-Tools gleich mit installiert.
Nun konnten die notwendigen Ruby-Gems installiert werden. An dieser Stelle kürze ich jedoch etwas ab, denn es benötigte ca. drei Versuche, bis es letztlich erfolgreich war. Erstens wollte ich als User „redmine“ installieren, was aber nur funktioniert, wenn man einen Pfad wie „vendor/bundle“ angibt. Ok. Dann fehlte noch libmysqlclient-dev, somit installiert. Und nicht zuletzt gab es dann Probleme mit „rmagick„, das sollte doch dank „ImageMagick“ eingerichtet sein? Nein, da musste noch „libmagickwand-dev“ hinzu gefügt werden:
$ sudo apt install libmysqlclient-dev $ sudo apt-get install libmagickwand-dev
Nun aber wirklich los – als User „redmine“:
$ cd /vol/www/redmine $ bundle install --path vendor/bundle --without development test
Nach einiger Zeit tauchte tatsächlich die Erfolgsmeldung auf:
Bundle complete! 30 Gemfile dependencies, 54 gems now installed. Gems in the groups development and test were not installed. Bundled gems are installed into ./vendor/bundle.
Danach laut Anleitung den secret token generieren:
$ bundle exec rake generate_secret_token
Nun noch die Datenbank importieren:
$ mysql -u redmine -p redmine < redmine_20170702.dump <Passworteingabe>
Nun war also die alte Redmine 2.4.x Datenbank in einer neuen Redmine-Installation vorhanden. Genau dasselbe wie beim Upgrade!
Insofern hieß es hoffen, dass die Rails Active Record Migrations ordentlich geschrieben worden waren und dass die Datenbank-Auffrischung somit erfolgreich durchlaufen werden kann.
$ RAILS_ENV=production bundle exec rake db:migrate
Nach kurzer Zeit folgte die Bestätigung – keinerlei Fehlermeldung bei der Migration, das sah insofern gut aus!
Ad-hoc-Test
Für einen ersten Test reichte daher die Nutzung des integrierten Webservers:
$ bundle exec rails server webrick -e production -b 0.0.0.0 => Booting WEBrick => Rails 4.2.8 application starting in production on http://0.0.0.0:3000 => Run `rails server -h` for more startup options => Ctrl-C to shutdown server [2017-07-03 01:07:00] INFO WEBrick 1.3.1 [2017-07-03 01:07:00] INFO ruby 2.3.3 (2016-11-21) [x86_64-linux-gnu] [2017-07-03 01:07:00] INFO WEBrick::HTTPServer#start: pid=31631 port=3000
Perfekt! Das Einloggen war möglich, alle Daten waren vorhanden, einzig das Design ließ zu wünschen übrig, was am noch nicht vorhandenen Theme lag.
Das Ergebnis
Redmine läuft und musste nun nur noch richtig gestartet bzw. eingebunden werden. Dazu dient Thin in Kombination mit Nginx, evtl. später diesbezüglich mehr.
Falls keine alten Daten vorhanden gewesen wären, hätte zum Aufsetzen der Datenbank und Befüllen mit Default-Werten ebenfalls eine Migration genügt:
$ RAILS_ENV=production bundle exec rake db:migrate $ RAILS_ENV=production bundle exec rake redmine:load_default_data
Das macht das Installieren somit wiederum einfach – und erst recht das Upgrade auf neue Versionen. Über die Anleitung habe ich mich ja bereits ausgelassen, beispielsweise sind diese Schritte einfach nicht chronologisch sinnvoll erklärt. Beispiel? Irgendwo mittendrin wird auf mögliche Probleme mit Ubuntu beim Migrationsschritt eingegangen. Ubuntu wurde aber weder zuvor noch danach irgendwo erwähnt. Darüber hinaus wird als Lösung die Installation einer doch eher alten Library benannt. Auf welche Ubuntu-Version bezieht sich der Einschub? Oder – weitere Abhängigkeiten, etwa das Puma-Gem. Sinnvoll oder nicht? Weitere Hinweise zu Puma? Nein. Ohne weitere Quellen bzw. Hinweisen der vorherigen Installations-Mitschrift wäre ich nicht besonders gut weiter gekommen.
Aber immerhin – Redmine läuft, alle Daten sind vorhanden. Ein wunderbares System, was mir noch lange Zeit gute Dienste leisten wird, wenngleich das Upgraden keinen Spaß macht.
