Tomcat + Apache2 auf Debian

Wär doch toll wenn man die Anwendungen die auf dem Tomcat laufen würden auch über den normalen 80er Zugriff erreichen könnte. Apache mod_jk machts möglich!

Aus Zwei mach Eins

Da ich gerade meinen Heimserver um diverse Entwickler Tools aufstocken möchte (Jenkins, Sonar, Nexus) musste erstmal ein Servlet-Container her: Tomcat
Port 80 ist bereits freigegeben und eigentlich nervt mich das Portgetippe (eh schon wissen: localhost:8080) beim URL Aufruf ziemlich. Wär doch toll wenn man die Anwendungen die auf dem Tomcat laufen würden auch über den normalen 80er Zugriff erreichen könnte, oder?

Naja, dann ran ans Eingemachte!

Installation Tomcat

Java

So noch nicht geschehen sollte sinnvollerweise eine Java Installation am Server vorhanden sein

# apt-get install openjdk-6-jre

Wer auf dem Server auch Programme compiliern will besorgt sich ein jdk. Für die Installatin von Java 7 verweise ich auf einen ausgezeichneten Blog Beitrag von SysadminsLife

Download und Installation

Auf der Tomcat Seite die gewünschte Version (im Falle des Tutorials die neueste 7.0) mit wget herunterladen und entpacken

# tar xvfz apache-tomcat-7.0.35.tar.gz

danach an eine passende Stelle verschieben /opt/tomcat

# mv apache-tomcat-7.0.35 /opt/tomcat

Zum Abschluss noch die Scripts ausführbar machen

# chmod +x /opt/tomcat/bin/*.sh

Tomcat User und Gruppe

# groupadd tomcat
# useradd -g tomcat -d /opt/tomcat tomcat
# usermod -G www-data tomcat
# chown tomcat:tomcat /opt/tomcat -R

Tomcat Startup Script

Unter /etc/init.d/tomcat wird das Tomcat 7 Script von collinpeters abgespeichert (Oh ja, Github rulez! Und gist erst recht – Danke für das schöne Script!)

Natürlich muss das Script noch ausführbar gemacht werden und es soll automatisch starten

# chmod +x /etc/init.d/tomcat
# update-rc.d tomcat defaults

Tomcat Server User

Tomcat will auch abgesichert sein, zumindest ein bisschen. Daher legen wir einen Benutzer für die Admin und Manager Webapps an. Unter /opts/tomcat/conf/tomcat-users.xml ist folgendes zu ergänzen

<tomcat-users>
    <role rolename="manager" />
    <role rolename="manager-gui" />
    <role rolename="admin"/>
    <role rolename="admin-gui"   />
    <user username="USER" password="PASSWORT"
     roles="admin,admin-gui,manager,manager-gui" />
</tomcat-users>

Bitte USER und PASSWORT durch eure Werte ersetzen.

Start und Test

Es wär alles für die Katz würden wir es nicht auch testen. Dafür starten wir das Service

# /etc/init.d/tomcat start

Nun sollte Tomcat unter http://<server-ip>:8080 erreichbar sein.

Installation mod_jk Apache connector

apt-get

Wie immer, als erstes ist das Package zu installieren:

# apt-get install libapache2-mod-jk

Dieses Apache Modul dient als Brücke zwischen dem Webserver und Tomcat

mod_jk Konfiguration

Mit ein paar Zeilen unter /etc/apache2/conf.d/jk.conf wird mod_jk konfiguriert

<ifmodule mod_jk.c>
    JkWorkersFile /etc/apache2/workers.properties
    JkLogFile /var/log/apache2/mod_jk.log
    JkLogLevel error
</ifmodule>

mod_jk Worker

Apache benötigt nun noch eine Konfiguration in der festgehalten wird wie er einen Request auf Tomcat umleitet

Unter /etc/apache2/workers.properties legen wir daher folgende Konfiguratino ab

workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-6-openjdk
ps=/
worker.list=default
worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1

sites-available

Nun muss Apache nur noch erfahren welche Requests er an Tomcat weiterleiten soll. Dazu fügen wir in /etc/apache2/sites-available/default JkMount Zuordnungen ein. Im Falle der Tomcat Manager Applikation wären das folgende Zeilen 8 und 9

<VirtualHost *>
ServerAdmin root@localhost
ServerAlias homeserver

DocumentRoot /var/www/
# weitere Konfiguration

JkMount /manager default
JkMount /manager/* default

</VirtualHost>

Test

Nun muss Apache natürlich neu gestartet werden:

# /etc/init.d/tomcat restart

Das wars, nun sollte unter http://<server-ip>/manager die erste Weiterleitung auf den Tomcat sichtbar sein!

Viel Spaß damit!

Ähnliche Artikel:

Kleine Java Tips: log4j Log Level im Programm ändern

Log4j ermöglicht einem während des Programmaufrufs das Log Level zu ändern, wie das geht wird in diesem Artikel aufgezeigt.

Will man dem Kunden nicht mit Logausgaben zumüllen, sich aber die Möglichkeit offen halten, dass dieser durch setzen eines zusätzlichen Parameters die Logausgaben erweitern kann, um im Problemfall aussagekräftigere Logfiles zu generieren, muss man dies zur Programmlaufzeit ändern. Mit diesen zwei kleinen Zeilen lässt sich das Log Level vom RootLogger für Apache Log4j wärend des Programmaufrufes ändern:

Level newLevel = Level.toLevel(level, Level.DEBUG);
Logger.getRootLogger().setLevel(newLevel);

Alternativ ist natürlich eine externe Konfigurationsdatei in der der Kunde den Parameter setzen kann und diesen auch ausführlich per Kommentar erklärt bekommt nie verkehrt.

Happy Coding

Ähnliche Artikel:

Gebt Oracle Zeit!

Seit der Übernahme Suns durch Oracle hat sich viel getan, vieles missfällt der Community. Doch Gebt Oracle Zeit! Es steht noch am Anfang und kann noch lernen.

Es schlägt zur Zeit überall große Wellen, erst kauft Oracle Sun auf, dann braucht es länger als einen Tag um sich in den Unternehmensstrukturen zurechtzufinden, gibt schließlich an Tag 2 nicht zu allen Projekten die weitere Zielsetzung bekannt. Will an Tag 3 doch tatsächlich mit dem Einkauf Geld verdienen und hat an Tag 4 immer noch nicht alle Projekte komplett gesichtet und die zukünftige Roadmap festgelegt. Verklagt daraufhin an Tag 5 Google, und während der Kampf Böse gegen Böse hier nun tobt, tun sich noch weitere Fronten auf. Eine Woche nach der Übernahme sprießen die Forks von Sun Projekten (Maria DB, Libre Office, Open Solaris) wie Maiglöckchen im Frühling. Zwei Wochen nach der Übernahme hat die Apache Software Foundation dem JCP den Rücken gekehrt. Oracle hatte im Lizenzstreit über Wochen hinaus keinerlei Bereitschaft für ein Miteinander gezeigt und strikt seine Sicht der Dinge fortgeführt.

Den Aufschrei der nun durch die Blogosphäre (grausames Wort) geht kann ich verstehen und nachvollziehen. Ja er ist sogar notwendig, damit Oracle sieht was diese Entscheidungen bewirken. Und dass dahinter sehr viel Emotion und Identifikation steckt.

Dass die ASF als Non-Profit-Organisation mit Oracle Lizenztechnisch im Klinsch liegt, und noch lange liegen wird, ist ebenfalls verständlich, und in meiner Position kann man hoffen dass hier das letzte Wort noch nicht gesprochen ist.

Und auch wenn ich selbst einige Entscheidungen seitens Oracle gern anders gesehen hätte, bleibt mir gerade deshalb nur zu sagen: Gebt Oracle Zeit!

Viele Geschäftsfelder dieser Firma funktionieren in und mit Java, man ist also davon abhängig. Und sie haben Recht, Java muss sich weiterentwickeln. Es herrschte lange Stillstand, der durch eine tolle Community kompensiert wurde. Durch 3rd Party Frameworks u.a.. Und deshalb kann die Community auch jetzt zeigen, dass ihr was an Java liegt, und weiterhin den Dialog suchen, versuchen Java voranzubringen und vor allem versuchen Oracle etwas Zeit zu geben einen Weg zu finden der für alle akzeptabel ist (und dabei weiterhin aufschreien wenn man nicht gehört wird).

Denn wenn Oracle noch nicht mal die Verpackung der Sun Produkte komplett erneuern konnte (siehe Bild), wie soll dann bei so vielen Projekten schon der für alle Beteiligten richtige Weg eingeschlagen sein?

Virtualbox Installationsdialog Oracle Sun gemixed

PS: Die zeitliche Anordnung der Ereignisse ist frei definiert. Die genannten Distanzen sollen vor allem eins Zeigen, es ist alles noch in den Kinderschuhen.

Ähnliche Artikel: