Letzte Änderung dieses Dokuments: 06.04.2008, 11:36:15. Wie backe ich einen lokalen WiTa-Server?
1. Inhalt
2. Einleitung
2.1. Downloadmenge
3. Java Development Kit
3.1. Download
3.2. Installation
3.3. Konfiguration
4. Der Tomcat-Server
4.1. Download
4.2. Installation
4.3. Konfiguration
5. MySQL-Datenbank
5.1. Download
5.2. Installation
5.3. Konfiguration
6. Datenbank einrichten
6.1. Übernahme der Originaldaten
6.2. User anlegen
6.3. Abschliessender Test
7. Ant
7.1. Download
7.2. Installation
8. Projekt im Tomcat verankern
8.1. CVS-Checkout
8.2. Tomcat-Zubehör
8.3. JSP-Seiten installieren
8.4. Anpassungen am Projekt
8.4.1. SQL-Engine
8.4.2. Konfigurationsdatei
8.5. Projekt kompilieren
9. Die Stunde der Wahrheit...
10. Wenn es doch nicht klappt
Diese Anleitung beschreibt, wie man sich einen lokalen WiTa-Server zum
Testen zuhause installiert, damit man zum Testen nicht immer auf den
langsamen Server der Uni zugreifen muss.
Logischerweise hat das den Nachteil, dass man Änderung an der
Datenbankstruktur selbst mit dem Uniserver abgleichen muss.
Das System, auf dem ich das alles ermittelt habe, ist Debian/GNU Linux,
aber auch Windows-User werden berücksichtigt. Die wesentlichen Unterschiede
sind, dass bei Pfadangaben keine Laufwerksbuchstaben vorne stehen, dass
der "normale" statt des "umgekehrten" Schrägstriches zum Trennen von
Verzeichnissen benutzt wird und dass bei Eingaben auf der Kommandozeile
der Prompt
user@rechner:/aktueller/pfad$ befehl
lautet und nicht wie bei Windows
C:\aktueller\pfad> befehl
Wir werden eine Menge Zeug aus dem Internet herunterladen müssen,
daher gebe ich ich vorab mal eine kurze Zusammenfassung der jeweiligen
Sachen samt deren Grösse an.
Für den Download der benötigten Komponenten werden folgende Datenmengen anfallen:
| Komponente/Programm |
Windows |
Linux |
| Java Enterprise Edition 1.4 |
117,0 MB |
132,0 MB |
| Tomcat 4.1.29 |
8,4 MB |
7,4 MB |
| Ant 1.5.4 |
8,0 MB |
8,0 MB |
| MySQL 4.0.16 |
23,0 MB |
14,6 MB |
| WinCVS |
4,1 MB |
(entfällt) |
| GESAMT: |
160,5 MB |
162,0 MB |
Der Download dieser Datenmenge ist bei breitbandigen Internetanschlüssen
wie in der Uni oder bei DSL kein Problem. Wer aber noch mit ISDN oder gar Modem
unterwegs ist, wird sich bei geschätzten Downloadzeiten von 6-10 Stunden
sicher die Haare raufen.
Daher ich kann den Betroffenen hier folgendes anbieten: Schickt mir eine
Mail und bringt zum nächsten Tutorium einen leeren, 700 MB fassenden CD-Rohling
mit. Dann brenne ich die Daten für euch auf eine CD und gebe sie euch mit.
Wer vielleicht gerade noch einen anständigen Browser, z.B. einen aktuellen
Mozilla oder Firebird, oder Sonstiges dazu haben möchte, kann das ruhig
dabei schreiben.
Dieser Text basiert auf der Verwendung der Java2 Enterprise Edition 1.4, kurz
j2ee1.4.
Wer diese noch nicht hat, sollte es sich auf dieser Seite herunterladen. Einfach durchklicken, aber
bitte das richtige Release erwischen. Wir wollen das Komplettpaket mit dem
J2SE 1.4.2_02.
Die Installation erfolgt auf die übliche Weise, einfach die heruntergeladene
Datei ausführen und dem Wizard folgen. Man kann es sich installieren, wohin
man will. Ich gehe im Folgenden mal davon aus, dass es unter
/usr/local/j2ee1.4 liegt. Windows-User setzen überall in diesem
Dokument bitte den passenden Pfad ein, z.B. C:\j2ee1.4.
Wichtig: Für die spätere Verwendung des JDK im WiTa-Projekt müssen zwei
Umgebungsvariablen gesetzt werden:
| J2EE_HOME |
Zeigt auf die Installation des J2EE-Kits, also z.B.
/usr/local/j2ee1.4 oder C:\j2ee1.4. |
| JAVA_HOME |
Zeigt auf den Pfad der J2SE-Engine, die unterhalb des J2EE-Kits liegt,
also /usr/local/j2ee1.4/jdk oder C:\j2ee1.4\jdk. |
Linux-User setzen die Umgebungsvarbiablen nach der Manpage ihrer Lieblingsshell,
für die Bash wäre das:
mjw@triton:~$ export J2EE_HOME=/usr/local/j2ee1.4
mjw@triton:~$ export JAVA_HOME=$J2EE_HOME/jdk
Dauerhaft verankern lassen sich die Befehl in der ~/.profile.
Windows-User nutzen den Kommandozeileninterpreter COMMAND.COM oder CMD.EXE,
da wäre der Befehl:
C:\> set JAVA_HOME=C:\J2EE\JDK
C:\> set J2EE_HOME=C:\J2EE
Ausserdem kann man in der Systemsteuerung beim Symbol "System" eine Registerkarte
zum Eingeben von globalen Umgebungsvariablen finden.
Hier muss man die Variablen unbedingt definieren, denn andernfalls lässt sich
z.B. der Tomcat-Server gar nicht installieren.
Ausserdem kann es praktisch sein, das Verzeichnis mit dem Java-Compiler und
Interpreter in den Suchpfad (PATH-Umgebungsvariable) aufzunehmen.
Nun besorgen wir uns den Tomcat-Server. Das ist unser Webserver, der
die HTTPS-Verbindungen abwickelt und dabei gleich das JSP interpretiert. Wer
bereits einen lokalen Apache laufen hat, kann den Tomcat dort auch als Plugin
einbinden, um keine zwei Webserver zu haben, aber damit habe ich mich
nicht näher befasst.
Hier kann man sich den Server herunterladen, sowohl die Windows- als
auch die Linuxversion. Ich habe die aktuellste 4.1er-Version verwendet,
zur Zeit 4.1.29. Also einfach runter scrollen bis zu "Tomcat 4.1.29"
und die betreffende Version (.exe oder .tar.gz) auswählen.
Linux-User installieren den Tomcat einfach durch entpacken und verschieben
das entpackte Verzeichnis dahin, wo sie es haben wollen. Bei mir ist das
/opt/tomcat. Fertig.
Windows-User wählen beim Installer als Installationsvariante ruhig "Normal"
und als Verzeichnis C:\Programme\Tomcat. Wer Windows NT/2K/XP hat,
kann wegen mir auch gerne den passenden Hintergrunddienst installieren. Ich
habe das nicht gemacht, dann läuft der Tomcat in einem Terminalfenster und
loggt da seine Fehler schön mit. Das finde ich zum Rumprobieren besser.
Der Tomcat-Server läuft in der Voreinstellung auf dem Port 8080. Das entspricht
nicht dem WiTa-Server an der Uni, aber unprivilegierte Ports sind ohnehin besser für
solchen experimentellen Krams, dann benötigt man keine Adminrechte, um an
den Port zu binden.
Wichtig ist hier, dass man in der server.xml, die im Unterverzeichnis
conf liegt, in jedem definierten Connector (auch bei dem, der gleich
erst dazu kommt) das Attribut address="127.0.0.1" hinzufügt. Beispiel:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
address="127.0.0.1"
acceptCount="100" debug="0" connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
Dadurch bindet sich der Tomcat nur auf das lokale Loopback-Interface und
ist beispielsweise nicht für Angreifer aus dem Internet erreichbar.
Andernfalls könnte jeder von überall auf unseren Server zugreifen und das
will man nur, wenn man wirklich weiss, was man tut.
Wir starten den Tomcat-Server nun einfach mal. Für Linux bitte:
root@triton:~# /opt/tomcat/bin/catalina.sh start
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JAVA_HOME: /usr/local/lib/java
Bei Windows müssten zwei entsprechende Menüpunkte zum Starten und Stoppen
des Server vorhanden sein.
Nun läuft der Tomcat-Server hoffentlich. Zum Testen gibt ihr im Browser eurer
Wahl einfach mal folgende URL ein:
http://127.0.0.1:8080. Die IP-Adresse ist die des Loopback-Interfaces.
Unter Linux kann man auch "localhost" verwenden, Windoof löst den Namen jedoch
überlicherweise nicht auf.
Dann müsste eigentlich die Willkommen-Seite des Tomcat-Servers erscheinen. Zum
Vergleich, wie das aussieht, hier ein Screenshot davon:
Wenn das funktioniert, kann man als nächstes das nun lokal abrufbare
SSL Configuration
HOWTO abarbeiten. Darin steht studentensicher beschrieben, wie man den SSL-Support
zu aktivieren hat. Vergesst nicht, den neuen Connector auch ausschliesslich auf
127.0.0.1 zu binden!
Hat man auch das geschafft, kann man nun auch über https://127.0.0.1:8443 auf den Tomcat zugreifen. Wenn ein Hinweis
über irgendwelche Zertifikate kommt: Die könnt ihr ruhig akzeptieren, das ist das
Zertifikat, dass ihr selber nach dem SSL-HOWTO ausgestellt habt.
Damit ist der Tomcat-Server im Prinzip fertig eingerichtet, allerdings werden
ihn später noch ein paar Mal neustarten müssen. Für Windows hat man ja die Menüpunkte,
unter Linux sieht dann so aus:
root@triton:~# /opt/tomcat/bin/catalina.sh stop
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JAVA_HOME: /usr/local/lib/java
root@triton:~# /opt/tomcat/bin/catalina.sh start
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JAVA_HOME: /usr/local/lib/java
Die MySQL-Datenbank gibt es auch sowohl für Windows als auch für Linux
auf
dieser Seite.
Ich empfehle die Version 4.0.16, da ich sie hier auch verwende. Wer selber
auch Debian Sid nutzt, macht einfach:
root@triton:~# apt-get install mysql-server mysql-client
lehnt sich zurück und guckt der Paketverwaltung beim Arbeiten zu.
Andere sollten zuerst mal schauen, ob ihre Distribution nicht auch aktuelle
MySQL-Pakete anbietet. Der Rest, vor allem Windows-User, wird wohl die
Installation selbst vornehmen müssen.
Die Installation läuft recht automatisch, entweder durch Einspielen der
Pakete oder durch Ausführen des Installers, dessen Vorgaben zur Installation
man getrost übernehmen kann.
Unter Linux sollte der MySQLd automatisch von der Distribution gestartet
werden. Bei Windows findet ihr im Unterverzeichnis bin ein Programm
namens winmysqladmin.exe, damit könnt ihr die DB starten.
Am MySQL-Server selbst muss so weit eigentlich nichts konfiguriert werden.
Allerdings sollte man darauf achten, dass er sich auch korrekt an den Port
3306 bindet, bei meinem Debian war das aus Sicherheitsgründen nicht die
Standardeinstellung. Bei der Windows-Installation sollte es unnötig sein.
Ganz wichtig für Leute, die mit ihrem Rechner im Internet unterwegs sind:
Tragt in der Konfiguration (/etc/my.cnf oder my.ini)
in der Sektion [mysqld] die Zeile bind-address = 127.0.0.1
ein. Andernfalls nimmt der MySQLd Anfragen von überall - auch aus dem Internet
- entgegen. Und wie oben beim Tomcat tut dat nich Not.
Ob der Dienst richtig gebunden wurde, prüft man mit netstat:
root@triton:/etc/mysql# netstat -lnp|grep 3306
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 26407/mysqld
Unter Windows ist es etwas komplizierter, weil es da kein grep gibt:
C:\> netstat -n > list.txt
und dann müsst ihr in der Datei list.txt nach einer Zeile
wie da oben suchen.
Auf die gleiche Weise kann man übrigens oben den Tomcat-Server überprüfen.
Wenn das so aussieht wie oben, läuft der Server richtig. Wenn statt
127.0.0.1:3306 aber 0.0.0.0:3306 da steht, ist der Dienst nicht richtig
gebunden. Prüft die Konfiguration auf Tippfehler und ob ihr den MySQL
Dienst auch neu gestartet habt.
Nun müssen wir die Datenbankinhalte herbeischaffen. Dazu benutzen wir das
Kommandozeilentool mysqldump, das bei MySQL dabei ist. Damit verbinden
wir uns zum Testserver, melden uns an und holen uns die gesamte Datenbank namens
"test" (dort sind die aktuellen WiTa-Daten drin).
Falls jemand das Passwort für die Datenbank nicht weiss: Es steht unter anderem
in der Mail, die ich euch geschickt habe.
mjw@triton:~$ mysqldump -a -c -B
--user=wita --password=geheim test > dump.sql
C:\> cd \mysql\bin
C:\mysql\bin> mysqldump -a -c -B
--user=wita --password=geheim test > C:\dump.sql
Wer will, kann sich nun die dump.sql angucken und vielleicht noch was über SQL lernen.
Ansonsten verfeuern wir sie einfach an das MySQL-Frontend für die Konsole:
root@triton:~$ mysql < /home/mjw/dump.sql
C:\mysql\bin> mysql < C:\dump.sql
Um später mit der Datenbank arbeiten zu können, muss man im MySQL einen
Account anlegen, um darauf zugreifen zu können. Am besten übernimmt man hier
Benutzername und Passwort (siehe Mail) vom Testserver, dann hat man später
weniger Anpassungen vorzunehmen.
root@triton:~$ mysql -u root
mysql> grant all privileges on *.* to wita@localhost with grant option;
Query OK, 0 rows affected (0.00 sec)
mysql> set password for wita@localhost=PASSWORD("geheim");
Query OK, 0 rows affected (0.00 sec)
C:\mysql\bin> mysql -u root
mysql> grant all privileges on *.* to wita@localhost with grant option;
Query OK, 0 rows affected (0.00 sec)
mysql> set password for wita@localhost=PASSWORD("geheim");
Query OK, 0 rows affected (0.00 sec)
Das war es auch schon mit der Datenbank. Man kann jetzt schon mit dem
Konsolenfrontend und ein paar einfachen SQL-Queries ein bisschen in den Daten
herumstöbern. Auch, um mal zu testen, ob alles geklappt hat:
mjw@triton:~$ mysql --user=wita --password=geheim test
mysql> select email from Person where lastName="Schmidt";
+------------------------------------+
| email |
+------------------------------------+
| schmidaa@mathematik.uni-marburg.de |
| schmidaa@students.uni-marburg.de |
| schmidt.peter@email.de |
| email1@email.com |
+------------------------------------+
4 rows in set (0.00 sec)
C:\mysql\bin> mysql --user=wita --password=geheim test
mysql> select email from Person where lastName="Schmidt";
+------------------------------------+
| email |
+------------------------------------+
| schmidaa@mathematik.uni-marburg.de |
| schmidaa@students.uni-marburg.de |
| schmidt.peter@email.de |
| email1@email.com |
+------------------------------------+
4 rows in set (0.00 sec)
Wie man sieht, lassen sich die von der alten Gruppe eingegeben Daten
abfragen. Windows-Nutzer finden mit dem Programm WinMySQLadmin auch ein
(recht spartanisches) GUI-Frontend für die Datenbank. Linux-Nutzern und
denen, die keine Hemmungen haben, auch noch einen Apache zu installieren,
empfehle ich phpmyadmin.
Ant, das make für Java, gibt es hier. Bitte die Version 1.5.4 nehmen.
Einfach in ein passendes Verzeichnis entpacken. Für Windows vielleicht
C:\ant und für Linux /usr/local/ant. Und am besten das
Unterverzeichnis bin in den Suchpfad legen, das macht man unter
Windows bei den Umgebungsvariablen.
Wer als Windows-User noch keinen CVS-Client hat, kann sich mit
WinCVS einen kostenlosen
Client herunterladen. Linuxer brauchen nur in ihre Distribution zu schauen;
CVS ist immer dabei.
Wer das CVS-Repository noch nicht ausgecheckt hat, muss das jetzt machen.
Die jeweilige Windows-GUI wird jeder wohl selbst bedienen können, auf der
Kommandozeile geht's so (Usernamen im CVSROOT bitte anpassen):
mjw@triton:~$ export CVSROOT=':pserver:mjw@pc12285.mathematik.uni-marburg.de:/home/cvs'
mjw@triton:~$ mkdir cvs; cd cvs
mjw@triton:~/cvs$ cvs login
Logging in to :pserver:mjw@pc12285.mathematik.uni-marburg.de:2401/home/cvs
CVS password:
mjw@triton:~/cvs$ cvs checkout egs
...(viele Dateien)...
C:\cvs> set CVSROOT=":pserver:mjw@pc12285.mathematik.uni-marburg.de:/home/cvs"
C:\> mkdir cvs
C:\> cd cvs
C:\cvs> c:\wincvs\cvsnt\cvs login
Logging in to :pserver:mjw@pc12285.mathematik.uni-marburg.de:2401/home/cvs
CVS password: **********
C:\cvs> c:\wincvs\cvsnt\cvs checkout egs
...(viele Dateien)...
Nun bitte aus dem frischen CVS die benötigten Erweiterung für den Tomcat
installieren. Wer mag, kann sich die auch alle aus dem Internet zusammensuchen,
aber wenn es schon so schön vorbereitet ist...
Einfach alle JAR-Dateien aus dem Verzeichnis egs/implementierung/lib
in das Verzeichnis /opt/tomcat/shared/lib kopieren. Für Linux:
root@triton:~# cp /pfad/zu/egs/implementierung/lib/* /opt/tomcat/shared/lib/
C:\cvs> copy egs\implementierung\lib\*.* C:\Programme\Tomcat\shared\lib
Um die Projektdateien für den Webserver (die JSP-Seiten) zu installieren,
kopiert man am besten das ganze Verzeichnis egs/implementierung/web
nach /opt/tomcat/webapps und benennt es in "wita" um. Unter Linux
sieht das so aus:
root@triton:~# cp -r /pfad/zu/egs/implementierung/web /opt/tomcat/webapps/wita
C:\cvs> xcopy /s egs\implementierung\web C:\Programme\Tomcat\webapps\wita\
Öffnet mit einem Editor eurer Wahl die folgende Datei:
egs/implementierung/src/de/uni_marburg/wita/sql/Engine.java
und sucht darin nach dem der Variable "DATABASE_URL". Deren
Wert setzt ihr auf euren lokalen Rechner.
private static String DATABASE_URL = "127.0.0.1";
Wer beim Einrichten vom Datenbank-User und -Passwort vorhin was anderes
genommen hat, muss die anderen Variablen jetzt auch anpassen. Selber schuld. :-P
Der aktuelle Fehler, der verhindert, dass das Projekt richtig läuft,
hängt damit zusammen, dass in der neuen Konfigurationsdatei einige Passwörter
verschlüsselt wurden. Irgendwas geht beim Entschlüsseln schief, zumindest
auf einigen Rechnern. Während die von der alten Gruppe sich da mal die Köpfe
drüber zerbrechen, geben wir uns damit zufrieden, die Passwörter wieder
in Plaintext einzutragen.
Öffnet die Datei egs/implementierung/etc/config.xml und schaut
euch die JavaObject-Elemente mit einem encrypted="encrypted"
Attribut an. Das müssen drei sein. Entfernt dieses encrypted-Attribut und
schreibt die Klartextfassung als Objektwert rein. Mit dem Root-Passwort ist
das gemeint, mit dem man sich ganz am Anfang bei der WiTa-Oberfläche einloggt.
Das Datenbank-Passwort kennt ihr ja nun schon. SMTP-Passwort kann leer bleiben.
Wenn ihr schon dabei seid, könnt ihr auch gerade den Datenbankserver
wieder auf euren Rechner umbiegen. Dieser Eintrag wird zwar gegenwärtig nicht
ausgewertet (weil das noch in der oben genannten Datei fest verdrahtet ist),
aber es kostet ja nichts.
Danach kopiert ihr die Datei in das webapps/wita Verzeichnis
unterhalb vom Tomcat.
Nun - und später auch immer mal wieder - muss man eine neue WAR-Datei bauen
und diese zusammen mit den kompilierten Klassen dem Tomcat unterschieben.
mjw@triton:~$ cd cvs/egs/implementierung
mjw@triton:~/cvs/egs/implementierung$ ant war
(Ausgabe siehe Windows-Box, ist identisch)
C:\cvs> cd egs\implementierung
C:\egs\implementierung> c:\ant\bin\ant war
Buildfile: build.xml
init:
compile:
[mkdir] Created dir: C:\cvs\egs\implementierung\classes
[javac] Compiling 68 source files to C:\cvs\egs\implementierung\classes
[javac] C:\cvs\egs\implementierung\src\de\uni_marburg\wita\test\orga\Test.ja
va:28: warning: Date(int,int,int) in java.sql.Date has been deprecated
[javac] Person p1 = new Person("Schmidt", "Jan Eric", "Herr", ad
1, new java.sql.Date(3,1,1), "Uni-Marburg", "", "email1@email.com", false);
[javac]
^
[javac] 1 warning
war:
[copy] Copying 1 file to C:\cvs\egs\implementierung\web
[copy] Copying 1 file to C:\cvs\egs\implementierung\web
[war] Building war: C:\cvs\egs\implementierung\wita.war
[war] Warning: selected war files include a WEB-INF/web.xml which will be
ignored (please use webxml attribute to war task)
BUILD SUCCESSFUL
Total time: 52 seconds
Nun müsste eine frische wita.war im Verzeichnis liegen. Diese bitte im Unterverzeichnis
webapps des Tomcat-Ordners ablegen. Das Verzeichnis egs/implementierung/classes
kann man komplett nach /opt/tomcat/webapps/wita/WEB-INF/classes kopieren.
root@triton:~$ cp /home/mjw/egs/implementierung/wita.war /opt/tomcat/webapps/
root@triton:~$ cp -r egs/implementierung/classes/* /opt/tomcat/webapps/wita/WEB-INF/classes/
C:\cvs\egs\implementierung> copy wita.war C:\Programme\Tomcat\webapps
C:\cvs\egs\implementierung> xcopy /s classes C:\Programme\Tomcat\webapps\wita\WEB-INF\classes\
GANZ WICHTIG: Danach muss man den Tomcat-Server neu starten!
So, nun sind wir endlich so weit. Falls ich keinen Fehler beim Tippen und ihr keinen
beim Nachmachen gemacht habt, können wir nun das WiTa-System komplett lokal nutzen.
Öffnet die URL
https://127.0.0.1:8443/wita und meldet euch am System an. Wenn ihr reinkommt, sieht
es wie gehabt aus. Nur dass eben alles deutlich schneller geht.
Mailt mir. Aber bitte mit einer brauchbaren Problembeschreibung. Nennt eurer
Betriebssystem, was genau ihr gemacht habt und an welcher Stelle das System
vom erwarteten Verhalten abweicht. Liefert ggf. die relevanten Teile des
Tomcat-Logs mit, zu finden unter /opt/tomcat/logs und in
/opt/tomcat/webapps/debug.log.
Wer noch Fehler findet oder Verbesserungsvorschläge hat, nur her damit.
| 