Hinweis:
Die hier beschriebene Speicherverwaltung lässt sich erst ab der Tomcat Version 5.5.15 realisieren und konzentriert sich auf die Linux-Architektur!

Auch wenn Tomcat einige gewisse Schwierigkeiten mit dem Umgang von großen JavaServer Pages mit sich bringt, so hilft der Kniff des Mitteilens, wieviel Arbeitsspeicher Ihr Server besitzt. Solche Angaben werden mit Hilfe der Variable CATALINA_OPT realisiert, die sich optional mit starten von Tomcat einbinden lässt. Dazu ist im Vorfeld eine Datei anzupassen. Sollte diese noch nicht vorhanden sein, erstellen Sie diese bitte:

$CATALINA_HOME/bin/setenv.sh

Neben anderen optionalen Parametern, auf die in diesem Beitrag aber kein Bezug genommen wird, soll es im folgendem um das Setzen der Variable für die Verwaltung des Arbeitsspeichers gehen. Der Inhalt dieser Datei, wird unter Linux wie folgt befüllt:

export CATALINA_OPTS="$CATALINA_OPTS -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Xms256m -Xmx2048m -XX:MaxPermSize=512m

Zunächst dient die Angabe von org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER für die Möglichkeit der Verwaltung des Arbeitsspeicher. Diese ist hierzu auf true zu setzen und steht erst ab der Tomcat-Version 5.5.15 zur Verfügung. Die nachfolgenden Attribute sind wie folgt zu verstehen:

-Xms256m (Mininum des Java Heap)
-Xmx2048m (Maximum des Java Heap)
-XX:MaxPermSize=512m (Permanent Generations Größe)

Die Angabe von -Xmx2048m verrät die Größe des RAMs. Stellen Sie diesen unter Linux zwingend auf den maximal zulässigen Arbeitsspeicher. Warum?, dies ist auf die Linux-Architektur zurück zu führen, welche den Arbeitsspeicher permanent und vollständig im Gebrauch hält. Sollte Tomcat nun nicht wissen, wieviel Arbeitsspeicher insgesamt zur Verfügung steht, wird er diesen auch nicht „beantragen”. Ist der Arbeitsspeicher zu diesem Zeitpunkt aber voll, so kann es zu merklichen Performance-Verlusten führen, da Tomcat selbst keinen freien Speicher findet. Linux bedient sich in diesem Fall des Auslagerns (SWAP). Wenn Tomcat weiß wieviel Arbeitsspeicher Sie wirklich besitzen, so wird bei Bedarf versucht, diesen auch zu allokieren. Der Linux-Kernel weiß nun das er viel zu viel Arbeitsspeicher hält und wird alte Daten Auslagern und Tomcat den RAM zusichern der gebraucht wird.

Mit einem Start oder Neustart von Tomcat wird die so eben angelegte, beziehungsweise angepasste Datei aufgerufen und Tomcat mit den entsprechenden Einstellungen gesetzt.

1. http://tomcat.apache.org/

update-alternatives --config java

Verständlicherweise ist dies nur möglich wenn mehr als eine Java-Runtime installiert ist. Dies ist oft der Fall. Besonders bei der Server Edition¹ von Ubuntu wird von haus aus nur die GIJ (GNU Interpreter for Java) mitgeliefert. Welche sich dadurch auszeichnet, das sich diese Runtime für fast nichts tiefgründigeres einsetzen lässt. Hintergrund ist die Lizenzvereinbarung von Sun Microsystems. Durch die abgespeckte Version ist eine Bestätigung durch den Anwender nicht notwendig. Im gegensatz zu der vollwärtigen Runtime die auf jedem Linux-Betriebsystem nachinstalliert werden kann.

Mit dem oben genannten Befehl lässt sich nun eine Standard Runtime definieren die sich mittelst einer textbasierte GUI präsentiert:

Mit dieser Methodik lassen sich viele Fehler bezüglich der Java Runtime schon im Vorfeld vermeiden, in dem keine abgespeckte, sondern vollwertige Runtime genutzt wird. Oft entfallen damit auch spezielle Konfigurationen am Server. Der folgende Befehlt gibt letztendlich Aufschluss ob nun standardmäßig die richtige Runtime genutzt wird.

java -version

1. Ubuntu Server Edition - http://www.ubuntu.com/products/whatIsubuntu/serveredition

dpkg-reconfigure console-setup

Wollt ich nun auch einmal festhalten.

sudo apt-get -y install libsvn-dev php-pear php5-dev
sudo apt-get -y install build-essential

Das Paket libsvn-dev stellt die nötigen Sources bereit die kompiliert werden müssen. Die Pakete php-pear und php5-dev sind für den Einsatz von PECL nötig um die automatische Installation zu realisieren. Letzteres Paket ist ein c - Compiler um die zuvor genannten Sources bauen zu können.

pear upgrade PEAR
pecl install -f svn

Bei manchen Paketen empfiehlt es sich, vor der eigentlichen Installation, ein PEAR Upgrade durchzuführen. Der PECL-Befehl, welcher mit php5-dev mitgeliefert wird, führt dann ein Script aus, um die SVN Extension zu kompilieren und in die lokale PHP-Version zu integrieren. Zum Schluss wird in der jeweiligen php.ini ein Eintrag fällig, um die SVN Extension letztendlich auch nutzen zu können.

extension=svn.so

Nun lässt sich über PHP diese Bibliothek im vollen Umfang nutzen. Hier noch ein Beispiel:

<?php
echo svn_update(realpath('working-copy'));
?>

Diese Extension ist bis einschließlich PHP6 nutzbar. Genaueres erfährt man über die Entwicklerseite.

[Update - 27. August 2009]

Im laufe der Kompelierung der SVN Extension können, vor allem auf einem recht jungen und frischem System, einige Fehler auftreten, welche durch fehlende Pakete resultieren. Hierbei kann unter anderem nach dem Paket -sasl2 und -lneon-gnutls gefragt werden. Um diese Pakete nachzuinstallieren sind jedeglich folgende Schritte nötig:

apt-cache search sasl2
sudo apt-get install libsasl2-dev libsasl2-modules-ldap

Und für das zweite Paket:

apt-cache search neon gnutls
sudo apt-get install libneon27-gnutls-dev

Danach sollte der pecl-Befehl erneut ausgeführt werden und mit einem „Build process completed successfully” enden.

aptitude -y install php5-curl

Das -y soll der Anweisung nur mitteilen, das dieses Paket ohne weitere Bestätigung installiert werden soll.

Als erstes benötigt man auf beiden Servern den SSH-Client¹ und natürlich die Möglichkeit der Verschlüsselung über SSL².

aptitude -y install ssh openssl ssl-cert

Eigentlich ist standardmäßig ein SSH-Client auf einem Root- oder V-Server installiert. Sollte es bei der Anweisung ssh zu einem Warnhinweis kommen, das dies bereits installiert ist, kann dieser ignoriert werden. Analog dazu die Anweisungen openssl und ssl-cert, die für die Erstellung von Zertifikaten nötig sind.

adduser backupuser

Mit dem Befehl adduser, der aus dem Bereich Debian / Ubuntu kommt, legt man sich einfachshalber auf beiden Servern den gleichen Benutzer an, der für die Kommunikation zuständig sein wird. Im allgemeinen Linuxbereich heisst dieser Befehl useradd. Bei genannten Befehl wird autoamtisch ein Benutzerverzeichnis und die benötigten Zugriffsrechte gesetzt. Mit passwd backupuser lässt sich das Passwort setzten, falls nicht schon bei adduser geschehen.

[Server A] => Hier werden Backups erstellt die auf einen anderen Server, über SSH, verschoben werden sollen.
[Server B] => Stellt die Möglichkeit bereit, sich ohne Passwort aber über SSL zu verbinden.

Es geht nun also auf Server A los. Als erstes meldet man sich mit dem User backupuser an und erstellt im Homverzeichnis ein „.ssh” Verzeichnis. Betritt es und erstellt darin einen Public- und Private-Key. Bei der Abfrage des gewünschten Dateinamen gibt man ssh.key ein. bei der Passwortabfrage einfach mit [ENTER] bestätigen und kein Passwort eintragen.

mkdir ~/.ssh
cd ~/.ssh
ssh-keygen -b 2048 -t rsa

Hierbei erhält man nun folgende zwei Dateien: id_dsa und id_dsa.pub. Dabei handelt es sich um den genannten Private- und Public-Key. Die Datei ssh.key.pub wird nun auf Server B kopiert. Der Ort sollte optional das Homeverzeichnis des zuvor erstellten Benutzers sein.

cat ssh.key.pub >> ~/.ssh/authorized_keys

Mit dem letzten Schritt fügt man den Public-Key zu den authorized keys, des aktuellen Benutzers hinzu. Sollte es hierbei zu einem Fehler kommen, ist wohlmöglich noch kein .ssh - Verzeichnis vorhanden. Demnach noch folgende Operationen durchführen und den letzten Schritt wiederholen.

mkdir ~/.ssh
touch ~/.ssh/authorized_keys
chmod go-rwx ~/.ssh/authorized_keys

Hierbei wird das besagte Verzeichnis und eine Datei mit dem Namen authorized_keys erstellt. Für einen nicht-öffentlichen Zugriff auf diese Datei sorgt der letzte Befehl.

Hat man dies erledigt lässt sich mit folgendem Befehl eine Datei vom Homeverzeichnis Server A auf das Homeverzeichnis Server B kopieren ohne eine Passwortabfrage zu erhalten. Dabei beziehe ich mich auf den erstellten backupuser und nenne Server B im folgendem Beispiel serv. Die backup.tgz steht für ein beispielhaftes Backup. (Die Datei ssh.key wurde zuvor mit oben beschriebenen Schritt erstellt)

scp -i ~/.ssh/ssh.key ~/backup.tgz backupuser@serv:backup.tgz

Es ist zu beachten, das der Zielpfad, das Homeverzeichnis von backupuser ist. Nach dem Doppelpunkt darf kein / (Slash) folgen!

Ich hoffe diese Anleitung bringt einigen etwas licht ins dunkle. Persönlich habe ich immer einen großen Bogen um diese Thematik gemacht. Wie man aber sieht, ist es gar nicht so schwer. Viel Erfolg beim ausprobieren.

1. http://de.wikipedia.org/wiki/Ssh
2. http://de.wikipedia.org/wiki/Transport_Layer_Security