Jira unter Debian mit SSL

Da hatte ich mir ja was vorgenommen. Eigentlich wollte ich nur "schnell mal" Atlassian Jira aufsetzen, um in den nächsten Tagen ein bisschen damit spielen zu können. Daraus wurde nun eine halbe Odyssee. Aber fangen wir von vorne an...

Bei Jira handelt es sich im Grunde um ein Bugtracking-Tool, das durch Erweiterungen wie GreenHopper (mein primäres Testziel) zu einem ausgewachsenen und ansehnlichen Aufgabenverwaltungstool wird. Und das ab gerade einmal $20! 😀

Leider gab es vom Start weg ein paar Probleme, die ich nach und nach aus dem Weg räumen musste. Das fing bereits bei der Installation an. Ich entschied mich für den Binary 64-bit Installer. Das ist eine große *.bin Datei, die man auf den Server schiebt und dort ausführt. Während der Installation soll man zwei Ports angeben - den eigentlichen HTTP-Port (Default: 8080) und einen Control-Port (Default: 8005). Ich hatte vorher per "netstat -l" sichergestellt, dass beide Ports unbenutzt sind. Trotzdem bekam ich folgende Fehlermeldung:

1
The Control port you have chosen appears to be in use. Please choose a different port number.

Ich dachte mir: Okay! Probiere ich halt einen anderen Port aus. Aber auch das half nichts. Egal, welchen Port ich testete. Natürlich führte ich den Installer als root aus, es sollte also kein Problem mit dem Öffnen der Ports geben. Erst nach langer Recherche stellte sich heraus, dass Jira (oder zumindest der Installer) ein Problem mit IPv6 hat. Also deaktivierte ich IPv6 und voila! Der Installer funktionierte!

Ich rief Jira das erste Mal unter http://jira.example.com:8080 auf und alles funktionierte soweit. Bis auf SSL. Aber das sollte ja nicht so ein großes Problem sein: Zertifikat erstellen, einbinden und fertig ist der Lack - dachte ich zumindest. Wie sich heraustellt, kann man Tomcat (auf dem Jira aufsetzt) nicht einfach Schlüssel und Zertifikat übergeben, sondern man muss das Zertifikat in einem Keystore abspeichert - so zumindest die Aussage der Jira-Dokumentation. Gesagt, getan. Alles soweit eingerichtet und dann das "./bin/config.sh"-Script aufgerufen. Ging aber nicht, weil die Java Runtime-Environment nicht gefunden wurde. Also musste ich ein bisschen nachhelfen:

1
export JAVA_HOME=`pwd`/jre

Nochmal den Aufruf probiert: Funktioniert! Hin zum Webserver-Profil gehangelt, den Keystore gewählt, das Keystore-Passwort eingegeben (das ich vom Standard "changeit" auf etwas sicheres geändert hatte) und den Alias eingetippt und...

1
The referenced certificate could not be found or accessed. Do you want to try again?  ([Y]/N)? >

Häh? Wie jetzt? Ich hatte das Zertifikat doch ordentlich eingebunden.

1
./jre/bin/keytool -import -alias tomcat -file ./bla.crt -keystore ./jre/lib/security/cacerts

Schnell nochmal im Keystore geguckt.

1
./jre/bin/keytool -list -alias tomcat -keystore ./jre/lib/security/cacerts

Siehe da. Das Zertifikat ist vorhanden, wie ich es gedacht hatte.

1
2
tomcat, Feb 28, 2013, trustedCertEntry,
Certificate fingerprint (MD5): 00:01:02:03:04:05:06:07:08:09:0A:0B:0C:0D:0E:0F

Irgendwie wollte das ganze einfach nicht klappen. Leider stellte sich die Jira-Dokumentation als nicht sonderlich hilfreich heraus und auch Google hatte von meinem Problem noch nie gehört. Plan B musste her. Und das war in diesem Fall, einfach Nginx als Proxy einzusetzen. Ja. Mit Nginx kenne ich mich aus, für den ist es ein Kinderspiel, Zertifikate zu verwenden. Ohne irgendwelchen Firlefanz. Also schnell meinen eigenen Blog durchsucht, erstmal Nginx konfiguriert, dann noch Nginx um SSL erweitert und schon war ich fast fertig. Fehlte nur noch... Nginx als Proxy zu konfigurieren. Das hatte ich noch nie gemacht. Doof. Aber andere Leute haben. Und es zum Funktionieren gebracht. Dazu haben sie in den entsprechenden Server-Block einfach folgende Zeilen eingefügt:

1
2
3
4
5
6
7
8
9
location / {
  proxy_set_header Host              $host;
  proxy_set_header X-Real-IP         $remote_addr;
  proxy_set_header X-Forwarded-Proto https;
  proxy_set_header X-Forwarded-For   $remote_addr;
  port_in_redirect                   off;
  proxy_redirect                     http://127.0.0.1:8080/jira /;
  proxy_pass                         http://127.0.0.1:8080;
}

Und damit Jira mitbekommt, dass es gerade per Proxy aufgerufen wird und trotzdem anständig funktioniert, muss in der "./conf/server.xml" beim Connector-Eintrag für den Port 8080 (wir erinnern uns, das ist der Default-HTTP-Port) noch folgendes hinzugefügt werden:

1
2
3
4
5
URIEncoding="UTF-8"
proxyName="jira.example.com"
address="127.0.0.1"
proxyPort="443"
scheme="https"

Zudem habe ich den Wert für den "redirectPort" im gleichen Connector-Blog abgeändert:

1
redirectPort="443"

Nun funktioniert alles wie gewollt. Nur leider mit einer Zwischenstufe mehr als erhofft. Wäre schön gewesen, wenn ich ohne Nginx ausgekommen wäre, aber so ging es schneller, einfacher und letzten Ende ist es so wahrscheinlich auch skalierbarer. Als Out-of-the-Box-Erlebnis würde ich den ersten Kontakt nun jedoch nicht mehr bezeichnen wollen.

Habt ihr schon einmal Erfahrungen mit dem Aufsetzen von Atlassian Jira gemacht und falls ja: Auf welche Probleme seid ihr gestoßen? Oder hat alles sofort und problemlos funktioniert? 😮
Testende Grüße, Kenny

P.S.: Das Tool "./bin/config.sh" scheint generell ein paar Probleme zu haben. Auch der Versuch, über das Tool von HSQLDB auf MySQL zu migrieren, schlug ebenfalls fehl. Nach den bisherigen Erfahrungen sollte man dieses Tool also dringend meiden.

6 Kommentare » Schreibe einen Kommentar

  1. Spätestens bei Java wär ich raus gewesen, da kann die Software noch so gut sein. Du solltest dann noch schauen, dass Du das Ding nur an localhost bindest oder den Port nach aussen per iptables dicht machst.

    Ich teste übrigens gerade viel mit dem TOR Netzwerk herum, da läuft das vom Prinzip her genau so. Bei meinem Lieblingswebserver (http://www.cherokee-project.com/) sollte das auch über einen einfachen reverse Proxy funktionieren.

    • Das Binden an Localhost ist natürlich in der Tat sinnvoll. Ich habe es mal in die Konfigurationsliste mit aufgenommen.

      Was ist denn in deinen Augen an Cherokee besser als an Nginx? Bei der Planung meines Servers hatte ich ja sämtliche bereitgestellten Services einzeln recherchiert. Und dort das rausgepickt, was mir von der Konfigurierbarkeit am ehesten zusagte.

      Bzgl. Java gebe ich dir Recht. Mir ist dabei auch ein bisschen mulmig. Deshalb läuft es auch getrennt von meinen restlichen Webseiten auf einem eigenen vServer bei einem fremden Hosting-Anbieter. 😀

        • Ich finde in dem Performancetest ja dieses G-WAN ziemlich spannend. Leider ist es Closed Source und damit kein Produkt, das ich einsetzen wollen würde.

          • Ja, G-WAN ist so eine Sache. Erstens kannst Du kein fertiges Script einsetzen, weil es keine echten Umgebungsvariabeln gibt und weil der PHP Support irgendwie so rein geschustert ist. Solltest Du also auf die ausgefallene Idee kommen, WordPress einsetzen zu wollen (ich weiß, crazy shit!!!11), kannst Du locker mal ein bis zwei Wochen einplanen, bis es überhaupt mal rudimentär läuft.

            Dann musst Du quasi alle Einstellungen als C Handler schreiben, was echt nerven kann (URL Rewriting, Zusätzliche Header usw.). Dann gibt es ja die Unterteilung in statisch und dynamisch (so ne Art cgi-bin), wo Du dann weiter nacharbeiten kannst bis die Ressourcen aus dem richtigem Ordner gelesen werden. Dann das Closed Source Problem. Dann gibt es ein paar Leute, die schon Sicherheitsprobleme gemeldet haben. Dann ist die Doku nur was für C Nerds bzw. nicht vorhanden. Es gibt keine Community, nur bezahlten Support. Und so zieht sich das dann weiter.

            Wenn ich dann sehe, dass der Performanceschub von Cherokee auf G-WAN nur den Faktor 2 hat (bei statischen Dateien), dann lohnt der Aufwand einfach nicht. Und ich tippe mal, es ist noch weniger, weil man Cherokee so einstellen kann, dass es alle statischen Dateien in den RAM lädt und nur von da abruft.

            Bei PHP ist es noch weniger, weil Du z. B. kein PHP-FPM einsetzen kannst und alles auf CLI läuft (und dazu noch relativ fehleranfällig). Man hat also auch keine Möglichkeit die PHP Prozesse auszulagern, was u. U. den Tag noch retten könnte. Skalieren mit G-WAN sehe ich nicht, weil es wirklich nur auf einen Rechner konzipiert ist. Dann bleiben noch statische Dateien, wo ich aber nicht weiß, ob sich der Aufwand lohnt, zwei Webserver zu pflegen.

            Auf'm Papier/Monitor sieht das sicher toll aus, aber in der Praxis taugt es einfach nicht.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.